From randell-ietf@jesup.org Fri Mar 1 00:37: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 D55EC21F886B for ; Fri, 1 Mar 2013 00:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9e2mRO1PvEv6 for ; Fri, 1 Mar 2013 00:37:15 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1E921F886A for ; Fri, 1 Mar 2013 00:37:15 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:3350 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UBLSs-00015c-Km for rtcweb@ietf.org; Fri, 01 Mar 2013 02:37:14 -0600 Message-ID: <51306893.1080103@jesup.org> Date: Fri, 01 Mar 2013 03:36:35 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Subject: [rtcweb] draft-jesup-rtcweb-data-protocol-04 published X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Mar 2013 08:37:15 -0000 FYI, draft-jesup-rtcweb-data-protocol-04 has been published: http://tools.ietf.org/html/draft-jesup-rtcweb-data-protocol-04 This is a major update based on discussions at the Interim, in-person afterwards and on the list. This moves the protocol to a 1-way declarative bidirectional channel creation (0 RTT) with no need to signal channel creation in SDP, and also allows for external negotiation or predefined channels. This provides websockets-like JS interface options, with the assumption that onopen will fire immediately at both ends (on sending Open at originator, and on receiving it at the other end). It brings back the idea of an even/odd Stream selection to avoid stream ID glare. -- Randell Jesup randell-ietf@jesup.org From christer.holmberg@ericsson.com Fri Mar 1 00:52: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 3BEBC21F8A5E for ; Fri, 1 Mar 2013 00:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.952 X-Spam-Level: X-Spam-Status: No, score=-5.952 tagged_above=-999 required=5 tests=[AWL=-0.303, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKxoYgTdrqWa for ; Fri, 1 Mar 2013 00:52:02 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 16FFC21F8992 for ; Fri, 1 Mar 2013 00:52:01 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-4a-51306c30f536 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 61.9F.10459.03C60315; Fri, 1 Mar 2013 09:52:00 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0318.004; Fri, 1 Mar 2013 09:52:00 +0100 From: Christer Holmberg To: Justin Uberti Thread-Topic: [rtcweb] JSEP-03: O/A state machine and trickle ICE with forking Thread-Index: Ac4VKEWZ4cYZzPT+TXSns1oyaegaDgAGp8mAAA6+H/AAH3olAAAWuuiA Date: Fri, 1 Mar 2013 08:51:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B10DDB0@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B10B6DE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B10B98F@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: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+Jvja5BjkGgwdajphZbpwpZrP3Xzu7A 5LFgU6nHkiU/mQKYorhsUlJzMstSi/TtErgyDjzZy16wLqTiyurp7A2MM4K6GDk5JARMJBqv /GOCsMUkLtxbz9bFyMUhJHCIUeLFlAmsEM4iRom/77YzdzFycLAJWEh0/9MGaRARUJN4OGsX K4jNLKAucWfxOXYQW1jAV+Lm4bVMEDUBEida/rNC2G4S/57cYgGxWQRUJE7/eQ8W5xXwlliw ZSoziC0kMJtJ4l6PHIjNKRAocfpIL9hMRqDjvp9awwSxS1zi1pP5UEcLSCzZc54ZwhaVePn4 HyuErShxdfpyJpCTmQU0Jdbv0odoVZSY0v2QHWKtoMTJmU9YJjCKzUIydRZCxywkHbOQdCxg ZFnFyJ6bmJmTXm64iREYGwe3/NbdwXjqnMghRmkOFiVx3jDXCwFCAumJJanZqakFqUXxRaU5 qcWHGJk4OKUaGPX/Mzfocjg95o93v+WukRa0ZJG9Fh8nR/C0fVe27jxaEDopapmU5s0Ejc+u GU/UWm4+DTmT9OCtbHOSu3zg5Fu1gjXZ2+5c/npm1YEpUqte1HyoYut4b3O0ZmqL68rpNy1E NsTw7ot4sJvv8q9XsivW8jY9stWptD/2f/ny/95rQnb/W6KVXqHEUpyRaKjFXFScCAAz2Gf9 WwIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-03: O/A state machine and trickle ICE with forking X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Mar 2013 08:52:04 -0000 SGkgSnVzdGluLA0KDQpObyBuZXcgcXVlc3Rpb25zIGluIHRoaXMgZS1tYWlsLCBidXQgY29tbWVu dHMgb24gdGhlIHByZXZpb3VzIG9uZXMg4pi6DQoNCi0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo+Pj4g UV9PQV8xOiBBcyBJIGhhdmUgY29tbWVudGVkIGVhcmxpZXIsIHRoZSBzdGF0ZSBtYWNoaW5lIGRv ZXMgbm90IHN1cHBvcnQgc2V0dGluZyBvZiByZW1vdGUgb2ZmZXIgd2hlbiBhDQo+Pj4gcmVtb3Rl IHByYW5zd2VyIGhhcyBiZWVuIHNldC4gQSBKUyBTSVAgYXBwIG1heSBlLmcuIHJlY2VpdmUgYW4g U0RQIGFuc3dlciBpbiBhIHJlbGlhYmxlIDE4eCByZXNwb25zZSwNCj4+PiBjYWxsIHNldFByYW5z d2VyLCBhbmQgdGhlbiByZWNlaXZlIGFuIFVQREFURSBvbiB0aGUgc2FtZSBsZWcgd2l0aCBhIG5l dyBvZmZlci4NCj4+Pg0KPj4+IFNlY3Rpb24gMy41LjIsIHBhcmFncmFwaCAyLCBhdHRlbXB0cyB0 byBwcm92aWRlIGEgd29ya2Fyb3VuZCBmb3IgdGhpcyBpc3N1ZS4gwqANCj4+U2VjdGlvbiAzLjUu MiB0YWxrcyBhYm91dCBwYXJhbGxlbCBmb3JraW5nLCBhbmQgaG93IGl0IGNhbiBiZSBzb2x2ZWQg YnkgY3JlYXRpbmcgYSBuZXcgUEMsIGFuZCB0aGVuIHNlbmQgYW4gVVBEQVRFIHRvIHByb3ZpZGUg dGhlIG5ldyBQQyBpbmZvcm1hdGlvbiB0byB0aGUgcmVtb3RlIGVudGl0eS4NCj4+DQo+PkJ1dCwg bXkgaXNzdWVzIGlzIHdoZW4gdGhlIHJlbW90ZSBlbnRpdHkgc2VuZHMgYW4gVVBEQVRFLCB3aXRo IGEgbmV3IG9mZmVyLiBJdCdzIG5vdCBldmVuIHJlbGF0ZWQgdG8gZm9ya2luZy4gU2VlIG15IGV4 YW1wbGUgYmVsb3c6DQo+Pg0KPj4NCj4+QlJPV1NFUiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBKUyBBUFAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqBSRU1PVEUgRU5JVFRZDQo+Pg0KPj7CoCDCoCAtLS0tLS0gY3JlYXRlIG9m ZmVyIC0tLS0tLS0tLS0NCj4+wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAtLS0tLS0tLSBTRFAgT2ZmZXIgMS0tLS0tLS0t LS0tLS0tLS0tPg0KPj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA8LS0tLS0tLSBTRFAgQW5zd2VyIDEgLS0tLS0tLS0tLS0t LS0tLQ0KPj7CoCDCoCAtLS0tLS0gc2V0IHByYW5zd2VyIC0tLS0tLS0tLQ0KPj4gwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgPC0t LS0tLS0gU0RQIE9mZmVyIDIgLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj7CoCDCoCAtLS0tLS0gPz8/ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4gUmlnaHQuIFRoaXMgaXMgY2xlYXJseSBhIHBy b2JsZW0sIGJ1dCB0aGUgcmVhc29uIGl0IGlzIGEgcHJvYmxlbSBpcyBiZWNhdXNlIHRoZSB0d28g c2lkZXMgZG9uJ3QgYWdyZWUgb24gdGhlIHN0YXRlIA0KPiBvZiB0aGUgbmVnb3RpYXRpb24uIElu IGEgZm9ya2luZyBjYXNlLCBpdCB3b3VsZCBiZSBoYW5kbGVkIHZpYSB0aGUgbWVjaGFuaXNtIEkg bWVudGlvbmVkIGFib3ZlLiBJbiBhIG5vbi1mb3JraW5nIA0KPiBjYXNlLCB0aGlzIGlzIG5vdCBz b2x2YWJsZSBldmVuIHdpdGggY2xvbmluZywgYmVjYXVzZSB0aGUgdHdvIHNpZGVzIGFyZSBvdXQg b2Ygc3luYy4gVGhlIGJyb3dzZXIgaGFzIHRvIGhhbmRsZSB0aGlzIA0KPiBjYXNlIGJ5IHJlamVj dGluZyBTRFAgT2ZmZXIgMi7CoA0KDQpJIGRvbid0IHVuZGVyc3RhbmQgd2hhdCB5b3UgbWVhbiBi eSAib3V0IG9mIHN5bmMiLiBPbmNlIHRoZSByZW1vdGUgZW50aXR5IGhhcyBzZW50IGFuIFNEUCBB bnN3ZXIsIGl0IGNhbiBzZW5kIGEgbmV3IFNEUCBPZmZlci4NCg0KS2VlcCBpbiBtaW5kIHRoYXQg dGhlIHJlbW90ZSBlbnRpdHkgZG9lcyBub3Qga25vdyB0aGF0IHRoZSBKUyBBUFAgaGFzIG1hcHBl ZCBTRFAgQW5zd2VyIDEgdG8gYSAicHJhbnN3ZXIiLiBJdCBjb3VsZCBhcyB3ZWxsIGhhdmUgbWFw cGVkIGl0IHRvICJhbnN3ZXIiIChpbiB3aGljaCBjYXNlIHRoZSBjdXJyZW50IHN0YXRlIG1hY2hp bmUgd291bGQgYWxsb3cgU0RQIE9mZmVyIDIpLg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoN Cj4gPlFfT0FfMzogV2hlbiBhIHByYW5zd2VyIGhhcyBiZWVuIHNldCwgdGhlIHN0YXRlIG1hY2hp bmUgZG9lcyBub3QgYWxsb3cgY3JlYXRpbmcgYSBuZXcgbG9jYWwgb2ZmZXIuDQo+Pg0KPj4gU28s IGlmIHRoZSBKUyBBUFAgbmVlZHMgdG8gc2VuZCBhIG5ldyBvZmZlciwgZS5nLiBiZWNhdXNlIG9m IEJVTkRMRSwgaXQgd291bGQgaGF2ZSB0byBzZXQgYW5zd2VyIGZpcnN0LiBCdXQsIHRoYXQgd291 bGQgYWdhaW4gbW9yZSBvciBsZXNzIHByZXZlbnQgc2VyaWFsIGZvcmtpbmcgKGF0IGxlYXN0IG9u IHRoZSBzYW1lIFBlZXJDb25uZWN0aW9uKS4NCj4NCj4gQ2FuIHlvdSBleHBsYWluIHRoZSBCVU5E TEUgY2FzZSB5b3UgaGF2ZSBpbiBtaW5kPyANCg0KU2VlIGV4YW1wbGUgYmVsb3csIHdoZXJlIHRo ZSBmaXJzdCBvZmZlciBjb250YWlucyBkaWZmZXJlbnQgcG9ydHMsIGFuZCB0aGUgc2Vjb25kIGlk ZW50aWNhbCBwb3J0cywgYWNjb3JkaW5nIHRvIEJVTkRMRS4NCg0KQlJPV1NFUiAgICAgICAgICAg ICAgICAgICAgICAgICBKUyBBUFAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgUkVNT1RFIEVOSVRUWQ0KDQogICAgLS0tLS0tIGNyZWF0 ZSBvZmZlciAtLS0tLS0tLS0tDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAtLS0tLS0tLSBTRFAgT2ZmZXIgMSAoRGlmZmVyZW50IHBvcnRzKSAtLS0tLS0tLS0t LS0tLS0tLT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC0t LS0tLS0gU0RQIEFuc3dlciAxIChTYW1lL0RpZmYgcG9ydHMpLS0tLS0tLS0tLS0tLS0tLQ0KICAg PC0tLS0gc2V0IHByYW5zd2VyIC0tLS0tLS0tLS0NCiAgICAtLS0tLS0tLS0tLS0tLS0tLSA/Pz8/ IC0tLS0tLS0tLQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAt LS0tLS0tLSBTRFAgT2ZmZXIgMiAoU2FtZSBwb3J0cykgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+ DQrCoA0KDQo+IFRoZSBCVU5ETEUgcmVuZWdvdGlhdGlvbiB0byBhIHNpbmdsZSBwb3J0IGNhbid0 IGhhcHBlbiBhdCB0aGlzIHBvaW50IGluIHRoZSBuZWdvdGlhdGlvbiwgYmVjYXVzZSB0aGUgY2Fs bGVyIG1heSByZWNlaXZlIGFub3RoZXIgYW5zd2VyIHRoYXQgZG9lc24ndCB3YW50IHRvIHVzZSBC VU5ETEUuDQoNCldlbGwsIHRoZW4gdGhlIEJST1dTRVIgaGFzIHRvICJmYWxsYmFjayIgdG8gZGlm ZmVyZW50IHBvcnRzIChwZXIgdGhlIG9yaWdpbmFsIG9mZmVyKS4gSXNuJ3QgdGhhdCB3aGF0ICJw cmFuc3dlciIgaXMgYWxsIGFib3V0IC0gaGF2aW5nIGFsbCByZXNvdXJjZXMgYXZhaWxhYmxlIGlu IGNhc2UgdGhlcmUgaXMgZ29pbmcgdG8gYmUgYSBkaWZmZXJlbnQgYW5zd2VyPw0KDQpOb3csIGZv ciBCVU5ETEUsIHdlIGNhbiBkaXNjdXNzIHdoZW4gdGhlIHNhbWUtcG9ydCBvZmZlciBpcyBzZW50 LCBidXQgdGhlcmUgbWF5IGJlIG1hbnkgT1RIRVIgcmVhc29ucyB3aHkgU0RQIE9mZmVyIDIgaGFz IHRvIGJlIHNlbnQsIHNvIHRoZSBwcm9ibGVtIGlzIG5vdCBCVU5ETEUtc3BlY2lmaWMuDQoNCg0K LS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KPj5RX1RJXzE6DQo+Pg0KPj5Bc3N1bWUgdGhlIEpTIEFQ UCByZWNlaXZlcyBhbiBTRFAgYW5zd2VyIGZyb20gcmVtb3RlIGVudGl0eSBBLCBhbmQgcHJvdmlk ZXMgaXQgdG8gdGhlIGJyb3dzZXIgYXMgYSBwcmFuc3dlci4gVGhlbiB0aGUgSlMgQVBQIHJlY2Vp dmVzIGFuIFNEUCBhbnN3ZXIgZnJvbSByZW1vdGUgZW50aXR5IEIsIGFuZCBwcm92aWRlcyBpdCB0 byB0aGUgYnJvd3NlciBhcyBhIHByYW5zd2VyLg0KPj4NCj4+VGhlbiwgdGhlIEpTIEFQUCByZWNl aXZlcyB0cmlja2xlIElDRSBjYW5kaWRhdGVzIGZyb20gYm90aCBlbnRpdGllcyBBIGFuZCBCLiBX aGF0IHdpbGwgaGFwcGVuIHRvIHRoZSB0cmlja2xlIElDRSBjYW5kaWRhdGVzIGZyb20gcmVtb3Rl IGVudGl0eSBBPyBUaGUgc2FtZSBxdWVzdGlvbiBhcHBsaWVzIGlmIHRoZSBicm93c2VyIHJlY2Vp dmVzIHBlZXIgcmVmbGV4aXZlIGNhbmRpZGF0ZXMgZnJvbSBBLg0KPj4NCj4+VGhlIGRyYWZ0IHNh eXMgdGhhdCB0cmlja2xlIElDRSBjYW5kaWRhdGVzIHdpbGwgYmUgcHJvdmlkZWQgdG8gdGhlIElD RSBBZ2VudCwgdGhhdCB3aWxsIHRoZW4gcGVyZm9ybSBjb25uZWN0aXZpdHkgY2hlY2tzIGV0Yy4g QnV0LCBkb2VzIHRoYXQgbWVhbiB0aGF0IHRoZSBJQ0UgQWdlbnQgd2lsbCBwZXJmb3JtIGNvbm5l Y3Rpdml0eSBjaGVja3Mgd2l0aCBib3RoIEEgYW5kIEIuDQo+Pg0KPj5UaGlzIGNvdWxkIG9mIGNv dXJzZSBiZSBoYW5kbGVkIGJ5IGFsd2F5cyBjcmVhdGluZyBzZXBhcmF0ZSBQZWVyQ29ubmVjdGlv bnMgKGFuZCBoZW5jZSBzZXBhcmF0ZSBJQ0UgYWdlbnRzKSBmb3IgQSBhbmQgQiwgZXZlbiBpbiB0 aGUgY2FzZSBvZiBzZXJpYWwgZm9ya2luZy4NCj4+DQo+PkJ1dCwgaW4gYW55IGNhc2UgSSB0aGlu ayB0aGUgZHJhZnQgYWxzbyBuZWVkcyB0byBkZXNjcmliZSB0aGUgSUNFIGltcGFjdHMgb2YgZm9y a2luZywgYmVjYXVzZSBjdXJyZW50bHkgSSBkb24ndCB0aGluayB0aGVyZSBpcyBhbnkgdGV4dC4N Cj4+DQo+PlRoYW5rcyBmb3IgcG9pbnRpbmcgdGhpcyBvdXQuIEkgZGlzY3Vzc2VkIHRoaXMgYXQg dGhlIElFVEYgODMuNSBpbnRlcmltLCBidXQgZm9yZ290IHRvIHB1dCB0aGlzIGludG8gdGhlIGRy YWZ0LiBUaGUgYW5zd2VyIGlzIHRoYXQgd2hlbiBCJ3MgcHJhbnN3ZXIgaXMgYXBwbGllZCwNCj4+ YW5kIHRoZSByZWNlaXZlZCBJQ0UgY3JlZGVudGlhbHMgYXJlIGRpZmZlcmVudCB0aGFuIHRoZSBw cmV2aW91cyBhbnN3ZXIgKGFzIHRoZXkgd291bGQgYmUgaW4gdGhpcyBjYXNlKSwgdGhlIGV4aXN0 aW5nIGNhbmRpZGF0ZXMgYXJlIGRpc2NhcmRlZC4NCj4+QnV0LCBBIGRvZXNuJ3Qga25vdyB0aGF0 LCBzbyBpdCBtYXkga2VlcCBzZW5kaW5nIFNUVU4gcmVxdWVzdHMsIHRyaWNrbGUgSUNFIGNhbmRp ZGF0ZXMgZXRjLg0KPg0KPiBUaGUgYXBwIHNob3VsZCBzZW5kIGEgdGVybWluYXRpb24gbWVzc2Fn ZSB0byBBIHdoZW4gaXQgYWNjZXB0cyB0aGUgcHJhbnN3ZXIgZnJvbSBCLg0KDQpTdWNoIHByb2Nl ZHVyZS9yZXN0cmljdGlvbiB3b3VsZCBoYXZlIHRvIGJlIGNsZWFybHkgZG9jdW1lbnRlZCBpbiBK U0VQLg0KDQo+IEV2ZW4gaWYgaXQgZGlkbid0bSB0aGUgU1RVTiByZXF1ZXN0cyB3b3VsZCBiZSBp Z25vcmVkIGJ5IHRoZSBpbXBsLCBhbmQgdGhlIElDRSBjYW5kaWRhdGVzIHdvdWxkIGJlIGlnbm9y ZWQgYnkgdGhlIGFwcCwgc28gSSBkb24ndCB0aGluayB0aGVyZSBpcyBhIHByb2JsZW0uDQoNClRy dWUgLSBhc3N1bWluZyB0aGUgYXBwIGlzIG5ldmVyIGdvaW5nIHRvICJzd2l0Y2ggYmFjayIgdG8g cmVtb3RlIGVudGl0eSBBLg0KDQo+PkJ1dCwgYXNzdW1lIHRoYXQgdGhlIEpTIEFQUCBkaXNjYXJk cyB3aGF0ZXZlciBjb21lcyBmcm9tIEEuIFRoZW4sIGlmIHRoZSBzZXNzaW9uIHdpbGwgZXZlbnR1 YWxseSBiZSBlc3RhYmxpc2hlZCB3aXRoIEEgKGkuZS4gdGhlIFNEUCANCj4+YW5zd2VyIGZyb20g QSBpcyBwcm92aWRlZCB0byB0aGUgYnJvd3NlciBhcyAiYW5zd2VyIiksIEEgbmVlZHMgdG8gYmUg aW5mb3JtZWQgdG8gcmUtc2VuZCBhbGwgdHJpY2tsZSBJQ0UgY2FuZGlkYXRlcyBldGMgYWdhaW4s IMKgYmVjYXVzZSANCj4+dGhlIHByZXZpb3VzbHkgc2VudCBvbmVzIHdlcmUgZGlzY2FyZGVkIChz aW5jZSB0aGUgSlMgQVBQIHByb3ZpZGVkIHRoZSBTRFAgYW5zd2VyIGZyb20gQiB0byB0aGUgYnJv d3NlcikuLi4NCj4NCj4gVGhlIGFwcCBjYW4ndCBrZWVwIHRoZSBzZXNzaW9uIGFsaXZlIHNpbXVs dGFuZW91c2x5IHdpdGggYm90aCBBIGFuZCBCLiBJdCBuZWVkcyB0byBwaWNrIG9uZSBvciB0aGUg b3RoZXIuIFRoZSBsYXN0IHRpbWUgdGhpcyB3YXMgDQo+IGRpc2N1c3NlZCwgdGhpcyB3YXMgZmVs dCB0byBiZSBhIHJlYXNvbmFibGUgc29sdXRpb24uIFBlcmhhcHMgdGhpcyBuZWVkcyB0byBiZSBj b2RpZmllZCBpbiB0aGUgSlNFUCBkcmFmdC4NCg0KSXQncyBub3Qgb25seSBhYm91dCBub3QgYmVp bmcgYWJsZSB0byBrZWVwIHRoZSBzZXNzaW9uIGFsaXZlIHNpbXVsdGFuZW91c2x5IHdpdGggYm90 aCBBIGFuZCBCIC0gaXQncyBhbHNvIGFib3V0IG5vdCBiZWluZyBhYmxlIHRvIGdvIGJhY2sgdG8g QS4gTWF5YmUgd2UgY2FuIGxpdmUgd2l0aCBzdWNoIHJlc3RyaWN0aW9uLCBidXQgYXMgSSBzYWlk IGVhcmxpZXI6IGl0IG5lZWRzIHRvIGJlIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQuDQoNCg0KLS0t LS0tLS0tLS0tLS0tLS0tDQoNCj4+IEkgYWN0dWFsbHkgdGhpbmsgdGhhdCBQZWVyQ29ubmVjdGlv biBjbG9uaW5nIHdvdWxkIHNvbHZlICpBTEwqIG9mIHRoZSBpc3N1ZXMgYWJvdmU6IHRoZXJlIHdv dWxkIGJlIG5vIG5lZWQgZm9yIHByYW5zd2VyLCB3aGljaCBtZWFucyB0aGF0IA0KPj4gdGhlIEpT RVAgTy9BIHByb2NlZHVyZXMgd291bGQgYmUgZnVsbHkgYWxpZ25lZCB3aXRoIFJGQyAzMjY0LiBB bmQsIElDRSBwcm9jZWR1cmVzIGNvdWxkIHRha2UgcGxhY2Ugd2l0aCBtdWx0aXBsZSByZW1vdGUg ZW50aXRpZXMgc2ltdWx0YW5lb3VzbHkuDQo+DQo+IEkgY29uc2lkZXJlZCB0aGF0IGluIHRoZSBw YXN0LCBidXQgUFJBTlNXRVIgaXMgbm90IGp1c3QgZm9yIGZvcmtpbmc7IGl0J3MgYWxzbyB1c2Vm dWwgaW4gdGhlIG5vbi1mb3JraW5nIGNhc2UgwqB0byBnZXQgbWVkaWEgZmxvd2luZyBhcyBmYXN0 IGFzIHBvc3NpYmxlIGluIGEgc2luZ2xlIE8vQSBzZXF1ZW5jZS7CoA0KDQpJbiBhIG5vbi1mb3Jr aW5nIGNhc2UsIGhvdyBkb2VzIGl0IG1ha2UgdGhpbmdzIGZhc3RlciB0aGFuIHNpbXBseSB1c2lu ZyBBTlNXRVI/DQoNCj4gVGhlIG92ZXJhbGwgb3BpbmlvbiBvZiB0aGUgV0cgd2FzIHRoYXQgUFJB TlNXRVIgc29sdmVzIHRoZSBwcm9ibGVtIGFib3ZlIGFuZCBwcm92aWRlcyBhIGZhaXJseSBnb29k IHRyZWF0bWVudCBvZiBmb3JraW5nIHdpdGhvdXQgDQo+IGludHJvZHVjaW5nIHNpZ25pZmljYW50 IGNvbXBsZXhpdHkuIEFkZGluZyBjbG9uaW5nIHdvdWxkIGFsbG93IGEgbW9yZSBjb21wcmVoZW5z aXZlIHRyZWF0bWVudCBvZiBmb3JraW5nLCBidXQgYXQgdGhlIGNvc3Qgb2Ygc2lnbmlmaWNhbnQg DQo+IGFkZGl0aW9uYWwgY29tcGxleGl0eS4gDQoNCkkgd2FzIGEgYmlnIHN1cHBvcnRlciBvZiBQ UkFOU1dFUiBteXNlbGYsIGJlY2F1c2Ugb2YgdGhlIHdheSB3ZSB3b3VsZCBzdXBwb3J0IGZvcmtp bmcgd2l0aCBhIHNpbmdsZSBQZWVyQ29ubmVjdGlvbi4NCg0KQnV0LCB3ZSBETyBuZWVkIHRvIGJl IGFibGUgdG8gc3VwcG9ydCB0aGUgdXNlLWNhc2VzIGluIFFfT0FfMSBhbmQgUV9PQV8zLg0KDQo+ IEFsc28sIEkgaGF2ZSB5ZXQgdG8gaGF2ZSBhbnkgYXBwbGljYXRpb24gYnVpbGRlciBhc2sgbWUg Zm9yIGNsb25pbmcgc3VwcG9ydC4NCg0KSSBkb24ndCBrbm93IHdoYXQgeW91ciBkZWZpbml0aW9u IG9mIGFwcGxpY2F0aW9uIGJ1aWxkZXIgaXMsIGJ1dCBJIGRpZCBteSBmaXJzdCBXaW5kb3dzOCAi SGVsbG8gd29ybGQiIGFwcCBsYXN0IHdlZWtlbmQsIHNvIEkgZ3Vlc3MgSSBjb3VudCBhcyBhIGJ1 aWxkZXIgLSBhbmQgSSB0aGluayB3ZSBzaG91bGQgcmUtY29uc2lkZXIgY2xvbmluZyA6KQ0KDQpS ZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From christer.holmberg@ericsson.com Fri Mar 1 02:12: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 B6C2721F869C for ; Fri, 1 Mar 2013 02:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.247 X-Spam-Level: X-Spam-Status: No, score=-6.247 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5H8ZKqiRNiX6 for ; Fri, 1 Mar 2013 02:12:20 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 85DCD21F85E2 for ; Fri, 1 Mar 2013 02:12:19 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-f5-51307f02a6e4 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 2C.6E.10459.20F70315; Fri, 1 Mar 2013 11:12:18 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0318.004; Fri, 1 Mar 2013 11:12:17 +0100 From: Christer Holmberg To: Justin Uberti , "Ejzak, Richard P (Richard)" Thread-Topic: [rtcweb] DRAFT Agenda for RTCWEB Thread-Index: AQHOFRLYvYjIpOEaVEm0BOghACRVm5iOJ7UogAGu4ICAAIu9gIAAKijg Date: Fri, 1 Mar 2013 10:12:17 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B10DEBC@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B10B717@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA7EAB@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+JvjS5TvUGgwYElGhZbpwpZ7Jv2gdmi tyHcYs6uB0wWa/+1s1s0zrVzYPNofbaX1WPq+VCPnbPusnss2FTqsWTJTyaPL5c/swWwRXHZ pKTmZJalFunbJXBlXN0wibngmGZF0yGtBsY9Gl2MnBwSAiYSzxa0s0HYYhIX7q0Hsrk4hAQO MUpc2jWHGcJZxCjR8fwZUIaDg03AQqL7nzZIg4hApsSED3/YQWqYBdYySvROnMQOkhAW0JVo uNHPDFGkJzFpwQJ2CNtN4ufEh4wgNouAisSr9V1MIDavgLfEkcPzGCGWrWGS+PRtEzvIMk6B QIlXEzJBahiBrvt+ag1YPbOAuMStJ/OZIK4WkFiy5zwzhC0q8fLxP1YIW1Hi6vTlTCBjmAU0 Jdbv0odoVZSY0v2QHWKtoMTJmU9YJjCKzUIydRZCxywkHbOQdCxgZFnFyJ6bmJmTXm64iREY ZQe3/NbdwXjqnMghRmkOFiVx3jDXCwFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGC0Wmd75 dOiW5leTX8vmJN2N5uZXvffDPFl4vcGT1T7O4hYsyb8iY5WX+tQql9zUm2KcHcTAVHk66aTx SoZ032XTJ/1QTeaJlj6233+vZtrmp9GzPk858366b0Ha+Vl3/m3vWrv7Xuk9XfetXZxbzMJF LjN8LX/z1PS1teGad1wfK5V+1IjWByixFGckGmoxFxUnAgAKTcOOgAIAAA== Cc: Richard Barnes , "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Mar 2013 10:12:20 -0000 SGksDQoNCj5CVU5ETEUgYW5kIGRhdGEgbXV4aW5nIHdvcmtzIGZvciBib3RoICJQbGFuIEEiIGFu ZCAiUGxhbiBCIi7CoA0KPg0KPlJlY2FsbCB0aGF0ICJQbGFuIEIiIGlzIG11eGluZyBtdWx0aXBs ZSBtZWRpYSBzb3VyY2VzIG9mIHRoZSBzYW1lIHR5cGUgb3ZlciBhIHNpbmdsZSBtPSBsaW5lLCBh bmQgQlVORExFIHRoZW4gcHJvdmlkZXMgbXV4aW5nIG9mIHRoZSBhdWRpbywgdmlkZW8sIGFuZCBk YXRhIG09IGxpbmVzLg0KDQpNeSB1bmRlcnN0YW5kaW5nIChiYXNlZCBvbiB0aGUgQm9zdG9uIHNs aWRlcywgYmVjYXVzZSBJIGhhdmVuJ3QgcmVhZCBDdWxsZW4ncyBwbGFuIGRyYWZ0IHlldCkgb2Yg IlBsYW4gQiIgaXMgdGhhdCBpdCBkaWRuJ3QgaW5jbHVkZSBCVU5ETEUgLSBvciBhbnkgb3RoZXIg bXVsdGktbWVkaWF0eXBlIG11bHRpcGxleGluZyBuZWdvdGlhdGlvbiBtZWNoYW5pc20gLSBidXQg b25seSBtdWx0aXBsZSBTU1JDcyBwZXIgbS0gbGluZS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXIN Cg0KDQoNCk9uIFRodSwgRmViIDI4LCAyMDEzIGF0IDM6MTAgUE0sIEVqemFrLCBSaWNoYXJkIFAg KFJpY2hhcmQpIDxyaWNoYXJkLmVqemFrQGFsY2F0ZWwtbHVjZW50LmNvbT4gd3JvdGU6DQpTaW5j ZSBtdWx0aXBsZXhpbmcgb2YgdGhlIGRhdGEgY2hhbm5lbCB3aXRoIFJUUCBtZWRpYSBoYXMgYmVl biBzaG93biBhcyBhIGRlc2lyYWJsZSBmZWF0dXJlIG9mIEJVTkRMRSAoYW5kIG1vc3Qgb2YgaXRz IHZhcmlhbnRzKSwgSSB3b3VsZCBzdWdnZXN0IHRoYXQgdGhpcyBiZSB0cmVhdGVkIGFzIGEgc2ln bmlmaWNhbnQgYWR2YW50YWdlIGZvciBCVU5ETEUgKGFuZCBzaW1pbGFybHkgY2FwYWJsZSB2YXJp YW50cykgb3ZlciBhbnkgcHJvcG9zYWwgd2l0aG91dCBpdC4gwqBDdWxsZW4ncyAiUGxhbiBBIiBp cyBwcmVmZXJyZWQgb3ZlciBQbGFuIEIgcHJlY2lzZWx5IGJlY2F1c2UgaXQgaGFzIGFuIGluY3Jl bWVudGFsIG11eGluZyBhZHZhbnRhZ2UuDQoNCkJSLCBSaWNoYXJkDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogcnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpy dGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mIENocmlzdGVyIEhvbG1iZXJn DQo+IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjcsIDIwMTMgMjozMCBQTQ0KPiBUbzogVGVk IEhhcmRpZTsgcnRjd2ViQGlldGYub3JnDQo+IENjOiBSaWNoYXJkIEJhcm5lczsgcnRjd2ViLWNo YWlyc0B0b29scy5pZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3J0Y3dlYl0gRFJBRlQgQWdlbmRh IGZvciBSVENXRUINCj4NCj4NCj4gSGksDQo+DQo+IERvZXMgdGhlIERhdGEgQ2hhbm5lbCBwYXJ0 IChvciBzb21lIG90aGVyIHBhcnQpIG9mIHRoZSBhZ2VuZGEgaW5jbHVkZQ0KPiBtYWtpbmcgYSBk ZWNpc2lvbiBvbiB3aGV0aGVyIGl0IHNoYWxsIGJlIHBvc3NpYmxlIHRvIGJ1bmRsZSB0aGUgRGF0 YQ0KPiBDaGFubmVsIHdpdGggdGhlIFJUUCBtZWRpYT8NCj4NCj4gT3IsIGRvIHdlIGFscmVhZHkg aGF2ZSBjb25zZW5zdXMgdGhhdCBpdCBzaGFsbCBiZSBwb3NzaWJsZT8NCj4NCj4gSnVzdCB0byBj bGFyaWZ5LCBiZWNhdXNlIEkgdGhpbmsgaXQgaXMgaW1wb3J0YW50IGlucHV0IGZvciB0aGUgTU1V U0lDDQo+IGRpc2N1c3Npb25zIG9uIHRoZSBhY3R1YWwgbWVjaGFuaXNtLg0KPg0KPiBSZWdhcmRz LA0KPg0KPiBDaHJpc3Rlcg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IEZyb206IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFtydGN3ZWItYm91bmNl c0BpZXRmLm9yZ10gb24gYmVoYWxmIG9mDQo+IFRlZCBIYXJkaWUgW3RlZC5pZXRmQGdtYWlsLmNv bV0NCj4gU2VudDogV2VkbmVzZGF5LCAyNyBGZWJydWFyeSAyMDEzIDc6NDkgUE0NCj4gVG86IHJ0 Y3dlYkBpZXRmLm9yZw0KPiBDYzogUmljaGFyZCBCYXJuZXM7IHJ0Y3dlYi1jaGFpcnNAdG9vbHMu aWV0Zi5vcmcNCj4gU3ViamVjdDogW3J0Y3dlYl0gRFJBRlQgQWdlbmRhIGZvciBSVENXRUINCj4N Cj4gVGhlIGFnZW5kYSBiZWxvdyBoYXMgYmVlbiB1cGxvYWRlZCBhcyBhbiBpbml0aWFsLCBkcmFm dCBhZ2VuZGEgZm9yIHRoZQ0KPiBncm91cC4gwqBDb21tZW50cyBvbiB0aGUgdGltaW5nIGFuZCBi YWxhbmNlIGFyZSBlbmNvdXJhZ2VkLg0KPg0KPiB0aGFua3MsDQo+DQo+IFRlZCBIYXJkaWUNCj4N Cj4gUlRDV0VCIERyYWZ0IEFnZW5kYQ0KPiBNYXJjaCAxMiwgMjAxMyA5OjAwIHRvIDExOjMwDQo+ DQo+IEFkbWluaXN0cml2aWEgKDUgbWluKQ0KPg0KPiBBRCBNZXNzYWdlICg1IG1pbikNCj4NCj4g RGF0YSBDaGFubmVsDQo+IMKgLSBkcmFmdC1qZXN1cC1ydGN3ZWItZGF0YS1wcm90b2NvbCAoMjAg bWluKQ0KPiDCoC0gZHJhZnQtdGhvbXNvbi1ydGN3ZWItZGF0YSAoMTUgbWluKQ0KPiDCoC0gZHJh ZnQtbWFyY29uLXJ0Y3dlYi1kYXRhLWNoYW5uZWwtbWFuYWdlbWVudCAoMTUgbWluKQ0KPiDCoC0g RGlzY3Vzc2lvbiAoMzAgbWluKQ0KPiDCoC0gQ29uc2Vuc3VzIGNhbGwocykgKDUgbWluKQ0KPg0K PiBXR0xDIElzc3VlIHJlc29sdXRpb24gKDMwIG1pbikNCj4gLSBkcmFmdC1pZXRmLXJ0Y3dlYi1z ZWN1cml0eQ0KPiAtIGRyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2gNCj4gLSBkcmFmdC1p ZXRmLXJ0Y3dlYi1vdmVydmlldw0KPiAtIGRyYWZ0LWlldGYtcnRjd2ViLXVzZS1jYXNlcy1hbmQt cmVxdWlyZW1lbnRzDQo+DQo+IFJUQ1AtWFIgKDE1IG1pbiApDQo+IC0gZHJhZnQtaWV0Zi1ydGN3 ZWItcnRwLXVzYWdlLTA2DQo+DQo+IEZFQyBpbiBSVENXRUIgwqAoQ2FsbCBmb3IgaW50ZXJlc3Qp DQo+IC0gZHJhZnQtbWFuZHlhbS1ydGN3ZWItZmVjZnJhbWUtMDAgKDUgbWluKQ0KPg0KPiBNb2Jp bGUgaXNzdWVzIGZvciBSVENXRUIgKENhbGwgZm9yIHJldmlldykNCj4gLSBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1yZWRkeS1ydGN3ZWItbW9iaWxlLTAwICg1IG1pbikNCj4NCj4N Cj4gTWFyY2ggMTQsIDIwMTMgOTowMCB0byAxMTozMA0KPg0KPiBKU0VQDQo+IC0gZHJhZnQtcnRj d2ViLWpzZXAgKDQwIG1pbikNCj4gLSBEaXNjdXNzaW9uICgzMCBtaW4pDQo+IC0gQ29uc2Vuc3Vz IGNhbGwocykgKDUpDQo+DQo+IFZpZGVvIENvZGVjIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIDEwOjE1IHRvIDExOjMwDQo+IDEuIGRyYWZ0LWFsdmVzdHJhbmQtcnRjd2ViLXZwOC0w MSAoMTUgbWlucykgMi4gZHJhZnQtYnVybWFuLXJ0Y3dlYi0NCj4gaDI2NC1wcm9wb3NhbC0wMStk cmFmdC1kYmVuaGFtLXdlYnJ0Y3ZpZGVvbXRpLTAxK2RyYWZ0LW1hcmpvdS1ydGN3ZWItDQo+IHZp ZGVvLWNvZGVjLTAwDQo+ICgyNSBtaW5zKQ0KPiDCoCDCoCDCoCBEaXNjdXNzaW9uICgzMCBtaW51 dGVzKQ0KPiDCoCDCoCDCoCBDYWxsIHRoZSBxdWVzdGlvbiAoNSBtaW51dGVzKQ0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBydGN3ZWIgbWFpbGlu ZyBsaXN0DQo+IHJ0Y3dlYkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3J0Y3dlYg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+IHJ0Y3dlYkBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QN CnJ0Y3dlYkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9y dGN3ZWINCg0K From harald@alvestrand.no Fri Mar 1 02:47: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 3608C21F88CF for ; Fri, 1 Mar 2013 02:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27ztCEaRtW3l for ; Fri, 1 Mar 2013 02:47:58 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1987121F8899 for ; Fri, 1 Mar 2013 02:47:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A7D2139E09F for ; Fri, 1 Mar 2013 11:47:55 +0100 (CET) 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 yulZpa1ex-rz for ; Fri, 1 Mar 2013 11:47:54 +0100 (CET) Received: from [193.157.215.103] (unknown [193.157.215.103]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id AD22739E05D for ; Fri, 1 Mar 2013 11:47:54 +0100 (CET) Message-ID: <5130875A.40304@alvestrand.no> Date: Fri, 01 Mar 2013 11:47:54 +0100 From: Harald Alvestrand 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: <7594FB04B1934943A5C02806D1A2204B10B717@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA7EAB@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B10DEBC@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B10DEBC@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Mar 2013 10:47:59 -0000 On 03/01/2013 11:12 AM, Christer Holmberg wrote: > Hi, > >> BUNDLE and data muxing works for both "Plan A" and "Plan B". >> >> Recall that "Plan B" is muxing multiple media sources of the same type over a single m= line, and BUNDLE then provides muxing of the audio, video, and data m= lines. > My understanding (based on the Boston slides, because I haven't read Cullen's plan draft yet) of "Plan B" is that it didn't include BUNDLE - or any other multi-mediatype multiplexing negotiation mechanism - but only multiple SSRCs per m- line. My understanding of Plan B is the same as Justin's. I remember the statement (or I may have made it) that "with Plan B, we're able to live without Bundle (would prefer to have it); with Plan A, we're absolutely dependent on Bundle, we can't live without it." From harald@alvestrand.no Fri Mar 1 02:53: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 AEE9221F8696 for ; Fri, 1 Mar 2013 02:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.498 X-Spam-Level: X-Spam-Status: No, score=-110.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AirsIUgKI7b4 for ; Fri, 1 Mar 2013 02:53:17 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E68BD21F8550 for ; Fri, 1 Mar 2013 02:53:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0C7B439E09F for ; Fri, 1 Mar 2013 11:53:15 +0100 (CET) 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 Hm89GM1PkXD0 for ; Fri, 1 Mar 2013 11:53:13 +0100 (CET) Received: from [193.157.215.103] (unknown [193.157.215.103]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id CA7B639E05D for ; Fri, 1 Mar 2013 11:53:13 +0100 (CET) Message-ID: <51308899.9050802@alvestrand.no> Date: Fri, 01 Mar 2013 11:53:13 +0100 From: Harald Alvestrand 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: <7594FB04B1934943A5C02806D1A2204B10B6DE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B10B98F@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060800010702090009080008" Subject: Re: [rtcweb] JSEP-03: O/A state machine and trickle ICE with forking X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Mar 2013 10:53:18 -0000 This is a multi-part message in MIME format. --------------060800010702090009080008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02/28/2013 11:37 PM, Justin Uberti wrote: > > > > On Wed, Feb 27, 2013 at 10:57 PM, Christer Holmberg > > wrote: > > > Hi Justin, > > Thanks for your response! > > Comments inline, with an additional state machine question (Q_OA_3). > > > ------------------ > > > >> Q_OA_1: As I have commented earlier, the state machine does not > support setting of remote offer when a > >> remote pranswer has been set. A JS SIP app may e.g. receive an > SDP answer in a reliable 18x response, > >> call setPranswer, and then receive an UPDATE on the same leg > with a new offer. > > > > Section 3.5.2, paragraph 2, attempts to provide a workaround for > this issue. > > Section 3.5.2 talks about parallel forking, and how it can be > solved by creating a new PC, and then send an UPDATE to provide > the new PC information to the remote entity. > > But, my issues is when the remote entity sends an UPDATE, with a > new offer. It's not even related to forking. See my example below: > > > BROWSER JS APP REMOTE ENITTY > > ------ create offer ---------- > -------- SDP Offer > 1-----------------> > <------- SDP Answer 1 > ---------------- > ------ set pranswer --------- > <------- SDP Offer 2 > ------------------- > ------ ??? ---------------------- > > > ------------------ > > > Right. This is clearly a problem, but the reason it is a problem is > because the two sides don't agree on the state of the negotiation. In > a forking case, it would be handled via the mechanism I mentioned > above. In a non-forking case, this is not solvable even with cloning, > because the two sides are out of sync. The browser has to handle this > case by rejecting SDP Offer 2. > My understanding is that the mismatch is that the JS APP isn't giving a consistent story to the browser on whether the answer was final or not. This sequence would work: BROWSER JS APP REMOTE ENITTY ------ create offer ---------- -------- SDP Offer 1-----------------> <------- SDP Answer 1 ---------------- ------ set remote pranswer(1) --------- <------- SDP Offer 2 ------------------- ------ set remote answer(1) ----- ------ set remote offer(2) ----- that is, when the JS app gets the information that there's a new offer incoming, it realizes that Answer 1 needs to be treated as a final answer, and finalizes it before passing in the new offer. (I'll leave it to others to argue about whether or not there needs to be a stable state between the set remote answer(1) and set remote offer(2)) --------------060800010702090009080008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 02/28/2013 11:37 PM, Justin Uberti wrote:



On Wed, Feb 27, 2013 at 10:57 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi Justin,

Thanks for your response!

Comments inline, with an additional state machine question (Q_OA_3).


------------------


>> Q_OA_1: As I have commented earlier, the state machine does not support setting of remote offer when a
>> remote pranswer has been set. A JS SIP app may e.g. receive an SDP answer in a reliable 18x response,
>> call setPranswer, and then receive an UPDATE on the same leg with a new offer.
>
> Section 3.5.2, paragraph 2, attempts to provide a workaround for this issue.  

Section 3.5.2 talks about parallel forking, and how it can be solved by creating a new PC, and then send an UPDATE to provide the new PC information to the remote entity.

But, my issues is when the remote entity sends an UPDATE, with a new offer. It's not even related to forking. See my example below:


BROWSER                         JS APP                                    REMOTE ENITTY

    ------ create offer ----------
                                             -------- SDP Offer 1----------------->
                                            <------- SDP Answer 1 ----------------
    ------ set pranswer ---------
                                            <------- SDP Offer 2 -------------------
    ------ ??? ----------------------


------------------

Right. This is clearly a problem, but the reason it is a problem is because the two sides don't agree on the state of the negotiation. In a forking case, it would be handled via the mechanism I mentioned above. In a non-forking case, this is not solvable even with cloning, because the two sides are out of sync. The browser has to handle this case by rejecting SDP Offer 2. 


My understanding is that the mismatch is that the JS APP isn't giving a consistent story to the browser on whether the answer was final or not.
This sequence would work:

BROWSER                         JS APP                                    REMOTE ENITTY

    ------ create offer ----------
                                             -------- SDP Offer 1----------------->
                                            <------- SDP Answer 1 ----------------
    ------ set remote pranswer(1) ---------
                                            <------- SDP Offer 2 -------------------
    ------ set remote answer(1) -----
    ------ set remote offer(2) -----
 
that is, when the JS app gets the information that there's a new offer incoming, it realizes that Answer 1 needs to be treated as a final answer, and finalizes it before passing in the new offer.

(I'll leave it to others to argue about whether or not there needs to be a stable state between the set remote answer(1) and set remote offer(2))


--------------060800010702090009080008-- From christer.holmberg@ericsson.com Fri Mar 1 03:24: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 7E46421F89B2 for ; Fri, 1 Mar 2013 03:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.247 X-Spam-Level: X-Spam-Status: No, score=-6.247 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBASpug0PI14 for ; Fri, 1 Mar 2013 03:24:25 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C092121F89E2 for ; Fri, 1 Mar 2013 03:24:24 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-f3-51308fe76347 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 74.0A.10459.7EF80315; Fri, 1 Mar 2013 12:24:23 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0318.004; Fri, 1 Mar 2013 12:24:23 +0100 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] JSEP-03: O/A state machine and trickle ICE with forking Thread-Index: Ac4VKEWZ4cYZzPT+TXSns1oyaegaDgAGp8mAAA6+H/AAH3olAAAZtDSAAALeZcA= Date: Fri, 1 Mar 2013 11:24:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B10DF97@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B10B6DE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B10B98F@ESESSMB209.ericsson.se> <51308899.9050802@alvestrand.no> In-Reply-To: <51308899.9050802@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+Jvje7zfoNAg9tzrC2O9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGXsPfWXteCvQMXGjcdYGhjPcncxcnJICJhI tB7YzAxhi0lcuLeerYuRi0NI4BCjxKZ7PSwQziJGielP/gA5HBxsAhYS3f+0QRpEBIIlep+/ ZwSxhQV8JW4eXssEEQ+QONHynxXC9pOY9fYX2AIWARWJVX/ng8V5Bbwlrr6byggxfx+TxJaV j1hAEpwCuhLXX85nB7EZgS76fmoN2FBmAXGJW0/mM0FcKiCxZM95qKtFJV4+/scKYStKXJ2+ HKpeT+LG1ClsELa2xLKFr5khFgtKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxjZcxMzc9LL DTcxAqPh4JbfujsYT50TOcQozcGiJM4b5nohQEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAMj 853PQkrz6wzWHF6aHbs7bNKWszL7Z+zjO3pY44KTZJyQoUW6ZJOtkO7ZOdI62trRfNn+qs4r LIO3hnXfm1p85m+s7gzec1Plr1yOnMB7jj/xkJW0/wY9//xZ/Ey2j5JWPGtSf1jM/Fxa5OmJ b2nmk7b93uflbhCy6azTncIeHh6nr2Xzw08rsRRnJBpqMRcVJwIAhm9tV1QCAAA= Subject: Re: [rtcweb] JSEP-03: O/A state machine and trickle ICE with forking X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Mar 2013 11:24:26 -0000 Hi Harald, >My understanding is that the mismatch is that the JS APP isn't giving a co= nsistent story to the browser on whether the answer was final or not. >This sequence would work: > >BROWSER =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 JS APP =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0REMOTE ENITTY > >=A0 =A0 ------ create offer ---------- >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0-------- SDP Offer 1-----------------> >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 <------- SDP Answer 1 ---------------- >=A0 =A0 ------ set remote pranswer(1) --------- >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 <------- SDP Offer 2 ------------------- >=A0=A0=A0 ------ set remote answer(1) ----- >=A0=A0=A0 ------ set remote offer(2) ----- > >that is, when the JS app gets the information that there's a new offer inc= oming, it realizes that Answer 1 needs to be treated as a final answer, and= finalizes it before passing in the new offer. The problem with such approach is that it will terminate forking, i.e. it w= ill not be possible to pass an SDP Answer from ANOTHER remote entity to the= browser. BROWSER JS APP R= EMOTE ENTITY A REMOTE ENTITY B ------ create offer ---------- -------- SDP Offer 1----------= -------> ------- SDP Offer 1 -----------= -----------------------------------------> <------- SDP Answer 1 (A) -----= ------ ------ set remote pranswer(1) --------- <------- SDP Offer 2 (A) ------= -------- ------ set remote answer(1) ----- ------ set remote offer(2) -------- <------ SDP Answer 1 (B) ------= --------------------------------------- ------ ???? ---------------------------- Regards, Christer From christer.holmberg@ericsson.com Fri Mar 1 04:38: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 BCDB621F8A3D for ; Fri, 1 Mar 2013 04:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.247 X-Spam-Level: X-Spam-Status: No, score=-6.247 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFhCic3w1Heb for ; Fri, 1 Mar 2013 04:38:27 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFD321F8806 for ; Fri, 1 Mar 2013 04:38:23 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-3f-5130a13fd5a1 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 76.C9.10459.F31A0315; Fri, 1 Mar 2013 13:38:23 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0318.004; Fri, 1 Mar 2013 13:38:22 +0100 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] DRAFT Agenda for RTCWEB Thread-Index: AQHOFRLYvYjIpOEaVEm0BOghACRVm5iOJ7UogAGu4ICAAIu9gIAAKijggAANEQCAAC8yIA== Date: Fri, 1 Mar 2013 12:38:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B10E0F0@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B10B717@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA7EAB@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B10DEBC@ESESSMB209.ericsson.se> <5130875A.40304@alvestrand.no> In-Reply-To: <5130875A.40304@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvja79QoNAg62/hSyO9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGX0X2tnKvjFVjFnxhbWBsa9rF2MnBwSAiYS K84/hLLFJC7cW8/WxcjFISRwiFHi++XTjBDOIkaJD+cvA1VxcLAJWEh0/9MGaRARCJboff6e EcQWFtCVaLjRzwwR15OYtGABO4QdJrFp7jswm0VAReJW9zcWEJtXwFti3dU7YPVCAv3MEjNm W4LYnALaEkvmrmUDsRmBDvp+ag0TiM0sIC5x68l8JohDBSSW7DnPDGGLSrx8/A/qAUWJq9OX Q9XrSCzY/YkNwtaWWLbwNTPEXkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFSN7bmJmTnq5 4SZGYCwc3PJbdwfjqXMihxilOViUxHnDXC8ECAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamC0 q1q+n2Hr+bSutSd29Hm15lRNFd+zQmiLt2BpYFHDW4nXRyx0K+f+95Xcu3ny5I8f9kqu6foW w1uhmxpTpbtbqNDZPVjksO3zG1Ollq182X+2/khd+LMs5hceBgKtWov2z/b+fPPAtEUHjGO+ Sq8WEZd9d6CjkLnrUIDMrWnrvpbV6YofEzirxFKckWioxVxUnAgAwewUp1MCAAA= Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Mar 2013 12:38:27 -0000 Hi, >>> BUNDLE and data muxing works for both "Plan A" and "Plan B". >>> >>> Recall that "Plan B" is muxing multiple media sources of the same type = over a single m=3D line, and BUNDLE=20 >>> then provides muxing of the audio, video, and data m=3D lines. >> My understanding (based on the Boston slides, because I haven't read Cul= len's plan draft yet) of "Plan B" is that=20 >> it didn't include BUNDLE - or any other multi-mediatype multiplexing neg= otiation mechanism - but only multiple SSRCs per m- line. > My understanding of Plan B is the same as Justin's. > > I remember the statement (or I may have made it) that "with Plan B, we're= able to live without Bundle (would prefer=20 > to have it); with Plan A, we're absolutely dependent on Bundle, we can't = live without it." If that was the outcome, I'm glad I understood wrong :) Regards, Christer From harald@alvestrand.no Fri Mar 1 04:45: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 A1EF621F8899 for ; Fri, 1 Mar 2013 04:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.224 X-Spam-Level: X-Spam-Status: No, score=-110.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3KW35cBEwWd for ; Fri, 1 Mar 2013 04:45:35 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3EE21F87C5 for ; Fri, 1 Mar 2013 04:45:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 496F839E0FD; Fri, 1 Mar 2013 13:45:28 +0100 (CET) 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 GRF97OZ7iDUQ; Fri, 1 Mar 2013 13:45:27 +0100 (CET) Received: from [193.157.215.103] (unknown [193.157.215.103]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 98E4039E09F; Fri, 1 Mar 2013 13:45:27 +0100 (CET) Message-ID: <5130A2E7.8060900@alvestrand.no> Date: Fri, 01 Mar 2013 13:45:27 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B10B6DE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B10B98F@ESESSMB209.ericsson.se> <51308899.9050802@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B10DF97@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B10DF97@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-03: O/A state machine and trickle ICE with forking X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Mar 2013 12:45:35 -0000 On 03/01/2013 12:24 PM, Christer Holmberg wrote: > Hi Harald, > >> My understanding is that the mismatch is that the JS APP isn't giving a consistent story to the browser on whether the answer was final or not. >> This sequence would work: >> >> BROWSER JS APP REMOTE ENITTY >> >> ------ create offer ---------- >> -------- SDP Offer 1-----------------> >> <------- SDP Answer 1 ---------------- >> ------ set remote pranswer(1) --------- >> <------- SDP Offer 2 ------------------- >> ------ set remote answer(1) ----- >> ------ set remote offer(2) ----- >> >> that is, when the JS app gets the information that there's a new offer incoming, it realizes that Answer 1 needs to be treated as a final answer, and finalizes it before passing in the new offer. > The problem with such approach is that it will terminate forking, i.e. it will not be possible to pass an SDP Answer from ANOTHER remote entity to the browser. > > BROWSER JS APP REMOTE ENTITY A REMOTE ENTITY B > > ------ create offer ---------- > -------- SDP Offer 1-----------------> > ------- SDP Offer 1 ----------------------------------------------------> > <------- SDP Answer 1 (A) ----------- > ------ set remote pranswer(1) --------- > <------- SDP Offer 2 (A) -------------- > ------ set remote answer(1) ----- > ------ set remote offer(2) -------- > <------ SDP Answer 1 (B) --------------------------------------------- > ------ ???? ---------------------------- Right. I don't think that's avoidable; after a second offer/answer exchange, you can't go back and act as if you were still in the first offer/answer exchange. Is there a sequence of SIP operations described in a spec that would allow this to happen? I don't even think it's logically possible in all cases. For example, if Offer 1 (and answer 1a and 1b) have the form m=audio and offer 2 is m=audio m=video then it's not possible to handle Answer 1(b) without dropping the video m-line - and in SDP offer/answer, you aren't allowed to drop m-lines, ever. (Right?) From christer.holmberg@ericsson.com Fri Mar 1 05:33: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 BAB5D21F905F for ; Fri, 1 Mar 2013 05:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.247 X-Spam-Level: X-Spam-Status: No, score=-6.247 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6TLfo+pVzoz for ; Fri, 1 Mar 2013 05:33:28 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 406E721F902E for ; Fri, 1 Mar 2013 05:33:27 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-ad-5130ae262419 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id AC.17.19728.62EA0315; Fri, 1 Mar 2013 14:33:26 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0318.004; Fri, 1 Mar 2013 14:33:26 +0100 From: Christer Holmberg To: Harald Alvestrand Thread-Topic: [rtcweb] JSEP-03: O/A state machine and trickle ICE with forking Thread-Index: Ac4VKEWZ4cYZzPT+TXSns1oyaegaDgAGp8mAAA6+H/AAH3olAAAZtDSAAALeZcAAAQ0NgAACMl1A Date: Fri, 1 Mar 2013 13:33:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B10E16F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B10B6DE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B10B98F@ESESSMB209.ericsson.se> <51308899.9050802@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B10DF97@ESESSMB209.ericsson.se> <5130A2E7.8060900@alvestrand.no> In-Reply-To: <5130A2E7.8060900@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvja7aOoNAg/l7rC2O9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGUs7L7KVjBDumLl7j2sDYxbhboYOTkkBEwk nq88zwxhi0lcuLeerYuRi0NI4BCjxJdf19hAEkICixglGrrCuxg5ONgELCS6/2mDhEUEdCQe 7m9gArGZBdQl7iw+xw5iCwv4Stw8vJYJoiZA4kTLf1YIO0qibdEvMJtFQEXi39mrYDavgLdE 05aFTBB7FzNL9B2+CHYQp4CuxI/rV1hAbEag476fWgO1TFzi1pP5TBBHC0gs2QPzgKjEy8f/ WCFsRYmr05dD1etILNj9iQ3C1pZYtvA1M8RiQYmTM5+wTGAUm4Vk7CwkLbOQtMxC0rKAkWUV I3tuYmZOernRJkZgjBzc8lt1B+OdcyKHGKU5WJTEecNdLwQICaQnlqRmp6YWpBbFF5XmpBYf YmTi4JRqYLQUvfStSZO/0jvMNk2cQdgke/+rmyfkdEMzOxbcObZTJSnsJZvjTZnVrmGpfUb7 Lh5jzutc82LfvfdLsr5b+jcsWKYcLCbn56X37qPJ/6ulWeJeAX0zRY7zuNkWOFh89RBXXPjd TG/2O7+sp00/ElMKu5jY05J4Tlx8ZWhV3lHdrvvacj6vEktxRqKhFnNRcSIAiCgWgF8CAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-03: O/A state machine and trickle ICE with forking X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Mar 2013 13:33:28 -0000 Hi, >>> My understanding is that the mismatch is that the JS APP isn't giving a= consistent story to the browser on whether the answer was final or not. >>> This sequence would work: >>> >>> BROWSER JS APP = REMOTE ENITTY >>> >>> ------ create offer ---------- >>> -------- SDP Offer 1-----= ------------> >>> <------- SDP Answer 1 ----= ------------ >>> ------ set remote pranswer(1) --------- >>> <------- SDP Offer 2 -----= -------------- >>> ------ set remote answer(1) ----- >>> ------ set remote offer(2) ----- >>> >>> that is, when the JS app gets the information that there's a new offer = incoming, it realizes that Answer 1 needs to be treated as a final answer, = and finalizes it before passing in the new offer. >> The problem with such approach is that it will terminate forking, i.e. i= t will not be possible to pass an SDP Answer from ANOTHER remote entity to = the browser. > > >> >> BROWSER JS APP = REMOTE ENTITY A REMOTE ENTITY B >> >> ------ create offer ---------- >> -------- SDP Offer 1------= -----------> >> ------- SDP Offer 1 -------= ---------------------------------------------> >> <------- SDP Answer 1 (A) -= ---------- >> ------ set remote pranswer(1) --------- >> <------- SDP Offer 2 (A) --= ------------ >> ------ set remote answer(1) ----- >> ------ set remote offer(2) -------- >> <------ SDP Answer 1 (B) --= ------------------------------------------- >> ------ ???? ---------------------------- > > Right. I don't think that's avoidable; after a second offer/answer exchan= ge, you can't go back and act as if you were still in the first offer/answe= r exchange. > > Is there a sequence of SIP operations described in a spec that would allo= w this to happen? It's not that common for the offerer (the BROWSER in this case) to RECEIVE = an offer in the backward direction before the call has been established, bu= t I HAVE seen such flow(s) somewhere. However, it is more common for the offerer to SEND a new offer (as I showed= in Q_OA_3) before the call has been established. It's used e.g. for negoti= ation down codecs, changing the media direction attribute, changing pre-con= ditions status - and, for BUNDLE. >I don't even think it's logically possible in all cases. > >For example, if Offer 1 (and answer 1a and 1b) have the form > >m=3Daudio > >and offer 2 is > >m=3Daudio >m=3Dvideo > >then it's not possible to handle Answer 1(b) without dropping the video m-= line - and in SDP offer/answer, you aren't allowed to drop m-lines, ever. (= Right?) Please keep in mind that, in SIP terms, we are talking about two separate e= arly SIP dialogs, and the SDP offer/answer state machines are independent f= rom each other. So, it would be allowed. PeerConnection cloning would introduce the same concept in browsers, as eac= h clone could represent a separate SIP early dialog.=20 Regards, Christer From magnus.westerlund@ericsson.com Fri Mar 1 06:23: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 E33B621E80C1 for ; Fri, 1 Mar 2013 06:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dI4dC0XK7C0H for ; Fri, 1 Mar 2013 06:23:10 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0740D21E80AE for ; Fri, 1 Mar 2013 06:23:09 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-ce-5130b9cd779f Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 3F.75.32353.DC9B0315; Fri, 1 Mar 2013 15:23:09 +0100 (CET) To: undisclosed-recipients:; Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Fri, 1 Mar 2013 15:23:08 +0100 Message-ID: <5130B9C3.3010404@ericsson.com> Date: Fri, 1 Mar 2013 15:22:59 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 CC: "rtcweb@ietf.org" X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDJMWRmVeSWpSXmKPExsUyM+Jvje7ZnQaBBr/28lis/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujHsLP7IWXGGt6JixnbGB8RRLFyMHh4SAicSKn8VdjJxAppjE hXvr2boYuTiEBE4ySpzes4IdJCEiICMxd/ZjVojEMkaJSxfPsIEkeAW0JRqmb2ABsVkEVCQe /1oNZrMJWEjc/NHIBrJAVCBY4uZiOYhyQYmTM5+AlTALqEvcWXwObL4wkP287x8zxD3iEmve cECU6ElMudrCCGHLS2x/O4cZxBYC2drUwTqBUWAWkqmzkLTMQtKygJF5FSN7bmJmTnq5+SZG YIgd3PLbYAfjpvtihxilOViUxHnDXS8ECAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamAsVjgY +vHQ18oNiSHrbyWYKweoO/2ayqSd+e60SNVDkfOdX+InpOq9ntTT7yLv9TlzoUe3pbSF1vVt h6YF7O/0/slj9fmI0fnZzJmeE+uFfQqrZnnMzln/5JOS4suuOX+XeCRkf5e5/El376kIowCG XL1aXhXGmXKVbTdPpbPfdy1KPbI3VliJpTgj0VCLuag4EQBA80Px/wEAAA== Subject: [rtcweb] Input to Video Codec Selection X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Mar 2013 14:23:11 -0000 WG, I hope everyone, especially Google, now have provided whatever input they have into the Video Codec discussion and selection. It is important that everyone has the possibility to evaluate the input in good time prior to the meeting. It is especially important if one might require legal or other support when evaluating the proposals or additional information, which might apply for IPR, as an example. To be extremely blunt, we don't want anyone revealing new input material during the presentations in Orlando. These presentations is only intended to provide a summary of the most important aspects from the proponents side. The RTCWEB WG chairs Magnus Westerlund Ted Hardie Cullen Jennings From worley@shell01.TheWorld.com Fri Mar 1 07:58: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 9CA4E11E80A2 for ; Fri, 1 Mar 2013 07:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.759 X-Spam-Level: X-Spam-Status: No, score=-2.759 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ng4OYqQhhCxU for ; Fri, 1 Mar 2013 07:58:56 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 13D1811E809C for ; Fri, 1 Mar 2013 07:58:55 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r21FwgUk021840; Fri, 1 Mar 2013 10:58:45 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r21FwguG2842193; Fri, 1 Mar 2013 10:58:42 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r21FwfGb2830347; Fri, 1 Mar 2013 10:58:41 -0500 (EST) Date: Fri, 1 Mar 2013 10:58:41 -0500 (EST) Message-Id: <201303011558.r21FwfGb2830347@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: "Ejzak, Richard P (Richard)" In-reply-to: <03FBA798AC24E3498B74F47FD082A92F36EA7EAB@US70UWXCHMBA04.zam.alcatel-lucent.com> (richard.ejzak@alcatel-lucent.com) References: <7594FB04B1934943A5C02806D1A2204B10B717@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA7EAB@US70UWXCHMBA04.zam.alcatel-lucent.com> Cc: rtcweb@ietf.org Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Mar 2013 15:58:56 -0000 > From: "Ejzak, Richard P (Richard)" > > Since multiplexing of the data channel with RTP media has been shown > as a desirable feature of BUNDLE (and most of its variants), I would > suggest that this be treated as a significant advantage for BUNDLE > (and similarly capable variants) over any proposal without it. > Cullen's "Plan A" is preferred over Plan B precisely because it has > an incremental muxing advantage. As far as I can tell from my analysis (http://tools.ietf.org/html/draft-worley-sdp-bundle-04#section-8), SCTP-over-DTLS can be demuxed from RTP and STUN quite easily. (This comes from RFC 5764 section 5.1.2.) And SCTP can be demuxed from the rest as long as you control the range of SCTP ports used. (And since the ports aren't actually to route the packets to the receiver (the underlying UDP does that), you have freedom in choosing SCTP ports.) So I don't see anything blocking Plan A as compared to Plan B. Of course, we have to *do* a bundle technique, but we've got a large library of possibilities now and can look at the fundamental design questions in context. Dale From juberti@google.com Fri Mar 1 08:33: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 DE3F311E80B8 for ; Fri, 1 Mar 2013 08:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtnP90nGXSPa for ; Fri, 1 Mar 2013 08:33:03 -0800 (PST) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3F211E809C for ; Fri, 1 Mar 2013 08:33:03 -0800 (PST) Received: by mail-qa0-f47.google.com with SMTP id j8so5141148qah.20 for ; Fri, 01 Mar 2013 08:33:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=D3cbdPLSkgiKuaALL0RgvC1je4Rd2JthZdJF3Tgghxc=; b=P160WoWyhqeLqJV8STlER94mo0OhIqump9XH4ykgXG+BX59X2b+QcjLMxJ2pq3P9SR HUL4G8aRDqA1zq37YHz60BpIvnVwvJ9OpdI5LXyvaEbc4uWE9t9P9CYVwOAIQdNSsrwZ 8RYtf9iONtvTwYq/u+Jd5mLfsoe0CoLHNMwQo5y3t9U0728WEPmW/t3SYd6x9riOZS9n U94q6Ufc28USTduVxumt0Amij11w0athBZ5xESX600K5jY0Ni5uwpur6rXKn5ITreNc2 ZPUZ/pKWBVngtj0hluHQ/sYxNbLAPFlGT+kiUMA+1DvggroXO1knHWcf5i4sYknZEpci e3YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=D3cbdPLSkgiKuaALL0RgvC1je4Rd2JthZdJF3Tgghxc=; b=YlZktggWnWOFkxu4fi38VGxHAXlWc2JRcfXgZO02P4IfaXZZgWCph8QQvzHJvYr7FM rwMZkAum7GurtBl6p4k6oai9hmG6Q+9xPARB3mGPlQ02a+58JsOPOoTYbdNvJDZr1klR 5UXxptod3CrciudGOXX85zLtnhxbVBFhF8fHvzqWa6cKJp0J9gFPlJD/tGT1upBQVT2T jxFCdlQ9T3U6zSNtUaHJc9FjFmzgwwWd6W4IPpCaW+pqVpzpP07ZnbhRHCDjw8vscNbI FHMwBhG88z/pT/HpR4uO5i1tF86Aqc+UQ64lYfq11BxRHUgs1kmyYlzWvMugeMy8UFfP Sbfw== X-Received: by 10.224.176.70 with SMTP id bd6mr20491521qab.26.1362155582741; Fri, 01 Mar 2013 08:33:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.206.17 with HTTP; Fri, 1 Mar 2013 08:32:41 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B10DDB0@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B10B6DE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B10B98F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B10DDB0@ESESSMB209.ericsson.se> From: Justin Uberti Date: Fri, 1 Mar 2013 08:32:41 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=20cf302ef790a377fa04d6df8f0a X-Gm-Message-State: ALoCoQmjPxFTjuqR8HzM87Op65UOYMu2bNFAKZW1hNei6s54U/AwgZA3Scl5Kp3m/kcLFMaVT3XHKeffmkGPhOpPLWQalnCV3gEP/d6DXwaSGTst8v9dVzVvHnKwt1tSJVva14tYkXjzvbb8wdmi8tf/6g9jMxxP7A6LHsdoLCjDXfViRBo+oIlg5OLme+gA0kYLBrNUGvk5 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP-03: O/A state machine and trickle ICE with forking X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Mar 2013 16:33:05 -0000 --20cf302ef790a377fa04d6df8f0a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 1, 2013 at 12:51 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Justin, > > No new questions in this e-mail, but comments on the previous ones =E2=98= =BA > > ------------------ > > >>> Q_OA_1: As I have commented earlier, the state machine does not > support setting of remote offer when a > >>> remote pranswer has been set. A JS SIP app may e.g. receive an SDP > answer in a reliable 18x response, > >>> call setPranswer, and then receive an UPDATE on the same leg with a > new offer. > >>> > >>> Section 3.5.2, paragraph 2, attempts to provide a workaround for this > issue. > >>Section 3.5.2 talks about parallel forking, and how it can be solved by > creating a new PC, and then send an UPDATE to provide the new PC > information to the remote entity. > >> > >>But, my issues is when the remote entity sends an UPDATE, with a new > offer. It's not even related to forking. See my example below: > >> > >> > >>BROWSER JS APP > REMOTE ENITTY > >> > >> ------ create offer ---------- > >> -------- SDP Offer > 1-----------------> > >> <------- SDP Answer 1 > ---------------- > >> ------ set pranswer --------- > >> <------- SDP Offer 2 > ------------------- > >> ------ ??? ---------------------- > > > > Right. This is clearly a problem, but the reason it is a problem is > because the two sides don't agree on the state > > of the negotiation. In a forking case, it would be handled via the > mechanism I mentioned above. In a non-forking > > case, this is not solvable even with cloning, because the two sides are > out of sync. The browser has to handle this > > case by rejecting SDP Offer 2. > > I don't understand what you mean by "out of sync". Once the remote entity > has sent an SDP Answer, it can send a new SDP Offer. > > Keep in mind that the remote entity does not know that the JS APP has > mapped SDP Answer 1 to a "pranswer". It could as well have mapped it to > "answer" (in which case the current state machine would allow SDP Offer 2= ). > > > ------------------ > > > > >Q_OA_3: When a pranswer has been set, the state machine does not allow > creating a new local offer. > >> > >> So, if the JS APP needs to send a new offer, e.g. because of BUNDLE, i= t > would have to set answer first. But, that would again more or less preven= t > serial forking (at least on the same PeerConnection). > > > > Can you explain the BUNDLE case you have in mind? > > See example below, where the first offer contains different ports, and th= e > second identical ports, according to BUNDLE. > > BROWSER JS APP > REMOTE ENITTY > > ------ create offer ---------- > -------- SDP Offer 1 > (Different ports) -----------------> > <------- SDP Answer 1 > (Same/Diff ports)---------------- > <---- set pranswer ---------- > ----------------- ???? --------- > -------- SDP Offer 2 (Same > ports) -----------------------> > > > > The BUNDLE renegotiation to a single port can't happen at this point in > the negotiation, because the caller may receive another answer that doesn= 't > want to use BUNDLE. > > Well, then the BROWSER has to "fallback" to different ports (per the > original offer). Isn't that what "pranswer" is all about - having all > resources available in case there is going to be a different answer? > > Now, for BUNDLE, we can discuss when the same-port offer is sent, but > there may be many OTHER reasons why SDP Offer 2 has to be sent, so the > problem is not BUNDLE-specific. > > > ------------------ > > > >>Q_TI_1: > >> > >>Assume the JS APP receives an SDP answer from remote entity A, and > provides it to the browser as a pranswer. Then the JS APP receives an SDP > answer from remote entity B, and provides it to the browser as a pranswer= . > >> > >>Then, the JS APP receives trickle ICE candidates from both entities A > and B. What will happen to the trickle ICE candidates from remote entity = A? > The same question applies if the browser receives peer reflexive candidat= es > from A. > >> > >>The draft says that trickle ICE candidates will be provided to the ICE > Agent, that will then perform connectivity checks etc. But, does that mea= n > that the ICE Agent will perform connectivity checks with both A and B. > >> > >>This could of course be handled by always creating separate > PeerConnections (and hence separate ICE agents) for A and B, even in the > case of serial forking. > >> > >>But, in any case I think the draft also needs to describe the ICE > impacts of forking, because currently I don't think there is any text. > >> > >>Thanks for pointing this out. I discussed this at the IETF 83.5 interim= , > but forgot to put this into the draft. The answer is that when B's pransw= er > is applied, > >>and the received ICE credentials are different than the previous answer > (as they would be in this case), the existing candidates are discarded. > >>But, A doesn't know that, so it may keep sending STUN requests, trickle > ICE candidates etc. > > > > The app should send a termination message to A when it accepts the > pranswer from B. > > Such procedure/restriction would have to be clearly documented in JSEP. > > > Even if it didn'tm the STUN requests would be ignored by the impl, and > the ICE candidates would be ignored by the app, so I don't think there is= a > problem. > > True - assuming the app is never going to "switch back" to remote entity = A. > > >>But, assume that the JS APP discards whatever comes from A. Then, if th= e > session will eventually be established with A (i.e. the SDP > >>answer from A is provided to the browser as "answer"), A needs to be > informed to re-send all trickle ICE candidates etc again, because > >>the previously sent ones were discarded (since the JS APP provided the > SDP answer from B to the browser)... > > > > The app can't keep the session alive simultaneously with both A and B. > It needs to pick one or the other. The last time this was > > discussed, this was felt to be a reasonable solution. Perhaps this need= s > to be codified in the JSEP draft. > > It's not only about not being able to keep the session alive > simultaneously with both A and B - it's also about not being able to go > back to A. Maybe we can live with such restriction, but as I said earlier= : > it needs to be described in the draft. > > > ------------------ > > >> I actually think that PeerConnection cloning would solve *ALL* of the > issues above: there would be no need for pranswer, which means that > >> the JSEP O/A procedures would be fully aligned with RFC 3264. And, ICE > procedures could take place with multiple remote entities simultaneously. > > > > I considered that in the past, but PRANSWER is not just for forking; > it's also useful in the non-forking case to get media flowing as fast as > possible in a single O/A sequence. > > In a non-forking case, how does it make things faster than simply using > ANSWER? > Assuming for now that the ANSWER corresponds to the remote side physically answering the call (i.e. media transmission starts), sending the PRANSWER first allows the ICE and DTLS handshakes to complete while we are waiting for the final ANSWER, preventing media clipping from the callee. > > > The overall opinion of the WG was that PRANSWER solves the problem abov= e > and provides a fairly good treatment of forking without > > introducing significant complexity. Adding cloning would allow a more > comprehensive treatment of forking, but at the cost of significant > > additional complexity. > > I was a big supporter of PRANSWER myself, because of the way we would > support forking with a single PeerConnection. > > But, we DO need to be able to support the use-cases in Q_OA_1 and Q_OA_3. > > > Also, I have yet to have any application builder ask me for cloning > support. > > I don't know what your definition of application builder is, but I did my > first Windows8 "Hello world" app last weekend, so I guess I count as a > builder - and I think we should re-consider cloning :) > > Regards, > > Christer > > --20cf302ef790a377fa04d6df8f0a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Mar 1, 2013 at 12:51 AM, Christer Holmberg <c= hrister.holmberg@ericsson.com> wrote:
Hi Justin,

No new questions in this e-mail, but comments on the previous ones =E2=98= =BA

------------------

>>> Q_OA_1: As I have commented earlier, the state machine does no= t support setting of remote offer when a
>>> remote pranswer has been set. A JS SIP app may e.g. receive an= SDP answer in a reliable 18x response,
>>> call setPranswer, and then receive an UPDATE on the same leg w= ith a new offer.
>>>
>>> Section 3.5.2, paragraph 2, attempts to provide a workaround f= or this issue. =C2=A0
>>Section 3.5.2 talks about parallel forking, and how it can be solve= d by creating a new PC, and then send an UPDATE to provide the new PC infor= mation to the remote entity.
>>
>>But, my issues is when the remote entity sends an UPDATE, with a ne= w offer. It's not even related to forking. See my example below:
>>
>>
>>BROWSER =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 JS APP =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 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0REMOTE ENITTY
>>
>>=C2=A0 =C2=A0 ------ create offer ----------
>>=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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0-------- SDP Offer 1----------------->
>>=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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 <------- SDP Answer 1 ----------------
>>=C2=A0 =C2=A0 ------ set pranswer ---------
>> =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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 <------- SDP Offer 2 -------------------
>>=C2=A0 =C2=A0 ------ ??? ----------------------
>
> Right. This is clearly a problem, but the reas= on it is a problem is because the two sides don't agree on the state > of the negotiation. In a forking case, it would be handled via the mec= hanism I mentioned above. In a non-forking
> case, this is not solvable even with cloning, because the two sides ar= e out of sync. The browser has to handle this
> case by rejecting SDP Offer 2.=C2=A0

I don't understand what you mean by "out of sync". Once= the remote entity has sent an SDP Answer, it can send a new SDP Offer.

Keep in mind that the remote entity does not know that the JS APP has mappe= d SDP Answer 1 to a "pranswer". It could as well have mapped it t= o "answer" (in which case the current state machine would allow S= DP Offer 2).


------------------


> >Q_OA_3: When a pranswer has been set, the state machine does not a= llow creating a new local offer.
>>
>> So, if the JS APP needs to send a new offer, e.g. because of BUNDL= E, it would have to set answer first. But, that would again more or less pr= event serial forking (at least on the same PeerConnection).
>
> Can you explain the BUNDLE case you have in mind?

See example below, where the first offer contains different ports, an= d the second identical ports, according to BUNDLE.

BROWSER =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 JS APP =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 =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 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 REMOTE ENITTY

=C2=A0 =C2=A0 ------ create offer ----------
=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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0-------- SDP Offer 1 (Different ports) -----------------&g= t;
=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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 <------- SDP Answer 1 (Same/Diff ports)----------------
=C2=A0 =C2=A0<---- set pranswer ----------
=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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 -------- SDP Offer 2 (Same ports) ----------------------->
=C2=A0

> The BUNDLE renegotiation to a single port can't happen at this poi= nt in the negotiation, because the caller may receive another answer that d= oesn't want to use BUNDLE.

Well, then the BROWSER has to "fallback" to different ports= (per the original offer). Isn't that what "pranswer" is all = about - having all resources available in case there is going to be a diffe= rent answer?

Now, for BUNDLE, we can discuss when the same-port offer is sent, but there= may be many OTHER reasons why SDP Offer 2 has to be sent, so the problem i= s not BUNDLE-specific.


------------------


>>Q_TI_1:
>>
>>Assume the JS APP receives an SDP answer from remote entity A, and = provides it to the browser as a pranswer. Then the JS APP receives an SDP a= nswer from remote entity B, and provides it to the browser as a pranswer. >>
>>Then, the JS APP receives trickle ICE candidates from both entities= A and B. What will happen to the trickle ICE candidates from remote entity= A? The same question applies if the browser receives peer reflexive candid= ates from A.
>>
>>The draft says that trickle ICE candidates will be provided to the = ICE Agent, that will then perform connectivity checks etc. But, does that m= ean that the ICE Agent will perform connectivity checks with both A and B.<= br> >>
>>This could of course be handled by always creating separate PeerCon= nections (and hence separate ICE agents) for A and B, even in the case of s= erial forking.
>>
>>But, in any case I think the draft also needs to describe the ICE i= mpacts of forking, because currently I don't think there is any text. >>
>>Thanks for pointing this out. I discussed this at the IETF 83.5 int= erim, but forgot to put this into the draft. The answer is that when B'= s pranswer is applied,
>>and the received ICE credentials are different than the previous an= swer (as they would be in this case), the existing candidates are discarded= .
>>But, A doesn't know that, so it may keep sending STUN requests,= trickle ICE candidates etc.
>
> The app should send a termination message to A when it accepts the pra= nswer from B.

Such procedure/restriction would have to be clearly documented in JSE= P.

> Even if it didn'tm the STUN requests would be ignored by the impl,= and the ICE candidates would be ignored by the app, so I don't think t= here is a problem.

True - assuming the app is never going to "switch back" to = remote entity A.

>>But, assume that the JS APP discards whatever comes from A. Then, i= f the session will eventually be established with A (i.e. the SDP
>>answer from A is provided to the browser as "answer"), A = needs to be informed to re-send all trickle ICE candidates etc again, =C2= =A0because
>>the previously sent ones were discarded (since the JS APP provided = the SDP answer from B to the browser)...
>
> The app can't keep the session alive simultaneously with both A an= d B. It needs to pick one or the other. The last time this was
> discussed, this was felt to be a reasonable solution. Perhaps this nee= ds to be codified in the JSEP draft.

It's not only about not being able to keep the session alive simu= ltaneously with both A and B - it's also about not being able to go bac= k to A. Maybe we can live with such restriction, but as I said earlier: it = needs to be described in the draft.


------------------

>> I actually think that PeerConnection cloning would solve *ALL* of = the issues above: there would be no need for pranswer, which means that
>> the JSEP O/A procedures would be fully aligned with RFC 3264. And,= ICE procedures could take place with multiple remote entities simultaneous= ly.
>
> I considered that in the past, but PRANSWER is not just for forking; i= t's also useful in the non-forking case =C2=A0to get media flowing as f= ast as possible in a single O/A sequence.=C2=A0

In a non-forking case, how does it make things faster than simply usi= ng ANSWER?

Assuming for now that = the ANSWER corresponds to the remote side physically answering the call (i.= e. media transmission starts), sending the PRANSWER first allows the ICE an= d DTLS handshakes to complete while we are waiting for the final ANSWER, pr= eventing media clipping from the callee.
=C2=A0

> The overall opinion of the WG was that PRANSWER solves the problem abo= ve and provides a fairly good treatment of forking without
> introducing significant complexity. Adding cloning would allow a more = comprehensive treatment of forking, but at the cost of significant
> additional complexity.

I was a big supporter of PRANSWER myself, because of the way we would= support forking with a single PeerConnection.

But, we DO need to be able to support the use-cases in Q_OA_1 and Q_OA_3.

> Also, I have yet to have any application builder ask me for cloning su= pport.

I don't know what your definition of application builder is, but = I did my first Windows8 "Hello world" app last weekend, so I gues= s I count as a builder - and I think we should re-consider cloning :)

Regards,

Christer


--20cf302ef790a377fa04d6df8f0a-- From martin.thomson@gmail.com Fri Mar 1 08:39: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 B455A21F9126 for ; Fri, 1 Mar 2013 08:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.652 X-Spam-Level: X-Spam-Status: No, score=-6.652 tagged_above=-999 required=5 tests=[AWL=-3.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCEMbuAtevg8 for ; Fri, 1 Mar 2013 08:39:27 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 07E9821F9122 for ; Fri, 1 Mar 2013 08:39:26 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hi8so9315606wib.7 for ; Fri, 01 Mar 2013 08:39:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=XD3yh8Bn0acdw1ZgzNySnfyazW2vYNk32mnGoHcN09I=; b=VZqLaBhwLCWct8PMCU4q0lcjbYmYdixvNzcg/AC3pHS4UbLHnkygOdbR+k86twKDJp WUC6acrgbJhQGT2TTipYmNLFol/c07JdJlzz+qyNgI1ccfc4Jf5HsE18nQA++6T3pBN0 75vp19EbFHYfNSAcwVHNLBeOtwXpxX3XCka5iYyc89AqFC+u1PQNnJO8kQsWXtzNUgwV P+HnT9+jH8K0oZNzxtZYd8e3hMKsSvEbR+h2Qw8AOLhrJVXIYKW7YfPtGz1rEjLNa4gX JNEbmxel1/ko0wovfv444d1InFwllT3p/tytdHewPWEoq+T4PYqYoBuouP9QdUO9zFMb 5GGQ== MIME-Version: 1.0 X-Received: by 10.194.76.37 with SMTP id h5mr18921881wjw.21.1362155966239; Fri, 01 Mar 2013 08:39:26 -0800 (PST) Received: by 10.194.5.135 with HTTP; Fri, 1 Mar 2013 08:39:26 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B10E0F0@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B10B717@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA7EAB@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B10DEBC@ESESSMB209.ericsson.se> <5130875A.40304@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B10E0F0@ESESSMB209.ericsson.se> Date: Fri, 1 Mar 2013 08:39:26 -0800 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Mar 2013 16:39:27 -0000 On 1 March 2013 04:38, Christer Holmberg wrote: >>> My understanding (based on the Boston slides, because I haven't read Cullen's plan draft yet) of "Plan B" is that >>> it didn't include BUNDLE - or any other multi-mediatype multiplexing negotiation mechanism - but only multiple SSRCs per m- line. >> My understanding of Plan B is the same as Justin's. Likewise. Plan B wouldn't have been the mother of all solutions, but it would have been enough. From Michael.Tuexen@lurchi.franken.de Fri Mar 1 09:58: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 0A94E21F93C5 for ; Fri, 1 Mar 2013 09:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkQrfjrfql3N for ; Fri, 1 Mar 2013 09:58:40 -0800 (PST) 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 260D021F8C45 for ; Fri, 1 Mar 2013 09:58:39 -0800 (PST) Received: from [192.168.1.101] (p5481B99F.dip.t-dialin.net [84.129.185.159]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 5BBAC1C0C0BEA; Fri, 1 Mar 2013 18:58:37 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <201303011558.r21FwfGb2830347@shell01.TheWorld.com> Date: Fri, 1 Mar 2013 18:58:35 +0100 Content-Transfer-Encoding: 7bit Message-Id: <5EB4AF68-2BB3-4243-B759-249065D8815F@lurchi.franken.de> References: <7594FB04B1934943A5C02806D1A2204B10B717@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA7EAB@US70UWXCHMBA04.zam.alcatel-lucent.com> <201303011558.r21FwfGb2830347@shell01.TheWorld.com> To: worley@ariadne.com (Dale R. Worley) X-Mailer: Apple Mail (2.1283) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Mar 2013 17:58:41 -0000 On Mar 1, 2013, at 4:58 PM, Dale R. Worley wrote: >> From: "Ejzak, Richard P (Richard)" >> >> Since multiplexing of the data channel with RTP media has been shown >> as a desirable feature of BUNDLE (and most of its variants), I would >> suggest that this be treated as a significant advantage for BUNDLE >> (and similarly capable variants) over any proposal without it. >> Cullen's "Plan A" is preferred over Plan B precisely because it has >> an incremental muxing advantage. > > As far as I can tell from my analysis > (http://tools.ietf.org/html/draft-worley-sdp-bundle-04#section-8), > SCTP-over-DTLS can be demuxed from RTP and STUN quite easily. (This > comes from RFC 5764 section 5.1.2.) And SCTP can be demuxed from the As far as I understand it is easy (based on the first byte) to demux DTLS from STUN and SRTP. SCTP is the only payload for DTLS, so there is no need for demuxing. So no need to control SCTP ports. Or am I missing something? > rest as long as you control the range of SCTP ports used. (And since > the ports aren't actually to route the packets to the receiver (the > underlying UDP does that), you have freedom in choosing SCTP ports.) > > So I don't see anything blocking Plan A as compared to Plan B. Of > course, we have to *do* a bundle technique, but we've got a large > library of possibilities now and can look at the fundamental design > questions in context. > > Dale > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From dwing@cisco.com Fri Mar 1 10: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 24BFA1F0D0C for ; Fri, 1 Mar 2013 10:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.237 X-Spam-Level: X-Spam-Status: No, score=-110.237 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3fuhpR-GD2h for ; Fri, 1 Mar 2013 10:57:33 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 46CF51F0C74 for ; Fri, 1 Mar 2013 10:57:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1811; q=dns/txt; s=iport; t=1362164253; x=1363373853; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=3oRL7IPD45SORQJZX5kZAXgbms/SszewUNRDxXNOSXg=; b=ccbwev07+MLht1R4IikQNT+VELChpNKf847DX0/7c0cTq5Qy8dcO5CFy PClFiNX21NIpZBGmFTbJf9yZvJ59CZ9meKyHNk/spj66PROBjr3MWHgbP b9FFvGoEoLNfXHUDJ2Uky+55hsTL1oia5vLqFEAcdPXpA2hKTy5Vi7Lsi c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHX4MFGrRDoJ/2dsb2JhbABEwjt/FnOCHwEBAQQIAjA/DAEDAgkRBAEBKAcZLQkIAgQTCwWIAg3BHY8SCwcGgzoDiGuFLogqgR6PTYMp X-IronPort-AV: E=Sophos;i="4.84,762,1355097600"; d="scan'208";a="73830350" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 01 Mar 2013 18:57:33 +0000 Received: from DWINGWS01 ([10.32.240.197]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r21IvWc9013761; Fri, 1 Mar 2013 18:57:32 GMT From: "Dan Wing" To: "'Dale R. Worley'" , "'Ejzak, Richard P \(Richard\)'" References: <7594FB04B1934943A5C02806D1A2204B10B717@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA7EAB@US70UWXCHMBA04.zam.alcatel-lucent.com> <201303011558.r21FwfGb2830347@shell01.TheWorld.com> In-Reply-To: <201303011558.r21FwfGb2830347@shell01.TheWorld.com> Date: Fri, 1 Mar 2013 10:57:32 -0800 Message-ID: <112a01ce16ae$a1720d90$e45628b0$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQImnlC61bFZQAa/2xpYNbQQY7seZQGhch3qATZkPdIB+mfzDJe5jbUw Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Mar 2013 18:57:34 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Dale R. Worley > Sent: Friday, March 01, 2013 7:59 AM > To: Ejzak, Richard P (Richard) > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB > > > From: "Ejzak, Richard P (Richard)" > > > > Since multiplexing of the data channel with RTP media has been shown > > as a desirable feature of BUNDLE (and most of its variants), I would > > suggest that this be treated as a significant advantage for BUNDLE > > (and similarly capable variants) over any proposal without it. > > Cullen's "Plan A" is preferred over Plan B precisely because it has an > > incremental muxing advantage. > > As far as I can tell from my analysis > (http://tools.ietf.org/html/draft-worley-sdp-bundle-04#section-8), > SCTP-over-DTLS can be demuxed from RTP and STUN quite easily. (This > comes from RFC 5764 section 5.1.2.) And SCTP can be demuxed from the > rest as long as you control the range of SCTP ports used. (And since > the ports aren't actually to route the packets to the receiver (the > underlying UDP does that), you have freedom in choosing SCTP ports.) > > So I don't see anything blocking Plan A as compared to Plan B. Of > course, we have to *do* a bundle technique, but we've got a large > library of possibilities now and can look at the fundamental design > questions in context. The analysis should also examine impact of port-based QoS on multiplexing data over the same port as audio. Even audio and video often prefer different drop precedence. I know the general consensus is to just supply more bandwidth, yet we consume all available bandwidth much like disk space, memory, and CPU/GPU cycles. -d From worley@shell01.TheWorld.com Fri Mar 1 11:58: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 063B621F8B77 for ; Fri, 1 Mar 2013 11:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.764 X-Spam-Level: X-Spam-Status: No, score=-2.764 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvyhLTd1MTIn for ; Fri, 1 Mar 2013 11:58:02 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 60CD721F8B75 for ; Fri, 1 Mar 2013 11:58:02 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r21JvL8x029606; Fri, 1 Mar 2013 14:57:24 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r21JvLFM2850768; Fri, 1 Mar 2013 14:57:21 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r21JvLZG2849736; Fri, 1 Mar 2013 14:57:21 -0500 (EST) Date: Fri, 1 Mar 2013 14:57:21 -0500 (EST) Message-Id: <201303011957.r21JvLZG2849736@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Michael Tuexen In-reply-to: <5EB4AF68-2BB3-4243-B759-249065D8815F@lurchi.franken.de> (Michael.Tuexen@lurchi.franken.de) References: <7594FB04B1934943A5C02806D1A2204B10B717@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA7EAB@US70UWXCHMBA04.zam.alcatel-lucent.com> <201303011558.r21FwfGb2830347@shell01.TheWorld.com> <5EB4AF68-2BB3-4243-B759-249065D8815F@lurchi.franken.de> Cc: rtcweb@ietf.org Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Mar 2013 19:58:03 -0000 > From: Michael Tuexen > As far as I understand it is easy (based on the first byte) to demux > DTLS from STUN and SRTP. SCTP is the only payload for DTLS, so there > is no need for demuxing. So no need to control SCTP ports. Or am I > missing something? Controlling port numbers is needed if SCTP is *not* encapsulated in DTLS and yet has to be distinguished from RTP et al. (That would become significant if encryption was applied to the bundle's packet stream as a whole, rather than to the constituent streams individually.) Dale From prvs=67729d4d83=gmartincocher@blackberry.com Fri Mar 1 14:22: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 3BE8B21F8AC0 for ; Fri, 1 Mar 2013 14:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iryKQWbjGpQI for ; Fri, 1 Mar 2013 14:21:59 -0800 (PST) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6E35321F8ABA for ; Fri, 1 Mar 2013 14:21:54 -0800 (PST) X-AuditID: 0a412830-b7f2b6d000000c6f-de-513129f7be8e Received: from XCT102CNC.rim.net (xct102cnc.rim.net [10.65.161.202]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 41.04.03183.7F921315; Fri, 1 Mar 2013 16:21:43 -0600 (CST) Received: from XMB106BCNC.rim.net ([fe80::99b8:8d0e:cdcd:c00d]) by XCT102CNC.rim.net ([fe80::2066:5d4f:8c45:af55%17]) with mapi id 14.02.0328.009; Fri, 1 Mar 2013 17:21:42 -0500 From: Gaelle Martin-Cocher To: Magnus Westerlund Thread-Topic: [rtcweb] Input to Video Codec Selection Thread-Index: AQHOFohR1tLbLyQU8Uy60/t42U/AApiRYfVg Date: Fri, 1 Mar 2013 22:21:42 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AA26529174@XMB106BCNC.rim.net> References: <5130B9C3.3010404@ericsson.com> In-Reply-To: <5130B9C3.3010404@ericsson.com> Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHKsWRmVeSWpSXmKPExsXC5bjwlO53TcNAgw2HdC0urb/HZLH2Xzu7 A5PHr69X2TyWLPnJFMAU1cBok5RYUhacmZ6nb2eTmJeXX5JYkqqQklqcbKvkk5qemKMQUJRZ lphcqeCSWZyck5iZm1qkpJCZYqtkoqRQkJOYnJqbmldiq5RYUJCal6Jkx6WAAWyAyjLzFFLz kvNTMvPSbZU8g/11LSxMLXUNlex0Ezp5Mnp2X2ArmKZa8e/xT7YGxl+yXYycHBICJhLnf/9m gbDFJC7cW88GYgsJtDNJfF+XBmFvZZSYszsZxGYTsJT4/2oPWL2IgJnEwwn7weqZBdQl7iw+ xw5iCwPNnNB5jgmixlTi7KlHbBC2kcTbA3+Bejk4WARUJJ4uSQEJ8wp4Snw9tJUJYpW2xPGf 7WBjOAV0JI5NOgpWzghUfvJpOMQmcYlbT+YzQVwsILFkz3lmCFtU4uXjf6wQtqLE3mdHmSDq 9SRuTJ0CdaW2xLKFr5kh1gpKnJz5hGUCo9gsJGNnIWmZhaRlFpKWBYwsqxgFczOKDcwMk/OS 9Yoyc/XyUks2MYIThIbBDsb37y0OMQpwMCrx8H5TMAwUYk0sK67MPcQowcGsJMLLfNEgUIg3 JbGyKrUoP76oNCe1+BCjKzBMJjJLcSfnA5NXXkm8sYEBbo6SOK9IoGigkEA6MB1lp6YWpBbB zGHi4ATZwyUlUgxMKqlFiaUlGfGg1BdfDEx+Ug2MllKOE54cDc1+WKNTMuNHoIvRusnsD1bP 65827dEW8bI3V5oe/OSfcfKD2EFGmwk+PUdT1x17uYL7z4Tcg1t/HmGY6Wm1TOGlHK/C9htb /Rx/KFy5Y2jwzc4/j/1mZIrVYcnF5uaz3II2Hft30/rLgvmXm5m0o///3vb7Y6zFjeruKZxL KsuDXyixFGckGmoxFxUnAgAy0WEDUQMAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Input to Video Codec Selection X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Mar 2013 22:23:30 -0000 Dear All, Further to Magnus email, while I assume there might not be "something new" t= o learn at the meeting, I believe the below requested clarifications on exis= ting information would be useful. Implementers should clearly know which li= cense they can pick or get when it comes to VP8 and by which groups. I beli= eve answers in advance of the meeting would help the discussion at the meeti= ng. Questions 1 & 2: It is assumed that in the case of choosing VP8, RTCWeb would reference the= informational RFC 6386. Q1: Is there an intent to move that RFC to the standard track at a point in= time? Q2: Would that change the rule of "who" is obliged to make an IPR declaratio= n? Question 3: The IPR disclosure was made on the draft 2 of draft-bankoski-vp8-bitstream-0= 2" as per https://datatracker.ietf.org/ipr/search/?option=3Drfc_search&rfc_s= earch=3D6386 Draft 3 and onward contains the copyright license and the additional IP righ= ts grant. Q3: Is the initial IPR disclosure still valid? Question 4: The informational RFC 6386 contains the decoder code and some piece of encod= er code. Though the IP rights grant mentioned in the RFC is offered against: "This implementation" means the copyrightable works distributed by Google as part of the WebM Project." Q4: As such the IP rights grant does not seem to apply to the RFC itself or= to an implementation of the code contained in the RFC. Should that be corr= ected or is that the intent? Question 5: The additional IP grant is applied to a particular implementation (namely th= e WebM VP8 code) without modifications. Any derivative work either: - produced from the reference code in WebM (that is a possible optimized ver= sion of it); or - produced from the RFC text or the code provided within the RFC (while not= using the WebM code) does not have the benefit of the additional IP grant. In other words a conformant implementation does not necessarily have the ben= efit of the additional IP grant. I am not confident that the VP8 code can be used "as is" for certain platfor= ms. I would think that the code might need some modification to provide the= desired performance. In other words, it should be clear that those implemen= ters would not necessarily receive the benefit of that grant. If the answer to Q3 is negative, then there is no IP license statement at al= l that applies to a "conformant implementation of the RFC" (aka a derivative= work). If the answer to Q3 is positive, it is not clear how to reconcile the decla= ration inside the RFC and the declaration that is attached to the the RFC dr= aft for implementers that would not modify the code. Q5: Can this be clarified or confirmed? Question 6: The IPR disclosure in IETF is different than the IPR statement made in MPEG= (see document sent by Harald earlier). Q6: the differences in license statement and IP grant referring to WebM code= are rather confusing. Can it be clarified which license, copyright, grant a= re provided for RFC 6386? In conclusion, before advancing this draft, or considering it as a candidate= for RTCWeb, consistency and clarity should be ensured between the IPR gran= t associated with the IETF draft, the IPR grants within the IETF draft docum= ent itself, the IPR grant given for MPEG, and any IPR grant given in connect= ion with the WEBM project for this same work. Otherwise, the IPR status of= the work that is undertaken is indeterminate, and likely will not produce a= result that will be useful. Thank you! Sincerely, Ga=EBlle -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Magnus Westerlund Sent: Friday, March 01, 2013 9:23 AM Cc: rtcweb@ietf.org Subject: [rtcweb] Input to Video Codec Selection WG, I hope everyone, especially Google, now have provided whatever input they ha= ve into the Video Codec discussion and selection. It is important that every= one has the possibility to evaluate the input in good time prior to the meet= ing. It is especially important if one might require legal or other support= when evaluating the proposals or additional information, which might apply= for IPR, as an example. To be extremely blunt, we don't want anyone revealing new input material dur= ing the presentations in Orlando. These presentations is only intended to pr= ovide a summary of the most important aspects from the proponents side. The RTCWEB WG chairs Magnus Westerlund Ted Hardie Cullen Jennings _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From Michael.Tuexen@lurchi.franken.de Fri Mar 1 15:09: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 D6CAA11E80BF for ; Fri, 1 Mar 2013 15:09:12 -0800 (PST) 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] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0WeXRfJgI1U for ; Fri, 1 Mar 2013 15:09:12 -0800 (PST) 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 30B5611E80BA for ; Fri, 1 Mar 2013 15:09:10 -0800 (PST) Received: from [192.168.1.101] (p548197B9.dip.t-dialin.net [84.129.151.185]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 389581C0C0BC5; Sat, 2 Mar 2013 00:09:08 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <201303011957.r21JvLZG2849736@shell01.TheWorld.com> Date: Sat, 2 Mar 2013 00:09:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B10B717@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA7EAB@US70UWXCHMBA04.zam.alcatel-lucent.com> <201303011558.r21FwfGb2830347@shell01.TheWorld.com> <5EB4AF68-2BB3-4243-B759-249065D8815F@lurchi.franken.de> <201303011957.r21JvLZG2849736@shell01.TheWorld.com> To: worley@ariadne.com (Dale R. Worley) X-Mailer: Apple Mail (2.1283) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Mar 2013 23:09:13 -0000 On Mar 1, 2013, at 8:57 PM, Dale R. Worley wrote: >> From: Michael Tuexen >=20 >> As far as I understand it is easy (based on the first byte) to demux >> DTLS from STUN and SRTP. SCTP is the only payload for DTLS, so there >> is no need for demuxing. So no need to control SCTP ports. Or am I >> missing something? >=20 > Controlling port numbers is needed if SCTP is *not* encapsulated in > DTLS and yet has to be distinguished from RTP et al. (That would > become significant if encryption was applied to the bundle's packet > stream as a whole, rather than to the constituent streams > individually.) Sorry, I don't understand what you are saying. Which document describes the stack you are referring to? How would encryption be done for SCTP = over UDP over IP? Best regards Michael >=20 > Dale >=20 From ted.ietf@gmail.com Fri Mar 1 16:23: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 2BF3E21E80F4; Fri, 1 Mar 2013 16:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=-0.880, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylhFF8YOi2IF; Fri, 1 Mar 2013 16:23:11 -0800 (PST) Received: from mail-ia0-x22a.google.com (mail-ia0-x22a.google.com [IPv6:2607:f8b0:4001:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id CD39121E80CA; Fri, 1 Mar 2013 16:23:10 -0800 (PST) Received: by mail-ia0-f170.google.com with SMTP id k20so3182297iak.1 for ; Fri, 01 Mar 2013 16:23:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=f5vy852zqwP6/1fPqMbzces/WjdZ6gBs40zIZt84N5w=; b=MMbqfQa0bI3E48oa9thmXYkIAThmxfdWdW3FOxno5NpQK9aScc9zKXVvhxIyMQOwOQ 2NGLBzT8IO6qSM2PRfEiOM9Fs+77Fe6YqyR5RrWaNdxtsZBS0n3nGfidGcc01OWS/CRC XGAjAAL4n9Ma3WT4XvaI/mWg3oEh3u1W+lDDl/An1rmMwOT9hDPeK/tYKT/ZR0juzJa8 I0d7HTeS0rSqfAfZtTKc0OY2Gl2sexta3sIMQXgFHLzprpIKod0rsv/dDN6Q7p0eCu3G OfGsyv8XwMMZODI5fIGuuEYaiuy0ysjkMEfHNnR5Byv+Ok9ZJzcM4bWzvG5vXGMTNKJT twsg== MIME-Version: 1.0 X-Received: by 10.43.91.5 with SMTP id bk5mr8893940icc.20.1362183790391; Fri, 01 Mar 2013 16:23:10 -0800 (PST) Received: by 10.43.135.202 with HTTP; Fri, 1 Mar 2013 16:23:10 -0800 (PST) Date: Fri, 1 Mar 2013 16:23:10 -0800 Message-ID: From: Ted Hardie To: rtcweb@ietf.org, mmusic@ietf.org Content-Type: multipart/mixed; boundary=bcaec518692cf1fbab04d6e62095 Subject: [rtcweb] Extremely drafty minutes X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Mar 2013 00:23:13 -0000 --bcaec518692cf1fbab04d6e62095 Content-Type: text/plain; charset=ISO-8859-1 Howdy, I've been working on minutes for the interim meeting last month; I've attached the current draft. It needs *extensive* review, as I had planned to work off recordings for two days, and they turned out to be available for only half of one. Several folks have volunteered their notes, but I have not made nearly enough progress. I've decided that it's better to have something out than nothing, so here they are, in the current state. Please review them and provide input; I will continue to work on them, but if we don't get more input, they will be *terrible*. My apologies for the plan going awry on this, and for the delay. I kept hoping that more time spent with them would make them coherent; in large part, I suspect that helped very little all. Please excuse that and help us correct it, thanks, Ted Hardie --bcaec518692cf1fbab04d6e62095 Content-Type: text/plain; charset=UTF-8; name="RTCWEBMMUSICJointInterimminutes.txt" Content-Disposition: attachment; filename="RTCWEBMMUSICJointInterimminutes.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hds104840 77u/RmVicnVhcnkgNS03dGgsIDIwMTMNClJUQ1dFQi9NTVVTSUMgSm9pbnQgSW50ZXJpbSBNaW51 dGVzDQpNTVVTSUMgQ2hhaXJzOiBGbGVtbWluZyBBbmRyZWFzZW4sIEFyaSBLZXLDpG5lbg0KUlRD V0VCIENoYWlyczogVGVkIEhhcmRpZSwgQ3VsbGVuIEplbm5pbmdzLCBNYWdudXMgV2VzdGVybHVu ZCAobm90IHByZXNlbnQpDQpQcm9jZWVlZGluZ3M6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2Vl ZGluZ3MvaW50ZXJpbS8yMDEzLzAyLzA1L3J0Y3dlYi9wcm9jZWVkaW5ncy5odG1sDQpSZWNvcmRp bmdzOiBodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL2xzci5waHA/QVQ9cGImU1A9 TUMmcklEPTY1ODU1MzUyJnJLZXk9MTA5OTc4NTRkNGI4NGFmNSxodHRwczovL2Npc2NvLndlYmV4 LmNvbS9jaXNjb3NhbGVzL2xzci5waHA/QVQ9cGImU1A9TUMmcklEPTY1ODg3Njg3JnJLZXk9OGMy MTdjYzEzYzllMGVhNw0KTm90ZSB0YWtlcnM6ICBNYXJ5IEJhcm5lcywgU3BlbmNlciBEYXdraW5z LCBBcmkgS2Vyw6RuZW4sIEFkYW0gUm9hY2gsIFRpbSBUZXJyaWJlcnJ5IA0KDQoNCg0KDQoNCg0K RmVicnVhcnkgNXRoDQoNCg0KVG9waWM6IEdlbmVyYWwgSW50cm9kdWN0aW9uIHRvIFNEUCBpc3N1 ZXMgcmFpc2VkIGJ5IFJUQ1dFQiB3b3JrDQpQcmVzZW50YXRpb246IGh0dHA6Ly93d3cuaWV0Zi5v cmcvcHJvY2VlZGluZ3MvaW50ZXJpbS8yMDEzLzAyLzA1L3J0Y3dlYi9zbGlkZXMvc2xpZGVzLWlu dGVyaW0tMjAxMy1ydGN3ZWItMS0yLnBwdHgNCg0KDQpQYXJ0aWNpcGFudHMgZGlzY3Vzc2VkIGJv dGggdGhlIElFVEYgYW5kIFdlYlJUQyB1c2Ugb2YgdGVybXMgbGlrZSDigJxtZWRpYSBzdHJlYW3i gJ0gYW5kIHRyYWNrLCBhdHRlbXB0aW5nIHRvIHdvcmsgdGhyb3VnaCB0byBhIGNvbW1vbiB2b2Nh YnVsYXJ5IGZyb20gYSBzZXQgdGhhdCBpcyBjdXJyZW50bHkgc29tZXdoYXQgY29uZnVzaW5nLiAg VGhlcmUgd2VyZSBzdWdnZXN0aW9ucyB0aGF0IHRoZSBXZWJSVEMgZ3JvdXAgY29uc2lkZXIgY2hh bmdpbmcgTWVkaWFTdHJlYW0gdG8gTWVkaWFTdHJlYW1UcmFja1NldCwgaW4gb3JkZXIgdG8gaGVs cCBkZXZlbG9wZXJzIHVuZGVyc3RhbmQgdGhhdCB3aGF0IGlzIG5vdyBhIE1lZGlhU3RyZWFtIG1h eSBjb250YWluIG1lZGlhIGluIG11bHRpcGxlIHRyYWNrcywgYnV0IHRoZXNlIGRpZCBub3QgaGF2 ZSBjb25zaXN0ZW50IHN1cHBvcnQuICBJdCB3YXMgYWdyZWVkIHRoYXQgZXh0cmVtZSBjYXJlIGlu IHRoZSB1c2Ugb2YgdGhlIHRlcm1zIHdhcyByZXF1aXJlZC4gIFRoZSByZWxhdGlvbnNoaXAgYW1v bmcgdGhlbSBuZWVkcyB0byBiZSBleHBsaWNpdCBpbiBwYXJ0IGJlY2F1c2UgdGhlIFdlYlJUQyBn cm91cCBuZWVkcyB0byB1bmRlcnN0YW5kIGhvdyB0byBwbHVtYiB0aGUgdHJhY2tzICh3aXRoaW4g TWVkaWFTdHJlYW1zLCB3aGV0aGVyIG9uIFBlZXJDb25uZWN0aW9ucyBvciBsb2NhbCkgdG8gU0RQ LWxldmVsIGNvbnN0cnVjdHMgbGlrZSBTU1JDcy4gIA0KDQpQYXJ0aWNpcGFudHMgdGhlbiBkaXNj dXNzZWQgdGhlIHVwZGF0ZWQgZnVuY3Rpb25hbGl0eSByZXF1aXJlZCBieSBSVENXRUIgYW5kIENM VUUsIGdvaW5nIG9mZiB0aGUgZGlzY3Vzc2lvbiBvbiBwYWdlcyAxNy0zMiBvZiB0aGUgc2FtZSBw cmVzZW50YXRpb24uICBUaGlzIGRpc2N1c3Npb24gd2FzIHdpZGUtcmFuZ2luZywgYW5kIHVuZm9y dHVuYXRlbHksIG5vdCBwZXJmZWN0bHkgY2FwdHVyZWQuICBUaGUgdGhyZWUgbWFpbiB0b3BpY3Mg d2VyZTogIFNpZ25hbGluZyBmb3Igc2Vzc2lvbnMgdGhhdCBoYXZlIG11bHRpcGxlIHNvdXJjZXMg b2YgdGhlIHNhbWUgdHlwZSBzZW50IGZyb20gYSBzaW5nbGUgZW5kcG9pbnQgYW5kIHJlY2VpdmVk IGJlIGEgcGVlciBlbmRwb2ludDsgdHJhbnNwb3J0IGFnZ3JlZ2F0aW9uOyBtdWx0aXBsZSBlbmNv ZGluZ3MgZm9yIGEgc2luZ2xlIG1lZGlhIHNvdXJjZSAoaGVyZSBtZWFuaW5nIGNhbWVyYSwgbWlj cm9waG9uZSwgb3Igc2ltaWxhcikuICBGb3Igc2lnbmFsaW5nLCBhbW9uZyB0aGUgcG9pbnRzIHJh aXNlZDogIENMVUUgYW5kIFJUQ1dFQiBsaWtlbHkgaGF2ZSB0d28gZGlmZmVyZW50IHVzYWdlIHBh dHRlcm5zLiAgRm9yIENMVUUsIG11bHRpcGxlIG1lZGlhIHNvdXJjZXMgd2lsbCBiZSBjb21tb24s IG11bHRpcGxlIGVuY29kaW5ncyBwZXIgbWVkaWEgc291cmNlIHdpbGwgYmUgdGhlIG5vcm0sICBt dWx0aXBsZSBlbmRwb2ludHMgbWF5IGJlIHZpc2libGUgZXZlbiBpbiB1bmljYXN0IHRyYW5zcG9y dCwgYW5kIHRoZXJlIG1heSBiZSBvbmUgb3IgbW9yZSBSVFAgc2Vzc2lvbi4gIEZvciBSVENXRUIs IHRoZSBjdXJyZW50IHRoZW9yeSBpcyB0aGF0IHRoZXJlIGlzIGEgc2luZ2xlIFJUUCBzZXNzaW9u IHBlciBtZWRpYSB0eXBlLCBpZiBub3QgYSBzaW5nbGUgUlRQIHNlc3Npb24gZnVsbCBzdG9wLiAg QWxsIFNTUkNzIHJlbGF0ZWQgdG8gYSBzaW5nbGUgcGVlciBjb25uZWN0aW9uICh3aGljaCBjb3Vs ZCBlbmNvbXBhc3NlcyBtb3JlIHRoYW4gb25lIE1lZGlhU3RyZWFtcyBoYXZpbmcgbW9yZSB0aGFu IG9uZSB0cmFjaykgd291bGQgY29tZSBmcm9tIGEgc2luZ2xlIFNTUkMgc3BhY2UuICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANClRoZSBncm91cCBhbHNvIGRpc2N1c3NlZCBob3cg dG8gaGFuZGxlIGltcGxpY2l0IFNTUkNzOyB0aGlzIGdhdmUgcmlzZSB0byBhIGxhcmdlciBtZXRh LWRpc2N1c3Npb24gb24gd2hldGhlciB0aGUgYWltIG9mIHRoZSBNTVVTSUMgd29yayB3YXMgdG8g Y3JlYXRlIHNvbWV0aGluZyB0aGF0IG1ldCBqdXN0IFJUQ1dFQuKAmXMgbmVlZHMgb3IgaGFkIGEg bGFyZ2VyIHNjb3BlLiAgQW1vbmcgdGhlIGNvbW1lbnRzOiAgSm9uYXRoYW4gTGVubm94IHBvaW50 ZWQgb3V0IHRoYXQgaXQgd2FzIE1NVVNJQ+KAmXMgam9iIHRvIHByb3ZpZGUgdG9vbHMsIHdpdGgg UlRDV0VCIGJlaW5nIGFtb25nIHRob3NlIHJlcXVlc3RpbmcgdG9vbHMuICBGbGVtbWluZyBzYWlk IHRoYXQgaXQgbWlnaHQgYmUgdXNlZnVsIHRvIGNvbnN0cmFpbiB0aGUgcHJvYmxlbSBzZXQgaW4g b3JkZXIgdG8gbWFrZSBwcm9ncmVzcy4gIEhhZHJpZWwgc2FpZCB0aGF0IGluIHBhc3QgbWVldGlu Z3Mgd2XigJl2ZSBsb29rZWQgZm9yIGEgY29tbW9uIHNvbHV0aW9uLg0KDQpEZWNpc2lvbnM6IA0K DQoqIERlY2lzaW9uIC0gd2Ugd29uJ3QgdXNlIHRoZSB3b3JkcyAibWVkaWEgc3RyZWFtIiB3aXRo b3V0IGFuIGlkZW50aWZpZXIgZm9yIGNvbnRleHQNCg0KKiBBY3Rpb24gaXRlbSB0byBkZXZlbG9w IG5ldyB0ZXJtcz8gSm9uYXRoYW4gd2lsbCBwcm92aWRlIHRoZSBsaXN0IG9mIGxhZ2dhcmRzIHdo byB2b2x1bnRlZXJlZCB0byBoZWxwIGhpbSBkbyB0aGF0LCBhbmQgdGhlIGNoYWlycyB3aWxsIG5h ZyB0aGVtDQoNCiogYWN0aW9uIC0gVGVkIHdpbGwgY2FwdHVyZSBKb25hdGhhbidzIGNvbW1lbnRz IGF0IHRoZSBtaWtlIGZvciBpbmNsdXNpb24gaW4gUlRDV2ViIGRvY3VtZW50cy4gRGFsZSBXb3Js ZXkgYXNrZWQgdGhhdCAiUlRQIHNlc3Npb24iIGJlIGluY2x1ZGVkIGluIHRoZSBydW5lIHJlYWRp bmcNCg0KKiBBY3Rpb24gLSBmb3IgUmljaGFyZCBFanphayB0byB0aGluayBhYm91dCBkb2luZyBh IHVzZSBjYXNlLWJ5LXVzZSBjYXNlIGFuYWx5c2lzIG9mIHRoZSB2YXJpb3VzIGFwcHJvYWNoZXMN Cg0KU2NvcGUgb2Ygd29yayBvcHRpb25zOg0KDQpPcHRpb24gMSAtIGRyaXZlbiBieSBicm9hZGVy IFJUQ1dlYiB1c2UgY2FzZXMNCg0KMTQgaGFuZHMNCg0KT3B0aW9uIDIgLSBhZGQgQ0xVRSB1c2Ug Y2FzZXMNCg0KOSBoYW5kcw0KDQpPcHRpb24gMyAtIGFkZCBhbnkgb2ZmZXIvYW5zd2VyIHVzZSBj YXNlcw0KDQo0IGhhbmRzDQoNCg0KRmVicnVhcnkgNnRoDQpCVU5ETEUsIE9ORS1SVFAsIE1NVDpo dHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzL2ludGVyaW0vMjAxMy8wMi8wNS9ydGN3ZWIv c2xpZGVzL3NsaWRlcy1pbnRlcmltLTIwMTMtcnRjd2ViLTEtMC5wcHQNCg0KKiBOb3RlIC0gSWYg d2UgcHJvY2VlZCB3aXRoIE1NVCwgd2Ugc2hvdWxkIHVzZSBtPWFwcGxpY2F0aW9uIGluc3RlYWQg b2YgbT1hbnltZWRpYQ0KDQoNCiogUXVlc3Rpb24gLSBBcmUgZm9sa3MgZ2VuZXJhbGx5IG9rYXkg d2l0aCBhbnkgb2YgdGhlIGFwcHJvYWNoZXMgdGhhdCByZWR1Y2UgdGhlIG51bWJlciBvZiBsb25n LWxpdmVkIGZsb3dzIHRvIHRoaXMgbGV2ZWwgT1IgaXMgdGhlcmUgc29tZSBvdGhlciBmZWF0dXJl IGluIG9uZSBvZiB0aGUgcHJvcG9zYWxzIHlvdSBtdXN0IGhhdmUgYmVmb3JlIHRoaXMgbWVldHMg eW91ciBuZWVkcz8NCg0KDQo2IGZvciB0aGUgZm9ybWVyLCAxNyBmb3IgdGhlIGxhdHRlcg0KDQoN Cg0KDQpDdWxsZW4ncyBwbGFuIHRvIGRpZyB1cyBvdXQgb2YgdGhpcyBob2xlOmh0dHA6Ly93d3cu aWV0Zi5vcmcvcHJvY2VlZGluZ3MvaW50ZXJpbS8yMDEzLzAyLzA1L3J0Y3dlYi9zbGlkZXMvc2xp ZGVzLWludGVyaW0tMjAxMy1ydGN3ZWItMS0xMC5wZGYNCg0KDQoqIFByb3Bvc2VkIFN1cGVyc2V0 IG9mIFJlcXVpcmVtZW50IDIgLSBTaG91bGQgYmUgYWJsZSB0byBpbnRlcm9wIHdpdGggbGVnYWN5 IHdpdGhvdXQgdGhlIEpTIGRvaW5nIGFueXRoaW5nIHNwZWNpYWwuDQoNCg0KKiBQcm9wb3NlZCBS ZWxheGF0aW9uIG9mIFJlcXVpcmVtZW50IDIgLSBTaG91bGQgYmUgYWJsZSB0byBpbnRlcm9wIHdp dGggbGVnYWN5LCBidXQgbm90IG5lY2Vzc2FyaWx5IGluIG9uZSBPL0EgZXhjaGFuZ2Ugd2l0aGlu IGEgc2luZ2xlIGRpYWxvZyAod2l0aG91dCByZWx5aW5nIG9uIGZhaWx1cmUgY2FzZXMpLg0KDQoN CiogUmVxdWlyZW1lbnQgMyAtIENoYW5nZSB2aWRlbyBmbG93cyB0byBtZWRpYSBmbG93cw0KDQoN CiogUHJvcG9zZWQgUmVxdWlyZW1lbnQgLSBXaGVuIHdlIGhhdmUgYSBsYXJnZSBjb25mZXJlbmNl IHdpdGggMTAwMCdzIG9mIHBlb3BsZSwgd2UgZG9uJ3QgaGF2ZSB0byBzZW5kIG5ldyBzaWduYWxp bmcgdG8gZXZlcnkgcGFydGljaXBhbnQgb2YgdGhlIGNvbmZlcmVuY2UuDQoNCg0KKiBQcm9wb3Nl ZCBSZXF1aXJlbWVudCAtIE11c3QgYmUgYWJsZSB0byBjb25maWd1cmUgYSBzZXQgb2Ygc2ltaWxh ciBmbG93cyBzdWNoIHRoYXQgb25jZSBlc3RhYmxpc2hlZCwgdGhlIGVuZHBvaW50cyBjYW4gYWRk IG9yIHJlbW92ZSBmbG93cyB3aXRob3V0IGhhdmluZyB0byBkbyBhbiBPL0EgY3ljbGUgKGkuZS4s IHdpdGhvdXQgaGF2aW5nIHRvIGV4Y2hhbmdlIFNEUCkuDQoNCg0KKiBQcm9wb3NlZCBSZXF1aXJl bWVudCAtIEhhdmUgdGhpcyBwcm9jZXNzIHRlcm1pbmF0ZSBpbiBzb21lIGZpbml0ZSBwZXJpb2Qg b2YgdGltZS4NCg0KDQoqIFBvaW50IG9mIERpc2N1c3Npb24gLSBQbGFuIEE6IHNhbWUgcG9ydCBv biBlYWNoIG0tbGluZSBvciBkaWZmZXJlbnQgY2FuZGlkYXRlIHNldHM/DQoNCg0KKiBBY3Rpb24g LSBQbGFuIEI6IFdyaXRlIHRoZSBkcmFmdHMgdG8gZXh0ZW5kIFNEUCB0byBleHBsaWNpdGx5IGRl c2NyaWJlIG11bHRpcGxlIGNhbWVyYXMgd2l0aCBtdWx0aXBsZSBzdHJlYW1zIGZyb20gZWFjaCBj YW1lcmEgdW5kZXIgYSBzaW5nbGUgbS1saW5lLg0KDQoNCiogRGVjaXNpb24gLSBTaG91bGQgd2Ug Y29tZSB1cCB3aXRoIGEgc2V0IG9mIHJlcXVpcmVtZW50cyBhbmQgcHJvY2VlZCB3aXRoIFBsYW4g QSBhbmQgUGxhbiBCIHdpdGggdGhlIHRpbWVsaW5lcyBvdXRsaW5lZCBoZXJlPw0KDQoNCjI0IGZv ciwgNSBhZ2FpbnN0DQoNCg0KDQoNCkRhdGFDaGFubmVsIFNEUA0KDQoNCiogQWN0aW9uIC0gSnVz dGluIHRvIGRyYWZ0IEFQSSBmb3IgU0RQLW9ubHkgY2hhbm5lbCBvcGVuDQoNCg0KKiBEZWNpc2lv biAocnRjd2ViIGhhdHMpIC0NCiAgMmEpIEluLWJhbmQgb25seSAtIDYNCiAgMmIpIFNEUCAmIGlu LWJhbmQgLSAxMA0KICAyYykgU0RQLW9ubHkgLSAxNQ0KICBXb3JrIG9uIGJvdGggd2lsbCBjb250 aW51ZSB1bnRpbCBhIGRlY2lzaW9uIGlzIHJlYWNoZWQuDQoNCg0KKiBBY3Rpb24gLSBNYXJ0aW4g YmVsaWV2ZXMgaGUgY2FuIHNlbmQgYSBwcm9wb3NhbCB0byB0aGUgbGlzdCB3aGljaCB3aWxsIGNo YW5nZSBzb21lIG1pbmRzLg0KDQoNCkZlYnJ1YXJ5IDd0aA0KDQoNCk1TSUQNCkhhcmFsZCBBbHZl c3RyYW5kDQoxLiBNZWNoYW5pc20gZm9yIGRlY2xhcmluZyBhc3NvY2lhdGlvbnMgYmV0d2VlbiBT U1JDcw0KMi4gTWlnaHQgYmUgYmV0d2VlbiBzZXNzaW9ucyAob3Igd2l0aGluIHNlc3Npb25zKQ0K RmxlbWluZzogRG9lcyB0aGlzIGluY2x1ZGUgRGF0YSBDaGFubmVscz8gSFRBOiBEYXRhY2hhbm5l bHMgZG9uJ3QgbmVlZCB0aGlzLiBNYXJ0aW46IEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0aGUgYXNz b2NpYXRpb24gdG8gTWVkaWFTdHJlYW1zLiBIVEE6IFRoaXMgaXMgbWVhbnQgZm9yIG9uZSBlbmQg dG8gaWRlbnRpZnkgb25lIGVuZCBvZiBhIHRoaW5nIHVzaW5nIHRoZSBzYW1lIGlkZW50aWZpZXIg YXMgdGhlIG90aGVyIGVuZC4NCjEuIE1TSUQgc2VtYW50aWNzIGFyZSBkZWNsYXJlZCBieSBhbiBt c2lkLXNlbWFudGljIGxpbmUNCjIuIEN1cnJlbnRseSwgb25seSAiV01TIiBkZWZpbmVkIChXZWJS VEMgTWVkaWEgU3RyZWFtKQ0KMy4gTWVhbnMgIkRlbGl2ZXIgdGhlc2Ugc291cmNlcyB0byB0aGVz ZSBtZWRpYSBzdHJlYW0gdHJhY2tzIG9uIHRoZSBvdGhlciBzaWRlLiINCmRyYWZ0LWFsdmVzdHJh bmQtbW11c2ljLW1zaWQtMDIgaXMgdGhlIG1vc3QgcmVjZW50IHZlcnNpb24uIEFwcHJvdmVkIGZv ciBhZG9wdGlvbiwganVzdCB3YWl0aW5nIG9uIGNoYXJ0ZXIgbm93Lg0KQmVybmFyZDogSSdtIGNv bmZ1c2VkIGJ5IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlc2UgYmVpbmcgY29tbXVuaWNhdGVk IGF0IGEgc2Vzc2lvbiBsZXZlbCBhbmQgaW5kZW50aWZ5aW5nIHN0cmVhbXMgaW4gZGlmZmVyZW50 IFJUUCBzZXNpb25zLiAoU29tZSBjbGFyaWZpY2FpdG9uIGFib3V0IHRoZSBpbnRlbmRlZCBzY29w ZSBvZiBiaW5kaW5nIGZvbGxvd3MpDQpFS1I6IElmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIGV2 ZXJ5IG09IGxpbmUgaW4gdGhlIHNhbWUgTWVkaWFTdHJlYW0gaGFzIHRoZSBzYW1lIE1TSUQgaWRl bnRpZmllciBmaXJzdCBoYWxmLCBidXQgYSBkaWZmZXJlbnQgc2Vjb25kIGhhbGYuIEhUQTogVGhh dCdzIGNvcnJlY3QuDQpGbGVtaW5nOiBUaGUgY2hhaXJzIGFyZSB1bmRlciB0aGUgaW1wcmVzc2lv biB0aGF0IHRoZXkgYXJlIHdhaXRpbmcgZm9yIHRoZSBhdXRob3IsIG5vdCB0aGUgb3RoZXIgd2F5 IGFyb3VuZC4gSFRBOiBJJ20gd2FpdGluZyBmb3IgdGhlIGNoYXJ0ZXIgdG8gYmUgYW1lbmRlZC4N CkFDVElPTiBJVEVNOiBDaGFpcnMgdG8gYW1lbmQgY2hhcnRlciB0byBpbmNsdWRlIGEgbWlsZXN0 b25lIGZvciB0aGlzIHdvcmsuDQooSW50ZXJjaGFuZ2UgYmV0d2VlbiBNYXJ0aW4gYW5kIEhUQSBy ZWdhcmRpbmcgdGhlIGlkZW50aWZpY2F0aW9uIG9mIHNpbXVsY2FzdCBzdHJlYW1zLCBpbmRpY2F0 aW5nIHRoYXQgdGhleSdyZSB0cmVhdGVkIGFzIGRpZmZlcmVudCB0cmFja3MpDQpQYXVsIEs6IFRo ZSBvdGhlciBkYXksIHdlIGhhZCBhIGRpc2N1c3Npb24gb2YgYWxsIHRoZSBtZWFuaW5ncyBvZiAi U3RyZWFtIiAoZS5nLiBvbmUgU1NSQywgb25lICJmbG93IiwgZXRjKS4gVGhpcyBqdXN0IG1hcHMg dG8gdGhlIFNTUkMgZGVmaW5pdGlvbi4gSXMgdGhlcmUgYW55IHdheSB0byBnZXQgYXQgdGhlIG90 aGVyIG5vdGlvbiB3aXRoIHRoaXMgbWVjaGFuaXNtLg0KSFRBOiBXaGljaCBvdGhlciBub3Rpb24/ DQpQYXVsIEs6IFRoZSBvbmUgd2hlcmUgd2UgaGF2ZSBzZXZlcmFsIFNTUkNzLCBidXQgb25seSBv bmUgYXQgYSB0aW1lLCBhbmQgdGhvc2UgU1NSQ3MgYXJlIHN0aXRjaGVkIHRvZ2V0aGVyIHRvIG1h a2UgYSBzaW5nbGUgbG9naWNhbCBjb25zdHJ1Y3QuDQpKb25hdGhhbiBMOiBUaGVyZSBpcyBhbiBh c3N1bXB0b2luIGluIGN1cnJlbnQgU0lQIGVuZHBvaW50cyB0aGF0IHRoZSBkZXZpY2Ugc2hvdWxk IG9ubHkgbmVlZCB0byBkZWNvZGUgb25lIHRoaW5nIGF0IGEgdGltZS4gVGhhdCBkb2Vzbid0IG5l Y2Vzc2FyaWx5IG1lYW4gdGhhdCB0aGV5J3JlIHNlbWFudGljYWxseSB0aGUgc2FtZSB0aGluZy4g Rm9yIGV4YW1wbGUsIHlvdSBjYW4gZ2V0IHJpbmdiYWNrIGZvbGxvd2VkIGJ5IGFuIGFubm91bmNt ZW50IHRoYXQgeW91ciBjYWxsIGlzIGJlaW5nIGZvcndhcmRlZCwgdGhlbiB0aGUgcGVyc29uIHlv dSdyZSBjYWxsaW5nLiBUaG9zZSBwcm9iYWJseSBhcmVuJ3QgdGhlIHNhbWUgdGhpbmcsIGZyb20g YW4gTVNJRCBwZXJzcGVjdGl2ZS4NCkhUQTogQWxsIHdlIHNheSBpcyB0aGF0IHRoaXMgbWVkaWEg c3RyZWFtIGJlbG9uZ3MgdG8gdGhpcyBNU0lELiBJdCdzIGEgVzNDIGlzc3VlIHRvIGRlZmluZSB3 aGF0ICJiZWxvbmcgdG8iIG1lYW5zLiBJZiB5b3UgaGF2ZSB0byBkaXN0aW5ndWlzaCBiZXR3ZWVu ICJwbGF5IHRoZXNlIGFsbCBhdCB0aGUgc2FtZSB0aW1lIiBvciAicGxheSBvbmx5IG9uZSwiIHRo YXQncyBjb21tdW5pY2F0ZWQgdXNpbmcgYSBkaWZmZXJlbnQgbWVjaGFuaXNtLg0KSm9uYXRoYW4g TDogSWYgd2Ugd2FudCB0byB1c2UgdGhpcyBhcyBvcHBvc2VkIHRvIGE9Z3JvdXAgZm9yIHRoaW5n cyBsaWtlIHNpbXVsY2FzdCBncm91cHMsIHdlIG5lZWQgdG8gYmUgdmVyeSBjbGVhciBhYm91dCB3 aGljaCBvbmUgYXBwbGllcy4NCkhUQTogRG8gd2Ugd2FudCB0byBleHByZXNzIHRoZSByZWxhdGlv bnNoaXAgYmV0d2VlbiBTU1JDcyBpbiB0aGUgc2FtZSBSVFAgc2Vzc2lvbiwgb3IgZGlmZmVyZW50 IFJUUCBzZXNzaW9ucz8NCkpvbmF0aGFuOiBSVFAgc2Vzc2lvbnMgb3IgbSBsaW5lcz8NCkhUQTog SSB0aGluayB3ZSB3YW50IHRvIHNheSBtIGxpbmVzLiBJJ2xsIGNoZWNrIHRoZSBkb2N1bWVudCBh bmQgbWFrZSBzdXJlIHRoaXMgbWFrZXMgc2Vuc2UuDQpQYXVsOiBJcyBpdCB2YWxpZCB0byBtYXAg bW9yZSB0aGFuIG9uZSBtLWxpbmUgdG8gdGhlIHNhbWUgbXNpZD8NCkhUQTogWWVzDQpQYXVsOiBX aHk/DQpIVEE6IExheWVycyBpbiBhIGxheWVyZWQgY29kZWMsIGZvciBleGFtcGxlLiBDaGFubmVs cyBpbiBhIHNpbXVsY2FzdCwgZm9yIGFub3RoZXIuIERpZmZlcmVudCB0eXBlcyBvZiBzZXF1ZW50 aWFsIG1lZGlhLCBhcyBhIHRoaXJkLg0KTWFydGluOiBUaGVyZSdzIGEgZm91cnRoIG9uZSBhbHNv DQpIVEE6IE9oLCB0aGVyZSdzIG1hbnkgbW9yZS4NCkhUQTogUmVxdWVzdCB0byBtYWtlIHN1cmUg d2UgdXNlIHRoZSBzYW1lIHRlcm1zIGFzIG90aGVyIGRvY3VtZW50cy4NCl9fX19fX19fX19fX19f X18NCg0KDQpNZWRpYSBTb3VyY2UgSUQ6IFNvbWV0aGluZyB3ZSBuZWVkPw0KU3RlZmFuIEjDpWth bnNvbg0KKFNlZSBzbGlkZXMgZm9yIGRpYWdyYW0gb2YgbW90aXZhdGluZyB1c2UgY2FzZSBzY2Vu YXJpb3MpDQpFS1IgKFJlZ2FyZGluZyAidG8gYSBwZWVyIiB1c2UgY2FzZSk6IFRoZSBhbHRlcm5h dGUgYXBwcm9hY2ggaXMgdG8gaGF2ZSBhIHNpbmdsZSBzdHJlYW0gd2l0aCBhbGwgdGhyZWUgdHJh Y2tzIGluIGl0LCBhbmQgaGF2ZSB0aGUgZmFyIGVuZCBzd2l0Y2hpbmcgdGhlIHZpZGVvIGJ1dCBu b3QgdGhlIGF1ZGlvLiBJJ20gc2Vuc2l0aXZlIHRvIG1ha2luZyB0aGlzIG1vcmUgY29tcGxpY2F0 ZWQgdGhhbiBuZWNlc3NhcnkuDQpDaHJpc3RlcjogV2UnbGwgYmUgc2VuZGluZyB0aGUgYXVkaW8g aW4gdHdvIGRpZmZlcmVudCB0cmFja3MsIHJpZ2h0PyBJc24ndCB0aGF0IGEgd2FzdGUgb2YgYml0 cz8NClN0ZWZhbjogRm9yIHRoZXNlIHRyYWNrcywgeW91IGNhbiBpbmRpdmlkdWFsbHkgcGF1c2Uv cmVzdW1lIHRvIHByZXZlbnQgdGhhdCBwcm9ibGVtLg0KRG9taW5pcXVlOiBJZiB0aGUgb25seSBw cm9ibGVtIGhlcmUgaXMgdGVsbGluZyBqYXZhc2NyaXB0IGRldmVsb3BlcnMgImRvbid0IGRvIHRo YXQgdGhlbiwiIEkgdGhpbmsgd2UganVzdCBuZWVkIHRvIGRvY3VtZW50IHRoaXMgc29tZXdoZXJl LiBUaGUgY29tcGxpY2F0aW9uIG9mIGFkZGl0aW9uYWwgc3luYyBpc24ndCB3b3J0aCBpdC4NCkVL UjogTGV0J3Mgc2F5IEkgY3JlYXRlIHR3byBQQ3MgYW5kIGF0dGFjaCB0aGVtIHRvIHRoZSBkaWZm ZXJlbnQgYXVkaW8gc3RyZWFtcy4gU2hvdWxkIHRoZXkgYmUgc3luY2hlZD8NClN0ZWZhbjogWWVz Lg0KRUtSOiBJJ20gbm90IHN1cmUgSSBhZ3JlZS4NCkN1bGxlbjogQXMgZmFyIGFzIEkgY2FuIHRl bGwsIG1lZGlhIHN0cmVhbSBpcyBvbmx5IGEgc3luY2hyb25pemF0aW9uIGNvbnN0cnVjdC4NClN0 ZWZhbjogSSB0aGluayB3ZSB3YW50IHRvIHN5bmMgYmV0d2VlbiBtZWRpYSBzdHJlYW1zLg0KQ3Vs bGVuOiBPa2F5LCBzbyBob3cgZG8geW91IHNpZ25hbCBzdHJlYW1zIHRoYXQgZG9uJ3QgbmVlZCB0 byBiZSBzeW5jaGVkPw0KU3RlZmFuOiBXaGF0J3MgdGhlIHVzZSBjYXNlPw0KQ3VsbGVuOiBXaGl0 ZWJvYXJkcywgZm9yIGV4YW1wbGUuDQpBZGFtOiBPbmUgc2NlbmFyaW8gaGVyZSBpcyB1c2luZyBt dWx0aXBsZSBQQ3MgdG8gZG8gc2ltdWxjYXN0Lg0KU3RlZmFuOiBJIGNvdmVyIHRoYXQgb24gdGhl IG5leHQgc2xpZGUuDQpKdXN0aW46IFdoeSBhcmUgd2Ugc2VuZGluZyBib3RoIHN0cmVhbXMgQSBh bmQgQyAoYXVkaW8gc3RyZWFtcyk/DQpTdGVmYW46IFdlIGRvbid0IGhhdmUgYW55IHRvb2xzIHRv IHRlbGwgZGV2ZWxvcGVycyBub3QgdG8gZG8gdGhpcy4NCkp1c3RpbjogV2UgY2FuJ3Qgc3RvcCBw ZW9wbGUgZnJvbSB3cml0aW5nIGJhZCBwcm9ncmFtcy4gV2UgbWlnaHQgbmVlZCB0byBkbyBtb3Jl IGV4YW1wbGVzLCBidXQgZXhwZWN0aW5nIHRoYXQgd2UnbGwgZ2V0IHBlcmZlY3QgYmVoYXZpb3Ig Zm9yIGltcGVyZmVjdCBzY3JpcHRzLi4uIHdlJ3JlIGdvaW5nIHRvIGhhdmUgdG8gZG8gYSBsb3Qg b2Ygd29yay4NCkhUQTogV2UgaGF2ZSB0aGUgdG9vbCBmb3IgdGhpcy4gSXQncyBjYWxsZWQgIkVu Z2xpc2gsIiBhbmQgd2UgcHV0IGl0IGluIHRoZSBzcGVjLiBSaWdodCBub3csIHdlIHNheSBzdHJl YW1zIGFyZSBzeW5jaGVkIGluIGEgc3RyZWFtLCBhbmQgdGhhdCB0aGV5J3JlIG5vdCBzeW5jaGVk IGJldHdlZW4gc3RyZWFtcy4gSWYgd2UgZG9jdW1lbnQgdGhpcyBwcm9wZXJ0eSBhbmQgZGV2ZWxv cGVycyBtZXNzIGl0IHVwLCBpdCdzIHRoZWlyIGZhdWx0Lg0KVGVkOiBJcyB0aGVyZSBhIGRyaXZp bmcgdXNlIGNhc2Ugb3RoZXIgdGhhbiAic29tZW9uZSBkaWRuJ3QgcmVhZCB0aGUgc3BlYyI/IElm IHlvdSBoYWQgc3VjaCBhIHVzZSBjYXNlLCBJIGNvdWxkIHVuZGVyc3RhbmQgdGhpcyBiZXR0ZXIu DQpTdGVmYW46IFNpbXVsY2FzdCB3aXRoIHR3byBQQ3MsIGZvciBleGFtcGxlLg0KRG9taW5pcXVl OiBUaGVyZSB3aWxsIGJlIGJhZCBwcm9ncmFtbWVycy4gVGhlaXIgcHJvZ3JhbXMgd2lsbCBmYWls LiBXZSBkb24ndCBuZWVkIHRvIHByb3RlY3QgYWdhaW5zdCBhbGwgYmFkIHByb2dyYW1taW5nLiBB cyBsb25nIGFzIHdlIGhhdmUgdGhlIHRvb2xzIHRvIGRvIHRoaW5ncyByaWdodCwgYW5kIGhhdmUg ZG9jdW1lbnRlZCB0aGVtLCB0aGVuIG91ciBqb2IgaXMgZG9uZS4NCkpvbmF0aGFuOiBJIHVuZGVy c3RhbmQgdGhhdCBBVlRDT1JFIGlzbid0IGhlcmUsIGJ1dCBJJ20gd29ycmllZCB0aGF0IFJUUCBk ZWZpbmVzIHN5bmMgYnkgQ05BTS4gSG93IGRvIGJyb3dzZXJzIGtub3cgdG8gdXNlIHN5bmNocm9u aXphdGlvbiB2aWEgc29tZXRoaW5nIG90aGVyIHRoYW4gQ05BTT8NCkN1bGxlbjogTXkgdW5kZXJz dGFuZGlnIChhcyBSVENXRUIgY2hhaXIpIHdhcyB0aGF0IGJyb3dzZXJzIGZ1bGx5IGludGVuZCB0 byBzZW5kIENOQU1zIGFjY29yZGluZyB0byB0aGlzIHNjaGVtZS4NCkpvbmF0aGFuOiBIb3cgYWJv dXQgcmVjZWlwdD8NCkN1bGxlbjogVEhleSBzaG91bGQgbWF0Y2ggdXAuDQpFS1I6IFRoYXQncyBu b3QgZ29pbmcgdG8gd29yay4gTWVkaWEgc3RyZWFtcyBhcmUgZ2VuZXJhdGVkIHByaW9yIHRvIHJl Y2VpdmluZyBhbnkgUlRQLiBHaXZlbiB0aGF0LCB3ZSBtdXN0IGJlIGFibGUgdG8gZGVyaXZlIHRo YXQgdHdvIHRoaW5ncyBhcmUgc3luY2hlZCB2aWEgU0RQIGFic2VudCBhbnkgUlRQIG1lY2hhbmlz bS4gSWYgdGhlcmUncyBhIGNvbmZsaWN0IGJldHdlZW4gU0RQIGFuZCBSVFAsIHdlIG5lZWQgdG8g aGFybW9uaXplIHRoZW0uDQpKb25hdGhhbjogKG1pc3NlZCB0aGlzIHN0YXRlbWVudCkNCkVLUjog TXkgYXNzdW1wdGlvbiBpcyB0aGF0IGJyb3dzZXJzIHdpbGwgdHJlYXQgdGhpbmdzIGluIHNlcGFy YXRlIE1TSURzIChvciB3aXRoIG5vIE1TSURzKSBhcyBpZiB0aGV5IGFyZSBzZXBlYXJ0ZSBzdHJl YW1zIChvciBtZXJnZSB0aGVtIGludG8gdGhlIHNhbWUgc3RyZWFtKS4NCkpvbmF0aGFuOiBJZiB5 b3UgaGF2ZSBvbmUgYXVkaW8gYW5kIG9uZSB2aWRlbywgdGhleSdyZSBwcm9iYWJseSBzdXBwb3Nl ZCB0byBiZSBzeW5jaHJvbml6ZWQuDQpFS1I6IChtaXNzZWQgdGhpcyBzdGF0ZW1lbnQpDQpDdWxs ZW46IElzIHRoZXJlIGEgZHJhZnQgZm9yIHB1dHRpbmcgQ05BTXMgaW4gU0RQPw0KSm9uYXRoYW46 IChSRkMgNTU3NiksIGJ1dCBubyBvbmUgaXMgZ29pbmcgdG8gd2FudCB0byB1c2UgaXQuDQoNCg0K SmVzdXA6IEkgdGhpbmsgd2hlbiB5b3UgaGF2ZSBsZWdhY3kgaW5jb21pbmcgU0RQLCB0aGUgYnJv d3NlciBpcyBnb2luZyB0byBuZWVkIHRvIHN0dWZmIHRoZW0gYWxsIGluIHRoZSBzYW1lIG1lZGlh IHN0cmVhbSBhbmQgc3luYyB0aGVtLiBZb3UgY2FuIHdhaXQgZm9yIHRoZSBDTkFNcyBpZiB5b3Ug d2FudCB0bywgYnV0IHJlYWxpc3RpY2FsbHkgeW91J2xsIGJlIGNvdmVyZWQganVzdCBmaW5lIGlm IHlvdSBkb24ndC4NCkpvbmF0aGFuOiBJJ20gbm90IHN1cmUgdGhlcmUncyBhbnkgZ3VhcmFudGVl IHRoYXQgc3luY2hyb25pemluZyBpbmZvcm1hdGlvbiBoYXMgYW55IHJlbGF0aW9uc2hpcCB0byBl YWNoIG90aGVyIGlmIHRoZSBzdHJlYW1zIGhhdmUgZGlmZmVyZW50IENOQU1zLiBDb25zaWRlciBk ZWNvbXBvc2VkIHNvdXJjZXMgd2l0aCBjbG9jayBza2V3Lg0KTWFydGluIFRob21wc29uOiBDb25z aWRlciB0aGF0IHN5bmMgaXMgZ29pbmcgdG8gYWN0IHRyYW5zaXRpdmUuIElmIHlvdSBzeW5jIEEg d2l0aCBCLCBhbmQgQyB3aXRoIEQsIHRoZW4gc3luY2hpbmcgQiB3aXRoIEQgd2lsbCBhdXRvbWF0 aWNhbGx5IHN5bmNoIEEgd2l0aCBCLiBBbHNvLCBJIHRoaW5rIGlmIHlvdSBzdGFydCB0byBzeW5j IHRoaW5ncyB0aGF0IHNob3VsZG4ndCBiZSBzeW5jaGVkLCB5b3UncmUgZ29pbmcgdG8gZW5kIHVw IHdpdGggc29tZSBzdXJwcmlzaW5nIGZhaWx1cmVzLg0KSGFkcmllbDogQXJlIHlvdSBzYXlpbmcg dGhlIG1lZGlhIHN0cmVhbSBjYW4gb3ZlcnJpZGUgdGhlIENOQU1zPw0KRmx1ZmZ5OiBJIGRvbid0 IHRoaW5rIHdlIGhhdmUgY29uc2Vuc3VzLiBJJ2QgY29uc2lkZXIgdGhhdCB1bnJlc29sdmVkLg0K SGFkcmllbDogV2hlbiB0aGVzZSBjb21lIGluIGZyb20gZ2F0ZXdheXMsIHRoZXkncmUgbm90IGdv aW5nIHRvIGJlIG9yZ2FuemllZCBieSBDTkFNcy4NCkFjdGlvbiBJdGVtIGZvciBjaGFpcnM6IERl dGVybWluZSBIb3cgd2UgaGFuZGxlIENOQU0sIE1lZGlhU3RyZWFtcywgTVNJRHMsIENOQU0gY2hh bmdlcywgY29uZmVyZW5jZSBtaXhpbmcgd2l0aCBubyBDU1JDcywgYW5kIHRoZSByZWxhdGVkIG1v cmFzcw0KU3RlZmFuOiBJIHRoaW5rIHdlJ2xsIGNhbGwgdGhhdCB0aGUgZW5kIG9mIHRoaXMgdGlt ZXNsb3QuDQpFS1I6IE1TSUQgaXMgdGhlIG9ubHkgdGhpbmcgd2UgY2FuIHVzZSB0byBhc3NlbWJs ZSBtZWRpYSBzdHJlYW1zLiBMYWNraW5nIHRoYXQsIHdlJ2xsIG5lZWQgdG8gdHJlYXQgdGhlbSBh cyBhbGwgc2VwYXJhdGUgb3IgYWxsIHRvZ2V0aGVyLg0KSGFkcmllbDogQ2FuIHdlIHBpY2sgb25l IGFuZCBzdGFuZGFyaXplIGl0Pw0KRUtSOiBTdXJlLg0KRUtSOiBXZSdsbCBoYXZlIHRvIGFzc3Vt ZSB0aGF0IGV2ZXJ5dGhpbmcgd2l0aCB0aGUgc2FtZSBNU0lEIGlzIGluIHRoZSBzYW1lIG1lZGlh IHN0cmVhbS4gKFNvbWUgcHJvcG9zYWwgYWJvdXQgaG93IHRvIGhhbmRsZSBDTkFNL01TSUQgbWlz bWF0Y2hlcywgYnV0IGl0IHdhcyB0b28gZmFzdCB0byBmb2xsb3cpLg0KSFRBOiAuLi4NCkhUQTog QW5vdGhlciBxdWVzdGlvbiBpcyB3aGV0aGVyIHdlIHNob3VsZCBjb25kaXRpb24gdGhlc2Ugb24g Q05BTXMsIHdoZW4gd2UgY2FuIGdldCBSVFAgcGFja2V0cyB3aXRob3V0IENOQU1zIGFyZSBhbGwu DQpUZWQ6IFdlIG5lZWQgdG8gY29uc2lkZXIgd2hldGhlciB3ZSBuZWVkIHRvIHJlYWxseSBuYWls IGRvd24gYmVoYXZpb3IgZnJvbSB0aGUgY29ybmVyIGNhc2Ugd2hlcmUgYSBicm93c2VyIGdldHMg U0RQIGZyb20gYSBub24tYnJvd3NlciwgZ2l2ZW4gdGhhdCBpdCdzIHJlYWxseSBhIGNvcm5lciBj YXNlLiBJdCdzIGVhc2llciB0byBzYXkgImlmIHRoZXJlJ3Mgbm8gTVNJRCwgYXNzdW1lIHRoZXkn bGwgYmUgdHJlYXRlZCBzZXBhcmF0ZS4iDQpKb25hdGhhbjogVGhlIGFiaWxpdHkgdG8gc3luYyBk ZXBlbmRzIG9uIHJlY2VpcHQgb2YgYSBmaXJzdCBDTkFNIGFueXdheS4NCkhhZHJpZWwgKHJlc3Bv bmRpbmcgdG8gVGVkKTogV2FpdCwgd2hlbiB3ZSdyZSBnYXRld2F5aW5nLCB3ZSBkb24ndCBrbm93 IGhvdyB0byBwdXQgTVNJRHMgaW4uIFRoaXMgaXNuJ3QgZ29pbmcgdG8gYmUgYXMgbXVjaCBvZiBh IGNvcm5lciBjYXNlLg0KKGNvbnZlcnNhdGlvbiBlbnN1ZXMgYWJvdXQgbm9uLXN5bmMgYmVoYXZp b3IgYmVpbmcgImNsb3NlIGVub3VnaCwiIHdoZXRoZXIgTVNJRHMgbmVlZCB0byBiZSBtYW5kYXRv cnksIHNvbWUgY29uc2lzdGVuY3kgYWJvdXQgd2hhdCBoYXBwZW5zIGlmIHRoZXkncmUgbWlzc2lu ZywgZXRjKS4NCk1hcnRpbjogSSB0aGluayB3ZSBjYW4gaGFuZGxlIHRoZW0gYmVpbmcgc2VwYXJh dGUgaW4gdGhlIGFic2VuY2Ugb2YgTVNJRC4NCkhhZHJpZWw6IFNvIHlvdSdyZSBzYXlpbmcgdGhh dCB5b3UncmUgb2theSBpZiB0aGV5J3JlIHNlcGFyYXRlPw0KTWFydGluOiBZZXMuDQpIYWRyaWVs OiBNZSB0b28uIEkgZG9uJ3QgYWN0dWFsbHkgY2FyZSwgSSBqdXN0IHdhbnQgb25lIG9yIHRoZSBv dGhlciB0byBiZSBzcGVjaWZpZWQuDQpCZXJuYXJkOiBJIGFyZ3VlIHRoYXQgUlRQIHN0cmVhbXMg d2l0aCB0aGUgc2FtZSBDTkFNIHNob3VsZCBzeW5jIGV2ZW4gaWYgd2Ugc3BlY2lmeSB0aGVtIGFz IGRpZmZlcmVudCBzdHJlYW1zLg0KVGltOiBZb3UgY2FuJ3QgYXNzdW1lIHRoYXQgdGhpbmdzIHRo YXQgYXJlIG5vdCBpbiB0aGUgc2FtZSBtZWRpYSBzdHJlYW0gYXJlIG5vdCBzeW5jaGVkLg0KQ3Vs bGVuOiBJbiB0aGUgY2FzZSBvZiBhIHNpbmdsZS1zdHJlYW0gdm9pY2UvdmlkZW8gcGhvbmUgdXNp bmcgU0lQLCBkbyB3ZSB0aGluayB0aGUgYnJvd3NlciBwbGF5b3V0IHNob3VsZCBiZSBzeW5jaHJv bml6ZWQ/DQpNYXJ0aW46IFdoYXQgVGVkIHNhaWQgaXMgdGhhdCB3ZSBuZWVkIHRvIE1lZGlhU3Ry ZWFtcywgd2hpY2ggbWF5IG9yIG1heSBub3QgYmUgc3luY2hlZC4gSWYgdGhleSB0dXJuIG91dCB0 byBiZSBzeW5jaGVkIChmb3Igd2hhdGV2ZXIgcmVhc29uKSwgY29vbC4gQnV0IHdlIGRvbid0IG1h a2UgYW55IHByb21pc2VzLg0KQ3VsbGVuOiBCdXQgaXMgdGhlcmUgYSByZXF1aXJlbWVudCBmb3Ig dGhlIGJyb3dzZXIgdG8gdGVsbCB0aGUgYXBwIHRoYXQgdGhlc2UgdGhpbmdzIGFyZSBpbiBzeW5j Pw0KTWFydGluOiBObywgSSB0aGluayB0aGUgYnJvd3NlciBjYW4ganVzdCBkbyB0aGF0DQpIYWRy aWVsOiBCdXQgYXJlIHdlIGdvaW5nIHRvIHJlcXVpcmUgdGhhdCB0aGV5IGFyZSBzeW5jaGVkIGlm IHRoZXkgaGF2ZSB0aGUgc2FtZSBDTkFNPw0KTWFydGluL1RlZDogTm8uDQpUZWQ6IFRoZXkgbWln aHQgYmUgc3luY2hlZCwgYnV0IHRoZXkgYXJlIG5vdCBndWFyYW50ZWVkIHRvIGJlLiBJdCdzIGFu ICJ1bmRlcnByb21pc2UgYW5kIChwb3RlbnRpYWxseSkgb3ZlcmRlbGl2ZXIiIHNpdHVhdGlvbi4N CkN1bGxlbjogVGhhdCdzIG5vdCB3aGF0IEhhZHJpZWwgc2FpZC4NCkpvbmF0aGFuOiBJIHRoaW5r IHdlJ3JlIG92ZXJwcm9taXNpbmcgYW5kIHVuZGVyZGVsaXZlcmluZyBpZiB3ZSBoYXZlIHR3byBz dHJlYW1zIGluIHRoZSBzYW1lIHN0cmVhbSBidXQgZGlmZmVyZW50IENOQU1zLiBJZiB0aGV5J3Jl IG5vdCB0aGUgc2FtZSBDTkFNLCB5b3UgY2FuIGVuZCB1cCB3aXRoICJ0aGVzZSBzdHJlYW1zIGFy ZSA0MCB5ZWFycyBvdXQgb2Ygc3luYywiIHNpbmNlIHRoZXkgY2FuIGJlIHVzaW5nIGRpZmZlcmVu dCBjbG9ja3MuIFRoYXQncyBwcm9iYWJseSBiYWQuDQpFS1I6IEkgd291bGQgYXNzdW1lIHRoYXQg eW91IHN0b3AgdHJ5aW5nIHRvIHN5bmMgdGhlbS4gVGhlcmUncyBubyBvdGhlciB3YXkgdG8gaW1h Z2luZSBob3cgeW91IGRvIHRoYXQuDQpKb25hdGhhbjogV2hhdCdzIHRoZSB0aHJlc2hvbGQgZm9y IHRoYXQ/DQpNYXJ0aW46IGltcGxlbWVudGFpb24gZGVjaXNpb24uDQpEYW46IFdoYXQgZG8geW91 IGV4cGVjdCB0byBoYXBwZW4gaWYgeW91IGhhdmUgdHdvIG1lZGlhIGZsb3dzIGZyb20gd2hlcmV2 ZXIgLS0gZGlmZmVyZW50IGRldmljZXMsIGRpZmZlcmVudCBQQ3MgLS0gYW5kIHRoZW4geW91IHNh eSAic3luY2ggdGhlc2UuIiBXaGF0IGRvIHlvdSBleHBlY3QgdG8gaGFwcGVuPyBTdGFydGluZyBm cm9tIHRoZSBwb2ludCBhdCB3aGljaCBJIHB1dCB0aGVtIHRvZ2V0aGVyLCBJIHdvdWxkIGV4cGVj dCB0aGVtIHRvIGFkdmFuY2UgYXQgdGhlIHNhbWUgcmF0ZS4NCkpvbmF0aGFuOiBZZXMsIHRoYXQn cyB3aGF0IGhhcHBlbnMuIFRoZSBvbmx5IHRpbWUgdGhhdCB3b24ndCBoYXBwZW4gaXMgaWYgeW91 J3JlIHRyeWluZyB0byBkZWFsIHdpdGggc3luYyBza2V3Lg0KKE1pc3NlZCBzb21lIG9mIHRoZSBk aXNjdXNzaW9uIGhlcmUpDQpIYWRyaWVsOiBJIGNvdWxkIGJlIHZlcnkgd3JvbmcsIGJ1dCBpdCBz ZWVtcyB0aGF0IHRoZSBicm93c2VyIGd1eXMgc2hvdWxkbid0IHdhbnQgdG8gbGVhdmUgdGhpcyB1 cCB0byBpbXBsZW1lbnRhdGlvbi4gVGhpcyB3b3VsZCBsZWFkIHRvIGludGVyb3AgZmFpbHVyZXMs IHJpZ2h0PyBZb3UnZCBoYXZlIHNjcmlwdHMgdGhhdCBkbyBkaWZmZXJlbnQgdGhpbmdzLCByaWdo dD8gSSB0aGluayBpZiB3ZSBoYXZlIHR3byB0cmFja3Mgd2l0aCB0aGUgc2FtZSBDTkFNLCB3ZSBz aG91bGQgZ3VhcmFudGVlIHRoYXQgdGhleSdsbCBiZSBzeW5jaGVkLg0KQmVybmFyZDogSSB0aGlu ayB0aGUgUlRQIHVzYWdlIGRvY3VtZW50IGFscmVhZHkgc2F5cyB0aGF0LCByaWdodD8NClRpbTog VGFsa2luZyBhYm91dCBhZHZhbmNpbmcgY2xvY2tzIGF0IHRoZSBzYW1lIHJhdGUsIHRoYXQgd2Fz IHdoYXQgd2UgZmlyc3Qgc2FpZCBhYm91dCBwdXR0aW5nIHR3byB0aGluZ3MgaW4gdGhlIHNhbWUg bWVkaWEgc3RyZWFtLCByaWdodD8NCkRhbjogUmlnaHQsIHdoYXQgSSBzYWlkIHdhcyB0aGF0IGEg bmHDr3ZlIGNvZGVyIHdvdWxkIGV4cGVjdCB0aGF0IHB1dHRpbmcgdHdvIHRoaW5ncyB0b2dldGhl ciBpbiB0aGUgc2FtZSBtZWRpYSBzdHJlYW0gc2hvdWxkIGJlIGd1YXJhbnRlZWQgdG8gcHJvY2Vl ZCBhdCB0aGUgc2FtZSByYXRlIGFzIGVhY2ggb3RoZXIuDQpIVEE6IFdoZW4gSSBzZXR1cCBhIHN0 cmVhbSwgSSBoYXZlIGEgaml0dGVyIGJ1ZmZlciBhbmQgYSBwbGF5b3V0IGNsb2NrLiBJZiB3ZSBj b21iaW5lIHRyYWNrcyBmcm9tIGRpZmZlcmVudCByZW1vdGUgc291cmNlcyAoYW5kIGl0J3MgbmF0 dXJhbCB0byB0aGluayB3ZSBzaG91bGQgYmUgYWJsZSB0byksIHNvbWUgb2YgdGhlc2UgY2xvY2tz IHdvbid0IHJ1biBhdCB0aGUgc2FtZSByYXRlLCB3aGljaCBtZWFucyBzb21lb25lIHNvbWV3aGVy ZSBuZWVkIHRvIGhhcm1vbml6ZSB0aGVtICh3aGljaCBpbnRyb2R1Y2VzIGFydGlmYWN0cykuIFlv dSBoYXZlIHRvIGRlY2lkZSB3aGVyZSB0aGUgaml0dGVyIGJ1ZmZlciBsaXZlcywgeW91IGhhdmUg dG8gZGV0ZXJtaW5lIGhvdyB5b3UgaGFuZGxlIHNrZXcuDQpLZWl0aDogTW9zdCBvZiB0aGlzIGNv bnZlcnNhdGlvbiBpcyBpbiB0aGUgcGVydmlldyBvZiBBVlRDT1JFLCBub3QgdGhpcyBjb252ZXJz YXRpb24gYW5kIG5vdCB0aGVzZSB3b3JraW5nIGdyb3Vwcy4gV2UgbmVlZCB0byBjb21tdW5pY2F0 ZSBhbnkgbmV3IHJlcXVpcmVtZW50cyB0byBBVlRDT1JFLg0KQ3VsbGVuOiBJIGRvbid0IHRoaW5r IHdlIGhhdmUgYW55IGNvbmNsdXNpb25zIGluIG5lZWQgb2YgYmVpbmcgY29tbXVuaWNhdGVkLg0K X19fX19fX19fX19fX19fXw0KDQoNClRyaWNrbGUgSUNFDQoxLiBUaGUgcG9pbnQgb2YgdHJpY2ts ZSBJQ0UgaXMgdG8gb3B0aW1pemUgYSBjaGFyYWN0ZXJpc2l0aWMgb2YgSUNFOyByaWdodCBub3cs IGRpc2NvdmVyeSBpcyBoYW5kbGVkIHNlcmlhbGx5LiBUaGUgaWRlYSBpcyB0aGF0IHdlIGNhbiBo YW5kbGUgdGhlc2Ugc3RlcHMgaW4gcGFyYWxsZWwuDQoyLiBGaXJzdCB0aW1lIGFyb3VuZCwgd2Ug dHJpZWQgZG9pbmcgaXQgaW4gYSB2ZXJ5IGdlbmVyaWMgZmFzaGlvbiwgaW4gcGFyaXRjdWxhciBh Z25vc3RpYyB0byBvZmZlcnMgYW5kIGFuc3dlcnMuDQozLiBXZSB3ZXJlIHRvbGQgdGhhdCB3ZSBh bHNvIG5lZWQgdG8gc3BlY2lmeSBob3cgdG8gZG8gdGhpcyBpbiBTSVAuDQo0LiBXZSB3ZXJlIHRv bGQgdG8gZXhwYW5kIG9uIGhhbGYtdHJpY2tsZQ0KNS4gV2Ugd2VyZSB0b2xkIHRvIGV4cGxhaW4g aW50ZXJvcCB3aXRoIElDRSBMaXRlIGltcGxlbWVudGF0aW9uczAuDQpDaGFuZ2VzDQoxLiBOb3cg YWR2ZXJ0aXNlIHN1cHBvcnQgaW4gYSBuZXcgYXR0cmlidXRlDQoyLiBOZXcgc3ludGF4IGZvciBv ZmZlci9hbnN3ZXIgd2l0aCBubyBhZGRyZXNzZXMgKDAuMC4wLjAsIHBvcnQgPSAxKQ0KMy4gU3lu dGF4IGZvciBhbm5vdW5jaW5nIGVuZCBvZiBjYW5kaWRhdGVzIChhPWVuZC1vZi1jYW5kaWRhdGVz KQ0KRUtSOiBBUEkgaXMgYWxyZWFkeSBkZWZpbmVkIHNvIHdlJ3JlIGp1c3QgZGlzY3Vzc2luZyB3 aXJlIHN5bnRheA0KQWRhbTogTWFrZSBzdXJlIHlvdXIgc3ludGF4IHRhbGtzIGFib3V0IElQdjYN CkVtaWw6IFlvdSdsbCBzdGlsbCBwdXQgSVB2NCwgYW5kIHRoZW4gaW5jbHVkZSB2NiBjYW5kaWF0 ZXMuDQpGbGVtaW5nOiAoc29tZXRoaW5nIGFib3V0IFNEUCBzeW50YXgpLg0KSGFkcmllbDogRW5k IG9mIGNhbmRpZGF0ZXMgcmVhbGx5IG1lYW5zICJ0aGlzIGlzIG15IGZpbmFsIFNEUCBjaGFuZ2Uu Ig0KRW1pbDogSXQgcmVhbGx5IG1lYW5zIHRoYXQgd2UncmUgZG9uZSBzZW5kaW5nIGNhbmRpZGF0 ZXMuDQpIYWRyaWVsOiBJdCdzIHJlYWxseSBzYXlpbmcgd2UncmUgZ29pbmcgdG8gc3RvcCBjaGFu Z2luZyBTRFAuDQpFbWlsOiBJdCBjb3VsZCBiZSBqdXN0IGEgZGlmZmVyZW50IG1lc3NhZ2UgdG8g dGhlIG90aGVyIFVBLg0KSm9uYXRoYW46IEkgdGhpbmsgdGhlIGFkdmFudGFnZSB0byAiYT1lbmQt b2YtY2FuZGlkYXRlcyIsIGlzIHRoYXQgeW91IGNhbiBzdGFydCBkb2luZyB0aGUgSUNFIGNvbmNs dXNpb24gYW5kL29yIGRlY2xhcmUgZmFpbHVyZSAob3Igc3VjY2VzcyBvbiBhIG5vbi1wcmVmZXJy ZWQgdHJhbnNwb3J0LCBsaWtlIFRVUk4pLg0KSm9uYXRoYW46IFVzZSBwb3J0IDkgcmF0aGVyIHRo YW4gMS4NCihEaXNjdXNzaW9uIGFib3V0IHRoZSB1c2Ugb2YgMC4wLjAuMCB3aGljaCB1c2VkIHRv IGhhdmUgZGlmZmVyZW50IHNlbWFudGljcykNCkFkYW06IEl0IHdvdWxkIGJlIG5pY2UgaWYgd2Ug dXNlIHNvbWV0aGluZyBkaWZmZXJlbnQsIGxpa2UgIklQNiA6OiIgcmF0aGVyIHRoYW4gIklQNCAw LjAuMC4wIiAtLSBvdGhlcndpc2UsIHlvdSBoYXZlIHRvIGFkZCBzcGVjaWFsIHB1cnBvc2UgY29k ZSB0byBleGlzdGluZyBTRFAgbGlicmFyaWVzLg0KKFNvbWUgZGlzY3Vzc2lvbiBhYm91dCBob3cg dG8gaGFuZGxlIHdpdGggU0lQLCBhbmQgdGhhdCB3ZSBuZWVkIHRvIGluY2x1ZGUgYSByZWZlcmVu Y2UgdG8gdGhlIFNJUCBkb2N1bWVudCkNCkpvbmF0aGFuOiBJdCdzIHBvc3NpYmxlIHRoYXQgeW91 IG1pZ2h0IG5lZWQgYSBuZXcgb2ZmZXIvYW5zd2VyIGJlZm9yZSB0cmlja2xlIGNvbmNsdWRlcy4g WW91J2xsIHdhbnQgdG8gaW5jbHVkZSB0aGUgcHJldmlvdXNseSBjb21tdW5pY2F0ZWQgY2FuZGlk YXRlcyBpbiB0aGUgbmV3IG1lc3NhZ2VzLCB3aGljaCB3b3VsZCBpbmNsdWRlIHRoZSAiYT1lbmQt b2YtY2FuZGlkYXRlcyIgaWYgbmVjZXNzYXJ5Lg0KKFNvbWUgZGlzdWNzc2lvbiBhcm91bmQgaG93 IGxvbmcgeW91IHJ1biB0cmlja2xlIHZlcnN1cyB3aGVuIHlvdSBkbyBJQ0UgcmVzdGFydHMpDQox LiBVc2VkIHRvIHNheSB0aGF0IHlvdSBvbmx5IGRvIHRyaWNrbGUgaWYgeW91IGtub3cgdGhlIHJl bW90ZSBwYXJ0eSBkb2VzIHRyaWNrbGUuIE5vdyBzYXkgdGhhdCB5b3UgY2FuIGRvIGhhbGYtdHJp Y2tsZSBpZiB5b3UgZG9uJ3Qga25vdyB0aGUgcmVtb3RlIGVuZCBzdXBwb3J0cyBpdC4NCihTb21l IHZlcnkgY29uZnVzaW5nIGRpc2N1c3Npb24gYWJvdXQgM1BDQykNCkRhbGU6IElmIHlvdSBzZW5k IGFuIG9mZmVyLCBhbmQgZ2V0IGFuIGFuc3dlciwgYW5kIHRoZW4gc2VuZCBhIHN1YnNlcXVlbnQg b2ZmZXIgaW4gdGhlIHNhbWUgZGlhbG9nLCB5b3UncmUgbm90IGd1YXJhbnRlZWQgdGhhdCB0aGUg c3Vic2VxdWVudCBvZmZlciBnb2VzIHRvIHRoZSBzYW1lIGltcGxlbWVudGF0aW9uLiBTbyB5b3Ug Y2FuJ3QgbWFrZSBhbnkgYXNzdW1wdGlvbiBhYm91dCB0aGUgY2FwYWJpbGl0eSBvZiB0aGUgdGhp bmcgcmVjZWl2aW5nIHRoZSBuZXcgb2ZmZXIuDQpGbGVtaW5nOiBUaGF0IHNlZW1zIHRvIGJlIHZl cnkgcHJvYmxlbWF0aWMuDQpEYWxlOiBZZXMsIGJ1dCB0aGVyZSBhcmUgc29sdXRpb25zLCBhbmQg bXkgZHJhZnQgZGlzY3Vzc2VzIHRoZXNlLg0KKFNvbWUgY2xhcmlmeWluZyBxdWVzdGlvbnMgYWJv dXQgdGhhdCBtZWNoYW5pc20pDQpGbGVtaW5nOiBOZWVkIGNsZWFuIHNlcGFyYXRpb24gZm9yIGlu ZGljYXRpb24gb2Ygc3VwcG9ydCBhbmQgaW5kaWNhdGlvbiBvZiAiSSdtIGdvaW5nIHRvIHVzZSB0 aGlzIHJpZ2h0IG5vdyIgKGUuZy4sICJhPXRyaWNrbGUtaWNlOm9uIikuDQpFbWlsOiBTbyB3aGF0 IGFyZSB0aGUgc2VtYW50aWNzIG9mIHNheWluZyAiSSBjYW4gZG8gdHJpY2tsZSwgYnV0IEknbSBu b3QgZG9pbmcgaXQgcmlnaHQgbm93PyINCkpvbmF0aGFuOiBJdCBsZXRzIHlvdSBpbmRpY2F0ZSB0 byB0aGUgcmVtb3RlIHBhcnR5IHRoYXQgeW91IGNhbiByZWNlaXZlIHRyaWNrbGUuDQpFS1I6IFlv dSBjYW4gZGV0ZWN0IHdoZXRoZXIgaXQncyBiZWluZyB1c2VkIGJ5IHRoZSBwcmVzZW5jZSBvZiBj YW5kaWRhdGVzLg0KSm9uYXRoYW46IEkgdGhpbmsgd2hhdCBJIHdhcyBzYXlpbmcgYmVmb3JlIGFi b3V0IDNQQ0MgLS0gaWYgeW91J3JlIHVzaW5nIElDRSwgaXQgd29uJ3Qgd29yayBhbnl3YXkgd2l0 aG91dCBJQ0UgcmVzdGFydCAtLSBzbyBJIHRoaW5rIHlvdSdyZSBva2F5Lg0KMS4gSGFsZiBUcmlj a2xlDQpNb3N0bHkgbWVhbnQgZm9yIFNJUC4gSW52b2x2ZXMgb2ZmZXJlciBzZW5kaW5nIGFsbCBh dHRyaWJ1dGVzIGluIHRoZSBvZmZlciwgYnV0IGdldHRpbmcgY2FuZGlkYXRlcyB0cmlja2xlZCBi YWNrIGJ5IHRoZSBhbnN3ZXJlci4gKEZyb20gdGhhdCBwb2ludCwgd2UgY2FuIHVzZSBmdWxsIHRy aWNrbGUgaW4gYm90aCBkaXJlY3Rpb25zKS4NCk9QRU4gSVNTVUVTDQoxLiBEbyB3ZSByZWFsbHkg bmVlZCB0aGUgc3RyZWFtIGluZGV4Pw0KRUtSOiBBbGwgd2UgbmVlZCBpcyBzb21lIHdheSBpbiB0 aGUgQVBJIHRvIGluZGljYXRlIHdoZXJlIHRoZXkgZ28uDQpFbWlsOiBTbyB0aGlzIHNob3VsZCBi ZSB0YWtlbiBjYXJlIG9mIGJ5IHRoZSBwcm90b2NvbCB0aGF0IHVzZXMgVHJpY2tsZSBJQ0UuDQpF bWlsOiBDdXJyZW50bHksIHdlIHNheSB0byB1c2UgZWl0aGVyIGluZGV4IG9yIG1pZC4gV2hlbiB3 b3VsZCB3ZSBldmVyIHVzZSBqdXN0IGluZGV4Pw0KKEkgbXVzdCBoYXZlIG1pc3NlZCBzb21ldGhp bmcgYmVjYXVzZSB0aGlzIHNlZW1zIGNvbXBsZXRlbHkgbm9uLXNlcXVpdHVyKQ0KRmxlbWluZzog V2UgbmVlZCB0byBkZWZpbmUgYSB3YXkgdG8gdXNlIHRoaXMgaW4gb2ZmZXIvYW5zd2VyLg0KQ3Vs bGVuOiBEbyB3ZSBoYXZlIGEgd2F5IHRvIGhhbmRsZSB0aGlzIGlmIHRoZXJlIGFyZSBubyBtaWQn cyBhdCBhbGw/DQooTXVybXVycyBmcm9tIHRoZSByb29tIHNlZW0gdG8gdGhpbmsgc28pLg0KU29t ZSBkaXNjdXNzaW9uIGFib3V0IG9yZGVyaW5nIG9mIGF0dHJpYnV0ZXMsIGFuZCB3aGV0aGVyICJl bmQtb2YtY2FuZGlkYXRlcyIgbmVlZHMgYW4gZXhwbGljaXQgaW5kZXguDQpKdXN0aW46IFdlIGNv dWxkIHB1dCBib3RoIG1pZCBhbmQgbS1saW5lIGluZGV4LCBidXQgd2UncmUgcHJvcG9zaW5nIGp1 c3QgbWlkIGZvciBzaW1wbGljaXR5LiBEb2VzIHRoYXQgd29yaz8NCkVLUjogUmlnaHQgbm93LCBJ IHJlYWQgaXQgYXMgc2F5aW5nIHlvdSBNVVNUIGhhdmUgYW4gbS1saW5lIGluZGV4LCBhbmQgU0hP VUxEIGhhdmUgYSBNSUQuDQpKdXN0aW46IElzIHRoZXJlIGFueSByZWFzb24gdG8gZG8gdHJpY2ts ZSB3aXRoIHNvbWV0aGluZyB0aGF0IGRvZXNuJ3QgZG8gbWlkPw0KQ3VsbGVuOiBXZSBjYW4gbWFu ZGF0ZSB0aGF0IGFsbCB0cmlja2xlIHVzZXJzIGluY2x1ZGUgYSBtaWQuDQooUGVvcGxlIHNlZW1l ZCB0byBsaWtlIHRoaXMpDQpFbWlsOiBXZSBkZWZpbmUgdGhlc2UgYXMgbS1saW5lIGF0dHJpYnV0 ZXMuIFNob3VsZCB0aGV5IGFsc28gYmUgc2Vzc2lvbi1sZXZlbD8NCkhUQTogSXMgdGhlcmUgYSBy ZWFzb24gd2h5IHdlIGhhdmUgImVuZC1vZi1jYW5kaWRhdGVzIiByYXRoZXIgdGhhbiAibW9yZS1j YW5kaWRhdGVzLXBlbmRpbmciPyBJdCB3b3VsZCBzZWVtIHRvIGJlIGxlc3MgZGlzcnVwdGl2ZSBp ZiB0aGUgZmluYWwgU0RQIGxvb2tzICJub3JtYWwuIg0KSnVzdGluOiBXZSBtaWdodCBoYXZlIGEg ZmFpbHVyZSBjYXNlIHRoYXQgY2F1c2VzICJlbmQtb2YtY2FuZGlkYXRlcyIgdG8gYmUgc2VudCBi dXQgd2UgZGlkbid0IGtub3cgd2Ugd2VyZSBkb25lIHByaW9yIHRvIHRoZSBmYWlsdXJlLg0KRmxl bWluZzogSXMgdGhpcyBTRFAgb3Igbm90Pw0KRW1pbDogVGhpcyBpc24ndCBTRFAuIEl0J3Mgd2hh dCB3ZSBzZW5kLg0KRUtSOiBXaHkgaXNuJ3QgdGhpcyByZWFsIFNEUD8NCkVtaWw6IE9rYXksIHNv IHlvdSBjYW4gY29uc2lkZXIgdGhpcyBTRFAuIENhbmRpZGF0ZXMgY2FuIGdvIG91dC1vZi1iYW5k IGFsc28uDQpGbGVtaW5nOiBTbyB3ZSdyZSBkZWZpbmluZyAiZW5kLW9mLWNhbmRpYXRlcyIgaW4g U0RQPw0KRW1pbDogWWVzLg0KRmxlbWluZzogU2Vzc2lvbiBMZXZlbCBhdHRyaWJ1dGVzIGFyZSB0 aGUgc291cmNlIG9mIGFsbCBldmlsIGluIFNEUC4gRG9uJ3QgZG8gaXQuIEtlZXAgaXQgYSB0aGUg bWVkaWEgbGV2ZWwuDQpKb25hdGhhbjogVGhlIElDRSBhbGdvcml0aG1zIGRvIGhhdmUgY3Jvc3Mt bS1saW5lIGZ1bmN0aW9uYWxpdHkuIFdlIG1pZ2h0IG5vdCB3YW50IHRvIHRyZWF0IG0tbGluZXMg aW5kZXBlbmRlbnRseSwgc2luY2UgdGhlcmUgYXJlIHdob2xlLVNEUC1zZXNzaW9uIHNlbWFudGlj cyBhdCBwbGF5Lg0KKFNpZGV0cmFjayBhcmd1bWVudCBpbnZvbHZpbmcgZXh0cmVtZSBlc290ZXJp Y2EgcmVnYXJkaW5nIElDRSBwYWNpbmcgaGVyZSkuDQpKb25hdGhhbjogSSB2b3RlIGZvciBwdXR0 aW5nIG09ZW5kLW9mLWNhbmRpZGF0ZXMgYXQgdGhlIHNlc3Npb24gbGV2ZWwgbWVhbmluZyBhbGwg bWVkaWEgc2VjdGlvbnMgYXJlIGRvbmUuDQpFbWlsOiBJdCdzIGRpZmZpY3VsdCB0byBwdXQgaXQg aW4gdGhlcmUgZm9yIFJUQ1dFQi4NClRlZDogU3VyZSwgYnV0IHdlIHNob3VsZCBzYXkgUlRDV0VC IGFsd2F5cyBzZW5kcyBpdCBmb3IgZWFjaCBtZWRpYSBzZWN0aW9uLg0KRUtSOiBSaWdodCBub3cs IGtlZXAgaW4gbWluZCB0aGF0IHdlIGRvbid0IGhhdmUgZXZlbnRzIGZvciBpbmRpdmlkdWFsIG1l ZGlhIHN0cmVhbXMsIG9ubHkgZm9yIHRoZSB3aG9sZSBzZXNzaW9uLg0KVGVkOiBXZSBjYW4gZml4 IHRoYXQsIHJpZ2h0Pw0KRUtSOiBSaWdodC4NCkVLUjogT2gsIGNyYXAuIFRoaXMgd29uJ3Qgd29y ay4gKEkgZGlkbid0IHVuZGVyc3RhbmQgd2h5LCBidXQgSSBhc3N1bWUgRUtSIHdpbGwgcHJvcG9z ZSBhIHNvbHV0aW9uIHRvIHRoZSBsaXN0KQ0KMS4gSUNFIGxpdGUgYW5kIENhbmRpZGF0ZSBTaWdu YWxpbmcNCkpvbmF0aGFuOiBXZSB0aGluayB0aGlzIGp1c3Qgd29ya3MuDQpKdXN0aW46IFdlIHNo b3VsZCBpbmNsdWRlIHNvbWUgZXhhbXBsZXMgdG8gc2hvdyBob3cgdGhpcyB3b3Jrcy4NCjEuIE5l dyBDYW5kaWRhdGVzIGFmdGVyIElDRSBjb21wbGV0aW9uOiBEbyB3ZSBkbyB0aGlzIHdpdGggSUNF IHJlc3RhcnQ/IG9yIHNob3VsZCB3ZSBjb250aW51ZSB0byB0cmlja2xlPw0KSm9uYXRoYW46IEl0 IG5lZWRzIHRvIGJlIElDRSByZXN0YXJ0LiBJIG1pZ2h0IGhhdmUgYWxyZWFkeSByZWFsZWFzZWQg bXkgVFVSTiBzZXJ2ZXIuDQoxLiBTSVAgVXNhZ2UgZm9yIFRyaWNrbGUgSUNFDQpTSVAgYXBwbGlj YXRpb25zIHdpbGwgYWx3YXN5IGRvIGhhbGYtdHJpY2tsZSB1bmxlc3Mgb3RoZXJ3aXNlIGNvbmZp Z3VyZWQuDQpUcmlja2xlIGNhbmRpZGF0ZSB3aWxsIGJlIGRvbmUgd2l0aCBJTkZPIHBhY2thZ2Uu DQpKb25hdGhhbi9BZGFtOiBUaGlzIHNob3VsZCBiZSBhcHBsaWNhdGlvbi9zZHBmcmFnIG5vdCBh cHBsaWNhdGlvbi9zZHANCkZsZW1pbmc6IFdlIG5lZWQgdG8gYmUgY2FyZWZ1bCBoZXJlOyB3ZSdy ZSBkZWZpbmluZyB0d28gZGlmZmVyZW50IG1lYW5zIHRvIGNvbW11bmljYXRlIFNEUCBpbmZvcm1h dGlvbi4gVGhpcyBjYW4gZ28gd3JvbmcgcXVpY2tseS4NCkN1bGxlbjogQWx3YXlzIHRoaW5rIG9m IHRoaXMgYXMgYSBkaWZmLCBub3QgYW4gYWx0ZXJuYXRpdmUgbWVjaGFuaXNtLiBUaGF0IHNhdmVz IHlvdSBmcm9tIEZsZW1pbmcncyB0YXIgcGl0LiBBbHNvLCB3ZSBjb3VsZCBkZWZpbmUgdGhpcyBp biB0ZXJtcyBvZiBhIHBhdGNoIHN5bnRheC4NCkhhZHJpZWw6IEFyZSB5b3UgZ29pbmcgdG8gdGFs ayBhYm91dCB3aGVuIHRoaXMgY2FuIGhhcHBlbj8NCkVtaWw6IFllcyEgUmlnaHQgbm93ISAoY2hl Y2sgc2xpZGVzIGZvciBkaWFncmFtKQ0KQ2hyaXN0ZXI6IFdlJ3JlIGNoYW5naW5nIHRoZSBTRFAg Ym9keS4gRG8gd2UgY2hhbmdlIHRoZSBTRFAgdmVyc2lvbiBudW1iZXIgb3Igbm8/DQpDaHJpc3Rl cjogQWxzbywgd2UgbmVlZCB0byBlbnN1cmUgdGhhdCB0aGUgMTgwIGlzIHNlbnQgcmVsaWFibHku IE1ha2Ugc3VyZSB0aGUgSU5GTyBpcyBzZW50IG9ubHkgd2hlbiBpdCBjYW4gYmUgc2VudC4NClBh dWw6IFRoZXJlJ3MgYWxzbyB0aGUgaXNzdWUgb2Ygd2hlbiBJTkZPIGNhbiBiZSBzZW50Lg0KKEN1 bGxlbiBleHBsb3JlcyBmb3JraW5nLCB3aXRoIGF0IGxlYXN0IG9uZSBwcm9wb3NhbCB0byBpbmNs dWRlIHVmcmFnL3Bhc3N3ZCBpbiB0cmlja2xlIElDRSBmcmFnbWVudHMpDQpFbWlsOiBDdXJyZW50 bHksIHdlIHNheSB0aGF0IHRoZSBJQ0UgcmUtaW52aXRlIG9ubHkgZG9lcyB0aGUgZmlyc3QgY2hl Y2tsaXN0LCBhbmQgYWN0aXZhdGVzIHRoZSBvdGhlciBvbmVzIG9ubHkgYWZ0ZXIgaXQgY29tcGxl dGVzLiBJIHRoaW5rIHdlIGNhbiBpZ25vcmUgdGhhdC4NCkVLUjogTm8sIHlvdSdsbCBlbmQgdXAg d2l0aCBhIHN0b3JtIG9mIElDRSBjaGVja3MsIHdoaWNoIGlzbid0IHJlYWxseSB3aGF0IHdlIHdh bnQuIFdoYXQgeW91IHNob3VsZCBkbyBpczogaWYgeW91IGdldCBhIGNhbmRpYXRlLCBjaGVjayB0 byBzZWUgaWYgYW55dGhpbmcgaXMgcnVubmluZy4gSWYgbm90LCBzdGFydCB0aGUgZmlyc3QgY2hl Y2tsaXN0IHRvIHdoaWNoIHRoZSBjYW5kaWRhdGUgYmVsb25ncy4gSWYgeW91IGRvIHRoYXQsIHlv dSBiZWhhdmUgbXVjaCBtb3JlIGxpa2UgSUNFLCBhbmQgdGhpbmdzIGxpa2Ugc3VpY2lkZSBwYWNr ZXRzIGFyZSBtdWNoIG1vcmUgbGlrZWx5IHRvIHN1Y2NlZWQuDQpNYXJ0aW46IFRoYXQncyBvbmUg d2F5IHRvIGRvIGl0LiBPciB5b3UgY291bGQgY2hlY2sganVzdCBvbmUgcGFpciAob2YgdGhlIHNh bWUgZm91bmRhdGlvbikgZm9yIGVhY2ggY2hlY2tsaXN0Lg0KRUtSOiBUaGF0J3MgYSBiaWcgY2hh bmdlIGluIGJlaGF2aW9yLg0KTWFydGluOiBidXQgaXQgd291bGQgd29yayBiZXR0ZXIuDQpFS1I6 IEdpdmVuIHdoYXQgSSBleHBlY3QgdG8gc2VlIC0tIGFsbCBjYW5kaWRhdGVzIGFycml2aW5nIGlu IGEgZ3JvdXAgLS0geW91J3JlIGdvaW5nIHRvIHNlcmlhbGl6ZSBhbGwgdGhlIGNoZWNrcy4gVGhh dCdzIGhvdyBJQ0UgaXMgbWVhbnQgdG8gYmVoYXZlLg0KRW1pbDogRG9lc24ndCBpdCBhY3RpdmF0 ZSBhbGwgb2YgdGhlIGNoZWNrbGlzdHMgYWZ0ZXIgdGhlIGZpcnN0IG9uZSBjb21wbGV0ZXM/DQpF S1I6IE5vLg0KKEZ1cnRoZXIgY29udmVyc2F0aW9uIGFyb3VuZCBob3cgdGhpcyBpcyBhbGwgc3Vw cG9zZWQgdG8gYmVoYXZlLikNCkpvbmF0aGFuOiBUaGUgcHJpbmNpcGxlIHNob3VsZCBiZSB0aGF0 IHdoZW4gYSBjYW5kaWF0ZSBjb21lcyBpbiwgaWYgaXQgd291bGQgaGF2ZSBiZWVuIHVuZnJvemVu LCB0aGVuIHVuZnJlZXplIGl0LiBPdGhlcndpc2UsIGl0IHNob3VsZCBiZSBmcm96ZW4uDQpFS1I6 IFdlIHJlYWxseSBuZWVkIHRvIHNpdCBkb3duLCB3b3JrIHRocm91Z2ggdGhpcywgYW5kIHdyaXRl IGl0IGRvd24uDQpBY3Rpb24gaXRlbTogRUtSIGFuZCBNYXJ0aW4gdG8gcHJvcG9zZSB0ZXh0DQpK b25hdGhhbjogV2hhdCBoYXBwZW5zIGlmIHRoZSBvdGhlciBzaWRlIG5ldmVyIHNlbmRzIGVuZC1v Zi1jYW5kaWRhdGVzPw0KRW1pbDogVGhpcyBpc24ndCBhbnkgd29yc2UgdGhhbiBub3JtYWwgSUNF Lg0KQ3VsbGVuIChDaGFpcik6IFBsZWFzZSBzZW5kIHNvbWV0aGluZyB0byB0aGUgbGlzdCBkZXNj cmliaW5nIHRoZSBwcm9ibGVtIGFuZCBwcm9wb3NlZCBzb2x1dGlvbnMuDQpGbGVtaW5nOiBUaGVy ZSBhcmUgdHdvIHRoaW5ncyBoZXJlLiBPbmUgc2hvdWxkIHByb2JhYmx5IGdvIHRvIERJU1BBVENI Lg0K --bcaec518692cf1fbab04d6e62095-- From salvatore.loreto@ericsson.com Fri Mar 1 22:26: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 80D2221F90B3 for ; Fri, 1 Mar 2013 22:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.175 X-Spam-Level: X-Spam-Status: No, score=-106.175 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3ghq5XT5DtB for ; Fri, 1 Mar 2013 22:26:09 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7E64421F8D65 for ; Fri, 1 Mar 2013 22:26:01 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-76-51319b78baee Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B7.73.32353.87B91315; Sat, 2 Mar 2013 07:26:00 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Sat, 2 Mar 2013 07:25:59 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 22C5D2443 for ; Sat, 2 Mar 2013 08:26:00 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7DC6D54165 for ; Sat, 2 Mar 2013 08:25:57 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 303B9540A0 for ; Sat, 2 Mar 2013 08:25:57 +0200 (EET) Message-ID: <51319B77.6050900@ericsson.com> Date: Sat, 2 Mar 2013 08:25:59 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20130225182705.666.1653.idtracker@ietfa.amsl.com> 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+NgFlrELMWRmVeSWpSXmKPExsUyM+JvjW7FbMNAg9cLtC3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxu0Hl9kL9vJXzJns18C4iaeLkZNDQsBE4v3sb4wQtpjEhXvr 2boYuTiEBE4ySlxtv8IM4axnlNg9dxNU5gKjxIYzVxghnMOMEhPPH4VyzjBK/Hy1mA1kGK+A tsSE63NYQGwWARWJfd9PMoHYbAJmEs8fbmEGsUUFkiX+PTrCCFEvKHFy5hOwehEBYYmtr3rB 6oUFAiUOdd1nglrNLPF8x06wBZxAibl/H4PZzAK2EhfmXGeBsOUltr+dwwzxkZrE1XObwGwh AS2J3rOdTBMYRWYh2TcLSfssJO0LGJlXMbLnJmbmpJebb2IEhvPBLb8NdjBuui92iFGag0VJ nDfc9UKAkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsaNR030zVdz9S9oflq2hP1bnN6MHbK7 z4e8uRPPffqBdL+5uGe9a5/eoaUdCtWhBU5COf9mvg61W828ctlaMfOPn75e7E6/ePBl3MTP 3ze4zH958dx6s+hwwSi3whx7zy/6POtuWdufj3jwYtrrW46CEklz/x65XR62JHayK+NeTbE7 /84ISk1WYinOSDTUYi4qTgQAfT8okzUCAAA= Subject: Re: [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-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: Sat, 02 Mar 2013 06:26:18 -0000 On 2/28/13 8:32 PM, Martin Thomson wrote: > On 28 February 2013 09:45, Muthu Arul Mozhi Perumal (mperumal) > wrote: >> |Imagine that you are running Tr at 1 second, with a complete >> |transaction required before you do anything. Do you run 39 in >> |parallel with hundreds of checks, or do you not create a new >> |transaction when another is outstanding? >> >> Yes, that's what I had in mind -- don't generate a new request when a response is pending. A couple more constraints that could be useful: > I would expect that to be hard for a low Tr value. Overlapped > requests seem like a real possibility for Tr=1s. > >> - Don't generate a new consent freshness check when no traffic was sent over the last x sec (could save battery). > Be careful here that you don't create a failure mode whereby you lose > NAT bindings. I agree with Martin, you should be careful (I suggest to remove it) with this constrain as you also recommend (SHOULD) not to use ICE keep alive and RTP keepalive > >> - Don't generate a new liveness check if any traffic was received since the last liveness check. > Definitely. Mandatory even. > >> |We've discussed tightening the timers once the session is live. We've >> |also discussed tightening timers when the session is starting. Both >> |of which I would have expected to see in the document as proposed >> |solutions. >> >> Not sure I understood. Do you mean tightening the backoff timer? > The initial timer and the number of rounds before giving up. In fact, > I don't consider exponential back-off to be a useful feature for a > live flow. It's there to help avoid overwhelming unknown peers with > checks. Exponential back-off could go entirely. Hence the suggestion > for a constant interval. A constant interval also avoids having > transitory problems trigger unnecessarily harsh actions like ICE > restart. remove back-off seems a reasonable thing to do /Salvatore From salvatore.loreto@ericsson.com Fri Mar 1 22:34: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 7EB8C21F90C8 for ; Fri, 1 Mar 2013 22:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.177 X-Spam-Level: X-Spam-Status: No, score=-106.177 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFd89Jey1i8L for ; Fri, 1 Mar 2013 22:34:57 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 72EAE21F8E48 for ; Fri, 1 Mar 2013 22:34:57 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-07-51319d90f68c Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 87.04.32353.09D91315; Sat, 2 Mar 2013 07:34:56 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Sat, 2 Mar 2013 07:34:55 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 612E92443 for ; Sat, 2 Mar 2013 08:34:55 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1237254165 for ; Sat, 2 Mar 2013 08:34:53 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C1C58540A0 for ; Sat, 2 Mar 2013 08:34:52 +0200 (EET) Message-ID: <51319D8E.8030502@ericsson.com> Date: Sat, 2 Mar 2013 08:34:54 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B10B717@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA7EAB@US70UWXCHMBA04.zam.alcatel-lucent.com> <201303011558.r21FwfGb2830347@shell01.TheWorld.com> <5EB4AF68-2BB3-4243-B759-249065D8815F@lurchi.franken.de> <201303011957.r21JvLZG2849736@shell01.TheWorld.com> 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+NgFlrILMWRmVeSWpSXmKPExsUyM+Jvje6EuYaBBscnqVus/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujN5Gv4KfHBXbZzaxNzBOYO9i5OSQEDCRuLfrIDOELSZx4d56 ti5GLg4hgZOMEvfnNTFCOOsZJfa/u8wO4VxglNhy7wcTSIuQwGFGiU0LjCASZxglJvRPAEvw CmhLXFn+lQXEZhFQkdjWuh4sziZgJvH84RawfaICyRL/Hh1hhKgXlDg58wlYvYiAsMTWV71g 9cICuhILF3+Dumk3s8SUtxtZQRKcAq4SZ67dAitiFrCVuDDnOguELS+x/e0cqIfUJK6e28QM camWRO/ZTqYJjCKzkOybhaR9FpL2BYzMqxjZcxMzc9LLzTcxAoP54JbfBjsYN90XO8QozcGi JM4b7nohQEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjSZ7TLGcXTg8o69VbY37SJTbeWH9d 8wNWLqfKzm+zdin+4U5PV9ugGMAXJd9Vt/bfVuEnJhPFQiMtNjZbVF+ZyrSPbePOsOdf4nr0 Tf6qVX/NlrBX1uVnuV4XZML/QD/b9+MFmaqmJcdsj+xcoXpu77H/ajLMjd/v3OS0lFR71ezx 2a1m1wYlluKMREMt5qLiRADvyffrNAIAAA== Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Mar 2013 06:34:58 -0000 On 3/2/13 1:09 AM, Michael Tuexen wrote: > On Mar 1, 2013, at 8:57 PM, Dale R. Worley wrote: > >>> From: Michael Tuexen >>> As far as I understand it is easy (based on the first byte) to demux >>> DTLS from STUN and SRTP. SCTP is the only payload for DTLS, so there >>> is no need for demuxing. So no need to control SCTP ports. Or am I >>> missing something? >> Controlling port numbers is needed if SCTP is *not* encapsulated in >> DTLS and yet has to be distinguished from RTP et al. (That would >> become significant if encryption was applied to the bundle's packet >> stream as a whole, rather than to the constituent streams >> individually.) > Sorry, I don't understand what you are saying. Which document describes > the stack you are referring to? How would encryption be done for SCTP over UDP > over IP? Dale: can you clarify which scenario you have in mind when you say: "Controlling port numbers is needed if SCTP is *not* encapsulated in DTLS and yet has to be distinguished from RTP et al." is it a WebRTC usage or a usage for a different aim (maybe CLUE?) /Salvatore From bernard_aboba@hotmail.com Fri Mar 1 23:06: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 C700821F8DDC for ; Fri, 1 Mar 2013 23:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.36 X-Spam-Level: X-Spam-Status: No, score=-102.36 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sDudAgHMkfI for ; Fri, 1 Mar 2013 23:06:07 -0800 (PST) Received: from blu0-omc3-s10.blu0.hotmail.com (blu0-omc3-s10.blu0.hotmail.com [65.55.116.85]) by ietfa.amsl.com (Postfix) with ESMTP id AA2AE21F8DCB for ; Fri, 1 Mar 2013 23:06:07 -0800 (PST) Received: from BLU405-EAS402 ([65.55.116.73]) by blu0-omc3-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Mar 2013 23:06:07 -0800 X-EIP: [j7Dov//LC+M1u97f2lAJ54i2UvgTXpjF] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_96b88778-77d3-43a5-a7a3-d698983d8866_" MIME-Version: 1.0 To: "Dale R. Worley" , Michael Tuexen From: Bernard Aboba Date: Fri, 1 Mar 2013 23:06:04 -0800 X-OriginalArrivalTime: 02 Mar 2013 07:06:07.0680 (UTC) FILETIME=[697B5C00:01CE1714] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Mar 2013 07:06:09 -0000 --_96b88778-77d3-43a5-a7a3-d698983d8866_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Why would we want unsecured SCTP either for the WebRTC data channel or CLUE= signaling? Let's not invent problems when we have enough real ones. ________________________________ From: Dale R. Worley Sent: =E2=80=8E3/=E2=80=8E1/=E2=80=8E2013 11:58 AM To: Michael Tuexen Cc: rtcweb@ietf.org Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB > From: Michael Tuexen > As far as I understand it is easy (based on the first byte) to demux > DTLS from STUN and SRTP. SCTP is the only payload for DTLS=2C so there > is no need for demuxing. So no need to control SCTP ports. Or am I > missing something? Controlling port numbers is needed if SCTP is *not* encapsulated in DTLS and yet has to be distinguished from RTP et al. (That would become significant if encryption was applied to the bundle's packet stream as a whole=2C rather than to the constituent streams individually.) Dale _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_96b88778-77d3-43a5-a7a3-d698983d8866_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Why wou= ld we want unsecured SCTP either for the WebRTC data channel or CLUE signal= ing? Let's not invent problems when we have enough real ones.
From: Dale R. Worley
Sent: =E2=80=8E3/=E2=80=8E1/=E2=80=8E2013 11:58 AM
To: Michael Tuexen
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB

>=3B From: Michael Tuexen <=3BMichael.Tuexen@l= urchi.franken.de>=3B

>=3B As far as I understand it is easy (based on the first byte) to demux=
>=3B DTLS from STUN and SRTP. SCTP is the only payload for DTLS=2C so the= re
>=3B is no need for demuxing. So no need to control SCTP ports. Or am I >=3B missing something?

Controlling port numbers is needed if SCTP is *not* encapsulated in
DTLS and yet has to be distinguished from RTP et al. =3B (That would become significant if encryption was applied to the bundle's packet
stream as a whole=2C rather than to the constituent streams
individually.)

Dale
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.o= rg/mailman/listinfo/rtcweb
--_96b88778-77d3-43a5-a7a3-d698983d8866_-- From bernard_aboba@hotmail.com Fri Mar 1 23: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 94B2E21F8FA9 for ; Fri, 1 Mar 2013 23:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.365 X-Spam-Level: X-Spam-Status: No, score=-102.365 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkqgG916Zp8N for ; Fri, 1 Mar 2013 23:11:37 -0800 (PST) Received: from blu0-omc4-s37.blu0.hotmail.com (blu0-omc4-s37.blu0.hotmail.com [65.55.111.176]) by ietfa.amsl.com (Postfix) with ESMTP id D8F7D21F8F98 for ; Fri, 1 Mar 2013 23:11:36 -0800 (PST) Received: from BLU405-EAS167 ([65.55.111.135]) by blu0-omc4-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Mar 2013 23:11:36 -0800 X-EIP: [eIWQCzLdBaSk8ykEm5cjlq2Gs3zj6H83] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_11cea61c-9c7b-4a4a-b2b2-ab9b359bc8f2_" MIME-Version: 1.0 To: Christer Holmberg , Justin Uberti , "Ejzak, Richard P (Richard)" From: Bernard Aboba Date: Fri, 1 Mar 2013 23:11:33 -0800 X-OriginalArrivalTime: 02 Mar 2013 07:11:36.0123 (UTC) FILETIME=[2D3FC8B0:01CE1715] Cc: Richard Barnes , "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Mar 2013 07:11:38 -0000 --_11cea61c-9c7b-4a4a-b2b2-ab9b359bc8f2_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Plan B doesn't provide A/V mux so it may be desirable to add Plan A BUNDLE = as well (e.g.=2C later)=2C assuming that the mux issues can be worked out (= PT muxing breaks the stats API). ________________________________ From: Christer Holmberg Sent: =E2=80=8E3/=E2=80=8E1/=E2=80=8E2013 2:12 AM To: Justin Uberti=3B Ejzak=2C Richard P (Richard= ) Cc: Richard Barnes=3B rtcweb@ietf.org=3B rtcweb-chairs@tools.ietf.org Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB Hi=2C >BUNDLE and data muxing works for both "Plan A" and "Plan B". > >Recall that "Plan B" is muxing multiple media sources of the same type ove= r a single m=3D line=2C and BUNDLE then provides muxing of the audio=2C vid= eo=2C and data m=3D lines. My understanding (based on the Boston slides=2C because I haven't read Cull= en's plan draft yet) of "Plan B" is that it didn't include BUNDLE - or any = other multi-mediatype multiplexing negotiation mechanism - but only multipl= e SSRCs per m- line. Regards=2C Christer On Thu=2C Feb 28=2C 2013 at 3:10 PM=2C Ejzak=2C Richard P (Richard) wrote: Since multiplexing of the data channel with RTP media has been shown as a d= esirable feature of BUNDLE (and most of its variants)=2C I would suggest th= at this be treated as a significant advantage for BUNDLE (and similarly cap= able variants) over any proposal without it. Cullen's "Plan A" is preferre= d over Plan B precisely because it has an incremental muxing advantage. BR=2C Richard > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Wednesday=2C February 27=2C 2013 2:30 PM > To: Ted Hardie=3B rtcweb@ietf.org > Cc: Richard Barnes=3B rtcweb-chairs@tools.ietf.org > Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB > > > Hi=2C > > Does the Data Channel part (or some other part) of the agenda include > making a decision on whether it shall be possible to bundle the Data > Channel with the RTP media? > > Or=2C do we already have consensus that it shall be possible? > > Just to clarify=2C because I think it is important input for the MMUSIC > discussions on the actual mechanism. > > Regards=2C > > Christer > > > ________________________________________ > From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of > Ted Hardie [ted.ietf@gmail.com] > Sent: Wednesday=2C 27 February 2013 7:49 PM > To: rtcweb@ietf.org > Cc: Richard Barnes=3B rtcweb-chairs@tools.ietf.org > Subject: [rtcweb] DRAFT Agenda for RTCWEB > > The agenda below has been uploaded as an initial=2C draft agenda for the > group. Comments on the timing and balance are encouraged. > > thanks=2C > > Ted Hardie > > RTCWEB Draft Agenda > March 12=2C 2013 9:00 to 11:30 > > Administrivia (5 min) > > AD Message (5 min) > > Data Channel > - draft-jesup-rtcweb-data-protocol (20 min) > - draft-thomson-rtcweb-data (15 min) > - draft-marcon-rtcweb-data-channel-management (15 min) > - Discussion (30 min) > - Consensus call(s) (5 min) > > WGLC Issue resolution (30 min) > - draft-ietf-rtcweb-security > - draft-ietf-rtcweb-security-arch > - draft-ietf-rtcweb-overview > - draft-ietf-rtcweb-use-cases-and-requirements > > RTCP-XR (15 min ) > - draft-ietf-rtcweb-rtp-usage-06 > > FEC in RTCWEB (Call for interest) > - draft-mandyam-rtcweb-fecframe-00 (5 min) > > Mobile issues for RTCWEB (Call for review) > - http://tools.ietf.org/html/draft-reddy-rtcweb-mobile-00 (5 min) > > > March 14=2C 2013 9:00 to 11:30 > > JSEP > - draft-rtcweb-jsep (40 min) > - Discussion (30 min) > - Consensus call(s) (5) > > Video Codec 10:15 to 11:30 > 1. draft-alvestrand-rtcweb-vp8-01 (15 mins) 2. draft-burman-rtcweb- > h264-proposal-01+draft-dbenham-webrtcvideomti-01+draft-marjou-rtcweb- > video-codec-00 > (25 mins) > Discussion (30 minutes) > Call the question (5 minutes) > _______________________________________________ > 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 --_11cea61c-9c7b-4a4a-b2b2-ab9b359bc8f2_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Plan B = doesn't provide A/V mux so it may be desirable to add Plan A BUNDLE as well= (e.g.=2C later)=2C assuming that the mux issues can be worked out (PT muxi= ng breaks the stats API).
From: Christer Holmberg
Sent: =E2=80=8E3/=E2=80=8E1/=E2=80=8E2013 2:12 AM
To: Justin Uberti=3B Ejzak=2C Richard P (Ric= hard)
Cc: Richard Barnes=3B rtcweb@ietf.org=3B rtcweb-chairs@tools.ietf.org
Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB

Hi=2C

>=3BBUNDLE and data muxing works for both "=3BPlan A"=3B and &quo= t=3BPlan B"=3B. =3B
>=3B
>=3BRecall that "=3BPlan B"=3B is muxing multiple media sources o= f the same type over a single m=3D line=2C and BUNDLE then provides muxing = of the audio=2C video=2C and data m=3D lines.

My understanding (based on the Boston slides=2C because I haven't read Cull= en's plan draft yet) of "=3BPlan B"=3B is that it didn't include BU= NDLE - or any other multi-mediatype multiplexing negotiation mechanism - bu= t only multiple SSRCs per m- line.

Regards=2C

Christer



On Thu=2C Feb 28=2C 2013 at 3:10 PM=2C Ejzak=2C Richard P (Richard) <=3Br= ichard.ejzak@alcatel-lucent.com>=3B wrote:
Since multiplexing of the data channel with RTP media has been shown as a d= esirable feature of BUNDLE (and most of its variants)=2C I would suggest th= at this be treated as a significant advantage for BUNDLE (and similarly cap= able variants) over any proposal without it.  =3BCullen's "=3BPlan A"=3B is preferred over Plan B preci= sely because it has an incremental muxing advantage.

BR=2C Richard

>=3B -----Original Message-----
>=3B From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
>=3B Behalf Of Christer Holmberg
>=3B Sent: Wednesday=2C February 27=2C 2013 2:30 PM
>=3B To: Ted Hardie=3B rtcweb@ietf.org
>=3B Cc: Richard Barnes=3B rtcweb-chairs@tools.ietf.org
>=3B Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB
>=3B
>=3B
>=3B Hi=2C
>=3B
>=3B Does the Data Channel part (or some other part) of the agenda includ= e
>=3B making a decision on whether it shall be possible to bundle the Data=
>=3B Channel with the RTP media?
>=3B
>=3B Or=2C do we already have consensus that it shall be possible?
>=3B
>=3B Just to clarify=2C because I think it is important input for the MMU= SIC
>=3B discussions on the actual mechanism.
>=3B
>=3B Regards=2C
>=3B
>=3B Christer
>=3B
>=3B
>=3B ________________________________________
>=3B From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of=
>=3B Ted Hardie [ted.ietf@gmail.com]
>=3B Sent: Wednesday=2C 27 February 2013 7:49 PM
>=3B To: rtcweb@ietf.org
>=3B Cc: Richard Barnes=3B rtcweb-chairs@tools.ietf.org
>=3B Subject: [rtcweb] DRAFT Agenda for RTCWEB
>=3B
>=3B The agenda below has been uploaded as an initial=2C draft agenda for= the
>=3B group.  =3BComments on the timing and balance are encouraged. >=3B
>=3B thanks=2C
>=3B
>=3B Ted Hardie
>=3B
>=3B RTCWEB Draft Agenda
>=3B March 12=2C 2013 9:00 to 11:30
>=3B
>=3B Administrivia (5 min)
>=3B
>=3B AD Message (5 min)
>=3B
>=3B Data Channel
>=3B  =3B- draft-jesup-rtcweb-data-protocol (20 min)
>=3B  =3B- draft-thomson-rtcweb-data (15 min)
>=3B  =3B- draft-marcon-rtcweb-data-channel-management (15 min)
>=3B  =3B- Discussion (30 min)
>=3B  =3B- Consensus call(s) (5 min)
>=3B
>=3B WGLC Issue resolution (30 min)
>=3B - draft-ietf-rtcweb-security
>=3B - draft-ietf-rtcweb-security-arch
>=3B - draft-ietf-rtcweb-overview
>=3B - draft-ietf-rtcweb-use-cases-and-requirements
>=3B
>=3B RTCP-XR (15 min )
>=3B - draft-ietf-rtcweb-rtp-usage-06
>=3B
>=3B FEC in RTCWEB  =3B(Call for interest)
>=3B - draft-mandyam-rtcweb-fecframe-00 (5 min)
>=3B
>=3B Mobile issues for RTCWEB (Call for review)
>=3B - http://tools.ietf.org/html/draft-reddy-rtcweb-mobile-00 (5 min)
>=3B
>=3B
>=3B March 14=2C 2013 9:00 to 11:30
>=3B
>=3B JSEP
>=3B - draft-rtcweb-jsep (40 min)
>=3B - Discussion (30 min)
>=3B - Consensus call(s) (5)
>=3B
>=3B Video Codec  =3B  =3B  =3B  =3B  =3B  =3B &n= bsp=3B  =3B  =3B  =3B  =3B 10:15 to 11:30
>=3B 1. draft-alvestrand-rtcweb-vp8-01 (15 mins) 2. draft-burman-rtcweb-<= br> >=3B h264-proposal-01+=3Bdraft-dbenham-webrtcvideomti-01+=3Bdraft-m= arjou-rtcweb-
>=3B video-codec-00
>=3B (25 mins)
>=3B  =3B  =3B  =3B Discussion (30 minutes)
>=3B  =3B  =3B  =3B Call the question (5 minutes)
>=3B _______________________________________________
>=3B rtcweb mailing list
>=3B rtcweb@ietf.org
>=3B https://www= .ietf.org/mailman/listinfo/rtcweb
>=3B _______________________________________________
>=3B rtcweb mailing list
>=3B rtcweb@ietf.org
>=3B https://www= .ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.o= rg/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.o= rg/mailman/listinfo/rtcweb
--_11cea61c-9c7b-4a4a-b2b2-ab9b359bc8f2_-- From harald@alvestrand.no Sat Mar 2 01:57: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 F1F9A21F8FEA for ; Sat, 2 Mar 2013 01:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.444 X-Spam-Level: X-Spam-Status: No, score=-111.444 tagged_above=-999 required=5 tests=[AWL=1.154, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HtHN1ksoo2i for ; Sat, 2 Mar 2013 01:57:56 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1732421F8FFA for ; Sat, 2 Mar 2013 01:57:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 40F9439E0FE; Sat, 2 Mar 2013 10:57:55 +0100 (CET) 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 4tnauKb5VkJT; Sat, 2 Mar 2013 10:57:52 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:b136:6ef7:2913:b4cd] (unknown [IPv6:2001:470:de0a:27:b136:6ef7:2913:b4cd]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7D98739E0A7; Sat, 2 Mar 2013 10:57:52 +0100 (CET) Message-ID: <5131CD20.8060201@alvestrand.no> Date: Sat, 02 Mar 2013 10:57:52 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Gaelle Martin-Cocher References: <5130B9C3.3010404@ericsson.com> <92D0D52F3A63344CA478CF12DB0648AA26529174@XMB106BCNC.rim.net> In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AA26529174@XMB106BCNC.rim.net> Content-Type: multipart/alternative; boundary="------------070805080201080207090603" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Input to Video Codec Selection X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Mar 2013 09:57:59 -0000 This is a multi-part message in MIME format. --------------070805080201080207090603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 03/01/2013 11:21 PM, Gaelle Martin-Cocher wrote: > Dear All, > > Further to Magnus email, while I assume there might not be "something new" to learn at the meeting, I believe the below requested clarifications on existing information would be useful. Implementers should clearly know which license they can pick or get when it comes to VP8 and by which groups. I believe answers in advance of the meeting would help the discussion at the meeting. > > Questions 1 & 2: > It is assumed that in the case of choosing VP8, RTCWeb would reference the informational RFC 6386. Yes, that is the intent. > Q1: Is there an intent to move that RFC to the standard track at a point in time? No. I don't personally see any benefit in doing so at this time. > Q2: Would that change the rule of "who" is obliged to make an IPR declaration? Speaking with my IETF-amateur-lawyer hat on (and as a former chair of the IPR WG): No, it does not change the rule. The rule depends on whether the technology in question is discussed in the IETF, not on the nature of the contribution. RFC 3979 section 6.1.2 refers to "Contribution", the definition of that term in RFC 3979 section 1 letter j makes it completely explicit that RFC Editor Contributions are covered by the term "Contribution". > > Question 3: > The IPR disclosure was made on the draft 2 of draft-bankoski-vp8-bitstream-02" as per https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=6386 > Draft 3 and onward contains the copyright license and the additional IP rights grant. > Q3: Is the initial IPR disclosure still valid? Yes. RFC 3979 section 6.2.1. The IPR disclosure required pursuant to section 6.1.1 must be made as soon as reasonably possible after the Contribution is published in an Internet Draft unless the required disclosure is already on file. For example, if the Contribution is an update to a Contribution for which an IPR disclosure has already been made and the applicability of the disclosure is not changed by the new Contribution, then no new disclosure is required. > > Question 4: > The informational RFC 6386 contains the decoder code and some piece of encoder code. > Though the IP rights grant mentioned in the RFC is offered against: > > "This implementation" means the copyrightable works distributed by > Google as part of the WebM Project." > > Q4: As such the IP rights grant does not seem to apply to the RFC itself or to an implementation of the code contained in the RFC. Should that be corrected or is that the intent? Speaking with WEBM hat on: There are two grants - the grant of license to copyrighted works, and the grant of license to patented technology. Software license: http://www.webmproject.org/license/software/ - classical 3-clause BSD. Patent license 1: http://www.webmproject.org/license/bitstream/ - covers any implementation that produces or consumes VP8 bitstreams. Patent license 2: http://www.webmproject.org/license/additional/ - covers usage of the implementation. > > > Question 5: > The additional IP grant is applied to a particular implementation (namely the WebM VP8 code) without modifications. > Any derivative work either: > - produced from the reference code in WebM (that is a possible optimized version of it); or > - produced from the RFC text or the code provided within the RFC (while not using the WebM code) > does not have the benefit of the additional IP grant. > In other words a conformant implementation does not necessarily have the benefit of the additional IP grant. > I am not confident that the VP8 code can be used "as is" for certain platforms. I would think that the code might need some modification to provide the desired performance. In other words, it should be clear that those implementers would not necessarily receive the benefit of that grant. > If the answer to Q3 is negative, then there is no IP license statement at all that applies to a "conformant implementation of the RFC" (aka a derivative work). > If the answer to Q3 is positive, it is not clear how to reconcile the declaration inside the RFC and the declaration that is attached to the the RFC draft for implementers that would not modify the code. > Q5: Can this be clarified or confirmed? All 3 of the pages referred to above permit the production of derivative works. Quoth: - bitstream: " ... license to make, have made, use, offer to sell, sell, import, and otherwise transfer implementations of this specification" (whether derived from the example code or not) - copyright: ".... Redistribution and use in source and binary forms, with or without modification, are permitted provided that.." - patent: "... patent license to make, have made, use, offer to sell, sell, import, transfer, and otherwise run, modify and propagate the contents of this implementation" I believe there should be no issue here; modification is permitted. > > > Question 6: > The IPR disclosure in IETF is different than the IPR statement made in MPEG (see document sent by Harald earlier). > Q6: the differences in license statement and IP grant referring to WebM code are rather confusing. Can it be clarified which license, copyright, grant are provided for RFC 6386? The statement we made in MPEG was crafted to be as similar to others' statements made in MPEG as possible, in order to respect MPEG's legal language traditions - which in turn should minimize the need for clarification of what was granted when discussing with people used to the MPEG language tradition. We believe that the statement made in MPEG is wholly within the statements made on the WEBM website - all permissions implied by the statement in MPEG should also be permitted by the statements on the WEBM website. We haven't tried to analyze whether there are cases where someone can do something within the permissions granted on the WEBM website that would not be permitted under the MPEG statement - the MPEG statement was aimed to allow the document to progress within MPEG; people who want to read the > > > > In conclusion, before advancing this draft, or considering it as a candidate for RTCWeb, consistency and clarity should be ensured between the IPR grant associated with the IETF draft, the IPR grants within the IETF draft document itself, the IPR grant given for MPEG, and any IPR grant given in connection with the WEBM project for this same work. Otherwise, the IPR status of the work that is undertaken is indeterminate, and likely will not produce a result that will be useful. Speaking with my Google hat on: We will of course seek maximum clarity of the statements we make. Unfortunately, different organizations have different traditions on how these things should be worded, and we cannot guarantee that there can't be differences in interpretation. However, I (speaking with my personal hat on) think the current statements on the WEBM website are pretty clear. I have yet to see a concrete scenario where there would be any reasonable doubt about whether usage of VP8 is permitted by Google or not - and in all cases except for those that fall within the defensive suspension exceptions, it is permitted. Hope that helps! Harald --------------070805080201080207090603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

On 03/01/2013 11:21 PM, Gaelle Martin-Cocher wrote:
Dear All,

Further to Magnus email, while I assume there might not be "something new" to learn at the meeting, I believe the below requested clarifications on existing information would be useful.  Implementers should clearly know which license they can pick or get when it comes to VP8 and by which groups.  I believe answers in advance of the meeting would help the discussion at the meeting.

Questions 1 & 2:
It is assumed that in  the case of choosing VP8, RTCWeb would reference  the informational RFC 6386.
Yes, that is the intent.
Q1: Is there an intent to move that RFC to the standard track at a point in time?
No. I don't personally see any benefit in doing so at this time.
Q2: Would that change the rule of "who" is obliged to make an IPR declaration?
Speaking with my IETF-amateur-lawyer hat on (and as a former chair of the IPR WG): No, it does not change the rule. The rule depends on whether the technology in question is discussed in the IETF, not on the nature of the contribution. RFC 3979 section 6.1.2 refers to "Contribution", the definition of that term in RFC 3979 section 1 letter j makes it completely explicit that RFC Editor Contributions are covered by the term "Contribution".

Question 3:
The IPR disclosure was made on the draft 2 of draft-bankoski-vp8-bitstream-02" as per https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=6386
Draft 3 and onward contains the copyright license and the additional IP rights grant. 
Q3: Is the initial IPR disclosure still valid?
Yes. RFC 3979 section 6.2.1.

   The IPR disclosure required pursuant to section 6.1.1 must be made as
   soon as reasonably possible after the Contribution is published in an
   Internet Draft unless the required disclosure is already on file.
   For example, if the Contribution is an update to a Contribution for
   which an IPR disclosure has already been made and the applicability
   of the disclosure is not changed by the new Contribution, then no new
   disclosure is required.


Question 4:
The informational RFC 6386 contains the decoder code and some piece of encoder code.
Though the IP rights grant mentioned in the RFC is offered against:

   "This implementation" means the copyrightable works distributed by
   Google as part of the WebM Project."

Q4: As such the  IP rights grant does not seem to apply to the RFC itself or to an implementation of the code contained in the RFC.  Should that be corrected or is that the intent?
Speaking with WEBM hat on:

There are two grants - the grant of license to copyrighted works, and the grant of license to patented technology.

Software license: http://www.webmproject.org/license/software/ - classical 3-clause BSD.
Patent license 1: http://www.webmproject.org/license/bitstream/ - covers any implementation that produces or consumes VP8 bitstreams.
Patent license 2: http://www.webmproject.org/license/additional/ - covers usage of the implementation.



Question 5:
The additional IP grant is applied to a particular implementation (namely the WebM VP8 code) without modifications. 
Any derivative work either:
- produced from the reference code in WebM (that is a possible optimized version of it); or
- produced from the RFC text or the code provided within the RFC (while not using the WebM code)
does not have the benefit of the additional IP grant. 
In other words a conformant implementation does not necessarily have the benefit of the additional IP grant.
I am not confident that the VP8 code can be used "as is" for certain platforms. I would think that the code might need some modification to provide the desired performance. In other words, it should be clear that those implementers would not necessarily receive the benefit of that grant.
If the answer to Q3 is negative, then there is no IP license statement at all that applies to a "conformant implementation of the RFC" (aka a derivative work).
If the answer to Q3 is positive, it is not clear  how to reconcile the declaration inside the RFC and the declaration that is attached to the the RFC draft for implementers that would not modify the code.
Q5: Can this be clarified or confirmed?
All 3 of the pages referred to above permit the production of derivative works. Quoth:

- bitstream: " ... license to make, have made, use, offer to sell, sell, import, and otherwise transfer implementations of this specification" (whether derived from the example code or not)
- copyright: ".... Redistribution and use in source and binary forms, with or without modification, are permitted provided that.."
- patent: "... patent license to make, have made, use, offer to sell, sell, import, transfer, and otherwise run, modify and propagate the contents of this implementation"

I believe there should be no issue here; modification is permitted.
 


Question 6:
The IPR disclosure in IETF is different than the IPR statement made in MPEG (see document sent by Harald earlier). 
Q6: the differences in license statement and IP grant referring to WebM code are rather confusing. Can it be clarified which license, copyright, grant are provided for RFC 6386?
The statement we made in MPEG was crafted to be as similar to others' statements made in MPEG as possible, in order to respect MPEG's legal language traditions - which in turn should minimize the need for clarification of what was granted when discussing with people used to the MPEG language tradition.

We believe that the statement made in MPEG is wholly within the statements made on the WEBM website - all permissions implied by the statement in MPEG should also be permitted by the statements on the WEBM website. We haven't tried to analyze whether there are cases where someone can do something within the permissions granted on the WEBM website that would not be permitted under the MPEG statement - the MPEG statement was aimed to allow the document to progress within MPEG; people who want to read the 



In conclusion, before advancing this draft, or considering it as a candidate for RTCWeb,  consistency and clarity should be ensured between the IPR grant associated with the IETF draft, the IPR grants within the IETF draft document itself, the IPR grant given for MPEG, and any IPR grant given in connection with the WEBM project for this same work.  Otherwise, the IPR status of the work that is undertaken is indeterminate, and likely will not produce a result that will be useful.

Speaking with my Google hat on:

We will of course seek maximum clarity of the statements we make. Unfortunately, different organizations have different traditions on how these things should be worded, and we cannot guarantee that there can't be differences in interpretation.

However, I (speaking with my personal hat on) think the current statements on the WEBM website are pretty clear. I have yet to see a concrete scenario where there would be any reasonable doubt about whether usage of VP8 is permitted by Google or not - and in all cases except for those that fall within the defensive suspension exceptions, it is permitted.

Hope that helps!

           Harald

--------------070805080201080207090603-- From harald@alvestrand.no Sat Mar 2 02: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 D67AB21F90EB for ; Sat, 2 Mar 2013 02:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.474 X-Spam-Level: X-Spam-Status: No, score=-110.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRzdFVYhJ-5k for ; Sat, 2 Mar 2013 02:27:05 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3078021F90C1 for ; Sat, 2 Mar 2013 02:27:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0607E39E0FE for ; Sat, 2 Mar 2013 11:27:03 +0100 (CET) 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 UdjvkykQcGzm for ; Sat, 2 Mar 2013 11:27:01 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:b136:6ef7:2913:b4cd] (unknown [IPv6:2001:470:de0a:27:b136:6ef7:2913:b4cd]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2590D39E0A7 for ; Sat, 2 Mar 2013 11:27:01 +0100 (CET) Message-ID: <5131D3F4.4040501@alvestrand.no> Date: Sat, 02 Mar 2013 11:27:00 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B10B717@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA7EAB@US70UWXCHMBA04.zam.alcatel-lucent.com> <201303011558.r21FwfGb2830347@shell01.TheWorld.com> <112a01ce16ae$a1720d90$e45628b0$@cisco.com> In-Reply-To: <112a01ce16ae$a1720d90$e45628b0$@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Mar 2013 10:27:06 -0000 On 03/01/2013 07:57 PM, Dan Wing wrote: >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >> Of Dale R. Worley >> Sent: Friday, March 01, 2013 7:59 AM >> To: Ejzak, Richard P (Richard) >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB >> >>> From: "Ejzak, Richard P (Richard)" >>> >>> Since multiplexing of the data channel with RTP media has been shown >>> as a desirable feature of BUNDLE (and most of its variants), I would >>> suggest that this be treated as a significant advantage for BUNDLE >>> (and similarly capable variants) over any proposal without it. >>> Cullen's "Plan A" is preferred over Plan B precisely because it has an >>> incremental muxing advantage. >> As far as I can tell from my analysis >> (http://tools.ietf.org/html/draft-worley-sdp-bundle-04#section-8), >> SCTP-over-DTLS can be demuxed from RTP and STUN quite easily. (This >> comes from RFC 5764 section 5.1.2.) And SCTP can be demuxed from the >> rest as long as you control the range of SCTP ports used. (And since >> the ports aren't actually to route the packets to the receiver (the >> underlying UDP does that), you have freedom in choosing SCTP ports.) >> >> So I don't see anything blocking Plan A as compared to Plan B. Of >> course, we have to *do* a bundle technique, but we've got a large >> library of possibilities now and can look at the fundamental design >> questions in context. > The analysis should also examine impact of port-based QoS on > multiplexing data over the same port as audio. Even audio and > video often prefer different drop precedence. I know the general > consensus is to just supply more bandwidth, yet we consume all > available bandwidth much like disk space, memory, and CPU/GPU > cycles. > A reason for the particular way BUNDLE is designed is so that it permits you to bundle all the audio separately from all the video if that's your desire. It just doesn't force you to do so. Once we have BUNDLE in place and the m-line thing settled, we can return to the issue of what the default operational mode should be. From stefan.lk.hakansson@ericsson.com Sun Mar 3 00:44: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 B9BBD21F862E for ; Sun, 3 Mar 2013 00:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.907 X-Spam-Level: X-Spam-Status: No, score=-5.907 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60MTF2lj7aTb for ; Sun, 3 Mar 2013 00:44:58 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1D36921F8626 for ; Sun, 3 Mar 2013 00:44:50 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-ea-51330d815d55 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E1.0B.32353.18D03315; Sun, 3 Mar 2013 09:44:50 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0318.004; Sun, 3 Mar 2013 09:44:49 +0100 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Magnus Westerlund Thread-Topic: [rtcweb] Input to Video Codec Selection Thread-Index: AQHOFohSX+FIz7sRDUakjRmzQELT9piTpd7w Date: Sun, 3 Mar 2013 08:44:48 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B0BA4DF@ESESSMB209.ericsson.se> References: <5130B9C3.3010404@ericsson.com> In-Reply-To: <5130B9C3.3010404@ericsson.com> 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+NgFjrILMWRmVeSWpSXmKPExsUyM+JvjW4Tr3GgwcyfzBZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY9oO3oK7/BX//y9kbWB8z9PFyMkhIWAiceLDM2YIW0ziwr31 bF2MXBxCAocYJb582MgK4SxilFh46RATSBWbQKDE1n0L2EBsEQEziYcT9oPZzALqEncWn2MH sYWBpk7oPMcEUWMqcfbUI6h6I4m3l9YCDeXgYBFQkTiyNxskzCvgLfHy0CJGEFtIQFvi+M92 sDGcAjoSxyYdZQGxGYGO+35qDRPEKnGJW0/mM0EcLSCxZM95qAdEJV4+/scKYStK7DzbzgxR rydxY+oUqDO1JZYtfM0MsVdQ4uTMJywTGMVmIRk7C0nLLCQts5C0LGBkWcXInpuYmZNebr6J ERgNB7f8NtjBuOm+2CFGaQ4WJXHecNcLAUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYW4y2 C+mJn3vrOJX9m+tHJYOtctkMUy8vjeUqj98g1np7vX70ucXymxtXbTmhkO/eIuq1msmeXfL2 /79XD06cs6FQ80eZ2n22lYfs2W3f9BnfCjlkKpxwsc262uWhbmz13+ypJU8bXjJce75sM5NX Xbnra/mz+hPm8lxVlmG/3XH1rO7Bzi1FSizFGYmGWsxFxYkAWcORA1QCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Input to Video Codec Selection X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Mar 2013 08:44:59 -0000 I can understand the logic behind not wanting any new input before the meet= ing, but at the same time we did postpone this discussion one meeting cycle= on request by Serge [1]. In his request Serge stated that "Google understa= nds that concerns have been raised within the IETF RTCWEB WG in regards to = VP8 IPR." and "We hereby commit to addressing this by the next IETF meeting= in Orlando. Our proposal will address prevalent IPR issues." I have seen no such input yet, and if no new input is allowed, it seems lik= e we will have the same discussion we postponed last time (all inputs look = more or less unchanged to me). Is this the plan? Have the chairs reached ou= t to Google to check the status (perhaps the IPR related things did encount= er some delay, but will be ready shortly after the meeting)? Stefan [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg05698.html -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Magnus Westerlund Sent: den 1 mars 2013 15:23 Cc: rtcweb@ietf.org Subject: [rtcweb] Input to Video Codec Selection WG, I hope everyone, especially Google, now have provided whatever input they h= ave into the Video Codec discussion and selection. It is important that eve= ryone has the possibility to evaluate the input in good time prior to the m= eeting. It is especially important if one might require legal or other supp= ort when evaluating the proposals or additional information, which might ap= ply for IPR, as an example. To be extremely blunt, we don't want anyone revealing new input material du= ring the presentations in Orlando. These presentations is only intended to = provide a summary of the most important aspects from the proponents side. The RTCWEB WG chairs Magnus Westerlund Ted Hardie Cullen Jennings _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@iii.ca Sun Mar 3 07:38: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 D832821F8704 for ; Sun, 3 Mar 2013 07:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcC9rlhgJAdG for ; Sun, 3 Mar 2013 07:38:27 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 6876B21F86F4 for ; Sun, 3 Mar 2013 07:38:27 -0800 (PST) Received: from [10.71.228.241] (unknown [208.180.59.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8CBFD509B6; Sun, 3 Mar 2013 10:38:26 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Cullen Jennings In-Reply-To: <5131CD20.8060201@alvestrand.no> Date: Sun, 3 Mar 2013 09:38:25 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9D4FB1F0-2A13-4335-9B90-ADB4D6F37AB6@iii.ca> References: <5130B9C3.3010404@ericsson.com> <92D0D52F3A63344CA478CF12DB0648AA26529174@XMB106BCNC.rim.net> <5131CD20.8060201@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1499) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Input to Video Codec Selection X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Mar 2013 15:38:29 -0000 Harald, The IPR disclosure says RF but the grant at webm pages is not RF. It = includes=20 If You or your agent or exclusive licensee institute or order or agree = to the institution of patent litigation against any entity (including a = cross-claim or counterclaim in a lawsuit) alleging that any = implementation of this specification constitutes direct or contributory = patent infringement, or inducement of patent infringement, then any = rights granted to You under the License for this specification shall = terminate as of the date such litigation is filed. So there seems to be some inconsistency here or perhaps the IPR grand on = IETF page was just much broader than the one on webm page. Can you help = make sure the IPR disclosure is correct? I also had the idea that IETF = preferred if Google actually disclosed patents that google control as = wells other that are known on VP8 in the disclosure. Cullen=20 On Mar 2, 2013, at 3:57 AM, Harald Alvestrand = wrote: >=20 > On 03/01/2013 11:21 PM, Gaelle Martin-Cocher wrote: >> Dear All, >>=20 >> Further to Magnus email, while I assume there might not be "something = new" to learn at the meeting, I believe the below requested = clarifications on existing information would be useful. Implementers = should clearly know which license they can pick or get when it comes to = VP8 and by which groups. I believe answers in advance of the meeting = would help the discussion at the meeting. >>=20 >> Questions 1 & 2: >> It is assumed that in the case of choosing VP8, RTCWeb would = reference the informational RFC 6386. >>=20 > Yes, that is the intent. >> Q1: Is there an intent to move that RFC to the standard track at a = point in time? > No. I don't personally see any benefit in doing so at this time. >> Q2: Would that change the rule of "who" is obliged to make an IPR = declaration? > Speaking with my IETF-amateur-lawyer hat on (and as a former chair of = the IPR WG): No, it does not change the rule. The rule depends on = whether the technology in question is discussed in the IETF, not on the = nature of the contribution. RFC 3979 section 6.1.2 refers to = "Contribution", the definition of that term in RFC 3979 section 1 letter = j makes it completely explicit that RFC Editor Contributions are covered = by the term "Contribution". >>=20 >> Question 3: >> The IPR disclosure was made on the draft 2 of = draft-bankoski-vp8-bitstream-02" as per=20 >> = https://datatracker.ietf.org/ipr/search/?option=3Drfc_search&rfc_search=3D= 6386 >>=20 >> Draft 3 and onward contains the copyright license and the additional = IP rights grant.=20 >> Q3: Is the initial IPR disclosure still valid?=20 >>=20 > Yes. RFC 3979 section 6.2.1. >=20 > The IPR disclosure required pursuant to section 6.1.1 must be made = as > soon as reasonably possible after the Contribution is published in = an > Internet Draft unless the required disclosure is already on file. > For example, if the Contribution is an update to a Contribution for > which an IPR disclosure has already been made and the applicability > of the disclosure is not changed by the new Contribution, then no = new > disclosure is required. >=20 >>=20 >> Question 4: >> The informational RFC 6386 contains the decoder code and some piece = of encoder code. >> Though the IP rights grant mentioned in the RFC is offered against: >>=20 >> "This implementation" means the copyrightable works distributed by >> Google as part of the WebM Project." >>=20 >> Q4: As such the IP rights grant does not seem to apply to the RFC = itself or to an implementation of the code contained in the RFC. Should = that be corrected or is that the intent? >>=20 > Speaking with WEBM hat on: >=20 > There are two grants - the grant of license to copyrighted works, and = the grant of license to patented technology. >=20 > Software license: http://www.webmproject.org/license/software/ - = classical 3-clause BSD. > Patent license 1: http://www.webmproject.org/license/bitstream/ - = covers any implementation that produces or consumes VP8 bitstreams. > Patent license 2: http://www.webmproject.org/license/additional/ - = covers usage of the implementation. >=20 >>=20 >>=20 >> Question 5: >> The additional IP grant is applied to a particular implementation = (namely the WebM VP8 code) without modifications.=20 >> Any derivative work either: >> - produced from the reference code in WebM (that is a possible = optimized version of it); or >> - produced from the RFC text or the code provided within the RFC = (while not using the WebM code) >> does not have the benefit of the additional IP grant.=20 >> In other words a conformant implementation does not necessarily have = the benefit of the additional IP grant. >> I am not confident that the VP8 code can be used "as is" for certain = platforms. I would think that the code might need some modification to = provide the desired performance. In other words, it should be clear that = those implementers would not necessarily receive the benefit of that = grant. >> If the answer to Q3 is negative, then there is no IP license = statement at all that applies to a "conformant implementation of the = RFC" (aka a derivative work). >> If the answer to Q3 is positive, it is not clear how to reconcile = the declaration inside the RFC and the declaration that is attached to = the the RFC draft for implementers that would not modify the code. >> Q5: Can this be clarified or confirmed? >>=20 > All 3 of the pages referred to above permit the production of = derivative works. Quoth: >=20 > - bitstream: " ... license to make, have made, use, offer to sell, = sell, import, and otherwise transfer implementations of this = specification" (whether derived from the example code or not) > - copyright: ".... Redistribution and use in source and binary forms, = with or without modification, are permitted provided that.." > - patent: "... patent license to make, have made, use, offer to sell, = sell, import, transfer, and otherwise run, modify and propagate = the contents of this implementation" >=20 > I believe there should be no issue here; modification is permitted. >> =20 >>=20 >>=20 >> Question 6: >> The IPR disclosure in IETF is different than the IPR statement made = in MPEG (see document sent by Harald earlier).=20 >> Q6: the differences in license statement and IP grant referring to = WebM code are rather confusing. Can it be clarified which license, = copyright, grant are provided for RFC 6386? >>=20 > The statement we made in MPEG was crafted to be as similar to others' = statements made in MPEG as possible, in order to respect MPEG's legal = language traditions - which in turn should minimize the need for = clarification of what was granted when discussing with people used = to the MPEG language tradition. >=20 > We believe that the statement made in MPEG is wholly within the = statements made on the WEBM website - all permissions implied by the = statement in MPEG should also be permitted by the statements on the WEBM = website. We haven't tried to analyze whether there are cases where = someone can do something within the permissions granted on the WEBM = website that would not be permitted under the MPEG statement - the MPEG = statement was aimed to allow the document to progress within MPEG; = people who want to read the=20 >>=20 >>=20 >>=20 >> In conclusion, before advancing this draft, or considering it as a = candidate for RTCWeb, consistency and clarity should be ensured between = the IPR grant associated with the IETF draft, the IPR grants within the = IETF draft document itself, the IPR grant given for MPEG, and any IPR = grant given in connection with the WEBM project for this same work. = Otherwise, the IPR status of the work that is undertaken is = indeterminate, and likely will not produce a result that will be useful. = =20 >>=20 >=20 > Speaking with my Google hat on: >=20 > We will of course seek maximum clarity of the statements we make. = Unfortunately, different organizations have different traditions on = how these things should be worded, and we cannot guarantee that there = can't be differences in interpretation. >=20 > However, I (speaking with my personal hat on) think the current = statements on the WEBM website are pretty clear. I have yet to see a = concrete scenario where there would be any reasonable doubt about = whether usage of VP8 is permitted by Google or not - and in all = cases except for those that fall within the defensive suspension = exceptions, it is permitted. >=20 > Hope that helps! >=20 > Harald >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From stewe@stewe.org Sun Mar 3 08:39: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 E33F321F8740 for ; Sun, 3 Mar 2013 08:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=2.500, BAYES_00=-2.599, GB_I_LETTER=-2, 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 CmpEwv7A5ynD for ; Sun, 3 Mar 2013 08:39:47 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9445A21F873D for ; Sun, 3 Mar 2013 08:39:44 -0800 (PST) Received: from mail144-tx2-R.bigfish.com (10.9.14.231) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.23; Sun, 3 Mar 2013 16:39:43 +0000 Received: from mail144-tx2 (localhost [127.0.0.1]) by mail144-tx2-R.bigfish.com (Postfix) with ESMTP id C6454160221; Sun, 3 Mar 2013 16:39:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT005.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: PS-28(zzbb2dI98dI9371I1432I41c5N14ffIzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL17326ah8275dhz2fh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1155h) Received-SPF: pass (mail144-tx2: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT005.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail144-tx2 (localhost.localdomain [127.0.0.1]) by mail144-tx2 (MessageSwitch) id 1362328741732677_20915; Sun, 3 Mar 2013 16:39:01 +0000 (UTC) Received: from TX2EHSMHS038.bigfish.com (unknown [10.9.14.234]) by mail144-tx2.bigfish.com (Postfix) with ESMTP id A58293C014F; Sun, 3 Mar 2013 16:39:01 +0000 (UTC) Received: from BL2PRD0710HT005.namprd07.prod.outlook.com (157.56.240.133) by TX2EHSMHS038.bigfish.com (10.9.99.138) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 3 Mar 2013 16:38:59 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.145]) by BL2PRD0710HT005.namprd07.prod.outlook.com ([10.255.102.40]) with mapi id 14.16.0275.006; Sun, 3 Mar 2013 16:38:59 +0000 From: Stephan Wenger To: Cullen Jennings , Harald Alvestrand Thread-Topic: [rtcweb] Input to Video Codec Selection Thread-Index: AQHOFohSMw+r3b1CrUOO2rY1Kr1TypiRaTwAgADCggCAAfF6gP//ismA Date: Sun, 3 Mar 2013 16:38:58 +0000 Message-ID: In-Reply-To: <9D4FB1F0-2A13-4335-9B90-ADB4D6F37AB6@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.5] Content-Type: text/plain; charset="us-ascii" Content-ID: <24E970FB12A89E459DD9C913EE19EC4C@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Input to Video Codec Selection X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Mar 2013 16:39:49 -0000 Hi all, On 3.3.2013 07:38 , "Cullen Jennings" wrote: > >Harald, > >The IPR disclosure says RF but the grant at webm pages is not RF. It >includes=20 > > If You or your agent or exclusive licensee institute or order or agree >to the institution of patent litigation against any entity (including a >cross-claim or counterclaim in a lawsuit) alleging that any >implementation of this specification constitutes direct or contributory >patent infringement, or inducement of patent infringement, then any >rights granted to You under the License for this specification shall >terminate as of the date such litigation is filed. If we were going into the business of analyzing reciprocity clauses in the IETF, we would have so much fun. Well, Cisco guys probably less so... :-) =20 I don't understand that discussion. I didn't understand Gaelle's inquiry for clarification on which license terms apply, either. If there are two licenses (or equivalent) being offered for approximately the same thing, a potential licensor can choose the one most advantageous to him/her. (At a car dealership, if a car is offered for cash value, at certain leasing terms, and at certain financing terms, the customer can choose dealer has to honor all three. Subject to conditions spelled out to either of the three. Same here.) > >So there seems to be some inconsistency here or perhaps the IPR grand on >IETF page was just much broader than the one on webm page. Can you help >make sure the IPR disclosure is correct? I also had the idea that IETF >preferred if Google actually disclosed patents that google control as >wells other that are known on VP8 in the disclosure. That would indeed be helpful. Even more helpful would be a patent landscape analysis, but I can certainly understand why no such analysis has been provided. > >Cullen=20 > > > >On Mar 2, 2013, at 3:57 AM, Harald Alvestrand >wrote: > >>=20 >> On 03/01/2013 11:21 PM, Gaelle Martin-Cocher wrote: >>> Dear All, >>>=20 >>> Further to Magnus email, while I assume there might not be "something >>>new" to learn at the meeting, I believe the below requested >>>clarifications on existing information would be useful. Implementers >>>should clearly know which license they can pick or get when it comes to >>>VP8 and by which groups. I believe answers in advance of the meeting >>>would help the discussion at the meeting. >>>=20 >>> Questions 1 & 2: >>> It is assumed that in the case of choosing VP8, RTCWeb would >>>reference the informational RFC 6386. >>>=20 >> Yes, that is the intent. >>> Q1: Is there an intent to move that RFC to the standard track at a >>>point in time? >> No. I don't personally see any benefit in doing so at this time. >>> Q2: Would that change the rule of "who" is obliged to make an IPR >>>declaration? >> Speaking with my IETF-amateur-lawyer hat on (and as a former chair of >>the IPR WG): No, it does not change the rule. The rule depends on >>whether the technology in question is discussed in the IETF, not on the >>nature of the contribution. RFC 3979 section 6.1.2 refers to >>"Contribution", the definition of that term in RFC 3979 section 1 letter >>j makes it completely explicit that RFC Editor Contributions are covered >>by the term "Contribution". >>>=20 >>> Question 3: >>> The IPR disclosure was made on the draft 2 of >>>draft-bankoski-vp8-bitstream-02" as per >>>=20 >>>https://datatracker.ietf.org/ipr/search/?option=3Drfc_search&rfc_search= =3D63 >>>86 >>>=20 >>> Draft 3 and onward contains the copyright license and the additional >>>IP rights grant. >>> Q3: Is the initial IPR disclosure still valid? >>>=20 >> Yes. RFC 3979 section 6.2.1. >>=20 >> The IPR disclosure required pursuant to section 6.1.1 must be made as >> soon as reasonably possible after the Contribution is published in an >> Internet Draft unless the required disclosure is already on file. >> For example, if the Contribution is an update to a Contribution for >> which an IPR disclosure has already been made and the applicability >> of the disclosure is not changed by the new Contribution, then no new >> disclosure is required. >>=20 >>>=20 >>> Question 4: >>> The informational RFC 6386 contains the decoder code and some piece of >>>encoder code. >>> Though the IP rights grant mentioned in the RFC is offered against: >>>=20 >>> "This implementation" means the copyrightable works distributed by >>> Google as part of the WebM Project." >>>=20 >>> Q4: As such the IP rights grant does not seem to apply to the RFC >>>itself or to an implementation of the code contained in the RFC. >>>Should that be corrected or is that the intent? >>>=20 >> Speaking with WEBM hat on: >>=20 >> There are two grants - the grant of license to copyrighted works, and >>the grant of license to patented technology. >>=20 >> Software license: http://www.webmproject.org/license/software/ - >>classical 3-clause BSD. >> Patent license 1: http://www.webmproject.org/license/bitstream/ - >>covers any implementation that produces or consumes VP8 bitstreams. >> Patent license 2: http://www.webmproject.org/license/additional/ - >>covers usage of the implementation. >>=20 >>>=20 >>>=20 >>> Question 5: >>> The additional IP grant is applied to a particular implementation >>>(namely the WebM VP8 code) without modifications. >>> Any derivative work either: >>> - produced from the reference code in WebM (that is a possible >>>optimized version of it); or >>> - produced from the RFC text or the code provided within the RFC >>>(while not using the WebM code) >>> does not have the benefit of the additional IP grant. >>> In other words a conformant implementation does not necessarily have >>>the benefit of the additional IP grant. >>> I am not confident that the VP8 code can be used "as is" for certain >>>platforms. I would think that the code might need some modification to >>>provide the desired performance. In other words, it should be clear >>>that those implementers would not necessarily receive the benefit of >>>that grant. >>> If the answer to Q3 is negative, then there is no IP license statement >>>at all that applies to a "conformant implementation of the RFC" (aka a >>>derivative work). >>> If the answer to Q3 is positive, it is not clear how to reconcile the >>>declaration inside the RFC and the declaration that is attached to the >>>the RFC draft for implementers that would not modify the code. >>> Q5: Can this be clarified or confirmed? >>>=20 >> All 3 of the pages referred to above permit the production of >>derivative works. Quoth: >>=20 >> - bitstream: " ... license to make, have made, use, offer to sell, >>sell, import, and otherwise transfer implementations of this >>specification" (whether derived from the example code or not) >> - copyright: ".... Redistribution and use in source and binary forms, >>with or without modification, are permitted provided that.." >> - patent: "... patent license to make, have made, use, offer to sell, >>sell, import, transfer, and otherwise run, modify and propagate >>the contents of this implementation" >>=20 >> I believe there should be no issue here; modification is permitted. >>> =20 >>>=20 >>>=20 >>> Question 6: >>> The IPR disclosure in IETF is different than the IPR statement made in >>>MPEG (see document sent by Harald earlier). >>> Q6: the differences in license statement and IP grant referring to >>>WebM code are rather confusing. Can it be clarified which license, >>>copyright, grant are provided for RFC 6386? >>>=20 >> The statement we made in MPEG was crafted to be as similar to others' >>statements made in MPEG as possible, in order to respect MPEG's legal >>language traditions - which in turn should minimize the need for >>clarification of what was granted when discussing with people used >>to the MPEG language tradition. >>=20 >> We believe that the statement made in MPEG is wholly within the >>statements made on the WEBM website - all permissions implied by the >>statement in MPEG should also be permitted by the statements on the WEBM >>website. We haven't tried to analyze whether there are cases where >>someone can do something within the permissions granted on the WEBM >>website that would not be permitted under the MPEG statement - the MPEG >>statement was aimed to allow the document to progress within MPEG; >>people who want to read the >>>=20 >>>=20 >>>=20 >>> In conclusion, before advancing this draft, or considering it as a >>>candidate for RTCWeb, consistency and clarity should be ensured >>>between the IPR grant associated with the IETF draft, the IPR grants >>>within the IETF draft document itself, the IPR grant given for MPEG, >>>and any IPR grant given in connection with the WEBM project for this >>>same work. Otherwise, the IPR status of the work that is undertaken is >>>indeterminate, and likely will not produce a result that will be >>>useful. =20 >>>=20 >>=20 >> Speaking with my Google hat on: >>=20 >> We will of course seek maximum clarity of the statements we make. >>Unfortunately, different organizations have different traditions on >>how these things should be worded, and we cannot guarantee that there >>can't be differences in interpretation. >>=20 >> However, I (speaking with my personal hat on) think the current >>statements on the WEBM website are pretty clear. I have yet to see a >>concrete scenario where there would be any reasonable doubt about >>whether usage of VP8 is permitted by Google or not - and in all >>cases except for those that fall within the defensive suspension >>exceptions, it is permitted. >>=20 >> Hope that helps! >>=20 >> Harald >>=20 >> _______________________________________________ >> 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 stewe@stewe.org Sun Mar 3 08: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 D0C8421F8727 for ; Sun, 3 Mar 2013 08:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.376 X-Spam-Level: X-Spam-Status: No, score=-6.376 tagged_above=-999 required=5 tests=[AWL=2.222, BAYES_00=-2.599, GB_I_LETTER=-2, 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 guBVIQ6PyplS for ; Sun, 3 Mar 2013 08:52:28 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDE121F8715 for ; Sun, 3 Mar 2013 08:52:28 -0800 (PST) Received: from mail150-co9-R.bigfish.com (10.236.132.227) by CO9EHSOBE026.bigfish.com (10.236.130.89) with Microsoft SMTP Server id 14.1.225.23; Sun, 3 Mar 2013 16:52:27 +0000 Received: from mail150-co9 (localhost [127.0.0.1]) by mail150-co9-R.bigfish.com (Postfix) with ESMTP id 8563F360267; Sun, 3 Mar 2013 16:52:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT001.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: PS-27(zzbb2dI98dI9371Ic85eh41c5N1447Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz8275ch1033IL17326ah8275dh18c673h8275bhz2fh2a8h668h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1155h) Received-SPF: pass (mail150-co9: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT001.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail150-co9 (localhost.localdomain [127.0.0.1]) by mail150-co9 (MessageSwitch) id 1362329544743822_17441; Sun, 3 Mar 2013 16:52:24 +0000 (UTC) Received: from CO9EHSMHS010.bigfish.com (unknown [10.236.132.226]) by mail150-co9.bigfish.com (Postfix) with ESMTP id A65B832008C; Sun, 3 Mar 2013 16:52:24 +0000 (UTC) Received: from BL2PRD0710HT001.namprd07.prod.outlook.com (157.56.240.133) by CO9EHSMHS010.bigfish.com (10.236.130.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 3 Mar 2013 16:52:22 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.145]) by BL2PRD0710HT001.namprd07.prod.outlook.com ([10.255.102.36]) with mapi id 14.16.0275.006; Sun, 3 Mar 2013 16:52:21 +0000 From: Stephan Wenger To: Harald Alvestrand , Gaelle Martin-Cocher Thread-Topic: [rtcweb] Input to Video Codec Selection Thread-Index: AQHOFohSMw+r3b1CrUOO2rY1Kr1TypiRaTwAgADCggCAAX//gA== Date: Sun, 3 Mar 2013 16:52:20 +0000 Message-ID: In-Reply-To: <5131CD20.8060201@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.4] Content-Type: multipart/alternative; boundary="_000_CD58BCAF95F6Cstewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Input to Video Codec Selection X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Mar 2013 16:52:29 -0000 --_000_CD58BCAF95F6Cstewesteweorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Harald, Thanks for these candid answers. I have a few comments, marked in blue and= with StW: Stephan From: Harald Alvestrand > Date: Saturday, 2 March, 2013 01:57 To: Gaelle Martin-Cocher > Cc: "rtcweb@ietf.org" > Subject: Re: [rtcweb] Input to Video Codec Selection On 03/01/2013 11:21 PM, Gaelle Martin-Cocher wrote: Dear All, Further to Magnus email, while I assume there might not be "something new" = to learn at the meeting, I believe the below requested clarifications on ex= isting information would be useful. Implementers should clearly know which= license they can pick or get when it comes to VP8 and by which groups. I = believe answers in advance of the meeting would help the discussion at the = meeting. Questions 1 & 2: It is assumed that in the case of choosing VP8, RTCWeb would reference th= e informational RFC 6386. Yes, that is the intent. Q1: Is there an intent to move that RFC to the standard track at a point in= time? No. I don't personally see any benefit in doing so at this time. Q2: Would that change the rule of "who" is obliged to make an IPR declarati= on? Speaking with my IETF-amateur-lawyer hat on (and as a former chair of the I= PR WG): No, it does not change the rule. The rule depends on whether the te= chnology in question is discussed in the IETF, not on the nature of the con= tribution. RFC 3979 section 6.1.2 refers to "Contribution", the definition = of that term in RFC 3979 section 1 letter j makes it completely explicit th= at RFC Editor Contributions are covered by the term "Contribution". StW; While this answer IMO correctly interprets the language of BCP79, you = answer the question IMO to directly. Therefore, the answer is somewhat mis= leading in it misses to mention an important point: The main (sole?) purpose of an IETF WG is to facilitate consensus building,= which necessarily involves more than one party, and those contributing to = the discussions (belonging to more than one party) have a disclosure obliga= tion. To which extent there is real discussion and consensus building depe= ndent from draft to draft and WG to WG, but there is at least some. ISE submissions, like the draft that lead to RFC 6386, OTOH, are almost alw= ays NOT the result of a multiparty consensus building process. Quite commo= nly, they involved only a small authors' group, often from the same company= . That's the case here. No technical community input from IETF participan= ts was received in an IETF context, no WG consensus was required, and the I= ESG "no conflict" statement is also no indication of IETF consensus. Insofar, almost inevitably, the disclosure obligations for an ISE submissio= n are different in practice. In this case, it appears that only the author= s (and perhaps the IESG members=97I'm not clear on this point) had a disclo= sure obligation. Which they fulfilled. /StW Question 3: The IPR disclosure was made on the draft 2 of draft-bankoski-vp8-bitstream-= 02" as per https://datatracker.ietf.org/ipr/search/?option=3Drfc_search&rfc= _search=3D6386 Draft 3 and onward contains the copyright license and the additional IP rig= hts grant. Q3: Is the initial IPR disclosure still valid? Yes. RFC 3979 section 6.2.1. The IPR disclosure required pursuant to section 6.1.1 must be made as soon as reasonably possible after the Contribution is published in an Internet Draft unless the required disclosure is already on file. For example, if the Contribution is an update to a Contribution for which an IPR disclosure has already been made and the applicability of the disclosure is not changed by the new Contribution, then no new disclosure is required. Question 4: The informational RFC 6386 contains the decoder code and some piece of enco= der code. Though the IP rights grant mentioned in the RFC is offered against: "This implementation" means the copyrightable works distributed by Google as part of the WebM Project." Q4: As such the IP rights grant does not seem to apply to the RFC itself o= r to an implementation of the code contained in the RFC. Should that be co= rrected or is that the intent? Speaking with WEBM hat on: There are two grants - the grant of license to copyrighted works, and the g= rant of license to patented technology. Software license: http://www.webmproject.org/license/software/ - classical = 3-clause BSD. Patent license 1: http://www.webmproject.org/license/bitstream/ - covers an= y implementation that produces or consumes VP8 bitstreams. Patent license 2: http://www.webmproject.org/license/additional/ - covers u= sage of the implementation. Question 5: The additional IP grant is applied to a particular implementation (namely t= he WebM VP8 code) without modifications. Any derivative work either: - produced from the reference code in WebM (that is a possible optimized ve= rsion of it); or - produced from the RFC text or the code provided within the RFC (while not= using the WebM code) does not have the benefit of the additional IP grant. In other words a conformant implementation does not necessarily have the be= nefit of the additional IP grant. I am not confident that the VP8 code can be used "as is" for certain platfo= rms. I would think that the code might need some modification to provide th= e desired performance. In other words, it should be clear that those implem= enters would not necessarily receive the benefit of that grant. If the answer to Q3 is negative, then there is no IP license statement at a= ll that applies to a "conformant implementation of the RFC" (aka a derivati= ve work). If the answer to Q3 is positive, it is not clear how to reconcile the decl= aration inside the RFC and the declaration that is attached to the the RFC = draft for implementers that would not modify the code. Q5: Can this be clarified or confirmed? All 3 of the pages referred to above permit the production of derivative wo= rks. Quoth: - bitstream: " ... license to make, have made, use, offer to sell, sell, im= port, and otherwise transfer implementations of this specification" (whethe= r derived from the example code or not) - copyright: ".... Redistribution and use in source and binary forms, with = or without modification, are permitted provided that.." - patent: "... patent license to make, have made, use, offer to sell, sell,= import, transfer, and otherwise run, modify and propagate the contents of = this implementation" I believe there should be no issue here; modification is permitted. Question 6: The IPR disclosure in IETF is different than the IPR statement made in MPEG= (see document sent by Harald earlier). Q6: the differences in license statement and IP grant referring to WebM cod= e are rather confusing. Can it be clarified which license, copyright, grant= are provided for RFC 6386? The statement we made in MPEG was crafted to be as similar to others' state= ments made in MPEG as possible, in order to respect MPEG's legal language t= raditions - which in turn should minimize the need for clarification of wha= t was granted when discussing with people used to the MPEG language traditi= on. We believe that the statement made in MPEG is wholly within the statements = made on the WEBM website - all permissions implied by the statement in MPEG= should also be permitted by the statements on the WEBM website. We haven't= tried to analyze whether there are cases where someone can do something wi= thin the permissions granted on the WEBM website that would not be permitte= d under the MPEG statement - the MPEG statement was aimed to allow the docu= ment to progress within MPEG; people who want to read the In conclusion, before advancing this draft, or considering it as a candidat= e for RTCWeb, consistency and clarity should be ensured between the IPR gr= ant associated with the IETF draft, the IPR grants within the IETF draft do= cument itself, the IPR grant given for MPEG, and any IPR grant given in con= nection with the WEBM project for this same work. Otherwise, the IPR statu= s of the work that is undertaken is indeterminate, and likely will not prod= uce a result that will be useful. Speaking with my Google hat on: We will of course seek maximum clarity of the statements we make. Unfortuna= tely, different organizations have different traditions on how these things= should be worded, and we cannot guarantee that there can't be differences = in interpretation. However, I (speaking with my personal hat on) think the current statements = on the WEBM website are pretty clear. I have yet to see a concrete scenario= where there would be any reasonable doubt about whether usage of VP8 is pe= rmitted by Google or not - and in all cases except for those that fall with= in the defensive suspension exceptions, it is permitted. Hope that helps! Harald --_000_CD58BCAF95F6Cstewesteweorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1C05DF8978B2224281C289B5CA6CBA89@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Harald,
Thanks for these candid answers.  I have = a few comments, marked in blue and with StW:
Stephan

From: Harald Alvestrand <harald@alvestrand.no>
Date: Saturday, 2 March, 2013 01:57=
To: Gaelle Martin-Cocher <gmartincocher@blackberry.com&= gt;
Cc: "rtcweb@ietf.org" <= rtcweb@ietf.org>
Subject: Re: [rtcweb] Input to Vide= o Codec Selection


On 03/01/2013 11:21 PM, Gaelle Martin-Cocher wrote:
Dear All,

Further to Magnus email, while I assume there might not be "something =
new" to learn at the meeting, I believe the below requested clarificat=
ions on existing information would be useful.  Implementers should clearly =
know which license they can pick or get when it comes to VP8 and by which g=
roups.  I believe answers in advance of the meeting would help the discussi=
on at the meeting.

Questions 1 & 2:
It is assumed that in  the case of choosing VP8, RTCWeb would reference  th=
e informational RFC 6386.
Yes, that is the intent.
Q1: Is there an intent to move that RFC to the standard trac=
k at a point in time?
No. I don't personally see any benefit in doing so at this time.
Q2: Would that change the rule of "who" is obliged=
 to make an IPR declaration?
Speaking with my IETF-amateur-lawyer hat on (and as a former chair of the I= PR WG): No, it does not change the rule. The rule depends on whether the te= chnology in question is discussed in the IETF, not on the nature of the con= tribution. RFC 3979 section 6.1.2 refers to "Contribution", the definition of that term in RFC 397= 9 section 1 letter j makes it completely explicit that RFC Editor Contribut= ions are covered by the term "Contribution".

StW; While this answer IMO correctly interpret= s the language of BCP79, you answer the question IMO to directly.  The= refore, the answer is somewhat misleading in it misses to mention an import= ant point: 

The main (sole?) purpose of an IETF WG is to f= acilitate consensus building, which necessarily involves more than one part= y, and those contributing to the discussions (belonging to more than one pa= rty) have a disclosure obligation.  To which extent there is real discussion and consensus building depe= ndent from draft to draft and WG to WG, but there is at least some.<= /div>

ISE submissions, like the draft that lead to R= FC 6386, OTOH, are almost always NOT the result of a multiparty consensus b= uilding process.  Quite commonly, they involved only a small authors' = group, often from the same company.  That's the case here.  No technical community input from IETF participants w= as received in an IETF context, no WG consensus was required, and the IESG = "no conflict" statement is also no indication of IETF consensus.<= /font>

Insofar, almost inevitably, the disclosure obl= igations for an ISE submission are different in practice.  In this cas= e, it appears that only the authors (and perhaps the IESG members=97I'm not= clear on this point) had a disclosure obligation.  Which they fulfilled.
/StW

Question 3:
The IPR disclosure was made on the draft 2 of draft-bankoski-vp8-bitstream-=
02" as per https:/=
/datatracker.ietf.org/ipr/search/?option=3Drfc_search&rfc_search=3D6386=

Draft 3 and onward contains the copyright license and the additional IP rig=
hts grant.=20
Q3: Is the initial IPR disclosure still valid?
Yes. RFC 3979 section 6.2.1.

   The IPR disclosure required pursuant to section 6.1.1 must be = made as
   soon as reasonably possible after the Contribution is publishe= d in an
   Internet Draft unless the required disclosure is already on fi= le.
   For example, if the Contribution is an update to a Contributio= n for
   which an IPR disclosure has already been made and the applicab= ility
   of the disclosure is not changed by the new Contribution, then= no new
   disclosure is required.

Question 4:
The informational RFC 6386 contains the decoder code and some piece of enco=
der code.
Though the IP rights grant mentioned in the RFC is offered against:

   "This implementation" means the copyrightable works distribute=
d by
   Google as part of the WebM Project."

Q4: As such the  IP rights grant does not seem to apply to the RFC itself o=
r to an implementation of the code contained in the RFC.  Should that be co=
rrected or is that the intent?
Speaking with WEBM hat on:

There are two grants - the grant of license to copyrighted works, and the g= rant of license to patented technology.

Software license: = http://www.webmproject.org/license/software/ - classical 3-clause BSD.<= br> Patent license 1: http://www.webmproject.org/license/bitstream/ - covers any implementat= ion that produces or consumes VP8 bitstreams.
Patent license 2: http://www.webmproject.org/license/additional/ - covers usage of the = implementation.

Question 5:
The additional IP grant is applied to a particular implementation (namely t=
he WebM VP8 code) without modifications.=20
Any derivative work either:
- produced from the reference code in WebM (that is a possible optimized ve=
rsion of it); or
- produced from the RFC text or the code provided within the RFC (while not=
 using the WebM code)
does not have the benefit of the additional IP grant.=20
In other words a conformant implementation does not necessarily have the be=
nefit of the additional IP grant.
I am not confident that the VP8 code can be used "as is" for cert=
ain platforms. I would think that the code might need some modification to =
provide the desired performance. In other words, it should be clear that th=
ose implementers would not necessarily receive the benefit of that grant.
If the answer to Q3 is negative, then there is no IP license statement at a=
ll that applies to a "conformant implementation of the RFC" (aka =
a derivative work).
If the answer to Q3 is positive, it is not clear  how to reconcile the decl=
aration inside the RFC and the declaration that is attached to the the RFC =
draft for implementers that would not modify the code.
Q5: Can this be clarified or confirmed?
All 3 of the pages referred to above permit the production of derivative wo= rks. Quoth:

- bitstream: " ... license to make, have made, use, offer to sell, sell, import, and otherwise= transfer implementations of this specification" (whether derived from= the example code or not)
- copyright: ".... Redistribution and use in source and binary forms, with or without modification, are perm= itted provided that.."
- patent: "... patent license to make, have made, use, offer to sell, sell, import, transfer, an= d otherwise run, modify and propagate the contents of this implementation&q= uot;

I believe there should be no issue here; modification is permitted.
 
Question 6:
The IPR disclosure in IETF is different than the IPR statement made in MPEG=
 (see document sent by Harald earlier).=20
Q6: the differences in license statement and IP grant referring to WebM cod=
e are rather confusing. Can it be clarified which license, copyright, grant=
 are provided for RFC 6386?
The statement we made in MPEG was crafted to be as similar to others' state= ments made in MPEG as possible, in order to respect MPEG's legal language t= raditions - which in turn should minimize the need for clarification of wha= t was granted when discussing with people used to the MPEG language tradition.

We believe that the statement made in MPEG is wholly within the statements = made on the WEBM website - all permissions implied by the statement in MPEG= should also be permitted by the statements on the WEBM website. We haven't= tried to analyze whether there are cases where someone can do something within the permissions granted on= the WEBM website that would not be permitted under the MPEG statement - th= e MPEG statement was aimed to allow the document to progress within MPEG; p= eople who want to read the 

In conclusion, before advancing this draft, or considering it as a candidat=
e for RTCWeb,  consistency and clarity should be ensured between the IPR gr=
ant associated with the IETF draft, the IPR grants within the IETF draft do=
cument itself, the IPR grant given for MPEG, and any IPR grant given in con=
nection with the WEBM project for this same work.  Otherwise, the IPR statu=
s of the work that is undertaken is indeterminate, and likely will not prod=
uce a result that will be useful.

Speaking with my Google hat on:

We will of course seek maximum clarity of the statements we make. Unfortuna= tely, different organizations have different traditions on how these things= should be worded, and we cannot guarantee that there can't be differences = in interpretation.

However, I (speaking with my personal hat on) think the current statements = on the WEBM website are pretty clear. I have yet to see a concrete scenario= where there would be any reasonable doubt about whether usage of VP8 is pe= rmitted by Google or not - and in all cases except for those that fall within the defensive suspension excep= tions, it is permitted.

Hope that helps!

           Harald

 --_000_CD58BCAF95F6Cstewesteweorg_-- From harald@alvestrand.no Sun Mar 3 09:20: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 42D6E21F84CA for ; Sun, 3 Mar 2013 09:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.477 X-Spam-Level: X-Spam-Status: No, score=-110.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 ZfrugCpJR86t for ; Sun, 3 Mar 2013 09:20:09 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6912121F84C8 for ; Sun, 3 Mar 2013 09:20:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1AB0439E172; Sun, 3 Mar 2013 18:20:08 +0100 (CET) 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 Ig8O5QKJAHSx; Sun, 3 Mar 2013 18:20:06 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:393a:5892:b68a:9264] (unknown [IPv6:2001:470:de0a:27:393a:5892:b68a:9264]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7B2E139E170; Sun, 3 Mar 2013 18:20:06 +0100 (CET) Message-ID: <51338645.9010306@alvestrand.no> Date: Sun, 03 Mar 2013 18:20:05 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Cullen Jennings References: <5130B9C3.3010404@ericsson.com> <92D0D52F3A63344CA478CF12DB0648AA26529174@XMB106BCNC.rim.net> <5131CD20.8060201@alvestrand.no> <9D4FB1F0-2A13-4335-9B90-ADB4D6F37AB6@iii.ca> In-Reply-To: <9D4FB1F0-2A13-4335-9B90-ADB4D6F37AB6@iii.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Input to Video Codec Selection X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Mar 2013 17:20:10 -0000 On 03/03/2013 04:38 PM, Cullen Jennings wrote: > Harald, > > The IPR disclosure says RF but the grant at webm pages is not RF. It includes > > If You or your agent or exclusive licensee institute or order or agree to the institution of patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that any implementation of this specification constitutes direct or contributory patent infringement, or inducement of patent infringement, then any rights granted to You under the License for this specification shall terminate as of the date such litigation is filed. > > So there seems to be some inconsistency here or perhaps the IPR grand on IETF page was just much broader than the one on webm page. Can you help make sure the IPR disclosure is correct? I also had the idea that IETF preferred if Google actually disclosed patents that google control as wells other that are known on VP8 in the disclosure. Cullen, in what way is the WEBM page grant not an RF grant (or more precisely: "under a royalty-free and otherwise reasonable and non-discriminatory license", which is the precise language used in RFC 3979 section 6.5)? I can't remember the last time I saw a royalty-free license commitment without a defensive suspension clause. Re patent numbers: I've heard Scott Bradner claim that a defensive-suspension filing is not covered by the "blanket license" rule in section 6.4.3 of RFC 3979, but the first time I heard that was at the RTCWEB meeting, and I objected to the claim - I was listening most carefully when we wrote RFC 3979 in the IPR working group; my belief at the time we filed this statement was that since it's a blanket RF license, it did not require listing specific patent numbers. (As you know, listing specific patent numbers can be a chore requiring a fair amount of human judgment = lawyer and engineer time. I believe the IETF IPR rules were intended to be biased towards making life easy for people willing to do RF licenses; I'd certainly not want to make life for those people harder. From harald@alvestrand.no Mon Mar 4 02:43: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 91B5721F8999 for ; Mon, 4 Mar 2013 02:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.598 X-Spam-Level: X-Spam-Status: No, score=-112.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 85k1J8W8e2-f for ; Mon, 4 Mar 2013 02:43:50 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 82C7521F897F for ; Mon, 4 Mar 2013 02:43:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0383739E0FD; Mon, 4 Mar 2013 11:43:48 +0100 (CET) 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 LwbhcU7d37LN; Mon, 4 Mar 2013 11:43:46 +0100 (CET) Received: from [IPv6:2001:6c8:1004:101:2553:85a4:ea3d:efab] (unknown [IPv6:2001:6c8:1004:101:2553:85a4:ea3d:efab]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 66D0639E0C8; Mon, 4 Mar 2013 11:43:46 +0100 (CET) Message-ID: <51347AE2.7020401@alvestrand.no> Date: Mon, 04 Mar 2013 11:43:46 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060700050704040405070703" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Input to Video Codec Selection X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Mar 2013 10:43:51 -0000 This is a multi-part message in MIME format. --------------060700050704040405070703 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 03/03/2013 05:52 PM, Stephan Wenger wrote: > Hi Harald, > Thanks for these candid answers. I have a few comments, marked in > blue and with StW: > Stephan > Speaking with my IETF-amateur-lawyer hat on (and as a former chair of > the IPR WG): No, it does not change the rule. The rule depends on > whether the technology in question is discussed in the IETF, not on > the nature of the contribution. RFC 3979 section 6.1.2 refers to > "Contribution", the definition of that term in RFC 3979 section 1 > letter j makes it completely explicit that RFC Editor Contributions > are covered by the term "Contribution". > ---- below here is StW --- > > StW; While this answer IMO correctly interprets the language of BCP79, > you answer the question IMO to directly. Therefore, the answer is > somewhat misleading in it misses to mention an important point: > > The main (sole?) purpose of an IETF WG is to facilitate consensus > building, which necessarily involves more than one party, and those > contributing to the discussions (belonging to more than one party) > have a disclosure obligation. To which extent there is real > discussion and consensus building dependent from draft to draft and WG > to WG, but there is at least some. > > ISE submissions, like the draft that lead to RFC 6386, OTOH, are > almost always NOT the result of a multiparty consensus building > process. Quite commonly, they involved only a small authors' group, > often from the same company. That's the case here. No technical > community input from IETF participants was received in an IETF > context, no WG consensus was required, and the IESG "no conflict" > statement is also no indication of IETF consensus. > > Insofar, almost inevitably, the disclosure obligations for an ISE > submission are different in practice. In this case, it appears that > only the authors (and perhaps the IESG members—I'm not clear on this > point) had a disclosure obligation. Which they fulfilled. > /StW > I don't know how much the blue survives, email formatting is still hit-and-miss, but I hope this makes sense still.... this is still from my IETF amateur lawyer perspective, and shouldn't be taken as a Google position in any way. I've always worked on the assumption that the RFC 3979 disclosure rules applied only when I was part of the discussion - but that it applied to anything brought into the discussion, including RFCs that I had not heard about before. Thus, I don't believe the submission, editing and publication of RFC 6386 triggered a disclosure obligation on anyone except those involved in the submission and editing process - but I believe that the moment a submission was made to the RTCWEB working group saying "VP8 should be a mandatory to implement codec for RTCWEB", participants who "reasonably and personally" knew of "IPR that is owned directly or indirectly, by the individual or his/her employer or sponsor (if any) or that such persons otherwise have the right to license or assert" (3979 section 6.6) were placed under the obligation of RFC 3979 section 6.1.2 (IPR in the contributions of others). (In the same way, I believe the submission saying "H.264 should be a mandatory to implement codec for RTCWEB", detailed in draft-marjou-rtcweb-video-codec among others, triggered a requirement for similar disclosure of IPR in H.264 technology. I believe the chairs earlier stated which draft such IPR claims should be filed against, but I don't have that message in front of me at the moment.) --------------060700050704040405070703 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 03/03/2013 05:52 PM, Stephan Wenger wrote:
Hi Harald,
Thanks for these candid answers.  I have a few comments, marked in blue and with StW:
Stephan
Speaking with my IETF-amateur-lawyer hat on (and as a former chair of the IPR WG): No, it does not change the rule. The rule depends on whether the technology in question is discussed in the IETF, not on the nature of the contribution. RFC 3979 section 6.1.2 refers to "Contribution", the definition of that term in RFC 3979 section 1 letter j makes it completely explicit that RFC Editor Contributions are covered by the term "Contribution".

---- below here is StW ---

StW; While this answer IMO correctly interprets the language of BCP79, you answer the question IMO to directly.  Therefore, the answer is somewhat misleading in it misses to mention an important point: 

The main (sole?) purpose of an IETF WG is to facilitate consensus building, which necessarily involves more than one party, and those contributing to the discussions (belonging to more than one party) have a disclosure obligation.  To which extent there is real discussion and consensus building dependent from draft to draft and WG to WG, but there is at least some.

ISE submissions, like the draft that lead to RFC 6386, OTOH, are almost always NOT the result of a multiparty consensus building process.  Quite commonly, they involved only a small authors' group, often from the same company.  That's the case here.  No technical community input from IETF participants was received in an IETF context, no WG consensus was required, and the IESG "no conflict" statement is also no indication of IETF consensus.

Insofar, almost inevitably, the disclosure obligations for an ISE submission are different in practice.  In this case, it appears that only the authors (and perhaps the IESG members—I'm not clear on this point) had a disclosure obligation.  Which they fulfilled.
/StW


I don't know how much the blue survives, email formatting is still hit-and-miss, but I hope this makes sense still.... this is still from my IETF amateur lawyer perspective, and shouldn't be taken as a Google position in any way.

I've always worked on the assumption that the RFC 3979 disclosure rules applied only when I was part of the discussion - but that it applied to anything brought into the discussion, including RFCs that I had not heard about before.

Thus, I don't believe the submission, editing and publication of RFC 6386 triggered a disclosure obligation on anyone except those involved in the submission and editing process - but I believe that the moment a submission was made to the RTCWEB working group saying "VP8 should be a mandatory to implement codec for RTCWEB", participants who "reasonably and personally" knew of "IPR that is owned directly or indirectly, by the individual or his/her employer or sponsor (if any) or that such persons otherwise have the right to license or assert" (3979 section 6.6) were placed under the obligation of RFC 3979 section 6.1.2 (IPR in the contributions of others).

(In the same way, I believe the submission saying "H.264 should be a mandatory to implement codec for RTCWEB", detailed in draft-marjou-rtcweb-video-codec among others, triggered a requirement for similar disclosure of IPR in H.264 technology. I believe the chairs earlier stated which draft such IPR claims should be filed against, but I don't have that message in front of me at the moment.)







--------------060700050704040405070703-- From csp@csperkins.org Mon Mar 4 04:58: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 4225F21F8A53 for ; Mon, 4 Mar 2013 04:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 NYldl7zqxmvO for ; Mon, 4 Mar 2013 04:58:23 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 918F121F8A42 for ; Mon, 4 Mar 2013 04:58:23 -0800 (PST) Received: from [130.209.247.112] (port=55360 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UCUyD-0004vK-KA; Mon, 04 Mar 2013 12:58:22 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Mon, 4 Mar 2013 12:58:20 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <95790319-C42C-48E2-A6FD-0E718CCF48FB@csperkins.org> References: To: Ted Hardie X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Reminder: Working group last call for draft-ietf-rtcweb-security-arch X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Mar 2013 12:58:24 -0000 Ted, This draft has a number of places where open issues are noted (e.g., in = Sections 5.1 and 5.5, but there are many others). It seems premature to = issue a working group last call until those are resolved. Colin On 25 Feb 2013, at 23:27, Ted Hardie wrote: > This is a reminder that there is an ongoing last call for > draft-ietf-rtcweb-security-arch-06. Please send comments, including > those of the "reviewed and no issues" ilk, by March 9th, 2012. >=20 > regards, >=20 > Ted Hardie >=20 > On Thu, Feb 14, 2013 at 8:35 AM, Ted Hardie = wrote: >> This begins a working group last call for >> draft-ietf-rtcweb-security-arch. Please send comments to the list by >> March 9, 2013. >>=20 >> regards, >>=20 >> Ted, Cullen, Magnus > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ From jerome.marcon@alcatel-lucent.com Mon Mar 4 05:27: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 643C521F8A7B for ; Mon, 4 Mar 2013 05:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 RPcUWaL0fNrM for ; Mon, 4 Mar 2013 05:27:40 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 732AF21F8A6E for ; Mon, 4 Mar 2013 05:27:40 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r24DR7HQ000549 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 Mar 2013 14:27:37 +0100 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 4 Mar 2013 14:27:01 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.55]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 4 Mar 2013 14:27:02 +0100 From: "MARCON, JEROME (JEROME)" To: Randell Jesup , "rtcweb@ietf.org" Thread-Topic: [rtcweb] TR : New Version Notification for draft-marcon-rtcweb-data-channel-management-00.txt Thread-Index: AQHODm2XDcYJNXiiNUSgiH+65Ett8JiVc4VA Date: Mon, 4 Mar 2013 13:27:01 +0000 Message-ID: <39821B4C400EC14DAD4DB25330A9271A01918D@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <20130218233047.19414.47123.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A012598@FR711WXCHMBA03.zeu.alcatel-lucent.com> <51232071.3070207@jesup.org> In-Reply-To: <51232071.3070207@jesup.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [rtcweb] TR : New Version Notification for draft-marcon-rtcweb-data-channel-management-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, 04 Mar 2013 13:27:41 -0000 Thanks Randell for you review. My replies inline.=20 > -----Message d'origine----- > De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org]=20 > De la part de Randell Jesup > Envoy=E9 : mardi 19 f=E9vrier 2013 07:49 > =C0 : rtcweb@ietf.org > Objet : Re: [rtcweb] TR : New Version Notification for=20 > draft-marcon-rtcweb-data-channel-management-00.txt >=20 > On 2/18/2013 7:07 PM, MARCON, JEROME (JEROME) wrote: > > Hi, > > > > I have submitted a draft proposing a new way of setting up=20 > data channels, based on the concept of data channel=20 > configurations. It uses a lightweight SDP signaling coupled=20 > with a lightweight in-band signaling (not an in-band=20 > protocol). I think it can handle efficiently the most=20 > demanding setup scenarios. The proposal is besides designed=20 > with the intent to not impact on current browser API. >=20 > Thanks. Still reading, but an initial comment: >=20 > "Whenever the application creates a new data channel, the=20 > browser internally checks if the passed set of parameters=20 > strictly matches an existing configuration, and if not=20 > generates a new configuration identifier for this set. In the=20 > latter case only does the browser trigger the application for=20 > an SDP renegotiation." >=20 > Wouldn't this occur on almost every channel because of label=20 > values? Or are you assuming applications won't actually use labels? In this first version of the proposal, the use of labels is still undefined= , but (for the sale of scalability) it would for now remain a local data ch= annel property not transmitted to the peer (should this local property be u= seful to something). I would appreciate some clarifications on the usefulness of labels in the c= ontext of data channels. W3C says nothing about it. Probably - if transmitt= ed to the peer - it can assist the user consent decision. But then assuming= the offer is for opening 100 data channels for file transfer (each channel= with a distinct label), would the answerer's consent be asked 100 times (o= nce per distinct label) ? Probably asking once "do you agree on some file t= ransfers" is enough (and better). And the 'file transfer' information is ca= rried by the subprotocol property, not the label. =20 >=20 > "For each data channel configuration in the offer that is=20 > accepted by the answerer, the answerer echoes in the answer=20 > the configurations supported and accepted. Once the offerer=20 > receives the answer and (in case of an initial offer) the=20 > SCTP initialization is complete, each data channel locally=20 > created using one of the accepted configurations is signaled=20 > to the application as open for transmission." >=20 > There's a bunch of API to surface here in order to support=20 > O/A ("for each ... that is accepted by the answerer..."). >=20 > "By convention, the inbound and outbound streams of a data=20 > channel have the same SCTP stream number. This stream number=20 > is selected by the first endpoint sending a user message on=20 > this channel. Till this happens, an open data channel has no=20 > assigned stream number." >=20 > How do you handle glare? (i.e. both sides start to send on=20 > stream 5 at the same time) >=20 There are two methods proposed in section 6.5. You seem to be supportive of= the 2nd method (even/odd stream number ownership convention). > "Data channel messages are sent as SCTP user messages,=20 > preceded in the DATA chunk User Data field by two bytes=20 > specifying data channel configuration identifier as well as=20 > the message data framing type (textual or binary)." >=20 > Aha. So you've moved this into a true inband protocol with=20 > data framing. The current draft sends data messages with no=20 > added framing required. Please explain why data framing is an issue. WebSocket protocol does this. = The proposal also only reserves a unique PPID for the entire RTCWeb data ch= annel functionality. Personally, I find it ackward to reserve a PPID for so= mething like "plain transmission of any binary data or UTF-8 stream". It se= emed to me that each PPID today registered with IANA is identifying a true = self-contained protocol.=20 >=20 > -- > Randell Jesup > randell-ietf@jesup.org >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From jerome.marcon@alcatel-lucent.com Mon Mar 4 06:36: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 5601921F8942 for ; Mon, 4 Mar 2013 06:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 OAzZbLbun68x for ; Mon, 4 Mar 2013 06:36:49 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8371821F85B4 for ; Mon, 4 Mar 2013 06:36:49 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r24EVun4020743 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 Mar 2013 15:36:45 +0100 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 4 Mar 2013 15:36:38 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.55]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 4 Mar 2013 15:36:38 +0100 From: "MARCON, JEROME (JEROME)" To: "rtcweb@ietf.org" , Randell Jesup Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt Thread-Index: AQHOE6kv4waTKhEPkEqZxW6NBQbqlZiVlNqA Date: Mon, 4 Mar 2013 14:36:38 +0000 Message-ID: <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> In-Reply-To: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-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, 04 Mar 2013 14:36:50 -0000 Randell, Thanks for this update. There are some points not (yet) explained in the te= xt: 1. Following the SDP opening handshake, are the data channels implicitly op= ened, or does the offerer send one DATA_CHANNEL_OPEN message per new data c= hannel ? 2. "channel is available to send as soon as the DATA_CHANNEL_OPEN has been = sent". And the SACK received I guess ? 3. Assuming an endpoint creating a new offer (e.g. to reflect a change in m= edia streams) while an SCTP association is already established. In this cas= e, what does the SCTP association m-line contain: the unchanged list of dat= a channels contained in the initial offer (which created the SCTP associati= on), or the list of data channels currently opened, or .. ? =20 4. What happens if the SDP Opening Handshake agreed on some data channels u= sing the 'chat' subprotocol, and later on an endpoint creates in-band a new= channel with 'file transfer' subprotocol ? Jerome > -----Message d'origine----- > De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org]=20 > De la part de internet-drafts@ietf.org > Envoy=E9 : lundi 25 f=E9vrier 2013 23:40 > =C0 : i-d-announce@ietf.org > Cc : rtcweb@ietf.org > Objet : [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Real-Time Communication in=20 > 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-04.txt > Pages : 13 > Date : 2013-02-25 >=20 > Abstract: > The Web Real-Time Communication (WebRTC) working group is=20 > 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=20 > the WebRTC > framework. It provides an architectural overview of how the Stream > Control Transmission Protocol (SCTP) is used in the WebRTC=20 > context as > a generic transport service allowing Web Browser to=20 > 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-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-data-channel-04 >=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 > = From jerome.marcon@alcatel-lucent.com Mon Mar 4 08:28: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 E181421F8935 for ; Mon, 4 Mar 2013 08:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.949 X-Spam-Level: X-Spam-Status: No, score=-7.949 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_48=0.6, 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 yYa9nSe5XLag for ; Mon, 4 Mar 2013 08:28:19 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6764621F8C2B for ; Mon, 4 Mar 2013 08:28:18 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r24GRxYr019562 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 Mar 2013 17:28:15 +0100 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 4 Mar 2013 17:28:12 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.55]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 4 Mar 2013 17:28:12 +0100 From: "MARCON, JEROME (JEROME)" To: Martin Thomson , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Data Channels Proposal: Now in Internet Draft Form Thread-Index: AQHODgC+U0LQIV4uXUqD2rdW2590g5iVtT3w Date: Mon, 4 Mar 2013 16:28:12 +0000 Message-ID: <39821B4C400EC14DAD4DB25330A9271A019231@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: Re: [rtcweb] Data Channels Proposal: Now in Internet Draft Form X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Mar 2013 16:28:23 -0000 Hi Martin, thanks for your proposal. I have some comments/questions: 1. So the label locally assigned to a data channel created in-band is not t= ransmitted to the peer ? (note that I am fine with this) 2. Whereas defaulting properties like order or reliability is more or less = OK, it seems more critical to default the subprotocol property. The app wou= ld have to parse the incoming user message to guess if this message is abou= t 'chat' or 'file transfer' 3. Why does StreamID need to be exposed to the app ? I first thought it was= to allow in-band data channel creation by a simple message sending. But th= en: - either the StreamID is a parameter of send(streamID, data) - and this bre= aks the alignment with WebSocket API and also the app has no handle on this= data channel=20 - or streamID is a parameter of createDataChannel and this seems useless as= the browser is able to select a new stream number internally 4. Why does binaryPPID need to be exposed to the app ? The browser is expe= cted to infer the message type from the data passed to send(). 5. Finally to decrease the number of mismatching properties situations, you= could simply assign a "Default=3Dstrict|loose" property to one of the data= channels in the SDP. If set to "strict", endpoints could only create in-band data channels for w= hich the default set of properties applies. To create other types of data c= hannels in-band, renegotiation is required If set to "loose'", an endpoint receiving a user message on an closed data = channel would open the data channel using these default properties. But wit= h the risk of mismatch on subprotocol... This would make scalable setup scenarios like: - the SDP offer/answer exchange negotiates one 'chat' data channel, and one= 'file transfer' Default data channel - later on, either endpoint creates in-band 100 data channels for file tran= sfer -> no renegotiation needed, no property mismatch. This reduces the mismatching situations, in the case where one single set o= f properties is mostly used at a given time in the session. But the browser= (or the app) has to guess at the time of SDP negotiation which set of prop= erties should be the default, i.e. will be used more frequently than the ot= hers later on in the session.=20 An extended (and deterministic) approach is to restrict the role of SDP off= er/answer to the negotiation of some identified set of properties (not data= channels). Then data channels are created in-band by the sending of user m= essages on closed streams, where each user message includes a "set of prope= rties" identifier. You may have a look at the draft I have submitted. Jerome > -----Message d'origine----- > De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org]=20 > De la part de Martin Thomson > Envoy=E9 : lundi 18 f=E9vrier 2013 18:52 > =C0 : rtcweb@ietf.org > Objet : [rtcweb] Data Channels Proposal: Now in Internet Draft Form >=20 > I think that we're actually at the point where the involved=20 > parties each understand each other's positions. Now comes=20 > the time to provide everyone else with a coherent proposal=20 > that they can evaluate. >=20 > http://tools.ietf.org/html/draft-thomson-rtcweb-data-00 >=20 > This is intended as an alternative to the mechanisms in=20 > draft-ietf-rtcweb-data-channel. It is also intended to=20 > render draft-jesup-rtcweb-data-protocol unnecessary. That=20 > is, of course, as long as it meets with the approval of the=20 > working group. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From ted.ietf@gmail.com Mon Mar 4 08:43: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 0638F21F871F for ; Mon, 4 Mar 2013 08:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=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 XbrRWf1rt186 for ; Mon, 4 Mar 2013 08:43:47 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 14F8221F8CE7 for ; Mon, 4 Mar 2013 08:43:47 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c10so6442559ieb.3 for ; Mon, 04 Mar 2013 08:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=q6KldLKGlZnDaEA/6VuAs7oW7y15r+FHLvxmcnxzZH4=; b=AJDOwJHwraKo4AarjTPPN6fa87DAwVaaAkIijcAF/1VEu5C93PJS1YnHzedoEw4QZd 3uhsOAKQ4V83Q1W1+Bth9oHBnhlqPuI64t4hAaLoO5rr03QPDJ+URFxUR88H4QL2mFHX 0nnVQwzQZQntUbiIqEngJIBHaEQW02ORynpSuuHU1nou/A2UjIsD3NKKh7loGLcslCgr VBF24nmgdWXMWF8mxzNb3416JN5ymVl9MPdFoiD2tgIzd+BnRhfv4C+g7+eTrV9RbViN ADZY6dFncLZUhRFT7BmS6hibChWAi0YtuQNgNWJ45d2BU8CBy1oqKzMlM8X9qbJ//2ni ywXA== MIME-Version: 1.0 X-Received: by 10.50.182.137 with SMTP id ee9mr2973524igc.96.1362415426647; Mon, 04 Mar 2013 08:43:46 -0800 (PST) Received: by 10.43.135.202 with HTTP; Mon, 4 Mar 2013 08:43:46 -0800 (PST) In-Reply-To: <95790319-C42C-48E2-A6FD-0E718CCF48FB@csperkins.org> References: <95790319-C42C-48E2-A6FD-0E718CCF48FB@csperkins.org> Date: Mon, 4 Mar 2013 08:43:46 -0800 Message-ID: From: Ted Hardie To: Colin Perkins Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Reminder: Working group last call for draft-ietf-rtcweb-security-arch X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Mar 2013 16:43:52 -0000 Hi Colin, Thanks for reviewing the document. As you note, there are open issues; 5.1, for example, has this: "This is a deliberate implementation complexity versus security tradeoff. [[ OPEN ISSUE:: Should we be more aggressive about this?]]" As far as I am aware,though, the document in each case includes a proposal for the Open Issue, and it is that which would be in a WG document post last-call. But if folks looked at the document and answered the "open issues" within, that would certainly be very welcome input. Were there any Open Issues or other points you wanted to comment on directly? Ted but there On Mon, Mar 4, 2013 at 4:58 AM, Colin Perkins wrote: > Ted, > > This draft has a number of places where open issues are noted (e.g., in Sections 5.1 and 5.5, but there are many others). It seems premature to issue a working group last call until those are resolved. > > Colin > > > > On 25 Feb 2013, at 23:27, Ted Hardie wrote: >> This is a reminder that there is an ongoing last call for >> draft-ietf-rtcweb-security-arch-06. Please send comments, including >> those of the "reviewed and no issues" ilk, by March 9th, 2012. >> >> regards, >> >> Ted Hardie >> >> On Thu, Feb 14, 2013 at 8:35 AM, Ted Hardie wrote: >>> This begins a working group last call for >>> draft-ietf-rtcweb-security-arch. Please send comments to the list by >>> March 9, 2013. >>> >>> regards, >>> >>> Ted, Cullen, Magnus >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > -- > Colin Perkins > http://csperkins.org/ > > > From martin.thomson@gmail.com Mon Mar 4 09:00: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 EFD6B21F8CC2 for ; Mon, 4 Mar 2013 09:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_48=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 krG23uPFuC+I for ; Mon, 4 Mar 2013 09:00:51 -0800 (PST) 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 0070021F8C26 for ; Mon, 4 Mar 2013 09:00:50 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hm11so2466493wib.5 for ; Mon, 04 Mar 2013 09:00:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=dX6agABwqy9ODLaSygMTyLuea9GcNH0SKDmXJB9AQpw=; b=vP/F/lUZQHX54B9rHxZGNjY0wjKbFnWC3k6ozEDnaFvqi3o7lC11PXcvkJo0b0iVGI HUB8dFWgFbk9CS2ftATn8fPhjIeEJkEig9RqIuWcgiFR4kzkLlwM42vRSFUnvpFxEA5+ JJk/lg8sfr6ioOY6iAbOY0RYpKPigTj2FL8c3hRwchsEW0ctxXq9w+b/TEsr2cGAhmv/ 1JGPsOyYPainkiURoCumigTqMdWByt6gDmNU0ZFtnW0fxuoK4LyP6XTgpqwoZLlCcvkg Wno5V1OtERfAIEm7vkaLMSgU3K/AY0LeAGh6FNLwTK7LvSK9f7SR7kwzXg8uxBltDgYp eqDg== MIME-Version: 1.0 X-Received: by 10.180.103.40 with SMTP id ft8mr13149994wib.28.1362416449949; Mon, 04 Mar 2013 09:00:49 -0800 (PST) Received: by 10.194.5.135 with HTTP; Mon, 4 Mar 2013 09:00:49 -0800 (PST) In-Reply-To: <39821B4C400EC14DAD4DB25330A9271A019231@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <39821B4C400EC14DAD4DB25330A9271A019231@FR711WXCHMBA03.zeu.alcatel-lucent.com> Date: Mon, 4 Mar 2013 09:00:49 -0800 Message-ID: From: Martin Thomson To: "MARCON, JEROME (JEROME)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data Channels Proposal: Now in Internet Draft Form X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Mar 2013 17:00:52 -0000 Brief answers inline. On 4 March 2013 08:28, MARCON, JEROME (JEROME) wrote: > > Hi Martin, thanks for your proposal. I have some comments/questions: > > 1. So the label locally assigned to a data channel created in-band is not= transmitted to the peer ? (note that I am fine with this) The label is a handle that is provided to the application as a convenience. The label is a new invention, which I'm not certain we entirely need. It might provide some use, but it's unclear how it adds value over the subprotocol label. > 2. Whereas defaulting properties like order or reliability is more or les= s OK, it seems more critical to default the subprotocol property. The app w= ould have to parse the incoming user message to guess if this message is ab= out 'chat' or 'file transfer' Actually, in most cases, an application will only ever receive packets that they know about beforehand. If they need to distinguish between chat and file transfer, they will have established conventions for identifying those packets. PPID is one possible convention, though I note that most uses of SCTP I've seen don't use more than one value, so most code ends up ignoring the PPID. I share the same leeriness about the "protocol" label used in thewebsocketprotocol. > 3. Why does StreamID need to be exposed to the app ? I first thought it w= as to allow in-band data channel creation by a simple message sending. But = then: > - either the StreamID is a parameter of send(streamID, data) - and this b= reaks the alignment with WebSocket API and also the app has no handle on th= is data channel > - or streamID is a parameter of createDataChannel and this seems useless = as the browser is able to select a new stream number internally Stream ID is exposed to the app because it allows the app to create their own usage pattern. It can create the streams it wants and attach meaning to those numbers. That said, stream IDs are allocated automatically by the browser for most uses. I'd expect that streamId would be an optional constraint (i.e., optional in usage) on channel creation. There is no in-band protocol, except for the one that the application uses. That's important. > 4. Why does binaryPPID need to be exposed to the app ? The browser is ex= pected to infer the message type from the data passed to send(). binaryPPID allows the application to generate (though not consume, except in constrained cases) SCTP that can be consumed by any application. The browser doesn't "infer" anything about message types, other than when messages use the textual PPID, in which case they are surfaced as strings rather than the specified binary type (a Blob or ArrayBuffer). > 5. Finally to decrease the number of mismatching properties situations, y= ou could simply assign a "Default=3Dstrict|loose" property to one of the da= ta channels in the SDP. > If set to "strict", endpoints could only create in-band data channels for= which the default set of properties applies. To create other types of data= channels in-band, renegotiation is required > If set to "loose'", an endpoint receiving a user message on an closed dat= a channel would open the data channel using these default properties. But w= ith the risk of mismatch on subprotocol... > This would make scalable setup scenarios like: > - the SDP offer/answer exchange negotiates one 'chat' data channel, and o= ne 'file transfer' Default data channel > - later on, either endpoint creates in-band 100 data channels for file tr= ansfer -> no renegotiation needed, no property mismatch. That's unnecessary. If I want an application that has one "special" channel and an arbitrary number of "normal" channels, I can do exactly as you say and then set the properties of those spontaneously created channels as they appear. It doesn't require any more standardization or browser machinery: pc.addEventListener('datachannel', function(e) { var fileTransferChannel =3D e.channel; fileTransferChannel.ordered =3D true; fileTransferChannel.subprotocol =3D 'filetransfer'; }); > This reduces the mismatching situations, in the case where one single set= of properties is mostly used at a given time in the session. But the brows= er (or the app) has to guess at the time of SDP negotiation which set of pr= operties should be the default, i.e. will be used more frequently than the = others later on in the session. > > An extended (and deterministic) approach is to restrict the role of SDP o= ffer/answer to the negotiation of some identified set of properties (not da= ta channels). Then data channels are created in-band by the sending of user= messages on closed streams, where each user message includes a "set of pro= perties" identifier. You may have a look at the draft I have submitted. I didn't see a specific need for negotiating properties in such a generic fashion. Ultimately, each property needs some semantics when you use it, so it seemed excessive. In SDP at least, the extension mechanism is well enough understood to be able to support extension enough to allow for new properties to be defined (like ordering, which I omitted from my draft by mistake). That said, if you are defining an in-band protocol (a bad idea in my opinion), the idea that properties are generic makes a great deal of sense. That allows applications to define what they need and allows them to avoid unnecessary noise. --Martin From prvs=9775da0dd3=gmartincocher@blackberry.com Mon Mar 4 10:02: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 69D3521F8D60 for ; Mon, 4 Mar 2013 10:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.202 X-Spam-Level: X-Spam-Status: No, score=-7.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 WQCk0VY8rnmf for ; Mon, 4 Mar 2013 10:02:06 -0800 (PST) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 29DFF21F8D65 for ; Mon, 4 Mar 2013 10:02:05 -0800 (PST) X-AuditID: 0a41282f-b7f136d0000013c4-08-5134e1865e10 Received: from XCT101CNC.rim.net (xct101cnc.rim.net [10.65.161.201]) by mhs060cnc.rim.net (SBG) with SMTP id 90.C8.05060.681E4315; Mon, 4 Mar 2013 12:01:42 -0600 (CST) Received: from XCT113CNC.rim.net (10.65.161.213) by XCT101CNC.rim.net (10.65.161.201) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 4 Mar 2013 13:01:42 -0500 Received: from XMB106BCNC.rim.net ([fe80::99b8:8d0e:cdcd:c00d]) by XCT113CNC.rim.net ([::1]) with mapi id 14.02.0328.009; Mon, 4 Mar 2013 13:01:41 -0500 From: Gaelle Martin-Cocher To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Input to Video Codec Selection Thread-Index: AQHOFohR1tLbLyQU8Uy60/t42U/AApiRYfVggAEdmgCAAgYiAIABF5aAgAAxN1CAAAT6gIAAAlYg Date: Mon, 4 Mar 2013 18:01:41 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AA2652C2A6@XMB106BCNC.rim.net> References: <5131CD20.8060201@alvestrand.no> <92D0D52F3A63344CA478CF12DB0648AA2652BB43@XMB106BCNC.rim.net> <55CA954E89EBBD46AC3D6022B7C7160727655871@XMB101ADS.rim.net> <92D0D52F3A63344CA478CF12DB0648AA2652C246@XMB106BCNC.rim.net> In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AA2652C246@XMB106BCNC.rim.net> Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: multipart/alternative; boundary="_000_92D0D52F3A63344CA478CF12DB0648AA2652C2A6XMB106BCNCrimne_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFKsWRmVeSWpSXmKPExsXC5bjwpG7bQ5NAg/XbbSzW/mtnd2D0WLLk J1MAY1QDo01SYklZcGZ6nr6dTWJeXn5JYkmqQkpqcbKtkk9qemKOQkBRZllicqWCS2Zxck5i Zm5qkZJCZoqtkomSQkFOYnJqbmpeia1SYkFBal6Kkh2XAgawASrLzFNIzUvOT8nMS7dV8gz2 17WwMLXUNVSy003o5Mk4sGY7c0HvbaaK0xs2sjYwfl7D1MXIySEhYCKx6t9nVghbTOLCvfVs XYxcHEICqxglrp3ewQzhrGCUeHX4HxOEM4dRYs6yRywgLWwClhL/X+0Bs0UE1CUuP7zADmIL A409+GcdG0TcVOLsqUdQdpTE0tOfwWwWARWJpvv7wWxeAU+JvXsvM4LYQgJ9TBJbTwV2MXJw cAp4Sby+mA1iMgKVn3waDlLBLCAucevJfKgHBCSW7DnPDGGLSrx8/A/qGUWJvc+OMkHU50vM +tzJCrFJUOLkzCcsEJs0JU6+OMc4gVFsFpKxs5C0zELSAhHXk7gxdQobhK0tsWzha2YIW1di xr9DLMjiCxjZVzEK5mYUG5gZJOcl6xVl5urlpZZsYgSnFw39HYxv31scYhTgYFTi4b16ySRQ iDWxrLgy9xCjBAezkgjvi7tAId6UxMqq1KL8+KLSnNTiQ4xBwHCbyCzFnZwPTH15JfHGBgZE cpTEeUUCRQOFBNKBqS87NbUgtQhmKBMHJ8hSLimRYmACSy1KLC3JiAel2fhiYKKVamDUbvCa VJB/YEat8uOd/xzXayw+LZg4xdbZQcYi84ZGZuR2X8uqQK2tbV+7k3WzuB/NEik+mME5wYhv xSvF9zEJHu+yF7oV3Dfl1QmfKTy96ldl7UVTvns277Ufpp73iXIziNtrnPhz5ccosx2LON7o FFVGHKy3mltn7Fe36k7x+dApZcX1FUosxRmJhlrMRcWJAOZZIjx9AwAA Subject: [rtcweb] FW: Input to Video Codec Selection X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Mar 2013 18:02:14 -0000 --_000_92D0D52F3A63344CA478CF12DB0648AA2652C2A6XMB106BCNCrimne_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Dear Harald, Stephan, All. Thank you for your answers. I have further comments and request for clarifications marked in red with [g= mc]. Sincerely, Ga=EBlle From: Stephan Wenger [mailto:stewe@stewe.org] Sent: Sunday, March 03, 2013 11:52 AM To: Harald Alvestrand; Gaelle Martin-Cocher Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Input to Video Codec Selection Hi Harald, Thanks for these candid answers. I have a few comments, marked in blue and= with StW: Stephan From: Harald Alvestrand > Date: Saturday, 2 March, 2013 01:57 To: Gaelle Martin-Cocher > Cc: "rtcweb@ietf.org" > Subject: Re: [rtcweb] Input to Video Codec Selection On 03/01/2013 11:21 PM, Gaelle Martin-Cocher wrote: Dear All, Further to Magnus email, while I assume there might not be "something new" t= o learn at the meeting, I believe the below requested clarifications on exis= ting information would be useful. Implementers should clearly know which li= cense they can pick or get when it comes to VP8 and by which groups. I beli= eve answers in advance of the meeting would help the discussion at the meeti= ng. Questions 1 & 2: It is assumed that in the case of choosing VP8, RTCWeb would reference the= informational RFC 6386. Yes, that is the intent. Q1: Is there an intent to move that RFC to the standard track at a point in= time? No. I don't personally see any benefit in doing so at this time. [GMC] I see many valid reasons why one implementer would want to comply to a= formal specification available in a standardization body where an IPR discl= osure process takes place. That specification would have had the right level= of scrutiny by a wide group of experts. >From a technical viewpoint, I would want to develop an implementation from s= uch a specification and I would want to test it against some conformance poi= nt/spec. >From an IP side, it should be noted that for some legal entities it is certa= inly easier to declare IP against a "spec" than against a "code". Having "ju= st" a code may have prevented some entities to make their declarations. So it seems from your answer and from StW answer below that for RFC 6386: "The Spec" is "the code". There will not be in IETF a more formal spec. is that correct? It will not move to the standard track hence not reach the level of scrutiny= /consensus that everyone was asking for. On the other hand in MPEG, we may/will (?) get a formal spec (that is, synta= x, semantic, decoding process, conformance) and a more thorough scrutiny/rev= iew. Q2: Would that change the rule of "who" is obliged to make an IPR declaratio= n? Speaking with my IETF-amateur-lawyer hat on (and as a former chair of the IP= R WG): No, it does not change the rule. The rule depends on whether the tech= nology in question is discussed in the IETF, not on the nature of the contri= bution. RFC 3979 section 6.1.2 refers to "Contribution", the definition of t= hat term in RFC 3979 section 1 letter j makes it completely explicit that RF= C Editor Contributions are covered by the term "Contribution". StW; While this answer IMO correctly interprets the language of BCP79, you a= nswer the question IMO to directly. Therefore, the answer is somewhat misle= ading in it misses to mention an important point: The main (sole?) purpose of an IETF WG is to facilitate consensus building,= which necessarily involves more than one party, and those contributing to t= he discussions (belonging to more than one party) have a disclosure obligati= on. To which extent there is real discussion and consensus building depende= nt from draft to draft and WG to WG, but there is at least some. ISE submissions, like the draft that lead to RFC 6386, OTOH, are almost alwa= ys NOT the result of a multiparty consensus building process. Quite commonl= y, they involved only a small authors' group, often from the same company. = That's the case here. No technical community input from IETF participants= was received in an IETF context, no WG consensus was required, and the IESG= "no conflict" statement is also no indication of IETF consensus. Insofar, almost inevitably, the disclosure obligations for an ISE submission= are different in practice. In this case, it appears that only the authors= (and perhaps the IESG members-I'm not clear on this point) had a disclosure= obligation. Which they fulfilled. /StW Question 3: The IPR disclosure was made on the draft 2 of draft-bankoski-vp8-bitstream-0= 2" as per https://datatracker.ietf.org/ipr/search/?option=3Drfc_search&rfc_s= earch=3D6386 Draft 3 and onward contains the copyright license and the additional IP righ= ts grant. Q3: Is the initial IPR disclosure still valid? Yes. RFC 3979 section 6.2.1. The IPR disclosure required pursuant to section 6.1.1 must be made as soon as reasonably possible after the Contribution is published in an Internet Draft unless the required disclosure is already on file. For example, if the Contribution is an update to a Contribution for which an IPR disclosure has already been made and the applicability of the disclosure is not changed by the new Contribution, then no new disclosure is required. Question 4: The informational RFC 6386 contains the decoder code and some piece of encod= er code. Though the IP rights grant mentioned in the RFC is offered against: "This implementation" means the copyrightable works distributed by Google as part of the WebM Project." Q4: As such the IP rights grant does not seem to apply to the RFC itself or= to an implementation of the code contained in the RFC. Should that be corr= ected or is that the intent? Speaking with WEBM hat on: There are two grants - the grant of license to copyrighted works, and the gr= ant of license to patented technology. Software license: http://www.webmproject.org/license/software/ - classical 3= -clause BSD. Patent license 1: http://www.webmproject.org/license/bitstream/ - covers any= implementation that produces or consumes VP8 bitstreams. Patent license 2: http://www.webmproject.org/license/additional/ - covers us= age of the implementation. [gmc] I am afraid you are not answering Q4. Those are WebM licenses that don= 't apply to the RFC (more precisely to the RFC code). You may be making the assumption that everyone will refer to and use the Web= M code. I am making the assumption that if the RFC is self-sufficient one would want= to derive a VP8 compliant implementation from the RFC (either from section= 1 to 19 or from section 20 to 20.24 or from both). Hence what is the meaning of 20.26 and 20.27 in the RFC and how does that ap= ply to the RFC itself? This is still confusing. Question 5: The additional IP grant is applied to a particular implementation (namely th= e WebM VP8 code) without modifications. Any derivative work either: - produced from the reference code in WebM (that is a possible optimized ver= sion of it); or - produced from the RFC text or the code provided within the RFC (while not= using the WebM code) does not have the benefit of the additional IP grant. In other words a conformant implementation does not necessarily have the ben= efit of the additional IP grant. I am not confident that the VP8 code can be used "as is" for certain platfor= ms. I would think that the code might need some modification to provide the= desired performance. In other words, it should be clear that those implemen= ters would not necessarily receive the benefit of that grant. If the answer to Q3 is negative, then there is no IP license statement at al= l that applies to a "conformant implementation of the RFC" (aka a derivative= work). If the answer to Q3 is positive, it is not clear how to reconcile the decla= ration inside the RFC and the declaration that is attached to the the RFC dr= aft for implementers that would not modify the code. Q5: Can this be clarified or confirmed? All 3 of the pages referred to above permit the production of derivative wor= ks. Quoth: - bitstream: " ... license to make, have made, use, offer to sell, sell, imp= ort, and otherwise transfer implementations of this specification" (whether= derived from the example code or not) - copyright: ".... Redistribution and use in source and binary forms, with o= r without modification, are permitted provided that.." - patent: "... patent license to make, have made, use, offer to sell, sell,= import, transfer, and otherwise run, modify and propagate the contents of t= his implementation" I believe there should be no issue here; modification is permitted. [gmc] the question is not "are modifications permitted" but which license ap= ply to those modifications (again referring to the RFC code and not to WebM)= . It seems that only the IETF declaration attached to the RFC apply to the RFC= code. (though that would depend on answers to Q4) Question 6: The IPR disclosure in IETF is different than the IPR statement made in MPEG= (see document sent by Harald earlier). Q6: the differences in license statement and IP grant referring to WebM code= are rather confusing. Can it be clarified which license, copyright, grant a= re provided for RFC 6386? The statement we made in MPEG was crafted to be as similar to others' statem= ents made in MPEG as possible, in order to respect MPEG's legal language tra= ditions - which in turn should minimize the need for clarification of what w= as granted when discussing with people used to the MPEG language tradition. [gmc] I believe the statement in MPEG in MPEG is similar to other MPEG state= ment except for the "other reasonable conditions" that triggers significant= confusion as they are undefined. We believe that the statement made in MPEG is wholly within the statements m= ade on the WEBM website - all permissions implied by the statement in MPEG s= hould also be permitted by the statements on the WEBM website. We haven't tr= ied to analyze whether there are cases where someone can do something within= the permissions granted on the WEBM website that would not be permitted und= er the MPEG statement - the MPEG statement was aimed to allow the document t= o progress within MPEG; people who want to read the [gmc] again, one would want to use a standard specification not the WebM cod= e to develop a conformant implementation and test it. In conclusion, before advancing this draft, or considering it as a candidate= for RTCWeb, consistency and clarity should be ensured between the IPR gran= t associated with the IETF draft, the IPR grants within the IETF draft docum= ent itself, the IPR grant given for MPEG, and any IPR grant given in connect= ion with the WEBM project for this same work. Otherwise, the IPR status of= the work that is undertaken is indeterminate, and likely will not produce a= result that will be useful. Speaking with my Google hat on: We will of course seek maximum clarity of the statements we make. Unfortunat= ely, different organizations have different traditions on how these things s= hould be worded, and we cannot guarantee that there can't be differences in= interpretation. However, I (speaking with my personal hat on) think the current statements o= n the WEBM website are pretty clear. [GMC] again that is not what matters. I have yet to see a concrete scenario where there would be any reasonable do= ubt about whether usage of VP8 is permitted by Google or not - and in all ca= ses except for those that fall within the defensive suspension exceptions, i= t is permitted. [gmc] the issue is not that Google would permit or not the usage of VP8. The= issue is: will VP8 become a "standard" one way or another, and/or will it g= et the right level of scrutiny so that OTHER will/could declare their IP and= thereby will finally get clarity on that aspect for implementers. I think that this is/was the purpose of the exercise of bringing VP8 via an= RFC or in MPEG. This exercise needs to be completed. Sincerely, Ga=EBlle Hope that helps! Harald --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_92D0D52F3A63344CA478CF12DB0648AA2652C2A6XMB106BCNCrimne_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable

 

Dear Harald, Stephan, All.<= o:p>

Thank you for your answers.

I have further comments and= request for clarifications marked in red with [gmc].

 

Sincerely,

Ga=EBlle<= /p>

 

From: Stephan Wen= ger [mailto:stewe@stewe.org]
Sent: Sunday, March 03, 2013 11:52 AM
To: Harald Alvestrand; Gaelle Martin-Cocher
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Input to Video Codec Selection

 

Hi Harald,

Thanks for these candid answer= s.  I have a few comments, marked in blue and with StW:

Stephan

 

From: Harald Alvestrand <harald@alvestrand.no>
Date: Saturday, 2 March, 2013 01:57
To: Gaelle Martin-Cocher <gmartincocher@blackberry.com>
Cc: "rtcweb@ietf.org"= ; <rtcweb@ietf.org>
Subject: Re: [rtcweb] Input to Video Codec Selection

 


On 03/01/2013 11:21 PM, Gaelle Martin-Cocher wrote:

Dear All,
 
Further to Magnus email, while I assume the=
re might not be "something new" to learn at the meeting, I believe=
 the below requested clarifications on existing information would be useful.=
  Implementers should clearly know which license they can pick or get w=
hen it comes to VP8 and by which groups.  I believe answers in advance=
 of the meeting would help the discussion at the meeting.<=
/pre>

 


Questions 1 & 2:

It is assumed that in  the case of cho=
osing VP8, RTCWeb would reference  the informational RFC 6386.

Q1: Is there an intent to move that RFC to= the standard track at a point in time?

No. I don't personally see an= y benefit in doing so at this time.
[GMC] I see manyvalid reasons why one implementer would want to= comply to a formal specification available in a standardization body where= an IPR disclosure process takes place. That specification would have had the right level of scrutiny by a wide group of experts.=

From a technical viewpoint, I would want to develop an implement= ation from such a specification and I would want to test it against some con= formance point/spec.

From an IP side, it should be n= oted that for some legal entities it is certainly easier to declare IP a= gainst a “spec” than against a “code”. Having “= ;just” a code may have prevented some entities to make their declarati= ons.

 

So it seems from your answer an= d from StW answer below that for RFC 6386:

“The Spec” is ̶= 0;the code”.

There will not be in IETF a mor= e formal spec. is that correct?

It will not move to the standar= d track hence not reach the level of scrutiny/consensus that everyone was as= king for.

On the other hand in MPEG, we may/will (?) get a formal spec (that is, syntax, semantic, d= ecoding process, conformance) and a more thorough scrutiny/review.

  

Q2: Would that change the rule of "who=
" is obliged to make an IPR declaration?

Speaking with my IETF-amateur= -lawyer hat on (and as a former chair of the IPR WG): No, it does not change= the rule. The rule depends on whether the technology in question is discussed in the IETF, not on the nature of the contribution= . RFC 3979 section 6.1.2 refers to "Contribution", the definition= of that term in RFC 3979 section 1 letter j makes it completely explicit th= at RFC Editor Contributions are covered by the term "Contribution".

 

StW; While this answer IMO cor= rectly interprets the language of BCP79, you answer the question IMO to dire= ctly.  Therefore, the answer is somewhat misleading in it misses to mention an important point: 

 

The main (sole?) purpose of an= IETF WG is to facilitate consensus building, which necessarily involves mor= e than one party, and those contributing to the discussions (belonging to more than one party) have a disclosure obligation.  To w= hich extent there is real discussion and consensus building dependent from d= raft to draft and WG to WG, but there is at least some.

 

ISE submissions, like the draf= t that lead to RFC 6386, OTOH, are almost always NOT the result of a multipa= rty consensus building process.  Quite commonly, they involved only a small authors' group, often from the same company.  Th= at's the case here.  No technical community input from IETF participant= s was received in an IETF context, no WG consensus was required, and the IES= G "no conflict" statement is also no indication of IETF consensus.

 

Insofar, almost inevitably, th= e disclosure obligations for an ISE submission are different in practice. &n= bsp;In this case, it appears that only the authors (and perhaps the IESG members—I'm not clear on this point) had a disclosure obliga= tion.  Which they fulfilled.

/StW

Question 3: 

The IPR disclosure was made on the draft 2=
 of draft-bankoski-vp8-bitstream-02" as per https://=
datatracker.ietf.org/ipr/search/?option=3Drfc_search&rfc_search=3D6386
Draft 3 and onward contains the copyright l=
icense and the additional IP rights grant. 
Q3: Is the initial IPR disclosure still val=
id?

Question 4: 

The informational RFC 6386 contains the dec=
oder code and some piece of encoder code.
Though the IP rights grant mentioned in the=
 RFC is offered against:
 
   "This implementation"=
; means the copyrightable works distributed by
   Google as part of the WebM Pro=
ject."
 
Q4: As such the  IP rights grant does=
 not seem to apply to the RFC itself or to an implementation of the code con=
tained in the RFC.  Should that be corrected or is that the intent?

Speaking with WEBM hat on:
There are two grants - the grant of license to copyrighted works, and the gr= ant of license to patented technology.

Software license: h= ttp://www.webmproject.org/license/software/ - classical 3-clause BSD. Patent license 1: = http://www.webmproject.org/license/bitstream/ - covers any implementatio= n that produces or consumes VP8 bitstreams.
Patent license 2: http://www.webmproject.org/license/additional/ - covers usage of the im= plementation.
[gmc] I am afraid you are not answering Q4. Tho= se are WebM licenses that don’t apply to the RFC (more precisely to th= e RFC code).

You may be making the assumptio= n that everyone will refer to and use the WebM code.

I am making the assumption that= if the RFC is self-sufficient one would want to derive a VP8 compliant impl= ementation from the RFC (either from section 1 to 19 or from section 20 to 20.24 or from both).

Hence what is the meaning of 20= .26 and 20.27 in the RFC and how does that apply to the RFC itself?

= This is still confusing. 

 
Question 5:
The additional IP grant is applied to a par=
ticular implementation (namely the WebM VP8 code) without modifications. 
Any derivative work either:
- produced from the reference code in WebM=
 (that is a possible optimized version of it); or
- produced from the RFC text or the code pr=
ovided within the RFC (while not using the WebM code)

does not have the benefit of the additional=
 IP grant. 


In other words a conformant implementation=
 does not necessarily have the benefit of the additional IP grant.


I am not confident that the VP8 code can be=
 used "as is" for certain platforms. I would think that the code m=
ight need some modification to provide the desired performance. In other wor=
ds, it should be clear that those implementers would not necessarily receive=
 the benefit of that grant.


If the answer to Q3 is negative, then there=
 is no IP license statement at all that applies to a "conformant implem=
entation of the RFC" (aka a derivative work).


If the answer to Q3 is positive, it is not=
 clear  how to reconcile the declaration inside the RFC and the declara=
tion that is attached to the the RFC draft for implementers that would not m=
odify the code.


Q5: Can this be clarified or confirmed?


All 3 of the pages referred t=
o above permit the production of derivative works. Quoth:



- bitstream: " ... =
license to make, have made, use, offer to sell, sell, import, and otherwise=
 transfer implementations of this specification" (whether
 derived from the example code or not)

- copyright: ".... Redistribution and use in source and binary forms, w=
ith or without modification, are permitted provided that.."

- patent: "... patent license to make, have made, use, offer to sell, s=
ell, import, transfer, and otherwise run, modify and propagate the contents=
 of this implementation"



I believe there should be no issue here; modification is permitted.

[gmc] the question is not “are modificati=
ons permitted” but which license apply to those modifications (again r=
eferring to the RFC code and not to WebM).


It seems that only the IETF dec=
laration attached to the RFC apply to the RFC code. (though that would depen=
d on answers to Q4)


 


Question 6:


The IPR disclosure in IETF is different tha=
n the IPR statement made in MPEG (see document sent by Harald earlier). 


Q6: the differences in license statement an=
d IP grant referring to WebM code are rather confusing. Can it be clarified=
 which license, copyright, grant are provided for RFC 6386?


The statement we made in MPEG=
 was crafted to be as similar to others' statements made in MPEG as possible=
, in order to respect MPEG's legal language traditions
 - which in turn should minimize the need for clarification of what was gran=
ted when discussing with people used to the MPEG language tradition.

[gmc] I believe the statement in MPEG in MPEG i=
s similar to other MPEG statement except for the “other reasonable con=
ditions” that triggers significant confusion as they are
 undefined.




We believe that the statement made in MPEG is wholly within the statements m=
ade on the WEBM website - all permissions implied by the statement in MPEG s=
hould also be permitted by the statements on the WEBM website. We haven't tr=
ied to analyze whether there
 are cases where someone can do something within the permissions granted on=
 the WEBM website that would not be permitted under the MPEG statement - the=
 MPEG statement was aimed to allow the document to progress within MPEG; peo=
ple who want to read the


[gmc] again, one would want to use a standard s=
pecification not the WebM code to develop a conformant implementation and te=
st it.


 


 


In conclusion, before advancing this draft,=
 or considering it as a candidate for RTCWeb,  consistency and clarity=
 should be ensured between the IPR grant associated with the IETF draft, the=
 IPR grants within the IETF draft document itself, the IPR grant given for M=
PEG, and any IPR grant given in connection with the WEBM project for this sa=
me work.  Otherwise, the IPR status of the work that is undertaken is i=
ndeterminate, and likely will not produce a result that will be useful. =
; 




=
[GMC] again that is not what matters.


[gmc] the issue is not that Google would permit=
 or not the usage of VP8. The issue is: will VP8 become a “standard=
221; one way or another, and/or will it get the right level of
 scrutiny so that OTHER will/could declare their IP and thereby will=
 finally get clarity on that aspect for implementers.



=
I think that this is/was the purpose of the exercise of bringing VP8 via an=
 RFC or in MPEG. This exercise needs to be completed.


=
Sincerely,


=
Ga=EBlle



To: "rtcweb@ietf.org" 
Thread-Topic: Data channel setup: scalability, user experience, labels
Thread-Index: Ac4ZBx/hYvUqem8+Tz2lp+QBZVXajg==
Date: Mon, 4 Mar 2013 18:36:04 +0000
Message-ID: <39821B4C400EC14DAD4DB25330A9271A01929A@FR711WXCHMBA03.zeu.alcatel-lucent.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
Subject: [rtcweb] Data channel setup: scalability, user experience, labels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 04 Mar 2013 18:36:08 -0000

I would like to get rough opinions on three data channel related topics:

Scalability-challenging scenarios
---------------------
If I am not mistaken, Randell mentioned in Boston some data channel setup s=
cenarios like: 1000 data channels opened in the same session, and possibly =
100 data channels opened simultaneously (usage: file transfer). I agree it =
is important to keep some scalability objectives in mind when taking decisi=
ons on the data channel setup design. So what about a list of real-life sca=
lability-challenging scenarios like:

1. No SCTP association is established, and an endpoint wishes to open 100 d=
ata channels for the same usage (e.g. file transfer)

2. An SCTP association is established, and an endpoint wishes to open 100 d=
ata channels for the same usage (e.g. file transfer)

3. An endpoint creates and closes a data channel at a high frequency, for t=
he same usage (probably an app misbehavior here, but...)

4. ...any other?

User consent
---------------------
These scalability-challenging scenarios not only raise scalability issues, =
but user experience issues as well. Should these be relevant in IETF (and n=
ot in W3C), which user consent is appropriate in the context of data channe=
l setup ?

A) Assuming an initial/updating SDP offer declaring one 'chat' channel and =
100 'file transfer' channels, each with a distinct label. The user consent =
will be:
* 1-line: "open data channels [for this time only | anytime during this ses=
sion] for any usage/subprotocol"
* 2-line: "open data channels [for this time only | anytime during this ses=
sion] for usage/subprotocol: (1) chat (2) file transfer"
* 101-line: "open data channels for this time only for usage/subprotocol.la=
bel: (1) chat.label1 (2) file transfer.label 2... (101) file transfer.label=
 101"

B) Assuming a data channel created in-band, with a subprotocol already nego=
tiated
* I assume user consent is not required here ?

C) Assuming a data channel created in-band, with a subprotocol 'file transf=
er' never negotiated before in the SDP handshake (I think only Randell's pr=
oposal allows this)
* 1-line: "open a data channel for this time only for usage/subprotocol.lab=
el =3D chat.label1" =20
* 1-line: "open a data channel [for this time only | anytime during this se=
ssion] for usage/subprotocol =3D chat"=20

>From these (too much detailed) cases, we can identify 3 main types of user =
consent for data channel setup:
U1. open any number of data channels of any type: prompted at the time of S=
CTP association setup=20
U2. open any number of data channels of a given usage/subprotocol: prompted=
 the first time this subprotocol is signaled to the peer (in SDP or in-band=
)
U3. open one data channel of a given usage/subprotocol of a given label=20

Label usefulness
---------------------
I would like to understand the usefulness of data channel labels. Consideri=
ng that:
- (if user consent is of type U1 or U2 described above) labels do not take =
part of user consent
- labels are no longer used as data channel identifiers (SCTP stream number=
s are better for this, according to the 3 data channel setup proposals on t=
he table: Randell's, Martin's and mine).=20
- W3C says nothing about the use of data channel labels

Jerome=

From martin.thomson@gmail.com  Mon Mar  4 10:45: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 41E2321F8E67 for ; Mon,  4 Mar 2013 10:45:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level: 
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[AWL=0.800, 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 bypBypf6wDRW for ; Mon,  4 Mar 2013 10:45:36 -0800 (PST)
Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 681B321F8E4A for ; Mon,  4 Mar 2013 10:45:36 -0800 (PST)
Received: by mail-wg0-f45.google.com with SMTP id dq12so4504579wgb.12 for ; Mon, 04 Mar 2013 10:45:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=NKvTrnXHCY2FdiVpdpraDRsb6qx4CC9a3w1jlFzzxaY=; b=e1PIZIbHy9zO3a0D5nGrNDiDhXtsDYsstjXgzqW8StNUMGKYLfK39hqYkGC1oZZQlM 5Hc8k/7P7ROfupmoes6w1/OjgDafCcuv7aZ7XlOFdBdgZfiUS+G2oxk4uBfn3CFCU2C2 FmBgDIQldMMw4IO3h225iGWkSQ7wJnCmzsUukRaZ48gD9t+3vnQ5pZcuMz0OBnPW8zLN hSEyay5vD1x8uJ/mCRr2FEkAt+0Q0ctiAENxeyEis8c2otNvbZAOX+Nuv3/LdtG9pAje sWMHG5t7qJ7dQvO2lpjrX3nxZuNudYlrjYix+EWKc35LWiCKkaTaPvo0/eRvDvhtYhny N6zg==
MIME-Version: 1.0
X-Received: by 10.194.5.137 with SMTP id s9mr34133632wjs.5.1362422735660; Mon, 04 Mar 2013 10:45:35 -0800 (PST)
Received: by 10.194.5.135 with HTTP; Mon, 4 Mar 2013 10:45:35 -0800 (PST)
In-Reply-To: <39821B4C400EC14DAD4DB25330A9271A01929A@FR711WXCHMBA03.zeu.alcatel-lucent.com>
References: <39821B4C400EC14DAD4DB25330A9271A01929A@FR711WXCHMBA03.zeu.alcatel-lucent.com>
Date: Mon, 4 Mar 2013 10:45:35 -0800
Message-ID: 
From: Martin Thomson 
To: "MARCON, JEROME (JEROME)" 
Content-Type: text/plain; charset=UTF-8
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Data channel setup: scalability, user experience, labels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 04 Mar 2013 18:45:37 -0000

On 4 March 2013 10:36, MARCON, JEROME (JEROME)
 wrote:
> Scalability-challenging scenarios

Honestly, I don't see these as being especially relevant.  Performance
under these sorts of scenarios is largely down to the browser.
Optimizing for crazy scaling cases would be a low priority.

> User consent

We've previously discussed consent for data and since this is
effectively just an optimization of existing channels, user consent
would not just be superfluous, but actually harmful.

> Label usefulness

I can see some limited use for labels.  They aren't super-effective or
necessary.  I'm sure that some people will find a use for them.

From Michael.Tuexen@lurchi.franken.de  Mon Mar  4 10:46: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 8719621F8E6E for ; Mon,  4 Mar 2013 10:46:42 -0800 (PST)
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 EKZAJMPA4T2p for ; Mon,  4 Mar 2013 10:46:41 -0800 (PST)
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 473E521F8E4A for ; Mon,  4 Mar 2013 10:46:41 -0800 (PST)
Received: from [192.168.1.102] (p508FAB81.dip.t-dialin.net [80.143.171.129]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id DF9731C0B4615; Mon,  4 Mar 2013 19:46:33 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=iso-8859-1
From: Michael Tuexen 
In-Reply-To: <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com>
Date: Mon, 4 Mar 2013 19:46:37 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <085532B8-9A37-44D6-B311-14AFEBDF5221@lurchi.franken.de>
References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com>
To: "MARCON, JEROME (JEROME)" 
X-Mailer: Apple Mail (2.1283)
Cc: Randell Jesup , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-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, 04 Mar 2013 18:46:42 -0000

On Mar 4, 2013, at 3:36 PM, MARCON, JEROME (JEROME) wrote:

>=20
> Randell,
>=20
> Thanks for this update. There are some points not (yet) explained in =
the text:
>=20
> 1. Following the SDP opening handshake, are the data channels =
implicitly opened, or does the offerer send one DATA_CHANNEL_OPEN =
message per new data channel ?
>=20
> 2. "channel is available to send as soon as the DATA_CHANNEL_OPEN has =
been sent". And the SACK received I guess ?
The SACK is an SCTP level ack. So you only know that the SCTP stack of =
the peer has received it,
so you don't know if the application has received it or even processed =
it. So if you want some
sort of ack, you need an application level ack. This was done in the 3 =
way handshake stuff which
was in the older version.

In this version, the sender sends an DATA_CHANNEL_OPEN as the first =
message and the receiver has
to buffer user messages until the DATA_CHANNEL_OPEN message has been =
received in case of reordering
in the network and using unordered delivery for user messages.

Best regards
Michael
>=20
> 3. Assuming an endpoint creating a new offer (e.g. to reflect a change =
in media streams) while an SCTP association is already established. In =
this case, what does the SCTP association m-line contain: the unchanged =
list of data channels contained in the initial offer (which created the =
SCTP association), or the list of data channels currently opened, or .. =
?
>=20
> 4. What happens if the SDP Opening Handshake agreed on some data =
channels using the 'chat' subprotocol, and later on an endpoint creates =
in-band a new channel with 'file transfer' subprotocol ?
>=20
> Jerome
>=20
>> -----Message d'origine-----
>> De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org]=20
>> De la part de internet-drafts@ietf.org
>> Envoy=E9 : lundi 25 f=E9vrier 2013 23:40
>> =C0 : i-d-announce@ietf.org
>> Cc : rtcweb@ietf.org
>> Objet : [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt
>>=20
>>=20
>> A New Internet-Draft is available from the on-line=20
>> Internet-Drafts directories.
>> This draft is a work item of the Real-Time Communication in=20
>> 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-04.txt
>> 	Pages           : 13
>> 	Date            : 2013-02-25
>>=20
>> Abstract:
>>   The Web Real-Time Communication (WebRTC) working group is=20
>> 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=20
>> the WebRTC
>>   framework.  It provides an architectural overview of how the Stream
>>   Control Transmission Protocol (SCTP) is used in the WebRTC=20
>> context as
>>   a generic transport service allowing Web Browser to=20
>> 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-04
>>=20
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-data-channel-04
>>=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
>=20


From ted.ietf@gmail.com  Mon Mar  4 10:50: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 B9AE021F8D8E for ; Mon,  4 Mar 2013 10:50:44 -0800 (PST)
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, 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 Ldx4oA+os3rQ for ; Mon,  4 Mar 2013 10:50:44 -0800 (PST)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6E721F8D72 for ; Mon,  4 Mar 2013 10:50:44 -0800 (PST)
Received: by mail-ie0-f182.google.com with SMTP id k14so6604550iea.27 for ; Mon, 04 Mar 2013 10:50:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=QPWIYmhZJOlz9XWnf3mVd0x9q5oprqt2zdIlAmVXewY=; b=SW46oWP9VxBe5oskQJGyAoO+y/PdMZI7TAw1uw2w8Rc0HCioVoHDRszlizZ+dXAeo/ 9+OA4zIy/Y4gauk3z4oXpEGdLvoNi+Fe8QjEKKbsqHqHh83wqu+Pf3HBj6/faFk3qmtW DrLOWDCBhOUnzEbz7JnYSWbOcx2sV7DQ9F1xtZidKhFhybQazH8wp4PjC7rZaziwrGFj 89EdOZ6sXlU+R1fpGXQaO+hxL0KLSDa21mvEX9+QRPBo/PpzS8nkl6oD8hLnwvbN2zu1 fdqZBuKZenFdfJHkfRdESCNIng/dSVxY04nrW6raBx3y3e308H+3s/c2rRwTzOzEQlz9 vOgw==
MIME-Version: 1.0
X-Received: by 10.50.36.169 with SMTP id r9mr3383884igj.96.1362423043916; Mon, 04 Mar 2013 10:50:43 -0800 (PST)
Received: by 10.43.135.202 with HTTP; Mon, 4 Mar 2013 10:50:43 -0800 (PST)
Date: Mon, 4 Mar 2013 10:50:43 -0800
Message-ID: 
From: Ted Hardie 
To: rtcweb@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [rtcweb] Color marking comments
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 04 Mar 2013 18:50:44 -0000

Howdy,

I appreciate the effort folks are putting into attribution in their
comments, but please don't rely on color as an attribution marker.  It
may not survive various archiving efforts and there are participants
who either use screen readers or have color vision issues that make
this sub-optimal.  You may use this as an optional marker, but please
use some other method (quoting, initials, tagging) as primary.

thanks,

Ted Hardie

From worley@shell01.TheWorld.com  Mon Mar  4 12:22: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 9FB1A21F8FAC for ; Mon,  4 Mar 2013 12:22:02 -0800 (PST)
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.022,  BAYES_00=-2.599, 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 6JzcVFoHPZQF for ; Mon,  4 Mar 2013 12:22:02 -0800 (PST)
Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id E7FA221F8FB3 for ; Mon,  4 Mar 2013 12:22:01 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r24KLpXg029036 for ; Mon, 4 Mar 2013 15:21:53 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r24KLpst3082914 for ; Mon, 4 Mar 2013 15:21:51 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r24KLpWl3070758; Mon, 4 Mar 2013 15:21:51 -0500 (EST)
Date: Mon, 4 Mar 2013 15:21:51 -0500 (EST)
Message-Id: <201303042021.r24KLpWl3070758@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: rtcweb@ietf.org
In-reply-to: <112a01ce16ae$a1720d90$e45628b0$@cisco.com> (dwing@cisco.com)
References: 	<7594FB04B1934943A5C02806D1A2204B10B717@ESESSMB209.ericsson.se>	<03FBA798AC24E3498B74F47FD082A92F36EA7EAB@US70UWXCHMBA04.zam.alcatel-lucent.com> <201303011558.r21FwfGb2830347@shell01.TheWorld.com> <112a01ce16ae$a1720d90$e45628b0$@cisco.com>
Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 04 Mar 2013 20:22:02 -0000

> From: "Dan Wing" 
> 
> The analysis should also examine impact of port-based QoS on 
> multiplexing data over the same port as audio.  Even audio and
> video often prefer different drop precedence.  I know the general
> consensus is to just supply more bandwidth, yet we consume all 
> available bandwidth much like disk space, memory, and CPU/GPU 
> cycles.

As Harald mentioned, since you can have more than one bundle in a
single session description, you can prescribe one bundle for the audio
and one for the video, and give different QoS parameters for each
bundle.

> From: Michael Tuexen 
> 
> Sorry, I don't understand what you are saying. Which document
> describes the stack you are referring to? How would encryption be
> done for SCTP over UDP over IP?

http://tools.ietf.org/html/draft-worley-sdp-bundle-04, section 8, as I
provided in the original message.

You get two variants of the problem, one where you multiplex all the
streams, and then apply DTLS, the other where you encrypt each stream
separately (SRTP, SRTCP, SCTP-over-DTLS) and then multiplex them.  The
analysis of how to demultiplex differs slightly in the two cases.

> From: Salvatore Loreto 
> 
> Dale: can you clarify which scenario you have in mind when you say:
> "Controlling port numbers is needed if SCTP is *not* encapsulated in 
> DTLS and yet has to be distinguished from RTP et al."
> is it a WebRTC usage or a usage for a different aim (maybe CLUE?)

Actually, I'm analyzing the situation in abstract.  Since it turns out
to be straightforward to demultiplex in the general case, the solution
isn't limited to specific scenarios.

> From: Bernard Aboba 
> 
> Why would we want unsecured SCTP either for the WebRTC data channel or
> CLUE signaling? Let's not invent problems when we have enough real
> ones.

The question would arise if one multiplexed the various streams
*before* encrypting them, then the demultiplexing problem is slightly
different.

In this case, we can straightforwardly solve a general problem, which
includes the current real problems, and possibly other real problems
we don't yet know that we'll have.

Dale

From stewe@stewe.org  Mon Mar  4 12:35: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 5E10921F8F9F for ; Mon,  4 Mar 2013 12:35:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.598
X-Spam-Level: 
X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 0bwOih0UTMAa for ; Mon,  4 Mar 2013 12:35:09 -0800 (PST)
Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2931A21F8F7A for ; Mon,  4 Mar 2013 12:35:05 -0800 (PST)
Received: from mail93-db3-R.bigfish.com (10.3.81.233) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Mon, 4 Mar 2013 20:35:04 +0000
Received: from mail93-db3 (localhost [127.0.0.1])	by mail93-db3-R.bigfish.com (Postfix) with ESMTP id 9CD921A0128; Mon,  4 Mar 2013 20:35:04 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT002.namprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -21
X-BigFish: PS-21(zzbb2dI98dI9371Ic85eh1447Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL8275bh8275dh18c673hz2fh2a8h668h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h)
Received-SPF: pass (mail93-db3: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT002.namprd07.prod.outlook.com ; .outlook.com ; 
Received: from mail93-db3 (localhost.localdomain [127.0.0.1]) by mail93-db3 (MessageSwitch) id 1362429301364113_12681; Mon,  4 Mar 2013 20:35:01 +0000 (UTC)
Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.227])	by mail93-db3.bigfish.com (Postfix) with ESMTP id 4D0643C0045; Mon,  4 Mar 2013 20:35:01 +0000 (UTC)
Received: from BL2PRD0710HT002.namprd07.prod.outlook.com (157.56.240.133) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 4 Mar 2013 20:35:00 +0000
Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.145]) by BL2PRD0710HT002.namprd07.prod.outlook.com ([10.255.102.37]) with mapi id 14.16.0275.006; Mon, 4 Mar 2013 20:34:58 +0000
From: Stephan Wenger 
To: Harald Alvestrand 
Thread-Topic: [rtcweb] Input to Video Codec Selection
Thread-Index: AQHOFohSMw+r3b1CrUOO2rY1Kr1TypiRaTwAgADCggCAAX//gIABsX0AgAAfDQA=
Date: Mon, 4 Mar 2013 20:34:57 +0000
Message-ID: 
In-Reply-To: <51347AE2.7020401@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.255.102.4]
Content-Type: multipart/alternative; boundary="_000_CD5A30D19603Cstewesteweorg_"
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Input to Video Codec Selection
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 04 Mar 2013 20:35:10 -0000

--_000_CD5A30D19603Cstewesteweorg_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Harald,

First, let me remark that I believe you are avoiding a reply to my original=
 comment, and instead open a somewhat new discussion.  My original comment =
was that asserting that there is no change in the disclosure situation betw=
een leaving VP8 as RFC 6386 "as is" versus discussion of VP8 in a WG does n=
ot change the obligations by policy.  I concurred, but stated that it will,=
 in practice, swipe in additional contributors that have an obligation by p=
olicy to disclose.  I continue to believe that this is true, and have not s=
een any assertion to the contrary.

With respect to the new topic, disclosure obligation in the rtcweb WG--whic=
h merely discusses referencing the VP8 spec, rather than developing it or t=
inkering with it technically--please see inline.  I hope that my markings a=
re acceptable.

Stephan


From: Harald Alvestrand >
Date: Monday, 4 March, 2013 02:43
To: Stephan Wenger >
Cc: "rtcweb@ietf.org" >
Subject: Re: [rtcweb] Input to Video Codec Selection

On 03/03/2013 05:52 PM, Stephan Wenger wrote:
Hi Harald,
Thanks for these candid answers.  I have a few comments, marked in blue and=
 with StW:
Stephan
Speaking with my IETF-amateur-lawyer hat on (and as a former chair of the I=
PR WG): No, it does not change the rule. The rule depends on whether the te=
chnology in question is discussed in the IETF, not on the nature of the con=
tribution. RFC 3979 section 6.1.2 refers to "Contribution", the definition =
of that term in RFC 3979 section 1 letter j makes it completely explicit th=
at RFC Editor Contributions are covered by the term "Contribution".

---- below here is StW ---

StW; While this answer IMO correctly interprets the language of BCP79, you =
answer the question IMO to directly.  Therefore, the answer is somewhat mis=
leading in it misses to mention an important point:

The main (sole?) purpose of an IETF WG is to facilitate consensus building,=
 which necessarily involves more than one party, and those contributing to =
the discussions (belonging to more than one party) have a disclosure obliga=
tion.  To which extent there is real discussion and consensus building depe=
ndent from draft to draft and WG to WG, but there is at least some.

ISE submissions, like the draft that lead to RFC 6386, OTOH, are almost alw=
ays NOT the result of a multiparty consensus building process.  Quite commo=
nly, they involved only a small authors' group, often from the same company=
.  That's the case here.  No technical community input from IETF participan=
ts was received in an IETF context, no WG consensus was required, and the I=
ESG "no conflict" statement is also no indication of IETF consensus.

Insofar, almost inevitably, the disclosure obligations for an ISE submissio=
n are different in practice.  In this case, it appears that only the author=
s (and perhaps the IESG members=97I'm not clear on this point) had a disclo=
sure obligation.  Which they fulfilled.
/StW


I don't know how much the blue survives, email formatting is still hit-and-=
miss, but I hope this makes sense still.... this is still from my IETF amat=
eur lawyer perspective, and shouldn't be taken as a Google position in any =
way.

I've always worked on the assumption that the RFC 3979 disclosure rules app=
lied only when I was part of the discussion - but that it applied to anythi=
ng brought into the discussion, including RFCs that I had not heard about b=
efore.

Up until here, I'm mostly with you.  I'm not sure I would need to disclose =
just because, during the discussion of draft "foo", someone brought in the =
idea that RFC "bar" has some relationship with the subject matter discussed=
.  I would probably see to what extent I need to comment on the *technical*=
 features of "bar" before making a decision.  If I were not to comment on t=
hose technical features, I would not disclose; otherwise, I would.


Thus, I don't believe the submission, editing and publication of RFC 6386 t=
riggered a disclosure obligation on anyone except those involved in the sub=
mission and editing process

Agreed.

- but I believe that the moment a submission was made to the RTCWEB working=
 group saying "VP8 should be a mandatory to implement codec for RTCWEB", pa=
rticipants who "reasonably and personally" knew of "IPR that is owned direc=
tly or indirectly, by the individual or his/her employer or sponsor (if any=
) or that such persons otherwise have the right to license or assert" (3979=
 section 6.6) were placed under the obligation of RFC 3979 section 6.1.2 (I=
PR in the contributions of others).

Perhaps.
Just assuming that your interpretation would hold water in a court, I'm not=
 sure that there would be that much practical difference in terms of number=
s of patents that would be held unenforcible due to policy violations throu=
gh non-disclosure.  The group of people who can competently discuss things =
like data channel setup or trickle ICE in context of O/A, and the group of =
people who not only read the VP8 spec (which, I understand, is no-go-territ=
ory for quite a few individuals) but also have an understanding of video co=
ding and a fair knowledge of their employer's video coding related patent p=
ortfolio, is rather limited.  That is probably why we have not seen all tha=
t many IPR disclosures against RFC6386.  Not any perceived or real policy v=
iolations.

But also: Perhaps not.
The Contributions folks make in the context of the rtcweb codec selection d=
iscussion is targeted towards the rtcweb I-Ds.  There is no IETF precedence=
 that I'm aware of where a disclosure has been made against a spec that mer=
ely references an encumbered technology specified in an RFC, like VP8.  To =
the contrary, AFAIK, WGs like RMT or FECFRAME have been careful to distingu=
ish the encumbered redundancy coding schemes from the non-encubered base sp=
ec.  (And these are IETF technologies, not just ISE RFCs=97something that o=
ught to be closer to the typical IETF participant's heart than such ISE RFC=
Ss=97though I already agreed with you that from a policy viewpoint, RFC is =
RFC, no matter the stream). The same ought to apply here.  Insofar, a discl=
osure obligation would be triggered only against the VP8 spec itself.

With respect to that, I don't believe that mere mentioning of essentially p=
olitical arguments (like performance, commercial environment considerations=
 etc.) in conjunction with a spec triggers a disclosure obligation.  Again,=
 I think I can support this with the common practice in WGs commonly dealin=
g with encumbered technologies, like (previously) AVT (and now) PAYLOAD.  F=
or example, I contributed to the development of the I-D for the VP8 payload=
 spec, knowing that I incur a disclosure obligation against this spec, and =
honoring that obligation by arranging a disclosure.  I was never asked, nor=
 did I ever have a sense in the room of an expectation, that I would need t=
o disclose what I may know of the VP8 spec itself and/or the relationship o=
f our patent portfolio to it.  Nor did that ever happen in the discussion o=
f other payload specs; see also below.   And that despite of the fact that =
AVT and PAYLOAD, in the context of discussing the finer features of media c=
odecs, necessarily have to dig deep into some technical features of these c=
odecs, leading to quite technical discussions well beyond those IMO politic=
al noise and meta arguments that are visible in rtcweb with respect to code=
c selection.


(In the same way, I believe the submission saying "H.264 should be a mandat=
ory to implement codec for RTCWEB", detailed in draft-marjou-rtcweb-video-c=
odec among others, triggered a requirement for similar disclosure of IPR in=
 H.264 technology. I believe the chairs earlier stated which draft such IPR=
 claims should be filed against, but I don't have that message in front of =
me at the moment.)

Here I absolutely disagree.  It would be against the tradition of the IETF =
to comment about IPR included in specs of other organizations.  I have not =
seen a single IPR disclosure pertaining to a media codec in the IETF IPR da=
tabase, although there are tons of references to known-as-encumbered media =
coding specs in, for example, RTP payload formats; and those specs extensiv=
ely comment on the technical features of these non-IETF media codec specs..=
 This is a discussion that, in other fori, is known as the "normative refer=
ence discussion": is there a need for a disclosure of rights pertaining to =
subject matter against a referencing spec that includes the subject matter =
by reference only.  Very few, if any, SDOs require such disclosures, mostly=
 for practical reasons.  The same reasons seem to apply here as well.









--_000_CD5A30D19603Cstewesteweorg_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <0E89400991974A4380B928944726B383@namprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable







Hi Harald,







First, let me remark that I&nb=
sp;believe you are avoiding a reply to my original comment,
 and instead open a somewhat new discussion.  My original co=
mment was that asserting that there is no change in the disclosure situatio=
n between leaving VP8 as RFC 6386 "as is" versus discussion of VP=
8 in a WG does not change the obligations by policy.  I concurred=
,
 but stated that it will, in practice, swipe in additional contributors tha=
t have an obligation by policy to disclose.  I continue to believe that=
 this is true, and have not seen any assertion
 to the contrary.







With respect=
 to the new topic, disclosure obligation in the rtcweb WG--which merely dis=
cusses referencing the VP8 spec, rather than developing it or tinkering&nbs=
p;with it
 technically--please see inline.  I hope that my markings are acc=
eptable.







Stephan


















From: Harald Alvestrand <harald@alvestrand.no>

Date: Monday, 4 March, 2013 02:43 <=
br>
To: Stephan Wenger <stewe@stewe.org>

Cc: "rtcweb@ietf.org" <=
rtcweb@ietf.org>

Subject: Re: [rtcweb] Input to Vide=
o Codec Selection

















On 03/03/2013 05:52 PM, Stephan Wenger wrote=
:






Hi Harald,


Thanks for these candid answers.  I have =
a few comments, marked in blue and with StW:


Stephan

Speaking with my IETF-amateur-lawyer hat on (and as a former chair of the I=
PR WG): No, it does not change the rule. The rule depends on whether the te=
chnology in question is discussed in the IETF, not on the nature of the con=
tribution. RFC 3979 section 6.1.2
 refers to "Contribution", the definition of that term in RFC 397=
9 section 1 letter j makes it completely explicit that RFC Editor Contribut=
ions are covered by the term "Contribution".







---- below here is StW ---












StW; While this answer IMO correctly interpret=
s the language of BCP79, you answer the question IMO to directly.  The=
refore, the answer is somewhat misleading in it misses to mention an import=
ant point: 







The main (sole?) purpose of an IETF WG is to f=
acilitate consensus building, which necessarily involves more than one part=
y, and those contributing to the discussions (belonging to more than one pa=
rty) have a disclosure obligation.
  To which extent there is real discussion and consensus building depe=
ndent from draft to draft and WG to WG, but there is at least some.<=
/div>






ISE submissions, like the draft that lead to R=
FC 6386, OTOH, are almost always NOT the result of a multiparty consensus b=
uilding process.  Quite commonly, they involved only a small authors' =
group, often from the same company.  That's
 the case here.  No technical community input from IETF participants w=
as received in an IETF context, no WG consensus was required, and the IESG =
"no conflict" statement is also no indication of IETF consensus.<=
/font>







Insofar, almost inevitably, the disclosure obl=
igations for an ISE submission are different in practice.  In this cas=
e, it appears that only the authors (and perhaps the IESG members=97I'm not=
 clear on this point) had a disclosure obligation.
  Which they fulfilled.


/StW






I don't know how much the blue survives, email formatting is still hit-and-=
miss, but I hope this makes sense still.... this is still from my IETF amat=
eur lawyer perspective, and shouldn't be taken as a Google position in any =
way.



I've always worked on the assumption that the RFC 3979 disclosure rules app=
lied only when I was part of the discussion - but that it applied to anythi=
ng brought into the discussion, including RFCs that I had not heard about b=
efore.














Up until here, I'm mostly with you.  I'm not s=
ure I would need to disclose just because, during the discussion of draft &=
quot;foo", someone brought in the idea that RFC "bar" has so=
me relationship with the subject matter discussed.  I would
 probably see to what extent I need to comment on the *technical* features =
of "bar" before making a decision.  If I were not to comment=
 on those technical features, I would not disclose; otherwise, I would.









Thus, I don't believe the submission, editing and publication of RFC 6386 t=
riggered a disclosure obligation on anyone except those involved in the sub=
mission and editing process

Agreed.

- but I believe that the moment a= submission was made to the RTCWEB working group saying "VP8 should be= a mandatory to implement codec for RTCWEB", participants who "re= asonably and personally" knew of "IPR that is owned directly or indirectly, by the individual or his/her employer or sponsor (= if any) or that such persons otherwise have the right to license or assert&= quot; (3979 section 6.6) were placed under the obligation of RFC 3979 secti= on 6.1.2 (IPR in the contributions of others).

Perhaps.  
Just assuming that= your interpretation would hold water in a court, I'm not sure th= at there would be that much practical difference in terms of numb= ers of patents that would be held unenforcible due to policy violations through non-disclosure.  The group of people w= ho can competently discuss things like data channel setup or trickle ICE in context of O/A, and the group of people wh= o not only read the VP8 spec (which, I understand, is no-go-territory for quite a few individuals) but also have a= n understanding of video coding and a fair knowledge of their employer's vi= deo coding related patent portfolio, is rather limited.  That is probably why we have not seen all that many = IPR disclosures against RFC6386.  Not any perceived or real poli= cy violations.

But also: Perhaps not.  
The Contributions = folks make in the context of the rtcweb codec selection discussion is targe= ted towards the rtcweb I-Ds.  There is no IETF preceden= ce that I'm aware of where a disclosure has been made against a spec that merely references an encumbered technology specified in an RFC= , like VP8.  To the contrary, AFAIK, WGs like RMT or FECFRAME have bee= n careful to distinguish the encumbered redundancy coding schemes from the non-encubered base spec.  (And these are IETF techno= logies, not just ISE RFCs=97something that ought to be closer to the typica= l IETF participant's heart than such ISE RFCSs=97though I already agreed with you that from a policy viewpoint, RFC is RFC, no matte= r the stream). The same ought to apply here.  Insofar, a di= sclosure obligation would be triggered only against the VP8 spec itself.

With respect&= nbsp;to that, I don't believe that mere mentioning of essentially= political arguments (like performance, commercial environment consideratio= ns etc.) in conjunction with a spec triggers a disclosure obligation.  Again, I think I can support this wi= th the common practice in WGs commonly dealing with encumbered technol= ogies, like (previously) AVT (and now) PAYLOAD.  For example, I&n= bsp;contributed to the development of the I-D for the VP8 pa= yload spec, knowing that I incur a disclosure obligation against this spec, and hono= ring that obligation by arranging a disclosure.  I was never aske= d, nor did I ever have a sense in the room of an expectation, tha= t I would need to disclose what I may know of the VP8 s= pec itself and/or the relationship of our patent portfolio to it.  Nor did that = ever happen in the discussion of other payload specs; see also below.  = ; And that despite of the fact that AVT and PAYLOAD, in the context&nb= sp;of discussing the finer features of media codecs, necessarily have to dig deep into some technical features of these codecs,= leading to quite technical discussions well beyond those IMO political noi= se and meta arguments that are visible in rtcweb with respect to = codec selection. 


(In the same way, I believe the submission saying "H.264 should be a m= andatory to implement codec for RTCWEB", detailed in draft-marjou-rtcw= eb-video-codec among others, triggered a requirement for similar disclosure= of IPR in H.264 technology. I believe the chairs earlier stated which draft such IPR claims should be filed against,= but I don't have that message in front of me at the moment.)

Here I absolutely disagree.  It would be = against the tradition of the IETF to comment about IPR included in specs of= other organizations.  I have not seen a single IPR disclosure pertaining to a media codec in the IETF I= PR database, although there are tons of references to known-as-encumbered m= edia coding specs in, for example, RTP payload formats; and those specs ext= ensively comment on the technical features of these non-IETF media codec specs.. This is = a discussion that, in other fori, is known as the "normative= reference discussion": is there a need for a disclosure of rights pertaining to subject matter ag= ainst a referencing = ;spec that includes the subject matter by reference only.  Very few, if any= , SDOs require such disclosures, mostly for practical reasons.  The sa= me reasons seem to apply here as well.








--_000_CD5A30D19603Cstewesteweorg_-- From fandreas@cisco.com Mon Mar 4 13:42: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 62DCA21F8429 for ; Mon, 4 Mar 2013 13:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 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 i7FEJOpe4I3N for ; Mon, 4 Mar 2013 13:42:18 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 99ACA21F8D42 for ; Mon, 4 Mar 2013 13:42:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3021; q=dns/txt; s=iport; t=1362433338; x=1363642938; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=6nur8TTIw+l3Cm9zZwhOebWR5u8Bwto1qWeJabJHkrA=; b=QpurE99wydxoymSUCQ0hF2oJVBoD79sN7L6ynU3bhPJZaDUD9TaGT/vm +9h5BWt30YIavsA0Pr+YiKdBMwXXWoW8GrCkooEV04kRdGa3QhvNLipiS a3myIhpNO6zR47M2smQwd/YP1hmLtn/esxsMpwXTBOJ8tixjWJCggybIi w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAIQUNVGtJV2d/2dsb2JhbABEjCu2KYEJFnOCHwEBAQQBAQFrCg0EDw0DAQIKFg8JAwIBAgEVJgIIBg0GAgEBiA8MwUUEjnsGEgaDOgOIbI1akGyDJg X-IronPort-AV: E=Sophos;i="4.84,783,1355097600"; d="scan'208,217";a="180667746" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 04 Mar 2013 21:42:16 +0000 Received: from rtp-fandreas-8713.cisco.com (rtp-fandreas-8713.cisco.com [10.117.7.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r24LgFYJ020571 for ; Mon, 4 Mar 2013 21:42:15 GMT Message-ID: <51351537.5010603@cisco.com> Date: Mon, 04 Mar 2013 16:42:15 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <5135150D.6070709@cisco.com> In-Reply-To: <5135150D.6070709@cisco.com> X-Forwarded-Message-Id: <5135150D.6070709@cisco.com> Content-Type: multipart/alternative; boundary="------------080208070605090305050601" Subject: [rtcweb] Fwd: [MMUSIC] Updated and Final MMUSIC Agenda for IETF 86 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Mar 2013 21:42:19 -0000 This is a multi-part message in MIME format. --------------080208070605090305050601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI -------- Original Message -------- Subject: [MMUSIC] Updated and Final MMUSIC Agenda for IETF 86 Date: Mon, 4 Mar 2013 16:41:33 -0500 From: Flemming Andreasen To: mmusic The final MMUSIC agenda for IETF 86 has been posted at: https://datatracker.ietf.org/meeting/86/agenda/mmusic/ Please note that we have had to shuffle things around quite a bit, however the overall agenda items are still the same. Thanks Ari & Flemming _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --------------080208070605090305050601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI


-------- Original Message --------
Subject: [MMUSIC] Updated and Final MMUSIC Agenda for IETF 86
Date: Mon, 4 Mar 2013 16:41:33 -0500
From: Flemming Andreasen <fandreas@cisco.com>
To: mmusic <mmusic@ietf.org> 


The final MMUSIC agenda for IETF 86 has been posted at:

    https://datatracker.ietf.org/meeting/86/agenda/mmusic/

Please note that we have had to shuffle things around quite a bit, 
however the overall agenda items are still the same.

Thanks

    Ari & Flemming
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


--------------080208070605090305050601-- From espeberg@cisco.com Mon Mar 4 14:31: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 2FBA311E80A2 for ; Mon, 4 Mar 2013 14:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[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 kdj0ZaHyHm-y for ; Mon, 4 Mar 2013 14:31:51 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF9711E80A3 for ; Mon, 4 Mar 2013 14:31:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4341; q=dns/txt; s=iport; t=1362436311; x=1363645911; h=from:to:cc:subject:date:message-id:mime-version; bh=fNTMRxCXoV3nffGu5McVX7ND8wbOkfpOglgUxuJrsc4=; b=kAO0OPuuPCFkIGpNY8gz0wLpWTzyajg6R830cV+M8VAp/HN7PzKXGBBe 8PiQxohInm+pFofjN16LnOMv+sieHsVq8sPTZGqgmgoErEwkMaj3goJHT putUTGmdBbogi62nxm4cGnAto/mLjIXv5UCm+Ea12MW3JCaC2CvfyOrmj w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGggNVGtJXG//2dsb2JhbABEgkPAEYELFnOCIQEELUwSASpWJgEEDg2IC8EKjlsxaoF8YQOnMoJ7DYIn X-IronPort-AV: E=Sophos;i="4.84,783,1355097600"; d="scan'208,217";a="180683413" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 04 Mar 2013 22:31:51 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r24MVoUH030752 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Mar 2013 22:31:50 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.247]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Mon, 4 Mar 2013 16:31:50 -0600 From: "Espen Berger (espeberg)" To: "rtcweb@ietf.org" Thread-Topic: Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01 Thread-Index: Ac4ZKAtdmGresaKASfu3i2cequ4EgA== Date: Mon, 4 Mar 2013 22:31:50 +0000 Message-ID: Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.161.21] Content-Type: multipart/alternative; boundary="_000_E8F5F2C7B2623641BD9ABF0B622D726D0F68869Exmbrcdx11ciscoc_" MIME-Version: 1.0 Cc: "rtcweb-chairs@tools.ietf.org" Subject: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Mar 2013 22:31:52 -0000 --_000_E8F5F2C7B2623641BD9ABF0B622D726D0F68869Exmbrcdx11ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I would like to request agenda time for: draft-marjou-rtcweb-audio-codecs-for-interop-01 The document presents use-cases underlining why WebRTC needs AMR-WB, AMR = and G.722 as additional relevant voice codecs to satisfactorily ensure inte= roperability with existing systems. A 10-minute time slot should be sufficient for presentation and discussion. Regards -Espen --_000_E8F5F2C7B2623641BD9ABF0B622D726D0F68869Exmbrcdx11ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I would like to request agen= da time for:

 

draft-marjou-rtcweb-audio-co= decs-for-interop-01

 

The document  presents = use-cases underlining why WebRTC needs AMR-WB,  AMR and G.722 as addit= ional relevant voice codecs to satisfactorily ensure interoperability with = existing systems.

 

A 10-minute time slot should= be sufficient for presentation and discussion.

 

Regards

 

-Espen

 

 

--_000_E8F5F2C7B2623641BD9ABF0B622D726D0F68869Exmbrcdx11ciscoc_-- From juberti@google.com Mon Mar 4 15:30: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 992D921F87BA for ; Mon, 4 Mar 2013 15:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_56=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 4WJU1dqaz7pu for ; Mon, 4 Mar 2013 15:30:24 -0800 (PST) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id C295221F8698 for ; Mon, 4 Mar 2013 15:30:21 -0800 (PST) Received: by mail-qe0-f47.google.com with SMTP id q19so4266177qeb.6 for ; Mon, 04 Mar 2013 15:30:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=S+lLTjYIhtDTkKEwL/lyxbbHgBCEgTMSPwlV1zFQxHs=; b=loAveMLLCmOaQytCNkXrn7jiJBnzRAZxwk22B3ccoiftGN4R6X8596WlD8DUjzfvJ3 2Uu/NtoxB/2CXUqkgZjxUSCCqqGYyaP2EGbLtWvyoQEjX+hZ6N0O9sNf0TSz7BsthJPA jxY8u8E+JXvM5pDYd78xzWPiyiK8f1tk5rz61rRIKzt2sxwAEMNZzi7Gl/F35WdWGLZW TaCloJGJ11tzba0i9agIuOZ89YAcEer7GBV2FoIK8B7/+oRZFReDbC29TJ0/7XWEoldA x80RBEI7P9mDhN5LePR+O+ZxvDzrw9dDLdDyon5zyO6qn/pbtEicsayVKSdBRmjZ/f0w R/Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=S+lLTjYIhtDTkKEwL/lyxbbHgBCEgTMSPwlV1zFQxHs=; b=ZBC51mM3gqQykSd4nuFbVldNDIgYb1v/wpZYULzOzRPGsbhxyHiUdR/hsWvYPGGIGb znq3fvROwsVidMPOOMMr9gDFGQ9RGJ74oHy8jgPhmbslRbi5tMOi4VLowuO1mN2MJhZj 70Vpnc4yZWPCRRh2CiFEb12tPwc5zAqsZHWBAZf/5Oo5Vx1Q3/CSbEcp6sDg962coaLx l9ViZMRwzTWj0XjwBBxh1Sun8ecN/je2vni63gCDQW5dvGtQNoM2x6CGAyZ6uxccCht9 v/ISc+8pEfSCMTyzLMbNKLoJ/7QWDDZQ/iEU3sGBf/HgHv38XImJ1N0OJS8zfelTtIoq fepg== X-Received: by 10.229.135.207 with SMTP id o15mr7638305qct.34.1362439821192; Mon, 04 Mar 2013 15:30:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.206.17 with HTTP; Mon, 4 Mar 2013 15:30:00 -0800 (PST) In-Reply-To: References: <95790319-C42C-48E2-A6FD-0E718CCF48FB@csperkins.org> From: Justin Uberti Date: Mon, 4 Mar 2013 15:30:00 -0800 Message-ID: To: Ted Hardie Content-Type: multipart/alternative; boundary=00248c7690fe9215bc04d721bd17 X-Gm-Message-State: ALoCoQmQOnhPS9SC5HunAAHHsJmVwG1SOd9yqNfYJBImLNu95TXXo09qGSs1rQK8Snsuzus+JBLgNNboPrOCb7IZCNBcAL6U3vdwi9W1EdTeB2Rtha64Y9PzT6mNaryFRCZ81zlJn4i0GnyudqIh9+vrGVKi2rzVWou+4Rj8ZC9wj+W4QZjwgIrmgCEW4R24HcpMNiY9+P2f Cc: "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] Reminder: Working group last call for draft-ietf-rtcweb-security-arch X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Mar 2013 23:30:25 -0000 --00248c7690fe9215bc04d721bd17 Content-Type: text/plain; charset=UTF-8 I already sent mail to Eric on this, but one thing that needs consideration in this draft is the use case identified in section 4.2.7 of draft-ietf-rtcweb-use-cases-and-requirements-06, i.e. desktop sharing. Section 5.2 of the security doc covers the requirements for consent for camera access, but not for desktop access. On Mon, Mar 4, 2013 at 8:43 AM, Ted Hardie wrote: > Hi Colin, > > Thanks for reviewing the document. As you note, there are open > issues; 5.1, for example, has this: > > "This is a deliberate implementation complexity versus security tradeoff. > [[ OPEN ISSUE:: Should we be more aggressive about this?]]" > > As far as I am aware,though, the document in each case includes a > proposal for the Open Issue, > and it is that which would be in a WG document post last-call. But if > folks looked at the document > and answered the "open issues" within, that would certainly be very > welcome input. > > Were there any Open Issues or other points you wanted to comment on > directly? > > Ted > > > but there > > On Mon, Mar 4, 2013 at 4:58 AM, Colin Perkins wrote: > > Ted, > > > > This draft has a number of places where open issues are noted (e.g., in > Sections 5.1 and 5.5, but there are many others). It seems premature to > issue a working group last call until those are resolved. > > > > Colin > > > > > > > > On 25 Feb 2013, at 23:27, Ted Hardie wrote: > >> This is a reminder that there is an ongoing last call for > >> draft-ietf-rtcweb-security-arch-06. Please send comments, including > >> those of the "reviewed and no issues" ilk, by March 9th, 2012. > >> > >> regards, > >> > >> Ted Hardie > >> > >> On Thu, Feb 14, 2013 at 8:35 AM, Ted Hardie wrote: > >>> This begins a working group last call for > >>> draft-ietf-rtcweb-security-arch. Please send comments to the list by > >>> March 9, 2013. > >>> > >>> regards, > >>> > >>> Ted, Cullen, Magnus > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > > > -- > > Colin Perkins > > http://csperkins.org/ > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --00248c7690fe9215bc04d721bd17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I already sent mail to Eric on this, but one thing that ne= eds consideration in this draft is the use case identified in section 4.2.7= of draft-ietf-rtcweb-use-cases-and-requirements-06, i.e. desktop sharing. = Section 5.2 of the security doc covers the requirements for consent for cam= era access, but not for desktop access.


On Mon, Mar 4= , 2013 at 8:43 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
Hi Colin,

Thanks for reviewing the document. =C2=A0As you note, there are open
issues; 5.1, for example, has this:

"This is a =C2=A0deliberate implementation complexity versus security = tradeoff.
=C2=A0[[ OPEN ISSUE:: =C2=A0Should we be more aggressive about this?]]"= ;

As far as I am aware,though, the document in each case includes a
proposal for the Open Issue,
and it is that which would be in a WG document post last-call. =C2=A0But if=
folks looked at the document
and answered the "open issues" within, that would certainly be ve= ry
welcome input.

Were there any Open Issues or other points you wanted to comment on directl= y?

Ted


but there

On Mon, Mar 4, 2013 at 4:58 AM, Colin Perkins <csp@csperkins.org> wrote:
> Ted,
>
> This draft has a number of places where open issues are noted (e.g., i= n Sections 5.1 and 5.5, but there are many others). It seems premature to i= ssue a working group last call until those are resolved.
>
> Colin
>
>
>
> On 25 Feb 2013, at 23:27, Ted Hardie wrote:
>> This is a reminder that there is an ongoing last call for
>> draft-ietf-rtcweb-security-arch-06. =C2=A0Please send comments, in= cluding
>> those of the "reviewed and no issues" ilk, by March 9th,= 2012.
>>
>> regards,
>>
>> Ted Hardie
>>
>> On Thu, Feb 14, 2013 at 8:35 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
>>> This begins a working group last call for
>>> draft-ietf-rtcweb-security-arch. =C2=A0Please send comments to= the list by
>>> March 9, 2013.
>>>
>>> regards,
>>>
>>> Ted, Cullen, Magnus
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> --
> Colin Perkins
> http://csperkins.o= rg/
>
>
>
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--00248c7690fe9215bc04d721bd17-- From ekr@rtfm.com Mon Mar 4 15:36: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 7BB9711E80D9 for ; Mon, 4 Mar 2013 15:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_56=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 QoL7KY0+qa1R for ; Mon, 4 Mar 2013 15:36:42 -0800 (PST) Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by ietfa.amsl.com (Postfix) with ESMTP id D861F11E80D7 for ; Mon, 4 Mar 2013 15:36:40 -0800 (PST) Received: by mail-qe0-f49.google.com with SMTP id 1so4262078qec.22 for ; Mon, 04 Mar 2013 15:36:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=hn4UyfqaQzeIOZ+SjNDQPVFYFI35cCa+h16oe8m/ocs=; b=cH3lhlxSi4Z4jZ0WN8kKDM8W9/vREm3I6tQ9dKpvCl9Rhhi/9tvseJl93dcOO40s1i PZtnjv4o7eBDJgrojFvr+0rRkK5yA9qHuTAoEckXU1G3irfj500UMg8iCJclOkZ9nza+ 2vY9ZZRYi8h40KtaWamqm6Jbsz2ZwiOoKZZDPP0vwtizYKukvaP+dQX1Dck2wfRCSRLb 60mD7krrlHNhLAOLtutzXWYbtsMEwSIpsHucwwin8Q1TqLnwh42fx2IZA4Oq/IGBhjgd asaA+xMbpct1G2vRW1upuoGKtLYxjEZujIXwXoDgrxTB0QAgXb6ixiu0zGzv5OvQldm0 /msQ== X-Received: by 10.49.106.71 with SMTP id gs7mr38298892qeb.21.1362440200204; Mon, 04 Mar 2013 15:36:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.27.230 with HTTP; Mon, 4 Mar 2013 15:36:00 -0800 (PST) X-Originating-IP: [63.245.220.224] In-Reply-To: References: <95790319-C42C-48E2-A6FD-0E718CCF48FB@csperkins.org> From: Eric Rescorla Date: Mon, 4 Mar 2013 15:36:00 -0800 Message-ID: To: Justin Uberti Content-Type: multipart/alternative; boundary=e89a8f921a1e294fb204d721d4df X-Gm-Message-State: ALoCoQnAMzZkOOsrMBctPZQsLujdgocaNtDBoWh3MaQDdMUQecq6Xy+9E7cIGlvE5I9I5DAgNOUf Cc: "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] Reminder: Working group last call for draft-ietf-rtcweb-security-arch X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Mar 2013 23:36:43 -0000 --e89a8f921a1e294fb204d721d4df Content-Type: text/plain; charset=ISO-8859-1 Thanks, Justin. I have been working on something for this and hope to have some text soon. -Ekr On Mon, Mar 4, 2013 at 3:30 PM, Justin Uberti wrote: > I already sent mail to Eric on this, but one thing that needs > consideration in this draft is the use case identified in section 4.2.7 of > draft-ietf-rtcweb-use-cases-and-requirements-06, i.e. desktop sharing. > Section 5.2 of the security doc covers the requirements for consent for > camera access, but not for desktop access. > > > On Mon, Mar 4, 2013 at 8:43 AM, Ted Hardie wrote: > >> Hi Colin, >> >> Thanks for reviewing the document. As you note, there are open >> issues; 5.1, for example, has this: >> >> "This is a deliberate implementation complexity versus security tradeoff. >> [[ OPEN ISSUE:: Should we be more aggressive about this?]]" >> >> As far as I am aware,though, the document in each case includes a >> proposal for the Open Issue, >> and it is that which would be in a WG document post last-call. But if >> folks looked at the document >> and answered the "open issues" within, that would certainly be very >> welcome input. >> >> Were there any Open Issues or other points you wanted to comment on >> directly? >> >> Ted >> >> >> but there >> >> On Mon, Mar 4, 2013 at 4:58 AM, Colin Perkins wrote: >> > Ted, >> > >> > This draft has a number of places where open issues are noted (e.g., in >> Sections 5.1 and 5.5, but there are many others). It seems premature to >> issue a working group last call until those are resolved. >> > >> > Colin >> > >> > >> > >> > On 25 Feb 2013, at 23:27, Ted Hardie wrote: >> >> This is a reminder that there is an ongoing last call for >> >> draft-ietf-rtcweb-security-arch-06. Please send comments, including >> >> those of the "reviewed and no issues" ilk, by March 9th, 2012. >> >> >> >> regards, >> >> >> >> Ted Hardie >> >> >> >> On Thu, Feb 14, 2013 at 8:35 AM, Ted Hardie >> wrote: >> >>> This begins a working group last call for >> >>> draft-ietf-rtcweb-security-arch. Please send comments to the list by >> >>> March 9, 2013. >> >>> >> >>> regards, >> >>> >> >>> Ted, Cullen, Magnus >> >> _______________________________________________ >> >> rtcweb mailing list >> >> rtcweb@ietf.org >> >> https://www.ietf.org/mailman/listinfo/rtcweb >> > >> > >> > >> > -- >> > Colin Perkins >> > http://csperkins.org/ >> > >> > >> > >> _______________________________________________ >> 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 > > --e89a8f921a1e294fb204d721d4df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks, Justin.

I have been working on someth= ing for this and hope to have some text soon.

-Ekr=


On Mon, Mar 4, 2013 at 3:30 P= M, Justin Uberti <juberti@google.com> wrote:
I already sent mail to Eric= on this, but one thing that needs consideration in this draft is the use c= ase identified in section 4.2.7 of draft-ietf-rtcweb-use-cases-and-requirem= ents-06, i.e. desktop sharing. Section 5.2 of the security doc covers the r= equirements for consent for camera access, but not for desktop access.


On Mon, Mar 4= , 2013 at 8:43 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
Hi Colin,

Thanks for reviewing the document. =A0As you note, there are open
issues; 5.1, for example, has this:

"This is a =A0deliberate implementation complexity versus security tra= deoff.
=A0[[ OPEN ISSUE:: =A0Should we be more aggressive about this?]]"

As far as I am aware,though, the document in each case includes a
proposal for the Open Issue,
and it is that which would be in a WG document post last-call. =A0But if folks looked at the document
and answered the "open issues" within, that would certainly be ve= ry
welcome input.

Were there any Open Issues or other points you wanted to comment on directl= y?

Ted


but there

On Mon, Mar 4, 2013 at 4:58 AM, Colin Perkins <csp@csperkins.org> wrote:
> Ted,
>
> This draft has a number of places where open issues are noted (e.g., i= n Sections 5.1 and 5.5, but there are many others). It seems premature to i= ssue a working group last call until those are resolved.
>
> Colin
>
>
>
> On 25 Feb 2013, at 23:27, Ted Hardie wrote:
>> This is a reminder that there is an ongoing last call for
>> draft-ietf-rtcweb-security-arch-06. =A0Please send comments, inclu= ding
>> those of the "reviewed and no issues" ilk, by March 9th,= 2012.
>>
>> regards,
>>
>> Ted Hardie
>>
>> On Thu, Feb 14, 2013 at 8:35 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
>>> This begins a working group last call for
>>> draft-ietf-rtcweb-security-arch. =A0Please send comments to th= e list by
>>> March 9, 2013.
>>>
>>> regards,
>>>
>>> Ted, Cullen, Magnus
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> --
> Colin Perkins
> http://csperkins.o= rg/
>
>
>
_______________________________________________
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


--e89a8f921a1e294fb204d721d4df-- From martin.thomson@gmail.com Mon Mar 4 17:02: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 534FE21F8999 for ; Mon, 4 Mar 2013 17:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, J_CHICKENPOX_56=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 zbI2fBwQd2WK for ; Mon, 4 Mar 2013 17:02:56 -0800 (PST) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4E53D21F893D for ; Mon, 4 Mar 2013 17:02:56 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id dq12so4754954wgb.0 for ; Mon, 04 Mar 2013 17:02:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=CDKBq/Hd2o+IMtkpeKEGew/P5uu8VPw/2m5z5+bHyuM=; b=H5x4TOSfGrEboPm0TQY9lJ+GBy0CN+FTrPpupWwGxI7uHTknskCRwPOhGzNayIUUe1 PkSXOhz6vAh8HzcoVQO8ym7yD3rjgYBakHxFJJLF4yKbx6FSCeHJg4pSw1voO75oAafl nauE9gODFK84mV5Nql+fF/gPbxBQEVX9/LxVtz0Lq5oTtxAPNeNi1AoV5uMry0xjag79 AkgMvyy8Yb+pBveBpI/1MhwTFYN5vDJZcol1c9gCqcpPn2NaUoU6XWlgJgeNt+djsfD8 +Aw1+a1vU8UalDUIvDOeGidAh4Wih/CEOBALIOkgvLulHDuxmxNw8zET47C1U9cLipd/ AINg== MIME-Version: 1.0 X-Received: by 10.180.80.35 with SMTP id o3mr15452687wix.9.1362445375502; Mon, 04 Mar 2013 17:02:55 -0800 (PST) Received: by 10.194.5.135 with HTTP; Mon, 4 Mar 2013 17:02:55 -0800 (PST) In-Reply-To: References: <95790319-C42C-48E2-A6FD-0E718CCF48FB@csperkins.org> Date: Mon, 4 Mar 2013 17:02:55 -0800 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] Reminder: Working group last call for draft-ietf-rtcweb-security-arch X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Mar 2013 01:02:57 -0000 Does the text say: "screen sharing is a bad idea" ? On 4 March 2013 15:36, Eric Rescorla wrote: > Thanks, Justin. > > I have been working on something for this and hope to have some text soon. > > -Ekr > > > On Mon, Mar 4, 2013 at 3:30 PM, Justin Uberti wrote: >> >> I already sent mail to Eric on this, but one thing that needs >> consideration in this draft is the use case identified in section 4.2.7 of >> draft-ietf-rtcweb-use-cases-and-requirements-06, i.e. desktop sharing. >> Section 5.2 of the security doc covers the requirements for consent for >> camera access, but not for desktop access. >> >> >> On Mon, Mar 4, 2013 at 8:43 AM, Ted Hardie wrote: >>> >>> Hi Colin, >>> >>> Thanks for reviewing the document. As you note, there are open >>> issues; 5.1, for example, has this: >>> >>> "This is a deliberate implementation complexity versus security >>> tradeoff. >>> [[ OPEN ISSUE:: Should we be more aggressive about this?]]" >>> >>> As far as I am aware,though, the document in each case includes a >>> proposal for the Open Issue, >>> and it is that which would be in a WG document post last-call. But if >>> folks looked at the document >>> and answered the "open issues" within, that would certainly be very >>> welcome input. >>> >>> Were there any Open Issues or other points you wanted to comment on >>> directly? >>> >>> Ted >>> >>> >>> but there >>> >>> On Mon, Mar 4, 2013 at 4:58 AM, Colin Perkins wrote: >>> > Ted, >>> > >>> > This draft has a number of places where open issues are noted (e.g., in >>> > Sections 5.1 and 5.5, but there are many others). It seems premature to >>> > issue a working group last call until those are resolved. >>> > >>> > Colin >>> > >>> > >>> > >>> > On 25 Feb 2013, at 23:27, Ted Hardie wrote: >>> >> This is a reminder that there is an ongoing last call for >>> >> draft-ietf-rtcweb-security-arch-06. Please send comments, including >>> >> those of the "reviewed and no issues" ilk, by March 9th, 2012. >>> >> >>> >> regards, >>> >> >>> >> Ted Hardie >>> >> >>> >> On Thu, Feb 14, 2013 at 8:35 AM, Ted Hardie >>> >> wrote: >>> >>> This begins a working group last call for >>> >>> draft-ietf-rtcweb-security-arch. Please send comments to the list by >>> >>> March 9, 2013. >>> >>> >>> >>> regards, >>> >>> >>> >>> Ted, Cullen, Magnus >>> >> _______________________________________________ >>> >> rtcweb mailing list >>> >> rtcweb@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/rtcweb >>> > >>> > >>> > >>> > -- >>> > Colin Perkins >>> > http://csperkins.org/ >>> > >>> > >>> > >>> _______________________________________________ >>> 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 randell-ietf@jesup.org Tue Mar 5 02:18: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 D855F21F88E5 for ; Tue, 5 Mar 2013 02:18:36 -0800 (PST) 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 b-CC4x+ULHfz for ; Tue, 5 Mar 2013 02:18:36 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 6573021F88E3 for ; Tue, 5 Mar 2013 02:18:36 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:3485 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UCox9-00097e-HS for rtcweb@ietf.org; Tue, 05 Mar 2013 04:18:35 -0600 Message-ID: <5135C64A.50302@jesup.org> Date: Tue, 05 Mar 2013 05:17:46 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-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, 05 Mar 2013 10:18:37 -0000 On 3/4/2013 9:36 AM, MARCON, JEROME (JEROME) wrote: > Randell, > > Thanks for this update. There are some points not (yet) explained in the text: > > 1. Following the SDP opening handshake, are the data channels implicitly opened, or does the offerer send one DATA_CHANNEL_OPEN message per new data channel ? One Open per new channel which can be followed immediately with data. If the application has some out-of-band way to know about the channels expected (see the text), it could indicate so (effectively allowing application-mediated negotiation with no Open messages in-band - not that I generally would suggest this for normal uses). > 2. "channel is available to send as soon as the DATA_CHANNEL_OPEN has been sent". And the SACK received I guess ? No SACK required I believe. As far as SCTP is concerned, Open messages are just data on the stream. > 3. Assuming an endpoint creating a new offer (e.g. to reflect a change in media streams) while an SCTP association is already established. In this case, what does the SCTP association m-line contain: the unchanged list of data channels contained in the initial offer (which created the SCTP association), or the list of data channels currently opened, or .. ? Just the listing for the association that was in the original offer (though this would be the SCTP SDP MMUSIC draft's issue). > 4. What happens if the SDP Opening Handshake agreed on some data channels using the 'chat' subprotocol, and later on an endpoint creates in-band a new channel with 'file transfer' subprotocol ? When you create a channel, it sends Open on an unused Stream. -- Randell Jesup randell-ietf@jesup.org From stefan.lk.hakansson@ericsson.com Tue Mar 5 03:43: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 0BBA121F8991 for ; Tue, 5 Mar 2013 03:43:06 -0800 (PST) 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=[AWL=0.000, 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 7kFr4VqoLwB5 for ; Tue, 5 Mar 2013 03:43:04 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 60F2821F8988 for ; Tue, 5 Mar 2013 03:43:04 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-9a-5135da475ef7 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 2C.61.19728.74AD5315; Tue, 5 Mar 2013 12:43:03 +0100 (CET) Received: from [150.132.141.119] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Tue, 5 Mar 2013 12:43:02 +0100 Message-ID: <5135DA46.7050909@ericsson.com> Date: Tue, 5 Mar 2013 12:43:02 +0100 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+Jvja77LdNAg+Y5ihZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4+bP62wFx1grLvV2MTYwHmTpYuTkkBAwkdjxbS47hC0mceHe erYuRi4OIYGTjBKdPydDOWsYJb4degpWxSugLbH3YRsjiM0ioCLx4u4rNhCbTSBQ4vr/X0xd jBwcogJRElf2WUKUC0qcnPkEbJmIgLDE1le9TCC2sECsxMGPi8DGCAn4SCzYvhhsPKeAr8TW JZ/A6pkFbCUuzLkOZctLbH87hxmiXlfi3et7rBMYBWYhWTELScssJC0LGJlXMbLnJmbmpJcb bWIEhtnBLb9VdzDeOSdyiFGag0VJnDfc9UKAkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsYq lasZK/aX8N9msLonvPDIDvmlyxTWmK8O2BlrkV11+favVz5NbYY5NwNEfT8fvXtJPWrjYynh KXlRW6ZETHGLzRC7pFbO+/kSg+Tc9Ckbfmmc/H054vSaD5NSbzQsaPeuMPpcW1Dsr8L2JP7Y qpmBtZyrN4smshQ7//P+f4N/8Wo201P7Ns5SYinOSDTUYi4qTgQATqfUHQECAAA= Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Mar 2013 11:43:06 -0000 On 2013-03-04 23:31, Espen Berger (espeberg) wrote: > Hello, > > I would like to request agenda time for: > > draft-marjou-rtcweb-audio-codecs-for-interop-01 > > The document presents use-cases underlining why WebRTC needs AMR-WB, > AMR and G.722 as additional relevant voice codecs to satisfactorily > ensure interoperability with existing systems. I agree to that we should discuss the subject of additional codecs. Stefan > > A 10-minute time slot should be sufficient for presentation and discussion. > > Regards > > -Espen > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From magnus.westerlund@ericsson.com Tue Mar 5 05: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 4BBAF21F888F for ; Tue, 5 Mar 2013 05:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.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, 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 aFnCXu5k6zoW for ; Tue, 5 Mar 2013 05:12:08 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2263921F8871 for ; Tue, 5 Mar 2013 05:12:07 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-40-5135ef272b00 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 11.C0.19728.72FE5315; Tue, 5 Mar 2013 14:12:07 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Tue, 5 Mar 2013 14:12:06 +0100 Message-ID: <5135EF22.10600@ericsson.com> Date: Tue, 5 Mar 2013 14:12:02 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= References: <5130B9C3.3010404@ericsson.com> <1447FA0C20ED5147A1AA0EF02890A64B0BA4DF@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B0BA4DF@ESESSMB209.ericsson.se> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphluLIzCtJLcpLzFFi42KZGfG3Rlf9vWmgQfMxXou1/9rZLbrvOzkw eSzYVOqxZMlPpgCmKC6blNSczLLUIn27BK6Ml3NXMBZclqzYvOIIUwPjA5EuRk4OCQETiZOn rjBD2GISF+6tZ+ti5OIQEjjJKPHw2lxmCGcZo8SplnusIFW8ApoS338uZwGxWQRUJM5vfc0G YrMJWEjc/NEIZHNwiAoES9xcLAdRLihxcuYTsHIRAX+J+U07mEFKmAUCJM491wcxhYFumHBF HqRCSCBbYuKtCWDncAr4SJx+t58V4jRJiS0v2tlBbGYBPYkpV1sYIWx5ieats5kherUlGpo6 WCcwCs1CsngWkpZZSFoWMDKvYmTPTczMSS832sQIDNGDW36r7mC8c07kEKM0B4uSOG+464UA IYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwmqqfS43W1/i2VMCk3aGiODtp35vm+XeqTXh3V 23po9dRAk2wTu+d9r885FrRrv4zT+nNuwg7Xtaf7nXY19S++yV22ytAx89ZxgUm9jy3n9gdX upm8D4rSb1qscUYxxkr4VckWLc7oMKag2zyzZx86/1/vTsSFE95K0Q4XE9muTS+JrPfNn6HE UpyRaKjFXFScCADyuONgHwIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Input to Video Codec Selection X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Mar 2013 13:12:09 -0000 Stefan and WG, We WG chairs can't forbid people to state new things. However, our message was a public prodding of everyone, including Google, that please ensure that you have provided material prior to the discussion. We think that in the interest of fairness and openness that any significant contribution should be made before the actual discussion in the WG. I think the below is a vary valid observation and I hope someone from Google, like Serge can comment if any additional material will be forthcoming. And if it will, then I request that it is provided ASAP so that people can analyze any such information. Cheers Magnus Westerlund (As WG chair) On 2013-03-03 09:44, Stefan Håkansson LK wrote: > I can understand the logic behind not wanting any new input before > the meeting, but at the same time we did postpone this discussion one > meeting cycle on request by Serge [1]. In his request Serge stated > that "Google understands that concerns have been raised within the > IETF RTCWEB WG in regards to VP8 IPR." and "We hereby commit to > addressing this by the next IETF meeting in Orlando. Our proposal > will address prevalent IPR issues." > > I have seen no such input yet, and if no new input is allowed, it > seems like we will have the same discussion we postponed last time > (all inputs look more or less unchanged to me). Is this the plan? > Have the chairs reached out to Google to check the status (perhaps > the IPR related things did encounter some delay, but will be ready > shortly after the meeting)? > > Stefan > > [1] > http://www.ietf.org/mail-archive/web/rtcweb/current/msg05698.html > > -----Original Message----- From: rtcweb-bounces@ietf.org > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlund Sent: > den 1 mars 2013 15:23 Cc: rtcweb@ietf.org Subject: [rtcweb] Input to > Video Codec Selection > > WG, > > I hope everyone, especially Google, now have provided whatever input > they have into the Video Codec discussion and selection. It is > important that everyone has the possibility to evaluate the input in > good time prior to the meeting. It is especially important if one > might require legal or other support when evaluating the proposals or > additional information, which might apply for IPR, as an example. > > To be extremely blunt, we don't want anyone revealing new input > material during the presentations in Orlando. These presentations is > only intended to provide a summary of the most important aspects from > the proponents side. > > > The RTCWEB WG chairs > > Magnus Westerlund Ted Hardie Cullen Jennings > > _______________________________________________ rtcweb mailing list > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > > -- 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 eckelcu@cisco.com Tue Mar 5 09:06: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 874B121F87D2; Tue, 5 Mar 2013 09:06:37 -0800 (PST) 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 AiFQ9D-0-aDc; Tue, 5 Mar 2013 09:06:36 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id A977821F87BA; Tue, 5 Mar 2013 09:06:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1884; q=dns/txt; s=iport; t=1362503196; x=1363712796; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ki+WIgbBNft6w05nY3kHrmSZaVCBZPMW6aPCbtdAInQ=; b=L/h4/FC5TAvCFnaAcE1TQM+jaUDDSI8Qb2qNAPluR6qJDPxv46Hh6Ero VHLXo4CL+A/HTjLW3utwLJFvBU8ZogHqIaCBeRnUkFQX61TfpQ+yMVvfn 6sJ2dSvUffsH3FH/ak5EWUdtRuJqfQv/oqetSDDa9q4tgAuVKzDnwhTDk s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAK8kNlGtJXHB/2dsb2JhbABExG6BaBZzgikBAQEEOksEAgEIEQQBAQsUCQcyFAkIAgQBEgiICgGsZpA0jlwmEgaCWWEDpziDCIIn X-IronPort-AV: E=Sophos;i="4.84,787,1355097600"; d="scan'208";a="183996195" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 05 Mar 2013 17:06:36 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r25H6aIc001909 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Mar 2013 17:06:36 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.144]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Tue, 5 Mar 2013 11:06:36 -0600 From: "Charles Eckel (eckelcu)" To: Ted Hardie , "rtcweb@ietf.org" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Extremely drafty minutes Thread-Index: AQHOFtwkfs1cLJI9OEe4++p7b3Zq05iXWJtA Date: Tue, 5 Mar 2013 17:06:35 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828047C706E@xmb-aln-x08.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] [MMUSIC] Extremely drafty minutes X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Mar 2013 17:06:37 -0000 Hi Ted, Thanks for the notes. It was a challenging session to summarize, so I reall= y appreciate your efforts here. One question I have is in regard to the following point from the Feb 5 summ= ary. " All SSRCs related to a single peer connection (which could encompasses mo= re than one MediaStreams having more than one track) would come from a sing= le SSRC space. " Is this a restatement of an opinion expressed at the mic, or does it carry = some weight as a working group consensus? I recall discussion in this area,= but I did not think consensus was reached that this is the way to go. If t= hat is the case, I think the notes should mention that more discussion is n= eeded. Cheers, Charles > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Ted Hardie > Sent: Friday, March 01, 2013 4:23 PM > To: rtcweb@ietf.org; mmusic@ietf.org > Subject: [MMUSIC] Extremely drafty minutes >=20 > Howdy, >=20 > I've been working on minutes for the interim meeting last month; I've > attached the current draft. It needs *extensive* review, as I had > planned to work off recordings for two days, and they turned out to be > available for only half of one. Several folks have volunteered their > notes, but I have not made nearly enough progress. I've decided that > it's better to have something out than nothing, so here they are, in > the current state. >=20 > Please review them and provide input; I will continue to work on them, > but if we don't get more input, they will be *terrible*. >=20 > My apologies for the plan going awry on this, and for the delay. I > kept hoping that more time spent with them would make them coherent; > in large part, I suspect that helped very little all. Please excuse > that and help us correct it, >=20 > thanks, >=20 > Ted Hardie From pthatcher@google.com Tue Mar 5 09:14: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 6051121F8609 for ; Tue, 5 Mar 2013 09:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 c5AW5om6z0pn for ; Tue, 5 Mar 2013 09:14:16 -0800 (PST) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1C41D21F85ED for ; Tue, 5 Mar 2013 09:14:15 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id p16so4358277vcq.29 for ; Tue, 05 Mar 2013 09:14:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=ZX6JIcx47ev9KCJMhPZMTpOqOl6d1QITeXaStTEDWwQ=; b=O6iC4E8DUgvU4x4HnVDIswBzYgGmRz4ANCEjQUVTp2oHqWA2ICWnTPg2vbZGlJbMsM CefMgj6Pf74tIDnL4gxuiyq2M65iGFzQjy39+paELa57lcsLF6BxfdG55gZFahz1HMN/ 93Debimd9vAwFEiwn5+HXTgKzh8AYjzVuYz9y04gCnRGP7XkBNUZ1VuzZrgYQOM1lvpe +xCE9Qh9vICQZ78cf2HJFwob0u+kmwmyyEBAU9uMjVvf7cUNChABjl+HJ8XY2SEk5Hr2 MvLSddChFVAFCQedSiBpR3M4ZBE2KWMGPaPXfPZ+RrJ3CN3mPwPVNmH2PnZ7dyWR/y4+ qO1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=ZX6JIcx47ev9KCJMhPZMTpOqOl6d1QITeXaStTEDWwQ=; b=UBxIFz+mAexmUCp6czrAprHmQYaormSeZ2McM2XdD8NK0ulSdfm9w2+1Svz7h15xEZ 85Zkh2KtPMCEPuAGkAW34EEFnc0LD8f1oOETHKiT9oLeDpELBNVfTNEyarnfUJGCzC7x zvYeCkXMyxKgSJeVZ9CXKTdLPvJejCGMuj6kbTpl6vK4XhuV5hQ7yt31LcpLY4v+AJal DDp1lCJywVEZJngxGjzoWqdujAUPL8QSr06x7iq2r1/99HStZgdn2As19aISZtisln7+ ucK0tIvk3I582ZQrvVHIi6V7WO0XfHVHhskmfni/ZK/FZj4Z5nK0C8v58zYF6IN0kOjj IaWg== X-Received: by 10.220.153.143 with SMTP id k15mr9810671vcw.33.1362503655441; Tue, 05 Mar 2013 09:14:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.223.171 with HTTP; Tue, 5 Mar 2013 09:13:35 -0800 (PST) In-Reply-To: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> From: Peter Thatcher Date: Tue, 5 Mar 2013 09:13:35 -0800 Message-ID: To: rtcweb@ietf.org, Randell Jesup Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQk00J6w8ZW5zlGilJT3JcQSH2msYUMIiecJMK64nwV0Wi/jt1OLngZ1HnBfQ+bOVANiMvSw3hiHI3V82W0DGpMcs5glEqM1QNKambzZAoKTR7EVRRM65foUPu88yOnznAN5PJojy9gtKmaocehmPS7n3F02KVrtnZoGmD1rnzCovMvGpH6fQUJnfqoaALts7a3RIqfZ Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-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, 05 Mar 2013 17:14:17 -0000 Randell, Thanks for these changes. I think it looks really good, and generally meets everything I've been looking for. On Mon, Feb 25, 2013 at 2:40 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-04.txt > Pages : 13 > Date : 2013-02-25 > > 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-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-data-channel-04 > > > 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 From ted.ietf@gmail.com Tue Mar 5 13:26: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 CEC0421F881D; Tue, 5 Mar 2013 13:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, 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 FpU-Yt34AG4C; Tue, 5 Mar 2013 13:26:26 -0800 (PST) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA9A21F87FF; Tue, 5 Mar 2013 13:26:25 -0800 (PST) Received: by mail-ia0-f169.google.com with SMTP id j5so6775091iaf.0 for ; Tue, 05 Mar 2013 13:26:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=BB7LyMd/ANd7ImshFunJznsj57UMxQPNpd3XUKjfXoU=; b=dZWJxmqkj3PbfBFbUQpKjBxSg8cf+QAtx04077xx8cNgk9RRRVR9q6SMd6vnva1jdJ VFRyheg6G3G2A0CYgIclc4soESFz1V8c7M/pEQ0ViQnf0TozgqfQyfyYMLah3F7kEqcH 0k/W04bzCPZuGeRwXDgN4exLmrGByR7ZPXN9tbjF6JL4Te+eXLSbr6ma+DRfTYIBJr10 D/e97oFpzfW2zJErAx+OdWBvdtUvcYy43+U8FUfrol4m1o+j/IJBCYZ6yz+zEbj9/BBh ytSyk3mtJzSAARZ6a4rm6Z55aGc7EUHbe6INhka6iceBtxIMPQ4yVkqK1P+ew1WUFpln +8nA== MIME-Version: 1.0 X-Received: by 10.50.36.169 with SMTP id r9mr7814974igj.96.1362518784931; Tue, 05 Mar 2013 13:26:24 -0800 (PST) Received: by 10.43.135.202 with HTTP; Tue, 5 Mar 2013 13:26:24 -0800 (PST) In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828047C706E@xmb-aln-x08.cisco.com> References: <92B7E61ADAC1BB4F941F943788C08828047C706E@xmb-aln-x08.cisco.com> Date: Tue, 5 Mar 2013 13:26:24 -0800 Message-ID: From: Ted Hardie To: "Charles Eckel (eckelcu)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" , Harald Tveit Alvestrand Subject: Re: [rtcweb] [MMUSIC] Extremely drafty minutes X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Mar 2013 21:26:27 -0000 On Tue, Mar 5, 2013 at 9:06 AM, Charles Eckel (eckelcu) wrote: > One question I have is in regard to the following point from the Feb 5 su= mmary. > > " All SSRCs related to a single peer connection (which could encompasses = more than one MediaStreams having more than one track) would come from a si= ngle SSRC space. " > > Is this a restatement of an opinion expressed at the mic, or does it carr= y some weight as a working group consensus? I recall discussion in this are= a, but I did not think consensus was reached that this is the way to go. If= that is the case, I think the notes should mention that more discussion is= needed. > My understanding of this is that it was expressed as a requirement by WebRTC on the work of RTCWEB, needed as part of the mechanics of how to plumb connections via the API. The base requirement is "a consistent identifer space for all the media that will be plumbed"; the SSRCs are the identifiers available. I may be mis-stating this, though, so it might be helpful if Stefan or Harald commented, as I think it was one of them that actually expressed it. As context for those who might be able to add their own understanding here, this is the relevant part of the draft minutes: For signaling, among the points raised: CLUE and RTCWEB likely have two different usage patterns. For CLUE, multiple media sources will be common, multiple encodings per media source will be the norm, multiple endpoints may be visible even in unicast transport, and there may be one or more RTP session. For RTCWEB, the current theory is that there is a single RTP session per media type, if not a single RTP session full stop. All SSRCs related to a single peer connection (which could encompasses more than one MediaStreams having more than one track) would come from a single SSRC space. regards, Ted From rhglidden@gmail.com Tue Mar 5 13:47: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 95CF611E80B8 for ; Tue, 5 Mar 2013 13:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.598 X-Spam-Level: X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 N0aMynuRzDcH for ; Tue, 5 Mar 2013 13:46:56 -0800 (PST) Received: from mail-ye0-f172.google.com (mail-ye0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBE311E80AD for ; Tue, 5 Mar 2013 13:46:56 -0800 (PST) Received: by mail-ye0-f172.google.com with SMTP id q9so1114017yen.31 for ; Tue, 05 Mar 2013 13:46:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type; bh=l4XZoUL8WIqv0yoyvyuYq16pDuBb6sNDwMKfgrkqTKQ=; b=SA7nRMklgcsGiDR3hPD0Ayno4BD54dkBv6GTXdO4vOANsQ6KO+VMQ8+KHdnueWkvwL ONiCbAzGs8ukn0zN2ZlsTTI1mUSU1+OUXlzyg5ScFG9M8Boj9CQxf6wiA6RSn/LLi8Fd XgDYBwavb4tK2yxzRIuul6fMhiWj7Hg3jc9HQ1YXSUG+Ty8ThJCJHjvo6o1rc1vA3j+9 pW3rXpr10Dzlm9GB37S7x9F9GaUyPloKsgpvUXppysTS4tA+b27JqCpnUb+/4FmX+ZWq YC1hcmMaAQPTMnQlKEheiIQpQj3daxE7LZm6JARhclZkXkP/M3/sWedcX5o9CQAv+RKd BMDQ== X-Received: by 10.236.165.135 with SMTP id e7mr18627287yhl.99.1362520015581; Tue, 05 Mar 2013 13:46:55 -0800 (PST) Received: from [10.0.0.10] (99-25-33-39.lightspeed.sntcca.sbcglobal.net. [99.25.33.39]) by mx.google.com with ESMTPS id g27sm8946522yhm.21.2013.03.05.13.46.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Mar 2013 13:46:53 -0800 (PST) Message-ID: <513667CB.4090804@gmail.com> Date: Tue, 05 Mar 2013 13:46:51 -0800 From: Rob Glidden User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Gaelle Martin-Cocher , "rtcweb@ietf.org" References: <5131CD20.8060201@alvestrand.no> <92D0D52F3A63344CA478CF12DB0648AA2652BB43@XMB106BCNC.rim.net> <55CA954E89EBBD46AC3D6022B7C7160727655871@XMB101ADS.rim.net> <92D0D52F3A63344CA478CF12DB0648AA2652C246@XMB106BCNC.rim.net> <92D0D52F3A63344CA478CF12DB0648AA2652C2A6@XMB106BCNC.rim.net> In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AA2652C2A6@XMB106BCNC.rim.net> Content-Type: multipart/alternative; boundary="------------010200070509070100030605" Subject: Re: [rtcweb] FW: Input to Video Codec Selection X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Mar 2013 21:47:04 -0000 This is a multi-part message in MIME format. --------------010200070509070100030605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit > [gmc] the issue is not that Google would permit or not the usage of VP8. The issue is: will VP8 become a "standard" one way or another, > and/or will it get the right level of scrutiny so that _OTHER_ will/could declare their IP and thereby will finally get clarity on that aspect for > implementers. > I think that this is/was the purpose of the exercise of bringing VP8 via an RFC or in MPEG. This exercise needs to be completed. I agree this is the gist of the MPEG resolutions 14.1.1 to 14.1.5 on the VP8 proposal (M28182) sent to this list. ISO procedures (section 2.14 etc.) document well the next steps that would be required and expected: - providing required ISO/ITU/IEC IPR form, - disclosure obligations, - call for patents, - etc. I for one doubt the advisability of dropping the existing, vetted IVC test model as a condition for taking these steps as recommended in M28182. That wasn't done or even requested in the similar-yet-different case of WebVC (the ultimately stalled h.264 profile proposal to IVC). There are obviously better, and better sequenced, ways to proceed. Rob On 3/4/2013 10:01 AM, Gaelle Martin-Cocher wrote: > > Dear Harald, Stephan, All. > > Thank you for your answers. > > I have further comments and request for clarifications marked in red > with [gmc]. > > Sincerely, > > Gaëlle > > *From:*Stephan Wenger [mailto:stewe@stewe.org] > *Sent:* Sunday, March 03, 2013 11:52 AM > *To:* Harald Alvestrand; Gaelle Martin-Cocher > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] Input to Video Codec Selection > > Hi Harald, > > Thanks for these candid answers. I have a few comments, marked in > blue and with StW: > > Stephan > > *From: *Harald Alvestrand > > *Date: *Saturday, 2 March, 2013 01:57 > *To: *Gaelle Martin-Cocher > > *Cc: *"rtcweb@ietf.org " > > *Subject: *Re: [rtcweb] Input to Video Codec Selection > > > On 03/01/2013 11:21 PM, Gaelle Martin-Cocher wrote: > > Dear All, > > > > Further to Magnus email, while I assume there might not be "something new" to learn at the meeting, I believe the below requested clarifications on existing information would be useful. Implementers should clearly know which license they can pick or get when it comes to VP8 and by which groups. I believe answers in advance of the meeting would help the discussion at the meeting. > > > > Questions 1 & 2: > > It is assumed that in the case of choosing VP8, RTCWeb would reference the informational RFC 6386. > > Yes, that is the intent. > > Q1: Is there an intent to move that RFC to the standard track at a point in time? > > No. I don't personally see any benefit in doing so at this time. > [GMC] I see manyvalid reasons why one implementer would want to comply > to a formal specification available in a standardization body where an > IPR disclosure process takes place. That specification would have had > the right level of scrutiny by a wide group of experts. > > From a technicalviewpoint, I would want to develop an implementation > from such a specification and I would want to test it against some > conformance point/spec. > > From an IP side, it should be noted that for some legalentities it is > certainly easier to declare IP against a "spec" than against a "code". > Having "just" a code may have prevented some entities to make their > declarations. > > So it seems from your answer and from StW answer below that for RFC 6386: > > "The Spec" is "the code". > > There will not be in IETF a more formal spec. is that correct? > > It will not move to the standard track hence not reach the level of > scrutiny/consensus that everyone was asking for. > > On the other hand in MPEG, we *may/will* (?)get a formal spec (that > is, syntax, semantic, decoding process, conformance) and a more > thorough scrutiny/review. > > Q2: Would that change the rule of "who" is obliged to make an IPR declaration? > > Speaking with my IETF-amateur-lawyer hat on (and as a former chair of > the IPR WG): No, it does not change the rule. The rule depends on > whether the technology in question is discussed in the IETF, not on > the nature of the contribution. RFC 3979 section 6.1.2 refers to > "Contribution", the definition of that term in RFC 3979 section 1 > letter j makes it completely explicit that RFC Editor Contributions > are covered by the term "Contribution". > > StW; While this answer IMO correctly interprets the language of BCP79, > you answer the question IMO to directly. Therefore, the answer is > somewhat misleading in it misses to mention an important point: > > The main (sole?) purpose of an IETF WG is to facilitate consensus > building, which necessarily involves more than one party, and those > contributing to the discussions (belonging to more than one party) > have a disclosure obligation. To which extent there is real > discussion and consensus building dependent from draft to draft and WG > to WG, but there is at least some. > > ISE submissions, like the draft that lead to RFC 6386, OTOH, are > almost always NOT the result of a multiparty consensus building > process. Quite commonly, they involved only a small authors' group, > often from the same company. That's the case here. No technical > community input from IETF participants was received in an IETF > context, no WG consensus was required, and the IESG "no conflict" > statement is also no indication of IETF consensus. > > Insofar, almost inevitably, the disclosure obligations for an ISE > submission are different in practice. In this case, it appears that > only the authors (and perhaps the IESG members---I'm not clear on this > point) had a disclosure obligation. Which they fulfilled. > > /StW > > Question 3: > The IPR disclosure was made on the draft 2 of draft-bankoski-vp8-bitstream-02" as perhttps://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=6386 > Draft 3 and onward contains the copyright license and the additional IP rights grant. > Q3: Is the initial IPR disclosure still valid? > > Yes. RFC 3979 section 6.2.1. > > The IPR disclosure required pursuant to section 6.1.1 must be made as > soon as reasonably possible after the Contribution is published in an > Internet Draft unless the required disclosure is already on file. > For example, if the Contribution is an update to a Contribution for > which an IPR disclosure has already been made and the applicability > of the disclosure is not changed by the new Contribution, then no new > disclosure is required. > > Question 4: > The informational RFC 6386 contains the decoder code and some piece of encoder code. > Though the IP rights grant mentioned in the RFC is offered against: > > "This implementation" means the copyrightable works distributed by > Google as part of the WebM Project." > > Q4: As such the IP rights grant does not seem to apply to the RFC itself or to an implementation of the code contained in the RFC. Should that be corrected or is that the intent? > > Speaking with WEBM hat on: > > There are two grants - the grant of license to copyrighted works, and > the grant of license to patented technology. > > Software license: http://www.webmproject.org/license/software/ - > classical 3-clause BSD. > Patent license 1: http://www.webmproject.org/license/bitstream/ - > covers any implementation that produces or consumes VP8 bitstreams. > Patent license 2: http://www.webmproject.org/license/additional/ - > covers usage of the implementation. > [gmc] I am afraid you are not answering Q4. Those are WebM licenses > that don't apply to the RFC (more precisely to the RFC code). > > You may be making the assumption that everyone will refer to and use > the WebM code. > > I am making the assumption that if the RFC is self-sufficient one > would want to derive a VP8 compliant implementation from the RFC > (either from section 1 to 19 or from section 20 to 20.24 or from both). > > Hence what is the meaning of 20.26 and 20.27 in the RFC and how does > that apply to the RFC itself? > > This is still confusing. > > > Question 5: > The additional IP grant is applied to a particular implementation (namely the WebM VP8 code) without modifications. > Any derivative work either: > - produced from the reference code in WebM (that is a possible optimized version of it); or > - produced from the RFC text or the code provided within the RFC (while not using the WebM code) > does not have the benefit of the additional IP grant. > In other words a conformant implementation does not necessarily have the benefit of the additional IP grant. > I am not confident that the VP8 code can be used "as is" for certain platforms. I would think that the code might need some modification to provide the desired performance. In other words, it should be clear that those implementers would not necessarily receive the benefit of that grant. > If the answer to Q3 is negative, then there is no IP license statement at all that applies to a "conformant implementation of the RFC" (aka a derivative work). > If the answer to Q3 is positive, it is not clear how to reconcile the declaration inside the RFC and the declaration that is attached to the the RFC draft for implementers that would not modify the code. > Q5: Can this be clarified or confirmed? > > All 3 of the pages referred to above permit the production of > derivative works. Quoth: > > - bitstream: " ... license to make, have made, use, offer to sell, > sell, import, and otherwise transfer implementations of this > specification" (whether derived from the example code or not) > - copyright: ".... Redistribution and use in source and binary forms, > with or without modification, are permitted provided that.." > - patent: "... patent license to make, have made, use, offer to sell, > sell, import, transfer, and otherwise run, modify and propagate the > contents of this implementation" > > I believe there should be no issue here; modification is permitted. > [gmc] the question is not "are modifications permitted" but which > license apply to those modifications (again referring to the RFC code > and not to WebM). > > It seems that only the IETF declaration attached to the RFC apply to > the RFC code. (though that would depend on answers to Q4) > > > Question 6: > The IPR disclosure in IETF is different than the IPR statement made in MPEG (see document sent by Harald earlier). > Q6: the differences in license statement and IP grant referring to WebM code are rather confusing. Can it be clarified which license, copyright, grant are provided for RFC 6386? > > The statement we made in MPEG was crafted to be as similar to others' > statements made in MPEG as possible, in order to respect MPEG's legal > language traditions - which in turn should minimize the need for > clarification of what was granted when discussing with people used to > the MPEG language tradition. > [gmc] I believe the statement in MPEG in MPEG is similar to other MPEG > statement except for the "other reasonable conditions" that triggers > significant confusion as they are undefined. > > > We believe that the statement made in MPEG is wholly within the > statements made on the WEBM website - all permissions implied by the > statement in MPEG should also be permitted by the statements on the > WEBM website. We haven't tried to analyze whether there are cases > where someone can do something within the permissions granted on the > WEBM website that would not be permitted under the MPEG statement - > the MPEG statement was aimed to allow the document to progress within > MPEG; people who want to read the > [gmc] again, one would want to use a standard specification not the > WebM code to develop a conformant implementation and test it. > > > > In conclusion, before advancing this draft, or considering it as a candidate for RTCWeb, consistency and clarity should be ensured between the IPR grant associated with the IETF draft, the IPR grants within the IETF draft document itself, the IPR grant given for MPEG, and any IPR grant given in connection with the WEBM project for this same work. Otherwise, the IPR status of the work that is undertaken is indeterminate, and likely will not produce a result that will be useful. > > > Speaking with my Google hat on: > > We will of course seek maximum clarity of the statements we make. > Unfortunately, different organizations have different traditions on > how these things should be worded, and we cannot guarantee that there > can't be differences in interpretation. > > However, I (speaking with my personal hat on) think the current > statements on the WEBM website are pretty clear. > > [GMC] again that is not what matters. > > I have yet to see a concrete scenario where there would be any > reasonable doubt about whether usage of VP8 is permitted by Google or > not - and in all cases except for those that fall within the defensive > suspension exceptions, it is permitted. > [gmc] the issue is not that Google would permit or not the usage of > VP8. The issue is: will VP8 become a "standard" one way or another, > and/or will it get the right level of scrutiny so that _OTHER_ > will/could declare their IP and thereby will finally get clarity on > that aspect for implementers. > > I think that this is/was the purpose of the exercise of bringing VP8 > via an RFC or in MPEG. This exercise needs to be completed. > > Sincerely, > > Gaëlle > > > Hope that helps! > > Harald > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute > non-public information. Any use of this information by anyone other > than the intended recipient is prohibited. If you have received this > transmission in error, please immediately reply to the sender and > delete this information from your system. Use, dissemination, > distribution, or reproduction of this transmission by unintended > recipients is not authorized and may be unlawful. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------010200070509070100030605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
> [gmc] the issue is not that Google would permit or not the usage of VP8. The issue is: will VP8 become a “standard” one way or another,
> and/or will it get the right level of scrutiny so that OTHER will/could declare their IP and thereby will finally get clarity on that aspect for
> implementers.

> I think that this is/was the purpose of the exercise of bringing VP8 via an RFC or in MPEG. This exercise needs to be completed.

I agree this is the gist of the MPEG resolutions 14.1.1 to 14.1.5 on the VP8 proposal (M28182) sent to this list.

ISO procedures (section 2.14 etc.) document well the next steps that would be required and expected:

- providing required ISO/ITU/IEC IPR form,
- disclosure obligations,
- call for patents,
- etc. 

I for one doubt the advisability of dropping the existing, vetted IVC test model as a condition for taking these steps as recommended in M28182. That wasn't done or even requested in the similar-yet-different case of WebVC (the ultimately stalled h.264 profile proposal to IVC).  There are obviously better, and better sequenced, ways to proceed.

Rob


On 3/4/2013 10:01 AM, Gaelle Martin-Cocher wrote:

 

Dear Harald, Stephan, All.

Thank you for your answers.

I have further comments and request for clarifications marked in red with [gmc].

 

Sincerely,

Gaëlle

 

From: Stephan Wenger [mailto:stewe@stewe.org]
Sent: Sunday, March 03, 2013 11:52 AM
To: Harald Alvestrand; Gaelle Martin-Cocher
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Input to Video Codec Selection

 

Hi Harald,

Thanks for these candid answers.  I have a few comments, marked in blue and with StW:

Stephan

 

From: Harald Alvestrand <harald@alvestrand.no>
Date: Saturday, 2 March, 2013 01:57
To: Gaelle Martin-Cocher <gmartincocher@blackberry.com>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Input to Video Codec Selection

 


On 03/01/2013 11:21 PM, Gaelle Martin-Cocher wrote:

Dear All,
 
Further to Magnus email, while I assume there might not be "something new" to learn at the meeting, I believe the below requested clarifications on existing information would be useful.  Implementers should clearly know which license they can pick or get when it comes to VP8 and by which groups.  I believe answers in advance of the meeting would help the discussion at the meeting.
 
Questions 1 & 2:
It is assumed that in  the case of choosing VP8, RTCWeb would reference  the informational RFC 6386.

Yes, that is the intent.

Q1: Is there an intent to move that RFC to the standard track at a point in time?

No. I don't personally see any benefit in doing so at this time.
[GMC] I see manyvalid reasons why one implementer would want to comply to a formal specification available in a standardization body where an IPR disclosure process takes place. That specification would have had the right level of scrutiny by a wide group of experts.

From a technicalviewpoint, I would want to develop an implementation from such a specification and I would want to test it against some conformance point/spec.

From an IP side, it should be noted that for some legal entities it is certainly easier to declare IP against a “spec” than against a “code”. Having “just” a code may have prevented some entities to make their declarations.

 

So it seems from your answer and from StW answer below that for RFC 6386:

“The Spec” is “the code”.

There will not be in IETF a more formal spec. is that correct?

It will not move to the standard track hence not reach the level of scrutiny/consensus that everyone was asking for.

On the other hand in MPEG, we may/will (?)get a formal spec (that is, syntax, semantic, decoding process, conformance) and a more thorough scrutiny/review.

 

Q2: Would that change the rule of "who" is obliged to make an IPR declaration?

Speaking with my IETF-amateur-lawyer hat on (and as a former chair of the IPR WG): No, it does not change the rule. The rule depends on whether the technology in question is discussed in the IETF, not on the nature of the contribution. RFC 3979 section 6.1.2 refers to "Contribution", the definition of that term in RFC 3979 section 1 letter j makes it completely explicit that RFC Editor Contributions are covered by the term "Contribution".

 

StW; While this answer IMO correctly interprets the language of BCP79, you answer the question IMO to directly.  Therefore, the answer is somewhat misleading in it misses to mention an important point: 

 

The main (sole?) purpose of an IETF WG is to facilitate consensus building, which necessarily involves more than one party, and those contributing to the discussions (belonging to more than one party) have a disclosure obligation.  To which extent there is real discussion and consensus building dependent from draft to draft and WG to WG, but there is at least some.

 

ISE submissions, like the draft that lead to RFC 6386, OTOH, are almost always NOT the result of a multiparty consensus building process.  Quite commonly, they involved only a small authors' group, often from the same company.  That's the case here.  No technical community input from IETF participants was received in an IETF context, no WG consensus was required, and the IESG "no conflict" statement is also no indication of IETF consensus.

 

Insofar, almost inevitably, the disclosure obligations for an ISE submission are different in practice.  In this case, it appears that only the authors (and perhaps the IESG members—I'm not clear on this point) had a disclosure obligation.  Which they fulfilled.

/StW

 

Question 3:
The IPR disclosure was made on the draft 2 of draft-bankoski-vp8-bitstream-02" as per https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=6386
Draft 3 and onward contains the copyright license and the additional IP rights grant. 
Q3: Is the initial IPR disclosure still valid?

Yes. RFC 3979 section 6.2.1.

   The IPR disclosure required pursuant to section 6.1.1 must be made as
   soon as reasonably possible after the Contribution is published in an
   Internet Draft unless the required disclosure is already on file.
   For example, if the Contribution is an update to a Contribution for
   which an IPR disclosure has already been made and the applicability
   of the disclosure is not changed by the new Contribution, then no new
   disclosure is required.

Question 4:
The informational RFC 6386 contains the decoder code and some piece of encoder code.
Though the IP rights grant mentioned in the RFC is offered against:
 
   "This implementation" means the copyrightable works distributed by
   Google as part of the WebM Project."
 
Q4: As such the  IP rights grant does not seem to apply to the RFC itself or to an implementation of the code contained in the RFC.  Should that be corrected or is that the intent?

Speaking with WEBM hat on:

There are two grants - the grant of license to copyrighted works, and the grant of license to patented technology.

Software license: http://www.webmproject.org/license/software/ - classical 3-clause BSD.
Patent license 1: http://www.webmproject.org/license/bitstream/ - covers any implementation that produces or consumes VP8 bitstreams.
Patent license 2: http://www.webmproject.org/license/additional/ - covers usage of the implementation.
[gmc] I am afraid you are not answering Q4. Those are WebM licenses that don’t apply to the RFC (more precisely to the RFC code).

You may be making the assumption that everyone will refer to and use the WebM code.

I am making the assumption that if the RFC is self-sufficient one would want to derive a VP8 compliant implementation from the RFC (either from section 1 to 19 or from section 20 to 20.24 or from both).

Hence what is the meaning of 20.26 and 20.27 in the RFC and how does that apply to the RFC itself?

This is still confusing.

 
Question 5:
The additional IP grant is applied to a particular implementation (namely the WebM VP8 code) without modifications. 
Any derivative work either:
- produced from the reference code in WebM (that is a possible optimized version of it); or
- produced from the RFC text or the code provided within the RFC (while not using the WebM code)
does not have the benefit of the additional IP grant. 
In other words a conformant implementation does not necessarily have the benefit of the additional IP grant.
I am not confident that the VP8 code can be used "as is" for certain platforms. I would think that the code might need some modification to provide the desired performance. In other words, it should be clear that those implementers would not necessarily receive the benefit of that grant.
If the answer to Q3 is negative, then there is no IP license statement at all that applies to a "conformant implementation of the RFC" (aka a derivative work).
If the answer to Q3 is positive, it is not clear  how to reconcile the declaration inside the RFC and the declaration that is attached to the the RFC draft for implementers that would not modify the code.
Q5: Can this be clarified or confirmed?

All 3 of the pages referred to above permit the production of derivative works. Quoth:

- bitstream: " ... license to make, have made, use, offer to sell, sell, import, and otherwise transfer implementations of this specification" (whether derived from the example code or not)
- copyright: ".... Redistribution and use in source and binary forms, with or without modification, are permitted provided that.."
- patent: "... patent license to make, have made, use, offer to sell, sell, import, transfer, and otherwise run, modify and propagate the contents of this implementation"

I believe there should be no issue here; modification is permitted.
[gmc] the question is not “are modifications permitted” but which license apply to those modifications (again referring to the RFC code and not to WebM).

It seems that only the IETF declaration attached to the RFC apply to the RFC code. (though that would depend on answers to Q4)

 
Question 6:
The IPR disclosure in IETF is different than the IPR statement made in MPEG (see document sent by Harald earlier). 
Q6: the differences in license statement and IP grant referring to WebM code are rather confusing. Can it be clarified which license, copyright, grant are provided for RFC 6386?

The statement we made in MPEG was crafted to be as similar to others' statements made in MPEG as possible, in order to respect MPEG's legal language traditions - which in turn should minimize the need for clarification of what was granted when discussing with people used to the MPEG language tradition.
[gmc] I believe the statement in MPEG in MPEG is similar to other MPEG statement except for the “other reasonable conditions” that triggers significant confusion as they are undefined.


We believe that the statement made in MPEG is wholly within the statements made on the WEBM website - all permissions implied by the statement in MPEG should also be permitted by the statements on the WEBM website. We haven't tried to analyze whether there are cases where someone can do something within the permissions granted on the WEBM website that would not be permitted under the MPEG statement - the MPEG statement was aimed to allow the document to progress within MPEG; people who want to read the
[gmc] again, one would want to use a standard specification not the WebM code to develop a conformant implementation and test it.

 
 
In conclusion, before advancing this draft, or considering it as a candidate for RTCWeb,  consistency and clarity should be ensured between the IPR grant associated with the IETF draft, the IPR grants within the IETF draft document itself, the IPR grant given for MPEG, and any IPR grant given in connection with the WEBM project for this same work.  Otherwise, the IPR status of the work that is undertaken is indeterminate, and likely will not produce a result that will be useful. 


Speaking with my Google hat on:

We will of course seek maximum clarity of the statements we make. Unfortunately, different organizations have different traditions on how these things should be worded, and we cannot guarantee that there can't be differences in interpretation.

However, I (speaking with my personal hat on) think the current statements on the WEBM website are pretty clear.

[GMC] again that is not what matters.

I have yet to see a concrete scenario where there would be any reasonable doubt about whether usage of VP8 is permitted by Google or not - and in all cases except for those that fall within the defensive suspension exceptions, it is permitted.
[gmc] the issue is not that Google would permit or not the usage of VP8. The issue is: will VP8 become a “standard” one way or another, and/or will it get the right level of scrutiny so that OTHER will/could declare their IP and thereby will finally get clarity on that aspect for implementers.

I think that this is/was the purpose of the exercise of bringing VP8 via an RFC or in MPEG. This exercise needs to be completed.

Sincerely,

Gaëlle


Hope that helps!

           Harald

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. 

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

--------------010200070509070100030605-- From jerome.marcon@alcatel-lucent.com Tue Mar 5 17:20: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 36F0121F859C for ; Tue, 5 Mar 2013 17:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.374 X-Spam-Level: X-Spam-Status: No, score=-9.374 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_48=0.6, 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 W0gtUuYhmPlR for ; Tue, 5 Mar 2013 17:20:22 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 94DC421F858C for ; Tue, 5 Mar 2013 17:20:22 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r261KKgV019111 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Mar 2013 02:20:20 +0100 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 6 Mar 2013 02:20:20 +0100 Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 6 Mar 2013 02:20:20 +0100 From: "MARCON, JEROME (JEROME)" To: Martin Thomson , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Data Channels Proposal: Now in Internet Draft Form Thread-Index: AQHODgC+U0LQIV4uXUqD2rdW2590g5iVtT3wgAARooCAAgaxUA== Date: Wed, 6 Mar 2013 01:20:19 +0000 Message-ID: <39821B4C400EC14DAD4DB25330A9271A02039F@FR711WXCHMBA02.zeu.alcatel-lucent.com> References: <39821B4C400EC14DAD4DB25330A9271A019231@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: Re: [rtcweb] Data Channels Proposal: Now in Internet Draft Form X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Mar 2013 01:20:24 -0000 Thanks. Two new comments inline. =20 Also, if you could outline the Data Channel API needed to support your prop= osal, that would help the understanding. > -----Message d'origine----- > De : Martin Thomson [mailto:martin.thomson@gmail.com]=20 > Envoy=E9 : lundi 4 mars 2013 18:01 > =C0 : MARCON, JEROME (JEROME) > Cc : rtcweb@ietf.org > Objet : Re: [rtcweb] Data Channels Proposal: Now in Internet=20 > Draft Form >=20 > Brief answers inline. >=20 > On 4 March 2013 08:28, MARCON, JEROME (JEROME)=20 > wrote: > > > > Hi Martin, thanks for your proposal. I have some comments/questions: > > > > 1. So the label locally assigned to a data channel created=20 > in-band is=20 > > not transmitted to the peer ? (note that I am fine with this) >=20 > The label is a handle that is provided to the application as=20 > a convenience. The label is a new invention, which I'm not=20 > certain we entirely need. It might provide some use, but=20 > it's unclear how it adds value over the subprotocol label. >=20 > > 2. Whereas defaulting properties like order or reliability=20 > is more or less OK, it seems more critical to default the=20 > subprotocol property. The app would have to parse the=20 > incoming user message to guess if this message is about=20 > 'chat' or 'file transfer' >=20 > Actually, in most cases, an application will only ever=20 > receive packets that they know about beforehand. If they=20 > need to distinguish between chat and file transfer, they will=20 > have established conventions for identifying those packets. =20 > PPID is one possible convention, though I note that most uses=20 > of SCTP I've seen don't use more than one value, so most code=20 > ends up ignoring the PPID. >=20 > I share the same leeriness about the "protocol" label used in=20 > thewebsocketprotocol. Before the 'subprotocol' concept was ever discussed, I thought the SDP O/A = should allow to negotiate the PPID to use for each channel (applied to all = messages of this channel) where the PPID would be a true IANA-registered pr= otocol defined over SCTP. Now I am fine with the negotiation of 'subprotoco= l' value. Randell's proposal is reserving the PPID for the per-message text/binary/co= ntrol signaling, so 'subprotocol' and PPID are orthogonal. But your proposa= l is exposing the per-message PPID to the app (regardless of the negotiated= subprotocol). So the roles of 'subprotocol' and PPID seem to potentially o= verlap (although semantically the PPID signals some protocol over a unidire= ctional SCTP stream, whereas 'subprotocol' rather signals some protocol ove= r a bi-directional RTCWeb data channel). Maybe you have some thoughts on th= e potential relationships between a registered PPID and a registered subpro= tocol (1-1, 1-N, N-1, etc.). Example: if I write an RFC porting a file tran= sfer protocol over RTCWeb data channel, would the RFC reserve exclusively o= ne PPID XXX and one 'file transfer XXX' subprotocol value ?=20 What bothers me so far in your proposal is the 'try and guess' property sel= ection process left to the app when a message is received on a closed chann= el, for the 'subprotocol' property in particular. But if the subprotocol ca= n be deterministically inferred from the incoming user message PPID, then t= hat's a lot better. =20 >=20 > > 3. Why does StreamID need to be exposed to the app ? I=20 > first thought it was to allow in-band data channel creation=20 > by a simple message sending. But then: > > - either the StreamID is a parameter of send(streamID, data) - and=20 > > this breaks the alignment with WebSocket API and also the=20 > app has no=20 > > handle on this data channel > > - or streamID is a parameter of createDataChannel and this seems=20 > > useless as the browser is able to select a new stream number=20 > > internally >=20 > Stream ID is exposed to the app because it allows the app to=20 > create their own usage pattern. It can create the streams it=20 > wants and attach meaning to those numbers. That said, stream=20 > IDs are allocated automatically by the browser for most uses.=20 > I'd expect that streamId would be an optional constraint=20 > (i.e., optional in usage) on channel creation. >=20 > There is no in-band protocol, except for the one that the=20 > application uses. That's important. >=20 > > 4. Why does binaryPPID need to be exposed to the app ? The=20 > browser is expected to infer the message type from the data=20 > passed to send(). >=20 > binaryPPID allows the application to generate (though not=20 > consume, except in constrained cases) SCTP that can be=20 > consumed by any application. The browser doesn't "infer"=20 > anything about message types, other than when messages use=20 > the textual PPID, in which case they are surfaced as strings=20 > rather than the specified binary type (a Blob or ArrayBuffer). >=20 > > 5. Finally to decrease the number of mismatching properties=20 > situations, you could simply assign a "Default=3Dstrict|loose"=20 > property to one of the data channels in the SDP. > > If set to "strict", endpoints could only create in-band=20 > data channels=20 > > for which the default set of properties applies. To create=20 > other types of data channels in-band, renegotiation is=20 > required If set to "loose'", an endpoint receiving a user=20 > message on an closed data channel would open the data channel=20 > using these default properties. But with the risk of mismatch=20 > on subprotocol... > > This would make scalable setup scenarios like: > > - the SDP offer/answer exchange negotiates one 'chat' data channel,=20 > > and one 'file transfer' Default data channel > > - later on, either endpoint creates in-band 100 data=20 > channels for file transfer -> no renegotiation needed, no=20 > property mismatch. >=20 > That's unnecessary. If I want an application that has one "special" > channel and an arbitrary number of "normal" channels, I can=20 > do exactly as you say and then set the properties of those=20 > spontaneously created channels as they appear. It doesn't=20 > require any more standardization or browser machinery: >=20 > pc.addEventListener('datachannel', function(e) { > var fileTransferChannel =3D e.channel; > fileTransferChannel.ordered =3D true; > fileTransferChannel.subprotocol =3D 'filetransfer'; }); >=20 > > This reduces the mismatching situations, in the case where=20 > one single set of properties is mostly used at a given time=20 > in the session. But the browser (or the app) has to guess at=20 > the time of SDP negotiation which set of properties should be=20 > the default, i.e. will be used more frequently than the=20 > others later on in the session. > > > > An extended (and deterministic) approach is to restrict the=20 > role of SDP offer/answer to the negotiation of some=20 > identified set of properties (not data channels). Then data=20 > channels are created in-band by the sending of user messages=20 > on closed streams, where each user message includes a "set of=20 > properties" identifier. You may have a look at the draft I=20 > have submitted. >=20 > I didn't see a specific need for negotiating properties in=20 > such a generic fashion. Ultimately, each property needs some=20 > semantics when you use it, so it seemed excessive. In SDP at=20 > least, the extension mechanism is well enough understood to=20 > be able to support extension enough to allow for new=20 > properties to be defined (like ordering, which I omitted from=20 > my draft by mistake). >=20 > That said, if you are defining an in-band protocol (a bad=20 > idea in my opinion), the idea that properties are generic=20 > makes a great deal of sense. That allows applications to=20 > define what they need and allows them to avoid unnecessary noise. Like you advise, I also propose is an out-of-band SDP negotiation of sets o= f generic properties, with no properties carried in-band. Where I differ is= that the selection of some properties (e.g. subprotocol) to apply to a cha= nnel created from an incoming message must be always (not just sometimes) d= eterministic.=20 =20 >=20 > --Martin > = From bernard_aboba@hotmail.com Tue Mar 5 19:42: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 B402111E80EE for ; Tue, 5 Mar 2013 19:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.392 X-Spam-Level: X-Spam-Status: No, score=-99.392 tagged_above=-999 required=5 tests=[AWL=1.212, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, 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 U0B1WersLi6G for ; Tue, 5 Mar 2013 19:42:35 -0800 (PST) Received: from blu0-omc2-s5.blu0.hotmail.com (blu0-omc2-s5.blu0.hotmail.com [65.55.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id AFDDF11E80EA for ; Tue, 5 Mar 2013 19:42:35 -0800 (PST) Received: from BLU404-EAS141 ([65.55.111.71]) by blu0-omc2-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Mar 2013 19:42:35 -0800 X-EIP: [4vZ+ioH1ydoBVuVSfOwBpjjgWGNClyos] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable References: <95790319-C42C-48E2-A6FD-0E718CCF48FB@csperkins.org> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: Date: Tue, 5 Mar 2013 19:42:38 -0800 To: Martin Thomson X-OriginalArrivalTime: 06 Mar 2013 03:42:35.0438 (UTC) FILETIME=[A4121CE0:01CE1A1C] Cc: "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] Reminder: Working group last call for draft-ietf-rtcweb-security-arch X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Mar 2013 03:42:36 -0000 Or at least recommend against granting long term screen sharing permissions.= Spying via audio and video is scary, true, but creepy screen sharing takes i= t to a new level. On Mar 4, 2013, at 17:03, "Martin Thomson" wrote:= > Does the text say: "screen sharing is a bad idea" ? >=20 > On 4 March 2013 15:36, Eric Rescorla wrote: >> Thanks, Justin. >>=20 >> I have been working on something for this and hope to have some text soon= . >>=20 >> -Ekr >>=20 >>=20 >> On Mon, Mar 4, 2013 at 3:30 PM, Justin Uberti wrote:= >>>=20 >>> I already sent mail to Eric on this, but one thing that needs >>> consideration in this draft is the use case identified in section 4.2.7 o= f >>> draft-ietf-rtcweb-use-cases-and-requirements-06, i.e. desktop sharing. >>> Section 5.2 of the security doc covers the requirements for consent for >>> camera access, but not for desktop access. >>>=20 >>>=20 >>> On Mon, Mar 4, 2013 at 8:43 AM, Ted Hardie wrote: >>>>=20 >>>> Hi Colin, >>>>=20 >>>> Thanks for reviewing the document. As you note, there are open >>>> issues; 5.1, for example, has this: >>>>=20 >>>> "This is a deliberate implementation complexity versus security >>>> tradeoff. >>>> [[ OPEN ISSUE:: Should we be more aggressive about this?]]" >>>>=20 >>>> As far as I am aware,though, the document in each case includes a >>>> proposal for the Open Issue, >>>> and it is that which would be in a WG document post last-call. But if >>>> folks looked at the document >>>> and answered the "open issues" within, that would certainly be very >>>> welcome input. >>>>=20 >>>> Were there any Open Issues or other points you wanted to comment on >>>> directly? >>>>=20 >>>> Ted >>>>=20 >>>>=20 >>>> but there >>>>=20 >>>> On Mon, Mar 4, 2013 at 4:58 AM, Colin Perkins wrote= : >>>>> Ted, >>>>>=20 >>>>> This draft has a number of places where open issues are noted (e.g., i= n >>>>> Sections 5.1 and 5.5, but there are many others). It seems premature t= o >>>>> issue a working group last call until those are resolved. >>>>>=20 >>>>> Colin >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 25 Feb 2013, at 23:27, Ted Hardie wrote: >>>>>> This is a reminder that there is an ongoing last call for >>>>>> draft-ietf-rtcweb-security-arch-06. Please send comments, including >>>>>> those of the "reviewed and no issues" ilk, by March 9th, 2012. >>>>>>=20 >>>>>> regards, >>>>>>=20 >>>>>> Ted Hardie >>>>>>=20 >>>>>> On Thu, Feb 14, 2013 at 8:35 AM, Ted Hardie >>>>>> wrote: >>>>>>> This begins a working group last call for >>>>>>> draft-ietf-rtcweb-security-arch. Please send comments to the list b= y >>>>>>> March 9, 2013. >>>>>>>=20 >>>>>>> regards, >>>>>>>=20 >>>>>>> Ted, Cullen, Magnus >>>>>> _______________________________________________ >>>>>> rtcweb mailing list >>>>>> rtcweb@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> Colin Perkins >>>>> http://csperkins.org/ >>>>>=20 >>>>>=20 >>>>>=20 >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>=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 salvatore.loreto@ericsson.com Wed Mar 6 00:49: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 02BB521F8484 for ; Wed, 6 Mar 2013 00:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.248 X-Spam-Level: X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 ej5zyVqC6A+y for ; Wed, 6 Mar 2013 00:49:01 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 300B821F848A for ; Wed, 6 Mar 2013 00:49:01 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-4e-513702fce19e Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D4.85.10459.CF207315; Wed, 6 Mar 2013 09:49:00 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Wed, 6 Mar 2013 09:48:59 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 155002B2F for ; Wed, 6 Mar 2013 10:48:59 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C354654637 for ; Wed, 6 Mar 2013 10:48:56 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 201E854556 for ; Wed, 6 Mar 2013 10:48:56 +0200 (EET) Message-ID: <513702F9.2030909@ericsson.com> Date: Wed, 6 Mar 2013 09:48:57 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20130218233047.19414.47123.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A012598@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <39821B4C400EC14DAD4DB25330A9271A012598@FR711WXCHMBA03.zeu.alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------070505070506070503060504" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+Jvje4fJvNAg2WPhCzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvQbD9kL2morZn9bwtrAuDOpi5GTQ0LAROLA/xVsELaYxIV7 68FsIYGTjBJXt4hD2OsZJW69NIGwLzBKfDqv2MXIBWQfZpSYf7uDHcI5wyhx5PFZIIeDg1dA W+LxWzGQBhYBFYmtf/8ygdhsAmYSzx9uYQaxRQWSJf49OsIIYvMKCEqcnPmEBcQWERCW2Pqq F6xeWCBL4veMo2wQ8ycwSnzYfResmVMgWuLXzDtgDcwCYRLL53WzQ3ygJnH13CZmiEu1JHrP djJNYBSehWTHLCQtELatxIU516Hi8hLNW2czQ9i6Ehf+T4GLb387h3kBI9sqRvbcxMyc9HLD TYzAwD+45bfuDsZT50QOMUpzsCiJ84a5XggQEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwCib kRdioFHdarnLM1Voe+e1a4WqCy3EdOa8DI9M495qrek1JXeu5Ie5zj/lbH6tUM/IEjrkn1rw 5fokPcEQlT/9L9o+Zd2Utrb/EOZyoXTVRrVjP6auZpcwO2xls2xGfPzCv3lFzrEaBgULJaOF 4s9UrXso+PXhXs356jme9X1W62T+FJQcVGIpzkg01GIuKk4EABRsOm9KAgAA Subject: Re: [rtcweb] TR : New Version Notification for draft-marcon-rtcweb-data-channel-management-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, 06 Mar 2013 08:49:03 -0000 --------------070505070506070503060504 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Hi Jerome, thanks for the draft. some initial comments 1) 1. Introduction [I-D.ietf-rtcweb-data-channel] provides use cases and requirements for the definition of RTCWeb data channels, and outlines how the Stream Control Transmission Protocol (SCTP) [RFC4960] encapsulated within Datagram Transport Layer Security (DTLS) [RFC6347] can be used for this purpose. While some of these requirements easily map to existing capabilities of the SCTP protocol and extensions (e.g. application messages can be carried as SCTP user messages), SCTP and existing SCTP extensions do not natively support the following requirements: o data channel bidirectionality (this can be achieved by pairing one SCTP outbound stream and one SCTP inbound stream) o data channel priority o partial reliability of delivery, based on a maximum number of retransmissions o general data channel setup here the problem for the 1 and 4 bullets is that SCTP does not have the concept of data channel but only of stream. About bullet 3, you may want to read the http://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-prpolicies-00 that propose how to define it. About bullet 2, data channel priority, this is an important one that should be discussed and defined. However I haven't found anything in your proposal about it. 2) Data Channel configuration Sorry but it is not clear to me what how you use DataChannel-configuration... i.e. if a DataChannel-configuration is 1:1 with an actual DataChannel, or we can have a 1:n relationship if I understood you correctly in 6.2. Opening a data channel out-of-band ... Note: for each new configuration, the offerer expectedly creates one data channel or more, whereas the answerer creates one data channel only. How the final data channel pairing (and SCTP stream number assignment) is resolved is further explained in this document. ... so in out of band mode, only one DataChannel will be created per DataChannel-configuration. i.e. there is no way to create more DataChannels with the same DataChannel-configuration out-bound. Isn't it? is so why? I don't get the advantage for this limitation one of the reason people are asking for out-of-bound, is to give the possibility to "disclosure" what kind of traffic (and how much) is going on between two WebRTC clients (i.e. browser). However, it seems that you make then possible to open more DataChannels with the same DataChannel-configuration in-band. 6.3. Opening a data channel in-band Each user message sent in a data channel includes the identifier of the configuration which this data channel is bound to. This signaling allows to enable or speed up the opening of new data channels in-band: 3) Framing an inband protocol with data framing is unnecessary and a useless complication for WebRTC DataChannel. That is why the http://tools.ietf.org/html/draft-jesup-rtcweb-data-protocol-04 has no added framing required. Please note that from a protocol point of view DataChannel is different from WebSocket. In WebSocket it has been necessary to add a framing (and we tried to design a minimal one, eve if I am not sure we have succeeded in that), mainly because we need to make the protocol frame-based where the pure TCP is stream-based. You do not need to do that with SCTP, as it already provides: sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages, /Salvatore On 2/19/13 1:07 AM, MARCON, JEROME (JEROME) wrote: > Hi, > > I have submitted a draft proposing a new way of setting up data channels, based on the concept of data channel configurations. It uses a lightweight SDP signaling coupled with a lightweight in-band signaling (not an in-band protocol). I think it can handle efficiently the most demanding setup scenarios. The proposal is besides designed with the intent to not impact on current browser API. > > This is a first draft, thanks for your suggestions of improvements. > > Jerome > > ________________________________________ > De : internet-drafts@ietf.org [internet-drafts@ietf.org] > Date d'envoi : mardi 19 février 2013 00:30 > À : MARCON, JEROME (JEROME) > Objet : New Version Notification for draft-marcon-rtcweb-data-channel-management-00.txt > > A new version of I-D, draft-marcon-rtcweb-data-channel-management-00.txt > has been successfully submitted by Jerome Marcon and posted to the > IETF repository. > > Filename: draft-marcon-rtcweb-data-channel-management > Revision: 00 > Title: RTCWeb data channel management > Creation date: 2013-02-19 > Group: Individual Submission > Number of pages: 15 > URL: http://www.ietf.org/internet-drafts/draft-marcon-rtcweb-data-channel-management-00.txt > Status: http://datatracker.ietf.org/doc/draft-marcon-rtcweb-data-channel-management > Htmlized: http://tools.ietf.org/html/draft-marcon-rtcweb-data-channel-management-00 > > > Abstract: > The Real-Time Communication in WEB-browsers (RTCWeb) working group is > charged to provide protocols to support direct interactive rich > communication using audio, video, and data between two peers' web- > browsers. For the support of data communication, the RTCWeb working > group has in particular defined the concept of bi-directional data > channels over SCTP. How to transport application messages on these > data channels seems straightforward (i.e. they can be carried as SCTP > user messages), however it is yet to be decided how to establish and > manage these data channels. This document specifies a method for > this, which relies first on a lightweight and scalable out-of-band > negotiation of data channel configurations (within the SDP offer/ > answer exchange) and second on the signaling of the configuration in > use in the SCTP user message itself. Once these configurations are > negotiated, further creations of data channels can occur purely in- > band by simply sending user messages, which avoids to define a new > in-band data channel protocol. > > > > > The IETF Secretariat > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Salvatore Loreto, PhD www.sloreto.com --------------070505070506070503060504 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
Hi Jerome,

thanks for the draft.
some initial comments

1)
1.  Introduction

   [I-D.ietf-rtcweb-data-channel] provides use cases and requirements
   for the definition of RTCWeb data channels, and outlines how the
   Stream Control Transmission Protocol (SCTP) [RFC4960] encapsulated
   within Datagram Transport Layer Security (DTLS) [RFC6347] can be used
   for this purpose.  While some of these requirements easily map to
   existing capabilities of the SCTP protocol and extensions (e.g.
   application messages can be carried as SCTP user messages), SCTP and
   existing SCTP extensions do not natively support the following
   requirements:

   o  data channel bidirectionality (this can be achieved by pairing one
      SCTP outbound stream and one SCTP inbound stream)

   o  data channel priority

   o  partial reliability of delivery, based on a maximum number of
      retransmissions

   o  general data channel setup

here the problem for the 1 and 4 bullets is that SCTP does not have the concept of data channel but only of stream.

About bullet 3, you may want to read the http://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-prpolicies-00
that propose how to define it.

About bullet 2, data channel priority, this is an important one that should be discussed and defined.
However I haven't found anything in your proposal about it.


2) Data Channel configuration
Sorry but it is not clear to me what how you use DataChannel-configuration...
i.e. if a DataChannel-configuration is 1:1 with an actual DataChannel, or we can have a 1:n relationship

if I understood you correctly in 
6.2.  Opening a data channel out-of-band

...

      Note: for each new configuration, the offerer expectedly creates
      one data channel or more, whereas the answerer creates one data
      channel only.  How the final data channel pairing (and SCTP stream
      number assignment) is resolved is further explained in this
      document.
...


      so in out of band mode, only one DataChannel will be created per
      DataChannel-configuration.

      i.e. there is no way to create more DataChannels with the same
      DataChannel-configuration out-bound.

      Isn't it? is so why? I don't get the advantage for this limitation

      

      one of the reason people are asking for out-of-bound, is to give
      the possibility to "disclosure" what kind

      of traffic (and how much) is going on between two WebRTC clients
      (i.e. browser).

      

      

      However, it seems that you make then possible to open more
      DataChannels with the same DataChannel-configuration

      in-band.

      

      
      
6.3.  Opening a data channel in-band

   Each user message sent in a data channel includes the identifier of
   the configuration which this data channel is bound to.  This
   signaling allows to enable or speed up the opening of new data
   channels in-band:

      

      

      

      3) Framing

      

      an inband protocol with data framing is unnecessary and a useless
      complication for WebRTC DataChannel.

      That is why the
      http://tools.ietf.org/html/draft-jesup-rtcweb-data-protocol-04 has
      no added framing required.

      

      Please note that from a protocol point of view DataChannel is
      different from WebSocket.

      

      In WebSocket it has been necessary to add a framing (and we tried
      to design a minimal one, eve if I am not sure we have succeeded in
      that),

      mainly because we need to make the protocol frame-based where the
      pure TCP is stream-based.

      You do not need to do that with SCTP, as it already provides:

      
      
       sequenced delivery of user messages within multiple streams, with
       an option for order-of-arrival delivery of individual user
       messages,

      

      /Salvatore

      

      

      

      On 2/19/13 1:07 AM, MARCON, JEROME (JEROME) wrote:

    

    

      
Hi,

I have submitted a draft proposing a new way of setting up data channels, based on the concept of data channel configurations. It uses a lightweight SDP signaling coupled with a lightweight in-band signaling (not an in-band protocol). I think it can handle efficiently the most demanding setup scenarios. The proposal is besides designed with the intent to not impact on current browser API.

This is a first draft, thanks for your suggestions of improvements.

Jerome 

________________________________________
De : internet-drafts@ietf.org [internet-drafts@ietf.org]
Date d'envoi : mardi 19 février 2013 00:30
À : MARCON, JEROME (JEROME)
Objet : New Version Notification for    draft-marcon-rtcweb-data-channel-management-00.txt

A new version of I-D, draft-marcon-rtcweb-data-channel-management-00.txt
has been successfully submitted by Jerome Marcon and posted to the
IETF repository.

Filename:        draft-marcon-rtcweb-data-channel-management
Revision:        00
Title:           RTCWeb data channel management
Creation date:   2013-02-19
Group:           Individual Submission
Number of pages: 15
URL:             http://www.ietf.org/internet-drafts/draft-marcon-rtcweb-data-channel-management-00.txt
Status:          http://datatracker.ietf.org/doc/draft-marcon-rtcweb-data-channel-management
Htmlized:        http://tools.ietf.org/html/draft-marcon-rtcweb-data-channel-management-00


Abstract:
   The Real-Time Communication in WEB-browsers (RTCWeb) working group is
   charged to provide protocols to support direct interactive rich
   communication using audio, video, and data between two peers' web-
   browsers.  For the support of data communication, the RTCWeb working
   group has in particular defined the concept of bi-directional data
   channels over SCTP.  How to transport application messages on these
   data channels seems straightforward (i.e. they can be carried as SCTP
   user messages), however it is yet to be decided how to establish and
   manage these data channels.  This document specifies a method for
   this, which relies first on a lightweight and scalable out-of-band
   negotiation of data channel configurations (within the SDP offer/
   answer exchange) and second on the signaling of the configuration in
   use in the SCTP user message itself.  Once these configurations are
   negotiated, further creations of data channels can occur purely in-
   band by simply sending user messages, which avoids to define a new
   in-band data channel protocol.




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


    

    

    

    
-- 
Salvatore Loreto, PhD
www.sloreto.com

  


--------------070505070506070503060504--

From salvatore.loreto@ericsson.com  Wed Mar  6 01: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 7478221F85C0 for ; Wed,  6 Mar 2013 01:24:40 -0800 (PST)
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 fwQco3ydc5gL for ; Wed,  6 Mar 2013 01:24:37 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id DB40421F84A6 for ; Wed,  6 Mar 2013 01:24:34 -0800 (PST)
X-AuditID: c1b4fb2d-b7f316d0000028db-50-51370b4f3894
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 87.CC.10459.F4B07315; Wed,  6 Mar 2013 10:24:32 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Wed, 6 Mar 2013 10:24:31 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 63A4C2AF0	for ; Wed,  6 Mar 2013 11:24:31 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 06F3B544AE	for ; Wed,  6 Mar 2013 11:24:29 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8C3EF54413	for ; Wed,  6 Mar 2013 11:24:28 +0200 (EET)
Message-ID: <51370B4E.5090004@ericsson.com>
Date: Wed, 6 Mar 2013 10:24:30 +0100
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> <5135C64A.50302@jesup.org>
In-Reply-To: <5135C64A.50302@jesup.org>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUyM+JvjW4At3mgwZITnBZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4+/zbYwFU1grOhbMZG1g7GTpYuTkkBAwkWjd+50VwhaTuHBv PVsXIxeHkMBJRonHp1ZAOesZJfo+TWaFcC4wSrQsbWCBcA4zSlzq+8EI4ZxhlJi16D7YYF4B bYl1u/rZQGwWARWJrYv2g8XZBMwknj/cwgxiiwokS/x7dIQRol5Q4uTMJ2A1IgLCEltf9TKB 2MIC7hIff3SyQyxYzSixuf0ZWBGngLrEjB3XwJqZBWwlLsy5zgJhy0tsfzuHGeIjNYmr5zaB 2UICWhK9ZzuZJjCKzEKybxaS9llI2hcwMq9iZM9NzMxJLzfcxAgM6INbfuvuYDx1TuQQozQH i5I4b5jrhQAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjEGfRQMN1h3IyWD+5aQsN23H+qvH nBW8QwySH//+ERn1YJ+IoGXln/++SmF7YioMdl+KDH57tethjWT1ifui1/5HVpw/Jml39tqt ipvzVsusm7f03ePrXQckFiSvXP/6C5OvxY5sbsXPTmslQ1/ybrsfunTrbw9PLiGn+S1Ox/20 2bXbPwu9N1RiKc5INNRiLipOBABUoODbNgIAAA==
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-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, 06 Mar 2013 09:24:40 -0000

On 3/5/13 11:17 AM, Randell Jesup wrote:
>
>> 3. Assuming an endpoint creating a new offer (e.g. to reflect a 
>> change in media streams) while an SCTP association is already 
>> established. In this case, what does the SCTP association m-line 
>> contain: the unchanged list of data channels contained in the initial 
>> offer (which created the SCTP association), or the list of data 
>> channels currently opened, or .. ?
>
> Just the listing for the association that was in the original offer 
> (though this would be the SCTP SDP MMUSIC draft's issue). 
I agree this is a SCTP SDP MMUSIC draft's issue
and is something we have to agree on


From Markus.Isomaki@nokia.com  Wed Mar  6 02:04: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 299B521F87C5 for ; Wed,  6 Mar 2013 02:04:43 -0800 (PST)
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 AVye3ALb+twE for ; Wed,  6 Mar 2013 02:04:42 -0800 (PST)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9812221F868F for ; Wed,  6 Mar 2013 02:04:42 -0800 (PST)
Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r26A3vRf028535; Wed, 6 Mar 2013 12:04:38 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 6 Mar 2013 12:04:12 +0200
Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.232]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0318.003; Wed, 6 Mar 2013 10:04:12 +0000
From: 
To: , 
Thread-Topic: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOGZadQwWRkr2Pv0KZo1p0ebE2i5iXXXaQ
Date: Wed, 6 Mar 2013 10:04:10 +0000
Message-ID: 
References:  <5135DA46.7050909@ericsson.com>
In-Reply-To: <5135DA46.7050909@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.21.81.63]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 06 Mar 2013 10:04:12.0196 (UTC) FILETIME=[F39A1E40:01CE1A51]
X-Nokia-AV: Clean
Subject: Re: [rtcweb] Agenda time request for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 06 Mar 2013 10:04:43 -0000

Hi,

Stefan H=E5kansson wrote:
>
>On 2013-03-04 23:31, Espen Berger (espeberg) wrote:
>> Hello,
>>
>> I would like to request agenda time for:
>>
>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>>
>> The document  presents use-cases underlining why WebRTC needs AMR-
>WB,
>>   AMR and G.722 as additional relevant voice codecs to satisfactorily
>> ensure interoperability with existing systems.
>
>I agree to that we should discuss the subject of additional codecs.
>

This is a controversial topic, but I agree it would deserve some discussion=
 to try to bring it to a closure.=20

Markus

From jerome.marcon@alcatel-lucent.com  Wed Mar  6 02:06: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 F2F0A21F8870 for ; Wed,  6 Mar 2013 02:06:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.729
X-Spam-Level: 
X-Spam-Status: No, score=-9.729 tagged_above=-999 required=5 tests=[AWL=0.520,  BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 ixPeCeZbFFtG for ; Wed,  6 Mar 2013 02:06:00 -0800 (PST)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBFD21F886E for ; Wed,  6 Mar 2013 02:06:00 -0800 (PST)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r26A4aQF008557 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Mar 2013 11:05:54 +0100
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 6 Mar 2013 11:05:32 +0100
Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.26]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 6 Mar 2013 11:05:32 +0100
From: "MARCON, JEROME (JEROME)" 
To: Michael Tuexen , "rtcweb@ietf.org" , Randell Jesup 
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt
Thread-Index: AQHOE6kv4waTKhEPkEqZxW6NBQbqlZiVlNqAgABEQ4CAAppZ0A==
Date: Wed, 6 Mar 2013 10:05:31 +0000
Message-ID: <39821B4C400EC14DAD4DB25330A9271A020C70@FR711WXCHMBA02.zeu.alcatel-lucent.com>
References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> <085532B8-9A37-44D6-B311-14AFEBDF5221@lurchi.franken.de>
In-Reply-To: <085532B8-9A37-44D6-B311-14AFEBDF5221@lurchi.franken.de>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-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, 06 Mar 2013 10:06:03 -0000

Thanks Michael, I still have a question/comment inline.

> -----Message d'origine-----
> De : Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]=20
> Envoy=E9 : lundi 4 mars 2013 19:47
> =C0 : MARCON, JEROME (JEROME)
> Cc : rtcweb@ietf.org; Randell Jesup
> Objet : Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt
>=20
> On Mar 4, 2013, at 3:36 PM, MARCON, JEROME (JEROME) wrote:
>=20
> >=20
> > Randell,
> >=20
> > Thanks for this update. There are some points not (yet)=20
> explained in the text:
> >=20
> > 1. Following the SDP opening handshake, are the data=20
> channels implicitly opened, or does the offerer send one=20
> DATA_CHANNEL_OPEN message per new data channel ?
> >=20
> > 2. "channel is available to send as soon as the=20
> DATA_CHANNEL_OPEN has been sent". And the SACK received I guess ?
> The SACK is an SCTP level ack. So you only know that the SCTP=20
> stack of the peer has received it, so you don't know if the=20
> application has received it or even processed it. So if you=20
> want some sort of ack, you need an application level ack.=20
> This was done in the 3 way handshake stuff which was in the=20
> older version.
>=20
> In this version, the sender sends an DATA_CHANNEL_OPEN as the=20
> first message and the receiver has to buffer user messages=20
> until the DATA_CHANNEL_OPEN message has been received in case=20
> of reordering in the network and using unordered delivery for=20
> user messages.
>=20
> Best regards
> Michael

OK thanks. I am not sure to get your last point about order of delivery. Yo=
u seem to refer to the SCTP endpoint behaviors (section 6.6) that unordered=
 messages a) could bypass the in-order messages in the outbound transmissio=
n queue and b) must be delivered before in-order messages on the receiver s=
ide.

But then the DATA_CHANNEL_OPEN message should be sent 'unordered'. Otherwis=
e this situation could occur: the sender app sends DATA_CHANNEL_OPEN 'in-or=
der' and then immediately many 'unordered' messages. Those messages would a=
ll bypass the transmission of the DATA_CHANNEL_OPEN message.

> >=20
> > 3. Assuming an endpoint creating a new offer (e.g. to=20
> reflect a change in media streams) while an SCTP association=20
> is already established. In this case, what does the SCTP=20
> association m-line contain: the unchanged list of data=20
> channels contained in the initial offer (which created the=20
> SCTP association), or the list of data channels currently=20
> opened, or .. ?
> >=20
> > 4. What happens if the SDP Opening Handshake agreed on some=20
> data channels using the 'chat' subprotocol, and later on an=20
> endpoint creates in-band a new channel with 'file transfer'=20
> subprotocol ?
> >=20
> > Jerome
> >=20
> >> -----Message d'origine-----
> >> De : rtcweb-bounces@ietf.org=20
> [mailto:rtcweb-bounces@ietf.org] De la=20
> >> part de internet-drafts@ietf.org Envoy=E9 : lundi 25 f=E9vrier=20
> 2013 23:40=20
> >> =C0 : i-d-announce@ietf.org Cc : rtcweb@ietf.org Objet :=20
> [rtcweb] I-D=20
> >> Action: draft-ietf-rtcweb-data-channel-04.txt
> >>=20
> >>=20
> >> A New Internet-Draft is available from the on-line=20
> >> Internet-Drafts directories.
> >> This draft is a work item of the Real-Time Communication in=20
> >> 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-04.txt
> >> 	Pages           : 13
> >> 	Date            : 2013-02-25
> >>=20
> >> Abstract:
> >>   The Web Real-Time Communication (WebRTC) working group is=20
> >> charged to
> >>   provide protocol support for direct interactive rich=20
> communication
> >>   using audio, video, and data between two peers'=20
> web-browsers.  This
> >>   document specifies the non-media data transport aspects of=20
> >> the WebRTC
> >>   framework.  It provides an architectural overview of how=20
> the Stream
> >>   Control Transmission Protocol (SCTP) is used in the WebRTC=20
> >> context as
> >>   a generic transport service allowing Web Browser to=20
> >> 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-04
> >>=20
> >> A diff from the previous version is available at:
> >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-data-channel-04
> >>=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
> >=20
>=20
> =

From jerome.marcon@alcatel-lucent.com  Wed Mar  6 02:40: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 0477C21F86F8 for ; Wed,  6 Mar 2013 02:40:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.816
X-Spam-Level: 
X-Spam-Status: No, score=-9.816 tagged_above=-999 required=5 tests=[AWL=0.433,  BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 sGq-eGJ4-JxO for ; Wed,  6 Mar 2013 02:40:19 -0800 (PST)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2A92021F86E4 for ; Wed,  6 Mar 2013 02:40:18 -0800 (PST)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r26AdWiN016866 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Mar 2013 11:40:16 +0100
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 6 Mar 2013 11:40:09 +0100
Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 6 Mar 2013 11:40:09 +0100
From: "MARCON, JEROME (JEROME)" 
To: Randell Jesup , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt
Thread-Index: AQHOE6kv4waTKhEPkEqZxW6NBQbqlZiVlNqAgAFIbACAAaCdEA==
Date: Wed, 6 Mar 2013 10:40:08 +0000
Message-ID: <39821B4C400EC14DAD4DB25330A9271A02108E@FR711WXCHMBA02.zeu.alcatel-lucent.com>
References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> <5135C64A.50302@jesup.org>
In-Reply-To: <5135C64A.50302@jesup.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-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, 06 Mar 2013 10:40:20 -0000

Randell,

Thanks, some other comments inline. Please answer (again) to question 4, I =
have other pending questions related to this matter.

Jerome

> -----Message d'origine-----
> De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org]=20
> De la part de Randell Jesup
> Envoy=E9 : mardi 5 mars 2013 11:18
> =C0 : rtcweb@ietf.org
> Objet : Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt
>=20
> On 3/4/2013 9:36 AM, MARCON, JEROME (JEROME) wrote:
> > Randell,
> >
> > Thanks for this update. There are some points not (yet)=20
> explained in the text:
> >
> > 1. Following the SDP opening handshake, are the data=20
> channels implicitly opened, or does the offerer send one=20
> DATA_CHANNEL_OPEN message per new data channel ?
>=20
> One Open per new channel which can be followed immediately=20
> with data. =20
> If the application has some out-of-band way to know about the=20
> channels expected (see the text), it could indicate so=20
> (effectively allowing application-mediated negotiation with=20
> no Open messages in-band - not that I generally would suggest=20
> this for normal uses).
>=20
OK, that should be in the text.

> > 2. "channel is available to send as soon as the=20
> DATA_CHANNEL_OPEN has been sent". And the SACK received I guess ?
>=20
> No SACK required I believe.  As far as SCTP is concerned,=20
> Open messages are just data on the stream.
>=20
I am following Michael's clarifications on this.

> > 3. Assuming an endpoint creating a new offer (e.g. to=20
> reflect a change in media streams) while an SCTP association=20
> is already established. In this case, what does the SCTP=20
> association m-line contain: the unchanged list of data=20
> channels contained in the initial offer (which created the=20
> SCTP association), or the list of data channels currently=20
> opened, or .. ?
>=20
> Just the listing for the association that was in the original=20
> offer (though this would be the SCTP SDP MMUSIC draft's issue).
>=20
OK, so you said In Boston. At least the text should say when the offer shou=
ld signal (or the answerer should interpret) that the list of data channels=
 is no longer valid. How to signal this is I understand in the scope of MMU=
SIC which hopefully will find a cleaner way that just repeating some now in=
valid information.=20

> > 4. What happens if the SDP Opening Handshake agreed on some=20
> data channels using the 'chat' subprotocol, and later on an=20
> endpoint creates in-band a new channel with 'file transfer'=20
> subprotocol ?
>=20
> When you create a channel, it sends Open on an unused Stream.
>=20
>=20

That does not answer to my question, so I reformulate: some time after the =
initial SDP Opening Handshake, can the DATA_CHANNEL_OPEN message create in-=
band a data channel with a 'subprotocol' not negotiated by the initial SDP =
Opening Handshake ?

>=20
> --
> Randell Jesup
> randell-ietf@jesup.org
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> =

From salvatore.loreto@ericsson.com  Wed Mar  6 02:45: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 4EA7C21F8611 for ; Wed,  6 Mar 2013 02:45:34 -0800 (PST)
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 9TLeVmfIzQsT for ; Wed,  6 Mar 2013 02:45:33 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5F23321F85D6 for ; Wed,  6 Mar 2013 02:45:33 -0800 (PST)
X-AuditID: c1b4fb2d-b7f316d0000028db-25-51371e4cebbd
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0F.1C.10459.C4E17315; Wed,  6 Mar 2013 11:45:32 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Wed, 6 Mar 2013 11:45:32 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id A95542AF0	for ; Wed,  6 Mar 2013 12:45:31 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 4BC6154659	for ; Wed,  6 Mar 2013 12:45:29 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D3A935463D	for ; Wed,  6 Mar 2013 12:45:28 +0200 (EET)
Message-ID: <51371E4A.4040602@ericsson.com>
Date: Wed, 6 Mar 2013 11:45:30 +0100
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> <5135C64A.50302@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02108E@FR711WXCHMBA02.zeu.alcatel-lucent.com>
In-Reply-To: <39821B4C400EC14DAD4DB25330A9271A02108E@FR711WXCHMBA02.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+Jvja6PnHmgwc+TihZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr48vkj8wFXWwVG5evYG1gfMfSxcjJISFgIvFo7gk2CFtM4sK9 9WC2kMBJRomGjTkQ9npGiaYvwV2MXED2BUaJA4s+s0A4hxklHq+bwwrhnGGUuHB9F1g7r4C2 xKyrV5lBbBYBFYlbX5eCxdkEzCSeP9wCFhcVSJb49+gII0S9oMTJmU/AThIREJbY+qqXCcQW FnCX+Pijkx1iwS9GibNXjoAN4hSIlviy7AcriM0sYCtxYc51FghbXmL72znMEP+oSVw9t4kZ 4gctid6znUwTGEVmIdk3C0n7LCTtCxiZVzGy5yZm5qSXG25iBAbzwS2/dXcwnjoncohRmoNF SZw3zPVCgJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGnlPLl7S8zNx2PlXXgllsj+WBO7YO r4w1EzbEz411z1H5wx2Ydk9B7MzMjU+OeE3lk9y+U3/K0TWX94bcvedQnnBYrWAz14QZgcdm Xfj3afrSaMZk4xuzPmzZedXi435DL+4/79RLsuuOLbCe8UvDq/K5c8ayD2rqpo17T7EyZiso GM5X11r3WYmlOCPRUIu5qDgRAL8RchA0AgAA
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-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, 06 Mar 2013 10:45:34 -0000

On 3/6/13 11:40 AM, MARCON, JEROME (JEROME) wrote:
>>> > >4. What happens if the SDP Opening Handshake agreed on some
>> >data channels using the 'chat' subprotocol, and later on an
>> >endpoint creates in-band a new channel with 'file transfer'
>> >subprotocol ?
>> >
>> >When you create a channel, it sends Open on an unused Stream.
>> >
>> >
> That does not answer to my question, so I reformulate: some time after the initial SDP Opening Handshake, can the DATA_CHANNEL_OPEN message create in-band a data channel with a 'subprotocol' not negotiated by the initial SDP Opening Handshake ?
>
I do think it should be possible to do it in-band

However I agree with you that an important side question is if/when that 
will be also signaled via SDP

/Salvatore

From jerome.marcon@alcatel-lucent.com  Wed Mar  6 04:09: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 AC28621F851E for ; Wed,  6 Mar 2013 04:09:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.878
X-Spam-Level: 
X-Spam-Status: No, score=-9.878 tagged_above=-999 required=5 tests=[AWL=0.371,  BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 RyjUO8mZItgP for ; Wed,  6 Mar 2013 04:09:38 -0800 (PST)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id E29A421F84C2 for ; Wed,  6 Mar 2013 04:09:32 -0800 (PST)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r26C7vsX029294 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Mar 2013 13:09:21 +0100
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 6 Mar 2013 13:08:55 +0100
Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 6 Mar 2013 13:08:55 +0100
From: "MARCON, JEROME (JEROME)" 
To: Salvatore Loreto , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt
Thread-Index: AQHOE6kv4waTKhEPkEqZxW6NBQbqlZiVlNqAgAFIbACAAaCdEP//+XgAgAAl0CA=
Date: Wed, 6 Mar 2013 12:08:54 +0000
Message-ID: <39821B4C400EC14DAD4DB25330A9271A0214C1@FR711WXCHMBA02.zeu.alcatel-lucent.com>
References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> <5135C64A.50302@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02108E@FR711WXCHMBA02.zeu.alcatel-lucent.com> <51371E4A.4040602@ericsson.com>
In-Reply-To: <51371E4A.4040602@ericsson.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-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, 06 Mar 2013 12:09:39 -0000

But then - and given that DATA_CHANNEL_OPEN_RESPONSE no longer exists in th=
is new draft version - I wonder how the peer can reject an incoming DATA_CH=
ANNEL_OPEN message signaling a 'subprotocol' it does not support.

> -----Message d'origine-----
> De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org]=20
> De la part de Salvatore Loreto
> Envoy=E9 : mercredi 6 mars 2013 11:46
> =C0 : rtcweb@ietf.org
> Objet : Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt
>=20
> On 3/6/13 11:40 AM, MARCON, JEROME (JEROME) wrote:
> >>> > >4. What happens if the SDP Opening Handshake agreed on some
> >> >data channels using the 'chat' subprotocol, and later on=20
> an endpoint=20
> >> >creates in-band a new channel with 'file transfer'
> >> >subprotocol ?
> >> >
> >> >When you create a channel, it sends Open on an unused Stream.
> >> >
> >> >
> > That does not answer to my question, so I reformulate: some=20
> time after the initial SDP Opening Handshake, can the=20
> DATA_CHANNEL_OPEN message create in-band a data channel with=20
> a 'subprotocol' not negotiated by the initial SDP Opening Handshake ?
> >
> I do think it should be possible to do it in-band
>=20
> However I agree with you that an important side question is=20
> if/when that will be also signaled via SDP
>=20
> /Salvatore
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> =

From salvatore.loreto@ericsson.com  Wed Mar  6 04:26: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 E75F221F883A for ; Wed,  6 Mar 2013 04:26:52 -0800 (PST)
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 qjLyc+HtEYxe for ; Wed,  6 Mar 2013 04:26:52 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id F27F821F86F8 for ; Wed,  6 Mar 2013 04:26:51 -0800 (PST)
X-AuditID: c1b4fb2d-b7f316d0000028db-31-5137360a8ec9
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 6F.EC.10459.A0637315; Wed,  6 Mar 2013 13:26:51 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Wed, 6 Mar 2013 13:26:50 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 98A8F2B2F; Wed,  6 Mar 2013 14:26:50 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 14076541DB; Wed,  6 Mar 2013 14:26:48 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6B69A5384F; Wed,  6 Mar 2013 14:26:47 +0200 (EET)
Message-ID: <51373608.50901@ericsson.com>
Date: Wed, 6 Mar 2013 13:26:48 +0100
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: "MARCON, JEROME (JEROME)" 
References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> <5135C64A.50302@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02108E@FR711WXCHMBA02.zeu.alcatel-lucent.com> <51371E4A.4040602@ericsson.com> <39821B4C400EC14DAD4DB25330A9271A0214C1@FR711WXCHMBA02.zeu.alcatel-lucent.com>
In-Reply-To: <39821B4C400EC14DAD4DB25330A9271A0214C1@FR711WXCHMBA02.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyM+JvjS63mXmgwbT7nBYXpzayWaz9187u wOTR+mwvq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDJ+rbnJXnCDp6L/7EGWBsZtXF2MnBwSAiYS d/+3skHYYhIX7q0Hsrk4hAROMkpMmv8fylnPKHF/RwsTSJWQwC5GiRnbQyASaxklFs97wATh bGOUaJ96gBGkildAU2Luqo0sIDaLgIrEsY8QcTYBM4nnD7cwg9iiAskS/x4dgaoXlDg58wlY vYiAg0TT2k2sIDazgLrEncXn2EFsYQF3iY8/Otkhlr1kkvg35SHYSZwC0RLnD8+DarCVuDDn OguELS/RvHU2M8RzahJXz21ihnhBS6L3bCfTBEbRWUh2z0LSPgtJ+wJG5lWM7LmJmTnp5Yab GIGhf3DLb90djKfOiRxilOZgURLnDXO9ECAkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB0av6 z5XG/TpfOZ/scDA8slDnZMZl/vU7T1ql9Rocn2HW90RAZ+O6kIzIrpyn5973/Hyad2gmu+R7 qdNP6i9uvJrszGaT6VJz8nFs/LWoIuHdreINapM+tZyTXiItxbN21lW/PRPl9sfFdMnnfj32 SjDquO/lcxd793iuE/2ycGqG+pvK3nmZh5RYijMSDbWYi4oTATcothZLAgAA
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-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, 06 Mar 2013 12:26:53 -0000

On 3/6/13 1:08 PM, MARCON, JEROME (JEROME) wrote:
> But then - and given that DATA_CHANNEL_OPEN_RESPONSE no longer exists in this new draft version - I wonder how the peer can reject an incoming DATA_CHANNEL_OPEN message signaling a 'subprotocol' it does not support.
well, it can simply and immediately close (i.e. resetting) the outgoing 
"peer" stream

/Salvatore

>
>> -----Message d'origine-----
>> De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org]
>> De la part de Salvatore Loreto
>> Envoyé : mercredi 6 mars 2013 11:46
>> À : rtcweb@ietf.org
>> Objet : Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt
>>
>> On 3/6/13 11:40 AM, MARCON, JEROME (JEROME) wrote:
>>>>>>> 4. What happens if the SDP Opening Handshake agreed on some
>>>>> data channels using the 'chat' subprotocol, and later on
>> an endpoint
>>>>> creates in-band a new channel with 'file transfer'
>>>>> subprotocol ?
>>>>>
>>>>> When you create a channel, it sends Open on an unused Stream.
>>>>>
>>>>>
>>> That does not answer to my question, so I reformulate: some
>> time after the initial SDP Opening Handshake, can the
>> DATA_CHANNEL_OPEN message create in-band a data channel with
>> a 'subprotocol' not negotiated by the initial SDP Opening Handshake ?
>> I do think it should be possible to do it in-band
>>
>> However I agree with you that an important side question is
>> if/when that will be also signaled via SDP
>>
>> /Salvatore
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb


From Michael.Tuexen@lurchi.franken.de  Wed Mar  6 04:36: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 3082621F8767 for ; Wed,  6 Mar 2013 04:36:16 -0800 (PST)
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 lXc3yAXboyUn for ; Wed,  6 Mar 2013 04:36:15 -0800 (PST)
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 BC8C121F86C5 for ; Wed,  6 Mar 2013 04:36:14 -0800 (PST)
Received: from [192.168.1.102] (p508F9FFE.dip.t-dialin.net [80.143.159.254]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 014181C0B4610; Wed,  6 Mar 2013 13:36:11 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=iso-8859-1
From: Michael Tuexen 
In-Reply-To: <39821B4C400EC14DAD4DB25330A9271A020C70@FR711WXCHMBA02.zeu.alcatel-lucent.com>
Date: Wed, 6 Mar 2013 13:36:07 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <1F61DA6E-21DD-43C3-8FC6-701E3B0ADDAF@lurchi.franken.de>
References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> <085532B8-9A37-44D6-B311-14AFEBDF5221@lurchi.franken.de> <39821B4C400EC14DAD4DB25330A9271A020C70@FR711WXCHMBA02.zeu.alcatel-lucent.com>
To: "MARCON, JEROME (JEROME)" 
X-Mailer: Apple Mail (2.1283)
Cc: Randell Jesup , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-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, 06 Mar 2013 12:36:16 -0000

On Mar 6, 2013, at 11:05 AM, MARCON, JEROME (JEROME) wrote:
>=20
> Thanks Michael, I still have a question/comment inline.
>=20
>> -----Message d'origine-----
>> De : Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]=20
>> Envoy=E9 : lundi 4 mars 2013 19:47
>> =C0 : MARCON, JEROME (JEROME)
>> Cc : rtcweb@ietf.org; Randell Jesup
>> Objet : Re: [rtcweb] I-D Action: =
draft-ietf-rtcweb-data-channel-04.txt
>>=20
>> On Mar 4, 2013, at 3:36 PM, MARCON, JEROME (JEROME) wrote:
>>=20
>>>=20
>>> Randell,
>>>=20
>>> Thanks for this update. There are some points not (yet)=20
>> explained in the text:
>>>=20
>>> 1. Following the SDP opening handshake, are the data=20
>> channels implicitly opened, or does the offerer send one=20
>> DATA_CHANNEL_OPEN message per new data channel ?
>>>=20
>>> 2. "channel is available to send as soon as the=20
>> DATA_CHANNEL_OPEN has been sent". And the SACK received I guess ?
>> The SACK is an SCTP level ack. So you only know that the SCTP=20
>> stack of the peer has received it, so you don't know if the=20
>> application has received it or even processed it. So if you=20
>> want some sort of ack, you need an application level ack.=20
>> This was done in the 3 way handshake stuff which was in the=20
>> older version.
>>=20
>> In this version, the sender sends an DATA_CHANNEL_OPEN as the=20
>> first message and the receiver has to buffer user messages=20
>> until the DATA_CHANNEL_OPEN message has been received in case=20
>> of reordering in the network and using unordered delivery for=20
>> user messages.
>>=20
>> Best regards
>> Michael
>=20
> OK thanks. I am not sure to get your last point about order of =
delivery. You seem to refer to the SCTP endpoint behaviors (section 6.6) =
that unordered messages a) could bypass the in-order messages in the =
outbound transmission queue and b) must be delivered before in-order =
messages on the receiver side.
>=20
> But then the DATA_CHANNEL_OPEN message should be sent 'unordered'. =
Otherwise this situation could occur: the sender app sends =
DATA_CHANNEL_OPEN 'in-order' and then immediately many 'unordered' =
messages. Those messages would all bypass the transmission of the =
DATA_CHANNEL_OPEN message.
That is why the receiver (the JS layer) has to buffer user messages if =
the DATA_CHANNEL_OPEN.
You have no way to make sure the the DATA_CHANNEL_OPEN is the first one =
delivered on the
receiver side, if the cannel provides unordered service. If the channel =
provides ordered
delivery, sending the DATA_CHANNEL_OPEN ordered, ensures that the JS =
layer gets them in the
correct order. So one can send the DATA_CHANNEL_OPEN always ordered, but =
the receiving JS
layer must be prepared to receive user message before it.
It you want to avoid this, you need the solution in the older version of =
the ID, where
you also send user messages ordered (even on an unordered channel) until =
you got a
DATA_CHANNEL_RESPONSE.

Best regards
Michael
>=20
>>>=20
>>> 3. Assuming an endpoint creating a new offer (e.g. to=20
>> reflect a change in media streams) while an SCTP association=20
>> is already established. In this case, what does the SCTP=20
>> association m-line contain: the unchanged list of data=20
>> channels contained in the initial offer (which created the=20
>> SCTP association), or the list of data channels currently=20
>> opened, or .. ?
>>>=20
>>> 4. What happens if the SDP Opening Handshake agreed on some=20
>> data channels using the 'chat' subprotocol, and later on an=20
>> endpoint creates in-band a new channel with 'file transfer'=20
>> subprotocol ?
>>>=20
>>> Jerome
>>>=20
>>>> -----Message d'origine-----
>>>> De : rtcweb-bounces@ietf.org=20
>> [mailto:rtcweb-bounces@ietf.org] De la=20
>>>> part de internet-drafts@ietf.org Envoy=E9 : lundi 25 f=E9vrier=20
>> 2013 23:40=20
>>>> =C0 : i-d-announce@ietf.org Cc : rtcweb@ietf.org Objet :=20
>> [rtcweb] I-D=20
>>>> Action: draft-ietf-rtcweb-data-channel-04.txt
>>>>=20
>>>>=20
>>>> A New Internet-Draft is available from the on-line=20
>>>> Internet-Drafts directories.
>>>> This draft is a work item of the Real-Time Communication in=20
>>>> 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-04.txt
>>>> 	Pages           : 13
>>>> 	Date            : 2013-02-25
>>>>=20
>>>> Abstract:
>>>>  The Web Real-Time Communication (WebRTC) working group is=20
>>>> charged to
>>>>  provide protocol support for direct interactive rich=20
>> communication
>>>>  using audio, video, and data between two peers'=20
>> web-browsers.  This
>>>>  document specifies the non-media data transport aspects of=20
>>>> the WebRTC
>>>>  framework.  It provides an architectural overview of how=20
>> the Stream
>>>>  Control Transmission Protocol (SCTP) is used in the WebRTC=20
>>>> context as
>>>>  a generic transport service allowing Web Browser to=20
>>>> 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-04
>>>>=20
>>>> A diff from the previous version is available at:
>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-data-channel-04
>>>>=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
>>>=20
>>=20
>>=20


From jerome.marcon@alcatel-lucent.com  Wed Mar  6 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 6239521F8A25 for ; Wed,  6 Mar 2013 07:04:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.924
X-Spam-Level: 
X-Spam-Status: No, score=-9.924 tagged_above=-999 required=5 tests=[AWL=0.325,  BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 mnTPnc8oeDJ7 for ; Wed,  6 Mar 2013 07:04:11 -0800 (PST)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4271621F89E2 for ; Wed,  6 Mar 2013 07:04:11 -0800 (PST)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r26F40UQ021289 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Mar 2013 16:04:09 +0100
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 6 Mar 2013 16:03:43 +0100
Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.26]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 6 Mar 2013 16:03:38 +0100
From: "MARCON, JEROME (JEROME)" 
To: Michael Tuexen , "rtcweb@ietf.org" , Randell Jesup 
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt
Thread-Index: AQHOE6kv4waTKhEPkEqZxW6NBQbqlZiVlNqAgABEQ4CAAppZ0IAAIsyAgAAx2aA=
Date: Wed, 6 Mar 2013 15:03:36 +0000
Message-ID: <39821B4C400EC14DAD4DB25330A9271A021951@FR711WXCHMBA02.zeu.alcatel-lucent.com>
References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> <085532B8-9A37-44D6-B311-14AFEBDF5221@lurchi.franken.de> <39821B4C400EC14DAD4DB25330A9271A020C70@FR711WXCHMBA02.zeu.alcatel-lucent.com> <1F61DA6E-21DD-43C3-8FC6-701E3B0ADDAF@lurchi.franken.de>
In-Reply-To: <1F61DA6E-21DD-43C3-8FC6-701E3B0ADDAF@lurchi.franken.de>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-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, 06 Mar 2013 15:04:12 -0000

=20

> -----Message d'origine-----
> De : Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]=20
> Envoy=E9 : mercredi 6 mars 2013 13:36
> =C0 : MARCON, JEROME (JEROME)
> Cc : rtcweb@ietf.org; Randell Jesup
> Objet : Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt
>=20
> On Mar 6, 2013, at 11:05 AM, MARCON, JEROME (JEROME) wrote:
> >=20
> > Thanks Michael, I still have a question/comment inline.
> >=20
> >> -----Message d'origine-----
> >> De : Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]
> >> Envoy=E9 : lundi 4 mars 2013 19:47
> >> =C0 : MARCON, JEROME (JEROME)
> >> Cc : rtcweb@ietf.org; Randell Jesup
> >> Objet : Re: [rtcweb] I-D Action:=20
> >> draft-ietf-rtcweb-data-channel-04.txt
> >>=20
> >> On Mar 4, 2013, at 3:36 PM, MARCON, JEROME (JEROME) wrote:
> >>=20
> >>>=20
> >>> Randell,
> >>>=20
> >>> Thanks for this update. There are some points not (yet)
> >> explained in the text:
> >>>=20
> >>> 1. Following the SDP opening handshake, are the data
> >> channels implicitly opened, or does the offerer send one=20
> >> DATA_CHANNEL_OPEN message per new data channel ?
> >>>=20
> >>> 2. "channel is available to send as soon as the
> >> DATA_CHANNEL_OPEN has been sent". And the SACK received I guess ?
> >> The SACK is an SCTP level ack. So you only know that the=20
> SCTP stack=20
> >> of the peer has received it, so you don't know if the=20
> application has=20
> >> received it or even processed it. So if you want some sort of ack,=20
> >> you need an application level ack.
> >> This was done in the 3 way handshake stuff which was in the older=20
> >> version.
> >>=20
> >> In this version, the sender sends an DATA_CHANNEL_OPEN as=20
> the first=20
> >> message and the receiver has to buffer user messages until the=20
> >> DATA_CHANNEL_OPEN message has been received in case of=20
> reordering in=20
> >> the network and using unordered delivery for user messages.
> >>=20
> >> Best regards
> >> Michael
> >=20
> > OK thanks. I am not sure to get your last point about order=20
> of delivery. You seem to refer to the SCTP endpoint behaviors=20
> (section 6.6) that unordered messages a) could bypass the=20
> in-order messages in the outbound transmission queue and b)=20
> must be delivered before in-order messages on the receiver side.
> >=20
> > But then the DATA_CHANNEL_OPEN message should be sent=20
> 'unordered'. Otherwise this situation could occur: the sender=20
> app sends DATA_CHANNEL_OPEN 'in-order' and then immediately=20
> many 'unordered' messages. Those messages would all bypass=20
> the transmission of the DATA_CHANNEL_OPEN message.
> That is why the receiver (the JS layer) has to buffer user=20
> messages if the DATA_CHANNEL_OPEN.
> You have no way to make sure the the DATA_CHANNEL_OPEN is the=20
> first one delivered on the receiver side, if the cannel=20
> provides unordered service. If the channel provides ordered=20
> delivery, sending the DATA_CHANNEL_OPEN ordered, ensures that=20
> the JS layer gets them in the correct order. So one can send=20
> the DATA_CHANNEL_OPEN always ordered, but the receiving JS=20
> layer must be prepared to receive user message before it.
> It you want to avoid this, you need the solution in the older=20
> version of the ID, where you also send user messages ordered=20
> (even on an unordered channel) until you got a DATA_CHANNEL_RESPONSE.
>=20
> Best regards
> Michael

I agree (in the context of your proposal) on the need for buffering user me=
ssages received on a closed channel. But still not sure about sending DATA_=
CHANNEL_OPEN 'in-order' always. Compare the results of setting or unsetting=
 the Unordered bit:

1a. 'in-order' DATA_CHANNEL_OPEN sent, then 'unordered' messages sent: DATA=
_CHANNEL_OPEN would be delivered last
1b. 'in-order' DATA_CHANNEL_OPEN sent, then 'ordered' messages sent: DATA_C=
HANNEL_OPEN would be delivered first

2a. 'unordered' DATA_CHANNEL_OPEN sent, then 'unordered' messages sent: DAT=
A_CHANNEL_OPEN would be delivered first or in-between or last
2b. 'unordered' DATA_CHANNEL_OPEN sent, then 'ordered' messages sent: DATA_=
CHANNEL_OPEN would be delivered first

So to me sending DATA_CHANNEL_OPEN 'unordered' is faster than - or as fast =
as - sending it 'in-order' (i.e 2a >=3D 1a). Sorry if I have missed somethi=
ng.

Observation: it seems suspicious in any case to receive an 'in-order' user =
message on a closed channel.

> >=20
> >>>=20
> >>> 3. Assuming an endpoint creating a new offer (e.g. to
> >> reflect a change in media streams) while an SCTP association is=20
> >> already established. In this case, what does the SCTP association=20
> >> m-line contain: the unchanged list of data channels=20
> contained in the=20
> >> initial offer (which created the SCTP association), or the list of=20
> >> data channels currently opened, or .. ?
> >>>=20
> >>> 4. What happens if the SDP Opening Handshake agreed on some
> >> data channels using the 'chat' subprotocol, and later on=20
> an endpoint=20
> >> creates in-band a new channel with 'file transfer'
> >> subprotocol ?
> >>>=20
> >>> Jerome
> >>>=20
> >>>> -----Message d'origine-----
> >>>> De : rtcweb-bounces@ietf.org
> >> [mailto:rtcweb-bounces@ietf.org] De la
> >>>> part de internet-drafts@ietf.org Envoy=E9 : lundi 25 f=E9vrier
> >> 2013 23:40
> >>>> =C0 : i-d-announce@ietf.org Cc : rtcweb@ietf.org Objet :=20
> >> [rtcweb] I-D
> >>>> Action: draft-ietf-rtcweb-data-channel-04.txt
> >>>>=20
> >>>>=20
> >>>> A New Internet-Draft is available from the on-line=20
> Internet-Drafts=20
> >>>> directories.
> >>>> This draft is a work item of the Real-Time Communication in=20
> >>>> 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-04.txt
> >>>> 	Pages           : 13
> >>>> 	Date            : 2013-02-25
> >>>>=20
> >>>> Abstract:
> >>>>  The Web Real-Time Communication (WebRTC) working group=20
> is charged=20
> >>>> to  provide protocol support for direct interactive rich
> >> communication
> >>>>  using audio, video, and data between two peers'=20
> >> web-browsers.  This
> >>>>  document specifies the non-media data transport aspects of the=20
> >>>> WebRTC  framework.  It provides an architectural overview of how
> >> the Stream
> >>>>  Control Transmission Protocol (SCTP) is used in the=20
> WebRTC context=20
> >>>> as  a generic transport service allowing Web Browser to exchange=20
> >>>> 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-04
> >>>>=20
> >>>> A diff from the previous version is available at:
> >>>>=20
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-data-channel-04
> >>>>=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
> >>>=20
> >>=20
> >>=20
>=20
> =

From harald@alvestrand.no  Wed Mar  6 07: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 3481211E8134 for ; Wed,  6 Mar 2013 07:28:35 -0800 (PST)
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 YK6eOiiLOC2V for ; Wed,  6 Mar 2013 07:28:33 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5C46B11E8133 for ; Wed,  6 Mar 2013 07:28:33 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D8B6F39E05D for ; Wed,  6 Mar 2013 16:28:30 +0100 (CET)
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 SW5BcK6YYuVp for ; Wed,  6 Mar 2013 16:28:29 +0100 (CET)
Received: from [172.16.39.12] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 560AB39E03A for ; Wed,  6 Mar 2013 16:28:29 +0100 (CET)
Message-ID: <5137609B.70407@alvestrand.no>
Date: Wed, 06 Mar 2013 16:28:27 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <39821B4C400EC14DAD4DB25330A9271A01929A@FR711WXCHMBA03.zeu.alcatel-lucent.com>
In-Reply-To: <39821B4C400EC14DAD4DB25330A9271A01929A@FR711WXCHMBA03.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Data channel setup: scalability, user experience, labels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 06 Mar 2013 15:28:35 -0000

On 03/04/2013 07:36 PM, MARCON, JEROME (JEROME) wrote:
> I would like to get rough opinions on three data channel related topics:
>
> Scalability-challenging scenarios
> ---------------------
> If I am not mistaken, Randell mentioned in Boston some data channel setup scenarios like: 1000 data channels opened in the same session, and possibly 100 data channels opened simultaneously (usage: file transfer). I agree it is important to keep some scalability objectives in mind when taking decisions on the data channel setup design. So what about a list of real-life scalability-challenging scenarios like:
>
> 1. No SCTP association is established, and an endpoint wishes to open 100 data channels for the same usage (e.g. file transfer)
>
> 2. An SCTP association is established, and an endpoint wishes to open 100 data channels for the same usage (e.g. file transfer)
>
> 3. An endpoint creates and closes a data channel at a high frequency, for the same usage (probably an app misbehavior here, but...)
>
> 4. ...any other?

If you want to establish minimum performance levels that a conforming 
application will have to support, we can certainly consider that.

We should start by stating the minimum number of video and audio 
channels that a conforming application will have to support, since this 
is important for a lot of the RTCWEB use cases, and may impact really 
scarce resources like hardware decoders.

Supporting an extra data channel is one more control block. Perhaps a 
few kilobytes of RAM. Buffer space (if the data channel congests) is 
likely to take far more memory than the control blocks; should we also 
create specifications on the minimum amount of memory available for buffers?

Seriously, I see all these as quality-of-implementation issues. We 
should make sure the API specification is clear about what happens when 
the browser runs out of resources, and leave it at that.
(FWIW, a rendering process in Chrome that runs out of memory, for any 
reason, will crash. Recovery is accomplished by the user pushing "reload".)

> User consent
> ---------------------
> These scalability-challenging scenarios not only raise scalability issues, but user experience issues as well. Should these be relevant in IETF (and not in W3C), which user consent is appropriate in the context of data channel setup ?
>
> A) Assuming an initial/updating SDP offer declaring one 'chat' channel and 100 'file transfer' channels, each with a distinct label. The user consent will be:
> * 1-line: "open data channels [for this time only | anytime during this session] for any usage/subprotocol"
> * 2-line: "open data channels [for this time only | anytime during this session] for usage/subprotocol: (1) chat (2) file transfer"
> * 101-line: "open data channels for this time only for usage/subprotocol.label: (1) chat.label1 (2) file transfer.label 2... (101) file transfer.label 101"
>
> B) Assuming a data channel created in-band, with a subprotocol already negotiated
> * I assume user consent is not required here ?
>
> C) Assuming a data channel created in-band, with a subprotocol 'file transfer' never negotiated before in the SDP handshake (I think only Randell's proposal allows this)
> * 1-line: "open a data channel for this time only for usage/subprotocol.label = chat.label1"
> * 1-line: "open a data channel [for this time only | anytime during this session] for usage/subprotocol = chat"
>
>  From these (too much detailed) cases, we can identify 3 main types of user consent for data channel setup:
> U1. open any number of data channels of any type: prompted at the time of SCTP association setup
> U2. open any number of data channels of a given usage/subprotocol: prompted the first time this subprotocol is signaled to the peer (in SDP or in-band)
> U3. open one data channel of a given usage/subprotocol of a given label
>
> Label usefulness
> ---------------------
> I would like to understand the usefulness of data channel labels. Considering that:
> - (if user consent is of type U1 or U2 described above) labels do not take part of user consent
> - labels are no longer used as data channel identifiers (SCTP stream numbers are better for this, according to the 3 data channel setup proposals on the table: Randell's, Martin's and mine).
> - W3C says nothing about the use of data channel labels
>
> Jerome
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From harald@alvestrand.no  Wed Mar  6 07:29: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 64D0621F85FC for ; Wed,  6 Mar 2013 07:29:46 -0800 (PST)
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 qOn0pYc8TyDR for ; Wed,  6 Mar 2013 07:29:45 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6890221F846C for ; Wed,  6 Mar 2013 07:29:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7651539E05D for ; Wed,  6 Mar 2013 16:29:43 +0100 (CET)
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 lnRgyInIIUX4 for ; Wed,  6 Mar 2013 16:29:42 +0100 (CET)
Received: from [172.16.39.12] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id F36B039E03A for ; Wed,  6 Mar 2013 16:29:41 +0100 (CET)
Message-ID: <513760E3.6070601@alvestrand.no>
Date: Wed, 06 Mar 2013 16:29:39 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <39821B4C400EC14DAD4DB25330A9271A01929A@FR711WXCHMBA03.zeu.alcatel-lucent.com>
In-Reply-To: <39821B4C400EC14DAD4DB25330A9271A01929A@FR711WXCHMBA03.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Data channel setup: scalability, user experience, labels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 06 Mar 2013 15:29:46 -0000

On 03/04/2013 07:36 PM, MARCON, JEROME (JEROME) wrote:
> I would like to get rough opinions on three data channel related topics:
>
> Scalability-challenging scenarios
> ---------------------
> If I am not mistaken, Randell mentioned in Boston some data channel setup scenarios like: 1000 data channels opened in the same session, and possibly 100 data channels opened simultaneously (usage: file transfer). I agree it is important to keep some scalability objectives in mind when taking decisions on the data channel setup design. So what about a list of real-life scalability-challenging scenarios like:
>
> 1. No SCTP association is established, and an endpoint wishes to open 100 data channels for the same usage (e.g. file transfer)
>
> 2. An SCTP association is established, and an endpoint wishes to open 100 data channels for the same usage (e.g. file transfer)
>
> 3. An endpoint creates and closes a data channel at a high frequency, for the same usage (probably an app misbehavior here, but...)
>
> 4. ...any other?

If you want to establish minimum performance levels that a conforming 
application will have to support, we can certainly consider that.

We should start by stating the minimum number of video and audio 
channels that a conforming application will have to support, since this 
is important for a lot of the RTCWEB use cases, and may impact really 
scarce resources like hardware decoders.

Supporting an extra data channel is one more control block. Perhaps a 
few kilobytes of RAM. Buffer space (if the data channel congests) is 
likely to take far more memory than the control blocks; should we also 
create specifications on the minimum amount of memory available for buffers?

Seriously, I see all these as quality-of-implementation issues. We 
should make sure the API specification is clear about what happens when 
the browser runs out of resources, and leave it at that.
(FWIW, a rendering process in Chrome that runs out of memory, for any 
reason, will crash. Recovery is accomplished by the user pushing "reload".)

> User consent
> ---------------------
> These scalability-challenging scenarios not only raise scalability issues, but user experience issues as well. Should these be relevant in IETF (and not in W3C), which user consent is appropriate in the context of data channel setup ?
>
> A) Assuming an initial/updating SDP offer declaring one 'chat' channel and 100 'file transfer' channels, each with a distinct label. The user consent will be:
> * 1-line: "open data channels [for this time only | anytime during this session] for any usage/subprotocol"
> * 2-line: "open data channels [for this time only | anytime during this session] for usage/subprotocol: (1) chat (2) file transfer"
> * 101-line: "open data channels for this time only for usage/subprotocol.label: (1) chat.label1 (2) file transfer.label 2... (101) file transfer.label 101"
>
> B) Assuming a data channel created in-band, with a subprotocol already negotiated
> * I assume user consent is not required here ?
>
> C) Assuming a data channel created in-band, with a subprotocol 'file transfer' never negotiated before in the SDP handshake (I think only Randell's proposal allows this)
> * 1-line: "open a data channel for this time only for usage/subprotocol.label = chat.label1"
> * 1-line: "open a data channel [for this time only | anytime during this session] for usage/subprotocol = chat"
>
>  From these (too much detailed) cases, we can identify 3 main types of user consent for data channel setup:
> U1. open any number of data channels of any type: prompted at the time of SCTP association setup
> U2. open any number of data channels of a given usage/subprotocol: prompted the first time this subprotocol is signaled to the peer (in SDP or in-band)
> U3. open one data channel of a given usage/subprotocol of a given label

We already have consensus that data channels don't require user consent; 
they expose no significant new security issues compared to data transfer 
via a Web server, which is already possible without user consent.

Please stop; the horse is dead.

> Label usefulness
> ---------------------
> I would like to understand the usefulness of data channel labels. Considering that:
> - (if user consent is of type U1 or U2 described above) labels do not take part of user consent
> - labels are no longer used as data channel identifiers (SCTP stream numbers are better for this, according to the 3 data channel setup proposals on the table: Randell's, Martin's and mine).
> - W3C says nothing about the use of data channel labels

Randell's proposal means that the channel number is not known before the 
channel is created for the normal case. (He suggests an "advanced" 
mechanism for forcing the channel number.)

Labels are useful for creating channels where the receiving application 
knows what channels to expect, but doesn't know the channel number in 
advance.

Exercise for the reader: Write an application that uses multiple data 
channels, and does not force channel numbers. Try

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


From randell-ietf@jesup.org  Wed Mar  6 07:53: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 BDE3321F8C9F for ; Wed,  6 Mar 2013 07:53:27 -0800 (PST)
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 DWlOVbpoxgOt for ; Wed,  6 Mar 2013 07:53:27 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 5285521F8A2A for ; Wed,  6 Mar 2013 07:53:27 -0800 (PST)
Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:1881 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UDGek-000AUy-Ga for rtcweb@ietf.org; Wed, 06 Mar 2013 09:53:26 -0600
Message-ID: <51376643.8090204@jesup.org>
Date: Wed, 06 Mar 2013 10:52:35 -0500
From: Randell Jesup 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> <5135C64A.50302@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02108E@FR711WXCHMBA02.zeu.alcatel-lucent.com> <51371E4A.4040602@ericsson.com> <39821B4C400EC14DAD4DB25330A9271A0214C1@FR711WXCHMBA02.zeu.alcatel-lucent.com>
In-Reply-To: <39821B4C400EC14DAD4DB25330A9271A0214C1@FR711WXCHMBA02.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-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, 06 Mar 2013 15:53:27 -0000

On 3/6/2013 7:08 AM, MARCON, JEROME (JEROME) wrote:
> But then - and given that DATA_CHANNEL_OPEN_RESPONSE no longer exists in this new draft version - I wonder how the peer can reject an incoming DATA_CHANNEL_OPEN message signaling a 'subprotocol' it does not support.

channel.close();

I.e. there's no explicit prior-to-connect rejection, you simply state 
instead "I'm not interested" and close it.  This resets the streams, and 
causes the other side to be notified of the close. You're correct in 
that this is not distinguished from other reasons to close() it; if 
those are needed you should either negotiate it out-of-band, or make a 
rejection part of the protocol you run over it.  This is entirely within 
the application's domain.  Most applications would have no need for this.

-- 
Randell Jesup
randell-ietf@jesup.org


From randell-ietf@jesup.org  Wed Mar  6 08:05: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 3FC6C21F85E8 for ; Wed,  6 Mar 2013 08:05:20 -0800 (PST)
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 AIf+oDP6GulW for ; Wed,  6 Mar 2013 08:05:19 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id AE03921F85D8 for ; Wed,  6 Mar 2013 08:05:19 -0800 (PST)
Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:1892 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UDGqF-000Gd7-4L for rtcweb@ietf.org; Wed, 06 Mar 2013 10:05:19 -0600
Message-ID: <5137690C.20105@jesup.org>
Date: Wed, 06 Mar 2013 11:04:28 -0500
From: Randell Jesup 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> <085532B8-9A37-44D6-B311-14AFEBDF5221@lurchi.franken.de> <39821B4C400EC14DAD4DB25330A9271A020C70@FR711WXCHMBA02.zeu.alcatel-lucent.com> <1F61DA6E-21DD-43C3-8FC6-701E3B0ADDAF@lurchi.franken.de> <39821B4C400EC14DAD4DB25330A9271A021951@FR711WXCHMBA02.zeu.alcatel-lucent.com>
In-Reply-To: <39821B4C400EC14DAD4DB25330A9271A021951@FR711WXCHMBA02.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-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, 06 Mar 2013 16:05:20 -0000

On 3/6/2013 10:03 AM, MARCON, JEROME (JEROME) wrote:
>
>>
>> In this version, the sender sends an DATA_CHANNEL_OPEN as the first
>> message and the receiver has to buffer user messages until the
>> DATA_CHANNEL_OPEN message has been received in case of
>> reordering in
>> the network and using unordered delivery for user messages.
>>
>> Best regards
>> Michael
>>> OK thanks. I am not sure to get your last point about order
>>> of delivery. You seem to refer to the SCTP endpoint behaviors
>>> (section 6.6) that unordered messages a) could bypass the
>>> in-order messages in the outbound transmission queue and b)
>>> must be delivered before in-order messages on the receiver side.
>>> But then the DATA_CHANNEL_OPEN message should be sent
>>> 'unordered'. Otherwise this situation could occur: the sender
>>> app sends DATA_CHANNEL_OPEN 'in-order' and then immediately
>>> many 'unordered' messages. Those messages would all bypass
>>> the transmission of the DATA_CHANNEL_OPEN message.

>> That is why the receiver (the JS layer) has to buffer user
>> messages if the DATA_CHANNEL_OPEN.
>> You have no way to make sure the the DATA_CHANNEL_OPEN is the
>> first one delivered on the receiver side, if the cannel
>> provides unordered service. If the channel provides ordered
>> delivery, sending the DATA_CHANNEL_OPEN ordered, ensures that
>> the JS layer gets them in the correct order. So one can send
>> the DATA_CHANNEL_OPEN always ordered, but the receiving JS
>> layer must be prepared to receive user message before it.
>> It you want to avoid this, you need the solution in the older
>> version of the ID, where you also send user messages ordered
>> (even on an unordered channel) until you got a DATA_CHANNEL_RESPONSE.
>>
>> Best regards
>> Michael
> I agree (in the context of your proposal) on the need for buffering user messages received on a closed channel. But still not sure about sending DATA_CHANNEL_OPEN 'in-order' always. Compare the results of setting or unsetting the Unordered bit:
>
> 1a. 'in-order' DATA_CHANNEL_OPEN sent, then 'unordered' messages sent: DATA_CHANNEL_OPEN would be delivered last

I think you may be mis-reading RFC 2960 #6.6... I think in almost all 
cases, the OPEN would be received before the unordered data.  I think 
6.6 means that unordered data following it *can* jump ahead of it in the 
reception buffer, though in practice I think that would only happen if 
the OPEN were blocked from being delivered by a missing ordered packet 
preceding it - which wouldn't exist in this protocol.

However, if this is incorrect, nothing would be harmed by sending OPENs 
for unordered channels in an unordered fashion, so long as they're reliable.

> 1b. 'in-order' DATA_CHANNEL_OPEN sent, then 'ordered' messages sent: DATA_CHANNEL_OPEN would be delivered first
>
> 2a. 'unordered' DATA_CHANNEL_OPEN sent, then 'unordered' messages sent: DATA_CHANNEL_OPEN would be delivered first or in-between or last
> 2b. 'unordered' DATA_CHANNEL_OPEN sent, then 'ordered' messages sent: DATA_CHANNEL_OPEN would be delivered first
>
> So to me sending DATA_CHANNEL_OPEN 'unordered' is faster than - or as fast as - sending it 'in-order' (i.e 2a >= 1a). Sorry if I have missed something.
>
> Observation: it seems suspicious in any case to receive an 'in-order' user message on a closed channel.
>

-- 
Randell Jesup
randell-ietf@jesup.org


From randell-ietf@jesup.org  Wed Mar  6 08:10: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 63AFB21F86A6 for ; Wed,  6 Mar 2013 08:10:41 -0800 (PST)
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 mCqyAEziX4JN for ; Wed,  6 Mar 2013 08:10:40 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5E921F8644 for ; Wed,  6 Mar 2013 08:10:34 -0800 (PST)
Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:1896 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UDGvJ-0002N9-J9 for rtcweb@ietf.org; Wed, 06 Mar 2013 10:10:33 -0600
Message-ID: <51376A46.70203@jesup.org>
Date: Wed, 06 Mar 2013 11:09:42 -0500
From: Randell Jesup 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <39821B4C400EC14DAD4DB25330A9271A01929A@FR711WXCHMBA03.zeu.alcatel-lucent.com> <5137609B.70407@alvestrand.no>
In-Reply-To: <5137609B.70407@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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
Subject: Re: [rtcweb] Data channel setup: scalability, user experience, labels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 06 Mar 2013 16:10:41 -0000

On 3/6/2013 10:28 AM, Harald Alvestrand wrote:
> On 03/04/2013 07:36 PM, MARCON, JEROME (JEROME) wrote:
>> I would like to get rough opinions on three data channel related topics:
>>
>> Scalability-challenging scenarios
>> ---------------------
>> If I am not mistaken, Randell mentioned in Boston some data channel 
>> setup scenarios like: 1000 data channels opened in the same session, 
>> and possibly 100 data channels opened simultaneously (usage: file 
>> transfer). I agree it is important to keep some scalability 
>> objectives in mind when taking decisions on the data channel setup 
>> design. So what about a list of real-life scalability-challenging 
>> scenarios like:
>>
>> 1. No SCTP association is established, and an endpoint wishes to open 
>> 100 data channels for the same usage (e.g. file transfer)
>>
>> 2. An SCTP association is established, and an endpoint wishes to open 
>> 100 data channels for the same usage (e.g. file transfer)
>>
>> 3. An endpoint creates and closes a data channel at a high frequency, 
>> for the same usage (probably an app misbehavior here, but...)
>>
>> 4. ...any other?
>
> If you want to establish minimum performance levels that a conforming 
> application will have to support, we can certainly consider that.
>
> We should start by stating the minimum number of video and audio 
> channels that a conforming application will have to support, since 
> this is important for a lot of the RTCWEB use cases, and may impact 
> really scarce resources like hardware decoders.
>
> Supporting an extra data channel is one more control block. Perhaps a 
> few kilobytes of RAM. Buffer space (if the data channel congests) is 
> likely to take far more memory than the control blocks; should we also 
> create specifications on the minimum amount of memory available for 
> buffers?

Actually, my understanding from Michael/Randall is that the number of 
streams allowed (defined in the association) only has a few bytes of 
overhead per stream.  For each stream in use, you'd have some pretty 
lightweight protocol-wrapping and DOM objects.  The protocol-wrapping 
objects are probably a few hundred bytes each, normally.  The DOM 
objects are base-size-of-a-DOM-object plus a few typical items (event 
handlers, etc) plus the user code attached to them - which may be the 
largest per-channel overhead.

>
> Seriously, I see all these as quality-of-implementation issues. We 
> should make sure the API specification is clear about what happens 
> when the browser runs out of resources, and leave it at that.
> (FWIW, a rendering process in Chrome that runs out of memory, for any 
> reason, will crash. Recovery is accomplished by the user pushing 
> "reload".)

Agreed.

-- 
Randell Jesup
randell-ietf@jesup.org


From Michael.Tuexen@lurchi.franken.de  Wed Mar  6 08:26: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 DB5A321F8AC3 for ; Wed,  6 Mar 2013 08:26:12 -0800 (PST)
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 oLy21lgDlRet for ; Wed,  6 Mar 2013 08:26:12 -0800 (PST)
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 6604721F89E9 for ; Wed,  6 Mar 2013 08:26:11 -0800 (PST)
Received: from [192.168.1.102] (p508FB97F.dip.t-dialin.net [80.143.185.127]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id C69BB1C0C069D; Wed,  6 Mar 2013 17:26:08 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=iso-8859-1
From: Michael Tuexen 
In-Reply-To: <39821B4C400EC14DAD4DB25330A9271A021951@FR711WXCHMBA02.zeu.alcatel-lucent.com>
Date: Wed, 6 Mar 2013 17:26:07 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> <085532B8-9A37-44D6-B311-14AFEBDF5221@lurchi.franken.de> <39821B4C400EC14DAD4DB25330A9271A020C70@FR711WXCHMBA02.zeu.alcatel-lucent.com> <1F61DA6E-21DD-43C3-8FC6-701E3B0ADDAF@lurchi.franken.de> <39821B4C400EC14DAD4DB25330A9271A021951@FR711WXCHMBA02.zeu.alcatel-lucent.com>
To: "MARCON, JEROME (JEROME)" 
X-Mailer: Apple Mail (2.1283)
Cc: Randell Jesup , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-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, 06 Mar 2013 16:26:13 -0000

On Mar 6, 2013, at 4:03 PM, MARCON, JEROME (JEROME) wrote:

>=20
>=20
>> -----Message d'origine-----
>> De : Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]=20
>> Envoy=E9 : mercredi 6 mars 2013 13:36
>> =C0 : MARCON, JEROME (JEROME)
>> Cc : rtcweb@ietf.org; Randell Jesup
>> Objet : Re: [rtcweb] I-D Action: =
draft-ietf-rtcweb-data-channel-04.txt
>>=20
>> On Mar 6, 2013, at 11:05 AM, MARCON, JEROME (JEROME) wrote:
>>>=20
>>> Thanks Michael, I still have a question/comment inline.
>>>=20
>>>> -----Message d'origine-----
>>>> De : Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]
>>>> Envoy=E9 : lundi 4 mars 2013 19:47
>>>> =C0 : MARCON, JEROME (JEROME)
>>>> Cc : rtcweb@ietf.org; Randell Jesup
>>>> Objet : Re: [rtcweb] I-D Action:=20
>>>> draft-ietf-rtcweb-data-channel-04.txt
>>>>=20
>>>> On Mar 4, 2013, at 3:36 PM, MARCON, JEROME (JEROME) wrote:
>>>>=20
>>>>>=20
>>>>> Randell,
>>>>>=20
>>>>> Thanks for this update. There are some points not (yet)
>>>> explained in the text:
>>>>>=20
>>>>> 1. Following the SDP opening handshake, are the data
>>>> channels implicitly opened, or does the offerer send one=20
>>>> DATA_CHANNEL_OPEN message per new data channel ?
>>>>>=20
>>>>> 2. "channel is available to send as soon as the
>>>> DATA_CHANNEL_OPEN has been sent". And the SACK received I guess ?
>>>> The SACK is an SCTP level ack. So you only know that the=20
>> SCTP stack=20
>>>> of the peer has received it, so you don't know if the=20
>> application has=20
>>>> received it or even processed it. So if you want some sort of ack,=20=

>>>> you need an application level ack.
>>>> This was done in the 3 way handshake stuff which was in the older=20=

>>>> version.
>>>>=20
>>>> In this version, the sender sends an DATA_CHANNEL_OPEN as=20
>> the first=20
>>>> message and the receiver has to buffer user messages until the=20
>>>> DATA_CHANNEL_OPEN message has been received in case of=20
>> reordering in=20
>>>> the network and using unordered delivery for user messages.
>>>>=20
>>>> Best regards
>>>> Michael
>>>=20
>>> OK thanks. I am not sure to get your last point about order=20
>> of delivery. You seem to refer to the SCTP endpoint behaviors=20
>> (section 6.6) that unordered messages a) could bypass the=20
>> in-order messages in the outbound transmission queue and b)=20
>> must be delivered before in-order messages on the receiver side.
>>>=20
>>> But then the DATA_CHANNEL_OPEN message should be sent=20
>> 'unordered'. Otherwise this situation could occur: the sender=20
>> app sends DATA_CHANNEL_OPEN 'in-order' and then immediately=20
>> many 'unordered' messages. Those messages would all bypass=20
>> the transmission of the DATA_CHANNEL_OPEN message.
>> That is why the receiver (the JS layer) has to buffer user=20
>> messages if the DATA_CHANNEL_OPEN.
>> You have no way to make sure the the DATA_CHANNEL_OPEN is the=20
>> first one delivered on the receiver side, if the cannel=20
>> provides unordered service. If the channel provides ordered=20
>> delivery, sending the DATA_CHANNEL_OPEN ordered, ensures that=20
>> the JS layer gets them in the correct order. So one can send=20
>> the DATA_CHANNEL_OPEN always ordered, but the receiving JS=20
>> layer must be prepared to receive user message before it.
>> It you want to avoid this, you need the solution in the older=20
>> version of the ID, where you also send user messages ordered=20
>> (even on an unordered channel) until you got a DATA_CHANNEL_RESPONSE.
>>=20
>> Best regards
>> Michael
>=20
> I agree (in the context of your proposal) on the need for buffering =
user messages received on a closed channel. But still not sure about =
sending DATA_CHANNEL_OPEN 'in-order' always. Compare the results of =
setting or unsetting the Unordered bit:
>=20
> 1a. 'in-order' DATA_CHANNEL_OPEN sent, then 'unordered' messages sent: =
DATA_CHANNEL_OPEN would be delivered last
No. If the DATA_CHANNEL_OPEN is received first by SCTP, it will be =
received first by the App.
>=20
> 1b. 'in-order' DATA_CHANNEL_OPEN sent, then 'ordered' messages sent: =
DATA_CHANNEL_OPEN would be delivered first
Correct.
>=20
> 2a. 'unordered' DATA_CHANNEL_OPEN sent, then 'unordered' messages =
sent: DATA_CHANNEL_OPEN would be delivered first or in-between or last
Correct.
> 2b. 'unordered' DATA_CHANNEL_OPEN sent, then 'ordered' messages sent: =
DATA_CHANNEL_OPEN would be delivered first
No. If the ordered message is received first, it gets delivered first.

Please note that the network layer might reorder packets or packets get =
lost and needs to be retransmitted.

Best regards
Michael
>=20
> So to me sending DATA_CHANNEL_OPEN 'unordered' is faster than - or as =
fast as - sending it 'in-order' (i.e 2a >=3D 1a). Sorry if I have missed =
something.
>=20
> Observation: it seems suspicious in any case to receive an 'in-order' =
user message on a closed channel.
>=20
>>>=20
>>>>>=20
>>>>> 3. Assuming an endpoint creating a new offer (e.g. to
>>>> reflect a change in media streams) while an SCTP association is=20
>>>> already established. In this case, what does the SCTP association=20=

>>>> m-line contain: the unchanged list of data channels=20
>> contained in the=20
>>>> initial offer (which created the SCTP association), or the list of=20=

>>>> data channels currently opened, or .. ?
>>>>>=20
>>>>> 4. What happens if the SDP Opening Handshake agreed on some
>>>> data channels using the 'chat' subprotocol, and later on=20
>> an endpoint=20
>>>> creates in-band a new channel with 'file transfer'
>>>> subprotocol ?
>>>>>=20
>>>>> Jerome
>>>>>=20
>>>>>> -----Message d'origine-----
>>>>>> De : rtcweb-bounces@ietf.org
>>>> [mailto:rtcweb-bounces@ietf.org] De la
>>>>>> part de internet-drafts@ietf.org Envoy=E9 : lundi 25 f=E9vrier
>>>> 2013 23:40
>>>>>> =C0 : i-d-announce@ietf.org Cc : rtcweb@ietf.org Objet :=20
>>>> [rtcweb] I-D
>>>>>> Action: draft-ietf-rtcweb-data-channel-04.txt
>>>>>>=20
>>>>>>=20
>>>>>> A New Internet-Draft is available from the on-line=20
>> Internet-Drafts=20
>>>>>> directories.
>>>>>> This draft is a work item of the Real-Time Communication in=20
>>>>>> 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-04.txt
>>>>>> 	Pages           : 13
>>>>>> 	Date            : 2013-02-25
>>>>>>=20
>>>>>> Abstract:
>>>>>> The Web Real-Time Communication (WebRTC) working group=20
>> is charged=20
>>>>>> to  provide protocol support for direct interactive rich
>>>> communication
>>>>>> using audio, video, and data between two peers'=20
>>>> web-browsers.  This
>>>>>> document specifies the non-media data transport aspects of the=20
>>>>>> WebRTC  framework.  It provides an architectural overview of how
>>>> the Stream
>>>>>> Control Transmission Protocol (SCTP) is used in the=20
>> WebRTC context=20
>>>>>> as  a generic transport service allowing Web Browser to exchange=20=

>>>>>> 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-04
>>>>>>=20
>>>>>> A diff from the previous version is available at:
>>>>>>=20
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-data-channel-04
>>>>>>=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
>>>>>=20
>>>>=20
>>>>=20
>>=20
>>=20


From Michael.Tuexen@lurchi.franken.de  Wed Mar  6 08:29: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 D887F21F8A98 for ; Wed,  6 Mar 2013 08:29:57 -0800 (PST)
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 Gtb4IYgB9XMR for ; Wed,  6 Mar 2013 08:29:57 -0800 (PST)
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 18FDC21F8A64 for ; Wed,  6 Mar 2013 08:29:51 -0800 (PST)
Received: from [192.168.1.102] (p508FB97F.dip.t-dialin.net [80.143.185.127]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 0F9DD1C0C069D; Wed,  6 Mar 2013 17:29:49 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Michael Tuexen 
In-Reply-To: <5137690C.20105@jesup.org>
Date: Wed, 6 Mar 2013 17:29:49 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4A1A73CF-DC19-477A-9124-E7EBAF6F09E7@lurchi.franken.de>
References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> <085532B8-9A37-44D6-B311-14AFEBDF5221@lurchi.franken.de> <39821B4C400EC14DAD4DB25330A9271A020C70@FR711WXCHMBA02.zeu.alcatel-lucent.com> <1F61DA6E-21DD-43C3-8FC6-701E3B0ADDAF@lurchi.franken.de> <39821B4C400EC14DAD4DB25330A9271A021951@FR711WXCHMBA02.zeu.alcatel-lucent.com> <5137690C.20105@jesup.org>
To: Randell Jesup 
X-Mailer: Apple Mail (2.1283)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-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, 06 Mar 2013 16:29:58 -0000

On Mar 6, 2013, at 5:04 PM, Randell Jesup wrote:

> On 3/6/2013 10:03 AM, MARCON, JEROME (JEROME) wrote:
>>=20
>>>=20
>>> In this version, the sender sends an DATA_CHANNEL_OPEN as the first
>>> message and the receiver has to buffer user messages until the
>>> DATA_CHANNEL_OPEN message has been received in case of
>>> reordering in
>>> the network and using unordered delivery for user messages.
>>>=20
>>> Best regards
>>> Michael
>>>> OK thanks. I am not sure to get your last point about order
>>>> of delivery. You seem to refer to the SCTP endpoint behaviors
>>>> (section 6.6) that unordered messages a) could bypass the
>>>> in-order messages in the outbound transmission queue and b)
>>>> must be delivered before in-order messages on the receiver side.
>>>> But then the DATA_CHANNEL_OPEN message should be sent
>>>> 'unordered'. Otherwise this situation could occur: the sender
>>>> app sends DATA_CHANNEL_OPEN 'in-order' and then immediately
>>>> many 'unordered' messages. Those messages would all bypass
>>>> the transmission of the DATA_CHANNEL_OPEN message.
>=20
>>> That is why the receiver (the JS layer) has to buffer user
>>> messages if the DATA_CHANNEL_OPEN.
>>> You have no way to make sure the the DATA_CHANNEL_OPEN is the
>>> first one delivered on the receiver side, if the cannel
>>> provides unordered service. If the channel provides ordered
>>> delivery, sending the DATA_CHANNEL_OPEN ordered, ensures that
>>> the JS layer gets them in the correct order. So one can send
>>> the DATA_CHANNEL_OPEN always ordered, but the receiving JS
>>> layer must be prepared to receive user message before it.
>>> It you want to avoid this, you need the solution in the older
>>> version of the ID, where you also send user messages ordered
>>> (even on an unordered channel) until you got a =
DATA_CHANNEL_RESPONSE.
>>>=20
>>> Best regards
>>> Michael
>> I agree (in the context of your proposal) on the need for buffering =
user messages received on a closed channel. But still not sure about =
sending DATA_CHANNEL_OPEN 'in-order' always. Compare the results of =
setting or unsetting the Unordered bit:
>>=20
>> 1a. 'in-order' DATA_CHANNEL_OPEN sent, then 'unordered' messages =
sent: DATA_CHANNEL_OPEN would be delivered last
>=20
> I think you may be mis-reading RFC 2960 #6.6... I think in almost all =
cases, the OPEN would be received before the unordered data.  I think =
6.6 means that unordered data following it *can* jump ahead of it in the =
reception buffer, though in practice I think that would only happen if =
the OPEN were blocked from being delivered by a missing ordered packet =
preceding it - which wouldn't exist in this protocol.
6.6. has no mandatory text on this... We push messages in the socket =
buffer as soon as we can. When they
are read by the application is up to the application.

The text allows you to bypass the ordering queue with an emphasis on =
preference to unordered messages.
But implementation details might come into the game.

Using a callback API allows to deliver as soon as possible, but if there =
is a socket buffer in the
game things might happen there...

Best regards
Michael
>=20
> However, if this is incorrect, nothing would be harmed by sending =
OPENs for unordered channels in an unordered fashion, so long as they're =
reliable.
>=20
>> 1b. 'in-order' DATA_CHANNEL_OPEN sent, then 'ordered' messages sent: =
DATA_CHANNEL_OPEN would be delivered first
>>=20
>> 2a. 'unordered' DATA_CHANNEL_OPEN sent, then 'unordered' messages =
sent: DATA_CHANNEL_OPEN would be delivered first or in-between or last
>> 2b. 'unordered' DATA_CHANNEL_OPEN sent, then 'ordered' messages sent: =
DATA_CHANNEL_OPEN would be delivered first
>>=20
>> So to me sending DATA_CHANNEL_OPEN 'unordered' is faster than - or as =
fast as - sending it 'in-order' (i.e 2a >=3D 1a). Sorry if I have missed =
something.
>>=20
>> Observation: it seems suspicious in any case to receive an 'in-order' =
user message on a closed channel.
>>=20
>=20
> --=20
> Randell Jesup
> randell-ietf@jesup.org
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>=20


From coverdale@sympatico.ca  Wed Mar  6 09: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 A7CAB21F8C32 for ; Wed,  6 Mar 2013 09:10:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.289
X-Spam-Level: 
X-Spam-Status: No, score=-0.289 tagged_above=-999 required=5 tests=[AWL=1.507,  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 yc-GoZ1zPuwa for ; Wed,  6 Mar 2013 09:10:37 -0800 (PST)
Received: from blu0-omc3-s30.blu0.hotmail.com (blu0-omc3-s30.blu0.hotmail.com [65.55.116.105]) by ietfa.amsl.com (Postfix) with ESMTP id 25EB321F8AF4 for ; Wed,  6 Mar 2013 09:10:37 -0800 (PST)
Received: from BLU0-SMTP76 ([65.55.116.72]) by blu0-omc3-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 6 Mar 2013 09:10:32 -0800
X-EIP: [bbM+MlwY2vDWbVtekqvfOZ8Qez7gQ+ZF]
X-Originating-Email: [coverdale@sympatico.ca]
Message-ID: 
Received: from PaulNewPC ([70.54.90.206]) by BLU0-SMTP76.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 6 Mar 2013 09:10:29 -0800
From: Paul Coverdale 
To: 
References: 	<5135DA46.7050909@ericsson.com> 
In-Reply-To: 
Date: Wed, 6 Mar 2013 12:10:23 -0500
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: AQHOGZadQwWRkr2Pv0KZo1p0ebE2i5iXXXaQgAGHdTA=
Content-Language: en-us
X-OriginalArrivalTime: 06 Mar 2013 17:10:29.0600 (UTC) FILETIME=[80EC3E00:01CE1A8D]
Subject: Re: [rtcweb] Agenda time request	for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 06 Mar 2013 17:10:37 -0000

Yes, draft-marjou-rtcweb-audio-codecs-for-interop-01 provides a proposal =
for
additional text to be added to draft-ietf-rtcweb-audio-01, which is an
rtcweb milestone supposed to be already completed. So it's not =
unreasonable
to have some discussion on the topic.

...Paul

>-----Original Message-----
>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On =
Behalf
>Of Markus.Isomaki@nokia.com
>Sent: Wednesday, March 06, 2013 5:04 AM
>To: stefan.lk.hakansson@ericsson.com; rtcweb@ietf.org
>Subject: Re: [rtcweb] Agenda time request for =
draft-marjou-rtcweb-audio-
>codecs-for-interop-01
>
>Hi,
>
>Stefan H=E5kansson wrote:
>>
>>On 2013-03-04 23:31, Espen Berger (espeberg) wrote:
>>> Hello,
>>>
>>> I would like to request agenda time for:
>>>
>>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>>>
>>> The document  presents use-cases underlining why WebRTC needs AMR-
>>WB,
>>>   AMR and G.722 as additional relevant voice codecs to =
satisfactorily
>>> ensure interoperability with existing systems.
>>
>>I agree to that we should discuss the subject of additional codecs.
>>
>
>This is a controversial topic, but I agree it would deserve some
>discussion to try to bring it to a closure.
>
>Markus


From harald@alvestrand.no  Wed Mar  6 09:47: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 66A3821F8D10 for ; Wed,  6 Mar 2013 09:47:23 -0800 (PST)
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 lZE3LpGSauYj for ; Wed,  6 Mar 2013 09:47:22 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A30A421F8D0D for ; Wed,  6 Mar 2013 09:47:19 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5E34F39E05D; Wed,  6 Mar 2013 18:47:18 +0100 (CET)
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 e7B+3N2TZpA2; Wed,  6 Mar 2013 18:47:17 +0100 (CET)
Received: from [172.16.39.12] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 85BC539E03A; Wed,  6 Mar 2013 18:47:16 +0100 (CET)
Message-ID: <51378121.5010908@alvestrand.no>
Date: Wed, 06 Mar 2013 18:47:13 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: Ted Hardie 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Richard Barnes , rtcweb@ietf.org, rtcweb-chairs@tools.ietf.org
Subject: [rtcweb] Time allocation for video codec MTI (Re: DRAFT Agenda for RTCWEB)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 06 Mar 2013 17:47:23 -0000

(this may be a repeat, but I can't find the other mail)

On 02/27/2013 06:49 PM, Ted Hardie wrote:
> Video Codec                       10:15 to 11:30
> 1. draft-alvestrand-rtcweb-vp8-01 (15 mins)
> 2. draft-burman-rtcweb-h264-proposal-01+draft-dbenham-webrtcvideomti-01+draft-marjou-rtcweb-video-codec-00
> (25 mins)
>        Discussion (30 minutes)
>        Call the question (5 minutes)

Looking at what has to be presented, and the likelyhood of questions, I 
think a more reasonable (less optimistic) allocation of time for the VP8 
part of this discussion would be 15 minutes for presentations and 15 
minutes for clarifying questions.


From robin@hookflash.com  Wed Mar  6 15:45: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 0470A21F8A79 for ; Wed,  6 Mar 2013 15:45:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.244
X-Spam-Level: *
X-Spam-Status: No, score=1.244 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_CPE=0.979, HOST_EQ_MODEMCABLE=1.368, MIME_QP_LONG_LINE=1.396, 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 PM4nnyT1WcFS for ; Wed,  6 Mar 2013 15:45:23 -0800 (PST)
Received: from mail-ia0-x22f.google.com (mail-ia0-x22f.google.com [IPv6:2607:f8b0:4001:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2204C21F8A6F for ; Wed,  6 Mar 2013 15:45:22 -0800 (PST)
Received: by mail-ia0-f175.google.com with SMTP id y26so124077iab.6 for ; Wed, 06 Mar 2013 15:45:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=ZpQXyHQRQQfSd8zcsWGnehAkokCIc77RNh+4o42h+Ao=; b=Sn8XCa1jNmFg4FS1iYSnVg3UES4aSpKlG2LbpRBzx0LHj28kUA/BRRgyaJMBsygw48 zS05fc94cRdqLqmAlrM0+gyYKOptI1saW9uKZH9mWusR0Bkmd4Gnp/CusqbCMVJ68kUQ XD5Usx/kQhaeq2B5qC9BzcW+wi9PhqvS4TdIQQuST8+Dcr8Nu4UOx++oZBg9Gyhe+pKD yARQM+ADqIysNtJQHGDLgt2KaCuOsx111J8oRbfATHpSRcG81yJmnGGHspihltJ9v9l4 dg6iqW0f9k3CqyUoO1vR7S8DvOzZJzBLhbm0K3phmpEcvLXp0SMWhqDio3B19zQ8QhR/ jSBw==
X-Received: by 10.50.170.69 with SMTP id ak5mr13028105igc.56.1362613522523; Wed, 06 Mar 2013 15:45:22 -0800 (PST)
Received: from [192.168.17.159] (CPE602ad08742f7-CM602ad08742f4.cpe.net.cable.rogers.com. [99.224.116.224]) by mx.google.com with ESMTPS id xf4sm24682614igb.8.2013.03.06.15.45.19 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 06 Mar 2013 15:45:21 -0800 (PST)
User-Agent: Microsoft-MacOutlook/14.3.1.130117
Date: Wed, 06 Mar 2013 18:45:09 -0500
From: Robin Raymond 
To: 
Message-ID: 
Thread-Topic: Proposed Plan for Usage of SDP and RTP - Lower level API minus SDP
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-Gm-Message-State: ALoCoQnOoSYDLvwww4XDQ9ucdKyGMYDbkeqU91l3ydAJohfGIMux4809TFESQFFjPsdKiMJRA9tH
Subject: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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, 06 Mar 2013 23:45:24 -0000

                  =20
                  =20
                  =20
                  =20
Do we need SDP "blob" format in the exchange in the first place? All media
can be done without SDP given an intelligent stream API. An API already
exists to create these streams (albeit somewhat lacking if we remove the
SDP 'blob'). This API helps "simplify" creating this blob for later
exchange. But the blob is truly not needed. Each side could in fact create
the desired streams, pass in the appropriate media information such as
codecs and ICE candidates and chose the socket pair to multiplex upon.
Yes, it's a bit more low level but it certainly can be done (and cleanly).

https://datatracker.ietf.org/doc/draft-jennings-rtcweb-plan/

Nothing wrong with the draft in an SDP/SIP mindset but I'm going to take
it from a totally different non-SDP angle. I have to say, the ideas
presented are very good. I appreciate FEC, and synchronizing streams is
cool. But SDP isn=B9t needed to do it. Let me as the programmer worry about
how to manage streams and the features on the streams and associations
between the streams via an API only.

Point 4, 5 and 6 in the specification all have to do with the complexities
of having to describe the intentions of mixing in SDP. So no comment
beyond =B3don=B9t use SDP=B2.

As for 7.1 =AD =B3this is because the sender choses the SSRC=B2 =AD only true
because we are forced to use SDP and the assumptions is that it=B9s SIP. We
could have the receiver dictate what the sender should use in advance of
any media. In our case, we establish in advance what we want from all
parties before even =B3ringing=B2 the other party. We do not have SSRC
collisions as we reversed the scenario allowing the receiver to pick the
expected SSRC. Coordinating the streams is a problem with SIP because of
how they do forking/conferencing. This specification forces this issue on
those not using SIP. If SIP has problems with streams arriving early to
their stateful offer/answer then let them worry about =B3how=B2 they intend to
match the streams at a higher SDP layer and get this draft out of the
RTCWEB track on the SIP track. To be clear, the proposal seems entirely
reasonable and intelligent for SIP/SDP. But it=B9s way to SIP centric for
general use.

On that note, what I do need in the API is an ability to dictate the SSRC
when I create an RTP stream for sending (should I care to do that).

7.2 Multiple render

Again this is an issue of SIP/SDP. We can control the SSRCs to split them
out to allow multiplexing easily on the same RTP ports with multiple
parties/sources. If given the primitives to control the streams just, this
specification could be used to dictate how to negotiate issues in their
space.

7.2.1 I=B9m feeling the pain. How about just giving me an API where I can
indicate what streams are FEC associated.

7.3 Give me API to give crypto keys to RTP layer. Let me handle the
fingerprint and security myself beyond that.

8. Let's just say politely that I would not want to be the developer
assigned to programming around all this stuff.

Again, a perfect illustration why I don=B9t want SDP.

Media is complicated for good reason as there are many untold use cases.
The entire IETF/W3C discussion around video constraints illustrates some
of the complexities and competing desires for just one single media type.
If we tie ourselves to SDP we are limiting ourselves big time, and some of
the cool future stuff will be horribly hampered by it.

My issues with SDP can be summarized as:

- unneeded - much too high level an API
- arcane format - legacy and problematic
- offer/answer
- incompatibilities
- lack of API contact
- doesn't truly solve goal of interoperability with legacy systems (eg.
SIP)

Regret that I did not have time for feedback earlier. As you can tell, I
am not at all happy with where we sit today wrt requiring SDP. IMHO we
need a lower level API if we are going to insist on using SDP.


You can read my entire (long) rant against SDP here
http://blog.webrtc.is/2013/03/06/sdp-the-webrtc-boat-anchor/




From martin.thomson@gmail.com  Wed Mar  6 17:03: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 B481521F8763 for ; Wed,  6 Mar 2013 17:03:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_48=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 wV6R0JJf4z+N for ; Wed,  6 Mar 2013 17:03:52 -0800 (PST)
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 80FF721F86A5 for ; Wed,  6 Mar 2013 17:03:51 -0800 (PST)
Received: by mail-wi0-f174.google.com with SMTP id hi8so508142wib.13 for ; Wed, 06 Mar 2013 17:03:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=8jhk1U8YHAQAL8AykaKWbLgX/1QP+8TwJ1mKQ+wQK1I=; b=TI5aSaKfr8iUOeJn2BUSf+ZjaGysZh5nzJ/zNjhPlVzj1prM8CIrcHsvS8Hvwy1ZWz PweyZVU1sbfwKxd2sLqKKwcDkCGgVRGQTfe9kUK/zWk24GaR5FHZ0zHGnBcrn9ziy4ht zHtMJyV/GHWyf6Hq8gogftO7ZZp4vuD0r+tJp5UzcGRgzuhAldSU/NYKqsyAcHFTDMG+ WPCmDDYT6vZJlR4dzO6nLnpor7nxPQPFxTzc+Sc/m3HTPpCo4QE6DG6ja09dEijvOj/3 NjNk1kQjuMy5frZtJPRnbCfwbMUlAyj9RJ1WzGHO/5VgbkKX8iqIxBTsIm7UXUESfJdl UB0Q==
MIME-Version: 1.0
X-Received: by 10.194.76.37 with SMTP id h5mr51294625wjw.21.1362618230579; Wed, 06 Mar 2013 17:03:50 -0800 (PST)
Received: by 10.194.5.135 with HTTP; Wed, 6 Mar 2013 17:03:50 -0800 (PST)
In-Reply-To: <39821B4C400EC14DAD4DB25330A9271A02039F@FR711WXCHMBA02.zeu.alcatel-lucent.com>
References:  <39821B4C400EC14DAD4DB25330A9271A019231@FR711WXCHMBA03.zeu.alcatel-lucent.com>  <39821B4C400EC14DAD4DB25330A9271A02039F@FR711WXCHMBA02.zeu.alcatel-lucent.com>
Date: Wed, 6 Mar 2013 17:03:50 -0800
Message-ID: 
From: Martin Thomson 
To: "MARCON, JEROME (JEROME)" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Data Channels Proposal: Now in Internet Draft Form
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 07 Mar 2013 01:03:52 -0000

I don't want to get into too deep on details.  The PPID thing is a
detail that would enable more flexibility, but that flexibility is
negotiable.  In my experience, I don't see there being much value in
negotiation/signaling "protocol" identifiers.  A priori knowledge
trumps these in most cases and WebRTC already has a strong reliance on
a priori knowledge.

On 5 March 2013 17:20, MARCON, JEROME (JEROME)
 wrote:
> Thanks. Two new comments inline.
>
> Also, if you could outline the Data Channel API needed to support your pr=
oposal, that would help the understanding.
>
>> -----Message d'origine-----
>> De : Martin Thomson [mailto:martin.thomson@gmail.com]
>> Envoy=C3=A9 : lundi 4 mars 2013 18:01
>> =C3=80 : MARCON, JEROME (JEROME)
>> Cc : rtcweb@ietf.org
>> Objet : Re: [rtcweb] Data Channels Proposal: Now in Internet
>> Draft Form
>>
>> Brief answers inline.
>>
>> On 4 March 2013 08:28, MARCON, JEROME (JEROME)
>>  wrote:
>> >
>> > Hi Martin, thanks for your proposal. I have some comments/questions:
>> >
>> > 1. So the label locally assigned to a data channel created
>> in-band is
>> > not transmitted to the peer ? (note that I am fine with this)
>>
>> The label is a handle that is provided to the application as
>> a convenience.  The label is a new invention, which I'm not
>> certain we entirely need.  It might provide some use, but
>> it's unclear how it adds value over the subprotocol label.
>>
>> > 2. Whereas defaulting properties like order or reliability
>> is more or less OK, it seems more critical to default the
>> subprotocol property. The app would have to parse the
>> incoming user message to guess if this message is about
>> 'chat' or 'file transfer'
>>
>> Actually, in most cases, an application will only ever
>> receive packets that they know about beforehand.  If they
>> need to distinguish between chat and file transfer, they will
>> have established conventions for identifying those packets.
>> PPID is one possible convention, though I note that most uses
>> of SCTP I've seen don't use more than one value, so most code
>> ends up ignoring the PPID.
>>
>> I share the same leeriness about the "protocol" label used in
>> thewebsocketprotocol.
>
> Before the 'subprotocol' concept was ever discussed, I thought the SDP O/=
A should allow to negotiate the PPID to use for each channel (applied to al=
l messages of this channel) where the PPID would be a true IANA-registered =
protocol defined over SCTP. Now I am fine with the negotiation of 'subproto=
col' value.
>
> Randell's proposal is reserving the PPID for the per-message text/binary/=
control signaling, so 'subprotocol' and PPID are orthogonal. But your propo=
sal is exposing the per-message PPID to the app (regardless of the negotiat=
ed subprotocol). So the roles of 'subprotocol' and PPID seem to potentially=
 overlap (although semantically the PPID signals some protocol over a unidi=
rectional SCTP stream, whereas 'subprotocol' rather signals some protocol o=
ver a bi-directional RTCWeb data channel). Maybe you have some thoughts on =
the potential relationships between a registered PPID and a registered subp=
rotocol (1-1, 1-N, N-1, etc.). Example: if I write an RFC porting a file tr=
ansfer protocol over RTCWeb data channel, would the RFC reserve exclusively=
 one PPID XXX and one 'file transfer XXX' subprotocol value ?
>
> What bothers me so far in your proposal is the 'try and guess' property s=
election process left to the app when a message is received on a closed cha=
nnel, for the 'subprotocol' property in particular. But if the subprotocol =
can be deterministically inferred from the incoming user message PPID, then=
 that's a lot better.
>>
>> > 3. Why does StreamID need to be exposed to the app ? I
>> first thought it was to allow in-band data channel creation
>> by a simple message sending. But then:
>> > - either the StreamID is a parameter of send(streamID, data) - and
>> > this breaks the alignment with WebSocket API and also the
>> app has no
>> > handle on this data channel
>> > - or streamID is a parameter of createDataChannel and this seems
>> > useless as the browser is able to select a new stream number
>> > internally
>>
>> Stream ID is exposed to the app because it allows the app to
>> create their own usage pattern.  It can create the streams it
>> wants and attach meaning to those numbers.  That said, stream
>> IDs are allocated automatically by the browser for most uses.
>>  I'd expect that streamId would be an optional constraint
>> (i.e., optional in usage) on channel creation.
>>
>> There is no in-band protocol, except for the one that the
>> application uses.  That's important.
>>
>
>> > 4.  Why does binaryPPID need to be exposed to the app ? The
>> browser is expected to infer the message type from the data
>> passed to send().
>>
>> binaryPPID allows the application to generate (though not
>> consume, except in constrained cases) SCTP that can be
>> consumed by any application.  The browser doesn't "infer"
>> anything about message types, other than when messages use
>> the textual PPID, in which case they are surfaced as strings
>> rather than the specified binary type (a Blob or ArrayBuffer).
>>
>
>> > 5. Finally to decrease the number of mismatching properties
>> situations, you could simply assign a "Default=3Dstrict|loose"
>> property to one of the data channels in the SDP.
>> > If set to "strict", endpoints could only create in-band
>> data channels
>> > for which the default set of properties applies. To create
>> other types of data channels in-band, renegotiation is
>> required If set to "loose'", an endpoint receiving a user
>> message on an closed data channel would open the data channel
>> using these default properties. But with the risk of mismatch
>> on subprotocol...
>> > This would make scalable setup scenarios like:
>> > - the SDP offer/answer exchange negotiates one 'chat' data channel,
>> > and one 'file transfer' Default data channel
>> > - later on, either endpoint creates in-band 100 data
>> channels for file transfer -> no renegotiation needed, no
>> property mismatch.
>>
>> That's unnecessary.  If I want an application that has one "special"
>> channel and an arbitrary number of "normal" channels, I can
>> do exactly as you say and then set the properties of those
>> spontaneously created channels as they appear.  It doesn't
>> require any more standardization or browser machinery:
>>
>> pc.addEventListener('datachannel', function(e) {
>>   var fileTransferChannel =3D e.channel;
>>   fileTransferChannel.ordered =3D true;
>>   fileTransferChannel.subprotocol =3D 'filetransfer'; });
>>
>> > This reduces the mismatching situations, in the case where
>> one single set of properties is mostly used at a given time
>> in the session. But the browser (or the app) has to guess at
>> the time of SDP negotiation which set of properties should be
>> the default, i.e. will be used more frequently than the
>> others later on in the session.
>> >
>> > An extended (and deterministic) approach is to restrict the
>> role of SDP offer/answer to the negotiation of some
>> identified set of properties (not data channels). Then data
>> channels are created in-band by the sending of user messages
>> on closed streams, where each user message includes a "set of
>> properties" identifier. You may have a look at the draft I
>> have submitted.
>>
>> I didn't see a specific need for negotiating properties in
>> such a generic fashion.  Ultimately, each property needs some
>> semantics when you use it, so it seemed excessive.  In SDP at
>> least, the extension mechanism is well enough understood to
>> be able to support extension enough to allow for new
>> properties to be defined (like ordering, which I omitted from
>> my draft by mistake).
>>
>> That said, if you are defining an in-band protocol (a bad
>> idea in my opinion), the idea that properties are generic
>> makes a great deal of sense.  That allows applications to
>> define what they need and allows them to avoid unnecessary noise.
>
> Like you advise, I also propose is an out-of-band SDP negotiation of sets=
 of generic properties, with no properties carried in-band. Where I differ =
is that the selection of some properties (e.g. subprotocol) to apply to a c=
hannel created from an incoming message must be always (not just sometimes)=
 deterministic.
>
>>
>> --Martin
>>

From magnus.westerlund@ericsson.com  Thu Mar  7 01:23: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 4AB3D21F8AA6 for ; Thu,  7 Mar 2013 01:23:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.099
X-Spam-Level: 
X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=0.150, 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 0mDnSAE8qxrB for ; Thu,  7 Mar 2013 01:23:03 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C3F1221F8A43 for ; Thu,  7 Mar 2013 01:22:49 -0800 (PST)
X-AuditID: c1b4fb25-b7f366d000004d10-ae-51385c6809d7
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 3A.54.19728.86C58315; Thu,  7 Mar 2013 10:22:48 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Thu, 7 Mar 2013 10:22:48 +0100
Message-ID: <51385C67.3040407@ericsson.com>
Date: Thu, 7 Mar 2013 10:22:47 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org, EKR 
References: 
In-Reply-To: 
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpiluLIzCtJLcpLzFFi42KZGfG3RjcjxiLQYEWjocWK1+fYLdb+a2d3 YPJYsuQnk8fkx23MAUxRXDYpqTmZZalF+nYJXBkX7y5hLdguV3F60XP2BsYVEl2MnBwSAiYS ex9vZYGwxSQu3FvPBmILCZxklFgxFSjOBWQvY5SYP2UiWIJXQFvi1IS3rCA2i4CKxNW398Ca 2QQsJG7+aASq4eAQFQiWuLlYDqJcUOLkzCdgJSIC6hIz5m8DGyMs4CGx49B2ZohdARLPnz9n BmnlFAiU6NyYBnGOpMSWF+3sIDazgJ7ElKstjBC2vETz1tlQrdoSDU0drBMYBWch2TYLScss JC0LGJlXMbLnJmbmpJcbbWIEhuPBLb9VdzDeOSdyiFGag0VJnDfc9UKAkEB6YklqdmpqQWpR fFFpTmrxIUYmDk6pBkaPfcbHLuixhvO3K/YznvglldUTaL9isU7ahlz7vw6n7eTnFVUcCNOf 6bjV/dOtg4u2GBxk3Hh/i+GbHysPKXIKx2xcLFK9S/q+y3653rLK0rn8efv1VFPLUoPnit6d vk7C6P7xkuLkNPs3USsUv8ryT9Z6IJ2d+vBkbmQ9442Ly9q+9O6Py1RiKc5INNRiLipOBABE HIi+FQIAAA==
Subject: Re: [rtcweb] Working Group Last Call draft-ietf-rtcweb-security
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 07 Mar 2013 09:23:05 -0000

EKR and WG,

I have reviewed the security draft (-04) as an individual and have the
following comments.

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?

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

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?

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.

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.

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?

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.

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.

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 oscar.ohlsson@ericsson.com  Thu Mar  7 06:41: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 E1E4B21F8D29 for ; Thu,  7 Mar 2013 06:41:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 8ZH2Chnwuk2P for ; Thu,  7 Mar 2013 06:41:56 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC6521F8D19 for ; Thu,  7 Mar 2013 06:41:45 -0800 (PST)
X-AuditID: c1b4fb2d-b7f316d0000028db-e3-5138a7273084
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 27.26.10459.727A8315; Thu,  7 Mar 2013 15:41:43 +0100 (CET)
Received: from ESESSMB301.ericsson.se ([169.254.1.208]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 15:41:43 +0100
From: Oscar Ohlsson 
To: EKR , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Working Group Last Call draft-ietf-rtcweb-security
Thread-Index: AQHOCtFWWS42KcwCtUuvtvD7u5XVeJiabL2w
Date: Thu, 7 Mar 2013 14:41:42 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: sv-SE, 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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvja76cotAgwnbVSxWvD7HbrH2Xzu7 A5PHkiU/mTwmP25jDmCK4rJJSc3JLEst0rdL4MpYMeMAc8Er3opT224wNjC2cXcxcnJICJhI rFm1lQXCFpO4cG89WxcjF4eQwCFGicu/zrNDOIsZJfr3XmACqWITMJC4df8kWIeIgLXEm52d 7CC2sICHxPP/t5gh4p4Sxx9+YoKwjSRer5kOZrMIqEg8PNEAVsMr4C1x+8o/sLiQQIDE8+fP geIcHJwCgRKdG9NAwowCshL3v98DW8UsIC5x68l8JohDBSSW7DnPDGGLSrx8/I8VwlaU2Hm2 nRmiXkdiwe5PbBC2tsSyha+h1gpKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxjZcxMzc9LL DTcxAmPh4JbfujsYT50TOcQozcGiJM4b5nohQEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPj jAAWZ9n7RnbnPjGtm6V0ayVPjOD6ivzK31vTRO83/7SrNv/KJ7BamFNIXu+cmvXRy48Kdzmn 2Ho4blnE72wR//Ol3+YQNfa6mual/jqyTz/J3/Dn+fRJ86FI9o2jVwzPOb7aEf3hOOeBUP5f D1lvrOA6ll1RF3aRXSP8g6zKjJPOa5JeOLkrsRRnJBpqMRcVJwIAbui0jVMCAAA=
Subject: Re: [rtcweb] Working Group Last Call draft-ietf-rtcweb-security
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 07 Mar 2013 14:41:57 -0000

Hi Eric,

Some minor comments on draft-ietf-rtcweb-security:

- Abstract

    This document defines the RTC-Web threat model and defines an=20
    architecture which provides security within that threat model=20

  Isn't the architecture defined in draft-ietf-rtcweb-security-arch?

- Section 4.1.1.3, 3rd paragraph

    However, this obviously presents a privacy challenge, as sites which=20
    host advertisements in IFRAMEs often learn very little about whether=20
    individual users clicked through to the ads, or even which ads were=20
    presented.=20
=09
  What exactly is the privacy issue here? Is it that the hosting site=20
  can eavesdrop on the call between the user and the advertiser since=20
  IFRAMEs are not used?=20
  =20
- Section 4.3.1, 3rd paragraph

    In addition, the system MUST NOT provide any APIs to extract either=20
    long-term keying material or to directly access any stored traffic keys=
.=20
=09
  Does this mean that SDES is out of the picture or does the sentence only=
=20
  apply to DTLS(-SRTP)?

I apologize if any of the points above have already been mentioned by the o=
ther reviewers.


Regards,

Oscar

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
> Of Ted Hardie
> Sent: den 14 februari 2013 17:35
> To: rtcweb@ietf.org
> Subject: [rtcweb] Working Group Last Call draft-ietf-rtcweb-security
>=20
> This begins a working group last call for draft-ietf-rtcweb-security.
> Please send comments to the list by March 9, 2013.
>=20
> regards,
>=20
> Ted, Cullen, Magnus
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

From oscar.ohlsson@ericsson.com  Thu Mar  7 06:49: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 121D821F8D52 for ; Thu,  7 Mar 2013 06:49:24 -0800 (PST)
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=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_18=0.6, 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 YTn4cuZW1rEQ for ; Thu,  7 Mar 2013 06:49:23 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E07A121F8D45 for ; Thu,  7 Mar 2013 06:49:22 -0800 (PST)
X-AuditID: c1b4fb25-b7f366d000004d10-69-5138a8f13436
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B9.8C.19728.1F8A8315; Thu,  7 Mar 2013 15:49:21 +0100 (CET)
Received: from ESESSMB301.ericsson.se ([169.254.1.208]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 15:49:21 +0100
From: Oscar Ohlsson 
To: "EKR (ekr@rtfm.com)" 
Thread-Topic: [rtcweb] Reminder: Working group last call for draft-ietf-rtcweb-security-arch
Thread-Index: AQHOE6+18fICFMHWHUySsbPOSiaetZiaXJBg
Date: Thu, 7 Mar 2013 14:49:20 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: sv-SE, 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+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvje7HFRaBBm8XWFqseH2O3WLtv3Z2 ByaPJUt+MnlMftzGHMAUxWWTkpqTWZZapG+XwJXxc/sxtoL/ihXtrV9YGxhPSnUxcnJICJhI /NnzghHCFpO4cG89WxcjF4eQwCFGiRnbdzNDOIsZJXZt+sIEUsUmYCBx6/5JFhBbREBd4uvE k+wgNjOQfWfxOTBbWCBWYteXV1A1cRJTF51hhLCNJHbuPA9Uw8HBIqAicfGgLEiYV8BbouHA RbBWIYEAib3XzrKB2JwCgRKvH99gBbEZBWQl7n+/xwKxSlzi1pP5TBBHC0gs2XOeGcIWlXj5 +B8rhK0osfNsOzNEvZ7EjalT2CBsbYllC18zQ+wVlDg58wnLBEaxWUjGzkLSMgtJyywkLQsY WVYxsucmZuaklxttYgTGyMEtv1V3MN45J3KIUZqDRUmcN9z1QoCQQHpiSWp2ampBalF8UWlO avEhRiYOTqkGxuY2qZSwmvWnel3Vb3x4rBL16lXC6vaENUx92136LQ6/rLy6t0w6xV7o5qpH df8EvB+5J9xnv9765ctbrYTvx66H2xXXM928vf5NyWau/L3TTR22uwSzb4g5dIBJ4ski3s8n RNIWO0fH3fX7tVlgchavw7Q1G3Qk+n7KfavbxtUgOP2q1nRODiWW4oxEQy3mouJEAMMrkSRf AgAA
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Reminder: Working group last call for	draft-ietf-rtcweb-security-arch
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 07 Mar 2013 14:49:24 -0000

Hi Eric,

When reading draft-ietf-rtcweb-security-arch I noticed a couple of things t=
hat might be missing:

- According to section 4.3.2.4 in draft-ietf-rtcweb-security there shold=20
  be a mechanism to verify that the remote browser has engaged a "secure=20
  media mode". This mechanism is not (yet) described in the document.
 =20
- Except for paragraph 6 in section 4.1, there is not much said about=20
  the implications of the "secure media mode".

- An enterprise network with an HTTP proxy may not want external web sites =
to=20
  learn the IP addresses of its hosts using the PeerConnection API. I'm=20
  not sure if this kind of attack is relevant or not. If it is then=20
  it should be mentioned in Section 5.4. IP Location Privacy.
=20
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). =20
  =20
  The term "hierarchy of trust" is unclear in this context. Are there other=
=20
  nodes in this hierarchy except for the browser and web server?
 =20
- Section 3, 2nd paragraph

    This is a natural extension of the end-to-end principle.
=09
  Perhaps it's just me but I don't understand what this end-to-end principl=
e is.=20
  =20
- 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.
  =20
   Won't there be separate handshake for the data channel?
  =20
- Section 5.4, 1st paragraph
 =20
    [...] which leaks large amounts of location information,
    especially for mobile devices.
=09
   Why are mobile devices different in this aspect?
 =20
- Section 5.6.4

  The SDP example contains RTP/AVP but I thought SRTP was made mandatory?
 =20
- 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.
  =20
  Couldn't the browser implementation handle the message routing=20
  without the id field?
 =20
- Section 5.6.5.1.1
 =20
  The mandatory id field is missing in the example

- Section 5.6.5.2.2

  How is the assertion field transformed into the a=3Didentity attribute?=20
  I guess you=B4re using some form of B64 encoding but this is not expained=
=20
  anywhere.

- Section 5.6.5.2.3

  I think the reason for including request_origin should be explained here=
=20
  instead of in the end of the document.
 =20
- Section 5.7.1, 3rd paragraph

  WebCrypto API lacks a reference.
 =20
- Section 5.7.4.5.2

    Any IdP which uses cookies to persist logins will be broken
    by third-party cookie blocking.
  =20
  Shouldn't it say "Any IdP which uses third-party cookies"?

- Appendix A and B

  Both appendices appear unfinished. For example, ROAP is still mentioned=20
  in othe BrowserID example and it's unclear what client credentials=20
  Bob uses in the OAuth example.

Regards,

Oscar

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
> Of Ted Hardie
> Sent: den 26 februari 2013 00:28
> To: rtcweb@ietf.org
> Subject: [rtcweb] Reminder: Working group last call for draft-ietf-
> rtcweb-security-arch
>=20
> This is a reminder that there is an ongoing last call for draft-ietf-
> rtcweb-security-arch-06.  Please send comments, including those of the
> "reviewed and no issues" ilk, by March 9th, 2012.
>=20
> regards,
>=20
> Ted Hardie
>=20
> On Thu, Feb 14, 2013 at 8:35 AM, Ted Hardie  wrote:
> > This begins a working group last call for
> > draft-ietf-rtcweb-security-arch.  Please send comments to the list by
> > March 9, 2013.
> >
> > regards,
> >
> > Ted, Cullen, Magnus
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

From randell-ietf@jesup.org  Thu Mar  7 06:50: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 C409121F8836 for ; Thu,  7 Mar 2013 06:50:53 -0800 (PST)
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 X57wPSrORfaO for ; Thu,  7 Mar 2013 06:50:53 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 16A4121F859A for ; Thu,  7 Mar 2013 06:50:53 -0800 (PST)
Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:4553 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UDc9k-0008pn-EO for rtcweb@ietf.org; Thu, 07 Mar 2013 08:50:52 -0600
Message-ID: <5138A917.7090207@jesup.org>
Date: Thu, 07 Mar 2013 09:49:59 -0500
From: Randell Jesup 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <20130218233047.19414.47123.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A012598@FR711WXCHMBA03.zeu.alcatel-lucent.com> <51232071.3070207@jesup.org> <39821B4C400EC14DAD4DB25330A9271A01918D@FR711WXCHMBA03.zeu.alcatel-lucent.com>
In-Reply-To: <39821B4C400EC14DAD4DB25330A9271A01918D@FR711WXCHMBA03.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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
Subject: Re: [rtcweb] TR : New Version Notification	for	draft-marcon-rtcweb-data-channel-management-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, 07 Mar 2013 14:50:53 -0000

On 3/4/2013 8:27 AM, MARCON, JEROME (JEROME) wrote:
>
>> -----Message d'origine-----
>>
>>
>> "Whenever the application creates a new data channel, the
>> browser internally checks if the passed set of parameters
>> strictly matches an existing configuration, and if not
>> generates a new configuration identifier for this set. In the
>> latter case only does the browser trigger the application for
>> an SDP renegotiation."
>>
>> Wouldn't this occur on almost every channel because of label
>> values?  Or are you assuming applications won't actually use labels?
> In this first version of the proposal, the use of labels is still undefined, but (for the sale of scalability) it would for now remain a local data channel property not transmitted to the peer (should this local property be useful to something).
>
> I would appreciate some clarifications on the usefulness of labels in the context of data channels. W3C says nothing about it. Probably - if transmitted to the peer - it can assist the user consent decision. But then assuming the offer is for opening 100 data channels for file transfer (each channel with a distinct label), would the answerer's consent be asked 100 times (once per distinct label) ? Probably asking once "do you agree on some file transfers" is enough (and better). And the 'file transfer' information is carried by the subprotocol property, not the label.

The labels are for the application to differentiate between data 
channels that are using the same protocol.  For example, in a 
conference-with-central-mixer case, you might have a data channel to the 
mixer for each private conversation with another participant, plus one 
(or more) shared chats.  Each would be the same protocol, but have 
different labels.

Basically, they're there for the application to do something with, if it 
chooses.  It can totally ignore them if it wishes.  I'll note that RTFMP 
has a similar (though binary) concept.   They're a tool, and are 
particularly useful in cases where the data on the channel is an 
already-defined protocol as opposed to a new, application-specific 
protocol (where they could include the label inside their protocol).

These labels would need to be plumbed through to the recipient, not just 
local.

Another (I think already addressed) misunderstanding is that there's no 
requirement for user notification of data channels.  The reasoning is 
that a data channel is no different in user security/risk to existing 
mechanisms such as websockets, HTTPS connections - it just can go 
peer-to-peer and may have better latency charactistics (support for 
UDP-like transfers, etc).

>
>> "Data channel messages are sent as SCTP user messages,
>> preceded in the DATA chunk User Data field by two bytes
>> specifying data channel configuration identifier as well as
>> the message data framing type (textual or binary)."
>>
>> Aha.  So you've moved this into a true inband protocol with
>> data framing.  The current draft sends data messages with no
>> added framing required.
> Please explain why data framing is an issue. WebSocket protocol does this. The proposal also only reserves a unique PPID for the entire RTCWeb data channel functionality. Personally, I find it ackward to reserve a PPID for something like "plain transmission of any binary data or UTF-8 stream". It seemed to me that each PPID today registered with IANA is identifying a true self-contained protocol.

In-packet framing can be an annoyance for anything that's gatewaying an 
existing data stream into a channel.  It will work, but it means extra 
copying in both directions, and in some architectures/devices (SBCs, 
MCU's/conference servers) may complicate things, and some people have 
indicated the have (unspecified) usecases where they find gatewaying 
traffic directly onto these channels is desirable. Given there's a 
standard facility in SCTP that can be used for this (with a large 
address space), there seems to be little downside to using it.  I don't 
think we're in danger of running out of PPID's this millennium.  :-)

-- 
Randell Jesup
randell-ietf@jesup.org


From harald@alvestrand.no  Thu Mar  7 07:37: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 B582821F8CF3 for ; Thu,  7 Mar 2013 07:37:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.99
X-Spam-Level: 
X-Spam-Status: No, score=-109.99 tagged_above=-999 required=5 tests=[AWL=-0.609, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, 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 Kxt0ebiwNeWm for ; Thu,  7 Mar 2013 07:37:06 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id EE84921F8C8D for ; Thu,  7 Mar 2013 07:37:05 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B87AA39E125; Thu,  7 Mar 2013 16:36:58 +0100 (CET)
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 CclyRJVlFHLe; Thu,  7 Mar 2013 16:36:58 +0100 (CET)
Received: from [172.16.39.56] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 07F1939E029; Thu,  7 Mar 2013 16:36:57 +0100 (CET)
Message-ID: <51372F03.40308@alvestrand.no>
Date: Wed, 06 Mar 2013 12:56:51 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [rtcweb] Time division for codec discussion (Re: DRAFT Agenda for RTCWEB)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 07 Mar 2013 15:37:06 -0000

On 02/27/2013 06:49 PM, Ted Hardie wrote:
> Video Codec                       10:15 to 11:30
> 1. draft-alvestrand-rtcweb-vp8-01 (15 mins)
> 2. draft-burman-rtcweb-h264-proposal-01+draft-dbenham-webrtcvideomti-01+draft-marjou-rtcweb-video-codec-00
> (25 mins)
>        Discussion (30 minutes)
>        Call the question (5 minutes)
On reconsidering this timeline, I feel that it is more realistic to 
expect 15 mins of presentations for VP8 followed by 15 mins of 
clarifying questions (not on the decision to be made, but in order to 
make sure everyone has a common understanding of what the VP8 
presentations were saying.

We will, however, live with what the chairs decide on time division.

From harald@alvestrand.no  Thu Mar  7 07:37: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 1427921F8D14 for ; Thu,  7 Mar 2013 07:37:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.837
X-Spam-Level: 
X-Spam-Status: No, score=-109.837 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, 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 LeDBtMv04RQS for ; Thu,  7 Mar 2013 07:37:07 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id F142321F8C8D for ; Thu,  7 Mar 2013 07:37:06 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1EF0739E173 for ; Thu,  7 Mar 2013 16:37:03 +0100 (CET)
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 J54HlTqu17Zf for ; Thu,  7 Mar 2013 16:37:02 +0100 (CET)
Received: from [172.16.39.56] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2131339E029 for ; Thu,  7 Mar 2013 16:37:01 +0100 (CET)
Message-ID: <5137333C.2000602@alvestrand.no>
Date: Wed, 06 Mar 2013 13:14:52 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <39821B4C400EC14DAD4DB25330A9271A01929A@FR711WXCHMBA03.zeu.alcatel-lucent.com>
In-Reply-To: <39821B4C400EC14DAD4DB25330A9271A01929A@FR711WXCHMBA03.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Data channel setup: scalability, user experience, labels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 07 Mar 2013 15:37:08 -0000

On 03/04/2013 07:36 PM, MARCON, JEROME (JEROME) wrote:
> I would like to get rough opinions on three data channel related topics:
>
> Scalability-challenging scenarios
> ---------------------
> If I am not mistaken, Randell mentioned in Boston some data channel setup scenarios like: 1000 data channels opened in the same session, and possibly 100 data channels opened simultaneously (usage: file transfer). I agree it is important to keep some scalability objectives in mind when taking decisions on the data channel setup design. So what about a list of real-life scalability-challenging scenarios like:
>
> 1. No SCTP association is established, and an endpoint wishes to open 100 data channels for the same usage (e.g. file transfer)
>
> 2. An SCTP association is established, and an endpoint wishes to open 100 data channels for the same usage (e.g. file transfer)
>
> 3. An endpoint creates and closes a data channel at a high frequency, for the same usage (probably an app misbehavior here, but...)
>
> 4. ...any other?

If you want to establish minimum performance levels that a conforming 
application will have to support, we can certainly consider that.

We should start by stating the minimum number of video and audio 
channels that a conforming application will have to support, since this 
is important for a lot of the RTCWEB use cases, and may impact really 
scarce resources like hardware decoders.

Supporting an extra data channel is one more control block. Perhaps a 
few kilobytes of RAM. Buffer space (if the data channel congests) is 
likely to take far more memory than the control blocks; should we also 
create specifications on the minimum amount of memory available for buffers?

Seriously, I see all these as quality-of-implementation issues. We 
should make sure the API specification is clear about what happens when 
the browser runs out of resources, and leave it at that.
(FWIW, a rendering process in Chrome that runs out of memory, for any 
reason, will crash. Recovery is accomplished by the user pushing "reload".)

>
> User consent
> ---------------------
> These scalability-challenging scenarios not only raise scalability issues, but user experience issues as well. Should these be relevant in IETF (and not in W3C), which user consent is appropriate in the context of data channel setup ?
>
> A) Assuming an initial/updating SDP offer declaring one 'chat' channel and 100 'file transfer' channels, each with a distinct label. The user consent will be:
> * 1-line: "open data channels [for this time only | anytime during this session] for any usage/subprotocol"
> * 2-line: "open data channels [for this time only | anytime during this session] for usage/subprotocol: (1) chat (2) file transfer"
> * 101-line: "open data channels for this time only for usage/subprotocol.label: (1) chat.label1 (2) file transfer.label 2... (101) file transfer.label 101"
>
> B) Assuming a data channel created in-band, with a subprotocol already negotiated
> * I assume user consent is not required here ?
>
> C) Assuming a data channel created in-band, with a subprotocol 'file transfer' never negotiated before in the SDP handshake (I think only Randell's proposal allows this)
> * 1-line: "open a data channel for this time only for usage/subprotocol.label = chat.label1"
> * 1-line: "open a data channel [for this time only | anytime during this session] for usage/subprotocol = chat"
>
>  From these (too much detailed) cases, we can identify 3 main types of user consent for data channel setup:
> U1. open any number of data channels of any type: prompted at the time of SCTP association setup
> U2. open any number of data channels of a given usage/subprotocol: prompted the first time this subprotocol is signaled to the peer (in SDP or in-band)
> U3. open one data channel of a given usage/subprotocol of a given label

We already have consensus that data channels don't require user consent; 
they expose no significant new security issues compared to data transfer 
via a Web server, which is already possible without user consent.

Please stop; the horse is dead.

>
> Label usefulness
> ---------------------
> I would like to understand the usefulness of data channel labels. Considering that:
> - (if user consent is of type U1 or U2 described above) labels do not take part of user consent
> - labels are no longer used as data channel identifiers (SCTP stream numbers are better for this, according to the 3 data channel setup proposals on the table: Randell's, Martin's and mine).
> - W3C says nothing about the use of data channel labels

Randell's proposal means that the channel number is not known before the 
channel is created for the normal case. (He suggests an "advanced" 
mechanism for forcing the channel number.)

Labels are useful for creating channels where the receiving application 
knows what channels to expect, but doesn't know the channel number in 
advance.

Exercise for the reader: Write an application that uses multiple data 
channels, and does not force channel numbers. Try it with and without 
labels.

From ted.ietf@gmail.com  Thu Mar  7 08:16: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 679CF21F86C3 for ; Thu,  7 Mar 2013 08:16:06 -0800 (PST)
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 dXN6pSN1CE20 for ; Thu,  7 Mar 2013 08:16:06 -0800 (PST)
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 9C69121F869E for ; Thu,  7 Mar 2013 08:16:05 -0800 (PST)
Received: by mail-ie0-f179.google.com with SMTP id k11so761204iea.38 for ; Thu, 07 Mar 2013 08:16:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Xc88zECOh4YeBEQHsBXWKe8L7ais8PgIaGhe2JIqJuc=; b=kGBHX3qD3/jC18ot/Rc98eTSkcNKBMBz2Vlg04hBZYR4lklHUOBNF1V8zI3DuXxcld M4cLmpZ4FvdBNQ3jgtwFuSLn5Dtu0n/cWgloiw3rRgckYzQwHtSIn+SXm8ROPejeKD4Z x/Wd5/ZMjd6k6wDARS1tuQC6c/gQIegTxRjb4O1u+ir/z1/1i7ZQqf3JKp/EmO8wXcxW oevWj45uKPweZAZuA9QnUhO3PB3fQiBfEOiEk/bguW/dJnNtew5r255nwg+5VLC3YixS UHn5TA4Ur+4uA2UNCevYav6lCIlgA85DC225R+d6XHzOvyUA5TmxJX39iL9hjcVeB0CS HpbQ==
MIME-Version: 1.0
X-Received: by 10.42.33.196 with SMTP id j4mr34327449icd.4.1362672965239; Thu, 07 Mar 2013 08:16:05 -0800 (PST)
Received: by 10.43.135.202 with HTTP; Thu, 7 Mar 2013 08:16:05 -0800 (PST)
In-Reply-To: <51378121.5010908@alvestrand.no>
References:  <51378121.5010908@alvestrand.no>
Date: Thu, 7 Mar 2013 08:16:05 -0800
Message-ID: 
From: Ted Hardie 
To: Harald Alvestrand 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Richard Barnes , rtcweb@ietf.org, rtcweb-chairs@tools.ietf.org
Subject: Re: [rtcweb] Time allocation for video codec MTI (Re: DRAFT Agenda for RTCWEB)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 07 Mar 2013 16:16:06 -0000

Magnus and I discussed this morning, and we will allot this extra time
if the JSEP discussion runs short.

regards,

Ted Hardie


On Wed, Mar 6, 2013 at 9:47 AM, Harald Alvestrand  wrote:
> (this may be a repeat, but I can't find the other mail)
>
> On 02/27/2013 06:49 PM, Ted Hardie wrote:
>>
>> Video Codec                       10:15 to 11:30
>> 1. draft-alvestrand-rtcweb-vp8-01 (15 mins)
>> 2.
>> draft-burman-rtcweb-h264-proposal-01+draft-dbenham-webrtcvideomti-01+draft-marjou-rtcweb-video-codec-00
>> (25 mins)
>>        Discussion (30 minutes)
>>        Call the question (5 minutes)
>
>
> Looking at what has to be presented, and the likelyhood of questions, I
> think a more reasonable (less optimistic) allocation of time for the VP8
> part of this discussion would be 15 minutes for presentations and 15 minutes
> for clarifying questions.
>

From ted.ietf@gmail.com  Thu Mar  7 08: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 46DC321F8C20 for ; Thu,  7 Mar 2013 08:18:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.525
X-Spam-Level: 
X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075,  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 Nwv2791cUX3K for ; Thu,  7 Mar 2013 08:18:41 -0800 (PST)
Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id B55A721F897A for ; Thu,  7 Mar 2013 08:18:41 -0800 (PST)
Received: by mail-ie0-f180.google.com with SMTP id bn7so763390ieb.39 for ; Thu, 07 Mar 2013 08:18:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=qq6Vu8Vseo2z6GEVS6P7lqx9U3JrOosj/sFpuIEA++Y=; b=oS/Uj4bMZyQziN55px30/J0bMk2a6q8bDVy8nPQRPcFvxwE4k2CMaNjelJz+u8nfjG wDs7r5qxMx05OfTyiNWgMdIlQ0hOWUf/aEt7wImd7zrcpLJJUWCV5L2k8y5CXntX2GxH 44Z6k9NeumQLTuVsrn0zyNgKeC9FjOZHjnfAvgjdcfQop+rf4Uv5UPfbXADEV09zZrvt m0AbYEnhXAgULlZAfhdXVtAzSKxs8INn75Az2Eg8E49OYP2UbAZWpR4NQ0QX4ywkmHS4 2p7OvxsuAhx2kHtwg2WmsAtUJpAudBcmgmoXgfIVsQv77EYg9v9OsjWdVMU1W/CvqMvS S7aQ==
MIME-Version: 1.0
X-Received: by 10.42.33.196 with SMTP id j4mr34333899icd.4.1362673121262; Thu, 07 Mar 2013 08:18:41 -0800 (PST)
Received: by 10.43.135.202 with HTTP; Thu, 7 Mar 2013 08:18:41 -0800 (PST)
In-Reply-To: 
References: 
Date: Thu, 7 Mar 2013 08:18:41 -0800
Message-ID: 
From: Ted Hardie 
To: "Espen Berger (espeberg)" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" 
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 07 Mar 2013 16:18:42 -0000

Magnus and I discussed this this morning, and we encourage you to
prepare something.  If the discussion of working group last call items
runs short, we may be able to fit this in at that time or at the end
of day one if its full agenda his finished.  This is not a commitment,
however, so please try and get discussion on the list on the points
from the draft you feel need resolution.

regards,

Ted


On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)
 wrote:
> Hello,
>
>
>
> I would like to request agenda time for:
>
>
>
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
>
>
> The document  presents use-cases underlining why WebRTC needs AMR-WB,  AMR
> and G.722 as additional relevant voice codecs to satisfactorily ensure
> interoperability with existing systems.
>
>
>
> A 10-minute time slot should be sufficient for presentation and discussion.
>
>
>
> Regards
>
>
>
> -Espen
>
>
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

From btv1==77867126054==HKaplan@acmepacket.com  Thu Mar  7 08:50: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 33B3B21F8A35 for ; Thu,  7 Mar 2013 08:50:52 -0800 (PST)
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]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5Lm0hXb7d2J for ; Thu,  7 Mar 2013 08:50:51 -0800 (PST)
Received: from mx2.acmepacket.com (mx2.acmepacket.com [216.41.24.99]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF8821F8A42 for ; Thu,  7 Mar 2013 08:50:47 -0800 (PST)
X-ASG-Debug-ID: 1362675046-03fc21725fd53f70001-4f8tJD
Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx2.acmepacket.com with ESMTP id EFduSsnpYkeQHgRq (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Thu, 07 Mar 2013 11:50:46 -0500 (EST)
X-Barracuda-Envelope-From: HKaplan@acmepacket.com
Received: from MAIL2.acmepacket.com ([169.254.2.222]) by Mail1.acmepacket.com ([169.254.1.30]) with mapi id 14.02.0283.003; Thu, 7 Mar 2013 11:50:46 -0500
From: Hadriel Kaplan 
To: Robin Raymond 
Thread-Topic: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API	minus SDP
X-ASG-Orig-Subj: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API	minus SDP
Thread-Index: AQHOG1Ppn8Vr1MpYMkefVsymk7EOnQ==
Date: Thu, 7 Mar 2013 16:50:45 +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.0.0.30]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <20CD67D6E4DEFC42972C64CB73EE1FC7@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21]
X-Barracuda-Start-Time: 1362675046
X-Barracuda-Encrypted: AES128-SHA
X-Barracuda-URL: http://216.41.24.99:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at acmepacket.com
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.124527 Rule breakdown below pts rule name              description ---- ---------------------- --------------------------------------------------
Cc: "" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API	minus 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: Thu, 07 Mar 2013 17:10:57 -0000

I knew there was a reason for posting an email for the archive machine to s=
tore for eternity... see this:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg01256.html

-hadriel


On Mar 6, 2013, at 6:45 PM, Robin Raymond  wrote:

>=20
> Do we need SDP "blob" format in the exchange in the first place? All medi=
a
> can be done without SDP given an intelligent stream API. An API already
> exists to create these streams (albeit somewhat lacking if we remove the
> SDP 'blob'). This API helps "simplify" creating this blob for later
> exchange. But the blob is truly not needed. Each side could in fact creat=
e
> the desired streams, pass in the appropriate media information such as
> codecs and ICE candidates and chose the socket pair to multiplex upon.
> Yes, it's a bit more low level but it certainly can be done (and cleanly)=
.
>=20
> https://datatracker.ietf.org/doc/draft-jennings-rtcweb-plan/
>=20
> Nothing wrong with the draft in an SDP/SIP mindset but I'm going to take
> it from a totally different non-SDP angle. I have to say, the ideas
> presented are very good. I appreciate FEC, and synchronizing streams is
> cool. But SDP isn=B9t needed to do it. Let me as the programmer worry abo=
ut
> how to manage streams and the features on the streams and associations
> between the streams via an API only.
>=20
> Point 4, 5 and 6 in the specification all have to do with the complexitie=
s
> of having to describe the intentions of mixing in SDP. So no comment
> beyond =B3don=B9t use SDP=B2.
>=20
> As for 7.1 =AD =B3this is because the sender choses the SSRC=B2 =AD only =
true
> because we are forced to use SDP and the assumptions is that it=B9s SIP. =
We
> could have the receiver dictate what the sender should use in advance of
> any media. In our case, we establish in advance what we want from all
> parties before even =B3ringing=B2 the other party. We do not have SSRC
> collisions as we reversed the scenario allowing the receiver to pick the
> expected SSRC. Coordinating the streams is a problem with SIP because of
> how they do forking/conferencing. This specification forces this issue on
> those not using SIP. If SIP has problems with streams arriving early to
> their stateful offer/answer then let them worry about =B3how=B2 they inte=
nd to
> match the streams at a higher SDP layer and get this draft out of the
> RTCWEB track on the SIP track. To be clear, the proposal seems entirely
> reasonable and intelligent for SIP/SDP. But it=B9s way to SIP centric for
> general use.
>=20
> On that note, what I do need in the API is an ability to dictate the SSRC
> when I create an RTP stream for sending (should I care to do that).
>=20
> 7.2 Multiple render
>=20
> Again this is an issue of SIP/SDP. We can control the SSRCs to split them
> out to allow multiplexing easily on the same RTP ports with multiple
> parties/sources. If given the primitives to control the streams just, thi=
s
> specification could be used to dictate how to negotiate issues in their
> space.
>=20
> 7.2.1 I=B9m feeling the pain. How about just giving me an API where I can
> indicate what streams are FEC associated.
>=20
> 7.3 Give me API to give crypto keys to RTP layer. Let me handle the
> fingerprint and security myself beyond that.
>=20
> 8. Let's just say politely that I would not want to be the developer
> assigned to programming around all this stuff.
>=20
> Again, a perfect illustration why I don=B9t want SDP.
>=20
> Media is complicated for good reason as there are many untold use cases.
> The entire IETF/W3C discussion around video constraints illustrates some
> of the complexities and competing desires for just one single media type.
> If we tie ourselves to SDP we are limiting ourselves big time, and some o=
f
> the cool future stuff will be horribly hampered by it.
>=20
> My issues with SDP can be summarized as:
>=20
> - unneeded - much too high level an API
> - arcane format - legacy and problematic
> - offer/answer
> - incompatibilities
> - lack of API contact
> - doesn't truly solve goal of interoperability with legacy systems (eg.
> SIP)
>=20
> Regret that I did not have time for feedback earlier. As you can tell, I
> am not at all happy with where we sit today wrt requiring SDP. IMHO we
> need a lower level API if we are going to insist on using SDP.
>=20
>=20
> You can read my entire (long) rant against SDP here
> http://blog.webrtc.is/2013/03/06/sdp-the-webrtc-boat-anchor/
>=20
>=20
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From martin.thomson@gmail.com  Thu Mar  7 09:43: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 2C3E021F8A7E for ; Thu,  7 Mar 2013 09:43:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[AWL=-0.600, 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 V9GlEWn85R33 for ; Thu,  7 Mar 2013 09:43:28 -0800 (PST)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5A821F8A51 for ; Thu,  7 Mar 2013 09:43:17 -0800 (PST)
Received: by mail-wg0-f44.google.com with SMTP id dr12so1340669wgb.35 for ; Thu, 07 Mar 2013 09:43:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=jOQdpnvTRGLCXZjwmZp6TBpjbCQQua5ZuxIFZ8DPu90=; b=y+KyXwDaKXVjFhfjzMhGEj9w24CMsjCnCFZVbxbHTtoyvgVM9brQrt7wj608EKfnS9 E62GzkwPULZnIgBBPYnqTTVzVFaQLDLNFdpDJpORh+fIrHgX5ghpp2mbRBNMMx8M0WtO 56yzYiaZIANCXAW+E2pJ9h5mrNHMezOgQ2IemixFa8Nha1Mm3+8N/6Y+SeoJlQNz8B3p 6RYjw8Y6cqxkgw1FmwSDcgKSL0z/xOfV4dbLqXnrt8YpKj21GDDHmVGLjO7Q2ViOVkmk ZO0lg8qCQzvroM8nrRYdwviXAC8kudouiFF76E6OCUL3XkCkK2jNFyAx1U++li7eGsTs Shaw==
MIME-Version: 1.0
X-Received: by 10.180.75.177 with SMTP id d17mr35470949wiw.16.1362678192905; Thu, 07 Mar 2013 09:43:12 -0800 (PST)
Received: by 10.194.5.135 with HTTP; Thu, 7 Mar 2013 09:43:12 -0800 (PST)
In-Reply-To: 
References:  
Date: Thu, 7 Mar 2013 09:43:12 -0800
Message-ID: 
From: Martin Thomson 
To: Hadriel Kaplan 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 17:43:29 -0000

Obviously I (and my employer) agree with these sentiments
wholeheartedly.  Both Robin and Hadriel.

That doesn't change the fact that a number of people are highly
motivated to protect their investment in SDP offer/answer.  For those
people, the pain that causes everyone else is clearly far less
important than the pain they feel at this moment.  So here we are.

On 7 March 2013 08:50, Hadriel Kaplan  wrote:
>
> I knew there was a reason for posting an email for the archive machine to=
 store for eternity... see this:
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg01256.html
>
> -hadriel
>
>
> On Mar 6, 2013, at 6:45 PM, Robin Raymond  wrote:
>
>>
>> Do we need SDP "blob" format in the exchange in the first place? All med=
ia
>> can be done without SDP given an intelligent stream API. An API already
>> exists to create these streams (albeit somewhat lacking if we remove the
>> SDP 'blob'). This API helps "simplify" creating this blob for later
>> exchange. But the blob is truly not needed. Each side could in fact crea=
te
>> the desired streams, pass in the appropriate media information such as
>> codecs and ICE candidates and chose the socket pair to multiplex upon.
>> Yes, it's a bit more low level but it certainly can be done (and cleanly=
).
>>
>> https://datatracker.ietf.org/doc/draft-jennings-rtcweb-plan/
>>
>> Nothing wrong with the draft in an SDP/SIP mindset but I'm going to take
>> it from a totally different non-SDP angle. I have to say, the ideas
>> presented are very good. I appreciate FEC, and synchronizing streams is
>> cool. But SDP isn=C2=B9t needed to do it. Let me as the programmer worry=
 about
>> how to manage streams and the features on the streams and associations
>> between the streams via an API only.
>>
>> Point 4, 5 and 6 in the specification all have to do with the complexiti=
es
>> of having to describe the intentions of mixing in SDP. So no comment
>> beyond =C2=B3don=C2=B9t use SDP=C2=B2.
>>
>> As for 7.1 =C2=AD =C2=B3this is because the sender choses the SSRC=C2=B2=
 =C2=AD only true
>> because we are forced to use SDP and the assumptions is that it=C2=B9s S=
IP. We
>> could have the receiver dictate what the sender should use in advance of
>> any media. In our case, we establish in advance what we want from all
>> parties before even =C2=B3ringing=C2=B2 the other party. We do not have =
SSRC
>> collisions as we reversed the scenario allowing the receiver to pick the
>> expected SSRC. Coordinating the streams is a problem with SIP because of
>> how they do forking/conferencing. This specification forces this issue o=
n
>> those not using SIP. If SIP has problems with streams arriving early to
>> their stateful offer/answer then let them worry about =C2=B3how=C2=B2 th=
ey intend to
>> match the streams at a higher SDP layer and get this draft out of the
>> RTCWEB track on the SIP track. To be clear, the proposal seems entirely
>> reasonable and intelligent for SIP/SDP. But it=C2=B9s way to SIP centric=
 for
>> general use.
>>
>> On that note, what I do need in the API is an ability to dictate the SSR=
C
>> when I create an RTP stream for sending (should I care to do that).
>>
>> 7.2 Multiple render
>>
>> Again this is an issue of SIP/SDP. We can control the SSRCs to split the=
m
>> out to allow multiplexing easily on the same RTP ports with multiple
>> parties/sources. If given the primitives to control the streams just, th=
is
>> specification could be used to dictate how to negotiate issues in their
>> space.
>>
>> 7.2.1 I=C2=B9m feeling the pain. How about just giving me an API where I=
 can
>> indicate what streams are FEC associated.
>>
>> 7.3 Give me API to give crypto keys to RTP layer. Let me handle the
>> fingerprint and security myself beyond that.
>>
>> 8. Let's just say politely that I would not want to be the developer
>> assigned to programming around all this stuff.
>>
>> Again, a perfect illustration why I don=C2=B9t want SDP.
>>
>> Media is complicated for good reason as there are many untold use cases.
>> The entire IETF/W3C discussion around video constraints illustrates some
>> of the complexities and competing desires for just one single media type=
.
>> If we tie ourselves to SDP we are limiting ourselves big time, and some =
of
>> the cool future stuff will be horribly hampered by it.
>>
>> My issues with SDP can be summarized as:
>>
>> - unneeded - much too high level an API
>> - arcane format - legacy and problematic
>> - offer/answer
>> - incompatibilities
>> - lack of API contact
>> - doesn't truly solve goal of interoperability with legacy systems (eg.
>> SIP)
>>
>> Regret that I did not have time for feedback earlier. As you can tell, I
>> am not at all happy with where we sit today wrt requiring SDP. IMHO we
>> need a lower level API if we are going to insist on using SDP.
>>
>>
>> You can read my entire (long) rant against SDP here
>> http://blog.webrtc.is/2013/03/06/sdp-the-webrtc-boat-anchor/
>>
>>
>>
>> _______________________________________________
>> 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 mary.ietf.barnes@gmail.com  Thu Mar  7 09:56: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 6AB8A21F89A6 for ; Thu,  7 Mar 2013 09:56:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.727
X-Spam-Level: 
X-Spam-Status: No, score=-103.727 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, 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 bd76TsVG2oY5 for ; Thu,  7 Mar 2013 09:56:34 -0800 (PST)
Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4485F21F8996 for ; Thu,  7 Mar 2013 09:56:34 -0800 (PST)
Received: by mail-qe0-f44.google.com with SMTP id x7so459509qeu.3 for ; Thu, 07 Mar 2013 09:56:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=Bc0IU/bsO9B7nvclo0lXf4COgCLBYO4CtcPQtXdsbTM=; b=L/TV7s2pFRhwtZOuW48sP2+CHOFC4NOfYp92vGbMV0Ftcsz56NiUilu5c+O0UUCIhU 1Ann5iOgJKCKknOWxZz87awshmsZGoQXjm2pNTBwuQNRKhtrMDKNTwsM3jJh0J3gu1TH Tv9VBh/3Lyc9OWClSWaSxjwHF1X2pvOgauXBP1xcZoXhi0/zqsIdtDPquroHdQAhsiOG jDS6NKSPk6gNsk2bXH1Gv9J9q4t+1isvSN5y/7S84+oWaitaqfFHU9LQfgSIQywLesz3 prfrAVdQBfnG8YpAnH1J6NIdbZtKV/oFzg4luafbt/59s4dVasuRylZWZLzhfDsLM5av U31Q==
MIME-Version: 1.0
X-Received: by 10.224.191.68 with SMTP id dl4mr4558163qab.85.1362678992837; Thu, 07 Mar 2013 09:56:32 -0800 (PST)
Received: by 10.49.24.130 with HTTP; Thu, 7 Mar 2013 09:56:32 -0800 (PST)
In-Reply-To: 
References:   
Date: Thu, 7 Mar 2013 11:56:32 -0600
Message-ID: 
From: Mary Barnes 
To: Martin Thomson 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 17:56:35 -0000

On Thu, Mar 7, 2013 at 11:43 AM, Martin Thomson
 wrote:
> Obviously I (and my employer) agree with these sentiments
> wholeheartedly.  Both Robin and Hadriel.
>
> That doesn't change the fact that a number of people are highly
> motivated to protect their investment in SDP offer/answer.  For those
> people, the pain that causes everyone else is clearly far less
> important than the pain they feel at this moment.  So here we are.

[MB] I originally thought that either approach could work.  I did see
the value that folks saw in using SDP offer/answer. But after sitting
through the interim meeting last month, I am very much of the mindset
that using SDP O/A is a bad idea.   I think many of us thought that
using the SDP blob would help with interoperability with "legacy" SIP
endpoints.  I don't see that now at all.  I think we will end up with
a very fragile solution that will be very difficult to extend/modify
later if we continue down the SDP O/A path.
[/MB]
>
> On 7 March 2013 08:50, Hadriel Kaplan  wrote:
>>
>> I knew there was a reason for posting an email for the archive machine t=
o store for eternity... see this:
>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg01256.html
>>
>> -hadriel
>>
>>
>> On Mar 6, 2013, at 6:45 PM, Robin Raymond  wrote:
>>
>>>
>>> Do we need SDP "blob" format in the exchange in the first place? All me=
dia
>>> can be done without SDP given an intelligent stream API. An API already
>>> exists to create these streams (albeit somewhat lacking if we remove th=
e
>>> SDP 'blob'). This API helps "simplify" creating this blob for later
>>> exchange. But the blob is truly not needed. Each side could in fact cre=
ate
>>> the desired streams, pass in the appropriate media information such as
>>> codecs and ICE candidates and chose the socket pair to multiplex upon.
>>> Yes, it's a bit more low level but it certainly can be done (and cleanl=
y).
>>>
>>> https://datatracker.ietf.org/doc/draft-jennings-rtcweb-plan/
>>>
>>> Nothing wrong with the draft in an SDP/SIP mindset but I'm going to tak=
e
>>> it from a totally different non-SDP angle. I have to say, the ideas
>>> presented are very good. I appreciate FEC, and synchronizing streams is
>>> cool. But SDP isn=B9t needed to do it. Let me as the programmer worry a=
bout
>>> how to manage streams and the features on the streams and associations
>>> between the streams via an API only.
>>>
>>> Point 4, 5 and 6 in the specification all have to do with the complexit=
ies
>>> of having to describe the intentions of mixing in SDP. So no comment
>>> beyond =B3don=B9t use SDP=B2.
>>>
>>> As for 7.1 =AD =B3this is because the sender choses the SSRC=B2 =AD onl=
y true
>>> because we are forced to use SDP and the assumptions is that it=B9s SIP=
. We
>>> could have the receiver dictate what the sender should use in advance o=
f
>>> any media. In our case, we establish in advance what we want from all
>>> parties before even =B3ringing=B2 the other party. We do not have SSRC
>>> collisions as we reversed the scenario allowing the receiver to pick th=
e
>>> expected SSRC. Coordinating the streams is a problem with SIP because o=
f
>>> how they do forking/conferencing. This specification forces this issue =
on
>>> those not using SIP. If SIP has problems with streams arriving early to
>>> their stateful offer/answer then let them worry about =B3how=B2 they in=
tend to
>>> match the streams at a higher SDP layer and get this draft out of the
>>> RTCWEB track on the SIP track. To be clear, the proposal seems entirely
>>> reasonable and intelligent for SIP/SDP. But it=B9s way to SIP centric f=
or
>>> general use.
>>>
>>> On that note, what I do need in the API is an ability to dictate the SS=
RC
>>> when I create an RTP stream for sending (should I care to do that).
>>>
>>> 7.2 Multiple render
>>>
>>> Again this is an issue of SIP/SDP. We can control the SSRCs to split th=
em
>>> out to allow multiplexing easily on the same RTP ports with multiple
>>> parties/sources. If given the primitives to control the streams just, t=
his
>>> specification could be used to dictate how to negotiate issues in their
>>> space.
>>>
>>> 7.2.1 I=B9m feeling the pain. How about just giving me an API where I c=
an
>>> indicate what streams are FEC associated.
>>>
>>> 7.3 Give me API to give crypto keys to RTP layer. Let me handle the
>>> fingerprint and security myself beyond that.
>>>
>>> 8. Let's just say politely that I would not want to be the developer
>>> assigned to programming around all this stuff.
>>>
>>> Again, a perfect illustration why I don=B9t want SDP.
>>>
>>> Media is complicated for good reason as there are many untold use cases=
.
>>> The entire IETF/W3C discussion around video constraints illustrates som=
e
>>> of the complexities and competing desires for just one single media typ=
e.
>>> If we tie ourselves to SDP we are limiting ourselves big time, and some=
 of
>>> the cool future stuff will be horribly hampered by it.
>>>
>>> My issues with SDP can be summarized as:
>>>
>>> - unneeded - much too high level an API
>>> - arcane format - legacy and problematic
>>> - offer/answer
>>> - incompatibilities
>>> - lack of API contact
>>> - doesn't truly solve goal of interoperability with legacy systems (eg.
>>> SIP)
>>>
>>> Regret that I did not have time for feedback earlier. As you can tell, =
I
>>> am not at all happy with where we sit today wrt requiring SDP. IMHO we
>>> need a lower level API if we are going to insist on using SDP.
>>>
>>>
>>> You can read my entire (long) rant against SDP here
>>> http://blog.webrtc.is/2013/03/06/sdp-the-webrtc-boat-anchor/
>>>
>>>
>>>
>>> _______________________________________________
>>> 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 pthatcher@google.com  Thu Mar  7 10:24: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 B4E3021F8B1D for ; Thu,  7 Mar 2013 10:24:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level: 
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 g-CHHBuU2kCg for ; Thu,  7 Mar 2013 10:24:29 -0800 (PST)
Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id 70AE821F8ACA for ; Thu,  7 Mar 2013 10:24:29 -0800 (PST)
Received: by mail-ve0-f182.google.com with SMTP id ox1so636773veb.27 for ; Thu, 07 Mar 2013 10:24:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=koHVyROIWgsEXj8dmDrrQm9XdaAzEWeg9eQ/ktRpLhk=; b=OOmbMGhibDDLV+1HKP2rYAIhWw9Ty5k9COvnzryLuthKuqKxONkBUnYEfXc81/ARRf h6aizG3zCjEsEQ0SqUZlfQMhrqWLevA/nYhT+a63M25hr+7dCxJoeHlO8QwbeRzSylDa pefiyQB4DDwO7GW0xkgFKUM5nznTdGiq5h8BT7lrxSFUy5aSOe8NUKFM7nGFTAoX/D01 R76tR8T8wtvnLgW4mWjlLIOB4gstE6Wb00BxxDTlQmVWIfpbb25ooZsbMyJO8CPsDqAj T+RVElwaAUeClaxwWBqODr8QKHga+hk8c1MxJCdJTMIyuLvD4/4eqEo8mL5A561DsGl2 /pYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=koHVyROIWgsEXj8dmDrrQm9XdaAzEWeg9eQ/ktRpLhk=; b=VUhT+kr5pu6bgum/9xDEiF1LqhWdn/Ly7CPRVekj1L1mGP0qLmlFgfL8H5RQz1OJh6 lkZiqNvJlsR7Fu6HqmHUv30iYt82uP1jH7Fn+EnRPYkTg6q0jw0rxyaqwdFj8dhKuqDx SGGn/Inpf+oqlaD0EfG+QAp5e/zW3TaUmAEynSXscYST0F7VkcJsn8BfT9RX/ptYF7/x G3cvDsv+1+LLb7wca61baSdoqELPyswIj8mVLpcHWLL0L1tbJtJQIthl6go7SlCOWQdV mQ71aiNDhtqPa1zM8L2+GUg+/zychcFr5mpn5t4LVUuyMnLQsmR3Cq0V13D8xFp/mIO5 A2ig==
X-Received: by 10.58.168.208 with SMTP id zy16mr3139997veb.3.1362680668914; Thu, 07 Mar 2013 10:24:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.49.102 with HTTP; Thu, 7 Mar 2013 10:23:48 -0800 (PST)
In-Reply-To: 
References:  
From: Peter Thatcher 
Date: Thu, 7 Mar 2013 10:23:48 -0800
Message-ID: 
To: Hadriel Kaplan 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnhKV9vg0oajqVUS6WnScRpdA3NC2nnx93PJKBREt6WUvjnxV8XD2QZVP6Y9Y6bJFl3IWSOr3bf9rZFWzHDy9fKHEuQg+Bwx4X04hwGXvOTpCnsRSkOHx3iEKudrm9b+7qk4ahnIfClJ27KjmH9xtBLM9fmc8sb8qoyQl994dqQ6b9LAKYHv93ki3koZccRKz9/IHY+
Cc: "" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 18:24:30 -0000

Hadriel,

That email is great.  Thank you for preserving it and for bringing it
to our attention.  I am especially sympathetic to the argument that
it's undesirable to have the W3C tied to MMUSIC for all time.




On Thu, Mar 7, 2013 at 8:50 AM, Hadriel Kaplan  wro=
te:
>
> I knew there was a reason for posting an email for the archive machine to=
 store for eternity... see this:
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg01256.html
>
> -hadriel
>
>
> On Mar 6, 2013, at 6:45 PM, Robin Raymond  wrote:
>
>>
>> Do we need SDP "blob" format in the exchange in the first place? All med=
ia
>> can be done without SDP given an intelligent stream API. An API already
>> exists to create these streams (albeit somewhat lacking if we remove the
>> SDP 'blob'). This API helps "simplify" creating this blob for later
>> exchange. But the blob is truly not needed. Each side could in fact crea=
te
>> the desired streams, pass in the appropriate media information such as
>> codecs and ICE candidates and chose the socket pair to multiplex upon.
>> Yes, it's a bit more low level but it certainly can be done (and cleanly=
).
>>
>> https://datatracker.ietf.org/doc/draft-jennings-rtcweb-plan/
>>
>> Nothing wrong with the draft in an SDP/SIP mindset but I'm going to take
>> it from a totally different non-SDP angle. I have to say, the ideas
>> presented are very good. I appreciate FEC, and synchronizing streams is
>> cool. But SDP isn=C2=B9t needed to do it. Let me as the programmer worry=
 about
>> how to manage streams and the features on the streams and associations
>> between the streams via an API only.
>>
>> Point 4, 5 and 6 in the specification all have to do with the complexiti=
es
>> of having to describe the intentions of mixing in SDP. So no comment
>> beyond =C2=B3don=C2=B9t use SDP=C2=B2.
>>
>> As for 7.1 =C2=AD =C2=B3this is because the sender choses the SSRC=C2=B2=
 =C2=AD only true
>> because we are forced to use SDP and the assumptions is that it=C2=B9s S=
IP. We
>> could have the receiver dictate what the sender should use in advance of
>> any media. In our case, we establish in advance what we want from all
>> parties before even =C2=B3ringing=C2=B2 the other party. We do not have =
SSRC
>> collisions as we reversed the scenario allowing the receiver to pick the
>> expected SSRC. Coordinating the streams is a problem with SIP because of
>> how they do forking/conferencing. This specification forces this issue o=
n
>> those not using SIP. If SIP has problems with streams arriving early to
>> their stateful offer/answer then let them worry about =C2=B3how=C2=B2 th=
ey intend to
>> match the streams at a higher SDP layer and get this draft out of the
>> RTCWEB track on the SIP track. To be clear, the proposal seems entirely
>> reasonable and intelligent for SIP/SDP. But it=C2=B9s way to SIP centric=
 for
>> general use.
>>
>> On that note, what I do need in the API is an ability to dictate the SSR=
C
>> when I create an RTP stream for sending (should I care to do that).
>>
>> 7.2 Multiple render
>>
>> Again this is an issue of SIP/SDP. We can control the SSRCs to split the=
m
>> out to allow multiplexing easily on the same RTP ports with multiple
>> parties/sources. If given the primitives to control the streams just, th=
is
>> specification could be used to dictate how to negotiate issues in their
>> space.
>>
>> 7.2.1 I=C2=B9m feeling the pain. How about just giving me an API where I=
 can
>> indicate what streams are FEC associated.
>>
>> 7.3 Give me API to give crypto keys to RTP layer. Let me handle the
>> fingerprint and security myself beyond that.
>>
>> 8. Let's just say politely that I would not want to be the developer
>> assigned to programming around all this stuff.
>>
>> Again, a perfect illustration why I don=C2=B9t want SDP.
>>
>> Media is complicated for good reason as there are many untold use cases.
>> The entire IETF/W3C discussion around video constraints illustrates some
>> of the complexities and competing desires for just one single media type=
.
>> If we tie ourselves to SDP we are limiting ourselves big time, and some =
of
>> the cool future stuff will be horribly hampered by it.
>>
>> My issues with SDP can be summarized as:
>>
>> - unneeded - much too high level an API
>> - arcane format - legacy and problematic
>> - offer/answer
>> - incompatibilities
>> - lack of API contact
>> - doesn't truly solve goal of interoperability with legacy systems (eg.
>> SIP)
>>
>> Regret that I did not have time for feedback earlier. As you can tell, I
>> am not at all happy with where we sit today wrt requiring SDP. IMHO we
>> need a lower level API if we are going to insist on using SDP.
>>
>>
>> You can read my entire (long) rant against SDP here
>> http://blog.webrtc.is/2013/03/06/sdp-the-webrtc-boat-anchor/
>>
>>
>>
>> _______________________________________________
>> 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 pthatcher@google.com  Thu Mar  7 10:34: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 A28D021F8A9B for ; Thu,  7 Mar 2013 10:34:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level: 
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 BEpjJrrDezDa for ; Thu,  7 Mar 2013 10:34:26 -0800 (PST)
Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) by ietfa.amsl.com (Postfix) with ESMTP id DDF9521F8A6E for ; Thu,  7 Mar 2013 10:34:25 -0800 (PST)
Received: by mail-ve0-f169.google.com with SMTP id 15so656257vea.0 for ; Thu, 07 Mar 2013 10:34:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=RBh7q8R4s4lJPNfMEFrhVCTa801Ct+YZfIa2cqqJp98=; b=mrNiDcrdRDF7boZXxUaqyLw/a+HsGj7GV/kN8p659+ilDH8rPLOa38D62BnG2HmRL/ P8AjoD+QiTWYMqnT9wMb6kNK7SyZhMHZXCw/+TlC/bdojN7fWRcu+zBXP3rDMNOAnZp9 TbycecAuabQYHOTqF6DIGodQzUTY1J7IZi5Ljw/fT9fxXytfUka0GVXMae+G1cncKq9b xYG6Qo48bFY4ISa4/ikRuZVUiPN3Iy2rlB0m3trcn8g00RUp1P9kBwUNZS94M2kwA5hZ So7Chm0lYLCqpmUFRg/eX48WX1xOUyk6ebIZwNF7nsxmqm+n8wWUgA/QL8ZSPgBNMQ3J nW/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=RBh7q8R4s4lJPNfMEFrhVCTa801Ct+YZfIa2cqqJp98=; b=bYXaGcOnIPi0Rbn5mCYFIR06oUfK7tyJt5zI7Xzs7ReAkMievPjVD5VAHy9dt5JKYq /oS2cHkcWsl0/B8GY5lRxAd2+qpYHUchC1ZOIZ8Nr/MmQbgEeemfUQV3Zk6K8ropoCoH lL2qOa0q8SILGRaWEdl0yFv5a59r6wkM+Emf+kwR8g35KtmQ0pjJsbtkCixh1yTyZTp5 q/vTMz6iT42z+nMlISYqyNfVnXUQdbsrZNcXatydkwbR2YQsYtCc3TTiqrUWp7U2gEK8 PcYDr+3mew8ohk2EQPOH855pu9DNVQG9LvUtk+8gwEMvrjgiJQNxTMOQa2ZBO3XaNgqH RtBA==
X-Received: by 10.220.155.8 with SMTP id q8mr13130443vcw.42.1362681264811; Thu, 07 Mar 2013 10:34:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.49.102 with HTTP; Thu, 7 Mar 2013 10:33:44 -0800 (PST)
In-Reply-To: 
References:   
From: Peter Thatcher 
Date: Thu, 7 Mar 2013 10:33:44 -0800
Message-ID: 
To: Hadriel Kaplan 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlhkeCSOc4qGjT1qRAwwxQ9feaw7Qyyng7A2fph+xRW+e8l5MDdnMwSqLftdo71amO2Eq3BX1ZXo+oJ6VE8TAoCjzDkuL7bvVuTxKgUb9cJKi2cS7DBlJfeyL9kLRr1l7XBk6YIMO0JkhXof9QIVm1DDs6UJuUrV7z+QJwL5+Gz+bLB6MpTRF9mihi/eoZ4sDWMk7tN
Cc: "" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 18:34:27 -0000

A question for all of you in the "please don't make us use SDP as an
API forever" crowd (and I include myself): Would it be acceptable to
you to have an intermediate step where we keep createOffeer,
setRemoteDescription and setLocalDescription as-is, but allow a JSON
argument?  It seems to be that such a thing could provide all the same
low-level of control as any other setup of methods, but may be much
more likely to be accepted by the group as a whole.  And, it would
still be a lot more pleasant for application developers, and leave
more flexibility for a future where low-level methods might be added.

As both an application developer and a browser implementor, I think a
good SessionDescription JSON format would be easy to implement,
pleasant to use, a small incremental step from what we currently have,
and would relieve the standards body of so much fighting over what the
SDP should look like.

I know it wouldn't be exactly what you're looking for, but I think it
would be achievable and much better than what we have.

If you're interested in such a thing, let me know.  I might be able to
provide something a little more concrete idea as to what such a format
could be.

On Thu, Mar 7, 2013 at 10:23 AM, Peter Thatcher  wrot=
e:
> Hadriel,
>
> That email is great.  Thank you for preserving it and for bringing it
> to our attention.  I am especially sympathetic to the argument that
> it's undesirable to have the W3C tied to MMUSIC for all time.
>
>
>
>
> On Thu, Mar 7, 2013 at 8:50 AM, Hadriel Kaplan  w=
rote:
>>
>> I knew there was a reason for posting an email for the archive machine t=
o store for eternity... see this:
>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg01256.html
>>
>> -hadriel
>>
>>
>> On Mar 6, 2013, at 6:45 PM, Robin Raymond  wrote:
>>
>>>
>>> Do we need SDP "blob" format in the exchange in the first place? All me=
dia
>>> can be done without SDP given an intelligent stream API. An API already
>>> exists to create these streams (albeit somewhat lacking if we remove th=
e
>>> SDP 'blob'). This API helps "simplify" creating this blob for later
>>> exchange. But the blob is truly not needed. Each side could in fact cre=
ate
>>> the desired streams, pass in the appropriate media information such as
>>> codecs and ICE candidates and chose the socket pair to multiplex upon.
>>> Yes, it's a bit more low level but it certainly can be done (and cleanl=
y).
>>>
>>> https://datatracker.ietf.org/doc/draft-jennings-rtcweb-plan/
>>>
>>> Nothing wrong with the draft in an SDP/SIP mindset but I'm going to tak=
e
>>> it from a totally different non-SDP angle. I have to say, the ideas
>>> presented are very good. I appreciate FEC, and synchronizing streams is
>>> cool. But SDP isn=C2=B9t needed to do it. Let me as the programmer worr=
y about
>>> how to manage streams and the features on the streams and associations
>>> between the streams via an API only.
>>>
>>> Point 4, 5 and 6 in the specification all have to do with the complexit=
ies
>>> of having to describe the intentions of mixing in SDP. So no comment
>>> beyond =C2=B3don=C2=B9t use SDP=C2=B2.
>>>
>>> As for 7.1 =C2=AD =C2=B3this is because the sender choses the SSRC=C2=
=B2 =C2=AD only true
>>> because we are forced to use SDP and the assumptions is that it=C2=B9s =
SIP. We
>>> could have the receiver dictate what the sender should use in advance o=
f
>>> any media. In our case, we establish in advance what we want from all
>>> parties before even =C2=B3ringing=C2=B2 the other party. We do not have=
 SSRC
>>> collisions as we reversed the scenario allowing the receiver to pick th=
e
>>> expected SSRC. Coordinating the streams is a problem with SIP because o=
f
>>> how they do forking/conferencing. This specification forces this issue =
on
>>> those not using SIP. If SIP has problems with streams arriving early to
>>> their stateful offer/answer then let them worry about =C2=B3how=C2=B2 t=
hey intend to
>>> match the streams at a higher SDP layer and get this draft out of the
>>> RTCWEB track on the SIP track. To be clear, the proposal seems entirely
>>> reasonable and intelligent for SIP/SDP. But it=C2=B9s way to SIP centri=
c for
>>> general use.
>>>
>>> On that note, what I do need in the API is an ability to dictate the SS=
RC
>>> when I create an RTP stream for sending (should I care to do that).
>>>
>>> 7.2 Multiple render
>>>
>>> Again this is an issue of SIP/SDP. We can control the SSRCs to split th=
em
>>> out to allow multiplexing easily on the same RTP ports with multiple
>>> parties/sources. If given the primitives to control the streams just, t=
his
>>> specification could be used to dictate how to negotiate issues in their
>>> space.
>>>
>>> 7.2.1 I=C2=B9m feeling the pain. How about just giving me an API where =
I can
>>> indicate what streams are FEC associated.
>>>
>>> 7.3 Give me API to give crypto keys to RTP layer. Let me handle the
>>> fingerprint and security myself beyond that.
>>>
>>> 8. Let's just say politely that I would not want to be the developer
>>> assigned to programming around all this stuff.
>>>
>>> Again, a perfect illustration why I don=C2=B9t want SDP.
>>>
>>> Media is complicated for good reason as there are many untold use cases=
.
>>> The entire IETF/W3C discussion around video constraints illustrates som=
e
>>> of the complexities and competing desires for just one single media typ=
e.
>>> If we tie ourselves to SDP we are limiting ourselves big time, and some=
 of
>>> the cool future stuff will be horribly hampered by it.
>>>
>>> My issues with SDP can be summarized as:
>>>
>>> - unneeded - much too high level an API
>>> - arcane format - legacy and problematic
>>> - offer/answer
>>> - incompatibilities
>>> - lack of API contact
>>> - doesn't truly solve goal of interoperability with legacy systems (eg.
>>> SIP)
>>>
>>> Regret that I did not have time for feedback earlier. As you can tell, =
I
>>> am not at all happy with where we sit today wrt requiring SDP. IMHO we
>>> need a lower level API if we are going to insist on using SDP.
>>>
>>>
>>> You can read my entire (long) rant against SDP here
>>> http://blog.webrtc.is/2013/03/06/sdp-the-webrtc-boat-anchor/
>>>
>>>
>>>
>>> _______________________________________________
>>> 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 ekr@rtfm.com  Thu Mar  7 10: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 F248321F8A9B for ; Thu,  7 Mar 2013 10:42:59 -0800 (PST)
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 NdduNELSPXeW for ; Thu,  7 Mar 2013 10:42:51 -0800 (PST)
Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7C04D21F89FD for ; Thu,  7 Mar 2013 10:42:51 -0800 (PST)
Received: by mail-qa0-f42.google.com with SMTP id cr7so3445949qab.1 for ; Thu, 07 Mar 2013 10:42:51 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=cp9JR3ZD85A0cutYvGllV+aPx4z+V/Q0ErWknTgsrjY=; b=XQxCjOPO9wPoW7roLGIbzBaSqckpGSMB0sO51GqCGsvChICr+w51/y38hnZyQgtgVg VpvnzE5urewyipVhinshcmQ02o58F4xKLPmqR44Uk439kSACA/XmcEdX02kiBOjMQjhU VtVnv+E/PIzObGhXgvrSch20DfzNEHkEw61JlsLYOAmLopTBNnFopUQetx97Xh2QnBjE uUHfwAMBYFI68wNhGiq0ua3jNOE5OVGwVKMRRj7ONcL6SQq0WCpmFuzp5wOtLmbUzUPN Fwo5s8IAbU0xa46ffrp9tJuSj0dq25om4tQUpVlmfQnJsmpXqqkqzJWPCIM3jn1MFc8H O5JA==
X-Received: by 10.224.199.70 with SMTP id er6mr52327309qab.19.1362681770877; Thu, 07 Mar 2013 10:42:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.49.27.230 with HTTP; Thu, 7 Mar 2013 10:42:09 -0800 (PST)
X-Originating-IP: [74.95.2.173]
In-Reply-To: 
References:    
From: Eric Rescorla 
Date: Thu, 7 Mar 2013 10:42:09 -0800
Message-ID: 
To: Mary Barnes 
Content-Type: multipart/alternative; boundary=20cf30050e8ae53d0804d75a12af
X-Gm-Message-State: ALoCoQkZsL+veIxFEubp95yj6jsK+8VsE0KUpml4L8bG6r64jTOP62Pwp2nmS+3UVfZaTM8k5aOa
Cc: "" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 18:43:00 -0000

--20cf30050e8ae53d0804d75a12af
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Mar 7, 2013 at 9:56 AM, Mary Barnes wrote:

> On Thu, Mar 7, 2013 at 11:43 AM, Martin Thomson
>  wrote:
> > Obviously I (and my employer) agree with these sentiments
> > wholeheartedly.  Both Robin and Hadriel.
> >
> > That doesn't change the fact that a number of people are highly
> > motivated to protect their investment in SDP offer/answer.  For those
> > people, the pain that causes everyone else is clearly far less
> > important than the pain they feel at this moment.  So here we are.
>
> [MB] I originally thought that either approach could work.  I did see
> the value that folks saw in using SDP offer/answer. But after sitting
> through the interim meeting last month, I am very much of the mindset
> that using SDP O/A is a bad idea.   I think many of us thought that
> using the SDP blob would help with interoperability with "legacy" SIP
> endpoints.  I don't see that now at all.  I think we will end up with
> a very fragile solution that will be very difficult to extend/modify
> later if we continue down the SDP O/A path.
> [/MB]
>
>
Hasn't the WG already been asked this question not once but
twice.

1. In Taipei:
http://www.ietf.org/proceedings/82/minutes/rtcweb.txt

  Cullen - we need to advise w3c on setting up a media stream.
  - low-level API - browser implementors were not interested.
  - mid-level - browser implements SDP negotiation
  - high-level - browser implements a signal protocol (jingle)

  Hardie - if you agree the state machine should be based on Offer/Answer,
raise
  your hand. Count: 31, 3 in jabber room.

  If you do not agree, raise your hand.
  Count: 4

  Bernard - how can you ask this if you assume ICE, you need Offer/Answer.

  Cullen - could rewrite ICE.

  If there is not enough info, raise your hand
  Count:  5

  Hardie - Rough consensus in the room and jabber that we will base the
state machine on SDP OA.


2. When we picked JSEP, which has SDP at its heart.



And that's just the IETF WG. W3C *also* had a consensus call on
exactly this point:
http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0098.html.

The consensus was for "Alternative 1":

  1) Continue with a design based on the PeerConnection object, using SDP
  as part of the API, roughly in the style of the current API description.

This happened less than 6 months ago and it wasn't a close thing.

Moreover, there are two shipping--and indeed
interopable!--implementations (Chrome and Firefox) based on the
PeerConnection/3264 OA design style (I'll get to Peter's comment about
JSON in a separate message).

Now, none of this is to say that the WG can't reconsider and come to a
new decision, but I think that at given the number of times this point
has been argued and reargued, the bar to that reconsideration has to
be fairly high (and needs to be jointly taken in IETF and W3C)
especially since this essentially amounts to a request to burn the
entire W3C API and start over.

-Ekr

--20cf30050e8ae53d0804d75a12af
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Thu, Mar 7, 2013 at 9:56 AM, Mary Barnes =
<mary.ietf.barnes@gmail.com> wrote:



On Thu, Mar 7, 2013 at 11:43 AM, Martin Thomson

<martin.thomson@gmail.com> wrote:

> Obviously I (and my employer) agree with these sentiments

> wholeheartedly. =A0Both Robin and Hadriel.

>

> That doesn't change the fact that a number of people are highly
> motivated to protect their investment in SDP offer/answer. =A0For thos=
e

> people, the pain that causes everyone else is clearly far less

> important than the pain they feel at this moment. =A0So here we are.



[MB] I originally thought that either approach could work. =A0I did s=
ee

the value that folks saw in using SDP offer/answer. But after sitting

through the interim meeting last month, I am very much of the mindset

that using SDP O/A is a bad idea. =A0 I think many of us thought that

using the SDP blob would help with interoperability with "legacy"=
 SIP

endpoints. =A0I don't see that now at all. =A0I think we will end up wi=
th

a very fragile solution that will be very difficult to extend/modify

later if we continue down the SDP O/A path.

[/MB]




Hasn't the WG already been asked this quest=
ion not once but
twice.

1. In Taipei:



<=
div>=A0 Cullen - we need to advise w3c on setting up a media stream.=A0


=A0 - low-level API - browser implementors were not interested.
<=
div>=A0 - mid-level - browser implements SDP negotiation
=A0 - hi=
gh-level - browser implements a signal protocol (jingle)
=A0=A0


=A0 Hardie - if you agree the state machine should be based on Offer/Answer=
, raise
=A0 your hand. Count: 31, 3 in jabber room.
=A0=
=A0
=A0 If you do not agree, raise your hand.=A0
=A0 Co=
unt: 4



=A0=A0
=A0 Bernard - how can you ask this if you assume ICE,=
 you need Offer/Answer.=A0
=A0=A0
=A0 Cullen - could re=
write ICE.=A0
=A0=A0
=A0 If there is not enough info, r=
aise your hand



=A0 Count: =A05
=A0=A0
=A0 Hardie - Rough consensu=
s in the room and jabber that we will base the state machine on SDP OA.


2. When we picked JSEP, which has SDP =
at its heart.






And that's just the I=
ETF WG. W3C *also* had a consensus call on
exactly this point:



The consensus was for "Alternative 1":
<=
div>
=A0 1) Continue with a design based on the PeerConnectio=
n object, using SDP=A0
=A0 as part of the API, roughly in the sty=
le of the current API description.




This happened less than 6 months ago and it wasn't =
a close thing.

Moreover, there are two shipping--a=
nd indeed
interopable!--implementations (Chrome and Firefox) base=
d on the



PeerConnection/3264 OA design style (I'll get to Peter's comme=
nt about
JSON in a separate message).

No=
w, none of this is to say that the WG can't reconsider and come to a


new decision, but I think that at given the number of times this point=

has been argued and reargued, the bar to that reconsideration ha=
s to
be fairly high (and needs to be jointly taken in IETF and W3=
C)



especially since this essentially amounts to a request to burn the
entire W3C API and start over.=A0
=A0 =A0
-Ekr
=A0


--20cf30050e8ae53d0804d75a12af--

From roman@telurix.com  Thu Mar  7 10:44: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 A02DE21F8945 for ; Thu,  7 Mar 2013 10:44:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.845
X-Spam-Level: 
X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_UNSUB18=0.131]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0BPOmUUr3ob for ; Thu,  7 Mar 2013 10:44:30 -0800 (PST)
Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by ietfa.amsl.com (Postfix) with ESMTP id A3D0D21F854E for ; Thu,  7 Mar 2013 10:44:29 -0800 (PST)
Received: by mail-ee0-f52.google.com with SMTP id b15so595243eek.39 for ; Thu, 07 Mar 2013 10:44:28 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=VeQp8h3xJ7q6QTpSmVgTnPQi9FeVXxWh3b9nPNP/6ao=; b=Pp/wg7D2bPoBvdy8Qsj5GEOf2OpZa0W6IoCgL4PAMzjtY2ZGdt1qIkUYGDsWsBOXjp dYbr1EaepwT1iGvSnV4cW77tMre8u3kI3xKAEIFSSDAhyIs1UkfkIN43WecllP2FFmqS hVGJ/LA5bHpf9ppr4FkTlrlkLxdquWftPMhqXdqBDg+kRPkU9+W5trYgdfJE6g6STUx5 uRxUMVpsC9PoDm6Go9gbP5xjY86fN1Y4KN9/C+0Gtt24Wuo5ctq8SSyQncRpJEJOk9oX zMqLJzJt5BaL8Hs9+YH4J3cAeTPfL0btsY0121TS8Yc0bauzQpg5Z+Z043tbRBxSS7t0 51Gw==
X-Received: by 10.194.158.161 with SMTP id wv1mr57014106wjb.38.1362681868602;  Thu, 07 Mar 2013 10:44:28 -0800 (PST)
Received: from mail-wi0-x231.google.com ([2a00:1450:400c:c05::231]) by mx.google.com with ESMTPS id eo1sm34853204wib.8.2013.03.07.10.44.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Mar 2013 10:44:27 -0800 (PST)
Received: by mail-wi0-f177.google.com with SMTP id hm14so515666wib.16 for ; Thu, 07 Mar 2013 10:44:26 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.91.106 with SMTP id cd10mr35702702wib.6.1362681866290; Thu, 07 Mar 2013 10:44:26 -0800 (PST)
Received: by 10.217.107.135 with HTTP; Thu, 7 Mar 2013 10:44:26 -0800 (PST)
In-Reply-To: 
References:    
Date: Thu, 7 Mar 2013 13:44:26 -0500
Message-ID: 
From: Roman Shpount 
To: Peter Thatcher 
Content-Type: multipart/alternative; boundary=f46d043be11a95317604d75a18c6
X-Gm-Message-State: ALoCoQm5z+TP3KY1yZAPU3Wmp8cXjIhjuiqG9I3I/g35MnEci6XSg+PpcQGEgXMRMpmYy7gJoVsU
Cc: "" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 18:44:31 -0000

--f46d043be11a95317604d75a18c6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I very strongly agree. I think having an API independent from SDP will
allow the group to concentrate on the actual features instead of arguing
about the useless blob syntax. I was initially proponent of Offer/Answer
but once I started using the actual API, I saw offer/answer presenting
nothing but problems. I actually see current WebRTC SDP offer/answer
implementation as a hindrance to SIP interop. It provides a much more
coarse API then typically present in SIP client. That in turns forces
WebRTC implementer to make decision for a developer that create interop
problems (like no way to switch send codecs without changing transport
parameters).
_____________
Roman Shpount


On Thu, Mar 7, 2013 at 1:33 PM, Peter Thatcher  wrote=
:

> A question for all of you in the "please don't make us use SDP as an
> API forever" crowd (and I include myself): Would it be acceptable to
> you to have an intermediate step where we keep createOffeer,
> setRemoteDescription and setLocalDescription as-is, but allow a JSON
> argument?  It seems to be that such a thing could provide all the same
> low-level of control as any other setup of methods, but may be much
> more likely to be accepted by the group as a whole.  And, it would
> still be a lot more pleasant for application developers, and leave
> more flexibility for a future where low-level methods might be added.
>
> As both an application developer and a browser implementor, I think a
> good SessionDescription JSON format would be easy to implement,
> pleasant to use, a small incremental step from what we currently have,
> and would relieve the standards body of so much fighting over what the
> SDP should look like.
>
> I know it wouldn't be exactly what you're looking for, but I think it
> would be achievable and much better than what we have.
>
> If you're interested in such a thing, let me know.  I might be able to
> provide something a little more concrete idea as to what such a format
> could be.
>
> On Thu, Mar 7, 2013 at 10:23 AM, Peter Thatcher 
> wrote:
> > Hadriel,
> >
> > That email is great.  Thank you for preserving it and for bringing it
> > to our attention.  I am especially sympathetic to the argument that
> > it's undesirable to have the W3C tied to MMUSIC for all time.
> >
> >
> >
> >
> > On Thu, Mar 7, 2013 at 8:50 AM, Hadriel Kaplan 
> wrote:
> >>
> >> I knew there was a reason for posting an email for the archive machine
> to store for eternity... see this:
> >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg01256.html
> >>
> >> -hadriel
> >>
> >>
> >> On Mar 6, 2013, at 6:45 PM, Robin Raymond  wrote:
> >>
> >>>
> >>> Do we need SDP "blob" format in the exchange in the first place? All
> media
> >>> can be done without SDP given an intelligent stream API. An API alrea=
dy
> >>> exists to create these streams (albeit somewhat lacking if we remove
> the
> >>> SDP 'blob'). This API helps "simplify" creating this blob for later
> >>> exchange. But the blob is truly not needed. Each side could in fact
> create
> >>> the desired streams, pass in the appropriate media information such a=
s
> >>> codecs and ICE candidates and chose the socket pair to multiplex upon=
.
> >>> Yes, it's a bit more low level but it certainly can be done (and
> cleanly).
> >>>
> >>> https://datatracker.ietf.org/doc/draft-jennings-rtcweb-plan/
> >>>
> >>> Nothing wrong with the draft in an SDP/SIP mindset but I'm going to
> take
> >>> it from a totally different non-SDP angle. I have to say, the ideas
> >>> presented are very good. I appreciate FEC, and synchronizing streams =
is
> >>> cool. But SDP isn=B9t needed to do it. Let me as the programmer worry
> about
> >>> how to manage streams and the features on the streams and association=
s
> >>> between the streams via an API only.
> >>>
> >>> Point 4, 5 and 6 in the specification all have to do with the
> complexities
> >>> of having to describe the intentions of mixing in SDP. So no comment
> >>> beyond =B3don=B9t use SDP=B2.
> >>>
> >>> As for 7.1 =AD =B3this is because the sender choses the SSRC=B2 =AD o=
nly true
> >>> because we are forced to use SDP and the assumptions is that it=B9s S=
IP.
> We
> >>> could have the receiver dictate what the sender should use in advance
> of
> >>> any media. In our case, we establish in advance what we want from all
> >>> parties before even =B3ringing=B2 the other party. We do not have SSR=
C
> >>> collisions as we reversed the scenario allowing the receiver to pick
> the
> >>> expected SSRC. Coordinating the streams is a problem with SIP because
> of
> >>> how they do forking/conferencing. This specification forces this issu=
e
> on
> >>> those not using SIP. If SIP has problems with streams arriving early =
to
> >>> their stateful offer/answer then let them worry about =B3how=B2 they
> intend to
> >>> match the streams at a higher SDP layer and get this draft out of the
> >>> RTCWEB track on the SIP track. To be clear, the proposal seems entire=
ly
> >>> reasonable and intelligent for SIP/SDP. But it=B9s way to SIP centric=
 for
> >>> general use.
> >>>
> >>> On that note, what I do need in the API is an ability to dictate the
> SSRC
> >>> when I create an RTP stream for sending (should I care to do that).
> >>>
> >>> 7.2 Multiple render
> >>>
> >>> Again this is an issue of SIP/SDP. We can control the SSRCs to split
> them
> >>> out to allow multiplexing easily on the same RTP ports with multiple
> >>> parties/sources. If given the primitives to control the streams just,
> this
> >>> specification could be used to dictate how to negotiate issues in the=
ir
> >>> space.
> >>>
> >>> 7.2.1 I=B9m feeling the pain. How about just giving me an API where I=
 can
> >>> indicate what streams are FEC associated.
> >>>
> >>> 7.3 Give me API to give crypto keys to RTP layer. Let me handle the
> >>> fingerprint and security myself beyond that.
> >>>
> >>> 8. Let's just say politely that I would not want to be the developer
> >>> assigned to programming around all this stuff.
> >>>
> >>> Again, a perfect illustration why I don=B9t want SDP.
> >>>
> >>> Media is complicated for good reason as there are many untold use
> cases.
> >>> The entire IETF/W3C discussion around video constraints illustrates
> some
> >>> of the complexities and competing desires for just one single media
> type.
> >>> If we tie ourselves to SDP we are limiting ourselves big time, and
> some of
> >>> the cool future stuff will be horribly hampered by it.
> >>>
> >>> My issues with SDP can be summarized as:
> >>>
> >>> - unneeded - much too high level an API
> >>> - arcane format - legacy and problematic
> >>> - offer/answer
> >>> - incompatibilities
> >>> - lack of API contact
> >>> - doesn't truly solve goal of interoperability with legacy systems (e=
g.
> >>> SIP)
> >>>
> >>> Regret that I did not have time for feedback earlier. As you can tell=
,
> I
> >>> am not at all happy with where we sit today wrt requiring SDP. IMHO w=
e
> >>> need a lower level API if we are going to insist on using SDP.
> >>>
> >>>
> >>> You can read my entire (long) rant against SDP here
> >>> http://blog.webrtc.is/2013/03/06/sdp-the-webrtc-boat-anchor/
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
>

--f46d043be11a95317604d75a18c6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I very strongly agree. I think having an API independent from SDP will allo=
w the group to concentrate on the actual features instead of arguing about =
the useless blob syntax.=A0I was initially proponent of Offer/Answer but on=
ce I started using the actual API, I saw offer/answer presenting nothing bu=
t problems.=A0I actually see current WebRTC SDP offer/answer implementation=
 as a=A0hindrance=A0to SIP interop. It provides a much more coarse API then=
 typically present in SIP client. That in turns forces WebRTC implementer=
=A0to make decision for a developer that create interop problems (like no w=
ay to switch send codecs without changing transport parameters).

_____________
Roman Shpount



On Thu, Mar 7, 2013 at 1:33 PM, Peter Th=
atcher <pthatcher@google.com> wrote:

A question for all of you in the "please don't make us use SDP as =
an

API forever" crowd (and I include myself): Would it be acceptable to
you to have an intermediate step where we keep createOffeer,

setRemoteDescription and setLocalDescription as-is, but allow a JSON

argument? =A0It seems to be that such a thing could provide all the same
low-level of control as any other setup of methods, but may be much

more likely to be accepted by the group as a whole. =A0And, it would

still be a lot more pleasant for application developers, and leave

more flexibility for a future where low-level methods might be added.



As both an application developer and a browser implementor, I think a

good SessionDescription JSON format would be easy to implement,

pleasant to use, a small incremental step from what we currently have,

and would relieve the standards body of so much fighting over what the

SDP should look like.



I know it wouldn't be exactly what you're looking for, but I think =
it

would be achievable and much better than what we have.



If you're interested in such a thing, let me know. =A0I might be able t=
o

provide something a little more concrete idea as to what such a format

could be.




On Thu, Mar 7, 2013 at 10:23 AM, Peter Thatcher <pthatcher@google.com> wrote:

> Hadriel,

>

> That email is great. =A0Thank you for preserving it and for bringing i=
t

> to our attention. =A0I am especially sympathetic to the argument that<=
br>
> it's undesirable to have the W3C tied to MMUSIC for all time.

>

>

>

>

> On Thu, Mar 7, 2013 at 8:50 AM, Hadriel Kaplan <HKaplan@acmepacket.com> wrote:

>>

>> I knew there was a reason for posting an email for the archive mac=
hine to store for eternity... see this:

>> http://www.ietf.org/mail-archive/web/rtcweb/c=
urrent/msg01256.html

>>

>> -hadriel

>>

>>

>> On Mar 6, 2013, at 6:45 PM, Robin Raymond <robin@hookflash.com> wrote:

>>

>>>

>>> Do we need SDP "blob" format in the exchange in the =
first place? All media

>>> can be done without SDP given an intelligent stream API. An AP=
I already

>>> exists to create these streams (albeit somewhat lacking if we =
remove the

>>> SDP 'blob'). This API helps "simplify" creat=
ing this blob for later

>>> exchange. But the blob is truly not needed. Each side could in=
 fact create

>>> the desired streams, pass in the appropriate media information=
 such as

>>> codecs and ICE candidates and chose the socket pair to multipl=
ex upon.

>>> Yes, it's a bit more low level but it certainly can be don=
e (and cleanly).

>>>

>>> https://datatracker.ietf.org/doc/draft-jenning=
s-rtcweb-plan/

>>>

>>> Nothing wrong with the draft in an SDP/SIP mindset but I'm=
 going to take

>>> it from a totally different non-SDP angle. I have to say, the =
ideas

>>> presented are very good. I appreciate FEC, and synchronizing s=
treams is

>>> cool. But SDP isn=B9t needed to do it. Let me as the programme=
r worry about

>>> how to manage streams and the features on the streams and asso=
ciations

>>> between the streams via an API only.

>>>

>>> Point 4, 5 and 6 in the specification all have to do with the =
complexities

>>> of having to describe the intentions of mixing in SDP. So no c=
omment

>>> beyond =B3don=B9t use SDP=B2.

>>>

>>> As for 7.1 =AD =B3this is because the sender choses the SSRC=
=B2 =AD only true

>>> because we are forced to use SDP and the assumptions is that i=
t=B9s SIP. We

>>> could have the receiver dictate what the sender should use in =
advance of

>>> any media. In our case, we establish in advance what we want f=
rom all

>>> parties before even =B3ringing=B2 the other party. We do not h=
ave SSRC

>>> collisions as we reversed the scenario allowing the receiver t=
o pick the

>>> expected SSRC. Coordinating the streams is a problem with SIP =
because of

>>> how they do forking/conferencing. This specification forces th=
is issue on

>>> those not using SIP. If SIP has problems with streams arriving=
 early to

>>> their stateful offer/answer then let them worry about =B3how=
=B2 they intend to

>>> match the streams at a higher SDP layer and get this draft out=
 of the

>>> RTCWEB track on the SIP track. To be clear, the proposal seems=
 entirely

>>> reasonable and intelligent for SIP/SDP. But it=B9s way to SIP =
centric for

>>> general use.

>>>

>>> On that note, what I do need in the API is an ability to dicta=
te the SSRC

>>> when I create an RTP stream for sending (should I care to do t=
hat).

>>>

>>> 7.2 Multiple render

>>>

>>> Again this is an issue of SIP/SDP. We can control the SSRCs to=
 split them

>>> out to allow multiplexing easily on the same RTP ports with mu=
ltiple

>>> parties/sources. If given the primitives to control the stream=
s just, this

>>> specification could be used to dictate how to negotiate issues=
 in their

>>> space.

>>>

>>> 7.2.1 I=B9m feeling the pain. How about just giving me an API =
where I can

>>> indicate what streams are FEC associated.

>>>

>>> 7.3 Give me API to give crypto keys to RTP layer. Let me handl=
e the

>>> fingerprint and security myself beyond that.

>>>

>>> 8. Let's just say politely that I would not want to be the=
 developer

>>> assigned to programming around all this stuff.

>>>

>>> Again, a perfect illustration why I don=B9t want SDP.

>>>

>>> Media is complicated for good reason as there are many untold =
use cases.

>>> The entire IETF/W3C discussion around video constraints illust=
rates some

>>> of the complexities and competing desires for just one single =
media type.

>>> If we tie ourselves to SDP we are limiting ourselves big time,=
 and some of

>>> the cool future stuff will be horribly hampered by it.

>>>

>>> My issues with SDP can be summarized as:

>>>

>>> - unneeded - much too high level an API

>>> - arcane format - legacy and problematic

>>> - offer/answer

>>> - incompatibilities

>>> - lack of API contact

>>> - doesn't truly solve goal of interoperability with legacy=
 systems (eg.

>>> SIP)

>>>

>>> Regret that I did not have time for feedback earlier. As you c=
an tell, I

>>> am not at all happy with where we sit today wrt requiring SDP.=
 IMHO we

>>> need a lower level API if we are going to insist on using SDP.=


>>>

>>>

>>> You can read my entire (long) rant against SDP here

>>> http://blog.webrtc.is/2013/03/06/sdp-the-webrt=
c-boat-anchor/

>>>

>>>

>>>

>>> _______________________________________________

>>> 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





--f46d043be11a95317604d75a18c6--

From ekr@rtfm.com  Thu Mar  7 10:46: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 75C4321F8B1A for ; Thu,  7 Mar 2013 10:46:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.91
X-Spam-Level: 
X-Spam-Status: No, score=-102.91 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 VPOtOKBGBVAv for ; Thu,  7 Mar 2013 10:46:38 -0800 (PST)
Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 960E321F8B18 for ; Thu,  7 Mar 2013 10:46:38 -0800 (PST)
Received: by mail-qe0-f48.google.com with SMTP id 9so482926qea.7 for ; Thu, 07 Mar 2013 10:46:38 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=bdGgVnnkZpUNxlUHLPNAFIoJJUkAD2867bbEWmWZCuk=; b=A7ZDGlB0BnuKiaKjh1lVb08arImn4y+8wV5Npc9omJeM6ij8cxgqfhPrgy2bbT47cR 11Imgs/WAaRUf/NHp0y2BEp8CfkA9yYuLOoSaQGBAYNPDHGtuXGSfeFsEimBhhoAB4ZT 7gIFtS1iC8xOxwE3Tyz+d2Y9nrlRlvpAUqCx/+zXShxo6P+OM72OIWpd1lHjqDEvzq2G Z0GlGGjaWgG4hyj2JkPtZff1F49YhGUfbezYffotH0q/k9PJSntckku4/e9LpU6K7Q4B uUSM8qnsaCYOQ9kv0V4AxCUsYoz4/pVpFrvLeHRZRmUSoPyHYO9Lw/snW0dA+K2V3CTc 7u+A==
X-Received: by 10.224.33.14 with SMTP id f14mr52436279qad.69.1362681998127; Thu, 07 Mar 2013 10:46:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.49.27.230 with HTTP; Thu, 7 Mar 2013 10:45:58 -0800 (PST)
X-Originating-IP: [74.95.2.173]
In-Reply-To: 
References:    
From: Eric Rescorla 
Date: Thu, 7 Mar 2013 10:45:58 -0800
Message-ID: 
To: Peter Thatcher 
Content-Type: multipart/alternative; boundary=20cf3074b9a470cb2304d75a20f5
X-Gm-Message-State: ALoCoQnf+lpC1bD1hfVSMQpiXgaaPitGiuZnSU0Z3lyrWrfPa4XCL5PbSAls5Sh8JW07u5VrlShi
Cc: "" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 18:46:39 -0000

--20cf3074b9a470cb2304d75a20f5
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Mar 7, 2013 at 10:33 AM, Peter Thatcher wrote:

> A question for all of you in the "please don't make us use SDP as an
> API forever" crowd (and I include myself): Would it be acceptable to
> you to have an intermediate step where we keep createOffeer,
> setRemoteDescription and setLocalDescription as-is, but allow a JSON
> argument?  It seems to be that such a thing could provide all the same
> low-level of control as any other setup of methods, but may be much
> more likely to be accepted by the group as a whole.  And, it would
> still be a lot more pleasant for application developers, and leave
> more flexibility for a future where low-level methods might be added.
>
> As both an application developer and a browser implementor, I think a
> good SessionDescription JSON format would be easy to implement,
> pleasant to use, a small incremental step from what we currently have,
> and would relieve the standards body of so much fighting over what the
> SDP should look like.
>
> I know it wouldn't be exactly what you're looking for, but I think it
> would be achievable and much better than what we have.


II don't understand how this changes anything meaningful. The point
of using SDP isn't the crufty line-based encoding, it's being committed
to the SDP offer/answer semantics. So, when you talk about having
JSON, you're talking about one of two things:

1. Having a format which is semantically equivalent to SDP.
2. Having a format which is semantically distinct (or perhaps a superset)
of SDP.

In case 1, I don't see what this bought you, other than programming
convenience. It's not like it would be difficult to build code to
mechanically
dissect the SDP encoding.

In case 2, you have forked SDP, and largely obviated the point of
using SDP in the first place.

-Ekr

--20cf3074b9a470cb2304d75a20f5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Thu, Mar 7, 2013 at 10:33 AM, Peter T=
hatcher <pthatcher@google.com> wrote:


A question for all of you in the "please don't make us use SDP as =
an

API forever" crowd (and I include myself): Would it be acceptable to
you to have an intermediate step where we keep createOffeer,

setRemoteDescription and setLocalDescription as-is, but allow a JSON

argument? =A0It seems to be that such a thing could provide all the same
low-level of control as any other setup of methods, but may be much

more likely to be accepted by the group as a whole. =A0And, it would

still be a lot more pleasant for application developers, and leave

more flexibility for a future where low-level methods might be added.



As both an application developer and a browser implementor, I think a

good SessionDescription JSON format would be easy to implement,

pleasant to use, a small incremental step from what we currently have,

and would relieve the standards body of so much fighting over what the

SDP should look like.



I know it wouldn't be exactly what you're looking for, but I think =
it

would be achievable and much better than what we have.
II don't understand how this changes anything meaningful. T=
he point
of using SDP isn't the crufty line-based encoding, i=
t's being committed



to the SDP offer/answer semantics. So, when you talk about having
JSON, you're talking about one of two things:

1. Having a format which is semantically equivalent to SDP.



2. Having a format which is semantically distinct (or perhaps a supers=
et)
of SDP.

In case 1, I don't see w=
hat this bought you, other than programming
convenience. It's=
 not like it would be difficult to build code to mechanically



dissect the SDP encoding.

In case 2, you have=
 forked SDP, and largely obviated the point of
using SDP in the f=
irst place.

-Ekr

=A0




--20cf3074b9a470cb2304d75a20f5--

From mary.ietf.barnes@gmail.com  Thu Mar  7 10:51: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 8650821F8AA6 for ; Thu,  7 Mar 2013 10:51:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.72
X-Spam-Level: 
X-Spam-Status: No, score=-103.72 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, 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 f3b1vDtQlMNH for ; Thu,  7 Mar 2013 10:51:04 -0800 (PST)
Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id BCC6E21F8A91 for ; Thu,  7 Mar 2013 10:51:01 -0800 (PST)
Received: by mail-qe0-f45.google.com with SMTP id b4so494604qen.32 for ; Thu, 07 Mar 2013 10:51:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=OMZXvCNI3yUumLjiOQB1TfzWWFDyc1rSGkW5CKj6xAM=; b=TMOAM2GXX6M9a4TeoT58y6FNORVzu4fiypifPY9jHjXM+NS6AOMKeIrcKXs5B6mV0j V+BcETw3bAzo+QSB9/01WCEK+4QnCxpZi4TkspnIfPlSOVBUrUQbrL3SFowHde6PxqKl SCGs+g0dXjQlflHmRWkLIiICeWkhDRFo0GYVkv+ngkta3p5SaRcDr3NKmo3Oa5JY2B53 QFtdTNN4jd2gC2IkeWwG9kxZBJ6/j9z+mRgtklTF8h+T70JhN171q7aVD4WfbCb/raQF b/bDBPGWrP63Axy4U+AWztd486Awu5taSdU9NEzS3p90CTsw/h/gy5zFZWy9C6wYShFN DmIw==
MIME-Version: 1.0
X-Received: by 10.49.127.139 with SMTP id ng11mr55910458qeb.54.1362682261049;  Thu, 07 Mar 2013 10:51:01 -0800 (PST)
Received: by 10.49.24.130 with HTTP; Thu, 7 Mar 2013 10:51:00 -0800 (PST)
In-Reply-To: 
References:     
Date: Thu, 7 Mar 2013 12:51:00 -0600
Message-ID: 
From: Mary Barnes 
To: Eric Rescorla 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 18:51:06 -0000

On Thu, Mar 7, 2013 at 12:42 PM, Eric Rescorla  wrote:
>
> On Thu, Mar 7, 2013 at 9:56 AM, Mary Barnes 
> wrote:
>>
>> On Thu, Mar 7, 2013 at 11:43 AM, Martin Thomson
>>  wrote:
>> > Obviously I (and my employer) agree with these sentiments
>> > wholeheartedly.  Both Robin and Hadriel.
>> >
>> > That doesn't change the fact that a number of people are highly
>> > motivated to protect their investment in SDP offer/answer.  For those
>> > people, the pain that causes everyone else is clearly far less
>> > important than the pain they feel at this moment.  So here we are.
>>
>> [MB] I originally thought that either approach could work.  I did see
>> the value that folks saw in using SDP offer/answer. But after sitting
>> through the interim meeting last month, I am very much of the mindset
>> that using SDP O/A is a bad idea.   I think many of us thought that
>> using the SDP blob would help with interoperability with "legacy" SIP
>> endpoints.  I don't see that now at all.  I think we will end up with
>> a very fragile solution that will be very difficult to extend/modify
>> later if we continue down the SDP O/A path.
>> [/MB]
>>
>
> Hasn't the WG already been asked this question not once but
> twice.
[MB] Yes.  And, some of us have changed our positions based upon the
challenges that the group is facing in getting the current approach
specified and agreed.  I don't disagree that it is not a good thing
that this is being discussed yet again.  [/MB]
>
> 1. In Taipei:
> http://www.ietf.org/proceedings/82/minutes/rtcweb.txt
>
>   Cullen - we need to advise w3c on setting up a media stream.
>   - low-level API - browser implementors were not interested.
>   - mid-level - browser implements SDP negotiation
>   - high-level - browser implements a signal protocol (jingle)
>
>   Hardie - if you agree the state machine should be based on Offer/Answer,
> raise
>   your hand. Count: 31, 3 in jabber room.
>
>   If you do not agree, raise your hand.
>   Count: 4
>
>   Bernard - how can you ask this if you assume ICE, you need Offer/Answer.
>
>   Cullen - could rewrite ICE.
>
>   If there is not enough info, raise your hand
>   Count:  5
>
>   Hardie - Rough consensus in the room and jabber that we will base the
> state machine on SDP OA.
>
>
> 2. When we picked JSEP, which has SDP at its heart.
>
>
>
> And that's just the IETF WG. W3C *also* had a consensus call on
> exactly this point:
> http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0098.html.
>
> The consensus was for "Alternative 1":
>
>   1) Continue with a design based on the PeerConnection object, using SDP
>   as part of the API, roughly in the style of the current API description.
>
> This happened less than 6 months ago and it wasn't a close thing.
>
> Moreover, there are two shipping--and indeed
> interopable!--implementations (Chrome and Firefox) based on the
> PeerConnection/3264 OA design style (I'll get to Peter's comment about
> JSON in a separate message).
>
> Now, none of this is to say that the WG can't reconsider and come to a
> new decision, but I think that at given the number of times this point
> has been argued and reargued, the bar to that reconsideration has to
> be fairly high (and needs to be jointly taken in IETF and W3C)
> especially since this essentially amounts to a request to burn the
> entire W3C API and start over.
>
> -Ekr
>

From sergel@google.com  Thu Mar  7 11:19: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 57A2521F856D for ; Thu,  7 Mar 2013 11:19:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.662
X-Spam-Level: 
X-Spam-Status: No, score=-101.662 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315, 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 cTsxdNvcptoT for ; Thu,  7 Mar 2013 11:19:18 -0800 (PST)
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 CBD9921F8566 for ; Thu,  7 Mar 2013 11:19:17 -0800 (PST)
Received: by mail-ie0-f179.google.com with SMTP id k11so1040754iea.10 for ; Thu, 07 Mar 2013 11:19:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:content-type; bh=NbMRmybYkrcfnf5LY9CMkPY+iXEbiKooVbnICZg8PDw=; b=kf721RIF0HOk/GgF1mI+AeAf/6zEG+tQkSl5jE/nOHwWf5Nr4xR6oxeR/SS7+1nXXP Khmykds0LSgBF0a3RN4ST7YWa6Mii71JtCe1T7yaACcY6fTGA7EQzsLCphHSktg85x40 vcc/YZ+Np5nkBORhuqKGltOLeTdK+ycjkKBTJi41g9ZXmJPpFyG5FW57HxOM62PUlvN9 bpVbumt6lUhyZGdvt8MhKdxPP02yxRAWocZJ51crBDw1Uw4/d23EHOYGnhTpKubjSkDO 3vZyD8ZYzQjn7T4qxLqoedBpfVwMwTnweOcPRxWBhzfZhvfz+dY0Dt7p3t/jfXHhKIN1 urTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:content-type:x-gm-message-state; bh=NbMRmybYkrcfnf5LY9CMkPY+iXEbiKooVbnICZg8PDw=; b=Wv79DlP6+U8GI31iMeOsrj9xl4AoMlVcqX1LBn14NNSNu6LtukqxQfclpE2xK/1rJo L1A/lb+Qqz1LBGT4kSxYhrN+KjDpGE4HQP8yHKbrVuhTeXsMD4pvv/5r5JyPdBYHoHX1 1ElEC0kZ+kNgMWGxg34rNg/1WY1pqTFcq6cdnX9z45h5giEIUndszTVVmmwOK9YnrsOE mkT1RTMJKSZ+hnNM3qDaFKjLRxpPaaAMJrWLcqe5D21o09EQUGbJHWzgCVWV86UCI/uN m7ck13NTJ1Emmk8yTgJwTn4Oh3+UWu77FmAFxXEck4qA38mTkJHujCz2ZgETngcdQST+ 6juA==
X-Received: by 10.50.170.36 with SMTP id aj4mr15205562igc.67.1362683955703; Thu, 07 Mar 2013 11:19:15 -0800 (PST)
MIME-Version: 1.0
Sender: sergel@google.com
Received: by 10.231.229.202 with HTTP; Thu, 7 Mar 2013 11:18:45 -0800 (PST)
From: Serge Lachapelle 
Date: Thu, 7 Mar 2013 20:18:45 +0100
X-Google-Sender-Auth: cU2WixX8pTnVbRrMD7xenD1704c
Message-ID: 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=e89a8f234a511f05af04d75a9570
X-Gm-Message-State: ALoCoQlBEcz69r2nASYrkck3Mp7bPEasmzEipd7VvdFUFkFOQNWXG/w+T2hZyQGuZjumIz4dcFRPcQj68FnfVWeH1ijleBnm/2uXqGm1UKE5elz1b105vYY61sQ/dfnKLRT9qwp2UW2mHTz3E02Ug2t0eQKeN/VmcpDVarJK1UdmrcV8e9zgJNzW/cyAmkSM8pdM0JvJzEIB
Subject: [rtcweb] VP8 IPR agreement announced.
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 07 Mar 2013 19:19:19 -0000

--e89a8f234a511f05af04d75a9570
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hello,

Today, Google Inc. and MPEG LA, LLC have announced that they have entered
into an agreement granting Google a license to techniques, if any, that may
be essential to VP8. Furthermore, MPEG LA has agreed to discontinue efforts
to form a patent pool around VP8.

The official press release can be found here: http://goo.gl/F7xUu

The licensors are part of the group that responded to MPEG LA=92s call for
patents. They are a group of well-known video IP holders and participants
in standards-based video patent pools.

This agreement allows for Google to sublicense the techniques to any user
of VP8, whether the VP8 implementation is by Google or another entity; this
means that users can develop independent implementations of VP8 and still
enjoy coverage under the sublicenses.

Google intends to license the techniques under terms that are in line with
the W3C=92s definition of a Royalty Free License. This definition can be
found here: http://www.w3.org/2001/07/SVG10-IPR-statements  We anticipate
having the sublicense ready in the next few weeks. The terms will appear on
the WebM Project website at http://webmproject.org

This agreement is not an acknowledgment that the licensed techniques read
on VP8. The purpose of this agreement is meant to provide further and
stronger reassurance to implementors of VP8.

On a personal note, I think you will all agree that the RTCWeb MTI video
codec discussion included many whispered doubts but little evidence. In
contrast, we have taken clear steps to demonstrate the viability of VP8:

1. Made VP8 available with a strong, simple software license and patent
grant.
2. Continued to innovate and improve VP8 in the open.
3. Licensed a royalty free VP8 enabled RTL (aka hardware source code) to
more than 50 SOCs.
4. Built, iterated and launched VP8 powered WebRTC in the Chrome browser to
hundreds of millions of users.
5. Worked to ensure WebRTC interop using the VP8 and Opus formats by
working closely with Firefox.
6. Introduced a preview of VP8 and Opus based WebRTC in Chrome for Android
beta.

And now, we have taken taken two significant steps that we hope will make
the situation clear to all:

7. Submitted VP8 to ISO SC29/WG11 (MPEG) in January of this year for
standardization.
8. Invested a significant amount of time and resources into reaching an
agreement with the MPEG LA, to provide further reassurances.

VP8 is a royalty free, open sourced codec that offers several advantages
and innovations for real time and other uses.  It has a publicly-available
specification that is getting broadly adopted in hardware; it has been
submitted for standardization to a leading standards body, and is the
subject of a royalty-free RAND license which will now include a license
covering any essential VP8 techniques that may be relevant to major IP
holders who responded to the MPEG LA's call for VP8 patents.

It is the most suitable codec for MTI.

I understand the timing is very close to the Orlando IETF meeting.  While
we tried to do this as quickly as possible, I am sure you will appreciate
the sensitivities and enormous effort involved in reaching such an
agreement.

I will be in Orlando, arriving monday evening and will be available to
answer questions.

/Serge

--e89a8f234a511f05af04d75a9570
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


Hello,

Today, Google Inc. an=
d MPEG LA, LLC have announced that they have entered into an agreement gran=
ting Google a license to techniques, if any, that may be essential to VP8. =
Furthermore, MPEG LA has agreed to discontinue efforts to form a patent poo=
l around VP8.




The official press release can be found here:=A0http://goo.gl/F7xUu

The licensors are part of the group that responded to =
MPEG LA=92s call for patents. They are a group of well-known video IP holde=
rs and participants in standards-based video patent pools.





This agreement allows for Google to sublicense the tech=
niques to any user of VP8, whether the VP8 implementation is by Google or a=
nother entity; this means that users can develop independent implementation=
s of VP8 and still enjoy coverage under the sublicenses.=A0





Google intends to license the techniques under terms th=
at are in line with the W3C=92s definition of a Royalty Free License. This =
definition can be found here: http://www.w3.org/2001/07/SVG10-IPR-stateme=
nts=A0 We anticipate having the sublicense ready in the next few weeks.=
 The terms will appear on the WebM Project website at http://webmproject.org





This agreement is not an acknowledgment that the licensed techniques read o=
n VP8. The purpose of this agreement is meant to provide further and strong=
er reassurance to implementors of VP8.=A0

On a per=
sonal note, I think you will all agree that the RTCWeb MTI video codec disc=
ussion included many whispered doubts but little evidence. In contrast, we =
have taken clear steps to demonstrate the viability of VP8:





1. Made VP8 available with a strong, simple software li=
cense and patent grant.
2. Continued to innovate and improve VP8 =
in the open.=A0
3. Licensed a royalty free VP8 enabled RTL (aka h=
ardware source code) to more than 50 SOCs.




4. Built, iterated and launched VP8 powered WebRTC in the Chrome brows=
er to hundreds of millions of users.=A0
5. Worked to ensure WebRT=
C interop using the VP8 and Opus formats by working closely with Firefox.



6. Introduced a preview of VP8 and Opus based WebRTC in Chrome for And=
roid beta.

And now, we have taken taken two signif=
icant steps that we hope will make the situation clear to all:=A0




7. Submitted VP8 to ISO SC29/WG11 (MPEG) in January of this =
year for standardization.
8. Invested a significant amount of tim=
e and resources into reaching an agreement with the MPEG LA, to provide fur=
ther reassurances.





VP8 is a royalty free, open sourced codec that offers s=
everal advantages and innovations for real time and other uses. =A0It has a=
 publicly-available specification that is getting broadly adopted in hardwa=
re; it has been submitted for standardization to a leading standards body, =
and is the subject of a royalty-free RAND license which will now include a =
license covering any essential VP8 techniques that may be relevant to major=
 IP holders who responded to the MPEG LA's call for VP8 patents.





It is the most suitable codec for MTI.

I understand the timing is very close to the Orlando IETF meeting.=
 =A0While we tried to do this as quickly as possible, I am sure you will ap=
preciate the sensitivities and enormous effort involved in reaching such an=
 agreement.





I will be in Orlando, arriving monday evening and will =
be available to answer questions.=A0

/Serge




--e89a8f234a511f05af04d75a9570--

From matthew@matthew.at  Thu Mar  7 11:33: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 0E5C921F89FD for ; Thu,  7 Mar 2013 11:33:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.114
X-Spam-Level: 
X-Spam-Status: No, score=-1.114 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WJ3aKuc1HRX for ; Thu,  7 Mar 2013 11:33:18 -0800 (PST)
Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F94721F88A2 for ; Thu,  7 Mar 2013 11:33:17 -0800 (PST)
Received: from [10.10.155.229] (unknown [10.10.155.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id AEC3A230005 for ; Thu,  7 Mar 2013 11:33:17 -0800 (PST)
Message-ID: <5138EB62.9000700@matthew.at>
Date: Thu, 07 Mar 2013 11:32:50 -0800
From: Matthew Kaufman 
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050306070908040307020008"
Subject: Re: [rtcweb] VP8 IPR agreement announced.
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 07 Mar 2013 19:33:21 -0000

This is a multi-part message in MIME format.
--------------050306070908040307020008
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

The below announcement, while an interesting development, comes weeks 
after the traditional deadlines for providing new information to the 
working group prior to an upcoming meeting and certainly does not give 
me enough time to adequately review the development. In fact, the 
sublicense terms referenced below will not be available to review until 
*after* the upcoming meeting and might very well contain language that 
is incompatible with my requirements or those of other implementers of 
RTCWEB specifications.

Therefore I believe the most sensible action is to once again delay the 
MTI video codec discussion, remove it from the agenda from the upcoming 
meeting, and have the call for an MTI codec at a later time... no sooner 
than several weeks after the relevant license terms are even available 
to review. I hope the chairs concur.

Alternatively, we can have the discussion at the upcoming meeting, but 
it will not be able to incorporate this development at all, and without 
any change in the IPR situation it was clear that H.264 was the only 
suitable alternative (and may still be the best choice, given the strong 
arguments for the technical merits and implementation advantages of 
H.264, irrespective of the IPR issues).

Matthew Kaufman

On 3/7/2013 11:18 AM, Serge Lachapelle wrote:
> Hello,
>
> Today, Google Inc. and MPEG LA, LLC have announced that they have 
> entered into an agreement granting Google a license to techniques, if 
> any, that may be essential to VP8. Furthermore, MPEG LA has agreed to 
> discontinue efforts to form a patent pool around VP8.
>
> The official press release can be found here: http://goo.gl/F7xUu
>
> The licensors are part of the group that responded to MPEG LA's call 
> for patents. They are a group of well-known video IP holders and 
> participants in standards-based video patent pools.
>
> This agreement allows for Google to sublicense the techniques to any 
> user of VP8, whether the VP8 implementation is by Google or another 
> entity; this means that users can develop independent implementations 
> of VP8 and still enjoy coverage under the sublicenses.
>
> Google intends to license the techniques under terms that are in line 
> with the W3C's definition of a Royalty Free License. This definition 
> can be found here: http://www.w3.org/2001/07/SVG10-IPR-statements We 
> anticipate having the sublicense ready in the next few weeks. The 
> terms will appear on the WebM Project website at http://webmproject.org
>
> This agreement is not an acknowledgment that the licensed techniques 
> read on VP8. The purpose of this agreement is meant to provide further 
> and stronger reassurance to implementors of VP8.
>
> On a personal note, I think you will all agree that the RTCWeb MTI 
> video codec discussion included many whispered doubts but little 
> evidence. In contrast, we have taken clear steps to demonstrate the 
> viability of VP8:
>
> 1. Made VP8 available with a strong, simple software license and 
> patent grant.
> 2. Continued to innovate and improve VP8 in the open.
> 3. Licensed a royalty free VP8 enabled RTL (aka hardware source code) 
> to more than 50 SOCs.
> 4. Built, iterated and launched VP8 powered WebRTC in the Chrome 
> browser to hundreds of millions of users.
> 5. Worked to ensure WebRTC interop using the VP8 and Opus formats by 
> working closely with Firefox.
> 6. Introduced a preview of VP8 and Opus based WebRTC in Chrome for 
> Android beta.
>
> And now, we have taken taken two significant steps that we hope will 
> make the situation clear to all:
>
> 7. Submitted VP8 to ISO SC29/WG11 (MPEG) in January of this year for 
> standardization.
> 8. Invested a significant amount of time and resources into reaching 
> an agreement with the MPEG LA, to provide further reassurances.
>
> VP8 is a royalty free, open sourced codec that offers several 
> advantages and innovations for real time and other uses.  It has a 
> publicly-available specification that is getting broadly adopted in 
> hardware; it has been submitted for standardization to a leading 
> standards body, and is the subject of a royalty-free RAND license 
> which will now include a license covering any essential VP8 techniques 
> that may be relevant to major IP holders who responded to the MPEG 
> LA's call for VP8 patents.
>
> It is the most suitable codec for MTI.
>
> I understand the timing is very close to the Orlando IETF meeting. 
>  While we tried to do this as quickly as possible, I am sure you will 
> appreciate the sensitivities and enormous effort involved in reaching 
> such an agreement.
>
> I will be in Orlando, arriving monday evening and will be available to 
> answer questions.
>
> /Serge
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--------------050306070908040307020008
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

      
      
      
      
      
      
      
      
      
      The below announcement, while an interesting development,
      comes weeks after the traditional deadlines for providing new
      information to the working group prior to an upcoming meeting and
      certainly does not give me enough time to adequately review the
      development. In fact, the sublicense terms referenced below will
      not be available to review until *after* the upcoming meeting and
      might very well contain language that is incompatible with my
      requirements or those of other implementers of RTCWEB
      specifications.

      

      Therefore I believe the most sensible action is to once again
      delay the MTI video codec discussion, remove it from the agenda
      from the upcoming meeting, and have the call for an MTI codec at a
      later time… no sooner than several weeks after the relevant
      license terms are even available to review. I hope the chairs
      concur.

      

      Alternatively, we can have the discussion at the upcoming meeting,
      but it will not be able to incorporate this development at all,
      and without any change in the IPR situation it was clear that
      H.264 was the only suitable alternative (and may still be the best
      choice, given the strong arguments for the technical merits and
      implementation advantages of H.264, irrespective of the IPR
      issues).

          

      Matthew Kaufman

      

      On 3/7/2013 11:18 AM, Serge Lachapelle wrote:

    

    

      

        
Hello,

        


        

        
Today, Google Inc. and MPEG LA, LLC have announced that
          they have entered into an agreement granting Google a license
          to techniques, if any, that may be essential to VP8.
          Furthermore, MPEG LA has agreed to discontinue efforts to form
          a patent pool around VP8.

        


        

        
The official press release can be found here: http://goo.gl/F7xUu

        

        


        

        
The licensors are part of the group that responded to MPEG
          LA’s call for patents. They are a group of well-known video IP
          holders and participants in standards-based video patent
          pools.

        


        

        
This agreement allows for Google to sublicense the
          techniques to any user of VP8, whether the VP8 implementation
          is by Google or another entity; this means that users can
          develop independent implementations of VP8 and still enjoy
          coverage under the sublicenses. 

        


        

        
Google intends to license the techniques under terms that
          are in line with the W3C’s definition of a Royalty Free
          License. This definition can be found here: http://www.w3.org/2001/07/SVG10-IPR-statements 
          We anticipate having the sublicense ready in the next few
          weeks. The terms will appear on the WebM Project website at http://webmproject.org

        


        

        

          This agreement is not an acknowledgment that the licensed
          techniques read on VP8. The purpose of this agreement is meant
          to provide further and stronger reassurance to implementors of
          VP8. 

        


        

        
On a personal note, I think you will all agree that the
          RTCWeb MTI video codec discussion included many whispered
          doubts but little evidence. In contrast, we have taken clear
          steps to demonstrate the viability of VP8:

        


        

        
1. Made VP8 available with a strong, simple software
          license and patent grant.

        
2. Continued to innovate and improve VP8 in the open. 

        
3. Licensed a royalty free VP8 enabled RTL (aka hardware
          source code) to more than 50 SOCs.

        
4. Built, iterated and launched VP8 powered WebRTC in the
          Chrome browser to hundreds of millions of users. 

        
5. Worked to ensure WebRTC interop using the VP8 and Opus
          formats by working closely with Firefox.

        
6. Introduced a preview of VP8 and Opus based WebRTC in
          Chrome for Android beta.

        


        

        
And now, we have taken taken two significant steps that we
          hope will make the situation clear to all: 

        

          

        

        
7. Submitted VP8 to ISO SC29/WG11 (MPEG) in January of this
          year for standardization.

        
8. Invested a significant amount of time and resources into
          reaching an agreement with the MPEG LA, to provide further
          reassurances.

        


        

        
VP8 is a royalty free, open sourced codec that offers
          several advantages and innovations for real time and other
          uses.  It has a publicly-available specification that is
          getting broadly adopted in hardware; it has been submitted for
          standardization to a leading standards body, and is the
          subject of a royalty-free RAND license which will now include
          a license covering any essential VP8 techniques that may be
          relevant to major IP holders who responded to the MPEG LA's
          call for VP8 patents.

        


        

        
It is the most suitable codec for MTI.

        


        

        
I understand the timing is very close to the Orlando IETF
          meeting.  While we tried to do this as quickly as possible, I
          am sure you will appreciate the sensitivities and enormous
          effort involved in reaching such an agreement.

        


        

        
I will be in Orlando, arriving monday evening and will be
          available to answer questions. 

        


        

        
/Serge

      

      

      

      

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


    

    

  


--------------050306070908040307020008--

From elagerway@gmail.com  Thu Mar  7 11:43: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 2467421F8B1C for ; Thu,  7 Mar 2013 11:43:47 -0800 (PST)
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 F+ZXp4YayKdR for ; Thu,  7 Mar 2013 11:43:45 -0800 (PST)
Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9A05A21F8AB8 for ; Thu,  7 Mar 2013 11:43:44 -0800 (PST)
Received: by mail-wg0-f49.google.com with SMTP id 15so1531669wgd.4 for ; Thu, 07 Mar 2013 11:43:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ku/J2Fq2G7BykBP2DPQB6GxkCu4GxutoqempZP6bIxA=; b=U3DvoeYeh9gnmCP3WNDuHEkgNaLSfqH7BNq9z7wfFhWUX6sanUWCIQkBoVw+kNYAsn w1J+RAaAGSnjPdw9UQRQmHTsVnqY/jn31+U+RYCj3tD9BhNI1zUM7ngpiDgNsSDs6SK3 aLrCf33+xBVDMYjMGfVRY5iE+LWnApqNf2SToqQnhoG84tVrdY/f5fbo+uU0lIHdP2uv kJovw46mjjsWksGQNapEn4Yd+EUvyY5FEEk1G1cFxnYv711ZqSjuba7jgf53tYjYAqqT YvlqHYx4rDM3QqC+4KN48OZXVegDhdJjFRsW7lNc0xjMCQhXVZrqODNm0GItEgcbixCe fUbQ==
MIME-Version: 1.0
X-Received: by 10.180.24.229 with SMTP id x5mr36010683wif.17.1362685423761; Thu, 07 Mar 2013 11:43:43 -0800 (PST)
Sender: elagerway@gmail.com
Received: by 10.216.206.65 with HTTP; Thu, 7 Mar 2013 11:43:43 -0800 (PST)
In-Reply-To: 
References:      
Date: Thu, 7 Mar 2013 11:43:43 -0800
X-Google-Sender-Auth: 1tnlu_7tmoxP3HULJmcPUP17Kz0
Message-ID: 
From: Erik Lagerway 
To: Mary Barnes 
Content-Type: multipart/alternative; boundary=f46d0421848d9fc1b604d75aecc3
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 19:43:47 -0000

--f46d0421848d9fc1b604d75aecc3
Content-Type: text/plain; charset=ISO-8859-1

+1

We feel that a lower level API that does not include SDP, and a layer built
on top (perhaps in a JS library) to manage SDP + offer/answer would solve
this issue for everyone. That would ensure legacy compatibility and give us
future stuff we would know we are going to need.

http://lists.w3.org/Archives/Public/public-webrtc/2012Feb/0198.html <- btw,
this went nowhere in the W3C so it seems the buck stops here

/erik

*Erik Lagerway  |
*Hookflash
* | 1 (855) Hookflash ext. 2 | Twitter  | WebRTC
Blog  *
****


On Thu, Mar 7, 2013 at 10:51 AM, Mary Barnes wrote:

> On Thu, Mar 7, 2013 at 12:42 PM, Eric Rescorla  wrote:
> >
> > On Thu, Mar 7, 2013 at 9:56 AM, Mary Barnes 
> > wrote:
> >>
> >> On Thu, Mar 7, 2013 at 11:43 AM, Martin Thomson
> >>  wrote:
> >> > Obviously I (and my employer) agree with these sentiments
> >> > wholeheartedly.  Both Robin and Hadriel.
> >> >
> >> > That doesn't change the fact that a number of people are highly
> >> > motivated to protect their investment in SDP offer/answer.  For those
> >> > people, the pain that causes everyone else is clearly far less
> >> > important than the pain they feel at this moment.  So here we are.
> >>
> >> [MB] I originally thought that either approach could work.  I did see
> >> the value that folks saw in using SDP offer/answer. But after sitting
> >> through the interim meeting last month, I am very much of the mindset
> >> that using SDP O/A is a bad idea.   I think many of us thought that
> >> using the SDP blob would help with interoperability with "legacy" SIP
> >> endpoints.  I don't see that now at all.  I think we will end up with
> >> a very fragile solution that will be very difficult to extend/modify
> >> later if we continue down the SDP O/A path.
> >> [/MB]
> >>
> >
> > Hasn't the WG already been asked this question not once but
> > twice.
> [MB] Yes.  And, some of us have changed our positions based upon the
> challenges that the group is facing in getting the current approach
> specified and agreed.  I don't disagree that it is not a good thing
> that this is being discussed yet again.  [/MB]
> >
> > 1. In Taipei:
> > http://www.ietf.org/proceedings/82/minutes/rtcweb.txt
> >
> >   Cullen - we need to advise w3c on setting up a media stream.
> >   - low-level API - browser implementors were not interested.
> >   - mid-level - browser implements SDP negotiation
> >   - high-level - browser implements a signal protocol (jingle)
> >
> >   Hardie - if you agree the state machine should be based on
> Offer/Answer,
> > raise
> >   your hand. Count: 31, 3 in jabber room.
> >
> >   If you do not agree, raise your hand.
> >   Count: 4
> >
> >   Bernard - how can you ask this if you assume ICE, you need
> Offer/Answer.
> >
> >   Cullen - could rewrite ICE.
> >
> >   If there is not enough info, raise your hand
> >   Count:  5
> >
> >   Hardie - Rough consensus in the room and jabber that we will base the
> > state machine on SDP OA.
> >
> >
> > 2. When we picked JSEP, which has SDP at its heart.
> >
> >
> >
> > And that's just the IETF WG. W3C *also* had a consensus call on
> > exactly this point:
> > http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0098.html.
> >
> > The consensus was for "Alternative 1":
> >
> >   1) Continue with a design based on the PeerConnection object, using SDP
> >   as part of the API, roughly in the style of the current API
> description.
> >
> > This happened less than 6 months ago and it wasn't a close thing.
> >
> > Moreover, there are two shipping--and indeed
> > interopable!--implementations (Chrome and Firefox) based on the
> > PeerConnection/3264 OA design style (I'll get to Peter's comment about
> > JSON in a separate message).
> >
> > Now, none of this is to say that the WG can't reconsider and come to a
> > new decision, but I think that at given the number of times this point
> > has been argued and reargued, the bar to that reconsideration has to
> > be fairly high (and needs to be jointly taken in IETF and W3C)
> > especially since this essentially amounts to a request to burn the
> > entire W3C API and start over.
> >
> > -Ekr
> >
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--f46d0421848d9fc1b604d75aecc3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


+1=A0

We feel that a lower level API tha=
t does not include SDP, and a layer built on top (perhaps in a JS library) =
to manage SDP + offer/answer would solve this issue for everyone. That woul=
d ensure legacy compatibility and give us future stuff we would know we are=
 going to need.



http://lists.w3.org/Archives/Pub=
lic/public-webrtc/2012Feb/0198.html=A0<- btw, this went nowhere in t=
he W3C so it seems the buck stops here



/erik

=
Erik Lagerway=
 | =
<=
font color=3D"#943634">Hookflash=
 | 1 (855) Hookflash ext. 2 | Twitter | WebRTC Blog 

<=
/span>




On Thu, Mar 7, 2013 at 10:51 AM, Mary Ba=
rnes <mary.ietf.barnes@gmail.com> wrote:


On Thu, Mar 7, 2013 at 12:42 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>

> On Thu, Mar 7, 2013 at 9:56 AM, Mary Barnes <mary.ietf.barnes@gmail.com>

> wrote:

>>

>> On Thu, Mar 7, 2013 at 11:43 AM, Martin Thomson

>> <martin.thomson@gma=
il.com> wrote:

>> > Obviously I (and my employer) agree with these sentiments

>> > wholeheartedly. =A0Both Robin and Hadriel.

>> >

>> > That doesn't change the fact that a number of people are =
highly

>> > motivated to protect their investment in SDP offer/answer. =
=A0For those

>> > people, the pain that causes everyone else is clearly far les=
s

>> > important than the pain they feel at this moment. =A0So here =
we are.

>>

>> [MB] I originally thought that either approach could work. =A0I di=
d see

>> the value that folks saw in using SDP offer/answer. But after sitt=
ing

>> through the interim meeting last month, I am very much of the mind=
set

>> that using SDP O/A is a bad idea. =A0 I think many of us thought t=
hat

>> using the SDP blob would help with interoperability with "leg=
acy" SIP

>> endpoints. =A0I don't see that now at all. =A0I think we will =
end up with

>> a very fragile solution that will be very difficult to extend/modi=
fy

>> later if we continue down the SDP O/A path.

>> [/MB]

>>

>

> Hasn't the WG already been asked this question not once but

> twice.


[MB] Yes. =A0And, some of us have changed our positions based upon th=
e

challenges that the group is facing in getting the current approach

specified and agreed. =A0I don't disagree that it is not a good thing
that this is being discussed yet again. =A0[/MB]


>

> 1. In Taipei:

> http://www.ietf.org/proceedings/82/minutes/rtcweb.txt

>

> =A0 Cullen - we need to advise w3c on setting up a media stream.

> =A0 - low-level API - browser implementors were not interested.

> =A0 - mid-level - browser implements SDP negotiation

> =A0 - high-level - browser implements a signal protocol (jingle)

>

> =A0 Hardie - if you agree the state machine should be based on Offer/A=
nswer,

> raise

> =A0 your hand. Count: 31, 3 in jabber room.

>

> =A0 If you do not agree, raise your hand.

> =A0 Count: 4

>

> =A0 Bernard - how can you ask this if you assume ICE, you need Offer/A=
nswer.

>

> =A0 Cullen - could rewrite ICE.

>

> =A0 If there is not enough info, raise your hand

> =A0 Count: =A05

>

> =A0 Hardie - Rough consensus in the room and jabber that we will base =
the

> state machine on SDP OA.

>

>

> 2. When we picked JSEP, which has SDP at its heart.

>

>

>

> And that's just the IETF WG. W3C *also* had a consensus call on
> exactly this point:

> http://lists.w3.org/Archives/Public/public-webr=
tc/2012Sep/0098.html.

>

> The consensus was for "Alternative 1":

>

> =A0 1) Continue with a design based on the PeerConnection object, usin=
g SDP

> =A0 as part of the API, roughly in the style of the current API descri=
ption.

>

> This happened less than 6 months ago and it wasn't a close thing.<=
br>
>

> Moreover, there are two shipping--and indeed

> interopable!--implementations (Chrome and Firefox) based on the

> PeerConnection/3264 OA design style (I'll get to Peter's comme=
nt about

> JSON in a separate message).

>

> Now, none of this is to say that the WG can't reconsider and come =
to a

> new decision, but I think that at given the number of times this point=


> has been argued and reargued, the bar to that reconsideration has to
> be fairly high (and needs to be jointly taken in IETF and W3C)

> especially since this essentially amounts to a request to burn the

> entire W3C API and start over.

>

> -Ekr

>


_______________________=
________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--f46d0421848d9fc1b604d75aecc3--

From martin.thomson@gmail.com  Thu Mar  7 12:00: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 76E0021F8C7C for ; Thu,  7 Mar 2013 12:00:49 -0800 (PST)
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, 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 BSrONnxc1aow for ; Thu,  7 Mar 2013 12:00:48 -0800 (PST)
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 A843821F8C2C for ; Thu,  7 Mar 2013 12:00:26 -0800 (PST)
Received: by mail-wg0-f41.google.com with SMTP id ds1so7393329wgb.0 for ; Thu, 07 Mar 2013 12:00:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BosxONkfJUAMyC0vBKgJ4MAGeMH+scmqKCIjsnG1ooI=; b=z0A3PB9f4WRtI18t8BdqM9+DbvAsI2R7wDr/AAabEiiw8WZ5AkuGseZsiPf4Fp8giT o8pE99xXFK44oqodzFjxa3K2HLJJ4JH4OYILM5yyx9KRxhtZ/EycXmmO1LIw0BUeyw3P sQNCIQxAyHA6AMbZlDRVPUcckm7jh3TMbVKP6++h5fFVknsrf7c3E0LIUmkV32pFde79 MgWeHU6hrLqPmYEeWWQSYH1Bn7WhzjA8yKGLr9gcFTBcHBjoFG6/uSsIe0g27H/HfS3+ lg8R35Q52CPwToQUenMOh/vZE5ArcfgdIqRN7S5KjJNcFJCSI+skUAadeCH9uBzKEVsm hv/Q==
MIME-Version: 1.0
X-Received: by 10.194.76.37 with SMTP id h5mr57706779wjw.21.1362686425035; Thu, 07 Mar 2013 12:00:25 -0800 (PST)
Received: by 10.194.5.135 with HTTP; Thu, 7 Mar 2013 12:00:24 -0800 (PST)
In-Reply-To: <5137333C.2000602@alvestrand.no>
References: <39821B4C400EC14DAD4DB25330A9271A01929A@FR711WXCHMBA03.zeu.alcatel-lucent.com> <5137333C.2000602@alvestrand.no>
Date: Thu, 7 Mar 2013 12:00:24 -0800
Message-ID: 
From: Martin Thomson 
To: Harald Alvestrand 
Content-Type: text/plain; charset=UTF-8
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Data channel setup: scalability, user experience, labels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 07 Mar 2013 20:00:51 -0000

On 6 March 2013 04:14, Harald Alvestrand  wrote:
> Exercise for the reader: Write an application that uses multiple data
> channels, and does not force channel numbers. Try it with and without
> labels.

Yes, it's a problem.  Of course, labels are just one possible solution
to that problem.  Exposing stream ID (i.e., channel.id) achieves the
same end.  So does strict ordering.  So does in-band application
messages.

From jmvalin@mozilla.com  Thu Mar  7 12:55: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 EBF2121F8581 for ; Thu,  7 Mar 2013 12:55:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.762
X-Spam-Level: 
X-Spam-Status: No, score=-1.762 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id df-PR97ZAyiE for ; Thu,  7 Mar 2013 12:55:21 -0800 (PST)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id F292B21F853D for ; Thu,  7 Mar 2013 12:55:20 -0800 (PST)
Received: from [192.168.1.15] (modemcable094.20-21-96.mc.videotron.ca [96.21.20.94]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 00513F2356;  Thu,  7 Mar 2013 12:55:19 -0800 (PST)
Message-ID: <5138FEB7.3060807@mozilla.com>
Date: Thu, 07 Mar 2013 15:55:19 -0500
From: Jean-Marc Valin 
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Matthew Kaufman 
References:  <5138EB62.9000700@matthew.at>
In-Reply-To: <5138EB62.9000700@matthew.at>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 IPR agreement announced.
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 07 Mar 2013 20:55:22 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I would propose that we actually have the discussion in Orlando, while
assuming that the Google license will make it possible for everyone to
implement VP8 with no additional restriction (and in compliance with
the W3C's licensing policies). If it turns out that the license has
unacceptable terms (with Google not willing to fix the issue), then we
can always revisit any decision. Sounds reasonable?

	Jean-Marc

On 03/07/2013 02:32 PM, Matthew Kaufman wrote:
> The below announcement, while an interesting development, comes
> weeks after the traditional deadlines for providing new information
> to the working group prior to an upcoming meeting and certainly
> does not give me enough time to adequately review the development.
> In fact, the sublicense terms referenced below will not be
> available to review until *after* the upcoming meeting and might
> very well contain language that is incompatible with my
> requirements or those of other implementers of RTCWEB
> specifications.
> 
> Therefore I believe the most sensible action is to once again delay
> the MTI video codec discussion, remove it from the agenda from the
> upcoming meeting, and have the call for an MTI codec at a later
> time? no sooner than several weeks after the relevant license terms
> are even available to review. I hope the chairs concur.
> 
> Alternatively, we can have the discussion at the upcoming meeting,
> but it will not be able to incorporate this development at all, and
> without any change in the IPR situation it was clear that H.264 was
> the only suitable alternative (and may still be the best choice,
> given the strong arguments for the technical merits and
> implementation advantages of H.264, irrespective of the IPR
> issues).
> 
> Matthew Kaufman
> 
> On 3/7/2013 11:18 AM, Serge Lachapelle wrote:
>> Hello,
>> 
>> Today, Google Inc. and MPEG LA, LLC have announced that they
>> have entered into an agreement granting Google a license to
>> techniques, if any, that may be essential to VP8. Furthermore,
>> MPEG LA has agreed to discontinue efforts to form a patent pool
>> around VP8.
>> 
>> The official press release can be found here:
>> http://goo.gl/F7xUu
>> 
>> The licensors are part of the group that responded to MPEG LA?s
>> call for patents. They are a group of well-known video IP holders
>> and participants in standards-based video patent pools.
>> 
>> This agreement allows for Google to sublicense the techniques to
>> any user of VP8, whether the VP8 implementation is by Google or
>> another entity; this means that users can develop independent
>> implementations of VP8 and still enjoy coverage under the
>> sublicenses.
>> 
>> Google intends to license the techniques under terms that are in
>> line with the W3C?s definition of a Royalty Free License. This
>> definition can be found here:
>> http://www.w3.org/2001/07/SVG10-IPR-statements  We anticipate
>> having the sublicense ready in the next few weeks. The terms will
>> appear on the WebM Project website at http://webmproject.org
>> 
>> This agreement is not an acknowledgment that the licensed
>> techniques read on VP8. The purpose of this agreement is meant to
>> provide further and stronger reassurance to implementors of VP8.
>> 
>> 
>> On a personal note, I think you will all agree that the RTCWeb
>> MTI video codec discussion included many whispered doubts but
>> little evidence. In contrast, we have taken clear steps to
>> demonstrate the viability of VP8:
>> 
>> 1. Made VP8 available with a strong, simple software license and 
>> patent grant. 2. Continued to innovate and improve VP8 in the
>> open. 3. Licensed a royalty free VP8 enabled RTL (aka hardware
>> source code) to more than 50 SOCs. 4. Built, iterated and
>> launched VP8 powered WebRTC in the Chrome browser to hundreds of
>> millions of users. 5. Worked to ensure WebRTC interop using the
>> VP8 and Opus formats by working closely with Firefox. 6.
>> Introduced a preview of VP8 and Opus based WebRTC in Chrome for 
>> Android beta.
>> 
>> And now, we have taken taken two significant steps that we hope
>> will make the situation clear to all:
>> 
>> 7. Submitted VP8 to ISO SC29/WG11 (MPEG) in January of this year
>> for standardization. 8. Invested a significant amount of time and
>> resources into reaching an agreement with the MPEG LA, to provide
>> further reassurances.
>> 
>> VP8 is a royalty free, open sourced codec that offers several 
>> advantages and innovations for real time and other uses.  It has
>> a publicly-available specification that is getting broadly
>> adopted in hardware; it has been submitted for standardization to
>> a leading standards body, and is the subject of a royalty-free
>> RAND license which will now include a license covering any
>> essential VP8 techniques that may be relevant to major IP holders
>> who responded to the MPEG LA's call for VP8 patents.
>> 
>> It is the most suitable codec for MTI.
>> 
>> I understand the timing is very close to the Orlando IETF
>> meeting. While we tried to do this as quickly as possible, I am
>> sure you will appreciate the sensitivities and enormous effort
>> involved in reaching such an agreement.
>> 
>> I will be in Orlando, arriving monday evening and will be
>> available to answer questions.
>> 
>> /Serge
>> 
>> 
>> _______________________________________________ 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
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJROP62AAoJEJ6/8sItn9q937sH/06VBoOteO+VVbS8dk+PXE5W
oRc6KmoH0AfCFEs90FIIJHmvIur+lnenoceoFn3fCTTJcO9FyAfFuh9+XagPzETe
6DjdX42LCAsgQ+1OcVLJ5XikXGu3XGGQecJ3zGJN27wc5aochdu3+cSh6iQg8L/D
sfgKkoilPyxo/N+O+texRLi6nsx/YM/xeKR7Z5aJ5EMd8RMMZ9054Lpz6v62aLRL
+GuKGdPD95FrMTTPuCSYEx6DRdizM5wYLnknZS9RHVgkA1Da/t9qx9gxAsWfNvjN
dfESIwbA9ZipUgUeRZ4kBPqqQGaV8C2oU8rG23pBykS2h5MG5NfOz7f83Lx8Gq4=
=f7ae
-----END PGP SIGNATURE-----

From pthatcher@google.com  Thu Mar  7 12:56: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 6479C21F8AA1 for ; Thu,  7 Mar 2013 12:56:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level: 
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 jCOLWNZcJXKY for ; Thu,  7 Mar 2013 12:56:46 -0800 (PST)
Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id 9504421F8581 for ; Thu,  7 Mar 2013 12:56:46 -0800 (PST)
Received: by mail-vc0-f171.google.com with SMTP id fy7so523881vcb.2 for ; Thu, 07 Mar 2013 12:56:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=IWkTY9P8fifcZhH/yIvw7sSIadDSjoCTx+2Rlqia6q8=; b=Kh7nP+o8Sr5WC2B9I4IOFZ+bp0vI2z4PjWVSjxTwDdhewYxAp+IeXxRCNhLRxed4SG nvG2Qdcr6XCVRKupRi2/fggPC5hh/77xxASKsN+IU57947EvJvo7NhPVgjEfyuYJBznX WAk9BwMdzLZo7Fwa7m/iBgOdvZj7ejlxYswU4heAqE9YivpYH7CRcPH6fHApewjC4SFS nRRlaQVWtqKUo/nRIJO7klZYtZ6vX5i5Vlbkzr3lM1H8rACyk+uOm96KSlrQVLXgWSf7 ONveJlQ3BTO/vubTxh4StgAColkbmgbDrkJVuBBGVXf98Ckf6ax+uk3ZQSNjvpT45TZU nedQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=IWkTY9P8fifcZhH/yIvw7sSIadDSjoCTx+2Rlqia6q8=; b=pCmNU/Czob/P3zCsjOXoga/DCKtQFuKyTEOHX8xlFIKDFQnFDa0KU0sd1IA17HdVOQ hOFUdsMk8NrICqy3C7MuSqJQcQ8m8UVYD5gidOtiLSF1OqyUjU0nsAuZsfrzwsCW6lI5 bZ6/Dmenx4GjZcNvvBiUzxey9P4kDlzsfj6ZSq8QeF7sKRQDwZ85esv9p6AwEdEBlo6o PRrMcGUurWZCqmuL4vB64utLwD75cMvb60IdWle1c703EKRCozlMWQe/QHsh8qjQrCxi QWHn5vOdW+NrXAzofonevTWZ6zzR06jJV04S+sEBg9j0OmNG6sFzsHWaBbmvP0q65mRr TmNg==
X-Received: by 10.52.70.228 with SMTP id p4mr11493089vdu.89.1362689805998; Thu, 07 Mar 2013 12:56:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.49.102 with HTTP; Thu, 7 Mar 2013 12:56:05 -0800 (PST)
In-Reply-To: 
References:     
From: Peter Thatcher 
Date: Thu, 7 Mar 2013 12:56:05 -0800
Message-ID: 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
X-Gm-Message-State: ALoCoQkVoDu234bzMZI+IIf/3qbeOT5Y++5VkIYTbtpuVJi8c9k4Vgs63R40iQNi8SSknDNK+fsSvSCUo9xbPKSBiq66qoG60N1WS93J41dCpnFIj7Pb4dd42frHHedfBC+awaynmryuVkDwYI2eJYoQzvJAOiD/HNpWeEtBEFKctRjXvp9Fw9AN2cGi6CG5DRlkfEqgZl4X
Cc: "" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 20:56:47 -0000

Having a JSON-based SessionDescription that's a 1:1 mapping to SDP
semantically seems like a bad idea to me.  We want something better
than SDP, not just a different syntax for SDP.  Trying to map all of
SDP would be a near-impossible task anyway.


I think you're combining two separate questions:
a.  Should the Browser<->JS API have SessionDescriptions at all, or
should it have just low-level methods?
b.  Should the SessionDescription be representable as SDP or as
something else or both?

So far, we have two camps that combine the two questions:
Pro-SDP camp: methods=createOffer/setLocal/setRemote   and  format=SDP
Anti-SDP camp: methods=low-level methods   and   format=none

I'm suggesting that there might value in a third possibility:
Compromise: methods=createOffer/setLocal/setRemote  and  format=JSON


The Pro-SDP camp will tell the Anti-SDP camp, "don't blow up the
world".  The Anti-SDP camp will tell the Pro-SDP camp, "SDP is a
horrible API surface".  I think they are both right.   And I hope that
an alternative format for a SessionDescription would be a sufficiently
good compromise.


I don't think of it as a fork of SDP, but rather as a much better way
to describe sessions than SDP.  I've personally worked with 6
different kinds of session descriptions (SDP, Jingle, libjingle
internals, and a few different Google internal representations), and
SDP is by far the worst, not just in syntax but in semantics also.  I
think a JSON one could be much better syntax and semantics, without
quite "blowing up the world".

At least, that's my hope.













On Thu, Mar 7, 2013 at 10:45 AM, Eric Rescorla  wrote:
>
>
> On Thu, Mar 7, 2013 at 10:33 AM, Peter Thatcher 
> wrote:
>>
>> A question for all of you in the "please don't make us use SDP as an
>> API forever" crowd (and I include myself): Would it be acceptable to
>> you to have an intermediate step where we keep createOffeer,
>> setRemoteDescription and setLocalDescription as-is, but allow a JSON
>> argument?  It seems to be that such a thing could provide all the same
>> low-level of control as any other setup of methods, but may be much
>> more likely to be accepted by the group as a whole.  And, it would
>> still be a lot more pleasant for application developers, and leave
>> more flexibility for a future where low-level methods might be added.
>>
>> As both an application developer and a browser implementor, I think a
>> good SessionDescription JSON format would be easy to implement,
>> pleasant to use, a small incremental step from what we currently have,
>> and would relieve the standards body of so much fighting over what the
>> SDP should look like.
>>
>> I know it wouldn't be exactly what you're looking for, but I think it
>> would be achievable and much better than what we have.
>
>
> II don't understand how this changes anything meaningful. The point
> of using SDP isn't the crufty line-based encoding, it's being committed
> to the SDP offer/answer semantics. So, when you talk about having
> JSON, you're talking about one of two things:
>
> 1. Having a format which is semantically equivalent to SDP.
> 2. Having a format which is semantically distinct (or perhaps a superset)
> of SDP.
>
> In case 1, I don't see what this bought you, other than programming
> convenience. It's not like it would be difficult to build code to
> mechanically
> dissect the SDP encoding.
>
> In case 2, you have forked SDP, and largely obviated the point of
> using SDP in the first place.
>
> -Ekr
>
>

From silviapfeiffer1@gmail.com  Thu Mar  7 13:10: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 23A1721F8AA6 for ; Thu,  7 Mar 2013 13:10:11 -0800 (PST)
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 VibNgimhuLJ5 for ; Thu,  7 Mar 2013 13:10:10 -0800 (PST)
Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9003B21F8A6E for ; Thu,  7 Mar 2013 13:10:09 -0800 (PST)
Received: by mail-lb0-f170.google.com with SMTP id ge1so816464lbb.29 for ; Thu, 07 Mar 2013 13:10:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=PUpmwfR83dSB+dCuwa5t8mYdy0R5velRGbEohgt1T10=; b=nyLS0bbpzdmLqas+qG+IDWuFgSSJ0pH9WlWsYD1TUCvSmAGV9S2Yy8ESm1XGReqEJ5 AJxwnbNrJv7YdIjWVQ1qu4CAgDZe2evKUwdBpKxtcm11l7NjAYw5eWVlKkfZZmzJkcyQ XYfEJQXSCiFqL8OYJOsdVbOkEUX4pYJ0lWu6qhVLh0MfS7+jHKl0FQeW+HeIObjESXmp uEQ/MbCqcZNLO0Ev8QrZQ1Oih+fo1pvKWpHtQAad/LqNQMrtVKxy5IfFIvdMZUqe/kQc Ydi1dM3j9ccp9wv7DDlaam1M/9MK8TCCiR9gJyOIIkcziKTCyKlxoJBDkl3+pGgFd9y/ LUeg==
X-Received: by 10.112.9.104 with SMTP id y8mr71165lba.132.1362690608456; Thu, 07 Mar 2013 13:10:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.51.229 with HTTP; Thu, 7 Mar 2013 13:09:48 -0800 (PST)
In-Reply-To: 
References:      
From: Silvia Pfeiffer 
Date: Fri, 8 Mar 2013 08:09:48 +1100
Message-ID: 
To: Mary Barnes 
Content-Type: multipart/alternative; boundary=e0cb4efe2ee6a7f24b04d75c21f6
Cc: "" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 21:10:33 -0000

--e0cb4efe2ee6a7f24b04d75c21f6
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Mar 8, 2013 at 5:51 AM, Mary Barnes wrote:

> On Thu, Mar 7, 2013 at 12:42 PM, Eric Rescorla  wrote:
> >
> > On Thu, Mar 7, 2013 at 9:56 AM, Mary Barnes 
> > wrote:
> >>
> >> On Thu, Mar 7, 2013 at 11:43 AM, Martin Thomson
> >>  wrote:
> >> > Obviously I (and my employer) agree with these sentiments
> >> > wholeheartedly.  Both Robin and Hadriel.
> >> >
> >> > That doesn't change the fact that a number of people are highly
> >> > motivated to protect their investment in SDP offer/answer.  For those
> >> > people, the pain that causes everyone else is clearly far less
> >> > important than the pain they feel at this moment.  So here we are.
> >>
> >> [MB] I originally thought that either approach could work.  I did see
> >> the value that folks saw in using SDP offer/answer. But after sitting
> >> through the interim meeting last month, I am very much of the mindset
> >> that using SDP O/A is a bad idea.   I think many of us thought that
> >> using the SDP blob would help with interoperability with "legacy" SIP
> >> endpoints.  I don't see that now at all.  I think we will end up with
> >> a very fragile solution that will be very difficult to extend/modify
> >> later if we continue down the SDP O/A path.
> >> [/MB]
> >>
> >
> > Hasn't the WG already been asked this question not once but
> > twice.
> [MB] Yes.  And, some of us have changed our positions based upon the
> challenges that the group is facing in getting the current approach
> specified and agreed.  I don't disagree that it is not a good thing
> that this is being discussed yet again.  [/MB]
>

[Gotta love the triple negation!]

Why can't we have it both ways?

Maintain the current way to get the raw SDP using createOffer, but then
provide an interface to change that offer before setLocalDescription.

Even CISCO provides such an API:
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/sip_tn/8_5_1/4-sdp_api.html
(I think we can do a better one than this, but it's a reference point).

Cheers,
Silvia.

--e0cb4efe2ee6a7f24b04d75c21f6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 8, 2013 at 5:51 AM, Mary Barnes <mary.ietf.barnes@g=
mail.com> wrote:



On Thu, Mar 7, 2013 at 12:42 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>

> On Thu, Mar 7, 2013 at 9:56 AM, Mary Barnes <mary.ietf.barnes@gmail.com>

> wrote:

>>

>> On Thu, Mar 7, 2013 at 11:43 AM, Martin Thomson

>> <martin.thomson@gma=
il.com> wrote:

>> > Obviously I (and my employer) agree with these sentiments

>> > wholeheartedly. =A0Both Robin and Hadriel.

>> >

>> > That doesn't change the fact that a number of people are =
highly

>> > motivated to protect their investment in SDP offer/answer. =
=A0For those

>> > people, the pain that causes everyone else is clearly far les=
s

>> > important than the pain they feel at this moment. =A0So here =
we are.

>>

>> [MB] I originally thought that either approach could work. =A0I di=
d see

>> the value that folks saw in using SDP offer/answer. But after sitt=
ing

>> through the interim meeting last month, I am very much of the mind=
set

>> that using SDP O/A is a bad idea. =A0 I think many of us thought t=
hat

>> using the SDP blob would help with interoperability with "leg=
acy" SIP

>> endpoints. =A0I don't see that now at all. =A0I think we will =
end up with

>> a very fragile solution that will be very difficult to extend/modi=
fy

>> later if we continue down the SDP O/A path.

>> [/MB]

>>

>

> Hasn't the WG already been asked this question not once but

> twice.


[MB] Yes. =A0And, some of us have changed our positions based upon th=
e

challenges that the group is facing in getting the current approach

specified and agreed. =A0I don't disagree that it is not a good thing
that this is being discussed yet again. =A0[/MB]

[Gotta=
 love the triple negation!]

Why can't we have it both ways?
<=
br>Maintain the current way to get the raw SDP using createOffer, but then =
provide an interface to change that offer before setLocalDescription.



Even CISCO provides such an API: http://www.cisco.com/e=
n/US/docs/voice_ip_comm/cucm/sip_tn/8_5_1/4-sdp_api.html
(I think we=
 can do a better one than this, but it's a reference point).



Cheers,
Silvia.



--e0cb4efe2ee6a7f24b04d75c21f6--

From pthatcher@google.com  Thu Mar  7 13:12: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 11EFC21F8A6E for ; Thu,  7 Mar 2013 13:12:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.978
X-Spam-Level: 
X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 tlR6C9oNNJFt for ; Thu,  7 Mar 2013 13:12:49 -0800 (PST)
Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8F221F89DC for ; Thu,  7 Mar 2013 13:12:49 -0800 (PST)
Received: by mail-vb0-f50.google.com with SMTP id ft2so362792vbb.23 for ; Thu, 07 Mar 2013 13:12:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=hNlRNktrLghJDcMsZl290vkRRA+tMJb42vxmwc3rl6U=; b=ZMLDwUT9Y8QzvA8bAI0grhYOBINDScl+8puvzzEePyJBbK5KLRQ5Gtu0RDp4wOPWfc pBFzHXByBlqfNvUNMmz2MON8XwOr5o4RtJ7omTLNtoYC3zpQzOCtN7ozv+F2W+jW5GDs YBMk5MSolyy6zJosOWUQrT2wf2fr5oBPl8zebVpBfXd12DIGi2Dkohxs/ioFI8l4ljNc 0AgZ6+x8y/RQ6L2IsU0eNB3YweB94wsxY/HLt29VQX9Xe/v6dLkegQR7e4mBXdmqTgJA g43zzFUsO3ewDDA7kTk1uw7qKPVRJR30/zGthBNSdCVYTS0cEiR9AZ/vl7pYEVKLT2z6 bKAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=hNlRNktrLghJDcMsZl290vkRRA+tMJb42vxmwc3rl6U=; b=OnmYdgX9crm0UV6hy0AkE5E6J+x4zOPAN3khIYRptkbW5+tdnIMwL4XNOsX/Z06zLl 7VGcHL/YIB+cgirg9R11zV5ukQv3kzfC2XtwMM1rE1Jo88UvmuFk/obzu2uRWlGDFN57 tnwRZ4GkpyRTRsBsoXor83tJeVhhVHdvnvf/R/HWBDER/dngEDKJxBpU1RGuSa6crgpj 5MEBwyCiOJG+CRpgHb+olrWc8NrYPwHuMIQsba1PVEHDR7N1SZAu/whMwyGzZ7LNkoso wRsMO1p5envAWKdkuvC0gZtkUmr+o3wkxcwQeefEs3Mr31A+6uRlzXj//ojXwmy6Lvem pFCQ==
X-Received: by 10.52.19.200 with SMTP id h8mr11747337vde.60.1362690768982; Thu, 07 Mar 2013 13:12:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.49.102 with HTTP; Thu, 7 Mar 2013 13:12:08 -0800 (PST)
In-Reply-To: 
References:       
From: Peter Thatcher 
Date: Thu, 7 Mar 2013 13:12:08 -0800
Message-ID: 
To: Silvia Pfeiffer 
Content-Type: text/plain; charset=UTF-8
X-Gm-Message-State: ALoCoQnxDwebVN/rITNjI3rhh3sU2of5DGcT4RB1WPJU3hfbMXF6Wvb7KFk2gzLEJZUz2nZ1PM/G4RNBfO2J1jmJ3ijTrJjrmsrtXNBAtgYNp4JdGaoJIxscfxGhbvIDFRs8HerJail0WnR/FXZ7Mn7ZlqfFJGZte69tSNSAAPepI+RtywOS6il+MmpGGWstNyLGblp/d6kd
Cc: "" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 21:12:51 -0000

You can already do that by "munging" the SDP.  It's just not very
pleasant to do.

On Thu, Mar 7, 2013 at 1:09 PM, Silvia Pfeiffer
 wrote:
> On Fri, Mar 8, 2013 at 5:51 AM, Mary Barnes 
> wrote:
>>
>> On Thu, Mar 7, 2013 at 12:42 PM, Eric Rescorla  wrote:
>> >
>> > On Thu, Mar 7, 2013 at 9:56 AM, Mary Barnes 
>> > wrote:
>> >>
>> >> On Thu, Mar 7, 2013 at 11:43 AM, Martin Thomson
>> >>  wrote:
>> >> > Obviously I (and my employer) agree with these sentiments
>> >> > wholeheartedly.  Both Robin and Hadriel.
>> >> >
>> >> > That doesn't change the fact that a number of people are highly
>> >> > motivated to protect their investment in SDP offer/answer.  For those
>> >> > people, the pain that causes everyone else is clearly far less
>> >> > important than the pain they feel at this moment.  So here we are.
>> >>
>> >> [MB] I originally thought that either approach could work.  I did see
>> >> the value that folks saw in using SDP offer/answer. But after sitting
>> >> through the interim meeting last month, I am very much of the mindset
>> >> that using SDP O/A is a bad idea.   I think many of us thought that
>> >> using the SDP blob would help with interoperability with "legacy" SIP
>> >> endpoints.  I don't see that now at all.  I think we will end up with
>> >> a very fragile solution that will be very difficult to extend/modify
>> >> later if we continue down the SDP O/A path.
>> >> [/MB]
>> >>
>> >
>> > Hasn't the WG already been asked this question not once but
>> > twice.
>> [MB] Yes.  And, some of us have changed our positions based upon the
>> challenges that the group is facing in getting the current approach
>> specified and agreed.  I don't disagree that it is not a good thing
>> that this is being discussed yet again.  [/MB]
>
>
> [Gotta love the triple negation!]
>
> Why can't we have it both ways?
>
> Maintain the current way to get the raw SDP using createOffer, but then
> provide an interface to change that offer before setLocalDescription.
>
> Even CISCO provides such an API:
> http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/sip_tn/8_5_1/4-sdp_api.html
> (I think we can do a better one than this, but it's a reference point).
>
> Cheers,
> Silvia.
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

From ibc@aliax.net  Thu Mar  7 13:15: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 58ABC21F8AA6 for ; Thu,  7 Mar 2013 13:15:21 -0800 (PST)
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 s1QP65elgeVc for ; Thu,  7 Mar 2013 13:15:18 -0800 (PST)
Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id BC6D021F8B1C for ; Thu,  7 Mar 2013 13:15:08 -0800 (PST)
Received: by mail-qa0-f50.google.com with SMTP id dx4so600654qab.9 for ; Thu, 07 Mar 2013 13:15:08 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=HSoee3kwArAhhCwIHgjlVtj+lKi1vBB1yX6wCcPqB5o=; b=aAwb7Mbhhk5ly2FXuyOFzaAtOMRcqLT2b7CFAdPt1Tk1RUliXf7Z/q2BrdiAjonvxg c+3rcaeLAqmRaTlLoVmALPb9Unbcbz/NFh74Mt4jcFHvc0p4qeVCqVkoYW/Mnr4luHVU zV9E4r2HoPmaAXk6x+L0F1FLqANA+XppEmSiF8UTy0sb05dqiGW4S17osGFNrMjujVgS jmQs6Pv7wgIO5nm3kJCO65H+C2kT1OGLIk4UF7oKI2fOTcZceGLATcQN8zsUGi03QVaT +yd7MEg+X47WiGrvPUFDHl6+C7qRSZKuTUMjDdPUDIeUtBS0JGH3dpq5FTMdQeBI1pUI Ll6A==
X-Received: by 10.229.201.137 with SMTP id fa9mr11142823qcb.18.1362690908472;  Thu, 07 Mar 2013 13:15:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.49.12.233 with HTTP; Thu, 7 Mar 2013 13:14:48 -0800 (PST)
In-Reply-To: 
References:      
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 7 Mar 2013 22:14:48 +0100
Message-ID: 
To: Peter Thatcher 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmfXd08vPSgoy5geAHZ7WsXtBPguxS9qDFtskN4Yr5RPemktjIy9NmnuA0mJ6Z6gEBSxl/i
Cc: "" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 21:15:21 -0000

2013/3/7 Peter Thatcher :
> Having a JSON-based SessionDescription that's a 1:1 mapping to SDP
> semantically seems like a bad idea to me.  We want something better
> than SDP, not just a different syntax for SDP.  Trying to map all of
> SDP would be a near-impossible task anyway.

An SDP is so "flexible" that it can include:

- multiple m video lines.
- with multiple SSRC each one.
- may be bundle for audio and video.
- may be separate ICE candidates for audio and each different "m" video.
- and so on. Too much "flexibility".

It's more than difficut to expect that a JS custom code can consider
all those possibilities. That's IMHO the main problem of SDP and not
so much the SDP format itself (which can be managed via a good JS
API).

And the worst of SDP IMGO: having to send the *entire* SDP when any
minimal change is done, so the receive must do magic to realize of the
exact change without "resetting" all.


--=20
I=C3=B1aki Baz Castillo


From ibc@aliax.net  Thu Mar  7 13:17: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 159A221F8C06 for ; Thu,  7 Mar 2013 13:17:32 -0800 (PST)
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 MAcAltCLG7Ga for ; Thu,  7 Mar 2013 13:17:31 -0800 (PST)
Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id 5B97121F8B1C for ; Thu,  7 Mar 2013 13:17:31 -0800 (PST)
Received: by mail-qe0-f52.google.com with SMTP id s14so591420qeb.11 for ; Thu, 07 Mar 2013 13:17:30 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=ITP34KVsPH7AE47QqBZF0cYRFUHt+aRgY9Ut32Oqb0s=; b=WNJv0bJtXV36Q96s+sK9xyPh5EZKbRH/cxb6Sb74rwPlh8Oo1od8YyLl+Iisgsf7Zx mIqkB6rLTNGelDQsSpCOX1yrXHGHlz2thQaVx/CkhmgceQQ2YhE/is/oLcp5rzUsB/Gt 4zpF4y+4ttreHzVGVx0uU8OpuO34nIzOqZOWO5f9hEHoCequvSDNTc0q4/fedkWfA7oQ Y1PaAMuCcPmh4XJF0VMxRafnW7vHetPxiovLJYEoCsfXwaQ+HEp+mSsTK8DwN0ofk4ZM 277sZvmkkhGM8O7Pp4ZGvGbM4vvZBz+rj/LVEGegRtI2iF7TkjQ+8XFPNbZfflxv1hT1 JT+A==
X-Received: by 10.224.33.140 with SMTP id h12mr381649qad.73.1362691050770; Thu, 07 Mar 2013 13:17:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.49.12.233 with HTTP; Thu, 7 Mar 2013 13:17:10 -0800 (PST)
In-Reply-To: 
References:      
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 7 Mar 2013 22:17:10 +0100
Message-ID: 
To: Peter Thatcher 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQl1kngEWHUTPlgNw61JGzgZpYmk2dxtGCSTJc9MUipyL8Fqvyph1nxhK/EGPaeWwTWrb2Y4
Cc: "" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 21:17:32 -0000

2013/3/7 Peter Thatcher :
> Anti-SDP camp: methods=3Dlow-level methods   and   format=3Dnone

What does "format=3Dnone" mean? There should be some kind of "format" to
tell the remote peer our video codec preferences, ICE candidates and
so, am I right? This is not about passing a URL to the remote.

That's exactly what SDP attempts to achieve but SDP is too flexible
and unmanageable.


--=20
I=C3=B1aki Baz Castillo


From pthatcher@google.com  Thu Mar  7 13:17: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 D67A921F8C20 for ; Thu,  7 Mar 2013 13:17:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.827
X-Spam-Level: 
X-Spam-Status: No, score=-102.827 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, 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 2jLuM+YaUUZ1 for ; Thu,  7 Mar 2013 13:17:56 -0800 (PST)
Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4800221F8B1C for ; Thu,  7 Mar 2013 13:17:55 -0800 (PST)
Received: by mail-vc0-f178.google.com with SMTP id m8so535028vcd.37 for ; Thu, 07 Mar 2013 13:17:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=R5iEo9j8wOUdf4ZL3X29siDb4wRr0m7BC38DFetsyp4=; b=a7BXynMk+lwWUt+FIi2Je4LCqRhKanXXG5vmJ2x3Sl8j2hHiD93dvfFjh01o+4yoDO rYvKaR1sjHTx9Swprwrbod2DAiQTNVtql3dCasCCd8xwHRk6BIuzQnarCDK1GBBx8UKn bo8dYyFbLwTsxazWbr1jAybTXrKecaokcuTndg0suDtwPMhK+TghjfwXTkGbJwGeLiPU sJRlnICNIQRYoCWVXHZx6BpS/P3RSMWqoCmQfdaiUwbEU/Uz12T0Mtk00f2Wyd0YSvwb GNCLC70VPGqc7d0MJpAqIsivbu2tx/J/ImPemDO+gn1bkuDtulorywrwIGa+yQJXK7Rj 77PQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=R5iEo9j8wOUdf4ZL3X29siDb4wRr0m7BC38DFetsyp4=; b=ForvTsE7uQ9lKivERQcJSeng41pZAjz+IHR50VslGWP79fLmY4ESyYfBjjIrtSEDaU bBK1bR70Lqgc2ILj9U7kmO4vbprzYcS70dLNMFeEKFiAadUgWvQL/TeJRCPUFSFvSVAK 0EHM64yMByLeG/RBeJaR1e5XsTXxzRx1X+nyLKf9D+o8qxBHfBzWB1EYvMeVNK7/fpOU 939hoexahOMg9pybNuXjppwJNyokC+mJFeaCVbH7UItYDJVg7fHHdl4MGuvaSE3pXQ5H fveoPacHJx/guKBtq+OvM6j/GIYllvC49MBwW5NSfb74AO+j6fDkePBEcNR4HVXhIDKz kZ3w==
X-Received: by 10.58.137.34 with SMTP id qf2mr13907747veb.25.1362691075413; Thu, 07 Mar 2013 13:17:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.49.102 with HTTP; Thu, 7 Mar 2013 13:17:15 -0800 (PST)
In-Reply-To: 
References:       
From: Peter Thatcher 
Date: Thu, 7 Mar 2013 13:17:15 -0800
Message-ID: 
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlHPX1rx2DU73joQhZSViK10ZiRQlt6xQGhC27BberOXtGoWYL6MQ9+h0UhK5gj82Cp8/ZtNdnz50T7TCKFrIFe9jYEWFWFKLvThQAJ59xoKUGsST1dkzowhRKrl4VCMjmJo3OvnuWOp64CiKQECxPeyMiONiyhUIh1K5PcHFyVCRAiD9sIMpy5XNt5YMub51FvrLCx
Cc: "" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 21:17:57 -0000

That's a very good point.  I think any replacement SessionDescription
ought to have a clear "update" mechanism built in.

On Thu, Mar 7, 2013 at 1:14 PM, I=C3=B1aki Baz Castillo  wro=
te:
> 2013/3/7 Peter Thatcher :
>> Having a JSON-based SessionDescription that's a 1:1 mapping to SDP
>> semantically seems like a bad idea to me.  We want something better
>> than SDP, not just a different syntax for SDP.  Trying to map all of
>> SDP would be a near-impossible task anyway.
>
> An SDP is so "flexible" that it can include:
>
> - multiple m video lines.
> - with multiple SSRC each one.
> - may be bundle for audio and video.
> - may be separate ICE candidates for audio and each different "m" video.
> - and so on. Too much "flexibility".
>
> It's more than difficut to expect that a JS custom code can consider
> all those possibilities. That's IMHO the main problem of SDP and not
> so much the SDP format itself (which can be managed via a good JS
> API).
>
> And the worst of SDP IMGO: having to send the *entire* SDP when any
> minimal change is done, so the receive must do magic to realize of the
> exact change without "resetting" all.
>
>
> --
> I=C3=B1aki Baz Castillo
> 

From silviapfeiffer1@gmail.com  Thu Mar  7 13:23: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 3406421F8B1C for ; Thu,  7 Mar 2013 13:23:11 -0800 (PST)
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 T11qIsRuVozr for ; Thu,  7 Mar 2013 13:23:10 -0800 (PST)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 35B3521F8AAC for ; Thu,  7 Mar 2013 13:23:03 -0800 (PST)
Received: by mail-la0-f52.google.com with SMTP id fs12so995876lab.25 for ; Thu, 07 Mar 2013 13:23:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=0LbFo+R503ZGy7+1ZEr7sXTc+mp8j8IhLwBwc5A8fRg=; b=v3XkvRItrjYBR8uSgLEyP12J3hVrXR78fmCz9V4ioxZLgz1wNT/uaH/gdyZMb9LM5T oQ0EkTBKCwOc40JHGrRIuaad+XWwcnDuitm9vnDhNzao0pOi4eaLpKgv9auq7QTu6wRP Rr0LBlA/ONB1fNYBNTmTGG57wmLHTsLi+dNX5lXrZmqdE/eLbgX2Zkx+mfwej3t+V//+ Qy+wfJ8PNZEzwfjhsHYvdbLhFSgrMEX18H5zYQbpsaS47dTEQa3Uy1L6daZtDUGSXWXB eJGtuJM3x0OegTcevL3MnAiVsZQg7Xn72k7YQsxmi2Adyr6h2ryTaMd4cI2eeS5RUxiI htpw==
X-Received: by 10.152.46.17 with SMTP id r17mr30191921lam.47.1362691382543; Thu, 07 Mar 2013 13:23:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.51.229 with HTTP; Thu, 7 Mar 2013 13:22:42 -0800 (PST)
In-Reply-To: 
References:        
From: Silvia Pfeiffer 
Date: Fri, 8 Mar 2013 08:22:42 +1100
Message-ID: 
To: Peter Thatcher 
Content-Type: multipart/alternative; boundary=bcaec5524106cb8ba704d75c4f6c
Cc: "" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 21:23:11 -0000

--bcaec5524106cb8ba704d75c4f6c
Content-Type: text/plain; charset=ISO-8859-1

Agreed, but it's also not sufficient. SDP is not "programmer friendly"
enough because it has too many details that are protocol-details only and
it's too hard to see the semantic bits in SDP and ignore the rest.

For example: the programmer wants to say - I want to get this video
resolution, this audio bitrate & channels, I want to use this camera and
this microphone for this call. Having to manipulate SDP directly for this
is a programmer's nightmare.

Silvia.

On Fri, Mar 8, 2013 at 8:12 AM, Peter Thatcher  wrote:

> You can already do that by "munging" the SDP.  It's just not very
> pleasant to do.
>
> On Thu, Mar 7, 2013 at 1:09 PM, Silvia Pfeiffer
>  wrote:
> > On Fri, Mar 8, 2013 at 5:51 AM, Mary Barnes 
> > wrote:
> >>
> >> On Thu, Mar 7, 2013 at 12:42 PM, Eric Rescorla  wrote:
> >> >
> >> > On Thu, Mar 7, 2013 at 9:56 AM, Mary Barnes <
> mary.ietf.barnes@gmail.com>
> >> > wrote:
> >> >>
> >> >> On Thu, Mar 7, 2013 at 11:43 AM, Martin Thomson
> >> >>  wrote:
> >> >> > Obviously I (and my employer) agree with these sentiments
> >> >> > wholeheartedly.  Both Robin and Hadriel.
> >> >> >
> >> >> > That doesn't change the fact that a number of people are highly
> >> >> > motivated to protect their investment in SDP offer/answer.  For
> those
> >> >> > people, the pain that causes everyone else is clearly far less
> >> >> > important than the pain they feel at this moment.  So here we are.
> >> >>
> >> >> [MB] I originally thought that either approach could work.  I did see
> >> >> the value that folks saw in using SDP offer/answer. But after sitting
> >> >> through the interim meeting last month, I am very much of the mindset
> >> >> that using SDP O/A is a bad idea.   I think many of us thought that
> >> >> using the SDP blob would help with interoperability with "legacy" SIP
> >> >> endpoints.  I don't see that now at all.  I think we will end up with
> >> >> a very fragile solution that will be very difficult to extend/modify
> >> >> later if we continue down the SDP O/A path.
> >> >> [/MB]
> >> >>
> >> >
> >> > Hasn't the WG already been asked this question not once but
> >> > twice.
> >> [MB] Yes.  And, some of us have changed our positions based upon the
> >> challenges that the group is facing in getting the current approach
> >> specified and agreed.  I don't disagree that it is not a good thing
> >> that this is being discussed yet again.  [/MB]
> >
> >
> > [Gotta love the triple negation!]
> >
> > Why can't we have it both ways?
> >
> > Maintain the current way to get the raw SDP using createOffer, but then
> > provide an interface to change that offer before setLocalDescription.
> >
> > Even CISCO provides such an API:
> >
> http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/sip_tn/8_5_1/4-sdp_api.html
> > (I think we can do a better one than this, but it's a reference point).
> >
> > Cheers,
> > Silvia.
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
>

--bcaec5524106cb8ba704d75c4f6c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Agreed, but it's also not sufficient. SDP is not "programmer frien=
dly" enough because it has too many details that are protocol-details =
only and it's too hard to see the semantic bits in SDP and ignore the r=
est.



For example: the programmer wants to say - I want to get this video res=
olution, this audio bitrate & channels, I want to use this camera and t=
his microphone for this call. Having to manipulate SDP directly for this is=
 a programmer's nightmare.



Silvia.

On Fri, Mar 8, 2013 at 8:12 AM, Peter Thatcher <ptha=
tcher@google.com> wrote:


You can already do that by "munging" the SDP. =A0It's just no=
t very

pleasant to do.




On Thu, Mar 7, 2013 at 1:09 PM, Silvia Pfeiffer

<silviapfeiffer1@gmail.com<=
/a>> wrote:

> On Fri, Mar 8, 2013 at 5:51 AM, Mary Barnes <mary.ietf.barnes@gmail.com>

> wrote:

>>

>> On Thu, Mar 7, 2013 at 12:42 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>> >

>> > On Thu, Mar 7, 2013 at 9:56 AM, Mary Barnes <mary.ietf.barnes@gmail.com>

>> > wrote:

>> >>

>> >> On Thu, Mar 7, 2013 at 11:43 AM, Martin Thomson

>> >> <martin.th=
omson@gmail.com> wrote:

>> >> > Obviously I (and my employer) agree with these senti=
ments

>> >> > wholeheartedly. =A0Both Robin and Hadriel.

>> >> >

>> >> > That doesn't change the fact that a number of pe=
ople are highly

>> >> > motivated to protect their investment in SDP offer/a=
nswer. =A0For those

>> >> > people, the pain that causes everyone else is clearl=
y far less

>> >> > important than the pain they feel at this moment. =
=A0So here we are.

>> >>

>> >> [MB] I originally thought that either approach could work=
. =A0I did see

>> >> the value that folks saw in using SDP offer/answer. But a=
fter sitting

>> >> through the interim meeting last month, I am very much of=
 the mindset

>> >> that using SDP O/A is a bad idea. =A0 I think many of us =
thought that

>> >> using the SDP blob would help with interoperability with =
"legacy" SIP

>> >> endpoints. =A0I don't see that now at all. =A0I think=
 we will end up with

>> >> a very fragile solution that will be very difficult to ex=
tend/modify

>> >> later if we continue down the SDP O/A path.

>> >> [/MB]

>> >>

>> >

>> > Hasn't the WG already been asked this question not once b=
ut

>> > twice.

>> [MB] Yes. =A0And, some of us have changed our positions based upon=
 the

>> challenges that the group is facing in getting the current approac=
h

>> specified and agreed. =A0I don't disagree that it is not a goo=
d thing

>> that this is being discussed yet again. =A0[/MB]

>

>

> [Gotta love the triple negation!]

>

> Why can't we have it both ways?

>

> Maintain the current way to get the raw SDP using createOffer, but the=
n

> provide an interface to change that offer before setLocalDescription.<=
br>
>

> Even CISCO provides such an API:

> http://www.cisco.com/en/US/docs/voic=
e_ip_comm/cucm/sip_tn/8_5_1/4-sdp_api.html

> (I think we can do a better one than this, but it's a reference po=
int).

>

> Cheers,

> Silvia.

>

>


> __________________=
_____________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb

>





--bcaec5524106cb8ba704d75c4f6c--

From pthatcher@google.com  Thu Mar  7 13:26: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 9553121F8ABC for ; Thu,  7 Mar 2013 13:26:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.947
X-Spam-Level: 
X-Spam-Status: No, score=-102.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 uVkcaGE+tNF3 for ; Thu,  7 Mar 2013 13:26:21 -0800 (PST)
Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9913621F8A68 for ; Thu,  7 Mar 2013 13:26:21 -0800 (PST)
Received: by mail-vc0-f174.google.com with SMTP id n11so538438vch.5 for ; Thu, 07 Mar 2013 13:26:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=7Sm1ZmPCDEkAHvyJo23Xg4U3mwvw9iND31X933L39Ek=; b=D3dcMcT6n7EO+OfhyumxrqC37KveUUIvUNbdGTwLILBzJBXOV0KTOl1o4/mWHGqsrR nqD+nJ/JgC2/JHeZXqTFGVoCKgCxnx9p9Ghr1mGUFkQKllJoCwNm82qjkpGhUfTXkqfH WS0kKKGhSstnes0kJw8QLTzOODi4uTweclcpsm4Yukzxs1FIHwePWXCmyGa/0134I7CO sj4O4Evz7kv6rsso85NL/W71DYMKFGSbJFsWl5maHPDWTAyiL3EVD/L1lnv+Nm41i9m1 AsbRQSc899E2WoEyANOBb9bRDJ0DpPX7bmguK7hPSCn/lDuplag1YKN1p2FequTJeS7Q wmrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=7Sm1ZmPCDEkAHvyJo23Xg4U3mwvw9iND31X933L39Ek=; b=BC7Wbvc99agrG6dOj6AK9iK7MwV5d2K5ooYQFu1ZxHWj02VH0HWVRCp6icuOO43/ed 9SrvmLNWKF2SyecDqKZU+AzfTz6fQ2FbT5XHgda/AuPIgQKXmlncaOWqs875yXq88DCO aMWMyTqJZ06W9/x7vwxOLrKR//NWA3asU/+BLCpJvlXVNSB6XckH1erTCB4YeWnVlap6 IOFWX7c6miAackgDvQzKaft4Py8TeO9cOP5XnnyWTwG0gaMg6JH/cX8gR5nhSejK42kM IKaiLwmcrIcTaMnh1Dwd8TszMwvXb5y+cpUpqFiFeTGONfVDGu6/NrnH5ib7T1U+l+/G gC1w==
X-Received: by 10.220.219.80 with SMTP id ht16mr13282042vcb.30.1362691580977;  Thu, 07 Mar 2013 13:26:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.49.102 with HTTP; Thu, 7 Mar 2013 13:25:40 -0800 (PST)
In-Reply-To: 
References:         
From: Peter Thatcher 
Date: Thu, 7 Mar 2013 13:25:40 -0800
Message-ID: 
To: Silvia Pfeiffer 
Content-Type: text/plain; charset=UTF-8
X-Gm-Message-State: ALoCoQn7mvH2T5cKysJnCI/eobcE/B9rhDXvabh44fqha9dURJw3ViB6a/BmiFwGEpnbk5ytwpdk7tEjQ4UUTrwRmXN2yn8pGHZZZudpXn6X7/sIvg7Iw+5f++5WqDL2fSI/hewk4eRGMMYQbesZoc+z3tWXVa3InR1gg/joNyDLGfY/fUy01/1l8H8QX6ybNh1z5oDkg7qH
Cc: "" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 21:26:22 -0000

So, would you like a SessionDescription that is easy to read and
manipulate, such as a JSON object?

On Thu, Mar 7, 2013 at 1:22 PM, Silvia Pfeiffer
 wrote:
> Agreed, but it's also not sufficient. SDP is not "programmer friendly"
> enough because it has too many details that are protocol-details only and
> it's too hard to see the semantic bits in SDP and ignore the rest.
>
> For example: the programmer wants to say - I want to get this video
> resolution, this audio bitrate & channels, I want to use this camera and
> this microphone for this call. Having to manipulate SDP directly for this is
> a programmer's nightmare.
>
> Silvia.
>
>
> On Fri, Mar 8, 2013 at 8:12 AM, Peter Thatcher  wrote:
>>
>> You can already do that by "munging" the SDP.  It's just not very
>> pleasant to do.
>>
>> On Thu, Mar 7, 2013 at 1:09 PM, Silvia Pfeiffer
>>  wrote:
>> > On Fri, Mar 8, 2013 at 5:51 AM, Mary Barnes 
>> > wrote:
>> >>
>> >> On Thu, Mar 7, 2013 at 12:42 PM, Eric Rescorla  wrote:
>> >> >
>> >> > On Thu, Mar 7, 2013 at 9:56 AM, Mary Barnes
>> >> > 
>> >> > wrote:
>> >> >>
>> >> >> On Thu, Mar 7, 2013 at 11:43 AM, Martin Thomson
>> >> >>  wrote:
>> >> >> > Obviously I (and my employer) agree with these sentiments
>> >> >> > wholeheartedly.  Both Robin and Hadriel.
>> >> >> >
>> >> >> > That doesn't change the fact that a number of people are highly
>> >> >> > motivated to protect their investment in SDP offer/answer.  For
>> >> >> > those
>> >> >> > people, the pain that causes everyone else is clearly far less
>> >> >> > important than the pain they feel at this moment.  So here we are.
>> >> >>
>> >> >> [MB] I originally thought that either approach could work.  I did
>> >> >> see
>> >> >> the value that folks saw in using SDP offer/answer. But after
>> >> >> sitting
>> >> >> through the interim meeting last month, I am very much of the
>> >> >> mindset
>> >> >> that using SDP O/A is a bad idea.   I think many of us thought that
>> >> >> using the SDP blob would help with interoperability with "legacy"
>> >> >> SIP
>> >> >> endpoints.  I don't see that now at all.  I think we will end up
>> >> >> with
>> >> >> a very fragile solution that will be very difficult to extend/modify
>> >> >> later if we continue down the SDP O/A path.
>> >> >> [/MB]
>> >> >>
>> >> >
>> >> > Hasn't the WG already been asked this question not once but
>> >> > twice.
>> >> [MB] Yes.  And, some of us have changed our positions based upon the
>> >> challenges that the group is facing in getting the current approach
>> >> specified and agreed.  I don't disagree that it is not a good thing
>> >> that this is being discussed yet again.  [/MB]
>> >
>> >
>> > [Gotta love the triple negation!]
>> >
>> > Why can't we have it both ways?
>> >
>> > Maintain the current way to get the raw SDP using createOffer, but then
>> > provide an interface to change that offer before setLocalDescription.
>> >
>> > Even CISCO provides such an API:
>> >
>> > http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/sip_tn/8_5_1/4-sdp_api.html
>> > (I think we can do a better one than this, but it's a reference point).
>> >
>> > Cheers,
>> > Silvia.
>> >
>> >
>> > _______________________________________________
>> > rtcweb mailing list
>> > rtcweb@ietf.org
>> > https://www.ietf.org/mailman/listinfo/rtcweb
>> >
>
>

From pthatcher@google.com  Thu Mar  7 13:27: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 45C7621F8AAC for ; Thu,  7 Mar 2013 13:27:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.802
X-Spam-Level: 
X-Spam-Status: No, score=-102.802 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, 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 2ULYw-YgMcaG for ; Thu,  7 Mar 2013 13:27:13 -0800 (PST)
Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id AF47821F897F for ; Thu,  7 Mar 2013 13:27:13 -0800 (PST)
Received: by mail-vc0-f170.google.com with SMTP id p16so547446vcq.1 for ; Thu, 07 Mar 2013 13:27:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=vf61ojDVzhCxvoqwoRucZ7E8oL8Dl+IV+/xyVAGCgPQ=; b=cUvppsUCw9xL6Yp8kkJkd5ghOVT/p1P9wqoOMalkSmLA8szgqPSrG7OmqWx7PgE4yQ x7XhzxDjMfrWuFLpBRBGxuTE1qHtd2t/l7hFxa1QE5RnXGsNK0a8cUu6DHtS5ox0NOl9 Jvy20clWST4wvAKeqyHOaVwEO5dRqB0QmYAlI2PL7pzTIo4iHPSMJylFsnsd/SxNZ/PM JHaVuGPMmy4ucKXhhp4R1aM0/oxftXHzwGN93YAwRABiK9kgBQ+62hYloz1kQWKVOjCh VbC4Nv7HusKzUgP1KgMxzsO7EMNTocomlYjkwrd5W2rkftuvySOdy5MRhpquQ45CF4Ve IIuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=vf61ojDVzhCxvoqwoRucZ7E8oL8Dl+IV+/xyVAGCgPQ=; b=Z+rmoWa/W6NE9yRx6g0ZDlZMwDc56u9dhlkTWGj60TTv90sAfIFVAEqW6MhboWBa1W Mav/FkPNmVKSG3nlPvErnLAlfaHC42QoLD71BlM95gjr8snrTnIs9ap4YBdYuGohay54 Sh0c86FH37S1QNnAJ35+VBhUX5awv7oxcOk/x3HlamAdn8QqJhH+/J5qjLmkA+9l6H4k jv6AMa29CNBEolEjkcDoY1fJD+6/QBftc3J+9QRyRHVMhLFPImTRPWftSrm2cD3NaHd1 q4Yu3yBEigF/Cl02OjRbN2Qg3xhiwddm0E9vu2pn2uvrChhApxswAoqajNcC6BcIH152 wZPA==
X-Received: by 10.52.17.104 with SMTP id n8mr1637535vdd.12.1362691633177; Thu, 07 Mar 2013 13:27:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.49.102 with HTTP; Thu, 7 Mar 2013 13:26:33 -0800 (PST)
In-Reply-To: 
References:       
From: Peter Thatcher 
Date: Thu, 7 Mar 2013 13:26:33 -0800
Message-ID: 
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQl9/4VatOex3NCW1zuE3yz5EDCouGJYmnGTsP2sSw6yqmiobVILy8yscQkL0peTKEwcAJl/3YFLoNJFQomNT0a8aJ39i63gdAeuU+/9SuasEYZXZ0jf2mhYVp1lm7w1V7PA1sRMBKMw9Xea1xqgp4k/w9Be7mbw6nVPOiu5un3BDmhV0+QmOtI2mtZ/99Ow7q3cqsJy
Cc: "" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 21:27:14 -0000

So, would you like a SessionDescription to send to the other side that
is flexible and manageable, such as a JSON object?

On Thu, Mar 7, 2013 at 1:17 PM, I=C3=B1aki Baz Castillo  wro=
te:
> 2013/3/7 Peter Thatcher :
>> Anti-SDP camp: methods=3Dlow-level methods   and   format=3Dnone
>
> What does "format=3Dnone" mean? There should be some kind of "format" to
> tell the remote peer our video codec preferences, ICE candidates and
> so, am I right? This is not about passing a URL to the remote.
>
> That's exactly what SDP attempts to achieve but SDP is too flexible
> and unmanageable.
>
>
> --
> I=C3=B1aki Baz Castillo
> 

From silviapfeiffer1@gmail.com  Thu Mar  7 13:31: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 4482121F852B for ; Thu,  7 Mar 2013 13:31:16 -0800 (PST)
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 onHWosrSBVvy for ; Thu,  7 Mar 2013 13:31:15 -0800 (PST)
Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id BEB0E21F8168 for ; Thu,  7 Mar 2013 13:31:14 -0800 (PST)
Received: by mail-la0-f42.google.com with SMTP id fe20so1029464lab.1 for ; Thu, 07 Mar 2013 13:31:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=5Jq1vT+oVuud6WtRG2qnje8+Db8RPIfmTQyeA91f8DE=; b=pFNC2Zud4dYFSHIOI3uHgd3oD2NFdjb/7AV3zWoRX7XEaYjRBH2AQKpw2hEp1jZEmN 8nHwDEctVt5VBOgwjmRhkfDJsjMDGrBoXxEzw/yDLljeWuwaMGIXTMTvCOaAuc4ZRDJq eQb6KWwmZlrwy4S0SYUm2kqQnGPmDMlb/esVDmDMLyA6ZBIs+GXNRZ6JP6K6B1/AIU+L /hIhsWksUeDmBvedORj6pTjqpNkb+ILzw8B4upGOziP6uJPl0EJeoEdRzqNi4Iw2pUhn hOQxdR7AlSOVKcE0OnvFFpKcFPSIzqM00YMOaFTP/wnOIN1hmNLp3Lsonp2WyU9uCIV2 sZiA==
X-Received: by 10.152.134.40 with SMTP id ph8mr29678970lab.39.1362691873725; Thu, 07 Mar 2013 13:31:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.51.229 with HTTP; Thu, 7 Mar 2013 13:30:52 -0800 (PST)
In-Reply-To: 
References:          
From: Silvia Pfeiffer 
Date: Fri, 8 Mar 2013 08:30:52 +1100
Message-ID: 
To: Peter Thatcher 
Content-Type: multipart/alternative; boundary=f46d042f96421266d004d75c6da2
Cc: "" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 21:31:16 -0000

--f46d042f96421266d004d75c6da2
Content-Type: text/plain; charset=ISO-8859-1

If your suggestion is only to convert the SDP to JSON, then that's a first
step, but not the full story, because the complexity is just represented in
a different format. I'm looking for something that helps programmers
achieve their goals more easily.

JSON is a first step, because it's a more readable data format. However, it
doesn't help me, to e.g. list the cameras on offer and remove one, or
change the offered video resolution. That needs manipulation functions.


On Fri, Mar 8, 2013 at 8:25 AM, Peter Thatcher  wrote:

> So, would you like a SessionDescription that is easy to read and
> manipulate, such as a JSON object?
>
> On Thu, Mar 7, 2013 at 1:22 PM, Silvia Pfeiffer
>  wrote:
> > Agreed, but it's also not sufficient. SDP is not "programmer friendly"
> > enough because it has too many details that are protocol-details only and
> > it's too hard to see the semantic bits in SDP and ignore the rest.
> >
> > For example: the programmer wants to say - I want to get this video
> > resolution, this audio bitrate & channels, I want to use this camera and
> > this microphone for this call. Having to manipulate SDP directly for
> this is
> > a programmer's nightmare.
> >
> > Silvia.
> >
> >
> > On Fri, Mar 8, 2013 at 8:12 AM, Peter Thatcher 
> wrote:
> >>
> >> You can already do that by "munging" the SDP.  It's just not very
> >> pleasant to do.
> >>
> >> On Thu, Mar 7, 2013 at 1:09 PM, Silvia Pfeiffer
> >>  wrote:
> >> > On Fri, Mar 8, 2013 at 5:51 AM, Mary Barnes <
> mary.ietf.barnes@gmail.com>
> >> > wrote:
> >> >>
> >> >> On Thu, Mar 7, 2013 at 12:42 PM, Eric Rescorla  wrote:
> >> >> >
> >> >> > On Thu, Mar 7, 2013 at 9:56 AM, Mary Barnes
> >> >> > 
> >> >> > wrote:
> >> >> >>
> >> >> >> On Thu, Mar 7, 2013 at 11:43 AM, Martin Thomson
> >> >> >>  wrote:
> >> >> >> > Obviously I (and my employer) agree with these sentiments
> >> >> >> > wholeheartedly.  Both Robin and Hadriel.
> >> >> >> >
> >> >> >> > That doesn't change the fact that a number of people are highly
> >> >> >> > motivated to protect their investment in SDP offer/answer.  For
> >> >> >> > those
> >> >> >> > people, the pain that causes everyone else is clearly far less
> >> >> >> > important than the pain they feel at this moment.  So here we
> are.
> >> >> >>
> >> >> >> [MB] I originally thought that either approach could work.  I did
> >> >> >> see
> >> >> >> the value that folks saw in using SDP offer/answer. But after
> >> >> >> sitting
> >> >> >> through the interim meeting last month, I am very much of the
> >> >> >> mindset
> >> >> >> that using SDP O/A is a bad idea.   I think many of us thought
> that
> >> >> >> using the SDP blob would help with interoperability with "legacy"
> >> >> >> SIP
> >> >> >> endpoints.  I don't see that now at all.  I think we will end up
> >> >> >> with
> >> >> >> a very fragile solution that will be very difficult to
> extend/modify
> >> >> >> later if we continue down the SDP O/A path.
> >> >> >> [/MB]
> >> >> >>
> >> >> >
> >> >> > Hasn't the WG already been asked this question not once but
> >> >> > twice.
> >> >> [MB] Yes.  And, some of us have changed our positions based upon the
> >> >> challenges that the group is facing in getting the current approach
> >> >> specified and agreed.  I don't disagree that it is not a good thing
> >> >> that this is being discussed yet again.  [/MB]
> >> >
> >> >
> >> > [Gotta love the triple negation!]
> >> >
> >> > Why can't we have it both ways?
> >> >
> >> > Maintain the current way to get the raw SDP using createOffer, but
> then
> >> > provide an interface to change that offer before setLocalDescription.
> >> >
> >> > Even CISCO provides such an API:
> >> >
> >> >
> http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/sip_tn/8_5_1/4-sdp_api.html
> >> > (I think we can do a better one than this, but it's a reference
> point).
> >> >
> >> > Cheers,
> >> > Silvia.
> >> >
> >> >
> >> > _______________________________________________
> >> > rtcweb mailing list
> >> > rtcweb@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/rtcweb
> >> >
> >
> >
>

--f46d042f96421266d004d75c6da2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

If your suggestion is only to convert the SDP to JSON, then that's a fi=
rst step, but not the full story, because the complexity is just represente=
d in a different format. I'm looking for something that helps programme=
rs achieve their goals more easily.



JSON is a first step, because it's a more readable data format. How=
ever, it doesn't help me, to e.g. list the cameras on offer and remove =
one, or change the offered video resolution. That needs manipulation functi=
ons.




On Fri, Mar 8, 2013 at 8:25 AM, Peter Th=
atcher <pthatcher@google.com> wrote:


So, would you like a SessionDescription that is easy to read and

manipulate, such as a JSON object?



On Thu, Mar 7, 2013 at 1:22 PM, Silvia Pfeiffer


<silviapfeiffer1@gmail.com> wrote:

> Agreed, but it's also not sufficient. SDP is not "programmer =
friendly"

> enough because it has too many details that are protocol-details only =
and

> it's too hard to see the semantic bits in SDP and ignore the rest.=


>

> For example: the programmer wants to say - I want to get this video
> resolution, this audio bitrate & channels, I want to use this came=
ra and

> this microphone for this call. Having to manipulate SDP directly for t=
his is

> a programmer's nightmare.

>

> Silvia.

>

>

> On Fri, Mar 8, 2013 at 8:12 AM, Peter Thatcher <pthatcher@google.com> wrote:

>>

>> You can already do that by "munging" the SDP. =A0It'=
s just not very

>> pleasant to do.

>>

>> On Thu, Mar 7, 2013 at 1:09 PM, Silvia Pfeiffer

>> <silviapfeiffer1@g=
mail.com> wrote:

>> > On Fri, Mar 8, 2013 at 5:51 AM, Mary Barnes <mary.ietf.barnes@gmail.com>

>> > wrote:

>> >>

>> >> On Thu, Mar 7, 2013 at 12:42 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>> >> >

>> >> > On Thu, Mar 7, 2013 at 9:56 AM, Mary Barnes

>> >> > <ma=
ry.ietf.barnes@gmail.com>

>> >> > wrote:

>> >> >>

>> >> >> On Thu, Mar 7, 2013 at 11:43 AM, Martin Thomson<=
br>
>> >> >> <=
martin.thomson@gmail.com> wrote:

>> >> >> > Obviously I (and my employer) agree with th=
ese sentiments

>> >> >> > wholeheartedly. =A0Both Robin and Hadriel.<=
br>
>> >> >> >

>> >> >> > That doesn't change the fact that a num=
ber of people are highly

>> >> >> > motivated to protect their investment in SD=
P offer/answer. =A0For

>> >> >> > those

>> >> >> > people, the pain that causes everyone else =
is clearly far less

>> >> >> > important than the pain they feel at this m=
oment. =A0So here we are.

>> >> >>

>> >> >> [MB] I originally thought that either approach c=
ould work. =A0I did

>> >> >> see

>> >> >> the value that folks saw in using SDP offer/answ=
er. But after

>> >> >> sitting

>> >> >> through the interim meeting last month, I am ver=
y much of the

>> >> >> mindset

>> >> >> that using SDP O/A is a bad idea. =A0 I think ma=
ny of us thought that

>> >> >> using the SDP blob would help with interoperabil=
ity with "legacy"

>> >> >> SIP

>> >> >> endpoints. =A0I don't see that now at all. =
=A0I think we will end up

>> >> >> with

>> >> >> a very fragile solution that will be very diffic=
ult to extend/modify

>> >> >> later if we continue down the SDP O/A path.

>> >> >> [/MB]

>> >> >>

>> >> >

>> >> > Hasn't the WG already been asked this question n=
ot once but

>> >> > twice.

>> >> [MB] Yes. =A0And, some of us have changed our positions b=
ased upon the

>> >> challenges that the group is facing in getting the curren=
t approach

>> >> specified and agreed. =A0I don't disagree that it is =
not a good thing

>> >> that this is being discussed yet again. =A0[/MB]

>> >

>> >

>> > [Gotta love the triple negation!]

>> >

>> > Why can't we have it both ways?

>> >

>> > Maintain the current way to get the raw SDP using createOffer=
, but then

>> > provide an interface to change that offer before setLocalDesc=
ription.

>> >

>> > Even CISCO provides such an API:

>> >

>> > http://www.cisco.com/en/US/=
docs/voice_ip_comm/cucm/sip_tn/8_5_1/4-sdp_api.html

>> > (I think we can do a better one than this, but it's a ref=
erence point).

>> >

>> > Cheers,

>> > Silvia.

>> >

>> >

>> > _______________________________________________

>> > rtcweb mailing list

>> > rtcweb@ietf.org

>> > https://www.ietf.org/mailman/listinfo/rtcweb

>> >

>

>





--f46d042f96421266d004d75c6da2--

From ibc@aliax.net  Thu Mar  7 13:33: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 193A221F8ABC for ; Thu,  7 Mar 2013 13:33:40 -0800 (PST)
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 ChwjZSNBlcFF for ; Thu,  7 Mar 2013 13:33:39 -0800 (PST)
Received: from mail-qe0-f43.google.com (mail-qe0-f43.google.com [209.85.128.43]) by ietfa.amsl.com (Postfix) with ESMTP id 62DEA21F852B for ; Thu,  7 Mar 2013 13:33:39 -0800 (PST)
Received: by mail-qe0-f43.google.com with SMTP id 1so602957qee.30 for ; Thu, 07 Mar 2013 13:33:38 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=IIUJd1yjBjYFnaF81MOT17xMUSts5OfGnxuH45mYppg=; b=HQyE+nredEG+2pNHjvSK7cZ5IxQeLpW+VjVZheKjv7ydej4zA30hTgR6MoNhG1T2rS VqCm1+VuX4ZHMMblU6RhKgkCuRFIVDdt0iQFqECQ6TjFBM0YokOMMRZBhaYF8R9Tgilp m0ERjF05CIBhHmQn/nNECWBc7gqdKo0Ickfdw/MJYzFLoQ+qAP6njdNAWUA7dZ4YgOPr Xf/H2j5ieJMBLpvHYsNWbDAc24IyS7NhLLlXXi+/ZrYm1CgyZan5VeCEPOcz+/tMvAhs OZ9HKy4Q0OcVFn7+pDVadEMNNBpKuFqFdG/faaPf4GKd5IgizFCFfbXjGBrUJpfzBYkR B//g==
X-Received: by 10.49.133.195 with SMTP id pe3mr56719174qeb.58.1362692018850; Thu, 07 Mar 2013 13:33:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.49.12.233 with HTTP; Thu, 7 Mar 2013 13:33:18 -0800 (PST)
In-Reply-To: 
References:        
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 7 Mar 2013 22:33:18 +0100
Message-ID: 
To: Peter Thatcher 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmJKHzVIy1ONvUjvQj3/EgYybOAlyscb4ZLPL0ut0fQ1ZyefzR49un1dvUHFy6a81cqYFV5
Cc: "" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 21:33:40 -0000

2013/3/7 Peter Thatcher :
> So, would you like a SessionDescription to send to the other side that
> is flexible and manageable, such as a JSON object?

If I have to receive the *entire* JSON / rawSDP /
whateverSessionDescription again with minimal changes just for
enabling/disabling video, I don't like it since it means that I must
"compare" the current SD with the new one.

I don't care whether the format is raw SDP, JSON or whatever. What I
would like is that I can establish an audio/video session with a peer
and, at some time, I can send a *minimal* SD "command" / "RPC" to say
the remote "Hi I am dissabling the video right now".


--=20
I=C3=B1aki Baz Castillo


From pthatcher@google.com  Thu Mar  7 13: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 A22E921F85FE for ; Thu,  7 Mar 2013 13:34:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.978
X-Spam-Level: 
X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 8WLIQrlq3vCN for ; Thu,  7 Mar 2013 13:34:20 -0800 (PST)
Received: from mail-vb0-x22c.google.com (mail-vb0-x22c.google.com [IPv6:2607:f8b0:400c:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B20D921F8566 for ; Thu,  7 Mar 2013 13:34:20 -0800 (PST)
Received: by mail-vb0-f44.google.com with SMTP id fr13so373944vbb.17 for ; Thu, 07 Mar 2013 13:34:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=pwHZvuwCzfbzXQi2XG1oBHTrxv+FMsowRTq5MH7AE/Y=; b=W8d8l6+pzOe6Su75rQYvMhALPKhC03ily/hgJUtXFPJ/Ybb1EIecSZ2oE72aQaD1N/ iIvJmU6/2QaVZbu8+E811M2t/C361zsTeKFECDqaDwexRUN+rX9uvV9EN5IX8XPkUODp GY+CgkC3TKg/JkiAjsegrODbCZxpVE4f5W3cVZ4RSunyhkSlH1/xZ+sNk7ZjqKk7Rb6F rYKUNe6gHFTBum6gKodUexxQeK4JQ9E46+2NU6e2dNmVils5su9A85T0j/CLeMa7Rq42 AqNJVGgubpbYFh+yunUlK2ZxdYqRBZc+OJg8iaxFNjblFoYYWfZE1Tn0auGq8gAk1OYH WBGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=pwHZvuwCzfbzXQi2XG1oBHTrxv+FMsowRTq5MH7AE/Y=; b=TsajwRTEnBSDdL1b8E1lgpq5Gq34KPglsH/yNA/SQDtz6YSsiSBgRaAd/tHfD3Z+Uf Z9wU1TCHCml2BhShbCrhwmiTz1WgYQXfNPn7VNyh5Mp3YsAnCbC6rLIJEP0KjwHdMqmw Gs/l71ZRjxEUoKmPE0C2Vp5LeSggJulclAiz+s/l1OGaW+3zJz6GF5iitmlMB2C+u8VH yC/EdUSUD6FP4bZKTx7ncqJRIHIyGaF5h+id7s19D3fWTgvACVAgNES6hzZ4AeI4zUe0 4d9fHMDiuIgbwoXvNXD95VszmnSVDUnX0OrNX/ywcj7WeikcBwnXURgGUYtc+amfO5/u T0rg==
X-Received: by 10.52.33.68 with SMTP id p4mr11699627vdi.125.1362692060120; Thu, 07 Mar 2013 13:34:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.49.102 with HTTP; Thu, 7 Mar 2013 13:33:40 -0800 (PST)
In-Reply-To: 
References:           
From: Peter Thatcher 
Date: Thu, 7 Mar 2013 13:33:40 -0800
Message-ID: 
To: Silvia Pfeiffer 
Content-Type: text/plain; charset=UTF-8
X-Gm-Message-State: ALoCoQkqS0/5hC+pwX+wmCtNr074YKb/Gikml/nqEH+m0qScJuR9tCRIOphqi+yv0DGjMbujF3oBSC1IfMqvz+Ag8A3CvYY1nb6/yWcUgiJuqQUYaryhXf+fvpH5OG3qmt4N7Jil++S0DqdvOkiHffXvO2SK6fiLqKLw5qbhZlbEGndtAKih8JZyS9P4lWvLEk4z1/SOmpPa
Cc: "" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 21:34:21 -0000

A JSON format doesn't have to be "SDP in a different format".  It can
be much better.  It can expose an easy way to change the video
resolution to send, or a way to add/remove tracks easily.

Listing cameras, however, is a whole different topic.

On Thu, Mar 7, 2013 at 1:30 PM, Silvia Pfeiffer
 wrote:
> If your suggestion is only to convert the SDP to JSON, then that's a first
> step, but not the full story, because the complexity is just represented in
> a different format. I'm looking for something that helps programmers achieve
> their goals more easily.
>
> JSON is a first step, because it's a more readable data format. However, it
> doesn't help me, to e.g. list the cameras on offer and remove one, or change
> the offered video resolution. That needs manipulation functions.
>
>
>
> On Fri, Mar 8, 2013 at 8:25 AM, Peter Thatcher  wrote:
>>
>> So, would you like a SessionDescription that is easy to read and
>> manipulate, such as a JSON object?
>>
>> On Thu, Mar 7, 2013 at 1:22 PM, Silvia Pfeiffer
>>  wrote:
>> > Agreed, but it's also not sufficient. SDP is not "programmer friendly"
>> > enough because it has too many details that are protocol-details only
>> > and
>> > it's too hard to see the semantic bits in SDP and ignore the rest.
>> >
>> > For example: the programmer wants to say - I want to get this video
>> > resolution, this audio bitrate & channels, I want to use this camera and
>> > this microphone for this call. Having to manipulate SDP directly for
>> > this is
>> > a programmer's nightmare.
>> >
>> > Silvia.
>> >
>> >
>> > On Fri, Mar 8, 2013 at 8:12 AM, Peter Thatcher 
>> > wrote:
>> >>
>> >> You can already do that by "munging" the SDP.  It's just not very
>> >> pleasant to do.
>> >>
>> >> On Thu, Mar 7, 2013 at 1:09 PM, Silvia Pfeiffer
>> >>  wrote:
>> >> > On Fri, Mar 8, 2013 at 5:51 AM, Mary Barnes
>> >> > 
>> >> > wrote:
>> >> >>
>> >> >> On Thu, Mar 7, 2013 at 12:42 PM, Eric Rescorla  wrote:
>> >> >> >
>> >> >> > On Thu, Mar 7, 2013 at 9:56 AM, Mary Barnes
>> >> >> > 
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> On Thu, Mar 7, 2013 at 11:43 AM, Martin Thomson
>> >> >> >>  wrote:
>> >> >> >> > Obviously I (and my employer) agree with these sentiments
>> >> >> >> > wholeheartedly.  Both Robin and Hadriel.
>> >> >> >> >
>> >> >> >> > That doesn't change the fact that a number of people are highly
>> >> >> >> > motivated to protect their investment in SDP offer/answer.  For
>> >> >> >> > those
>> >> >> >> > people, the pain that causes everyone else is clearly far less
>> >> >> >> > important than the pain they feel at this moment.  So here we
>> >> >> >> > are.
>> >> >> >>
>> >> >> >> [MB] I originally thought that either approach could work.  I did
>> >> >> >> see
>> >> >> >> the value that folks saw in using SDP offer/answer. But after
>> >> >> >> sitting
>> >> >> >> through the interim meeting last month, I am very much of the
>> >> >> >> mindset
>> >> >> >> that using SDP O/A is a bad idea.   I think many of us thought
>> >> >> >> that
>> >> >> >> using the SDP blob would help with interoperability with "legacy"
>> >> >> >> SIP
>> >> >> >> endpoints.  I don't see that now at all.  I think we will end up
>> >> >> >> with
>> >> >> >> a very fragile solution that will be very difficult to
>> >> >> >> extend/modify
>> >> >> >> later if we continue down the SDP O/A path.
>> >> >> >> [/MB]
>> >> >> >>
>> >> >> >
>> >> >> > Hasn't the WG already been asked this question not once but
>> >> >> > twice.
>> >> >> [MB] Yes.  And, some of us have changed our positions based upon the
>> >> >> challenges that the group is facing in getting the current approach
>> >> >> specified and agreed.  I don't disagree that it is not a good thing
>> >> >> that this is being discussed yet again.  [/MB]
>> >> >
>> >> >
>> >> > [Gotta love the triple negation!]
>> >> >
>> >> > Why can't we have it both ways?
>> >> >
>> >> > Maintain the current way to get the raw SDP using createOffer, but
>> >> > then
>> >> > provide an interface to change that offer before setLocalDescription.
>> >> >
>> >> > Even CISCO provides such an API:
>> >> >
>> >> >
>> >> > http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/sip_tn/8_5_1/4-sdp_api.html
>> >> > (I think we can do a better one than this, but it's a reference
>> >> > point).
>> >> >
>> >> > Cheers,
>> >> > Silvia.
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > rtcweb mailing list
>> >> > rtcweb@ietf.org
>> >> > https://www.ietf.org/mailman/listinfo/rtcweb
>> >> >
>> >
>> >
>
>

From pthatcher@google.com  Thu Mar  7 13: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 00E6E21F8566 for ; Thu,  7 Mar 2013 13:37:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.784
X-Spam-Level: 
X-Spam-Status: No, score=-102.784 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 u098HrV0Wtme for ; Thu,  7 Mar 2013 13:37:56 -0800 (PST)
Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id 6714621F8B16 for ; Thu,  7 Mar 2013 13:37:56 -0800 (PST)
Received: by mail-ve0-f171.google.com with SMTP id b10so789856vea.30 for ; Thu, 07 Mar 2013 13:37:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=8L255dxS10UGOdOxQiEL39dHNbr8jkCoba2Z1dS22q0=; b=J54pc1Yc9OLvtxUKZvGKthyxn4BAR9OHr9k4wKrFm8sTe3vAgwLsPuKfBO+WtJCAAM cQoZ5kT1aod13smDwWBVayULu9k+sjl6K0zbrv69ofnrbvi5Eu72MrR/xJ/mdSmVYV+d iv+x2Yh+DhmbVYqrnMOnIr2hHsAiOPdd/B+UCFDcd9N+lIbL8Kh+eFYDrENnE1oKRhtr 2IdzMEHF7G1EAJ1Ne5XLhjQELSl+LIyl27hdugUqIFhmNUjq0+/CEZ/oZ1sPVrMbUi33 2fAVgfaXhJ+Mhs8uZWj+ad8reeJOjLM3pBvWjBVgdVCY1yy8gyjq/YdObTNByxgJXpcG ef4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=8L255dxS10UGOdOxQiEL39dHNbr8jkCoba2Z1dS22q0=; b=C8710PjXgM+Lc8430UuHagG33eQMdrlwS/U+IYeoCHVJ0A0I3ZGy5BSTzK75h5Uxn6 k+MvrzR7esUdyjf/g0uizDXi84tOnd6cktJ8uAvccA1+FbfHhPSoDn5fSeAIOUOUjOAm CwgHdvlGaojVYdSMaJ1nlHkQzSGsVQYZ9y/ij4pdjgnQm1dPwzNoemAqrXQcI9Ayu0wT 999VE3+E/dYfMgy26+hV0FzF7eng3mUYYe2of4z5TfoIu8JpUHUrRZsk0dkY85b2SEQx BrjhoYdhjBF4ib5CQW67w25xDGNLFDOvbF1dq5m97lTzFeQABOevKwG7KM8OvGJiR4tJ Hz1Q==
X-Received: by 10.220.219.80 with SMTP id ht16mr13296730vcb.30.1362692275805;  Thu, 07 Mar 2013 13:37:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.49.102 with HTTP; Thu, 7 Mar 2013 13:37:15 -0800 (PST)
In-Reply-To: 
References:         
From: Peter Thatcher 
Date: Thu, 7 Mar 2013 13:37:15 -0800
Message-ID: 
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQk8GDCyhES6N2ub7vDqEyuqbB00DGPdqa/R7DA7PJoYaKzxEfVBf+e5Q3j5nm2MHm/vIlPiDTjxtTfoIeaNCQdEVuH13k+Sx/00kINhnBa3g8xkiz4pvJQO9M/35SqA/CJHwSnu6Em/XPMEawMxbFCA/v1IauHhsR6TjnUJn3YtdDkFik63a2nsRAvtx++Nprb9CJ1w
Cc: "" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 21:37:57 -0000

Having a minimal SessionDescription command and then a
"SessionDescription update message" that says "I'm adding new video
now" or "I'm disabling the video
right now" absolutely can and should be a part of a better
SessionDescription format.  I think that's a good idea and very
doable.





On Thu, Mar 7, 2013 at 1:33 PM, I=C3=B1aki Baz Castillo  wro=
te:
> 2013/3/7 Peter Thatcher :
>> So, would you like a SessionDescription to send to the other side that
>> is flexible and manageable, such as a JSON object?
>
> If I have to receive the *entire* JSON / rawSDP /
> whateverSessionDescription again with minimal changes just for
> enabling/disabling video, I don't like it since it means that I must
> "compare" the current SD with the new one.
>
> I don't care whether the format is raw SDP, JSON or whatever. What I
> would like is that I can establish an audio/video session with a peer
> and, at some time, I can send a *minimal* SD "command" / "RPC" to say
> the remote "Hi I am dissabling the video right now".
>
>
> --
> I=C3=B1aki Baz Castillo
> 

From roman@telurix.com  Thu Mar  7 13:46: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 8E85821F8AF2 for ; Thu,  7 Mar 2013 13:46:42 -0800 (PST)
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 AlEVM0lKdbEc for ; Thu,  7 Mar 2013 13:46:42 -0800 (PST)
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 7B9EA21F8AB8 for ; Thu,  7 Mar 2013 13:46:41 -0800 (PST)
Received: by mail-we0-f172.google.com with SMTP id d46so221451wer.31 for ; Thu, 07 Mar 2013 13:46:40 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=7g+dv7W35M2849CxScS+Vil+Zi7z8YhICS1BvfBpdJE=; b=UW+6SsdFseV5NbhMemPj21gMhlNqubEsUFR5noDkTeqMArxE3AUneL5xgBDoJIAvNF n1K3IV2SxY3YiSU6rjkvF+U65gddGPmey/LjQk4mpT0aoBDrj8GVrigUY9MnlUTrGFRt Tr8gp7KGiFLCiJjYEqWJ0OyYlNtlzl29ynlyTxq+HrMet2/VMVXdicqlgGr3ewXzG0H6 4Vb44pwcYCOo33Lq0Lxmq7tb4ZJHCDkhA3AAGF8RrFYliqkd/AQCC3Dk0hqjCL1UvMhI 2dvGF63ms8e+ScMZwJf0Vsd/4xtmQQYftL+TjFa6raf+fCZvDpDiMjpPwCt/STdCLOmf ySug==
X-Received: by 10.180.100.169 with SMTP id ez9mr36845946wib.3.1362692800492; Thu, 07 Mar 2013 13:46:40 -0800 (PST)
Received: from mail-wi0-x229.google.com ([2a00:1450:400c:c05::229]) by mx.google.com with ESMTPS id n10sm5723061wia.0.2013.03.07.13.46.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Mar 2013 13:46:39 -0800 (PST)
Received: by mail-wi0-f169.google.com with SMTP id l13so3952073wie.2 for ; Thu, 07 Mar 2013 13:46:38 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.76.37 with SMTP id h5mr58209470wjw.21.1362692798578; Thu, 07 Mar 2013 13:46:38 -0800 (PST)
Received: by 10.217.107.135 with HTTP; Thu, 7 Mar 2013 13:46:38 -0800 (PST)
In-Reply-To: 
References:          
Date: Thu, 7 Mar 2013 16:46:38 -0500
Message-ID: 
From: Roman Shpount 
To: Peter Thatcher 
Content-Type: multipart/alternative; boundary=047d7bb03bc43288c004d75ca401
X-Gm-Message-State: ALoCoQmMhTpgcAqpv20NoluWKLvHer8xCrD2hwC6DwTpDr0MPCZvbdT593Esdy3Qbag+HJNJmJEZ
Cc: "" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 21:46:42 -0000

--047d7bb03bc43288c004d75ca401
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I do not think redefining session description is the best approach. Having
access to direct API methods that control send codecs, send media types,
resolution, etc  is easier to understand and to program. I think even
simply exposing the API from Voice and Video engines in current WebRTC
implementation would be a more usable API then the current offer/answer SDP
based one.
_____________
Roman Shpount


On Thu, Mar 7, 2013 at 4:37 PM, Peter Thatcher  wrote=
:

> Having a minimal SessionDescription command and then a
> "SessionDescription update message" that says "I'm adding new video
> now" or "I'm disabling the video
> right now" absolutely can and should be a part of a better
> SessionDescription format.  I think that's a good idea and very
> doable.
>
>
>
>
>
> On Thu, Mar 7, 2013 at 1:33 PM, I=F1aki Baz Castillo  wrot=
e:
> > 2013/3/7 Peter Thatcher :
> >> So, would you like a SessionDescription to send to the other side that
> >> is flexible and manageable, such as a JSON object?
> >
> > If I have to receive the *entire* JSON / rawSDP /
> > whateverSessionDescription again with minimal changes just for
> > enabling/disabling video, I don't like it since it means that I must
> > "compare" the current SD with the new one.
> >
> > I don't care whether the format is raw SDP, JSON or whatever. What I
> > would like is that I can establish an audio/video session with a peer
> > and, at some time, I can send a *minimal* SD "command" / "RPC" to say
> > the remote "Hi I am dissabling the video right now".
> >
> >
> > --
> > I=F1aki Baz Castillo
> > 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--047d7bb03bc43288c004d75ca401
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I do not think redefining session description is the best approach. Having =
access to direct API methods that control send codecs, send media types, re=
solution, etc =A0is easier to understand and to program. I think even simpl=
y exposing the API from Voice and Video engines in current WebRTC implement=
ation would be a more usable API then the current offer/answer SDP based on=
e.


_____________
Roman Shpount



On Thu, Mar 7, 2013 at 4:37 PM, Peter Th=
atcher <pthatcher@google.com> wrote:

Having a minimal SessionDescription command and then a

"SessionDescription update message" that says "I'm addin=
g new video

now" or "I'm disabling the video

right now" absolutely can and should be a part of a better

SessionDescription format. =A0I think that's a good idea and very

doable.












On Thu, Mar 7, 2013 at 1:33 PM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:

> 2013/3/7 Peter Thatcher <pt=
hatcher@google.com>:

>> So, would you like a SessionDescription to send to the other side =
that

>> is flexible and manageable, such as a JSON object?

>

> If I have to receive the *entire* JSON / rawSDP /

> whateverSessionDescription again with minimal changes just for

> enabling/disabling video, I don't like it since it means that I mu=
st

> "compare" the current SD with the new one.

>

> I don't care whether the format is raw SDP, JSON or whatever. What=
 I

> would like is that I can establish an audio/video session with a peer<=
br>
> and, at some time, I can send a *minimal* SD "command" / &qu=
ot;RPC" to say

> the remote "Hi I am dissabling the video right now".

>

>

> --

> I=F1aki Baz Castillo

> <ibc@aliax.net>

_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--047d7bb03bc43288c004d75ca401--

From matthew@matthew.at  Thu Mar  7 13:48: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 34F0821F8C46 for ; Thu,  7 Mar 2013 13:48:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.272
X-Spam-Level: 
X-Spam-Status: No, score=-1.272 tagged_above=-999 required=5 tests=[AWL=0.158,  BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+DqAwW2xa4W for ; Thu,  7 Mar 2013 13:48:43 -0800 (PST)
Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id C220121F8B27 for ; Thu,  7 Mar 2013 13:48:43 -0800 (PST)
Received: from [10.10.155.2] (unknown [10.10.155.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 9A3CE230005 for ; Thu,  7 Mar 2013 13:48:43 -0800 (PST)
Message-ID: <51390B3C.7010203@matthew.at>
Date: Thu, 07 Mar 2013 13:48:44 -0800
From: Matthew Kaufman 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References:           
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 21:48:44 -0000

On 3/7/2013 1:46 PM, Roman Shpount wrote:
> I do not think redefining session description is the best approach. 
> Having access to direct API methods that control send codecs, send 
> media types, resolution, etc  is easier to understand and to program. 
> I think even simply exposing the API from Voice and Video engines in 
> current WebRTC implementation would be a more usable API then the 
> current offer/answer SDP based one.

There is an existing proposal published by my employer which is along 
these lines. It might be helpful if the folks who are just now realizing 
what the issues are with dealing with both the complexity of the format 
of SDP as well as the embedded offer-answer semantics could review that 
and see how closely it matches their needs, rather than starting from a 
clean sheet of paper.

Matthew Kaufman

From silviapfeiffer1@gmail.com  Thu Mar  7 13:57: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 AD08B21F8BFD for ; Thu,  7 Mar 2013 13:57:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.442
X-Spam-Level: 
X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsThUwcTXR3e for ; Thu,  7 Mar 2013 13:57:21 -0800 (PST)
Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id AD43321F8C46 for ; Thu,  7 Mar 2013 13:57:20 -0800 (PST)
Received: by mail-la0-f53.google.com with SMTP id fr10so1031377lab.40 for ; Thu, 07 Mar 2013 13:57:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=2vnmZI7k+crfS5SeC+F1Ix/bYFGHeBwa75jVwsl+Nfw=; b=zEmIvt60VMJE8vhPs81GctiM5aR7Wp7/+pC8tvg03u4xYp45lyebOGWT31xxlvSbYM 2xFESj6hFPRHK8o8fjiWanUEPnCVgBzCbXPewnS7soGnH2+fHhCRZdfOGpbHa4AIGRfr NDe7W+AV44KEVPZb6KzJqvltdBRCtijv937YKVQiBklHmCchcuXAZZS3mMdezsn/2oh/ 40rrIbYH4YO60BeFmjH1XYWQP0ERDag5uzMKDQ/H4ah/jt4MUJCASKMXip/CBv9MGmQp IsEbVQW1tEjmk/bWS49txKHs7OH22ujjCTHpqG1L1CZ9eHbNLfRaPHY5oaLnjzib8TPX wuSg==
X-Received: by 10.112.9.104 with SMTP id y8mr119572lba.132.1362693436470; Thu, 07 Mar 2013 13:57:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.51.229 with HTTP; Thu, 7 Mar 2013 13:56:55 -0800 (PST)
In-Reply-To: <5138EB62.9000700@matthew.at>
References:  <5138EB62.9000700@matthew.at>
From: Silvia Pfeiffer 
Date: Fri, 8 Mar 2013 08:56:55 +1100
Message-ID: 
To: Matthew Kaufman 
Content-Type: multipart/alternative; boundary=e0cb4efe2ee638022104d75cca4b
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 IPR agreement announced.
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 07 Mar 2013 21:57:22 -0000

--e0cb4efe2ee638022104d75cca4b
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Seriously? Google and MPEG just announced that VP8 is essentially the first
widely agreed non-patent-encumbered codec and your reaction is "an
interesting development" and "process disallows discussion"? It's almost a
week until the meeting, just start preparing for it now.

For everyone else: it is a day of great joy and overwhelming relief that
MPEG and Google have found an arrangement to allow the world to publish and
share video without risk of getting sued over codec patents. I say: rejoice=
!

Silvia.
(speaking for myself and dare I say: most of humanity who doesn't even
realize what just happened ;-)


On Fri, Mar 8, 2013 at 6:32 AM, Matthew Kaufman  wrote:

>  The below announcement, while an interesting development, comes weeks
> after the traditional deadlines for providing new information to the
> working group prior to an upcoming meeting and certainly does not give me
> enough time to adequately review the development. In fact, the sublicense
> terms referenced below will not be available to review until *after* the
> upcoming meeting and might very well contain language that is incompatibl=
e
> with my requirements or those of other implementers of RTCWEB
> specifications.
>
> Therefore I believe the most sensible action is to once again delay the
> MTI video codec discussion, remove it from the agenda from the upcoming
> meeting, and have the call for an MTI codec at a later time=85 no sooner =
than
> several weeks after the relevant license terms are even available to
> review. I hope the chairs concur.
>
> Alternatively, we can have the discussion at the upcoming meeting, but it
> will not be able to incorporate this development at all, and without any
> change in the IPR situation it was clear that H.264 was the only suitable
> alternative (and may still be the best choice, given the strong arguments
> for the technical merits and implementation advantages of H.264,
> irrespective of the IPR issues).
>
> Matthew Kaufman
>
>
> On 3/7/2013 11:18 AM, Serge Lachapelle wrote:
>
>  Hello,
>
>  Today, Google Inc. and MPEG LA, LLC have announced that they have
> entered into an agreement granting Google a license to techniques, if any=
,
> that may be essential to VP8. Furthermore, MPEG LA has agreed to
> discontinue efforts to form a patent pool around VP8.
>
>  The official press release can be found here: http://goo.gl/F7xUu
>
>  The licensors are part of the group that responded to MPEG LA=92s call f=
or
> patents. They are a group of well-known video IP holders and participants
> in standards-based video patent pools.
>
>  This agreement allows for Google to sublicense the techniques to any
> user of VP8, whether the VP8 implementation is by Google or another entit=
y;
> this means that users can develop independent implementations of VP8 and
> still enjoy coverage under the sublicenses.
>
>  Google intends to license the techniques under terms that are in line
> with the W3C=92s definition of a Royalty Free License. This definition ca=
n be
> found here: http://www.w3.org/2001/07/SVG10-IPR-statements  We anticipate
> having the sublicense ready in the next few weeks. The terms will appear =
on
> the WebM Project website at http://webmproject.org
>
>  This agreement is not an acknowledgment that the licensed techniques
> read on VP8. The purpose of this agreement is meant to provide further an=
d
> stronger reassurance to implementors of VP8.
>
>  On a personal note, I think you will all agree that the RTCWeb MTI video
> codec discussion included many whispered doubts but little evidence. In
> contrast, we have taken clear steps to demonstrate the viability of VP8:
>
>  1. Made VP8 available with a strong, simple software license and patent
> grant.
> 2. Continued to innovate and improve VP8 in the open.
> 3. Licensed a royalty free VP8 enabled RTL (aka hardware source code) to
> more than 50 SOCs.
> 4. Built, iterated and launched VP8 powered WebRTC in the Chrome browser
> to hundreds of millions of users.
> 5. Worked to ensure WebRTC interop using the VP8 and Opus formats by
> working closely with Firefox.
> 6. Introduced a preview of VP8 and Opus based WebRTC in Chrome for Androi=
d
> beta.
>
>  And now, we have taken taken two significant steps that we hope will
> make the situation clear to all:
>
>  7. Submitted VP8 to ISO SC29/WG11 (MPEG) in January of this year for
> standardization.
> 8. Invested a significant amount of time and resources into reaching an
> agreement with the MPEG LA, to provide further reassurances.
>
>  VP8 is a royalty free, open sourced codec that offers several advantages
> and innovations for real time and other uses.  It has a publicly-availabl=
e
> specification that is getting broadly adopted in hardware; it has been
> submitted for standardization to a leading standards body, and is the
> subject of a royalty-free RAND license which will now include a license
> covering any essential VP8 techniques that may be relevant to major IP
> holders who responded to the MPEG LA's call for VP8 patents.
>
>  It is the most suitable codec for MTI.
>
>  I understand the timing is very close to the Orlando IETF meeting.
>  While we tried to do this as quickly as possible, I am sure you will
> appreciate the sensitivities and enormous effort involved in reaching suc=
h
> an agreement.
>
>  I will be in Orlando, arriving monday evening and will be available to
> answer questions.
>
>  /Serge
>
>
> _______________________________________________
> rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/r=
tcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--e0cb4efe2ee638022104d75cca4b
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Seriously? Google and MPEG just announced that VP8 is essentially the first=
 widely agreed non-patent-encumbered codec and your reaction is "an in=
teresting development" and "process disallows discussion"? I=
t's almost a week until the meeting, just start preparing for it now.


For everyone else: it is a day of great joy and overwhelming relief tha=
t MPEG and Google have found an arrangement to allow the world to publish a=
nd share video without risk of getting sued over codec patents. I say: rejo=
ice!



Silvia.
(speaking for myself and dare I say: most of humanity who do=
esn't even realize what just happened ;-)


On Fri, Mar 8, 2013 at 6:32 AM, Matthew Kaufman =
<matthew@matthew=
.at> wrote:




 =20
   =20
 =20
  

    

     =20
     =20
     =20
     =20
     =20
     =20
     =20
     =20
     =20
      The below announcement, while an interesting development,
      comes weeks after the traditional deadlines for providing new
      information to the working group prior to an upcoming meeting and
      certainly does not give me enough time to adequately review the
      development. In fact, the sublicense terms referenced below will
      not be available to review until *after* the upcoming meeting and
      might very well contain language that is incompatible with my
      requirements or those of other implementers of RTCWEB
      specifications.

      

      Therefore I believe the most sensible action is to once again
      delay the MTI video codec discussion, remove it from the agenda
      from the upcoming meeting, and have the call for an MTI codec at a
      later time=85 no sooner than several weeks after the relevant
      license terms are even available to review. I hope the chairs
      concur.

      

      Alternatively, we can have the discussion at the upcoming meeting,
      but it will not be able to incorporate this development at all,
      and without any change in the IPR situation it was clear that
      H.264 was the only suitable alternative (and may still be the best
      choice, given the strong arguments for the technical merits and
      implementation advantages of H.264, irrespective of the IPR
      issues).

      =A0=A0=A0 

      Matthew Kaufman


      

      On 3/7/2013 11:18 AM, Serge Lachapelle wrote:

    

    

      

        
Hello,

        


        

        
Today, Google Inc. and MPEG LA, LLC have announced that
          they have entered into an agreement granting Google a license
          to techniques, if any, that may be essential to VP8.
          Furthermore, MPEG LA has agreed to discontinue efforts to form
          a patent pool around VP8.

        


        

        
The official press release can be found here:=A0http://goo.gl/F7xUu

        

        


        

        
The licensors are part of the group that responded to MPEG
          LA=92s call for patents. They are a group of well-known video IP
          holders and participants in standards-based video patent
          pools.

        


        

        
This agreement allows for Google to sublicense the
          techniques to any user of VP8, whether the VP8 implementation
          is by Google or another entity; this means that users can
          develop independent implementations of VP8 and still enjoy
          coverage under the sublicenses.=A0

        


        

        
Google intends to license the techniques under terms that
          are in line with the W3C=92s definition of a Royalty Free
          License. This definition can be found here: http://www.w3.org/2=
001/07/SVG10-IPR-statements=A0
          We anticipate having the sublicense ready in the next few
          weeks. The terms will appear on the WebM Project website at http://webmproject.org<=
/div>
        


        

        

          This agreement is not an acknowledgment that the licensed
          techniques read on VP8. The purpose of this agreement is meant
          to provide further and stronger reassurance to implementors of
          VP8.=A0

        


        

        
On a personal note, I think you will all agree that the
          RTCWeb MTI video codec discussion included many whispered
          doubts but little evidence. In contrast, we have taken clear
          steps to demonstrate the viability of VP8:

        


        

        
1. Made VP8 available with a strong, simple software
          license and patent grant.

        
2. Continued to innovate and improve VP8 in the open.=A0

        
3. Licensed a royalty free VP8 enabled RTL (aka hardware
          source code) to more than 50 SOCs.

        
4. Built, iterated and launched VP8 powered WebRTC in the
          Chrome browser to hundreds of millions of users.=A0

        
5. Worked to ensure WebRTC interop using the VP8 and Opus
          formats by working closely with Firefox.

        
6. Introduced a preview of VP8 and Opus based WebRTC in
          Chrome for Android beta.

        


        

        
And now, we have taken taken two significant steps that we
          hope will make the situation clear to all:=A0

        

          

        

        
7. Submitted VP8 to ISO SC29/WG11 (MPEG) in January of this
          year for standardization.

        
8. Invested a significant amount of time and resources into
          reaching an agreement with the MPEG LA, to provide further
          reassurances.

        


        

        
VP8 is a royalty free, open sourced codec that offers
          several advantages and innovations for real time and other
          uses. =A0It has a publicly-available specification that is
          getting broadly adopted in hardware; it has been submitted for
          standardization to a leading standards body, and is the
          subject of a royalty-free RAND license which will now include
          a license covering any essential VP8 techniques that may be
          relevant to major IP holders who responded to the MPEG LA's
          call for VP8 patents.

        


        

        
It is the most suitable codec for MTI.

        


        

        
I understand the timing is very close to the Orlando IETF
          meeting. =A0While we tried to do this as quickly as possible, I
          am sure you will appreciate the sensitivities and enormous
          effort involved in reaching such an agreement.

        


        

        
I will be in Orlando, arriving monday evening and will be
          available to answer questions.=A0

        


        

        
/Serge

      

      

      

      

      
_______________________________________________
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





--e0cb4efe2ee638022104d75cca4b--

From pthatcher@google.com  Thu Mar  7 13:58: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 6E5DC21F8CA4 for ; Thu,  7 Mar 2013 13:58:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.771
X-Spam-Level: 
X-Spam-Status: No, score=-102.771 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 06J7QP4WyXaN for ; Thu,  7 Mar 2013 13:58:54 -0800 (PST)
Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id B11F421F8CC5 for ; Thu,  7 Mar 2013 13:58:53 -0800 (PST)
Received: by mail-lb0-f173.google.com with SMTP id gf7so850857lbb.18 for ; Thu, 07 Mar 2013 13:58:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=Rq46FW3oEiGoGji7It+Y/lH44xRYgOxL+3Kq/IsnPzw=; b=HO4nToz6d9V+5lJLhf1wI7yJ1vP86BgblNwCrRy6Uhe/LsXfLcoADlDNursQzR+6Za rW7twe6rYhLPEYyQU8wFUvbnkFR37NythRTZJysvOYaLPD2zUggpLXGDmyXpNFgzAnzL QKmm/koRh8zfxnDTH4r6irYa9Vk0FOOKaBHe30oxYn3Em72u33EruN7lDw51xRYXmpZA hIcKwvMSVRzcCR3Jml7ebm2zz/C9bMwDiYh4nI04aMZqC+sJwRVv1Ql0AObm9FMtR9iN WylqWQrUUKxsCw/OhDNyCImqpmjSAARfTBQA9mpGhBTGgt7J+675tCz/hP6Z63yUSuq4 WLJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=Rq46FW3oEiGoGji7It+Y/lH44xRYgOxL+3Kq/IsnPzw=; b=ZUo1CXfsS5BN04lvaS6z9qEKapMXfHGHY/tfy/jULqlvi1amo9Ihvt3wKJf6OoZf4R ZmRhw4PpiRJczWYWCaDVqCaYRmHi8Yr2DAXGdkww+UBTK0aFOn45FSNK8ASjqUbove11 IKo3RgiDUEbXPcORfMhk2J2oEdO3amf44rOppGY+pK3mYNIO9d7RakoofixW0NH4y/MT jG/f4JZY84t0V2dj7zqC99zGRJqz5ZqItn0IR+lthOJ9fIZ3AypXsAS7kbAoDvCFc3Yw KXmstRCcR4NEe3k0PLmfYETM9EaPsq9xBSoMuTofbvFWKur0TQC3lgXnOB3Bvgs900XF EBVw==
X-Received: by 10.152.109.112 with SMTP id hr16mr30242533lab.38.1362693532547;  Thu, 07 Mar 2013 13:58:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.6.5 with HTTP; Thu, 7 Mar 2013 13:58:11 -0800 (PST)
In-Reply-To: 
References:           
From: Peter Thatcher 
Date: Thu, 7 Mar 2013 13:58:11 -0800
Message-ID: 
To: Roman Shpount , =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= ,  Silvia Pfeiffer 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmwlDlw0qjeJ3qy0n4yWTkZYUfcyZQ3Yk4Kv0WTonzPwVul6DKaCAppcTRGHXgFccIOmXM3f2LhvmhilmrB/COBMqQ+IzJSolmnJzeJc0/bAi95jylOvE0du0GGENiLrHpQVUiltfxEaH85BYYNv/5BDmIIGT2xHnex7HSRzDx32cLqagI2nqv7gWxlGlkvI8gSpT17
Cc: "" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 21:58:55 -0000

To help keep track of all the needs mentioned, I made a Google Doc
that tracks them:

https://docs.google.com/document/d/1hXxZoLFMmypWlkQR8LmbYYD_uZnQS0FWaYItSDB=
9v-s/edit

If you're interested in a better SessionDescription that offers
low-level control in a readable and programmable way, without quite
"blowing up the world" with major changes to the API, please take a
look and leave comments.  I'll try to keep it up to date with what's
on the mailing list, but it's hard to keep track of everything :).

On Thu, Mar 7, 2013 at 1:46 PM, Roman Shpount  wrote:
> I do not think redefining session description is the best approach. Havin=
g
> access to direct API methods that control send codecs, send media types,
> resolution, etc  is easier to understand and to program. I think even sim=
ply
> exposing the API from Voice and Video engines in current WebRTC
> implementation would be a more usable API then the current offer/answer S=
DP
> based one.
> _____________
> Roman Shpount
>
>
> On Thu, Mar 7, 2013 at 4:37 PM, Peter Thatcher  wro=
te:
>>
>> Having a minimal SessionDescription command and then a
>> "SessionDescription update message" that says "I'm adding new video
>> now" or "I'm disabling the video
>> right now" absolutely can and should be a part of a better
>> SessionDescription format.  I think that's a good idea and very
>> doable.
>>
>>
>>
>>
>>
>> On Thu, Mar 7, 2013 at 1:33 PM, I=C3=B1aki Baz Castillo  =
wrote:
>> > 2013/3/7 Peter Thatcher :
>> >> So, would you like a SessionDescription to send to the other side tha=
t
>> >> is flexible and manageable, such as a JSON object?
>> >
>> > If I have to receive the *entire* JSON / rawSDP /
>> > whateverSessionDescription again with minimal changes just for
>> > enabling/disabling video, I don't like it since it means that I must
>> > "compare" the current SD with the new one.
>> >
>> > I don't care whether the format is raw SDP, JSON or whatever. What I
>> > would like is that I can establish an audio/video session with a peer
>> > and, at some time, I can send a *minimal* SD "command" / "RPC" to say
>> > the remote "Hi I am dissabling the video right now".
>> >
>> >
>> > --
>> > I=C3=B1aki Baz Castillo
>> > 
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

From ibc@aliax.net  Thu Mar  7 14:10: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 1E08B21F8B33 for ; Thu,  7 Mar 2013 14:10:05 -0800 (PST)
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 1Vod+qWiBvmi for ; Thu,  7 Mar 2013 14:10:04 -0800 (PST)
Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id B3BEE21F8B26 for ; Thu,  7 Mar 2013 14:10:02 -0800 (PST)
Received: by mail-qa0-f47.google.com with SMTP id j8so3557497qah.13 for ; Thu, 07 Mar 2013 14:10:01 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=znkAKwVLMaOvuHOBuhxpFn/gpbq27FZ+vP2Ex9uslQM=; b=GfYwRpITGIWL0+4EVXOZg7RoBUmGH31UBFwd+kzXwp9tFlHM8lGoMx7PYsOi9xIO1q arLifMT4a0nRroxAdTk2xsDtX6Th1GWUKV82XO321pjzRRDClb/oa+YgIXtiniShigk/ mJI8/uFhe2c3PJ7inBIKQ68tVGVp5I5K1SS2zqaOv0xiOa4RaRzJZqrrkuyCc2g4XT7N 3sFsODCPN/fd2qRM7nU71Yvkg/2H+zWgE3EmcI7S3kpoRpwpZBVifRrSI4pOw3IULXG2 Lf8dZuTeAkE7UgmXm8/+oHuFpnNzI1WjgEo8veJ9kx+BJyS5DiyVEJYs1DY369JSY7OA AECA==
X-Received: by 10.229.201.137 with SMTP id fa9mr11191985qcb.18.1362694201688;  Thu, 07 Mar 2013 14:10:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.49.12.233 with HTTP; Thu, 7 Mar 2013 14:09:41 -0800 (PST)
In-Reply-To: 
References:            
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 7 Mar 2013 23:09:41 +0100
Message-ID: 
To: Peter Thatcher 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlrXx3AkSmjRssNa8t7RzcZIJzdtA1aDWgJ3Sw37EGz8JQ1EWP9gvnMtYy0m9I0GxSyk57F
Cc: "" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 22:10:05 -0000

2013/3/7 Peter Thatcher :
> To help keep track of all the needs mentioned, I made a Google Doc
> that tracks them:
>
> https://docs.google.com/document/d/1hXxZoLFMmypWlkQR8LmbYYD_uZnQS0FWaYItS=
DB9v-s/edit
>
> If you're interested in a better SessionDescription that offers
> low-level control in a readable and programmable way, without quite
> "blowing up the world" with major changes to the API, please take a
> look and leave comments.  I'll try to keep it up to date with what's
> on the mailing list, but it's hard to keep track of everything :).


Hi, I've made the following proposal in ~10 minutes, so probably it
lacks some requried features, but I hope the idea behind it is clear
enough:

http://www.gitpaste.com/paste/1423/



--=20
I=C3=B1aki Baz Castillo


From ted.ietf@gmail.com  Thu Mar  7 14:48: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 0770821F8C98 for ; Thu,  7 Mar 2013 14:48:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level: 
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050,  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 fWZEcd-Vspde for ; Thu,  7 Mar 2013 14:48:50 -0800 (PST)
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 8452F21F8CD0 for ; Thu,  7 Mar 2013 14:48:50 -0800 (PST)
Received: by mail-ie0-f178.google.com with SMTP id c13so1266281ieb.23 for ; Thu, 07 Mar 2013 14:48:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=wHv0vUVL9D9PZUHkE4xq2itIQ4y5ZzjNnTvSoMSl1BI=; b=Y0IrcrBclvXfAeQnUQIVJcV8fTQsv53rCkk/Y2au2V0bRn0MctCvvboNaXw4hzPIkz X24anCDpbHkRv/Xblw/SzmLJMzXciydqPzplzsZIBbfm1xxu2wBTCvYzC9so0bKiHU83 XNcWmS6zUToSw54U9WC3KmRLv19mYhhYk2IGLZpF3VKfaQ6lgr4E/wPPNGHqYEjIU+6+ UR8q1rmWWHVtAVBsRZemgBocQidwoBsOKbq4bH0GnlnBGtVxvrE09JaV5kwsR+S3ZFmm iQORNrhBeM/o6ov4u+FR2KYy95i+PwmxJ4lPv638GUPgxA4cZ9K/824WwTr0S+MYLWjj WkYA==
MIME-Version: 1.0
X-Received: by 10.50.170.102 with SMTP id al6mr16047714igc.20.1362696530080; Thu, 07 Mar 2013 14:48:50 -0800 (PST)
Received: by 10.43.135.202 with HTTP; Thu, 7 Mar 2013 14:48:49 -0800 (PST)
Date: Thu, 7 Mar 2013 14:48:49 -0800
Message-ID: 
From: Ted Hardie 
To: rtcweb@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Cc: rtcweb-chairs@tools.ietf.org
Subject: [rtcweb] Checkpointing decisions in RTCWEB
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 07 Mar 2013 22:48:51 -0000

Howdy,

For any working group to be able to make consistent progress, it must
be able to rely on decisions that have already been taken to remain
stable in the absence of new technical issues.    Re-raising old
issues without new information does not help move the work forward,
and, as tempting as it may be for those who raised it the initial
times, nor does a chorus of "I thought that all along".

For the specific question in the thread entitled "Proposed Plan for
Usage of SDP and RTP - Lower level API minus SDP", I believe every
point in the thread has been raised before.  SDP has been unlovely and
arcane for many years, so this is not new news.  Despite that old
news, we have run consensus calls on this topic in both the IETF and
the W3C and agreed to use both it and offer/answer.

May I politely suggest we finish that work *before* we examine the
need and feasibility of an addtional, potentially lower-layer approach
to this?  Finishing the work before us does not close off all related
work for all time, but failure to produce something viable soon likely
will.

I'm not sure what hat to wear for this message, so assume a "grumpy
old timer" porkpie, size 7 and 3/8ths.

regards,

Ted Hardie

From silviapfeiffer1@gmail.com  Thu Mar  7 15:02: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 E3CAD21F8C00 for ; Thu,  7 Mar 2013 15:02:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.546
X-Spam-Level: 
X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.052,  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 ZtoZeeMyeCzY for ; Thu,  7 Mar 2013 15:02:19 -0800 (PST)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C375721F8A5E for ; Thu,  7 Mar 2013 15:02:18 -0800 (PST)
Received: by mail-la0-f43.google.com with SMTP id ek20so1100724lab.30 for ; Thu, 07 Mar 2013 15:02:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=4hCIJjzDLVKaWloxYVJzOOPXJwhul/7iOPOswscP1jk=; b=kDhh1vVlG3X+gjPS7YOyw/12tnqdJLQg4p25yxQB9cCgsFHY2XkRhNbC52oCRlLl2y qzns58D+ctERImWQFwQUnzr+Eo2QfafKS5Ztp9E42BG8qa8Cqv3h1xcpWdy8WbqSX/zV J18ro+Xw9m3wHp/dydJNZSCv1dmZjNUnjvKMpCeIkw6wWT//zKgdeBZtotrfMoewhxdw ntkvYuYfRW2DKLoqGMGHVIgX4cIOSEcbPw2Eg+ciHV5Rn7FHGzLR4tGK5qWGd2wiM/Y6 Q55+LEv/cPJnbL/JMH/sG0jxr63HV1EQXxDQv5+fDDETZu6UJrpYPusuEjpW1ZeH//Wf GM1g==
X-Received: by 10.152.104.80 with SMTP id gc16mr30225106lab.49.1362697337453;  Thu, 07 Mar 2013 15:02:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.51.229 with HTTP; Thu, 7 Mar 2013 15:01:56 -0800 (PST)
In-Reply-To: <51390B3C.7010203@matthew.at>
References:            <51390B3C.7010203@matthew.at>
From: Silvia Pfeiffer 
Date: Fri, 8 Mar 2013 10:01:56 +1100
Message-ID: 
To: Matthew Kaufman 
Content-Type: multipart/alternative; boundary=f46d040714d5bc46ad04d75db2d8
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 23:02:20 -0000

--f46d040714d5bc46ad04d75db2d8
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Mar 8, 2013 at 8:48 AM, Matthew Kaufman  wrote:

> On 3/7/2013 1:46 PM, Roman Shpount wrote:
>
>> I do not think redefining session description is the best approach.
>> Having access to direct API methods that control send codecs, send media
>> types, resolution, etc  is easier to understand and to program. I think
>> even simply exposing the API from Voice and Video engines in current WebRTC
>> implementation would be a more usable API then the current offer/answer SDP
>> based one.
>>
>
> There is an existing proposal published by my employer which is along
> these lines. It might be helpful if the folks who are just now realizing
> what the issues are with dealing with both the complexity of the format of
> SDP as well as the embedded offer-answer semantics could review that and
> see how closely it matches their needs, rather than starting from a clean
> sheet of paper.
>

I assume you're referring to:
http://www.w3.org/TR/2012/WD-webrtc-20120821/#rtcsdptype  ?

I like some of the approaches taken in this proposal.
I like that there are actual objects for RTCSdpType and
RTCSessionDescription .
There are, however, no functions to manipulate a SDP yet.

I assume that the API discussion has to happen in the W3C and not here? To
be honest, I am not overly fussed as to what format the browser deals with
- SDP or JSON - though the latter is a more natural browser format. I do,
however, care what the Web developer has to deal with.

Cheers,
Silvia.

--f46d040714d5bc46ad04d75db2d8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 8, 2013 at 8:48 AM, Matthew Kaufman <matthew@matthew.at&g=
t; wrote:



On 3/7/2013 1:46 PM, Roman Shpount wrote:



I do not think redefining session description is the best approach. Having =
access to direct API methods that control send codecs, send media types, re=
solution, etc =A0is easier to understand and to program. I think even simpl=
y exposing the API from Voice and Video engines in current WebRTC implement=
ation would be a more usable API then the current offer/answer SDP based on=
e.







There is an existing proposal published by my employer which is along these=
 lines. It might be helpful if the folks who are just now realizing what th=
e issues are with dealing with both the complexity of the format of SDP as =
well as the embedded offer-answer semantics could review that and see how c=
losely it matches their needs, rather than starting from a clean sheet of p=
aper.




I assume you're referring to:
http://w=
ww.w3.org/TR/2012/WD-webrtc-20120821/#rtcsdptype=A0 ?

I like som=
e of the approaches taken in this proposal.


I like that there are actual objects for RTCSdpType and RTCSessionDescripti=
on .
There are, however, no functions to manipulate a SDP yet.

I =
assume that the API discussion has to happen in the W3C and not here? To be=
 honest, I am not overly fussed as to what format the browser deals with - =
SDP or JSON - though the latter is a more natural browser format. I do, how=
ever, care what the Web developer has to deal with.



Cheers,
Silvia.


=



--f46d040714d5bc46ad04d75db2d8--

From ted.ietf@gmail.com  Thu Mar  7 15:03: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 5350521F8B33 for ; Thu,  7 Mar 2013 15:03:47 -0800 (PST)
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, 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 giZIHWnVWtM2 for ; Thu,  7 Mar 2013 15:03:47 -0800 (PST)
Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id DA92721F8A68 for ; Thu,  7 Mar 2013 15:03:46 -0800 (PST)
Received: by mail-ie0-f181.google.com with SMTP id 17so1273845iea.40 for ; Thu, 07 Mar 2013 15:03:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=w04FajZ0eRx77HrlVWIHMpwa/Xcd+cpwWNs4mn/3w28=; b=d52EykaO+WK6Z7/0SGAv7+GoM/DBVVDgWRjzgFegsJjlFz45hpRhKa9JuB1u2idumF tHTri9CFA6oXL4+W50gsUNKuGH9DMy4K0iSRF6KbFiyU6jzOCNXvzWVPfra38KSBmwxJ U5hsP/D+w6PoVFYEkB1RHu4ggWHq/yy0t1tOKQDBFsDaZiOEYCcwt3QH8QWkX8ORa/fu wgNChPM16/faGJEjBJgJ+Q69pqOOfOF3h88gXTPsMY3QH8gm2rh5VhZ9vVsH3s3upMjR qttSCBkzDbP9xiqwJfwWimnvcwns2sP5XcGfJL+nE9zPii95UwwSFoZZ3FY0DYogiKBp FPLg==
MIME-Version: 1.0
X-Received: by 10.50.36.169 with SMTP id r9mr15933485igj.96.1362697426517; Thu, 07 Mar 2013 15:03:46 -0800 (PST)
Received: by 10.43.135.202 with HTTP; Thu, 7 Mar 2013 15:03:46 -0800 (PST)
In-Reply-To: 
References:  <5138EB62.9000700@matthew.at> 
Date: Thu, 7 Mar 2013 15:03:46 -0800
Message-ID: 
From: Ted Hardie 
To: Silvia Pfeiffer 
Content-Type: text/plain; charset=ISO-8859-1
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 IPR agreement announced.
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 07 Mar 2013 23:03:47 -0000

On Thu, Mar 7, 2013 at 1:56 PM, Silvia Pfeiffer
 wrote:
> Seriously? Google and MPEG

Just as a point of clarification, the announcement was made by
MPEG-LA, which is distinct from MPEG.

regards,

Ted Hardie

From silviapfeiffer1@gmail.com  Thu Mar  7 15:05: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 A6EC021F8A68 for ; Thu,  7 Mar 2013 15:05:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.56
X-Spam-Level: 
X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039,  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 h9wm1ULUBzQx for ; Thu,  7 Mar 2013 15:05:03 -0800 (PST)
Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id E155421F8B1C for ; Thu,  7 Mar 2013 15:05:02 -0800 (PST)
Received: by mail-la0-f49.google.com with SMTP id fs13so1100353lab.36 for ; Thu, 07 Mar 2013 15:05:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=kq31Y8gngPpGXT2pcJZef/3OjKWQI9OkolD80Pp2A6U=; b=aCPTCpLdSCKAbkrg2MCC2SxnW6rSydIFwYfSWVK9iARguh28qU71IZE2eqqP0YhS4y jhl29MirNcCza73OzX5HG+LnRvQYQLbEYi/4x1qzQQMDSeApoI8fn8jm00XPw6bPxM7Q WwF+ivRCR35pUzmFkcEDSgbR2usfDxIoj2Qknq9BamAcUA/6nFLDjtsBu4XVJnco3xzO 9J2y7ldyC/sw8bPs4iJaYJBhjWZdsWS9QoA1QlCxXmaDR+fmQvOtgeTyDXyzeCGfROdV MXI6RS9HT45Mnjy87THroUtdiAqlxX+4eGuP22sCZ4wDw/vt7sEncns1mRaGJiu9I4tG vrDw==
X-Received: by 10.152.104.80 with SMTP id gc16mr30231100lab.49.1362697501837;  Thu, 07 Mar 2013 15:05:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.51.229 with HTTP; Thu, 7 Mar 2013 15:04:41 -0800 (PST)
In-Reply-To: 
References:  <5138EB62.9000700@matthew.at>  
From: Silvia Pfeiffer 
Date: Fri, 8 Mar 2013 10:04:41 +1100
Message-ID: 
To: Ted Hardie 
Content-Type: multipart/alternative; boundary=f46d040714d588944204d75dbc13
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 IPR agreement announced.
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 07 Mar 2013 23:05:03 -0000

--f46d040714d588944204d75dbc13
Content-Type: text/plain; charset=ISO-8859-1

Oops! Point taken. Thanks for noticing - it's what I meant to say.
Silvia.

On Fri, Mar 8, 2013 at 10:03 AM, Ted Hardie  wrote:

> On Thu, Mar 7, 2013 at 1:56 PM, Silvia Pfeiffer
>  wrote:
> > Seriously? Google and MPEG
>
> Just as a point of clarification, the announcement was made by
> MPEG-LA, which is distinct from MPEG.
>
> regards,
>
> Ted Hardie
>

--f46d040714d588944204d75dbc13
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Oops! Point taken. Thanks for noticing - it's what I meant to say.
S=
ilvia.

On Fri, Mar 8, 2013 at 10:03 AM, T=
ed Hardie <ted.ietf@gmail.com> wrote:



On Thu, Mar 7, 2013 at 1:5=
6 PM, Silvia Pfeiffer

<silviapfeiffer1@gmail.com<=
/a>> wrote:

> Seriously? Google and MPEG




Just as a point of clarification, the announcement was made by

MPEG-LA, which is distinct from MPEG.



regards,



Ted Hardie





--f46d040714d588944204d75dbc13--

From matthew@matthew.at  Thu Mar  7 15:10: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 BBBB021F8484 for ; Thu,  7 Mar 2013 15:10:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.351
X-Spam-Level: 
X-Spam-Status: No, score=-1.351 tagged_above=-999 required=5 tests=[AWL=0.079,  BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, 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 OZ0DlMx+W10o for ; Thu,  7 Mar 2013 15:10:27 -0800 (PST)
Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D5821F8464 for ; Thu,  7 Mar 2013 15:10:25 -0800 (PST)
Received: from [10.10.155.229] (unknown [10.10.155.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 4FCE6148049; Thu,  7 Mar 2013 15:10:23 -0800 (PST)
Message-ID: <51391E5E.4080007@matthew.at>
Date: Thu, 07 Mar 2013 15:10:22 -0800
From: Matthew Kaufman 
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Silvia Pfeiffer 
References:            <51390B3C.7010203@matthew.at> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000806070600020408010504"
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 23:10:30 -0000

This is a multi-part message in MIME format.
--------------000806070600020408010504
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 3/7/2013 3:01 PM, Silvia Pfeiffer wrote:
> On Fri, Mar 8, 2013 at 8:48 AM, Matthew Kaufman  > wrote:
>
>     On 3/7/2013 1:46 PM, Roman Shpount wrote:
>
>         I do not think redefining session description is the best
>         approach. Having access to direct API methods that control
>         send codecs, send media types, resolution, etc  is easier to
>         understand and to program. I think even simply exposing the
>         API from Voice and Video engines in current WebRTC
>         implementation would be a more usable API then the current
>         offer/answer SDP based one.
>
>
>     There is an existing proposal published by my employer which is
>     along these lines. It might be helpful if the folks who are just
>     now realizing what the issues are with dealing with both the
>     complexity of the format of SDP as well as the embedded
>     offer-answer semantics could review that and see how closely it
>     matches their needs, rather than starting from a clean sheet of paper.
>
>
> I assume you're referring to:
> http://www.w3.org/TR/2012/WD-webrtc-20120821/#rtcsdptype ?

No, I was referring to 
http://html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web.htm

>
> I like some of the approaches taken in this proposal.
> I like that there are actual objects for RTCSdpType and 
> RTCSessionDescription .
> There are, however, no functions to manipulate a SDP yet.
>
> I assume that the API discussion has to happen in the W3C and not 
> here? To be honest, I am not overly fussed as to what format the 
> browser deals with - SDP or JSON - though the latter is a more natural 
> browser format. I do, however, care what the Web developer has to deal 
> with.

The web developer currently is stuck with SDP *and* the SDP offer/answer 
semantics *plus* whatever gets added in MMUSIC to SDP in order to 
actually do everything that's needed (bundle, stream identification, 
etc.)... assuming that the changes to SDP can be made while keeping them 
compatible with everything else that already uses SDP.

Matthew Kaufman


--------------000806070600020408010504
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 3/7/2013 3:01 PM, Silvia Pfeiffer
      wrote:

    

    
On Fri, Mar 8, 2013 at 8:48 AM, Matthew Kaufman <matthew@matthew.at>
      wrote:

      

        

          
On 3/7/2013 1:46 PM, Roman Shpount wrote:

            

              I do not think redefining session description is the best
              approach. Having access to direct API methods that control
              send codecs, send media types, resolution, etc  is easier
              to understand and to program. I think even simply exposing
              the API from Voice and Video engines in current WebRTC
              implementation would be a more usable API then the current
              offer/answer SDP based one.

            

            

          

          There is an existing proposal published by my employer which
          is along these lines. It might be helpful if the folks who are
          just now realizing what the issues are with dealing with both
          the complexity of the format of SDP as well as the embedded
          offer-answer semantics could review that and see how closely
          it matches their needs, rather than starting from a clean
          sheet of paper.

            

        
      

    

    

    No, I was referring to
    http://html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web.htm

    

    

      

        


          I like some of the approaches taken in this proposal.

          I like that there are actual objects for RTCSdpType and
          RTCSessionDescription .

          There are, however, no functions to manipulate a SDP yet.

          

          I assume that the API discussion has to happen in the W3C and
          not here? To be honest, I am not overly fussed as to what
          format the browser deals with - SDP or JSON - though the
          latter is a more natural browser format. I do, however, care
          what the Web developer has to deal with.

        

      

    

    

    The web developer currently is stuck with SDP *and* the SDP
    offer/answer semantics *plus* whatever gets added in MMUSIC to SDP
    in order to actually do everything that's needed (bundle, stream
    identification, etc.)... assuming that the changes to SDP can be
    made while keeping them compatible with everything else that already
    uses SDP.

    

    Matthew Kaufman

    

  


--------------000806070600020408010504--

From finlayson@live555.com  Thu Mar  7 15:25: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 06DC821F869C for ; Thu,  7 Mar 2013 15:25:25 -0800 (PST)
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 EQhh02uQJx17 for ; Thu,  7 Mar 2013 15:25:24 -0800 (PST)
Received: from ns.live555.com (ns.live555.com [4.79.217.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9FC21F869B for ; Thu,  7 Mar 2013 15:25:24 -0800 (PST)
Received: from [127.0.0.1] (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.14.4/8.14.4) with ESMTP id r27NPMAd021003 for ; Thu, 7 Mar 2013 15:25:23 -0800 (PST) (envelope-from finlayson@live555.com)
From: Ross Finlayson 
Content-Type: multipart/alternative; boundary="Apple-Mail=_C9A6715F-E192-4176-9C77-15EC8EE6C3F9"
Message-Id: <1C6A54B3-1878-483B-BFBE-C799C252E0BE@live555.com>
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Date: Fri, 8 Mar 2013 12:25:22 +1300
References:  <5138EB62.9000700@matthew.at>   
To: rtcweb@ietf.org
In-Reply-To: 
X-Mailer: Apple Mail (2.1499)
Subject: Re: [rtcweb] VP8 IPR agreement announced.
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 07 Mar 2013 23:25:25 -0000

--Apple-Mail=_C9A6715F-E192-4176-9C77-15EC8EE6C3F9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

This is indeed excellent news (though one has to wonder: What did "MPEG =
LA" get out of the deal?)

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/


--Apple-Mail=_C9A6715F-E192-4176-9C77-15EC8EE6C3F9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

This =
is indeed excellent news (though one has to wonder: What did "MPEG LA" =
get out of the deal?)


Ross =
Finlayson
Live Networks, Inc.
http://www.live555.com/=




=

--Apple-Mail=_C9A6715F-E192-4176-9C77-15EC8EE6C3F9--

From silviapfeiffer1@gmail.com  Thu Mar  7 15:53: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 BDEE021F86EA for ; Thu,  7 Mar 2013 15:53:07 -0800 (PST)
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 6WISNn2ipPco for ; Thu,  7 Mar 2013 15:53:06 -0800 (PST)
Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3E68121F86EF for ; Thu,  7 Mar 2013 15:53:06 -0800 (PST)
Received: by mail-lb0-f174.google.com with SMTP id l12so911181lbo.33 for ; Thu, 07 Mar 2013 15:53:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=KrTP5lx9PxXBswXLyS6/64Q9MPCsvcJOhhs15GLXFlA=; b=nOEGh58JqMHtt8tFLvo2Xx3VN5apk8MdsQaju5HOoEa1u40Co5cesOWrWBdzxfpxI9 8U8jxXztx52m18sLNAeidhI7BBY7K9fY2L90zh58e8oxMBEtK+7SYyW4VscKmBJxmyCK au0b68JjPFDR5p3Yga9nHCNsclIRRp8a/cefBSnuDn6cYYoq9nhBXsWDl3+AN7mNLfYT myPHChFtEp/LHf09klEsRjw1VhbnlJzimAwgh/A0Xpq3k+ppJew6j+YsmoQG3zoNDnWB jNX2DYZea8BEa13SB5uUNXgs2GfujFHMxAx2C+2WN0KCqrNmyD6vPysD20RCBaWwgB3n XZnw==
X-Received: by 10.112.103.196 with SMTP id fy4mr229074lbb.125.1362700385115; Thu, 07 Mar 2013 15:53:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.51.229 with HTTP; Thu, 7 Mar 2013 15:52:45 -0800 (PST)
In-Reply-To: <51391E5E.4080007@matthew.at>
References:            <51390B3C.7010203@matthew.at>  <51391E5E.4080007@matthew.at>
From: Silvia Pfeiffer 
Date: Fri, 8 Mar 2013 10:52:45 +1100
Message-ID: 
To: Matthew Kaufman 
Content-Type: multipart/alternative; boundary=f46d0401f93763ea9e04d75e68dd
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Thu, 07 Mar 2013 23:53:07 -0000

--f46d0401f93763ea9e04d75e68dd
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Mar 8, 2013 at 10:10 AM, Matthew Kaufman  wrote:

>  On 3/7/2013 3:01 PM, Silvia Pfeiffer wrote:
>
> On Fri, Mar 8, 2013 at 8:48 AM, Matthew Kaufman wrote:
>
>> On 3/7/2013 1:46 PM, Roman Shpount wrote:
>>
>>> I do not think redefining session description is the best approach.
>>> Having access to direct API methods that control send codecs, send media
>>> types, resolution, etc  is easier to understand and to program. I think
>>> even simply exposing the API from Voice and Video engines in current WebRTC
>>> implementation would be a more usable API then the current offer/answer SDP
>>> based one.
>>>
>>
>>  There is an existing proposal published by my employer which is along
>> these lines. It might be helpful if the folks who are just now realizing
>> what the issues are with dealing with both the complexity of the format of
>> SDP as well as the embedded offer-answer semantics could review that and
>> see how closely it matches their needs, rather than starting from a clean
>> sheet of paper.
>>
>
> I assume you're referring to:
> http://www.w3.org/TR/2012/WD-webrtc-20120821/#rtcsdptype  ?
>
>
> No, I was referring to
> http://html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web.htm
>


I like many features of this proposal and I would love to see it a good
part of it integrated with the existing API.



>  I like some of the approaches taken in this proposal.
> I like that there are actual objects for RTCSdpType and
> RTCSessionDescription .
> There are, however, no functions to manipulate a SDP yet.
>
> I assume that the API discussion has to happen in the W3C and not here? To
> be honest, I am not overly fussed as to what format the browser deals with
> - SDP or JSON - though the latter is a more natural browser format. I do,
> however, care what the Web developer has to deal with.
>
>
> The web developer currently is stuck with SDP *and* the SDP offer/answer
> semantics *plus* whatever gets added in MMUSIC to SDP in order to actually
> do everything that's needed (bundle, stream identification, etc.)...
> assuming that the changes to SDP can be made while keeping them compatible
> with everything else that already uses SDP.
>


So, in your opinion what should change in the SDP offer/answer semantic to
allow for a better API for Web developers along the lines of the above
linked proposal?

Silvia.

--f46d0401f93763ea9e04d75e68dd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 8, 2013 at 10:10 AM, Matthew Kaufman <matthew@matthew.at&=
gt; wrote:



 =20
   =20
 =20
  

    
On 3/7/2013 3:01 PM, Silvia Pfeiffer
      wrote:

    

    
On Fri, Mar 8, 2013 at 8:48 AM, Matthew Kaufm=
an <matthew@matthew.at>
      wrote:

      

        

          
On 3/7/2013 1:46 PM, Roman Shpount wrote:

            

              I do not think redefining session description is the best
              approach. Having access to direct API methods that control
              send codecs, send media types, resolution, etc =A0is easier
              to understand and to program. I think even simply exposing
              the API from Voice and Video engines in current WebRTC
              implementation would be a more usable API then the current
              offer/answer SDP based one.

            

            

          

          There is an existing proposal published by my employer which
          is along these lines. It might be helpful if the folks who are
          just now realizing what the issues are with dealing with both
          the complexity of the format of SDP as well as the embedded
          offer-answer semantics could review that and see how closely
          it matches their needs, rather than starting from a clean
          sheet of paper.

            

        
      

    

    

    No, I was referring to
    http://html5labs.interoperabilitybridges.com/=
cu-rtc-web/cu-rtc-web.htm


I like many fe=
atures of this proposal and I would love to see it a good part of it integr=
ated with the existing API.






    

      
I like some of the approaches taken in thi=
s proposal.

          I like that there are actual objects for RTCSdpType and
          RTCSessionDescription .

          There are, however, no functions to manipulate a SDP yet.

          

          I assume that the API discussion has to happen in the W3C and
          not here? To be honest, I am not overly fussed as to what
          format the browser deals with - SDP or JSON - though the
          latter is a more natural browser format. I do, however, care
          what the Web developer has to deal with.

        

      

    

    

    The web developer currently is stuck with SDP *and* the SDP
    offer/answer semantics *plus* whatever gets added in MMUSIC to SDP
    in order to actually do everything that's needed (bundle, stream
    identification, etc.)... assuming that the changes to SDP can be
    made while keeping them compatible with everything else that already
    uses SDP.


So, in your opinion what should change in the=
 SDP offer/answer semantic to allow for a better API for Web developers alo=
ng the lines of the above linked proposal?



Silvia.


--f46d0401f93763ea9e04d75e68dd--

From tterriberry@mozilla.com  Thu Mar  7 16: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 02A1621F86BC for ; Thu,  7 Mar 2013 16:28:58 -0800 (PST)
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 HOopQdNIzXhJ for ; Thu,  7 Mar 2013 16:28:56 -0800 (PST)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id D8FC921F869C for ; Thu,  7 Mar 2013 16:28:56 -0800 (PST)
Received: from [10.250.6.54] (unknown [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 779A4F2347 for ; Thu,  7 Mar 2013 16:28:56 -0800 (PST)
Message-ID: <513930C8.6050900@mozilla.com>
Date: Thu, 07 Mar 2013 16:28:56 -0800
From: "Timothy B. Terriberry" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120626 SeaMonkey/2.10.1
MIME-Version: 1.0
To: "" 
References:         
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Fri, 08 Mar 2013 00:28:58 -0000

Silvia Pfeiffer wrote:
> For example: the programmer wants to say - I want to get this video
> resolution, this audio bitrate & channels, I want to use this camera and
> this microphone for this call. Having to manipulate SDP directly for
> this is a programmer's nightmare.

I would like to point out that the currently proposed W3C APIs do not 
require (or even allow) SDP manipulation for _any_ of this, with the 
possible exception of audio bitrate (which, as we've long discussed, 
should actually be adapted in real-time based on available bandwidth as 
determined by congestion control, with some app-provided way to set 
priorities that will _not_ be based on SDP... the number in SDP merely 
defines the limits of what's possible).

From silviapfeiffer1@gmail.com  Thu Mar  7 18:56: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 BB48A21F862B for ; Thu,  7 Mar 2013 18:56:38 -0800 (PST)
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 V5UByzt-ZlIB for ; Thu,  7 Mar 2013 18:56:38 -0800 (PST)
Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id C72D221F862A for ; Thu,  7 Mar 2013 18:56:37 -0800 (PST)
Received: by mail-lb0-f179.google.com with SMTP id j14so973969lbo.24 for ; Thu, 07 Mar 2013 18:56:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Qt+g2U7SJ7aBltH/cVL0GlKz/pA5xK+YMMlsFs2/omw=; b=MCAS4yE/JlDfdV+Qrm8VVPEvObPPBjZg68TCzNQPUJh1azUEIHrEAZjk1dGqWNEY5b WzmMbaMIvdPl7zl8Jx9uWJOlR/Gp+OWObhbXjlKDubFK9hdyNQnXqxy3yTm4TsHMl5Mn OVHg7QTJLfQm1lqMC67hjMJkA8cWi6ww2e+VN2VZNV6x/jfvda3VTXdw//+pgxypJfbN 5lGx7pydG+cv5Jv+tyTLKasLqwH8m5U++NFUyAAfOcVaV0L4HofT8GmgQRHKT+sQU8lm rGkXfZuieBqWwvzc9caYozPy5ezM3ep/Ornjx1qDlG2Tgr2YBPQMBa6CaB7Lr8WRfKW+ Ab9Q==
X-Received: by 10.152.109.112 with SMTP id hr16mr502738lab.38.1362711396473; Thu, 07 Mar 2013 18:56:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.51.229 with HTTP; Thu, 7 Mar 2013 18:56:16 -0800 (PST)
In-Reply-To: <513930C8.6050900@mozilla.com>
References:          <513930C8.6050900@mozilla.com>
From: Silvia Pfeiffer 
Date: Fri, 8 Mar 2013 13:56:16 +1100
Message-ID: 
To: "Timothy B. Terriberry" 
Content-Type: multipart/alternative; boundary=bcaec54eea70b7e56904d760f8ce
Cc: "" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Fri, 08 Mar 2013 02:56:38 -0000

--bcaec54eea70b7e56904d760f8ce
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Mar 8, 2013 at 11:28 AM, Timothy B. Terriberry <
tterriberry@mozilla.com> wrote:

> Silvia Pfeiffer wrote:
>
>> For example: the programmer wants to say - I want to get this video
>> resolution, this audio bitrate & channels, I want to use this camera and
>> this microphone for this call. Having to manipulate SDP directly for
>> this is a programmer's nightmare.
>>
>
> I would like to point out that the currently proposed W3C APIs do not
> require (or even allow) SDP manipulation for _any_ of this, with the
> possible exception of audio bitrate (which, as we've long discussed, should
> actually be adapted in real-time based on available bandwidth as determined
> by congestion control, with some app-provided way to set priorities that
> will _not_ be based on SDP... the number in SDP merely defines the limits
> of what's possible).


Is there any way for the Web developer to influence the negotiation of,
say, the video resolution? For example, if the video is displayed in a
160x120 video element, then it makes no sense to receive anything larger
than that resolution. I was under the impression that this would have to be
done through manipulating SDP?

Silvia.

--bcaec54eea70b7e56904d760f8ce
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 8, 2013 at 11:28 AM, Timothy B. Terriberry &l=
t;tterriberry@=
mozilla.com> wrote:



Silvia Pfeiffer wrote:



For example: the programmer wants to say - I want to get this video

resolution, this audio bitrate & channels, I want to use this camera an=
d

this microphone for this call. Having to manipulate SDP directly for

this is a programmer's nightmare.





I would like to point out that the currently proposed W3C APIs do not requi=
re (or even allow) SDP manipulation for _any_ of this, with the possible ex=
ception of audio bitrate (which, as we've long discussed, should actual=
ly be adapted in real-time based on available bandwidth as determined by co=
ngestion control, with some app-provided way to set priorities that will _n=
ot_ be based on SDP... the number in SDP merely defines the limits of what&=
#39;s possible).


Is there any way for the Web developer to influence the negotiation of,=
 say, the video resolution? For example, if the video is displayed in a 160=
x120 video element, then it makes no sense to receive anything larger than =
that resolution. I was under the impression that this would have to be done=
 through manipulating SDP?



Silvia.


--bcaec54eea70b7e56904d760f8ce--

From tterriberry@mozilla.com  Thu Mar  7 19:05: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 EC31521F869C for ; Thu,  7 Mar 2013 19:05:17 -0800 (PST)
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 homLlb28WOhf for ; Thu,  7 Mar 2013 19:05:15 -0800 (PST)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id DFEF321F8512 for ; Thu,  7 Mar 2013 19:05:15 -0800 (PST)
Received: from [10.250.6.54] (unknown [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id C2356F22BE for ; Thu,  7 Mar 2013 19:05:13 -0800 (PST)
Message-ID: <51395569.4030603@mozilla.com>
Date: Thu, 07 Mar 2013 19:05:13 -0800
From: "Timothy B. Terriberry" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120626 SeaMonkey/2.10.1
MIME-Version: 1.0
To: "" 
References:          <513930C8.6050900@mozilla.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Fri, 08 Mar 2013 03:05:18 -0000

Silvia Pfeiffer wrote:
> Is there any way for the Web developer to influence the negotiation of,
> say, the video resolution? For example, if the video is displayed in a
> 160x120 video element, then it makes no sense to receive anything larger
> than that resolution. I was under the impression that this would have to
> be done through manipulating SDP?

Again, that would be done via constraints:
http://tools.ietf.org/html/draft-alvestrand-constraints-resolution-00#section-4

See Section 3.1 for examples involving gUM... the draft doesn't have any 
examples, but these same constraints could be applied to incoming 
streams using the settings API currently under discussion in the W3C. 
It's perhaps an open question whether or not a 

Without going into tremendous det=
ails (which believe me, I could), I'm going to summarize the reasons wh=
y I believe it's a bad idea to include SDP:

- =
increases incompatibilities


- support nightmare (whose to blame when the format introduces problem=
s and features are injected into SDP along the way)
- bad user ex=
perience (protocol will be brittle)
- non predictable behavior, i=
.e. not an API-contract (receiving side can't predict or control implie=
d logic, behaviours, etc)


- forces SDP to be standard on all future protocols (not advisable or =
too dangerous to parse SDP but some will have to in order to send as altern=
ative format and then reassemble)
- offer / answer actually break=
s other concepts of state machines


- offer / answer forces problems that don=92t need to exist when done =
differently (roll back, simultaneous negation cross over, SSRC clashes, kno=
wledge of remote party's state)
- does not really solve legac=
y compatibility (would likely increase legacy incompatibility IMHO)


- truly is not needed
- initially simpler for some programme=
rs but at the cost of tremendous pain forever for others
- foreve=
r hamper future technologies and burden them with SIP issues

- make browsers much more difficult to innovate
- make new protoc=
ols much more difficult to innovate
- will cause the introduction=
 of SBCs to sanitize the SDPs mid point to correct compatibility issues

- cause rollouts of new browser versions with even the tiniest of SDP =
changes to break countless existing devices


I have to strongly reiterate. It's not just the format. It'=
;s the concept. I know there is the argument "we need some data to be =
exchanged and this is close to what we need". Absolutely, we need data=
 but it can be at the split by only what each component actually needs rath=
er than one big monolithic thing. Many parts of the information are the rel=
ationships between media. I strongly prefer to assemble relationships with =
code control than with monolithic blobs.



Again, it's not necessary to have the blob at all. =
Take CR-RTCWEB for example, they have objects that each independently take =
the information for each component and then you wire the components togethe=
r. Is it perfect? No, but that's the kind of API that would make future=
 stuff much more possible/better. (Not pushing them, just using as an examp=
le.)



Would a JSONified version be better? Perhaps. It could =
be treated as one big function call with JSONified arguments. The format is=
 certainly nicer. But I think that will cause a large amount of arguments a=
s to what that should be and in order to make it flexible. I would be happi=
er I suppose, especially if it got rid of offer/answer but I don't thin=
k all the problems are truly solved. Perhaps if that's all that we coul=
d "win" it might be better but I'm not sure it won't intr=
oduce new problems either.



I completely agree with Erik's suggestion: Expose a=
 lower layer stream API, without SDP and without offer/answer and then crea=
te a library (perhaps entirely JS) that mimics the behavior of the current =
drafts on top of the lower layers. The SIP people get exactly what they wan=
t and think they need and those that need lower to innovate new stuff get w=
hat they absolutely need.



Benefits: Both sides win and nobody loses. This should =
not be any harder to make since all that logic is layered internally this w=
ay anyway (it must be). Better still, Microsoft/IE can be brought back into=
 the mix and the proposals can be reunited. Perhaps I'm an idealist tho=
ugh with rose coloured glasses.



If we lock into SDP, the long-term implications will be=
 very bad for WebRTC (IMHO). Ultimately, whatever is imposed, I will adopt =
and adapt. In our case, we'll have to make a really tough choice of how=
 we will have to mess with SDP or make wonky work-arounds for the problems =
SDP introduces.



If forced to use SDP, are any others willing to work on=
 a common JS library with us for the sender/receiver that extracts the SDP =
from the browsers into informational structures, manipulates the data (comp=
letely outside of the browser APIs which tie it to real streams), and sanit=
izes/normalizes the SDP behaviours to make it more contractual/predictable =
in behaviour? I really don't like this idea but if we are forced to use=
 SDP then at least it would be better to have a common library to handle th=
e pain of manipulating the SDP for those who can't avoid it. I'd pr=
efer not introduce yet another set of incompatibilities between all of us t=
hat will need to do it.





--047d7bb04ed67eb87c04d769b625--

From pthatcher@google.com  Fri Mar  8 05:51: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 B421D21F863A for ; Fri,  8 Mar 2013 05:51:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.76
X-Spam-Level: 
X-Spam-Status: No, score=-102.76 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 JfzAUTk2FlrB for ; Fri,  8 Mar 2013 05:50:58 -0800 (PST)
Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id 1B68621F85D9 for ; Fri,  8 Mar 2013 05:50:57 -0800 (PST)
Received: by mail-vc0-f178.google.com with SMTP id m8so929644vcd.9 for ; Fri, 08 Mar 2013 05:50:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=0mal0eBwjUF+3ed3IAnmb7S0KLnalttq69OFSHuXdZY=; b=DkrOJyXEZX5GflG5ElRJZlWTpNT7s4UwA97I/VIFEuxlCUPHJqYqWOk1zl70U1O4vO qEg83Fvj+6zDVDF6n4X/4RCtPpNplGlPzlp+RW2riRX/h/uhnVfZZ/PqY4VE9dnV572i /8Py6hZm/bfNV/l2sApQhiq7Xk1RzXknnrS8SXkZ2SAz/w4M4xSC+9qQyZ1VpqhPWfJB vbWUGnaD+efB7zBlp6oTNV1qtmE6K8IS+fBiaOBK7B1hRki03uRFalrMgpdB7jQ9A6hc zU5q+j5htKUWOqn3oKXk+qe2mjWxc93Ni/hdbS/CPVdys7jAyWMvdT4J5te0OtDrUCdP KP7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=0mal0eBwjUF+3ed3IAnmb7S0KLnalttq69OFSHuXdZY=; b=Qy1adlHGiOnE8besaZvLJhwKh9gG6W4d2SdLFQpcF+JHu7U9kmCFNAqwvg19nVX83B /RmLRigvfM9cphr5OsM1kGxmsZg1vwcAike0aaKeeNNDOyMrfeLWb6PvuTw5fOhYKswV iOltWZi+cuVsRIo8V5LcfF9RzdGhqHx+9lDkV3oZx8rENgdrUmlP0UdZIp+hE9cCRhbf VWQhb4AtVwwVgsBSo8kuVMgRAwNhsAr0Aap6wR8LuN+TdO4bkTDKsm7aOn29wnj0wpdU qFuaOCoXAvKRk2LD408w8mpZTtawW/28ym5WbTHtvP1gq/F68XyI7xIzrUtsNZlYhCl1 KIgg==
X-Received: by 10.58.48.166 with SMTP id m6mr906652ven.59.1362750657319; Fri, 08 Mar 2013 05:50:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.49.102 with HTTP; Fri, 8 Mar 2013 05:50:17 -0800 (PST)
In-Reply-To: <5139AF4C.70109@ericsson.com>
References:  <5139AF4C.70109@ericsson.com>
From: Peter Thatcher 
Date: Fri, 8 Mar 2013 05:50:17 -0800
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: ALoCoQk8l4QhdLCompktwWKrynJFCgeFLJCXsamIUuOsqjXvQsKw3fn73xU2eOuQZmMaSM8Nn0TmINZXnesNbvqSOi5IeXXf9NTP7+NnvLONLgCm4t6TFzN3Omq1oeRfLirlDGEPtzAqheaKh3xEl+6ZOZ0L/6d8ad1+5LfZoRu4YkViWqGSbjF/xWO0iEp6ZI7ho3WAIRO9
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Fri, 08 Mar 2013 13:51:02 -0000

One the question of "what info do the two endpoints exchange to be
able to set up connection(s) and send and receive audio, video and
data", my  assumption has *not* been SDP, but rather that it has been
left to the javascript application to decide what info to exhange.
I've heard over and over at WebRTC meeting and conferences that
"signalling is not defined; that's up to the javascript application".
I completely agree with that and think we should stick to it.  In
Google Talk/Hangouts, for example, we use Jingle, not SDP.  SDP only
serves as a javascript API surface, not as a format to exchange with
the remote side.

As an application developer I do not want to exchange SDP.  I only use
it as an API surface.  And it looks like I'm not the only application
developer that sees it this way:
- http://s.phono.com/releases/0.6/jquery.phono.js
- https://github.com/lukeweber/webrtc-jingle-client
- https://code.google.com/p/openfire-candy/source/browse/trunk/plugin/candy=
/plugins/voicebridge/webrtc-jingle.js
- https://github.com/mweibel/sdpToJingle

Again, for me, and many others it appears, SDP only serves as a
javascript API surface.








On Fri, Mar 8, 2013 at 1:28 AM, Stefan H=C3=A5kansson LK
 wrote:
> On 2013-03-07 00:45, Robin Raymond wrote:
>>
>>
>>
>>
>>
>>
>> Do we need SDP "blob" format in the exchange in the first place? All med=
ia
>> can be done without SDP given an intelligent stream API. An API already
>> exists to create these streams (albeit somewhat lacking if we remove the
>> SDP 'blob'). This API helps "simplify" creating this blob for later
>> exchange. But the blob is truly not needed. Each side could in fact crea=
te
>> the desired streams, pass in the appropriate media information such as
>> codecs and ICE candidates and chose the socket pair to multiplex upon.
>> Yes, it's a bit more low level but it certainly can be done (and cleanly=
).
>
>
> I think we are mixing up two different things in the discussion. One is
> "what info to the two endpoints exchange to be able to set up connection(=
s)
> and send and receive audio, video and data" and the other is "what APIs
> should we use to control the settings".
>
> For the first part, the assumption has so far been SDP. I think we've all
> realized now that the legacy of SDP gives us quite a bit of headache. I
> think that splitting up signaling about connections (ICE candidates) from
> signaling for media stuff (codecs, how different ssrc's correlate to
> MediaStreamTrack's, ...) would simplify things a lot. But on the other ha=
nd,
> it seems to me that we're really close to nailing those details. I'm pret=
ty
> sure that switching to some other format would cost more in time than we
> gain.
>
> Also, remember that those session descriptions come with a flag saying
> "sdp". This is intentional, it gives us the freedom to change format with=
out
> affecting the application in the future (as long as the application can
> follow the normal createOffer/setLocal etc. procedures).
>
> When it comes to the API, that discussion is really for the W3C webrtc WG=
.
> But as has been said by Tim and Harald already, the session descriptions
> should never be changed in normal cases - there should be (and are) other
> APIs for setting up how a MediaStreamTrack is transported over the networ=
k,
> resolutions, etc. What is set in those APIs will be reflected in the SDP
> created by "createOffer".
>
> Stefan
>
>
>>
>> https://datatracker.ietf.org/doc/draft-jennings-rtcweb-plan/
>>
>> Nothing wrong with the draft in an SDP/SIP mindset but I'm going to take
>> it from a totally different non-SDP angle. I have to say, the ideas
>> presented are very good. I appreciate FEC, and synchronizing streams is
>> cool. But SDP isn=C2=B9t needed to do it. Let me as the programmer worry=
 about
>> how to manage streams and the features on the streams and associations
>> between the streams via an API only.
>>
>> Point 4, 5 and 6 in the specification all have to do with the complexiti=
es
>> of having to describe the intentions of mixing in SDP. So no comment
>> beyond =C2=B3don=C2=B9t use SDP=C2=B2.
>>
>> As for 7.1 =C2=AD =C2=B3this is because the sender choses the SSRC=C2=B2=
 =C2=AD only true
>> because we are forced to use SDP and the assumptions is that it=C2=B9s S=
IP. We
>> could have the receiver dictate what the sender should use in advance of
>> any media. In our case, we establish in advance what we want from all
>> parties before even =C2=B3ringing=C2=B2 the other party. We do not have =
SSRC
>> collisions as we reversed the scenario allowing the receiver to pick the
>> expected SSRC. Coordinating the streams is a problem with SIP because of
>> how they do forking/conferencing. This specification forces this issue o=
n
>> those not using SIP. If SIP has problems with streams arriving early to
>> their stateful offer/answer then let them worry about =C2=B3how=C2=B2 th=
ey intend to
>> match the streams at a higher SDP layer and get this draft out of the
>> RTCWEB track on the SIP track. To be clear, the proposal seems entirely
>> reasonable and intelligent for SIP/SDP. But it=C2=B9s way to SIP centric=
 for
>> general use.
>>
>> On that note, what I do need in the API is an ability to dictate the SSR=
C
>> when I create an RTP stream for sending (should I care to do that).
>>
>> 7.2 Multiple render
>>
>> Again this is an issue of SIP/SDP. We can control the SSRCs to split the=
m
>> out to allow multiplexing easily on the same RTP ports with multiple
>> parties/sources. If given the primitives to control the streams just, th=
is
>> specification could be used to dictate how to negotiate issues in their
>> space.
>>
>> 7.2.1 I=C2=B9m feeling the pain. How about just giving me an API where I=
 can
>> indicate what streams are FEC associated.
>>
>> 7.3 Give me API to give crypto keys to RTP layer. Let me handle the
>> fingerprint and security myself beyond that.
>>
>> 8. Let's just say politely that I would not want to be the developer
>> assigned to programming around all this stuff.
>>
>> Again, a perfect illustration why I don=C2=B9t want SDP.
>>
>> Media is complicated for good reason as there are many untold use cases.
>> The entire IETF/W3C discussion around video constraints illustrates some
>> of the complexities and competing desires for just one single media type=
.
>> If we tie ourselves to SDP we are limiting ourselves big time, and some =
of
>> the cool future stuff will be horribly hampered by it.
>>
>> My issues with SDP can be summarized as:
>>
>> - unneeded - much too high level an API
>> - arcane format - legacy and problematic
>> - offer/answer
>> - incompatibilities
>> - lack of API contact
>> - doesn't truly solve goal of interoperability with legacy systems (eg.
>> SIP)
>>
>> Regret that I did not have time for feedback earlier. As you can tell, I
>> am not at all happy with where we sit today wrt requiring SDP. IMHO we
>> need a lower level API if we are going to insist on using SDP.
>>
>>
>> You can read my entire (long) rant against SDP here
>> http://blog.webrtc.is/2013/03/06/sdp-the-webrtc-boat-anchor/
>>
>>
>>
>> _______________________________________________
>> 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 pthatcher@google.com  Fri Mar  8 06:02: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 E591521F85D9 for ; Fri,  8 Mar 2013 06:02:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.752
X-Spam-Level: 
X-Spam-Status: No, score=-102.752 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, 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 PxBWi7fsf++H for ; Fri,  8 Mar 2013 06:02:26 -0800 (PST)
Received: from mail-ve0-f179.google.com (mail-ve0-f179.google.com [209.85.128.179]) by ietfa.amsl.com (Postfix) with ESMTP id C65D721F8596 for ; Fri,  8 Mar 2013 06:02:25 -0800 (PST)
Received: by mail-ve0-f179.google.com with SMTP id da11so1307233veb.10 for ; Fri, 08 Mar 2013 06:02:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=3glyFVvL1EwncjFCAtH+5BrU93aQW/RY5bKJuFFOeBM=; b=AhYUN7KvwWP5ya8dJOvV88/fV1I5Lw1Y5/xaE9VFRqQEVVhFdAuA3L4yCOV5px+MCi 4obwt9IE2HJ1mXBAj8TA/XsZDU/vQhdpKMc68QCm8N9Jn8FmYtk/viDA93XMYph1WPFY afjFdddvRa/6PzUt95BkmhqnI6m2sjBuxUP0LKwzHqLPQ2HWrDfZisE5sO06LudKquNT HhA5pNGevqZ2tpm5zEQQtiEdyKz6GinE8Ei5BWKKCUG8nLoSdVVDLiHbPGBF37yed6/p EkIJj1ePT7WMD02841Ikqu1ts41XxFZQpl2Z24kKGzVX9gPYHfXNmbbXORTRe2qMKkfx H14g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=3glyFVvL1EwncjFCAtH+5BrU93aQW/RY5bKJuFFOeBM=; b=imyifNnPJBqMNbcCWeI724ZSzAlNukLnOrfojGVduln3Uc9pAWKFSFlj6KYaQ2DbWO bYrN0gb1e1g9jLqurTWEIQS9fFUaLVk5aaejdozbng6I5j7SrrqQLN26Evi+qJ73lzwY 0N5Nt5/wapYFltMRaOnuWvDYkt7oK+BtVtrfuVOpoVn2s8tGrBI07qeqGg4C3eY2Jt6Y vnxX3YlE69z9brvsIT5xgLISefH9xqXfCTp0Hi3YgJSBfNO2kUKHhC28s++RYaobilVV NRWXRmuTuiyupA3AzDHq3jGDFXb4Xi5rzCwEqxknGK0NEWjy4gz9RqT5dvMHcga9vYZ1 dCTQ==
X-Received: by 10.52.33.68 with SMTP id p4mr784341vdi.125.1362751345108; Fri, 08 Mar 2013 06:02:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.49.102 with HTTP; Fri, 8 Mar 2013 06:01:45 -0800 (PST)
In-Reply-To: <5139AF4C.70109@ericsson.com>
References:  <5139AF4C.70109@ericsson.com>
From: Peter Thatcher 
Date: Fri, 8 Mar 2013 06:01:45 -0800
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: ALoCoQkNuiaAx/UrJxY9RGwfktMNBZ0K7UcQXR8/2f8uvSCqeIXI9up4DsVbyKLhUUUMevEqkTjLC/RPtgFzG5kJgYL5sLRA33XA8Sael0r4JFW8qDqyQewu06jFbuh+4L3Gn5G+gKHV1pehscDuW8s6mmdXjmHzd1xpB7degf7dwX9CJJR5Zh80HQcCKSa2xxHVCnWz3RdY
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Fri, 08 Mar 2013 14:02:30 -0000

Stefan, that is a very good point about the W3C.  Should Robin share
his input with the W3C WG rather than this one?

On Fri, Mar 8, 2013 at 1:28 AM, Stefan H=C3=A5kansson LK
 wrote:
> On 2013-03-07 00:45, Robin Raymond wrote:
>>
>>
>>
>>
>>
>>
>> Do we need SDP "blob" format in the exchange in the first place? All med=
ia
>> can be done without SDP given an intelligent stream API. An API already
>> exists to create these streams (albeit somewhat lacking if we remove the
>> SDP 'blob'). This API helps "simplify" creating this blob for later
>> exchange. But the blob is truly not needed. Each side could in fact crea=
te
>> the desired streams, pass in the appropriate media information such as
>> codecs and ICE candidates and chose the socket pair to multiplex upon.
>> Yes, it's a bit more low level but it certainly can be done (and cleanly=
).
>
>
> I think we are mixing up two different things in the discussion. One is
> "what info to the two endpoints exchange to be able to set up connection(=
s)
> and send and receive audio, video and data" and the other is "what APIs
> should we use to control the settings".
>
> For the first part, the assumption has so far been SDP. I think we've all
> realized now that the legacy of SDP gives us quite a bit of headache. I
> think that splitting up signaling about connections (ICE candidates) from
> signaling for media stuff (codecs, how different ssrc's correlate to
> MediaStreamTrack's, ...) would simplify things a lot. But on the other ha=
nd,
> it seems to me that we're really close to nailing those details. I'm pret=
ty
> sure that switching to some other format would cost more in time than we
> gain.
>
> Also, remember that those session descriptions come with a flag saying
> "sdp". This is intentional, it gives us the freedom to change format with=
out
> affecting the application in the future (as long as the application can
> follow the normal createOffer/setLocal etc. procedures).
>
> When it comes to the API, that discussion is really for the W3C webrtc WG=
.
> But as has been said by Tim and Harald already, the session descriptions
> should never be changed in normal cases - there should be (and are) other
> APIs for setting up how a MediaStreamTrack is transported over the networ=
k,
> resolutions, etc. What is set in those APIs will be reflected in the SDP
> created by "createOffer".
>
> Stefan
>
>
>>
>> https://datatracker.ietf.org/doc/draft-jennings-rtcweb-plan/
>>
>> Nothing wrong with the draft in an SDP/SIP mindset but I'm going to take
>> it from a totally different non-SDP angle. I have to say, the ideas
>> presented are very good. I appreciate FEC, and synchronizing streams is
>> cool. But SDP isn=C2=B9t needed to do it. Let me as the programmer worry=
 about
>> how to manage streams and the features on the streams and associations
>> between the streams via an API only.
>>
>> Point 4, 5 and 6 in the specification all have to do with the complexiti=
es
>> of having to describe the intentions of mixing in SDP. So no comment
>> beyond =C2=B3don=C2=B9t use SDP=C2=B2.
>>
>> As for 7.1 =C2=AD =C2=B3this is because the sender choses the SSRC=C2=B2=
 =C2=AD only true
>> because we are forced to use SDP and the assumptions is that it=C2=B9s S=
IP. We
>> could have the receiver dictate what the sender should use in advance of
>> any media. In our case, we establish in advance what we want from all
>> parties before even =C2=B3ringing=C2=B2 the other party. We do not have =
SSRC
>> collisions as we reversed the scenario allowing the receiver to pick the
>> expected SSRC. Coordinating the streams is a problem with SIP because of
>> how they do forking/conferencing. This specification forces this issue o=
n
>> those not using SIP. If SIP has problems with streams arriving early to
>> their stateful offer/answer then let them worry about =C2=B3how=C2=B2 th=
ey intend to
>> match the streams at a higher SDP layer and get this draft out of the
>> RTCWEB track on the SIP track. To be clear, the proposal seems entirely
>> reasonable and intelligent for SIP/SDP. But it=C2=B9s way to SIP centric=
 for
>> general use.
>>
>> On that note, what I do need in the API is an ability to dictate the SSR=
C
>> when I create an RTP stream for sending (should I care to do that).
>>
>> 7.2 Multiple render
>>
>> Again this is an issue of SIP/SDP. We can control the SSRCs to split the=
m
>> out to allow multiplexing easily on the same RTP ports with multiple
>> parties/sources. If given the primitives to control the streams just, th=
is
>> specification could be used to dictate how to negotiate issues in their
>> space.
>>
>> 7.2.1 I=C2=B9m feeling the pain. How about just giving me an API where I=
 can
>> indicate what streams are FEC associated.
>>
>> 7.3 Give me API to give crypto keys to RTP layer. Let me handle the
>> fingerprint and security myself beyond that.
>>
>> 8. Let's just say politely that I would not want to be the developer
>> assigned to programming around all this stuff.
>>
>> Again, a perfect illustration why I don=C2=B9t want SDP.
>>
>> Media is complicated for good reason as there are many untold use cases.
>> The entire IETF/W3C discussion around video constraints illustrates some
>> of the complexities and competing desires for just one single media type=
.
>> If we tie ourselves to SDP we are limiting ourselves big time, and some =
of
>> the cool future stuff will be horribly hampered by it.
>>
>> My issues with SDP can be summarized as:
>>
>> - unneeded - much too high level an API
>> - arcane format - legacy and problematic
>> - offer/answer
>> - incompatibilities
>> - lack of API contact
>> - doesn't truly solve goal of interoperability with legacy systems (eg.
>> SIP)
>>
>> Regret that I did not have time for feedback earlier. As you can tell, I
>> am not at all happy with where we sit today wrt requiring SDP. IMHO we
>> need a lower level API if we are going to insist on using SDP.
>>
>>
>> You can read my entire (long) rant against SDP here
>> http://blog.webrtc.is/2013/03/06/sdp-the-webrtc-boat-anchor/
>>
>>
>>
>> _______________________________________________
>> 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 stefan.lk.hakansson@ericsson.com  Fri Mar  8 06:04: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 B4B7221F85DB for ; Fri,  8 Mar 2013 06:04:49 -0800 (PST)
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=[AWL=0.000,  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 MYN0vuKqaNb3 for ; Fri,  8 Mar 2013 06:04:45 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5665F21F85D9 for ; Fri,  8 Mar 2013 06:04:42 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-40-5139eff9719e
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B2.14.32353.9FFE9315; Fri,  8 Mar 2013 15:04:41 +0100 (CET)
Received: from [150.132.141.119] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Fri, 8 Mar 2013 15:04:40 +0100
Message-ID: <5139EFF8.7040603@ericsson.com>
Date: Fri, 8 Mar 2013 15:04:40 +0100
From: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Peter Thatcher 
References:  <5139AF4C.70109@ericsson.com> 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmluLIzCtJLcpLzFFi42KZGfG3Rvfne8tAgyn35CyuLX/NarH2Xzu7 A5PHgk2lHkuW/GQKYIrisklJzcksSy3St0vgynjTfICp4K59xarT09gbGNcYdzFyckgImEic O7eTCcIWk7hwbz1bFyMXh5DASUaJSd1z2CGcNYwSlzdOYgWp4hXQlvg/v4Gli5GDg0VAReL2 fy+QMJtAsMT+5SDNHByiAlESV/ZZQlQLSpyc+YQFxBYR0JSYPLkZbAqzgLrEncXn2EFsYaDy r89+QO2dxCix+fhtsASnQKBE95pX7BANFhKL3xyEsuUlmrfOZgaxhQR0Jd69vsc6gVFwFpJ9 s5C0zELSsoCReRUje25iZk56ufkmRmBAHtzy22AH46b7YocYpTlYlMR5w10vBAgJpCeWpGan phakFsUXleakFh9iZOLglGpgXPRJapKMzY+H640d71gEWnTXtLav2c1xrXHTnKfHiz9WZV/9 yHetdcnba+yGG4Wm3+v+vXuftHij2z5rgUMHFbgTrnHtmZRjuehOcNIVG7PW3zZh4t/CPGZ0 aD2uNKs9p/fp84OJLRx2Qe/We3N8qDNd2upv7fJl4unijWsUvYpKXBfvit1orMRSnJFoqMVc VJwIAGCZCowWAgAA
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Fri, 08 Mar 2013 14:04:49 -0000

On 2013-03-08 14:50, Peter Thatcher wrote:
> One the question of "what info do the two endpoints exchange to be
> able to set up connection(s) and send and receive audio, video and
> data", my  assumption has *not* been SDP, but rather that it has been
> left to the javascript application to decide what info to exhange.
> I've heard over and over at WebRTC meeting and conferences that
> "signalling is not defined; that's up to the javascript application".

I agree to the above - signaling is entirely up to the application. I'm 
sorry if my message gave another impression. But we need to define the 
format of the "blobs" (if we call them that) that browser A produces so 
that they can be plumbed into browser B and things work. So far the 
assumption has been that those blobs are SDP descriptions, and my point 
is that changing that to something else may cost us more than we gain.

> I completely agree with that and think we should stick to it.  In
> Google Talk/Hangouts, for example, we use Jingle, not SDP.  SDP only
> serves as a javascript API surface, not as a format to exchange with
> the remote side.
>
> As an application developer I do not want to exchange SDP.  I only use
> it as an API surface.  And it looks like I'm not the only application
> developer that sees it this way:
> - http://s.phono.com/releases/0.6/jquery.phono.js
> - https://github.com/lukeweber/webrtc-jingle-client
> - https://code.google.com/p/openfire-candy/source/browse/trunk/plugin/candy/plugins/voicebridge/webrtc-jingle.js
> - https://github.com/mweibel/sdpToJingle
>
> Again, for me, and many others it appears, SDP only serves as a
> javascript API surface.
>
>
>
>
>
>
>
>
> On Fri, Mar 8, 2013 at 1:28 AM, Stefan HÃ¥kansson LK
>  wrote:
>> On 2013-03-07 00:45, Robin Raymond wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>> Do we need SDP "blob" format in the exchange in the first place? All media
>>> can be done without SDP given an intelligent stream API. An API already
>>> exists to create these streams (albeit somewhat lacking if we remove the
>>> SDP 'blob'). This API helps "simplify" creating this blob for later
>>> exchange. But the blob is truly not needed. Each side could in fact create
>>> the desired streams, pass in the appropriate media information such as
>>> codecs and ICE candidates and chose the socket pair to multiplex upon.
>>> Yes, it's a bit more low level but it certainly can be done (and cleanly).
>>
>>
>> I think we are mixing up two different things in the discussion. One is
>> "what info to the two endpoints exchange to be able to set up connection(s)
>> and send and receive audio, video and data" and the other is "what APIs
>> should we use to control the settings".
>>
>> For the first part, the assumption has so far been SDP. I think we've all
>> realized now that the legacy of SDP gives us quite a bit of headache. I
>> think that splitting up signaling about connections (ICE candidates) from
>> signaling for media stuff (codecs, how different ssrc's correlate to
>> MediaStreamTrack's, ...) would simplify things a lot. But on the other hand,
>> it seems to me that we're really close to nailing those details. I'm pretty
>> sure that switching to some other format would cost more in time than we
>> gain.
>>
>> Also, remember that those session descriptions come with a flag saying
>> "sdp". This is intentional, it gives us the freedom to change format without
>> affecting the application in the future (as long as the application can
>> follow the normal createOffer/setLocal etc. procedures).
>>
>> When it comes to the API, that discussion is really for the W3C webrtc WG.
>> But as has been said by Tim and Harald already, the session descriptions
>> should never be changed in normal cases - there should be (and are) other
>> APIs for setting up how a MediaStreamTrack is transported over the network,
>> resolutions, etc. What is set in those APIs will be reflected in the SDP
>> created by "createOffer".
>>
>> Stefan
>>
>>
>>>
>>> https://datatracker.ietf.org/doc/draft-jennings-rtcweb-plan/
>>>
>>> Nothing wrong with the draft in an SDP/SIP mindset but I'm going to take
>>> it from a totally different non-SDP angle. I have to say, the ideas
>>> presented are very good. I appreciate FEC, and synchronizing streams is
>>> cool. But SDP isn¹t needed to do it. Let me as the programmer worry about
>>> how to manage streams and the features on the streams and associations
>>> between the streams via an API only.
>>>
>>> Point 4, 5 and 6 in the specification all have to do with the complexities
>>> of having to describe the intentions of mixing in SDP. So no comment
>>> beyond ³don¹t use SDP².
>>>
>>> As for 7.1 ­ ³this is because the sender choses the SSRC² ­ only true
>>> because we are forced to use SDP and the assumptions is that it¹s SIP. We
>>> could have the receiver dictate what the sender should use in advance of
>>> any media. In our case, we establish in advance what we want from all
>>> parties before even ³ringing² the other party. We do not have SSRC
>>> collisions as we reversed the scenario allowing the receiver to pick the
>>> expected SSRC. Coordinating the streams is a problem with SIP because of
>>> how they do forking/conferencing. This specification forces this issue on
>>> those not using SIP. If SIP has problems with streams arriving early to
>>> their stateful offer/answer then let them worry about ³how² they intend to
>>> match the streams at a higher SDP layer and get this draft out of the
>>> RTCWEB track on the SIP track. To be clear, the proposal seems entirely
>>> reasonable and intelligent for SIP/SDP. But it¹s way to SIP centric for
>>> general use.
>>>
>>> On that note, what I do need in the API is an ability to dictate the SSRC
>>> when I create an RTP stream for sending (should I care to do that).
>>>
>>> 7.2 Multiple render
>>>
>>> Again this is an issue of SIP/SDP. We can control the SSRCs to split them
>>> out to allow multiplexing easily on the same RTP ports with multiple
>>> parties/sources. If given the primitives to control the streams just, this
>>> specification could be used to dictate how to negotiate issues in their
>>> space.
>>>
>>> 7.2.1 I¹m feeling the pain. How about just giving me an API where I can
>>> indicate what streams are FEC associated.
>>>
>>> 7.3 Give me API to give crypto keys to RTP layer. Let me handle the
>>> fingerprint and security myself beyond that.
>>>
>>> 8. Let's just say politely that I would not want to be the developer
>>> assigned to programming around all this stuff.
>>>
>>> Again, a perfect illustration why I don¹t want SDP.
>>>
>>> Media is complicated for good reason as there are many untold use cases.
>>> The entire IETF/W3C discussion around video constraints illustrates some
>>> of the complexities and competing desires for just one single media type.
>>> If we tie ourselves to SDP we are limiting ourselves big time, and some of
>>> the cool future stuff will be horribly hampered by it.
>>>
>>> My issues with SDP can be summarized as:
>>>
>>> - unneeded - much too high level an API
>>> - arcane format - legacy and problematic
>>> - offer/answer
>>> - incompatibilities
>>> - lack of API contact
>>> - doesn't truly solve goal of interoperability with legacy systems (eg.
>>> SIP)
>>>
>>> Regret that I did not have time for feedback earlier. As you can tell, I
>>> am not at all happy with where we sit today wrt requiring SDP. IMHO we
>>> need a lower level API if we are going to insist on using SDP.
>>>
>>>
>>> You can read my entire (long) rant against SDP here
>>> http://blog.webrtc.is/2013/03/06/sdp-the-webrtc-boat-anchor/
>>>
>>>
>>>
>>> _______________________________________________
>>> 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 stefan.lk.hakansson@ericsson.com  Fri Mar  8 06:05: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 DF78221F8626 for ; Fri,  8 Mar 2013 06:05:56 -0800 (PST)
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=[AWL=0.000,  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 SoixV9uvJJHI for ; Fri,  8 Mar 2013 06:05:51 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2752321F85E0 for ; Fri,  8 Mar 2013 06:05:50 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-99-5139f03ee90b
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id AF.44.32353.E30F9315; Fri,  8 Mar 2013 15:05:50 +0100 (CET)
Received: from [150.132.141.119] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Fri, 8 Mar 2013 15:05:49 +0100
Message-ID: <5139F03D.1010009@ericsson.com>
Date: Fri, 8 Mar 2013 15:05:49 +0100
From: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Peter Thatcher 
References:  <5139AF4C.70109@ericsson.com> 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3Rtfug2Wgwe8OYYtry1+zWqz9187u wOSxYFOpx5IlP5kCmKK4bFJSczLLUov07RK4MpqP7WErmGxS0fzqP3sD4w/NLkZODgkBE4k7 81ayQdhiEhfurQeyuTiEBE4ySvSdXwjlrGGUuLCrixWkildAW+J42xVmEJtFQEVi+f9zYDab QLDE/uUg3RwcogJRElf2WUKUC0qcnPmEBcQWEdCUmDy5GWwMs4C6xJ3F59hBbGGg8q/PfkDt msQo8fFJM1gDp0CgxOKFjewQDRYSi98chLLlJZq3zgbbKySgK/Hu9T3WCYyCs5Dsm4WkZRaS lgWMzKsY2XMTM3PSy803MQJD8uCW3wY7GDfdFzvEKM3BoiTOG+56IUBIID2xJDU7NbUgtSi+ qDQntfgQIxMHp1QD4+TiLbUr/bapP9gQNSlR+U+9V+f/KVv+d/1YG7T51tGjjSqhR55VXOF7 E6fTl1n25bbip/MBkw59C7257+aFj06vLTe/PvTPsZ6547pj0nrzZ4ceSOb8FXm6d0uDdlCf pUTThZCc9tyawwGPtri9jw7Q6T54OHha9K4zayK+8Wi8ts+wnpvNPUuJpTgj0VCLuag4EQCA MfaHFwIAAA==
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Fri, 08 Mar 2013 14:05:57 -0000

On 2013-03-08 15:01, Peter Thatcher wrote:
> Stefan, that is a very good point about the W3C.  Should Robin share
> his input with the W3C WG rather than this one?

He should at least send his input there as well.

Stefan

>
> On Fri, Mar 8, 2013 at 1:28 AM, Stefan HÃ¥kansson LK
>  wrote:
>> On 2013-03-07 00:45, Robin Raymond wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>> Do we need SDP "blob" format in the exchange in the first place? All media
>>> can be done without SDP given an intelligent stream API. An API already
>>> exists to create these streams (albeit somewhat lacking if we remove the
>>> SDP 'blob'). This API helps "simplify" creating this blob for later
>>> exchange. But the blob is truly not needed. Each side could in fact create
>>> the desired streams, pass in the appropriate media information such as
>>> codecs and ICE candidates and chose the socket pair to multiplex upon.
>>> Yes, it's a bit more low level but it certainly can be done (and cleanly).
>>
>>
>> I think we are mixing up two different things in the discussion. One is
>> "what info to the two endpoints exchange to be able to set up connection(s)
>> and send and receive audio, video and data" and the other is "what APIs
>> should we use to control the settings".
>>
>> For the first part, the assumption has so far been SDP. I think we've all
>> realized now that the legacy of SDP gives us quite a bit of headache. I
>> think that splitting up signaling about connections (ICE candidates) from
>> signaling for media stuff (codecs, how different ssrc's correlate to
>> MediaStreamTrack's, ...) would simplify things a lot. But on the other hand,
>> it seems to me that we're really close to nailing those details. I'm pretty
>> sure that switching to some other format would cost more in time than we
>> gain.
>>
>> Also, remember that those session descriptions come with a flag saying
>> "sdp". This is intentional, it gives us the freedom to change format without
>> affecting the application in the future (as long as the application can
>> follow the normal createOffer/setLocal etc. procedures).
>>
>> When it comes to the API, that discussion is really for the W3C webrtc WG.
>> But as has been said by Tim and Harald already, the session descriptions
>> should never be changed in normal cases - there should be (and are) other
>> APIs for setting up how a MediaStreamTrack is transported over the network,
>> resolutions, etc. What is set in those APIs will be reflected in the SDP
>> created by "createOffer".
>>
>> Stefan
>>
>>
>>>
>>> https://datatracker.ietf.org/doc/draft-jennings-rtcweb-plan/
>>>
>>> Nothing wrong with the draft in an SDP/SIP mindset but I'm going to take
>>> it from a totally different non-SDP angle. I have to say, the ideas
>>> presented are very good. I appreciate FEC, and synchronizing streams is
>>> cool. But SDP isn¹t needed to do it. Let me as the programmer worry about
>>> how to manage streams and the features on the streams and associations
>>> between the streams via an API only.
>>>
>>> Point 4, 5 and 6 in the specification all have to do with the complexities
>>> of having to describe the intentions of mixing in SDP. So no comment
>>> beyond ³don¹t use SDP².
>>>
>>> As for 7.1 ­ ³this is because the sender choses the SSRC² ­ only true
>>> because we are forced to use SDP and the assumptions is that it¹s SIP. We
>>> could have the receiver dictate what the sender should use in advance of
>>> any media. In our case, we establish in advance what we want from all
>>> parties before even ³ringing² the other party. We do not have SSRC
>>> collisions as we reversed the scenario allowing the receiver to pick the
>>> expected SSRC. Coordinating the streams is a problem with SIP because of
>>> how they do forking/conferencing. This specification forces this issue on
>>> those not using SIP. If SIP has problems with streams arriving early to
>>> their stateful offer/answer then let them worry about ³how² they intend to
>>> match the streams at a higher SDP layer and get this draft out of the
>>> RTCWEB track on the SIP track. To be clear, the proposal seems entirely
>>> reasonable and intelligent for SIP/SDP. But it¹s way to SIP centric for
>>> general use.
>>>
>>> On that note, what I do need in the API is an ability to dictate the SSRC
>>> when I create an RTP stream for sending (should I care to do that).
>>>
>>> 7.2 Multiple render
>>>
>>> Again this is an issue of SIP/SDP. We can control the SSRCs to split them
>>> out to allow multiplexing easily on the same RTP ports with multiple
>>> parties/sources. If given the primitives to control the streams just, this
>>> specification could be used to dictate how to negotiate issues in their
>>> space.
>>>
>>> 7.2.1 I¹m feeling the pain. How about just giving me an API where I can
>>> indicate what streams are FEC associated.
>>>
>>> 7.3 Give me API to give crypto keys to RTP layer. Let me handle the
>>> fingerprint and security myself beyond that.
>>>
>>> 8. Let's just say politely that I would not want to be the developer
>>> assigned to programming around all this stuff.
>>>
>>> Again, a perfect illustration why I don¹t want SDP.
>>>
>>> Media is complicated for good reason as there are many untold use cases.
>>> The entire IETF/W3C discussion around video constraints illustrates some
>>> of the complexities and competing desires for just one single media type.
>>> If we tie ourselves to SDP we are limiting ourselves big time, and some of
>>> the cool future stuff will be horribly hampered by it.
>>>
>>> My issues with SDP can be summarized as:
>>>
>>> - unneeded - much too high level an API
>>> - arcane format - legacy and problematic
>>> - offer/answer
>>> - incompatibilities
>>> - lack of API contact
>>> - doesn't truly solve goal of interoperability with legacy systems (eg.
>>> SIP)
>>>
>>> Regret that I did not have time for feedback earlier. As you can tell, I
>>> am not at all happy with where we sit today wrt requiring SDP. IMHO we
>>> need a lower level API if we are going to insist on using SDP.
>>>
>>>
>>> You can read my entire (long) rant against SDP here
>>> http://blog.webrtc.is/2013/03/06/sdp-the-webrtc-boat-anchor/
>>>
>>>
>>>
>>> _______________________________________________
>>> 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 pthatcher@google.com  Fri Mar  8 06:08: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 762DA21F8615 for ; Fri,  8 Mar 2013 06:08:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.745
X-Spam-Level: 
X-Spam-Status: No, score=-102.745 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 iL4DXU4h1g-r for ; Fri,  8 Mar 2013 06:08:25 -0800 (PST)
Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by ietfa.amsl.com (Postfix) with ESMTP id 33A7821F8697 for ; Fri,  8 Mar 2013 06:08:25 -0800 (PST)
Received: by mail-vc0-f176.google.com with SMTP id fk10so919003vcb.7 for ; Fri, 08 Mar 2013 06:08:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=hMxjMGkGwYeeufgRmIkfQkWd6Acsc/p0eM0HE1PWxDw=; b=fYJEYYX1A6bU2h9HiBu+VFTJFa2LZESQgXfftqmcDQGLuFYX54qDNrngpWlW+WYq2i fwGJdkzr2piMd9o8H2SJEwjmkK43LaECzK0hm4oqqn+CtRN1NIyr9jQkH5rRG4EWZDZA JHSCpouprhu9C4ck7ChLEjH4maORS95d5DNy9aJcWWAX8296mCMrC2qEjjQdLKg6MgyN LGnbvag65o8Kd4faZ3x+lRk8rkpPKx4r4ZFtgOxl+tQD6ip97b6w5D3sBxz0HmMRBzsR S+WYS1RFVU4QetqSGhSwuIxUmA7SNg6d/fjL71ZOk3tqB+aPhZ2jZjCMw3nOD+e080Wy 5gJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=hMxjMGkGwYeeufgRmIkfQkWd6Acsc/p0eM0HE1PWxDw=; b=nw7vwe9TQe0qk8hzAT+riBzmrocb4fZxmiQFsP8imwItUxHWBq0rG4Ilp1j8q+lwjb yui5dEAwv+EenKEQVKaz0Sp76Q+sPQ+Owu/CbYwKEpZGxfwPwPQKWh/EWksxeusPZtc5 1OgqGpLmJIfK7hMOlvrfN5CVaJ8h/5rer10p5GjJ6ubZJMJe3rsRoTE7hjcHj+xGcnpL fZFzMN0nrWWvEKiF59UgKZYFOs3JzCKrb8JxHR06jntgSZTR63wsB34tmdUUG/W7T02z uiIOKYjyLr+P4iA7zEGPgix1BuB2ciJx7CAIIhSF5uEJxlfjkJg80ijvtIv8ieh2LnAT SBoQ==
X-Received: by 10.220.223.14 with SMTP id ii14mr943175vcb.50.1362751704618; Fri, 08 Mar 2013 06:08:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.49.102 with HTTP; Fri, 8 Mar 2013 06:07:44 -0800 (PST)
In-Reply-To: <5139EFF8.7040603@ericsson.com>
References:  <5139AF4C.70109@ericsson.com>  <5139EFF8.7040603@ericsson.com>
From: Peter Thatcher 
Date: Fri, 8 Mar 2013 06:07:44 -0800
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: ALoCoQmjUf30WOMxV+YA41vVr0cm+FObrso93Jmx3Mh+PyFXdqe2S7TTncdkgTZlsk1Quadjf4Rl47qh9BtmmHDjBW4kgNFWTWUT7likOxvQ0601occ1Lwmyk38g5LSA7QPmwB/jPRrcmrfsqEv4jPF4anNLkXbY0Az0IbIpBf/Pk3L2zC+v1w7xR9yArpRVgXJvdu3zkgka
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Fri, 08 Mar 2013 14:08:29 -0000

Is the blob format defined by the IETF or the W3C?  If the W3C decided
not to use SDP as the blob, or not to use blobs at all, what would
that mean for the IETF?

On Fri, Mar 8, 2013 at 6:04 AM, Stefan H=C3=A5kansson LK
 wrote:
> On 2013-03-08 14:50, Peter Thatcher wrote:
>>
>> One the question of "what info do the two endpoints exchange to be
>> able to set up connection(s) and send and receive audio, video and
>> data", my  assumption has *not* been SDP, but rather that it has been
>> left to the javascript application to decide what info to exhange.
>> I've heard over and over at WebRTC meeting and conferences that
>> "signalling is not defined; that's up to the javascript application".
>
>
> I agree to the above - signaling is entirely up to the application. I'm
> sorry if my message gave another impression. But we need to define the
> format of the "blobs" (if we call them that) that browser A produces so t=
hat
> they can be plumbed into browser B and things work. So far the assumption
> has been that those blobs are SDP descriptions, and my point is that
> changing that to something else may cost us more than we gain.
>
>
>> I completely agree with that and think we should stick to it.  In
>> Google Talk/Hangouts, for example, we use Jingle, not SDP.  SDP only
>> serves as a javascript API surface, not as a format to exchange with
>> the remote side.
>>
>> As an application developer I do not want to exchange SDP.  I only use
>> it as an API surface.  And it looks like I'm not the only application
>> developer that sees it this way:
>> - http://s.phono.com/releases/0.6/jquery.phono.js
>> - https://github.com/lukeweber/webrtc-jingle-client
>> -
>> https://code.google.com/p/openfire-candy/source/browse/trunk/plugin/cand=
y/plugins/voicebridge/webrtc-jingle.js
>> - https://github.com/mweibel/sdpToJingle
>>
>> Again, for me, and many others it appears, SDP only serves as a
>> javascript API surface.
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Mar 8, 2013 at 1:28 AM, Stefan H=C3=A5kansson LK
>>  wrote:
>>>
>>> On 2013-03-07 00:45, Robin Raymond wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Do we need SDP "blob" format in the exchange in the first place? All
>>>> media
>>>> can be done without SDP given an intelligent stream API. An API alread=
y
>>>> exists to create these streams (albeit somewhat lacking if we remove t=
he
>>>> SDP 'blob'). This API helps "simplify" creating this blob for later
>>>> exchange. But the blob is truly not needed. Each side could in fact
>>>> create
>>>> the desired streams, pass in the appropriate media information such as
>>>> codecs and ICE candidates and chose the socket pair to multiplex upon.
>>>> Yes, it's a bit more low level but it certainly can be done (and
>>>> cleanly).
>>>
>>>
>>>
>>> I think we are mixing up two different things in the discussion. One is
>>> "what info to the two endpoints exchange to be able to set up
>>> connection(s)
>>> and send and receive audio, video and data" and the other is "what APIs
>>> should we use to control the settings".
>>>
>>> For the first part, the assumption has so far been SDP. I think we've a=
ll
>>> realized now that the legacy of SDP gives us quite a bit of headache. I
>>> think that splitting up signaling about connections (ICE candidates) fr=
om
>>> signaling for media stuff (codecs, how different ssrc's correlate to
>>> MediaStreamTrack's, ...) would simplify things a lot. But on the other
>>> hand,
>>> it seems to me that we're really close to nailing those details. I'm
>>> pretty
>>> sure that switching to some other format would cost more in time than w=
e
>>> gain.
>>>
>>> Also, remember that those session descriptions come with a flag saying
>>> "sdp". This is intentional, it gives us the freedom to change format
>>> without
>>> affecting the application in the future (as long as the application can
>>> follow the normal createOffer/setLocal etc. procedures).
>>>
>>> When it comes to the API, that discussion is really for the W3C webrtc
>>> WG.
>>> But as has been said by Tim and Harald already, the session description=
s
>>> should never be changed in normal cases - there should be (and are) oth=
er
>>> APIs for setting up how a MediaStreamTrack is transported over the
>>> network,
>>> resolutions, etc. What is set in those APIs will be reflected in the SD=
P
>>> created by "createOffer".
>>>
>>> Stefan
>>>
>>>
>>>>
>>>> https://datatracker.ietf.org/doc/draft-jennings-rtcweb-plan/
>>>>
>>>> Nothing wrong with the draft in an SDP/SIP mindset but I'm going to ta=
ke
>>>> it from a totally different non-SDP angle. I have to say, the ideas
>>>> presented are very good. I appreciate FEC, and synchronizing streams i=
s
>>>> cool. But SDP isn=C2=B9t needed to do it. Let me as the programmer wor=
ry
>>>> about
>>>> how to manage streams and the features on the streams and associations
>>>> between the streams via an API only.
>>>>
>>>> Point 4, 5 and 6 in the specification all have to do with the
>>>> complexities
>>>> of having to describe the intentions of mixing in SDP. So no comment
>>>> beyond =C2=B3don=C2=B9t use SDP=C2=B2.
>>>>
>>>> As for 7.1 =C2=AD =C2=B3this is because the sender choses the SSRC=C2=
=B2 =C2=AD only true
>>>> because we are forced to use SDP and the assumptions is that it=C2=B9s=
 SIP.
>>>> We
>>>> could have the receiver dictate what the sender should use in advance =
of
>>>> any media. In our case, we establish in advance what we want from all
>>>> parties before even =C2=B3ringing=C2=B2 the other party. We do not hav=
e SSRC
>>>> collisions as we reversed the scenario allowing the receiver to pick t=
he
>>>> expected SSRC. Coordinating the streams is a problem with SIP because =
of
>>>> how they do forking/conferencing. This specification forces this issue
>>>> on
>>>> those not using SIP. If SIP has problems with streams arriving early t=
o
>>>> their stateful offer/answer then let them worry about =C2=B3how=C2=B2 =
they intend
>>>> to
>>>> match the streams at a higher SDP layer and get this draft out of the
>>>> RTCWEB track on the SIP track. To be clear, the proposal seems entirel=
y
>>>> reasonable and intelligent for SIP/SDP. But it=C2=B9s way to SIP centr=
ic for
>>>> general use.
>>>>
>>>> On that note, what I do need in the API is an ability to dictate the
>>>> SSRC
>>>> when I create an RTP stream for sending (should I care to do that).
>>>>
>>>> 7.2 Multiple render
>>>>
>>>> Again this is an issue of SIP/SDP. We can control the SSRCs to split
>>>> them
>>>> out to allow multiplexing easily on the same RTP ports with multiple
>>>> parties/sources. If given the primitives to control the streams just,
>>>> this
>>>> specification could be used to dictate how to negotiate issues in thei=
r
>>>> space.
>>>>
>>>> 7.2.1 I=C2=B9m feeling the pain. How about just giving me an API where=
 I can
>>>> indicate what streams are FEC associated.
>>>>
>>>> 7.3 Give me API to give crypto keys to RTP layer. Let me handle the
>>>> fingerprint and security myself beyond that.
>>>>
>>>> 8. Let's just say politely that I would not want to be the developer
>>>> assigned to programming around all this stuff.
>>>>
>>>> Again, a perfect illustration why I don=C2=B9t want SDP.
>>>>
>>>> Media is complicated for good reason as there are many untold use case=
s.
>>>> The entire IETF/W3C discussion around video constraints illustrates so=
me
>>>> of the complexities and competing desires for just one single media
>>>> type.
>>>> If we tie ourselves to SDP we are limiting ourselves big time, and som=
e
>>>> of
>>>> the cool future stuff will be horribly hampered by it.
>>>>
>>>> My issues with SDP can be summarized as:
>>>>
>>>> - unneeded - much too high level an API
>>>> - arcane format - legacy and problematic
>>>> - offer/answer
>>>> - incompatibilities
>>>> - lack of API contact
>>>> - doesn't truly solve goal of interoperability with legacy systems (eg=
.
>>>> SIP)
>>>>
>>>> Regret that I did not have time for feedback earlier. As you can tell,=
 I
>>>> am not at all happy with where we sit today wrt requiring SDP. IMHO we
>>>> need a lower level API if we are going to insist on using SDP.
>>>>
>>>>
>>>> You can read my entire (long) rant against SDP here
>>>> http://blog.webrtc.is/2013/03/06/sdp-the-webrtc-boat-anchor/
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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 stefan.lk.hakansson@ericsson.com  Fri Mar  8 06: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 5432721F86EF for ; Fri,  8 Mar 2013 06:11:34 -0800 (PST)
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=[AWL=0.000,  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 JgwPfzKVR6AD for ; Fri,  8 Mar 2013 06:11:25 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 16B0F21F84F8 for ; Fri,  8 Mar 2013 06:11:24 -0800 (PST)
X-AuditID: c1b4fb2d-b7f316d0000028db-e9-5139f18aeb20
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 01.BB.10459.A81F9315; Fri,  8 Mar 2013 15:11:22 +0100 (CET)
Received: from [150.132.141.119] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Fri, 8 Mar 2013 15:11:22 +0100
Message-ID: <5139F18A.6060100@ericsson.com>
Date: Fri, 8 Mar 2013 15:11:22 +0100
From: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Peter Thatcher 
References:  <5139AF4C.70109@ericsson.com>  <5139EFF8.7040603@ericsson.com> 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3Rrfro2WgwbcZWhbXlr9mtVj7r53d gcljwaZSjyVLfjIFMEVx2aSk5mSWpRbp2yVwZfx7dpOxoN2j4vrBLuYGxkVWXYycHBICJhKb P3SwQ9hiEhfurWfrYuTiEBI4ySixZcdndghnDaPE5UVbGUGqeAW0JZavOcwKYrMIqEgcODKB DcRmEwiW2L8cpJuDQ1QgSuLKPkuIckGJkzOfsIDYIgKaEpMnN4O1MguoS9xZfA5ssTBQ+ddn P6AWf2eUWLNyLRNIglMgUGLp7n5GiAYLicVvDrJD2PISzVtnM4PYQgK6Eu9e32OdwCg4C8m+ WUhaZiFpWcDIvIqRPTcxMye93HATIzAkD275rbuD8dQ5kUOM0hwsSuK8Ya4XAoQE0hNLUrNT UwtSi+KLSnNSiw8xMnFwSjUwMqpViy8LTlcIN4z/VvTM/pd2T0NZvtZKo5TKpyePNLBfen6z cdfro+cfRr74+vy2UK5zXrd3TmvgNMm5rq0KVx0jhcqlTwoYRXxcHVcxx82eJ2COd9hPu929 F0o/Fzm9Enml9t6Ev0rRckbV5ZViXtX5xe1/fRzbL7FW8jr4sx68J+bp8k6JpTgj0VCLuag4 EQBnnLlhFwIAAA==
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Fri, 08 Mar 2013 14:11:34 -0000

On 2013-03-08 15:07, Peter Thatcher wrote:
> Is the blob format defined by the IETF or the W3C?

It is defined by the IETF currently.

> If the W3C decided
> not to use SDP as the blob, or not to use blobs at all, what would
> that mean for the IETF?

That is a good question, and something that could be discussed if the 
IETF fail to make progress on resolving the issues around the SDP blob 
format (in my personal opinion).

>
> On Fri, Mar 8, 2013 at 6:04 AM, Stefan HÃ¥kansson LK
>  wrote:
>> On 2013-03-08 14:50, Peter Thatcher wrote:
>>>
>>> One the question of "what info do the two endpoints exchange to be
>>> able to set up connection(s) and send and receive audio, video and
>>> data", my  assumption has *not* been SDP, but rather that it has been
>>> left to the javascript application to decide what info to exhange.
>>> I've heard over and over at WebRTC meeting and conferences that
>>> "signalling is not defined; that's up to the javascript application".
>>
>>
>> I agree to the above - signaling is entirely up to the application. I'm
>> sorry if my message gave another impression. But we need to define the
>> format of the "blobs" (if we call them that) that browser A produces so that
>> they can be plumbed into browser B and things work. So far the assumption
>> has been that those blobs are SDP descriptions, and my point is that
>> changing that to something else may cost us more than we gain.
>>
>>
>>> I completely agree with that and think we should stick to it.  In
>>> Google Talk/Hangouts, for example, we use Jingle, not SDP.  SDP only
>>> serves as a javascript API surface, not as a format to exchange with
>>> the remote side.
>>>
>>> As an application developer I do not want to exchange SDP.  I only use
>>> it as an API surface.  And it looks like I'm not the only application
>>> developer that sees it this way:
>>> - http://s.phono.com/releases/0.6/jquery.phono.js
>>> - https://github.com/lukeweber/webrtc-jingle-client
>>> -
>>> https://code.google.com/p/openfire-candy/source/browse/trunk/plugin/candy/plugins/voicebridge/webrtc-jingle.js
>>> - https://github.com/mweibel/sdpToJingle
>>>
>>> Again, for me, and many others it appears, SDP only serves as a
>>> javascript API surface.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Mar 8, 2013 at 1:28 AM, Stefan HÃ¥kansson LK
>>>  wrote:
>>>>
>>>> On 2013-03-07 00:45, Robin Raymond wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Do we need SDP "blob" format in the exchange in the first place? All
>>>>> media
>>>>> can be done without SDP given an intelligent stream API. An API already
>>>>> exists to create these streams (albeit somewhat lacking if we remove the
>>>>> SDP 'blob'). This API helps "simplify" creating this blob for later
>>>>> exchange. But the blob is truly not needed. Each side could in fact
>>>>> create
>>>>> the desired streams, pass in the appropriate media information such as
>>>>> codecs and ICE candidates and chose the socket pair to multiplex upon.
>>>>> Yes, it's a bit more low level but it certainly can be done (and
>>>>> cleanly).
>>>>
>>>>
>>>>
>>>> I think we are mixing up two different things in the discussion. One is
>>>> "what info to the two endpoints exchange to be able to set up
>>>> connection(s)
>>>> and send and receive audio, video and data" and the other is "what APIs
>>>> should we use to control the settings".
>>>>
>>>> For the first part, the assumption has so far been SDP. I think we've all
>>>> realized now that the legacy of SDP gives us quite a bit of headache. I
>>>> think that splitting up signaling about connections (ICE candidates) from
>>>> signaling for media stuff (codecs, how different ssrc's correlate to
>>>> MediaStreamTrack's, ...) would simplify things a lot. But on the other
>>>> hand,
>>>> it seems to me that we're really close to nailing those details. I'm
>>>> pretty
>>>> sure that switching to some other format would cost more in time than we
>>>> gain.
>>>>
>>>> Also, remember that those session descriptions come with a flag saying
>>>> "sdp". This is intentional, it gives us the freedom to change format
>>>> without
>>>> affecting the application in the future (as long as the application can
>>>> follow the normal createOffer/setLocal etc. procedures).
>>>>
>>>> When it comes to the API, that discussion is really for the W3C webrtc
>>>> WG.
>>>> But as has been said by Tim and Harald already, the session descriptions
>>>> should never be changed in normal cases - there should be (and are) other
>>>> APIs for setting up how a MediaStreamTrack is transported over the
>>>> network,
>>>> resolutions, etc. What is set in those APIs will be reflected in the SDP
>>>> created by "createOffer".
>>>>
>>>> Stefan
>>>>
>>>>
>>>>>
>>>>> https://datatracker.ietf.org/doc/draft-jennings-rtcweb-plan/
>>>>>
>>>>> Nothing wrong with the draft in an SDP/SIP mindset but I'm going to take
>>>>> it from a totally different non-SDP angle. I have to say, the ideas
>>>>> presented are very good. I appreciate FEC, and synchronizing streams is
>>>>> cool. But SDP isn¹t needed to do it. Let me as the programmer worry
>>>>> about
>>>>> how to manage streams and the features on the streams and associations
>>>>> between the streams via an API only.
>>>>>
>>>>> Point 4, 5 and 6 in the specification all have to do with the
>>>>> complexities
>>>>> of having to describe the intentions of mixing in SDP. So no comment
>>>>> beyond ³don¹t use SDP².
>>>>>
>>>>> As for 7.1 ­ ³this is because the sender choses the SSRC² ­ only true
>>>>> because we are forced to use SDP and the assumptions is that it¹s SIP.
>>>>> We
>>>>> could have the receiver dictate what the sender should use in advance of
>>>>> any media. In our case, we establish in advance what we want from all
>>>>> parties before even ³ringing² the other party. We do not have SSRC
>>>>> collisions as we reversed the scenario allowing the receiver to pick the
>>>>> expected SSRC. Coordinating the streams is a problem with SIP because of
>>>>> how they do forking/conferencing. This specification forces this issue
>>>>> on
>>>>> those not using SIP. If SIP has problems with streams arriving early to
>>>>> their stateful offer/answer then let them worry about ³how² they intend
>>>>> to
>>>>> match the streams at a higher SDP layer and get this draft out of the
>>>>> RTCWEB track on the SIP track. To be clear, the proposal seems entirely
>>>>> reasonable and intelligent for SIP/SDP. But it¹s way to SIP centric for
>>>>> general use.
>>>>>
>>>>> On that note, what I do need in the API is an ability to dictate the
>>>>> SSRC
>>>>> when I create an RTP stream for sending (should I care to do that).
>>>>>
>>>>> 7.2 Multiple render
>>>>>
>>>>> Again this is an issue of SIP/SDP. We can control the SSRCs to split
>>>>> them
>>>>> out to allow multiplexing easily on the same RTP ports with multiple
>>>>> parties/sources. If given the primitives to control the streams just,
>>>>> this
>>>>> specification could be used to dictate how to negotiate issues in their
>>>>> space.
>>>>>
>>>>> 7.2.1 I¹m feeling the pain. How about just giving me an API where I can
>>>>> indicate what streams are FEC associated.
>>>>>
>>>>> 7.3 Give me API to give crypto keys to RTP layer. Let me handle the
>>>>> fingerprint and security myself beyond that.
>>>>>
>>>>> 8. Let's just say politely that I would not want to be the developer
>>>>> assigned to programming around all this stuff.
>>>>>
>>>>> Again, a perfect illustration why I don¹t want SDP.
>>>>>
>>>>> Media is complicated for good reason as there are many untold use cases.
>>>>> The entire IETF/W3C discussion around video constraints illustrates some
>>>>> of the complexities and competing desires for just one single media
>>>>> type.
>>>>> If we tie ourselves to SDP we are limiting ourselves big time, and some
>>>>> of
>>>>> the cool future stuff will be horribly hampered by it.
>>>>>
>>>>> My issues with SDP can be summarized as:
>>>>>
>>>>> - unneeded - much too high level an API
>>>>> - arcane format - legacy and problematic
>>>>> - offer/answer
>>>>> - incompatibilities
>>>>> - lack of API contact
>>>>> - doesn't truly solve goal of interoperability with legacy systems (eg.
>>>>> SIP)
>>>>>
>>>>> Regret that I did not have time for feedback earlier. As you can tell, I
>>>>> am not at all happy with where we sit today wrt requiring SDP. IMHO we
>>>>> need a lower level API if we are going to insist on using SDP.
>>>>>
>>>>>
>>>>> You can read my entire (long) rant against SDP here
>>>>> http://blog.webrtc.is/2013/03/06/sdp-the-webrtc-boat-anchor/
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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 pthatcher@google.com  Fri Mar  8 06: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 66D9F21F8622 for ; Fri,  8 Mar 2013 06:23:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.828
X-Spam-Level: 
X-Spam-Status: No, score=-101.828 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 TOORXLfYYFNy for ; Fri,  8 Mar 2013 06:23:59 -0800 (PST)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9494521F85E7 for ; Fri,  8 Mar 2013 06:23:58 -0800 (PST)
Received: by mail-la0-f45.google.com with SMTP id er20so1722407lab.4 for ; Fri, 08 Mar 2013 06:23:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=NlkLATnqyUIO7XbqNaOlix2vAE4MxwxoHIcvCfNsEIE=; b=VKdGmDYT2IUEA8TY4DLz7Sy0c8zvKMbHzLiB7z6cUHtE+eUbo7GLRZeug27om7kZBE fhbas2YpYgJuDOy8HuuGrDVLxt5mH8PEpm2BrvtUqi742jnP/Q9AnkNNKwWTOuW/ncne Y6LsjtmjfRqKauw7gzhGg0BXepOzL6Gnce1b5gNOYxcH1yVSm8CzSBW4/UtTEFgHhUFh I4LPR8n6eB3lWAMuX9W5+jG1YW3mFAwTUQgLH9t6tP89KsIQl37kUgVouhFfJF5z423p AQ4Uj6qBcw+iU47EkGK8lwB7xdEhTc18yX+NawW+6PzgqmramLgn1xyZJGkgiVQa2HkP tC0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=NlkLATnqyUIO7XbqNaOlix2vAE4MxwxoHIcvCfNsEIE=; b=MSDoK6akOa46nFyYilOZ8/dptlRuNrniJDVHLb9SQWrHjdb8b6A8am6HweNwHqQv4n oP6Qc6PDTFSx2rXySgl07tVNV2Oc4lC23H1HI34QkACf1OioFjnBuc+7PWEDyFWNUNCR LQKlbaw6lYdALjUanhr3gT2/5hv2rIHptKzE2BQNpgah9ijqq75etG6IQBJReV+Z0nbs m4r9IgTeopsOIKb71z8T073+y4nkUEGYSdWJgT0aj+U+vty8jWY+UYABHIcNovi2J6HY 0pYgcq3K29b/ZeOfBZzsmLeboTOx0wCVjAWgYgiYD3K5TGOPYAr9frPNY1hDQsR4MaSX WyuA==
X-Received: by 10.152.46.131 with SMTP id v3mr2152104lam.57.1362752637507; Fri, 08 Mar 2013 06:23:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.6.5 with HTTP; Fri, 8 Mar 2013 06:23:17 -0800 (PST)
In-Reply-To: <5139F18A.6060100@ericsson.com>
References:  <5139AF4C.70109@ericsson.com>  <5139EFF8.7040603@ericsson.com>  <5139F18A.6060100@ericsson.com>
From: Peter Thatcher 
Date: Fri, 8 Mar 2013 06:23:17 -0800
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: ALoCoQnZ80WtBs0ih73hu1d0YIEq23iDLGk1yaXCECpj2DdvVbzARaifZRXz1Hc+x47LKbi0o40Yp7DIJwS/+gIrVzuAWpOyMeoNAeCHtYP7aFVHhpBWROBptnqqzx6AZznLmZyXaz7uIPCgWYePkEGHq/G4EPQY3K/toYn3SahgPPrpai+e4UTroTDRCQKFsTbpvPl2ganH
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Fri, 08 Mar 2013 14:23:59 -0000

On Fri, Mar 8, 2013 at 6:11 AM, Stefan H=C3=A5kansson LK
 wrote:
> On 2013-03-08 15:07, Peter Thatcher wrote:
>>
>> Is the blob format defined by the IETF or the W3C?
>
>
> It is defined by the IETF currently.
>

But that's only because the W3C chose SDP, which is defined by the
IETF.  The W3C has effectively delegated its API surface to the IETF.
Which blob format to use in the first place (SDP, something else, or
none at all) is still, ultimately, a W3C decision.  Right?

So, should the IETF WG's standing response to Robin and future
developers like him (and I'm sure the same thing will come up many
times for  many years) be "we don't talk about non-SDP around here" or
 should it be "that's a W3C issue.  Please share your input with their
working group"?  The latter seems to me much more friendly.

From mary.ietf.barnes@gmail.com  Fri Mar  8 06:49: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 5D7D721F85BF for ; Fri,  8 Mar 2013 06:49:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.758
X-Spam-Level: 
X-Spam-Status: No, score=-103.758 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, 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 T5QN7JUV4OqP for ; Fri,  8 Mar 2013 06:49:41 -0800 (PST)
Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id 9958B21F8514 for ; Fri,  8 Mar 2013 06:49:41 -0800 (PST)
Received: by mail-qe0-f50.google.com with SMTP id k5so1025826qej.9 for ; Fri, 08 Mar 2013 06:49:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=1JtawpQoiiNziH3xqNLoZWwq5aDU2e0xKXGzdeRLJH4=; b=z9bKnvZvEGtzkMCiF8uK+JJcxUwZk8L2M86ouyIselt8qs+yP8tY7rs74Iu2TJutOB Y6INcS15FkIDoHAp7uHC7ZhItBr9rgwdkNX70zokLmFBSudhoTuwwglv2Aw1JxUSx2Qi k4le63pyMjxVo0KxSn6xJpnUK8ky0VgRyCIr3rGlgkiuTVvfvjofOanXKbhxSDurBi0z Rqsmf9L+GjXOo9p+CVsQMnfofi9//FT9BhnEYKMIiFSB4WrKANqTBfRzNax7uXFX97Cs n/NhDbwSLx2pCCSKEENny4dlaQkncHeqMGEFmlSTpjAFXpdr+GD5VshStd3umvqLng2Q JPiA==
MIME-Version: 1.0
X-Received: by 10.49.87.40 with SMTP id u8mr3872192qez.62.1362754181173; Fri, 08 Mar 2013 06:49:41 -0800 (PST)
Received: by 10.49.24.130 with HTTP; Fri, 8 Mar 2013 06:49:41 -0800 (PST)
In-Reply-To: 
References: 
Date: Fri, 8 Mar 2013 08:49:41 -0600
Message-ID: 
From: Mary Barnes 
To: Ted Hardie 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" 
Subject: Re: [rtcweb] Checkpointing decisions in RTCWEB
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 08 Mar 2013 14:49:42 -0000

As an individual that's also a chair, I truly do understand your pain.
 I realize that a change this late in the game is not at all a good
thing.  I also realize the impact this might have on folks whose
products are very entrenched in SDP (including my own employer).  But,
this seems very much to be a pay now or pay later situation.  I have
100% confidence that this energetic and intelligent group of folks can
come up with a protocol spec that relies on SDP - we have shown over
and over that we can eventually make decisions when there are strong
proponents with different approaches.  I don't debate that at all, but
I am concerned about interoperability issues and the fragility of SDP.
 This is not at all a new sort of problem - it's a pattern that exists
very often in product development.  In my experience, doing something
that seems a little more novel and disruptive can be done more quickly
than trying to work with existing code/architectures that are being
pushed well beyond their limits (based upon original design intent).
I've seen this time and again in developing products.

We also have a number of situations in IETF where we have been
determined to complete something based upon a decision that was made
and we have successfully completed protocol documents in these cases.
However, we have a number of these cases where those documents just
get put on a shelf.

Best Regards,
Mary



On Thu, Mar 7, 2013 at 4:48 PM, Ted Hardie  wrote:
> Howdy,
>
> For any working group to be able to make consistent progress, it must
> be able to rely on decisions that have already been taken to remain
> stable in the absence of new technical issues.    Re-raising old
> issues without new information does not help move the work forward,
> and, as tempting as it may be for those who raised it the initial
> times, nor does a chorus of "I thought that all along".
>
> For the specific question in the thread entitled "Proposed Plan for
> Usage of SDP and RTP - Lower level API minus SDP", I believe every
> point in the thread has been raised before.  SDP has been unlovely and
> arcane for many years, so this is not new news.  Despite that old
> news, we have run consensus calls on this topic in both the IETF and
> the W3C and agreed to use both it and offer/answer.
>
> May I politely suggest we finish that work *before* we examine the
> need and feasibility of an addtional, potentially lower-layer approach
> to this?  Finishing the work before us does not close off all related
> work for all time, but failure to produce something viable soon likely
> will.
>
> I'm not sure what hat to wear for this message, so assume a "grumpy
> old timer" porkpie, size 7 and 3/8ths.
>
> regards,
>
> Ted Hardie
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

From matthew.kaufman@skype.net  Fri Mar  8 06:55: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 DD5C821F84F7 for ; Fri,  8 Mar 2013 06:55:50 -0800 (PST)
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 KJRJe94HHZmj for ; Fri,  8 Mar 2013 06:55:50 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7F621F8491 for ; Fri,  8 Mar 2013 06:55:49 -0800 (PST)
Received: from BY2FFO11FD010.protection.gbl (10.1.15.200) by BY2FFO11HUB031.protection.gbl (10.1.14.116) with Microsoft SMTP Server (TLS) id 15.0.620.12; Fri, 8 Mar 2013 14:55:41 +0000
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD010.mail.protection.outlook.com (10.1.14.74) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Fri, 8 Mar 2013 14:55:41 +0000
Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.76]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Fri, 8 Mar 2013 14:55:27 +0000
From: "Matthew Kaufman (SKYPE)" 
To: =?utf-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= , Peter Thatcher 
Thread-Topic: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus SDP
Thread-Index: AQHOG99cNdIHhEwrJ0yj3rXtTeVDRpibz/yAgAAEBQCAAAub8A==
Date: Fri, 8 Mar 2013 14:55:26 +0000
Message-ID: 
References:  <5139AF4C.70109@ericsson.com>  <5139EFF8.7040603@ericsson.com>
In-Reply-To: <5139EFF8.7040603@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.34]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(199002)(189002)(56776001)(74502001)(54316002)(49866001)(80022001)(47736001)(56816002)(54356001)(46102001)(65816001)(16406001)(44976002)(69226001)(33656001)(47446002)(50986001)(74662001)(53806001)(51856001)(66066001)(79102001)(50466001)(20776003)(23676001)(31966008)(47976001)(55846006)(47776003)(4396001)(63696002)(77982001)(59766001)(76482001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB031; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 077929D941
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Fri, 08 Mar 2013 14:55:51 -0000

U3RlZmFuIEjDpWthbnNzb24gTEs6DQo+DQo+IEkgYWdyZWUgdG8gdGhlIGFib3ZlIC0gc2lnbmFs
aW5nIGlzIGVudGlyZWx5IHVwIHRvIHRoZSBhcHBsaWNhdGlvbi4gSSdtIHNvcnJ5IGlmIG15DQo+
IG1lc3NhZ2UgZ2F2ZSBhbm90aGVyIGltcHJlc3Npb24uIEJ1dCB3ZSBuZWVkIHRvIGRlZmluZSB0
aGUgZm9ybWF0IG9mIHRoZQ0KPiAiYmxvYnMiIChpZiB3ZSBjYWxsIHRoZW0gdGhhdCkgdGhhdCBi
cm93c2VyIEEgcHJvZHVjZXMgc28gdGhhdCB0aGV5IGNhbiBiZQ0KPiBwbHVtYmVkIGludG8gYnJv
d3NlciBCIGFuZCB0aGluZ3Mgd29yay4gDQoNCk5vIHdlIGRvbid0LiBJbiBmYWN0IHRoYXQgaXMg
ZXhhY3RseSB3aGF0IHdlIHNob3VsZCBtZWFuIHdoZW4gd2Ugc2F5ICJzaWduYWxpbmcgaXMgZW50
aXJlbHkgdXAgdG8gdGhlIGFwcGxpY2F0aW9uIi4NCg0KVGhlcmUgaXMgbm8gcmVhc29uIHdoeSBC
cm93c2VyIEEgbXVzdCBwcm9kdWNlIHNvbWV0aGluZyBhIHNlcmlhbGl6ZWQgYmxvYiB0aGF0IGNh
biBiZSBzdHVmZmVkIGRpcmVjdGx5IGludG8gYW4gQVBJIGF0IEJyb3dzZXIgQi4gQW5kIGluIGZh
Y3QsIGRvaW5nIHNvIG1lYW5zIHRoYXQgeW91ciB0d28gYnJvd3NlcnMgYXJlIHZlcnkgbGlrZWx5
IGRvaW5nIHRoaW5ncyB5b3UgZG9uJ3QgZXhwZWN0Li4uIGJlY2F1c2UgaW5zdGVhZCBvZiB5b3Vy
IEphdmFTY3JpcHQgYXBwbGljYXRpb24gc2F5aW5nICJkbyB0aGlzIiB0byBlYWNoLCBpdCBpcyBz
YXlpbmcgImRvIHdoYXRldmVyIHRoaXMgYmxvYiB0aGF0IHdhcyBnZW5lcmF0ZWQgYnkgY29kZSBJ
IGRvbid0IGNvbnRyb2wgKm1lYW5zIHRvIHlvdSogKGV2ZW4gaWYgdGhhdCBtZWFuaW5nIGlzIHN1
YnRseSBkaWZmZXJlbnQgdGhhbiB3aGF0IGl0IG1lYW50IHRvIHRoZSBzZW5kZXIpIi4gQW5kIHRo
ZW4gaWYgeW91IHdhbnQgdG8gaW5mbHVlbmNlIHRoYXQgeW91IGhhdmUgZWl0aGVyIHRoZSBwb2lu
dHkgc3RpY2tzIGNhbGxlZCBjb25zdHJhaW50cyBvciBlZGl0aW5nIG9mIHRoZSBibG9iIGFzIHlv
dXIgb25seSByZW1haW5pbmcgYXZlbnVlcyBvZiBjb250cm9sLg0KDQpXb3JzZSwgYmVjYXVzZSB0
aGlzIG5vdyBjYXJyaWVzIHRoZSBleHBsaWNpdCBhc3N1bXB0aW9uIHRoYXQgdGhlIHR3byBicm93
c2VycyBhcmUgbmVnb3RpYXRpbmcgZGlyZWN0bHkgYmV0d2VlbiBlYWNoIG90aGVyJ3MgY29kZSAo
YW5kIHJlYWxseSAqbm90KiBleHBlY3RpbmcgYW55dGhpbmcgaW4gdGhlIG1pZGRsZSB0byBtZXNz
IHdpdGggdGhvc2UgYmxvYnMpLCB5b3UgbmVlZCBhIHdob2xlIHNldCBvZiBzZW1hbnRpY3Mgb24g
dG9wIG9mIHRoaXMgdG8gZW5zdXJlIHRoYXQgdGhlIGJyb3dzZXJzIGNvbnZlcmdlIG9uIHNvbWV0
aGluZyB0aGF0IHdvcmtzIHdpdGhvdXQgdGhlaXIgSmF2YVNjcmlwdCBhcHAgaGVscGluZyB0aGVt
LiBUaGF0IGJyaW5ncyBpbiBSRkMzMjY0LXN0eWxlIE9mZmVyL0Fuc3dlciAod2hpY2ggaXMgbm90
IHRoZSBvbmx5IHdheSB0byBkbyBpdCwgYnV0IHRoZSBvbmUgdGhhdCB3YXMgY2hvc2VuKS4gVGhp
cyB0aGVuIG1lYW5zIHRoYXQgaWYgeW91IGluc3RlYWQgYXJlIHRyeWluZyB0byB1c2UgdGhlICJi
bG9iIiBpbnRlcmZhY2UgZm9yIGRpcmVjdCBtYW5pcHVsYXRpb24sIHlvdSBhcmUgZmlnaHRpbmcg
YWdhaW5zdCB3aGF0IG1heSBiZSBhbiBlbnRpcmVseSBpbmNvbXBhdGlibGUgc3RhdGUgbWFjaGlu
ZSBpbnNpZGUgdGhlIGJyb3dzZXIuDQoNCj4gU28gZmFyIHRoZSBhc3N1bXB0aW9uIGhhcyBiZWVu
DQo+IHRoYXQgdGhvc2UgYmxvYnMgYXJlIFNEUCBkZXNjcmlwdGlvbnMsIGFuZCBteSBwb2ludCBp
cyB0aGF0IGNoYW5naW5nIHRoYXQgdG8NCj4gc29tZXRoaW5nIGVsc2UgbWF5IGNvc3QgdXMgbW9y
ZSB0aGFuIHdlIGdhaW4uDQoNCldlIG5lZWQgdG8gcHJvdmlkZSB0aGUgYnJvd3NlciB3aXRoIGFu
ICpBUEkqLiBBbmQgdGhhdCBBUEkgc2hvdWxkIGFsbG93IHRoZSBKYXZhU2NyaXB0IGRldmVsb3Bl
ciB0byBkaXJlY3RseSBpbmZsdWVuY2Ugd2hhdCBpcyBoYXBwZW5pbmcuIFByZWZlcmFibHkgd2l0
aG91dCB0aGUgYnJvd3NlciBmaWdodGluZyBpdHMgZGV2ZWxvcGVyIGJ5IHRyeWluZyB0byBydW4g
dGhlIG9mZmVyLWFuc3dlciBzdGF0ZSBtYWNoaW5lIGl0c2VsZi4gR2V0dGluZyBodW5nIHVwIG9u
IGJlaW5nIGFibGUgdG8gcGFzcyBibG9icyBiYWNrIGFuZCBmb3J0aCBpcyBub3cgYW5kIGhhcyBh
bHdheXMgYmVlbiB0aGUgd2hvbGUgcHJvYmxlbS4NCg0KTWF0dGhldyBLYXVmbWFuDQoNCg==

From jim.barnett@genesyslab.com  Fri Mar  8 06:57: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 9F43821F8626 for ; Fri,  8 Mar 2013 06:57:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 7QVABKsPKscH for ; Fri,  8 Mar 2013 06:57:30 -0800 (PST)
Received: from service107-us.mimecast.com (service107-us.mimecast.com [207.211.31.84]) by ietfa.amsl.com (Postfix) with ESMTP id BFC4B21F8621 for ; Fri,  8 Mar 2013 06:57:29 -0800 (PST)
Received: from webmail-us.genesyslab.com (168.75.250.3 [168.75.250.3]) (Using TLS) by service107-us.mimecast.com; Fri, 08 Mar 2013 09:57:28 -0500
Received: from GENSJZMBX03.msg.int.genesyslab.com ([fe80::fc31:8268:eb4c:f8af]) by GENSJZFE01.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Fri, 8 Mar 2013 06:57:26 -0800
From: Jim Barnett 
To: Mary Barnes , Ted Hardie 
Thread-Topic: [rtcweb] Checkpointing decisions in RTCWEB
Thread-Index: AQHOG4X1bqeXKKMkOkGn8rQENJxOWZicZ2SA//96ejA=
Date: Fri, 8 Mar 2013 14:57:25 +0000
Message-ID: <57A15FAF9E58F841B2B1651FFE16D281026A26@GENSJZMBX03.msg.int.genesyslab.com>
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [98.110.233.90]
MIME-Version: 1.0
X-MC-Unique: 113030809572801001
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" 
Subject: Re: [rtcweb] Checkpointing decisions in RTCWEB
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 08 Mar 2013 14:57:30 -0000

Mary,
  How can there be interoperability issues if no one is required to use SDP=
 over the wire?  Are you saying that there are things that we need that SDP=
 cannot express (or cannot be extended to express)? =20

- Jim

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Mary Barnes
Sent: Friday, March 08, 2013 9:50 AM
To: Ted Hardie
Cc: rtcweb@ietf.org; rtcweb-chairs@tools.ietf.org
Subject: Re: [rtcweb] Checkpointing decisions in RTCWEB

As an individual that's also a chair, I truly do understand your pain.
 I realize that a change this late in the game is not at all a good thing. =
 I also realize the impact this might have on folks whose products are very=
 entrenched in SDP (including my own employer).  But, this seems very much =
to be a pay now or pay later situation.  I have 100% confidence that this e=
nergetic and intelligent group of folks can come up with a protocol spec th=
at relies on SDP - we have shown over and over that we can eventually make =
decisions when there are strong proponents with different approaches.  I do=
n't debate that at all, but I am concerned about interoperability issues an=
d the fragility of SDP.
 This is not at all a new sort of problem - it's a pattern that exists very=
 often in product development.  In my experience, doing something that seem=
s a little more novel and disruptive can be done more quickly than trying t=
o work with existing code/architectures that are being pushed well beyond t=
heir limits (based upon original design intent).
I've seen this time and again in developing products.

We also have a number of situations in IETF where we have been determined t=
o complete something based upon a decision that was made and we have succes=
sfully completed protocol documents in these cases.
However, we have a number of these cases where those documents just get put=
 on a shelf.

Best Regards,
Mary



On Thu, Mar 7, 2013 at 4:48 PM, Ted Hardie  wrote:
> Howdy,
>
> For any working group to be able to make consistent progress, it must=20
> be able to rely on decisions that have already been taken to remain
> stable in the absence of new technical issues.    Re-raising old
> issues without new information does not help move the work forward,=20
> and, as tempting as it may be for those who raised it the initial=20
> times, nor does a chorus of "I thought that all along".
>
> For the specific question in the thread entitled "Proposed Plan for=20
> Usage of SDP and RTP - Lower level API minus SDP", I believe every=20
> point in the thread has been raised before.  SDP has been unlovely and=20
> arcane for many years, so this is not new news.  Despite that old=20
> news, we have run consensus calls on this topic in both the IETF and=20
> the W3C and agreed to use both it and offer/answer.
>
> May I politely suggest we finish that work *before* we examine the=20
> need and feasibility of an addtional, potentially lower-layer approach=20
> to this?  Finishing the work before us does not close off all related=20
> work for all time, but failure to produce something viable soon likely=20
> will.
>
> I'm not sure what hat to wear for this message, so assume a "grumpy=20
> old timer" porkpie, size 7 and 3/8ths.
>
> regards,
>
> Ted Hardie
> _______________________________________________
> 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 matthew.kaufman@skype.net  Fri Mar  8 06: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 BC7AC21F8732 for ; Fri,  8 Mar 2013 06:57:54 -0800 (PST)
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 MMcYVCmWPwnS for ; Fri,  8 Mar 2013 06:57:54 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id 173BB21F871E for ; Fri,  8 Mar 2013 06:57:54 -0800 (PST)
Received: from BL2FFO11FD010.protection.gbl (10.173.161.203) by BL2FFO11HUB021.protection.gbl (10.173.161.45) with Microsoft SMTP Server (TLS) id 15.0.620.12; Fri, 8 Mar 2013 14:57:48 +0000
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD010.mail.protection.outlook.com (10.173.161.16) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Fri, 8 Mar 2013 14:57:48 +0000
Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.76]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Fri, 8 Mar 2013 14:57:31 +0000
From: "Matthew Kaufman (SKYPE)" 
To: Peter Thatcher , =?utf-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= 
Thread-Topic: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus SDP
Thread-Index: AQHOG99cNdIHhEwrJ0yj3rXtTeVDRpibz/yAgAAEBQCAAADbAIAADXHw
Date: Fri, 8 Mar 2013 14:57:30 +0000
Message-ID: 
References:  <5139AF4C.70109@ericsson.com>  <5139EFF8.7040603@ericsson.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.34]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(189002)(199002)(77982001)(4396001)(76482001)(53806001)(55846006)(74662001)(33656001)(54356001)(59766001)(47736001)(50986001)(56776001)(47976001)(23676001)(51856001)(47776003)(47446002)(79102001)(65816001)(66066001)(54316002)(74502001)(50466001)(44976002)(31966008)(63696002)(56816002)(20776003)(46102001)(80022001)(49866001)(69226001)(16406001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB021; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 077929D941
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Fri, 08 Mar 2013 14:57:54 -0000

UGV0ZXIgVGhhdGNoZXI6DQo+IA0KPiBJcyB0aGUgYmxvYiBmb3JtYXQgZGVmaW5lZCBieSB0aGUg
SUVURiBvciB0aGUgVzNDPyAgSWYgdGhlIFczQyBkZWNpZGVkIG5vdCB0bw0KPiB1c2UgU0RQIGFz
IHRoZSBibG9iLCBvciBub3QgdG8gdXNlIGJsb2JzIGF0IGFsbCwgd2hhdCB3b3VsZCB0aGF0IG1l
YW4gZm9yIHRoZQ0KPiBJRVRGPw0KDQpUaGUgVzNDIGhhcyBhcHBhcmVudGx5IGRlZmVycmVkIHRv
IHRoZSBJRVRGIGZvciBldmVyeXRoaW5nLCBpbmNsdWRpbmcgd2hhdCBjb2RlY3Mgc2hvdWxkIGJl
IG1hbmRhdG9yeSBhbmQgd2hhdCB0aGUgSmF2YVNjcmlwdCBBUEkgc2hvdWxkIGxvb2sgbGlrZS4N
Cg0KV2h5IHRoaXMgaXMgdGhlIGNhc2UsIEkgZG9uJ3Qga25vdywgYnV0IGV2ZW50dWFsbHkgdGhl
cmUgd2lsbCBiZSBhIFczQyBzcGVjaWZpY2F0aW9uIGFuZCBpdCB3aWxsIGNvbnRhaW4gYSBidW5j
aCBvZiByZWZlcmVuY2VzIHRvIG90aGVyIHNwZWNzIGFuZCB0aG9zZSBlaXRoZXIgd2lsbCBvciB3
aWxsIG5vdCBiZSBhY2NlcHRhYmxlIHRvIHRoZSBXM0MgV0cgYXMgYSBjb21wbGV0ZSBBUEkuDQoN
Ck1hdHRoZXcgS2F1Zm1hbg0KDQo=

From adam@nostrum.com  Fri Mar  8 07: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 9BC1921F8745 for ; Fri,  8 Mar 2013 07:26:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.204
X-Spam-Level: 
X-Spam-Status: No, score=-101.204 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 pLYf29x32zP5 for ; Fri,  8 Mar 2013 07:26:59 -0800 (PST)
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 DC29021F8700 for ; Fri,  8 Mar 2013 07:26:58 -0800 (PST)
Received: from [192.168.0.159] (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r28FQsE2016262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Mar 2013 09:26:54 -0600 (CST) (envelope-from adam@nostrum.com)
References:  
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <6A6C9D56-D182-43BB-94F8-35A0A225639C@nostrum.com>
X-Mailer: iPad Mail (10A403)
From: Adam Roach 
Date: Fri, 8 Mar 2013 09:26:55 -0600
To: Mary Barnes 
Received-SPF: pass (shaman.nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism)
Cc: "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" 
Subject: Re: [rtcweb] Checkpointing decisions in RTCWEB
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 08 Mar 2013 15:26:59 -0000

On Mar 8, 2013, at 8:49, Mary Barnes  wrote:

> We also have a number of situations in IETF where we have been
> determined to complete something based upon a decision that was made
> and we have successfully completed protocol documents in these cases.
> However, we have a number of these cases where those documents just
> get put on a shelf.

I'm not sure which spec you're trying to warn us about never being deployed.=
 The RTCWEB specification, for all its current holes, already has independen=
t interoperable implementations in the field.=20

/a=

From pthatcher@google.com  Fri Mar  8 07: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 3090E21F854D for ; Fri,  8 Mar 2013 07:34:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.928
X-Spam-Level: 
X-Spam-Status: No, score=-101.928 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 o2ujLqu+eUkY for ; Fri,  8 Mar 2013 07:34:02 -0800 (PST)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 44AE521F84CA for ; Fri,  8 Mar 2013 07:34:02 -0800 (PST)
Received: by mail-la0-f43.google.com with SMTP id ek20so1808700lab.16 for ; Fri, 08 Mar 2013 07:34:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=dAnhPx4aakytpZy56skowRk9jJAZQTQmy/U8zXF+qRw=; b=PzvdMsV9/1WuCr1n20KxfPXnI0Z5BeyLlW0kk/kYmplldG1j85qoyqFJbDc23LENRh 4m6jl0/J2RrjYRd+ZqqU5lglguq+O3EooCmF8Ek3b7n5VmxUfILGTtKpMnHT/84wH2AH ezUcNYcTcwzTc5SU4EHGt+D3D7gb9gJxyI1dKMkgKH7Q5Z5FXY0bfQVbNEU1uzhe2hGd vRwfiFFSJ9WWdGbLUi1qD7USC/huBVXa7fEoW89y/jNwMXk8KAZ2/Rc4i6EvFeUm2HhA xvNx9oBahjPZ+1H6i4OD61fRv5dKPwWg41Od9EUDIkwtkdtNJWuilxzqdcpN2OTFAkwH 8E1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=dAnhPx4aakytpZy56skowRk9jJAZQTQmy/U8zXF+qRw=; b=bee/ChXQYD4pqA+sty94zXr9hsk8OhHhZ+EOTNo8nTrk51JeFoB8c05GYxYvcUZQ8A QpSLWQHe+i73bX1NASL8I5o/1RFSw1Wd+4e3YeOYADtHzQ5/WGLPH3mZeL1clzxXsyWH dM9HnLQN1JJWJiAyipwO+IE2kZ0C4jkXRIlYRN36rK+8kWVNXHJ5wWpEtdMiU+T0BEn0 FD0H5qdRC2OeSpbggm1L1R0TWwMg4z0QY7+jN6iObKY5JjbMxCxHW6JthXQPXLQSjI/P RNVMJ0TbH0IzrtfhldWrsAsIaw54+gTf7Vty1ZxZ61IQv/DZX0p1uHJlg/VEXFcTbKBb At9w==
X-Received: by 10.152.46.131 with SMTP id v3mr2334141lam.57.1362756841214; Fri, 08 Mar 2013 07:34:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.6.5 with HTTP; Fri, 8 Mar 2013 07:33:21 -0800 (PST)
In-Reply-To: <57A15FAF9E58F841B2B1651FFE16D281026A26@GENSJZMBX03.msg.int.genesyslab.com>
References:   <57A15FAF9E58F841B2B1651FFE16D281026A26@GENSJZMBX03.msg.int.genesyslab.com>
From: Peter Thatcher 
Date: Fri, 8 Mar 2013 07:33:21 -0800
Message-ID: 
To: Jim Barnett 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnH8R+mgqs30AAK6TiNIzyn7W4HytBRp1151cfgmQ5XnRiyQzef8gylCVDxZwv/tWZOyFj4gQ8OKBMD8Em7AQcVx6Sx3vTNwVafISka0YKkD3MGc3InBaceVaozxa8SkUjl8V89TRK2z1k0CmoKj64nIGUu7YyAECZkOw46xo91EVrhoH8cd3hE88VSLeM9ME5z0c5W
Cc: "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" 
Subject: Re: [rtcweb] Checkpointing decisions in RTCWEB
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 08 Mar 2013 15:34:07 -0000

Sorry for answering a question addressed to Mary, but it's important
to me to remind everyone that SDP isn't the only signalling protocol
in use, and that there isn't a 1:1 mapping between SDP and what
browsers support.


On Fri, Mar 8, 2013 at 6:57 AM, Jim Barnett  wr=
ote:
> Mary,
>   How can there be interoperability issues if no one is required to use S=
DP over the wire?

Not everything uses SDP over the wire.  Jingle devices and
applications don't use SDP over the wire.  If I'd like to interop with
Jingle applications and devices, I would not use SDP over the wire.

> Are you saying that there are things that we need that SDP cannot express=
 (or cannot be extended to express)?

Of course there are things SDP cannot currently express.  For example,
the browser API has explicit methods to support trickle ICE because
SDP doesn't express it well.  It looks like we're going down the same
path with SCTP data channels: since SDP doesn't support SCTP data
channels currently, it's easier for the browser to express data
channels mostly outside of SDP rather than extend SDP.

Of course we can keep extending SDP to include more and more, but even
extending SDP isn't enough.  Just because there's an SDP extension
doesn't mean the browser supports it.  RFC5576, for example.  It's a
standardized extension to SDP, but is it supported by the browser?
There's enormous debate over whether it should be or not.

So, we already have the case that the browser does things that aren't
expressed in SDP, and SDP expresses things the browser can't do.
Extending SDP isn't always the right answer.

>
> - Jim
>
> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf =
Of Mary Barnes
> Sent: Friday, March 08, 2013 9:50 AM
> To: Ted Hardie
> Cc: rtcweb@ietf.org; rtcweb-chairs@tools.ietf.org
> Subject: Re: [rtcweb] Checkpointing decisions in RTCWEB
>
> As an individual that's also a chair, I truly do understand your pain.
>  I realize that a change this late in the game is not at all a good thing=
.  I also realize the impact this might have on folks whose products are ve=
ry entrenched in SDP (including my own employer).  But, this seems very muc=
h to be a pay now or pay later situation.  I have 100% confidence that this=
 energetic and intelligent group of folks can come up with a protocol spec =
that relies on SDP - we have shown over and over that we can eventually mak=
e decisions when there are strong proponents with different approaches.  I =
don't debate that at all, but I am concerned about interoperability issues =
and the fragility of SDP.
>  This is not at all a new sort of problem - it's a pattern that exists ve=
ry often in product development.  In my experience, doing something that se=
ems a little more novel and disruptive can be done more quickly than trying=
 to work with existing code/architectures that are being pushed well beyond=
 their limits (based upon original design intent).
> I've seen this time and again in developing products.
>
> We also have a number of situations in IETF where we have been determined=
 to complete something based upon a decision that was made and we have succ=
essfully completed protocol documents in these cases.
> However, we have a number of these cases where those documents just get p=
ut on a shelf.
>
> Best Regards,
> Mary
>
>
>
> On Thu, Mar 7, 2013 at 4:48 PM, Ted Hardie  wrote:
>> Howdy,
>>
>> For any working group to be able to make consistent progress, it must
>> be able to rely on decisions that have already been taken to remain
>> stable in the absence of new technical issues.    Re-raising old
>> issues without new information does not help move the work forward,
>> and, as tempting as it may be for those who raised it the initial
>> times, nor does a chorus of "I thought that all along".
>>
>> For the specific question in the thread entitled "Proposed Plan for
>> Usage of SDP and RTP - Lower level API minus SDP", I believe every
>> point in the thread has been raised before.  SDP has been unlovely and
>> arcane for many years, so this is not new news.  Despite that old
>> news, we have run consensus calls on this topic in both the IETF and
>> the W3C and agreed to use both it and offer/answer.
>>
>> May I politely suggest we finish that work *before* we examine the
>> need and feasibility of an addtional, potentially lower-layer approach
>> to this?  Finishing the work before us does not close off all related
>> work for all time, but failure to produce something viable soon likely
>> will.
>>
>> I'm not sure what hat to wear for this message, so assume a "grumpy
>> old timer" porkpie, size 7 and 3/8ths.
>>
>> regards,
>>
>> Ted Hardie
>> _______________________________________________
>> 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 mary.ietf.barnes@gmail.com  Fri Mar  8 08:36: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 AA29621F882A for ; Fri,  8 Mar 2013 08:36:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.754
X-Spam-Level: 
X-Spam-Status: No, score=-103.754 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, 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 OTsX9GrI4c4Q for ; Fri,  8 Mar 2013 08:36:12 -0800 (PST)
Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1AB21F85A1 for ; Fri,  8 Mar 2013 08:36:12 -0800 (PST)
Received: by mail-qe0-f48.google.com with SMTP id 9so1088892qea.35 for ; Fri, 08 Mar 2013 08:36:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=cXl7hBK5yPfOkzKuqrimtv5Fuwx8ebf47Gi6wbKxdyI=; b=c0mk7QpaDvdT0UottQn6H6GACDgggK0tKvnVnR5tSRf6jNrpqgFFur9Es7vnaFJACY 24RZqn78CRwQn0HBXuY1UkM3P30QxIw4JUtq8S4QtgnPhSUA/keLjCqVNfWy/a3M4Pff NU6yXurpIGaYISFK4JL4bdm/an0TlnqMFdP4MkDHd4vHxuudjTHyUR2pJ6oLoVODQz9i B5axgbXpXkN/yANNUoHyHHC6CvvqLu3FpYYVyMI0klS48GdB/Wr8X9VXe/npYaTm23Ip 8Oi8Y8SxM8ZNqRzDjKy74SAm8XEoypWE1KguE53Kr+ZI5KI6pRm6nqynZHsEKG2+uVha XfLA==
MIME-Version: 1.0
X-Received: by 10.49.85.34 with SMTP id e2mr4876083qez.1.1362760570092; Fri, 08 Mar 2013 08:36:10 -0800 (PST)
Received: by 10.49.24.130 with HTTP; Fri, 8 Mar 2013 08:36:09 -0800 (PST)
In-Reply-To: <57A15FAF9E58F841B2B1651FFE16D281026A26@GENSJZMBX03.msg.int.genesyslab.com>
References:   <57A15FAF9E58F841B2B1651FFE16D281026A26@GENSJZMBX03.msg.int.genesyslab.com>
Date: Fri, 8 Mar 2013 10:36:09 -0600
Message-ID: 
From: Mary Barnes 
To: Jim Barnett 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" 
Subject: Re: [rtcweb] Checkpointing decisions in RTCWEB
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 08 Mar 2013 16:36:13 -0000

On Fri, Mar 8, 2013 at 8:57 AM, Jim Barnett  wr=
ote:
> Mary,
>   How can there be interoperability issues if no one is required to use S=
DP over the wire?
[MB]  My concern is extrapolated a bit beyond just RTCWEB to the
extensions that are being proposed for SDP to support RTCWEB -
independent of whether RTCWEB uses it over the wire.  In cases where
folks want interop with "legacy" SIP some form of the SDP needs to go
over the wire.  In an ideal world, that would be the same SDP blob,
but it doesn't appear that would be the case where RTCWEB is now.
[/MB]

[MB] Are you saying that there are things that we need that SDP cannot
express (or cannot be extended to express)?
[MB] Right now, there are things you need in SDP that there is no
agreement as to how they should be expressed.  I agree that the group
could certainly pick a way and then try to live with it.  However,
some of these things overlap with what CLUE needs.  If CLUE wants to
use the same building blocks (and not create yet another way to do
multi-stream), then CLUE would reuse some of what is being driven to
meet RTCWEB requirements.  A CLUE application/endpoint will be using
the SDP over the wire.  As I said initially, I arrived at my current
position after seeing the lack of consensus that was being reached at
the interim meeting.  I could be a total pessimist and all this will
get figured out next week in Orlando, but I am typically over
optimistic about work getting done in IETF, so I'm wouldn't put any
money on it.
 [/MB]
>
> - Jim
>
> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf =
Of Mary Barnes
> Sent: Friday, March 08, 2013 9:50 AM
> To: Ted Hardie
> Cc: rtcweb@ietf.org; rtcweb-chairs@tools.ietf.org
> Subject: Re: [rtcweb] Checkpointing decisions in RTCWEB
>
> As an individual that's also a chair, I truly do understand your pain.
>  I realize that a change this late in the game is not at all a good thing=
.  I also realize the impact this might have on folks whose products are ve=
ry entrenched in SDP (including my own employer).  But, this seems very muc=
h to be a pay now or pay later situation.  I have 100% confidence that this=
 energetic and intelligent group of folks can come up with a protocol spec =
that relies on SDP - we have shown over and over that we can eventually mak=
e decisions when there are strong proponents with different approaches.  I =
don't debate that at all, but I am concerned about interoperability issues =
and the fragility of SDP.
>  This is not at all a new sort of problem - it's a pattern that exists ve=
ry often in product development.  In my experience, doing something that se=
ems a little more novel and disruptive can be done more quickly than trying=
 to work with existing code/architectures that are being pushed well beyond=
 their limits (based upon original design intent).
> I've seen this time and again in developing products.
>
> We also have a number of situations in IETF where we have been determined=
 to complete something based upon a decision that was made and we have succ=
essfully completed protocol documents in these cases.
> However, we have a number of these cases where those documents just get p=
ut on a shelf.
>
> Best Regards,
> Mary
>
>
>
> On Thu, Mar 7, 2013 at 4:48 PM, Ted Hardie  wrote:
>> Howdy,
>>
>> For any working group to be able to make consistent progress, it must
>> be able to rely on decisions that have already been taken to remain
>> stable in the absence of new technical issues.    Re-raising old
>> issues without new information does not help move the work forward,
>> and, as tempting as it may be for those who raised it the initial
>> times, nor does a chorus of "I thought that all along".
>>
>> For the specific question in the thread entitled "Proposed Plan for
>> Usage of SDP and RTP - Lower level API minus SDP", I believe every
>> point in the thread has been raised before.  SDP has been unlovely and
>> arcane for many years, so this is not new news.  Despite that old
>> news, we have run consensus calls on this topic in both the IETF and
>> the W3C and agreed to use both it and offer/answer.
>>
>> May I politely suggest we finish that work *before* we examine the
>> need and feasibility of an addtional, potentially lower-layer approach
>> to this?  Finishing the work before us does not close off all related
>> work for all time, but failure to produce something viable soon likely
>> will.
>>
>> I'm not sure what hat to wear for this message, so assume a "grumpy
>> old timer" porkpie, size 7 and 3/8ths.
>>
>> regards,
>>
>> Ted Hardie
>> _______________________________________________
>> 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 adam@nostrum.com  Fri Mar  8 08:45: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 63A0221F869B for ; Fri,  8 Mar 2013 08:45:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.902
X-Spam-Level: 
X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[AWL=0.698, 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 DWyZP70lRdpp for ; Fri,  8 Mar 2013 08:45:25 -0800 (PST)
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 C1F9721F8644 for ; Fri,  8 Mar 2013 08:45:25 -0800 (PST)
Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r28GjKPr024996 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 8 Mar 2013 10:45:21 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <513A159E.4030800@nostrum.com>
Date: Fri, 08 Mar 2013 10:45:18 -0600
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Mary Barnes 
References:   <57A15FAF9E58F841B2B1651FFE16D281026A26@GENSJZMBX03.msg.int.genesyslab.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.144.32 is authenticated by a trusted mechanism)
Cc: "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" 
Subject: Re: [rtcweb] Checkpointing decisions in RTCWEB
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 08 Mar 2013 16:45:26 -0000

On 3/8/13 10:36, Mary Barnes wrote:
> [MB]  My concern is extrapolated a bit beyond just RTCWEB to the
> extensions that are being proposed for SDP to support RTCWEB -
> independent of whether RTCWEB uses it over the wire.  In cases where
> folks want interop with "legacy" SIP some form of the SDP needs to go
> over the wire.  In an ideal world, that would be the same SDP blob,
> but it doesn't appear that would be the case where RTCWEB is now.
> [/MB]

Much to my surprise, we actually saw exactly this mostly work at the 
SIPit in Boston. The places we fell down were ICE support and DTLS-SRTP, 
both of which are in the process of being adopted in SIP products at the 
moment.

> [MB] Are you saying that there are things that we need that SDP cannot
> express (or cannot be extended to express)?
> [MB] Right now, there are things you need in SDP that there is no
> agreement as to how they should be expressed.  I agree that the group
> could certainly pick a way and then try to live with it.  However,
> some of these things overlap with what CLUE needs.  If CLUE wants to
> use the same building blocks (and not create yet another way to do
> multi-stream), then CLUE would reuse some of what is being driven to
> meet RTCWEB requirements.  A CLUE application/endpoint will be using
> the SDP over the wire.

Given that most of the extensions under discussion are driven in equal 
measures by RTCWEB and CLUE, are you about to propose that CLUE move 
away from SDP as well? We could well charter a new WG for SDPNGNG.

/a

From mary.ietf.barnes@gmail.com  Fri Mar  8 09:08: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 C3B4821F8767 for ; Fri,  8 Mar 2013 09:08:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.782
X-Spam-Level: 
X-Spam-Status: No, score=-102.782 tagged_above=-999 required=5 tests=[AWL=-0.182, 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 MNwQrsLMk33k for ; Fri,  8 Mar 2013 09:08:15 -0800 (PST)
Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 103CC21F84FF for ; Fri,  8 Mar 2013 09:08:14 -0800 (PST)
Received: by mail-qc0-f173.google.com with SMTP id b12so641919qca.32 for ; Fri, 08 Mar 2013 09:08:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TZ5HcYBxUtaG+4Ij1DxjlChA25N91Qf1W0Kwb/BQ1f4=; b=GlIpBwzW2PRaPGcU+sFNwLs86o01ZUoHIE4hJ6oCaJH+vu8FImzhmyGc7mSnY4tQr9 kZ2Y5wM/s0DQLHFtz5jXxdeUGlaR3b6CYHPbLMUjIYHzzVInfpwg1n267aKwQt3AWfkF NOqy1txJb/rNp/lrm/D6avWUqooTaGQ1me2H6gpmCK5DEu3n9sUiiXaTJH+Xpv2SjRzp e7z9y2k3s84qZpIjo3OWZYWGqvfXks5XN5ecLWyau9wCcthLRq2QKnBvydDRtDM28eFw qNdFyPe41zKugzq37iGz6pgxVF0OlprvOuLxms+AplaJa/3RJuIPFpsUbyUE9GlQTbIx 7E/A==
MIME-Version: 1.0
X-Received: by 10.49.85.34 with SMTP id e2mr5097470qez.1.1362762493876; Fri, 08 Mar 2013 09:08:13 -0800 (PST)
Received: by 10.49.24.130 with HTTP; Fri, 8 Mar 2013 09:08:13 -0800 (PST)
In-Reply-To: <513A159E.4030800@nostrum.com>
References:   <57A15FAF9E58F841B2B1651FFE16D281026A26@GENSJZMBX03.msg.int.genesyslab.com>  <513A159E.4030800@nostrum.com>
Date: Fri, 8 Mar 2013 11:08:13 -0600
Message-ID: 
From: Mary Barnes 
To: Adam Roach 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" 
Subject: Re: [rtcweb] Checkpointing decisions in RTCWEB
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 08 Mar 2013 17:08:15 -0000

On Fri, Mar 8, 2013 at 10:45 AM, Adam Roach  wrote:
> On 3/8/13 10:36, Mary Barnes wrote:
>>
>> [MB]  My concern is extrapolated a bit beyond just RTCWEB to the
>> extensions that are being proposed for SDP to support RTCWEB -
>> independent of whether RTCWEB uses it over the wire.  In cases where
>> folks want interop with "legacy" SIP some form of the SDP needs to go
>> over the wire.  In an ideal world, that would be the same SDP blob,
>> but it doesn't appear that would be the case where RTCWEB is now.
>> [/MB]
>
>
> Much to my surprise, we actually saw exactly this mostly work at the SIPit
> in Boston. The places we fell down were ICE support and DTLS-SRTP, both of
> which are in the process of being adopted in SIP products at the moment.
[MB2] Right, but that wasn't doing any of the multistream stuff was
it?   Or, did I miss something in the SIPit report?  Again, I don't
debate you wizards can make things work.  [/MB2]
>
>
>> [MB] Are you saying that there are things that we need that SDP cannot
>> express (or cannot be extended to express)?
>> [MB] Right now, there are things you need in SDP that there is no
>> agreement as to how they should be expressed.  I agree that the group
>> could certainly pick a way and then try to live with it.  However,
>> some of these things overlap with what CLUE needs.  If CLUE wants to
>> use the same building blocks (and not create yet another way to do
>> multi-stream), then CLUE would reuse some of what is being driven to
>> meet RTCWEB requirements.  A CLUE application/endpoint will be using
>> the SDP over the wire.
>
>
> Given that most of the extensions under discussion are driven in equal
> measures by RTCWEB and CLUE, are you about to propose that CLUE move away
> from SDP as well? We could well charter a new WG for SDPNGNG.
[MB2]  My personal opinion is that CLUE would do much better to
minimize its dependency on SDP.  We will use SIP for basic session
setup.  We are in the process of figuring out exactly what from the
CLUE data (see the FW and data model in CLUE) can or should be carried
in SDP.   I'm (as an individual) of the opinion that we should do bare
minimum in SDP - e.g., just what it takes to get a CLUE client
endpoint connected  to a non-CLUE endpoint.  I believe that the more
we put in SDP, the less extensible CLUE will be. I don't think that's
a good thing when we are defining a new application.  There are those
that believe we can signal lots of stuff in the SDP - that introduces
a tighter coupling between the CLUE data and SDP.  As I said for the
RTCWEB folks, I don't doubt that the CLUE folks can eventually get it
specified and made to work putting as much as possible in SDP.  I will
note that there are already deployed and interoperable telepresence
applications out there that do rely entirely on SIP and SDP, so I am
not suggesting it isn't possible, but the reason for chartering CLUE
was that the implementations are not standards based (despite there
being a specification that defines the interfaces) and not easily
extended.  That was the motivation for chartering CLUE.  Note, we will
be having this discussion in CLUE WG on Monday morning.

And, no I don't think we need SDPNGNG.  I think we need to decouple
our applications from the underlying session setup protocols.  [/MB2]
>
> /a

From robin@hookflash.com  Fri Mar  8 11:05: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 03F9221F868E for ; Fri,  8 Mar 2013 11:05:04 -0800 (PST)
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 KEixbQWqzZXp for ; Fri,  8 Mar 2013 11:05:03 -0800 (PST)
Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD9821F8630 for ; Fri,  8 Mar 2013 11:05:03 -0800 (PST)
Received: by mail-ob0-f181.google.com with SMTP id ni5so1568073obc.26 for ; Fri, 08 Mar 2013 11:05:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=0eA5SwGwNJ8Tdpd2HVjtSBRJ6rVl38IJh+eirw8fjyI=; b=FsiBPaQ58bpCGbAqPr3YQrp5nHmUsB0DuCgMckLiRG8KDPlwmbbIWgncnX/rqC74Le 5DoE6O+XbIBoUWSXcifQMOajPB5X2Jj/G/1A07y+bPWqfB50PHekhAzcYNFe6A8mEQN8 LyKmGUqaiP0c0alFR2kq/iVpzLXhZNBA9c0JDXAZ2CQcMWV0QRbwo3KJYc0vdHPim21A y9NOxAGOQBC/A2nuR+VHBbQL5r3s26Y8X4f3Fz6rdpkD6a7aGJ7QxfpuKZUVeEqE4tFq lgFivoRn2ze+Kx+CPFULGqIHM8G60yStXtqLbUCKYcu7tAOFdjuGyMvJw0pUUyM81KSE SEbQ==
MIME-Version: 1.0
X-Received: by 10.182.245.109 with SMTP id xn13mr2724057obc.46.1362769502194;  Fri, 08 Mar 2013 11:05:02 -0800 (PST)
Received: by 10.60.134.197 with HTTP; Fri, 8 Mar 2013 11:05:02 -0800 (PST)
In-Reply-To: <57A15FAF9E58F841B2B1651FFE16D281026A26@GENSJZMBX03.msg.int.genesyslab.com>
References:   <57A15FAF9E58F841B2B1651FFE16D281026A26@GENSJZMBX03.msg.int.genesyslab.com>
Date: Fri, 8 Mar 2013 14:05:02 -0500
Message-ID: 
From: Robin Raymond 
To: Jim Barnett 
Content-Type: multipart/alternative; boundary=14dae93b602216e20504d76e80b7
X-Gm-Message-State: ALoCoQkFeDgXhofO6EgShCE9U1XnFUqzD0JGNz4n8UxlzeqHdLWGMiZPovCKgGsaFsRSzuAeAV0h
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Checkpointing decisions in RTCWEB
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 08 Mar 2013 19:05:04 -0000

--14dae93b602216e20504d76e80b7
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Mar 8, 2013 at 9:57 AM, Jim Barnett wrote:

> Mary,
>   How can there be interoperability issues if no one is required to use
> SDP over the wire?  Are you saying that there are things that we need that
> SDP cannot express (or cannot be extended to express)?
>
> - Jim
>
>
I just want to clarify something. Is the expectation that an application
developer can (if they so choose) take the SDP, parse it, extract the data,
send in an alternative format and then reassemble the SDP at the remote
side an accepted practice and an expected use case?

Regardless if it is or not, I'm positive that this extraction/assembly
process will be done but I want to make sure the expectation/use case is
absolutely clear. From what I've been reading, the expectation is the
browser generates "blob" and "blob" gets given to other party 'as is' but
perhaps I'm mistaken.

Further, the issue with SDP is also offer/answer. SDP isn't just a
arcane/obtuse format. It's a state machine and a media signalling protocol.
That causes a great deal of pain (breaks or messy hybrids) for other models
even if we can "disassemble and reassemble" SDP.

--14dae93b602216e20504d76e80b7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Fri, Mar 8, 2013 at 9:57 AM, Jim Barnett <<=
a href=3D"mailto:Jim.Barnett@genesyslab.com" target=3D"_blank">Jim.Barnett@=
genesyslab.com> wrote:


Mary,

=A0 How can there be interoperability issues if no one is required to use S=
DP over the wire? =A0Are you saying that there are things that we need that=
 SDP cannot express (or cannot be extended to express)?



- Jim




I just want to clarify something. Is the =
expectation that an application developer can (if they so choose) take the =
SDP, parse it, extract the data, send in an alternative format and then rea=
ssemble the SDP at the remote side an accepted practice and an expected use=
 case?



Regardless if it is or not, I'm positiv=
e that this extraction/assembly process will be done but I want to make sur=
e the expectation/use case is absolutely clear. From what I've been rea=
ding, the expectation is the browser generates "blob" and "b=
lob" gets given to other party 'as is' but perhaps I'm mis=
taken.



Further, the issue with SDP is also offer/a=
nswer. SDP isn't just a arcane/obtuse format. It's a state machine =
and a media signalling protocol. That causes a great deal of pain (breaks o=
r messy hybrids) for other models even if we can "disassemble and reas=
semble" SDP.





--14dae93b602216e20504d76e80b7--

From jim.barnett@genesyslab.com  Fri Mar  8 11:33: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 6AC3A21F88EE for ; Fri,  8 Mar 2013 11:33:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 Sbyy1Rm5Y-0F for ; Fri,  8 Mar 2013 11:33:20 -0800 (PST)
Received: from service108-us.mimecast.com (service108-us.mimecast.com [205.139.110.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC1221F88E8 for ; Fri,  8 Mar 2013 11:33:18 -0800 (PST)
Received: from webmail-us.genesyslab.com (168.75.250.4 [168.75.250.4]) (Using TLS) by service108-us.mimecast.com; Fri, 08 Mar 2013 14:33:17 -0500
Received: from GENSJZMBX03.msg.int.genesyslab.com ([fe80::fc31:8268:eb4c:f8af]) by GENSJZFE02.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Fri, 8 Mar 2013 11:33:13 -0800
From: Jim Barnett 
To: Robin Raymond 
Thread-Topic: [rtcweb] Checkpointing decisions in RTCWEB
Thread-Index: AQHOG4X1bqeXKKMkOkGn8rQENJxOWZicZ2SA//96ejCAAMzeAP//fcBQ
Date: Fri, 8 Mar 2013 19:33:13 +0000
Message-ID: <57A15FAF9E58F841B2B1651FFE16D281026B8A@GENSJZMBX03.msg.int.genesyslab.com>
References:   <57A15FAF9E58F841B2B1651FFE16D281026A26@GENSJZMBX03.msg.int.genesyslab.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [98.110.233.90]
MIME-Version: 1.0
X-MC-Unique: 113030814331709502
Content-Type: multipart/alternative; boundary="_000_57A15FAF9E58F841B2B1651FFE16D281026B8AGENSJZMBX03msgint_"
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Checkpointing decisions in RTCWEB
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 08 Mar 2013 19:33:22 -0000

--_000_57A15FAF9E58F841B2B1651FFE16D281026B8AGENSJZMBX03msgint_
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable

My understanding is that SDP is an API surface _only_.  So, yes, the applic=
ation developer can send whatever he wants over the wire.   (I imagine that=
 a lot of implementations, including ours, will send the SDP to the other s=
ide, but it's not required.)

I tend to agree with a previous poster who suggests that we separate proble=
ms with the offer/answer state machine from problems with the SDP API surfa=
ce.  We could keep the state machine but change the API surface, or change =
the API language and keep the state machine.


-          Jim

From: Robin Raymond [mailto:robin@hookflash.com]
Sent: Friday, March 08, 2013 2:05 PM
To: Jim Barnett
Cc: Mary Barnes; Ted Hardie; rtcweb@ietf.org
Subject: Re: [rtcweb] Checkpointing decisions in RTCWEB



On Fri, Mar 8, 2013 at 9:57 AM, Jim Barnett > wrote:
Mary,
  How can there be interoperability issues if no one is required to use SDP=
 over the wire?  Are you saying that there are things that we need that SDP=
 cannot express (or cannot be extended to express)?

- Jim


I just want to clarify something. Is the expectation that an application de=
veloper can (if they so choose) take the SDP, parse it, extract the data, s=
end in an alternative format and then reassemble the SDP at the remote side=
 an accepted practice and an expected use case?

Regardless if it is or not, I'm positive that this extraction/assembly proc=
ess will be done but I want to make sure the expectation/use case is absolu=
tely clear. From what I've been reading, the expectation is the browser gen=
erates "blob" and "blob" gets given to other party 'as is' but perhaps I'm =
mistaken.

Further, the issue with SDP is also offer/answer. SDP isn't just a arcane/o=
btuse format. It's a state machine and a media signalling protocol. That ca=
uses a great deal of pain (breaks or messy hybrids) for other models even i=
f we can "disassemble and reassemble" SDP.

--_000_57A15FAF9E58F841B2B1651FFE16D281026B8AGENSJZMBX03msgint_
Content-Type: text/html; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable











My understanding is that =
SDP is an API surface _only_.  So, yes, the application develop=
er can send whatever he wants over the wire.   (I imagine that
 a lot of implementations, including ours, will send the SDP to the other s=
ide, but it’s not required.)


 <=
/p>

I tend to agree with a pr=
evious poster who suggests that we separate problems with the offer/answer =
state machine from problems with the SDP API surface.  We
 could keep the state machine but change the API surface, or change the API=
 language and keep the state machine. 



 <=
/p>

- =
        
Jim


 <=
/p>



From: Robin Ra=
ymond [mailto:robin@hookflash.com]


Sent: Friday, March 08, 2013 2:05 PM

To: Jim Barnett

Cc: Mary Barnes; Ted Hardie; rtcweb@ietf.org

Subject: Re: [rtcweb] Checkpointing decisions in RTCWEB




 




 




 




On Fri, Mar 8, 2013 at 9:57 AM, Jim Barnett <Jim.Barnett@gen=
esyslab.com> wrote:


Mary,

  How can there be interoperability issues if no one is required to us=
e SDP over the wire?  Are you saying that there are things that we nee=
d that SDP cannot express (or cannot be extended to express)?



- Jim






 








 






I just want to clarify something. Is the expectation=
 that an application developer can (if they so choose) take the SDP, parse =
it, extract the data, send in an alternative format and then reassemble the=
 SDP at the remote side an accepted
 practice and an expected use case?






 






Regardless if it is or not, I'm positive that this e=
xtraction/assembly process will be done but I want to make sure the expecta=
tion/use case is absolutely clear. From what I've been reading, the expecta=
tion is the browser generates "blob"
 and "blob" gets given to other party 'as is' but perhaps I'm mis=
taken.






 






Further, the issue with SDP is also offer/answer. SD=
P isn't just a arcane/obtuse format. It's a state machine and a media signa=
lling protocol. That causes a great deal of pain (breaks or messy hybrids) =
for other models even if we can "disassemble
 and reassemble" SDP.






 













--_000_57A15FAF9E58F841B2B1651FFE16D281026B8AGENSJZMBX03msgint_--


From radhika.r.roy.civ@mail.mil  Fri Mar  8 11:33: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 3648321F890F for ; Fri,  8 Mar 2013 11:33:38 -0800 (PST)
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 NpKYCx-+ZnIU for ; Fri,  8 Mar 2013 11:33:37 -0800 (PST)
Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.11]) by ietfa.amsl.com (Postfix) with ESMTP id C929421F88E8 for ; Fri,  8 Mar 2013 11:33:36 -0800 (PST)
Received: from UCOLHP3B.easf.csd.disa.mil (131.64.100.151) by ucolhp3l.easf.csd.disa.mil (131.64.100.11) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 8 Mar 2013 19:33:27 +0000
Received: from UCOLHP9B.easf.csd.disa.mil ([169.254.10.116]) by UCOLHP3B.easf.csd.disa.mil ([131.64.100.151]) with mapi id 14.02.0309.003; Fri, 8 Mar 2013 19:33:27 +0000
From: "Roy, Radhika R CIV USARMY (US)" 
To: Mary Barnes , Adam Roach 
Thread-Topic: [rtcweb] Checkpointing decisions in RTCWEB (UNCLASSIFIED)
Thread-Index: AQHOHBsZcNqTVidNBEKjNK/XRAqS8picAGsAgAAGZ4CAACI/UA==
Date: Fri, 8 Mar 2013 19:33:25 +0000
Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF49A615FE@ucolhp9b.easf.csd.disa.mil>
References:   <57A15FAF9E58F841B2B1651FFE16D281026A26@GENSJZMBX03.msg.int.genesyslab.com>  <513A159E.4030800@nostrum.com> 
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_003D_01CE1C09.E28C1E00"
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" 
Subject: Re: [rtcweb] Checkpointing decisions in RTCWEB (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: Fri, 08 Mar 2013 19:33:38 -0000

------=_NextPart_000_003D_01CE1C09.E28C1E00
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Classification: UNCLASSIFIED
Caveats: NONE

[MB2] ...  I think we need to decouple our applications from the underlying
session setup protocols.  [/MB2]

[RRR]
It is a good idea to do so as it is also seen somewhat in the centralized
conferencing FW (RFC 5239). Accordingly, all other things were developed and
most of them have been new protocols although SIP and SDP were kept as they
are without any extensions per se. Probably it was the case to do so for
this.

If we use the same principles for RTCWEB, we can write a framework document
based on the experiences that we have gained after almost working nearly
more than a year, we can then start to see where we need to do the
development of new protocols keeping SIP and SDP as they are if we think
that our efforts have met a wall.

The reason that we need to do so because we can do an analysis and see what
exactly our requirements are and why we need to start all over again with a
new approach. So far, we have some ideas in both ways with pros and cons,
but it is not entirely clear why and what we exactly need to do to change
our present approaches. Even we take a new approach, we need to a convincing
analysis beforehand we will succeed in solving problems with our new
approach before changing our direction again. [/RRR]

Classification: UNCLASSIFIED
Caveats: NONE



------=_NextPart_000_003D_01CE1C09.E28C1E00
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
SIb3DQEJBTEPFw0xMzAzMDgxOTMzMjJaMCMGCSqGSIb3DQEJBDEWBBT0D5aycNvzwtG3C+Ir1RQH
5jdowzBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC
BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x
CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG
A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm
oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E
MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB
AQUABIIBABVaQ0S5G3YzXNELZPvRbvcyUdQ8PyCSUYVzDdizH6GZ1YiVz3JQNU75Qg4aixpTayE3
HsCdci0G+PNPKn4Yyl4xRMnMv95HWcAnaNplRaMaYqE4pBrBz0SUjore1koFJNNbLqIFCN3F/OtO
qAZiPlAXRkTn6wzDbiBkK1FIcGY199FUCYGkEFT0ppOyKU6DDYJM5GI5Mc7qa1d/GFPVdU/6fi4b
WJwdJApiqdPJl0Ced5DGauW7WtapN2VttjHYsB1lIDomqVFfTmzcQ6rYVYgVPVGYta4aDzfPVCge
7LVraglpnb5Z4dRDVM2dVGQkhTM8XDIhpZbNsXG2aSNLD70AAAAAAAA=

------=_NextPart_000_003D_01CE1C09.E28C1E00--

From martin.thomson@gmail.com  Fri Mar  8 11:51: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 AF7C321F8945 for ; Fri,  8 Mar 2013 11:51:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level: 
X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[AWL=-3.500, 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 ykgOXtk-g8S1 for ; Fri,  8 Mar 2013 11:51:19 -0800 (PST)
Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id A002621F8923 for ; Fri,  8 Mar 2013 11:51:18 -0800 (PST)
Received: by mail-lb0-f169.google.com with SMTP id m4so1622618lbo.28 for ; Fri, 08 Mar 2013 11:51:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=QhZKJIYPDgFH8iyVHwNhGDAQydHTHadVrw9fLVHkiEM=; b=PySfomlUD3zsk49qpiSeddQ8XnPgW7X6NP6Z11XEgsFy2JBFXd9IERK1gMMGwzyPy2 JQRRV0/Ox0Ilu2p8Tim4vw9mPNEkAr3pMZmFk0mRD9CmOQTDvR7QDXdOxDuJajIeMG7N x0+153nevzYLkgAwtjXDZQc/IFqSQm22yxeuWsW/fs2aIPtQzasbpN/0QtCtL5OKUYMF Z6ktWvp3tCMwNZ05WrtdeJFkoB7+R72r7S2XrQ2cv068chW2EbIvavTfLpv7KEZzL8/K lxLgcOH+mjApieeoDCi59h54Nsap7CUg4K0LJf254m4lNEJQyWtXTLxnVYyBN1XRXVRH xakQ==
MIME-Version: 1.0
X-Received: by 10.152.146.199 with SMTP id te7mr3043333lab.23.1362772277509; Fri, 08 Mar 2013 11:51:17 -0800 (PST)
Received: by 10.112.56.37 with HTTP; Fri, 8 Mar 2013 11:51:17 -0800 (PST)
In-Reply-To: <57A15FAF9E58F841B2B1651FFE16D281026B8A@GENSJZMBX03.msg.int.genesyslab.com>
References:   <57A15FAF9E58F841B2B1651FFE16D281026A26@GENSJZMBX03.msg.int.genesyslab.com>  <57A15FAF9E58F841B2B1651FFE16D281026B8A@GENSJZMBX03.msg.int.genesyslab.com>
Date: Fri, 8 Mar 2013 11:51:17 -0800
Message-ID: 
From: Martin Thomson 
To: Jim Barnett 
Content-Type: multipart/alternative; boundary=e89a8f22c55582c59204d76f258d
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Checkpointing decisions in RTCWEB
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 08 Mar 2013 19:51:19 -0000

--e89a8f22c55582c59204d76f258d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 8 March 2013 11:33, Jim Barnett  wrote:

>  My understanding is that SDP is an API surface _*only*_.  So, yes, the
> application developer can send whatever he wants over the wire.   (I
> imagine that a lot of implementations, including ours, will send the SDP =
to
> the other side, but it=E2=80=99s not required.)****
>
>
Even if this were the case, there are two important problems:
 - two browsers made by different vendors need to be able to produce and
consume SDP with predictable results.
- applications that do slice and dice need to be able to receive
predictable inputs and be able to produce outputs that are consumed by the
APIs in a predictable fashion.  Robin is right: applications will do this
because they have to.

Less important is the ability to take the product of a browser and send
that to a legacy endpoint, or do the same in the opposite direction.


> I tend to agree with a previous poster who suggests that we separate
> problems with the offer/answer state machine from problems with the SDP A=
PI
> surface.  We could keep the state machine but change the API surface, or
> change the API language and keep the state machine.
>
>  **
>
Both are problems, but yes, they are separable. Many things are almost
infinitely separable, but where separation can increase clarity, it can
also mask issues.  Caution advised.

--e89a8f22c55582c59204d76f258d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On 8=
 March 2013 11:33, Jim Barnett <Jim.Barnett@genesyslab.com>=
; wrote:













My understanding is that =
SDP is an API surface _only_.=C2=A0 So, yes, the application develop=
er can send whatever he wants over the wire.=C2=A0 =C2=A0(I imagine that
 a lot of implementations, including ours, will send the SDP to the other s=
ide, but it=E2=80=99s not required.)



Even if this were the case, there are two im=
portant problems:

=C2=A0- two browsers made by different vendors need to be able to produce a=
nd consume SDP with predictable results.
- applications that =
do slice and dice need to be able to receive predictable inputs and be able=
 to produce outputs that are consumed by the APIs in a predictable fashion.=
=C2=A0 Robin is right: applications will do this because they have to.


Less important is the ability to take the product of a brows=
er and send that to a legacy endpoint, or do the same in the opposite direc=
tion.
=C2=A0


I tend to agree with a previous poster who suggests that we separat=
e problems with the offer/answer state machine from problems with the SDP A=
PI surface.=C2=A0 We
 could keep the state machine but change the API surface, or change the API=
 language and keep the state machine.=C2=A0


 


Both are problems, but yes, they are separable. Many things=
 are almost infinitely separable, but where separation can increase clarity=
, it can also mask issues.=C2=A0 Caution advised.





--e89a8f22c55582c59204d76f258d--

From stewe@stewe.org  Fri Mar  8 12:14: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 43BF921F8984 for ; Fri,  8 Mar 2013 12:14:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.441
X-Spam-Level: 
X-Spam-Status: No, score=-4.441 tagged_above=-999 required=5 tests=[AWL=-1.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzNLnskb3-Y5 for ; Fri,  8 Mar 2013 12:14:21 -0800 (PST)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 618CB21F8936 for ; Fri,  8 Mar 2013 12:14:20 -0800 (PST)
Received: from mail5-am1-R.bigfish.com (10.3.201.250) by AM1EHSOBE012.bigfish.com (10.3.207.134) with Microsoft SMTP Server id 14.1.225.23; Fri, 8 Mar 2013 20:14:19 +0000
Received: from mail5-am1 (localhost [127.0.0.1])	by mail5-am1-R.bigfish.com (Postfix) with ESMTP id 709E12C00A3; Fri,  8 Mar 2013 20:14:19 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT001.namprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -10
X-BigFish: PS-10(zzc85ehfafJ4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1730fah1033IL177df4h17326ah8275dh18c673h1954cbh8275bh63567mf65c6kf3c47jz2fh2a8h668h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h)
Received-SPF: pass (mail5-am1: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT001.namprd07.prod.outlook.com ; .outlook.com ; 
Received: from mail5-am1 (localhost.localdomain [127.0.0.1]) by mail5-am1 (MessageSwitch) id 13627736576261_17996; Fri,  8 Mar 2013 20:14:17 +0000 (UTC)
Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.226])	by mail5-am1.bigfish.com (Postfix) with ESMTP id F23F81200B6; Fri,  8 Mar 2013 20:14:16 +0000 (UTC)
Received: from BL2PRD0710HT001.namprd07.prod.outlook.com (157.56.240.133) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 8 Mar 2013 20:14:16 +0000
Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.49]) by BL2PRD0710HT001.namprd07.prod.outlook.com ([10.255.102.36]) with mapi id 14.16.0275.006; Fri, 8 Mar 2013 20:14:08 +0000
From: Stephan Wenger 
To: Serge Lachapelle , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] VP8 IPR agreement announced.
Thread-Index: AQHOG2jFHPF2KVFzGUSG2LjE89vDs5ibtgcA
Date: Fri, 8 Mar 2013 20:14:08 +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: [10.255.102.5]
Content-Type: multipart/alternative; boundary="_000_CD5F826796635stewesteweorg_"
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Subject: Re: [rtcweb] VP8 IPR agreement announced.
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 08 Mar 2013 20:14:22 -0000

--_000_CD5F826796635stewesteweorg_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Serge,

This is a great development for VP8.  Congratulations.  I'm sure it took a =
few cycles and dollars to get something like this arranged.  I wish your PR=
 would have come out a bit earlier, but licensing discussions do take time=
=85  So better now than never.

I want to ask two more pieces of information that would allow me to put thi=
s announcement into context.

First, who are those 11 rightholders?  I'm sure you agree that, in order to=
 make a meaningful risk assessment, that information is needed.

Second, the link provided to "preview" the possible sublicensing terms (htt=
p://www.w3.org/2001/07/SVG10-IPR-statements) lists a bunch of company state=
ments that vary widely among the rightholders listed there, which do not in=
clude google.  It would be great if you could provide more specific informa=
tion as early as possible, especially with respect to the essential claims =
definition and the reciprocity conditions.  That does not have to be final =
legal text, but should be a clear indication of your business intentions.  =
To me, term-sheet level is OK.

Please understand that without that information (especially the first item=
=97on the second I at least would be willing to trust your good intentions =
in combination with written statements already one file), it will be very h=
ard to take a position based on an informed position.

Thanks,
Stephan

From: Serge Lachapelle >
Date: Thursday, 7 March, 2013 11:18
To: "rtcweb@ietf.org" >
Subject: [rtcweb] VP8 IPR agreement announced.

Hello,

Today, Google Inc. and MPEG LA, LLC have announced that they have entered i=
nto an agreement granting Google a license to techniques, if any, that may =
be essential to VP8. Furthermore, MPEG LA has agreed to discontinue efforts=
 to form a patent pool around VP8.

The official press release can be found here: http://goo.gl/F7xUu

The licensors are part of the group that responded to MPEG LA=92s call for =
patents. They are a group of well-known video IP holders and participants i=
n standards-based video patent pools.

This agreement allows for Google to sublicense the techniques to any user o=
f VP8, whether the VP8 implementation is by Google or another entity; this =
means that users can develop independent implementations of VP8 and still e=
njoy coverage under the sublicenses.

Google intends to license the techniques under terms that are in line with =
the W3C=92s definition of a Royalty Free License. This definition can be fo=
und here: http://www.w3.org/2001/07/SVG10-IPR-statements  We anticipate hav=
ing the sublicense ready in the next few weeks. The terms will appear on th=
e WebM Project website at http://webmproject.org

This agreement is not an acknowledgment that the licensed techniques read o=
n VP8. The purpose of this agreement is meant to provide further and strong=
er reassurance to implementors of VP8.

On a personal note, I think you will all agree that the RTCWeb MTI video co=
dec discussion included many whispered doubts but little evidence. In contr=
ast, we have taken clear steps to demonstrate the viability of VP8:

1. Made VP8 available with a strong, simple software license and patent gra=
nt.
2. Continued to innovate and improve VP8 in the open.
3. Licensed a royalty free VP8 enabled RTL (aka hardware source code) to mo=
re than 50 SOCs.
4. Built, iterated and launched VP8 powered WebRTC in the Chrome browser to=
 hundreds of millions of users.
5. Worked to ensure WebRTC interop using the VP8 and Opus formats by workin=
g closely with Firefox.
6. Introduced a preview of VP8 and Opus based WebRTC in Chrome for Android =
beta.

And now, we have taken taken two significant steps that we hope will make t=
he situation clear to all:

7. Submitted VP8 to ISO SC29/WG11 (MPEG) in January of this year for standa=
rdization.
8. Invested a significant amount of time and resources into reaching an agr=
eement with the MPEG LA, to provide further reassurances.

VP8 is a royalty free, open sourced codec that offers several advantages an=
d innovations for real time and other uses.  It has a publicly-available sp=
ecification that is getting broadly adopted in hardware; it has been submit=
ted for standardization to a leading standards body, and is the subject of =
a royalty-free RAND license which will now include a license covering any e=
ssential VP8 techniques that may be relevant to major IP holders who respon=
ded to the MPEG LA's call for VP8 patents.

It is the most suitable codec for MTI.

I understand the timing is very close to the Orlando IETF meeting.  While w=
e tried to do this as quickly as possible, I am sure you will appreciate th=
e sensitivities and enormous effort involved in reaching such an agreement.

I will be in Orlando, arriving monday evening and will be available to answ=
er questions.

/Serge

--_000_CD5F826796635stewesteweorg_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Hi Serge,







This is a great development for VP8.  Congratulations.  I'm =
sure it took a few cycles and dollars to get something like this arranged. =
 I wish your PR would have come out a bit earlier, but licensing discu=
ssions do take time=85  So better now than never.







I want to ask two more pieces of information that would allow me to pu=
t this announcement into context.







First, who are those 11 rightholders?  I'm sure you agree that, i=
n order to make a meaningful risk assessment, that information is needed.






Second, the link provided to "preview" the possible sublicen=
sing terms (http=
://www.w3.org/2001/07/SVG10-IPR-statements) lists a bunch of company st=
atements that vary widely among the rightholders
 listed there, which do not include google.  It would be great if you =
could provide more specific information as early as possible, especially wi=
th respect to the essential claims definition and the reciprocity condition=
s.  That does not have to be final legal
 text, but should be a clear indication of your business intentions.  =
To me, term-sheet level is OK.  







Please understand that without that information (especially the first =
item=97on the second I at least would be willing to trust your good intenti=
ons in combination with written statements already one file), it will be ve=
ry hard to take a position based on
 an informed position.







Thanks,


Stephan









From: Serge Lachapelle <sergel@webrtc.org>

Date: Thursday, 7 March, 2013 11:18=
 

To: "rtcweb@ietf.org" <=
rtcweb@ietf.org>

Subject: [rtcweb] VP8 IPR agreement=
 announced.















Hello,







Today, Google Inc. and MPEG LA, LLC have announced that they have ente=
red into an agreement granting Google a license to techniques, if any, that=
 may be essential to VP8. Furthermore, MPEG LA has agreed to discontinue ef=
forts to form a patent pool around
 VP8.







The official press release can be found here: http://goo.gl/F7xUu









The licensors are part of the group that responded to MPEG LA=92s call=
 for patents. They are a group of well-known video IP holders and participa=
nts in standards-based video patent pools.







This agreement allows for Google to sublicense the techniques to any u=
ser of VP8, whether the VP8 implementation is by Google or another entity; =
this means that users can develop independent implementations of VP8 and st=
ill enjoy coverage under the sublicenses. 







Google intends to license the techniques under terms that are in line =
with the W3C=92s definition of a Royalty Free License. This definition can =
be found here:
http://www.w3.org/2001/07/SVG10-IPR-statements  We anticipate ha=
ving the sublicense ready in the next few weeks. The terms will appear on t=
he WebM Project website at
http://webmproject.org=








This agreement is not an acknowledgment that the licensed techniques r=
ead on VP8. The purpose of this agreement is meant to provide further and s=
tronger reassurance to implementors of VP8. 







On a personal note, I think you will all agree that the RTCWeb MTI vid=
eo codec discussion included many whispered doubts but little evidence. In =
contrast, we have taken clear steps to demonstrate the viability of VP8:






1. Made VP8 available with a strong, simple software license and paten=
t grant.


2. Continued to innovate and improve VP8 in the open. 


3. Licensed a royalty free VP8 enabled RTL (aka hardware source code) =
to more than 50 SOCs.


4. Built, iterated and launched VP8 powered WebRTC in the Chrome brows=
er to hundreds of millions of users. 


5. Worked to ensure WebRTC interop using the VP8 and Opus formats by w=
orking closely with Firefox.


6. Introduced a preview of VP8 and Opus based WebRTC in Chrome for And=
roid beta.







And now, we have taken taken two significant steps that we hope will m=
ake the situation clear to all: 







7. Submitted VP8 to ISO SC29/WG11 (MPEG) in January of this year for s=
tandardization.


8. Invested a significant amount of time and resources into reaching a=
n agreement with the MPEG LA, to provide further reassurances.







VP8 is a royalty free, open sourced codec that offers several advantag=
es and innovations for real time and other uses.  It has a publicly-av=
ailable specification that is getting broadly adopted in hardware; it has b=
een submitted for standardization to
 a leading standards body, and is the subject of a royalty-free RAND licens=
e which will now include a license covering any essential VP8 techniques th=
at may be relevant to major IP holders who responded to the MPEG LA's call =
for VP8 patents.







It is the most suitable codec for MTI.







I understand the timing is very close to the Orlando IETF meeting. &nb=
sp;While we tried to do this as quickly as possible, I am sure you will app=
reciate the sensitivities and enormous effort involved in reaching such an =
agreement.







I will be in Orlando, arriving monday evening and will be available to=
 answer questions. 







/Serge











--_000_CD5F826796635stewesteweorg_--

From harald@alvestrand.no  Fri Mar  8 13: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 AAE7321F84DC for ; Fri,  8 Mar 2013 13:25:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.948
X-Spam-Level: 
X-Spam-Status: No, score=-110.948 tagged_above=-999 required=5 tests=[AWL=-0.350, 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 pSEebR6k7hx0 for ; Fri,  8 Mar 2013 13:25:21 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1B55021F84BC for ; Fri,  8 Mar 2013 13:25:21 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3C0C639E0FA for ; Fri,  8 Mar 2013 22:25:18 +0100 (CET)
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 3da6tjytaIPb for ; Fri,  8 Mar 2013 22:25:14 +0100 (CET)
Received: from [IPv6:2001:470:de0a:27:84a9:6a28:85d0:194b] (unknown [IPv6:2001:470:de0a:27:84a9:6a28:85d0:194b]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 9ECF639E0F3 for ; Fri,  8 Mar 2013 22:25:14 +0100 (CET)
Message-ID: <513A5739.8010801@alvestrand.no>
Date: Fri, 08 Mar 2013 22:25:13 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <5139AF4C.70109@ericsson.com>  <5139EFF8.7040603@ericsson.com>  
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020303010004080505020601"
Subject: [rtcweb] Division of labor (Re: Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Fri, 08 Mar 2013 21:25:22 -0000

This is a multi-part message in MIME format.
--------------020303010004080505020601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 03/08/2013 03:57 PM, Matthew Kaufman (SKYPE) wrote:
> Peter Thatcher:
>> Is the blob format defined by the IETF or the W3C?  If the W3C decided not to
>> use SDP as the blob, or not to use blobs at all, what would that mean for the
>> IETF?
> The W3C has apparently deferred to the IETF for everything, including what codecs should be mandatory and what the JavaScript API should look like.
The charters of the two WGs are interesting reading. I recommend reading 
them to anyone who wishes to know what the division of responsibilities 
was intended to be.

https://tools.ietf.org/wg/rtcweb/charters

" This work will be done in collaboration with the W3C. The IETF WG will 
produce architecture and requirements for selection and profiling of the 
on the wire protocols. The architecture needs to be coordinated with 
W3C. The IETF WG work will identify state information and events that 
need to be exposed in the APIs as input to W3C. The W3C will be 
responsible for defining APIs to ensure that application developers can 
control the components."

http://www.w3.org/2011/04/webrtc-charter.html

" While the specified API Functions will not constrain implementations 
into supporting a specific profile, they will be compatible with the 
Profile that will be specified by the RTCWeb Working Group"

The last-quoted paragraph was inserted after a discussion that concluded 
that only one organization should have the mandatory-to-implement codec 
discussion, and that the IETF should be the one place.

>
> Why this is the case, I don't know, but eventually there will be a W3C specification and it will contain a bunch of references to other specs and those either will or will not be acceptable to the W3C WG as a complete API.
>
> Matthew Kaufman
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--------------020303010004080505020601
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 03/08/2013 03:57 PM, Matthew Kaufman
      (SKYPE) wrote:

    

    

      
Peter Thatcher:


      

        
Is the blob format defined by the IETF or the W3C?  If the W3C decided not to
use SDP as the blob, or not to use blobs at all, what would that mean for the
IETF?


      

      
The W3C has apparently deferred to the IETF for everything, including what codecs should be mandatory and what the JavaScript API should look like.

    

    The charters of the two WGs are interesting reading. I recommend
    reading them to anyone who wishes to know what the division of
    responsibilities was intended to be.

    

    
    https://tools.ietf.org/wg/rtcweb/charters

    

    "
    
    This work will be done in collaboration with the W3C. The IETF WG
    will produce architecture and requirements for selection and
    profiling of the on the wire protocols. The architecture needs to be
    coordinated with W3C. The IETF WG work will identify state
    information and events that need to be exposed in the APIs as input
    to W3C. The W3C will be responsible for defining APIs to ensure that
    application developers can control the components."

    

    
    http://www.w3.org/2011/04/webrtc-charter.html

    

    "
    
    While the
      specified API Functions will not constrain implementations into
      supporting a specific profile, they will be compatible with the
      Profile that will be specified by the RTCWeb Working Group"

      

      The last-quoted paragraph was inserted after a discussion that
      concluded that only one organization should have the
      mandatory-to-implement codec discussion, and that the IETF should
      be the one place.

      

    
    

      

Why this is the case, I don't know, but eventually there will be a W3C specification and it will contain a bunch of references to other specs and those either will or will not be acceptable to the W3C WG as a complete API.

Matthew Kaufman

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


    

    

  


--------------020303010004080505020601--

From matthew@matthew.at  Fri Mar  8 13:29: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 15A7521F85B2 for ; Fri,  8 Mar 2013 13:29:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level: 
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AWL=0.052,  BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, 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 ThJgaVoevS8e for ; Fri,  8 Mar 2013 13:29:57 -0800 (PST)
Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id B580121F85B0 for ; Fri,  8 Mar 2013 13:29:57 -0800 (PST)
Received: from [10.10.155.229] (unknown [10.10.155.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 9649B230005 for ; Fri,  8 Mar 2013 13:29:57 -0800 (PST)
Message-ID: <513A5854.6020601@matthew.at>
Date: Fri, 08 Mar 2013 13:29:56 -0800
From: Matthew Kaufman 
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <5139AF4C.70109@ericsson.com>  <5139EFF8.7040603@ericsson.com>   <513A5739.8010801@alvestrand.no>
In-Reply-To: <513A5739.8010801@alvestrand.no>
Content-Type: multipart/alternative; boundary="------------030007000008020407050507"
Subject: Re: [rtcweb] Division of labor (Re: Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Fri, 08 Mar 2013 21:29:58 -0000

This is a multi-part message in MIME format.
--------------030007000008020407050507
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 3/8/2013 1:25 PM, Harald Alvestrand wrote:
> The W3C will be responsible for defining APIs to ensure that 
> application developers can control the components."

Yeah, that's the part that the W3C pretty much pointed at the JSEP draft 
and said "whatever IETF does"... and how you get a blob of SDP and an 
O/A state machine fighting back at you as "the JavaScript API".

Matthew Kaufman

--------------030007000008020407050507
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 3/8/2013 1:25 PM, Harald Alvestrand
      wrote:

    

    

      
      The W3C will be responsible for defining APIs to ensure that
      application developers can control the components."

    

    

    Yeah, that's the part that the W3C pretty much pointed at the JSEP
    draft and said "whatever IETF does"... and how you get a blob of SDP
    and an O/A state machine fighting back at you as "the JavaScript
    API".

    

    Matthew Kaufman

  


--------------030007000008020407050507--

From juberti@google.com  Fri Mar  8 14:57: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 20B8721F8578 for ; Fri,  8 Mar 2013 14:57:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.977
X-Spam-Level: 
X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 9UA54FUsafdc for ; Fri,  8 Mar 2013 14:57:11 -0800 (PST)
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 B784021F8576 for ; Fri,  8 Mar 2013 14:57:10 -0800 (PST)
Received: by mail-ie0-f169.google.com with SMTP id 13so2714929iea.14 for ; Fri, 08 Mar 2013 14:57:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=bdkEa8Ko37jF2hOrYnxPCZ6hdN3ysy8oGYnQtFmYQDA=; b=epVyGa6FtHP9uTTxYf9Bw1+ZHQqVom3QB8mTwHYEYNPwPCTomGiufzM7TQ8Z3goiEf 2T3CcOqQxHndpzvX9cNLKFeNrpZ6NgeYZOyeyunu4gJHBp6xV0izuTsWeUPzNeBViYEL QqnYmfj1KLFbSw+AAkykRATjmm2M7vexTBL425CIBaDeZi78yk+ww8tdmMd186BVTm8i WJVq0VYgYJ1/6Tw8chgxDm9GTz+69TW1QReKduvTdDk2nbDjGi1O+1qTD8kLL4e5VNLX ImEQPkyUpGo42wN8pF/jQomkb28MT4r7vaiEXH+AxdnAqETb0k0qD9Y0kZB3261tNowJ ClFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=bdkEa8Ko37jF2hOrYnxPCZ6hdN3ysy8oGYnQtFmYQDA=; b=Md1n5KvojeswzwMLIpM+pIP8jcRi8nS+QclHbVrO1XlZ+o61aJ5k2MaYgb7XYt7Jyb 1V9KthVfppDb9De5rpRIXQbin60DAAMjVKXh88daGkC4WIjtHiP2c1ge0n2QPiUgWK2U AlrGYiiyLhpcYMULtSGXpla4OpR5CMg1EOVkxCoxY5yMOKtb7GpOVvNhfv/eBwP+1Hr+ GnmSSMEgmZerMnz0SYNytJ4ZRL6IUCfI/ItMe05/cY9y+bZaIP8OeNXIb/2hiENa55PA dHMnWl9TV5CZLgMHHn/cfpbxhf7jN4Y4xaDbPN3dG079Qs0WxyBMM1WHaY/YYY07b0qu WYJQ==
X-Received: by 10.43.8.200 with SMTP id ot8mr2738595icb.11.1362783430071; Fri, 08 Mar 2013 14:57:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.250.18 with HTTP; Fri, 8 Mar 2013 14:56:50 -0800 (PST)
In-Reply-To: 
References: 
From: Justin Uberti 
Date: Fri, 8 Mar 2013 14:56:50 -0800
Message-ID: 
To: Robin Raymond 
Content-Type: multipart/alternative; boundary=bcaec5161fff41713404d771befc
X-Gm-Message-State: ALoCoQmTbtZ4PgPUsEMbhLRGdRPTUbhpdL4LwkTCQxls1m4EVJ1eHaRlJ0OLapf1K3QlwGzL3br/SMAqX8D9YZ7UR89nd9wBDQaKJpZk2Jwr5kPCtWd1MvjV5lWXEoqhAgl8Iwh6YBGvdapsn3n4R3wXGtp5VeYdJpuY9l5SgMt0qKGgUscN4DwmrL0o0tpabBgDssH9+9rn
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Fri, 08 Mar 2013 22:57:12 -0000

--bcaec5161fff41713404d771befc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I sympathize with the concerns originally posted by Robin, and I am glad to
see this kind of application developer feedback in this forum.

The current model has many compromises, to be sure. But in this WG, we have
been able to resolve many tough decisions, and get to a point where we have
multiple interoperating implementations, spanning desktop and mobile, which
means we must be doing at least something right. So, with apologies to the
Beatles, when you talk about destruction, don't you know that you can count
me out.

Rather, as I look at Robin's comments, which are directed toward
https://datatracker.ietf.org/doc/draft-jennings-rtcweb-plan/, I see them as
an indication that "Plan A" ties us more deeply to SDP and legacy
behaviors. He wants the ability to make his own decisions about how these
things should be handled, including setting the SSRC for a stream, setting
FEC, crypto keys, multiplexing, etc. This is more akin to the "Plan B"
approach, which Chrome currently implements (and in which these things are
possible, albeit through SDP).

I certainly agree that SDP is a terrible thing to have to work with from
within a Javascript application, and as Peter has mentioned, there are a
number of ways in which we could improve that. But that is a question about
the API surface, and we can (and should) deal with this separately in the
W3C.



On Wed, Mar 6, 2013 at 3:45 PM, Robin Raymond  wrote:

>
>
>
>
>
> Do we need SDP "blob" format in the exchange in the first place? All medi=
a
> can be done without SDP given an intelligent stream API. An API already
> exists to create these streams (albeit somewhat lacking if we remove the
> SDP 'blob'). This API helps "simplify" creating this blob for later
> exchange. But the blob is truly not needed. Each side could in fact creat=
e
> the desired streams, pass in the appropriate media information such as
> codecs and ICE candidates and chose the socket pair to multiplex upon.
> Yes, it's a bit more low level but it certainly can be done (and cleanly)=
.
>
> https://datatracker.ietf.org/doc/draft-jennings-rtcweb-plan/
>
> Nothing wrong with the draft in an SDP/SIP mindset but I'm going to take
> it from a totally different non-SDP angle. I have to say, the ideas
> presented are very good. I appreciate FEC, and synchronizing streams is
> cool. But SDP isn=C2=B9t needed to do it. Let me as the programmer worry =
about
> how to manage streams and the features on the streams and associations
> between the streams via an API only.
>
> Point 4, 5 and 6 in the specification all have to do with the complexitie=
s
> of having to describe the intentions of mixing in SDP. So no comment
> beyond =C2=B3don=C2=B9t use SDP=C2=B2.
>
> As for 7.1 =C2=AD =C2=B3this is because the sender choses the SSRC=C2=B2 =
=C2=AD only true
> because we are forced to use SDP and the assumptions is that it=C2=B9s SI=
P. We
> could have the receiver dictate what the sender should use in advance of
> any media. In our case, we establish in advance what we want from all
> parties before even =C2=B3ringing=C2=B2 the other party. We do not have S=
SRC
> collisions as we reversed the scenario allowing the receiver to pick the
> expected SSRC. Coordinating the streams is a problem with SIP because of
> how they do forking/conferencing. This specification forces this issue on
> those not using SIP. If SIP has problems with streams arriving early to
> their stateful offer/answer then let them worry about =C2=B3how=C2=B2 the=
y intend to
> match the streams at a higher SDP layer and get this draft out of the
> RTCWEB track on the SIP track. To be clear, the proposal seems entirely
> reasonable and intelligent for SIP/SDP. But it=C2=B9s way to SIP centric =
for
> general use.
>
> On that note, what I do need in the API is an ability to dictate the SSRC
> when I create an RTP stream for sending (should I care to do that).
>
> 7.2 Multiple render
>
> Again this is an issue of SIP/SDP. We can control the SSRCs to split them
> out to allow multiplexing easily on the same RTP ports with multiple
> parties/sources. If given the primitives to control the streams just, thi=
s
> specification could be used to dictate how to negotiate issues in their
> space.
>
> 7.2.1 I=C2=B9m feeling the pain. How about just giving me an API where I =
can
> indicate what streams are FEC associated.
>
> 7.3 Give me API to give crypto keys to RTP layer. Let me handle the
> fingerprint and security myself beyond that.
>
> 8. Let's just say politely that I would not want to be the developer
> assigned to programming around all this stuff.
>
> Again, a perfect illustration why I don=C2=B9t want SDP.
>
> Media is complicated for good reason as there are many untold use cases.
> The entire IETF/W3C discussion around video constraints illustrates some
> of the complexities and competing desires for just one single media type.
> If we tie ourselves to SDP we are limiting ourselves big time, and some o=
f
> the cool future stuff will be horribly hampered by it.
>
> My issues with SDP can be summarized as:
>
> - unneeded - much too high level an API
> - arcane format - legacy and problematic
> - offer/answer
> - incompatibilities
> - lack of API contact
> - doesn't truly solve goal of interoperability with legacy systems (eg.
> SIP)
>
> Regret that I did not have time for feedback earlier. As you can tell, I
> am not at all happy with where we sit today wrt requiring SDP. IMHO we
> need a lower level API if we are going to insist on using SDP.
>
>
> You can read my entire (long) rant against SDP here
> http://blog.webrtc.is/2013/03/06/sdp-the-webrtc-boat-anchor/
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--bcaec5161fff41713404d771befc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I sympathize with the concerns originally posted by Robin,=
 and I am glad to see this kind of application developer feedback in this f=
orum.

The current model has many compromises, to b=
e sure. But in this WG, we have been able to resolve many tough decisions, =
and get to a point where we have multiple interoperating implementations, s=
panning desktop and mobile, which means we must be doing at least something=
 right. So, with apologies to the Beatles,=C2=A0when you talk about destruction, don't you know that you can co=
unt me out.



Rather, as I look at Robin's comments, which are directe=
d toward=C2=A0https://datatracker.ietf.org/doc/draft-jennings-rtcweb-plan/, =
I see them as an indication that "Plan A" ties us more deeply to =
SDP and legacy behaviors. He wants the ability to make his own decisions ab=
out how these things should be handled, including setting the SSRC for a st=
ream, setting FEC, crypto keys, multiplexing, etc. This is more akin to the=
 "Plan B" approach, which Chrome currently implements (and in whi=
ch these things are possible, albeit through SDP).




I certainly agree that SDP is a terrible th=
ing to have to work with from within a Javascript application, and as Peter=
 has mentioned, there are a number of ways in which we could improve that. =
But that is a question about the API surface, and we can (and should) deal =
with this separately in the W3C.






On Wed, Mar 6, 2013 at 3:45 PM, Robin Raymond <=
;robin@hookflash.c=
om> wrote:













Do we need SDP "blob" format in the exchange in the first place? =
All media

can be done without SDP given an intelligent stream API. An API already

exists to create these streams (albeit somewhat lacking if we remove the
SDP 'blob'). This API helps "simplify" creating this blob=
 for later

exchange. But the blob is truly not needed. Each side could in fact create<=
br>
the desired streams, pass in the appropriate media information such as

codecs and ICE candidates and chose the socket pair to multiplex upon.

Yes, it's a bit more low level but it certainly can be done (and cleanl=
y).



https://datatracker.ietf.org/doc/draft-jennings-rtcweb-plan=
/



Nothing wrong with the draft in an SDP/SIP mindset but I'm going to tak=
e

it from a totally different non-SDP angle. I have to say, the ideas

presented are very good. I appreciate FEC, and synchronizing streams is

cool. But SDP isn=C2=B9t needed to do it. Let me as the programmer worry ab=
out

how to manage streams and the features on the streams and associations

between the streams via an API only.



Point 4, 5 and 6 in the specification all have to do with the complexities<=
br>
of having to describe the intentions of mixing in SDP. So no comment

beyond =C2=B3don=C2=B9t use SDP=C2=B2.



As for 7.1 =C2=AD =C2=B3this is because the sender choses the SSRC=C2=B2 =
=C2=AD only true

because we are forced to use SDP and the assumptions is that it=C2=B9s SIP.=
 We

could have the receiver dictate what the sender should use in advance of
any media. In our case, we establish in advance what we want from all

parties before even =C2=B3ringing=C2=B2 the other party. We do not have SSR=
C

collisions as we reversed the scenario allowing the receiver to pick the
expected SSRC. Coordinating the streams is a problem with SIP because of
how they do forking/conferencing. This specification forces this issue on
those not using SIP. If SIP has problems with streams arriving early to

their stateful offer/answer then let them worry about =C2=B3how=C2=B2 they =
intend to

match the streams at a higher SDP layer and get this draft out of the

RTCWEB track on the SIP track. To be clear, the proposal seems entirely

reasonable and intelligent for SIP/SDP. But it=C2=B9s way to SIP centric fo=
r

general use.



On that note, what I do need in the API is an ability to dictate the SSRC
when I create an RTP stream for sending (should I care to do that).



7.2 Multiple render



Again this is an issue of SIP/SDP. We can control the SSRCs to split them
out to allow multiplexing easily on the same RTP ports with multiple

parties/sources. If given the primitives to control the streams just, this<=
br>
specification could be used to dictate how to negotiate issues in their

space.



7.2.1 I=C2=B9m feeling the pain. How about just giving me an API where I ca=
n

indicate what streams are FEC associated.



7.3 Give me API to give crypto keys to RTP layer. Let me handle the

fingerprint and security myself beyond that.



8. Let's just say politely that I would not want to be the developer
assigned to programming around all this stuff.



Again, a perfect illustration why I don=C2=B9t want SDP.



Media is complicated for good reason as there are many untold use cases.
The entire IETF/W3C discussion around video constraints illustrates some
of the complexities and competing desires for just one single media type.
If we tie ourselves to SDP we are limiting ourselves big time, and some of<=
br>
the cool future stuff will be horribly hampered by it.



My issues with SDP can be summarized as:



- unneeded - much too high level an API

- arcane format - legacy and problematic

- offer/answer

- incompatibilities

- lack of API contact

- doesn't truly solve goal of interoperability with legacy systems (eg.=


SIP)



Regret that I did not have time for feedback earlier. As you can tell, I
am not at all happy with where we sit today wrt requiring SDP. IMHO we

need a lower level API if we are going to insist on using SDP.





You can read my entire (long) rant against SDP here

http://blog.webrtc.is/2013/03/06/sdp-the-webrtc-boat-anchor=
/







_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--bcaec5161fff41713404d771befc--

From bo.burman@ericsson.com  Fri Mar  8 15:03: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 E09D321F85BD for ; Fri,  8 Mar 2013 15:03:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.933
X-Spam-Level: 
X-Spam-Status: No, score=-5.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xt6F-aM+mUj1 for ; Fri,  8 Mar 2013 15:03:30 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEFE21F85BB for ; Fri,  8 Mar 2013 15:03:29 -0800 (PST)
X-AuditID: c1b4fb25-b7f366d000004d10-fe-513a6e405b56
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 81.0F.19728.04E6A315; Sat,  9 Mar 2013 00:03:28 +0100 (CET)
Received: from ESESSMB105.ericsson.se ([169.254.5.124]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0318.004; Sat, 9 Mar 2013 00:03:27 +0100
From: Bo Burman 
To: Serge Lachapelle , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] VP8 IPR agreement announced.
Thread-Index: AQHOG2izufbB7AdJh0qHqd6TmHnGLZicK2UAgAA+piA=
Date: Fri, 8 Mar 2013 23:03:26 +0000
Message-ID: 
References:  
In-Reply-To: 
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: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22DE2E2FBESESSMB105erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvja5DnlWgwa21khZr/7WzW5zdUmFx vXETuwOzx5IlP5k8Fq9/z+jxe98itgDmKC6blNSczLLUIn27BK6MJQ/XMRf0VFb0zXrJ3sC4 MbWLkZNDQsBE4vrHP0wQtpjEhXvr2boYuTiEBA4xStz52sYE4SxmlLh87z5YFZuAhsT8HXcZ QWwRAV+JGetnsHcxcnAwC6hI/F7tAmIKCxhJ/L+VAVFhLPH8+Sp2CNtKon3JdxYQmwWoetXf 7WATeYGmTH5yCqxGSKBY4uaTRjYQm1NAV+LY3n5WEJtRQFbi/vd7YL3MAuISt57Mh7pZQGLJ nvPMELaoxMvH/1hBTpAQUJRY3i8HUZ4vce7wEUaIVYISJ2c+YZnAKDoLyaRZSMpmISmDiOtI LNj9iQ3C1pZYtvA1M4x95sBjJmTxBYzsqxjZcxMzc9LLjTYxAiPs4JbfqjsY75wTOcQozcGi JM4b7nohQEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjUdOJ8Au71qcnrD4ToLbknLFAtdEM 7ZPHVS5++axWIzJNW/Cp+42LMk8rT/DPX7s3u+vSrA2OZ5cE1/Y73rz5vSY5ovgR85TazbZP XoaoTfmTrX3N7Whuh5otJ4f2pte1NdM+/t8foLZCzH9OULpSYukKGa29W1cvy14XMU3Orr9N 9lHA8kcFSizFGYmGWsxFxYkAC3Tb7X4CAAA=
Subject: Re: [rtcweb] VP8 IPR agreement announced.
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 08 Mar 2013 23:03:34 -0000

--_000_BBE9739C2C302046BD34B42713A1E2A22DE2E2FBESESSMB105erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Serge,

This is indeed interesting, but I anyway have a couple of follow up questio=
ns, in addition to the ones listed by Stephan below:

  *   Who among the ones in the group that responded to the MPEG-LA call ar=
e not part of the deal? Why? What will the implications be for implementing=
 or shipping?
  *   How will Google act if (when) other IPR holders approach people imple=
menting/shipping VP8 devices, or approaches MPEG-LA? Will Google extend the=
 deal to cover these IPRs as well, and sub-license on the same terms as out=
lined below?

/Bo

________________________________
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Stephan Wenger
Sent: Friday, March 08, 2013 9:14 PM
To: Serge Lachapelle; rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 IPR agreement announced.

Hi Serge,

This is a great development for VP8.  Congratulations.  I'm sure it took a =
few cycles and dollars to get something like this arranged.  I wish your PR=
 would have come out a bit earlier, but licensing discussions do take time.=
..  So better now than never.

I want to ask two more pieces of information that would allow me to put thi=
s announcement into context.

First, who are those 11 rightholders?  I'm sure you agree that, in order to=
 make a meaningful risk assessment, that information is needed.

Second, the link provided to "preview" the possible sublicensing terms (htt=
p://www.w3.org/2001/07/SVG10-IPR-statements) lists a bunch of company state=
ments that vary widely among the rightholders listed there, which do not in=
clude google.  It would be great if you could provide more specific informa=
tion as early as possible, especially with respect to the essential claims =
definition and the reciprocity conditions.  That does not have to be final =
legal text, but should be a clear indication of your business intentions.  =
To me, term-sheet level is OK.

Please understand that without that information (especially the first item-=
on the second I at least would be willing to trust your good intentions in =
combination with written statements already one file), it will be very hard=
 to take a position based on an informed position.

Thanks,
Stephan

From: Serge Lachapelle >
Date: Thursday, 7 March, 2013 11:18
To: "rtcweb@ietf.org" >
Subject: [rtcweb] VP8 IPR agreement announced.

Hello,

Today, Google Inc. and MPEG LA, LLC have announced that they have entered i=
nto an agreement granting Google a license to techniques, if any, that may =
be essential to VP8. Furthermore, MPEG LA has agreed to discontinue efforts=
 to form a patent pool around VP8.

The official press release can be found here: http://goo.gl/F7xUu

The licensors are part of the group that responded to MPEG LA's call for pa=
tents. They are a group of well-known video IP holders and participants in =
standards-based video patent pools.

This agreement allows for Google to sublicense the techniques to any user o=
f VP8, whether the VP8 implementation is by Google or another entity; this =
means that users can develop independent implementations of VP8 and still e=
njoy coverage under the sublicenses.

Google intends to license the techniques under terms that are in line with =
the W3C's definition of a Royalty Free License. This definition can be foun=
d here: http://www.w3.org/2001/07/SVG10-IPR-statements  We anticipate havin=
g the sublicense ready in the next few weeks. The terms will appear on the =
WebM Project website at http://webmproject.org

This agreement is not an acknowledgment that the licensed techniques read o=
n VP8. The purpose of this agreement is meant to provide further and strong=
er reassurance to implementors of VP8.

On a personal note, I think you will all agree that the RTCWeb MTI video co=
dec discussion included many whispered doubts but little evidence. In contr=
ast, we have taken clear steps to demonstrate the viability of VP8:

1. Made VP8 available with a strong, simple software license and patent gra=
nt.
2. Continued to innovate and improve VP8 in the open.
3. Licensed a royalty free VP8 enabled RTL (aka hardware source code) to mo=
re than 50 SOCs.
4. Built, iterated and launched VP8 powered WebRTC in the Chrome browser to=
 hundreds of millions of users.
5. Worked to ensure WebRTC interop using the VP8 and Opus formats by workin=
g closely with Firefox.
6. Introduced a preview of VP8 and Opus based WebRTC in Chrome for Android =
beta.

And now, we have taken taken two significant steps that we hope will make t=
he situation clear to all:

7. Submitted VP8 to ISO SC29/WG11 (MPEG) in January of this year for standa=
rdization.
8. Invested a significant amount of time and resources into reaching an agr=
eement with the MPEG LA, to provide further reassurances.

VP8 is a royalty free, open sourced codec that offers several advantages an=
d innovations for real time and other uses.  It has a publicly-available sp=
ecification that is getting broadly adopted in hardware; it has been submit=
ted for standardization to a leading standards body, and is the subject of =
a royalty-free RAND license which will now include a license covering any e=
ssential VP8 techniques that may be relevant to major IP holders who respon=
ded to the MPEG LA's call for VP8 patents.

It is the most suitable codec for MTI.

I understand the timing is very close to the Orlando IETF meeting.  While w=
e tried to do this as quickly as possible, I am sure you will appreciate th=
e sensitivities and enormous effort involved in reaching such an agreement.

I will be in Orlando, arriving monday evening and will be available to answ=
er questions.

/Serge

--_000_BBE9739C2C302046BD34B42713A1E2A22DE2E2FBESESSMB105erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi =
Serge,




This is indeed interes=
ting, but I anyway
have a couple of follow up questions, in addition to the ones listed=
 by Stephan below:


    

  • Who among the o=
nes in the group that responded to the MPEG-LA call
are not part of the deal? Why? What will the implications be for implementing or shipping?

  • How will Google =
act if (when) other IPR holders approach people
implementing/shipping VP8 devices, or approaches MPEG-LA? Will
Google extend the deal to cover these IPRs as well, and sub-license
on the same terms as outlined below?


/Bo











From: rtcweb-bounces@ietf.org [mail=
to:rtcweb-bounces@ietf.org]
On Behalf Of Stephan Wenger

Sent: Friday, March 08, 2013 9:14 PM

To: Serge Lachapelle; rtcweb@ietf.org

Subject: Re: [rtcweb] VP8 IPR agreement announced.








Hi Serge,







This is a great development for VP8.  Congratulations.  I'm =
sure it took a few cycles and dollars to get something like this arranged. =
 I wish your PR would have come out a bit earlier, but licensing discu=
ssions do take time…  So better now than never.







I want to ask two more pieces of information that would allow me to pu=
t this announcement into context.







First, who are those 11 rightholders?  I'm sure you agree that, i=
n order to make a meaningful risk assessment, that information is needed.






Second, the link provided to "preview" the possible sublicen=
sing terms (http=
://www.w3.org/2001/07/SVG10-IPR-statements) lists a bunch of company st=
atements that vary widely among the rightholders
 listed there, which do not include google.  It would be great if you =
could provide more specific information as early as possible, especially wi=
th respect to the essential claims definition and the reciprocity condition=
s.  That does not have to be final legal
 text, but should be a clear indication of your business intentions.  =
To me, term-sheet level is OK.  







Please understand that without that information (especially the first =
item—on the second I at least would be willing to trust your good int=
entions in combination with written statements already one file), it will b=
e very hard to take a position based on
 an informed position.







Thanks,


Stephan









From: Serge Lachapelle <sergel@webrtc.org>

Date: Thursday, 7 March, 2013 11:1=
8 

To: "rtcweb@ietf.org" <rtcweb@ietf.org>

Subject: [rtcweb] VP8 IPR agreemen=
t announced.















Hello,







Today, Google Inc. and MPEG LA, LLC have announced that they have ente=
red into an agreement granting Google a license to techniques, if any, that=
 may be essential to VP8. Furthermore, MPEG LA has agreed to discontinue ef=
forts to form a patent pool around
 VP8.







The official press release can be found here: http://goo.gl/F7xUu









The licensors are part of the group that responded to MPEG LA’s =
call for patents. They are a group of well-known video IP holders and parti=
cipants in standards-based video patent pools.







This agreement allows for Google to sublicense the techniques to any u=
ser of VP8, whether the VP8 implementation is by Google or another entity; =
this means that users can develop independent implementations of VP8 and st=
ill enjoy coverage under the sublicenses. 







Google intends to license the techniques under terms that are in line =
with the W3C’s definition of a Royalty Free License. This definition =
can be found here:
http://www.w3.org/2001/07/SVG10-IPR-statements  We anticipate ha=
ving the sublicense ready in the next few weeks. The terms will appear on t=
he WebM Project website at
http://webmproject.org=








This agreement is not an acknowledgment that the licensed techniques r=
ead on VP8. The purpose of this agreement is meant to provide further and s=
tronger reassurance to implementors of VP8. 







On a personal note, I think you will all agree that the RTCWeb MTI vid=
eo codec discussion included many whispered doubts but little evidence. In =
contrast, we have taken clear steps to demonstrate the viability of VP8:






1. Made VP8 available with a strong, simple software license and paten=
t grant.


2. Continued to innovate and improve VP8 in the open. 


3. Licensed a royalty free VP8 enabled RTL (aka hardware source code) =
to more than 50 SOCs.


4. Built, iterated and launched VP8 powered WebRTC in the Chrome brows=
er to hundreds of millions of users. 


5. Worked to ensure WebRTC interop using the VP8 and Opus formats by w=
orking closely with Firefox.


6. Introduced a preview of VP8 and Opus based WebRTC in Chrome for And=
roid beta.







And now, we have taken taken two significant steps that we hope will m=
ake the situation clear to all: 







7. Submitted VP8 to ISO SC29/WG11 (MPEG) in January of this year for s=
tandardization.


8. Invested a significant amount of time and resources into reaching a=
n agreement with the MPEG LA, to provide further reassurances.







VP8 is a royalty free, open sourced codec that offers several advantag=
es and innovations for real time and other uses.  It has a publicly-av=
ailable specification that is getting broadly adopted in hardware; it has b=
een submitted for standardization to
 a leading standards body, and is the subject of a royalty-free RAND licens=
e which will now include a license covering any essential VP8 techniques th=
at may be relevant to major IP holders who responded to the MPEG LA's call =
for VP8 patents.







It is the most suitable codec for MTI.







I understand the timing is very close to the Orlando IETF meeting. &nb=
sp;While we tried to do this as quickly as possible, I am sure you will app=
reciate the sensitivities and enormous effort involved in reaching such an =
agreement.







I will be in Orlando, arriving monday evening and will be available to=
 answer questions. 







/Serge











--_000_BBE9739C2C302046BD34B42713A1E2A22DE2E2FBESESSMB105erics_--

From magnus.westerlund@ericsson.com  Fri Mar  8 23:41: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 D492021F851F for ; Fri,  8 Mar 2013 23:41:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.574
X-Spam-Level: 
X-Spam-Status: No, score=-105.574 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_111=0.6, J_CHICKENPOX_17=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 xTGdPFPZNIzy for ; Fri,  8 Mar 2013 23:41:39 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 529A921F8518 for ; Fri,  8 Mar 2013 23:41:38 -0800 (PST)
X-AuditID: c1b4fb25-b7f366d000004d10-93-513ae7b1cade
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 2A.FC.19728.1B7EA315; Sat,  9 Mar 2013 08:41:37 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Sat, 9 Mar 2013 08:41:36 +0100
Message-ID: <513AE7A8.7000405@ericsson.com>
Date: Sat, 9 Mar 2013 08:41:28 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org, EKR 
References: 
In-Reply-To: 
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmluLIzCtJLcpLzFFi42KZGfG3Rnfjc6tAg6brQhYrXp9jt1j7r53d gcljyZKfTB6TH7cxBzBFcdmkpOZklqUW6dslcGWsurWApeC+TcWP7jfMDYxX9LsYOTkkBEwk ej7NYIOwxSQu3FsPZHNxCAmcZJSYt/U1E4SzjFHi6L8GVpAqXgFtia9tf9lBbBYBFYlp596x gNhsAhYSN380AnVzcIgKBEvcXCwHUS4ocXLmE7ASEQF1iRnzt4EtExYIlPh15RQrSLmQQIDE 5oklIGFOoPDzo1OZIO6RlNjyoh1sE7OAnsSUqy2MELa8RPPW2cwgthDQNQ1NHawTGAVnIdk2 C0nLLCQtCxiZVzGy5yZm5qSXG21iBAbkwS2/VXcw3jkncohRmoNFSZw33PVCgJBAemJJanZq akFqUXxRaU5q8SFGJg5OqQbGolfez29fizrd+vLo3FPsh9751HGJTjx0nssndsJzr4sLb+l4 K2geN7ztWXBGMfvuxrx+ubLzSpt0jMW7Qi+wlV1dJ5QrE7njd5aX18wOYX+l8+Va7Nu6vmVu eygZef6X4fetkSfeTX2f8jzR0322Btv8TI+HGwOlLhgZfG09GOYT9lVFvPqNEktxRqKhFnNR cSIA41m9AhYCAAA=
Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-security-arch
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 09 Mar 2013 07:41:39 -0000

EKR, WG,

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?

2. Section 7.2 is wrongly labeled, I assume it is -04 version

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?

4. Figure 4. The arrow between Bob's browser and Bob's IdP is missalinged.

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.

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.

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?

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.

9. Section 5.1, similarly I think this applies to the second open issue
in this section.

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.

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.

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.

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.

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.

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?

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.

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?

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!

20. Section 5.6.4.1:

   The "algorithm" and digest values correspond directly to the
   algorithm and digest in the a=fingerprint line of the SDP.

Should there be a reference to where a=fingerprint is defined here?

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

21. Section 5.6.4.2:
This SDP attribute is underspecified. No clear definition of what is
allowed, no IANA consideration section registering it.

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.

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?

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?

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?

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?

26. Section 5.6.5.2.3:

Are the fields required to be included or not. This is a bit unclear.

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

27. Section 5.6.5.2.3.1

Open issue needing resolution. No opinion.

28. Section 5.7.2:

Missing the linkability issues discussion here.

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.]

I think you can remove the parenthis but keep the text here.

30. Page 40 SDP example looks strange with no a=idenity attribute,
instead just the JSON object.


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 harald@alvestrand.no  Sat Mar  9 02:08: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 18F4821F8455 for ; Sat,  9 Mar 2013 02:08:37 -0800 (PST)
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 PqgTJLC7ugK6 for ; Sat,  9 Mar 2013 02:08:35 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 148CB21F8507 for ; Sat,  9 Mar 2013 02:08:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D703139E173 for ; Sat,  9 Mar 2013 11:08:32 +0100 (CET)
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 sFYj29oEVu2H for ; Sat,  9 Mar 2013 11:08:30 +0100 (CET)
Received: from [212.238.78.132] (ip212-238-78-132.hotspotsvankpn.com [212.238.78.132]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id A57FA39E116 for ; Sat,  9 Mar 2013 11:08:30 +0100 (CET)
Message-ID: <513B0A1D.2020002@alvestrand.no>
Date: Sat, 09 Mar 2013 11:08:29 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070304070807030902090206"
Subject: Re: [rtcweb] VP8 IPR agreement announced.
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 09 Mar 2013 10:08:37 -0000

This is a multi-part message in MIME format.
--------------070304070807030902090206
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 03/08/2013 09:14 PM, Stephan Wenger wrote:
> Hi Serge,
>
> This is a great development for VP8.  Congratulations.  I'm sure it 
> took a few cycles and dollars to get something like this arranged.  I 
> wish your PR would have come out a bit earlier, but licensing 
> discussions do take time...  So better now than never.
>
> I want to ask two more pieces of information that would allow me to 
> put this announcement into context.
>
> First, who are those 11 rightholders?  I'm sure you agree that, in 
> order to make a meaningful risk assessment, that information is needed.

Stephan, at the moment, we have no agreement with the rightsholders that 
permits us to disclose their names. We're discussing that topic with 
them, but we will not name them without an agreement to do so.

Of course, the rightsholders are free to disclose themselves.
>
> Second, the link provided to "preview" the possible sublicensing terms 
> (http://www.w3.org/2001/07/SVG10-IPR-statements) lists a bunch of 
> company statements that vary widely among the rightholders listed 
> there, which do not include google.  It would be great if you could 
> provide more specific information as early as possible, especially 
> with respect to the essential claims definition and the reciprocity 
> conditions.  That does not have to be final legal text, but should be 
> a clear indication of your business intentions.  To me, term-sheet 
> level is OK.

That link was a bit weird - the real W3C definition of "royalty-free" is 
http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Requirements - 
I think the intent of the link was that if you don't find any of the RF 
terms listed on that page objectionable, you'll not find the Google RF 
terms objectionable either.

--------------070304070807030902090206
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 03/08/2013 09:14 PM, Stephan Wenger
      wrote:

    

    

      
      
Hi Serge,

      


      

      
This is a great development for VP8.  Congratulations.  I'm
        sure it took a few cycles and dollars to get something like this
        arranged.  I wish your PR would have come out a bit earlier, but
        licensing discussions do take time…  So better now than never.

      


      

      
I want to ask two more pieces of information that would allow
        me to put this announcement into context.

      


      

      
First, who are those 11 rightholders?  I'm sure you agree
        that, in order to make a meaningful risk assessment, that
        information is needed.

    

    

    Stephan, at the moment, we have no agreement with the rightsholders
    that permits us to disclose their names. We're discussing that topic
    with them, but we will not name them without an agreement to do so.

    

    Of course, the rightsholders are free to disclose themselves.

    

      


      

      
Second, the link provided to "preview" the possible
        sublicensing terms (http://www.w3.org/2001/07/SVG10-IPR-statements)
        lists a bunch of company statements that vary widely among the
        rightholders listed there, which do not include google.  It
        would be great if you could provide more specific information as
        early as possible, especially with respect to the essential
        claims definition and the reciprocity conditions.  That does not
        have to be final legal text, but should be a clear indication of
        your business intentions.  To me, term-sheet level is OK. 

      

    

    

    That link was a bit weird - the real W3C definition of
    "royalty-free" is
    
    http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Requirements
    - I think the intent of the link was that if you don't find any of
    the RF terms listed on that page objectionable, you'll not find the
    Google RF terms objectionable either.

  


--------------070304070807030902090206--

From alan.b.johnston@gmail.com  Sat Mar  9 09:29: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 0A4AD21F843F for ; Sat,  9 Mar 2013 09:29:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 JhMQQZcV8AiO for ; Sat,  9 Mar 2013 09:29:26 -0800 (PST)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id E594F21F843E for ; Sat,  9 Mar 2013 09:29:25 -0800 (PST)
Received: by mail-wi0-f182.google.com with SMTP id hi18so262003wib.3 for ; Sat, 09 Mar 2013 09:29:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=hRl6mVpNB1gTckV8FVn26rxm3VChEqRi40oVYX1DZAc=; b=qnaB6hlewRSFrYRDaQEJFJUXMNR93miD3yQVi008mkVCtFavHsoSNcLuHQ8b9jP542 1004PZmAjR6LZv9ZoqOSstB18qdq+NcGqAjrQyNrK+AbZsILmOHgzN5UDBOyDbqwS9pz ouPDHTBqFzNtcnEhjfPA5kDCflMgTVoKEUr3UAkmHoYRCx0SFJ98ClXwDf0ajjrBNfIV c/ClWaaSlCaJ+6ut+dtJvngrZk8ceDc5ySPQwhpD99jkHgNU4lqk7WnnAEhHrWg3xgLW WJk89hYDTGIYQ7jPv1AUg1wR1gkPAWRzvD26e32+/drS4Yj3L+BunxJqI7Bfxz8yTS/0 ZUtQ==
MIME-Version: 1.0
X-Received: by 10.180.8.4 with SMTP id n4mr4413990wia.13.1362850165017; Sat, 09 Mar 2013 09:29:25 -0800 (PST)
Received: by 10.216.151.67 with HTTP; Sat, 9 Mar 2013 09:29:24 -0800 (PST)
Date: Sat, 9 Mar 2013 11:29:24 -0600
Message-ID: 
From: Alan Johnston 
To: rtcweb@ietf.org
Content-Type: multipart/alternative; boundary=f46d04428f18f7d3a304d7814705
Subject: [rtcweb] Review of draft-ietf-rtcweb-security-04
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 09 Mar 2013 17:29:27 -0000

--f46d04428f18f7d3a304d7814705
Content-Type: text/plain; charset=ISO-8859-1

Here is my review of draft-ietf-rtcweb-security-04.

The draft is mostly ready to progress, with a few corrections noted below.

- Alan -


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"

Figure 1:  might also want to show WebSockets as this is becoming very
common and is mentioned later in the document without much context.  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)?

JS, popunder, and SWF are not defined in the draft

4.1.2. has a reference to draft-ietf-rescorla-rtcweb-generic-idp.  What is
the status of this draft?

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.

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

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.

"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.

"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.

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.

Essentially, since we are using DTLS-SRTP, we do not have the capability to
provide an SAS to users, which is a real shame, as it is one usable way to
involve interested users in securing their own media sessions.  Due to the
design of DTLS-SRTP, it is not possible to add one either.

--f46d04428f18f7d3a304d7814705
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Here is my review of=A0draft-ietf-rtcweb-security-04.

The draft is mostly ready to progress, with a few corrections note=
d below.

- Alan -



Abstract and the duplicate text in Introduction: RTC-web turn into either R=
TCWEB or WebRTC, with WebRTC being preferred.

"some Web server" - slangy =
=A0"a web server"



Figure 1: =A0might also want to show WebSockets as this=
 is becoming very common and is mentioned later in the document without muc=
h context. =A0Also, do we want to show the signaling channel (the one refer=
enced by the W3C WebRTC spec that transports the SDP offers and answers bet=
ween browsers)?



JS, popunder, and SWF are not defined in the draft

4.1.2. has a reference to draft-ietf-rescorla-rtcweb-g=
eneric-idp. =A0What is the status of this draft?


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


4.3.1. Might be useful to mention that this is sometimes called a "pas=
sive attack" whereas 4.3.2 is an "active attack".
=

4.3.2.2.There are a number of misleading statements about SA=
S in this section which should be corrected. =A0For example:



=A0"This SAS is designed to be read over the voice=
 channel and if confirmed by both sides precludes MITM attack." =A0The=
 SAS is to be *compared* by the users - reading it out loud is only one pos=
sible mechanism.



"Moreover, it is possible for an attacker who cont=
rols 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 SA=
S" indicator has been set (which seems likely)." - I don't qu=
ite know what this means. =A0If SAS is used, the UI is the browser chrome, =
so if this is possible, it is just a badly designed UI not a protocol failu=
re or issue.



"Even were SAS secure if used, it seems exceedingl=
y unlikely that users will actually use it." - This reads like specula=
tion. =A0There are users today using SAS, open source users and commercial =
users. =A0One thing is certain, if we don't provide SAS, then users wil=
l not use it.



The whole paragraph is about SAS, but then adds "o=
r fingerprints" in the last sentence. =A0There are very significant di=
fferences between an SAS and a fingerprint (which I will call a Way Too Lon=
g Authentication String). =A0If fingerprints are going to be discussed in t=
his section, then the differences between an SAS and a WTLAS need to be exp=
lained.



Essentially, since we are using DTLS-SRTP, we do not ha=
ve the capability to provide an SAS to users, which is a real shame, as it =
is one usable way to involve interested users in securing their own media s=
essions. =A0Due to the design of DTLS-SRTP, it is not possible to add one e=
ither.






--f46d04428f18f7d3a304d7814705--

From rhglidden@gmail.com  Sat Mar  9 12:22: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 4B52621F87D6 for ; Sat,  9 Mar 2013 12:22:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level: 
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[AWL=-1.377, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 RwDejPJ-sYIL for ; Sat,  9 Mar 2013 12:22:02 -0800 (PST)
Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id F3C4521F84BE for ; Sat,  9 Mar 2013 12:22:01 -0800 (PST)
Received: by mail-yh0-f53.google.com with SMTP id q3so445363yhf.40 for ; Sat, 09 Mar 2013 12:21:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type; bh=/HBrHl6Z0vJYK7oqsqn0RCUqIZ0+lI5AK1Y0xZENsrs=; b=EjC4T04Yn3mwTGiSMtRvIKo8EBCd4567BFfSQJvPZaYdgBJLuEl1Fy+KiKJUL0Bu7u j+6S5PPaZmbAhs5W2pFNrvekM8rW5rsUvUfjiR/v1hU05T7BPdHvmK4W7vrDkbbt0GCq rTgkMLX6Gg4zWXvH2MUGRa3OfJxVwXs3RO0CjlnJjFvWpg40qjn/KpQ0hpMvQABbglPN VsnLMq4RWxM8g56DrirLZ1KU2J/wRrqL89fMLA5X3eWTFMqAh/GhgmpCosY6nO20A7GX idoIHnRUMJQqCNNEDIGWqGC6tflAalgvE+Fk2E01vRdneCGO6YLYFX5TwXpvoHGj/RVW Qypg==
X-Received: by 10.236.145.33 with SMTP id o21mr5255983yhj.55.1362860511904; Sat, 09 Mar 2013 12:21:51 -0800 (PST)
Received: from [10.0.0.10] (99-25-33-39.lightspeed.sntcca.sbcglobal.net. [99.25.33.39]) by mx.google.com with ESMTPS id k45sm15081319yhd.2.2013.03.09.12.21.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Mar 2013 12:21:50 -0800 (PST)
Message-ID: <513B99DA.7060300@gmail.com>
Date: Sat, 09 Mar 2013 12:21:46 -0800
From: Rob Glidden 
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Harald Alvestrand 
References:  <513B0A1D.2020002@alvestrand.no>
In-Reply-To: <513B0A1D.2020002@alvestrand.no>
Content-Type: multipart/alternative; boundary="------------090401080801020109030009"
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 IPR agreement announced.
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 09 Mar 2013 20:22:04 -0000

This is a multi-part message in MIME format.
--------------090401080801020109030009
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Interesting.  Potential licensees will be aided by the provision of a 
clear list of the portfolio patents, said the 1997 US Department of 
Justice review letter of MPEG LA.

ISO/MPEG IPR rules are clear that proposers must ask for, and rights 
holders must provide, patent statements for a proposal to proceed.

Rob

On 3/9/2013 2:08 AM, Harald Alvestrand wrote:
> On 03/08/2013 09:14 PM, Stephan Wenger wrote:
>> Hi Serge,
>>
>> This is a great development for VP8.  Congratulations.  I'm sure it 
>> took a few cycles and dollars to get something like this arranged.  I 
>> wish your PR would have come out a bit earlier, but licensing 
>> discussions do take time...  So better now than never.
>>
>> I want to ask two more pieces of information that would allow me to 
>> put this announcement into context.
>>
>> First, who are those 11 rightholders?  I'm sure you agree that, in 
>> order to make a meaningful risk assessment, that information is needed.
>
> Stephan, at the moment, we have no agreement with the rightsholders 
> that permits us to disclose their names. We're discussing that topic 
> with them, but we will not name them without an agreement to do so.
>
> Of course, the rightsholders are free to disclose themselves.
>>
>> Second, the link provided to "preview" the possible sublicensing 
>> terms (http://www.w3.org/2001/07/SVG10-IPR-statements) lists a bunch 
>> of company statements that vary widely among the rightholders listed 
>> there, which do not include google.  It would be great if you could 
>> provide more specific information as early as possible, especially 
>> with respect to the essential claims definition and the reciprocity 
>> conditions.  That does not have to be final legal text, but should be 
>> a clear indication of your business intentions.  To me, term-sheet 
>> level is OK.
>
> That link was a bit weird - the real W3C definition of "royalty-free" 
> is 
> http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Requirements 
> - I think the intent of the link was that if you don't find any of the 
> RF terms listed on that page objectionable, you'll not find the Google 
> RF terms objectionable either.
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--------------090401080801020109030009
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Interesting.  Potential licensees will
      be aided by the provision of a clear list of the portfolio
      patents, said the 1997 US Department of Justice review letter of
      MPEG LA.

      

      ISO/MPEG IPR rules are clear that proposers must ask for, and
      rights holders must provide, patent statements for a proposal to
      proceed. 

      

      Rob

      

      On 3/9/2013 2:08 AM, Harald Alvestrand wrote:

    

    

      
      
On 03/08/2013 09:14 PM, Stephan
        Wenger wrote:

      

      

        
        
Hi Serge,

        


        

        
This is a great development for VP8.  Congratulations.  I'm
          sure it took a few cycles and dollars to get something like
          this arranged.  I wish your PR would have come out a bit
          earlier, but licensing discussions do take time…  So better
          now than never.

        


        

        
I want to ask two more pieces of information that would
          allow me to put this announcement into context.

        


        

        
First, who are those 11 rightholders?  I'm sure you agree
          that, in order to make a meaningful risk assessment, that
          information is needed.

      

      

      Stephan, at the moment, we have no agreement with the
      rightsholders that permits us to disclose their names. We're
      discussing that topic with them, but we will not name them without
      an agreement to do so.

      

      Of course, the rightsholders are free to disclose themselves.

      

        


        

        
Second, the link provided to "preview" the possible
          sublicensing terms (http://www.w3.org/2001/07/SVG10-IPR-statements)
          lists a bunch of company statements that vary widely among the
          rightholders listed there, which do not include google.  It
          would be great if you could provide more specific information
          as early as possible, especially with respect to the essential
          claims definition and the reciprocity conditions.  That does
          not have to be final legal text, but should be a clear
          indication of your business intentions.  To me, term-sheet
          level is OK. 

        

      

      

      That link was a bit weird - the real W3C definition of
      "royalty-free" is
      
      http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Requirements
      - I think the intent of the link was that if you don't find any of
      the RF terms listed on that page objectionable, you'll not find
      the Google RF terms objectionable either.

      

      

      

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


    

    

  


--------------090401080801020109030009--

From tterriberry@mozilla.com  Sat Mar  9 13:53: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 A1C7021F875A for ; Sat,  9 Mar 2013 13:53:51 -0800 (PST)
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 2LzUK+cX5Q5e for ; Sat,  9 Mar 2013 13:53:51 -0800 (PST)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3239721F8700 for ; Sat,  9 Mar 2013 13:53:51 -0800 (PST)
Received: from [130.129.32.51] (dhcp-2033.meeting.ietf.org [130.129.32.51]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 87A3EF2180 for ; Sat,  9 Mar 2013 13:53:50 -0800 (PST)
Message-ID: <513BAF6D.20108@mozilla.com>
Date: Sat, 09 Mar 2013 13:53:49 -0800
From: "Timothy B. Terriberry" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120625 SeaMonkey/2.10.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  <513B0A1D.2020002@alvestrand.no> <513B99DA.7060300@gmail.com>
In-Reply-To: <513B99DA.7060300@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] VP8 IPR agreement announced.
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 09 Mar 2013 21:53:51 -0000

Rob Glidden wrote:
> ISO/MPEG IPR rules are clear that proposers must ask for, and rights
> holders must provide, patent statements for a proposal to proceed.

My understanding is that the MPEG LA pool license for AVC requires 
licensees to provide a reciprocal license to any essential patents they 
might own. Does someone have a list of all of those patent numbers?

From stewe@stewe.org  Sat Mar  9 14:39: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 DCDE921F87AA for ; Sat,  9 Mar 2013 14:39:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.52
X-Spam-Level: 
X-Spam-Status: No, score=-5.52 tagged_above=-999 required=5 tests=[AWL=1.079,  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 jSCwZyHPIVDp for ; Sat,  9 Mar 2013 14:39:44 -0800 (PST)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id E5F9A21F86B2 for ; Sat,  9 Mar 2013 14:39:42 -0800 (PST)
Received: from mail139-tx2-R.bigfish.com (10.9.14.242) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.23; Sat, 9 Mar 2013 22:39:42 +0000
Received: from mail139-tx2 (localhost [127.0.0.1])	by mail139-tx2-R.bigfish.com (Postfix) with ESMTP id 2D4A2600D4; Sat,  9 Mar 2013 22:39:42 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT002.namprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -19
X-BigFish: PS-19(zz98dI1432Idb82hzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL17326ah8275dh8275bhz2fh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h)
Received-SPF: pass (mail139-tx2: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT002.namprd07.prod.outlook.com ; .outlook.com ; 
Received: from mail139-tx2 (localhost.localdomain [127.0.0.1]) by mail139-tx2 (MessageSwitch) id 1362868779643164_13308; Sat,  9 Mar 2013 22:39:39 +0000 (UTC)
Received: from TX2EHSMHS009.bigfish.com (unknown [10.9.14.243])	by mail139-tx2.bigfish.com (Postfix) with ESMTP id 9766C16075B; Sat,  9 Mar 2013 22:39:39 +0000 (UTC)
Received: from BL2PRD0710HT002.namprd07.prod.outlook.com (157.56.240.133) by TX2EHSMHS009.bigfish.com (10.9.99.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 9 Mar 2013 22:39:39 +0000
Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.49]) by BL2PRD0710HT002.namprd07.prod.outlook.com ([10.255.102.37]) with mapi id 14.16.0275.006; Sat, 9 Mar 2013 22:39:38 +0000
From: Stephan Wenger 
To: "Timothy B. Terriberry" , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] VP8 IPR agreement announced.
Thread-Index: AQHOG2jFHPF2KVFzGUSG2LjE89vDs5ibtgcAgAFvP4CAAKtZAIAAGbiA//+Gq4A=
Date: Sat, 9 Mar 2013 22:39:38 +0000
Message-ID: 
In-Reply-To: <513BAF6D.20108@mozilla.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.255.102.5]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <92C717368DC1294293E278EA64B98029@namprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Subject: Re: [rtcweb] VP8 IPR agreement announced.
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 09 Mar 2013 22:39:45 -0000

For AVC, the patent list is public; see here:
http://www.mpegla.com/main/programs/AVC/Pages/PatentList.aspx.  However,
what parties have agreed to with respect to AVC has little or nothing to
do with what they have to do with respect to VP8.
Stephan



On 3.9.2013 13:53 , "Timothy B. Terriberry" 
wrote:

>Rob Glidden wrote:
>> ISO/MPEG IPR rules are clear that proposers must ask for, and rights
>> holders must provide, patent statements for a proposal to proceed.
>
>My understanding is that the MPEG LA pool license for AVC requires
>licensees to provide a reciprocal license to any essential patents they
>might own. Does someone have a list of all of those patent numbers?
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb
>



From tterriberry@mozilla.com  Sat Mar  9 14:50: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 B2AB021F8771 for ; Sat,  9 Mar 2013 14:50:45 -0800 (PST)
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 t79uJX8c08Dv for ; Sat,  9 Mar 2013 14:50:45 -0800 (PST)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id D67AD21F8783 for ; Sat,  9 Mar 2013 14:50:43 -0800 (PST)
Received: from [130.129.32.51] (dhcp-2033.meeting.ietf.org [130.129.32.51]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 4C91AF222D for ; Sat,  9 Mar 2013 14:50:43 -0800 (PST)
Message-ID: <513BBCC2.6070108@mozilla.com>
Date: Sat, 09 Mar 2013 14:50:42 -0800
From: "Timothy B. Terriberry" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120625 SeaMonkey/2.10.1
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] VP8 IPR agreement announced.
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 09 Mar 2013 22:50:45 -0000

Stephan Wenger wrote:
> For AVC, the patent list is public; see here:
> http://www.mpegla.com/main/programs/AVC/Pages/PatentList.aspx.  However,

I think you missed my point. That is the list for patents owned by the 
_licensors_. It does not appear to include any patents held by 
licensees, which are supposedly available via those licensees' 
reciprocal licenses.

> what parties have agreed to with respect to AVC has little or nothing to
> do with what they have to do with respect to VP8.

Well, Rob was the one who brought up the MPEG LA. But I won't argue with 
you on this point.

From stewe@stewe.org  Sat Mar  9 15:08: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 2809821F8782 for ; Sat,  9 Mar 2013 15:08:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.879
X-Spam-Level: 
X-Spam-Status: No, score=-4.879 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, GB_I_LETTER=-2, 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 iWFB+j4CHRaw for ; Sat,  9 Mar 2013 15:07:59 -0800 (PST)
Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0189.outbound.messaging.microsoft.com [213.199.154.189]) by ietfa.amsl.com (Postfix) with ESMTP id 79A6F21F86B6 for ; Sat,  9 Mar 2013 15:07:58 -0800 (PST)
Received: from mail141-db8-R.bigfish.com (10.174.8.230) by DB8EHSOBE040.bigfish.com (10.174.4.103) with Microsoft SMTP Server id 14.1.225.23; Sat, 9 Mar 2013 23:07:57 +0000
Received: from mail141-db8 (localhost [127.0.0.1])	by mail141-db8-R.bigfish.com (Postfix) with ESMTP id 67A3C1E0149; Sat,  9 Mar 2013 23:07:57 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT005.namprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -20
X-BigFish: PS-20(zzbb2dI98dI9371Ic85ehd799hdb82hzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz18de19h1033IL17326ah8275dh18c673h8275bhz2fh2a8h668h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h)
Received-SPF: pass (mail141-db8: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT005.namprd07.prod.outlook.com ; .outlook.com ; 
Received: from mail141-db8 (localhost.localdomain [127.0.0.1]) by mail141-db8 (MessageSwitch) id 1362870474470273_7455; Sat,  9 Mar 2013 23:07:54 +0000 (UTC)
Received: from DB8EHSMHS032.bigfish.com (unknown [10.174.8.235])	by mail141-db8.bigfish.com (Postfix) with ESMTP id 6682F360045; Sat,  9 Mar 2013 23:07:54 +0000 (UTC)
Received: from BL2PRD0710HT005.namprd07.prod.outlook.com (157.56.240.133) by DB8EHSMHS032.bigfish.com (10.174.4.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 9 Mar 2013 23:07:54 +0000
Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.49]) by BL2PRD0710HT005.namprd07.prod.outlook.com ([10.255.102.40]) with mapi id 14.16.0275.006; Sat, 9 Mar 2013 23:07:53 +0000
From: Stephan Wenger 
To: Rob Glidden , Harald Alvestrand 
Thread-Topic: [rtcweb] VP8 IPR agreement announced.
Thread-Index: AQHOG2jFHPF2KVFzGUSG2LjE89vDs5ibtgcAgAFvP4CAAKtZAP//qEmA
Date: Sat, 9 Mar 2013 23:07:52 +0000
Message-ID: 
In-Reply-To: <513B99DA.7060300@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.255.102.5]
Content-Type: multipart/alternative; boundary="_000_CD60FA3097137stewesteweorg_"
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 IPR agreement announced.
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 09 Mar 2013 23:08:00 -0000

--_000_CD60FA3097137stewesteweorg_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Rob,
Please see inline.
Stephan

From: Rob Glidden >
Date: Saturday, 9 March, 2013 12:21
To: Harald Alvestrand >
Cc: "rtcweb@ietf.org" >
Subject: Re: [rtcweb] VP8 IPR agreement announced.

Interesting.  Potential licensees will be aided by the provision of a clear=
 list of the portfolio patents, said the 1997 US Department of Justice revi=
ew letter of MPEG LA.

AFAIK, neither a patent list nor a list of potential pool licensors were ev=
er published.  What is known is that there were originally 12 parties which=
 each submitted at least one patent (which was found essential) into a poss=
ible future pool, and 11 parties (which may or may not be related to the or=
iginal 12 parties) decided, apparently with MPEG-LA's help, to furnish a su=
blicenseable license to google (but not to the world).  So we have a closed=
 group of 11 licensors, and a single licensee, who came to an agreement usi=
ng a facilitator which also happens to administers pools.  To what extent t=
hat transaction qualifies as a pooling arrangement from an antitrust law vi=
ewpoint surely has been looked at carefully by the parties in question.  Ap=
parently, they came to the conclusion that they do not need to name the lic=
ensors, nor the patents in question.  Otherwise, I guess we would know by n=
ow.

ISO/MPEG IPR rules are clear that proposers must ask for, and rights holder=
s must provide, patent statements for a proposal to proceed.

Huh?  Is that something special for this MPEG subgroup?  If yes, would ther=
e be a doc you can share explaining such procedures?

My understanding is that ISO/IEC patent matters are generally dealt with un=
der the joint ITU/ISO/IEC patent policy, which requires in practice declara=
tions with RAND terms towards the end of the process (before final approval=
 of the standard, but after it is clear that the patent claim reads on the =
future standard).  Chairs are also under the obligation to request disclosu=
re during each meeting, but (AFAIK) there are almost never replies to these=
 calls.  When participating in a meeting, I usually to not reply, because I=
'm not quite sure that a patent claim reads on the final standard before th=
at standard is reasonable frozen.

I know that the video coding joint teams (JVT, JCT-VC, JCT-3V) have additio=
nally adopted a policy requiring in practice some form of RAND language in =
each contribution.

As some here know, I do not participate in this MPEG effort, so I really do=
n't know.


Rob

On 3/9/2013 2:08 AM, Harald Alvestrand wrote:
On 03/08/2013 09:14 PM, Stephan Wenger wrote:
Hi Serge,

This is a great development for VP8.  Congratulations.  I'm sure it took a =
few cycles and dollars to get something like this arranged.  I wish your PR=
 would have come out a bit earlier, but licensing discussions do take time=
=85  So better now than never.

I want to ask two more pieces of information that would allow me to put thi=
s announcement into context.

First, who are those 11 rightholders?  I'm sure you agree that, in order to=
 make a meaningful risk assessment, that information is needed.

Stephan, at the moment, we have no agreement with the rightsholders that pe=
rmits us to disclose their names. We're discussing that topic with them, bu=
t we will not name them without an agreement to do so.

Of course, the rightsholders are free to disclose themselves.

Second, the link provided to "preview" the possible sublicensing terms (htt=
p://www.w3.org/2001/07/SVG10-IPR-statements) lists a bunch of company state=
ments that vary widely among the rightholders listed there, which do not in=
clude google.  It would be great if you could provide more specific informa=
tion as early as possible, especially with respect to the essential claims =
definition and the reciprocity conditions.  That does not have to be final =
legal text, but should be a clear indication of your business intentions.  =
To me, term-sheet level is OK.

That link was a bit weird - the real W3C definition of "royalty-free" is ht=
tp://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Requirements - I thi=
nk the intent of the link was that if you don't find any of the RF terms li=
sted on that page objectionable, you'll not find the Google RF terms object=
ionable either.



_______________________________________________
rtcweb mailing list
rtcweb@ietf.orghttps://www.ietf.org/mailman/listinf=
o/rtcweb


--_000_CD60FA3097137stewesteweorg_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <2D24E79EB9468441B77364FE47716096@namprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable







Hi Rob,


Please see inline.  


Stephan










From: Rob Glidden <rhglidden@gmail.com>

Date: Saturday, 9 March, 2013 12:21=
 

To: Harald Alvestrand <harald@alvestrand.no>

Cc: "rtcweb@ietf.org" <=
rtcweb@ietf.org>

Subject: Re: [rtcweb] VP8 IPR agree=
ment announced.















Interesting.  Potential licensees will =
be aided by the provision of a clear list of the portfolio patents, said th=
e 1997 US Department of Justice review letter of MPEG LA.

















AFAIK,=
 neither a patent list nor a list of potential pool licensors were ever pub=
lished.  What is known is that there were originally 12 parties which =
each submitted at least one patent (which
 was found essential) into a possible future pool, and 11 parties (which ma=
y or may not be related to the original 12 parties) decided, apparently wit=
h MPEG-LA's help, to furnish a sublicenseable license to google (but not to=
 the world).  So we have a closed
 group of 11 licensors, and a single licensee, who came to an agreement usi=
ng a facilitator which also happens to administers&=
nbsp;pools.  To what extent that transaction qualifies
 as a pooling arrangement from an antitrust law viewpoint surely has been l=
ooked at carefully by the parties in question.  Apparently, they came =
to the conclusion that they do not need to name the licensors, nor the pate=
nts in question.  Otherwise, I guess
 we would know by now. 









ISO/MPEG IPR rules are clear that proposers must ask for, and rights holder=
s must provide, patent statements for a proposal to proceed.














Huh?  Is that something special for this MPEG subgroup? &=
nbsp;If yes, would there be a doc you can share explaining such procedures?=
 


 


My understanding is that ISO/IEC patent matters are gene=
rally dealt with under the joint ITU/ISO/IEC patent policy, which requires =
in practice declarations with RAND terms
 towards the end of the process (before final approval of the standard, but=
 after it is clear that the patent claim reads on the future standard). &nb=
sp;Chairs are also under the obligation to request disclosure during each m=
eeting, but (AFAIK) there are almost
 never replies to these calls.  When participating in a meeting, I usu=
ally to not reply, because I'm not quite sure that a patent claim reads on =
the final standard before that standard is reasonable frozen.  =








I know that the video coding joint teams (JVT, JCT-VC, J=
CT-3V) have additionally adopted a policy requiring in practice some form o=
f RAND language in each contribution.
 








As some here know, =
I do not participate in this MPEG effort, so I really don't know.=












Rob



On 3/9/2013 2:08 AM, Harald Alvestrand wrote:






On 03/08/2013 09:14 PM, Stephan Wenger wrote=
:






Hi Serge,







This is a great development for VP8.  Congratulations.  I'm =
sure it took a few cycles and dollars to get something like this arranged. =
 I wish your PR would have come out a bit earlier, but licensing discu=
ssions do take time=85  So better now than never.







I want to ask two more pieces of information that would allow me to pu=
t this announcement into context.







First, who are those 11 rightholders?  I'm sure you agree that, i=
n order to make a meaningful risk assessment, that information is needed.




Stephan, at the moment, we have no agreement with the rightsholders that pe=
rmits us to disclose their names. We're discussing that topic with them, bu=
t we will not name them without an agreement to do so.



Of course, the rightsholders are free to disclose themselves.









Second, the link provided to "preview" the possible sublicen=
sing terms (http://www.w3.org/2001/07/SVG10-IPR-statements) li=
sts a bunch of company statements that vary widely
 among the rightholders listed there, which do not include google.  It=
 would be great if you could provide more specific information as early as =
possible, especially with respect to the essential claims definition and th=
e reciprocity conditions.  That does
 not have to be final legal text, but should be a clear indication of your =
business intentions.  To me, term-sheet level is OK.








That link was a bit weird - the real W3C definition of "royalty-free&q=
uot; is 
http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Requirements -=
 I think the intent of the link was that if you don't find any of the RF te=
rms listed on that page objectionable, you'll not find the Google RF terms =
objectionable either.




 


_______________________________________________
rtcweb mailing list
rtcwe=
b@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb














--_000_CD60FA3097137stewesteweorg_--

From stewe@stewe.org  Sat Mar  9 15:11: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 D9B2121F8783 for ; Sat,  9 Mar 2013 15:11:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.809
X-Spam-Level: 
X-Spam-Status: No, score=-3.809 tagged_above=-999 required=5 tests=[AWL=-1.210, 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 O4xCJykH7T3V for ; Sat,  9 Mar 2013 15:11:53 -0800 (PST)
Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0186.outbound.messaging.microsoft.com [213.199.154.186]) by ietfa.amsl.com (Postfix) with ESMTP id BEAF121F872D for ; Sat,  9 Mar 2013 15:11:52 -0800 (PST)
Received: from mail35-db8-R.bigfish.com (10.174.8.226) by DB8EHSOBE013.bigfish.com (10.174.4.76) with Microsoft SMTP Server id 14.1.225.23; Sat, 9 Mar 2013 23:11:51 +0000
Received: from mail35-db8 (localhost [127.0.0.1])	by mail35-db8-R.bigfish.com (Postfix) with ESMTP id 9F9635C012B; Sat,  9 Mar 2013 23:11:51 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT001.namprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -19
X-BigFish: PS-19(zz98dI1432Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL17326ah8275dh8275bhz2fh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h)
Received-SPF: pass (mail35-db8: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT001.namprd07.prod.outlook.com ; .outlook.com ; 
Received: from mail35-db8 (localhost.localdomain [127.0.0.1]) by mail35-db8 (MessageSwitch) id 1362870709782331_24900; Sat,  9 Mar 2013 23:11:49 +0000 (UTC)
Received: from DB8EHSMHS027.bigfish.com (unknown [10.174.8.239])	by mail35-db8.bigfish.com (Postfix) with ESMTP id BC64B240045; Sat,  9 Mar 2013 23:11:49 +0000 (UTC)
Received: from BL2PRD0710HT001.namprd07.prod.outlook.com (157.56.240.133) by DB8EHSMHS027.bigfish.com (10.174.4.37) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 9 Mar 2013 23:11:49 +0000
Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.49]) by BL2PRD0710HT001.namprd07.prod.outlook.com ([10.255.102.36]) with mapi id 14.16.0275.006; Sat, 9 Mar 2013 23:11:48 +0000
From: Stephan Wenger 
To: "Timothy B. Terriberry" , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] VP8 IPR agreement announced.
Thread-Index: AQHOG2jFHPF2KVFzGUSG2LjE89vDs5ibtgcAgAFvP4CAAKtZAIAAGbiA//+Gq4CAAIk6AP//f78A
Date: Sat, 9 Mar 2013 23:11:47 +0000
Message-ID: 
In-Reply-To: <513BBCC2.6070108@mozilla.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.255.102.5]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Subject: Re: [rtcweb] VP8 IPR agreement announced.
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 09 Mar 2013 23:11:54 -0000

Hi Tim,

On 3.9.2013 14:50 , "Timothy B. Terriberry" 
wrote:

>Stephan Wenger wrote:
>> For AVC, the patent list is public; see here:
>> http://www.mpegla.com/main/programs/AVC/Pages/PatentList.aspx.  However,
>
>I think you missed my point. That is the list for patents owned by the
>_licensors_. It does not appear to include any patents held by
>licensees, which are supposedly available via those licensees'
>reciprocal licenses.

Yes, I missed your point.
No, I don't believe that such a list has ever been published.  Nor that it
ever will.  Why does it matter?

Stephan


>
>> what parties have agreed to with respect to AVC has little or nothing to
>> do with what they have to do with respect to VP8.
>
>Well, Rob was the one who brought up the MPEG LA. But I won't argue with
>you on this point.
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb
>



From tterriberry@mozilla.com  Sat Mar  9 15:26: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 5903121F87A3 for ; Sat,  9 Mar 2013 15:26:49 -0800 (PST)
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 yDWO3cJQXXyX for ; Sat,  9 Mar 2013 15:26:49 -0800 (PST)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id F211E21F8734 for ; Sat,  9 Mar 2013 15:26:48 -0800 (PST)
Received: from [130.129.32.51] (dhcp-2033.meeting.ietf.org [130.129.32.51]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 59828F22B6 for ; Sat,  9 Mar 2013 15:26:48 -0800 (PST)
Message-ID: <513BC537.5000809@mozilla.com>
Date: Sat, 09 Mar 2013 15:26:47 -0800
From: "Timothy B. Terriberry" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120625 SeaMonkey/2.10.1
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] VP8 IPR agreement announced.
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 09 Mar 2013 23:26:49 -0000

Stephan Wenger wrote:
> No, I don't believe that such a list has ever been published.  Nor that it
> ever will.  Why does it matter?

I thought we just agreed that it did not.

From ron@debian.org  Sat Mar  9 16:49: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 3CE4421F85B1 for ; Sat,  9 Mar 2013 16:49:23 -0800 (PST)
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 r9cIPfYe8nyw for ; Sat,  9 Mar 2013 16:49:22 -0800 (PST)
Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 6B96F21F8570 for ; Sat,  9 Mar 2013 16:49:22 -0800 (PST)
Received: from ppp118-210-231-139.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([118.210.231.139]) by ipmail05.adl6.internode.on.net with ESMTP; 10 Mar 2013 11:19:21 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 0FB834F8F3 for ; Sun, 10 Mar 2013 11:19:20 +1030 (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 wp4xqLDRj0KT for ; Sun, 10 Mar 2013 11:19:19 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 312A34F902; Sun, 10 Mar 2013 11:19:19 +1030 (CST)
Date: Sun, 10 Mar 2013 11:19:19 +1030
From: Ron 
To: rtcweb@ietf.org
Message-ID: <20130310004919.GR7852@audi.shelbyville.oz>
References:  <513B0A1D.2020002@alvestrand.no>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <513B0A1D.2020002@alvestrand.no>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] VP8 IPR agreement announced.
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 10 Mar 2013 00:49:23 -0000

On Sat, Mar 09, 2013 at 11:08:29AM +0100, Harald Alvestrand wrote:
> On 03/08/2013 09:14 PM, Stephan Wenger wrote:
> >
> >I want to ask two more pieces of information that would allow me
> >to put this announcement into context.
> >
> >First, who are those 11 rightholders?  I'm sure you agree that, in
> >order to make a meaningful risk assessment, that information is
> >needed.
> 
> Stephan, at the moment, we have no agreement with the rightsholders
> that permits us to disclose their names. We're discussing that topic
> with them, but we will not name them without an agreement to do so.

I'm a bit mystified by why Stephan thinks this is somehow essential
for anything more than curiosity sake.  Didn't he previously reassure
us that we could trust MPEG-LA to negotiate needed licences for us,
without any of the sort of additional guarantees and indemnities that
were being insisted of Google?

Why can we not trust them to have done so now, when they clearly
released a formal statement saying they have?

If anything really does remain in order to make a meaningful assessment
I would think it would be a careful examination of why this apparent
double-standard still persists.

> Of course, the rightsholders are free to disclose themselves.

Since it seems like a pretty good bet that most if not all of them
are represented here and have participated passionately in this
discussion, I assume they are actually under an obligation to under
the IETF IPR rules, should their IPR actually be relevant ...

So if they don't, then we can only assume that is yet another data
point solidly indicating that they also don't believe that anything
they have actually does read on this technology.  And that the
'agreement' may be as simple as not pressing a case with the DOJ
to tear their whole crooked circus down, and not embarrassing them
in public for being the simple grifters that they are.

So long as we're all perfectly clear on the actual status of what
is now even more obviously the preferred MTI technology to choose,
I guess I can live with that compromise.

 Good outcome is good,
 Ron



From stewe@stewe.org  Sat Mar  9 18: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 7032F21F87CE for ; Sat,  9 Mar 2013 18:15:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.567
X-Spam-Level: 
X-Spam-Status: No, score=-5.567 tagged_above=-999 required=5 tests=[AWL=1.032,  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 mqjCdUka-tPq for ; Sat,  9 Mar 2013 18:15:28 -0800 (PST)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9587721F87CB for ; Sat,  9 Mar 2013 18:15:28 -0800 (PST)
Received: from mail20-co9-R.bigfish.com (10.236.132.253) by CO9EHSOBE001.bigfish.com (10.236.130.64) with Microsoft SMTP Server id 14.1.225.23; Sun, 10 Mar 2013 02:15:27 +0000
Received: from mail20-co9 (localhost [127.0.0.1])	by mail20-co9-R.bigfish.com (Postfix) with ESMTP id 8533C60121; Sun, 10 Mar 2013 02:15:27 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT003.namprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -18
X-BigFish: PS-18(zzbb2dI98dI9371I1432I5a4kzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL8275dhz2fh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h)
Received-SPF: pass (mail20-co9: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT003.namprd07.prod.outlook.com ; .outlook.com ; 
Received: from mail20-co9 (localhost.localdomain [127.0.0.1]) by mail20-co9 (MessageSwitch) id 1362881725359799_9021; Sun, 10 Mar 2013 02:15:25 +0000 (UTC)
Received: from CO9EHSMHS026.bigfish.com (unknown [10.236.132.254])	by mail20-co9.bigfish.com (Postfix) with ESMTP id 555903A0076; Sun, 10 Mar 2013 02:15:25 +0000 (UTC)
Received: from BL2PRD0710HT003.namprd07.prod.outlook.com (157.56.240.133) by CO9EHSMHS026.bigfish.com (10.236.130.36) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 10 Mar 2013 02:15:25 +0000
Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.49]) by BL2PRD0710HT003.namprd07.prod.outlook.com ([10.255.102.38]) with mapi id 14.16.0275.006; Sun, 10 Mar 2013 02:15:23 +0000
From: Stephan Wenger 
To: Ron , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] VP8 IPR agreement announced.
Thread-Index: AQHOG2jFHPF2KVFzGUSG2LjE89vDs5ibtgcAgAFvP4CAAPYagP//keoA
Date: Sun, 10 Mar 2013 02:15:22 +0000
Message-ID: 
In-Reply-To: <20130310004919.GR7852@audi.shelbyville.oz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.255.102.4]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Subject: Re: [rtcweb] VP8 IPR agreement announced.
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 10 Mar 2013 02:15:29 -0000

Hi Ron,
Please see inline.
Stephan

On 3.9.2013 16:49 , "Ron"  wrote:

>On Sat, Mar 09, 2013 at 11:08:29AM +0100, Harald Alvestrand wrote:
>> On 03/08/2013 09:14 PM, Stephan Wenger wrote:
>> >
>> >I want to ask two more pieces of information that would allow me
>> >to put this announcement into context.
>> >
>> >First, who are those 11 rightholders?  I'm sure you agree that, in
>> >order to make a meaningful risk assessment, that information is
>> >needed.
>>=20
>> Stephan, at the moment, we have no agreement with the rightsholders
>> that permits us to disclose their names. We're discussing that topic
>> with them, but we will not name them without an agreement to do so.
>
>I'm a bit mystified by why Stephan thinks this is somehow essential
>for anything more than curiosity sake.  Didn't he previously reassure
>us that we could trust MPEG-LA to negotiate needed licences for us,
>without any of the sort of additional guarantees and indemnities that
>were being insisted of Google?

I don't think I have ever said anything like this.  I may have previously
said something along the following lines:

A pooling arrangement (in the traditional sense), combined with a RAND
commitment by a large percentage of potential rightholders (i.e. through
their participation in a RAND SDO) can, IMO, indeed create a licensing
ecosystem that would reduce (though never eliminate) the risk of using a
technology and be hit by business-damaging royalties or injunctions.  In
the deal currently under discussion, we don't seem have to have either
factor in play.  At least not in a way verifiable by me.

If I knew the rightholders, I could correlate their names and portfolios
with a landscape study I may have performed, and then could decide a) the
rightholder group under whose rights which I would be licensed if I pick a
google sublicense is all I worry about, b) there are a few rightholders
where I don't have a license through google, but that's a risk I'm willing
to take given the benefits get, or c) I continue to stay away from VP8.
Given the nature of the google deal, I could also take a shortcut--as the
license google has appears to encompass all VP8-essential patent claims of
these 11 rightholders, I could just make a per company risk/benefit
assessment.

Further, one nice thing about pools is that they set a market price for
patent licenses for the standard in question, which, in combination with a
RAND commitment, MAY limit the damages and royalties and MAY also rule out
injunctions.  Both aspects are currently being litigated and hotly debated
in the academic and standards/patents communities, which is why I wrote
"MAY".  We will know better in a few years.


>Why can we not trust them to have done so now, when they clearly
>released a formal statement saying they have?

It's not clear to me to what you refer here.

>
>If anything really does remain in order to make a meaningful assessment
>I would think it would be a careful examination of why this apparent
>double-standard still persists.
>
>> Of course, the rightsholders are free to disclose themselves.
>
>Since it seems like a pretty good bet that most if not all of them
>are represented here and have participated passionately in this
>discussion, I assume they are actually under an obligation to under
>the IETF IPR rules, should their IPR actually be relevant ...

Your understanding of the IETF IPR policy has, umm, a few holes.  Suggest
you read BCP79.  To summarize, only individuals have an obligations for
disclosure, and only if they a) have reasonable and personal knowledge of
IPR reading on the standard, b) have contributed, and c) the IPR is owned
by their employer.  Given the rather limited overlap between the video
coding community and IETF participants, it's rather unlikely that you find
people with a disclosure obligation under all three factors.  Of course,
people are also encouraged to disclose if only factor a) above is correct,
but there is no obligation, and given the risk of disclosures, such
voluntary disclosures are not particularly common and typically come from
academics (though others are by no means unheard of.)

>
>So if they don't, then we can only assume that is yet another data
>point solidly indicating that they also don't believe that anything
>they have actually does read on this technology.  And that the
>'agreement' may be as simple as not pressing a case with the DOJ
>to tear their whole crooked circus down, and not embarrassing them
>in public for being the simple grifters that they are.

I leave it to others to comment on this rant.

>
>So long as we're all perfectly clear on the actual status of what
>is now even more obviously the preferred MTI technology to choose,
>I guess I can live with that compromise.
>
> Good outcome is good,

On that, we agree.

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



From stewe@stewe.org  Sat Mar  9 18:31: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 A7BD721F87D7 for ; Sat,  9 Mar 2013 18:31:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.239
X-Spam-Level: 
X-Spam-Status: No, score=-4.239 tagged_above=-999 required=5 tests=[AWL=-0.641, 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 C+gCXwnCeZN3 for ; Sat,  9 Mar 2013 18:31:50 -0800 (PST)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 44A2721F87C4 for ; Sat,  9 Mar 2013 18:31:45 -0800 (PST)
Received: from mail182-co1-R.bigfish.com (10.243.78.246) by CO1EHSOBE032.bigfish.com (10.243.66.97) with Microsoft SMTP Server id 14.1.225.23; Sun, 10 Mar 2013 02:31:44 +0000
Received: from mail182-co1 (localhost [127.0.0.1])	by mail182-co1-R.bigfish.com (Postfix) with ESMTP id 56CCD8800C2	for ; Sun, 10 Mar 2013 02:31:44 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT005.namprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: 3
X-BigFish: PS3(zzc85ehzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz17326ah18c673h8275bhz2fh2a8h668h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h)
Received-SPF: pass (mail182-co1: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT005.namprd07.prod.outlook.com ; .outlook.com ; 
Received: from mail182-co1 (localhost.localdomain [127.0.0.1]) by mail182-co1 (MessageSwitch) id 1362882701535064_28935; Sun, 10 Mar 2013 02:31:41 +0000 (UTC)
Received: from CO1EHSMHS009.bigfish.com (unknown [10.243.78.251])	by mail182-co1.bigfish.com (Postfix) with ESMTP id 75B73800DC	for ; Sun, 10 Mar 2013 02:31:41 +0000 (UTC)
Received: from BL2PRD0710HT005.namprd07.prod.outlook.com (157.56.240.133) by CO1EHSMHS009.bigfish.com (10.243.66.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 10 Mar 2013 02:31:41 +0000
Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.49]) by BL2PRD0710HT005.namprd07.prod.outlook.com ([10.255.102.40]) with mapi id 14.16.0275.006; Sun, 10 Mar 2013 02:31:40 +0000
From: Stephan Wenger 
To: "rtcweb@ietf.org" 
Thread-Topic: VP8 litigation in Germany?
Thread-Index: AQHOHTdlrWoXGfl7J0qzyy7s7WzxBA==
Date: Sun, 10 Mar 2013 02:31:40 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.255.102.4]
Content-Type: multipart/alternative; boundary="_000_CD613089973B9stewesteweorg_"
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Subject: [rtcweb] VP8 litigation in Germany?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 10 Mar 2013 02:31:51 -0000

--_000_CD613089973B9stewesteweorg_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi,
An additional data point.
Florian Mueller writes in his patent blog (http://www.fosspatents.com/2013/=
03/patent-clouds-remain-over-vp8-google.html) that he has attended a court =
hearing in Mannheim, Germany, where, according to his blog, "Counsel for No=
kia indeed based the infringement allegation in no small part on what the s=
pecifications of the Google-controlled VP8 standard say, which is an unmist=
akable sign that Nokia considers EP1206881 to be inevitably infringed by al=
l implementations of VP8."
Now, I understand that Mr. Mueller is not particularly highly regarded by a=
 whole bunch of people in the open source community.  I myself find a numbe=
r of other statements in this blog post, however carefully worded, somewhat=
 questionable.  OTOH, I consider it very unlikely that he made up all those=
 reported facts.
That my former colleagues in Nokia decide to sue over this patent (if they =
have done so) does, of course, not mean that the VP8 implementation of HTC =
infringes, let alone all VP8 implementations.  Quite likely we will never k=
now either way=97most patent lawsuits are settled out of court.
One other data point: Mr. Mueller is correct in that Nokia is not a member =
of the H.264 pool.  Nor are they members in any other video coding related =
patent pool that I'm aware of, despite IMO having one of the strongest vide=
o coding research teams in the industry (I was part of that myself, a while=
 ago).
Regards,
Stephan


--_000_CD613089973B9stewesteweorg_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Hi,


An additional data point.


Florian Mueller writes in his patent blog (http://www.fosspatents.com/=
2013/03/patent-clouds-remain-over-vp8-google.html) that he has attended a c=
ourt hearing in Mannheim, Germany, where, according to his blog, "Coun=
sel for Nokia indeed based the infringement
 allegation in no small part on what the specifications of the Google-contr=
olled VP8 standard say, which is an unmistakable sign that Nokia considers =
EP1206881 to be inevitably infringed by all implementations of VP8."

Now, I understand that Mr. Mueller is not particularly highly regarded=
 by a whole bunch of people in the open source community.  I myself fi=
nd a number of other statements in this blog post, however carefully worded=
, somewhat questionable.  OTOH, I consider
 it very unlikely that he made up all those reported facts.


That my former colleagues in Nokia decide to sue over this patent (if =
they have done so) does, of course, not mean that the VP8 implementation of=
 HTC infringes, let alone all VP8 implementations.  Quite likely we wi=
ll never know either way=97most patent
 lawsuits are settled out of court.


One other data point: Mr. Mueller is correct in that Nokia is not a me=
mber of the H.264 pool.  Nor are they members in any other video codin=
g related patent pool that I'm aware of, despite IMO having one of the stro=
ngest video coding research teams in
 the industry (I was part of that myself, a while ago).  


Regards,


Stephan


 




--_000_CD613089973B9stewesteweorg_--

From harald@alvestrand.no  Sat Mar  9 19:54: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 7BC8721F85FE for ; Sat,  9 Mar 2013 19:54:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.53
X-Spam-Level: 
X-Spam-Status: No, score=-109.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 rt+HCcYj9555 for ; Sat,  9 Mar 2013 19:54:16 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 13F8B21F85DA for ; Sat,  9 Mar 2013 19:54:16 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CBA6739E194 for ; Sun, 10 Mar 2013 04:54:13 +0100 (CET)
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 juHj9dGTexIU for ; Sun, 10 Mar 2013 04:54:13 +0100 (CET)
Received: from [192.168.255.9] (unknown [216.189.219.66]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1161D39E0E1 for ; Sun, 10 Mar 2013 04:54:11 +0100 (CET)
Message-ID: <513B5D98.2070601@alvestrand.no>
Date: Sat, 09 Mar 2013 17:04:40 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References:         
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [rtcweb] Separating stream manipulation from the SDP loudness (Re: Proposed Plan for Usage of SDP and RTP)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 10 Mar 2013 03:54:17 -0000

As usual, I'm trying to use subject line change in order to achieve some 
separation of concerns...

On 03/07/2013 10:22 PM, Silvia Pfeiffer wrote:
> Agreed, but it's also not sufficient. SDP is not "programmer friendly" 
> enough because it has too many details that are protocol-details only 
> and it's too hard to see the semantic bits in SDP and ignore the rest.
>
> For example: the programmer wants to say - I want to get this video 
> resolution, this audio bitrate & channels, I want to use this camera 
> and this microphone for this call. Having to manipulate SDP directly 
> for this is a programmer's nightmare.

I think we've been over exactly those pieces, and our current proposed 
solution is called the Media Stream API and the constraints mechanism - 
and they have exactly nothing to do with SDP, or even with PeerConnection.

I don't think we've got it to be "unproblematic" yet, but also, I don't 
think SDP, JSON or even the offer-answer model is either the problem or 
the solution on this set of functionalities.

Or did I misunderstand something basic?

                Harald


From pthatcher@google.com  Sat Mar  9 21:02: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 B1EB721F86CE for ; Sat,  9 Mar 2013 21:02:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.056
X-Spam-Level: 
X-Spam-Status: No, score=-102.056 tagged_above=-999 required=5 tests=[AWL=-0.746, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 CIhhPtL+0233 for ; Sat,  9 Mar 2013 21:02:13 -0800 (PST)
Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) by ietfa.amsl.com (Postfix) with ESMTP id D02A321F86C9 for ; Sat,  9 Mar 2013 21:02:12 -0800 (PST)
Received: by mail-ve0-f175.google.com with SMTP id cy12so2033567veb.20 for ; Sat, 09 Mar 2013 21:02:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=vhCTJxrxqp0DrDNb1txdNHUgfF7q2twgP+sF+bylGH8=; b=k/WSIFGmObxXY29cFykMPNrWKHoUzB4l+D0wC7PjFq1eOn/ty2T2QsbBcr1W2IpjBy OJRiBAhWguupvnaISWiIESg9xeeQFHsSrbHxy0YXSyNWasQEglZQeiWmeSafc2ynWCo/ e1u8DyHhCDG6p8+ja9nz7HA8E+roSeqpCphNWyCvH2ZzXRKJ29Xm072AoyRbuL7D+4Ql ZcG5Mfh4NAu4d9zGJTJqS6W23PsWxO4CZ15TfXCIz9brg4yfRl2kLS6aRcpB2uxuSTYR XwPhlHAYFe6POZ97fRZnrQgh1bFwfu+sSF6tvirmHwIZNZDEyNP8+T6N48weifXCGZmK zazw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=vhCTJxrxqp0DrDNb1txdNHUgfF7q2twgP+sF+bylGH8=; b=AmfTsmn/qUab3COtGEeEdGLk1wKlnPYVlrUVaoKhNHdSi8qS8aqqhSnYwZTq5Z2/PK gd9BFRao6P9lj7UWVUUEkSUWaQe0LzB5Kt0wXVkkh+jorZfVYcB3ljSRtxF6pr3bQ8NB uoYbHps0Ygpuz8tu52Wi1UqwOFPHxhkXneHllYBrj36ad1kTMZ3tKZPPZLpr3IC3bhde FT4W2YyqZUrTf652o9iZNreVb8Dqfauz1prM3daOYk1jf2vxBpRLpLro/feYg74I9pW5 BHUYkYchwAus0AK1i1idUJvdpcCq7CXn5kF2C2MMPmReUYJAotDE4BaxMUBgeHZg3X9z JM3Q==
MIME-Version: 1.0
X-Received: by 10.58.137.34 with SMTP id qf2mr3226940veb.25.1362891732198; Sat, 09 Mar 2013 21:02:12 -0800 (PST)
Received: by 10.58.49.102 with HTTP; Sat, 9 Mar 2013 21:02:11 -0800 (PST)
Received: by 10.58.49.102 with HTTP; Sat, 9 Mar 2013 21:02:11 -0800 (PST)
In-Reply-To: <513B5D98.2070601@alvestrand.no>
References:          <513B5D98.2070601@alvestrand.no>
Date: Sat, 9 Mar 2013 21:02:11 -0800
Message-ID: 
From: Peter Thatcher 
To: Harald Alvestrand 
Content-Type: multipart/alternative; boundary=089e0129546690b9be04d78af5f6
X-Gm-Message-State: ALoCoQlGvcPlcEYRok29IzfkW/2+tWeGZNZxwQROxqeS463pTMXToY8zoXqG8R0GM/iV7wXuCeS7S68axX3g52M+QbgOrhSVrTSgTNF4ejIGVlPe3Qg02R955vtafX3K3D+It2/KhUJ3MuWwrEJEfyTu5ChTU9AcobZ61Y+10PmXfkG8C4s1f8ikEmAGBLLq6ZMizKF/IjiU
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Separating stream manipulation from the SDP loudness (Re: Proposed Plan for Usage of SDP and RTP)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 10 Mar 2013 05:02:13 -0000

--089e0129546690b9be04d78af5f6
Content-Type: text/plain; charset=UTF-8

There's a difference between the resolution that you open the camera at and
the resolution you send over the network at.  Does the current constraints
API let you capture at one resolution and send at another?  Also, does it
let you change the send resolution on the fly?

These are important controls that, as far as I know, are not currently
supplied to the application.  They could potentially be supplied by SDP,
new methods, or as you suggest, perhaps even as some kind of constraint.
But I don't think they are currently provided.
On Mar 9, 2013 7:54 PM, "Harald Alvestrand"  wrote:

> As usual, I'm trying to use subject line change in order to achieve some
> separation of concerns...
>
> On 03/07/2013 10:22 PM, Silvia Pfeiffer wrote:
>
>> Agreed, but it's also not sufficient. SDP is not "programmer friendly"
>> enough because it has too many details that are protocol-details only and
>> it's too hard to see the semantic bits in SDP and ignore the rest.
>>
>> For example: the programmer wants to say - I want to get this video
>> resolution, this audio bitrate & channels, I want to use this camera and
>> this microphone for this call. Having to manipulate SDP directly for this
>> is a programmer's nightmare.
>>
>
> I think we've been over exactly those pieces, and our current proposed
> solution is called the Media Stream API and the constraints mechanism - and
> they have exactly nothing to do with SDP, or even with PeerConnection.
>
> I don't think we've got it to be "unproblematic" yet, but also, I don't
> think SDP, JSON or even the offer-answer model is either the problem or the
> solution on this set of functionalities.
>
> Or did I misunderstand something basic?
>
>                Harald
>
> ______________________________**_________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/**listinfo/rtcweb
>

--089e0129546690b9be04d78af5f6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


There's a difference between the resolution that you ope=
n the camera at and the resolution you send over the network at.=C2=A0 Does=
 the current constraints API let you capture at one resolution and send at =
another?=C2=A0 Also, does it let you change the send resolution on the fly?=
=C2=A0 



These are important controls that, as far as I know, are not=
 currently supplied to the application.=C2=A0 They could potentially be sup=
plied by SDP, new methods, or as you suggest, perhaps even as some kind of =
constraint.=C2=A0 But I don't think they are currently provided.



On Mar 9, 2013 7:54 PM, "Harald Alvestrand&=
quot; <harald@alvestrand.no&=
gt; wrote:

As usual, I'm trying to use subject line change in order to achieve som=
e separation of concerns...



On 03/07/2013 10:22 PM, Silvia Pfeiffer wrote:



Agreed, but it's also not sufficient. SDP is not "programmer frien=
dly" enough because it has too many details that are protocol-details =
only and it's too hard to see the semantic bits in SDP and ignore the r=
est.




For example: the programmer wants to say - I want to get this video resolut=
ion, this audio bitrate & channels, I want to use this camera and this =
microphone for this call. Having to manipulate SDP directly for this is a p=
rogrammer's nightmare.






I think we've been over exactly those pieces, and our current proposed =
solution is called the Media Stream API and the constraints mechanism - and=
 they have exactly nothing to do with SDP, or even with PeerConnection.




I don't think we've got it to be "unproblematic" yet, but=
 also, I don't think SDP, JSON or even the offer-answer model is either=
 the problem or the solution on this set of functionalities.



Or did I misunderstand something basic?



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Harald



_______________________________________________

rtcweb mailing list

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




--089e0129546690b9be04d78af5f6--

From stefan.lk.hakansson@ericsson.com  Sat Mar  9 23:01: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 2DFB521F87D6 for ; Sat,  9 Mar 2013 23:01:17 -0800 (PST)
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=[AWL=0.000,  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 7tdkRkDWldWu for ; Sat,  9 Mar 2013 23:01:16 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9002021F8782 for ; Sat,  9 Mar 2013 23:01:15 -0800 (PST)
X-AuditID: c1b4fb25-b7f366d000004d10-b5-513c2fb95546
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1B.BD.19728.9BF2C315; Sun, 10 Mar 2013 08:01:14 +0100 (CET)
Received: from [153.88.18.176] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Sun, 10 Mar 2013 08:01:13 +0100
Message-ID: <513C2FB9.7040803@ericsson.com>
Date: Sun, 10 Mar 2013 08:01:13 +0100
From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
References:          <513B5D98.2070601@alvestrand.no> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+Jvje4ufZtAgw+nWCzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxu3bB9gLFshWnG6ezNzA+Eysi5GTQ0LARGL2xo+sELaYxIV7 69m6GLk4hAROMkrsXvOIGcJZzShx8tVqsCpeAW2Jr8/XAiU4OFgEVCWWz/cACbMJBEpc//+L CSQsKhAlcWWfJUS1oMTJmU9YQGwRAXWJyw8vsIPYwgKVEm3v10LtWscqsbnhAiNIghNozoQn e9lAbGYBW4kLc66zQNjyEtvfzmEGsYUEdCXevb7HOoFRYBaSHbOQtMxC0rKAkXkVI3tuYmZO ernRJkZgmB3c8lt1B+OdcyKHGKU5WJTEecNdLwQICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRq YNxqHfVuEYNCjQLTqceJM5IFjm+4WLv3Rtl1P+HTOlsXh+Rs3MaQu8/fuf9zHseHTV0iHo+1 NNXzYh+8nMOwI3zn5tlGQdurzk16+HUfo7nz9VV5jzU+HuJlV0pUjT5fVLBBo3rR2enBYg9b tLsWHlrTvOVg0YvGbetFVq2auLPyVv+HhW6LfZ2UWIozEg21mIuKEwHyZrvIAQIAAA==
Subject: Re: [rtcweb] Separating stream manipulation from the SDP loudness (Re: Proposed Plan for Usage of SDP and RTP)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 10 Mar 2013 07:01:17 -0000

On 2013-03-10 06:02, Peter Thatcher wrote:
> There's a difference between the resolution that you open the camera at
> and the resolution you send over the network at.  Does the current
> constraints API let you capture at one resolution and send at another?
> Also, does it let you change the send resolution on the fly?
>
> These are important controls that, as far as I know, are not currently
> supplied to the application.  They could potentially be supplied by SDP,
> new methods, or as you suggest, perhaps even as some kind of
> constraint.  But I don't think they are currently provided.

They are currently not provided. One reason is that there was a 
comprehensive proposal for how to change - on the fly - settings using 
constraints submitted by Travis last fall [1]. After a lot of discussion 
the editors are currently incorporating a slightly modified version of 
it for the local use. Once we have general agreement on that model it 
can be extended to the cases when media is transmitted over the network.

I did make a proposal to the webrtc WG, [2], which is heavily influenced 
by [1], for how we could add an API surface to individually control 
setting for how media is transported (the focus is on Priority but the 
idea was that is should be extendable) but it was never thoroughly 
discussed. And, there are probably other and better ways to do it :-), 
my main point is that SDP manipulation should not be the way.

As for the specific control of resolution there has also been a 
discussion (and that is also part of [1]) that the display area used by 
e.g. a video element should travel back to the source so that is can 
adjust settings to optimize (even if the web app developer does nothing).

[1] 
https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v6.html
[2] 
http://lists.w3.org/Archives/Public/public-webrtc/2013Jan/att-0005/PrioAPI.pdf

Stefan

>
> On Mar 9, 2013 7:54 PM, "Harald Alvestrand"  > wrote:
>
>     As usual, I'm trying to use subject line change in order to achieve
>     some separation of concerns...
>
>     On 03/07/2013 10:22 PM, Silvia Pfeiffer wrote:
>
>         Agreed, but it's also not sufficient. SDP is not "programmer
>         friendly" enough because it has too many details that are
>         protocol-details only and it's too hard to see the semantic bits
>         in SDP and ignore the rest.
>
>         For example: the programmer wants to say - I want to get this
>         video resolution, this audio bitrate & channels, I want to use
>         this camera and this microphone for this call. Having to
>         manipulate SDP directly for this is a programmer's nightmare.
>
>
>     I think we've been over exactly those pieces, and our current
>     proposed solution is called the Media Stream API and the constraints
>     mechanism - and they have exactly nothing to do with SDP, or even
>     with PeerConnection.
>
>     I don't think we've got it to be "unproblematic" yet, but also, I
>     don't think SDP, JSON or even the offer-answer model is either the
>     problem or the solution on this set of functionalities.
>
>     Or did I misunderstand something basic?
>
>                     Harald
>
>     _________________________________________________
>     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 jerome.marcon@alcatel-lucent.com  Sun Mar 10 04:37: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 7A26F21F87D6 for ; Sun, 10 Mar 2013 04:37:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.96
X-Spam-Level: 
X-Spam-Status: No, score=-9.96 tagged_above=-999 required=5 tests=[AWL=0.288,  BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 pSoHbnwRNGKz for ; Sun, 10 Mar 2013 04:37:30 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id A0F7E21F87C4 for ; Sun, 10 Mar 2013 04:37:29 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2ABbC8E016486 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 10 Mar 2013 12:37:26 +0100
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 10 Mar 2013 12:37:19 +0100
Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Sun, 10 Mar 2013 12:37:19 +0100
From: "MARCON, JEROME (JEROME)" 
To: Salvatore Loreto , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] TR : New Version Notification	for draft-marcon-rtcweb-data-channel-management-00.txt
Thread-Index: AQHOGkeKBp6ZZkZVYEKNZbJkrTFNCpiexC8w
Date: Sun, 10 Mar 2013 11:37:19 +0000
Message-ID: <39821B4C400EC14DAD4DB25330A9271A0241E1@FR711WXCHMBA02.zeu.alcatel-lucent.com>
References: <20130218233047.19414.47123.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A012598@FR711WXCHMBA03.zeu.alcatel-lucent.com> <513702F9.2030909@ericsson.com>
In-Reply-To: <513702F9.2030909@ericsson.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.40]
Content-Type: multipart/alternative; boundary="_000_39821B4C400EC14DAD4DB25330A9271A0241E1FR711WXCHMBA02zeu_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
Subject: Re: [rtcweb] TR : New Version Notification	for	draft-marcon-rtcweb-data-channel-management-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: Sun, 10 Mar 2013 11:37:31 -0000

--_000_39821B4C400EC14DAD4DB25330A9271A0241E1FR711WXCHMBA02zeu_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Hi Salvatore,

Thanks for your review. Some answers [JM1] in line.


________________________________
De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la part de=
 Salvatore Loreto
Envoy=E9 : mercredi 6 mars 2013 09:49
=C0 : rtcweb@ietf.org
Objet : Re: [rtcweb] TR : New Version Notification for draft-marcon-rtcweb-=
data-channel-management-00.txt

Hi Jerome,

thanks for the draft.
some initial comments

1)

1.  Introduction

   [I-D.ietf-rtcweb-data-channel] provides use cases and requirements
   for the definition of RTCWeb data channels, and outlines how the
   Stream Control Transmission Protocol (SCTP) [RFC4960] encapsulated
   within Datagram Transport Layer Security (DTLS) [RFC6347] can be used
   for this purpose.  While some of these requirements easily map to
   existing capabilities of the SCTP protocol and extensions (e.g.
   application messages can be carried as SCTP user messages), SCTP and
   existing SCTP extensions do not natively support the following
   requirements:

   o  data channel bidirectionality (this can be achieved by pairing one
      SCTP outbound stream and one SCTP inbound stream)

   o  data channel priority

   o  partial reliability of delivery, based on a maximum number of
      retransmissions

   o  general data channel setup

here the problem for the 1 and 4 bullets is that SCTP does not have the con=
cept of data channel but only of stream.
[JM1] The introduction basically says that some data channels requirements =
cannot be met using SCTP alone. It does not say that the document will addr=
ess all these unfullfilled requirements

About bullet 3, you may want to read the http://tools.ietf.org/html/draft-t=
uexen-tsvwg-sctp-prpolicies-00
that propose how to define it.
[JM1] OK

About bullet 2, data channel priority, this is an important one that should=
 be discussed and defined.
However I haven't found anything in your proposal about it.
[JM1] Yes, work to be done. I haven't found anything either in Randell's (y=
ours) and Martin's proposal.

2) Data Channel configuration
Sorry but it is not clear to me what how you use DataChannel-configuration.=
..
i.e. if a DataChannel-configuration is 1:1 with an actual DataChannel, or w=
e can have a 1:n relationship
[JM1] Config -> 0..N Data Channels, and Data Channel -> 1 Config.


if I understood you correctly in

6.2.  Opening a data channel out-of-band

...

      Note: for each new configuration, the offerer expectedly creates
      one data channel or more, whereas the answerer creates one data
      channel only.  How the final data channel pairing (and SCTP stream
      number assignment) is resolved is further explained in this
      document.

...

so in out of band mode, only one DataChannel will be created per DataChanne=
l-configuration.
i.e. there is no way to create more DataChannels with the same DataChannel-=
configuration out-bound.
Isn't it? is so why? I don't get the advantage for this limitation
[JM1] For a new config declared in the offer, the answerer does not know ho=
w many data channels have been created on offerer's side (1 or more), i.e h=
ow many createDataChannel(withThisConfig) were called, as the SDP does not =
carry this number of channels. If the answerer's browser does nothing, then=
 the answerer's app will not be aware of the offerer's data channels till t=
he offerer sends messages on these. So:
- by creating one data channel of this config, the answerer's browser notif=
ies the app that data sending is fine on this channel, and that other data =
channels of this config could be created inband later on
- but when I think of it now, this one data channel creation is unnecessary=
, because the app is unaware of configs anyway. It can at anytime create ne=
w data channels of any properties, and these will sometimes match an existi=
ng config (so no renegotiation), and sometimes not .
So this answerer's behavior should be removed I think. In any case, each en=
dpoint app can create any number of data channels of any properties. The on=
ly noticeable difference noticeable to the app is that sometimes renegotiat=
ion will be triggered, sometimes not.

one of the reason people are asking for out-of-bound, is to give the possib=
ility to "disclosure" what kind
of traffic (and how much) is going on between two WebRTC clients (i.e. brow=
ser).
[JM1] The kind of traffic is disclosed, not the amount

However, it seems that you make then possible to open more DataChannels wit=
h the same DataChannel-configuration
in-band.


6.3.  Opening a data channel in-band

   Each user message sent in a data channel includes the identifier of
   the configuration which this data channel is bound to.  This
   signaling allows to enable or speed up the opening of new data
   channels in-band:



3) Framing

an inband protocol with data framing is unnecessary and a useless complicat=
ion for WebRTC DataChannel.
That is why the http://tools.ietf.org/html/draft-jesup-rtcweb-data-protocol=
-04 has no added framing required.

Please note that from a protocol point of view DataChannel is different fro=
m WebSocket.

In WebSocket it has been necessary to add a framing (and we tried to design=
 a minimal one, eve if I am not sure we have succeeded in that),
mainly because we need to make the protocol frame-based where the pure TCP =
is stream-based.
You do not need to do that with SCTP, as it already provides:

       sequenced delivery of user messages within multiple streams, with
       an option for order-of-arrival delivery of individual user
       messages,

[JM1] one principle of the proposal is to not carry in-band any data channe=
l properties, but instead the {SCTP stream number, Config ID} of the channe=
l(s) to be opened. This draft 00 proposes to do so using some header in app=
lication message. I agree that despite the header is smaller (2 bytes) than=
 the WebSocket (6 bytes or more), there are other concerns recalled by Rand=
ell. I have thought of alternatives since (still inline with the principle)=
.

/Salvatore



On 2/19/13 1:07 AM, MARCON, JEROME (JEROME) wrote:

Hi,

I have submitted a draft proposing a new way of setting up data channels, b=
ased on the concept of data channel configurations. It uses a lightweight S=
DP signaling coupled with a lightweight in-band signaling (not an in-band p=
rotocol). I think it can handle efficiently the most demanding setup scenar=
ios. The proposal is besides designed with the intent to not impact on curr=
ent browser API.

This is a first draft, thanks for your suggestions of improvements.

Jerome

________________________________________
De : internet-drafts@ietf.org [internet-dr=
afts@ietf.org]
Date d'envoi : mardi 19 f=E9vrier 2013 00:30
=C0 : MARCON, JEROME (JEROME)
Objet : New Version Notification for    draft-marcon-rtcweb-data-channel-ma=
nagement-00.txt

A new version of I-D, draft-marcon-rtcweb-data-channel-management-00.txt
has been successfully submitted by Jerome Marcon and posted to the
IETF repository.

Filename:        draft-marcon-rtcweb-data-channel-management
Revision:        00
Title:           RTCWeb data channel management
Creation date:   2013-02-19
Group:           Individual Submission
Number of pages: 15
URL:             http://www.ietf.org/internet-drafts/draft-marcon-rtcweb-da=
ta-channel-management-00.txt
Status:          http://datatracker.ietf.org/doc/draft-marcon-rtcweb-data-c=
hannel-management
Htmlized:        http://tools.ietf.org/html/draft-marcon-rtcweb-data-channe=
l-management-00


Abstract:
   The Real-Time Communication in WEB-browsers (RTCWeb) working group is
   charged to provide protocols to support direct interactive rich
   communication using audio, video, and data between two peers' web-
   browsers.  For the support of data communication, the RTCWeb working
   group has in particular defined the concept of bi-directional data
   channels over SCTP.  How to transport application messages on these
   data channels seems straightforward (i.e. they can be carried as SCTP
   user messages), however it is yet to be decided how to establish and
   manage these data channels.  This document specifies a method for
   this, which relies first on a lightweight and scalable out-of-band
   negotiation of data channel configurations (within the SDP offer/
   answer exchange) and second on the signaling of the configuration in
   use in the SCTP user message itself.  Once these configurations are
   negotiated, further creations of data channels can occur purely in-
   band by simply sending user messages, which avoids to define a new
   in-band data channel protocol.




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




--
Salvatore Loreto, PhD
www.sloreto.com

--_000_39821B4C400EC14DAD4DB25330A9271A0241E1FR711WXCHMBA02zeu_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









 


Hi Salvatore,


 


Thanks for your review. Some answers [JM1] in line.<=
/span>


 









De : rtcweb-bounces@ietf.org [=
mailto:rtcweb-bounces@ietf.org]
De la part de Salvatore Loreto

Envoy=E9 : mercredi 6 mars 2013 09:49

=C0 : rtcweb@ietf.org

Objet : Re: [rtcweb] TR : New Version Notification for draft-ma=
rcon-rtcweb-data-channel-management-00.txt








Hi Jerome,



thanks for the draft.

some initial comments



1)






1.  Introduction

   [I-D.ietf-rtcweb-data-channel] provides use cases and requirements
   for the definition of RTCWeb data channels, and outlines how the
   Stream Control Transmission Protocol (SCTP) [RFC4960] encapsulated
   within Datagram Transport Layer Security (DTLS) [RFC6347] can be used
   for this purpose.  While some of these requirements easily map to
   existing capabilities of the SCTP protocol and extensions (e.g.
   application messages can be carried as SCTP user messages), SCTP and
   existing SCTP extensions do not natively support the following
   requirements:

   o  data channel bidirectionality (this can be achieved by pairing one
      SCTP outbound stream and one SCTP inbound stream)

   o  data channel priority

   o  partial reliability of delivery, based on a maximum number of
      retransmissions

   o  general data channel setup






here the problem for the 1 and 4 bullets is that SCTP does not have the con=
cept of data channel but only of stream.

[JM1] The introduction basically says that some data channels re=
quirements cannot be met using SCTP alone. It does not say that the documen=
t will address all these unfullfilled requirements





About bullet 3, you may want to read the 
http://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-prpolicies-00

that propose how to define it.

[JM1] OK


 

About bullet 2, data channel priority, this is an important one that should=
 be discussed and defined.

However I haven't found anything in your proposal about it.

[JM1] Yes, work to be done. I haven't found anything either=
 in Randell's (yours) and Martin's proposal.



2) Data Channel configuration

Sorry but it is not clear to me what how you use DataChannel-configuration.=
..

i.e. if a DataChannel-configuration is 1:1 with an actual DataChannel, or w=
e can have a 1:n relationship

[JM1] Config -> 0..N Data Channels, and Data Cha=
nnel -> 1 Config.

 


 

if I understood you correctly in 






6.2.  Opening a data channel out-of-band

...

      Note: for each new configuration, the offerer expectedly creates
      one data channel or more, whereas the answerer creates one data
      channel only.  How the final data channel pairing (and SCTP stream
      number assignment) is resolved is further explained in this
      document.
...





so in out of band mode, only one DataChannel=
 will be created per DataChannel-configuration.

i.e. there is no way to create more DataChannels with the same DataChannel-=
configuration out-bound.

Isn't it? is so why? I don't get the advantage for this limitation

[JM1] For a new config
 declared in the offer, the answerer does not know how many data channels h=
ave been created on offerer's side (1 or more), i.e how many createDataChan=
nel(withThisConfig) were called, as the SDP does not carry this number of c=
hannels. If the answerer's browser does
 nothing, then the answerer's app will not be aware of the offere=
r's data channels till the offerer sends messages on these. So:


- by creating one data channel of this
 config, the answerer's browser notifies the app that data sendin=
g is fine on this channel, and that other data channels of this config coul=
d be created inband later on 


- but when I think of it now, this one
 data channel creation is unnecessary, because the app is unaware of config=
s anyway. It can at anytime create new data channels of any prope=
rties, and these will sometimes match an existing config (so no renegotiati=
on), and sometimes not . 

So this answerer's behavior should be removed
 I think. In any case, each endpoint app can create any number of data chan=
nels of any properties. The only noticeable difference noticeable to t=
he app is that sometimes renegotiation will be triggered, sometimes no=
t.


  

one of the reason people are asking for out-of-bound, is to give the possib=
ility to "disclosure" what kind

of traffic (and how much) is going on between two WebRTC clients (i.e. brow=
ser).

[JM1] The kind of traffic
 is disclosed, not the amount



However, it seems that you make then possible to open more DataChannels wit=
h the same DataChannel-configuration

in-band.








6.3.  Opening a data channel in-band

   Each user message sent in a data channel includes the identifier of
   the configuration which this data channel is bound to.  This
   signaling allows to enable or speed up the opening of new data
   channels in-band:










3) Framing



an inband protocol with data framing is unnecessary and a useless complicat=
ion for WebRTC DataChannel.

That is why the 
http://tools.ietf.org/html/draft-jesup-rtcweb-data-protocol-04 has no a=
dded framing required.



Please note that from a protocol point of view DataChannel is different fro=
m WebSocket.



In WebSocket it has been necessary to add a framing (and we tried to design=
 a minimal one, eve if I am not sure we have succeeded in that),

mainly because we need to make the protocol frame-based where the pure TCP =
is stream-based.

You do not need to do that with SCTP, as it already provides:






       sequenced delivery of user messages within multiple streams, wi=
th
       an option for order-of-arrival delivery of individual user
       messages,




[JM1]
 one principle of the proposal is <=
font face=3D"Tahoma" color=3D"#000080" size=3D"2">to
 not carry in-band any data channel properties, but instead the {SCTP strea=
m number, Config ID} of the channel(s) to be opened. This draft 00 proposes=
 to do so using some header in application message. I agree that despite th=
e header is smaller (2 bytes) than
 the WebSocket (6 bytes or more), there are other concerns recalled by Rand=
ell. I have thought of alternatives since (still inline with the principle)=
. 




/Salvatore







On 2/19/13 1:07 AM, MARCON, JEROME (JEROME) wrote:






Hi,

I have submitted a draft proposing a new way of setting up data channels, b=
ased on the concept of data channel configurations. It uses a lightweight S=
DP signaling coupled with a lightweight in-band signaling (not an in-band p=
rotocol). I think it can handle efficiently the most demanding setup scenar=
ios. The proposal is besides designed with the intent to not impact on curr=
ent browser API.

This is a first draft, thanks for your suggestions of improvements.

Jerome=20

________________________________________
De : internet-drafts@ietf.org [internet-drafts@ietf.org]
Date d'envoi : mardi 19 f=E9vrier 2013 00:30
=C0 : MARCON, JEROME (JEROME)
Objet : New Version Notification for    draft-marcon-rtcweb-data-channel-ma=
nagement-00.txt

A new version of I-D, draft-marcon-rtcweb-data-channel-management-00.txt
has been successfully submitted by Jerome Marcon and posted to the
IETF repository.

Filename:        draft-marcon-rtcweb-data-channel-management
Revision:        00
Title:           RTCWeb data channel management
Creation date:   2013-02-19
Group:           Individual Submission
Number of pages: 15
URL:             ht=
tp://www.ietf.org/internet-drafts/draft-marcon-rtcweb-data-channel-manageme=
nt-00.txt
Status:          http://datatr=
acker.ietf.org/doc/draft-marcon-rtcweb-data-channel-management
Htmlized:        http://tools.ie=
tf.org/html/draft-marcon-rtcweb-data-channel-management-00


Abstract:
   The Real-Time Communication in WEB-browsers (RTCWeb) working group is
   charged to provide protocols to support direct interactive rich
   communication using audio, video, and data between two peers' web-
   browsers.  For the support of data communication, the RTCWeb working
   group has in particular defined the concept of bi-directional data
   channels over SCTP.  How to transport application messages on these
   data channels seems straightforward (i.e. they can be carried as SCTP
   user messages), however it is yet to be decided how to establish and
   manage these data channels.  This document specifies a method for
   this, which relies first on a lightweight and scalable out-of-band
   negotiation of data channel configurations (within the SDP offer/
   answer exchange) and second on the signaling of the configuration in
   use in the SCTP user message itself.  Once these configurations are
   negotiated, further creations of data channels can occur purely in-
   band by simply sending user messages, which avoids to define a new
   in-band data channel protocol.




The IETF Secretariat
_______________________________________________
rtcweb mailing list
rtcwe=
b@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb









--=20
Salvatore Loreto, PhD
www.s=
loreto.com






--_000_39821B4C400EC14DAD4DB25330A9271A0241E1FR711WXCHMBA02zeu_--

From harald@alvestrand.no  Sun Mar 10 07:35: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 2CBF721F8809 for ; Sun, 10 Mar 2013 07:35:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.064
X-Spam-Level: 
X-Spam-Status: No, score=-110.064 tagged_above=-999 required=5 tests=[AWL=0.534, 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 EkARM7iY92yb for ; Sun, 10 Mar 2013 07:35:48 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D243D21F8804 for ; Sun, 10 Mar 2013 07:35:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5573F39E1AD; Sun, 10 Mar 2013 15:35:45 +0100 (CET)
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 W15JpxHHxohm; Sun, 10 Mar 2013 15:35:43 +0100 (CET)
Received: from [192.168.255.9] (unknown [216.189.219.66]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5332739E182; Sun, 10 Mar 2013 15:35:43 +0100 (CET)
Message-ID: <513C9A3D.8080906@alvestrand.no>
Date: Sun, 10 Mar 2013 15:35:41 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: Peter Thatcher 
References:          <513B5D98.2070601@alvestrand.no> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010706040903020409070709"
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Separating stream manipulation from the SDP loudness (Re: Proposed Plan for Usage of SDP and RTP)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 10 Mar 2013 14:35:49 -0000

This is a multi-part message in MIME format.
--------------010706040903020409070709
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 03/10/2013 06:02 AM, Peter Thatcher wrote:
>
> There's a difference between the resolution that you open the camera 
> at and the resolution you send over the network at.  Does the current 
> constraints API let you capture at one resolution and send at 
> another?  Also, does it let you change the send resolution on the fly?
>
Peter, you were in Boston, where we spent quite a bit of time on this 
very topic.

The relevant presentation is 
http://www.w3.org/wiki/images/f/fd/Constraints20130406.pdf.

Dan has promised to have the consensus of the discussion represented in 
the Media Capture and Streams spec well before the Media Capture and 
Streams meeting that we're currently scheduling for 2 weeks after the 
IETF (Doodle poll at http://doodle.com/xd7ffpidh6mgn2m8 )


> These are important controls that, as far as I know, are not currently 
> supplied to the application.  They could potentially be supplied by 
> SDP, new methods, or as you suggest, perhaps even as some kind of 
> constraint.  But I don't think they are currently provided.
>

But we DO have a W3C consensus on which approach to take in providing them.




--------------010706040903020409070709
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 03/10/2013 06:02 AM, Peter Thatcher
      wrote:

    

    

      
There's a difference between the resolution that you
        open the camera at and the resolution you send over the network
        at.  Does the current constraints API let you capture at one
        resolution and send at another?  Also, does it let you change
        the send resolution on the fly?  

    

    Peter, you were in Boston, where we spent quite a bit of time on
    this very topic.

    

    The relevant presentation is
    
    http://www.w3.org/wiki/images/f/fd/Constraints20130406.pdf.

    

    Dan has promised to have the consensus of the discussion represented
    in the Media Capture and Streams spec well before the Media Capture
    and Streams meeting that we're currently scheduling for 2 weeks
    after the IETF (Doodle poll at http://doodle.com/xd7ffpidh6mgn2m8 )

    

    

    

      
These are important controls that, as far as I know,
        are not currently supplied to the application.  They could
        potentially be supplied by SDP, new methods, or as you suggest,
        perhaps even as some kind of constraint.  But I don't think they
        are currently provided.

    

    

    But we DO have a W3C consensus on which approach to take in
    providing them.

    

    

    

  


--------------010706040903020409070709--

From prvs=27818836e5=gmartincocher@blackberry.com  Sun Mar 10 07:45: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 C3F0221F8675 for ; Sun, 10 Mar 2013 07:45:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.992
X-Spam-Level: 
X-Spam-Status: No, score=-4.992 tagged_above=-999 required=5 tests=[AWL=-2.210, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u00sa3DBq38K for ; Sun, 10 Mar 2013 07:45:13 -0700 (PDT)
Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5595621F8441 for ; Sun, 10 Mar 2013 07:45:13 -0700 (PDT)
X-AuditID: 0a41282f-b7fa06d000002431-e8-513c9c6e5b09
Received: from XCT108CNC.rim.net (xct108cnc.rim.net [10.65.161.208]) by mhs060cnc.rim.net (SBG) with SMTP id 27.72.09265.E6C9C315; Sun, 10 Mar 2013 09:45:02 -0500 (CDT)
Received: from XMB106BCNC.rim.net ([fe80::99b8:8d0e:cdcd:c00d]) by XCT108CNC.rim.net ([fe80::8dc1:9551:6ed8:c618%17]) with mapi id 14.02.0328.009; Sun, 10 Mar 2013 10:45:01 -0400
From: Gaelle Martin-Cocher 
To: "rtcweb@ietf.org" 
Thread-Topic: Request to postpone the question on VP8 as MTI
Thread-Index: Ac4dlY3FzJtNznrqSx+jCyG0eO/KJA==
Date: Sun, 10 Mar 2013 14:45:00 +0000
Message-ID: <92D0D52F3A63344CA478CF12DB0648AA26537A69@XMB106BCNC.rim.net>
Accept-Language: fr-FR, en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.160.252]
Content-Type: multipart/related; boundary="_004_92D0D52F3A63344CA478CF12DB0648AA26537A69XMB106BCNCrimne_"; type="multipart/alternative"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBJsWRmVeSWpSXmKPExsXC5bjwgm7eHJtAgwVnpC3W/mtnd2D0WLLk J1MAY1QDo01SYklZcGZ6nr6dTWJeXn5JYkmqQkpqcbKtkk9qemKOQkBRZllicqWCS2Zxck5i Zm5qkZJCZoqtkomSQkFOYnJqbmpeia1SYkFBal6Kkh2XAgawASrLzFNIzUvOT8nMS7dV8gz2 17WwMLXUNVSy003o5Ml4cu8Le8HkSYwVm+deYG1gPNHA2MXIySEhYCJx8fMrVghbTOLCvfVs ILaQwCpGiSfn+LoYuYDsbYwSkzvOM4Mk2AQsJf6/2sMCYosIqEtcfniBHcQWFjCX+HT4PiNE 3EZi0aTfUDV6Ehs+7waLswioSkzvawebwyvgKbHz03cgm4ODUUBF4uTTcJAws4C4xK0n85kg 7hGReHjxNBuELSrx8vE/qDsVJZ7dWcoOUd/NKPFmVyDESEGJkzOfsExgFJqFZNQsJGWzkJRB xPMljt3eyQxh60ncmDqFDcLWlli28DVUXFdixr9DLJjiOhKbL+2EiitKtHXOBtrFBWQvZZSY 938/C0xR26F9bDBFU7ofsi9g5F3FKJibUWxgZpCcl6xXlJmrl5dasokRnI409Hcwvn1vcYhR gINRiYf3cIN1oBBrYllxZe4hRhWgGY82rL7AKMWSl5+XqiTCy1NlEyjEm5JYWZValB9fVJqT WnyIMQcY0hOZpbiT84EpNK8k3tjAgGKOkjivSKBooJBAOjDtZqemFqQWwaxj4uA8xCjBwSUl UgxMnqlFiaUlGfGgFB9fDEzyUg2MDe+/PtZQEtg46/3qKVnH70VaLbtf6F+rmln35Cw756NQ KbfzX3/pZvstmvU2t3fu5WC7N+1PRHwVwrr6DikFxDk/ubjsCEvgAxn/z+ZcWguWnHvwdPff 6WxKD7fHe79njVydWjnjhXjm4ncf/OWfhkvq7zTOmTvVZ/4Llu8PMxRdIiRddWZsU2Ipzkg0 1GIuKk4EABP7dAK7AwAA
Subject: [rtcweb] Request to postpone the question on VP8 as MTI
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 10 Mar 2013 14:45:16 -0000

--_004_92D0D52F3A63344CA478CF12DB0648AA26537A69XMB106BCNCrimne_
Content-Type: multipart/alternative;
	boundary="_000_92D0D52F3A63344CA478CF12DB0648AA26537A69XMB106BCNCrimne_"

--_000_92D0D52F3A63344CA478CF12DB0648AA26537A69XMB106BCNCrimne_
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable

Dear All,

In light of the recent announcements (both MPEG-LA and the VP8 litigation),=
 I believe that more time is needed to make a proper risk assessment on VP8=
 and an informed decision. On one side the MPEG-LA announcement provides som=
e relief but also confirms that VP8 does not come for free and that concerns=
 were/are justified. This is further confirmed by the second announcement.
It will take more efforts for VP8 supporters (and Google does not need to be=
 alone in that process) to reach the goal of an RF video codec (or a codec w=
ith a suitable licensing terms). I think it is understood by now, that this=
 would likely be more prone to success in a standardization body than anywhe=
re else . (speaking here as a WebVC proponent that went through that process=
 too).
It is also apparent that the MPEG-LA/Google agreement raises additional ques=
tions.

Here are the reasons I believe we need more time and should postpone the que=
stion on VP8 (I am not saying that this should not be asked at a later time)=
:
-The license is not yet published (and the meeting starts tomorrow)
-Some negotiations are still ongoing (e.g. names of the licensors).
-Some questions were/are raised and not answered yet, below are the one that=
 matters to me:
- Will the patent list be provided?
- Who are the licensors  and how that group of licensors relates to the init=
ial 12 patent holders identified by MPEG-LA?
- Will there be alignment of licenses across WebM, RFC, MPEG, and is that ev=
en feasible with the possible new license terms?
- Questions related to clarifications of the different grants inside/outside=
 the RFC and their applicability to the RFC itself still need to be answered=
 (aka: how  section 20: 27 apply to the RFC code itself or to the code provi=
ded in MPEG)
- Questions related to the status of VP8 as a standard as it was mentioned t=
hat the RFC will not progress to the standard track still remain
- In light of the litigation announcement, was due diligence done by VP8 pro=
ponents toward patent holders that are not MPEG-LA members?  (e.g. possibly=
 on a model similar to what was done in WebVC)
- More questions will likely be raised once the license is published.
-We need to give enough time to Google to finalize its license and provide a=
nswers on those above points.
-VP8 is not (yet) a standard in IETF nor in MPEG (MPEG only saw an input con=
tribution for the first time in January). It would be desirable that RTCWeb=
 points to a standard or that VP8 reaches a certain stage in MPEG so that it=
 can be considered as an MPEG deliverable. VP8 may reach that status at a ne=
xt MPEG meeting in April or July, I don't see how that can be accelerated fu=
rther. We need to give MPEG the time to proceed properly.
-legal entities will need time to review both the new license and the answer=
s to the various questions that were asked. This cannot be achieved in 3 day=
s.

Further, I just came across an informational RFC for VP9:
-Is VP9 going to "deprecate" VP8?
- What is the timeframe for VP9 in IETF?
-if VP9 going to be proposed for a next generation of RTCWeb Client? Which t=
imeframe?
I don't think it would be desirable to mandate VP8 today if VP9 is around th=
e corner and will be proposed for RTCWeb as well.
Requesting two codecs to be implemented instead of one in a short timeframe=
 is obviously an issue for implementers that cannot do a simple software upg=
rade of their products.


I hope all of you will find that request reasonable.
Sincerely,


Ga=EBlle Martin-Cocher

Standards Manager


Office: (905) 629-4746 x14591

BlackBerry: (647) 267-0569

PIN: 2835485E


[Description: C:\Documents and Settings\gmartincocher\Application Data\Micro=
soft\Signatures\bblogo.gif]

www.rim.com



---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

--_000_92D0D52F3A63344CA478CF12DB0648AA26537A69XMB106BCNCrimne_
Content-Type: text/html; charset="iso-8859-1"
content-transfer-encoding: quoted-printable











Dear All,


 


In light of the recent announcements (both MPEG-LA an=
d the VP8 litigation), I believe that more time is needed to make a proper r=
isk assessment on VP8 and an informed decision. On one side the MPEG-LA anno=
uncement provides some relief but
 also confirms that VP8 does not come for free and that concerns were/are ju=
stified. This is further confirmed by the second announcement.

It will take more efforts for VP8 supporters (and Goo=
gle does not need to be alone in that process) to reach the goal of an RF vi=
deo codec (or a codec with a suitable licensing terms). I think it is unders=
tood by now, that this would likely
 be more prone to success in a standardization body than anywhere else . (sp=
eaking here as a WebVC proponent that went through that process too).


It is also apparent that the MPEG-LA/Google agreement=
 raises additional questions.


 


Here are the reasons I believe we need more time and=
 should postpone the question on VP8 (I am not saying that this should not b=
e asked at a later time):


-The license is not yet published (and the meeting st=
arts tomorrow)


-Some negotiations are still ongoing (e.g. names of t=
he licensors).  


-Some questions were/are raised and not answered yet,=
 below are the one that matters to me:


- Will the patent list be=
 provided?


- Who are the licensors&nb=
sp; and how that group of licensors relates to the initial 12 patent holders=
 identified by MPEG-LA?


- Will there be alignment=
 of licenses across WebM, RFC, MPEG, and is that even feasible with the poss=
ible new license terms?


- Questions related to cla=
rifications of the different grants inside/outside the RFC and their applica=
bility to the RFC itself still need to be answered (aka: how  section 2=
0: 27 apply to the RFC code itself or
 to the code provided in MPEG)


- Questions related to the=
 status of VP8 as a standard as it was mentioned that the RFC will not progr=
ess to the standard track still remain


- In light of the litigati=
on announcement, was due diligence done by VP8 proponents toward patent hold=
ers that are not MPEG-LA members?  (e.g. possibly on a model similar to=
 what was done in WebVC)  


- More questions will likely be raised once the licen=
se is published.



-We need to give enough time to Google to finalize it=
s license and provide answers on those above points.


-VP8 is not (yet) a standard in IETF nor in MPEG (MPE=
G only saw an input contribution for the first time in January). It would be=
 desirable that RTCWeb points to a standard or that VP8 reaches a certain st=
age in MPEG so that it can be considered
 as an MPEG deliverable. VP8 may reach that status at a next MPEG meeting in=
 April or July, I don’t see how that can be accelerated further. We ne=
ed to give MPEG the time to proceed properly.


-legal entities will need time to review both the new=
 license and the answers to the various questions that were asked. This cann=
ot be achieved in 3 days.


 


Further, I just came across an informational RFC for=
 VP9:


-Is VP9 going to “deprecate” VP8?


- What is the timeframe for VP9 in IETF?

-if VP9 going to be proposed for a next generation of=
 RTCWeb Client? Which timeframe?


I don’t think it would be desirable to mandate=
 VP8 today if VP9 is around the corner and will be proposed for RTCWeb as we=
ll.



Requesting two codecs to be implemented instead of on=
e in a short timeframe is obviously an issue for implementers that cannot do=
 a simple software upgrade of their products.



 


 


I hope all of you will find that request reasonable.<=
o:p>


Sincerely,


 


 








Ga=
=EBlle Martin-Cocher









Standards Manager








 <=
/p>







Office: (905) 629-4746 x145=
91








BlackBerry: (647) 267-0569<=
o:p>








PIN: 2835485E








 <=
/p>







3D"Description=








ww=
w.rim.com









 



--------------------------------------------------------------------- 

This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.



--_000_92D0D52F3A63344CA478CF12DB0648AA26537A69XMB106BCNCrimne_--

--_004_92D0D52F3A63344CA478CF12DB0648AA26537A69XMB106BCNCrimne_
Content-Type: image/gif; name="image001.gif"
Content-Description: image001.gif
Content-Disposition: inline; filename="image001.gif"; size=2577;
	creation-date="Sun, 10 Mar 2013 14:44:59 GMT";
	modification-date="Sun, 10 Mar 2013 14:44:59 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

R0lGODlhjQAiANUAAF5bXMrJydjX1zIvMF5bW+Xl5fLx8UE9PsvKyvPy8np3eJSTkzIvL5WTlMvK
ycrKybCvr4eFhk9MTV5cXJSSk6KhoEI+PoeGhmtqaXp4eOTk5KOhoa+urmxqab68vUE9PZWTk727
vHp3d2xqauTl5LCvrtjY19nY2FBNTdnY16KgoKOhoE9MTL28vK+vrvPy8WtpaTIuLzEuL11bW4iG
hkI9Pr68vIiGh09NTSMfHyQgICMfICQfIP///wAAAAAAACH/C1hNUCBEYXRhWE1QPD94cGFja2V0
IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4
bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iQWRvYmUgWE1QIENvcmUgNS4wLWMwNjAg
NjEuMTM0Nzc3LCAyMDEwLzAyLzEyLTE3OjMyOjAwICAgICAgICAiPiA8cmRmOlJERiB4bWxuczpy
ZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPiA8cmRmOkRl
c2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFw
LzEuMC8iIHhtbG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxu
czpzdFJlZj0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIg
eG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1M1IFdpbmRvd3MiIHhtcE1NOkluc3Rh
bmNlSUQ9InhtcC5paWQ6QTk5QzA5MUNFQkExMTFFMDg4OTZBOEYxNkFFRjgzRjEiIHhtcE1NOkRv
Y3VtZW50SUQ9InhtcC5kaWQ6QTk5QzA5MURFQkExMTFFMDg4OTZBOEYxNkFFRjgzRjEiPiA8eG1w
TU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0ieG1wLmlpZDpBOTlDMDkxQUVCQTExMUUw
ODg5NkE4RjE2QUVGODNGMSIgc3RSZWY6ZG9jdW1lbnRJRD0ieG1wLmRpZDpBOTlDMDkxQkVCQTEx
MUUwODg5NkE4RjE2QUVGODNGMSIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6
eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/PgH//v38+/r5+Pf29fTz8vHw7+7t7Ovq6ejn5uXk
4+Lh4N/e3dzb2tnY19bV1NPS0dDPzs3My8rJyMfGxcTDwsHAv769vLu6ubi3trW0s7KxsK+urayr
qqmop6alpKOioaCfnp2cm5qZmJeWlZSTkpGQj46NjIuKiYiHhoWEg4KBgH9+fXx7enl4d3Z1dHNy
cXBvbm1sa2ppaGdmZWRjYmFgX15dXFtaWVhXVlVUU1JRUE9OTUxLSklIR0ZFRENCQUA/Pj08Ozo5
ODc2NTQzMjEwLy4tLCsqKSgnJiUkIyIhIB8eHRwbGhkYFxYVFBMSERAPDg0MCwoJCAcGBQQDAgEA
ACH5BAAAAAAALAAAAACNACIAAAb/wJ5wSCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16v+CweEwum89o
7oYwAQA8wgsBQOgI0vh8D6Db8XgDQn88OjwdeohmO4uLDD0Cg3+HiZRgAn6EORw9Kn08OQN3Ag8B
AXdFpAgIpQ+nQyelBVsODgEJRwIItaUBDpVDBrWrGkIFugEIt3s5zDoRRZk8O54HLUMWfQ9aBn45
skY4hNLSoA2/UMyDAEQBOdLTjH8BPQY5hQZaD4UfSIv2hX925DBHSYQ0HQcgCEGxiIeEOwHG5dih
gEiFaQPcABggDkMPD58ObFmgI8ekIgim6Zgz4QOzHY4oSfAEkx6jQodCEJgDYIEy/yEY3HkUYkCC
tHUUpI1gp4BAjgMzSqDMYPQABoVDJvShIMTEiJ0AFLjjNwQDvCEFRBi1AMNXEQMUwN4psIEOgDYX
iHigMwHfkXGLRAYoJDBHxSUHFlUgAsCPR608FguJ4AdgnwxDLhDCdNQvA3mPBkzkwaGDtJM9LhSS
IQTC6NE8DgsRINrejgQQYryTEJjIgT8ikAwWx8BFj6SYDohChsDvkAQCdVRAFmIEIR0hesSY5lZz
ST8CP5noscDd5nfOehT4nuAEAx06BiDo8aGQggCkKC/iWgKg+T47LFDMAPB9YgECAf0RwSc8DLHB
JwM499YDtWhTDH6mDJGYedYMEf9RdJ/Ak8MNPWhQiA5CmPgHAbIkYIEfARQAHgMbBNDAdzoY4ME0
ByDAgDvK9fCCJwH9s8NSCXD0FBwCoPBHTAoQMgAIpgDwhwwc2OKODrIYMIAfBFlhQCQ7rDMEBfCQ
s9kGrfUhQTGrxBgABBmAF0AGJTHgSgWjBRCBOxyVJIEyCAA0ziDP9HDRRN/0kEAfOmjzZWRCkHCi
KwdMNF8Di1ggBU9h4fMheMENYeUOB7TxpSe+qKaDbCRE8FtDABnwYg40oORAMo2F6I5zCxDCwAwA
fBDQDotNsOVBlTFDiz0NtrkDC4z9wYEG0/DQ4RMapCONOQ18Ep8CEjIwjQpDkPD/5Q6H8CFda+mY
ly0/zcyDBGDjYNUDAZ9gJsQLLEjjKb+fMPNSQA5ssIiZPfzJQ6JCNGDPAgr4wfATHhDmh4BKYCuQ
Kz1kMNEEPXQjynUHLODBAxdM5NE72R2RQkADGLUDAUNMqq+iheSwB3wo0MHTBHOQECUPYQIwkVRD
VFDIi36A7ARlf+TAAAlLpLQIEQWYywMAl3wixAI8+pWAuTmgm2kOJAtxQmUUcNCIAOv9MV8PDLqS
AAt+OGKWYeyUcseGMeP9x3geAuiHbFAIQEspPyURtgUUULAABqtG5oA4xIQLSAgJlGBBiPMZdJQN
K3zpTgoRlHQYAdOYWfACIFDM/9HiPXAAX4AkFFDnIhA86s43JhRcBHSeDBC5GDVg0k1AKJT4hycR
Jbjl1ur9yCBsec2kwyY9PNBnD2KFB94fA3wz63WbvfnAk0Os8MfFQigZ4BkCeL2ZHyMoM8H064hS
ZeLTkCFA4DOG4kGpCuaKXq0jATPJlkBuloIhCOA359nBoHoQrh3AYAgV40FeijABP4gEDQaAQAMa
sIAGbKBR9FiAG9jUAxcIjQIGoN0CGlWACLiBABmwVwFqxzEhpKABIMBhayiARBYijggGWAFPRmAc
IYRghXfrQQmQKLW65QAO5wijGGCnA/qJ8Yz5CM8J0MjGLXxgEYxroxynwAEIwRRwjnh8ggCQIbU8
+vGPgAykIPMYBAA7

--_004_92D0D52F3A63344CA478CF12DB0648AA26537A69XMB106BCNCrimne_--

From fluffy@iii.ca  Sun Mar 10 08:53: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 A8E1521F86CE for ; Sun, 10 Mar 2013 08:53: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 C8m4k7jGDge8 for ; Sun, 10 Mar 2013 08:52:51 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 708EC21F8633 for ; Sun, 10 Mar 2013 08:52:33 -0700 (PDT)
Received: from rcdn-vpn-client-10-89-1-224.cisco.com (unknown [72.163.0.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7DDD9509B7; Sun, 10 Mar 2013 11:52:32 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Cullen Jennings 
In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AA26537A69@XMB106BCNC.rim.net>
Date: Sun, 10 Mar 2013 10:52:31 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <92D0D52F3A63344CA478CF12DB0648AA26537A69@XMB106BCNC.rim.net>
To: Gaelle Martin-Cocher 
X-Mailer: Apple Mail (2.1499)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Request to postpone the question on VP8 as MTI
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 10 Mar 2013 15:53:01 -0000

Gaelle,=20

I think these are good points and other have erased similar points. I =
need to discuss it with my co-chairs but I suspect that for the points =
you raised, we will need delay this to IETF 86. Again, I need to talk to =
my co-chairs before we can make a decision on this but I would guess =
that is the direction things will need to go.

Cullen (One of the co-chairs)


On Mar 10, 2013, at 9:45 AM, Gaelle Martin-Cocher =
 wrote:

> Dear All,
> =20
> In light of the recent announcements (both MPEG-LA and the VP8 =
litigation), I believe that more time is needed to make a proper risk =
assessment on VP8 and an informed decision. On one side the MPEG-LA =
announcement provides some relief but also confirms that VP8 does not =
come for free and that concerns were/are justified. This is further =
confirmed by the second announcement.
> It will take more efforts for VP8 supporters (and Google does not need =
to be alone in that process) to reach the goal of an RF video codec (or =
a codec with a suitable licensing terms). I think it is understood by =
now, that this would likely be more prone to success in a =
standardization body than anywhere else . (speaking here as a WebVC =
proponent that went through that process too).
> It is also apparent that the MPEG-LA/Google agreement raises =
additional questions.
> =20
> Here are the reasons I believe we need more time and should postpone =
the question on VP8 (I am not saying that this should not be asked at a =
later time):
> -The license is not yet published (and the meeting starts tomorrow)
> -Some negotiations are still ongoing (e.g. names of the licensors). =20=

> -Some questions were/are raised and not answered yet, below are the =
one that matters to me:
> - Will the patent list be provided?
> - Who are the licensors  and how that group of licensors relates to =
the initial 12 patent holders identified by MPEG-LA?
> - Will there be alignment of licenses across WebM, RFC, MPEG, and is =
that even feasible with the possible new license terms?
> - Questions related to clarifications of the different grants =
inside/outside the RFC and their applicability to the RFC itself still =
need to be answered (aka: how  section 20: 27 apply to the RFC code =
itself or to the code provided in MPEG)
> - Questions related to the status of VP8 as a standard as it was =
mentioned that the RFC will not progress to the standard track still =
remain
> - In light of the litigation announcement, was due diligence done by =
VP8 proponents toward patent holders that are not MPEG-LA members?  =
(e.g. possibly on a model similar to what was done in WebVC) =20
> - More questions will likely be raised once the license is published.
> -We need to give enough time to Google to finalize its license and =
provide answers on those above points.
> -VP8 is not (yet) a standard in IETF nor in MPEG (MPEG only saw an =
input contribution for the first time in January). It would be desirable =
that RTCWeb points to a standard or that VP8 reaches a certain stage in =
MPEG so that it can be considered as an MPEG deliverable. VP8 may reach =
that status at a next MPEG meeting in April or July, I don=92t see how =
that can be accelerated further. We need to give MPEG the time to =
proceed properly.
> -legal entities will need time to review both the new license and the =
answers to the various questions that were asked. This cannot be =
achieved in 3 days.
> =20
> Further, I just came across an informational RFC for VP9:
> -Is VP9 going to =93deprecate=94 VP8?
> - What is the timeframe for VP9 in IETF?
> -if VP9 going to be proposed for a next generation of RTCWeb Client? =
Which timeframe?
> I don=92t think it would be desirable to mandate VP8 today if VP9 is =
around the corner and will be proposed for RTCWeb as well.
> Requesting two codecs to be implemented instead of one in a short =
timeframe is obviously an issue for implementers that cannot do a simple =
software upgrade of their products.
> =20
> =20
> I hope all of you will find that request reasonable.
> Sincerely,
> =20
> =20
> Ga=EBlle Martin-Cocher
> Standards Manager
> Office: (905) 629-4746 x14591
> BlackBerry: (647) 267-0569
> PIN: 2835485E
> 
> www.rim.com
> =20
> ---------------------------------------------------------------------=20=

> This transmission (including any attachments) may contain confidential =
information, privileged material (including material protected by the =
solicitor-client or other applicable privileges), or constitute =
non-public information. Any use of this information by anyone other than =
the intended recipient is prohibited. If you have received this =
transmission in error, please immediately reply to the sender and delete =
this information from your system. Use, dissemination, distribution, or =
reproduction of this transmission by unintended recipients is not =
authorized and may be unlawful. =
_______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From ted.ietf@gmail.com  Sun Mar 10 11:09: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 0524A21F858C for ; Sun, 10 Mar 2013 11:09:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.573
X-Spam-Level: 
X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.027,  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 2G-ehQqGZf+1 for ; Sun, 10 Mar 2013 11:09:20 -0700 (PDT)
Received: from mail-ia0-x22a.google.com (mail-ia0-x22a.google.com [IPv6:2607:f8b0:4001:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA7421F8578 for ; Sun, 10 Mar 2013 11:09:20 -0700 (PDT)
Received: by mail-ia0-f170.google.com with SMTP id h8so2952713iaa.1 for ; Sun, 10 Mar 2013 11:09:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=7wwzne+LXaIw3AoltYaTu9Fo8QUi2kd2BxOZcgPZQsA=; b=f4gpAGGm/q3tpXZkoEQwQV7TphU921xBiDgSfLBIJO9ej1T2G5WgLsAS83YsRHId9W gdmjpYHc6++RzJ2iBuLeAUJpXbKShV2G4ToHvi5oVec5yFd+u67BeWOV1LVoYyFtI/iL suxiladNlYOGwaKj9gLT4+D1SXzNLMtqwVJRUz6hkFzi4H2KjLYn8YYVn0mOCGUFqBeX Q/7k3nYbv21MlmFZJB55nhetr/oj/M5G69+TFRElf69EJ3CcLm4t3lQnzGw3A2TUhqES vbdF4vFAwdXbi1mbwquK9fqlLL+0Dv2Qbask5Cqna3dLgIyD/YO23fJBGyvvWprEsyB9 rI1Q==
MIME-Version: 1.0
X-Received: by 10.50.170.102 with SMTP id al6mr5292929igc.20.1362938959877; Sun, 10 Mar 2013 11:09:19 -0700 (PDT)
Received: by 10.43.135.202 with HTTP; Sun, 10 Mar 2013 11:09:19 -0700 (PDT)
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BEDCB@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <949EF20990823C4C85C18D59AA11AD8BEDCB@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Date: Sun, 10 Mar 2013 14:09:19 -0400
Message-ID: 
From: Ted Hardie 
To: rtcweb@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [rtcweb] Fwd: [MMUSIC] Grouping 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: Sun, 10 Mar 2013 18:09:21 -0000

Of interest to this group, I believe.

regards,

Ted Hardie


---------- Forwarded message ----------
From: DRAGE, Keith (Keith) 
Date: Sun, Mar 10, 2013 at 10:30 AM
Subject: [MMUSIC] Grouping discussion
To: "mmusic@ietf.org" 


I have made a small revision to the AVTEXT agenda which can be found here.

https://datatracker.ietf.org/meeting/86/agenda/avtext/

The addition is to add

draft-burman-rtcweb-mmusic-media-structure-00

as a relevant document to the discussion on grouping, which is joint
with MMUSIC.

There is also planned to be an ad-hoc discussion of the grouping
material on Monday in the slot 15:40 to 17:10. If you are interested
in participating in this discussion please consult with either Bo
Burman, or one of the AVTEXT chairs, and we'll let you know which
room, when we find out ourselves.

Regards

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

From ted.ietf@gmail.com  Sun Mar 10 11:19: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 4BB3721F88C7 for ; Sun, 10 Mar 2013 11:19:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.575
X-Spam-Level: 
X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.025,  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 hGWLwimdfo-u for ; Sun, 10 Mar 2013 11:19:04 -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 B463621F8895 for ; Sun, 10 Mar 2013 11:19:04 -0700 (PDT)
Received: by mail-ie0-f170.google.com with SMTP id c11so3923440ieb.15 for ; Sun, 10 Mar 2013 11:19:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aJD1CtQbXcZHAJWD3ywGYBB688ermGXiwFmbbOkt7XQ=; b=sneaesGFennpjSUvHx7c83KKteR4mvyqiN7N0qVYRwJvgTClnWV1ujPVzohLU2HhE3 ReQtJ21QI3E2pvNJuYqcxPfdHMaTzEcwyHe4PClyF9iCSjKqzyT1JBOvCP/tkCxhL7FJ 02dwMudloSFbP5I1n0/P+a+YNJtTH2OYaKjHJS1onIp/C3Q/Vo/60u/LzabRbXsrqTWk UXYY1iCPkyADd261C4hWWfHhBdltu/4111qsr/vEQdPnXVOdyX2K1mz7ljUAbyq4poal 0MePTCcjjKDu2A/yufVnJPr4e3NfErLw+T/8bsi3zMOvtlxNb2+ae8dn9DNhUO+NskZa LwzA==
MIME-Version: 1.0
X-Received: by 10.50.36.169 with SMTP id r9mr5124464igj.96.1362939544338; Sun, 10 Mar 2013 11:19:04 -0700 (PDT)
Received: by 10.43.135.202 with HTTP; Sun, 10 Mar 2013 11:19:04 -0700 (PDT)
In-Reply-To: 
References: 
Date: Sun, 10 Mar 2013 14:19:04 -0400
Message-ID: 
From: Ted Hardie 
To: Stephan Wenger 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 litigation in Germany?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 10 Mar 2013 18:19:05 -0000

On Sat, Mar 9, 2013 at 9:31 PM, Stephan Wenger  wrote:
> One other data point: Mr. Mueller is correct in that Nokia is not a member
> of the H.264 pool.  Nor are they members in any other video coding related
> patent pool that I'm aware of, despite IMO having one of the strongest video
> coding research teams in the industry (I was part of that myself, a while
> ago).

Hi Stephan,

So, this seems to me to imply that any Nokia IPR on either H.264 or
VP8 is not part of any established patent pool and thus is not
publicly in the "market" of which you have previously spoken.  If that
is the case, it would seem to be an equally unknown factor for an
implementer of either.   To put this slightly different, even if Mr.
Mueller were correct, the additional context seems to result in this
being null data for our particular working group decision.

regards,

Ted Hardie

From ted.ietf@gmail.com  Sun Mar 10 11: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 65BC421F88A0 for ; Sun, 10 Mar 2013 11:22:20 -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.023,  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 TAEJ7W3xsjKJ for ; Sun, 10 Mar 2013 11:22:19 -0700 (PDT)
Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 63A2421F8895 for ; Sun, 10 Mar 2013 11:22:19 -0700 (PDT)
Received: by mail-ie0-f181.google.com with SMTP id 17so3817981iea.40 for ; Sun, 10 Mar 2013 11:22:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lh2JWD4DL51LoDblr6i4DnxyhDbOfzUEDEFoeCHL9+Y=; b=BTW5k+3w5KovYCX9j566+hVtWNzffQBS7QjkvuyG5v8tw9llQ7t+hKji1HuWXpefEb La+MEeUGJMMjAj7IeJaDRITdcWaBsBJyu/rOHSLcRlmJr7Ap/XkluiKzT0uGIvhPzHWG sHRhOfV/yWXK8PquJcVOKxvgLg6PebnCaAQvemF4Ouy0mhwPBR+XeBLgMzuoDhK1Xh3w 1My1XVU9+ywY/al2mDc9D2aZdP6FPjbCY4XgJsuvGCu7d78FAKDwUQ0l9d6ZF+YC/BJJ 4ujisT8k1G6c7UEmbhZX0S1kESkH3DJbPyaS+xWhtR62se9+3EJFor5iYGQ/llxi9SXy pSpA==
MIME-Version: 1.0
X-Received: by 10.43.88.134 with SMTP id ba6mr3753598icc.18.1362939738984; Sun, 10 Mar 2013 11:22:18 -0700 (PDT)
Received: by 10.43.135.202 with HTTP; Sun, 10 Mar 2013 11:22:18 -0700 (PDT)
In-Reply-To: 
References:          <513B5D98.2070601@alvestrand.no> 
Date: Sun, 10 Mar 2013 14:22:18 -0400
Message-ID: 
From: Ted Hardie 
To: Peter Thatcher 
Content-Type: text/plain; charset=ISO-8859-1
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Separating stream manipulation from the SDP loudness (Re: Proposed Plan for Usage of SDP and RTP)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 10 Mar 2013 18:22:20 -0000

On Sun, Mar 10, 2013 at 12:02 AM, Peter Thatcher  wrote:
> There's a difference between the resolution that you open the camera at and
> the resolution you send over the network at.  Does the current constraints
> API let you capture at one resolution and send at another?  Also, does it
> let you change the send resolution on the fly?
>
Just to make sure I understand the use case here, is the idea that you
open the camera at one resolution, potentially using that for a
recording or local display, then send a different resolution to the
peer?  I ask because I'm trying to understand how this control would
map to the connection objects--is there always a mediastream track
consuming the "native" resolution of the camera?

regards,

Ted


> These are important controls that, as far as I know, are not currently
> supplied to the application.  They could potentially be supplied by SDP, new
> methods, or as you suggest, perhaps even as some kind of constraint.  But I
> don't think they are currently provided.
>
> On Mar 9, 2013 7:54 PM, "Harald Alvestrand"  wrote:
>>
>> As usual, I'm trying to use subject line change in order to achieve some
>> separation of concerns...
>>
>> On 03/07/2013 10:22 PM, Silvia Pfeiffer wrote:
>>>
>>> Agreed, but it's also not sufficient. SDP is not "programmer friendly"
>>> enough because it has too many details that are protocol-details only and
>>> it's too hard to see the semantic bits in SDP and ignore the rest.
>>>
>>> For example: the programmer wants to say - I want to get this video
>>> resolution, this audio bitrate & channels, I want to use this camera and
>>> this microphone for this call. Having to manipulate SDP directly for this is
>>> a programmer's nightmare.
>>
>>
>> I think we've been over exactly those pieces, and our current proposed
>> solution is called the Media Stream API and the constraints mechanism - and
>> they have exactly nothing to do with SDP, or even with PeerConnection.
>>
>> I don't think we've got it to be "unproblematic" yet, but also, I don't
>> think SDP, JSON or even the offer-answer model is either the problem or the
>> solution on this set of functionalities.
>>
>> Or did I misunderstand something basic?
>>
>>                Harald
>>
>> _______________________________________________
>> 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 stewe@stewe.org  Sun Mar 10 11:32: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 2610521F88C1 for ; Sun, 10 Mar 2013 11:32:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.648
X-Spam-Level: 
X-Spam-Status: No, score=-3.648 tagged_above=-999 required=5 tests=[AWL=-1.049, 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 dUd5p7Fw+GvO for ; Sun, 10 Mar 2013 11:32:47 -0700 (PDT)
Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0A421F84C9 for ; Sun, 10 Mar 2013 11:32:46 -0700 (PDT)
Received: from mail207-db8-R.bigfish.com (10.174.8.235) by DB8EHSOBE042.bigfish.com (10.174.4.105) with Microsoft SMTP Server id 14.1.225.23; Sun, 10 Mar 2013 18:32:45 +0000
Received: from mail207-db8 (localhost [127.0.0.1])	by mail207-db8-R.bigfish.com (Postfix) with ESMTP id 5D05210013E; Sun, 10 Mar 2013 18:32:45 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT002.namprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: PS0(zz98dI9371I1432Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz8275dh8275bhz2fh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h)
Received-SPF: pass (mail207-db8: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT002.namprd07.prod.outlook.com ; .outlook.com ; 
Received: from mail207-db8 (localhost.localdomain [127.0.0.1]) by mail207-db8 (MessageSwitch) id 1362940363927332_19253; Sun, 10 Mar 2013 18:32:43 +0000 (UTC)
Received: from DB8EHSMHS001.bigfish.com (unknown [10.174.8.235])	by mail207-db8.bigfish.com (Postfix) with ESMTP id CB966180049; Sun, 10 Mar 2013 18:32:43 +0000 (UTC)
Received: from BL2PRD0710HT002.namprd07.prod.outlook.com (157.56.240.133) by DB8EHSMHS001.bigfish.com (10.174.4.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 10 Mar 2013 18:32:43 +0000
Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.49]) by BL2PRD0710HT002.namprd07.prod.outlook.com ([10.255.102.37]) with mapi id 14.16.0275.006; Sun, 10 Mar 2013 18:32:42 +0000
From: Stephan Wenger 
To: Ted Hardie 
Thread-Topic: [rtcweb] VP8 litigation in Germany?
Thread-Index: AQHOHTdlrWoXGfl7J0qzyy7s7WzxBJifPQ8A//+fL4A=
Date: Sun, 10 Mar 2013 18:32:41 +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: [10.255.102.4]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 litigation in Germany?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 10 Mar 2013 18:32:48 -0000

Hi Ted,

On 3.10.2013 11:19 , "Ted Hardie"  wrote:

>On Sat, Mar 9, 2013 at 9:31 PM, Stephan Wenger  wrote:
>> One other data point: Mr. Mueller is correct in that Nokia is not a
>>member
>> of the H.264 pool.  Nor are they members in any other video coding
>>related
>> patent pool that I'm aware of, despite IMO having one of the strongest
>>video
>> coding research teams in the industry (I was part of that myself, a
>>while
>> ago).
>
>Hi Stephan,
>
>So, this seems to me to imply that any Nokia IPR on either H.264 or
>VP8 is not part of any established patent pool and thus is not
>publicly in the "market" of which you have previously spoken.  If that
>is the case, it would seem to be an equally unknown factor for an
>implementer of either.   To put this slightly different, even if Mr.
>Mueller were correct, the additional context seems to result in this
>being null data for our particular working group decision.

No, I don't think that this is correct, for at least two reasons.

First, if we were adopting a tit for tat approach, I could argue that this
lawsuit counterbalances the H.264 related lawsuit(s) (there is only one
critical left AFAIR, which is Motorola/Microsoft) that has created so much
noise here in the past.  You can get sued over H.264 (interlace
frame/field adaptivity for example), but you can equally get sued over VP8
(motion vector coding technology for example, if I remember correctly).

Second, remember that H.264 is a RAND standard and Nokia is undoubtedly
bound to their RAND commitment to the ITU.  Insofar, I very much doubt
that they could get away with charging non-RAND rates or doing other
unpleasant things.  For VP8, as not being a standard under RAND, there is
no such a restricting framework in place, AFAIK.

The second aspect may make little difference to those whose business model
discourages them from paying royalties (which I do not consider a
sustainable business model in this field, however, others have other
opinions including a few folks who know their stuff in this field).
However, the first aspect does.

>
>regards,
>
>Ted Hardie
>



From ted.ietf@gmail.com  Sun Mar 10 11:50: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 3321121F88A2 for ; Sun, 10 Mar 2013 11:50:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.579
X-Spam-Level: 
X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.021,  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 ahKyW9Uo9K7B for ; Sun, 10 Mar 2013 11:50:31 -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 A15A921F866F for ; Sun, 10 Mar 2013 11:50:31 -0700 (PDT)
Received: by mail-ie0-f170.google.com with SMTP id c11so3927691ieb.1 for ; Sun, 10 Mar 2013 11:50:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=epCpRW03nnp53XGp79k33z49UqDMx0LiA1mdVlufE9U=; b=ZeFxWlTqIqDmk9VIokxYh6NVhLq9f0FYjAVWTVjfZXZRVXv6GKjTr187zPrKkAqh+6 gj2cl5dH+OekT+Bfy2E6s2D02H9pK+yDg1uhNPXPtdixxv3O/yk+GUWFiBsVJbu4Bu8Y adF96jf5Vy8mdqA3PK0oyh5vRU9xSYo2s/DIdKaW5a0nIA9/FvAZeOLMNfkIRUWhe0iG Bebabh0ReCt8gLsxTAMAndlJd/rAy7MtPOoUui32e6S/aV85BUv8uSPWZ0+c4EYj/gGA J2q+9Zhodp0qfeKptTGVC/9D1f2FOmRN0WYl0r7gDoiDkXY+3Lhmq7QVONzNVBF7sEDO CVDQ==
MIME-Version: 1.0
X-Received: by 10.50.170.102 with SMTP id al6mr5352177igc.20.1362941431324; Sun, 10 Mar 2013 11:50:31 -0700 (PDT)
Received: by 10.43.135.202 with HTTP; Sun, 10 Mar 2013 11:50:31 -0700 (PDT)
In-Reply-To: 
References:  
Date: Sun, 10 Mar 2013 14:50:31 -0400
Message-ID: 
From: Ted Hardie 
To: Stephan Wenger 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 litigation in Germany?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 10 Mar 2013 18:50:32 -0000

On Sun, Mar 10, 2013 at 2:32 PM, Stephan Wenger  wrote:
>
> First, if we were adopting a tit for tat approach, I could argue that this
> lawsuit counterbalances the H.264 related lawsuit(s) (there is only one
> critical left AFAIR, which is Motorola/Microsoft) that has created so much
> noise here in the past.  You can get sued over H.264 (interlace
> frame/field adaptivity for example), but you can equally get sued over VP8
> (motion vector coding technology for example, if I remember correctly).
>

I think I must be missing the disagreement here--I read your recent
note to say that the existence of patents (in this case, Nokia's)
outside the pool was possible for both H.264 and VP8.  Your response
seems to be "this is true for others as well", which doesn't seem to
change the conclusion.

> Second, remember that H.264 is a RAND standard and Nokia is undoubtedly
> bound to their RAND commitment to the ITU.  Insofar, I very much doubt
> that they could get away with charging non-RAND rates or doing other
> unpleasant things.  For VP8, as not being a standard under RAND, there is
> no such a restricting framework in place, AFAIK.
>

A potential non-RAND response seems to be entirely a supposition; you
could equally suppose that they would make their licenses royalty
free, should they have any applicable to VP8, based on the PR value of
contributing to the existence of a more vibrant ecosystem.

regards,

Ted

From cb.list6@gmail.com  Sun Mar 10 11:57: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 02C5021F859B for ; Sun, 10 Mar 2013 11:57:38 -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=[AWL=0.000, 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 XhgdDyaBJ3gA for ; Sun, 10 Mar 2013 11:57:37 -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 A18BB21F8530 for ; Sun, 10 Mar 2013 11:57:36 -0700 (PDT)
Received: by mail-wg0-f41.google.com with SMTP id ds1so1380185wgb.0 for ; Sun, 10 Mar 2013 11:57:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=q7EF7+kThBSsNLPBDL/yVeL+tInWIjeOMG7trL8N1Og=; b=M228mHQn6oz0UTt/vtcHX1jBH9fc0jyoJbLZJUiWCERMSB1oqr0Z1yGxUI7j1zMs27 7IQBR14HE1rhIdpJ8xm92hPHx1cfCIuW/+Zzb3qNZ7vjFV1w2dO/NMKcDLyt2erhSl2J NfBkf0vHNzp7tNNt8J7CiAW+dRMx6Ufp1sJ+YarWiTtW3iIrwUh1ZLPjTvGmKZ9JTwk7 aCLq3sOWVrH99EunuqAR/3wzJY1Sax7ibCYxPp2/HNBI2Zh8egjUvptrk6lKil7YmWyW UClJG+fMkk2vxNeFdbzykLIlgan/d15a+FGJXj+WJ6Ef1cj8RH3fMluyJMM/O4h9kup2 DFOQ==
MIME-Version: 1.0
X-Received: by 10.194.242.163 with SMTP id wr3mr14819711wjc.35.1362941855781;  Sun, 10 Mar 2013 11:57:35 -0700 (PDT)
Received: by 10.194.20.35 with HTTP; Sun, 10 Mar 2013 11:57:35 -0700 (PDT)
In-Reply-To: 
References: <92D0D52F3A63344CA478CF12DB0648AA26537A69@XMB106BCNC.rim.net> 
Date: Sun, 10 Mar 2013 11:57:35 -0700
Message-ID: 
From: Cameron Byrne 
To: Cullen Jennings 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Request to postpone the question on VP8 as MTI
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 10 Mar 2013 18:57:38 -0000

After seeing this play out over the last few months,  i believe we
need to strongly consider no MTI for video.

It's unfortunate, but i believe the various stakeholder have
irreconcilable difference.  IPR is a dark art and the IETF has no
method for dealing with it beyond running away.  That said, run away.

CB

On Sun, Mar 10, 2013 at 8:52 AM, Cullen Jennings  wrote:
>
> Gaelle,
>
> I think these are good points and other have erased similar points. I nee=
d to discuss it with my co-chairs but I suspect that for the points you rai=
sed, we will need delay this to IETF 86. Again, I need to talk to my co-cha=
irs before we can make a decision on this but I would guess that is the dir=
ection things will need to go.
>
> Cullen (One of the co-chairs)
>
>
> On Mar 10, 2013, at 9:45 AM, Gaelle Martin-Cocher  wrote:
>
>> Dear All,
>>
>> In light of the recent announcements (both MPEG-LA and the VP8 litigatio=
n), I believe that more time is needed to make a proper risk assessment on =
VP8 and an informed decision. On one side the MPEG-LA announcement provides=
 some relief but also confirms that VP8 does not come for free and that con=
cerns were/are justified. This is further confirmed by the second announcem=
ent.
>> It will take more efforts for VP8 supporters (and Google does not need t=
o be alone in that process) to reach the goal of an RF video codec (or a co=
dec with a suitable licensing terms). I think it is understood by now, that=
 this would likely be more prone to success in a standardization body than =
anywhere else . (speaking here as a WebVC proponent that went through that =
process too).
>> It is also apparent that the MPEG-LA/Google agreement raises additional =
questions.
>>
>> Here are the reasons I believe we need more time and should postpone the=
 question on VP8 (I am not saying that this should not be asked at a later =
time):
>> -The license is not yet published (and the meeting starts tomorrow)
>> -Some negotiations are still ongoing (e.g. names of the licensors).
>> -Some questions were/are raised and not answered yet, below are the one =
that matters to me:
>> - Will the patent list be provided?
>> - Who are the licensors  and how that group of licensors relates to the =
initial 12 patent holders identified by MPEG-LA?
>> - Will there be alignment of licenses across WebM, RFC, MPEG, and is tha=
t even feasible with the possible new license terms?
>> - Questions related to clarifications of the different grants inside/out=
side the RFC and their applicability to the RFC itself still need to be ans=
wered (aka: how  section 20: 27 apply to the RFC code itself or to the code=
 provided in MPEG)
>> - Questions related to the status of VP8 as a standard as it was mention=
ed that the RFC will not progress to the standard track still remain
>> - In light of the litigation announcement, was due diligence done by VP8=
 proponents toward patent holders that are not MPEG-LA members?  (e.g. poss=
ibly on a model similar to what was done in WebVC)
>> - More questions will likely be raised once the license is published.
>> -We need to give enough time to Google to finalize its license and provi=
de answers on those above points.
>> -VP8 is not (yet) a standard in IETF nor in MPEG (MPEG only saw an input=
 contribution for the first time in January). It would be desirable that RT=
CWeb points to a standard or that VP8 reaches a certain stage in MPEG so th=
at it can be considered as an MPEG deliverable. VP8 may reach that status a=
t a next MPEG meeting in April or July, I don=92t see how that can be accel=
erated further. We need to give MPEG the time to proceed properly.
>> -legal entities will need time to review both the new license and the an=
swers to the various questions that were asked. This cannot be achieved in =
3 days.
>>
>> Further, I just came across an informational RFC for VP9:
>> -Is VP9 going to =93deprecate=94 VP8?
>> - What is the timeframe for VP9 in IETF?
>> -if VP9 going to be proposed for a next generation of RTCWeb Client? Whi=
ch timeframe?
>> I don=92t think it would be desirable to mandate VP8 today if VP9 is aro=
und the corner and will be proposed for RTCWeb as well.
>> Requesting two codecs to be implemented instead of one in a short timefr=
ame is obviously an issue for implementers that cannot do a simple software=
 upgrade of their products.
>>
>>
>> I hope all of you will find that request reasonable.
>> Sincerely,
>>
>>
>> Ga=EBlle Martin-Cocher
>> Standards Manager
>> Office: (905) 629-4746 x14591
>> BlackBerry: (647) 267-0569
>> PIN: 2835485E
>> 
>> www.rim.com
>>
>> ---------------------------------------------------------------------
>> This transmission (including any attachments) may contain confidential i=
nformation, privileged material (including material protected by the solici=
tor-client or other applicable privileges), or constitute non-public inform=
ation. Any use of this information by anyone other than the intended recipi=
ent is prohibited. If you have received this transmission in error, please =
immediately reply to the sender and delete this information from your syste=
m. Use, dissemination, distribution, or reproduction of this transmission b=
y unintended recipients is not authorized and may be unlawful. ____________=
___________________________________
>> 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 magnus.westerlund@ericsson.com  Sun Mar 10 12:03: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 179E511E80DE for ; Sun, 10 Mar 2013 12:03:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.166
X-Spam-Level: 
X-Spam-Status: No, score=-106.166 tagged_above=-999 required=5 tests=[AWL=0.083, 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 GRybB8i+bEGZ for ; Sun, 10 Mar 2013 12:03:27 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id DBAD511E80E0 for ; Sun, 10 Mar 2013 12:03:25 -0700 (PDT)
X-AuditID: c1b4fb25-b7f366d000004d10-e9-513cd8fc39dc
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id EC.0B.19728.CF8DC315; Sun, 10 Mar 2013 20:03:25 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Sun, 10 Mar 2013 20:03:23 +0100
Message-ID: <513CD8F8.70809@ericsson.com>
Date: Sun, 10 Mar 2013 15:03:20 -0400
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
References: <513CD8D3.2060807@ericsson.com>
In-Reply-To: <513CD8D3.2060807@ericsson.com>
X-Enigmail-Version: 1.5.1
X-Forwarded-Message-Id: <513CD8D3.2060807@ericsson.com>
Content-Type: multipart/mixed; boundary="------------030804050106010009090705"
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSbUhTYRiGed3ZJ01fp9aThoUmq7TUsDKUEYVk/ZpWZBbkoJNKy3Sa+UNw aqmIWNJc8ygmOXPaNDU/JwquRMQhx9XA0RdqoAiz7zJr1s7OIvt3cXM/z/3w3q+AI7FxAwWZ WXmkKkuhDOGJiLoUZ+Fe52x8UtTbMm5sx3o5/whK1Ot/eMlRqij+EqnMzCdVkbI0Ucb4rzVu tiWuoMc6zFcjw4FKJBQAjoE+zQSf5c1Av3nMY1iCJxEMtcsrkcjFrQjuDrz0qkQCgRjvhuV7 mxgPgcNgpt+IGObhWLCvFvMYSwA+BfbmYEYWY1+YrHtHMOyPpfB8jnZH+eF98HvEzmXsEhwO Vm02IwtxBHSVPSPYa7ZC71K557JDUP7gKYexc7AcSt8fY48MB3VJBfcO8qU2hFH/XIzMcWVp bDcRy9thwNHAYfkELGmK+f/rzGgy1NoSKXduGthNdtdG5hVMCBZqLATlTu5GMPO6iOUhBM4V j16LwFh1nhkgcDUBpa39fHbTTqgxUu4jCBwKzs/DPHZrJwKHutpj2gW6NhoxVwD2gQ5zKOXp RfdpnMuyGKY0E+5ZwHoElskxLzbZimB0TsbymGvpegTlKXhl7bYnbAoB/aGRS/1tdVY7j9in C4fFF4/4lKdWi8nBozbUynAAPgO3Gq1ujz+Og+WFXh6blgJ9I028JhTbjvhXFZnK9Bv7e5Dr a471/gwbRK+m/c0oSECEbBGfTaDlEpyuyCOvkGQ2qbqouq4kc83ISyAMVCPtwyi9tXnV9uSC QVoWrKELpIP9Ym+sFzoMxkhZstY/g1bmXytqih6P0aUMfmtOOv5xfk5o/j4aN+Qnm/Ge7+px GLaZLtf7fCmkOxt2UGnhCT45R6fzS3IUI0lBklRaQp7MxW1fHYdt0rrA0/cPVrRoK6bOLepo UlHV0l0fQuRmKKL3cFS5ij8hNW8VaAMAAA==
Subject: [rtcweb] Fwd: Re: [MMUSIC] Grouping 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: Sun, 10 Mar 2013 19:03:28 -0000

--------------030804050106010009090705
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


--------------030804050106010009090705
Content-Type: message/rfc822; name="Re: [MMUSIC] Grouping discussion.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="Re: [MMUSIC] Grouping discussion.eml"

X-Mozilla-Keys: 
Received: from esessmw0237.eemea.ericsson.se (153.88.115.90) by
 ESESSHC010.ericsson.se (153.88.183.48) with Microsoft SMTP Server (TLS) id
 14.2.318.4; Sun, 10 Mar 2013 20:02:54 +0100
Received: from sesbmg10.ericsson.net (153.88.115.8) by
 esessmw0237.eemea.ericsson.se (153.88.115.92) with Microsoft SMTP Server id
 8.3.279.1; Sun, 10 Mar 2013 20:02:54 +0100
Received: from mail.ietf.org (mail.ietf.org [12.22.58.30])	by
 sesbmg10.ericsson.net (Symantec Mail Security) with SMTP id
 08.02.12311.DD8DC315; Sun, 10 Mar 2013 20:02:54 +0100 (CET)
Received: from ietfa.amsl.com (localhost [127.0.0.1])	by ietfa.amsl.com
 (Postfix) with ESMTP id D9BF321F882A;	Sun, 10 Mar 2013 12:02:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1;
	t=1362942172; bh=gL6H6Dj0zaXZ8xCQvizPFLREY8xNmWjyf/hZRfjBFtA=;
	h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc:
	 Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:
	 List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender;
	b=rtyI5uLkRsDwDMNGkah5MF8pyBNNSea+uLBuBK/T8OM38FcP2J1FV6PvznMtQQxe1
	 e/qx5lrPQFF+gk0Wf+Hto9bfx9aa06kgW3QlDGjlXhZOLdzpfPPAmzyNd4sZ7EC+ZI
	 ncpz7SZ7HryXkWls7cHWe4ChKPRRL5gbT4Ztg120=
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])	by ietfa.amsl.com (Postfix)
 with ESMTP id ED76F21F8816	for ; Sun, 10 Mar 2013
 12:02:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.142
X-Spam-Level: 
X-Spam-Status: No, score=-106.142 tagged_above=-999 required=5
	tests=[AWL=0.107, 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 Gs2sC-BPlVcE for
 ;	Sun, 10 Mar 2013 12:02:49 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48])	by
 ietfa.amsl.com (Postfix) with ESMTP id 6135621F8808	for ;
 Sun, 10 Mar 2013 12:02:49 -0700 (PDT)
X-AuditID: c1b4fb3c-b7f836d000003017-d8-513cd8dd88d7
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124])
	by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id
	2E.F3.32353.7D8DC315; Sun, 10 Mar 2013 20:02:48 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se
	(153.88.115.88) with Microsoft SMTP Server id 8.3.279.1;	Sun, 10 Mar 2013
 20:02:47 +0100
Message-ID: <513CD8D3.2060807@ericsson.com>
Date: Sun, 10 Mar 2013 15:02:43 -0400
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:17.0) Gecko/20130215 Thunderbird/17.0.3
To: "DRAGE, Keith (Keith)" 
References: <949EF20990823C4C85C18D59AA11AD8BEDCB@FR712WXCHMBA11.zeu.alcatel-lucent.com>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BEDCB@FR712WXCHMBA11.zeu.alcatel-lucent.com>
X-Enigmail-Version: 1.5.1
X-Brightmail-Tracker: H4sIAAAAAAAAA1VTf0wTZxjmvbZ3B/bwLEJfOyVaNZORMUkw+bJ1xphlLpolssRkP2K0HSft
	BoXcnROTLQFmg9GIsMhoGSAzuMoGc2B1hAUEFDekC4zxo87BIpaIiMhgZgoh2utR3f573jzP
	8z7Pm3wfqzEs0CZWyJMF0WnNMtMxWn3Cq4kvjwYs6ZtvnV1HepsqgRSO+BjS57kCpOlGLrn4
	QCRN3jqK9F79E8iJumodCfxSRJGCQok09pQBuRxoA9J/fpQi9bPnGDI0PEuRqsfp5MsLlQzx
	eoo1ZGTxkoaMPn5Ik6PnLuhIuet1cvX6tGab8a35h4P0bng/xpIhZDk+EcRXtu6PsXtPBelc
	F5vXXlVJ58Pv9DGIZpFPw+n5k0s4AftGz4dwDGvgfwRsHllk1KEc8J/6Wp0yaPliLX7uvcSo
	lg1YWl8BCtby63Fx7qcl+/eAD344o1NFm9Bd1xcSsSG8HBs610fi3LNdS5JY/G3iEaV4ka8F
	9Hd3UOqiAcDa47+COnQAjv89zUSa17TeXCrYA9g3U61TBy9gzx8F4VIcn4x3Br5j1IIb0d9y
	P3wrzRO88aggjOP5Peiq7mdU/Qrs9gS1Cl7Jv4aTt31hjYF/Fy+21oRxNP8eftX1r1ZtsQp9
	E0WMWnxQh9dc4+GLNPyLWFoVoJSj4/gk9LujVf1qHDh9hIp4j50IMiWQXPGf6IqwOwUDZado
	FSfjN1/f09SA5luIlwTJlp2ZujlFEB0fSlKOM8UpyE0QenEdvgVLM9wKpnbCKpYyx3O2AUu6
	IdaWk3HYbpXs+8SDWYLUCS+wWrORa75Zu9vAZ1pl4WNByBXECLuaZc3ITQ6HnCtEIVPIO+DI
	kp/TFBvdCcjqzSu5YUXDSbnWbMmRqfLXYZ3JyN1WCF4h7Aedz7yRP9EPa0xxHERFRRn0odxs
	h/x/fhKMLJjjuDFli97hlJ9tnwwFU6HglO3hYNn6nDLlwwctGS7b3NuHii2f/nyyamzXO748
	26YDb5h20klf3J0zTMWm5jckNXg9Ocs+WrP2cKOp/fjRvcOJb/Y4N/pLyhJ2dG25MzPSWP7Z
	wpB+pkhsGWtrTRsqvfzXE797R1piSYUpeHfw/tZlbd2Hptzz7b1d1imj7HYVTsSv9eTLT8Yh
	qdislezW1Jc0omR9ClP5BP4OBAAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjluLIzCtJLcpLzFFi42KZGfG3RvfGDZtAg6ZuHounjWcZLaYuf8zi
	wOTR+mwvq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDKuPZjMWPCTreJv6xf2BsbLrF2MnBwSAiYS
	C/beZoewxSQu3FvP1sXIxSEkcJJR4v3mB0wQznJGifvbf7KAVPEKaEs8v7IarINFQFXizK63
	bCA2m4CFxM0fjUA2B4eoQLDEzcVyEOWCEidnPgFrFRGwlnj1eAtYCbOAusTVxUEgprCApsSZ
	GZwgFUICERJb9y4AG8gpECkx++h3FojTJCW2vGgHW8osoCcx5WoLI4QtL9G8dTYzRK+2RENT
	B+sERqFZSBbPQtIyC0nLAkbmVYzsuYmZOenl5psYgWF6cMtvgx2Mm+6LHWKU5mBREucNd70Q
	ICSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFRxlu5l6uhapfVaRP+203id899E7zryvSXn5mn
	Qf/T/mPv8u98dpvGdu2TV/Hbf8rJd2f2PRFJPLu66Nu9+0de7Tr1eP/Gkwql0pG7LBr2sjm6
	XJX6sUT6yMvqX0cZXqQ/Dj+39PUUrx8KTpyGT7kmdHOpTHhzj/VJ9uvlWstO8Tt0XNT0WvQq
	S4mlOCPRUIu5qDgRAETi8jUhAgAA
CC: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Grouping discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: 
Errors-To: mmusic-bounces@ietf.org
Return-Path: mmusic-bounces@ietf.org
X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0
X-MS-Exchange-Organization-AuthSource: esessmw0237.eemea.ericsson.se
X-MS-Exchange-Organization-AuthAs: Anonymous
MIME-Version: 1.0

On 2013-03-10 10:30, DRAGE, Keith (Keith) wrote:

> There is also planned to be an ad-hoc discussion of the grouping
> material on Monday in the slot 15:40 to 17:10. If you are interested
> in participating in this discussion please consult with either Bo
> Burman, or one of the AVTEXT chairs, and we'll let you know which
> room, when we find out ourselves.
>=20

This discussion will happen in Boca 8.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
F=E4r=F6gatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

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



--------------030804050106010009090705--

From magnus.westerlund@ericsson.com  Sun Mar 10 12: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 BA9D621F84BE for ; Sun, 10 Mar 2013 12:11:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.174
X-Spam-Level: 
X-Spam-Status: No, score=-106.174 tagged_above=-999 required=5 tests=[AWL=0.075, 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 3Y1rRT38TsHZ for ; Sun, 10 Mar 2013 12:11:22 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B591A21F84BD for ; Sun, 10 Mar 2013 12:11:21 -0700 (PDT)
X-AuditID: c1b4fb25-b7f366d000004d10-a7-513cdad84332
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F6.7B.19728.8DADC315; Sun, 10 Mar 2013 20:11:20 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Sun, 10 Mar 2013 20:11:19 +0100
Message-ID: <513CDAD4.3070704@ericsson.com>
Date: Sun, 10 Mar 2013 15:11:16 -0400
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
References: <513CD8D3.2060807@ericsson.com> <513CD8F8.70809@ericsson.com>
In-Reply-To: <513CD8F8.70809@ericsson.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+Jvje6NWzaBBg9vmFus/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPt3t7EX/OGpaN58kbGB8TZXFyMnh4SAicT6T+/YIWwxiQv3 1rN1MXJxCAmcZJSYv34jE0hCSGA5o8TR93UgNq+AtsSSfxfB4iwCqhK7OiazgNhsAhYSN380 AjVzcIgKBEvcXCwHUS4ocXLmE7ASEQF1icsPL4DtEhawlth8r4MNYrynxJYNu8DinAJaEo9f 7mWEuEdSYsuLdrA4s4CexJSrLYwQtrxE89bZzBC92hINTR2sExgFZyFZNwtJyywkLQsYmVcx sucmZuaklxttYgQG38Etv1V3MN45J3KIUZqDRUmcN9z1QoCQQHpiSWp2ampBalF8UWlOavEh RiYOTqkGRpfriduXFXz8yzy9I6xegPeV15Tby0/0LXi97slR97VFf7kntd1Le3vZ2Odtwb6d Yv3zmjvC5rpsvP2zXMiZ8YF3yByHj5V8x3K+7bQz0frEpZL/z+3kfFHOC9lbxJ3YuWR7FAK5 n5lrei/QaZ1zaNqdJRaaMe9cy1/9Kq/2LQlaNmPufdGjYkosxRmJhlrMRcWJACiK5fsMAgAA
Subject: Re: [rtcweb] Fwd: Re: [MMUSIC] Grouping 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: Sun, 10 Mar 2013 19:11:22 -0000

WG,

To provide a bit more context on this. This a discussion around grouping
of objects in a multi-media session. This span out of the AVTEXT
discussion around draft-westerlund-avtext-rtcp-sdes-srcname-02 in
Atlanta. This resulted in an follow up discussion after the AVTEXT
session. The group of people had some email discussion and some
preparation work was done. This has resulted in two internet drafts and
an UML model. This model will be presented and discussed in this meeting.

The drafts are:
https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping-taxonomy/
https://datatracker.ietf.org/doc/draft-burman-rtcweb-mmusic-media-structure/

If you coming to this meeting please try to prepare by reviewing the
above drafts.

On 2013-03-10 15:03, Magnus Westerlund wrote:
>> > There is also planned to be an ad-hoc discussion of the grouping
>> > material on Monday in the slot 15:40 to 17:10. If you are interested
>> > in participating in this discussion please consult with either Bo
>> > Burman, or one of the AVTEXT chairs, and we'll let you know which
>> > room, when we find out ourselves.
>> > 
> This discussion will happen in Boca 8.


-- 

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 stewe@stewe.org  Sun Mar 10 12: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 8278121F8464 for ; Sun, 10 Mar 2013 12:19:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.017
X-Spam-Level: 
X-Spam-Status: No, score=-4.017 tagged_above=-999 required=5 tests=[AWL=-0.418, 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 LDbvOFw18nFk for ; Sun, 10 Mar 2013 12:19:30 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 5432921F8459 for ; Sun, 10 Mar 2013 12:19:30 -0700 (PDT)
Received: from mail41-am1-R.bigfish.com (10.3.201.240) by AM1EHSOBE016.bigfish.com (10.3.207.138) with Microsoft SMTP Server id 14.1.225.23; Sun, 10 Mar 2013 19:19:29 +0000
Received: from mail41-am1 (localhost [127.0.0.1])	by mail41-am1-R.bigfish.com (Postfix) with ESMTP id 2732B1C01D6; Sun, 10 Mar 2013 19:19:29 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT001.namprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: PS0(zz98dI9371I1432Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz8275dh8275bhz2fh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h)
Received-SPF: pass (mail41-am1: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT001.namprd07.prod.outlook.com ; .outlook.com ; 
Received: from mail41-am1 (localhost.localdomain [127.0.0.1]) by mail41-am1 (MessageSwitch) id 1362943167319302_9465; Sun, 10 Mar 2013 19:19:27 +0000 (UTC)
Received: from AM1EHSMHS011.bigfish.com (unknown [10.3.201.229])	by mail41-am1.bigfish.com (Postfix) with ESMTP id 41BF7E003F; Sun, 10 Mar 2013 19:19:27 +0000 (UTC)
Received: from BL2PRD0710HT001.namprd07.prod.outlook.com (157.56.240.133) by AM1EHSMHS011.bigfish.com (10.3.207.111) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 10 Mar 2013 19:19:27 +0000
Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.49]) by BL2PRD0710HT001.namprd07.prod.outlook.com ([10.255.102.36]) with mapi id 14.16.0275.006; Sun, 10 Mar 2013 19:19:25 +0000
From: Stephan Wenger 
To: Ted Hardie 
Thread-Topic: [rtcweb] VP8 litigation in Germany?
Thread-Index: AQHOHTdlrWoXGfl7J0qzyy7s7WzxBJifPQ8A//+fL4CAAGmagP//o3eA
Date: Sun, 10 Mar 2013 19:19:25 +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: [10.255.102.4]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <413F495FCDBFB54883822EB1C8B4848B@namprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 litigation in Germany?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 10 Mar 2013 19:19:31 -0000

Hi Ted,

On 3.10.2013 11:50 , "Ted Hardie"  wrote:

>On Sun, Mar 10, 2013 at 2:32 PM, Stephan Wenger  wrote:
>>
>> First, if we were adopting a tit for tat approach, I could argue that
>>this
>> lawsuit counterbalances the H.264 related lawsuit(s) (there is only one
>> critical left AFAIR, which is Motorola/Microsoft) that has created so
>>much
>> noise here in the past.  You can get sued over H.264 (interlace
>> frame/field adaptivity for example), but you can equally get sued over
>>VP8
>> (motion vector coding technology for example, if I remember correctly).
>>
>
>I think I must be missing the disagreement here--I read your recent
>note to say that the existence of patents (in this case, Nokia's)
>outside the pool was possible for both H.264 and VP8.  Your response
>seems to be "this is true for others as well", which doesn't seem to
>change the conclusion.

The only thing I tried to say above is that, in the past, folks called it
a plus for VP8 that no one has litigated against a VP8 user, whereas there
were known lawsuits against H.264 users.  That argument is gone.  Both
specs (or, better, patent claims allegedly related to those specs) are
subject to lawsuits.  No change the WG needs to think about?  Come on...

>
>> Second, remember that H.264 is a RAND standard and Nokia is undoubtedly
>> bound to their RAND commitment to the ITU.  Insofar, I very much doubt
>> that they could get away with charging non-RAND rates or doing other
>> unpleasant things.  For VP8, as not being a standard under RAND, there
>>is
>> no such a restricting framework in place, AFAIK.
>>
>
>A potential non-RAND response seems to be entirely a supposition; you
>could equally suppose that they would make their licenses royalty
>free, should they have any applicable to VP8, based on the PR value of
>contributing to the existence of a more vibrant ecosystem.

Risk assessment necessarily deals with probabilities.  How high is the
chance that an aggressive IP enforcer would ask for non RAND terms
(billions in royalty, injunction, whatnot), RAND terms, or give in for
good, when litigation has been initiated and the IP enforcer is not bound
to RAND terms?  Rhetoric question.

You are, of course, absolutely right that potentially a lot of
rightholders are willing to hold still or settle for less money than
possible, so not to damage the ecosystem, relationship with google, and so
on.  The fact that google got a sublicenseable license--almost unheard of
in the pool business and certainly not MPEG-LA's common business
model--speaks for the second and potentially the third point.  However,
remember the context of this email: did the lawsuit in Germany change
anything?  Well, to me, it clearly indicates that "PR value of
contributing to the existence of a more vibrant ecosystem" didn't work all
that well in this case...  and, while I have not read the prayers of the
Nokia complaint, I can easily imagine what they request, and it's not
recognition for contributing to a vibrant ecosystem :-)

Stephan

>
>regards,
>
>Ted
>



From alan.b.johnston@gmail.com  Sun Mar 10 12:32: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 648CC21F88E8 for ; Sun, 10 Mar 2013 12:32:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 rSKdpbhvgysP for ; Sun, 10 Mar 2013 12:32:13 -0700 (PDT)
Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id E43F721F88E6 for ; Sun, 10 Mar 2013 12:32:12 -0700 (PDT)
Received: by mail-we0-f181.google.com with SMTP id t44so2818914wey.40 for ; Sun, 10 Mar 2013 12:32:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=Fo4zjove1jBWR6bDNXnkxktyNoThIaieOxbqvKqay/4=; b=qz+seu6QdrOT5swE0vK7CpuehRUwWIVZ3vDanu4IkVYSWERl33k4iGwL3ZF3o8gyPL NZ5jNy25MtB6lCsxAyTxfTGpIQh/g9dCy90jiMpADM0jH7jMSbMj8m3D198YTZ7iIkTg ak0ucAiwRsU9Nt4enZXEdaIjMdEaNIVH3Ul/t81n0fwBlb1ydVgG2MtXlEgMAMV4ELSh byWWAirsyS6kPHyAVZ5xHOHPlthCqk4TyEXTtdvmRMNIy8FoIdKbO1x9fdgKV8tOs1vE KiK9GbHSdaOo+/TmKB7TrMxOw0ga4yQ0VHaw1Nzx0x4ihw54Kp8YjelSQTTuIF6zn63p SSGQ==
MIME-Version: 1.0
X-Received: by 10.180.8.4 with SMTP id n4mr8476571wia.13.1362943932115; Sun, 10 Mar 2013 12:32:12 -0700 (PDT)
Received: by 10.216.151.67 with HTTP; Sun, 10 Mar 2013 12:32:11 -0700 (PDT)
Date: Sun, 10 Mar 2013 14:32:11 -0500
Message-ID: 
From: Alan Johnston 
To: rtcweb@ietf.org
Content-Type: multipart/alternative; boundary=f46d04428f18ec31ba04d7971c55
Subject: [rtcweb] Review of draft-ietf-rtcweb-security-arch-06
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 10 Mar 2013 19:32:14 -0000

--f46d04428f18ec31ba04d7971c55
Content-Type: text/plain; charset=ISO-8859-1

Here is my review of draft-ietf-rtcweb-security-arch-06.

The document has some open issues and clarifications needed, as well as
some editorial and perhaps structural changes.

See below for the details.

- Alan -


Again, lots of RTCWEB, RTCWeb, etc that should be WebRTC.

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).

"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.

"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?

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.

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.

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.

Figure 4 is the Trapezoid of the overview and should be referenced as such.

JS is used but not defined.

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.

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?

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'?

There are many cases of using [] instead of () for parentheical text.

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

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?

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?

5.2 The API and UI requirements and elsewhere - should these be in a W3C
document instead of/in addition to this document?

5.2 "Implementations which support some form of direct user authentication
   SHOULD also provide a policy by which a user can authorize calls only
   to specific counterparties."  What is a counterparty?

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?

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?

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.

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.

5.6.4.2  Is this document defining a new SDP attribute?  Shouldn't this be
done in MMUSIC?

typos "implemementations"  "termnating" "restrcitions"

WebIntents mentioned without reference or explanation.

Missing normative reference: RFC 3711.

--f46d04428f18ec31ba04d7971c55
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Here is my review of draft-ietf-rtcweb-security-arch-06.

The document has some open issues and clarifications needed, as well as so=
me editorial and perhaps structural changes.

See b=
elow for the details.



- Alan -


A=
gain, lots of RTCWEB, RTCWeb, etc that should be WebRTC.

The document introduction seems to be specific to audio and video We=
bRTC sessions. =A0Later, it becomes clear that the analysis applies to the =
data channel as well. =A0This should be stated clearly up front and any dif=
ferences between the two should be explained (i.e. DTLS vs SRTP encryption)=
.



"SIP or XMPP" - XMPP isn't a signaling pr=
otocol but Jingle is, so that is probably what should be mentioned, but Jin=
gle doesn't use SDP.

"Web sites whose ori=
gin we can verify (optimally via HTTPS, but in some cases because we are on=
 a topologically restricted network, such as behind a firewall)" =A0- =
what is the 2nd case - no verification? =A0Verification using something oth=
er than HTTPS?



3.1 =A0middle para graph is basically saying that secur=
ity policy can be applied after authentication - might be worth stating thi=
s after the Dr. Evil analogy.

4. "Specificall=
y, Alice and Bob have relationships with


=A0 =A0some Identity Provider (IdP) that supports a protocol such as O=
penID
=A0 =A0or BrowserID) that can be used to demonstrate their =
identity to other
=A0 =A0parties." - needs one more ( to par=
se correctly.



Figures 3 & 4. =A0Would be better to have IdP1 and =
IdP2 to make clear that this can be 2 different providers. Also, Secure Web=
Sockets should be shown with HTTPS. =A0=A0

In Figu=
res 3 & 4, media is shown as DTLS-SRTP when the media is in fact SRTP w=
hich is keyed with DTLS-SRTP. =A0In fact, RFC 3711 is not even referenced, =
when it should be a normative reference, which is potentially very confusin=
g and misleading for implementors. =A0There are many places where DTLS-SRTP=
 described as if it is more than a key agreement protocol for SRTP.



Figure 4 is the Trapezoid of the overview and should be=
 referenced as such.

JS is used but not defined. =
=A0

4.1 =A0The first example in this document of m=
icrophone and webcam permissions is that of a permanent grant. =A0Is this t=
he model we want to encourage? =A0Shouldn't the first mention be of the=
 much safer per call grant? =A0Later the per call grant is mentioned, but d=
eep in the document.



4.1 "This message is sent to the signaling server,=
 e.g., by XMLHttpRequest[XmlHttpRequest] or by WebSockets [RFC6455] " =
=A0Sentence is missing a period. =A0Do we really mean HTTPS and Secure WebS=
ockets here?



4.1 "This allows the browser to display a trusted =
element in the browser chrome indicating that a call is coming in from Alic=
e." =A0Can this assertion be made now, prior to the DTLS-SRTP handshak=
e completing? =A0If this identity assertion is made at this stage, then a d=
ifferent fingerprint shows up in the DTLS-SRTP handshake, does the browser =
chrome then indicate 'sorry, I made a mistake, it isn't Alice calli=
ng'?



There are many cases of using [] instead of () for pare=
ntheical text.

4.2 ICE is not defined or reference=
d in its first occurance.

typo "theor"


5.1 "[[ 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 manufacturers have traditiona=
lly been permissive here


=A0 =A0here.]] "=A0

=A0 =A0[[ OPEN ISSUE=
:: =A0Should we be more aggressive about this?]]

D=
o these issues need to be discussed in a W3C document where browser experti=
se might help us do the right thing?



5.2 =A0Do we really expect browsers to have X.509 certi=
ficates? =A0Does anyone do this with DTLS-SRTP today? =A0Do browsers have U=
I to manage these certs?

5.2 The API and UI requir=
ements and elsewhere - should these be in a W3C document instead of/in addi=
tion to this document?



5.2 "Implementations which support some form of di=
rect user authentication
=A0 =A0SHOULD also provide a policy by w=
hich a user can authorize calls only
=A0 =A0to specific counterpa=
rties." =A0What is a counterparty?



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=A0draft-rescorla-mmusic-ice-lite?



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

5.5 =A0Again, the media channel is secured=
 using SRTP, not DTLS-SRTP, which is one way to key SRTP. =A0In the future,=
 new and better key agreements will be developed, and if we write all our s=
pecs assuming one particular keying method, then they will become obsolete.=




Section 5.6 with Appendix A reads like a completely sep=
arate document. =A0It is also very hard reading as there are lots of new co=
ncepts and ideas. =A0Should perhaps this be in a separate document? =A0The =
basic security architecture for WebRTC is unlikely to change, but given tha=
t 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 separat=
e document.



5.6.4.2 =A0Is this document defining a new SDP attribut=
e? =A0Shouldn't this be done in MMUSIC?

typos =
"implemementations" =A0"termnating" "restrcitions&=
quot;=A0



WebIntents mentioned without reference or explanation.<=
/div>

Missing normative reference: RFC 3711.
<=
br>










=





=







--f46d04428f18ec31ba04d7971c55--

From martin.thomson@gmail.com  Sun Mar 10 12:39: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 C790E21F85A2 for ; Sun, 10 Mar 2013 12:39:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.079
X-Spam-Level: 
X-Spam-Status: No, score=-4.079 tagged_above=-999 required=5 tests=[AWL=-0.481, 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 8h6wPw4QHhIU for ; Sun, 10 Mar 2013 12:39:48 -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 0778821F858A for ; Sun, 10 Mar 2013 12:39:47 -0700 (PDT)
Received: by mail-wg0-f54.google.com with SMTP id fm10so4392110wgb.9 for ; Sun, 10 Mar 2013 12:39:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=HjBxmUJafQqZjU7e09YAntDlqzftQwUDpE8ygMNC/As=; b=LTE9ra9MbP6uTteOCaqZxByyXAmxUGBar8by7Pv0Q2ZUGcucEp85FKE33pay2O14ms kX2OTlCRBTfTacTWiauUOD9Wx+e0o0mJp36hg+v3ufhwPa4xZGmdaROXhVJHHpV2c4Wa 8XHX2Tvkgh3eK8NJuhFAmVzWKJe0auL7biEw6vy4e590E46vc2ZiQC72i08S+hVzJQMp DXhQZjQn+KQDPN9dA2e3Tj8KATXHl0zk6Q5RIY4SBcezJ38bG+8lNSqZi5r+0Sjgx/5R FQS9w9QoknhYGxWurXbFZegjyfVPkFqvmIeuA/JrjTnMo+bWgAVMgQBfyl/RZypG9Zp+ /iIw==
MIME-Version: 1.0
X-Received: by 10.180.76.84 with SMTP id i20mr8681821wiw.9.1362944387212; Sun, 10 Mar 2013 12:39:47 -0700 (PDT)
Received: by 10.194.5.135 with HTTP; Sun, 10 Mar 2013 12:39:47 -0700 (PDT)
In-Reply-To: 
References:          <513B5D98.2070601@alvestrand.no>  
Date: Sun, 10 Mar 2013 15:39:47 -0400
Message-ID: 
From: Martin Thomson 
To: Ted Hardie 
Content-Type: multipart/alternative; boundary=f46d0434c0aa0c6afe04d7973889
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Separating stream manipulation from the SDP loudness (Re: Proposed Plan for Usage of SDP and RTP)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 10 Mar 2013 19:39:48 -0000

--f46d0434c0aa0c6afe04d7973889
Content-Type: text/plain; charset=UTF-8

On 10 March 2013 14:22, Ted Hardie  wrote:

> On Sun, Mar 10, 2013 at 12:02 AM, Peter Thatcher 
> wrote:
> > There's a difference between the resolution that you open the camera at
> and
> > the resolution you send over the network at.  Does the current
> constraints
> > API let you capture at one resolution and send at another?  Also, does it
> > let you change the send resolution on the fly?
> >
> Just to make sure I understand the use case here, is the idea that you
> open the camera at one resolution, potentially using that for a
> recording or local display, then send a different resolution to the
> peer?  I ask because I'm trying to understand how this control would
> map to the connection objects--is there always a mediastream track
> consuming the "native" resolution of the camera?
>

The W3C media capture task force has discussed this at some length.  I
suggest that you both consult their archives.  It's all there.

This specific example has been discussed and incorporated into the models.
Unfortunately, the work to incorporate what we agreed to in Boston
regarding this model is not yet complete.

--f46d0434c0aa0c6afe04d7973889
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On 1=
0 March 2013 14:22, Ted Hardie <ted.ietf@gmail.com> wrote:<=
br>


On Sun, Mar 10, 2013 at 12:02 AM, Peter Thatcher <pthatcher@google.com> wrote:

> There's a difference between the resolution that you open the came=
ra at and

> the resolution you send over the network at. =C2=A0Does the current co=
nstraints

> API let you capture at one resolution and send at another? =C2=A0Also,=
 does it

> let you change the send resolution on the fly?

>


Just to make sure I understand the use case here, is the idea that yo=
u

open the camera at one resolution, potentially using that for a

recording or local display, then send a different resolution to the

peer? =C2=A0I ask because I'm trying to understand how this control wou=
ld

map to the connection objects--is there always a mediastream track

consuming the "native" resolution of the camera?
=

=C2=A0
The W3C media capture task force has discussed this at som=
e length.=C2=A0 I suggest that you both consult their archives.=C2=A0 It=
9;s all there.


This specific example has been discuss=
ed and incorporated into the models.=C2=A0 Unfortunately, the work to incor=
porate what we agreed to in Boston regarding this model is not yet complete=
.




--f46d0434c0aa0c6afe04d7973889--

From rhglidden@gmail.com  Sun Mar 10 13:11: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 6613B21F8984 for ; Sun, 10 Mar 2013 13:11:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.91
X-Spam-Level: 
X-Spam-Status: No, score=-4.91 tagged_above=-999 required=5 tests=[AWL=0.688,  BAYES_00=-2.599, GB_I_LETTER=-2, 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 WirLTTN-ANjB for ; Sun, 10 Mar 2013 13:11:49 -0700 (PDT)
Received: from mail-ye0-f169.google.com (mail-ye0-f169.google.com [209.85.213.169]) by ietfa.amsl.com (Postfix) with ESMTP id D25B821F8758 for ; Sun, 10 Mar 2013 13:11:48 -0700 (PDT)
Received: by mail-ye0-f169.google.com with SMTP id r10so523035yen.0 for ; Sun, 10 Mar 2013 13:11:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type; bh=7fVLyV7W9YgrdMuKuInyAL84/W/ILEqK17xSMI3SfOE=; b=tvK4IEligTMeeaYt7pucWT//bNFCJfME7q41cBHHAXepc9MiVfZ/TilRdkwvWP/nP6 16jCJtx8HJ1RmCzKNO8f2DM5zXfh8C4PSMt3A8d3Tc3kOscryZvcsFWF9rttKe2vAbw6 zQch1gIYOuceyilSZaz3cT5gbv2+qaXOs+LllV9QGVQ6eJnjL38D7iXqpjmX+FBbGod5 ua78dnY/UZqgmqk1uBJoD6+J7EHIxcuwq+uucVxs0XEoW+QgrJA2aRtBx4N796FjFxXP FR5Q3Od0Yaes+tkbuiDll3KvUmd3hDCFLDxNQdJRbWnaD+NTNmhfcqd8lhpMDpy2W8zQ M3iQ==
X-Received: by 10.236.139.113 with SMTP id b77mr7131818yhj.130.1362946308165;  Sun, 10 Mar 2013 13:11:48 -0700 (PDT)
Received: from [10.0.0.10] (99-25-33-39.lightspeed.sntcca.sbcglobal.net. [99.25.33.39]) by mx.google.com with ESMTPS id u3sm20075916yhd.14.2013.03.10.13.11.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Mar 2013 13:11:46 -0700 (PDT)
Message-ID: <513CE8FC.6080401@gmail.com>
Date: Sun, 10 Mar 2013 13:11:40 -0700
From: Rob Glidden 
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Stephan Wenger 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000309040903020503030700"
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 IPR agreement announced.
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 10 Mar 2013 20:11:50 -0000

This is a multi-part message in MIME format.
--------------000309040903020503030700
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Stephan:

I'm sure you are aware this is straight from the official ISO web site 
where you are listed as the liaison from IETF.

Perhaps I confused you by paraphrasing the term "shall" as "must".  I 
think they mean the same thing here, the former just seems oddly formal 
to use in an email.

Rob

On 3/9/2013 3:07 PM, Stephan Wenger wrote:
> Hi Rob,
> Please see inline.
> Stephan
>
> From: Rob Glidden >
> Date: Saturday, 9 March, 2013 12:21
> To: Harald Alvestrand >
> Cc: "rtcweb@ietf.org "  >
> Subject: Re: [rtcweb] VP8 IPR agreement announced.
>
>     Interesting.  Potential licensees will be aided by the provision
>     of a clear list of the portfolio patents, said the 1997 US
>     Department of Justice review letter of MPEG LA.
>
>
> AFAIK, neither a patent list nor a list of potential pool licensors 
> were ever published.  What is known is that there were originally 12 
> parties which each submitted at least one patent (which was found 
> essential) into a possible future pool, and 11 parties (which may or 
> may not be related to the original 12 parties) decided, apparently 
> with MPEG-LA's help, to furnish a sublicenseable license to google 
> (but not to the world).  So we have a closed group of 11 licensors, 
> and a single licensee, who came to an agreement using a facilitator 
> which also happens to administers pools.  To what extent that 
> transaction qualifies as a pooling arrangement from an antitrust law 
> viewpoint surely has been looked at carefully by the parties in 
> question.  Apparently, they came to the conclusion that they do not 
> need to name the licensors, nor the patents in question. 
>  Otherwise, I guess we would know by now.
>
>
>     ISO/MPEG IPR rules are clear that proposers must ask for, and
>     rights holders must provide, patent statements for a proposal to
>     proceed.
>
>
> Huh?  Is that something special for this MPEG subgroup?  If yes, would 
> there be a doc you can share explaining such procedures?
> My understanding is that ISO/IEC patent matters are generally dealt 
> with under the joint ITU/ISO/IEC patent policy, which requires in 
> practice declarations with RAND terms towards the end of the process 
> (before final approval of the standard, but after it is clear that the 
> patent claim reads on the future standard).  Chairs are also under the 
> obligation to request disclosure during each meeting, but (AFAIK) 
> there are almost never replies to these calls.  When participating in 
> a meeting, I usually to not reply, because I'm not quite sure that a 
> patent claim reads on the final standard before that standard is 
> reasonable frozen.
>
> I know that the video coding joint teams (JVT, JCT-VC, JCT-3V) have 
> additionally adopted a policy requiring in practice some form of RAND 
> language in each contribution.
>
> As some here know, I do not participate in this MPEG effort, 
> so I really don't know.
>
>
>
>     Rob
>
>     On 3/9/2013 2:08 AM, Harald Alvestrand wrote:
>>     On 03/08/2013 09:14 PM, Stephan Wenger wrote:
>>>     Hi Serge,
>>>
>>>     This is a great development for VP8.  Congratulations.  I'm sure
>>>     it took a few cycles and dollars to get something like this
>>>     arranged.  I wish your PR would have come out a bit earlier, but
>>>     licensing discussions do take time…  So better now than never.
>>>
>>>     I want to ask two more pieces of information that would allow me
>>>     to put this announcement into context.
>>>
>>>     First, who are those 11 rightholders?  I'm sure you agree that,
>>>     in order to make a meaningful risk assessment, that information
>>>     is needed.
>>
>>     Stephan, at the moment, we have no agreement with the
>>     rightsholders that permits us to disclose their names. We're
>>     discussing that topic with them, but we will not name them
>>     without an agreement to do so.
>>
>>     Of course, the rightsholders are free to disclose themselves.
>>>
>>>     Second, the link provided to "preview" the possible sublicensing
>>>     terms (http://www.w3.org/2001/07/SVG10-IPR-statements) lists a
>>>     bunch of company statements that vary widely among the
>>>     rightholders listed there, which do not include google.  It
>>>     would be great if you could provide more specific information as
>>>     early as possible, especially with respect to the essential
>>>     claims definition and the reciprocity conditions.  That does not
>>>     have to be final legal text, but should be a clear indication of
>>>     your business intentions.  To me, term-sheet level is OK.
>>
>>     That link was a bit weird - the real W3C definition of
>>     "royalty-free" is
>>     http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Requirements
>>     - I think the intent of the link was that if you don't find any
>>     of the RF terms listed on that page objectionable, you'll not
>>     find the Google RF terms objectionable either.
>>
>>
>>     _______________________________________________
>>     rtcweb mailing list
>>     rtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb
>


--------------000309040903020503030700
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Stephan:

      

      I'm sure you are aware this is straight from the official ISO web
      site where you are listed as the liaison from IETF.

      

      Perhaps I confused you by paraphrasing the term "shall" as
      "must".  I think they mean the same thing here, the former just
      seems oddly formal to use in an email.

      

      Rob

      

      On 3/9/2013 3:07 PM, Stephan Wenger wrote:

    

    

      
      
Hi Rob,

      
Please see inline.  

      
Stephan

      

        

      

      
        

          From: Rob Glidden <rhglidden@gmail.com>

          Date: Saturday, 9
          March, 2013 12:21 

          To: Harald Alvestrand
          <harald@alvestrand.no>

          Cc: "rtcweb@ietf.org"
          <rtcweb@ietf.org>

          Subject: Re: [rtcweb]
          VP8 IPR agreement announced.

        

        


        

        

          

            

              
Interesting.  Potential
                licensees will be aided by the provision of a clear list
                of the portfolio patents, said the 1997 US Department of
                Justice review letter of MPEG LA.

              

            

          

        

      
      

        

      

      
AFAIK,
              neither a patent list nor a list of potential pool
              licensors were ever published.  What is known is that
              there were originally 12 parties which each submitted at
              least one patent (which was found essential) into a
              possible future pool, and 11 parties (which may or may not
              be related to the original 12 parties) decided, apparently
              with MPEG-LA's help, to furnish a sublicenseable license
              to google (but not to the world).  So we have a closed
              group of 11 licensors, and a single licensee, who came to
              an agreement using a facilitator which also happens to administers pools.  To what extent that
              transaction qualifies as a pooling arrangement from an
              antitrust law viewpoint surely has been looked at
              carefully by the parties in question.  Apparently, they
              came to the conclusion that they do not need to name the
              licensors, nor the patents in question.
               Otherwise, I guess we would know by now. 

      
        

          

            

              


                ISO/MPEG IPR rules are clear that proposers must ask
                for, and rights holders must provide, patent statements
                for a proposal to proceed.
              

            

          

        

      
      


        

      
Huh?  Is that something special for this MPEG
          subgroup?  If yes, would there be a doc you can share
          explaining such procedures? 

      
 

      
My understanding is that ISO/IEC
            patent matters are generally dealt with under the joint
            ITU/ISO/IEC patent policy, which requires in practice
            declarations with RAND terms towards the end of the process
            (before final approval of the standard, but after it is
            clear that the patent claim reads on the future standard).
             Chairs are also under the obligation to request disclosure
            during each meeting, but (AFAIK) there are almost never
            replies to these calls.  When participating in a meeting, I
            usually to not reply, because I'm not quite sure that a
            patent claim reads on the final standard before that
            standard is reasonable frozen.  

      


          

      
I know that the video coding joint
            teams (JVT, JCT-VC, JCT-3V) have additionally adopted a
            policy requiring in practice some form of RAND language in
            each contribution.
           

      

        

      

      
As some here
          know, I do not participate in this MPEG effort, so I really
          don't know.

      
        

          

            

              


                

                Rob

                

                On 3/9/2013 2:08 AM, Harald Alvestrand wrote:

              

              

                
On 03/08/2013 09:14 PM,
                  Stephan Wenger wrote:

                

                

                  
Hi Serge,

                  


                  

                  
This is a great development for VP8.
                     Congratulations.  I'm sure it took a few cycles and
                    dollars to get something like this arranged.  I wish
                    your PR would have come out a bit earlier, but
                    licensing discussions do take time…  So better now
                    than never.

                  


                  

                  
I want to ask two more pieces of information that
                    would allow me to put this announcement into
                    context.

                  


                  

                  
First, who are those 11 rightholders?  I'm sure
                    you agree that, in order to make a meaningful risk
                    assessment, that information is needed.

                

                

                Stephan, at the moment, we have no agreement with the
                rightsholders that permits us to disclose their names.
                We're discussing that topic with them, but we will not
                name them without an agreement to do so.

                

                Of course, the rightsholders are free to disclose
                themselves.

                

                  


                  

                  
Second, the link provided to "preview" the
                    possible sublicensing terms (http://www.w3.org/2001/07/SVG10-IPR-statements)
                    lists a bunch of company statements that vary widely
                    among the rightholders listed there, which do not
                    include google.  It would be great if you could
                    provide more specific information as early as
                    possible, especially with respect to the essential
                    claims definition and the reciprocity conditions.
                     That does not have to be final legal text, but
                    should be a clear indication of your business
                    intentions.  To me, term-sheet level is OK.
                    

                  

                

                

                That link was a bit weird - the real W3C definition of
                "royalty-free" is http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Requirements
                - I think the intent of the link was that if you don't
                find any of the RF terms listed on that page
                objectionable, you'll not find the Google RF terms
                objectionable either.

                

                

                

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

              

              

            

          

        

      
    

    

  


--------------000309040903020503030700--

From csp@csperkins.org  Sun Mar 10 13:47: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 6AF871F041A for ; Sun, 10 Mar 2013 13:47:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 uwmJavsmSY7B for ; Sun, 10 Mar 2013 13:47:23 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE4E21F865D for ; Sun, 10 Mar 2013 13:47:23 -0700 (PDT)
Received: from [130.209.254.15] (port=51430 helo=vpn15.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UEn9M-00055k-H9 for rtcweb@ietf.org; Sun, 10 Mar 2013 20:47:22 +0000
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1283)
From: Colin Perkins 
In-Reply-To: <20130225211410.2172.19161.idtracker@ietfa.amsl.com>
Date: Sun, 10 Mar 2013 16:47:17 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <40F0DAC8-ECA3-46B0-B2C8-9305A5B21CEE@csperkins.org>
References: <20130225211410.2172.19161.idtracker@ietfa.amsl.com>
To: rtcweb@ietf.org
X-Mailer: Apple Mail (2.1283)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold =  On = 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-06.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: Sun, 10 Mar 2013 20:47:24 -0000

On 25 Feb 2013, at 16:14, 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-06.txt
> 	Pages           : 62
> 	Date            : 2013-02-25
>=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-06


This is a minor updates. The changes are:

- Expand and clarify discussion of RTP session multiplexing in Section =
4.4

- Add Section 7.2 on RTCP extensions for congestion control

- Clarify Section 12.1 on RTP Sessions and PeerConnections

- Expand Section 12.4 on SSRC collision detections

- Rewrite and clarify Section 12.5 on Contributing Sources and the CSRC =
list

- Rewrite and clarify Section 12.9 on differentiated treatment of flows

- Expand security considerations

There's time on the agenda to discuss use of RTCP XR metrics, which is =
one of the open issues with this draft. If there are any more general =
comments, please send them by email.

--=20
Colin Perkins
http://csperkins.org/




From silviapfeiffer1@gmail.com  Sun Mar 10 14:10: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 38CBF21F88A1 for ; Sun, 10 Mar 2013 14:10:54 -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=[AWL=-0.000, 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 PjtLdC-H9QnX for ; Sun, 10 Mar 2013 14:10:53 -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 1409421F87E4 for ; Sun, 10 Mar 2013 14:10:52 -0700 (PDT)
Received: by mail-lb0-f171.google.com with SMTP id gg13so2599007lbb.2 for ; Sun, 10 Mar 2013 14:10:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=w3zpRnXBJWi2tL3DgiRdUHKNGKWTeUdQB1fTA8RSLnQ=; b=vhHoIykxYX5FxZk1AHYQbv8/XCc0x1xWpER784NT+b8vaENx+vU7sLzlFlUWv2FuT8 hk4SU4He8QgHZ3spA4OKx9pJplJyf8S2QEGTjI/n4dhaBmZcydcULMfG+8uUhFVMl/0k Q+vnhRHi9vFjymw+spHAivLNnfxO1tA5TS6zr/cjU0M3NPONRnUxCzS2VKV536c5a/Yt R9GkHqqNSxk3KwpLwpjj7BDWcfDiHCurTSuDiKHZuVK13KWnrnEhRKYPZ6+w9rNe8sDQ sW4fXPepT+vnMxGNXa7ak8rD7AtXEwOWlr4swckv0RVnk7LBywT7koVT77Tiv4OXm/xt Lnag==
X-Received: by 10.112.83.133 with SMTP id q5mr3710485lby.25.1362949852013; Sun, 10 Mar 2013 14:10:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.51.229 with HTTP; Sun, 10 Mar 2013 14:10:31 -0700 (PDT)
In-Reply-To: <513B5D98.2070601@alvestrand.no>
References:          <513B5D98.2070601@alvestrand.no>
From: Silvia Pfeiffer 
Date: Mon, 11 Mar 2013 08:10:31 +1100
Message-ID: 
To: Harald Alvestrand 
Content-Type: multipart/alternative; boundary=f46d04016c2dc6afc204d7987dfd
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Separating stream manipulation from the SDP loudness (Re: Proposed Plan for Usage of SDP and RTP)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 10 Mar 2013 21:10:54 -0000

--f46d04016c2dc6afc204d7987dfd
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Mar 10, 2013 at 3:04 AM, Harald Alvestrand wrote:

> As usual, I'm trying to use subject line change in order to achieve some
> separation of concerns...
>
> On 03/07/2013 10:22 PM, Silvia Pfeiffer wrote:
>
>> Agreed, but it's also not sufficient. SDP is not "programmer friendly"
>> enough because it has too many details that are protocol-details only and
>> it's too hard to see the semantic bits in SDP and ignore the rest.
>>
>> For example: the programmer wants to say - I want to get this video
>> resolution, this audio bitrate & channels, I want to use this camera and
>> this microphone for this call. Having to manipulate SDP directly for this
>> is a programmer's nightmare.
>>
>
> I think we've been over exactly those pieces, and our current proposed
> solution is called the Media Stream API and the constraints mechanism - and
> they have exactly nothing to do with SDP, or even with PeerConnection.
>
> I don't think we've got it to be "unproblematic" yet, but also, I don't
> think SDP, JSON or even the offer-answer model is either the problem or the
> solution on this set of functionalities.
>

TBH I just hadn't seen
https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v6.html.
Is it implemented anywhere yet?

Now that I've looked at it, I wonder how that interacts with the SDP
created through createOffer(). If indeed the JS programmer never has to
touch the SDP, I don't see a need to expose it in the API at all, i.e.
setLocalDescription() should not be necessary.

Silvia.

--f46d04016c2dc6afc204d7987dfd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sun, Mar 10, 2013 at 3:04 AM, Harald Alvestrand <harald@alvestrand.n=
o> wrote:


As usual, I'm trying to use subject line change in order to achieve som=
e separation of concerns...



On 03/07/2013 10:22 PM, Silvia Pfeiffer wrote:



Agreed, but it's also not sufficient. SDP is not "programmer frien=
dly" enough because it has too many details that are protocol-details =
only and it's too hard to see the semantic bits in SDP and ignore the r=
est.





For example: the programmer wants to say - I want to get this video resolut=
ion, this audio bitrate & channels, I want to use this camera and this =
microphone for this call. Having to manipulate SDP directly for this is a p=
rogrammer's nightmare.







I think we've been over exactly those pieces, and our current proposed =
solution is called the Media Stream API and the constraints mechanism - and=
 they have exactly nothing to do with SDP, or even with PeerConnection.





I don't think we've got it to be "unproblematic" yet, but=
 also, I don't think SDP, JSON or even the offer-answer model is either=
 the problem or the solution on this set of functionalities.




TBH I just hadn't seen ht=
tps://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/Settin=
gsAPI_proposal_v6.html . Is it implemented anywhere yet?



Now that I've looked at it, I wonder how that interacts with the SD=
P created through createOffer(). If indeed the JS programmer never has to t=
ouch the SDP, I don't see a need to expose it in the API at all, i.e. s=
etLocalDescription() should not be necessary.


=A0
Silvia.



--f46d04016c2dc6afc204d7987dfd--

From suhasietf@gmail.com  Sun Mar 10 15:59: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 4333521F8706 for ; Sun, 10 Mar 2013 15:59: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, 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 lVpmb+ZxN5oR for ; Sun, 10 Mar 2013 15:59:08 -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 2CDF121F86FB for ; Sun, 10 Mar 2013 15:59:08 -0700 (PDT)
Received: by mail-wi0-f170.google.com with SMTP id hm11so658971wib.5 for ; Sun, 10 Mar 2013 15:59:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hLiO1aZ3pXzf87AjKHYO4DuI8xeEqhSle6dRF4Myx7o=; b=CKlfALNSUJOeyPCTTAUCmBBIsdNlxznbP/pJqPBRUfbbRLV3wj3hOrQj1QOn+VMMwp MhMvoIaeH8bkJnE1ZwPFEznHg92sqaFCfDIKEUaPxrbeuRDFq24UC694EImbbU7/rPm/ zjzJzB3G759GHJCxRFTxnZgf8iQvtmxgETFSNzBvVponePdMC/69/c2+KcaTxe6Eo96q Ag4SQI1QQQJXmuFDCRFpF1M5Vi1FjJLlay4DP+ZkMW+0rdlIBFNgW/ZnZRIwsU9dQ7sX Y3dNEWnQ1wGL/yiccYiR1P8puBS8I3jISoNBZ4u/0h/8TIHMtpxd1hH56GU6PJRoD/+x m6DA==
MIME-Version: 1.0
X-Received: by 10.180.98.232 with SMTP id el8mr9089802wib.22.1362956347347; Sun, 10 Mar 2013 15:59:07 -0700 (PDT)
Received: by 10.194.44.99 with HTTP; Sun, 10 Mar 2013 15:59:07 -0700 (PDT)
In-Reply-To: 
References:          <513B5D98.2070601@alvestrand.no> 
Date: Sun, 10 Mar 2013 15:59:07 -0700
Message-ID: 
From: Suhas Nandakumar 
To: Silvia Pfeiffer 
Content-Type: multipart/alternative; boundary=f46d0442885eed9c9d04d79a00fb
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Separating stream manipulation from the SDP loudness (Re: Proposed Plan for Usage of SDP and RTP)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 10 Mar 2013 22:59:09 -0000

--f46d0442885eed9c9d04d79a00fb
Content-Type: text/plain; charset=ISO-8859-1

I agree .,. JS developer need not have to touch SDP unless it is required ,
which I feel might be needed for few special scenarios.
Constraints, Medie Stream Apis, media capture Apis and Peer Connection Apis
should be able to support majority of use cases without JS developer
needing to manipulate SDP directly.

2 cents

Cheers
Suhas

On Sunday, March 10, 2013, Silvia Pfeiffer wrote:

> On Sun, Mar 10, 2013 at 3:04 AM, Harald Alvestrand 
> > wrote:
>
>> As usual, I'm trying to use subject line change in order to achieve some
>> separation of concerns...
>>
>> On 03/07/2013 10:22 PM, Silvia Pfeiffer wrote:
>>
>>> Agreed, but it's also not sufficient. SDP is not "programmer friendly"
>>> enough because it has too many details that are protocol-details only and
>>> it's too hard to see the semantic bits in SDP and ignore the rest.
>>>
>>> For example: the programmer wants to say - I want to get this video
>>> resolution, this audio bitrate & channels, I want to use this camera and
>>> this microphone for this call. Having to manipulate SDP directly for this
>>> is a programmer's nightmare.
>>>
>>
>> I think we've been over exactly those pieces, and our current proposed
>> solution is called the Media Stream API and the constraints mechanism - and
>> they have exactly nothing to do with SDP, or even with PeerConnection.
>>
>> I don't think we've got it to be "unproblematic" yet, but also, I don't
>> think SDP, JSON or even the offer-answer model is either the problem or the
>> solution on this set of functionalities.
>>
>
> TBH I just hadn't seen
> https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v6.html. Is it implemented anywhere yet?
>
> Now that I've looked at it, I wonder how that interacts with the SDP
> created through createOffer(). If indeed the JS programmer never has to
> touch the SDP, I don't see a need to expose it in the API at all, i.e.
> setLocalDescription() should not be necessary.
>
> Silvia.
>
>

--f46d0442885eed9c9d04d79a00fb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I agree .,. JS developer need not=A0have to touch SDP unless it is required=
 , which I feel might be needed for few=A0special scenarios.=A0
Constra=
ints, Medie Stream Apis, media capture Apis and Peer Connection Apis should=
 be able=A0to support majority of use cases without JS developer needing to=
 manipulate SDP directly.



2 cents

Cheers=A0
Suhas

On Sunday, March 10, 2013, Silvia Pfeiffer  wrote:

On Sun, Mar 10, 2013 at 3:04 AM, Harald Alvestrand <harald@alvestrand.no> wrote:




As usual, I'm trying to use subject line change in order to achieve som=
e separation of concerns...



On 03/07/2013 10:22 PM, Silvia Pfeiffer wrote:



Agreed, but it's also not sufficient. SDP is not "programmer frien=
dly" enough because it has too many details that are protocol-details =
only and it's too hard to see the semantic bits in SDP and ignore the r=
est.






For example: the programmer wants to say - I want to get this video resolut=
ion, this audio bitrate & channels, I want to use this camera and this =
microphone for this call. Having to manipulate SDP directly for this is a p=
rogrammer's nightmare.








I think we've been over exactly those pieces, and our current proposed =
solution is called the Media Stream API and the constraints mechanism - and=
 they have exactly nothing to do with SDP, or even with PeerConnection.






I don't think we've got it to be "unproblematic" yet, but=
 also, I don't think SDP, JSON or even the offer-answer model is either=
 the problem or the solution on this set of functionalities.





TBH I just hadn't seen https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-captur=
e/proposals/SettingsAPI_proposal_v6.html . Is it implemented anywhere y=
et?




Now that I've looked at it, I wonder how that interacts with the SD=
P created through createOffer(). If indeed the JS programmer never has to t=
ouch the SDP, I don't see a need to expose it in the API at all, i.e. s=
etLocalDescription() should not be necessary.



=A0
Silvia.





--f46d0442885eed9c9d04d79a00fb--

From silviapfeiffer1@gmail.com  Sun Mar 10 16:03: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 6217B21F8810 for ; Sun, 10 Mar 2013 16:03:20 -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, 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 7KuVQW0zQR-j for ; Sun, 10 Mar 2013 16:03:19 -0700 (PDT)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0AED621F8804 for ; Sun, 10 Mar 2013 16:03:18 -0700 (PDT)
Received: by mail-la0-f43.google.com with SMTP id ek20so3254776lab.2 for ; Sun, 10 Mar 2013 16:03:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=xCAEX5BjggEUXfmoU9lKx4VgPclMGol2NdEu+9fy49Y=; b=ifFfcj1ETO57bAQPknYNyOmqE5k1G2WWVOCuBU7aHRbjD7BZC8jerEfyy2gjfIFNZE 4fbpRPM1NEoQIBW7h55+BQhOyys3NDXjJV1ExaUJVtK4u7Lp68S2jiWEFaTWlODxzGgV qhJlx60dTl1Px4BL6VkKblgW6fI+tlBvefc6MGiYN2dMHezGceswQckRRwZkMrdXjFUZ TAadtoqi5yPlPM5YI6UWVTYJ2GBtYIAZHAnUApQZN7EfIqbWBGeV82FsbZecnlsAz+tg KGrdDvJFSzsi1BKPdKMC3BxbVJN98W8OUCjshZfoavOma1PHPAXmOhn0eKqKVBJr2Jnv WHiw==
X-Received: by 10.112.9.104 with SMTP id y8mr3718413lba.132.1362956597872; Sun, 10 Mar 2013 16:03:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.51.229 with HTTP; Sun, 10 Mar 2013 16:02:57 -0700 (PDT)
In-Reply-To: 
References:          <513B5D98.2070601@alvestrand.no>  
From: Silvia Pfeiffer 
Date: Mon, 11 Mar 2013 10:02:57 +1100
Message-ID: 
To: Suhas Nandakumar 
Content-Type: multipart/alternative; boundary=e0cb4efe2ee6dc567304d79a0f8b
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Separating stream manipulation from the SDP loudness (Re: Proposed Plan for Usage of SDP and RTP)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 10 Mar 2013 23:03:20 -0000

--e0cb4efe2ee6dc567304d79a0f8b
Content-Type: text/plain; charset=ISO-8859-1

What are the special scenarios?
(Noting that this is likely the wrong list for this topic...)
Silvia.

On Mon, Mar 11, 2013 at 9:59 AM, Suhas Nandakumar wrote:

> I agree .,. JS developer need not have to touch SDP unless it is required
> , which I feel might be needed for few special scenarios.
> Constraints, Medie Stream Apis, media capture Apis and Peer Connection
> Apis should be able to support majority of use cases without JS developer
> needing to manipulate SDP directly.
>
> 2 cents
>
> Cheers
> Suhas
>
>
> On Sunday, March 10, 2013, Silvia Pfeiffer wrote:
>
>> On Sun, Mar 10, 2013 at 3:04 AM, Harald Alvestrand wrote:
>>
>>> As usual, I'm trying to use subject line change in order to achieve some
>>> separation of concerns...
>>>
>>> On 03/07/2013 10:22 PM, Silvia Pfeiffer wrote:
>>>
>>>> Agreed, but it's also not sufficient. SDP is not "programmer friendly"
>>>> enough because it has too many details that are protocol-details only and
>>>> it's too hard to see the semantic bits in SDP and ignore the rest.
>>>>
>>>> For example: the programmer wants to say - I want to get this video
>>>> resolution, this audio bitrate & channels, I want to use this camera and
>>>> this microphone for this call. Having to manipulate SDP directly for this
>>>> is a programmer's nightmare.
>>>>
>>>
>>> I think we've been over exactly those pieces, and our current proposed
>>> solution is called the Media Stream API and the constraints mechanism - and
>>> they have exactly nothing to do with SDP, or even with PeerConnection.
>>>
>>> I don't think we've got it to be "unproblematic" yet, but also, I don't
>>> think SDP, JSON or even the offer-answer model is either the problem or the
>>> solution on this set of functionalities.
>>>
>>
>> TBH I just hadn't seen
>> https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v6.html. Is it implemented anywhere yet?
>>
>> Now that I've looked at it, I wonder how that interacts with the SDP
>> created through createOffer(). If indeed the JS programmer never has to
>> touch the SDP, I don't see a need to expose it in the API at all, i.e.
>> setLocalDescription() should not be necessary.
>>
>> Silvia.
>>
>>

--e0cb4efe2ee6dc567304d79a0f8b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

What are the special scenarios?
(Noting that this is likely the wrong li=
st for this topic...)
Silvia.

On Mon, =
Mar 11, 2013 at 9:59 AM, Suhas Nandakumar <suhasietf@gmail.com> wrote:



I agree .,. JS developer need not=A0have to =
touch SDP unless it is required , which I feel might be needed for few=A0sp=
ecial scenarios.=A0


Constraints, Medie Stream Apis, media capture Apis and Peer Connection Apis=
 should be able=A0to support majority of use cases without JS developer nee=
ding to manipulate SDP directly.



2 cents

Cheers=A0
Suhas


On Sunday, March 10, 2013, Silvia Pfeiffe=
r  wrote:




On Sun, Mar 10, 2013 at 3:04 AM, Harald Alvestrand <harald@alvestrand.no> wrote:




As usual, I'm trying to use subject line change in order to achieve som=
e separation of concerns...



On 03/07/2013 10:22 PM, Silvia Pfeiffer wrote:



Agreed, but it's also not sufficient. SDP is not "programmer frien=
dly" enough because it has too many details that are protocol-details =
only and it's too hard to see the semantic bits in SDP and ignore the r=
est.








For example: the programmer wants to say - I want to get this video resolut=
ion, this audio bitrate & channels, I want to use this camera and this =
microphone for this call. Having to manipulate SDP directly for this is a p=
rogrammer's nightmare.










I think we've been over exactly those pieces, and our current proposed =
solution is called the Media Stream API and the constraints mechanism - and=
 they have exactly nothing to do with SDP, or even with PeerConnection.








I don't think we've got it to be "unproblematic" yet, but=
 also, I don't think SDP, JSON or even the offer-answer model is either=
 the problem or the solution on this set of functionalities.







TBH I just hadn't seen https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-captur=
e/proposals/SettingsAPI_proposal_v6.html . Is it implemented anywhere y=
et?






Now that I've looked at it, I wonder how that interacts with the SD=
P created through createOffer(). If indeed the JS programmer never has to t=
ouch the SDP, I don't see a need to expose it in the API at all, i.e. s=
etLocalDescription() should not be necessary.





=A0
Silvia.








--e0cb4efe2ee6dc567304d79a0f8b--

From ron@debian.org  Sun Mar 10 17:37: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 1F9FD21F886B for ; Sun, 10 Mar 2013 17:37:13 -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 XJaIvNc4cPJN for ; Sun, 10 Mar 2013 17:37:12 -0700 (PDT)
Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 5C87421F8867 for ; Sun, 10 Mar 2013 17:37:12 -0700 (PDT)
Received: from ppp118-210-253-40.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([118.210.253.40]) by ipmail07.adl2.internode.on.net with ESMTP; 11 Mar 2013 11:07:10 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 63DE94F8F3 for ; Mon, 11 Mar 2013 11:07:09 +1030 (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 K1EZjRVTj3wy for ; Mon, 11 Mar 2013 11:07:08 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id B42684F902; Mon, 11 Mar 2013 11:07:08 +1030 (CST)
Date: Mon, 11 Mar 2013 11:07:08 +1030
From: Ron 
To: rtcweb@ietf.org
Message-ID: <20130311003708.GT7852@audi.shelbyville.oz>
References:  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] VP8 litigation in Germany?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 11 Mar 2013 00:37:13 -0000

On Sun, Mar 10, 2013 at 07:19:25PM +0000, Stephan Wenger wrote:
> On 3.10.2013 11:50 , "Ted Hardie"  wrote:
> >
> >A potential non-RAND response seems to be entirely a supposition; you
> >could equally suppose that they would make their licenses royalty
> >free, should they have any applicable to VP8, based on the PR value of
> >contributing to the existence of a more vibrant ecosystem.
> 
> Risk assessment necessarily deals with probabilities.  How high is the
> chance that an aggressive IP enforcer would ask for non RAND terms
> (billions in royalty, injunction, whatnot), RAND terms, or give in for
> good, when litigation has been initiated and the IP enforcer is not bound
> to RAND terms?  Rhetoric question.

Yeah, that would be like Google saying "Ok guys we have a really big
chequebook here, what's it going to cost for you to quit with the FUD?"

And MPEG-LA saying "oh, ah ... hmm.  Well ... we don't want your money
(tell them we've already got one), so we'll just excuse ourselves here
from any further involvement and let you folks talk among yourselves" ...

"Oh, and you're welcome to say in the press release that we agree none
of this indicates any of the patents actually read on your technology."

Never going to happen in our lifetimes, right?  What are the chances?
(Genuine question for anyone who fancies themselves a bookmaker)


  Ron

  - who still suspects his previous theory of the actual 'arrangement'
    details is far closer to the truth indicated by the known facts.



From harald@alvestrand.no  Mon Mar 11 05:39: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 890F421F84CD for ; Mon, 11 Mar 2013 05:39:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.774
X-Spam-Level: 
X-Spam-Status: No, score=-110.774 tagged_above=-999 required=5 tests=[AWL=-0.175, 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 OOgQ+SFp2bKd for ; Mon, 11 Mar 2013 05:39:37 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D2C0B21F84AB for ; Mon, 11 Mar 2013 05:39:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0C52B39E1B7; Mon, 11 Mar 2013 13:39:34 +0100 (CET)
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 sOwOomeoYoHg; Mon, 11 Mar 2013 13:39:33 +0100 (CET)
Received: from [IPv6:2001:df8:0:16:b4fd:eac0:98eb:c482] (unknown [IPv6:2001:df8:0:16:b4fd:eac0:98eb:c482]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7A58739E1AD; Mon, 11 Mar 2013 13:39:32 +0100 (CET)
Message-ID: <513DD082.9090701@alvestrand.no>
Date: Mon, 11 Mar 2013 13:39:30 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: Silvia Pfeiffer 
References:          <513B5D98.2070601@alvestrand.no>   
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Separating stream manipulation from the SDP loudness (Re: Proposed Plan for Usage of SDP and RTP)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 11 Mar 2013 12:39:37 -0000

On 03/11/2013 12:02 AM, Silvia Pfeiffer wrote:
> What are the special scenarios?
> (Noting that this is likely the wrong list for this topic...)

One that I've heard mention is if the remote gateway requires stuff in 
the SDP that the browser knows nothing about. (I've never encountered 
this in practice, but it wouldn't surprise me if it happens).

In that case, the application would be written especially for 
communicating with that remote gateway.



From Markus.Isomaki@nokia.com  Mon Mar 11 08: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 43E6311E80FC for ; Mon, 11 Mar 2013 08:06:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 bnso0SRD2vVy for ; Mon, 11 Mar 2013 08:06:45 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB0321F84EF for ; Mon, 11 Mar 2013 08:06:45 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r2BF6hoq023261; Mon, 11 Mar 2013 17:06:44 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 11 Mar 2013 17:06:42 +0200
Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.232]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.02.0328.011; Mon, 11 Mar 2013 15:06:42 +0000
From: 
To: , 
Thread-Topic: VP8 litigation in Germany?
Thread-Index: AQHOHTdlrWoXGfl7J0qzyy7s7WzxBJigkRPg
Date: Mon, 11 Mar 2013 15:06:41 +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: [130.129.134.1]
Content-Type: multipart/alternative; boundary="_000_E44893DD4E290745BB608EB23FDDB7623BB2E7008AM1MPN1042mgdn_"
MIME-Version: 1.0
X-OriginalArrivalTime: 11 Mar 2013 15:06:42.0652 (UTC) FILETIME=[0A2EA9C0:01CE1E6A]
X-Nokia-AV: Clean
Subject: Re: [rtcweb] VP8 litigation in Germany?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 11 Mar 2013 15:06:47 -0000

--_000_E44893DD4E290745BB608EB23FDDB7623BB2E7008AM1MPN1042mgdn_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,


I am not personally aware of any more details of this case than what is inc=
luded below. However, I have been in contact with the Nokia Legal departmen=
t about it. It is true that Nokia believes we have IPR related to VP8. Alth=
ough the disclosure obligations are not entirely clear in this case as seen=
 e.g. in [1], Nokia is preparing to do a disclosure about it to the IETF, "=
to ensure that IETF working groups and participants have as much informatio=
n about any IPR constraints on a technical proposal as possible", as stated=
 in RFC 3979. That's all the information I have right now, but I will keep =
this list updated as soon as something new comes up.



[1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06578.html

Markus


From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 ext Stephan Wenger
Sent: 10 March, 2013 04:32
To: rtcweb@ietf.org
Subject: [rtcweb] VP8 litigation in Germany?

Hi,
An additional data point.
Florian Mueller writes in his patent blog (http://www.fosspatents.com/2013/=
03/patent-clouds-remain-over-vp8-google.html) that he has attended a court =
hearing in Mannheim, Germany, where, according to his blog, "Counsel for No=
kia indeed based the infringement allegation in no small part on what the s=
pecifications of the Google-controlled VP8 standard say, which is an unmist=
akable sign that Nokia considers EP1206881 to be inevitably infringed by al=
l implementations of VP8."
Now, I understand that Mr. Mueller is not particularly highly regarded by a=
 whole bunch of people in the open source community.  I myself find a numbe=
r of other statements in this blog post, however carefully worded, somewhat=
 questionable.  OTOH, I consider it very unlikely that he made up all those=
 reported facts.
That my former colleagues in Nokia decide to sue over this patent (if they =
have done so) does, of course, not mean that the VP8 implementation of HTC =
infringes, let alone all VP8 implementations.  Quite likely we will never k=
now either way-most patent lawsuits are settled out of court.
One other data point: Mr. Mueller is correct in that Nokia is not a member =
of the H.264 pool.  Nor are they members in any other video coding related =
patent pool that I'm aware of, despite IMO having one of the strongest vide=
o coding research teams in the industry (I was part of that myself, a while=
 ago).
Regards,
Stephan


--_000_E44893DD4E290745BB608EB23FDDB7623BB2E7008AM1MPN1042mgdn_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi all,=



 <=
/p>

I am not personally aware of any more detai=
ls of this case than what is included below. However, I have been in contac=
t with the Nokia Legal department about it. It is true that Nokia believes =
we have IPR related to VP8. Although the disclosure obligations are not ent=
irely clear in this case as seen e.g. in [1], Nokia is preparing to do a di=
sclosure about it to the IETF, “to ensure that IETF working groups an=
d participants have as much information about any IPR constraints on a tech=
nical proposal as possible”, as stated in RFC 3979. That’s all =
the information I have right now, but I will keep this list updated as soon=
 as something new comes up.


 


[1] http://www.ietf.org/mail-archive/web=
/rtcweb/current/msg06578.html


 <=
/p>

Markus



  


 <=
/p>







From: rtcweb-b=
ounces@ietf.org [mailto:rtcweb-bounces@ietf.org]
On Behalf Of ext Stephan Wenger

Sent: 10 March, 2013 04:32

To: rtcweb@ietf.org

Subject: [rtcweb] VP8 litigation in Germany?






 




Hi,






An additional data point.






Florian Mueller writes in h=
is patent blog (http://www.fosspatents.com/2013/03/patent-clo=
uds-remain-over-vp8-google.html)
 that he has attended a court hearing in Mannheim, Germany, where, accordin=
g to his blog, "Counsel for Nokia indeed based the infringement allega=
tion in no small part on what the specifications of the Google-controlled V=
P8 standard say, which is an unmistakable
 sign that Nokia considers EP1206881 to be inevitably infringed by all impl=
ementations of VP8."






Now, I understand that Mr. =
Mueller is not particularly highly regarded by a whole bunch of people in t=
he open source community.  I myself find a number of other
 statements in this blog post, however carefully worded, somewhat questiona=
ble.  OTOH, I consider it very unlikely that he made up all those repo=
rted facts.






That my former colleagues i=
n Nokia decide to sue over this patent (if they have done so) does, of cour=
se, not mean that the VP8 implementation of HTC infringes,
 let alone all VP8 implementations.  Quite likely we will never know e=
ither way—most patent lawsuits are settled out of court.






One other data point: Mr. M=
ueller is correct in that Nokia is not a member of the H.264 pool.  No=
r are they members in any other video coding related patent pool
 that I'm aware of, despite IMO having one of the strongest video coding re=
search teams in the industry (I was part of that myself, a while ago). &nbs=
p;






Regards,<=
/p>





Stephan





 









--_000_E44893DD4E290745BB608EB23FDDB7623BB2E7008AM1MPN1042mgdn_--

From Markus.Isomaki@nokia.com  Mon Mar 11 08:13: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 5089E11E810E for ; Mon, 11 Mar 2013 08:13:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001,  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 ppp65WkgDVJM for ; Mon, 11 Mar 2013 08:13:21 -0700 (PDT)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 7E06A21F86A8 for ; Mon, 11 Mar 2013 08:13:20 -0700 (PDT)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r2BFDErX026028; Mon, 11 Mar 2013 17:13:15 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 11 Mar 2013 17:13:13 +0200
Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.232]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.02.0328.011; Mon, 11 Mar 2013 15:13:13 +0000
From: 
To: , 
Thread-Topic: [rtcweb] VP8 litigation in Germany?
Thread-Index: AQHOHTdl6kb3TqdDTc2vRZKKqKDI4ZifPQ8A//+fL4CAAb2/gA==
Date: Mon, 11 Mar 2013 15:13:13 +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: [130.129.134.1]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 11 Mar 2013 15:13:13.0991 (UTC) FILETIME=[F3704170:01CE1E6A]
X-Nokia-AV: Clean
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 litigation in Germany?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 11 Mar 2013 15:13:22 -0000

Hi,

>Second, remember that H.264 is a RAND standard and Nokia is undoubtedly
>bound to their RAND commitment to the ITU.  Insofar, I very much doubt tha=
t
>they could get away with charging non-RAND rates or doing other unpleasant
>things.  For VP8, as not being a standard under RAND, there is no such a
>restricting framework in place, AFAIK.

Stephan is correct. All Nokia's H.264 related IPR is bound to RAND commitme=
nts. There is no unclarity about that.=20

VP8 is a different case.=20

Markus=20


>-----Original Message-----
>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
>Of ext Stephan Wenger
>Sent: 10 March, 2013 20:33
>To: Ted Hardie
>Cc: rtcweb@ietf.org
>Subject: Re: [rtcweb] VP8 litigation in Germany?
>
>Hi Ted,
>
>On 3.10.2013 11:19 , "Ted Hardie"  wrote:
>
>>On Sat, Mar 9, 2013 at 9:31 PM, Stephan Wenger 
>wrote:
>>> One other data point: Mr. Mueller is correct in that Nokia is not a
>>>member  of the H.264 pool.  Nor are they members in any other video
>>>coding related  patent pool that I'm aware of, despite IMO having one
>>>of the strongest video  coding research teams in the industry (I was
>>>part of that myself, a while  ago).
>>
>>Hi Stephan,
>>
>>So, this seems to me to imply that any Nokia IPR on either H.264 or
>>VP8 is not part of any established patent pool and thus is not publicly
>>in the "market" of which you have previously spoken.  If that is the
>>case, it would seem to be an equally unknown factor for an
>>implementer of either.   To put this slightly different, even if Mr.
>>Mueller were correct, the additional context seems to result in this
>>being null data for our particular working group decision.
>
>No, I don't think that this is correct, for at least two reasons.
>
>First, if we were adopting a tit for tat approach, I could argue that this=
 lawsuit
>counterbalances the H.264 related lawsuit(s) (there is only one critical l=
eft
>AFAIR, which is Motorola/Microsoft) that has created so much noise here in
>the past.  You can get sued over H.264 (interlace frame/field adaptivity f=
or
>example), but you can equally get sued over VP8 (motion vector coding
>technology for example, if I remember correctly).
>
>Second, remember that H.264 is a RAND standard and Nokia is undoubtedly
>bound to their RAND commitment to the ITU.  Insofar, I very much doubt tha=
t
>they could get away with charging non-RAND rates or doing other unpleasant
>things.  For VP8, as not being a standard under RAND, there is no such a
>restricting framework in place, AFAIK.
>
>The second aspect may make little difference to those whose business model
>discourages them from paying royalties (which I do not consider a sustaina=
ble
>business model in this field, however, others have other opinions includin=
g a
>few folks who know their stuff in this field).
>However, the first aspect does.
>
>>
>>regards,
>>
>>Ted Hardie
>>
>
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb

From worley@shell01.TheWorld.com  Mon Mar 11 09:01: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 2F8B711E80E4 for ; Mon, 11 Mar 2013 09:01:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.911
X-Spam-Level: 
X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[AWL=0.069,  BAYES_00=-2.599, 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 QIgpT3OAJ3Ch for ; Mon, 11 Mar 2013 09:01:03 -0700 (PDT)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 93C5621F8B9B for ; Mon, 11 Mar 2013 09:01:03 -0700 (PDT)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r2BG05VC027116; Mon, 11 Mar 2013 12:00:07 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r2BG05iM222692; Mon, 11 Mar 2013 11:00:05 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2BG00ZG222679; Mon, 11 Mar 2013 12:00:00 -0400 (EDT)
Date: Mon, 11 Mar 2013 12:00:00 -0400 (EDT)
Message-Id: <201303111600.r2BG00ZG222679@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: Harald Alvestrand 
In-reply-to: <513DD082.9090701@alvestrand.no> (harald@alvestrand.no)
References:          <513B5D98.2070601@alvestrand.no>    <513DD082.9090701@alvestrand.no>
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Separating stream manipulation from the SDP loudness (Re: Proposed Plan for Usage of SDP and RTP)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 11 Mar 2013 16:01:05 -0000

> From: Harald Alvestrand 
> 
> One that I've heard mention is if the remote gateway requires stuff in 
> the SDP that the browser knows nothing about. (I've never encountered 
> this in practice, but it wouldn't surprise me if it happens).

I would be surprised if this happens much.  In the offer/answer arena,
backward compatibility considerations mean that the recipient of SDP
is always prepared to receive *less* information about the media than
it would prefer to receive, and to process such SDP successfully.

Dale

From binod.pg@oracle.com  Mon Mar 11 09:01: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 F346011E8119 for ; Mon, 11 Mar 2013 09:01:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.69
X-Spam-Level: 
X-Spam-Status: No, score=-4.69 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908, 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 PVGk9VqaMRAD for ; Mon, 11 Mar 2013 09:01:11 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 700BF11E80F0 for ; Mon, 11 Mar 2013 09:01:11 -0700 (PDT)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r2BG1AJU003164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 11 Mar 2013 16:01:11 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r2BG19VD027939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 Mar 2013 16:01:09 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r2BG19qs008172 for ; Mon, 11 Mar 2013 11:01:09 -0500
Received: from [223.239.147.187] (/223.239.147.187) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 11 Mar 2013 09:01:09 -0700
Message-ID: <513DFFC2.1000605@oracle.com>
Date: Mon, 11 Mar 2013 21:31:06 +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
Content-Type: multipart/alternative; boundary="------------070700030505050905030004"
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [rtcweb] TURN, NAT and Proxies
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 11 Mar 2013 16:01:12 -0000

This is a multi-part message in MIME format.
--------------070700030505050905030004
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I was scanning the webrtc drafts to figure out what is
specified regarding NAT traversal, firewall and proxies.

draft-ietf-rtcweb-use-cases-and-requirements 
 
mentions
1)  NAT/FW that blocks UDP :

Ok, This is achieved by supporting ICE-TCP

2) FW that only allows http:

How is this supported?

What about enterprises that only support proxies?

In the google group discussion, Justin was mentioning
that browser could connect with a proxy (http connect)
even for TURN traffic and also mentioned supporting
an enterprise TURN server.

Will this make into one of the webrtc rfcs?

thanks,
Binod.

--------------070700030505050905030004
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    I was scanning the webrtc drafts to figure out what is 

    specified regarding NAT traversal, firewall and proxies.

    

    draft-ietf-rtcweb-use-cases-and-requirements
    mentions

    1)  NAT/FW that blocks UDP : 

    

    Ok, This is achieved by supporting ICE-TCP

    

    2) FW that only allows http:

    

    How is this supported?

    

    What about enterprises that only support proxies?

    

    In the google group discussion, Justin was mentioning 

    that browser could connect with a proxy (http connect)

    even for TURN traffic and also mentioned supporting

    an enterprise TURN server. 

    

    Will this make into one of the webrtc rfcs?

    

    thanks,

    Binod. 

    
  


--------------070700030505050905030004--

From worley@shell01.TheWorld.com  Mon Mar 11 09: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 BB2E011E8107 for ; Mon, 11 Mar 2013 09:02:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.92
X-Spam-Level: 
X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, 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 9djtMQTGLe9f for ; Mon, 11 Mar 2013 09:02:11 -0700 (PDT)
Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8418B11E80E4 for ; Mon, 11 Mar 2013 09:02:06 -0700 (PDT)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r2BG0KXR015127; Mon, 11 Mar 2013 12:00:22 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r2BG0Kev222739; Mon, 11 Mar 2013 11:00:20 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2BG0K16222765; Mon, 11 Mar 2013 12:00:20 -0400 (EDT)
Date: Mon, 11 Mar 2013 12:00:20 -0400 (EDT)
Message-Id: <201303111600.r2BG0K16222765@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: mmusic@ietf.org
Cc: rtcweb@ietf.org
Subject: [rtcweb] Revision of bundling proposal/analysis
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 11 Mar 2013 16:02:11 -0000

I've just submitted draft-worley-sdp-bundle-05, which is an SDP
bundling proposal along with a bunch of analysis and comparison to
other bundling proposals.

The biggest change is adding a detailed analysis of alternatives for
the address/port combinations to be used when offering constituent
media descriptions (m= lines) so as to get all the mechanics to work
as we'd like.  It is from this analysis I noticed that we don't have a
good method to *answer* a constituent media description.  (I've sent
e-mail about that to MMUSIC.)

I've added an example containing two SCTP media descriptions, which
will be a common case on WebRTC.

A change that I have not yet made is removing the RTP encapsulation
payload format ("kumquat" itself).  It looks like encapsulation works
against some properties we'd like the solution to have.
Unfortunately, removing encapsulation causes constraints in other
parts of the solution.  In particular, different media descriptions
will be constrained to have different payload type numbers, and
bundling can't support multiple transport addresses or multiple ports
within a single media description.

Dale


A new version of I-D, draft-worley-sdp-bundle-05.txt
has been successfully submitted by Dale R. Worley and posted to the
IETF repository.

Filename:	 draft-worley-sdp-bundle
Revision:	 05
Title:		 Kumquat: A Generic Bundle Mechanism for the Session Description Protocol (SDP)
Creation date:	 2013-03-11
Group:		 Individual Submission
Number of pages: 42
URL:             http://www.ietf.org/internet-drafts/draft-worley-sdp-bundle-05.txt
Status:          http://datatracker.ietf.org/doc/draft-worley-sdp-bundle
Htmlized:        http://tools.ietf.org/html/draft-worley-sdp-bundle-05
Diff:            http://www.ietf.org/rfcdiff?url2=draft-worley-sdp-bundle-05

Abstract:
   This document defines a generic bundle mechanism for the Session
   Description Protocol (SDP) by which the media described by a number
   of media descriptions ("m= lines") are multiplexed and transmitted
   over a single transport association.  The transport association is
   described by an additional media description, allowing SDP attributes
   to be applied to the aggregate, independently of attributes applied
   to the constituents.  In offer/answer usage, the bundle mechanism is
   backward compatible with SDP processors that do not understand the
   mechanism.  The mechanism is designed to be compatible with the
   limitations of the existing Internet infrastructure.

From lorenzo@meetecho.com  Mon Mar 11 09:22: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 BA29E21F8C96 for ; Mon, 11 Mar 2013 09:22:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level: 
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C60scuKFiWAG for ; Mon, 11 Mar 2013 09:22:13 -0700 (PDT)
Received: from smtpdg8.aruba.it (smtpdg226.aruba.it [62.149.158.226]) by ietfa.amsl.com (Postfix) with ESMTP id D692C21F8C87 for ; Mon, 11 Mar 2013 09:22:12 -0700 (PDT)
Received: from lminiero-acer ([130.129.20.132]) by smtpcmd03.ad.aruba.it with bizsmtp id AGN81l01G2qyxt601GN90P; Mon, 11 Mar 2013 17:22:10 +0100
Date: Mon, 11 Mar 2013 17:21:56 +0100
From: Lorenzo Miniero 
To: Binod 
Message-ID: <20130311172156.11de6c97@lminiero-acer>
In-Reply-To: <513DFFC2.1000605@oracle.com>
References: <513DFFC2.1000605@oracle.com>
Organization: Meetecho
X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] TURN, NAT and Proxies
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 11 Mar 2013 16:22:14 -0000

Il giorno Mon, 11 Mar 2013 21:31:06 +0530
Binod  ha scritto:

> I was scanning the webrtc drafts to figure out what is
> specified regarding NAT traversal, firewall and proxies.
> 
> draft-ietf-rtcweb-use-cases-and-requirements 
>  
> mentions
> 1)  NAT/FW that blocks UDP :
> 
> Ok, This is achieved by supporting ICE-TCP
> 
> 2) FW that only allows http:
> 
> How is this supported?
> 
> What about enterprises that only support proxies?
> 
> In the google group discussion, Justin was mentioning
> that browser could connect with a proxy (http connect)
> even for TURN traffic and also mentioned supporting
> an enterprise TURN server.
> 
> Will this make into one of the webrtc rfcs?
> 
> thanks,
> Binod.


I submitted an individual draft (now expired) a few months ago that
tried to address this exact issue. From the discussion that came out,
which you can find in the archives, the consensus was basically to rely
on TURN (e.g. on port 443 to look like HTTPS) or on nothing at all, as
using some kind of HTTP fallback could have been seen as "overkill".
Besides, trying to pass through more restrictive firewalls by, well,
fooling them was seen as trying to bypass policies configured by
network administrators, so not acceptable for some.

Lorenzo

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

From andrew.hutton@siemens-enterprise.com  Mon Mar 11 09:56: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 8D1DC11E8146 for ; Mon, 11 Mar 2013 09:56:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.478
X-Spam-Level: 
X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hiFueFrlqrb for ; Mon, 11 Mar 2013 09:56: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 CDA1911E8142 for ; Mon, 11 Mar 2013 09:56:52 -0700 (PDT)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 9405B23F048D for ; Mon, 11 Mar 2013 17:56:51 +0100 (CET)
Received: from MCHP04MSX.global-ad.net ([169.254.1.94]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0328.009; Mon, 11 Mar 2013 17:56:51 +0100
From: "Hutton, Andrew" 
To: "rtcweb@ietf.org" 
Thread-Topic: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
Thread-Index: AQHOHj9zQPNB80XASUa1nEzDk7aFy5igtR3Q
Date: Mon, 11 Mar 2013 16:56:50 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF06894839@MCHP04MSX.global-ad.net>
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: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-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, 11 Mar 2013 16:56:53 -0000

FYI - We submitted this draft today it relates to the requirements in the u=
se case draft for rtcweb to work in the presence of firewalls and http prox=
ies etc.

Look forward to feedback and hope that this can be considered for adoption =
by the working group.

Regards
Andy



-----Original Message-----
From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] =
On Behalf Of internet-drafts@ietf.org
Sent: 11 March 2013 06:01
To: i-d-announce@ietf.org
Subject: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.


	Title           : RTCWEB Considerations for NATs, Firewalls and HTTP proxi=
es
	Author(s)       : Thomas Stach
                          Andrew Hutton
                          Justin Uberti
	Filename        : draft-hutton-rtcweb-nat-firewall-considerations-00.txt
	Pages           : 8
	Date            : 2013-03-11

Abstract:
   This document describes mechanism to enable media stream
   establishment in the presence of NATs, firewalls and HTTP proxies.
   HTTP proxy and firewall policies applied in many private network
   domains introduce obstacles to the successful establishment of media
   stream via RTCWEB.  This document examines some of these policies and
   develops requirements on the web browsers designed to provide the
   best possible chance of media connectivity between RTCWEB peers.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-hutton-rtcweb-nat-firewall-considera=
tions

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-=
00


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 andrew.hutton@siemens-enterprise.com  Mon Mar 11 10:00: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 2B50F11E816B for ; Mon, 11 Mar 2013 10:00:38 -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.047,  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 8b8ercTyWjdG for ; Mon, 11 Mar 2013 10:00:25 -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 827A411E8146 for ; Mon, 11 Mar 2013 10:00:25 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 8EB921EB855A; Mon, 11 Mar 2013 18:00:24 +0100 (CET)
Received: from MCHP04MSX.global-ad.net ([169.254.1.94]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Mon, 11 Mar 2013 18:00:24 +0100
From: "Hutton, Andrew" 
To: Lorenzo Miniero , Binod 
Thread-Topic: [rtcweb] TURN, NAT and Proxies
Thread-Index: AQHOHnG+BNg15CdYtE6BJoqWVgtjVpigm3EAgAAatnA=
Date: Mon, 11 Mar 2013 17:00:23 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF06894866@MCHP04MSX.global-ad.net>
References: <513DFFC2.1000605@oracle.com> <20130311172156.11de6c97@lminiero-acer>
In-Reply-To: <20130311172156.11de6c97@lminiero-acer>
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] TURN, NAT and Proxies
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 11 Mar 2013 17:00:38 -0000

Hi,

By coincidence we submitted a draft on this subject just this morning it ca=
n be found at: http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-=
considerations-00.

Regards
Andy=20

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Lorenzo Miniero
> Sent: 11 March 2013 12:22
> To: Binod
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] TURN, NAT and Proxies
>=20
> Il giorno Mon, 11 Mar 2013 21:31:06 +0530
> Binod  ha scritto:
>=20
> > I was scanning the webrtc drafts to figure out what is
> > specified regarding NAT traversal, firewall and proxies.
> >
> > draft-ietf-rtcweb-use-cases-and-requirements
> >  requirements/>
> > mentions
> > 1)  NAT/FW that blocks UDP :
> >
> > Ok, This is achieved by supporting ICE-TCP
> >
> > 2) FW that only allows http:
> >
> > How is this supported?
> >
> > What about enterprises that only support proxies?
> >
> > In the google group discussion, Justin was mentioning
> > that browser could connect with a proxy (http connect)
> > even for TURN traffic and also mentioned supporting
> > an enterprise TURN server.
> >
> > Will this make into one of the webrtc rfcs?
> >
> > thanks,
> > Binod.
>=20
>=20
> I submitted an individual draft (now expired) a few months ago that
> tried to address this exact issue. From the discussion that came out,
> which you can find in the archives, the consensus was basically to rely
> on TURN (e.g. on port 443 to look like HTTPS) or on nothing at all, as
> using some kind of HTTP fallback could have been seen as "overkill".
> Besides, trying to pass through more restrictive firewalls by, well,
> fooling them was seen as trying to bypass policies configured by
> network administrators, so not acceptable for some.
>=20
> Lorenzo
>=20
> --
> Lorenzo Miniero, COB
>=20
> Meetecho s.r.l.
> Web Conferencing and Collaboration Tools
> http://www.meetecho.com
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

From repenno@cisco.com  Mon Mar 11 10:04: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 50F2A21F89C5 for ; Mon, 11 Mar 2013 10:04:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.443
X-Spam-Level: 
X-Spam-Status: No, score=-10.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HktF2VmPmWyI for ; Mon, 11 Mar 2013 10:04:19 -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 8087021F8900 for ; Mon, 11 Mar 2013 10:04:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2501; q=dns/txt; s=iport; t=1363021459; x=1364231059; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=rnTInLK7kMEU8CxFsuO8YpBXeh9jZ5fjgkFYaHvUVac=; b=O+tw6YuBf0g21B+fHLHw/HAn9c5bTQHllpUaNF2kKvXB7OaRL9rDm7sS gyJtzNzl2yAbtVPsnUPbT79+XIoRphJAwkqw4s8b91uFtFbeHGqAxGUpT TIxwgOvCTXe5fqIotnTUs1VkIIu4gU2AQrfCevnp4zr5NBgExD0ZYhTwn U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFACUOPlGtJXG//2dsb2JhbABDxGCBXRZ0gikBAQEEAQEBNzQXBgEIEQQBAQsUCS4LFAgBCAIEARIIAYgKDL0/F45dJg0FBoJZYQOXc4pBhRaBVIE2gig
X-IronPort-AV: E=Sophos;i="4.84,825,1355097600"; d="scan'208";a="186216565"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 11 Mar 2013 17:04:19 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2BH4Iv9027478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Mar 2013 17:04:18 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 12:04:18 -0500
From: "Reinaldo Penno (repenno)" 
To: "Hutton, Andrew" , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
Thread-Index: AQHOHj9zQPNB80XASUa1nEzDk7aFy5igtR3Q///hxoA=
Date: Mon, 11 Mar 2013 17:04:17 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040901B274@xmb-rcd-x04.cisco.com>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF06894839@MCHP04MSX.global-ad.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.21.86.68]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5FEFC0CBBC5C574B86756B6A92E1CF46@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-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, 11 Mar 2013 17:04:20 -0000

Hello,

Why not use Port Control Protocol (PCP) to control Firewalls and NATs
explicitly?=20

Thanks,

On 3/11/13 9:56 AM, "Hutton, Andrew"
 wrote:

>FYI - We submitted this draft today it relates to the requirements in the
>use case draft for rtcweb to work in the presence of firewalls and http
>proxies etc.
>
>Look forward to feedback and hope that this can be considered for
>adoption by the working group.
>
>Regards
>Andy
>
>
>
>-----Original Message-----
>From: i-d-announce-bounces@ietf.org
>[mailto:i-d-announce-bounces@ietf.org] On Behalf Of
>internet-drafts@ietf.org
>Sent: 11 March 2013 06:01
>To: i-d-announce@ietf.org
>Subject: I-D Action:
>draft-hutton-rtcweb-nat-firewall-considerations-00.txt
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>
>	Title           : RTCWEB Considerations for NATs, Firewalls and HTTP
>proxies
>	Author(s)       : Thomas Stach
>                          Andrew Hutton
>                          Justin Uberti
>	Filename        : draft-hutton-rtcweb-nat-firewall-considerations-00.txt
>	Pages           : 8
>	Date            : 2013-03-11
>
>Abstract:
>   This document describes mechanism to enable media stream
>   establishment in the presence of NATs, firewalls and HTTP proxies.
>   HTTP proxy and firewall policies applied in many private network
>   domains introduce obstacles to the successful establishment of media
>   stream via RTCWEB.  This document examines some of these policies and
>   develops requirements on the web browsers designed to provide the
>   best possible chance of media connectivity between RTCWEB peers.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-hutton-rtcweb-nat-firewall-consider
>ations
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations
>-00
>
>
>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
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb


From harald@alvestrand.no  Mon Mar 11 10:29: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 35C1111E8128 for ; Mon, 11 Mar 2013 10:29:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.661
X-Spam-Level: 
X-Spam-Status: No, score=-110.661 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156, 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 FQkG29OlxVUy for ; Mon, 11 Mar 2013 10:29:22 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCD411E80F3 for ; Mon, 11 Mar 2013 10:29:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8B2DD39E1C2 for ; Mon, 11 Mar 2013 18:29:21 +0100 (CET)
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 EPNWtN5ThZha for ; Mon, 11 Mar 2013 18:29:20 +0100 (CET)
Received: from [IPv6:2001:df8:0:16:b4fd:eac0:98eb:c482] (unknown [IPv6:2001:df8:0:16:b4fd:eac0:98eb:c482]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0CD8E39E1AD for ; Mon, 11 Mar 2013 18:29:19 +0100 (CET)
Message-ID: <513E146D.4060009@alvestrand.no>
Date: Mon, 11 Mar 2013 18:29:17 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <45A697A8FFD7CF48BCF2BE7E106F06040901B274@xmb-rcd-x04.cisco.com>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040901B274@xmb-rcd-x04.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-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, 11 Mar 2013 17:29:23 -0000

On 03/11/2013 06:04 PM, Reinaldo Penno (repenno) wrote:
> Hello,
>
> Why not use Port Control Protocol (PCP) to control Firewalls and NATs
> explicitly?
We can switch to that as soon as 100% of firewalls support it - until 
then, we have to be able to rely on other techniques.

That's the deployment problem in a nutshell... I don't understand how 
the first firewall gets an advantage from having PCP, given that none of 
the apps support it, and I don't understand how the first app gets an 
advantage from having PCP, given that no firewalls support it.

If PCP succeeds despite my misgivings, we can certainly revisit the issue.

>
> Thanks,
>
> On 3/11/13 9:56 AM, "Hutton, Andrew"
>  wrote:
>
>> FYI - We submitted this draft today it relates to the requirements in the
>> use case draft for rtcweb to work in the presence of firewalls and http
>> proxies etc.
>>
>> Look forward to feedback and hope that this can be considered for
>> adoption by the working group.
>>
>> Regards
>> Andy
>>
>>
>>
>> -----Original Message-----
>> From: i-d-announce-bounces@ietf.org
>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of
>> internet-drafts@ietf.org
>> Sent: 11 March 2013 06:01
>> To: i-d-announce@ietf.org
>> Subject: I-D Action:
>> draft-hutton-rtcweb-nat-firewall-considerations-00.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>> 	Title           : RTCWEB Considerations for NATs, Firewalls and HTTP
>> proxies
>> 	Author(s)       : Thomas Stach
>>                           Andrew Hutton
>>                           Justin Uberti
>> 	Filename        : draft-hutton-rtcweb-nat-firewall-considerations-00.txt
>> 	Pages           : 8
>> 	Date            : 2013-03-11
>>
>> Abstract:
>>    This document describes mechanism to enable media stream
>>    establishment in the presence of NATs, firewalls and HTTP proxies.
>>    HTTP proxy and firewall policies applied in many private network
>>    domains introduce obstacles to the successful establishment of media
>>    stream via RTCWEB.  This document examines some of these policies and
>>    develops requirements on the web browsers designed to provide the
>>    best possible chance of media connectivity between RTCWEB peers.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-hutton-rtcweb-nat-firewall-consider
>> ations
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations
>> -00
>>
>>
>> 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
>> _______________________________________________
>> 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 repenno@cisco.com  Mon Mar 11 11:03: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 6372521F8A98 for ; Mon, 11 Mar 2013 11:03:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.521
X-Spam-Level: 
X-Spam-Status: No, score=-10.521 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nys6AsMh2-6a for ; Mon, 11 Mar 2013 11:03:00 -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 4BDF811E80F2 for ; Mon, 11 Mar 2013 11:02:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4141; q=dns/txt; s=iport; t=1363024979; x=1364234579; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=hh/58cDLTwHjWPjfvuSlULvbHE6sK4vrIhqP/raNGfA=; b=gvwpdOUd3/HW1EzOOODj1d/l1p6Izw2gEtqfDzUxz0rCr2A1tdGHMV2b SMnTI7TzOttLFbgt0baeJYMlusAycajWBGr/mm/7T8wQaaUrwmVta5wV3 HF4JZC15EvRa2q1xT7Huefrni96uaFnLzNV1egzUqS3UDoRXZyEefTaBL k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAGMbPlGtJV2b/2dsb2JhbABDxGKBXxZ0gikBAQEEAQEBNzQXBgEIEQQBAQEKFAkuCxQIAQgCBAESCAGICgy+MBeOXSYNBQaCWWEDl3OKQYUWgVSBNoIo
X-IronPort-AV: E=Sophos;i="4.84,825,1355097600"; d="scan'208";a="183206749"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 11 Mar 2013 18:02:58 +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 r2BI2wo2014181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Mar 2013 18:02:58 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 13:02:58 -0500
From: "Reinaldo Penno (repenno)" 
To: Harald Alvestrand , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
Thread-Index: AQHOHoKpVPM3WtZH0EiYxevcVicwOg==
Date: Mon, 11 Mar 2013 18:02:57 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040901B3A9@xmb-rcd-x04.cisco.com>
In-Reply-To: <513E146D.4060009@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.86.245.189]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <343B43A414E95747BCFA6927E424597C@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-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, 11 Mar 2013 18:03:01 -0000

Hello,

On 3/11/13 10:29 AM, "Harald Alvestrand"  wrote:

>On 03/11/2013 06:04 PM, Reinaldo Penno (repenno) wrote:
>> Hello,
>>
>> Why not use Port Control Protocol (PCP) to control Firewalls and NATs
>> explicitly?
>We can switch to that as soon as 100% of firewalls support it - until
>then, we have to be able to rely on other techniques.

I'm sure STUN and TURN servers are not universally deployed ('100%') in
ISP networks either.

But I'm not proposing dropping STUN/TURN in lieu of PCP, but using PCP as
an additional technique. Maybe you misunderstood what I was proposing.


>
>That's the deployment problem in a nutshell... I don't understand how
>the first firewall gets an advantage from having PCP, given that none of
>the apps support it, and I don't understand how the first app gets an
>advantage from having PCP, given that no firewalls support it.
>
>If PCP succeeds despite my misgivings, we can certainly revisit the issue.

I believe it should be considered as a viable option now since it is a
specific protocol to control NATs/Firewalls and Flow-aware devices
required Pv6 CPE requirements document, Broadband Forum and 3GPP specs.



>
>>
>> Thanks,
>>
>> On 3/11/13 9:56 AM, "Hutton, Andrew"
>>  wrote:
>>
>>> FYI - We submitted this draft today it relates to the requirements in
>>>the
>>> use case draft for rtcweb to work in the presence of firewalls and http
>>> proxies etc.
>>>
>>> Look forward to feedback and hope that this can be considered for
>>> adoption by the working group.
>>>
>>> Regards
>>> Andy
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: i-d-announce-bounces@ietf.org
>>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of
>>> internet-drafts@ietf.org
>>> Sent: 11 March 2013 06:01
>>> To: i-d-announce@ietf.org
>>> Subject: I-D Action:
>>> draft-hutton-rtcweb-nat-firewall-considerations-00.txt
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>
>>>
>>> 	Title           : RTCWEB Considerations for NATs, Firewalls and HTTP
>>> proxies
>>> 	Author(s)       : Thomas Stach
>>>                           Andrew Hutton
>>>                           Justin Uberti
>>> 	Filename        :
>>>draft-hutton-rtcweb-nat-firewall-considerations-00.txt
>>> 	Pages           : 8
>>> 	Date            : 2013-03-11
>>>
>>> Abstract:
>>>    This document describes mechanism to enable media stream
>>>    establishment in the presence of NATs, firewalls and HTTP proxies.
>>>    HTTP proxy and firewall policies applied in many private network
>>>    domains introduce obstacles to the successful establishment of media
>>>    stream via RTCWEB.  This document examines some of these policies
>>>and
>>>    develops requirements on the web browsers designed to provide the
>>>    best possible chance of media connectivity between RTCWEB peers.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>>=20
>>>https://datatracker.ietf.org/doc/draft-hutton-rtcweb-nat-firewall-consid
>>>er
>>> ations
>>>
>>> There's also a htmlized version available at:
>>>=20
>>>http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-consideratio
>>>ns
>>> -00
>>>
>>>
>>> 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
>>> _______________________________________________
>>> 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 cb.list6@gmail.com  Mon Mar 11 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 7E5E011E81A7 for ; Mon, 11 Mar 2013 11:07:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.522
X-Spam-Level: 
X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gU2UnKW6COxS for ; Mon, 11 Mar 2013 11:07:28 -0700 (PDT)
Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 97C7B11E81C6 for ; Mon, 11 Mar 2013 11:07:27 -0700 (PDT)
Received: by mail-wg0-f42.google.com with SMTP id 12so2388771wgh.3 for ; Mon, 11 Mar 2013 11:07:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=SvdG8xXBDVEy0bCIgT0OIMMudXJ5AwBnhFhS2ku7o0Y=; b=k9DYzi3Shx58po4Oy7uPH/nP1BtgayNW/8jJ3NdINMcXMunuNxn+jS05UZI00E/EEV IusYrz47Bz7FiXV/zO2fzp8f3uiRxTkknHmOMK51z5p6Tjby6Aj6HttSkSimFGdo6/gE oBewja5W6kOuEQ89MhP8SA6qhbQwxMn08xfpQsOxPYjE8HDbWlZkM0D0YuWct6jCHJJE khEq5PzJp71wJVWnK8W0HBqSjeSfJ9x92/YH/Kfe5s7kwkhQUlROUUkSFB3VNYIvjcG5 mPPYE82xv7qJm5ER/UAtSHKfn4/bHLIsCa6PWpUErkejrG7iF7RrUgftWtv3Hkd/th7f exMA==
MIME-Version: 1.0
X-Received: by 10.194.242.163 with SMTP id wr3mr21144084wjc.35.1363025246459;  Mon, 11 Mar 2013 11:07:26 -0700 (PDT)
Received: by 10.194.20.35 with HTTP; Mon, 11 Mar 2013 11:07:26 -0700 (PDT)
In-Reply-To: <513E146D.4060009@alvestrand.no>
References: <45A697A8FFD7CF48BCF2BE7E106F06040901B274@xmb-rcd-x04.cisco.com> <513E146D.4060009@alvestrand.no>
Date: Mon, 11 Mar 2013 11:07:26 -0700
Message-ID: 
From: Cameron Byrne 
To: Harald Alvestrand 
Content-Type: text/plain; charset=ISO-8859-1
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-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, 11 Mar 2013 18:07:28 -0000

On Mon, Mar 11, 2013 at 10:29 AM, Harald Alvestrand
 wrote:
> On 03/11/2013 06:04 PM, Reinaldo Penno (repenno) wrote:
>>
>> Hello,
>>
>> Why not use Port Control Protocol (PCP) to control Firewalls and NATs
>> explicitly?
>
> We can switch to that as soon as 100% of firewalls support it - until then,
> we have to be able to rely on other techniques.
>
> That's the deployment problem in a nutshell... I don't understand how the
> first firewall gets an advantage from having PCP, given that none of the
> apps support it, and I don't understand how the first app gets an advantage
> from having PCP, given that no firewalls support it.
>
> If PCP succeeds despite my misgivings, we can certainly revisit the issue.
>

I am also pessimistic on PCP being deployed and would rather not
confuse the WebRTC community into thinking PCP is requirement for
WebRTC.  I believe TURN is much better solution.  As mobile network
operator, i feel much more comfortable offering TURN as a solution to
customers than PCP.

CB


>
>>
>> Thanks,
>>
>> On 3/11/13 9:56 AM, "Hutton, Andrew"
>>  wrote:
>>
>>> FYI - We submitted this draft today it relates to the requirements in the
>>> use case draft for rtcweb to work in the presence of firewalls and http
>>> proxies etc.
>>>
>>> Look forward to feedback and hope that this can be considered for
>>> adoption by the working group.
>>>
>>> Regards
>>> Andy
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: i-d-announce-bounces@ietf.org
>>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of
>>> internet-drafts@ietf.org
>>> Sent: 11 March 2013 06:01
>>> To: i-d-announce@ietf.org
>>> Subject: I-D Action:
>>> draft-hutton-rtcweb-nat-firewall-considerations-00.txt
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>
>>>
>>>         Title           : RTCWEB Considerations for NATs, Firewalls and
>>> HTTP
>>> proxies
>>>         Author(s)       : Thomas Stach
>>>                           Andrew Hutton
>>>                           Justin Uberti
>>>         Filename        :
>>> draft-hutton-rtcweb-nat-firewall-considerations-00.txt
>>>         Pages           : 8
>>>         Date            : 2013-03-11
>>>
>>> Abstract:
>>>    This document describes mechanism to enable media stream
>>>    establishment in the presence of NATs, firewalls and HTTP proxies.
>>>    HTTP proxy and firewall policies applied in many private network
>>>    domains introduce obstacles to the successful establishment of media
>>>    stream via RTCWEB.  This document examines some of these policies and
>>>    develops requirements on the web browsers designed to provide the
>>>    best possible chance of media connectivity between RTCWEB peers.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>>
>>> https://datatracker.ietf.org/doc/draft-hutton-rtcweb-nat-firewall-consider
>>> ations
>>>
>>> There's also a htmlized version available at:
>>>
>>> http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations
>>> -00
>>>
>>>
>>> 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
>>> _______________________________________________
>>> 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 jerome.marcon@alcatel-lucent.com  Mon Mar 11 11:51: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 A8F5C21F8E32 for ; Mon, 11 Mar 2013 11:51:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.989
X-Spam-Level: 
X-Spam-Status: No, score=-7.989 tagged_above=-999 required=5 tests=[AWL=-1.740, BAYES_00=-2.599, HELO_EQ_FR=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 NZIUfRVTAT6j for ; Mon, 11 Mar 2013 11:51:57 -0700 (PDT)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id BA08B21F8E1D for ; Mon, 11 Mar 2013 11:51:56 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2BIplUo018527 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 11 Mar 2013 19:51:53 +0100
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 11 Mar 2013 19:51:46 +0100
Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.26]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 11 Mar 2013 19:51:46 +0100
From: "MARCON, JEROME (JEROME)" 
To: Randell Jesup , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt
Thread-Index: AQHOE6kv4waTKhEPkEqZxW6NBQbqlZiVlNqAgAFIbACAAaCdEP//+XgAgAAl0CCAAC/8gIAIC3cR
Date: Mon, 11 Mar 2013 18:51:45 +0000
Message-ID: <39821B4C400EC14DAD4DB25330A9271A024649@FR711WXCHMBA02.zeu.alcatel-lucent.com>
References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> <5135C64A.50302@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02108E@FR711WXCHMBA02.zeu.alcatel-lucent.com> <51371E4A.4040602@ericsson.com> <39821B4C400EC14DAD4DB25330A9271A0214C1@FR711WXCHMBA02.zeu.alcatel-lucent.com>, <51376643.8090204@jesup.org>
In-Reply-To: <51376643.8090204@jesup.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.41]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84
Subject: [rtcweb] RE :  I-D Action: draft-ietf-rtcweb-data-channel-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, 11 Mar 2013 18:51:57 -0000

Randell,

Assuming that some day a spec defines the transport of T.140 (or whatever s=
imilar protocol) over RTCWeb data channels
- with a registered subprotocol
- with multiple reliability options supported
- requiring some new data channel properties
- of which some are assymetric between the endpoints (like the "characters =
per second" defined in [RFC4103].

Then (in the current version of your proposal) it seems to me that
* Because current DATA_CHANNEL_OPEN syntax is not extensible:
- it is not possible to carry these new properties in DATA_CHANNEL_OPEN

* Because the successful response to an open data channel request does not =
exist:
- it is not possible to agree on assymetric property values

* Because the error response to an open data channel has no payload (error)=
:
- an endpoint cannot easily know if this subprotocol is supported or which =
reliability properties are supported. Unless it sends as many DATA_CHANNEL_=
OPEN
 messages as there are combinations of {subprotocol, property variants}

Besides, if after unsuccessful tries (DATA_CHANNEL_OPEN) and errors (close(=
) ), the endpoint decides to go for an SDP renegotiation:
- first this might be for nothing (the peer might not support anything afte=
r all),
- second  the design would be more complex, because for now the proposal as=
sumes that SDP negotiation only happens once, in the offer/answer establish=
ing the SCTP association, when no data channels exist.  =20
  =20
This might have been discussed before, but in the eventually that an inband=
 protocol is really unavoidable (I still hope it is not), another option wo=
uld have been to base this protocol on a new CHUNK type (e.g. Data Channel =
Control CHUNK) carrying request and response parameters in a bi-directional=
 way. Most SCTP extensions are defined this way, aren't they ? And with the=
 additional benefits:
- 1 RTT also
- built-in parameter extensibility
- refined error handling, e.g. report which parameter caused an error
- control messages not mixed with application messages
- proper data channel closing (the use of SSN reset is more like a trick; a=
lso open() and close() messages to not belong to the same protocol/layer)
- ability to define optimized retransmission procedures - those inherited f=
rom user messages might not be the best one=20
- ...
=20
I guess this has been discussed in the past ?

Jerome

________________________________________
De : rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] de la part de Randel=
l Jesup [randell-ietf@jesup.org]
Date d'envoi : mercredi 6 mars 2013 16:52
=C0 : rtcweb@ietf.org
Objet : Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt

On 3/6/2013 7:08 AM, MARCON, JEROME (JEROME) wrote:
> But then - and given that DATA_CHANNEL_OPEN_RESPONSE no longer exists in =
this new draft version - I wonder how the peer can reject an incoming DATA_=
CHANNEL_OPEN message signaling a 'subprotocol' it does not support.

channel.close();

I.e. there's no explicit prior-to-connect rejection, you simply state
instead "I'm not interested" and close it.  This resets the streams, and
causes the other side to be notified of the close. You're correct in
that this is not distinguished from other reasons to close() it; if
those are needed you should either negotiate it out-of-band, or make a
rejection part of the protocol you run over it.  This is entirely within
the application's domain.  Most applications would have no need for this.

--
Randell Jesup
randell-ietf@jesup.org

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

From harald@alvestrand.no  Mon Mar 11 11: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 8E5BE21F8D83 for ; Mon, 11 Mar 2013 11:59:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.702
X-Spam-Level: 
X-Spam-Status: No, score=-110.702 tagged_above=-999 required=5 tests=[AWL=-0.104, 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 MxQ83SzfhWOW for ; Mon, 11 Mar 2013 11:59:17 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 134F121F8D9A for ; Mon, 11 Mar 2013 11:59:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E4D2B39E1C4 for ; Mon, 11 Mar 2013 19:59:08 +0100 (CET)
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 2GhbTYafREcG for ; Mon, 11 Mar 2013 19:59:07 +0100 (CET)
Received: from [IPv6:2001:df8:0:16:b4fd:eac0:98eb:c482] (unknown [IPv6:2001:df8:0:16:b4fd:eac0:98eb:c482]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1FE0A39E1AD for ; Mon, 11 Mar 2013 19:59:05 +0100 (CET)
Message-ID: <513E2972.4000604@alvestrand.no>
Date: Mon, 11 Mar 2013 19:58:58 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References:  
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000503090105010509080706"
Subject: Re: [rtcweb] VP8 litigation in Germany?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 11 Mar 2013 18:59:20 -0000

This is a multi-part message in MIME format.
--------------000503090105010509080706
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thanks for the comment - I've been in contact with our legal people too, 
and they say that German process rules say that we can't comment on the 
ongoing legal case (even beyond our usual "we don't comment on ongoing 
legal processes").

We'll comment once the case is resolved, I guess.

On 03/11/2013 04:06 PM, Markus.Isomaki@nokia.com wrote:
>
> Hi all,
>
> I am not personally aware of any more details of this case than what is included below. However, I have been in contact with the Nokia Legal department about it. It is true that Nokia believes we have IPR related to VP8. Although the disclosure obligations are not entirely clear in this case as seen e.g. in [1], Nokia is preparing to do a disclosure about it to the IETF, "to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible", as stated in RFC 3979. That's all the information I have right now, but I will keep this list updated as soon as something new comes up.
>   
> [1]http://www.ietf.org/mail-archive/web/rtcweb/current/msg06578.html
>
> Markus
>
> *From:*rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On 
> Behalf Of *ext Stephan Wenger
> *Sent:* 10 March, 2013 04:32
> *To:* rtcweb@ietf.org
> *Subject:* [rtcweb] VP8 litigation in Germany?
>
> Hi,
>
> An additional data point.
>
> Florian Mueller writes in his patent blog 
> (http://www.fosspatents.com/2013/03/patent-clouds-remain-over-vp8-google.html) 
> that he has attended a court hearing in Mannheim, Germany, where, 
> according to his blog, "Counsel for Nokia indeed based the 
> infringement allegation in no small part on what the specifications of 
> the Google-controlled VP8 standard say, which is an unmistakable sign 
> that Nokia considers EP1206881 to be inevitably infringed by all 
> implementations of VP8."
>
> Now, I understand that Mr. Mueller is not particularly highly regarded 
> by a whole bunch of people in the open source community.  I myself 
> find a number of other statements in this blog post, however carefully 
> worded, somewhat questionable.  OTOH, I consider it very unlikely that 
> he made up all those reported facts.
>
> That my former colleagues in Nokia decide to sue over this patent (if 
> they have done so) does, of course, not mean that the VP8 
> implementation of HTC infringes, let alone all VP8 implementations. 
>  Quite likely we will never know either way---most patent lawsuits are 
> settled out of court.
>
> One other data point: Mr. Mueller is correct in that Nokia is not a 
> member of the H.264 pool.  Nor are they members in any other video 
> coding related patent pool that I'm aware of, despite IMO having one 
> of the strongest video coding research teams in the industry (I was 
> part of that myself, a while ago).
>
> Regards,
>
> Stephan
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--------------000503090105010509080706
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Thanks for the comment - I've been in
      contact with our legal people too, and they say that German
      process rules say that we can't comment on the ongoing legal case
      (even beyond our usual "we don't comment on ongoing legal
      processes").

      

      We'll comment once the case is resolved, I guess.

      

      On 03/11/2013 04:06 PM, Markus.Isomaki@nokia.com wrote:

    

    

      
      
      
      

        
Hi
            all,

        
 

        
I am not personally aware of any more details of this case than what is included below. However, I have been in contact with the Nokia Legal department about it. It is true that Nokia believes we have IPR related to VP8. Although the disclosure obligations are not entirely clear in this case as seen e.g. in [1], Nokia is preparing to do a disclosure about it to the IETF, “to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible”, as stated in RFC 3979. That’s all the information I have right now, but I will keep this list updated as soon as something new comes up.

        
 

        
[1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg06578.html

        
 

        
Markus
            

        
  

        
 

        

          

            

              
From:
                  rtcweb-bounces@ietf.org
                  [mailto:rtcweb-bounces@ietf.org]
                  On Behalf Of ext Stephan Wenger

                  Sent: 10 March, 2013 04:32

                  To: rtcweb@ietf.org

                  Subject: [rtcweb] VP8 litigation in Germany?

            

          

          
 

          

            
Hi,

          

          

            
An
                additional data point.

          

          

            
Florian
                Mueller writes in his patent blog (http://www.fosspatents.com/2013/03/patent-clouds-remain-over-vp8-google.html)
                that he has attended a court hearing in Mannheim,
                Germany, where, according to his blog, "Counsel for
                Nokia indeed based the infringement allegation in no
                small part on what the specifications of the
                Google-controlled VP8 standard say, which is an
                unmistakable sign that Nokia considers EP1206881 to be
                inevitably infringed by all implementations of VP8."

          

          

            
Now,
                I understand that Mr. Mueller is not particularly highly
                regarded by a whole bunch of people in the open source
                community.  I myself find a number of other statements
                in this blog post, however carefully worded, somewhat
                questionable.  OTOH, I consider it very unlikely that he
                made up all those reported facts.

          

          

            
That
                my former colleagues in Nokia decide to sue over this
                patent (if they have done so) does, of course, not mean
                that the VP8 implementation of HTC infringes, let alone
                all VP8 implementations.  Quite likely we will never
                know either way—most patent lawsuits are settled out of
                court.

          

          

            
One
                other data point: Mr. Mueller is correct in that Nokia
                is not a member of the H.264 pool.  Nor are they members
                in any other video coding related patent pool that I'm
                aware of, despite IMO having one of the strongest video
                coding research teams in the industry (I was part of
                that myself, a while ago).  

          

          

            
Regards,

          

          

            
Stephan

          

          

            
 

          

        

      

      

      

      

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


    

    

  


--------------000503090105010509080706--

From ted.ietf@gmail.com  Mon Mar 11 12:06: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 C78FE21F8F67 for ; Mon, 11 Mar 2013 12:06:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.581
X-Spam-Level: 
X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.019,  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 3XqRTeKHUoiw for ; Mon, 11 Mar 2013 12:06:26 -0700 (PDT)
Received: from mail-ia0-x235.google.com (mail-ia0-x235.google.com [IPv6:2607:f8b0:4001:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0A65121F8ECB for ; Mon, 11 Mar 2013 12:06:25 -0700 (PDT)
Received: by mail-ia0-f181.google.com with SMTP id w33so3960150iag.26 for ; Mon, 11 Mar 2013 12:06:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=RJFTvHEN8d/NZ6qT/+OhM1gdL6d23GLpjE2gioBpBgA=; b=blQFR9MxPEu9WhMTAeXYsS2GtbpXF2UXAP+wk9W+Jlxi2sKIV3U+KXo2XZ5PajC2Du SeAANbGF6gh5c3pdAqZy+rQe9z/vrCf40/Tcq9K0abzhWr5RVAHMH5YnSnbnUqh0C9aH 70LG3tw6Jx91h9yuSaCGhYrnGIq19HY0deoagNZDhKsel/ZL6URe7Cs6JUyaBfnsu9Qx T4UpCxv4XVZTUYjiszQeYTVhk7XxEEKycO8uhvAfiU5+D2zx4NpTFTv77cFFa7r0vTNb eLYSLR3g18Nu0g/hG+ZjOgjFBjihISLELgd1GU1GbRe3r+4Jz4cvnAzNNctRaU+annkC sK+g==
MIME-Version: 1.0
X-Received: by 10.50.88.199 with SMTP id bi7mr8578240igb.70.1363028785562; Mon, 11 Mar 2013 12:06:25 -0700 (PDT)
Received: by 10.43.135.202 with HTTP; Mon, 11 Mar 2013 12:06:25 -0700 (PDT)
In-Reply-To: 
References:  
Date: Mon, 11 Mar 2013 15:06:25 -0400
Message-ID: 
From: Ted Hardie 
To: Markus.Isomaki@nokia.com
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 litigation in Germany?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 11 Mar 2013 19:06:27 -0000

Hi Markus,

Just confirm my understanding of this:

On Mon, Mar 11, 2013 at 11:06 AM,   wrote:
>Nokia is preparing to do a disclosure about it to the
> IETF, =93to ensure that IETF working groups and participants have as much
> information about any IPR constraints on a technical proposal as possible=
=94,
> as stated in RFC 3979. That=92s all the information I have right now, but=
 I
> will keep this list updated as soon as something new comes up.

this disclosure will cover both H.264 and VP8, as they are the two
technical proposals?

regards,

Ted Hardie

From harald@alvestrand.no  Mon Mar 11 12:22: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 A378C11E81EB for ; Mon, 11 Mar 2013 12:22:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.688
X-Spam-Level: 
X-Spam-Status: No, score=-110.688 tagged_above=-999 required=5 tests=[AWL=-0.089, 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 xMzMMkAlU+n1 for ; Mon, 11 Mar 2013 12:22:30 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 086EB11E8120 for ; Mon, 11 Mar 2013 12:22:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C04ED39E1C4 for ; Mon, 11 Mar 2013 20:22:27 +0100 (CET)
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 oOYmBBHZH4Lm for ; Mon, 11 Mar 2013 20:22:27 +0100 (CET)
Received: from [IPv6:2001:df8:0:16:b4fd:eac0:98eb:c482] (unknown [IPv6:2001:df8:0:16:b4fd:eac0:98eb:c482]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 8226939E1AD for ; Mon, 11 Mar 2013 20:22:26 +0100 (CET)
Message-ID: <513E2EEE.3050106@alvestrand.no>
Date: Mon, 11 Mar 2013 20:22:22 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> <5135C64A.50302@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02108E@FR711WXCHMBA02.zeu.alcatel-lucent.com> <51371E4A.4040602@ericsson.com> <39821B4C400EC14DAD4DB25330A9271A0214C1@FR711WXCHMBA02.zeu.alcatel-lucent.com>, <51376643.8090204@jesup.org> <39821B4C400EC14DAD4DB25330A9271A024649@FR711WXCHMBA02.zeu.alcatel-lucent.com>
In-Reply-To: <39821B4C400EC14DAD4DB25330A9271A024649@FR711WXCHMBA02.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] RE : I-D Action: draft-ietf-rtcweb-data-channel-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, 11 Mar 2013 19:22:30 -0000

On 03/11/2013 07:51 PM, MARCON, JEROME (JEROME) wrote:
> Randell,
>
> Assuming that some day a spec defines the transport of T.140 (or whatever similar protocol) over RTCWeb data channels
> - with a registered subprotocol
> - with multiple reliability options supported
> - requiring some new data channel properties
> - of which some are assymetric between the endpoints (like the "characters per second" defined in [RFC4103].
>
> Then (in the current version of your proposal) it seems to me that
> * Because current DATA_CHANNEL_OPEN syntax is not extensible:
> - it is not possible to carry these new properties in DATA_CHANNEL_OPEN
>
> * Because the successful response to an open data channel request does not exist:
> - it is not possible to agree on assymetric property values
>
> * Because the error response to an open data channel has no payload (error):
> - an endpoint cannot easily know if this subprotocol is supported or which reliability properties are supported. Unless it sends as many DATA_CHANNEL_OPEN
>   messages as there are combinations of {subprotocol, property variants}

Is there any reason why the app that desires to use such a protocol over 
a data channel shouldn't send a new message (defined in the protocol) 
after the DATA_CHANNEL_OPEN saying what the desired properties are, and 
with an accept/reject message on the return channel?

One of the desirable properties of DATA_CHANNEL_OPEN is that it's 
simple. I'd like to keep it that way.


From Michael.Tuexen@lurchi.franken.de  Mon Mar 11 12:23: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 68F5C11E81F0 for ; Mon, 11 Mar 2013 12:23: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 rUXl3CW9eQ3G for ; Mon, 11 Mar 2013 12:23:54 -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 4A6DD11E8121 for ; Mon, 11 Mar 2013 12:23:54 -0700 (PDT)
Received: from dhcp-9228.meeting.ietf.org (dhcp-9228.meeting.ietf.org [130.129.10.40]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 7970C1C0C0BF5; Mon, 11 Mar 2013 20:23:51 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=iso-8859-1
From: Michael Tuexen 
In-Reply-To: <39821B4C400EC14DAD4DB25330A9271A024649@FR711WXCHMBA02.zeu.alcatel-lucent.com>
Date: Mon, 11 Mar 2013 15:23:50 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <2024BD14-E25C-426F-B046-46D61AF7077C@lurchi.franken.de>
References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> <5135C64A.50302@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02108E@FR711WXCHMBA02.zeu.alcatel-lucent.com> <51371E4A.4040602@ericsson.com> <39821B4C400EC14DAD4DB25330A9271A0214C1@FR711WXCHMBA02.zeu.alcatel-lucent.com>, <51376643.8090204@jesup.org> <39821B4C400EC14DAD4DB25330A9271A024649@FR711WXCHMBA02.zeu.alcatel-lucent.com>
To: "MARCON, JEROME (JEROME)" 
X-Mailer: Apple Mail (2.1283)
Cc: Randell Jesup , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-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, 11 Mar 2013 19:23:55 -0000

On Mar 11, 2013, at 2:51 PM, MARCON, JEROME (JEROME) wrote:

> Randell,
>=20
> Assuming that some day a spec defines the transport of T.140 (or =
whatever similar protocol) over RTCWeb data channels
> - with a registered subprotocol
> - with multiple reliability options supported
> - requiring some new data channel properties
> - of which some are assymetric between the endpoints (like the =
"characters per second" defined in [RFC4103].
>=20
> Then (in the current version of your proposal) it seems to me that
> * Because current DATA_CHANNEL_OPEN syntax is not extensible:
> - it is not possible to carry these new properties in =
DATA_CHANNEL_OPEN
Why is it not extensible? We have a message type and you could simply
define another message...
>=20
> * Because the successful response to an open data channel request does =
not exist:
> - it is not possible to agree on assymetric property values
>=20
> * Because the error response to an open data channel has no payload =
(error):
> - an endpoint cannot easily know if this subprotocol is supported or =
which reliability properties are supported. Unless it sends as many =
DATA_CHANNEL_OPEN
> messages as there are combinations of {subprotocol, property variants}
>=20
> Besides, if after unsuccessful tries (DATA_CHANNEL_OPEN) and errors =
(close() ), the endpoint decides to go for an SDP renegotiation:
> - first this might be for nothing (the peer might not support anything =
after all),
> - second  the design would be more complex, because for now the =
proposal assumes that SDP negotiation only happens once, in the =
offer/answer establishing the SCTP association, when no data channels =
exist.  =20
>=20
> This might have been discussed before, but in the eventually that an =
inband protocol is really unavoidable (I still hope it is not), another =
option would have been to base this protocol on a new CHUNK type (e.g. =
Data Channel Control CHUNK) carrying request and response parameters in =
a bi-directional way. Most SCTP extensions are defined this way, aren't =
they ? And with the additional benefits:
I don't think it makes sense to extend SCTP instead of doing this on top =
of SCTP, if you need.

Best regards
Michael
> - 1 RTT also
> - built-in parameter extensibility
> - refined error handling, e.g. report which parameter caused an error
> - control messages not mixed with application messages
> - proper data channel closing (the use of SSN reset is more like a =
trick; also open() and close() messages to not belong to the same =
protocol/layer)
> - ability to define optimized retransmission procedures - those =
inherited from user messages might not be the best one=20
> - ...
>=20
> I guess this has been discussed in the past ?
>=20
> Jerome
>=20
> ________________________________________
> De : rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] de la part de =
Randell Jesup [randell-ietf@jesup.org]
> Date d'envoi : mercredi 6 mars 2013 16:52
> =C0 : rtcweb@ietf.org
> Objet : Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt
>=20
> On 3/6/2013 7:08 AM, MARCON, JEROME (JEROME) wrote:
>> But then - and given that DATA_CHANNEL_OPEN_RESPONSE no longer exists =
in this new draft version - I wonder how the peer can reject an incoming =
DATA_CHANNEL_OPEN message signaling a 'subprotocol' it does not support.
>=20
> channel.close();
>=20
> I.e. there's no explicit prior-to-connect rejection, you simply state
> instead "I'm not interested" and close it.  This resets the streams, =
and
> causes the other side to be notified of the close. You're correct in
> that this is not distinguished from other reasons to close() it; if
> those are needed you should either negotiate it out-of-band, or make a
> rejection part of the protocol you run over it.  This is entirely =
within
> the application's domain.  Most applications would have no need for =
this.
>=20
> --
> Randell Jesup
> randell-ietf@jesup.org
>=20
> _______________________________________________
> 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 hannes.tschofenig@gmx.net  Mon Mar 11 12:34: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 6240521F8E5A for ; Mon, 11 Mar 2013 12:34:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.425
X-Spam-Level: 
X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156, 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 g02SdqHG-Vin for ; Mon, 11 Mar 2013 12:34:31 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id B2FDA21F8E53 for ; Mon, 11 Mar 2013 12:34:30 -0700 (PDT)
Received: from mailout-de.gmx.net ([10.1.76.24]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LgsnI-1UZZoY022o-00oBlG for ; Mon, 11 Mar 2013 20:34:28 +0100
Received: (qmail invoked by alias); 11 Mar 2013 19:34:27 -0000
Received: from dhcp-1077.meeting.ietf.org (EHLO dhcp-1077.meeting.ietf.org) [130.129.16.119] by mail.gmx.net (mp024) with SMTP; 11 Mar 2013 20:34:27 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+/zG4nvoq/kMNOnnAOswxeujApiMum58K6Wnk9B9 JZmv17uIOMLpcJ
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Hannes Tschofenig 
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040901B3A9@xmb-rcd-x04.cisco.com>
Date: Mon, 11 Mar 2013 15:34:25 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <32A40EF5-E012-49CF-AC73-6F354700B900@gmx.net>
References: <45A697A8FFD7CF48BCF2BE7E106F06040901B3A9@xmb-rcd-x04.cisco.com>
To: "Reinaldo Penno (repenno)" 
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-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, 11 Mar 2013 19:34:31 -0000

On Mar 11, 2013, at 2:02 PM, Reinaldo Penno (repenno) wrote:

>>> Why not use Port Control Protocol (PCP) to control Firewalls and =
NATs
>>> explicitly?
>> We can switch to that as soon as 100% of firewalls support it - until
>> then, we have to be able to rely on other techniques.
>=20
> I'm sure STUN and TURN servers are not universally deployed ('100%') =
in
> ISP networks either.

STUN and TURN don't require any support from ISPs. Both protocols are =
used today.=20
Your co-worker Jonathan Rosenberg worked on these mechanisms and Cisco =
also supports them ;-)

Ciao
Hannes


From repenno@cisco.com  Mon Mar 11 12: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 2215221F8EE6 for ; Mon, 11 Mar 2013 12:52:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.443
X-Spam-Level: 
X-Spam-Status: No, score=-10.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eixy9GB4FAdw for ; Mon, 11 Mar 2013 12:52:42 -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 4BD4121F8EA7 for ; Mon, 11 Mar 2013 12:52:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=978; q=dns/txt; s=iport; t=1363031562; x=1364241162; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/LlLnqC4IeNvcZfH5Y7hvpqjtiNSZY615lCS3bg5y8c=; b=cAUc01QRCsoKME2CbI8wmEXQyCJ+PczBBkg9LQf//IuOC3snB19RUGUC RpyXNeI0qXYBoN2VNGpzWVV0oNA27D6Ge+8e8yON8Rg3rQKUBUTF9JhJ7 0BOER0EUTUgTfxXd5bA8ZBM2Ioz3Im19E5e0Otm1WmUmzZK7GrsxEbgxo 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAFg1PlGtJXG//2dsb2JhbABDxGaBXxZ0gikBAQEEOj8SAQgYChRCHAkCBA4FCId5Aw+/U4xGghcxB4JfYQOnSoFUgTaCKA
X-IronPort-AV: E=Sophos;i="4.84,825,1355097600"; d="scan'208";a="186028050"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 11 Mar 2013 19:52:42 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2BJqfxK007394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Mar 2013 19:52:41 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 14:52:41 -0500
From: "Reinaldo Penno (repenno)" 
To: Hannes Tschofenig 
Thread-Topic: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
Thread-Index: AQHOHoKpVPM3WtZH0EiYxevcVicwOpihNayA//+PwQA=
Date: Mon, 11 Mar 2013 19:52:41 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040901B656@xmb-rcd-x04.cisco.com>
In-Reply-To: <32A40EF5-E012-49CF-AC73-6F354700B900@gmx.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.21.116.59]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-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, 11 Mar 2013 19:52:43 -0000

On 3/11/13 12:34 PM, "Hannes Tschofenig"  wrote:

>
>On Mar 11, 2013, at 2:02 PM, Reinaldo Penno (repenno) wrote:
>
>>>> Why not use Port Control Protocol (PCP) to control Firewalls and NATs
>>>> explicitly?
>>> We can switch to that as soon as 100% of firewalls support it - until
>>> then, we have to be able to rely on other techniques.
>>=20
>> I'm sure STUN and TURN servers are not universally deployed ('100%') in
>> ISP networks either.
>
>STUN and TURN don't require any support from ISPs.

If ISPs want to provide RTCweb like services don't they need STUN and TURN
Servers so that ICE can gather candidates?

>Both protocols are used today.

Yes, today. But that did not stop design decisions to include these
protocols in ICE at a they time were not deployed at all.

>=20
>Your co-worker Jonathan Rosenberg worked on these mechanisms and Cisco
>also supports them ;-)

Certainly.=20

>
>Ciao
>Hannes
>


From simon.perreault@viagenie.ca  Mon Mar 11 12:58: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 AEFE121F8F8A for ; Mon, 11 Mar 2013 12:58:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.521
X-Spam-Level: 
X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7k+8QhNJwyah for ; Mon, 11 Mar 2013 12:58:15 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBBA21F8EE6 for ; Mon, 11 Mar 2013 12:58:04 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2001:df8:0:16:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5850240167 for ; Mon, 11 Mar 2013 15:57:33 -0400 (EDT)
Message-ID: <513E372C.6060405@viagenie.ca>
Date: Mon, 11 Mar 2013 15:57:32 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <45A697A8FFD7CF48BCF2BE7E106F06040901B656@xmb-rcd-x04.cisco.com>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040901B656@xmb-rcd-x04.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-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, 11 Mar 2013 19:58:16 -0000

Le 2013-03-11 15:52, Reinaldo Penno (repenno) a écrit :
>> STUN and TURN don't require any support from ISPs.
>
> If ISPs want to provide RTCweb like services don't they need STUN and TURN
> Servers so that ICE can gather candidates?

An example of freely-accessible non-ISP STUN/TURN service: 
http://numb.viagenie.ca

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 andrew.hutton@siemens-enterprise.com  Mon Mar 11 12:58: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 68A8721F8FA4 for ; Mon, 11 Mar 2013 12:58:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.479
X-Spam-Level: 
X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGZUKNv0uEoR for ; Mon, 11 Mar 2013 12:58:16 -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 7D67521F8DC5 for ; Mon, 11 Mar 2013 12:58:15 -0700 (PDT)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 155D81EB84BE; Mon, 11 Mar 2013 20:58:09 +0100 (CET)
Received: from MCHP04MSX.global-ad.net ([169.254.1.94]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0328.009; Mon, 11 Mar 2013 20:58:08 +0100
From: "Hutton, Andrew" 
To: "Reinaldo Penno (repenno)" , Harald Alvestrand , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
Thread-Index: AQHOHoKpQPNB80XASUa1nEzDk7aFy5ig5ncw
Date: Mon, 11 Mar 2013 19:58:08 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF06895013@MCHP04MSX.global-ad.net>
References: <513E146D.4060009@alvestrand.no> <45A697A8FFD7CF48BCF2BE7E106F06040901B3A9@xmb-rcd-x04.cisco.com>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040901B3A9@xmb-rcd-x04.cisco.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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-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, 11 Mar 2013 19:58:20 -0000

On: 11 March 2013 14:03 Reinaldo Penno (repenno) Wrote:


>=20
> I'm sure STUN and TURN servers are not universally deployed ('100%') in
> ISP networks either.

It is not required for an ISP to deploy a TURN server the webrtc TURN serve=
r is much more likely to be deployed by the web application provider which =
will instruct the browser to use it when accessing its service.

>=20
> But I'm not proposing dropping STUN/TURN in lieu of PCP, but using PCP
> as
> an additional technique. Maybe you misunderstood what I was proposing.
>=20

Understood but would need to understand what the benefits of doing so would=
 be.

Regards
Andy

From repenno@cisco.com  Mon Mar 11 13:01: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 35C3A21F8CBE for ; Mon, 11 Mar 2013 13:01:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.482
X-Spam-Level: 
X-Spam-Status: No, score=-10.482 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBTMhoVMQpN7 for ; Mon, 11 Mar 2013 13:01:46 -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 DF1EE21F8C35 for ; Mon, 11 Mar 2013 13:01:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=842; q=dns/txt; s=iport; t=1363032106; x=1364241706; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=vk9q+l+0MrEiEwK1/3TJirXPGw2jspCxE62K5zYYq6k=; b=mN1sfNEc5UhFVZ79WIR6z93zwxqtmBXNg+7cbsqLo3dgOjhE9MwwWo5r XAVpydN5encSA+wqKFcOKlob/JG1+7J+difmCtRbbSBgCDgrsAiGeIF7N S+vrlB1k8tj+PucCklHZiiUzT0Tq3uuLn+jZe6D1S8QhThppBpve/0x5c U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgFACY3PlGtJV2b/2dsb2JhbABDh2S9AoFfFnSCKQEBAQQBAQEkRx0BCCJLCxwJAgQBEgiICwy/TY5dOIJfYQOIPI83j1eBVIE2gig
X-IronPort-AV: E=Sophos;i="4.84,825,1355097600"; d="scan'208";a="186219628"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 11 Mar 2013 20:01:45 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2BK1jIC031650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Mar 2013 20:01:45 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 15:01:45 -0500
From: "Reinaldo Penno (repenno)" 
To: Simon Perreault , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
Thread-Index: AQHOHpNBxccKfXwcAkGpPlGeyd8T3Q==
Date: Mon, 11 Mar 2013 20:01:44 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040901B8B9@xmb-rcd-x04.cisco.com>
In-Reply-To: <513E372C.6060405@viagenie.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.21.116.59]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <2E20F5A3E8BFF1469479C6842F5DACA4@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-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, 11 Mar 2013 20:01:47 -0000

I meant an ISP provided service, not a "hoping over the ISP" scenario.

On 3/11/13 12:57 PM, "Simon Perreault"  wrote:

>Le 2013-03-11 15:52, Reinaldo Penno (repenno) a =E9crit :
>>> STUN and TURN don't require any support from ISPs.
>>
>> If ISPs want to provide RTCweb like services don't they need STUN and
>>TURN
>> Servers so that ICE can gather candidates?
>
>An example of freely-accessible non-ISP STUN/TURN service:
>http://numb.viagenie.ca
>
>Simon
>--=20
>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
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb


From harald@alvestrand.no  Mon Mar 11 13:04: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 8A98821F8E5F for ; Mon, 11 Mar 2013 13:04:25 -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.156, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156, 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 qNYJXbabTn5X for ; Mon, 11 Mar 2013 13:04:25 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8226C21F8E67 for ; Mon, 11 Mar 2013 13:04:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 896F539E1C4; Mon, 11 Mar 2013 21:04:22 +0100 (CET)
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 ki67uJAGX8Ew; Mon, 11 Mar 2013 21:04:22 +0100 (CET)
Received: from [IPv6:2001:df8:0:16:b4fd:eac0:98eb:c482] (unknown [IPv6:2001:df8:0:16:b4fd:eac0:98eb:c482]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1D95539E1AD; Mon, 11 Mar 2013 21:04:20 +0100 (CET)
Message-ID: <513E38BD.6070105@alvestrand.no>
Date: Mon, 11 Mar 2013 21:04:13 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: "Reinaldo Penno (repenno)" 
References: <45A697A8FFD7CF48BCF2BE7E106F06040901B656@xmb-rcd-x04.cisco.com>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040901B656@xmb-rcd-x04.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-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, 11 Mar 2013 20:04:25 -0000

On 03/11/2013 08:52 PM, Reinaldo Penno (repenno) wrote:
>
> On 3/11/13 12:34 PM, "Hannes Tschofenig"  wrote:
>
>> On Mar 11, 2013, at 2:02 PM, Reinaldo Penno (repenno) wrote:
>>
>>>>> Why not use Port Control Protocol (PCP) to control Firewalls and NATs
>>>>> explicitly?
>>>> We can switch to that as soon as 100% of firewalls support it - until
>>>> then, we have to be able to rely on other techniques.
>>> I'm sure STUN and TURN servers are not universally deployed ('100%') in
>>> ISP networks either.
>> STUN and TURN don't require any support from ISPs.
> If ISPs want to provide RTCweb like services don't they need STUN and TURN
> Servers so that ICE can gather candidates?

ISPs may want to offer services. But that's independent of their role as 
ISPs.
Anyone can offer a STUN or TURN server, and they can be anywhere on the 
Internet.

PCP, on the other hand, has to be available on the specific firewall or 
NAT box you intend to traverse. If it isn't there, it won't work.
>> Both protocols are used today.
> Yes, today. But that did not stop design decisions to include these
> protocols in ICE at a they time were not deployed at all.

Sorry, I can't parse that.

ICE was deployed to support applications that needed ICE; there was no 
need to deploy more than 1 STUN/TURN server in order to start using STUN 
and TURN.


From repenno@cisco.com  Mon Mar 11 13: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 5965B21F8F63 for ; Mon, 11 Mar 2013 13:11:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.443
X-Spam-Level: 
X-Spam-Status: No, score=-10.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfxM5PHMO95d for ; Mon, 11 Mar 2013 13:11:37 -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 19F0421F8F5C for ; Mon, 11 Mar 2013 13:11:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1910; q=dns/txt; s=iport; t=1363032697; x=1364242297; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=THDXfsbXRfvr1ntPawXLZKN9DdrfBaqve8cz/KAWKsY=; b=arylarLyX6BGP0p4SMGPG5tcxhp9ZphcXqCJTB6pF6lZ7QX1sUpVGlH7 oxOsxO2XsdUaniMpMedyrHjQKhvttujOngCZcvfPbD+HD6Q8zGJ96D1SH FxRKd1hyO1m5zi+ygvHU0COg2P3HMxV6+q0j51Ya9Zi8q8igzW2qbHlV7 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFABM5PlGtJV2c/2dsb2JhbABDxGaBXxZ0gikBAQEDATo/EgEIGAoUQhwJAgQOBQgTh2YDCQa/XoxGghcxB4JfYQOTEJQ6gVSBNoIo
X-IronPort-AV: E=Sophos;i="4.84,825,1355097600"; d="scan'208";a="186291048"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 11 Mar 2013 20:11:36 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2BKBaHQ030797 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Mar 2013 20:11:36 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 15:11:36 -0500
From: "Reinaldo Penno (repenno)" 
To: Harald Alvestrand 
Thread-Topic: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
Thread-Index: AQHOHoKpVPM3WtZH0EiYxevcVicwOpihNayA//+PwQCAAHiSgP//jLSA
Date: Mon, 11 Mar 2013 20:11:35 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040901B8D6@xmb-rcd-x04.cisco.com>
In-Reply-To: <513E38BD.6070105@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.21.116.59]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1BFF60CE95AE1C4E92C0C3CDF2EA9575@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-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, 11 Mar 2013 20:11:38 -0000

On 3/11/13 1:04 PM, "Harald Alvestrand"  wrote:

>On 03/11/2013 08:52 PM, Reinaldo Penno (repenno) wrote:
>>
>> On 3/11/13 12:34 PM, "Hannes Tschofenig" 
>>wrote:
>>
>>> On Mar 11, 2013, at 2:02 PM, Reinaldo Penno (repenno) wrote:
>>>
>>>>>> Why not use Port Control Protocol (PCP) to control Firewalls and
>>>>>>NATs
>>>>>> explicitly?
>>>>> We can switch to that as soon as 100% of firewalls support it - until
>>>>> then, we have to be able to rely on other techniques.
>>>> I'm sure STUN and TURN servers are not universally deployed ('100%')
>>>>in
>>>> ISP networks either.
>>> STUN and TURN don't require any support from ISPs.
>> If ISPs want to provide RTCweb like services don't they need STUN and
>>TURN
>> Servers so that ICE can gather candidates?
>
>ISPs may want to offer services. But that's independent of their role as
>ISPs.
>Anyone can offer a STUN or TURN server, and they can be anywhere on the
>Internet.
>
>PCP, on the other hand, has to be available on the specific firewall or
>NAT box you intend to traverse. If it isn't there, it won't work.

Yes, but on the other hand you deterministically get an IP address:port or
pinhole (both for incoming and outgoing connections) for a specific
lifetime instead of relying on outbound connections, keep-alives, and
external server.=20

The point is that if the FW/NAT supports PCP, the solution is certainly
cleaner. Client is always free to fallback to STUN/TURN/indirect ways.


>>> Both protocols are used today.
>> Yes, today. But that did not stop design decisions to include these
>> protocols in ICE at a they time were not deployed at all.
>
>Sorry, I can't parse that.
>
>ICE was deployed to support applications that needed ICE; there was no
>need to deploy more than 1 STUN/TURN server in order to start using STUN
>and TURN.
>


From repenno@cisco.com  Mon Mar 11 13:14: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 402D821F8FA5 for ; Mon, 11 Mar 2013 13:14:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.443
X-Spam-Level: 
X-Spam-Status: No, score=-10.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3l6WoWujnOFG for ; Mon, 11 Mar 2013 13:14:25 -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 9E8D021F8FA4 for ; Mon, 11 Mar 2013 13:14:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1202; q=dns/txt; s=iport; t=1363032865; x=1364242465; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=ej7pfv28ypmQm8EedkE2y/iRjf2tSTzDHUDuFV/IPA4=; b=QsaQb6pNSv+k2i4BG/CdLxSVWd9iDnEnlNgWcKhOODDnMDj6lL+0333Y kuYahPJRSJzU//ULpzDkhjwW0Yrptn0HKbP7K181IAOyqK34Gq+OYcA1V ArSwvYRT6bcz673sqAhe3S70brY4cHR9D8q3etnVeah6L5vL52osAFhOa g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAIY5PlGtJXG+/2dsb2JhbABDxGaBXxZ0gikBAQEEOlEBCBgKFEIcCQIEARIIiAu/Xo1DgRo4gl9hA6dKgVSBNoFzNQ
X-IronPort-AV: E=Sophos;i="4.84,825,1355097600"; d="scan'208";a="186223763"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 11 Mar 2013 20:14:25 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2BKEPON024070 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Mar 2013 20:14:25 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 15:14:24 -0500
From: "Reinaldo Penno (repenno)" 
To: "Hutton, Andrew" , Harald Alvestrand , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
Thread-Index: AQHOHoKpVPM3WtZH0EiYxevcVicwOpihPEwA//+PMoA=
Date: Mon, 11 Mar 2013 20:14:24 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040901B8ED@xmb-rcd-x04.cisco.com>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF06895013@MCHP04MSX.global-ad.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.21.116.59]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-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, 11 Mar 2013 20:14:26 -0000

On 3/11/13 12:58 PM, "Hutton, Andrew"
 wrote:

>On: 11 March 2013 14:03 Reinaldo Penno (repenno) Wrote:
>
>
>>=20
>> I'm sure STUN and TURN servers are not universally deployed ('100%') in
>> ISP networks either.
>
>It is not required for an ISP to deploy a TURN server the webrtc TURN
>server is much more likely to be deployed by the web application provider
>which will instruct the browser to use it when accessing its service.

The line between Application providers and ISPs is very blurry today.
Application provider can be over the top or it can be the ISP itself.


>
>>=20
>> But I'm not proposing dropping STUN/TURN in lieu of PCP, but using PCP
>> as
>> an additional technique. Maybe you misunderstood what I was proposing.
>>=20
>
>Understood but would need to understand what the benefits of doing so
>would be.


Yes, certainly.

A protocol that allows a host to explicit control FW/NAT mappings/pinholes
(both for incoming and outgoing connections IPv4/IPv6), including
lifetime, knowing when such device restart/reboot, is more deterministic.
Client is always free to use STUN/TURN.


>
>Regards
>Andy


From ekr@rtfm.com  Mon Mar 11 13:54: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 2D89021F8DEF for ; Mon, 11 Mar 2013 13:54:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.977
X-Spam-Level: 
X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 6C8lLVyNrx2C for ; Mon, 11 Mar 2013 13:54:22 -0700 (PDT)
Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id E63C921F8E01 for ; Mon, 11 Mar 2013 13:54:21 -0700 (PDT)
Received: by mail-qc0-f179.google.com with SMTP id b40so1714950qcq.38 for ; Mon, 11 Mar 2013 13:54:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=Gdg+0qWpWin6YdN0M1q8M1P6Ppjl13dAF+kQ3aJ2+WA=; b=l36kxNhfPKUcS3dAjNxOSICKIXuCWGUPDV7faBCM7y03SYrVbV3QFtMVhXuuc/CNVW X5DNHXVYFqgKYPzYvYBMEfmSg85trVfdcuPxQP2PKRPCcgVsRAsWmj9wa76eRrPKlfnn Lyh1gxL4ZMyigmlH/1uDYkbMp49u36I5rlgjuXmHbUeWO+HuVbEdOR9DTGMZZgvK5rkM 55hJBhVS7J0jutw7n3eYS118i3iXBpcY+ATqph1NNR18vZGbAHzwdPgbMZVi/GSVLLsV 12XTTbb/6AlMyISLWJQjN3YKuyBhijoqLYk0OQq332+fs0qTUi2ISVMyM9ZL7DzDK19E qFaA==
X-Received: by 10.224.181.210 with SMTP id bz18mr19102504qab.68.1363035261364;  Mon, 11 Mar 2013 13:54:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.0.40 with HTTP; Mon, 11 Mar 2013 13:53:41 -0700 (PDT)
X-Originating-IP: [2001:df8:0:16:5a55:caff:fef1:5a11]
From: Eric Rescorla 
Date: Mon, 11 Mar 2013 13:53:41 -0700
Message-ID: 
To: rtcweb@ietf.org, public-webrtc@w3.org
Content-Type: multipart/alternative; boundary=20cf30363ef7921ddc04d7ac60bb
X-Gm-Message-State: ALoCoQlKuI3/ARFRZKeZPuBG7v0Pfb161KaljgD33JX9p3HLTtPHWTNmR6OBlxwMAm9bFaFcS2XZ
Subject: [rtcweb] Notes on security for browser-based screen/application sharing
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 11 Mar 2013 20:54:29 -0000

--20cf30363ef7921ddc04d7ac60bb
Content-Type: text/plain; charset=ISO-8859-1

1. INTRODUCTION
WebRTC [0][1] already contains facilities for JavaScript applications
to acquire to the user's camera and microphone and either to directly
access the media or to send it elsewhere over a voice/video call.
This obviously presents security issues [2][3] and the consensus
approach is that any access to camera or microphone must only occur
with user consent. Current versions of Chrome obtain this consent once
and persist it indefinitely for a given site. Firefox obtains consent
for every request but will likely eventually add a persistent consent
feature.

One of the major applications of WebRTC-style technology is
videoconferencing and most videoconferencing applications offer either
"screen sharing" or "application sharing" or both. Unfortunately,
while the security properties of camera/microphone access are fairly
obvious to the user--though the properties of persistent permissions
may not be--the security properties of screen/application sharing are
far less obvious. It has been suggested by Adam Barth among others that
permissions should be stricter for screen sharing than for
camera/microphone access. This note provides an overview of the
relevant security issues and of the potential permissions/consent
mechanisms.


2. GENERAL SECURITY PROPERTIES OF SCREEN/APPLICATION SHARING
Technically, screen/application sharing is relatively simple. In
screen sharing, the conference sees whatever is on the user's display;
if there are multiple monitors, typically only one is shared. In
application sharing, the conference gets access to all the windows in
an application.

Because existing conferening products (e.g., WebEx) require some sort
of download/install experience, they end up with the permissions of a
native application. Thus, it doesn't really make sense to worry about
misuse of the sharing permissions specifically because the application
has free run of the user's machine. The security question then becomes
whether the user wishes to run the application at all, not whether he
trusts the application to see his screen specifically.

Even so, there are known security risks to this type of sharing,
mostly due to the user's misunderstanding/lack of thought about
the security properties. For instance:

* The desktop often contains icons that the user has forgotten
  about, including the names of files. These themselves can
  be confidential.

* Desktop notifications such as Growl for incoming messages,
  IMs, etc. can be get shared. These can also contain confidential
  information.

* Users often think of "application sharing" as "window sharing"
  and will have other sensitive documents open at the same
  time as the document they intend to be sharing.

I have heard reports of all of these issues (the first two are also
often seen in settings when the user is projecting their screen at
conferences and the like). Fundamentally, these are examples of user
error, though possibly combined with confusing interfaces. The users
generally understand that they have given the downloaded application
wide permissions. Because users' expectation for Web applications are
that they are safer, there is yet more space for confusion.


3. SECURITY OF SCREEN/APPLICATION SHARING IN THE WEB ENVIRONMENT
3.1. Threat Model
Huang et al.[4] describe the Web security guarantee as:

   Users can safely visit arbitrary web sites and execute scripts
   provided by those sites.

More generally, users expect that the browser will protect them from
malicious sites and that sites are isolated from each other.  (More on
the technical mechanisms below).

Obviously, granting permission to see the desktop breaches this
guarantee to some extent, since the user is granting the site (via the
browser) some very dangerous capabilities. Generally the intent is
that the user can understand the security impact of the permission he
is granting. As should be clear from the discussion above, this is
already not entirely so. However, in the Web environment the problem
is much worse because the user likely thinks that he is assuming
*just* the screen/application sharing risks without the corresponding
"full application privileges" risks. This is unfortunately less true
than one would like.


3.2. Background: Same Origin Policy
In order to isolate sites from each other, browsers implement what's
called the "Same Origin Policy" (SOP). The basic idea is that content
(scripts, HTML, etc.) that runs on one site cannot get access to
content from another site, except under very limited conditions.  For
instance, site A can:

- Run scripts from site B.
- IFRAME HTML from site B but not look at the content or output.
- Display images and videos from site B but not examine their
  contents.

[Note: I am ignoring CORS and WebSockets for the moment.]

The basic idiom here is that site A can cause content from site B to
be *displayed* but it can't access the content itself. This allows for
the construction of some kinds of composite Web sites (i.e., mash-ups)
but still allows for site isolation.

Many important Web security mechanisms depend explicitly on these
guarantees. For instance, consider a Web mail site which bases its
authentication on cookies and will therefore service any HTTP request
which contains the right cookie. Content from any other site can cause
the browser to emit the right HTTP request, but because of the
same-origin policy, it can't see the responses. This prevents random
sites from accessing your web mail.


3.3. Web-Specific Risks
At this point, the risk of combining screen sharing with the Web
environment should be obvious. SOP protection depends on denying
Web content access from site A to content from site B, but
because site A can cause content from site B to be displayed
on the screen, if A can see the user's screen then he can
close the loop and bypass SOP. (We assume below that either
the site is sharing the user's screen or that the browser is
the application being shared.)


3.3.1. SOP Violations for Visible Content
The most obvious attack vector is that the the site can see any
content that the user can see. All he needs to do is to open a window
with the URL of the relevant content and put it in view of the screen
sharing system. Note that the content only needs to be briefly visible
(long enough to be captured by the sharing code). Potential attacks
include:

- Capture the user's webmail (and potentially individual messages).
- Capture the user's "sitekey" anti-phishing picture. [6]
- View any confidential documents that the user has access to
  on the Internet or on their own computer.

In general, any resource which can be opened in a browser window
(if the browser is being shared) or in an external application
(if screen sharing is in use) can be accessed in this fashion.


3.3.2. SOP Violations for "Hidden" Content
The SOP issue extends beyond visible content. For instance, many sites
use secret tokens in HTML content to prevent Cross-Site Resource
Forgery (CSRF) attacks. The idea is that the token is available to
same-origin JS which then embeds it in any XHR requests it
performs. The site checks for presence of the token, thus preventing
content from other sites from performing operations which might have
side effects (even if they cannot see the response). While embedded in
the HTML, these tokens are hidden to avoid annoying the user.

Similar techniques to those described above can be used to bypass this
type of CSRF protection. Instead of loading the content directly in a
window, the attacker loads the HTML in a source view window (using the
view-source: scheme, which both Chrome and Firefox support). Since the
HTML source contains the CSRF token, the attacker can simply read it
off, and use it to mount CSRF attacks.


4. CONSENT/PERMISSIONS OPTIONS
A number of possible permissions models have been proposed.

1. The same permissions model as audio/video, namely a consent
   dialog with (optional?) persistent content. [the
   natural default.]

2. A similar permissions dialog to audio/video but with *only*
   one-time consent. [proposed by Cullen Jennings]

3. A "sysapps" [5] API in which the user had to go through an
   app store type install experience to enable sharing for
   each specific site. [proposed by Adam Barth and others]

There have also been proposals for hybrid designs, such as a
sysapps-style API that also requires an in-chrome permissions dialog
for every sharing instance. Another possible design would be a
"preferred site" desing in which certain sites could directly ask for
permission without an application install but other sites would need
to do an app store install experience.  (Like the Firefox Social API).

The argument for the less onerous permissions models is of course
reduced user friction. The argument for the more restrictive models is
that the set of permissions that is being granted to the web site is
really more similar to those of a Web application install (even though
the user does not know it) and that therefore the barrier to entry
should be more like that of an application (i.e., a curated,
authenticated app store).




ACKNOWLEDGEMENT
Much of this material came out of discussions with Adam Barth,
Cullen Jennings, and Randell Jesup but I may well have mangled it.


[0] http://dev.w3.org/2011/webrtc/editor/webrtc.html
[1] http://dev.w3.org/2011/webrtc/editor/getusermedia.html
[2] http://tools.ietf.org/html/draft-ietf-rtcweb-security
[3] http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch
[4] http://w2spconf.com/2011/papers/websocket.pdf
[5] http://www.w3.org/2012/09/sysapps-wg-charter
[6]
https://www.bankofamerica.com/privacy/online-mobile-banking-privacy/sitekey.go

--20cf30363ef7921ddc04d7ac60bb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


1. INTRODUCTION
WebRTC [0][1] already contains facilities fo=
r JavaScript applications
to acquire to the user's camera and=
 microphone and either to directly
access the media or to send it=
 elsewhere over a voice/video call.



This obviously presents security issues [2][3] and the consensus
=

approach is that any access to camera or microphone must only occur
with user consent. Current versions of Chrome obtain this consent o=
nce



and persist it indefinitely for a given site. Firefox obtains consent<=
/div>
for every request but will likely eventually add a persistent con=
sent
feature.

One of the major applicati=
ons of WebRTC-style technology is



videoconferencing and most videoconferencing applications offer either=

"screen sharing" or "application sharing" or=
 both. Unfortunately,
while the security properties of camera/mic=
rophone access are fairly



obvious to the user--though the properties of persistent permissions
may not be--the security properties of screen/application sharing =
are
far less obvious. It has been suggested by Adam Barth among o=
thers that



permissions should be stricter for screen sharing than for
c=
amera/microphone access. This note provides an overview of the
re=
levant security issues and of the potential permissions/consent


mechanisms.


2. GENERAL SECURITY PRO=
PERTIES OF SCREEN/APPLICATION SHARING
Technically, screen/applica=
tion sharing is relatively simple. In
screen sharing, the confere=
nce sees whatever is on the user's display;



if there are multiple monitors, typically only one is shared. In
=

application sharing, the conference gets access to all the windows in<=
/div>
an application.

Because existing confere=
ning products (e.g., WebEx) require some sort



of download/install experience, they end up with the permissions of a<=
/div>
native application. Thus, it doesn't really make sense to wor=
ry about
misuse of the sharing permissions specifically because t=
he application



has free run of the user's machine. The security question then bec=
omes
whether the user wishes to run the application at all, not w=
hether he
trusts the application to see his screen specifically.<=
/div>



Even so, there are known security risks to this type of=
 sharing,
mostly due to the user's misunderstanding/lack of t=
hought about
the security properties. For instance:



* The desktop often contains icons that the user has forgott=
en
=A0 about, including the names of files. These themselves can<=
/div>
=A0 be confidential.

* Desktop notificat=
ions such as Growl for incoming messages,



=A0 IMs, etc. can be get shared. These can also contain confidential
=A0 information.

* Users often think of &=
quot;application sharing" as "window sharing"
=A0 =
and will have other sensitive documents open at the same



=A0 time as the document they intend to be sharing.=A0

<=
/div>
I have heard reports of all of these issues (the first two are al=
so
often seen in settings when the user is projecting their scree=
n at



conferences and the like). Fundamentally, these are examples of user
error, though possibly combined with confusing interfaces. The use=
rs
generally understand that they have given the downloaded appli=
cation



wide permissions. Because users' expectation for Web applications =
are
that they are safer, there is yet more space for confusion.
=A0 =A0=A0

3. SECURITY OF SCREEN/APPLICAT=
ION SHARING IN THE WEB ENVIRONMENT



3.1. Threat Model
Huang et al.[4] describe the Web security =
guarantee as:

=A0 =A0Users can safely visit arbitr=
ary web sites and execute scripts
=A0 =A0provided by those sites.=





More generally, users expect that the browser will prot=
ect them from
malicious sites and that sites are isolated from ea=
ch other. =A0(More on
the technical mechanisms below).



Obviously, granting permission to see the desktop breaches t=
his
guarantee to some extent, since the user is granting the site=
 (via the
browser) some very dangerous capabilities. Generally th=
e intent is



that the user can understand the security impact of the permission he<=
/div>
is granting. As should be clear from the discussion above, this i=
s
already not entirely so. However, in the Web environment the pr=
oblem



is much worse because the user likely thinks that he is assuming
=

*just* the screen/application sharing risks without the corresponding<=
/div>
"full application privileges" risks. This is unfortunat=
ely less true



than one would like.


3.2. Back=
ground: Same Origin Policy
In order to isolate sites from each ot=
her, browsers implement what's
called the "Same Origin P=
olicy" (SOP). The basic idea is that content



(scripts, HTML, etc.) that runs on one site cannot get access to
=

content from another site, except under very limited conditions. =A0Fo=
r
instance, site A can:

- Run scripts fr=
om site B.



- IFRAME HTML from site B but not look at the content or output.
=

- Display images and videos from site B but not examine their
=A0 contents.

[Note: I am ignoring CORS and WebS=
ockets for the moment.]




The basic idiom here is that site A can cause content f=
rom site B to
be *displayed* but it can't access the content =
itself. This allows for
the construction of some kinds of composi=
te Web sites (i.e., mash-ups)



but still allows for site isolation.

Many imp=
ortant Web security mechanisms depend explicitly on these
guarant=
ees. For instance, consider a Web mail site which bases its

authentication on cookies and will therefore service any HTTP request


which contains the right cookie. Content from any other site can cause=

the browser to emit the right HTTP request, but because of the
same-origin policy, it can't see the responses. This prevents =
random



sites from accessing your web mail.


3.3. Web-Specific Risks
At this point, the risk of combinin=
g screen sharing with the Web
environment should be obvious. SOP =
protection depends on denying



Web content access from site A to content from site B, but
b=
ecause site A can cause content from site B to be displayed
on th=
e screen, if A can see the user's screen then he can
close th=
e loop and bypass SOP. (We assume below that either



the site is sharing the user's screen or that the browser is
=

the application being shared.)


3.3.1. SOP Violations for Visible Content
The most obvious attac=
k vector is that the the site can see any



content that the user can see. All he needs to do is to open a window<=
/div>
with the URL of the relevant content and put it in view of the sc=
reen
sharing system. Note that the content only needs to be brief=
ly visible



(long enough to be captured by the sharing code). Potential attacks
include:

- Capture the user's webmail =
(and potentially individual messages).
- Capture the user's &=
quot;sitekey" anti-phishing picture. [6]



- View any confidential documents that the user has access to
=A0 on the Internet or on their own computer.

In=
 general, any resource which can be opened in a browser window


(if the browser is being shared) or in an external application
(i=
f screen sharing is in use) can be accessed in this fashion.

=


3.3.2. SOP Violations for "Hidden" Cont=
ent



The SOP issue extends beyond visible content. For instance, many sites=

use secret tokens in HTML content to prevent Cross-Site Resource=

Forgery (CSRF) attacks. The idea is that the token is available =
to



same-origin JS which then embeds it in any XHR requests it
p=
erforms. The site checks for presence of the token, thus preventing
content from other sites from performing operations which might have


side effects (even if they cannot see the response). While embedded in=

the HTML, these tokens are hidden to avoid annoying the user.

Similar techniques to those described above can be u=
sed to bypass this



type of CSRF protection. Instead of loading the content directly in a<=
/div>
window, the attacker loads the HTML in a source view window (usin=
g the
view-source: scheme, which both Chrome and Firefox support)=
. Since the



HTML source contains the CSRF token, the attacker can simply read it
off, and use it to mount CSRF attacks.

4. CONSENT/PERMISSIONS OPTIONS
A number of possible =
permissions models have been proposed.




1. The same permissions model as audio/video, namely a =
consent
=A0 =A0dialog with (optional?) persistent content. [the
=A0 =A0natural default.]

2. A similar per=
missions dialog to audio/video but with *only*



=A0 =A0one-time consent. [proposed by Cullen Jennings]

<=
/div>
3. A "sysapps" [5] API in which the user had to go thro=
ugh an
=A0 =A0app store type install experience to enable sharing=
 for



=A0 =A0each specific site. [proposed by Adam Barth and others]

There have also been proposals for hybrid designs, such a=
s a
sysapps-style API that also requires an in-chrome permissions=
 dialog



for every sharing instance. Another possible design would be a
"preferred site" desing in which certain sites could directly =
ask for
permission without an application install but other sites=
 would need



to do an app store install experience. =A0(Like the Firefox Social API=
).

The argument for the less onerous permissions m=
odels is of course
reduced user friction. The argument for the mo=
re restrictive models is



that the set of permissions that is being granted to the web site is
really more similar to those of a Web application install (even th=
ough
the user does not know it) and that therefore the barrier to=
 entry



should be more like that of an application (i.e., a curated,
authenticated app store).




ACKNOWLEDGEMENT
Much of this material came =
out of discussions with Adam Barth,



Cullen Jennings, and Randell Jesup but I may well have mangled it.





[2] <=
a href=3D"http://tools.ietf.org/html/draft-ietf-rtcweb-security">http://too=
ls.ietf.org/html/draft-ietf-rtcweb-security


[4] http://w2s=
pconf.com/2011/papers/websocket.pdf










--20cf30363ef7921ddc04d7ac60bb--

From jerome.marcon@alcatel-lucent.com  Mon Mar 11 14:21: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 EDA6621F8FEE for ; Mon, 11 Mar 2013 14:20:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.83
X-Spam-Level: 
X-Spam-Status: No, score=-9.83 tagged_above=-999 required=5 tests=[AWL=0.418,  BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 qsZYVKGFYDBs for ; Mon, 11 Mar 2013 14:20:58 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 40FF221F8F7A for ; Mon, 11 Mar 2013 14:20:58 -0700 (PDT)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2BLKtRS006047 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 11 Mar 2013 22:20:55 +0100
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 11 Mar 2013 22:20:54 +0100
Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.26]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 11 Mar 2013 22:20:55 +0100
From: "MARCON, JEROME (JEROME)" 
To: Michael Tuexen , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb]  I-D Action: draft-ietf-rtcweb-data-channel-04.txt
Thread-Index: AQHOHo4Bj9+KsPxJJE2oLAO4Ougqn5ig+Bfx
Date: Mon, 11 Mar 2013 21:20:53 +0000
Message-ID: <39821B4C400EC14DAD4DB25330A9271A024714@FR711WXCHMBA02.zeu.alcatel-lucent.com>
References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> <5135C64A.50302@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02108E@FR711WXCHMBA02.zeu.alcatel-lucent.com> <51371E4A.4040602@ericsson.com> <39821B4C400EC14DAD4DB25330A9271A0214C1@FR711WXCHMBA02.zeu.alcatel-lucent.com>, <51376643.8090204@jesup.org> <39821B4C400EC14DAD4DB25330A9271A024649@FR711WXCHMBA02.zeu.alcatel-lucent.com>, <2024BD14-E25C-426F-B046-46D61AF7077C@lurchi.franken.de>
In-Reply-To: <2024BD14-E25C-426F-B046-46D61AF7077C@lurchi.franken.de>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.40]
Content-Type: multipart/alternative; boundary="_000_39821B4C400EC14DAD4DB25330A9271A024714FR711WXCHMBA02zeu_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
Cc: Randell Jesup 
Subject: [rtcweb] RE :   I-D Action: draft-ietf-rtcweb-data-channel-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, 11 Mar 2013 21:21:00 -0000

--_000_39821B4C400EC14DAD4DB25330A9271A024714FR711WXCHMBA02zeu_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thanks again Michael. Inline my [JM1] comments.

________________________________________
De : Michael Tuexen [Michael.Tuexen@lurchi.franken.de]
Date d'envoi : lundi 11 mars 2013 20:23
=C0 : MARCON, JEROME (JEROME)
Cc: Randell Jesup; rtcweb@ietf.org
Objet : Re: [rtcweb]  I-D Action: draft-ietf-rtcweb-data-channel-04.txt

On Mar 11, 2013, at 2:51 PM, MARCON, JEROME (JEROME) wrote:

> Randell,
>
> Assuming that some day a spec defines the transport of T.140 (or whatever=
 similar protocol) over RTCWeb data channels
> - with a registered subprotocol
> - with multiple reliability options supported
> - requiring some new data channel properties
> - of which some are assymetric between the endpoints (like the "character=
s per second" defined in [RFC4103].
>
> Then (in the current version of your proposal) it seems to me that
> * Because current DATA_CHANNEL_OPEN syntax is not extensible:
> - it is not possible to carry these new properties in DATA_CHANNEL_OPEN
Why is it not extensible? We have a message type and you could simply
define another message...

[JM1]. Mmh, then the spec defining T.140 (or whatever) over data channels (=
and willing to add a new property like "cps") would have to define a new me=
ssage type  - and more less its own DATA_CHANNEL_OPEN structure? That's a c=
ostly extensibility.

Also, given that different message types likely imply incompatible structur=
es (as the spec says), the spec should specify how one endpoint can discove=
r which message types the other endpoint supports. Of course the endpoint c=
ould reject the message by a close() again. But then this close() would hav=
e three hats :)
- close a channel
- reject some parameters of an incoming DATA_CHANNEL_OPEN
- reject the format of an incoming DATA_CHANNEL_OPEN

>
> * Because the successful response to an open data channel request does no=
t exist:
> - it is not possible to agree on assymetric property values
>
> * Because the error response to an open data channel has no payload (erro=
r):
> - an endpoint cannot easily know if this subprotocol is supported or whic=
h reliability properties are supported. Unless it sends as many DATA_CHANNE=
L_OPEN
> messages as there are combinations of {subprotocol, property variants}
>
> Besides, if after unsuccessful tries (DATA_CHANNEL_OPEN) and errors (clos=
e() ), the endpoint decides to go for an SDP renegotiation:
> - first this might be for nothing (the peer might not support anything af=
ter all),
> - second  the design would be more complex, because for now the proposal =
assumes that SDP negotiation only happens once, in the offer/answer establi=
shing the SCTP association, when no data channels exist.
>
> This might have been discussed before, but in the eventually that an inba=
nd protocol is really unavoidable (I still hope it is not), another option =
would have been to base this protocol on a new CHUNK type (e.g. Data Channe=
l Control CHUNK) carrying request and response parameters in a bi-direction=
al way. Most SCTP extensions are defined this way, aren't they ? And with t=
he additional benefits:
I don't think it makes sense to extend SCTP instead of doing this on top of=
 SCTP, if you need.

[JM1]. On top of SCTP, and to reduce the RTT, you had to drop DATA_CHANNEL_=
OPEN_RESPONSE at the cost of assymetric negotiation and proper error handli=
ng.
Also a true protocol on top of SCTP would define a DATA_CHANNEL_CLOSE user =
message.

Best regards
Michael
> - 1 RTT also
> - built-in parameter extensibility
> - refined error handling, e.g. report which parameter caused an error
> - control messages not mixed with application messages
> - proper data channel closing (the use of SSN reset is more like a trick;=
 also open() and close() messages to not belong to the same protocol/layer)
> - ability to define optimized retransmission procedures - those inherited=
 from user messages might not be the best one
> - ...
>
> I guess this has been discussed in the past ?
>
> Jerome
>
> ________________________________________
> De : rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] de la part de Rand=
ell Jesup [randell-ietf@jesup.org]
> Date d'envoi : mercredi 6 mars 2013 16:52
> =C0 : rtcweb@ietf.org
> Objet : Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt
>
> On 3/6/2013 7:08 AM, MARCON, JEROME (JEROME) wrote:
>> But then - and given that DATA_CHANNEL_OPEN_RESPONSE no longer exists in=
 this new draft version - I wonder how the peer can reject an incoming DATA=
_CHANNEL_OPEN message signaling a 'subprotocol' it does not support.
>
> channel.close();
>
> I.e. there's no explicit prior-to-connect rejection, you simply state
> instead "I'm not interested" and close it.  This resets the streams, and
> causes the other side to be notified of the close. You're correct in
> that this is not distinguished from other reasons to close() it; if
> those are needed you should either negotiate it out-of-band, or make a
> rejection part of the protocol you run over it.  This is entirely within
> the application's domain.  Most applications would have no need for this.
>
> --
> Randell Jesup
> randell-ietf@jesup.org
>
> _______________________________________________
> 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_39821B4C400EC14DAD4DB25330A9271A024714FR711WXCHMBA02zeu_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








Thanks again Michael. Inline my [JM1] comments.



________________________________________

De : Michael Tuexen [Michael.Tuexen@lurchi.franken.de]

Date d'envoi : lundi 11 mars 2013 20:23

=C0 : MARCON, JEROME (JEROME)

Cc: Randell Jesup; rtcweb@ietf.org

Objet : Re: [rtcweb]  I-D Action: draft-ietf-rtcweb-data-channel-04.tx=
t



On Mar 11, 2013, at 2:51 PM, MARCON, JEROME (JEROME) wrote:



> Randell,

>

> Assuming that some day a spec defines the transport of T.140 (or whate=
ver similar protocol) over RTCWeb data channels

> - with a registered subprotocol

> - with multiple reliability options supported

> - requiring some new data channel properties

> - of which some are assymetric between the endpoints (like the "c=
haracters per second" defined in [RFC4103].

>

> Then (in the current version of your proposal) it seems to me that

> * Because current DATA_CHANNEL_OPEN syntax is not extensible:

> - it is not possible to carry these new properties in DATA_CHANNEL_OPE=
N

Why is it not extensible? We have a message type and you could simply

define another message...



[JM1]. Mmh, then the spec defining T.140 (or whatev=
er) over data channels (and willing to add a new property like "cps&qu=
ot;) would have to define a new message type  - and more less its own =
DATA_CHANNEL_OPEN structure? That's a costly extensibility.



Also, given that different message types likely imply incompatible structur=
es (as the spec says), the spec should specify how one endpoint can discove=
r which message types the other endpoint supports. Of course the endpoint c=
ould reject the message by a close()
 again. But then this close() would have three hats :)

- close a channel

- reject some parameters of an incoming DATA_CHANNEL_OPEN

- reject the format of an incoming DATA_CHANNEL_OPEN

 

>

> * Because the successful response to an open data channel request does=
 not exist:

> - it is not possible to agree on assymetric property values

>

> * Because the error response to an open data channel has no payload (e=
rror):

> - an endpoint cannot easily know if this subprotocol is supported or w=
hich reliability properties are supported. Unless it sends as many DATA_CHA=
NNEL_OPEN

> messages as there are combinations of {subprotocol, property variants}=


>

> Besides, if after unsuccessful tries (DATA_CHANNEL_OPEN) and errors (c=
lose() ), the endpoint decides to go for an SDP renegotiation:

> - first this might be for nothing (the peer might not support anything=
 after all),

> - second  the design would be more complex, because for now the p=
roposal assumes that SDP negotiation only happens once, in the offer/answer=
 establishing the SCTP association, when no data channels exist.

>

> This might have been discussed before, but in the eventually that an i=
nband protocol is really unavoidable (I still hope it is not), another opti=
on would have been to base this protocol on a new CHUNK type (e.g. Data Cha=
nnel Control CHUNK) carrying request
 and response parameters in a bi-directional way. Most SCTP extensions are =
defined this way, aren't they ? And with the additional benefits:

I don't think it makes sense to extend SCTP instead of doing this on top of=
 SCTP, if you need.



[JM1]. On top of SCTP, and =
to reduce the RTT, you had to drop DATA_CHANNEL_OPEN_RESPONSE at the cost o=
f assymetric negotiation and proper error handling.

Also a true protocol on top of SCTP would define a DATA_CHANNEL_CLOSE user =
message.



Best regards

Michael

> - 1 RTT also

> - built-in parameter extensibility

> - refined error handling, e.g. report which parameter caused an error<=
br>
> - control messages not mixed with application messages

> - proper data channel closing (the use of SSN reset is more like a tri=
ck; also open() and close() messages to not belong to the same protocol/lay=
er)

> - ability to define optimized retransmission procedures - those inheri=
ted from user messages might not be the best one

> - ...

>

> I guess this has been discussed in the past ?

>

> Jerome

>

> ________________________________________

> De : rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] de la part de R=
andell Jesup [randell-ietf@jesup.org]

> Date d'envoi : mercredi 6 mars 2013 16:52

> =C0 : rtcweb@ietf.org

> Objet : Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt=


>

> On 3/6/2013 7:08 AM, MARCON, JEROME (JEROME) wrote:

>> But then - and given that DATA_CHANNEL_OPEN_RESPONSE no longer exi=
sts in this new draft version - I wonder how the peer can reject an incomin=
g DATA_CHANNEL_OPEN message signaling a 'subprotocol' it does not support.<=
br>
>

> channel.close();

>

> I.e. there's no explicit prior-to-connect rejection, you simply state<=
br>
> instead "I'm not interested" and close it.  This resets=
 the streams, and

> causes the other side to be notified of the close. You're correct in
> that this is not distinguished from other reasons to close() it; if
> those are needed you should either negotiate it out-of-band, or make a=


> rejection part of the protocol you run over it.  This is entirely=
 within

> the application's domain.  Most applications would have no need f=
or this.

>

> --

> Randell Jesup

> randell-ietf@jesup.org

>

> _______________________________________________

> 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_39821B4C400EC14DAD4DB25330A9271A024714FR711WXCHMBA02zeu_--

From jerome.marcon@alcatel-lucent.com  Mon Mar 11 15:09: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 8E03C21F9044 for ; Mon, 11 Mar 2013 15:09:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.865
X-Spam-Level: 
X-Spam-Status: No, score=-9.865 tagged_above=-999 required=5 tests=[AWL=0.383,  BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 vAuRosbSagab for ; Mon, 11 Mar 2013 15:09:02 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABBD21F9097 for ; Mon, 11 Mar 2013 15:09:02 -0700 (PDT)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2BM8iA1008571 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 11 Mar 2013 23:08:58 +0100
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 11 Mar 2013 23:08:53 +0100
Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.26]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 11 Mar 2013 23:08:53 +0100
From: "MARCON, JEROME (JEROME)" 
To: Harald Alvestrand , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] RE : I-D Action: draft-ietf-rtcweb-data-channel-04.txt
Thread-Index: AQHOHo3R0WBnkelXBEOrl0OojyYzLZihCmJR
Date: Mon, 11 Mar 2013 22:08:53 +0000
Message-ID: <39821B4C400EC14DAD4DB25330A9271A024756@FR711WXCHMBA02.zeu.alcatel-lucent.com>
References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> <5135C64A.50302@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02108E@FR711WXCHMBA02.zeu.alcatel-lucent.com> <51371E4A.4040602@ericsson.com> <39821B4C400EC14DAD4DB25330A9271A0214C1@FR711WXCHMBA02.zeu.alcatel-lucent.com>, <51376643.8090204@jesup.org> <39821B4C400EC14DAD4DB25330A9271A024649@FR711WXCHMBA02.zeu.alcatel-lucent.com>, <513E2EEE.3050106@alvestrand.no>
In-Reply-To: <513E2EEE.3050106@alvestrand.no>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.41]
Content-Type: multipart/alternative; boundary="_000_39821B4C400EC14DAD4DB25330A9271A024756FR711WXCHMBA02zeu_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
Subject: [rtcweb] RE : RE : I-D Action: draft-ietf-rtcweb-data-channel-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, 11 Mar 2013 22:09:03 -0000

--_000_39821B4C400EC14DAD4DB25330A9271A024756FR711WXCHMBA02zeu_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

[JM1]
________________________________________
De : rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] de la part de Harald=
 Alvestrand [harald@alvestrand.no]
Date d'envoi : lundi 11 mars 2013 20:22
=C0 : rtcweb@ietf.org
Objet : Re: [rtcweb] RE : I-D Action: draft-ietf-rtcweb-data-channel-04.txt

On 03/11/2013 07:51 PM, MARCON, JEROME (JEROME) wrote:
> Randell,
>
> Assuming that some day a spec defines the transport of T.140 (or whatever=
 similar protocol) over RTCWeb data channels
> - with a registered subprotocol
> - with multiple reliability options supported
> - requiring some new data channel properties
> - of which some are assymetric between the endpoints (like the "character=
s per second" defined in [RFC4103].
>
> Then (in the current version of your proposal) it seems to me that
> * Because current DATA_CHANNEL_OPEN syntax is not extensible:
> - it is not possible to carry these new properties in DATA_CHANNEL_OPEN
>
> * Because the successful response to an open data channel request does no=
t exist:
> - it is not possible to agree on assymetric property values
>
> * Because the error response to an open data channel has no payload (erro=
r):
> - an endpoint cannot easily know if this subprotocol is supported or whic=
h reliability properties are supported. Unless it sends as many DATA_CHANNE=
L_OPEN
>   messages as there are combinations of {subprotocol, property variants}

Is there any reason why the app that desires to use such a protocol over
a data channel shouldn't send a new message (defined in the protocol)
after the DATA_CHANNEL_OPEN saying what the desired properties are, and
with an accept/reject message on the return channel?

One of the desirable properties of DATA_CHANNEL_OPEN is that it's
simple. I'd like to keep it that way.

[JM1] All right, this would work in many cases (brand-new protocols, and pr=
otocols "adapted" over RTCWeb data channels, which have or can easily integ=
rate capabilities negotiation). In some cases though, that would be challen=
ging: e.g. the character-oriented T.140 protocol.

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

--_000_39821B4C400EC14DAD4DB25330A9271A024756FR711WXCHMBA02zeu_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








[JM1]

________________________________________

De : rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] de la part de Harald=
 Alvestrand [harald@alvestrand.no]

Date d'envoi : lundi 11 mars 2013 20:22

=C0 : rtcweb@ietf.org

Objet : Re: [rtcweb] RE : I-D Action: draft-ietf-rtcweb-data-channel-04.txt=




On 03/11/2013 07:51 PM, MARCON, JEROME (JEROME) wrote:

> Randell,

>

> Assuming that some day a spec defines the transport of T.140 (or whate=
ver similar protocol) over RTCWeb data channels

> - with a registered subprotocol

> - with multiple reliability options supported

> - requiring some new data channel properties

> - of which some are assymetric between the endpoints (like the "c=
haracters per second" defined in [RFC4103].

>

> Then (in the current version of your proposal) it seems to me that

> * Because current DATA_CHANNEL_OPEN syntax is not extensible:

> - it is not possible to carry these new properties in DATA_CHANNEL_OPE=
N

>

> * Because the successful response to an open data channel request does=
 not exist:

> - it is not possible to agree on assymetric property values

>

> * Because the error response to an open data channel has no payload (e=
rror):

> - an endpoint cannot easily know if this subprotocol is supported or w=
hich reliability properties are supported. Unless it sends as many DATA_CHA=
NNEL_OPEN

>   messages as there are combinations of {subprotocol, proper=
ty variants}



Is there any reason why the app that desires to use such a protocol over
a data channel shouldn't send a new message (defined in the protocol)

after the DATA_CHANNEL_OPEN saying what the desired properties are, and

with an accept/reject message on the return channel?



One of the desirable properties of DATA_CHANNEL_OPEN is that it's

simple. I'd like to keep it that way.



[JM1] All right, this would work in many cases (bra=
nd-new protocols, and protocols "adapted" over RTCWeb data channe=
ls, which have or can easily integrate capabilities negotiation). In some c=
ases though, that would be challenging: e.g.
 the character-oriented T.140 protocol.  



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb



--_000_39821B4C400EC14DAD4DB25330A9271A024756FR711WXCHMBA02zeu_--

From keith.drage@alcatel-lucent.com  Mon Mar 11 15:24: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 70F4E21F8E0C for ; Mon, 11 Mar 2013 15:24:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.249
X-Spam-Level: 
X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 cdaatuJ+0TcN for ; Mon, 11 Mar 2013 15:24:01 -0700 (PDT)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id BBB5721F8DE9 for ; Mon, 11 Mar 2013 15:24:00 -0700 (PDT)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2BMNwGN024471 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 11 Mar 2013 23:23:58 +0100
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 11 Mar 2013 23:23:58 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 11 Mar 2013 23:23:57 +0100
From: "DRAGE, Keith (Keith)" 
To: Ted Hardie , "Markus.Isomaki@nokia.com" 
Thread-Topic: [rtcweb] VP8 litigation in Germany?
Thread-Index: AQHOHouGr8NsCldLPUWhUkHPBxzgxZihDNXA
Date: Mon, 11 Mar 2013 22:23:57 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B01121E@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References:   
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 litigation in Germany?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 11 Mar 2013 22:24:02 -0000

I would not expect it to.

Normal declarations cover whether the normative requirements of an RFC or i=
nternet draft are covered by a claimed IPR.

As I believe there are no IETF documents that specify H.264 or VP8 directly=
, then you will not get a direct declaration.

What does exist as an IETF document is the payload format for H.264 (RFC398=
4 and RFC 6184) and you will see Nokia (among others) have made declaration=
s against this document or the predecessors. However this document only con=
tains normative requirements for making a codec stream into an RTP payload.

Unless IETF actually defines the codec, you will need to go to the IPR data=
base of the SDO that defines the codec to get a fuller story. VP8?

regards

Keith

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
> Of Ted Hardie
> Sent: 11 March 2013 19:06
> To: Markus.Isomaki@nokia.com
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] VP8 litigation in Germany?
>=20
> Hi Markus,
>=20
> Just confirm my understanding of this:
>=20
> On Mon, Mar 11, 2013 at 11:06 AM,   wrote:
> >Nokia is preparing to do a disclosure about it to the
> > IETF, "to ensure that IETF working groups and participants have as much
> > information about any IPR constraints on a technical proposal as
> possible",
> > as stated in RFC 3979. That's all the information I have right now, but
> I
> > will keep this list updated as soon as something new comes up.
>=20
> this disclosure will cover both H.264 and VP8, as they are the two
> technical proposals?
>=20
> regards,
>=20
> Ted Hardie
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

From ted.ietf@gmail.com  Mon Mar 11 15:47: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 2135421F9099 for ; Mon, 11 Mar 2013 15:47:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.582
X-Spam-Level: 
X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.018,  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 Xf8dUw+aDcS8 for ; Mon, 11 Mar 2013 15:47:26 -0700 (PDT)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A87C721F9075 for ; Mon, 11 Mar 2013 15:47:26 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id c10so5581385ieb.31 for ; Mon, 11 Mar 2013 15:47:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=NEdQlACN0qEEzhzsmX2/PiTAGsMTeeGzOhMyEbi5Iuc=; b=tS8H7coi5WciIk1pj7ofk+T2aTXMnsLFA+yxsR2rOPA/ljpG5RWBppEGdSZHPkpI/O yK9WzLFR9d2eI8C+Iei2QYIv8kzdhZDfHq5VKNn2V1whIK8FpAdmzteQmxVWbNWUl7+x 9ohvmzKIsikXa3TlCbEAFi0V9evlgD+VtNVz76yfvFUBQic3w6VTGpLXWXTnj6evm5ca oop3tn7/PbfDfQnagUnP6+qp+Wz+6iW7nKT1Q70KO3N4dExjrchDOcHE9G+fXFzCHB2x Kp7p9uBAnRo900eDYAfZeSmtSiLsx4gA+9XLryxjCV/Ocko8DMrN5t4aIZtGcxzLAMD2 4WzA==
MIME-Version: 1.0
X-Received: by 10.50.87.196 with SMTP id ba4mr9562937igb.20.1363042046376; Mon, 11 Mar 2013 15:47:26 -0700 (PDT)
Received: by 10.43.135.202 with HTTP; Mon, 11 Mar 2013 15:47:26 -0700 (PDT)
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B01121E@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References:    <949EF20990823C4C85C18D59AA11AD8B01121E@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Date: Mon, 11 Mar 2013 18:47:26 -0400
Message-ID: 
From: Ted Hardie 
To: "DRAGE, Keith (Keith)" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] VP8 litigation in Germany?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 11 Mar 2013 22:47:27 -0000

On Mon, Mar 11, 2013 at 6:23 PM, DRAGE, Keith (Keith)
 wrote:
>
> As I believe there are no IETF documents that specify H.264 or VP8 directly, then you will not get a direct declaration.
>

This contradicts what I understood Markus to be saying, which is that
Nokia would supply one.  If I have misunderstood this text:

Nokia is preparing to do a disclosure about it to the  IETF "to ensure
that IETF working groups and participants have as much information
about any IPR constraints on a technical proposal as  possible".

I hope he will let me know.

thanks,

Ted

From singer@apple.com  Mon Mar 11 15: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 20D3521F8F37 for ; Mon, 11 Mar 2013 15:51: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=[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 NLSnxDICzmPH for ; Mon, 11 Mar 2013 15:51:52 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id F2EAC21F8FF3 for ; Mon, 11 Mar 2013 15:51:51 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset=windows-1252
Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MJI00FU7Q6EZC01@mail-out.apple.com> for rtcweb@ietf.org; Mon, 11 Mar 2013 15:51:51 -0700 (PDT)
X-AuditID: 11807153-b7f8a6d0000064e7-2e-513e6007c112
Received: from cardamom.apple.com (cardamom.apple.com [17.128.115.94]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay3.apple.com (Apple SCV relay) with SMTP id 87.53.25831.7006E315; Mon, 11 Mar 2013 15:51:51 -0700 (PDT)
Received: from [17.153.107.198] by cardamom.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MJI00DWIQ65WK40@cardamom.apple.com> for rtcweb@ietf.org; Mon, 11 Mar 2013 15:51:51 -0700 (PDT)
From: David Singer 
In-reply-to: 
Date: Mon, 11 Mar 2013 15:51:40 -0700
Content-transfer-encoding: quoted-printable
Message-id: 
References: <92D0D52F3A63344CA478CF12DB0648AA26537A69@XMB106BCNC.rim.net> 
To: Cullen Jennings 
X-Mailer: Apple Mail (2.1499)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUi2FAcp8ueYBdo0HiYx2Ltv3Z2B0aPJUt+ MgUwRnHZpKTmZJalFunbJXBlzOkNKHinXfF75xyWBsaNyl2MnBwSAiYSB46cZIWwxSQu3FvP 1sXIxSEkMJFJYundhawQTiuTREf3eaAMBwezgJ7E/YtaICYvkDlpfxBIr7CAi0TX5jZ2EJtN QFXiwZxjjCA2p4CVRPOKFWBxFqD4trvrmEBsZoE4iZ9Tn7JC2NoST95dALN5BWwkjrW+A6sR EqiUmHx2PguILSKgLHFux11miDtlJVZM7WWawCgwC+GgWQgHzUIydAEj8ypGgaLUnMRKY73E goKcVL3k/NxNjOCAKwzewfhnmdUhRgEORiUeXoVvtoFCrIllxZW5hxglOJiVRHhLHewChXhT EiurUovy44tKc1KLDzFKc7AoifNmBgBVC6QnlqRmp6YWpBbBZJk4OKUaGNXTT0brhAuEdV0/ d4R7vdPXUze3NvZ1H+RPioj6cc2ptXi5dCafN//5+PrKs5f9p+74kscQMmcrf8jbtkf/+7cv 4xK+6Pv29bk7h6zCdIVfcRdGSF/221JT9nDpdJkDnccFOz6c5ufLnc2juUHbfL923YISwajl /nNO1G2Qlvkj9UX3ca5krxJLcUaioRZzUXEiAJ5LZ300AgAA
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Request to postpone the question on VP8 as MTI
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 11 Mar 2013 22:51:53 -0000

On Mar 10, 2013, at 8:52 , Cullen Jennings  wrote:

>=20
> Gaelle,=20
>=20
> I think these are good points and other have erased similar points. I =
need to discuss it with my co-chairs but I suspect that for the points =
you raised, we will need delay this to IETF 86. Again, I need to talk to =
my co-chairs before we can make a decision on this but I would guess =
that is the direction things will need to go.

I also think it would be prudent to defer the codec decision.


>=20
> Cullen (One of the co-chairs)
>=20
>=20
> On Mar 10, 2013, at 9:45 AM, Gaelle Martin-Cocher =
 wrote:
>=20
>> Dear All,
>>=20
>> In light of the recent announcements (both MPEG-LA and the VP8 =
litigation), I believe that more time is needed to make a proper risk =
assessment on VP8 and an informed decision. On one side the MPEG-LA =
announcement provides some relief but also confirms that VP8 does not =
come for free and that concerns were/are justified. This is further =
confirmed by the second announcement.
>> It will take more efforts for VP8 supporters (and Google does not =
need to be alone in that process) to reach the goal of an RF video codec =
(or a codec with a suitable licensing terms). I think it is understood =
by now, that this would likely be more prone to success in a =
standardization body than anywhere else . (speaking here as a WebVC =
proponent that went through that process too).
>> It is also apparent that the MPEG-LA/Google agreement raises =
additional questions.
>>=20
>> Here are the reasons I believe we need more time and should postpone =
the question on VP8 (I am not saying that this should not be asked at a =
later time):
>> -The license is not yet published (and the meeting starts tomorrow)
>> -Some negotiations are still ongoing (e.g. names of the licensors). =20=

>> -Some questions were/are raised and not answered yet, below are the =
one that matters to me:
>> - Will the patent list be provided?
>> - Who are the licensors  and how that group of licensors relates to =
the initial 12 patent holders identified by MPEG-LA?
>> - Will there be alignment of licenses across WebM, RFC, MPEG, and is =
that even feasible with the possible new license terms?
>> - Questions related to clarifications of the different grants =
inside/outside the RFC and their applicability to the RFC itself still =
need to be answered (aka: how  section 20: 27 apply to the RFC code =
itself or to the code provided in MPEG)
>> - Questions related to the status of VP8 as a standard as it was =
mentioned that the RFC will not progress to the standard track still =
remain
>> - In light of the litigation announcement, was due diligence done by =
VP8 proponents toward patent holders that are not MPEG-LA members?  =
(e.g. possibly on a model similar to what was done in WebVC) =20
>> - More questions will likely be raised once the license is published.
>> -We need to give enough time to Google to finalize its license and =
provide answers on those above points.
>> -VP8 is not (yet) a standard in IETF nor in MPEG (MPEG only saw an =
input contribution for the first time in January). It would be desirable =
that RTCWeb points to a standard or that VP8 reaches a certain stage in =
MPEG so that it can be considered as an MPEG deliverable. VP8 may reach =
that status at a next MPEG meeting in April or July, I don=92t see how =
that can be accelerated further. We need to give MPEG the time to =
proceed properly.
>> -legal entities will need time to review both the new license and the =
answers to the various questions that were asked. This cannot be =
achieved in 3 days.
>>=20
>> Further, I just came across an informational RFC for VP9:
>> -Is VP9 going to =93deprecate=94 VP8?
>> - What is the timeframe for VP9 in IETF?
>> -if VP9 going to be proposed for a next generation of RTCWeb Client? =
Which timeframe?
>> I don=92t think it would be desirable to mandate VP8 today if VP9 is =
around the corner and will be proposed for RTCWeb as well.
>> Requesting two codecs to be implemented instead of one in a short =
timeframe is obviously an issue for implementers that cannot do a simple =
software upgrade of their products.
>>=20
>>=20
>> I hope all of you will find that request reasonable.
>> Sincerely,
>>=20
>>=20
>> Ga=EBlle Martin-Cocher
>> Standards Manager
>> Office: (905) 629-4746 x14591
>> BlackBerry: (647) 267-0569
>> PIN: 2835485E
>> 
>> www.rim.com
>>=20
>> ---------------------------------------------------------------------=20=

>> This transmission (including any attachments) may contain =
confidential information, privileged material (including material =
protected by the solicitor-client or other applicable privileges), or =
constitute non-public information. Any use of this information by anyone =
other than the intended recipient is prohibited. If you have received =
this transmission in error, please immediately reply to the sender and =
delete this information from your system. Use, dissemination, =
distribution, or reproduction of this transmission by unintended =
recipients is not authorized and may be unlawful. =
_______________________________________________
>> 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

David Singer
Multimedia and Software Standards, Apple Inc.


From ietf@meetecho.com  Mon Mar 11 16: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 B7CE021F8B96 for ; Mon, 11 Mar 2013 16:04:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.619
X-Spam-Level: 
X-Spam-Status: No, score=-0.619 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1w8huITUa3cM for ; Mon, 11 Mar 2013 16:04:12 -0700 (PDT)
Received: from smtpdg10.aruba.it (smtpdg228.aruba.it [62.149.158.228]) by ietfa.amsl.com (Postfix) with ESMTP id 0F65521F915F for ; Mon, 11 Mar 2013 16:04:09 -0700 (PDT)
Received: from meetecho ([130.129.6.44]) by smtpcmd04.ad.aruba.it with bizsmtp id AP461l00N0wzZHu01P47eD; Tue, 12 Mar 2013 00:04:08 +0100
Date: Mon, 11 Mar 2013 19:03:33 -0700 (PDT)
From: Meetecho Team 
To: rtcweb@ietf.org
Message-ID: <23150567.5.1363053813218.JavaMail.root@meetecho>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_Part_4_27546477.1363053813217"
Subject: [rtcweb] Meetecho support for RTCWEB session
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 11 Mar 2013 23:04:13 -0000

------=_Part_4_27546477.1363053813217
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dear all,

a virtual room has been reserved on the Meetecho system for the 
RTCWEB WG meeting session.
Access to the on-line session (including audio and video streams) will
be available (just a couple of minutes before session start time) at:
	http://www.meetecho.com/ietf86/rtcweb

The Meetecho session automatically logs you into the standard IETF
jabber room. So, from there, you can have an integrated experience
involving all media and allowing you to interact with the room.

A tutorial of interactivity features of the tool can be found at:
	http://www.meetecho.com/ietf86

Cheers,
the Meetecho Team


This email has been automatically generated by The Meetecho Conferencing System


------=_Part_4_27546477.1363053813217--

From Michael.Tuexen@lurchi.franken.de  Mon Mar 11 16:15: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 8A03A11E8127 for ; Mon, 11 Mar 2013 16:15: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 gDIOBsehsEUP for ; Mon, 11 Mar 2013 16:15:13 -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 1A46511E8112 for ; Mon, 11 Mar 2013 16:15:13 -0700 (PDT)
Received: from [IPv6:2001:df8::8:1427:9f54:fae4:eeee] (unknown [IPv6:2001:df8:0:8:1427:9f54:fae4:eeee]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id A86851C0B4619; Tue, 12 Mar 2013 00:15:10 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=iso-8859-1
From: Michael Tuexen 
In-Reply-To: <39821B4C400EC14DAD4DB25330A9271A024714@FR711WXCHMBA02.zeu.alcatel-lucent.com>
Date: Mon, 11 Mar 2013 19:15:08 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D227799-7A9E-4113-AED8-510BDC62B58C@lurchi.franken.de>
References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> <5135C64A.50302@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02108E@FR711WXCHMBA02.zeu.alcatel-lucent.com> <51371E4A.4040602@ericsson.com> <39821B4C400EC14DAD4DB25330A9271A0214C1@FR711WXCHMBA02.zeu.alcatel-lucent.com>, <51376643.8090204@jesup.org> <39821B4C400EC14DAD4DB25330A9271A024649@FR711WXCHMBA02.zeu.alcatel-lucent.com>, <2024BD14-E25C-426F-B046-46D61AF7077C@lurchi.franken.de> <39821B4C400EC14DAD4DB25330A9271A024714@FR711WXCHMBA02.zeu.alcatel-lucent.com>
To: "MARCON, JEROME (JEROME)" 
X-Mailer: Apple Mail (2.1283)
Cc: Randell Jesup , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-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, 11 Mar 2013 23:15:14 -0000

On Mar 11, 2013, at 5:20 PM, MARCON, JEROME (JEROME) wrote:

> Thanks again Michael. Inline my [JM1] comments.
>=20
> ________________________________________
> De : Michael Tuexen [Michael.Tuexen@lurchi.franken.de]
> Date d'envoi : lundi 11 mars 2013 20:23
> =C0 : MARCON, JEROME (JEROME)
> Cc: Randell Jesup; rtcweb@ietf.org
> Objet : Re: [rtcweb]  I-D Action: =
draft-ietf-rtcweb-data-channel-04.txt
>=20
> On Mar 11, 2013, at 2:51 PM, MARCON, JEROME (JEROME) wrote:
>=20
> > Randell,
> >
> > Assuming that some day a spec defines the transport of T.140 (or =
whatever similar protocol) over RTCWeb data channels
> > - with a registered subprotocol
> > - with multiple reliability options supported
> > - requiring some new data channel properties
> > - of which some are assymetric between the endpoints (like the =
"characters per second" defined in [RFC4103].
> >
> > Then (in the current version of your proposal) it seems to me that
> > * Because current DATA_CHANNEL_OPEN syntax is not extensible:
> > - it is not possible to carry these new properties in =
DATA_CHANNEL_OPEN
> Why is it not extensible? We have a message type and you could simply
> define another message...
>=20
> [JM1]. Mmh, then the spec defining T.140 (or whatever) over data =
channels (and willing to add a new property like "cps") would have to =
define a new message type  - and more less its own DATA_CHANNEL_OPEN =
structure? That's a costly extensibility.
>=20
> Also, given that different message types likely imply incompatible =
structures (as the spec says), the spec should specify how one endpoint =
can discover which message types the other endpoint supports. Of course =
the endpoint could reject the message by a close() again. But then this =
close() would have three hats :)
> - close a channel
> - reject some parameters of an incoming DATA_CHANNEL_OPEN
> - reject the format of an incoming DATA_CHANNEL_OPEN
I agree, having an error message and defining what error is sent back if =
an unknown message
is received does make sense.
> =20
> >
> > * Because the successful response to an open data channel request =
does not exist:
> > - it is not possible to agree on assymetric property values
> >
> > * Because the error response to an open data channel has no payload =
(error):
> > - an endpoint cannot easily know if this subprotocol is supported or =
which reliability properties are supported. Unless it sends as many =
DATA_CHANNEL_OPEN
> > messages as there are combinations of {subprotocol, property =
variants}
> >
> > Besides, if after unsuccessful tries (DATA_CHANNEL_OPEN) and errors =
(close() ), the endpoint decides to go for an SDP renegotiation:
> > - first this might be for nothing (the peer might not support =
anything after all),
> > - second  the design would be more complex, because for now the =
proposal assumes that SDP negotiation only happens once, in the =
offer/answer establishing the SCTP association, when no data channels =
exist.
> >
> > This might have been discussed before, but in the eventually that an =
inband protocol is really unavoidable (I still hope it is not), another =
option would have been to base this protocol on a new CHUNK type (e.g. =
Data Channel Control CHUNK) carrying request and response parameters in =
a bi-directional way. Most SCTP extensions are defined this way, aren't =
they ? And with the additional benefits:
> I don't think it makes sense to extend SCTP instead of doing this on =
top of SCTP, if you need.
>=20
> [JM1]. On top of SCTP, and to reduce the RTT, you had to drop =
DATA_CHANNEL_OPEN_RESPONSE at the cost of assymetric negotiation and =
proper error handling.
That is the drawback...
> Also a true protocol on top of SCTP would define a DATA_CHANNEL_CLOSE =
user message.
But it wouldn't really help, since you can't make sure that the message =
is received as
the last message. So using an SCTP mechanism for resetting streams makes =
sense...

Best regards
Michael
>=20
> Best regards
> Michael
> > - 1 RTT also
> > - built-in parameter extensibility
> > - refined error handling, e.g. report which parameter caused an =
error
> > - control messages not mixed with application messages
> > - proper data channel closing (the use of SSN reset is more like a =
trick; also open() and close() messages to not belong to the same =
protocol/layer)
> > - ability to define optimized retransmission procedures - those =
inherited from user messages might not be the best one
> > - ...
> >
> > I guess this has been discussed in the past ?
> >
> > Jerome
> >
> > ________________________________________
> > De : rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] de la part de =
Randell Jesup [randell-ietf@jesup.org]
> > Date d'envoi : mercredi 6 mars 2013 16:52
> > =C0 : rtcweb@ietf.org
> > Objet : Re: [rtcweb] I-D Action: =
draft-ietf-rtcweb-data-channel-04.txt
> >
> > On 3/6/2013 7:08 AM, MARCON, JEROME (JEROME) wrote:
> >> But then - and given that DATA_CHANNEL_OPEN_RESPONSE no longer =
exists in this new draft version - I wonder how the peer can reject an =
incoming DATA_CHANNEL_OPEN message signaling a 'subprotocol' it does not =
support.
> >
> > channel.close();
> >
> > I.e. there's no explicit prior-to-connect rejection, you simply =
state
> > instead "I'm not interested" and close it.  This resets the streams, =
and
> > causes the other side to be notified of the close. You're correct in
> > that this is not distinguished from other reasons to close() it; if
> > those are needed you should either negotiate it out-of-band, or make =
a
> > rejection part of the protocol you run over it.  This is entirely =
within
> > the application's domain.  Most applications would have no need for =
this.
> >
> > --
> > Randell Jesup
> > randell-ietf@jesup.org
> >
> > _______________________________________________
> > 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 Markus.Isomaki@nokia.com  Mon Mar 11 18:28: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 7E80E21F8D7A for ; Mon, 11 Mar 2013 18:28:00 -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 jPUP2q3oNPU2 for ; Mon, 11 Mar 2013 18:27:59 -0700 (PDT)
Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8CB21F8D77 for ; Mon, 11 Mar 2013 18:27:59 -0700 (PDT)
Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r2C1RoWL019123; Tue, 12 Mar 2013 03:27:51 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 12 Mar 2013 03:27:51 +0200
Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.232]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0328.011; Tue, 12 Mar 2013 01:27:44 +0000
From: 
To: , 
Thread-Topic: [rtcweb] VP8 litigation in Germany?
Thread-Index: AQHOHqpm6kb3TqdDTc2vRZKKqKDI4ZihQSJQ
Date: Tue, 12 Mar 2013 01:27:43 +0000
Message-ID: 
References:    <949EF20990823C4C85C18D59AA11AD8B01121E@FR712WXCHMBA11.zeu.alcatel-lucent.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.129.134.1]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 12 Mar 2013 01:27:51.0063 (UTC) FILETIME=[CFE2E270:01CE1EC0]
X-Nokia-AV: Clean
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 litigation in Germany?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 01:28:00 -0000

Hi,

Ted Hardie wrote:
>
>On Mon, Mar 11, 2013 at 6:23 PM, DRAGE, Keith (Keith) lucent.com> wrote:
>>
>> As I believe there are no IETF documents that specify H.264 or VP8 direc=
tly,
>then you will not get a direct declaration.
>>
>
>This contradicts what I understood Markus to be saying, which is that Noki=
a
>would supply one.  If I have misunderstood this text:
>
>Nokia is preparing to do a disclosure about it to the  IETF "to ensure tha=
t IETF
>working groups and participants have as much information about any IPR
>constraints on a technical proposal as  possible".
>
>I hope he will let me know.
>

Yes, Nokia is preparing a disclosure related to VP8.=20

What comes to H.264, the Nokia IPR related to that has been disclosed to th=
ose SDOs where that codec has been developed, except for the RTP payload fo=
rmat that is in the IETF. I assume all that is publicly available to intere=
sted parties. If I recall correctly, some pointers were floating around pri=
or to IETF 85. I'm sure others on this list know that side better than me.

Markus=20

From Markus.Isomaki@nokia.com  Mon Mar 11 18:42: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 C36A621F8922 for ; Mon, 11 Mar 2013 18:42:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.521
X-Spam-Level: 
X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5S-09lf91frh for ; Mon, 11 Mar 2013 18:42:15 -0700 (PDT)
Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 778AD21F88EF for ; Mon, 11 Mar 2013 18:42:15 -0700 (PDT)
Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r2C1g6dR030194; Tue, 12 Mar 2013 03:42:06 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 12 Mar 2013 03:42:06 +0200
Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.232]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.02.0328.011; Tue, 12 Mar 2013 01:42:05 +0000
From: 
To: , , , 
Thread-Topic: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
Thread-Index: AQHOHoKpQPNB80XASUa1nEzDk7aFy5ihPEwA//+PMoCAAC0HYA==
Date: Tue, 12 Mar 2013 01:42:05 +0000
Message-ID: 
References: <9F33F40F6F2CD847824537F3C4E37DDF06895013@MCHP04MSX.global-ad.net> <45A697A8FFD7CF48BCF2BE7E106F06040901B8ED@xmb-rcd-x04.cisco.com>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040901B8ED@xmb-rcd-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.129.134.1]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 12 Mar 2013 01:42:06.0620 (UTC) FILETIME=[CDD685C0:01CE1EC2]
X-Nokia-AV: Clean
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-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, 12 Mar 2013 01:42:17 -0000

Hi,

ICE/STUN/TURN and PCP are not really competitors or alternatives to each ot=
her.=20

A browser or any other client will anyway need to implement ICE/STUN/TURN t=
o work its way through non-PCP supporting NATs, which will be the majority =
for a long time even if PCP became succesfull. The benefit of the ICE/STUN/=
TURN approach is that every organization or individual who deploys NATs or =
firewalls will not need to deploy STUN and TURN servers, but they can be de=
ployed independently e.g. by the WebRTC service provider.=20

However, PCP, even gradually deployed, would still be useful as well. As Re=
inaldo is saying, it would improve robustness it produces explict NAT mappi=
ngs with explicit durations. Also, it can serve as an alternative to STUN/T=
URN in case the browser happens to be behind a PCP-capable NAT/FW. So, PCP =
can be seen as an optimization and should be used when it is available. PCP=
 can also help clients behind NAT/FW to reduce their keep-alive rate which =
is applicable to WebRTC as well. However, as depicted in [1], knowing when =
a client can entirely rely on PCP is not always so easy to detect.

I hope we will see PCP deployment especially in the mobile/cellular access,=
 but as many people have pointed out, the success rate of this type of prot=
ocols has been quite low. So it will be a nice surprise rather than somethi=
ng I would count on if it happens.

[1] http://datatracker.ietf.org/doc/draft-reddy-pcp-optimize-keepalives/?in=
clude_text=3D1.

Markus


>-----Original Message-----
>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
>Of ext Reinaldo Penno (repenno)
>Sent: 11 March, 2013 22:14
>To: Hutton, Andrew; Harald Alvestrand; rtcweb@ietf.org
>Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-
>considerations-00.txt
>
>
>
>On 3/11/13 12:58 PM, "Hutton, Andrew"
> wrote:
>
>>On: 11 March 2013 14:03 Reinaldo Penno (repenno) Wrote:
>>
>>
>>>
>>> I'm sure STUN and TURN servers are not universally deployed ('100%')
>>> in ISP networks either.
>>
>>It is not required for an ISP to deploy a TURN server the webrtc TURN
>>server is much more likely to be deployed by the web application
>>provider which will instruct the browser to use it when accessing its ser=
vice.
>
>The line between Application providers and ISPs is very blurry today.
>Application provider can be over the top or it can be the ISP itself.
>
>
>>
>>>
>>> But I'm not proposing dropping STUN/TURN in lieu of PCP, but using
>>> PCP as an additional technique. Maybe you misunderstood what I was
>>> proposing.
>>>
>>
>>Understood but would need to understand what the benefits of doing so
>>would be.
>
>
>Yes, certainly.
>
>A protocol that allows a host to explicit control FW/NAT mappings/pinholes
>(both for incoming and outgoing connections IPv4/IPv6), including lifetime=
,
>knowing when such device restart/reboot, is more deterministic.
>Client is always free to use STUN/TURN.
>
>
>>
>>Regards
>>Andy
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb

From cb.list6@gmail.com  Mon Mar 11 18:57: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 39CC321F86D9 for ; Mon, 11 Mar 2013 18:57:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.605
X-Spam-Level: 
X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=0.838,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-MuQVJuAqdX for ; Mon, 11 Mar 2013 18:57:03 -0700 (PDT)
Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 2546D21F86D5 for ; Mon, 11 Mar 2013 18:57:02 -0700 (PDT)
Received: by mail-wg0-f43.google.com with SMTP id e12so5646823wge.10 for ; Mon, 11 Mar 2013 18:57:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=9jnBUFyITSjlenQMeskfXT5HZ5rppKhS/Id7DBp6hS4=; b=JfaSHiy7i7PPzDK073hC/GaY1y034mhAI40nUbHqhy9Ts0sWzu6FnqCq+IkgvPLzfw h+M0DS5//eao8UDrVcrt2BrJytDFYxdeQMCh5m1rwNFV1M7K2DFQndclDgg35dG+kRJJ T0BbmcwxZpzoPMaTqWJ2jWc1YsjcV+86mZvfqd5veH24tCf5HLXCJDEHkmjr4sc8lA6W 2qWLVR9SBCmfEnt6yjsSwCbEYRY4HXILycjkcYU34XlPF0sV4vvc9qeRBkcCamdJBRWg CW2hEDDgnnwEjA80GemUwiZfCcsOMvL5kKARV5T0jWe54nExR4xcntl1XitjfPzA9kbL xiDg==
MIME-Version: 1.0
X-Received: by 10.194.20.40 with SMTP id k8mr23352067wje.16.1363053422275; Mon, 11 Mar 2013 18:57:02 -0700 (PDT)
Received: by 10.194.20.35 with HTTP; Mon, 11 Mar 2013 18:57:02 -0700 (PDT)
In-Reply-To: 
References: <9F33F40F6F2CD847824537F3C4E37DDF06895013@MCHP04MSX.global-ad.net> <45A697A8FFD7CF48BCF2BE7E106F06040901B8ED@xmb-rcd-x04.cisco.com> 
Date: Mon, 11 Mar 2013 18:57:02 -0700
Message-ID: 
From: Cameron Byrne 
To: Markus.Isomaki@nokia.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-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, 12 Mar 2013 01:57:04 -0000

On Mon, Mar 11, 2013 at 6:42 PM,   wrote:
> Hi,
>
> ICE/STUN/TURN and PCP are not really competitors or alternatives to each =
other.
>
> A browser or any other client will anyway need to implement ICE/STUN/TURN=
 to work its way through non-PCP supporting NATs, which will be the majorit=
y for a long time even if PCP became succesfull. The benefit of the ICE/STU=
N/TURN approach is that every organization or individual who deploys NATs o=
r firewalls will not need to deploy STUN and TURN servers, but they can be =
deployed independently e.g. by the WebRTC service provider.
>
> However, PCP, even gradually deployed, would still be useful as well. As =
Reinaldo is saying, it would improve robustness it produces explict NAT map=
pings with explicit durations. Also, it can serve as an alternative to STUN=
/TURN in case the browser happens to be behind a PCP-capable NAT/FW. So, PC=
P can be seen as an optimization and should be used when it is available. P=
CP can also help clients behind NAT/FW to reduce their keep-alive rate whic=
h is applicable to WebRTC as well. However, as depicted in [1], knowing whe=
n a client can entirely rely on PCP is not always so easy to detect.
>
> I hope we will see PCP deployment especially in the mobile/cellular acces=
s, but as many people have pointed out, the success rate of this type of pr=
otocols has been quite low. So it will be a nice surprise rather than somet=
hing I would count on if it happens.
>
> [1] http://datatracker.ietf.org/doc/draft-reddy-pcp-optimize-keepalives/?=
include_text=3D1.
>
> Markus
>

I am hopeful e2e connectivity will be provided by IPv6 prior to PCP
reaching critical mass. This more because i am on bullish on v6 than
bearish on PCP.  That said, the more interesting use-case is v4 to v6
via TURN, but i believe that is already covered well ... another
reason ICE is a good fit.

CB
>
>>-----Original Message-----
>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
>>Of ext Reinaldo Penno (repenno)
>>Sent: 11 March, 2013 22:14
>>To: Hutton, Andrew; Harald Alvestrand; rtcweb@ietf.org
>>Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-
>>considerations-00.txt
>>
>>
>>
>>On 3/11/13 12:58 PM, "Hutton, Andrew"
>> wrote:
>>
>>>On: 11 March 2013 14:03 Reinaldo Penno (repenno) Wrote:
>>>
>>>
>>>>
>>>> I'm sure STUN and TURN servers are not universally deployed ('100%')
>>>> in ISP networks either.
>>>
>>>It is not required for an ISP to deploy a TURN server the webrtc TURN
>>>server is much more likely to be deployed by the web application
>>>provider which will instruct the browser to use it when accessing its se=
rvice.
>>
>>The line between Application providers and ISPs is very blurry today.
>>Application provider can be over the top or it can be the ISP itself.
>>
>>
>>>
>>>>
>>>> But I'm not proposing dropping STUN/TURN in lieu of PCP, but using
>>>> PCP as an additional technique. Maybe you misunderstood what I was
>>>> proposing.
>>>>
>>>
>>>Understood but would need to understand what the benefits of doing so
>>>would be.
>>
>>
>>Yes, certainly.
>>
>>A protocol that allows a host to explicit control FW/NAT mappings/pinhole=
s
>>(both for incoming and outgoing connections IPv4/IPv6), including lifetim=
e,
>>knowing when such device restart/reboot, is more deterministic.
>>Client is always free to use STUN/TURN.
>>
>>
>>>
>>>Regards
>>>Andy
>>
>>_______________________________________________
>>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 tireddy@cisco.com  Mon Mar 11 19:32: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 04B5721F8AB2 for ; Mon, 11 Mar 2013 19:32:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.443
X-Spam-Level: 
X-Spam-Status: No, score=-10.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTsmeS1qjJ5j for ; Mon, 11 Mar 2013 19:32:49 -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 1AE7721F8AA0 for ; Mon, 11 Mar 2013 19:32:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3037; q=dns/txt; s=iport; t=1363055569; x=1364265169; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=IF8OOfvoTp8g5Zor7rg8wOtmY48naaIXQB7vv3lqdRI=; b=m+r8qusi9yWkbVtt+wLBgNm3J2BmK2Rsfq4yzkInEhmJHFEXRn6CCEUj vXn9BYThyBNwgT9yRDZBCKQBBivPNFIUKPeb64FSrWgF7kQaH3OnQ8NHT +cSD0eJWtjHom1Tfn2uW01haLtmntwlF7gbpSbtkN0xBzMm38iTeycuTg 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAHmTPlGtJV2b/2dsb2JhbABDxGaBXxZ0gikBAQEEAQEBNzQXBAIBCBEEAQELFAkHJwsUCAEIAgQBEggBiAoMr16QHY5dJg0FBoJZYQOXc4pBhRaBVIEpDYIo
X-IronPort-AV: E=Sophos;i="4.84,827,1355097600"; d="scan'208";a="186358057"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 12 Mar 2013 02:32:48 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2C2Wm4S020440 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Mar 2013 02:32:48 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 21:32:48 -0500
From: "Tirumaleswar Reddy (tireddy)" 
To: "Hutton, Andrew" , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
Thread-Index: AQHOHj9zQPNB80XASUa1nEzDk7aFy5igtR3QgACdbFA=
Date: Tue, 12 Mar 2013 02:32:48 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A149314E8@xmb-rcd-x10.cisco.com>
References: <9F33F40F6F2CD847824537F3C4E37DDF06894839@MCHP04MSX.global-ad.net>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF06894839@MCHP04MSX.global-ad.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.71.82]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-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, 12 Mar 2013 02:32:50 -0000

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf =
Of
> Hutton, Andrew
> Sent: Monday, March 11, 2013 10:27 PM
> To: rtcweb@ietf.org
> Subject: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-
> considerations-00.txt
>=20
> FYI - We submitted this draft today it relates to the requirements in the=
 use
> case draft for rtcweb to work in the presence of firewalls and http proxi=
es
> etc.
>=20
> Look forward to feedback and hope that this can be considered for adoptio=
n by
> the working group.
>=20
> Regards
> Andy

we submitted a individual draft that addresses the problem of Firewalls to =
permit UDP.
http://tools.ietf.org/html/draft-reddy-mmusic-stun-auth-fw-traversal-00

This draft proposes extensions to ICE connectivity checks that can be exami=
ned by the firewall to permit outgoing UDP flows across the firewall.

--Tiru.

>=20
>=20
>=20
> -----Original Message-----
> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org=
] On
> Behalf Of internet-drafts@ietf.org
> Sent: 11 March 2013 06:01
> To: i-d-announce@ietf.org
> Subject: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.t=
xt
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>=20
>=20
> 	Title           : RTCWEB Considerations for NATs, Firewalls and HTTP
> proxies
> 	Author(s)       : Thomas Stach
>                           Andrew Hutton
>                           Justin Uberti
> 	Filename        : draft-hutton-rtcweb-nat-firewall-considerations-00.txt
> 	Pages           : 8
> 	Date            : 2013-03-11
>=20
> Abstract:
>    This document describes mechanism to enable media stream
>    establishment in the presence of NATs, firewalls and HTTP proxies.
>    HTTP proxy and firewall policies applied in many private network
>    domains introduce obstacles to the successful establishment of media
>    stream via RTCWEB.  This document examines some of these policies and
>    develops requirements on the web browsers designed to provide the
>    best possible chance of media connectivity between RTCWEB peers.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-hutton-rtcweb-nat-firewall-
> considerations
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-consideration=
s-00
>=20
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> 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
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

From repenno@cisco.com  Mon Mar 11 19:46: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 5968D21F8A9B for ; Mon, 11 Mar 2013 19:46:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.468
X-Spam-Level: 
X-Spam-Status: No, score=-10.468 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcIn3rluMCBo for ; Mon, 11 Mar 2013 19:46:46 -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 300AA21F87B1 for ; Mon, 11 Mar 2013 19:46:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4239; q=dns/txt; s=iport; t=1363056406; x=1364266006; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=7klgJvW/ARrAmdN6EZvteSViYgB9HIvvibWZu4QpMeA=; b=buhtDZharZdtdoxSWdaPSvOhGI6BRDyLnoJF2WHyCjOCUHwQVO3JZu06 YJlKgQYCL6gdsnZKG/diwWJks8sTq/4UsBwIoiphw01EpFCosT4pUtOD0 fHl9zw8A7M3rJFt2GN9BH//g5s8nhNNgjNJifqU86dQWY5gu2F5WwJZdm k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAOWVPlGtJXHA/2dsb2JhbABDxGaBXxZ0gikBAQEEAQEBNzQLDAYBCA4DBAEBAQoUCSgGCxQIAQgCBAENBQiHeQMPDK9ihjYNiVuMRn2BGgYgCwcGgllhA5R1gn6KPoUZgVSBKQ2BczU
X-IronPort-AV: E=Sophos;i="4.84,827,1355097600"; d="scan'208";a="186355855"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 12 Mar 2013 02:46:45 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2C2kjfs018033 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Mar 2013 02:46:45 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 21:46:45 -0500
From: "Reinaldo Penno (repenno)" 
To: Cameron Byrne , "Markus.Isomaki@nokia.com" 
Thread-Topic: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
Thread-Index: AQHOHoKpVPM3WtZH0EiYxevcVicwOpihPEwA//+PMoCAANDogIAABC0A///K0gA=
Date: Tue, 12 Mar 2013 02:46:43 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040901BC8F@xmb-rcd-x04.cisco.com>
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.21.84.182]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <41EA2390E9CD2D47806AE7D16DC9FEBB@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-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, 12 Mar 2013 02:46:47 -0000

Agree with you on e2e IPv6 would be ideal. PCP is well suited to control
IPv6 firewalls and it is one of the main use-cases as part of IPV6 CPE
requirements RFC. Unless you think with IPv6 there will no IPv6 firewalls.

On 3/11/13 9:57 PM, "Cameron Byrne"  wrote:

>On Mon, Mar 11, 2013 at 6:42 PM,   wrote:
>> Hi,
>>
>> ICE/STUN/TURN and PCP are not really competitors or alternatives to
>>each other.
>>
>> A browser or any other client will anyway need to implement
>>ICE/STUN/TURN to work its way through non-PCP supporting NATs, which
>>will be the majority for a long time even if PCP became succesfull. The
>>benefit of the ICE/STUN/TURN approach is that every organization or
>>individual who deploys NATs or firewalls will not need to deploy STUN
>>and TURN servers, but they can be deployed independently e.g. by the
>>WebRTC service provider.
>>
>> However, PCP, even gradually deployed, would still be useful as well.
>>As Reinaldo is saying, it would improve robustness it produces explict
>>NAT mappings with explicit durations. Also, it can serve as an
>>alternative to STUN/TURN in case the browser happens to be behind a
>>PCP-capable NAT/FW. So, PCP can be seen as an optimization and should be
>>used when it is available. PCP can also help clients behind NAT/FW to
>>reduce their keep-alive rate which is applicable to WebRTC as well.
>>However, as depicted in [1], knowing when a client can entirely rely on
>>PCP is not always so easy to detect.
>>
>> I hope we will see PCP deployment especially in the mobile/cellular
>>access, but as many people have pointed out, the success rate of this
>>type of protocols has been quite low. So it will be a nice surprise
>>rather than something I would count on if it happens.
>>
>> [1]=20
>>http://datatracker.ietf.org/doc/draft-reddy-pcp-optimize-keepalives/?incl
>>ude_text=3D1.
>>
>> Markus
>>
>
>I am hopeful e2e connectivity will be provided by IPv6 prior to PCP
>reaching critical mass. This more because i am on bullish on v6 than
>bearish on PCP.  That said, the more interesting use-case is v4 to v6
>via TURN, but i believe that is already covered well ... another
>reason ICE is a good fit.
>
>CB
>>
>>>-----Original Message-----
>>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
>>>Of ext Reinaldo Penno (repenno)
>>>Sent: 11 March, 2013 22:14
>>>To: Hutton, Andrew; Harald Alvestrand; rtcweb@ietf.org
>>>Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-
>>>considerations-00.txt
>>>
>>>
>>>
>>>On 3/11/13 12:58 PM, "Hutton, Andrew"
>>> wrote:
>>>
>>>>On: 11 March 2013 14:03 Reinaldo Penno (repenno) Wrote:
>>>>
>>>>
>>>>>
>>>>> I'm sure STUN and TURN servers are not universally deployed ('100%')
>>>>> in ISP networks either.
>>>>
>>>>It is not required for an ISP to deploy a TURN server the webrtc TURN
>>>>server is much more likely to be deployed by the web application
>>>>provider which will instruct the browser to use it when accessing its
>>>>service.
>>>
>>>The line between Application providers and ISPs is very blurry today.
>>>Application provider can be over the top or it can be the ISP itself.
>>>
>>>
>>>>
>>>>>
>>>>> But I'm not proposing dropping STUN/TURN in lieu of PCP, but using
>>>>> PCP as an additional technique. Maybe you misunderstood what I was
>>>>> proposing.
>>>>>
>>>>
>>>>Understood but would need to understand what the benefits of doing so
>>>>would be.
>>>
>>>
>>>Yes, certainly.
>>>
>>>A protocol that allows a host to explicit control FW/NAT
>>>mappings/pinholes
>>>(both for incoming and outgoing connections IPv4/IPv6), including
>>>lifetime,
>>>knowing when such device restart/reboot, is more deterministic.
>>>Client is always free to use STUN/TURN.
>>>
>>>
>>>>
>>>>Regards
>>>>Andy
>>>
>>>_______________________________________________
>>>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 tireddy@cisco.com  Mon Mar 11 19: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 612B221F8A9B for ; Mon, 11 Mar 2013 19:48:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.443
X-Spam-Level: 
X-Spam-Status: No, score=-10.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybbsINtQX3xT for ; Mon, 11 Mar 2013 19:48:48 -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 659DC21F88E8 for ; Mon, 11 Mar 2013 19:48:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4403; q=dns/txt; s=iport; t=1363056528; x=1364266128; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=IgLgagId/yBXVkKUXa2S+GPSqE3YRUCKPiaceQ0+fA0=; b=ij/9TvJYg6ZCoZxUYPolKd7CP2XdE/O3TKZDG/zt+baPv119i606fdrv prLVG7TMC3TbJ2S3Unhk7ffZ3uqbmk9blpnQF/6pZGRuurPcPeUzKILbl 9TXyfPLuoz6tCo/RrNeq/v1sQUjwr1pauC+cg0oJTOcwV6dhm7ZrwARs2 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAGOWPlGtJV2Z/2dsb2JhbABDxGaBXxZ0gikBAQEDAQEBATc0FwQCAQgRBAEBAQoUCQcnCxQIAQgCBAESCIgFBgyvZJAejUOBGiYSBoJZYQOXc49XgVSBKQ2BczU
X-IronPort-AV: E=Sophos;i="4.84,827,1355097600"; d="scan'208";a="186356902"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 12 Mar 2013 02:48:48 +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 r2C2mlLV022713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Mar 2013 02:48:47 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 21:48:47 -0500
From: "Tirumaleswar Reddy (tireddy)" 
To: "Markus.Isomaki@nokia.com" , "Reinaldo Penno (repenno)" , "andrew.hutton@siemens-enterprise.com" , "harald@alvestrand.no" , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
Thread-Index: AQHOHoLCeBG0qZf7qESwwRmByq5f3JihPEwAgAAEjACAAFuNgP//urKQ
Date: Tue, 12 Mar 2013 02:48:46 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A1493154C@xmb-rcd-x10.cisco.com>
References: <9F33F40F6F2CD847824537F3C4E37DDF06895013@MCHP04MSX.global-ad.net> <45A697A8FFD7CF48BCF2BE7E106F06040901B8ED@xmb-rcd-x04.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.65.71.82]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-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, 12 Mar 2013 02:48:49 -0000

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf =
Of
> Markus.Isomaki@nokia.com
> Sent: Tuesday, March 12, 2013 7:12 AM
> To: Reinaldo Penno (repenno); andrew.hutton@siemens-enterprise.com;
> harald@alvestrand.no; rtcweb@ietf.org
> Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-
> considerations-00.txt
>=20
> Hi,
>=20
> ICE/STUN/TURN and PCP are not really competitors or alternatives to each
> other.

Good point. http://tools.ietf.org/html/rfc6544#section-5.3 explains to gath=
er candidates also using PCP in addition to using STUN/TURN. ICE connectivi=
ty checks
will reveal if PCP Unaware NAT exists or not.=20

>=20
> A browser or any other client will anyway need to implement ICE/STUN/TURN=
 to
> work its way through non-PCP supporting NATs, which will be the majority =
for a
> long time even if PCP became succesfull. The benefit of the ICE/STUN/TURN
> approach is that every organization or individual who deploys NATs or
> firewalls will not need to deploy STUN and TURN servers, but they can be
> deployed independently e.g. by the WebRTC service provider.

Enterprise use cases would be different. http://tools.ietf.org/html/draft-i=
etf-rtcweb-use-cases-and-requirements-09 explains some of the reasons to de=
ploy TURN server in the campus itself.=20

--Tiru.

>=20
> However, PCP, even gradually deployed, would still be useful as well. As
> Reinaldo is saying, it would improve robustness it produces explict NAT
> mappings with explicit durations. Also, it can serve as an alternative to
> STUN/TURN in case the browser happens to be behind a PCP-capable NAT/FW. =
So,
> PCP can be seen as an optimization and should be used when it is availabl=
e.
> PCP can also help clients behind NAT/FW to reduce their keep-alive rate w=
hich
> is applicable to WebRTC as well. However, as depicted in [1], knowing whe=
n a
> client can entirely rely on PCP is not always so easy to detect.
>=20
> I hope we will see PCP deployment especially in the mobile/cellular acces=
s,
> but as many people have pointed out, the success rate of this type of
> protocols has been quite low. So it will be a nice surprise rather than
> something I would count on if it happens.
>=20
> [1] http://datatracker.ietf.org/doc/draft-reddy-pcp-optimize-
> keepalives/?include_text=3D1.
>=20
> Markus
>=20
>=20
> >-----Original Message-----
> >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
> >Of ext Reinaldo Penno (repenno)
> >Sent: 11 March, 2013 22:14
> >To: Hutton, Andrew; Harald Alvestrand; rtcweb@ietf.org
> >Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-
> >considerations-00.txt
> >
> >
> >
> >On 3/11/13 12:58 PM, "Hutton, Andrew"
> > wrote:
> >
> >>On: 11 March 2013 14:03 Reinaldo Penno (repenno) Wrote:
> >>
> >>
> >>>
> >>> I'm sure STUN and TURN servers are not universally deployed ('100%')
> >>> in ISP networks either.
> >>
> >>It is not required for an ISP to deploy a TURN server the webrtc TURN
> >>server is much more likely to be deployed by the web application
> >>provider which will instruct the browser to use it when accessing its
> service.
> >
> >The line between Application providers and ISPs is very blurry today.
> >Application provider can be over the top or it can be the ISP itself.
> >
> >
> >>
> >>>
> >>> But I'm not proposing dropping STUN/TURN in lieu of PCP, but using
> >>> PCP as an additional technique. Maybe you misunderstood what I was
> >>> proposing.
> >>>
> >>
> >>Understood but would need to understand what the benefits of doing so
> >>would be.
> >
> >
> >Yes, certainly.
> >
> >A protocol that allows a host to explicit control FW/NAT mappings/pinhol=
es
> >(both for incoming and outgoing connections IPv4/IPv6), including lifeti=
me,
> >knowing when such device restart/reboot, is more deterministic.
> >Client is always free to use STUN/TURN.
> >
> >
> >>
> >>Regards
> >>Andy
> >
> >_______________________________________________
> >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 cb.list6@gmail.com  Mon Mar 11 19:51: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 AC75721F8B35 for ; Mon, 11 Mar 2013 19:51:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.32
X-Spam-Level: 
X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.122,  BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsPIifG6EVj4 for ; Mon, 11 Mar 2013 19:51:32 -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 5D43A21F8A9B for ; Mon, 11 Mar 2013 19:51:32 -0700 (PDT)
Received: by mail-wg0-f41.google.com with SMTP id ds1so2787133wgb.0 for ; Mon, 11 Mar 2013 19:51:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=o8knrnSbFE4nxyS7wXu/rfSc1uXtASg5jPeKx1de9J4=; b=IaDzufcjEi545ywbUmLfth2Wu92jSMeMJoJGgH1JqnZuB0jkTXjzqbkXjizQhHz3uO dbUk0e6yxou8yN3ttVAW5lz+J219sxIF3ltl3QArSqozPzUaGhK7aJez0dIGdnugcITc 1UOTP2ohw5vw8HC2ACawGfo7N2IqvWbwcyzjB167h7ZCyKowYHVQ2kzJ23UD+vIgRPSF j9UAma22KLNCQbgr3SY4TnAQogzYgZFIOhH5AwpP6zCByov2X07D9Elu5ehPSdFUEtAE 1dnMbas4+8FQ1ACP6uS/C0w2yaIQJaLDQjSF6usQmFeblEjCOFX9KFE/wnsuIaIVABf3 Q6Zw==
MIME-Version: 1.0
X-Received: by 10.194.242.163 with SMTP id wr3mr23254857wjc.35.1363056691510;  Mon, 11 Mar 2013 19:51:31 -0700 (PDT)
Received: by 10.194.20.35 with HTTP; Mon, 11 Mar 2013 19:51:31 -0700 (PDT)
Received: by 10.194.20.35 with HTTP; Mon, 11 Mar 2013 19:51:31 -0700 (PDT)
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040901BC8F@xmb-rcd-x04.cisco.com>
References:  <45A697A8FFD7CF48BCF2BE7E106F06040901BC8F@xmb-rcd-x04.cisco.com>
Date: Mon, 11 Mar 2013 19:51:31 -0700
Message-ID: 
From: Cameron Byrne 
To: repenno@cisco.com
Content-Type: multipart/alternative; boundary=089e013d1da8e8045f04d7b15d07
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-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, 12 Mar 2013 02:51:33 -0000

--089e013d1da8e8045f04d7b15d07
Content-Type: text/plain; charset=ISO-8859-1

On Mar 11, 2013 7:46 PM, "Reinaldo Penno (repenno)" 
wrote:
>
> Agree with you on e2e IPv6 would be ideal. PCP is well suited to control
> IPv6 firewalls and it is one of the main use-cases as part of IPV6 CPE
> requirements RFC. Unless you think with IPv6 there will no IPv6 firewalls.
>

That is my plan. Ipv6 e2e ftw.

CB

> On 3/11/13 9:57 PM, "Cameron Byrne"  wrote:
>
> >On Mon, Mar 11, 2013 at 6:42 PM,   wrote:
> >> Hi,
> >>
> >> ICE/STUN/TURN and PCP are not really competitors or alternatives to
> >>each other.
> >>
> >> A browser or any other client will anyway need to implement
> >>ICE/STUN/TURN to work its way through non-PCP supporting NATs, which
> >>will be the majority for a long time even if PCP became succesfull. The
> >>benefit of the ICE/STUN/TURN approach is that every organization or
> >>individual who deploys NATs or firewalls will not need to deploy STUN
> >>and TURN servers, but they can be deployed independently e.g. by the
> >>WebRTC service provider.
> >>
> >> However, PCP, even gradually deployed, would still be useful as well.
> >>As Reinaldo is saying, it would improve robustness it produces explict
> >>NAT mappings with explicit durations. Also, it can serve as an
> >>alternative to STUN/TURN in case the browser happens to be behind a
> >>PCP-capable NAT/FW. So, PCP can be seen as an optimization and should be
> >>used when it is available. PCP can also help clients behind NAT/FW to
> >>reduce their keep-alive rate which is applicable to WebRTC as well.
> >>However, as depicted in [1], knowing when a client can entirely rely on
> >>PCP is not always so easy to detect.
> >>
> >> I hope we will see PCP deployment especially in the mobile/cellular
> >>access, but as many people have pointed out, the success rate of this
> >>type of protocols has been quite low. So it will be a nice surprise
> >>rather than something I would count on if it happens.
> >>
> >> [1]
> >>
http://datatracker.ietf.org/doc/draft-reddy-pcp-optimize-keepalives/?incl
> >>ude_text=1.
> >>
> >> Markus
> >>
> >
> >I am hopeful e2e connectivity will be provided by IPv6 prior to PCP
> >reaching critical mass. This more because i am on bullish on v6 than
> >bearish on PCP.  That said, the more interesting use-case is v4 to v6
> >via TURN, but i believe that is already covered well ... another
> >reason ICE is a good fit.
> >
> >CB
> >>
> >>>-----Original Message-----
> >>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
Behalf
> >>>Of ext Reinaldo Penno (repenno)
> >>>Sent: 11 March, 2013 22:14
> >>>To: Hutton, Andrew; Harald Alvestrand; rtcweb@ietf.org
> >>>Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-
> >>>considerations-00.txt
> >>>
> >>>
> >>>
> >>>On 3/11/13 12:58 PM, "Hutton, Andrew"
> >>> wrote:
> >>>
> >>>>On: 11 March 2013 14:03 Reinaldo Penno (repenno) Wrote:
> >>>>
> >>>>
> >>>>>
> >>>>> I'm sure STUN and TURN servers are not universally deployed ('100%')
> >>>>> in ISP networks either.
> >>>>
> >>>>It is not required for an ISP to deploy a TURN server the webrtc TURN
> >>>>server is much more likely to be deployed by the web application
> >>>>provider which will instruct the browser to use it when accessing its
> >>>>service.
> >>>
> >>>The line between Application providers and ISPs is very blurry today.
> >>>Application provider can be over the top or it can be the ISP itself.
> >>>
> >>>
> >>>>
> >>>>>
> >>>>> But I'm not proposing dropping STUN/TURN in lieu of PCP, but using
> >>>>> PCP as an additional technique. Maybe you misunderstood what I was
> >>>>> proposing.
> >>>>>
> >>>>
> >>>>Understood but would need to understand what the benefits of doing so
> >>>>would be.
> >>>
> >>>
> >>>Yes, certainly.
> >>>
> >>>A protocol that allows a host to explicit control FW/NAT
> >>>mappings/pinholes
> >>>(both for incoming and outgoing connections IPv4/IPv6), including
> >>>lifetime,
> >>>knowing when such device restart/reboot, is more deterministic.
> >>>Client is always free to use STUN/TURN.
> >>>
> >>>
> >>>>
> >>>>Regards
> >>>>Andy
> >>>
> >>>_______________________________________________
> >>>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
>

--089e013d1da8e8045f04d7b15d07
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On Mar 11, 2013 7:46 PM, "Reinaldo Penno (repenno)" <repenno@cisco.com> wrote:

>

> Agree with you on e2e IPv6 would be ideal. PCP is well suited to contr=
ol

> IPv6 firewalls and it is one of the main use-cases as part of IPV6 CPE=


> requirements RFC. Unless you think with IPv6 there will no IPv6 firewa=
lls.

>


That is my plan. Ipv6 e2e ftw. 


CB


> On 3/11/13 9:57 PM, "Cameron Byrne" <cb.list6@gmail.com> wrote:

>

> >On Mon, Mar 11, 2013 at 6:42 PM, =A0<Markus.Isomaki@nokia.com> wrote:

> >> Hi,

> >>

> >> ICE/STUN/TURN and PCP are not really competitors or alternati=
ves to

> >>each other.

> >>

> >> A browser or any other client will anyway need to implement
> >>ICE/STUN/TURN to work its way through non-PCP supporting NATs,=
 which

> >>will be the majority for a long time even if PCP became succes=
full. The

> >>benefit of the ICE/STUN/TURN approach is that every organizati=
on or

> >>individual who deploys NATs or firewalls will not need to depl=
oy STUN

> >>and TURN servers, but they can be deployed independently e.g. =
by the

> >>WebRTC service provider.

> >>

> >> However, PCP, even gradually deployed, would still be useful =
as well.

> >>As Reinaldo is saying, it would improve robustness it produces=
 explict

> >>NAT mappings with explicit durations. Also, it can serve as an=


> >>alternative to STUN/TURN in case the browser happens to be beh=
ind a

> >>PCP-capable NAT/FW. So, PCP can be seen as an optimization and=
 should be

> >>used when it is available. PCP can also help clients behind NA=
T/FW to

> >>reduce their keep-alive rate which is applicable to WebRTC as =
well.

> >>However, as depicted in [1], knowing when a client can entirel=
y rely on

> >>PCP is not always so easy to detect.

> >>

> >> I hope we will see PCP deployment especially in the mobile/ce=
llular

> >>access, but as many people have pointed out, the success rate =
of this

> >>type of protocols has been quite low. So it will be a nice sur=
prise

> >>rather than something I would count on if it happens.

> >>

> >> [1]

> >>http://datatracker.ietf.org/doc/draft-reddy-pcp-opt=
imize-keepalives/?incl

> >>ude_text=3D1.

> >>

> >> Markus

> >>

> >

> >I am hopeful e2e connectivity will be provided by IPv6 prior to PC=
P

> >reaching critical mass. This more because i am on bullish on v6 th=
an

> >bearish on PCP. =A0That said, the more interesting use-case is v4 =
to v6

> >via TURN, but i believe that is already covered well ... another
> >reason ICE is a good fit.

> >

> >CB

> >>

> >>>-----Original Message-----

> >>>From: rtcweb-bo=
unces@ietf.org [mailto:rtcwe=
b-bounces@ietf.org] On Behalf

> >>>Of ext Reinaldo Penno (repenno)

> >>>Sent: 11 March, 2013 22:14

> >>>To: Hutton, Andrew; Harald Alvestrand; rtcweb@ietf.org

> >>>Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-=
nat-firewall-

> >>>considerations-00.txt

> >>>

> >>>

> >>>

> >>>On 3/11/13 12:58 PM, "Hutton, Andrew"

> >>><andrew.hutton@siemens-enterprise.com> wrote:

> >>>

> >>>>On: 11 March 2013 14:03 Reinaldo Penno (repenno) Wrote=
:

> >>>>

> >>>>

> >>>>>

> >>>>> I'm sure STUN and TURN servers are not univer=
sally deployed ('100%')

> >>>>> in ISP networks either.

> >>>>

> >>>>It is not required for an ISP to deploy a TURN server =
the webrtc TURN

> >>>>server is much more likely to be deployed by the web a=
pplication

> >>>>provider which will instruct the browser to use it whe=
n accessing its

> >>>>service.

> >>>

> >>>The line between Application providers and ISPs is very bl=
urry today.

> >>>Application provider can be over the top or it can be the =
ISP itself.

> >>>

> >>>

> >>>>

> >>>>>

> >>>>> But I'm not proposing dropping STUN/TURN in l=
ieu of PCP, but using

> >>>>> PCP as an additional technique. Maybe you misunde=
rstood what I was

> >>>>> proposing.

> >>>>>

> >>>>

> >>>>Understood but would need to understand what the benef=
its of doing so

> >>>>would be.

> >>>

> >>>

> >>>Yes, certainly.

> >>>

> >>>A protocol that allows a host to explicit control FW/NAT
> >>>mappings/pinholes

> >>>(both for incoming and outgoing connections IPv4/IPv6), in=
cluding

> >>>lifetime,

> >>>knowing when such device restart/reboot, is more determini=
stic.

> >>>Client is always free to use STUN/TURN.

> >>>

> >>>

> >>>>

> >>>>Regards

> >>>>Andy

> >>>

> >>>_______________________________________________

> >>>rtcweb mailing list

> >>>rtcweb@ietf.org

> >>>h=
ttps://www.ietf.org/mailman/listinfo/rtcweb

> >> _______________________________________________

> >> rtcweb mailing list

> >> rtcweb@ietf.org

> >> http=
s://www.ietf.org/mailman/listinfo/rtcweb

>




--089e013d1da8e8045f04d7b15d07--

From repenno@cisco.com  Mon Mar 11 20:05: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 2D26421F8563 for ; Mon, 11 Mar 2013 20:05:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.162
X-Spam-Level: 
X-Spam-Status: No, score=-10.162 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yVQWGo4Aygj for ; Mon, 11 Mar 2013 20:05:26 -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 8DB7321F856D for ; Mon, 11 Mar 2013 20:05:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3678; q=dns/txt; s=iport; t=1363057521; x=1364267121; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=KjS/cPdFjCnsxlPnX2yBfg6gwAywhDZdQr5HG4UzlR8=; b=Ym+KF7AWgQW4jMjr3Qm0a5eLa4v7Idm4J8JoU3izZThaZRm6r3oRNxJF V+6t3arJNfxh03QP7DwZajDfVi86UFmp+TI92szrLddhnXGHX/Pf+bKRp Rwj52TMY4YE4NXjazE+mBOvipUvlnwL+iZL2c2TcNwL98ukCe4w3wF9m8 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAOmYPlGtJV2Y/2dsb2JhbABDxGaBXxZ0gikBAQEEAQEBNzQXBgEIEQQBAQEKFAkuCxQIAQgCBAESCIgLDK9kkB+NQ4EaBiASBoJZYQOXc49XgVSBKQ2BczU
X-IronPort-AV: E=Sophos;i="4.84,827,1355097600"; d="scan'208";a="186361917"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 12 Mar 2013 03:05:21 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2C35KvA010018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Mar 2013 03:05:20 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 22:05:20 -0500
From: "Reinaldo Penno (repenno)" 
To: "Markus.Isomaki@nokia.com" , "andrew.hutton@siemens-enterprise.com" , "harald@alvestrand.no" , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
Thread-Index: AQHOHoKpVPM3WtZH0EiYxevcVicwOpihPEwA//+PMoCAANDogP//1DCA
Date: Tue, 12 Mar 2013 03:05:19 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040901BCD4@xmb-rcd-x04.cisco.com>
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.21.84.182]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0944A1E260B55F4E8831318EF4BA7867@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-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, 12 Mar 2013 03:05:27 -0000

I think another advantage of PCP is to reduce call setup time in RTCweb.
If a NAT/FW/Middlebox tells us that you have a mapping for 1 hour, during
that hour you can reuse that external IP:port across calls over and over,
or least reuse as your prime ICE candidate.


On 3/11/13 9:42 PM, "Markus.Isomaki@nokia.com" 
wrote:

>Hi,
>
>ICE/STUN/TURN and PCP are not really competitors or alternatives to each
>other.=20
>
>A browser or any other client will anyway need to implement ICE/STUN/TURN
>to work its way through non-PCP supporting NATs, which will be the
>majority for a long time even if PCP became succesfull. The benefit of
>the ICE/STUN/TURN approach is that every organization or individual who
>deploys NATs or firewalls will not need to deploy STUN and TURN servers,
>but they can be deployed independently e.g. by the WebRTC service
>provider.=20
>
>However, PCP, even gradually deployed, would still be useful as well. As
>Reinaldo is saying, it would improve robustness it produces explict NAT
>mappings with explicit durations. Also, it can serve as an alternative to
>STUN/TURN in case the browser happens to be behind a PCP-capable NAT/FW.
>So, PCP can be seen as an optimization and should be used when it is
>available. PCP can also help clients behind NAT/FW to reduce their
>keep-alive rate which is applicable to WebRTC as well. However, as
>depicted in [1], knowing when a client can entirely rely on PCP is not
>always so easy to detect.
>
>I hope we will see PCP deployment especially in the mobile/cellular
>access, but as many people have pointed out, the success rate of this
>type of protocols has been quite low. So it will be a nice surprise
>rather than something I would count on if it happens.
>
>[1]=20
>http://datatracker.ietf.org/doc/draft-reddy-pcp-optimize-keepalives/?inclu
>de_text=3D1.
>
>Markus
>
>
>>-----Original Message-----
>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
>>Of ext Reinaldo Penno (repenno)
>>Sent: 11 March, 2013 22:14
>>To: Hutton, Andrew; Harald Alvestrand; rtcweb@ietf.org
>>Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-
>>considerations-00.txt
>>
>>
>>
>>On 3/11/13 12:58 PM, "Hutton, Andrew"
>> wrote:
>>
>>>On: 11 March 2013 14:03 Reinaldo Penno (repenno) Wrote:
>>>
>>>
>>>>
>>>> I'm sure STUN and TURN servers are not universally deployed ('100%')
>>>> in ISP networks either.
>>>
>>>It is not required for an ISP to deploy a TURN server the webrtc TURN
>>>server is much more likely to be deployed by the web application
>>>provider which will instruct the browser to use it when accessing its
>>>service.
>>
>>The line between Application providers and ISPs is very blurry today.
>>Application provider can be over the top or it can be the ISP itself.
>>
>>
>>>
>>>>
>>>> But I'm not proposing dropping STUN/TURN in lieu of PCP, but using
>>>> PCP as an additional technique. Maybe you misunderstood what I was
>>>> proposing.
>>>>
>>>
>>>Understood but would need to understand what the benefits of doing so
>>>would be.
>>
>>
>>Yes, certainly.
>>
>>A protocol that allows a host to explicit control FW/NAT
>>mappings/pinholes
>>(both for incoming and outgoing connections IPv4/IPv6), including
>>lifetime,
>>knowing when such device restart/reboot, is more deterministic.
>>Client is always free to use STUN/TURN.
>>
>>
>>>
>>>Regards
>>>Andy
>>
>>_______________________________________________
>>rtcweb mailing list
>>rtcweb@ietf.org
>>https://www.ietf.org/mailman/listinfo/rtcweb


From tireddy@cisco.com  Mon Mar 11 20:18: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 A81ED21F87DF for ; Mon, 11 Mar 2013 20:18:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.442
X-Spam-Level: 
X-Spam-Status: No, score=-10.442 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygtN2W2LuDJv for ; Mon, 11 Mar 2013 20:18:43 -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 7DB7221F87E4 for ; Mon, 11 Mar 2013 20:18:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16643; q=dns/txt; s=iport; t=1363058323; x=1364267923; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lC7etHFVVKIUh8RcvT68ZUotwx/VRmwUXdOk2qIKfTs=; b=UoMty9J1ZYy32TVEKQQ6zQc8bAbYLrVgWPtwZyKF7Sjz61jmCR0ne4mu m8ZIkt0LF0KVJfEd4IER6Vf5MPbrEVu3tsu8WFpqtobc8LF3tWYCxJp6F KNaq2LvL89VMv91HtNVZMR8yOatybMDehKYMTIfUQhJ9N2+4r4KZxGIte 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhYFAKWdPlGtJV2c/2dsb2JhbABDhB2ud4kniC2BYRZ0gikBAQEDAQEBASpBCwUHBAIBCA4DBAEBAQodByEGCxQIAQgCBAENBQiHeQMJBgyvdoY4DYlbjEZ9gRoGBxkHBAYBBoJZYQOUdYJ+ij6FGYFUgSkNgXM1
X-IronPort-AV: E=Sophos;i="4.84,827,1355097600";  d="scan'208,217";a="183373121"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 12 Mar 2013 03:18:42 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2C3IghY020033 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Mar 2013 03:18:42 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 22:18:41 -0500
From: "Tirumaleswar Reddy (tireddy)" 
To: Cameron Byrne , "Reinaldo Penno (repenno)" 
Thread-Topic: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
Thread-Index: AQHOHsyGE/PY/mrgxECBIYYne8LE+pihXzbg
Date: Tue, 12 Mar 2013 03:18:41 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A149315A8@xmb-rcd-x10.cisco.com>
References:  <45A697A8FFD7CF48BCF2BE7E106F06040901BC8F@xmb-rcd-x04.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.65.71.82]
Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A149315A8xmbrcdx10ciscoc_"
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] FW: I-D Action:	draft-hutton-rtcweb-nat-firewall-considerations-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, 12 Mar 2013 03:18:45 -0000

--_000_913383AAA69FF945B8F946018B75898A149315A8xmbrcdx10ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Cameron Byrne
Sent: Tuesday, March 12, 2013 8:22 AM
To: Reinaldo Penno (repenno)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-cons=
iderations-00.txt


On Mar 11, 2013 7:46 PM, "Reinaldo Penno (repenno)" > wrote:
>
> Agree with you on e2e IPv6 would be ideal. PCP is well suited to control
> IPv6 firewalls and it is one of the main use-cases as part of IPV6 CPE
> requirements RFC. Unless you think with IPv6 there will no IPv6 firewalls=
.
>

That is my plan. Ipv6 e2e ftw.

[TR] Even with IPv6, there is no guarantee that NPTv6 will not be deployed.=
 So PCP/STUN is still required to gather server-reflexive candidates. Even =
without NPTv6, Firewalls would block UDP flows -  PCP would address that pr=
oblem. TURN should be only used as last resort if all other techniques fail=
 because it could result in media latency, single point of failure etc.

--Tiru.

CB

> On 3/11/13 9:57 PM, "Cameron Byrne" > wrote:
>
> >On Mon, Mar 11, 2013 at 6:42 PM,  > wrote:
> >> Hi,
> >>
> >> ICE/STUN/TURN and PCP are not really competitors or alternatives to
> >>each other.
> >>
> >> A browser or any other client will anyway need to implement
> >>ICE/STUN/TURN to work its way through non-PCP supporting NATs, which
> >>will be the majority for a long time even if PCP became succesfull. The
> >>benefit of the ICE/STUN/TURN approach is that every organization or
> >>individual who deploys NATs or firewalls will not need to deploy STUN
> >>and TURN servers, but they can be deployed independently e.g. by the
> >>WebRTC service provider.
> >>
> >> However, PCP, even gradually deployed, would still be useful as well.
> >>As Reinaldo is saying, it would improve robustness it produces explict
> >>NAT mappings with explicit durations. Also, it can serve as an
> >>alternative to STUN/TURN in case the browser happens to be behind a
> >>PCP-capable NAT/FW. So, PCP can be seen as an optimization and should b=
e
> >>used when it is available. PCP can also help clients behind NAT/FW to
> >>reduce their keep-alive rate which is applicable to WebRTC as well.
> >>However, as depicted in [1], knowing when a client can entirely rely on
> >>PCP is not always so easy to detect.
> >>
> >> I hope we will see PCP deployment especially in the mobile/cellular
> >>access, but as many people have pointed out, the success rate of this
> >>type of protocols has been quite low. So it will be a nice surprise
> >>rather than something I would count on if it happens.
> >>
> >> [1]
> >>http://datatracker.ietf.org/doc/draft-reddy-pcp-optimize-keepalives/?in=
cl
> >>ude_text=3D1.
> >>
> >> Markus
> >>
> >
> >I am hopeful e2e connectivity will be provided by IPv6 prior to PCP
> >reaching critical mass. This more because i am on bullish on v6 than
> >bearish on PCP.  That said, the more interesting use-case is v4 to v6
> >via TURN, but i believe that is already covered well ... another
> >reason ICE is a good fit.
> >
> >CB
> >>
> >>>-----Original Message-----
> >>>From: rtcweb-bounces@ietf.org [mailto:=
rtcweb-bounces@ietf.org] On Behalf
> >>>Of ext Reinaldo Penno (repenno)
> >>>Sent: 11 March, 2013 22:14
> >>>To: Hutton, Andrew; Harald Alvestrand; rtcweb@ietf.org
> >>>Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall=
-
> >>>considerations-00.txt
> >>>
> >>>
> >>>
> >>>On 3/11/13 12:58 PM, "Hutton, Andrew"
> >>>> wrote:
> >>>
> >>>>On: 11 March 2013 14:03 Reinaldo Penno (repenno) Wrote:
> >>>>
> >>>>
> >>>>>
> >>>>> I'm sure STUN and TURN servers are not universally deployed ('100%'=
)
> >>>>> in ISP networks either.
> >>>>
> >>>>It is not required for an ISP to deploy a TURN server the webrtc TURN
> >>>>server is much more likely to be deployed by the web application
> >>>>provider which will instruct the browser to use it when accessing its
> >>>>service.
> >>>
> >>>The line between Application providers and ISPs is very blurry today.
> >>>Application provider can be over the top or it can be the ISP itself.
> >>>
> >>>
> >>>>
> >>>>>
> >>>>> But I'm not proposing dropping STUN/TURN in lieu of PCP, but using
> >>>>> PCP as an additional technique. Maybe you misunderstood what I was
> >>>>> proposing.
> >>>>>
> >>>>
> >>>>Understood but would need to understand what the benefits of doing so
> >>>>would be.
> >>>
> >>>
> >>>Yes, certainly.
> >>>
> >>>A protocol that allows a host to explicit control FW/NAT
> >>>mappings/pinholes
> >>>(both for incoming and outgoing connections IPv4/IPv6), including
> >>>lifetime,
> >>>knowing when such device restart/reboot, is more deterministic.
> >>>Client is always free to use STUN/TURN.
> >>>
> >>>
> >>>>
> >>>>Regards
> >>>>Andy
> >>>
> >>>_______________________________________________
> >>>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_913383AAA69FF945B8F946018B75898A149315A8xmbrcdx10ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











 








From: rtcweb-b=
ounces@ietf.org [mailto:rtcweb-bounces@ietf.org]
On Behalf Of Cameron Byrne

Sent: Tuesday, March 12, 2013 8:22 AM

To: Reinaldo Penno (repenno)

Cc: rtcweb@ietf.org

Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewa=
ll-considerations-00.txt






 




On Mar 11, 2013 7:46 PM, "Reinaldo Penno (repenno)" <repenno@cisco.com> wrote:

>

> Agree with you on e2e IPv6 would be ideal. PCP is well suited to contr=
ol

> IPv6 firewalls and it is one of the main use-cases as part of IPV6 CPE=


> requirements RFC. Unless you think with IPv6 there will no IPv6 firewa=
lls.

>


That is my plan. Ipv6 e2e ftw. 


[TR] Even with IPv6, there is no guarantee th=
at NPTv6 will not be deployed. So PCP/STUN is still required to gather serv=
er-reflexive candidates. Even without NPTv6, Firewalls
 would block UDP flows –  PCP would address that problem. TURN s=
hould be only used as last resort if all other techniques fail because it c=
ould result in media latency, single point of failure etc.



--Tiru.


CB


> On 3/11/13 9:57 PM, "Cameron Byrne" <cb.list6@gmail.com> wrote:

>

> >On Mon, Mar 11, 2013 at 6:42 PM,  <Markus.Isomaki@nokia.com> wrote:

> >> Hi,

> >>

> >> ICE/STUN/TURN and PCP are not really competitors or alternati=
ves to

> >>each other.

> >>

> >> A browser or any other client will anyway need to implement
> >>ICE/STUN/TURN to work its way through non-PCP supporting NATs,=
 which

> >>will be the majority for a long time even if PCP became succes=
full. The

> >>benefit of the ICE/STUN/TURN approach is that every organizati=
on or

> >>individual who deploys NATs or firewalls will not need to depl=
oy STUN

> >>and TURN servers, but they can be deployed independently e.g. =
by the

> >>WebRTC service provider.

> >>

> >> However, PCP, even gradually deployed, would still be useful =
as well.

> >>As Reinaldo is saying, it would improve robustness it produces=
 explict

> >>NAT mappings with explicit durations. Also, it can serve as an=


> >>alternative to STUN/TURN in case the browser happens to be beh=
ind a

> >>PCP-capable NAT/FW. So, PCP can be seen as an optimization and=
 should be

> >>used when it is available. PCP can also help clients behind NA=
T/FW to

> >>reduce their keep-alive rate which is applicable to WebRTC as =
well.

> >>However, as depicted in [1], knowing when a client can entirel=
y rely on

> >>PCP is not always so easy to detect.

> >>

> >> I hope we will see PCP deployment especially in the mobile/ce=
llular

> >>access, but as many people have pointed out, the success rate =
of this

> >>type of protocols has been quite low. So it will be a nice sur=
prise

> >>rather than something I would count on if it happens.

> >>

> >> [1]

> >>http://datatracker.ietf.org/doc/draft-reddy-pcp-opt=
imize-keepalives/?incl

> >>ude_text=3D1.

> >>

> >> Markus

> >>

> >

> >I am hopeful e2e connectivity will be provided by IPv6 prior to PC=
P

> >reaching critical mass. This more because i am on bullish on v6 th=
an

> >bearish on PCP.  That said, the more interesting use-case is =
v4 to v6

> >via TURN, but i believe that is already covered well ... another
> >reason ICE is a good fit.

> >

> >CB

> >>

> >>>-----Original Message-----

> >>>From: rtcweb-bo=
unces@ietf.org [mailto:rtcwe=
b-bounces@ietf.org] On Behalf

> >>>Of ext Reinaldo Penno (repenno)

> >>>Sent: 11 March, 2013 22:14

> >>>To: Hutton, Andrew; Harald Alvestrand; rtcweb@ietf.org

> >>>Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-=
nat-firewall-

> >>>considerations-00.txt

> >>>

> >>>

> >>>

> >>>On 3/11/13 12:58 PM, "Hutton, Andrew"

> >>><andrew.hutton@siemens-enterprise.com> wrote:

> >>>

> >>>>On: 11 March 2013 14:03 Reinaldo Penno (repenno) Wrote=
:

> >>>>

> >>>>

> >>>>>

> >>>>> I'm sure STUN and TURN servers are not universall=
y deployed ('100%')

> >>>>> in ISP networks either.

> >>>>

> >>>>It is not required for an ISP to deploy a TURN server =
the webrtc TURN

> >>>>server is much more likely to be deployed by the web a=
pplication

> >>>>provider which will instruct the browser to use it whe=
n accessing its

> >>>>service.

> >>>

> >>>The line between Application providers and ISPs is very bl=
urry today.

> >>>Application provider can be over the top or it can be the =
ISP itself.

> >>>

> >>>

> >>>>

> >>>>>

> >>>>> But I'm not proposing dropping STUN/TURN in lieu =
of PCP, but using

> >>>>> PCP as an additional technique. Maybe you misunde=
rstood what I was

> >>>>> proposing.

> >>>>>

> >>>>

> >>>>Understood but would need to understand what the benef=
its of doing so

> >>>>would be.

> >>>

> >>>

> >>>Yes, certainly.

> >>>

> >>>A protocol that allows a host to explicit control FW/NAT
> >>>mappings/pinholes

> >>>(both for incoming and outgoing connections IPv4/IPv6), in=
cluding

> >>>lifetime,

> >>>knowing when such device restart/reboot, is more determini=
stic.

> >>>Client is always free to use STUN/TURN.

> >>>

> >>>

> >>>>

> >>>>Regards

> >>>>Andy

> >>>

> >>>_______________________________________________

> >>>rtcweb mailing list

> >>>rtcweb@ietf.org

> >>>h=
ttps://www.ietf.org/mailman/listinfo/rtcweb

> >> _______________________________________________

> >> rtcweb mailing list

> >> rtcweb@ietf.org

> >> http=
s://www.ietf.org/mailman/listinfo/rtcweb

>








--_000_913383AAA69FF945B8F946018B75898A149315A8xmbrcdx10ciscoc_--

From harald@alvestrand.no  Mon Mar 11 20:20: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 1BDA621F880F for ; Mon, 11 Mar 2013 20:20:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.42
X-Spam-Level: 
X-Spam-Status: No, score=-110.42 tagged_above=-999 required=5 tests=[AWL=0.178, 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 SYwXxzA9+2Ib for ; Mon, 11 Mar 2013 20:20:47 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD9321F87E8 for ; Mon, 11 Mar 2013 20:20:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5B3FC39E1BD for ; Tue, 12 Mar 2013 04:20:46 +0100 (CET)
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 Vu6V09sbNx5P for ; Tue, 12 Mar 2013 04:20:45 +0100 (CET)
Received: from [192.168.255.77] (unknown [216.189.219.66]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0FAC239E1AD for ; Tue, 12 Mar 2013 04:20:42 +0100 (CET)
Message-ID: <513E9F01.3020800@alvestrand.no>
Date: Tue, 12 Mar 2013 04:20:33 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References:    <949EF20990823C4C85C18D59AA11AD8B01121E@FR712WXCHMBA11.zeu.alcatel-lucent.com>  
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080202080004040009020902"
Subject: [rtcweb] H.264 IPR status (Re:  VP8 litigation in Germany?)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 03:20:49 -0000

This is a multi-part message in MIME format.
--------------080202080004040009020902
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 03/12/2013 02:27 AM, Markus.Isomaki@nokia.com wrote:
> Hi,
>
> Ted Hardie wrote:
>> On Mon, Mar 11, 2013 at 6:23 PM, DRAGE, Keith (Keith) > lucent.com> wrote:
>>> As I believe there are no IETF documents that specify H.264 or VP8 directly,
>> then you will not get a direct declaration.
>> This contradicts what I understood Markus to be saying, which is that Nokia
>> would supply one.  If I have misunderstood this text:
>>
>> Nokia is preparing to do a disclosure about it to the  IETF "to ensure that IETF
>> working groups and participants have as much information about any IPR
>> constraints on a technical proposal as  possible".
>>
>> I hope he will let me know.
>>
> Yes, Nokia is preparing a disclosure related to VP8.
>
> What comes to H.264, the Nokia IPR related to that has been disclosed to those SDOs where that codec has been developed, except for the RTP payload format that is in the IETF. I assume all that is publicly available to interested parties. If I recall correctly, some pointers were floating around prior to IETF 85. I'm sure others on this list know that side better than me.
>

I know of 3 sources of IPR information related to H.264:

- The ISO database of disclosures ( 
http://www.iso.org/iso/standards_development/patents)
- The MPEG-LA list of IPR available for licensing via their license pool
- The list that Cliff Reader did related to H.264 Baseline work in MPEG

The first 2 are public on the Web; I don't know the status of the third 
one (MPEG doesn't make its input documents public by default).

I think it's fair to ask the proponents of H.264 to present the IPR 
situation for their candidate codec; saying that it is "well known" is 
not the same as having an input contribution to the IETF stating what 
the situation is.




--------------080202080004040009020902
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 03/12/2013 02:27 AM,
      Markus.Isomaki@nokia.com wrote:

    

    

      
Hi,

Ted Hardie wrote:


      

        
On Mon, Mar 11, 2013 at 6:23 PM, DRAGE, Keith (Keith) <keith.drage@alcatel-
lucent.com> wrote:


        

          
As I believe there are no IETF documents that specify H.264 or VP8 directly,


        

        
then you will not get a direct declaration.


        

          

        

        
This contradicts what I understood Markus to be saying, which is that Nokia
would supply one.  If I have misunderstood this text:

Nokia is preparing to do a disclosure about it to the  IETF "to ensure that IETF
working groups and participants have as much information about any IPR
constraints on a technical proposal as  possible".

I hope he will let me know.



      

      
Yes, Nokia is preparing a disclosure related to VP8. 

What comes to H.264, the Nokia IPR related to that has been disclosed to those SDOs where that codec has been developed, except for the RTP payload format that is in the IETF. I assume all that is publicly available to interested parties. If I recall correctly, some pointers were floating around prior to IETF 85. I'm sure others on this list know that side better than me.



    

    

    I know of 3 sources of IPR information related to H.264:

    

    - The ISO database of disclosures (
    
    http://www.iso.org/iso/standards_development/patents)

    - The MPEG-LA list of IPR available for licensing via their license
    pool

    - The list that Cliff Reader did related to H.264 Baseline work in
    MPEG

    

    The first 2 are public on the Web; I don't know the status of the
    third one (MPEG doesn't make its input documents public by default).

    

    I think it's fair to ask the proponents of H.264 to present the IPR
    situation for their candidate codec; saying that it is "well known"
    is not the same as having an input contribution to the IETF stating
    what the situation is.

    

    

    

  


--------------080202080004040009020902--

From stewe@stewe.org  Mon Mar 11 20:52: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 2F72821F8A53 for ; Mon, 11 Mar 2013 20:52:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.97
X-Spam-Level: 
X-Spam-Status: No, score=-3.97 tagged_above=-999 required=5 tests=[AWL=-0.372,  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 8y-nOvAGitla for ; Mon, 11 Mar 2013 20:52:31 -0700 (PDT)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 86B4721F8A41 for ; Mon, 11 Mar 2013 20:52:31 -0700 (PDT)
Received: from mail60-co1-R.bigfish.com (10.243.78.243) by CO1EHSOBE017.bigfish.com (10.243.66.80) with Microsoft SMTP Server id 14.1.225.23; Tue, 12 Mar 2013 03:52:30 +0000
Received: from mail60-co1 (localhost [127.0.0.1])	by mail60-co1-R.bigfish.com (Postfix) with ESMTP id 53EA88400E1; Tue, 12 Mar 2013 03:52:30 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT003.namprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -20
X-BigFish: PS-20(zzbb2dI98dI9371Ic85ehzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz18de19h1033IL17326ah8275bh8275dh18c673hz2fh2a8h668h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h)
Received-SPF: pass (mail60-co1: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT003.namprd07.prod.outlook.com ; .outlook.com ; 
Received: from mail60-co1 (localhost.localdomain [127.0.0.1]) by mail60-co1 (MessageSwitch) id 1363060348274576_14815; Tue, 12 Mar 2013 03:52:28 +0000 (UTC)
Received: from CO1EHSMHS008.bigfish.com (unknown [10.243.78.250])	by mail60-co1.bigfish.com (Postfix) with ESMTP id 358D5700049; Tue, 12 Mar 2013 03:52:28 +0000 (UTC)
Received: from BL2PRD0710HT003.namprd07.prod.outlook.com (157.56.240.133) by CO1EHSMHS008.bigfish.com (10.243.66.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 12 Mar 2013 03:52:27 +0000
Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.49]) by BL2PRD0710HT003.namprd07.prod.outlook.com ([10.255.102.38]) with mapi id 14.16.0275.006; Tue, 12 Mar 2013 03:52:27 +0000
From: Stephan Wenger 
To: Harald Alvestrand , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] H.264 IPR status (Re:  VP8 litigation in Germany?)
Thread-Index: AQHOHtChAA8uuuSegUivR5hbrx1zH5ihKVKA
Date: Tue, 12 Mar 2013 03:52:26 +0000
Message-ID: 
In-Reply-To: <513E9F01.3020800@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.255.102.4]
Content-Type: multipart/alternative; boundary="_000_CD64184097FDEstewesteweorg_"
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Subject: Re: [rtcweb] H.264 IPR status (Re:  VP8 litigation in Germany?)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 03:52:33 -0000

--_000_CD64184097FDEstewesteweorg_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi,

From: Harald Alvestrand >
Date: Monday, 11 March, 2013 23:20
To: "rtcweb@ietf.org" >
Subject: [rtcweb] H.264 IPR status (Re: VP8 litigation in Germany?)

On 03/12/2013 02:27 AM, Markus.Isomaki@nokia.com wrote:

[=85]


I know of 3 sources of IPR information related to H.264:

- The ISO database of disclosures ( http://www.iso.org/iso/standards_develo=
pment/patents)
- The MPEG-LA list of IPR available for licensing via their license pool
- The list that Cliff Reader did related to H.264 Baseline work in MPEG

The first 2 are public on the Web; I don't know the status of the third one=
 (MPEG doesn't make its input documents public by default).

I know of a fourth one: the ITU patents database.  H.264 is an ITU recommen=
dation, so ITU patent declaration can be found in the ITU database.  Of cou=
rse, there is a large overlap with the ISO/IEC database.  The IT database, =
though, is more easily accessible.  See here, and search for H.264 on the r=
ight sidebar.  http://www.itu.int/ipr/IPRSearch.aspx?iprtype=3DPS  Much pre=
ttier than the ISO xls spreadsheet with all its reportedly existing typos. =
 In that xls one, look for ISO/IEC 14496-10.


I think it's fair to ask the proponents of H.264 to present the IPR situati=
on for their candidate codec; saying that it is "well known" is not the sam=
e as having an input contribution to the IETF stating what the situation is=
.

Describing H.264's IPR situation has been done before=97more than once--but=
 is easy to repeat.  Parties contributing to H.264 in JVT, and its parent b=
odies MPEG in VCEG, have to license any H.264 essential patent in their por=
tfolio under reasonable and non-discriminatory terms, on a world-wide bases=
, often subject to reciprocity.  That includes at least all the patents and=
/or portfolios listed in the patent databases of ISO/IEC and ITU.  (There m=
ay be additional patents or portfolios where the rightholders contributed t=
o JVT, MPEG, or VCEG, but did not make a declaration.  Whether or not those=
 patents are enforceable is questionable.  Undoubtly, RAND terms apply to t=
hose as well.)  Further, a large percentage, but not all, of these patents =
are licensable through a pooling arrangement from MPEG-LA  (see http://www.=
mpegla.com/main/programs/AVC/Pages/Intro.aspx), at a cost of no more than $=
0.20 per codec, plus (in some cases) applicable content fees.  Known partie=
s whose patent claims are not licensable through MPEG-LA include Nokia and =
many semiconductor companies.  Outside of the pooling arrangement, what exa=
ctly RAND royalties are is subject to negotiations between licensor and lic=
ensee.  There is currently ongoing litigation in a number of legislation wh=
ich attempts, among other things, to further clarify the meaning of RAND in=
 terms of maximum royalties.   Finally, there may be parties that own essen=
tial IPR and have not contributed to the development of H.264, nor are ISO/=
IEC or ITU members, and those patent claims may not be subject to RAND term=
s.

Hope I didn't forget anything.

Anyone wants me to characterize the VP8 sitation similarly?  :-)

Stephan





--_000_CD64184097FDEstewesteweorg_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <8997AACE6AECD84D9D107E3022B27D14@namprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable







Hi,











From: Harald Alvestrand <harald@alvestrand.no>

Date: Monday, 11 March, 2013 23:20 =


To: "rtcweb@ietf.org" <=
rtcweb@ietf.org>

Subject: [rtcweb] H.264 IPR status =
(Re: VP8 litigation in Germany?)













On 03/12/2013 02:27 AM, 
Markus.Isomaki@nokia.com wrote:
















[=85]













I know of 3 sources of IPR information related to H.264:



- The ISO database of disclosures ( 
http://www.iso.org/iso/standards_development/patents)

- The MPEG-LA list of IPR available for licensing via their license pool
- The list that Cliff Reader did related to H.264 Baseline work in MPEG



The first 2 are public on the Web; I don't know the status of the third one=
 (MPEG doesn't make its input documents public by default).

















I know of a fourth one: the ITU p=
atents database.  H.264 is an ITU recommendation, so ITU patent declar=
ation can be found in the ITU database.  Of course, there is a large o=
verlap with the ISO/IEC database.  The IT database,
 though, is more easily accessible.  See here, and search for H.264 on=
 the right sidebar.  http://www.itu.int/ipr/IPRSearch.aspx?iprtype=3DPS  =
Much prettier than the ISO xls spreadsheet with all its
 reportedly existing typos.  In that xls one, look for ISO/IEC 14496-1=
0.

















I think it's fair to ask the proponents of H.264 to present the IPR situati=
on for their candidate codec; saying that it is "well known" is n=
ot the same as having an input contribution to the IETF stating what the si=
tuation is.
















Describing H.264's IPR situation has been done before=97more than once=
--but is easy to repeat.  Parties contributing to H.264 in JVT, and it=
s parent bodies MPEG in VCEG, have to license any H.264 essential patent in=
 their portfolio under reasonable and non-discriminatory
 terms, on a world-wide bases, often subject to reciprocity.  That inc=
ludes at least all the patents and/or portfolios listed in the patent datab=
ases of ISO/IEC and ITU.  (There may be additional patents or portfoli=
os where the rightholders contributed to JVT,
 MPEG, or VCEG, but did not make a declaration.  Whether or not those =
patents are enforceable is questionable.  Undoubtly, RAND terms apply =
to those as well.)  Further, a large percentage, but not all, of these=
 patents are licensable through a pooling arrangement
 from MPEG-LA  (see http://www.mpegla.com/main/programs/AVC/Pages/Intro=
.aspx), at a cost of no more than $0.20 per codec, plus (in some cases)=
 applicable content fees.  Known parties whose
 patent claims are not licensable through MPEG-LA include Nokia and many se=
miconductor companies.  Outside of the pooling arrangement, what exact=
ly RAND royalties are is subject to negotiations between licensor and licen=
see.  There is currently ongoing litigation
 in a number of legislation which attempts, among other things, to further =
clarify the meaning of RAND in terms of maximum royalties.   Finally, =
there may be parties that own essential IPR and have not contributed to the=
 development of H.264, nor are ISO/IEC
 or ITU members, and those patent claims may not be subject to RAND terms.<=
/div>






Hope I didn't forget anything.







Anyone wants me to characterize the VP8 sitation similarly?  :-)<=
/div>






Stephan





















--_000_CD64184097FDEstewesteweorg_--

From mperumal@cisco.com  Mon Mar 11 20:57: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 42FE221F8A5E for ; Mon, 11 Mar 2013 20:57:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.521
X-Spam-Level: 
X-Spam-Status: No, score=-10.521 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuQgrXHyrg1G for ; Mon, 11 Mar 2013 20:57:56 -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 8728321F8A52 for ; Mon, 11 Mar 2013 20:57:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1835; q=dns/txt; s=iport; t=1363060676; x=1364270276; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=goiGArqahaTrum/V+tnfa5yXF5wMGg0euhdVNUijV/o=; b=mqla2txo9Tqq+AwOdQ1uxdSxGuhPH4QRGcKX6upmtOu/mwGNUxP3/jCY 7Yrd4ibaIA+3jG82CscIqjWyE3tCBeTz1WgfGW/H/p9HVOQhSRQbPOfie bmKNuJsb2GycpxvxvXpfpvfSauXUfDMGMPc34iIizb7+ysGTUwRXctcB4 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFADKmPlGtJV2Y/2dsb2JhbABDxGuBYhZ0gikBAQEEAQEBNzQXBAIBCBEEAQELFAkHJwsUCAEIAgQBEgiICwyva5ANEwSNQoEaJhIGgllhA6dKgVSBKQ2BczU
X-IronPort-AV: E=Sophos;i="4.84,827,1355097600"; d="scan'208";a="183379558"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 12 Mar 2013 03:57:56 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2C3vu3B007652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Mar 2013 03:57:56 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.47]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 22:57:55 -0500
From: "Muthu Arul Mozhi Perumal (mperumal)" 
To: "Hutton, Andrew" , "Reinaldo Penno (repenno)" , Harald Alvestrand , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
Thread-Index: AQHOHoKpQPNB80XASUa1nEzDk7aFy5ig5ncwgACByzA=
Date: Tue, 12 Mar 2013 03:57:55 +0000
Message-ID: 
References: <513E146D.4060009@alvestrand.no> <45A697A8FFD7CF48BCF2BE7E106F06040901B3A9@xmb-rcd-x04.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF06895013@MCHP04MSX.global-ad.net>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF06895013@MCHP04MSX.global-ad.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.86.58]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-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, 12 Mar 2013 03:57:57 -0000

|It is not required for an ISP to deploy a TURN server the webrtc TURN serv=
er=20
|is much more likely to be deployed by the web application provider which w=
ill
|instruct the browser to use it when accessing its service.

Right, and the application provider could be also an enterprise hosting a T=
URN server for a number of reasons in addition to NAT/firewall traversal --=
 media anchoring, monitoring, recording etc. I think TURN servers aren't go=
ing away, especially with WebRTC where the session signaling protocol betwe=
en the browser and the web server could be proprietary (and encrypted), mak=
ing ALG techniques in NATs/Firewalls/SBCs fail miserably.

Muthu

|-----Original Message-----
|From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf O=
f Hutton, Andrew
|Sent: Tuesday, March 12, 2013 1:28 AM
|To: Reinaldo Penno (repenno); Harald Alvestrand; rtcweb@ietf.org
|Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-con=
siderations-00.txt
|
|On: 11 March 2013 14:03 Reinaldo Penno (repenno) Wrote:
|
|
|>
|> I'm sure STUN and TURN servers are not universally deployed ('100%') in
|> ISP networks either.
|
|It is not required for an ISP to deploy a TURN server the webrtc TURN serv=
er is much more likely to be
|deployed by the web application provider which will instruct the browser t=
o use it when accessing its
|service.
|
|>
|> But I'm not proposing dropping STUN/TURN in lieu of PCP, but using PCP
|> as
|> an additional technique. Maybe you misunderstood what I was proposing.
|>
|
|Understood but would need to understand what the benefits of doing so woul=
d be.
|
|Regards
|Andy
|_______________________________________________
|rtcweb mailing list
|rtcweb@ietf.org
|https://www.ietf.org/mailman/listinfo/rtcweb

From randell-ietf@jesup.org  Tue Mar 12 01: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 EEB9B21F86AF for ; Tue, 12 Mar 2013 01:00:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.486
X-Spam-Level: 
X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.114,  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 2mTWj27b5nP7 for ; Tue, 12 Mar 2013 01:00:27 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id CBD2421F8917 for ; Tue, 12 Mar 2013 01:00:24 -0700 (PDT)
Received: from [216.53.157.5] (port=27295 helo=[10.96.3.64]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UFK8F-0000TN-9Y for rtcweb@ietf.org; Tue, 12 Mar 2013 03:00:23 -0500
Message-ID: <513EE098.3040806@jesup.org>
Date: Tue, 12 Mar 2013 04:00:24 -0400
From: Randell Jesup 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> <5135C64A.50302@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02108E@FR711WXCHMBA02.zeu.alcatel-lucent.com> <51371E4A.4040602@ericsson.com> <39821B4C400EC14DAD4DB25330A9271A0214C1@FR711WXCHMBA02.zeu.alcatel-lucent.com>, <51376643.8090204@jesup.org> <39821B4C400EC14DAD4DB25330A9271A024649@FR711WXCHMBA02.zeu.alcatel-lucent.com>, <2024BD14-E25C-426F-B046-46D61AF7077C@lurchi.franken.de> <39821B4C400EC14DAD4DB25330A9271A024714@FR711WXCHMBA02.zeu.alcatel-lucent.com>
In-Reply-To: <39821B4C400EC14DAD4DB25330A9271A024714@FR711WXCHMBA02.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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
Subject: Re: [rtcweb] RE : I-D Action: draft-ietf-rtcweb-data-channel-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, 12 Mar 2013 08:00:28 -0000

On 3/11/2013 5:20 PM, MARCON, JEROME (JEROME) wrote:
>
> > Assuming that some day a spec defines the transport of T.140 (or 
> whatever similar protocol) over RTCWeb data channels
> > - with a registered subprotocol
> > - with multiple reliability options supported
> > - requiring some new data channel properties
> > - of which some are assymetric between the endpoints (like the 
> "characters per second" defined in [RFC4103].
> >
> > Then (in the current version of your proposal) it seems to me that
> > * Because current DATA_CHANNEL_OPEN syntax is not extensible:
> > - it is not possible to carry these new properties in DATA_CHANNEL_OPEN
> Why is it not extensible? We have a message type and you could simply
> define another message...
>
> [JM1]. Mmh, then the spec defining T.140 (or whatever) over data 
> channels (and willing to add a new property like "cps") would have to 
> define a new message type - and more less its own DATA_CHANNEL_OPEN 
> structure? That's a costly extensibility.

It you need to do a more complex negotiation, you have several choices.  
One would be:

Open a reliable data channel for negotiation (0 RTT) (flagged by label & 
protocol).  Over that channel, immediately send a message that sets up 
an offer for T.140 (take your pick on format. A JS app would likely use 
JSON), with a channel which was preset with the appropriate options ("I 
expect to receive data on this channel with these options").  The 
answerer can send back the response (on the negotiation channel), and 
also say "I expect data on this channel with these options").  At this 
point, the T.140 channel is open, and as soon as the response is 
received by the offerer, both sides know it.

If this sounds very much like "fast-path re-negotiation" for JSEP, it 
is.  Once you have DataChannels, you can leverage them to do a lot of 
things.  This sort of sequence is enabled by the ability added to allow 
external negotiation.  This is as fast as any other mechanism (and 
faster than any that goes via a signaling server) - 3 messages, 1 RTT 
total.  (Open, Offer -> Answer)

You can do this in SDP if you wish (and are willing to parse SDP, or 
whatever limited SDP  you need).  As mentioned, I normally would suggest 
JSON or something like that for JS Apps.)

You can also do external negotiation over whatever channel and method 
you like.

-- 
Randell Jesup
randell-ietf@jesup.org


From ted.ietf@gmail.com  Tue Mar 12 05:48: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 CD43821F8A48 for ; Tue, 12 Mar 2013 05:48:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.583
X-Spam-Level: 
X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.017,  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 ScRcK6h-zjFn for ; Tue, 12 Mar 2013 05:48:01 -0700 (PDT)
Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id C176821F8A5E for ; Tue, 12 Mar 2013 05:47:58 -0700 (PDT)
Received: by mail-ia0-f169.google.com with SMTP id j5so4799875iaf.14 for ; Tue, 12 Mar 2013 05:47:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=q9z57i/u8yX4v9FWlbzea3+VLJ+DAVYELH8wLuWdqGI=; b=niBp+WsMjZZzGuumFvBPDD+DL8/+wuju9GU0wA+531CkmvGJAI4VYBWGyfjVwIyT6r 0t4q//4dLXn0Ti5Tflrnl3buyeLhkUJygOjn5EtwFhonFxtoX/VYuZjwYlGjzM6Sb+9T 7Fz1xWVC06xMOV1wcgxNWkUhyOM7oJ0wjd7bLCfJCmPw2j5MBd1hZkRH0acA8I2frFJB vxTd5+6de6E9Ue+MBhjhFhEBK0wGeA/zP46HGcvV2AZ0ccPCr7S+XgKRTJowm69kZePr OWc5Vy7Ta8nnFt9l8Hy5pVFg0stfY0D1n3l5P8T46CVmK0buFqzNJatsF7t1VC7OpR5D robA==
MIME-Version: 1.0
X-Received: by 10.42.201.73 with SMTP id ez9mr12150649icb.29.1363092478443; Tue, 12 Mar 2013 05:47:58 -0700 (PDT)
Received: by 10.43.135.202 with HTTP; Tue, 12 Mar 2013 05:47:58 -0700 (PDT)
In-Reply-To: 
References:    <949EF20990823C4C85C18D59AA11AD8B01121E@FR712WXCHMBA11.zeu.alcatel-lucent.com>  
Date: Tue, 12 Mar 2013 08:47:58 -0400
Message-ID: 
From: Ted Hardie 
To: Markus.Isomaki@nokia.com
Content-Type: text/plain; charset=ISO-8859-1
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 litigation in Germany?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 12:48:02 -0000

On Mon, Mar 11, 2013 at 9:27 PM,   wrote:

>
> Yes, Nokia is preparing a disclosure related to VP8.
>
> What comes to H.264, the Nokia IPR related to that has been disclosed to
> those SDOs where that codec has been developed, except for the RTP payload
> format that is in the IETF. I assume all that is publicly available to interested
> parties. If I recall correctly, some pointers were floating around prior to IETF 85. > I'm sure others on this list know that side better than me.
>
Hi Markus,

Thanks for the clarification.  I could not find the pointers that you
mention; if you could provide a URL to the patent list and license
terms, that would be very useful.  I understand you have already said
that this would be some flavor of RAND, but the working group comments
seem to indicate folks want to see the actual license text if that is
available.

thanks again,

Ted Hardie

From harald@alvestrand.no  Tue Mar 12 06:38: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 BC17F21F8B5B for ; Tue, 12 Mar 2013 06:38:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.581
X-Spam-Level: 
X-Spam-Status: No, score=-110.581 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156, 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 JfGZScrLCPEa for ; Tue, 12 Mar 2013 06:38:41 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 977A621F8A99 for ; Tue, 12 Mar 2013 06:38:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 52D1239E1C4; Tue, 12 Mar 2013 14:38:38 +0100 (CET)
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 cRT8ssf31cYK; Tue, 12 Mar 2013 14:38:37 +0100 (CET)
Received: from [IPv6:2001:df8:0:16:b4fd:eac0:98eb:c482] (unknown [IPv6:2001:df8:0:16:b4fd:eac0:98eb:c482]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1234239E1AD; Tue, 12 Mar 2013 14:38:35 +0100 (CET)
Message-ID: <513F2FD9.4000308@alvestrand.no>
Date: Tue, 12 Mar 2013 14:38:33 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: Markus.Isomaki@nokia.com
References: <9F33F40F6F2CD847824537F3C4E37DDF06895013@MCHP04MSX.global-ad.net> <45A697A8FFD7CF48BCF2BE7E106F06040901B8ED@xmb-rcd-x04.cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-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, 12 Mar 2013 13:38:41 -0000

On 03/12/2013 02:42 AM, Markus.Isomaki@nokia.com wrote:
> Hi,
>
> ICE/STUN/TURN and PCP are not really competitors or alternatives to each other.
>
> A browser or any other client will anyway need to implement ICE/STUN/TURN to work its way through non-PCP supporting NATs, which will be the majority for a long time even if PCP became succesfull. The benefit of the ICE/STUN/TURN approach is that every organization or individual who deploys NATs or firewalls will not need to deploy STUN and TURN servers, but they can be deployed independently e.g. by the WebRTC service provider.
>
> However, PCP, even gradually deployed, would still be useful as well. As Reinaldo is saying, it would improve robustness it produces explict NAT mappings with explicit durations. Also, it can serve as an alternative to STUN/TURN in case the browser happens to be behind a PCP-capable NAT/FW. So, PCP can be seen as an optimization and should be used when it is available. PCP can also help clients behind NAT/FW to reduce their keep-alive rate which is applicable to WebRTC as well. However, as depicted in [1], knowing when a client can entirely rely on PCP is not always so easy to detect.
>
> I hope we will see PCP deployment especially in the mobile/cellular access, but as many people have pointed out, the success rate of this type of protocols has been quite low. So it will be a nice surprise rather than something I would count on if it happens.

I absolutely agree with this summary about the usefulness and status of PCP.

My concern with RTCWEB at the moment is getting things out the door with 
all the features we really need to have, and as few additional features 
as possible.

That's why I don't want to add PCP into the mix at this time - once 
we're finished with the basic stuff, we can discuss adding support for 
new features at our leisure, but making the specs more complex than they 
currently are really should be done only when it's a really important 
feature that needs adding.

            Harald


From martin.thomson@gmail.com  Tue Mar 12 07:08: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 3271D21F88D6 for ; Tue, 12 Mar 2013 07:08:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.473
X-Spam-Level: 
X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[AWL=-1.475, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_29=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 ji+snvkQQQ+4 for ; Tue, 12 Mar 2013 07:08:10 -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 6349021F859B for ; Tue, 12 Mar 2013 07:08:10 -0700 (PDT)
Received: by mail-wg0-f54.google.com with SMTP id fm10so6345767wgb.9 for ; Tue, 12 Mar 2013 07:08:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=hjLexLH+aJkadixZXWHhhL6iMa7gkdA3Mz/Y4/9xnBo=; b=uxriBucXz4ZBT9NfXvSKhWinPGPO/2giIDQoGS5dbu09LXkK8Wruq29BocUVAUaVme VKirozSuzgCbbI80miL3nyUAnHelE3WEruA7dmmceMxk2lVfcHfsXdNYSG4IzsDR4WOl e08aQuX5/L/TWOIYNKtKlRcQZd9y+nG94qQOUcmP3egbxWy0OQh5L8f2gQkcAeaQ2kI0 l8NJIgdwaVP2gKJpdFRr6gzhjfneiM1xhPJSpd5pE4Ey7VFsCeZkHTLPdiw4ae0PHwfD enMuEYvIJEizRlg1n7fQ602AAXGivN628uZOK34ht/7W1SXilUnj+54VVAWWJdHBLTeN 7G1g==
MIME-Version: 1.0
X-Received: by 10.194.76.37 with SMTP id h5mr27233365wjw.21.1363097289528; Tue, 12 Mar 2013 07:08:09 -0700 (PDT)
Received: by 10.194.5.135 with HTTP; Tue, 12 Mar 2013 07:08:09 -0700 (PDT)
Date: Tue, 12 Mar 2013 10:08:09 -0400
Message-ID: 
From: Martin Thomson 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7bb03bc4bc9fbc04d7bad15c
Subject: [rtcweb] Not an API proposal
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 14:08:11 -0000

--047d7bb03bc4bc9fbc04d7bad15c
Content-Type: text/plain; charset=UTF-8

Keep in mind that this isn't the W3C.  This would be illustrative only.

partial interface RTCPeerConnection {
    RTCDataChannel createDataChannel(optional DataChannelProperties
properties);
    EventHandler ondatachannel;
};

dictionary DataChannelProperties {
    unsigned short streamId = (next available value);
    boolean ordered = true;
    long rtxCount = (really really big);
    long rtxTime = (really really big);
    [Clamp] unsigned short binaryPpid = (registered webrtc binary PPID);
    DOMString label = "";
    DOMString protocol = null;
};

interface RTCDataChannel {
    unsigned short streamId;
    boolean ordered;
    long rtxCount;
    long rtxTime;
    short binaryPpid;
    DOMString label;
    DOMString protocol;
};
RTCDataChannel implements WebSocket;

DataChannelMessageEvent : Event {
     short binaryPpid;
};

Usage for reliable, ordered text (basically the same as websockets):

var dc = pc.createDataChannel();
dc.send(text);
dc.onmessage = function(e) {
    console.log(e.message);
};

Advanced usage for something else...on request.  I need to pay more
attention to the session.

--047d7bb03bc4bc9fbc04d7bad15c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Keep in mind that this isn't the W3C.=
=C2=A0 This would be illustrative only.

partial interface RTCP=
eerConnection {
=C2=A0=C2=A0=C2=A0 RTCDataChannel createDataChanne=
l(optional DataChannelProperties properties);


=C2=A0=C2=A0=C2=A0 EventHandler ondatachannel;
};

dictionary DataChannelProperties {
=C2=
=A0=C2=A0=C2=A0 unsigned short streamId =3D (next available value);
=C2=A0=C2=A0=C2=A0 boolean ordered =3D true;


=C2=A0=C2=A0=C2=A0 long rtxCount =3D (really really big);
=C2=A0=C2=A0=C2=A0 long rtxTime =3D (really really big);
<=
div>=C2=A0=C2=A0=C2=A0 [Clamp] unsigned short binaryPpid =3D (registered we=
brtc binary PPID);
=C2=A0=C2=A0=C2=A0 DOMString label =3D "";<=
br>

=C2=A0=C2=A0=C2=A0 DOMString protocol =3D null;
};
<=
/div>

interface RTCDataChannel {
=C2=A0=C2=
=A0=C2=A0 unsigned short streamId;
=C2=A0=C2=A0=C2=A0 boolean=
 ordered;
=C2=A0=C2=A0=C2=A0 long rtxCount;


=C2=A0=C2=A0=C2=A0 long rtxTime;
=C2=A0=C2=A0=
=C2=A0 short binaryPpid;
=C2=A0=C2=A0=C2=A0 DOMString label;
=C2=A0=C2=A0=C2=A0 DOMString protocol;
};
RTCData=
Channel implements WebSocket;

DataChannelMessageEvent : E=
vent {


=C2=A0=C2=A0 =C2=A0 short binaryPpid;
};

Usage for reliable, ordered text (basically the same as websockets=
):

var dc =3D pc.createDataChannel();
dc.se=
nd(text);


dc.onmessage =3D function(e) {
=C2=A0=C2=A0=C2=A0 =
console.log(e.message);
};

Advan=
ced usage for something else...on request.=C2=A0 I need to pay more attenti=
on to the session.




--047d7bb03bc4bc9fbc04d7bad15c--

From Markus.Isomaki@nokia.com  Tue Mar 12 07:20: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 73AAC21F8B4C for ; Tue, 12 Mar 2013 07:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.579
X-Spam-Level: 
X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020,  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 BEar6PDZyVKY for ; Tue, 12 Mar 2013 07:20:04 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC0921F8B4A for ; Tue, 12 Mar 2013 07:20:04 -0700 (PDT)
Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r2CEJL7p029355; Tue, 12 Mar 2013 16:19:24 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 12 Mar 2013 16:19:21 +0200
Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.232]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.02.0328.011; Tue, 12 Mar 2013 14:19:21 +0000
From: 
To: 
Thread-Topic: H.264 IPR status (RE: VP8 litigation in Germany?)
Thread-Index: Ac4fK/aknXH8NmqKSZOHVHXjAHrRYg==
Date: Tue, 12 Mar 2013 14:19:21 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.129.16.204]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 12 Mar 2013 14:19:21.0879 (UTC) FILETIME=[975CDA70:01CE1F2C]
X-Nokia-AV: Clean
Cc: rtcweb@ietf.org
Subject: [rtcweb] H.264 IPR status (RE: VP8 litigation in Germany?)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 14:20:06 -0000

Hi Ted,

Ted Hardie wrote:
>
>> What comes to H.264, the Nokia IPR related to that has been disclosed
>> to those SDOs where that codec has been developed, except for the RTP
>> payload format that is in the IETF. I assume all that is publicly
>> available to interested parties. If I recall correctly, some pointers we=
re
>floating around prior to IETF 85. > I'm sure others on this list know that=
 side
>better than me.
>>
>Hi Markus,
>
>Thanks for the clarification.  I could not find the pointers that you ment=
ion; if
>you could provide a URL to the patent list and license terms, that would b=
e
>very useful.  I understand you have already said that this would be some
>flavor of RAND, but the working group comments seem to indicate folks want
>to see the actual license text if that is available.
>

Please see the URLs posted earlier today by Harald and Stephan, and the sum=
mary of H.264 IPR situation by Stephan. Are you asking for this about Nokia=
 specifically, or for all of the H.264 proponents (several affiliations) or=
 for H.264 in general? Nokia is certainly no special case in that context.=
=20

I have gotten the impression that H.264's IPR status is relatively clear en=
ough for the WG participants to form their opinion about it. But if somethi=
ng more would *really* be useful, I think the proponets could try do dig it=
 out.=20

Markus=20



From radhika.r.roy.civ@mail.mil  Tue Mar 12 07:45: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 D077B21F87F6 for ; Tue, 12 Mar 2013 07:45:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.521
X-Spam-Level: 
X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rX0I7R+kzcGv for ; Tue, 12 Mar 2013 07:45:54 -0700 (PDT)
Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.11]) by ietfa.amsl.com (Postfix) with ESMTP id D40AE21F85D4 for ; Tue, 12 Mar 2013 07:45:52 -0700 (PDT)
Received: from UCOLHP3B.easf.csd.disa.mil (131.64.100.151) by ucolhp3l.easf.csd.disa.mil (131.64.100.11) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 12 Mar 2013 14:45:39 +0000
Received: from UCOLHP9B.easf.csd.disa.mil ([169.254.10.116]) by UCOLHP3B.easf.csd.disa.mil ([131.64.100.151]) with mapi id 14.02.0309.003; Tue, 12 Mar 2013 14:45:40 +0000
From: "Roy, Radhika R CIV USARMY (US)" 
To: Harald Alvestrand , "Markus.Isomaki@nokia.com" 
Thread-Topic: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt (UNCLASSIFIED)
Thread-Index: AQHOHyb5/9U6NQLV2EWTHf5XQuc2iJiiH4rg
Date: Tue, 12 Mar 2013 14:45:39 +0000
Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF49A64948@ucolhp9b.easf.csd.disa.mil>
References: <9F33F40F6F2CD847824537F3C4E37DDF06895013@MCHP04MSX.global-ad.net> <45A697A8FFD7CF48BCF2BE7E106F06040901B8ED@xmb-rcd-x04.cisco.com>  <513F2FD9.4000308@alvestrand.no>
In-Reply-To: <513F2FD9.4000308@alvestrand.no>
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_002A_01CE1F0E.BAD29850"
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] FW: I-D Action:	draft-hutton-rtcweb-nat-firewall-considerations-00.txt (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, 12 Mar 2013 14:45:57 -0000

------=_NextPart_000_002A_01CE1F0E.BAD29850
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Classification: UNCLASSIFIED
Caveats: NONE

Folks:

I also agree with Harald on his proposal that PCP would be considered later.
In addition, I like to add the following:

1. Let PCP becomes an RFC.
2. Let there be some use cases/call-flows (as a PCP call-flow IETF draft is
there) using PCP for FW/NAT crossing by RTCWEB, SIP (audio/video)
conferencing, and related real-time applications.

Once above two items are completed, a separate draft using PCP for FW/NAT
crossing by RTCWEB applications can be written as soon as possible including
co-existing with ICE/STUN/TURN complementing each other capabilities.

Best regards,
Radhika

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
Harald Alvestrand
Sent: Tuesday, March 12, 2013 9:39 AM
To: Markus.Isomaki@nokia.com
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] FW: I-D Action:
draft-hutton-rtcweb-nat-firewall-considerations-00.txt

On 03/12/2013 02:42 AM, Markus.Isomaki@nokia.com wrote:
> Hi,
>
> ICE/STUN/TURN and PCP are not really competitors or alternatives to each
other.
>
> A browser or any other client will anyway need to implement ICE/STUN/TURN
to work its way through non-PCP supporting NATs, which will be the majority
for a long time even if PCP became succesfull. The benefit of the
ICE/STUN/TURN approach is that every organization or individual who deploys
NATs or firewalls will not need to deploy STUN and TURN servers, but they
can be deployed independently e.g. by the WebRTC service provider.
>
> However, PCP, even gradually deployed, would still be useful as well. As
Reinaldo is saying, it would improve robustness it produces explict NAT
mappings with explicit durations. Also, it can serve as an alternative to
STUN/TURN in case the browser happens to be behind a PCP-capable NAT/FW. So,
PCP can be seen as an optimization and should be used when it is available.
PCP can also help clients behind NAT/FW to reduce their keep-alive rate
which is applicable to WebRTC as well. However, as depicted in [1], knowing
when a client can entirely rely on PCP is not always so easy to detect.
>
> I hope we will see PCP deployment especially in the mobile/cellular
access, but as many people have pointed out, the success rate of this type
of protocols has been quite low. So it will be a nice surprise rather than
something I would count on if it happens.

I absolutely agree with this summary about the usefulness and status of PCP.

My concern with RTCWEB at the moment is getting things out the door with all
the features we really need to have, and as few additional features as
possible.

That's why I don't want to add PCP into the mix at this time - once we're
finished with the basic stuff, we can discuss adding support for new
features at our leisure, but making the specs more complex than they
currently are really should be done only when it's a really important
feature that needs adding.

            Harald

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

Classification: UNCLASSIFIED
Caveats: NONE



------=_NextPart_000_002A_01CE1F0E.BAD29850
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
SIb3DQEJBTEPFw0xMzAzMTIxNDQ1MzZaMCMGCSqGSIb3DQEJBDEWBBS8X8FkpiekWm3dP1ldOr7X
aJYv5TBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC
BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x
CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG
A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm
oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E
MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB
AQUABIIBAMUMqTp6jXh1Ji8zDd+291+7Uln3AyexePbWiNMVjp0YCGDf/NG5NFgYbu2e7dRSd4P/
KZK0SI+F6fIyb62bf/hfg5FG74dHJ7HsU7Q9chABJCLVgjuo/+RWxx5GUGVxyY7hSzKnmfVpecDP
x6I70E/Ojza2Vc7PcB/QLLRYxeFp6FvAJVPlQXItOz5LatSn2OOG/vw6Le527NpHrDo4qPp9YkND
rGtBLI/mgbDYYkdawrNrBL8gPMNecCiX0N+epl6eH4BpdRCMkfTL3EAnL0HjpHYAcWMNSFSYPj0C
ICiA58b6AzDFdKxvpbB9qUd/1O8GZv5Zfy24gEDFNOmRGyYAAAAAAAA=

------=_NextPart_000_002A_01CE1F0E.BAD29850--

From ted.ietf@gmail.com  Tue Mar 12 07:47: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 8959B21F8BEA for ; Tue, 12 Mar 2013 07:47:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.584
X-Spam-Level: 
X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.016,  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 IRu9iyN8cfzU for ; Tue, 12 Mar 2013 07:47:34 -0700 (PDT)
Received: from mail-ia0-x22c.google.com (mail-ia0-x22c.google.com [IPv6:2607:f8b0:4001:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 06B3F21F8BE0 for ; Tue, 12 Mar 2013 07:47:33 -0700 (PDT)
Received: by mail-ia0-f172.google.com with SMTP id l29so4849824iag.17 for ; Tue, 12 Mar 2013 07:47:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/6cdlUavzJ/YLe0VKEguRPvFi3IWiZCu/NDGCooyYiQ=; b=ErX/MWhdC+ehv5sogGNF0BGdVEo+Zmoa0ZY8OVPDjTX+1l3ytL9LO4JeZTp3mPcuQp vIf+Ouxy0URN3Jc+u58o3PIGup90oDaF2HiTbQ5qBhEfBr9hbPi2kU5p433bFafBCI7d 4kf9nk+0zg5OM2oYZ1eSKrk4WmSMBjTIXG6F1gbJIZ0GHxDh4FLJqwzWkj5WSmt2SFHL 8sQ1HMd2+7caHjXiyvkO8tl4/P82G8fODl9y7VqUaNK8Yo4QqO5LWs7eFFKKnMIlbTQq xdacy9RgouBd6aC+XFvOOnvZX5Vp74XE5SX6HbE3kScj2ZBUIcwUvfq5zyjHHjRvNvG6 91VQ==
MIME-Version: 1.0
X-Received: by 10.50.182.137 with SMTP id ee9mr11877460igc.96.1363099653452; Tue, 12 Mar 2013 07:47:33 -0700 (PDT)
Received: by 10.43.135.202 with HTTP; Tue, 12 Mar 2013 07:47:33 -0700 (PDT)
In-Reply-To: 
References: 
Date: Tue, 12 Mar 2013 10:47:33 -0400
Message-ID: 
From: Ted Hardie 
To: Markus.Isomaki@nokia.com
Content-Type: text/plain; charset=ISO-8859-1
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] H.264 IPR status (RE: VP8 litigation in Germany?)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 14:47:34 -0000

On Tue, Mar 12, 2013 at 10:19 AM,   wrote:

>
> Please see the URLs posted earlier today by Harald and Stephan, > and the summary of H.264 IPR situation by Stephan.

I actually wasn't able to find license text at any of those; Stephan's
message indicated that they did vary (since apparently some mention
reciprocity and some do not).  So it really would be helpful if the
data that an IETF disclosure would provide (patents + license) were
available in a simple form for the working group to review.


 >Are you asking for this about Nokia specifically, or for all of the
> H.264 proponents (several affiliations) or for H.264 in general?
> Nokia is certainly no special case in that context.

I certainly encourage *anyone* with data that helps the working group
make this decision to bring it forward.  Thanks to you and Nokia for
your willingness to do so.

regards,

Ted Hardie

From prvs=7783af613c=gmartincocher@blackberry.com  Tue Mar 12 09:09: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 30A1321F8962 for ; Tue, 12 Mar 2013 09:09:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.098
X-Spam-Level: 
X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=0.106,  BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 ULwgVO10EEEX for ; Tue, 12 Mar 2013 09:09:25 -0700 (PDT)
Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7467221F8941 for ; Tue, 12 Mar 2013 09:09:25 -0700 (PDT)
X-AuditID: 0a412830-b7ef86d00000339d-db-513f5328715c
Received: from XCT102CNC.rim.net (xct102cnc.rim.net [10.65.161.202]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id F3.F7.13213.8235F315; Tue, 12 Mar 2013 11:09:12 -0500 (CDT)
Received: from XCT109CNC.rim.net (10.65.161.209) by XCT102CNC.rim.net (10.65.161.202) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 12 Mar 2013 12:09:12 -0400
Received: from XMB106BCNC.rim.net ([fe80::99b8:8d0e:cdcd:c00d]) by XCT109CNC.rim.net ([::1]) with mapi id 14.02.0328.009; Tue, 12 Mar 2013 12:09:11 -0400
From: Gaelle Martin-Cocher 
To: David Singer , Cullen Jennings 
Thread-Topic: [rtcweb] Request to postpone the question on VP8 as MTI
Thread-Index: Ac4dlY3FzJtNznrqSx+jCyG0eO/KJAAMz82AAEDuGQAAG6aKkA==
Date: Tue, 12 Mar 2013 16:09:10 +0000
Message-ID: <92D0D52F3A63344CA478CF12DB0648AA2653B7D5@XMB106BCNC.rim.net>
References: <92D0D52F3A63344CA478CF12DB0648AA26537A69@XMB106BCNC.rim.net>  
In-Reply-To: 
Accept-Language: fr-FR, en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.160.249]
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCKsWRmVeSWpSXmKPExsXC5bjwlK5GsH2gQcdJHYsP638wWqz9185u Mb//I4sDs8fWkz/YPJYs+cnkcfn8R8YA5qgGRpukxJKy4Mz0PH07m8S8vPySxJJUhZTU4mRb JZ/U9MQchYCizLLE5EoFl8zi5JzEzNzUIiWFzBRbJRMlhYKcxOTU3NS8ElulxIKC1LwUJTsu BQxgA1SWmaeQmpecn5KZl26r5Bnsr2thYWqpa6hkp5vQyZMxa8dCxoKv5hV7j51gbWCcqtvF yMkhIWAiceTwRGYIW0ziwr31bF2MXBxCAu1MErd7brNAOCsZJc7M64Vy5jJKvL97mx2khU3A UuL/qz1ACQ4OEQEXiZsXwkDCzALqEncWnwMrEQYKLz60hxXEFhFwlTj+fQkjhO0ksfTaRhYQ m0VAVaJh50KwGl4BT4nFj94xQ+xawygx8/gssAZOAVuJ0z0ggzg4GAVUJE4+DYfYJS5x68l8 JogPBCSW7DkP9Y2oxMvH/1ghbEWJvc+OMkHU60ncmDqFDcLWlli28DUzxF5BiZMzn4DdIySg KXHyxTnGCYwSs5CsmIWkfRaS9llI2hcwsqxiFMzNKDYwM0zOS9YryszVy0st2cQITjYaBjsY 37+3OMQowMGoxMO7098+UIg1say4MvcQowQHs5II719foBBvSmJlVWpRfnxRaU5q8SFGV2AI TWSW4k7OBybCvJJ4YwMD3BwlcV6RQNFAIYF0YBrLTk0tSC2CmcPEwQmyh0tKpBiYjFKLEktL MuJBKTO+GJg0pRoYTzHNOb/t/4qUI8d3ffraPefvszdzzl98MbvzvErwj/Cfa6Rjwq4v2ht2 bvGyhTNmT13PkFZyW/Bi/dLMqcqmc2Sc5IqnldW222VLrVQvEnnNP/3MfG6J7j0Z/GI6ix1j z9f4uU/Q6bpx4uinO3f8KuNNXv4Uvvj/qPps3VUHDsbPmvYjiaMpXFmJpTgj0VCLuag4EQBB tF2NdwMAAA==
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Request to postpone the question on VP8 as MTI
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 16:09:27 -0000

Dear All,

I am following up on my request to postpone the discussion.
It appears that the new license for VP8 and the Nokia declaration in IETF on=
 VP8 are not available yet.
Questions were not answered either.
The meeting has started, and that particular discussion is planned for Thurs=
day.

In light of the recent email exchanges, it is clear that the discussion is n=
ot technical at all anymore; this is about risk assessments and legal matter=
s. 
It seems that it would be necessary that legal counsels from IETF and from t=
he various companies are involved in the discussion. I am not sure if this t=
opic will be better dealt with in the RTCWeb group of if there is another gr=
oup in IETF that would be more suitable. 
One (as a technical expert) can try to bring his/her legal counsel up to spe=
ed quickly; but within that time frame and without tangible information that=
 is very improbable  that our respective legal counsel will be able to have=
 an informed position and that each one of us would be in a position to reac=
h a consensus on Thursday.

I am hence re-iterating my request to postpone that discussion. Cullen (or c=
hairs) , would you mind giving an update on this?

Sincerely,
Ga=EBlle

-----Original Message-----
From: David Singer [mailto:singer@apple.com] 
Sent: Monday, March 11, 2013 6:52 PM
To: Cullen Jennings
Cc: Gaelle Martin-Cocher; rtcweb@ietf.org
Subject: Re: [rtcweb] Request to postpone the question on VP8 as MTI


On Mar 10, 2013, at 8:52 , Cullen Jennings  wrote:

> 
> Gaelle,
> 
> I think these are good points and other have erased similar points. I need=
 to discuss it with my co-chairs but I suspect that for the points you raise=
d, we will need delay this to IETF 86. Again, I need to talk to my co-chairs=
 before we can make a decision on this but I would guess that is the directi=
on things will need to go.

I also think it would be prudent to defer the codec decision.


> 
> Cullen (One of the co-chairs)
> 
> 
> On Mar 10, 2013, at 9:45 AM, Gaelle Martin-Cocher  wrote:
> 
>> Dear All,
>> 
>> In light of the recent announcements (both MPEG-LA and the VP8 litigation=
), I believe that more time is needed to make a proper risk assessment on VP=
8 and an informed decision. On one side the MPEG-LA announcement provides so=
me relief but also confirms that VP8 does not come for free and that concern=
s were/are justified. This is further confirmed by the second announcement.
>> It will take more efforts for VP8 supporters (and Google does not need to=
 be alone in that process) to reach the goal of an RF video codec (or a code=
c with a suitable licensing terms). I think it is understood by now, that th=
is would likely be more prone to success in a standardization body than anyw=
here else . (speaking here as a WebVC proponent that went through that proce=
ss too).
>> It is also apparent that the MPEG-LA/Google agreement raises additional q=
uestions.
>> 
>> Here are the reasons I believe we need more time and should postpone the=
 question on VP8 (I am not saying that this should not be asked at a later t=
ime):
>> -The license is not yet published (and the meeting starts tomorrow) 
>> -Some negotiations are still ongoing (e.g. names of the licensors).
>> -Some questions were/are raised and not answered yet, below are the one t=
hat matters to me:
>> - Will the patent list be provided?
>> - Who are the licensors  and how that group of licensors relates to the i=
nitial 12 patent holders identified by MPEG-LA?
>> - Will there be alignment of licenses across WebM, RFC, MPEG, and is that=
 even feasible with the possible new license terms?
>> - Questions related to clarifications of the different grants 
>> inside/outside the RFC and their applicability to the RFC itself 
>> still need to be answered (aka: how  section 20: 27 apply to the RFC 
>> code itself or to the code provided in MPEG)
>> - Questions related to the status of VP8 as a standard as it was 
>> mentioned that the RFC will not progress to the standard track still 
>> remain
>> - In light of the litigation announcement, was due diligence done by 
>> VP8 proponents toward patent holders that are not MPEG-LA members?  
>> (e.g. possibly on a model similar to what was done in WebVC)
>> - More questions will likely be raised once the license is published.
>> -We need to give enough time to Google to finalize its license and provid=
e answers on those above points.
>> -VP8 is not (yet) a standard in IETF nor in MPEG (MPEG only saw an input=
 contribution for the first time in January). It would be desirable that RTC=
Web points to a standard or that VP8 reaches a certain stage in MPEG so that=
 it can be considered as an MPEG deliverable. VP8 may reach that status at a=
 next MPEG meeting in April or July, I don't see how that can be accelerated=
 further. We need to give MPEG the time to proceed properly.
>> -legal entities will need time to review both the new license and the ans=
wers to the various questions that were asked. This cannot be achieved in 3=
 days.
>> 
>> Further, I just came across an informational RFC for VP9:
>> -Is VP9 going to "deprecate" VP8?
>> - What is the timeframe for VP9 in IETF?
>> -if VP9 going to be proposed for a next generation of RTCWeb Client? Whic=
h timeframe?
>> I don't think it would be desirable to mandate VP8 today if VP9 is around=
 the corner and will be proposed for RTCWeb as well.
>> Requesting two codecs to be implemented instead of one in a short timefra=
me is obviously an issue for implementers that cannot do a simple software u=
pgrade of their products.
>> 
>> 
>> I hope all of you will find that request reasonable.
>> Sincerely,
>> 
>> 
>> Ga=EBlle Martin-Cocher
>> Standards Manager
>> Office: (905) 629-4746 x14591
>> BlackBerry: (647) 267-0569
>> PIN: 2835485E
>> 
>> www.rim.com
>> 
>> ---------------------------------------------------------------------
>> This transmission (including any attachments) may contain 
>> confidential information, privileged material (including material 
>> protected by the solicitor-client or other applicable privileges), or 
>> constitute non-public information. Any use of this information by 
>> anyone other than the intended recipient is prohibited. If you have 
>> received this transmission in error, please immediately reply to the 
>> sender and delete this information from your system. Use, 
>> dissemination, distribution, or reproduction of this transmission by 
>> unintended recipients is not authorized and may be unlawful. 
>> _______________________________________________
>> 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

David Singer
Multimedia and Software Standards, Apple Inc.


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From magnus.westerlund@ericsson.com  Tue Mar 12 10:41: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 B227411E80E7 for ; Tue, 12 Mar 2013 10:41:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.181
X-Spam-Level: 
X-Spam-Status: No, score=-106.181 tagged_above=-999 required=5 tests=[AWL=0.068, 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 CPVQX6OCMf+s for ; Tue, 12 Mar 2013 10:41:37 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 16E9C11E80F0 for ; Tue, 12 Mar 2013 10:41:34 -0700 (PDT)
X-AuditID: c1b4fb30-b7f0d6d000007e61-54-513f68c97433
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id C4.26.32353.9C86F315; Tue, 12 Mar 2013 18:41:29 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Tue, 12 Mar 2013 18:41:28 +0100
Message-ID: <513F68C0.4010106@ericsson.com>
Date: Tue, 12 Mar 2013 13:41:20 -0400
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEJMWRmVeSWpSXmKPExsUyM+Jvje7JDPtAgzkTVSzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtddL5kLzrFWzJ10kq2B8TJLFyMnh4SAicTzptlMELaYxIV7 69m6GLk4hAROMkrMvdrGCOEsZ5SYsP0wWBWvgLbEji3n2UFsFgFViXNf7oFNYhOwkLj5oxGo m4NDVCBY4uZiOYhyQYmTM5+AlYgIqEtcfngBrFVYwFzi6/JWqCMkJba8aAeLMwvoSUy52sII YctLNG+dzQxiCwGtbWjqYJ3AyD8LydhZSFpmIWlZwMi8ipE9NzEzJ73cfBMjMJwObvltsINx 032xQ4zSHCxK4rzhrhcChATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTBqH7rXlXbM1N721K5L TzMlXxWYrFy7uyFC5HzAFIecfwfLZx+XXfTNal98RIeMwzIFOZNct+NJ56V71efNzF8gk8Pe 5TZnT3fTQZ60AI+w3tkuSXYedSIzvihy5/jef9SsssPwTNXvcEERVrvmxus/lnSsO6t0enZA c/CR23KNPXKKW79rJiixFGckGmoxFxUnAgC89hp69QEAAA==
Subject: [rtcweb] Video Codec discussion in Thursday agenda slot
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 17:41:37 -0000

WG,

We will hold the presentations and the discussion on Thursday regarding
mandatory to implement video codec. Prior to any consensus question
regarding the actual codec the chairs will verify consensus to ask such
questions.

For the chairs

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 singer@apple.com  Tue Mar 12 11:12: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 688C811E8136 for ; Tue, 12 Mar 2013 11:12:43 -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 TzNWIuN9zk2o for ; Tue, 12 Mar 2013 11:12:42 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 22E0611E80E4 for ; Tue, 12 Mar 2013 11:12:42 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Received: from relay2.apple.com ([17.128.113.67]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MJK00GJ77WIH640@mail-out.apple.com> for rtcweb@ietf.org; Tue, 12 Mar 2013 11:12:41 -0700 (PDT)
X-AuditID: 11807143-b7f896d000006d55-c4-513f70193eeb
Received: from cardamom.apple.com (cardamom.apple.com [17.128.115.94]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay2.apple.com (Apple SCV relay) with SMTP id 5B.4F.27989.9107F315; Tue, 12 Mar 2013 11:12:41 -0700 (PDT)
Received: from [17.153.105.92] by cardamom.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MJK00CW87WYWF30@cardamom.apple.com> for rtcweb@ietf.org; Tue, 12 Mar 2013 11:12:41 -0700 (PDT)
From: David Singer 
In-reply-to: <513F68C0.4010106@ericsson.com>
Date: Tue, 12 Mar 2013 11:12:33 -0700
Content-transfer-encoding: quoted-printable
Message-id: 
References: <513F68C0.4010106@ericsson.com>
To: Magnus Westerlund 
X-Mailer: Apple Mail (2.1499)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FAcpytZYB9o0L9ey2Ltv3Z2B0aPJUt+ MgUwRnHZpKTmZJalFunbJXBlLOu4ylJwiqfi9cdDzA2MS7i6GDk5JARMJDqufGSEsMUkLtxb z9bFyMUhJDCRSeLi3TVMEE4Lk8TGL3+YQaqYBXQker9/A7I5OHgF9CQm7Q8CCQsLuEgsvbOc BcRmE1CVeDDnGNhQTqDyX2v2gtksQPGFv5vYIMZYSmzY3gA1UlviybsLrBAjbSSuPrQBCQsB hRuvdoG1igiYSTycsJ8N4k5ZiRVTe5kmMArMQnLQLISDZiEZuoCReRWjQFFqTmKlkV5iQUFO ql5yfu4mRnDQFTrvYDy2zOoQowAHoxIPr0SafaAQa2JZcWXuIUYJDmYlEd6/vkAh3pTEyqrU ovz4otKc1OJDjNIcLErivBkBtoFCAumJJanZqakFqUUwWSYOTqkGRlZP7Ubf2n2FHqLX7/zv XFvRdvdQwv3IB0vtrd+f6LnJclLz1/vM+j1c/YqzNIzqGe04eJK/vq9n83/wddlZMY6wpLJv S6bHb5wmM+mR97vWQl9dvggFyfWC/h/9dr9133RI+9XtS6oJWq+UVvYdZ33r+lrys3Tjl44t pyV8FyZcDFvBv7TvnhJLcUaioRZzUXEiADCDRkY2AgAA
Cc: Stuart Cheshire , rtcweb@ietf.org
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 18:12:50 -0000

I am sorry, I don't understand.

At the last meeting, the codec discussion was deferred at the request of =
one company and with no reason offered.  It was delayed so late that =
people, such as my colleague, who had flown in for this discussion had =
already arrived when it was deferred.

This time, we have late-breaking news which is missing important =
details, warrants significant preparatory discussion before the meeting, =
and you have justified requests for time from multiple companies, and =
you go ahead?



On Mar 12, 2013, at 10:41 , Magnus Westerlund =
 wrote:

> WG,
>=20
> We will hold the presentations and the discussion on Thursday =
regarding
> mandatory to implement video codec. Prior to any consensus question
> regarding the actual codec the chairs will verify consensus to ask =
such
> questions.
>=20
> For the chairs
>=20
> Magnus Westerlund
>=20
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> F=E4r=F6gatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

David Singer
Multimedia and Software Standards, Apple Inc.


From matthew@matthew.at  Tue Mar 12 11:26: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 6E0AE11E8120 for ; Tue, 12 Mar 2013 11:26:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.39
X-Spam-Level: 
X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[AWL=0.039,  BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, 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 iobCPWUJR4OA for ; Tue, 12 Mar 2013 11:26:46 -0700 (PDT)
Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F88011E8109 for ; Tue, 12 Mar 2013 11:26:45 -0700 (PDT)
Received: from [10.10.155.229] (unknown [10.10.155.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id A3F37230005; Tue, 12 Mar 2013 11:26:44 -0700 (PDT)
Message-ID: <513F734E.5010803@matthew.at>
Date: Tue, 12 Mar 2013 11:26:22 -0700
From: Matthew Kaufman 
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: David Singer 
References: <513F68C0.4010106@ericsson.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090207000803010204020103"
Cc: Stuart Cheshire , rtcweb@ietf.org
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 18:26:52 -0000

This is a multi-part message in MIME format.
--------------090207000803010204020103
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

I don't get it either. Until Google posted their announcement, nothing 
had changed since the last postponement. Once Google posted their 
announcement, it was posted too late to be of any value for this 
meeting. And the relevant legal text (among other things) is still "TBD" 
and not even available for review.

I will reiterate what I said on March 7th: "Therefore I believe the most 
sensible action is to once again delay the MTI video codec discussion, 
remove it from the agenda from the upcoming meeting, and have the call 
for an MTI codec at a later time... no sooner than several weeks after 
the relevant license terms are even available to review. I hope the 
chairs concur."

The chairs now have requests from at least three participants to 
entirely defer the presentation and discussion. I cannot see how this 
could possibly have less weight than the single request received the 
very morning of the meeting last time.

We can hold a consensus call on the list right now regarding whether or 
not to proceed if these three requests are not enough.

Matthew Kaufman


On 3/12/2013 11:12 AM, David Singer wrote:
> I am sorry, I don't understand.
>
> At the last meeting, the codec discussion was deferred at the request of one company and with no reason offered.  It was delayed so late that people, such as my colleague, who had flown in for this discussion had already arrived when it was deferred.
>
> This time, we have late-breaking news which is missing important details, warrants significant preparatory discussion before the meeting, and you have justified requests for time from multiple companies, and you go ahead?
>
>
>
> On Mar 12, 2013, at 10:41 , Magnus Westerlund  wrote:
>
>> WG,
>>
>> We will hold the presentations and the discussion on Thursday regarding
>> mandatory to implement video codec. Prior to any consensus question
>> regarding the actual codec the chairs will verify consensus to ask such
>> questions.
>>
>> For the chairs
>>
>> 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
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> David Singer
> Multimedia and Software Standards, Apple Inc.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--------------090207000803010204020103
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

      
      
      
      
      
      
      
      
      
      I don't get it either. Until Google posted their
      announcement, nothing had changed since the last postponement.
      Once Google posted their announcement, it was posted too late to
      be of any value for this meeting. And the relevant legal text
      (among other things) is still "TBD" and not even available for
      review.

      

      I will reiterate what I said on March 7th: "Therefore I believe
      the most sensible action is to once again delay the MTI video
      codec discussion, remove it from the agenda from the upcoming
      meeting, and have the call for an MTI codec at a later time… no
      sooner than several weeks after the relevant license terms are
      even available to review. I hope the chairs concur."

      

      The chairs now have requests from at least three participants to
      entirely defer the presentation and discussion. I cannot see how
      this could possibly have less weight than the single request
      received the very morning of the meeting last time.

      

      We can hold a consensus call on the list right now regarding
      whether or not to proceed if these three requests are not enough.

      

      Matthew Kaufman

      

      

      On 3/12/2013 11:12 AM, David Singer wrote:

    

    

      
I am sorry, I don't understand.

At the last meeting, the codec discussion was deferred at the request of one company and with no reason offered.  It was delayed so late that people, such as my colleague, who had flown in for this discussion had already arrived when it was deferred.

This time, we have late-breaking news which is missing important details, warrants significant preparatory discussion before the meeting, and you have justified requests for time from multiple companies, and you go ahead?



On Mar 12, 2013, at 10:41 , Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:



      

        
WG,

We will hold the presentations and the discussion on Thursday regarding
mandatory to implement video codec. Prior to any consensus question
regarding the actual codec the chairs will verify consensus to ask such
questions.

For the chairs

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
----------------------------------------------------------------------

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


      

      
David Singer
Multimedia and Software Standards, Apple Inc.

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


    

    

  


--------------090207000803010204020103--

From ted.ietf@gmail.com  Tue Mar 12 11:33: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 507C111E817B for ; Tue, 12 Mar 2013 11:33:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.585
X-Spam-Level: 
X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.015,  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 0LDl7zlWzPZ7 for ; Tue, 12 Mar 2013 11:33:17 -0700 (PDT)
Received: from mail-ia0-x235.google.com (mail-ia0-x235.google.com [IPv6:2607:f8b0:4001:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9705311E817C for ; Tue, 12 Mar 2013 11:33:16 -0700 (PDT)
Received: by mail-ia0-f181.google.com with SMTP id w33so150729iag.12 for ; Tue, 12 Mar 2013 11:33:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3vKRVNIdyY4PdvAzI2kDMiGSt9/g27EamuzV5tUO5+k=; b=Xip83E2XvYfcmjjNVVqHAwkvfNOpllL1EDZWwV2mtrd82z8fIvDLgcgUGfdsFku4v1 Ve4rNBhbUX5jm4iEpd0lAymuOmHFHPP3HUgoDGCTjMKGXdjfr/ko4BKFlcIqPqZMyktD Fcbf6O6bC56KgIvzY10ENLxmXSbII3QSx0PDJwCS37ZBj9NJnI1xxvcY4kbtd9VDj8Y6 b4gkyK1tCWXGFR7sPfT+dKNPZQrdkY3otdNV6uqYxXNTfh7ky++K23GJKqwq3Yu2+v2o 5xPfHJW6gq0H3MBVc6cysm1ZlKU+EORdDlr1eJ4Pf789E5Z+rTLDrF9ORNnbWxB4XTix B2Rw==
MIME-Version: 1.0
X-Received: by 10.50.87.196 with SMTP id ba4mr12978888igb.20.1363113194898; Tue, 12 Mar 2013 11:33:14 -0700 (PDT)
Received: by 10.43.135.202 with HTTP; Tue, 12 Mar 2013 11:33:14 -0700 (PDT)
In-Reply-To: 
References: <513F68C0.4010106@ericsson.com> 
Date: Tue, 12 Mar 2013 14:33:14 -0400
Message-ID: 
From: Ted Hardie 
To: David Singer 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Stuart Cheshire , rtcweb@ietf.org
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 18:33:18 -0000

Hi David,

On Tue, Mar 12, 2013 at 2:12 PM, David Singer  wrote:
> I am sorry, I don't understand.
>
> At the last meeting, the codec discussion was deferred at the request of one company and with no reason offered.  It was delayed so late that people, such as my colleague, who had flown in for this discussion had already arrived when it was deferred.
>
> This time, we have late-breaking news which is missing important details, warrants significant preparatory discussion before the meeting, and you have justified requests for time from multiple companies, and you go ahead?
>
>
Magnus and I discussed this with the RAI area directors last night at
some length, and our joint conclusion was that the presentations could
go ahead in the existing agenda slot because there was technical
content to discuss.  Those discussions need to happen
in advance of the overall consensus call, and we concluded that we
could likely do that at this meeting without having to re-do it again
in the light of new IPR data.  (In the interest of full disclosure, I
should note that Cullen disagreed with this, but was not able to
attend the discussion with the ADs, as he has been unavoidably
detained).

Magnus's comment "Prior to any consensus question regarding the actual
codec the chairs will verify consensus to ask such questions." means
that a consensus call on whether or not there is currently enough
information to make a decision will happen before a call on
the actual codec.   If there is no such consensus, the call on the
actual codec is likely to happen on the list, as a two week last call
after the new data is available.  That's not entirely fixed as a plan
in part because we have not been able to discuss it with Cullen, but
that's the basic idea at the moment.

As before, all of the chairs and our AD have potential conflicts of
interest, so Robert Sparks will be asking the actual consensus calls
and assessing the results.

Hope that helps explain things,

regards,

Ted Hardie

From hta@google.com  Tue Mar 12 11:21: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 3C52221F8976 for ; Tue, 12 Mar 2013 11:21:39 -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 ObBIr0Ep3Zzw for ; Tue, 12 Mar 2013 11:21:38 -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 E4E2C21F8940 for ; Tue, 12 Mar 2013 11:21:37 -0700 (PDT)
Received: by mail-qe0-f45.google.com with SMTP id b4so93236qen.32 for ; Tue, 12 Mar 2013 11:21:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=GXH1EETaLBDv8YpWbKBKd/XqykB3dD86seTBBFOpUA0=; b=VoWOTMlC1buh1occ3FrT1oYYIz8roaJPNA/Ovm8VFhNEFM6frhxjN7Ya1qjVp6j7YV cFu2YHeLfr1JB9P/3XYKPCwPhknf6McrtoWV3QS4sDwztKmeKcAbToqFHt4UlcLhtOcZ W1FkloL/jyv1FiNT3SxB1UwROlfqV69rDjZjIW9hFQwm4FCQowEoRVKQoOIGlVpUTEKH erz0xMtZcmsV83twTZoKKDHHb6HNy1cVGut47C1F22JEdVqTAU/uevSDhyYSbqoyqs7/ yD3fp0615GmeORwZSU0Jk5mpISVaTd0reS6AYmzTI6Gam8IhbKDvZQH4iVjHIFf0Kq/H pRhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=GXH1EETaLBDv8YpWbKBKd/XqykB3dD86seTBBFOpUA0=; b=j/iVGQsyJXNd7aY0hserfD7RuwoEU+VT/JaHPvLcuv12teBS0eFe7sYVPx491/ubj5 FxObRTqrpZ5xNaANUb66XXKkJrCfApj2vV0dMCrl257ryAfFgdwz1wgiLlozg7cQd8MZ fDZgsfQTpIOZYI7WF8qi4K58eZC3OabVqjWt17E2Osl+zmWALrOqV976d6S7rWdrM0zI d3GzlFhBsNzm7hTKasLZym3MxZk3Pvz9PUeC0YQCsuTxF07Yi1uFDGHKVJwlGEF9vky2 kRjCes/BAjqaINU6nP27mUvJmK0sYA9cscdIYHJCLvVGkwiMaL3u0FSThfNMiSMeaTQy bugw==
X-Received: by 10.224.71.16 with SMTP id f16mr3542712qaj.31.1363112497294; Tue, 12 Mar 2013 11:21:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.128.17 with HTTP; Tue, 12 Mar 2013 11:21:17 -0700 (PDT)
From: Harald Alvestrand 
Date: Tue, 12 Mar 2013 19:21:17 +0100
Message-ID: 
To: rtcweb@ietf.org
Content-Type: multipart/alternative; boundary=bcaec51b1b9730e95c04d7be5cbd
X-Gm-Message-State: ALoCoQlRLQxaJ11MIYTWKOXuS2gPuhg4hoCS6KIshgLEvc3/9vrEmisTnP0OuFMUIm0ge9RTBLNnwU3njlS/fPAhsJ1exIcBJSEamNX403XSdnjT8X6910UwIivKD5HRi1PLzGDBuTyQL0ssMzXSQuJzwf8U3coMrAgxYhyE34OpQPB4ItcJFD8eysgeQDE5Lxg1q+JW1k9x
X-Mailman-Approved-At: Tue, 12 Mar 2013 11:34:49 -0700
Subject: [rtcweb] Detailed test results for our VP8 to H.264 comparisions
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 18:21:39 -0000

--bcaec51b1b9730e95c04d7be5cbd
Content-Type: text/plain; charset=UTF-8

As part of the effort to make sure people have the maximum amount of
information wrt the choice of MTI codec for RTCWEB, we've made the scripts,
source files and results for our quality measurements available on the WEBM
project website.

The 4 documents of interest are:

- The PSNR quality measurements:
http://downloads.webmproject.org/ietf_tests/vp8_vs_h264_quality.html

- The CPU usage for encode/decode:
http://downloads.webmproject.org/ietf_tests/vp8_vs_h264_speed.html

- The scripts used for generating the graphs:
http://downloads.webmproject.org/ietf_tests/vp8_vs_h264.tar.xz

- A text presentation of the CPU results:
http://downloads.webmproject.org/ietf_tests/vp8vsh264-decodetime.txt

The source videos in YUV format are also available from the same site.

The scripts file contains a README file; if you want to verify the results,
or understand how the results were arrived at, please follow the
instructions in this file.

Harald, for the WEBM team

--bcaec51b1b9730e95c04d7be5cbd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


As part of the effort to make sure people have the maximum amount of infor=
mation wrt the choice of MTI codec for RTCWEB, we've made the scripts, =
source files and results for our quality measurements available on the WEBM=
 project website.




The 4 documents of int=
erest are:
=












- The scripts used for=
 generating the graphs:



- A te=
xt presentation of the CPU results:=C2=A0http://downloads.webmproject=
.org/ietf_tests/vp8vsh264-decodetime.txt




The source videos in Y=
UV format are also available from the same site.



The sc=
ripts file contains a README file; if you want to verify the results, or un=
derstand how the results were arrived at, please follow the instructions in=
 this file.




Harald, for the WEBM t=
eam


--bcaec51b1b9730e95c04d7be5cbd--

From prvs=4783119d51=gmartincocher@blackberry.com  Tue Mar 12 11: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 343CA11E8179 for ; Tue, 12 Mar 2013 11:37:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.133
X-Spam-Level: 
X-Spam-Status: No, score=-5.133 tagged_above=-999 required=5 tests=[AWL=0.070,  BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 KFciueuRECBH for ; Tue, 12 Mar 2013 11:37:21 -0700 (PDT)
Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6637B11E80FB for ; Tue, 12 Mar 2013 11:37:21 -0700 (PDT)
X-AuditID: 0a412830-b7ef86d00000339d-a1-513f75d8c59c
Received: from XCT101CNC.rim.net (xct101cnc.rim.net [10.65.161.201]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 2E.DD.13213.8D57F315; Tue, 12 Mar 2013 13:37:12 -0500 (CDT)
Received: from XCT110CNC.rim.net (10.65.161.210) by XCT101CNC.rim.net (10.65.161.201) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 12 Mar 2013 14:37:12 -0400
Received: from XMB106BCNC.rim.net ([fe80::99b8:8d0e:cdcd:c00d]) by XCT110CNC.rim.net ([::1]) with mapi id 14.02.0328.009; Tue, 12 Mar 2013 14:37:11 -0400
From: Gaelle Martin-Cocher 
To: Ted Hardie , David Singer 
Thread-Topic: [rtcweb] Video Codec discussion in Thursday agenda slot
Thread-Index: AQHOH0jpubeezyLlMka1Nd5JzNGBEZiintGAgAAFyAD//718IA==
Date: Tue, 12 Mar 2013 18:37:11 +0000
Message-ID: <92D0D52F3A63344CA478CF12DB0648AA2653BC5E@XMB106BCNC.rim.net>
References: <513F68C0.4010106@ericsson.com>  
In-Reply-To: 
Accept-Language: fr-FR, en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.160.249]
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGKsWRmVeSWpSXmKPExsXC5bjwpO6NUvtAg+5rJhbH7tRYrP3Xzm4x v/8ji0XjXDsHFo+tJ3+weeycdZfdY8mSn0wBzFENjDZJiSVlwZnpefp2Nol5efkliSWpCimp xcm2Sj6p6Yk5CgFFmWWJyZUKLpnFyTmJmbmpRUoKmSm2SiZKCgU5icmpual5JbZKiQUFqXkp SnZcChjABqgsM08hNS85PyUzL91WyTPYX9fCwtRS11DJTjehkyfj2RvNgmlsFQtWfGNvYPzK 0sXIySEhYCIx++4hNghbTOLCvfVgtpBAO5NER6tHFyMXkL2SUeLs2kvsEM5cRonFe84xgVSx CVhK/H+1B2ySiICLxMdFt8FsZgFfiUOHW8BqhIHit14sY4KocZV4+3QGI4TtJHGjqQFsG4uA qsTn2yvA4rwCnhJn17xjhFi2lFGid8ImsASnQKBEw869rF2MHByMAioSJ5+GQ+wSl7j1ZD4T xAcCEkv2nGeGsEUlXj7+xwphK0rsfXaUCaJeT+LG1ClsELa2xLKFr5kh9gpKnJz5hAXie02J ky/OMU5glJiFZMUsJO2zkLTPQtK+gJFlFaNgbkaxgZlhcl6yXlFmrl5easkmRnDC0TDYwfj+ vcUhRgEORiUe3rfF9oFCrIllxZW5hxglOJiVRHj/+gKFeFMSK6tSi/Lji0pzUosPMboCQ2gi sxR3cj4wGeaVxBsbGODmKInzigSKBgoJpAOTWHZqakFqEcwcJg5OkD1cUiLFwFSUWpRYWpIR D0qY8cXAlCnVwDjB81XeZK8cYRa1BYJiL/be5rqYYCjglnfIZ99jWwlZgzVfT33Z/2EF8xXB M7/amd2CTHgW8jgZBLNINicm3+m83Ltp6ZmvzvPa3sy3VD7zdb2+p0vDI8+cmk3md7ecz0m8 tEL60CTWRmcBTq7lEjLXgz6xPm6Y2qsf976pbXWin88t38kqIUosxRmJhlrMRcWJANFXex15 AwAA
Cc: Stuart Cheshire , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 18:37:22 -0000

Magnus and I discussed this with the RAI area directors last night at some l=
ength, and our joint conclusion was that the presentations could go ahead in=
 the existing agenda slot because there was technical content to discuss.  T=
hose discussions need to happen in advance of the overall consensus call, an=
d we concluded that we could likely do that at this meeting without having t=
o re-do it again in the light of new IPR data.  (In the interest of full dis=
closure, I should note that Cullen disagreed with this, but was not able to=
 attend the discussion with the ADs, as he has been unavoidably detained).

[gmc] so why was those technical aspects not discussed at the prior meeting?
 Can there just be a technical discussion with no questions?


Ga=EBlle

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From tterriberry@mozilla.com  Tue Mar 12 11:41: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 950A411E80A3 for ; Tue, 12 Mar 2013 11:41:51 -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 Lm5rkZ68Lgfu for ; Tue, 12 Mar 2013 11:41:51 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 04EEA21F8793 for ; Tue, 12 Mar 2013 11:41:51 -0700 (PDT)
Received: from [130.129.33.240] (dhcp-21f0.meeting.ietf.org [130.129.33.240]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 7A85FF22D9 for ; Tue, 12 Mar 2013 11:41:50 -0700 (PDT)
Message-ID: <513F76ED.4090201@mozilla.com>
Date: Tue, 12 Mar 2013 11:41:49 -0700
From: "Timothy B. Terriberry" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120625 SeaMonkey/2.10.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <513F68C0.4010106@ericsson.com>  <513F734E.5010803@matthew.at>
In-Reply-To: <513F734E.5010803@matthew.at>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 18:41:51 -0000

Matthew Kaufman wrote:
> The chairs now have requests from at least three participants to
> entirely defer the presentation and discussion. I cannot see how this
> could possibly have less weight than the single request received the
> very morning of the meeting last time.

As I recall that morning, there was a hum in the room over whether or 
not to postpone, and the result was overwhelming. If it had not been, 
the result might have been very different.

From harald@alvestrand.no  Tue Mar 12 11:43: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 A696E11E8126 for ; Tue, 12 Mar 2013 11:43:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.645
X-Spam-Level: 
X-Spam-Status: No, score=-110.645 tagged_above=-999 required=5 tests=[AWL=-0.046, 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 sLNzLGw-oFA0 for ; Tue, 12 Mar 2013 11:43:25 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 60AC611E811D for ; Tue, 12 Mar 2013 11:43:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A082E39E1C9 for ; Tue, 12 Mar 2013 19:43:21 +0100 (CET)
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 orW4RURyVOup for ; Tue, 12 Mar 2013 19:43:20 +0100 (CET)
Received: from [IPv6:2001:df8:0:16:dc4b:da73:da24:d309] (unknown [IPv6:2001:df8:0:16:dc4b:da73:da24:d309]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0053239E1AD for ; Tue, 12 Mar 2013 19:43:19 +0100 (CET)
Message-ID: <513F7745.3020302@alvestrand.no>
Date: Tue, 12 Mar 2013 19:43:17 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <513F68C0.4010106@ericsson.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 18:43:25 -0000

On 03/12/2013 07:12 PM, David Singer wrote:
> I am sorry, I don't understand.
>
> At the last meeting, the codec discussion was deferred at the request of one company and with no reason offered.  It was delayed so late that people, such as my colleague, who had flown in for this discussion had already arrived when it was deferred.
>
> This time, we have late-breaking news which is missing important details, warrants significant preparatory discussion before the meeting, and you have justified requests for time from multiple companies, and you go ahead?

I am very sympathetic with the plight of people who don't have time to 
analyze the new information provided. Believe me, we did the best we 
could to make it available earlier - but as you know, it is not possible 
to announce a deal until the deal has actually been signed.

At the last meeting, we knew that this was likely to happen, but we 
could (of course) not breathe a word about it - it was clear from the 
traffic on the mailing list and the arguments being fielded in 
presentations that in the absence of information about the agreement, 
our assertions about the IPR situation of VP8 would simply not be taken 
at face value. This was the reason we requested a delay at that time.

At this meeting, we believe the important cards are on the table: H.264 
is still a royalty-required codec in all its profiles, and has many 
patent holders insisting on royalties being paid both outside and inside 
the MPEG-LA patent pool; VP8 is still a codec where all the IPR holders 
that have made declarations have declared their willingness to license 
on a royalty free basis (either directly or via Google).

We appreciate the need to have time to evaluate the specific words of 
the license statements that are forthcoming, and the need for the people 
who haven't made their IPR declarations over the last couple of years of 
discussion to do so within the next couple of weeks - but we do think 
that it is important to use the face to face time that we have here in 
Orlando to lay to rest any *other* issues than the licensing terms and 
other issues derived from Google's announcement.

Harald


From singer@apple.com  Tue Mar 12 11: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 9270311E8122 for ; Tue, 12 Mar 2013 11:50:38 -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 KXTQ-iKLmFcO for ; Tue, 12 Mar 2013 11:50:38 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8B78311E8108 for ; Tue, 12 Mar 2013 11:50:37 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay6.apple.com ([17.128.113.90]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MJK00G3W9NKH670@mail-out.apple.com> for rtcweb@ietf.org; Tue, 12 Mar 2013 11:50:29 -0700 (PDT)
X-AuditID: 1180715a-b7f566d000006daa-d2-513f78f55a4e
Received: from cardamom.apple.com (cardamom.apple.com [17.128.115.94]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay6.apple.com (Apple SCV relay) with SMTP id 78.D3.28074.5F87F315; Tue, 12 Mar 2013 11:50:29 -0700 (PDT)
Received: from [17.153.105.92] by cardamom.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MJK00CA19NMWF50@cardamom.apple.com> for rtcweb@ietf.org; Tue, 12 Mar 2013 11:50:29 -0700 (PDT)
From: David Singer 
In-reply-to: <513F7745.3020302@alvestrand.no>
Date: Tue, 12 Mar 2013 11:50:09 -0700
Message-id: 
References: <513F68C0.4010106@ericsson.com>  <513F7745.3020302@alvestrand.no>
To: Harald Alvestrand 
X-Mailer: Apple Mail (2.1499)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUi2FAcp/u1wj7Q4PVfbYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsbXpC2PBU4mK+Rc/sDYwvhLuYuTkkBAwkVhzaTEjhC0mceHe ejYQW0hgIpPExG75LkYuILuFSWLN92awBLOAlsT6nceZuhg5OHgF9CQm7Q8CCQsLuEgsvbOc BcRmE1CVeDDnGNhMTgFdiX3bprGD2CxA8RcLPzBCjBGW+P74HguErS3x5N0FVhCbV8BG4kPX MxaIvY2MEvP/tYA1iAjoSDzc38AEcaisxIqpvUwTGAVmITlpFsJJs5CMXcDIvIpRoCg1J7HS TC+xoCAnVS85P3cTIzjsCqN2MDYstzrEKMDBqMTDK5FmHyjEmlhWXJl7iFGCg1lJhPevL1CI NyWxsiq1KD++qDQntfgQozQHi5I4b3aAbaCQQHpiSWp2ampBahFMlomDU6qBcVFdRUDUrdev fn++7PVDn/spz+ubUTue2nVV/9Qvbq61WHLzU6PunQiXJdf35apMF40LmMomxfeLP+zNvdbF kjualy7dzim79vGk4p9hW4On/AotlTu5i//k7sBk92ijhYbiy4s+tFix/BFVntVh0Z2yJWGx 1NyF87fdvzDLasKfVFGZjXfLPZVYijMSDbWYi4oTAdKg56w3AgAA
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 18:50:40 -0000

On Mar 12, 2013, at 11:43 , Harald Alvestrand  wrote:

> On 03/12/2013 07:12 PM, David Singer wrote:
>> I am sorry, I don't understand.
>> 
>> At the last meeting, the codec discussion was deferred at the request of one company and with no reason offered.  It was delayed so late that people, such as my colleague, who had flown in for this discussion had already arrived when it was deferred.
>> 
>> This time, we have late-breaking news which is missing important details, warrants significant preparatory discussion before the meeting, and you have justified requests for time from multiple companies, and you go ahead?
> 
> I am very sympathetic with the plight of people who don't have time to analyze the new information provided. Believe me, we did the best we could to make it available earlier - but as you know, it is not possible to announce a deal until the deal has actually been signed.
> 
> At the last meeting, we knew that this was likely to happen, but we could (of course) not breathe a word about it - it was clear from the traffic on the mailing list and the arguments being fielded in presentations that in the absence of information about the agreement, our assertions about the IPR situation of VP8 would simply not be taken at face value. This was the reason we requested a delay at that time.
> 
> At this meeting, we believe the important cards are on the table:

The license, Harald; it is not yet available.  The license and licensors.  The price is only one aspect of the license, as I am sure you understand.

Even without this license, this announcement represents a significant change, and people need time to discuss and understand it.

> H.264 is still a royalty-required codec in all its profiles, and has many patent holders insisting on royalties being paid both outside and inside the MPEG-LA patent pool; VP8 is still a codec where all the IPR holders that have made declarations have declared their willingness to license on a royalty free basis (either directly or via Google).

I think someone has already gently pointed out an existing suit.

> 
> We appreciate the need to have time to evaluate the specific words of the license statements that are forthcoming, and the need for the people who haven't made their IPR declarations over the last couple of years of discussion to do so within the next couple of weeks - but we do think that it is important to use the face to face time that we have here in Orlando to lay to rest any *other* issues than the licensing terms and other issues derived from Google's announcement.

I am not sure we can have a reasoned consideration of 'other issues derived' at such short notice.  

Look, I'd like our discussions and decisions to be informed and considered, and there simply isn't time for either.

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

David Singer
Multimedia and Software Standards, Apple Inc.


From ted.ietf@gmail.com  Tue Mar 12 12:26: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 F194811E80E2 for ; Tue, 12 Mar 2013 12:26:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.586
X-Spam-Level: 
X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.014,  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 YXPhnfRJCaQb for ; Tue, 12 Mar 2013 12:26:41 -0700 (PDT)
Received: from mail-ia0-x22c.google.com (mail-ia0-x22c.google.com [IPv6:2607:f8b0:4001:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABC511E80D5 for ; Tue, 12 Mar 2013 12:26:41 -0700 (PDT)
Received: by mail-ia0-f172.google.com with SMTP id l29so200513iag.3 for ; Tue, 12 Mar 2013 12:26:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=fcw4g5pPlVjzDA+wsGcmuxKEXKaKVRZJbfxzXRn0gSg=; b=kYrWGYs6bvqlI7IMicTYpRaqxqJzb6UtW/0QBq7FeJX2E+OjLCjHtwMdJ97wC9+atz +zj1dSkFV5Bi2N/Q4Yru+Nbv0QRrSjKM9rrJuWxFB2qJ6zrv6aLm2uWSarM4kZaYuXbM /MXBLs8E5tWCn1IfN8//VTklvRZAZhD6PyTENohiOga8UnrPZAFhs3QXXXUUIZdBJ+Ee VwkanMFEDJN2oJUrhmbDXGPg78P4DJWo1ki/p+Zj+Rrae4hoCs44enA5RGVNvPHv6Y58 hPMww24PlxLZd3/quVZrWwcDUPAEYkUugPt0jcAMurQlFcLlLK2vI8NELxj6h+znzEKF 6fDw==
MIME-Version: 1.0
X-Received: by 10.50.88.199 with SMTP id bi7mr12921916igb.70.1363116400915; Tue, 12 Mar 2013 12:26:40 -0700 (PDT)
Received: by 10.43.135.202 with HTTP; Tue, 12 Mar 2013 12:26:40 -0700 (PDT)
In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AA2653BC5E@XMB106BCNC.rim.net>
References: <513F68C0.4010106@ericsson.com>   <92D0D52F3A63344CA478CF12DB0648AA2653BC5E@XMB106BCNC.rim.net>
Date: Tue, 12 Mar 2013 15:26:40 -0400
Message-ID: 
From: Ted Hardie 
To: Gaelle Martin-Cocher 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Stuart Cheshire , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 19:26:42 -0000

On Tue, Mar 12, 2013 at 2:37 PM, Gaelle Martin-Cocher
 wrote:
>
> [gmc] so why was those technical aspects not discussed at the prior
> meeting?

Frankly, it probably could have.  We can't go back and fix that now,
unfortunately.

>Can there just be a technical discussion with no questions?
>

The focus will be technical discussion.  Questions on the technical
aspects are, of course, in scope there.

regards,

Ted Hardie

From prvs=0783138e01=gmartincocher@blackberry.com  Tue Mar 12 12:30: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 51CD421F8632 for ; Tue, 12 Mar 2013 12:30:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.15
X-Spam-Level: 
X-Spam-Status: No, score=-5.15 tagged_above=-999 required=5 tests=[AWL=0.053,  BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 U7JFbGiIYORR for ; Tue, 12 Mar 2013 12:30:34 -0700 (PDT)
Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 867C321F8623 for ; Tue, 12 Mar 2013 12:30:34 -0700 (PDT)
X-AuditID: 0a41282f-b7fa06d000002431-7d-513f824d7c8c
Received: from XCT106CNC.rim.net (xct106cnc.rim.net [10.65.161.206]) by mhs060cnc.rim.net (SBG) with SMTP id C4.40.09265.D428F315; Tue, 12 Mar 2013 14:30:21 -0500 (CDT)
Received: from XCT115CNC.rim.net (10.65.161.215) by XCT106CNC.rim.net (10.65.161.206) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 12 Mar 2013 15:30:21 -0400
Received: from XMB106BCNC.rim.net ([fe80::99b8:8d0e:cdcd:c00d]) by XCT115CNC.rim.net ([::1]) with mapi id 14.02.0328.009; Tue, 12 Mar 2013 15:30:21 -0400
From: Gaelle Martin-Cocher 
To: Ted Hardie 
Thread-Topic: [rtcweb] Video Codec discussion in Thursday agenda slot
Thread-Index: AQHOH0jpubeezyLlMka1Nd5JzNGBEZiintGAgAAFyAD//718IIAAUXEA//+9DYA=
Date: Tue, 12 Mar 2013 19:30:20 +0000
Message-ID: <92D0D52F3A63344CA478CF12DB0648AA2653BE76@XMB106BCNC.rim.net>
References: <513F68C0.4010106@ericsson.com>   <92D0D52F3A63344CA478CF12DB0648AA2653BC5E@XMB106BCNC.rim.net> 
In-Reply-To: 
Accept-Language: fr-FR, en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.160.249]
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBKsWRmVeSWpSXmKPExsXC5bjwnK5vk32gwfknxhbH7tRYrP3Xzm4x v/8ji0XjXDsHFo+tJ3+weeycdZfdY8mSn0wBzFENjDZJiSVlwZnpefp2Nol5efkliSWpCimp xcm2Sj6p6Yk5CgFFmWWJyZUKLpnFyTmJmbmpRUoKmSm2SiZKCgU5icmpual5JbZKiQUFqXkp SnZcChjABqgsM08hNS85PyUzL91WyTPYX9fCwtRS11DJTjehkyfj1utXrAVzOSo2935nbWA8 y9bFyMkhIWAi8WrbA2YIW0ziwr31QHEuDiGBVYwSjRePMkI4Kxkl+p69ZIJw5jJK3N90mAmk hU3AUuL/qz0sILaIgLLE3is7wMYyCxRI7DqxBqxGWMBF4taLZUwQNa4Sb5/OYISw/SRmPNvE DmKzCKhKND48DmbzCnhKLDw3DWrzGiaJV3faWUESnAKBEq/uHgBaxsHBKKAicfJpOMQucYlb T+YzQbwgILFkz3mod0QlXj7+xwphK0rsfXaUCaJeT+LG1ClQd2pLLFv4mhlir6DEyZlPwH4R EtCUOPniHOMERolZSFbMQtI+C0n7LCTtCxhZVjEK5mYUG5gZJOcl6xVl5urlpZZsYgQnHQ39 HYxv31scYhTgYFTi4WUstg8UYk0sK67MPcQowcGsJML71xcoxJuSWFmVWpQfX1Sak1p8iNEV GEITmaW4k/OBCTGvJN7YwAA3R0mcVyRQNFBIIB2YyLJTUwtSi2DmMHFwguzhkhIpBqaj1KLE 0pKMeFDSjC8Gpk2pBkbZ1V8N9odXZbtGFhg/DG+79fJNZ8Ly2vijZbt/yz34VMd2zNIou2XB bQupksObXjw8NulF+owHFpNnqXa8V/xkFPDq5t7EDzYSaoyp9Q3d3kJdWxZ//bM0QWuOT83K wtXmG+0Fet0+nS6ZpL/qk8+7ivzlAQWzT9wPtzCJqZhxc64/Q86ziVuUWIozEg21mIuKEwGZ 7TYLewMAAA==
Cc: Stuart Cheshire , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 19:30:35 -0000

Thanks Ted for your clarifications
Though I am not sure we are on the same page.
Technical questions are in scope for sure.

What I was asking is that there would not be the question on mandating a vid=
eo codec - that is, this question/the question on MTI to be deferred.

Sincerely,
Ga=EBlle

-----Original Message-----
From: Ted Hardie [mailto:ted.ietf@gmail.com] 
Sent: Tuesday, March 12, 2013 3:27 PM
To: Gaelle Martin-Cocher
Cc: David Singer; Stuart Cheshire; rtcweb@ietf.org
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot

On Tue, Mar 12, 2013 at 2:37 PM, Gaelle Martin-Cocher  wrote:
>
> [gmc] so why was those technical aspects not discussed at the prior 
> meeting?

Frankly, it probably could have.  We can't go back and fix that now, unfortu=
nately.

>Can there just be a technical discussion with no questions?
>

The focus will be technical discussion.  Questions on the technical aspects=
 are, of course, in scope there.

regards,

Ted Hardie

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From ted.ietf@gmail.com  Tue Mar 12 12:32: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 B5A1911E80E0 for ; Tue, 12 Mar 2013 12:32:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.586
X-Spam-Level: 
X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.014,  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 qhEev437xDPq for ; Tue, 12 Mar 2013 12:32:04 -0700 (PDT)
Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id DEDD911E80D5 for ; Tue, 12 Mar 2013 12:32:03 -0700 (PDT)
Received: by mail-ie0-f180.google.com with SMTP id bn7so310693ieb.39 for ; Tue, 12 Mar 2013 12:32:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=UOFC0+JjaNhLbC6VxDQoAV+mH50i6ObvkwgkNfyYHys=; b=cMiwxu1Md1h73qU0U8DWrz6fmo+EL3IuYXvvP+UgKaVhXoKs0xMhaYSYol+g9XG/NO 0DIYTRdSrE5jyIMB6dhntbVq++KaYnPXgyTT0Es+XDlo7dcpRnlw7cghX8eFXRr4/iGs Iu+vE6BKGPz8+HhHORxD8tI1zs/F7kESg0qlYmjVftpvkefXtAKnMb2ugyRA5Kcb5kSD JsemIOmriRhh9n7ZU+XxxHeBrmiFRKHYB5bzajSKm2jvDOXohM4tIY58NJprcQxg+iR3 8Ff1B06QtNqjcDym7iwvPYX0s49xgCAPms3eUACCqzGuA94l23zvbe4BEfZ/MY2Yjzu6 HWLg==
MIME-Version: 1.0
X-Received: by 10.50.88.199 with SMTP id bi7mr12940732igb.70.1363116723552; Tue, 12 Mar 2013 12:32:03 -0700 (PDT)
Received: by 10.43.135.202 with HTTP; Tue, 12 Mar 2013 12:32:03 -0700 (PDT)
In-Reply-To: 
References: <513F68C0.4010106@ericsson.com>  <513F7745.3020302@alvestrand.no> 
Date: Tue, 12 Mar 2013 15:32:03 -0400
Message-ID: 
From: Ted Hardie 
To: David Singer 
Content-Type: text/plain; charset=ISO-8859-1
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 19:32:04 -0000

On Tue, Mar 12, 2013 at 2:50 PM, David Singer  wrote:
>
> Look, I'd like our discussions and decisions to be informed and
> considered, and there simply isn't time for either.
>

The obverse is that we should use the high bandwidth time we have here
to have to what discussions we can have; it seemed to Magnus, me, and
the chairs that the technical discussion fell into that category.

regards,

Ted Hardie

From singer@apple.com  Tue Mar 12 12:33: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 7582911E80E0 for ; Tue, 12 Mar 2013 12:33:10 -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 5yzc425zBXIA for ; Tue, 12 Mar 2013 12:33:09 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1C411E80D5 for ; Tue, 12 Mar 2013 12:33:07 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MJK00DVCBMYNNL0@mail-out.apple.com> for rtcweb@ietf.org; Tue, 12 Mar 2013 12:33:07 -0700 (PDT)
X-AuditID: 11807158-b7fa36d000006cd2-c6-513f82f3b710
Received: from cardamom.apple.com (cardamom.apple.com [17.128.115.94]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay5.apple.com (Apple SCV relay) with SMTP id 73.47.27858.3F28F315; Tue, 12 Mar 2013 12:33:07 -0700 (PDT)
Received: from [17.153.105.92] by cardamom.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MJK00CNHBN0WF60@cardamom.apple.com> for rtcweb@ietf.org; Tue, 12 Mar 2013 12:33:07 -0700 (PDT)
From: David Singer 
In-reply-to: 
Date: Tue, 12 Mar 2013 12:33:00 -0700
Message-id: <1BF51E01-AE8A-4DCF-82B9-7C8AE95A3C6E@apple.com>
References: <513F68C0.4010106@ericsson.com>   <92D0D52F3A63344CA478CF12DB0648AA2653BC5E@XMB106BCNC.rim.net> 
To: Ted Hardie 
X-Mailer: Apple Mail (2.1499)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FAcp/u5yT7QYOonDou1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVceDqX6aCyewVPUuvsTYwXmXtYuTkkBAwkVj84TwzhC0mceHe erYuRi4OIYGJTBIN0x4zQzgtTBLfF59jAaliFtCR6P3+DSjBwcEroCcxaX8QSFhYwEVi6Z3l YCVsAqoSD+YcYwSxOQWCJRYdb2QHsVmA4s8+PGECmcks0MIo8erKRiaImdoST95dYIWYaSOx d1UExN41TBI7vl8HGyQioCyx98oONohLZSVWTO1lmsAoMAvJSbMQTpqFZOoCRuZVjAJFqTmJ laZ6iQUFOal6yfm5mxjBgVcYsYPx/zKrQ4wCHIxKPLwSafaBQqyJZcWVuYcYJTiYlUR4//oC hXhTEiurUovy44tKc1KLDzFKc7AoifNmBdgGCgmkJ5akZqemFqQWwWSZODilGhg3Nwb9j/aM fffS2iWh396415b7755thqf90y68bpnYeMpzHcvLi++27Miti+LS3ip6q0frwnS9KN45RYZl n84cX2sV/927bhtPVUncwfpbjQs9BEKNfhjMeDD1qROL9A2Xsl+GwvJNpSrMEy932E+YwWpq q5yyad1hs82dj/Vl1te+mmpq6aLEUpyRaKjFXFScCADZmTWbOAIAAA==
Cc: Stuart Cheshire , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 19:33:10 -0000

On Mar 12, 2013, at 12:26 , Ted Hardie  wrote:

> On Tue, Mar 12, 2013 at 2:37 PM, Gaelle Martin-Cocher
>  wrote:
>> 
>> [gmc] so why was those technical aspects not discussed at the prior
>> meeting?
> 
> Frankly, it probably could have.  We can't go back and fix that now,
> unfortunately.
> 
>> Can there just be a technical discussion with no questions?
>> 
> 
> The focus will be technical discussion.  Questions on the technical
> aspects are, of course, in scope there.


OK, to be clear, 

* I am totally in favor of people understanding the technologies on offer.
* The decision rests on (at least) late-breaking news, and unavailable information, and I am opposed to any move to get a formal decision for a mandatory video codec at the meeting.


David Singer
Multimedia and Software Standards, Apple Inc.


From ted.ietf@gmail.com  Tue Mar 12 12:39: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 5BC7B11E810D for ; Tue, 12 Mar 2013 12:39:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.587
X-Spam-Level: 
X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.013,  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 yGMNT4iz4AUt for ; Tue, 12 Mar 2013 12:39:32 -0700 (PDT)
Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 67D6921F8A48 for ; Tue, 12 Mar 2013 12:39:32 -0700 (PDT)
Received: by mail-ie0-f180.google.com with SMTP id bn7so325953ieb.25 for ; Tue, 12 Mar 2013 12:39:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wKiwjflIiz/cuytjrO8hJ7xvWhwVjij9TGG4LCCjuxY=; b=EV2yjm/gWsTey2g4UyJ+UxN3Uyhl3rU1046JZ0wVWVrgZ1TkkksnObUfwuyu6YiYEe gLVjLaZMJZJZa499SC/k/hKuwRYpKCIPYE6sXleyA9RQ5MZr5ysdMR/t3/ItSIFQvC0j 3pUeRMvUdas0LgASVHzlWn3jAS/VfUqlJtXqWATPWtxtej3js39S/0m0fHcf9mVHu4mP tETtP+6ZVa9xTJE3aiGdsYeJ9QNnmBVeOkn/YpSXGJXCw/Wmo36Vh1Ol05dLyTc4dugn 1jIR0WACld7CE41ie3jq0vlnT6UXjtMD9xdEP+vwBhCOs40qW5n9N5eR1CIqgaSP8xRW 2bJA==
MIME-Version: 1.0
X-Received: by 10.50.36.169 with SMTP id r9mr12955998igj.96.1363117167365; Tue, 12 Mar 2013 12:39:27 -0700 (PDT)
Received: by 10.43.135.202 with HTTP; Tue, 12 Mar 2013 12:39:27 -0700 (PDT)
In-Reply-To: <1BF51E01-AE8A-4DCF-82B9-7C8AE95A3C6E@apple.com>
References: <513F68C0.4010106@ericsson.com>   <92D0D52F3A63344CA478CF12DB0648AA2653BC5E@XMB106BCNC.rim.net>  <1BF51E01-AE8A-4DCF-82B9-7C8AE95A3C6E@apple.com>
Date: Tue, 12 Mar 2013 15:39:27 -0400
Message-ID: 
From: Ted Hardie 
To: David Singer 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Stuart Cheshire , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 19:39:33 -0000

On Tue, Mar 12, 2013 at 3:33 PM, David Singer  wrote:
>

> * The decision rests on (at least) late-breaking news, and
>unavailable information, and I am opposed to any move to get a >formal decision for a mandatory video codec at the meeting.
>
>

Hi David, Gaelle,

I am glad that we all agree that the technical discussion is needed
and can go forward.

On the IPR issue, my understanding is that Robert will call for a
sense of the room on who believes that they have enough data now to
make decision and, if not, what exactly is needed.  That will occur
*before* any discussion on which will be chosen.  I am confident he is
aware of the discussion on the list to date from those who are already
indicating their preferences to wait for more information, but I have
cc'ed him explicitly on this message so he can confirm.

As noted before, none of the chairs will be making the calls related
to the codec question.

regards,

Ted Hardie

From mcoban@qti.qualcomm.com  Tue Mar 12 13:05: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 10FF311E8165 for ; Tue, 12 Mar 2013 13:05:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 RsuiCRYyEjAn for ; Tue, 12 Mar 2013 13:05:43 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 4056A11E8139 for ; Tue, 12 Mar 2013 13:05:41 -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=1363118741; x=1394654741; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Mk3j8FD4hdMqN3W/uLVxvQ5yGtpLlxfp+Va2dC3LBnE=; b=d+P+rmtcUCEtLgFCDszzDFrl0gCnTw9kyXUoQK2+cRUrynDRGU89ngQp oMbxymUlXFKaSJM288me8UQhQ6SDcE/6Pvfl8B8uoGQc1OLCG324qhZc7 9p04pEyeuPjt297bWTPOFFn8+9EZls/o1AZiExbmWGoTbN3mXQQslT9ik U=;
X-IronPort-AV: E=Sophos;i="4.84,832,1355126400"; d="scan'208";a="28874875"
Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 12 Mar 2013 13:05:34 -0700
X-IronPort-AV: E=Sophos;i="4.84,832,1355126400"; d="scan'208";a="504133730"
Received: from nasanexhc14.na.qualcomm.com ([172.30.48.23]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 12 Mar 2013 13:05:34 -0700
Received: from NASANEXD01A.na.qualcomm.com ([169.254.1.136]) by nasanexhc14.na.qualcomm.com ([172.30.48.23]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 13:05:34 -0700
From: "Coban, Muhammed" 
To: David Singer 
Thread-Topic: [rtcweb] Video Codec discussion in Thursday agenda slot
Thread-Index: AQHOH0jsHDBBu6vBckanQqZgteXncJii0RyAgAAFxwCAAAEbgIAADdMAgAABxQD//5EhUA==
Date: Tue, 12 Mar 2013 20:05:34 +0000
Message-ID: 
References: <513F68C0.4010106@ericsson.com>   <92D0D52F3A63344CA478CF12DB0648AA2653BC5E@XMB106BCNC.rim.net>  <1BF51E01-AE8A-4DCF-82B9-7C8AE95A3C6E@apple.com>
In-Reply-To: <1BF51E01-AE8A-4DCF-82B9-7C8AE95A3C6E@apple.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.30.39.5]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 20:05:45 -0000

I also favor having the technical discussions in this meeting and postponin=
g the decision to a later time.

Muhammed Coban
Qualcomm Inc

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 David Singer
Sent: Tuesday, March 12, 2013 12:33 PM
To: Ted Hardie
Cc: Stuart Cheshire; rtcweb@ietf.org
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot


On Mar 12, 2013, at 12:26 , Ted Hardie  wrote:

> On Tue, Mar 12, 2013 at 2:37 PM, Gaelle Martin-Cocher=20
>  wrote:
>>=20
>> [gmc] so why was those technical aspects not discussed at the prior=20
>> meeting?
>=20
> Frankly, it probably could have.  We can't go back and fix that now,=20
> unfortunately.
>=20
>> Can there just be a technical discussion with no questions?
>>=20
>=20
> The focus will be technical discussion.  Questions on the technical=20
> aspects are, of course, in scope there.


OK, to be clear,=20

* I am totally in favor of people understanding the technologies on offer.
* The decision rests on (at least) late-breaking news, and unavailable info=
rmation, and I am opposed to any move to get a formal decision for a mandat=
ory video codec at the meeting.


David Singer
Multimedia and Software Standards, Apple Inc.

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

From rjsparks@nostrum.com  Tue Mar 12 13:16: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 BDFEF21F8C99 for ; Tue, 12 Mar 2013 13:16:52 -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 vH4gubxNTRkG for ; Tue, 12 Mar 2013 13:16:52 -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 29B6021F8C98 for ; Tue, 12 Mar 2013 13:16:52 -0700 (PDT)
Received: from dhcp-5232.meeting.ietf.org (dhcp-5232.meeting.ietf.org [130.129.82.50]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2CKGjSN005180 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 12 Mar 2013 15:16:45 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
Message-ID: <513F8D2D.2070502@nostrum.com>
Date: Tue, 12 Mar 2013 16:16:45 -0400
From: Robert Sparks 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Ted Hardie 
References: <513F68C0.4010106@ericsson.com>   <92D0D52F3A63344CA478CF12DB0648AA2653BC5E@XMB106BCNC.rim.net>  <1BF51E01-AE8A-4DCF-82B9-7C8AE95A3C6E@apple.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 130.129.82.50 is authenticated by a trusted mechanism)
Cc: Stuart Cheshire , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 20:16:52 -0000

On 3/12/13 3:39 PM, Ted Hardie wrote:
> On Tue, Mar 12, 2013 at 3:33 PM, David Singer  wrote:
>> * The decision rests on (at least) late-breaking news, and
>> unavailable information, and I am opposed to any move to get a >formal decision for a mandatory video codec at the meeting.
>>
>>
> Hi David, Gaelle,
>
> I am glad that we all agree that the technical discussion is needed
> and can go forward.
>
> On the IPR issue, my understanding is that Robert will call for a
> sense of the room on who believes that they have enough data now to
> make decision and, if not, what exactly is needed.
I do not believe we can call for consensus on this question at this meeting.

We _do_ need to have the technical discussions.

I am planning to take the sense of the room using the questions that have
already been published. These are not going to make a decision on their
own, but may help with reading consensus when we do make that call.

I do expect the working group to have this consensus call soon. As the 
chairs
have mentioned earlier in the thread, we hope to make this call on the 
list in
the next few weeks, ->well before the IETF87 meeting in Berlin<-. We 
understand
there needs to be some lead time.

RjS

>   That will occur
> *before* any discussion on which will be chosen.  I am confident he is
> aware of the discussion on the list to date from those who are already
> indicating their preferences to wait for more information, but I have
> cc'ed him explicitly on this message so he can confirm.
>
> As noted before, none of the chairs will be making the calls related
> to the codec question.
>
> regards,
>
> Ted Hardie


From btv1==7831efcc49b==HKaplan@acmepacket.com  Tue Mar 12 12:37: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 5FE9411E80E6 for ; Tue, 12 Mar 2013 12:37:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.441
X-Spam-Level: 
X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.002,  BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjGHNB3p6wgz for ; Tue, 12 Mar 2013 12:37:41 -0700 (PDT)
Received: from mx2.acmepacket.com (mx2.acmepacket.com [216.41.24.99]) by ietfa.amsl.com (Postfix) with ESMTP id D9BDA11E80D5 for ; Tue, 12 Mar 2013 12:37:40 -0700 (PDT)
X-ASG-Debug-ID: 1363117059-03fc21725feebe20001-4f8tJD
Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx2.acmepacket.com with ESMTP id A6ogzpDoTvdOtb49 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Mar 2013 15:37:39 -0400 (EDT)
X-Barracuda-Envelope-From: HKaplan@acmepacket.com
Received: from MAIL2.acmepacket.com ([169.254.2.222]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Tue, 12 Mar 2013 15:37:39 -0400
From: Hadriel Kaplan 
To: Harald Alvestrand 
Thread-Topic: [rtcweb] I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
X-ASG-Orig-Subj: Re: [rtcweb] I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
Thread-Index: AQHOH1kNj2zs6HGfLE2wgqDokvjqiw==
Date: Tue, 12 Mar 2013 19:37:38 +0000
Message-ID: 
References: <45A697A8FFD7CF48BCF2BE7E106F06040901B274@xmb-rcd-x04.cisco.com> <513E146D.4060009@alvestrand.no>
In-Reply-To: <513E146D.4060009@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <00D57D0C278B7649B96F4C13EABB59EC@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21]
X-Barracuda-Start-Time: 1363117059
X-Barracuda-Encrypted: AES128-SHA
X-Barracuda-URL: http://216.41.24.99:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at acmepacket.com
X-Barracuda-Spam-Score: 0.41
X-Barracuda-Spam-Status: No, SCORE=0.41 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=SUBJECT_FUZZY_TION
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.125017 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.41 SUBJECT_FUZZY_TION     Attempt to obfuscate words in Subject:
Cc: "" 
Subject: Re: [rtcweb] I-D Action:	draft-hutton-rtcweb-nat-firewall-considerations-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, 12 Mar 2013 20:22:56 -0000

On Mar 11, 2013, at 1:29 PM, Harald Alvestrand  wrote=
:

> On 03/11/2013 06:04 PM, Reinaldo Penno (repenno) wrote:
>> Hello,
>>=20
>> Why not use Port Control Protocol (PCP) to control Firewalls and NATs
>> explicitly?
> We can switch to that as soon as 100% of firewalls support it - until the=
n, we have to be able to rely on other techniques.


Not to contradict with your point, but to pile on it...
Even if 100% of the Firewalls were to support PCP, you'd still want to do S=
TUN/TURN/ICE methinks, because=20

1) you never know that your local Firewall is the *only* Firewall-ish thing=
 between you and the public Internet or some network reachable by both part=
ies.  This problem already happens with UPnP and NAT-PMP today, and has bee=
n noted before in BEHAVE or MMUSIC, I think.=20

2) There's a big difference between 100% of Firewalls implementing PCP, and=
 it being actually enabled/turned-on in 100% of them.

3) you don't know if the IP path across the Internet works for a given addr=
ess family - this has been given as the reason STUN/ICE needs to be require=
d for v4/v6 dual-stack implementations, to test reachability across the IPv=
6 Internet before trying to use it; regardless of NATs/Firewalls.

-hadriel


From magnus.westerlund@ericsson.com  Tue Mar 12 13:29: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 57EFD11E8163 for ; Tue, 12 Mar 2013 13:29:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.195
X-Spam-Level: 
X-Spam-Status: No, score=-106.195 tagged_above=-999 required=5 tests=[AWL=0.054, 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 79HqKBav0j56 for ; Tue, 12 Mar 2013 13:29:09 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 97F6911E8108 for ; Tue, 12 Mar 2013 13:29:09 -0700 (PDT)
X-AuditID: c1b4fb30-b7f0d6d000007e61-92-513f9014ae3a
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E2.05.32353.4109F315; Tue, 12 Mar 2013 21:29:08 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Tue, 12 Mar 2013 21:29:08 +0100
Message-ID: <513F9011.4040900@ericsson.com>
Date: Tue, 12 Mar 2013 16:29:05 -0400
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMJMWRmVeSWpSXmKPExsUyM+Jvja7IBPtAgwML1S3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvtDE1gKJnFUbLuwkrWB8TFbFyMnh4SAicS/9lXMELaYxIV7 64HiXBxCAicZJdbd/ckK4SxnlGhe+xasildAW2L/itWsIDaLgKrE6s3fwCaxCVhI3PzRCGaL CgRL/Hx1hgWiXlDi5MwnYLaIgLrE5YcX2EFsYQEtiU29d5kgNktKbHnRDhZnFtCTmHK1hRHC lpdo3jobbK8Q0N6Gpg7WCYz8s5CMnYWkZRaSlgWMzKsY2XMTM3PSy803MQID6uCW3wY7GDfd FzvEKM3BoiTOG+56IUBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY9sC6ekZPZ6Notl3xIVn +6uJ5f7hP+zYd+jIJbZ3i8Kf5/awi/3m86v6/225cHfxuhcTgktF92avLPmlcuPxn/P7s5Vv Pf08c6nAgt4ZTjc1Ko5NW7Tot/qqwyrFatkM6+7uPPSkcMFl13U7tnw7kjrx6I1Je2931K3t OnFC+ahDQqTTRgYef0ElluKMREMt5qLiRAAGpmp49gEAAA==
Subject: [rtcweb] Datachannel adoption confirmation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 20:29:10 -0000

WG,

In today's session we had a call for adopting as WG draft a proposal as
the starting point for the Data channel management. There was a strong
consensus in the meeting to pick draft-jesup-rtcweb-data-protocol-04 as
that document.

This is the confirmation on the mailing list, where people who where not
present may express their position of which of the three proposals:

- draft-jesup-rtcweb-data-protocol-04
- draft-thomson-rtcweb-data-00
- draft-marcon-rtcweb-data-channel-management-00

Please provide any additional input by 19th of March.

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 ted.ietf@gmail.com  Tue Mar 12 13:33: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 8F2A711E8163 for ; Tue, 12 Mar 2013 13:33:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.587
X-Spam-Level: 
X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.013,  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 PK9Kc5p7IYSh for ; Tue, 12 Mar 2013 13:33:13 -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 09BE821F8C8C for ; Tue, 12 Mar 2013 13:33:04 -0700 (PDT)
Received: by mail-ie0-f177.google.com with SMTP id 16so405171iea.22 for ; Tue, 12 Mar 2013 13:33:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=tYlQLLtT+jfSLg3rLj0MLcAVFWYwit6txKHb3oGgFDQ=; b=VdUafLIPjEi2PJ4W/8omnTIQZfrXq7TXokOkzBxcukMMrW22TnI8lagq7EbtJCpRoY c65MMawxou4aNlf5zurW4egFJQ/vTgS5fLcXuqJG35eEwn2Bqf2WjYUYrysEZ0VUC5NF 2c+TXLgCEfI55T7vq1d9xG77SBrfGKz+iSHoFtLdcmrxelnYQeBHIr/WIWI/GyTYKk7O q+Moeou5BBAKoPKIOyQnvndkNpmX5TucJIh+btDp8RXkNkp8ejUGfIznxZLC7uyxWfA2 S23yQZW2k9ywOogHPRW5c6JXRIcPNiMQkj+KXievBQOm02nAGsEBveY/2FyW/ok2/23X 73eg==
MIME-Version: 1.0
X-Received: by 10.43.88.134 with SMTP id ba6mr10685150icc.18.1363120384692; Tue, 12 Mar 2013 13:33:04 -0700 (PDT)
Received: by 10.43.135.202 with HTTP; Tue, 12 Mar 2013 13:33:04 -0700 (PDT)
In-Reply-To: <513F8D2D.2070502@nostrum.com>
References: <513F68C0.4010106@ericsson.com>   <92D0D52F3A63344CA478CF12DB0648AA2653BC5E@XMB106BCNC.rim.net>  <1BF51E01-AE8A-4DCF-82B9-7C8AE95A3C6E@apple.com>  <513F8D2D.2070502@nostrum.com>
Date: Tue, 12 Mar 2013 16:33:04 -0400
Message-ID: 
From: Ted Hardie 
To: Robert Sparks 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Stuart Cheshire , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 20:33:13 -0000

Thanks, Robert, for this clarification.

Ted

On Tue, Mar 12, 2013 at 4:16 PM, Robert Sparks  wrote:
> On 3/12/13 3:39 PM, Ted Hardie wrote:
>>
>> On Tue, Mar 12, 2013 at 3:33 PM, David Singer  wrote:
>>>
>>> * The decision rests on (at least) late-breaking news, and
>>> unavailable information, and I am opposed to any move to get a >formal
>>> decision for a mandatory video codec at the meeting.
>>>
>>>
>> Hi David, Gaelle,
>>
>> I am glad that we all agree that the technical discussion is needed
>> and can go forward.
>>
>> On the IPR issue, my understanding is that Robert will call for a
>> sense of the room on who believes that they have enough data now to
>> make decision and, if not, what exactly is needed.
>
> I do not believe we can call for consensus on this question at this meeting.
>
> We _do_ need to have the technical discussions.
>
> I am planning to take the sense of the room using the questions that have
> already been published. These are not going to make a decision on their
> own, but may help with reading consensus when we do make that call.
>
> I do expect the working group to have this consensus call soon. As the
> chairs
> have mentioned earlier in the thread, we hope to make this call on the list
> in
> the next few weeks, ->well before the IETF87 meeting in Berlin<-. We
> understand
> there needs to be some lead time.
>
> RjS
>
>
>>   That will occur
>> *before* any discussion on which will be chosen.  I am confident he is
>> aware of the discussion on the list to date from those who are already
>> indicating their preferences to wait for more information, but I have
>> cc'ed him explicitly on this message so he can confirm.
>>
>> As noted before, none of the chairs will be making the calls related
>> to the codec question.
>>
>> regards,
>>
>> Ted Hardie
>
>

From btv1==7831efcc49b==HKaplan@acmepacket.com  Tue Mar 12 13:46: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 AF02721F8CCA for ; Tue, 12 Mar 2013 13:46:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.513
X-Spam-Level: 
X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086,  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 L4hEu3unuNDk for ; Tue, 12 Mar 2013 13:46:52 -0700 (PDT)
Received: from mx2.acmepacket.com (mx2.acmepacket.com [216.41.24.99]) by ietfa.amsl.com (Postfix) with ESMTP id 31DF021F8CC9 for ; Tue, 12 Mar 2013 13:46:52 -0700 (PDT)
X-ASG-Debug-ID: 1363121211-03fc217260eeff60001-4f8tJD
Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx2.acmepacket.com with ESMTP id kQtIhMnxQp2wjBfV (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 12 Mar 2013 16:46:51 -0400 (EDT)
X-Barracuda-Envelope-From: HKaplan@acmepacket.com
Received: from MAIL2.acmepacket.com ([169.254.2.222]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Tue, 12 Mar 2013 16:46:51 -0400
From: Hadriel Kaplan 
To: "" 
Thread-Topic: Something to do on Thursday
X-ASG-Orig-Subj: Something to do on Thursday
Thread-Index: AQHOH2K4PKlqj6VJ2k2T8d8wvtASQw==
Date: Tue, 12 Mar 2013 20:46:49 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <917C65B2885BD248807530E4525CC01B@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21]
X-Barracuda-Start-Time: 1363121211
X-Barracuda-Encrypted: AES128-SHA
X-Barracuda-URL: http://216.41.24.99:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at acmepacket.com
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.125021 Rule breakdown below pts rule name              description ---- ---------------------- --------------------------------------------------
Subject: [rtcweb] Something to do on Thursday
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 20:46:52 -0000

I will probably be blasted for this, but I'm feeling Goofy...

If we need something else to talk about on Thursday's RTCWeb meeting slot i=
nstead of video codecs, we can have the SRTP keying discussion that has bee=
n delayed so far.  I believe there are slide sets already prepared for both=
 sides of the debate, and no IPR issues I know of.

-hadriel


From prvs=27833456df=gmartincocher@blackberry.com  Tue Mar 12 14:01: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 84FFB21F8CFE for ; Tue, 12 Mar 2013 14:01:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.161
X-Spam-Level: 
X-Spam-Status: No, score=-5.161 tagged_above=-999 required=5 tests=[AWL=0.042,  BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 uPEDTIE8cxVh for ; Tue, 12 Mar 2013 14:01:13 -0700 (PDT)
Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 96B2921F8CFB for ; Tue, 12 Mar 2013 14:01:10 -0700 (PDT)
X-AuditID: 0a412830-b7ef86d00000339d-ed-513f9788b636
Received: from XCT105CNC.rim.net (xct105cnc.rim.net [10.65.161.205]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id AE.85.13213.8879F315; Tue, 12 Mar 2013 16:00:57 -0500 (CDT)
Received: from XCT115CNC.rim.net (10.65.161.215) by XCT105CNC.rim.net (10.65.161.205) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 12 Mar 2013 17:00:56 -0400
Received: from XMB106BCNC.rim.net ([fe80::99b8:8d0e:cdcd:c00d]) by XCT115CNC.rim.net ([::1]) with mapi id 14.02.0328.009; Tue, 12 Mar 2013 17:00:56 -0400
From: Gaelle Martin-Cocher 
To: Robert Sparks , Ted Hardie 
Thread-Topic: [rtcweb] Video Codec discussion in Thursday agenda slot
Thread-Index: AQHOH0jpubeezyLlMka1Nd5JzNGBEZiintGAgAAFyAD//718IIAAUXEAgAABxQCAAAHOgIAACmyA///FsnA=
Date: Tue, 12 Mar 2013 21:00:54 +0000
Message-ID: <92D0D52F3A63344CA478CF12DB0648AA2653C29F@XMB106BCNC.rim.net>
References: <513F68C0.4010106@ericsson.com>   <92D0D52F3A63344CA478CF12DB0648AA2653BC5E@XMB106BCNC.rim.net>  <1BF51E01-AE8A-4DCF-82B9-7C8AE95A3C6E@apple.com>  <513F8D2D.2070502@nostrum.com>
In-Reply-To: <513F8D2D.2070502@nostrum.com>
Accept-Language: fr-FR, en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.160.249]
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrIKsWRmVeSWpSXmKPExsXC5bjwrG7ndPtAg6ZjfBbH7tRYXJvTyGax 9l87u8X8/o8sFo1z7RxYPbae/MHmsXPWXXaPJUt+MnnM2vmEJYAlqoHRJimxpCw4Mz1P384m MS8vvySxJFUhJbU42VbJJzU9MUchoCizLDG5UsElszg5JzEzN7VISSEzxVbJREmhICcxOTU3 Na/EVimxoCA1L0XJjksBA9gAlWXmKaTmJeenZOal2yp5BvvrWliYWuoaKtnpJnTyZPzr2cle 8EikouXkNKYGxgMCXYycHBICJhK9GzoYIWwxiQv31rN1MXJxCAm0M0n8/PiCHcJZySjx+uU0 KGcuo8SlOX2sIC1sApYS/1/tYQGxRQQ8Ja6e3MoMYjMLFEjsOrGGCcQWFnCRuPViGRNEjavE 26czGCHsJIl3C+6xgdgsAqoSU9uOg83kBZpz6stfVohlx5kluhfPACri4OAU0JaYPpUfxGQU UJE4+TQcYpW4xK0n85kgPhCQWLLnPDOELSrx8vE/VghbUWLvs6NMEPV6EjemTmGDsLUlli18 zQyxVlDi5MwnYK8ICWhKnHxxjnECo8QsJCtmIWmfhaR9FpL2BYwsqxgFczOKDcwMk/OS9Yoy c/XyUks2MYLTkIbBDsb37y0OMQpwMCrx8CZ32gcKsSaWFVfmHmKU4GBWEuH96wsU4k1JrKxK LcqPLyrNSS0+xOgKDKCJzFLcyfnAFJlXEm9sYICboyTOKxIoGigkkA5MY9mpqQWpRTBzmDg4 QfZwSYkUA5NRalFiaUlGPChlxhcDk6ZUA6NAZYLoyspXa+exbLdhUTlT275/+4apP9usi1+s 5Skyd1spf/vu66ucfFaCG6dYVbRLbfR5d8ejl+3j2cKumXFTlJNWydyO2b+wy3P+m/N7bbhv 517K5bqyQYTh7IUja2w1nleud9K7ten2qeenfhnkbjhZ9jV+vX2cbZyufWb4nbyf0tr/JKcr sRRnJBpqMRcVJwIALNaWXIQDAAA=
Cc: Stuart Cheshire , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 21:01:14 -0000

Thanks Rob, 

And I agree with Ted, that helps.
I may have missed the point that the consensus call will happen after this m=
eeting and before the berlin meeting.  I apologize for that. 
I want to clarify as well that I never asked to postponed the technical disc=
ussion.
Would it be suitable to set-up an adhoc meeting/call (after Orlando/before B=
erlin) when more information will be available so that legal experts can par=
ticipate, ask questions, ideally reach a consensus?
Resuming the technical discussion and having the final consensus call should=
 be much easier then.

Thank you
Sincerely,
Ga=EBlle


-----Original Message-----
From: Robert Sparks [mailto:rjsparks@nostrum.com] 
Sent: Tuesday, March 12, 2013 4:17 PM
To: Ted Hardie
Cc: David Singer; Gaelle Martin-Cocher; Stuart Cheshire; rtcweb@ietf.org
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot

On 3/12/13 3:39 PM, Ted Hardie wrote:
> On Tue, Mar 12, 2013 at 3:33 PM, David Singer  wrote:
>> * The decision rests on (at least) late-breaking news, and 
>> unavailable information, and I am opposed to any move to get a >formal de=
cision for a mandatory video codec at the meeting.
>>
>>
> Hi David, Gaelle,
>
> I am glad that we all agree that the technical discussion is needed 
> and can go forward.
>
> On the IPR issue, my understanding is that Robert will call for a 
> sense of the room on who believes that they have enough data now to 
> make decision and, if not, what exactly is needed.
I do not believe we can call for consensus on this question at this meeting.

We _do_ need to have the technical discussions.

I am planning to take the sense of the room using the questions that have al=
ready been published. These are not going to make a decision on their own, b=
ut may help with reading consensus when we do make that call.

I do expect the working group to have this consensus call soon. As the chair=
s have mentioned earlier in the thread, we hope to make this call on the lis=
t in the next few weeks, ->well before the IETF87 meeting in Berlin<-. We un=
derstand there needs to be some lead time.

RjS

>   That will occur
> *before* any discussion on which will be chosen.  I am confident he is 
> aware of the discussion on the list to date from those who are already 
> indicating their preferences to wait for more information, but I have 
> cc'ed him explicitly on this message so he can confirm.
>
> As noted before, none of the chairs will be making the calls related 
> to the codec question.
>
> regards,
>
> Ted Hardie


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From gonzalo.camarillo@ericsson.com  Tue Mar 12 14:07: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 B51BA11E810F for ; Tue, 12 Mar 2013 14:07:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.499
X-Spam-Level: 
X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 HmPhZC5M1UzZ for ; Tue, 12 Mar 2013 14:07:22 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A380911E80E9 for ; Tue, 12 Mar 2013 14:07:21 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f316d0000028db-26-513f99083d71
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 20.28.10459.8099F315; Tue, 12 Mar 2013 22:07:20 +0100 (CET)
Received: from ESESSMB207.ericsson.se ([169.254.7.163]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 22:07:19 +0100
From: Gonzalo Camarillo 
To: Gaelle Martin-Cocher 
Thread-Topic: [rtcweb] Video Codec discussion in Thursday agenda slot
Thread-Index: Ac4fZZTIyJfn2QDK+EyaL7qTXFvDuw==
Date: Tue, 12 Mar 2013 21:07:19 +0000
Message-ID: <5478BC3A860A8B4A87765D899FAAF3D4110704@ESESSMB207.ericsson.se>
References: <513F68C0.4010106@ericsson.com>   <92D0D52F3A63344CA478CF12DB0648AA2653BC5E@XMB106BCNC.rim.net>  <1BF51E01-AE8A-4DCF-82B9-7C8AE95A3C6E@apple.com>  <513F8D2D.2070502@nostrum.com> <92D0D52F3A63344CA478CF12DB0648AA2653C29F@XMB106BCNC.rim.net>
Accept-Language: en-US, es-ES
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.19]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+JvjS7HTPtAg/5XKhbH7tRYrPh7j9ni 2pxGNou1/9rZLRrn2jmwemw9+YPNY1bDWnaPnbPusnssWfKTyWPWzicsAaxRXDYpqTmZZalF +nYJXBkLb/9kKjjHXHHx+D/mBsY/TF2MnBwSAiYSH8/8Z4GwxSQu3FvP1sXIxSEkcIhRomnS J1YIZwmjxIklK4EyHBxsAhYSHavNQBpEBMwlFn77BtbALDCNUeL+xm1gk4QFXCSW3lnOAlHk KvH26QxGCFtPYvusx2CbWQRUJd7cfQhWwyvgLTF36nYWiGXtLBIT989kB0kwCshKvJs/nxXE ZhYQl7j1ZD7U2QISS/acZ4awRSVePv7HCmErSrQ/bWCEqNeRWLD7ExuErS2xbOFrZohlghIn Zz5hmcAoOgvJ2FlIWmYhaZmFpGUBI8sqRvbcxMyc9HLDTYzAODq45bfuDsZT50QOMUpzsCiJ 84a5XggQEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwBg2I/Zeeey+BMFJS169d9f++uxG/fop p0I92TjyzJpu8H94NEH4l8isLx6l86ZsO5669Dx/sNPNH1s/H7vM5S2cey1/XpX1nwZbQ2Z+ zvSbGmcXa6gs9V2pqir+iZkvz7XkqTJHxuSGzB0zpu1bsOKL0r2Xq8V95l3J/ax+4ui9W0tt Eov5LVcqsRRnJBpqMRcVJwIAuWuNoXECAAA=
Cc: Stuart Cheshire , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 21:07:22 -0000

Hi,=0A=
=0A=
> Would it be suitable to set-up an adhoc meeting/call (after=0A=
> Orlando/before Berlin) when more information will be available so=0A=
> that legal experts can participate, ask questions, ideally reach a=0A=
> consensus?=0A=
=0A=
so far, there are no plans to have any face-to-face meeting between=0A=
Orlando and Berlin. If needed, a virtual interim would of course be=0A=
easier to organize.=0A=
=0A=
Cheers,=0A=
=0A=
Gonzalo=0A=

From adam@nostrum.com  Tue Mar 12 14:09: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 49CBB21F8480 for ; Tue, 12 Mar 2013 14:09:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.57
X-Spam-Level: 
X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, 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 SLnZBenNbHP8 for ; Tue, 12 Mar 2013 14:09:19 -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 845AC21F8442 for ; Tue, 12 Mar 2013 14:09:19 -0700 (PDT)
Received: from dhcp-5033.meeting.ietf.org (dhcp-5033.meeting.ietf.org [130.129.80.51]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2CL9F76011080 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 12 Mar 2013 16:09:16 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <513F997B.50807@nostrum.com>
Date: Tue, 12 Mar 2013 17:09:15 -0400
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Magnus Westerlund 
References: <513F9011.4040900@ericsson.com>
In-Reply-To: <513F9011.4040900@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: pass (shaman.nostrum.com: 130.129.80.51 is authenticated by a trusted mechanism)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Datachannel adoption confirmation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 21:09:20 -0000

I strongly support the use of draft-jesup-rtcweb-data-protocol as the 
basis for a working group document to address this issue.

/a

On 3/12/13 16:29, Magnus Westerlund wrote:
> WG,
>
> In today's session we had a call for adopting as WG draft a proposal as
> the starting point for the Data channel management. There was a strong
> consensus in the meeting to pick draft-jesup-rtcweb-data-protocol-04 as
> that document.
>
> This is the confirmation on the mailing list, where people who where not
> present may express their position of which of the three proposals:
>
> - draft-jesup-rtcweb-data-protocol-04
> - draft-thomson-rtcweb-data-00
> - draft-marcon-rtcweb-data-channel-management-00
>
> Please provide any additional input by 19th of March.
>
> 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
> ----------------------------------------------------------------------
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From magnus.westerlund@ericsson.com  Tue Mar 12 14:18: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 2C2EF21F8B15 for ; Tue, 12 Mar 2013 14:18:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.199
X-Spam-Level: 
X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=0.050, 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 sS45fk42WSn9 for ; Tue, 12 Mar 2013 14:18:12 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3126721F8B13 for ; Tue, 12 Mar 2013 14:18:12 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f316d0000028db-9e-513f9b9337d9
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0F.F8.10459.39B9F315; Tue, 12 Mar 2013 22:18:11 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Tue, 12 Mar 2013 22:18:10 +0100
Message-ID: <513F9B90.4090802@ericsson.com>
Date: Tue, 12 Mar 2013 17:18:08 -0400
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Adam Roach 
References: <513F9011.4040900@ericsson.com> <513F997B.50807@nostrum.com>
In-Reply-To: <513F997B.50807@nostrum.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3RnfybPtAg6v/xCz2/F3EbrH2Xzu7 A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJWx89EXtoKZghWX5hxlaWDs5uti5OCQEDCR +NDj38XICWSKSVy4t56ti5GLQ0jgJKPEs73T2SGc5YwSW9d+YQap4hXQljj85TArSDOLgKrE rp3yIGE2AQuJmz8a2UBsUYFgiZ+vzrBAlAtKnJz5BMwWEVCUaDt8E2wMs4C6xJ3F59hBbGEB c4n589aC1QgJeEh0di1hBbE5BTQlvh6bwA5xnKTElhft7BC9ehJTrrYwQtjyEs1bZzND9GpL NDR1sE5gFJqFZPUsJC2zkLQsYGRexciem5iZk15uuIkRGKgHt/zW3cF46pzIIUZpDhYlcd4w 1wsBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhi5l/1drsOtcuz0L9P51e4PViQcTnZu9FEx 11csfCDRq3pj5eUTlQHbTs35WagkuXTi9+KXlW3bZHu7BDgZpKdrV5S4ysq5R1vv3iYX8mV+ BNPESeJqUuUTo4pPHdKSf/zsTlLl/Y5PiVOOf5rnULqDsbjNKnrufF111u9sAVZWpW68D8s/ 6SqxFGckGmoxFxUnAgAMrCpTIgIAAA==
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Datachannel adoption confirmation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 21:18:13 -0000

Adam,

To my knowledge you where in the meeting and thus you don't need to
restate any position. I don't want all the person that actually was in
the meeting to restate their position here.

Cheers

Magnus

On 2013-03-12 17:09, Adam Roach wrote:
> I strongly support the use of draft-jesup-rtcweb-data-protocol as the
> basis for a working group document to address this issue.
> 
> /a
> 
> On 3/12/13 16:29, Magnus Westerlund wrote:
>> WG,
>>
>> In today's session we had a call for adopting as WG draft a proposal as
>> the starting point for the Data channel management. There was a strong
>> consensus in the meeting to pick draft-jesup-rtcweb-data-protocol-04 as
>> that document.
>>
>> This is the confirmation on the mailing list, where people who where not
>> present may express their position of which of the three proposals:
>>
>> - draft-jesup-rtcweb-data-protocol-04
>> - draft-thomson-rtcweb-data-00
>> - draft-marcon-rtcweb-data-channel-management-00
>>
>> Please provide any additional input by 19th of March.
>>
>> 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
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 
> 


-- 

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 singer@apple.com  Tue Mar 12 15:05: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 0302121F8D10 for ; Tue, 12 Mar 2013 15:05:22 -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 AQMCuvYeg8ER for ; Tue, 12 Mar 2013 15:05:20 -0700 (PDT)
Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7B66521F8D0A for ; Tue, 12 Mar 2013 15:05:18 -0700 (PDT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_AWuPeFfm1aYQSi7ImnVDvA)"
Received: from relay6.apple.com ([17.128.113.90]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MJK00KXAIOQXO11@mail-out.apple.com> for rtcweb@ietf.org; Tue, 12 Mar 2013 15:05:15 -0700 (PDT)
X-AuditID: 1180715a-b7f566d000006daa-a6-513fa69a8a90
Received: from cilantro.apple.com (cilantro.apple.com [17.128.115.18]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay6.apple.com (Apple SCV relay) with SMTP id A6.50.28074.A96AF315; Tue, 12 Mar 2013 15:05:14 -0700 (PDT)
Received: from [17.153.96.57] by cilantro.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MJK00CICIOH6P20@cilantro.apple.com> for rtcweb@ietf.org; Tue, 12 Mar 2013 15:05:14 -0700 (PDT)
From: David Singer 
In-reply-to: <513E9F01.3020800@alvestrand.no>
Date: Tue, 12 Mar 2013 15:05:03 -0700
Message-id: <01663961-7F84-4560-83F2-64DE0651B10C@apple.com>
References:    <949EF20990823C4C85C18D59AA11AD8B01121E@FR712WXCHMBA11.zeu.alcatel-lucent.com>   <513E9F01.3020800@alvestrand.no>
To: Harald Alvestrand 
X-Mailer: Apple Mail (2.1499)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUi2FAspDtrmX2gwZJ/lhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr49Pxy2wFW1wrer8fZ25gfGbVxcjJISFgIrFyxkMmCFtM4sK9 9WxdjFwcQgITmSRO/L7HBOE0M0m07W0Ecjg4mAWSJG7PUAIxeQX0JCbtDwLpFRbwkFjUO40d xGYTUJV4MOcYI4jNKaArcbjrHpjNAhTv2/cCzGYWEJb4/vgeC4jNK2AjsajpGTPEqmPMEse2 HgQ7SERAR+Lh/gao42QlVkztZZrAyD8L4YpZCFfMApuqLbFs4WtmCFtP4mXTO3ZMcV2Ji+sm MS5gZFvFKFCUmpNYaaaXWFCQk6qXnJ+7iREcpIVROxgbllsdYhTgYFTi4ZVIsw8UYk0sK67M PcQowcGsJMLLNwsoxJuSWFmVWpQfX1Sak1p8iFGag0VJnHdjB1BKID2xJDU7NbUgtQgmy8TB KdXAGHpff+tWA/ddO09sOaZg1+GT8Tey2CJr5f27Hea6XI98dBfn1K1aFlOwKe+rQ2f6esXC 37cX7kuxc/x4Lj7F13NGwrbPht2PTknkHTyQOOPmUokFx6bOVNP59XPp5zDr7ynW/yL5rzbX hHPdUWAtCFb9sCeHeYv2LuM3PUX3NGqcXvquTueQUGIpzkg01GIuKk4EAIaxhbROAgAA
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] H.264 IPR status (Re:  VP8 litigation in Germany?)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 22:05:22 -0000

--Boundary_(ID_AWuPeFfm1aYQSi7ImnVDvA)
Content-type: text/plain; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT


On Mar 11, 2013, at 20:20 , Harald Alvestrand  wrote:

> 
> I know of 3 sources of IPR information related to H.264:
> 
> - The ISO database of disclosures ( http://www.iso.org/iso/standards_development/patents)
> - The MPEG-LA list of IPR available for licensing via their license pool
> - The list that Cliff Reader did related to H.264 Baseline work in MPEG
> 
> The first 2 are public on the Web; I don't know the status of the third one (MPEG doesn't make its input documents public by default).
> 
> I think it's fair to ask the proponents of H.264 to present the IPR situation for their candidate codec; saying that it is "well known" is not the same as having an input contribution to the IETF stating what the situation is.
> 

I think we're past the formal contribution deadline, alas.  However, you are basically right, with perhaps one or two additions, and a caveat.

The caveat is that the AVC/H.264 specification contains (a) AVC itself and (b) scalable video coding (SVC) and (c) multi-view coding (MVC).  So the complete list includes IPR on SVC and MVC as well.  You might 

The union of these gives, I think, a very thorough view (there is, of course, a lot of overlap):

1. The ITU database can be searched;  the formal name at the ITU is H.264 and the search page is .
2. The ISO database is a download and manual search for 14496-10 (the format spec. number), the page is .
3. MPEG is formally part of the joint ISO/IEC technical committee;  it may be the IEC database at  helps (again, 14496-10).
4. The MPEG-LA list of licensors and licensed patents in their patent pool is also public at their web site. 

I hope this helps;  in most cases you will see company names, contact information, and the declared IPR;  in the MPEG-LA case, a summary of the license is also available, and of course the license can be requested.

I look forward to the same clarity, completeness, and commitment not only to 'F' (free, already stated) but also 'RAND' (reasonable and non-discrimatory terms) for VP8.  I understand it should be coming soon, and I appreciate all the work you and others are doing to bring it to the table.

David Singer
Multimedia and Software Standards, Apple Inc.


--Boundary_(ID_AWuPeFfm1aYQSi7ImnVDvA)
Content-type: text/html; CHARSET=US-ASCII
Content-transfer-encoding: quoted-printable

harald@alvestrand.no> =
wrote:


 =20
    
 =20
  

    


    I know of 3 sources of IPR information related to H.264:

    

    - The ISO database of disclosures (
    
    http://www.i=
so.org/iso/standards_development/patents)

    - The MPEG-LA list of IPR available for licensing via their license
    pool

    - The list that Cliff Reader did related to H.264 Baseline work in
    MPEG

    

    The first 2 are public on the Web; I don't know the status of the
    third one (MPEG doesn't make its input documents public by =
default).

    

    I think it's fair to ask the proponents of H.264 to present the IPR
    situation for their candidate codec; saying that it is "well known"
    is not the same as having an input contribution to the IETF stating
    what the situation is.

    

I think we're past the formal =
contribution deadline, alas.  However, you are basically right, =
with perhaps one or two additions, and a =
caveat.

The caveat is that the AVC/H.264 =
specification contains (a) AVC itself and (b) scalable video coding =
(SVC) and (c) multi-view coding (MVC).  So the complete list =
includes IPR on SVC and MVC as well.  You =
might 

The union of these gives, I think, =
a very thorough view (there is, of course, a lot of =
overlap):

1. The ITU database can be searched; =
 the formal name at the ITU is H.264 and the search page is <http://www.itu=
.int/ipr/IPRSearch.aspx?iprtype=3DPS>.
2. The ISO =
database is a download and manual search for 14496-10 (the format spec. =
number), the page is <http://www.i=
so.org/iso/standards_development/patents>.
3. MPEG is =
formally part of the joint ISO/IEC technical committee;  it may be =
the IEC database at <http://www.iec.ch/members_experts/tools/patents/patent_policy.htm>=
 helps (again, 14496-10).
4. The MPEG-LA list of licensors and =
licensed patents in their patent pool is also public at their web site. =
<http://w=
ww.mpegla.com/main/programs/AVC/Pages/Intro.aspx>

I hope this helps;  in most cases you will see company =
names, contact information, and the declared IPR;  in the MPEG-LA =
case, a summary of the license is also available, and of course the =
license can be requested.

I look forward to the =
same clarity, completeness, and commitment not only to 'F' (free, =
already stated) but also 'RAND' (reasonable and non-discrimatory terms) =
for VP8.  I understand it should be coming soon, and I appreciate =
all the work you and others are doing to bring it to the =
table.



David Singer
Multimedia and Software =
Standards, Apple Inc.




=

--Boundary_(ID_AWuPeFfm1aYQSi7ImnVDvA)--

From singer@apple.com  Tue Mar 12 15:06: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 E8FAD21F8D0A for ; Tue, 12 Mar 2013 15:06:31 -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 Jc+Et1W-pJ1P for ; Tue, 12 Mar 2013 15:06:31 -0700 (PDT)
Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5572521F8D1C for ; Tue, 12 Mar 2013 15:06:31 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MJK00K0DIQUXO21@mail-out.apple.com> for rtcweb@ietf.org; Tue, 12 Mar 2013 15:06:31 -0700 (PDT)
X-AuditID: 11807158-b7fa36d000006cd2-26-513fa6e73dff
Received: from cilantro.apple.com (cilantro.apple.com [17.128.115.18]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay5.apple.com (Apple SCV relay) with SMTP id 7D.F0.27858.7E6AF315; Tue, 12 Mar 2013 15:06:31 -0700 (PDT)
Received: from [17.153.96.57] by cilantro.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MJK00CL2IQM6P20@cilantro.apple.com> for rtcweb@ietf.org; Tue, 12 Mar 2013 15:06:31 -0700 (PDT)
From: David Singer 
In-reply-to: 
Date: Tue, 12 Mar 2013 15:06:21 -0700
Message-id: <5FB1A732-782B-4AD0-A273-0F3624681FE4@apple.com>
References: 
To: markus.isomaki@nokia.com
X-Mailer: Apple Mail (2.1499)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUi2FAspPt8mX2gQc9nLou1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsefXC+aC5bwVp2f6NDDu5upi5OSQEDCR2HHvPwuELSZx4d56 ti5GLg4hgYlMEpuvTWOFcJqZJP5172UHqWIW0JJYv/M4UxcjBwevgJ7EpP1BIGFhAXeJhSdn MILYbAKqEg/mHAOzOQUiJNp3nQRrZQGKv3w3mxVijLpE44Z2FghbW+LJuwtgcV4BG4mFj5+C jRcSCJeYfd8MJCwiICPROnkCE8SdshIrpvYyTWAUmIXkoFkIB81CMnQBI/MqRoGi1JzESlO9 xIKCnFS95PzcTYzgkCuM2MH4f5nVIUYBDkYlHl6JNPtAIdbEsuLK3EOMEhzMSiK8fLOAQrwp iZVVqUX58UWlOanFhxilOViUxHk3dgClBNITS1KzU1MLUotgskwcnFINjL2r9LivqxxUlHyZ sq+rJjtwHdOdBG6OwK9bw2c0J4hNeDqt8clqO4EDszZXeQn+nLfcoiJk3Te7xaJZ/fcsbs1h 2mDTYvucLT+dYbdyI3OhF2uodBFL79J1RSt1dmsGLpcoTvOX9E9zibnvll1x8dLr2OlCJ/Qn r5q265SNuqevr5VSSq2SEktxRqKhFnNRcSIA8bsR1TUCAAA=
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] H.264 IPR status (RE: VP8 litigation in Germany?)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 22:06:32 -0000

On Mar 12, 2013, at 7:19 , markus.isomaki@nokia.com wrote:

> Hi Ted,
> 
> Ted Hardie wrote:
>> 
>>> What comes to H.264, the Nokia IPR related to that has been disclosed
>>> to those SDOs where that codec has been developed, except for the RTP
>>> payload format that is in the IETF. I assume all that is publicly
>>> available to interested parties. If I recall correctly, some pointers were
>> floating around prior to IETF 85. > I'm sure others on this list know that side
>> better than me.
>>> 
>> Hi Markus,
>> 
>> Thanks for the clarification.  I could not find the pointers that you mention; if
>> you could provide a URL to the patent list and license terms, that would be
>> very useful.  I understand you have already said that this would be some
>> flavor of RAND, but the working group comments seem to indicate folks want
>> to see the actual license text if that is available.
>> 
> 
> Please see the URLs posted earlier today by Harald and Stephan, and the summary of H.264 IPR situation by Stephan. Are you asking for this about Nokia specifically, or for all of the H.264 proponents (several affiliations) or for H.264 in general? Nokia is certainly no special case in that context. 
> 
> I have gotten the impression that H.264's IPR status is relatively clear enough for the WG participants to form their opinion about it. But if something more would *really* be useful, I think the proponets could try do dig it out. 

I have posted a more detailed list of where to find information, on another thread.  I hope it helps.


David Singer
Multimedia and Software Standards, Apple Inc.


From elagerway@gmail.com  Tue Mar 12 15:08: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 539F521F8D1C for ; Tue, 12 Mar 2013 15:08:37 -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 oAV86rkzhL0r for ; Tue, 12 Mar 2013 15:08:36 -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 3DDE821F8D24 for ; Tue, 12 Mar 2013 15:08:36 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id hm6so286395wib.14 for ; Tue, 12 Mar 2013 15:08:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=27siwgF+dunGgOpL3/YYhKt4H8nDbvO+X1ydZeL+848=; b=PT3Fe1t1xuMbQXn5LRkk7e5KOZpO8MKe3zkddgYJ5Y3T2mqg7wkkOm9IKTGzg+Eu6f 30sjUv3gpd3O/1Y5RGjOXU08TN6X/MqqSPjw9zzrJQqk4XAlEss3vPm0C+/qaBYA5lr6 A73SF9hc4VBCtgGRzFVQKxQjaPJ4jrv4YVP5HjpXnDyBD0H3dnvRXoLomAKxkeEtCgxi R5iB2ZvfS69b++ROy7QgeI5y8qEvpSdwDMcrBe4Q0kbrklcvUoeWEfzPfhbj6cv0WLx5 KnzI9j71uXnISBArDaa5WnvX4loZC89GgprNAsg6Nad4pobbJZhdWnkzwNbKcDbeOXq1 8v2A==
MIME-Version: 1.0
X-Received: by 10.180.24.229 with SMTP id x5mr23057251wif.17.1363126115273; Tue, 12 Mar 2013 15:08:35 -0700 (PDT)
Sender: elagerway@gmail.com
Received: by 10.216.206.65 with HTTP; Tue, 12 Mar 2013 15:08:35 -0700 (PDT)
In-Reply-To: <513F9B90.4090802@ericsson.com>
References: <513F9011.4040900@ericsson.com> <513F997B.50807@nostrum.com> <513F9B90.4090802@ericsson.com>
Date: Tue, 12 Mar 2013 15:08:35 -0700
X-Google-Sender-Auth: v3zMELN_toqr801UCoalAxjTXNg
Message-ID: 
From: Erik Lagerway 
To: Magnus Westerlund 
Content-Type: multipart/alternative; boundary=f46d0421848de40ab704d7c18784
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Datachannel adoption confirmation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 22:08:37 -0000

--f46d0421848de40ab704d7c18784
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

As a remote participant, not sure if I was considered as contributing
member in that meeting, I did hum for draft-jesup-rtcweb-data-protocol-04.

Best,
Erik

*Erik Lagerway  |
*Hookflash
* | 1 (855) Hookflash ext. 2 | Twitter  | Web=
RTC
Blog  *
****


On Tue, Mar 12, 2013 at 2:18 PM, Magnus Westerlund <
magnus.westerlund@ericsson.com> wrote:

> Adam,
>
> To my knowledge you where in the meeting and thus you don't need to
> restate any position. I don't want all the person that actually was in
> the meeting to restate their position here.
>
> Cheers
>
> Magnus
>
> On 2013-03-12 17:09, Adam Roach wrote:
> > I strongly support the use of draft-jesup-rtcweb-data-protocol as the
> > basis for a working group document to address this issue.
> >
> > /a
> >
> > On 3/12/13 16:29, Magnus Westerlund wrote:
> >> WG,
> >>
> >> In today's session we had a call for adopting as WG draft a proposal a=
s
> >> the starting point for the Data channel management. There was a strong
> >> consensus in the meeting to pick draft-jesup-rtcweb-data-protocol-04 a=
s
> >> that document.
> >>
> >> This is the confirmation on the mailing list, where people who where n=
ot
> >> present may express their position of which of the three proposals:
> >>
> >> - draft-jesup-rtcweb-data-protocol-04
> >> - draft-thomson-rtcweb-data-00
> >> - draft-marcon-rtcweb-data-channel-management-00
> >>
> >> Please provide any additional input by 19th of March.
> >>
> >> Cheers
> >>
> >> Magnus Westerlund
> >>
> >> ----------------------------------------------------------------------
> >> Multimedia Technologies, Ericsson Research EAB/TVM
> >> ----------------------------------------------------------------------
> >> Ericsson AB                | Phone  +46 10 7148287
> >> F=E4r=F6gatan 6                | Mobile +46 73 0949079
> >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> >> ----------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> rtcweb mailing list
> >> rtcweb@ietf.org
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> >
>
>
> --
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> F=E4r=F6gatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--f46d0421848de40ab704d7c18784
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


As a remote participant, not su=
re if I was considered as contributing member in that meeting, I did hum fo=
r=A0draft-jesup-rtcweb-data-protocol-04.



Best,


Erik

Erik Lagerway | Hookflash<=
span style=3D"font-size:small"> | 1 (855) Hookflash ext. 2 =
| Twitter | =
WebRTC Blog 

<=
/span>




On Tue, Mar 12, 2013 at 2:18 PM, Magnus =
Westerlund <magnus.westerlund@ericsson.com> wro=
te:


Adam,



To my knowledge you where in the meeting and thus you don't need to

restate any position. I don't want all the person that actually was in<=
br>
the meeting to restate their position here.



Cheers



Magnus




On 2013-03-12 17:09, Adam Roach wrote:

> I strongly support the use of draft-jesup-rtcweb-data-protocol as the<=
br>
> basis for a working group document to address this issue.

>

> /a

>

> On 3/12/13 16:29, Magnus Westerlund wrote:

>> WG,

>>

>> In today's session we had a call for adopting as WG draft a pr=
oposal as

>> the starting point for the Data channel management. There was a st=
rong

>> consensus in the meeting to pick draft-jesup-rtcweb-data-protocol-=
04 as

>> that document.

>>

>> This is the confirmation on the mailing list, where people who whe=
re not

>> present may express their position of which of the three proposals=
:

>>

>> - draft-jesup-rtcweb-data-protocol-04

>> - draft-thomson-rtcweb-data-00

>> - draft-marcon-rtcweb-data-channel-management-00

>>

>> Please provide any additional input by 19th of March.

>>

>> Cheers

>>

>> Magnus Westerlund

>>

>> ------------------------------------------------------------------=
----

>> Multimedia Technologies, Ericsson Research EAB/TVM

>> ------------------------------------------------------------------=
----

>> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287

>> F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 094=
9079

>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com

>> ------------------------------------------------------------------=
----

>>

>> _______________________________________________

>> rtcweb mailing list

>> rtcweb@ietf.org

>> https://www.ietf.org/mailman/listinfo/rtcweb

>

>

>






--




Magnus Westerlund



----------------------------------------------------------------------

Multimedia Technologies, Ericsson Research EAB/TVM

----------------------------------------------------------------------

Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287

F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079

SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com

----------------------------------------------------------------------



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--f46d0421848de40ab704d7c18784--

From rlb@ipv.sx  Tue Mar 12 15: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 D50F211E812D for ; Tue, 12 Mar 2013 15:23:56 -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.624,  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 o1dAJd+DIcre for ; Tue, 12 Mar 2013 15:23:56 -0700 (PDT)
Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by ietfa.amsl.com (Postfix) with ESMTP id 39A7111E812B for ; Tue, 12 Mar 2013 15:23:56 -0700 (PDT)
Received: by mail-oa0-f42.google.com with SMTP id i18so421264oag.1 for ; Tue, 12 Mar 2013 15:23:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=V8y4qkLni1cTmaTMjKhxe/Eu2/GUVY+j8RKje3ZTY6o=; b=ONZZ+IC81JF//gaaSNc5I7EyAryLamVSglS5sAhdl/A358+4REDUMpzBsojn1xpOcX wyoPRTDDyw6z612iTLEEo39NTd4BKAcNQdUvfyScA5OeMO0YcERSjWXf600rDNx02cs8 FAv9mF0Mitvv522aGVjyAs69cVCdPS4XZ0R8nniTRi81n4RO7D2bHEAkZq/ikR1efqqu qrKrrQFkHZ8+HZJAUAAX1DujeZ9B3GqenbP4U+XjTVpReHOyLJOfEJP4+09xChVlTbKc smyBsNJam0yK/GojVcaJ3/hwEVEZ2uPaKG3g6QYlEkihOD2Hz13tkZ0jTjpeD+PEcDsU uBAg==
MIME-Version: 1.0
X-Received: by 10.182.245.33 with SMTP id xl1mr13532643obc.91.1363127035728; Tue, 12 Mar 2013 15:23:55 -0700 (PDT)
Received: by 10.60.40.233 with HTTP; Tue, 12 Mar 2013 15:23:55 -0700 (PDT)
X-Originating-IP: [128.89.253.127]
In-Reply-To: 
References: 
Date: Tue, 12 Mar 2013 18:23:55 -0400
Message-ID: 
From: Richard Barnes 
To: Ted Hardie 
Content-Type: multipart/alternative; boundary=14dae93a19a3bfb16b04d7c1be01
X-Gm-Message-State: ALoCoQmAO10fE0Gh2SxQNBocEpS1Wf1j2xGD+h5mHkz8zlUU2QYCadG0uP4wQzpKweN8OGgWkHrp
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Reminder: Working group last call for draft-ietf-rtcweb-security-arch
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 12 Mar 2013 22:23:56 -0000

--14dae93a19a3bfb16b04d7c1be01
Content-Type: text/plain; charset=ISO-8859-1

I haven't had a chance to write up detailed comments, but my high-level
comment is that it goes into a bit too much detail on how the security
goals are accomplished.

The main thing this document needs to do is lay out the high-level roles in
the process (IdPs, calling sites, UAs) and what security guarantees they
each provide.  It does a good job of that Section 4 and the beginning of
Section 5.

Beginning around Section 5.6, it starts to veer off into technical details.
 Section 5.6 and Section 5.7.4 (and possibly others) should probably be
moved to a separate document, not because I think they're wrong, but
because there are some alternative models to be considered for how to meet
the goals of the security architecture.

--Richard




On Mon, Feb 25, 2013 at 6:27 PM, Ted Hardie  wrote:

> This is a reminder that there is an ongoing last call for
> draft-ietf-rtcweb-security-arch-06.  Please send comments, including
> those of the "reviewed and no issues" ilk, by March 9th, 2012.
>
> regards,
>
> Ted Hardie
>
> On Thu, Feb 14, 2013 at 8:35 AM, Ted Hardie  wrote:
> > This begins a working group last call for
> > draft-ietf-rtcweb-security-arch.  Please send comments to the list by
> > March 9, 2013.
> >
> > regards,
> >
> > Ted, Cullen, Magnus
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--14dae93a19a3bfb16b04d7c1be01
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I haven't had a chance to write up detailed comments, but my high-level=
 comment is that it goes into a bit too much detail on how the security goa=
ls are accomplished.

The main thing this document needs =
to do is lay out the high-level roles in the process (IdPs, calling sites, =
UAs) and what security guarantees they each provide. =A0It does a good job =
of that Section 4 and the beginning of Section 5.



Beginning around Section 5.6, it starts to veer off int=
o technical details. =A0Section 5.6 and Section 5.7.4 (and possibly others)=
 should probably be moved to a separate document, not because I think they&=
#39;re wrong, but because there are some alternative models to be considere=
d for how to meet the goals of the security architecture. =A0



--Richard



<=
br>
On Mon, Feb 25, 2013 at 6:27 PM, Ted Hardie <=
span dir=3D"ltr"><ted.ietf@gmail.com> wrote:


This is a reminder that there is an ongoing =
last call for

draft-ietf-rtcweb-security-arch-06. =A0Please send comments, including

those of the "reviewed and no issues" ilk, by March 9th, 2012.


regards,



Ted Hardie



On Thu, Feb 14, 2013 at 8:35 AM, Ted Hardie <ted.ietf@gmail.com> wrote:

> This begins a working group last call for

> draft-ietf-rtcweb-security-arch. =A0Please send comments to the list b=
y

> March 9, 2013.

>

> regards,

>

> Ted, Cullen, Magnus

_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--14dae93a19a3bfb16b04d7c1be01--

From bernard_aboba@hotmail.com  Tue Mar 12 17:32: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 6181B11E80F6 for ; Tue, 12 Mar 2013 17:32:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.47
X-Spam-Level: 
X-Spam-Status: No, score=-101.47 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, 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 fAZmBa7x-w3x for ; Tue, 12 Mar 2013 17:32:06 -0700 (PDT)
Received: from blu0-omc3-s23.blu0.hotmail.com (blu0-omc3-s23.blu0.hotmail.com [65.55.116.98]) by ietfa.amsl.com (Postfix) with ESMTP id AF2C411E80E9 for ; Tue, 12 Mar 2013 17:32:06 -0700 (PDT)
Received: from BLU403-EAS202 ([65.55.116.74]) by blu0-omc3-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Mar 2013 17:32:03 -0700
X-EIP: [JJ3DRVNl3C6Pb7bQDKdfikyiWx+BOyXr]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
References: 
From: Bernard Aboba 
MIME-Version: 1.0 (1.0)
In-Reply-To: 
Date: Tue, 12 Mar 2013 20:32:01 -0400
To: Hadriel Kaplan 
X-OriginalArrivalTime: 13 Mar 2013 00:32:03.0540 (UTC) FILETIME=[2F052940:01CE1F82]
Cc: "" 
Subject: Re: [rtcweb] Something to do on Thursday
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 00:32:14 -0000

It would be a better use of time than the video codec discussion, and might e=
ven yield a decision.

So yeah, it is a good idea, but no doubt one that will be ignored.

Bernard "someday they will have a museum for Hadriel's email posts (alongsid=
e Nostradamus predictions) and the masses will come in droves" Aboba

On Mar 12, 2013, at 16:46, "Hadriel Kaplan"  wrote:

> I will probably be blasted for this, but I'm feeling Goofy...
>=20
> If we need something else to talk about on Thursday's RTCWeb meeting slot i=
nstead of video codecs, we can have the SRTP keying discussion that has been=
 delayed so far.  I believe there are slide sets already prepared for both s=
ides of the debate, and no IPR issues I know of.
>=20
> -hadriel
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

From xavier.marjou@gmail.com  Wed Mar 13 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 8B7E921F8614 for ; Wed, 13 Mar 2013 06:14:32 -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 DYC4BE52vFO0 for ; Wed, 13 Mar 2013 06:14:31 -0700 (PDT)
Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 64DBE21F85EB for ; Wed, 13 Mar 2013 06:14:31 -0700 (PDT)
Received: by mail-la0-f42.google.com with SMTP id fe20so1095488lab.15 for ; Wed, 13 Mar 2013 06:14:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=XGGM4n15QVc8WaUEfOCIDRPmbGEcM5ZbDoIbZNr85fc=; b=FP1qayd+bwwcp8OW6wn7hAvUe5q5HXuvU05S+cSsMabVGo6UMhVIcN+VWzduW9niAq 1R0zUCf0U4YYDkXBDPIq098FDDjblfMeiCwebKcHtms98Eh80YrfEITkCNAy3GNQVywg gCUqs/mLN/dejpdsuKAPHrleSfsC6tWwVlCLSVs898R2uihVpihg0KSioF97Cjmah5uV IO9+xHZLsrI0U1O9LnNcxcJ1vwGDnSCgrLYzTjfS4Z4MAkYAlZXpMzCUo817y+H0XoXa d5hYzzl5ca9Lu8Mcv7XKygobHgLD5e8Cb7698SLsKqlEYtVkDg8SlmjdyNn27hAr3+gF 2ZgA==
MIME-Version: 1.0
X-Received: by 10.112.41.101 with SMTP id e5mr7407453lbl.120.1363180470253; Wed, 13 Mar 2013 06:14:30 -0700 (PDT)
Sender: xavier.marjou@gmail.com
Received: by 10.114.7.167 with HTTP; Wed, 13 Mar 2013 06:14:30 -0700 (PDT)
In-Reply-To: 
References:  
Date: Wed, 13 Mar 2013 09:14:30 -0400
X-Google-Sender-Auth: 6FoQnM6l_8elkx7naq85ntS1RJY
Message-ID: 
From: Xavier Marjou 
To: rtcweb@ietf.org
Content-Type: multipart/alternative; boundary=e0cb4efe2f9cb1c57004d7ce2f92
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 13:14:32 -0000

--e0cb4efe2f9cb1c57004d7ce2f92
Content-Type: text/plain; charset=ISO-8859-1

Here is a summary of the draft-marjou-rtcweb-audio-codecs-for-interop-00
presentation that I had prepared for yesterday's session:

- The co-authors want to underline that non-WebRTC voice endpoints usually
use one of the following codecs: AMR, AMR-WB or G.722, which will result in
massive transcoding when there will be communications between WebRTC
endpoints and non-WebRTC endpoints.

- On one side, transcoding is bad for many reasons discussed in the draft
(cost issues, intrinsic quality degradation, degraded interactivity,
fallback from HD to G.711...);

- On the other side, it is recognized that implementing additional codecs
in the browsers can generate additional costs.

- In order to reach a compromise, we would like to add some text in the WG
draft draft-ietf-rtcweb-audio providing incentives for the browser to use
these three codecs: make them mandatory to implement when there is no cost
impact on the browser (e.g. if codec already installed, paid by the device
vendor...).

Any opinion on that?

Cheers,

Xavier

PS: I will be ready to present the slides on Thursday if time permits it.

(c.f. http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf )



On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie  wrote:

> Magnus and I discussed this this morning, and we encourage you to
> prepare something.  If the discussion of working group last call items
> runs short, we may be able to fit this in at that time or at the end
> of day one if its full agenda his finished.  This is not a commitment,
> however, so please try and get discussion on the list on the points
> from the draft you feel need resolution.
>
> regards,
>
> Ted
>
>
> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)
>  wrote:
> > Hello,
> >
> >
> >
> > I would like to request agenda time for:
> >
> >
> >
> > draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> >
> >
> > The document  presents use-cases underlining why WebRTC needs AMR-WB,
>  AMR
> > and G.722 as additional relevant voice codecs to satisfactorily ensure
> > interoperability with existing systems.
> >
> >
> >
> > A 10-minute time slot should be sufficient for presentation and
> discussion.
> >
> >
> >
> > Regards
> >
> >
> >
> > -Espen
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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
>

--e0cb4efe2f9cb1c57004d7ce2f92
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Here is a summary of the draft-marjou-rtcweb-audi=
o-codecs-for-interop-00 presentation that I had prepared for yesterday'=
s session:



- The co-authors want to underline that non-WebRT=
C voice
endpoints usually use one of the following codecs: AMR, AMR-WB or G.722, wh=
ich
will result in massive transcoding when there will be communications betwee=
n
WebRTC endpoints and non-WebRTC endpoints.



- On one side, transcoding is bad for many reason=
s
discussed in the draft (cost issues, intrinsic quality degradation, degrade=
d interactivity,
fallback from HD to G.711...);



- On the other side, it is recognized that implem=
enting
additional codecs in the browsers can generate additional costs.



- In order to reach a compromise, we would like t=
o add
some text in the WG draft draft-ietf-rtcweb-audio providing incentives for =
the
browser to use these three codecs: make them mandatory to implement when th=
ere
is no cost impact on the browser (e.g. if codec already installed, paid by =
the
device vendor...).



Any opinion on that?



Cheers,



Xavier



PS: I will be ready to present the slides on Thur=
sday if time
permits it.
(c.f. http://tools.ietf.org/agenda/=
86/slides/slides-86-rtcweb-6.pdf )



On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie =
<ted.ietf@gmail.com> wrote:

Magnus and I discussed this this morning, and we encourage you to

prepare something. =A0If the discussion of working group last call items
runs short, we may be able to fit this in at that time or at the end

of day one if its full agenda his finished. =A0This is not a commitment,
however, so please try and get discussion on the list on the points

from the draft you feel need resolution.



regards,



Ted






On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)

<espeberg@cisco.com> wrote:=


> Hello,

>

>

>

> I would like to request agenda time for:

>

>

>

> draft-marjou-rtcweb-audio-codecs-for-interop-01

>

>

>

> The document =A0presents use-cases underlining why WebRTC needs AMR-WB=
, =A0AMR

> and G.722 as additional relevant voice codecs to satisfactorily ensure=


> interoperability with existing systems.

>

>

>

> A 10-minute time slot should be sufficient for presentation and discus=
sion.

>

>

>

> Regards

>

>

>

> -Espen

>

>

>

>

>

>


> __________________=
_____________________________

> 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





--e0cb4efe2f9cb1c57004d7ce2f92--

From alex@voxeo.com  Wed Mar 13 06:25: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 B058221F8C96 for ; Wed, 13 Mar 2013 06:25:15 -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 5LvOUhzDSlZS for ; Wed, 13 Mar 2013 06:25:14 -0700 (PDT)
Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by ietfa.amsl.com (Postfix) with ESMTP id 4D69A21F8C9D for ; Wed, 13 Mar 2013 06:25:14 -0700 (PDT)
Received: from dhcp-1127.meeting.ietf.org (account alex@voxeo.com [130.129.17.39] verified) by voxeo.com (CommuniGate Pro SMTP 5.3.8) with ESMTPSA id 130085870 for rtcweb@ietf.org; Wed, 13 Mar 2013 13:25:11 +0000
Message-ID: <51407E37.7090307@voxeo.com>
Date: Wed, 13 Mar 2013 09:25:11 -0400
From: Alex Agranovsky 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References:   
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080408010702010104080408"
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 13:25:15 -0000

This is a multi-part message in MIME format.
--------------080408010702010104080408
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

It's hard to imagine a situation in which AMR/AMR-WB will be available 
at no cost to the browser, considering royalties involved.

http://www.voiceage.com/amr_faqs.php#11

And if we limit the requirement only to those who have paid ... it's not 
really 'mandatory'.

- Alex

On 3/13/13 9:14 AM, Xavier Marjou wrote:
>
> Here is a summary of the 
> draft-marjou-rtcweb-audio-codecs-for-interop-00 presentation that I 
> had prepared for yesterday's session:
>
> - The co-authors want to underline that non-WebRTC voice endpoints 
> usually use one of the following codecs: AMR, AMR-WB or G.722, which 
> will result in massive transcoding when there will be communications 
> between WebRTC endpoints and non-WebRTC endpoints.
>
> - On one side, transcoding is bad for many reasons discussed in the 
> draft (cost issues, intrinsic quality degradation, degraded 
> interactivity, fallback from HD to G.711...);
>
> - On the other side, it is recognized that implementing additional 
> codecs in the browsers can generate additional costs.
>
> - In order to reach a compromise, we would like to add some text in 
> the WG draft draft-ietf-rtcweb-audio providing incentives for the 
> browser to use these three codecs: make them mandatory to implement 
> when there is no cost impact on the browser (e.g. if codec already 
> installed, paid by the device vendor...).
>
> Any opinion on that?
>
> Cheers,
>
> Xavier
>
> PS: I will be ready to present the slides on Thursday if time permits it.
>
> (c.f. http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf )
>
>
>
> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie  > wrote:
>
>     Magnus and I discussed this this morning, and we encourage you to
>     prepare something.  If the discussion of working group last call items
>     runs short, we may be able to fit this in at that time or at the end
>     of day one if its full agenda his finished.  This is not a commitment,
>     however, so please try and get discussion on the list on the points
>     from the draft you feel need resolution.
>
>     regards,
>
>     Ted
>
>
>     On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)
>     > wrote:
>     > Hello,
>     >
>     >
>     >
>     > I would like to request agenda time for:
>     >
>     >
>     >
>     > draft-marjou-rtcweb-audio-codecs-for-interop-01
>     >
>     >
>     >
>     > The document  presents use-cases underlining why WebRTC needs
>     AMR-WB,  AMR
>     > and G.722 as additional relevant voice codecs to satisfactorily
>     ensure
>     > interoperability with existing systems.
>     >
>     >
>     >
>     > A 10-minute time slot should be sufficient for presentation and
>     discussion.
>     >
>     >
>     >
>     > Regards
>     >
>     >
>     >
>     > -Espen
>     >
>     >
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > 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


--------------080408010702010104080408
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
It's hard to imagine a situation in
      which AMR/AMR-WB will be available at no cost to the browser,
      considering royalties involved.

      

      http://www.voiceage.com/amr_faqs.php#11

      

      And if we limit the requirement only to those who have paid ...
      it's not really 'mandatory'.

      

      - Alex

      

      On 3/13/13 9:14 AM, Xavier Marjou wrote:

    

    

      
Here is a summary of the
        draft-marjou-rtcweb-audio-codecs-for-interop-00 presentation
        that I had prepared for yesterday's session:

      
- The co-authors want to underline that
        non-WebRTC voice
        endpoints usually use one of the following codecs: AMR, AMR-WB
        or G.722, which
        will result in massive transcoding when there will be
        communications between
        WebRTC endpoints and non-WebRTC endpoints.

      
- On one side, transcoding is bad for many
        reasons
        discussed in the draft (cost issues, intrinsic quality
        degradation, degraded interactivity,
        fallback from HD to G.711...);

      
- On the other side, it is recognized that
        implementing
        additional codecs in the browsers can generate additional costs.

      
- In order to reach a compromise, we would
        like to add
        some text in the WG draft draft-ietf-rtcweb-audio providing
        incentives for the
        browser to use these three codecs: make them mandatory to
        implement when there
        is no cost impact on the browser (e.g. if codec already
        installed, paid by the
        device vendor...).

      
Any opinion on that?

      
Cheers,

      
Xavier

      
PS: I will be ready to present the slides
        on Thursday if time
        permits it.

      
(c.f. http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf
        )

      


      

      

      
On Thu, Mar 7, 2013 at 11:18 AM, Ted
        Hardie <ted.ietf@gmail.com>
        wrote:

        

          Magnus and I discussed this this morning, and we encourage you
          to

          prepare something.  If the discussion of working group last
          call items

          runs short, we may be able to fit this in at that time or at
          the end

          of day one if its full agenda his finished.  This is not a
          commitment,

          however, so please try and get discussion on the list on the
          points

          from the draft you feel need resolution.

          

          regards,

          

          Ted

          

            


              

              On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)

              <espeberg@cisco.com>
              wrote:

              > Hello,

              >

              >

              >

              > I would like to request agenda time for:

              >

              >

              >

              > draft-marjou-rtcweb-audio-codecs-for-interop-01

              >

              >

              >

              > The document  presents use-cases underlining why
              WebRTC needs AMR-WB,  AMR

              > and G.722 as additional relevant voice codecs to
              satisfactorily ensure

              > interoperability with existing systems.

              >

              >

              >

              > A 10-minute time slot should be sufficient for
              presentation and discussion.

              >

              >

              >

              > Regards

              >

              >

              >

              > -Espen

              >

              >

              >

              >

              >

              >

            

          

          

            
>
              _______________________________________________

              > 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


    

    

  


--------------080408010702010104080408--

From Kalyani.Bogineni@VerizonWireless.com  Wed Mar 13 06:31: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 1D9FA21F8A41 for ; Wed, 13 Mar 2013 06:31:56 -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 gKj0mn3EY8Rc for ; Wed, 13 Mar 2013 06:31:53 -0700 (PDT)
Received: from vanguard.verizonwireless.com (vanguard.verizonwireless.com [162.115.35.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3782721F8CBB for ; Wed, 13 Mar 2013 06:31:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizonwireless.com; i=@verizonwireless.com; l=0; q=dns/txt; s=prodmail; t=1363181506; x=1394717506; h=from:to:cc:date:subject:references:in-reply-to: mime-version; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=nRcHyEu0auo0MKOGIEh4w6lE8hi8umOh9GFMjOXieODjfRulThBot8X0 fUmG35HLVQTFhiCdMk9gQYtqgv+ZhX5GZPGeyljRkS4wdjqpQKpohSQO9 2l0+w+f2Ofyk7eyAZhsCc2SeEDYM8gIuUNict57vMwDaSrPv+5Xb53dFh 8=;
Received: from ohdub02exhub01.uswin.ad.vzwcorp.com ([10.97.42.201]) by vanguard.verizonwireless.com with ESMTP; 13 Mar 2013 06:31:44 -0700
Received: from OHDUB02EXCV33.uswin.ad.vzwcorp.com ([10.97.42.179]) by OHDUB02EXHUB01.uswin.ad.vzwcorp.com ([10.97.42.201]) with mapi; Wed, 13 Mar 2013 09:31:42 -0400
From: "Bogineni, Kalyani" 
To: 'Alex Agranovsky' , "rtcweb@ietf.org" 
Date: Wed, 13 Mar 2013 09:31:42 -0400
Thread-Topic: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: Ac4f7jhmTgrd5SE0S0e0buG3NBingwAAEspg
References:    <51407E37.7090307@voxeo.com>
In-Reply-To: <51407E37.7090307@voxeo.com>
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_4FB1AF8D91129944881538CDCC5347CF03206857EDOHDUB02EXCV33_"
MIME-Version: 1.0
Message-Id: <20130313133146.3782721F8CBB@ietfa.amsl.com>
X-Mailman-Approved-At: Wed, 13 Mar 2013 07:03:38 -0700
Cc: "Bogineni, Kalyani" 
Subject: Re: [rtcweb] Agenda time request for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 13:31:56 -0000

--_000_4FB1AF8D91129944881538CDCC5347CF03206857EDOHDUB02EXCV33_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Mobile devices that run on 3GPP networks will already have AMR/AMR-WB codec=
s. Browsers should be
able to access those codecs on such devices. Does this make the proposal 'o=
ptional mandatory'?

Regards,
Kalyani Bogineni


From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Alex Agranovsky
Sent: Wednesday, March 13, 2013 9:25 AM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01

It's hard to imagine a situation in which AMR/AMR-WB will be available at n=
o cost to the browser, considering royalties involved.

http://www.voiceage.com/amr_faqs.php#11

And if we limit the requirement only to those who have paid ... it's not re=
ally 'mandatory'.

- Alex

On 3/13/13 9:14 AM, Xavier Marjou wrote:

Here is a summary of the draft-marjou-rtcweb-audio-codecs-for-interop-00 pr=
esentation that I had prepared for yesterday's session:

- The co-authors want to underline that non-WebRTC voice endpoints usually =
use one of the following codecs: AMR, AMR-WB or G.722, which will result in=
 massive transcoding when there will be communications between WebRTC endpo=
ints and non-WebRTC endpoints.

- On one side, transcoding is bad for many reasons discussed in the draft (=
cost issues, intrinsic quality degradation, degraded interactivity, fallbac=
k from HD to G.711...);

- On the other side, it is recognized that implementing additional codecs i=
n the browsers can generate additional costs.

- In order to reach a compromise, we would like to add some text in the WG =
draft draft-ietf-rtcweb-audio providing incentives for the browser to use t=
hese three codecs: make them mandatory to implement when there is no cost i=
mpact on the browser (e.g. if codec already installed, paid by the device v=
endor...).

Any opinion on that?

Cheers,

Xavier

PS: I will be ready to present the slides on Thursday if time permits it.

(c.f. http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf )



On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie > wrote:
Magnus and I discussed this this morning, and we encourage you to
prepare something.  If the discussion of working group last call items
runs short, we may be able to fit this in at that time or at the end
of day one if its full agenda his finished.  This is not a commitment,
however, so please try and get discussion on the list on the points
from the draft you feel need resolution.

regards,

Ted


On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)
> wrote:
> Hello,
>
>
>
> I would like to request agenda time for:
>
>
>
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
>
>
> The document  presents use-cases underlining why WebRTC needs AMR-WB,  AM=
R
> and G.722 as additional relevant voice codecs to satisfactorily ensure
> interoperability with existing systems.
>
>
>
> A 10-minute time slot should be sufficient for presentation and discussio=
n.
>
>
>
> Regards
>
>
>
> -Espen
>
>
>
>
>
>
> _______________________________________________
> 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


--_000_4FB1AF8D91129944881538CDCC5347CF03206857EDOHDUB02EXCV33_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


=
Mobile devices that run on 3GPP networks will already have AMR/AMR-W=
B codecs. Browsers should be
able to access those codecs on such devices. Does this make the proposal=
 ‘optional mandatory’?
 
Regards,
Kalyani Bogineni=

 
 
From: rtcweb-bounces@ietf.org [mail=
to:rtcweb-bounces@ietf.org] On Behalf Of Alex Agranovsky
Sent:=
 Wednesday, March 13, 2013 9:25 AM
To: rtcweb@ietf.org
=
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio=
-codecs-for-interop-01
 
It's hard to imagine a sit=
uation in which AMR/AMR-WB will be available at no cost to the browser, con=
sidering royalties involved.

http://www.voiceage.com/amr_faqs.php#11

And if we l=
imit the requirement only to those who have paid ... it's not really 'manda=
tory'.

- Alex

On 3/13/13 9:14 AM, Xavier Marjou wrote:
Here is a summary of the draft-marjou-rtcweb-audio-co=
decs-for-interop-00 presentation that I had prepared for yesterday's sessio=
n:
- The co-authors want to underline=
 that non-WebRTC voice endpoints usually use one of the following codecs: A=
MR, AMR-WB or G.722, which will result in massive transcoding when there wi=
ll be communications between WebRTC endpoints and non-WebRTC endpoints.
- On one side, transcoding is bad for ma=
ny reasons discussed in the draft (cost issues, intrinsic quality degradati=
on, degraded interactivity, fallback from HD to G.711...);
- On the other side, it is recognized that implementi=
ng additional codecs in the browsers can generate additional costs.
- In order to reach a compromise, we would l=
ike to add some text in the WG draft draft-ietf-rtcweb-audio providing ince=
ntives for the browser to use these three codecs: make them mandatory to im=
plement when there is no cost impact on the browser (e.g. if codec already =
installed, paid by the device vendor...).
Any opinion on that?
Cheers,
Xavier
PS: I will be ready to present the slides on Thursday if time permits =
it.
(c.f. http://tools.ietf.org/agenda=
/86/slides/slides-86-rtcweb-6.pdf )
 
 
On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie <ted.ietf@gmail.com> wr=
ote:
Magnus and I discussed this this mo=
rning, and we encourage you to
prepare something.  If the discussio=
n of working group last call items
runs short, we may be able to fit thi=
s in at that time or at the end
of day one if its full agenda his finish=
ed.  This is not a commitment,
however, so please try and get discu=
ssion on the list on the points
from the draft you feel need resolution.=


regards,

Ted

On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)
<espeberg@cisco.com> wrote:
> H=
ello,
>
>
>
> I would like to request agenda time f=
or:
>
>
>
> draft-marjou-rtcweb-audio-codecs-for-in=
terop-01
>
>
>
> The document  presents use-ca=
ses underlining why WebRTC needs AMR-WB,  AMR
> and G.722 as add=
itional relevant voice codecs to satisfactorily ensure
> interoperabi=
lity with existing systems.
>
>
>
> A 10-minute tim=
e slot should be sufficient for presentation and discussion.
>
>=
;
>
> Regards
>
>
>
> -Espen
>>
>
>
>
>
<=
p class=3DMsoNormal>> _______________________________________________> rtcweb mailing list
> rtcweb=
@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
&=
gt;
_______________________________________________
rtcweb mailing li=
st
rtcweb@ietf.org
https://www=
.ietf.org/mailman/listinfo/rtcweb




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

--_000_4FB1AF8D91129944881538CDCC5347CF03206857EDOHDUB02EXCV33_--

From harald@alvestrand.no  Wed Mar 13 07: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 AFA8821F8CB7 for ; Wed, 13 Mar 2013 07:05:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.641
X-Spam-Level: 
X-Spam-Status: No, score=-110.641 tagged_above=-999 required=5 tests=[AWL=-0.043, 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 6qoTpxPB72sD for ; Wed, 13 Mar 2013 07:05:52 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6ED21F8C72 for ; Wed, 13 Mar 2013 07:05:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6E97839E1F8 for ; Wed, 13 Mar 2013 15:05:51 +0100 (CET)
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 q2LbDhaLq6Sl for ; Wed, 13 Mar 2013 15:05:49 +0100 (CET)
Received: from [IPv6:2001:df8:0:16:dc4b:da73:da24:d309] (unknown [IPv6:2001:df8:0:16:dc4b:da73:da24:d309]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id F310A39E1EE for ; Wed, 13 Mar 2013 15:05:48 +0100 (CET)
Message-ID: <514087BA.7000709@alvestrand.no>
Date: Wed, 13 Mar 2013 15:05:46 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References:   
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010207080903090800080907"
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 14:05:53 -0000

This is a multi-part message in MIME format.
--------------010207080903090800080907
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

High level thoughts from a browser implementor:

- The first target of WebRTC is the browser to browser case. These 
codecs do not add any capability to the browser to browser case, because 
OPUS is available.

- In the most common browser distribution models, it is an advantage to 
include at least a fallback version of all available features in the 
binary, so that the set of features available to the user is constant. 
This means that the browser either incurs licensing costs or support 
costs (to support the variability of user scenarios).

- The inclusion of royalty-required codecs severely crimps the 
distribution models available for browsers, which makes it even harder 
for new browsers to enter the market than it already is, and the WG 
charter we agreed on says that we "prefer non-encumbered codecs".

We can discuss the cost of transcoding separately, but the cost to the 
browsers of extra codecs, especially royalty-encumbered ones, should not 
be underestimated.

On 03/13/2013 02:14 PM, Xavier Marjou wrote:
>
> Here is a summary of the 
> draft-marjou-rtcweb-audio-codecs-for-interop-00 presentation that I 
> had prepared for yesterday's session:
>
> - The co-authors want to underline that non-WebRTC voice endpoints 
> usually use one of the following codecs: AMR, AMR-WB or G.722, which 
> will result in massive transcoding when there will be communications 
> between WebRTC endpoints and non-WebRTC endpoints.
>
> - On one side, transcoding is bad for many reasons discussed in the 
> draft (cost issues, intrinsic quality degradation, degraded 
> interactivity, fallback from HD to G.711...);
>
> - On the other side, it is recognized that implementing additional 
> codecs in the browsers can generate additional costs.
>
> - In order to reach a compromise, we would like to add some text in 
> the WG draft draft-ietf-rtcweb-audio providing incentives for the 
> browser to use these three codecs: make them mandatory to implement 
> when there is no cost impact on the browser (e.g. if codec already 
> installed, paid by the device vendor...).
>
> Any opinion on that?
>
> Cheers,
>
> Xavier
>
> PS: I will be ready to present the slides on Thursday if time permits it.
>
> (c.f. http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf )
>
>
>
> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie  > wrote:
>
>     Magnus and I discussed this this morning, and we encourage you to
>     prepare something.  If the discussion of working group last call items
>     runs short, we may be able to fit this in at that time or at the end
>     of day one if its full agenda his finished.  This is not a commitment,
>     however, so please try and get discussion on the list on the points
>     from the draft you feel need resolution.
>
>     regards,
>
>     Ted
>
>
>     On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)
>     > wrote:
>     > Hello,
>     >
>     >
>     >
>     > I would like to request agenda time for:
>     >
>     >
>     >
>     > draft-marjou-rtcweb-audio-codecs-for-interop-01
>     >
>     >
>     >
>     > The document  presents use-cases underlining why WebRTC needs
>     AMR-WB,  AMR
>     > and G.722 as additional relevant voice codecs to satisfactorily
>     ensure
>     > interoperability with existing systems.
>     >
>     >
>     >
>     > A 10-minute time slot should be sufficient for presentation and
>     discussion.
>     >
>     >
>     >
>     > Regards
>     >
>     >
>     >
>     > -Espen
>     >
>     >
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > 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


--------------010207080903090800080907
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
High level thoughts from a browser
      implementor:

      

      - The first target of WebRTC is the browser to browser case. These
      codecs do not add any capability to the browser to browser case,
      because OPUS is available.

      

      - In the most common browser distribution models, it is an
      advantage to include at least a fallback version of all available
      features in the binary, so that the set of features available to
      the user is constant. This means that the browser either incurs
      licensing costs or support costs (to support the variability of
      user scenarios).

      

      - The inclusion of royalty-required codecs severely crimps the
      distribution models available for browsers, which makes it even
      harder for new browsers to enter the market than it already is,
      and the WG charter we agreed on says that we "prefer
      non-encumbered codecs".

      

      We can discuss the cost of transcoding separately, but the cost to
      the browsers of extra codecs, especially royalty-encumbered ones,
      should not be underestimated.

      

      On 03/13/2013 02:14 PM, Xavier Marjou wrote:

    

    

      
Here is a summary of the
        draft-marjou-rtcweb-audio-codecs-for-interop-00 presentation
        that I had prepared for yesterday's session:

      
- The co-authors want to underline that
        non-WebRTC voice
        endpoints usually use one of the following codecs: AMR, AMR-WB
        or G.722, which
        will result in massive transcoding when there will be
        communications between
        WebRTC endpoints and non-WebRTC endpoints.

      
- On one side, transcoding is bad for many
        reasons
        discussed in the draft (cost issues, intrinsic quality
        degradation, degraded interactivity,
        fallback from HD to G.711...);

      
- On the other side, it is recognized that
        implementing
        additional codecs in the browsers can generate additional costs.

      
- In order to reach a compromise, we would
        like to add
        some text in the WG draft draft-ietf-rtcweb-audio providing
        incentives for the
        browser to use these three codecs: make them mandatory to
        implement when there
        is no cost impact on the browser (e.g. if codec already
        installed, paid by the
        device vendor...).

      
Any opinion on that?

      
Cheers,

      
Xavier

      
PS: I will be ready to present the slides
        on Thursday if time
        permits it.

      
(c.f. http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf
        )

      


      

      

      
On Thu, Mar 7, 2013 at 11:18 AM, Ted
        Hardie <ted.ietf@gmail.com>
        wrote:

        

          Magnus and I discussed this this morning, and we encourage you
          to

          prepare something.  If the discussion of working group last
          call items

          runs short, we may be able to fit this in at that time or at
          the end

          of day one if its full agenda his finished.  This is not a
          commitment,

          however, so please try and get discussion on the list on the
          points

          from the draft you feel need resolution.

          

          regards,

          

          Ted

          

            


              

              On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)

              <espeberg@cisco.com>
              wrote:

              > Hello,

              >

              >

              >

              > I would like to request agenda time for:

              >

              >

              >

              > draft-marjou-rtcweb-audio-codecs-for-interop-01

              >

              >

              >

              > The document  presents use-cases underlining why
              WebRTC needs AMR-WB,  AMR

              > and G.722 as additional relevant voice codecs to
              satisfactorily ensure

              > interoperability with existing systems.

              >

              >

              >

              > A 10-minute time slot should be sufficient for
              presentation and discussion.

              >

              >

              >

              > Regards

              >

              >

              >

              > -Espen

              >

              >

              >

              >

              >

              >

            

          

          

            
>
              _______________________________________________

              > 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


    

    

  


--------------010207080903090800080907--

From ron@debian.org  Wed Mar 13 07:27: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 7209A21F8B20 for ; Wed, 13 Mar 2013 07:27:46 -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 PD2HH4498IR6 for ; Wed, 13 Mar 2013 07:27:45 -0700 (PDT)
Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id EA4ED21F8D8F for ; Wed, 13 Mar 2013 07:27:34 -0700 (PDT)
Received: from ppp118-210-121-105.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([118.210.121.105]) by ipmail06.adl2.internode.on.net with ESMTP; 14 Mar 2013 00:57:33 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id D68724F8F3; Thu, 14 Mar 2013 00:57:32 +1030 (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 z7iB8iz2Fy88; Thu, 14 Mar 2013 00:57:32 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 265864F902; Thu, 14 Mar 2013 00:57:32 +1030 (CST)
Date: Thu, 14 Mar 2013 00:57:32 +1030
From: Ron 
To: Xavier Marjou , rtcweb@ietf.org
Message-ID: <20130313142732.GE12022@audi.shelbyville.oz>
References:   
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 14:27:46 -0000

Hi Xavier,

On Wed, Mar 13, 2013 at 09:14:30AM -0400, Xavier Marjou wrote:
> Here is a summary of the draft-marjou-rtcweb-audio-codecs-for-interop-00
> presentation that I had prepared for yesterday's session:
> 
> - The co-authors want to underline that non-WebRTC voice endpoints usually
> use one of the following codecs: AMR, AMR-WB or G.722, which will result in
> massive transcoding when there will be communications between WebRTC
> endpoints and non-WebRTC endpoints.

"Massive" seems a little overstated here.  Any system providing a gateway
service to or between 'low bandwidth' devices is almost surely going to
support more than just WebRTC, and is going to have to transcode for most
or all of them anyway.  Adding an extra burden to WebRTC, especially one
that would only ever apply to some small subset of users, wouldn't appear
to make a significant difference in the requirements for such a system.


> - On one side, transcoding is bad for many reasons discussed in the draft
> (cost issues, intrinsic quality degradation, degraded interactivity,
> fallback from HD to G.711...);

Are you aware of the listening tests presented to the CODEC WG?

In particular the ones that show Opus->AMR and AMR->Opus is not significantly
worse than the intrinsic quality degradation suffered by using AMR alone?

Or that Opus->G.711->AMR is actually better than AMR->G.711->AMR ?


> - On the other side, it is recognized that implementing additional codecs
> in the browsers can generate additional costs.
> 
> - In order to reach a compromise, we would like to add some text in the WG
> draft draft-ietf-rtcweb-audio providing incentives for the browser to use
> these three codecs: make them mandatory to implement when there is no cost
> impact on the browser (e.g. if codec already installed, paid by the device
> vendor...).

Since there is never no cost impact to supporting additional features, that
would imply this is never mandatory ...

In which case why bother half-saying otherwise?

I thought it was already quite clear all along, that people who want to or
have their own good reasons to are free to implement any other codecs they
please - and that they already have, and certainly will continue to do so?

> Any opinion on that?

I don't really see much point to handwaving about particular niche codecs
for particular niche uses unless this is going to be some sort of separate
informational document, that is kept up to date with changes in all the
niches that people have an interest in.

That might be useful.  But 'mandating' something that the people who will
do it were going to do it anyway, and the people who were not are still
not going to do, doesn't seem to add any real value here to either users
or implementers.  It won't explain anything to anybody that they don't
already know if it is of any interest to them.

 Cheers,
 Ron



From prvs=3784b6b78c=aallen@blackberry.com  Wed Mar 13 07: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 CE74F21F8DBB for ; Wed, 13 Mar 2013 07:30:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.31
X-Spam-Level: 
X-Spam-Status: No, score=-5.31 tagged_above=-999 required=5 tests=[AWL=-0.108,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 a7z9-FBID3Xm for ; Wed, 13 Mar 2013 07:30:33 -0700 (PDT)
Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 800D721F8CEF for ; Wed, 13 Mar 2013 07:30:32 -0700 (PDT)
X-AuditID: 0a41282f-b7fa06d000002431-42-51408d7d14d4
Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) by mhs060cnc.rim.net (SBG) with SMTP id 01.05.09265.E7D80415; Wed, 13 Mar 2013 09:30:22 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 09:30:21 -0500
From: Andrew Allen 
To: Xavier Marjou , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOH+y5qq47PO3D8ky8VwcKUkGl6pijrV3A
Date: Wed, 13 Mar 2013 14:30:20 +0000
Message-ID: 
References:   
In-Reply-To: 
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.252]
Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338D2870FXMB104ADSrimnet_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNKsWRmVeSWpSXmKPExsXC5ZyvpVvX6xBoMGulkMXaf+3sFke2rmV2 YPJYsuQnk0fLs5NsAUxRDYw2SYklZcGZ6Xn6djaJeXn5JYklqQopqcXJtko+qemJOQoBRZll icmVCi6Zxck5iZm5qUVKCpkptkomSgoFOYnJqbmpeSW2SokFBal5KUp2XAoYwAaoLDNPITUv OT8lMy/dVskz2F/XwsLUUtdQyU43oZMnY/v0M+wFH3Mqjt5bxd7A2BvXxcjJISFgIvHuTTcj hC0mceHeerYuRi4OIYGVjBL/5sxlgnA2M0r8//IErIpNQEti/+HpTCC2iECwxMG9W1hBbGGB eInze+cyQ8QTJP58/s0OYRtJLD+8EcxmEVCVOD3vDFgvr4CHxKKnM8F6hQRuMUqcm1QMYnMK BEo8argEFmcUkJXYffY6WD2zgLjErSfzmSAuFZBYsuc8M4QtKvHy8T9WCFtR4nFLNwtEfb7E 1DMH2SB2CUqcnPmEZQKjyCwko2YhKZuFpAwiriOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKv YhTMzSg2MDNIzkvWK8rM1ctLLdnECEogjhr6Oxjfvrc4xCjAwajEw2vV6hAoxJpYVlyZe4hR goNZSYR3eS5QiDclsbIqtSg/vqg0J7X4EGMQMLQmMktxJ+cDk1teSbyxgQGRHCVxXpFA0UAh gXRgIstOTS1ILYIZysTBCbKUS0qkGJiOUosSS0sy4kFJM74YmDalGhgPbloXJno8bfG75YvS dbkd81fv4DYKuegRfVt20d8fVa5TTL4U2LzQUgiZJWr7LaiTi+u5Asvm1lPZ6x8zOT2JK99t Fth67rK4bcYmTa/z6sYzd4vv6X8Wd0TM/7hcwZWmL/O+/lpVKWB67yOT8LIldRc52jUv/RP7 YbduwjPLGwKZy5Z/SedTYinOSDTUYi4qTgQA9ide424DAAA=
Subject: Re: [rtcweb] Agenda time request for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 14:30:34 -0000

--_000_BBF5DDFE515C3946BC18D733B20DAD2338D2870FXMB104ADSrimnet_
Content-Type: text/plain; charset="us-ascii"
content-transfer-encoding: quoted-printable


I think this draft is not consistent with the scope stated by the RTCweb cha=
irs in the decision on this topic  back in February

"Additional Relevant Codecs". That can contain a list of codecs which are re=
levant in specific  contexts, along with a short description of the context=
 for each. Specifically there seems to be interest in understanding the  adv=
antages and costs of G.722, AMR, and AMR-WB. We hope that text would broaden=
 understanding of the WebRTC use case contexts.
The current draft goes way beyond that decision in scope and uses MUST and S=
HOULD strength normative language instead of focusing on identifying the adv=
antages and costs of the specific codecs and the use case contexts of where=
 they are useful.

I think we should stick to the scope defined by the chairs and remove the no=
rmative language and focus on identifying the advantages and costs of the sp=
ecific codecs and the use case contexts of where they are useful..

Andrew

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Xavier Marjou
Sent: Wednesday, March 13, 2013 9:15 AM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-code=
cs-for-interop-01


Here is a summary of the draft-marjou-rtcweb-audio-codecs-for-interop-00 pre=
sentation that I had prepared for yesterday's session:

- The co-authors want to underline that non-WebRTC voice endpoints usually u=
se one of the following codecs: AMR, AMR-WB or G.722, which will result in m=
assive transcoding when there will be communications between WebRTC endpoint=
s and non-WebRTC endpoints.

- On one side, transcoding is bad for many reasons discussed in the draft (c=
ost issues, intrinsic quality degradation, degraded interactivity, fallback=
 from HD to G.711...);

- On the other side, it is recognized that implementing additional codecs in=
 the browsers can generate additional costs.

- In order to reach a compromise, we would like to add some text in the WG d=
raft draft-ietf-rtcweb-audio providing incentives for the browser to use the=
se three codecs: make them mandatory to implement when there is no cost impa=
ct on the browser (e.g. if codec already installed, paid by the device vendo=
r...).

Any opinion on that?

Cheers,

Xavier

PS: I will be ready to present the slides on Thursday if time permits it.

(c.f. http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf )



On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie > wrote:
Magnus and I discussed this this morning, and we encourage you to
prepare something.  If the discussion of working group last call items
runs short, we may be able to fit this in at that time or at the end
of day one if its full agenda his finished.  This is not a commitment,
however, so please try and get discussion on the list on the points
from the draft you feel need resolution.

regards,

Ted


On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)
> wrote:
> Hello,
>
>
>
> I would like to request agenda time for:
>
>
>
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
>
>
> The document  presents use-cases underlining why WebRTC needs AMR-WB,  AMR
> and G.722 as additional relevant voice codecs to satisfactorily ensure
> interoperability with existing systems.
>
>
>
> A 10-minute time slot should be sufficient for presentation and discussion=
.
>
>
>
> Regards
>
>
>
> -Espen
>
>
>
>
>
>
> _______________________________________________
> 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


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

--_000_BBF5DDFE515C3946BC18D733B20DAD2338D2870FXMB104ADSrimnet_
Content-Type: text/html; charset="us-ascii"
content-transfer-encoding: quoted-printable











 

I think this draft is not c=
onsistent with the scope stated by the RTCweb chairs in the decision on this=
 topic  back in February


"Additional Relevant Codecs". That can c=
ontain a list of codecs which are relevant in specific  contexts, along=
 with a short description of the context for each. Specifically there seems=
 to be interest in understanding the  advantages
 and costs of G.722, AMR, and AMR-WB. We hope that text would broaden unders=
tanding of the WebRTC use case contexts.


The current draft
goes way beyond that decision in scope and=
 uses MUST and SHOULD strength normative language instead of focusing on ide=
ntifying the advantages and costs of the specific codecs
 and the use case contexts of where they are useful.


 

I think we should stick to=
 the scope defined by the chairs and remove the normative language and focus=
 on
identifying the advantages and costs of the=
 specific codecs and the use case contexts of where they are useful.<=
span style=3D"font-size:11.0pt;font-family:"Calibri","sans-se=
rif";color:#1F497D">.


 

Andrew

 

From: rtcweb-boun=
ces@ietf.org [mailto:rtcweb-bounces@ietf.org]
On Behalf Of Xavier Marjou

Sent: Wednesday, March 13, 2013 9:15 AM

To: rtcweb@ietf.org

Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-aud=
io-codecs-for-interop-01


 


Here is a summary of the draft-marjou-rtcweb-audio=
-codecs-for-interop-00 presentation that I had prepared for yesterday's sess=
ion:


- The co-authors want to underline that non-WebRTC=
 voice endpoints usually use one of the following codecs: AMR, AMR-WB or G.7=
22, which will result in massive transcoding when there will be communicatio=
ns between WebRTC endpoints and
 non-WebRTC endpoints.


- On one side, transcoding is bad for many reasons=
 discussed in the draft (cost issues, intrinsic quality degradation, degrade=
d interactivity, fallback from HD to G.711...);


- On the other side, it is recognized that impleme=
nting additional codecs in the browsers can generate additional costs.<=
/o:p>


- In order to reach a compromise, we would like to=
 add some text in the WG draft draft-ietf-rtcweb-audio providing incentives=
 for the browser to use these three codecs: make them mandatory to implement=
 when there is no cost impact on
 the browser (e.g. if codec already installed, paid by the device vendor...)=
.


Any opinion on that?


Cheers,


Xavier


PS: I will be ready to present the slides on Thurs=
day if time permits it.


(c.f. 
http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf )


 


 




On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie <ted.ietf@gmail.com>=
; wrote:


Magnus and I discussed this this morning, and we enco=
urage you to

prepare something.  If the discussion of working group last call items<=
br>
runs short, we may be able to fit this in at that time or at the end

of day one if its full agenda his finished.  This is not a commitment,<=
br>
however, so please try and get discussion on the list on the points

from the draft you feel need resolution.



regards,



Ted










On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)

<espeberg@cisco.com> wrote:<=
br>
> Hello,

>

>

>

> I would like to request agenda time for:

>

>

>

> draft-marjou-rtcweb-audio-codecs-for-interop-01

>

>

>

> The document  presents use-cases underlining why WebRTC needs AMR-=
WB,  AMR

> and G.722 as additional relevant voice codecs to satisfactorily ensure<=
br>
> interoperability with existing systems.

>

>

>

> A 10-minute time slot should be sufficient for presentation and discuss=
ion.

>

>

>

> Regards

>

>

>

> -Espen

>

>

>

>

>

>










> _______________________________________________<=
br>
> rtcweb mailing list

> rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb

>

_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/rtcweb








 



--------------------------------------------------------------------- 

This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.



--_000_BBF5DDFE515C3946BC18D733B20DAD2338D2870FXMB104ADSrimnet_--

From Kalyani.Bogineni@VerizonWireless.com  Wed Mar 13 07:21: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 9030A21F8D87 for ; Wed, 13 Mar 2013 07:21:16 -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 ecjKw+GEjBXh for ; Wed, 13 Mar 2013 07:21:13 -0700 (PDT)
Received: from vanguard.verizonwireless.com (vanguard.verizonwireless.com [162.115.35.70]) by ietfa.amsl.com (Postfix) with ESMTP id 320FB21F87FB for ; Wed, 13 Mar 2013 07:21:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizonwireless.com; i=@verizonwireless.com; l=0; q=dns/txt; s=prodmail; t=1363184473; x=1394720473; h=from:to:cc:date:subject:references:in-reply-to: mime-version; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=eBdbCcNBaaMtr0ryAovTVmPPP7Y03ZQZeIXoxlaQ2yfvRVU/jQ91aeRh 7b9XsOHu/28ZjS2I9joLnCTZfcXyFRadmfv0dBlWPdz9b7WB1hp/47WM4 jZ+DtdcZ3h5QFgupUFPsch+192ibxYKssJ803XKXQpOZE+JPtVkAL8H1E A=;
Received: from ohdub02exhub04.uswin.ad.vzwcorp.com ([10.97.42.166]) by vanguard.verizonwireless.com with ESMTP; 13 Mar 2013 07:21:09 -0700
Received: from OHDUB02EXCV33.uswin.ad.vzwcorp.com ([10.97.42.179]) by OHDUB02EXHUB04.uswin.ad.vzwcorp.com ([10.97.42.166]) with mapi; Wed, 13 Mar 2013 10:20:48 -0400
From: "Bogineni, Kalyani" 
To: 'Harald Alvestrand' , "rtcweb@ietf.org" 
Date: Wed, 13 Mar 2013 10:20:48 -0400
Thread-Topic: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: Ac4f8+gIEv6EzAQ8SA6mabbFRBM0PAAATzuw
References:    <514087BA.7000709@alvestrand.no>
In-Reply-To: <514087BA.7000709@alvestrand.no>
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_4FB1AF8D91129944881538CDCC5347CF03206857EEOHDUB02EXCV33_"
MIME-Version: 1.0
Message-Id: <20130313142113.320FB21F87FB@ietfa.amsl.com>
X-Mailman-Approved-At: Wed, 13 Mar 2013 07:32:14 -0700
Cc: "Bogineni, Kalyani" 
Subject: Re: [rtcweb] Agenda time request for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 14:21:16 -0000

--_000_4FB1AF8D91129944881538CDCC5347CF03206857EEOHDUB02EXCV33_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Section 4.3.1 of  draft-ietf-rtcweb-use-cases-and-requirements-10.txt
has usecases for mobile devices.

Here is the exact wording from the WG charter:

"..The working group cannot explicitly rule out the possibility of adopting=
 encumbered
technologies; however, the working group will try to avoid encumbered
technologies that require royalties or other encumbrances that would
prevent such technologies from being easy to use in web browsers."
So the proposal to include support for AMR/AMR-WB is within the scope of th=
e
current work.

Regards,
Kalyani Bogineni

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Harald Alvestrand
Sent: Wednesday, March 13, 2013 10:06 AM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01

High level thoughts from a browser implementor:

- The first target of WebRTC is the browser to browser case. These codecs d=
o not add any capability to the browser to browser case, because OPUS is av=
ailable.

- In the most common browser distribution models, it is an advantage to inc=
lude at least a fallback version of all available features in the binary, s=
o that the set of features available to the user is constant. This means th=
at the browser either incurs licensing costs or support costs (to support t=
he variability of user scenarios).

- The inclusion of royalty-required codecs severely crimps the distribution=
 models available for browsers, which makes it even harder for new browsers=
 to enter the market than it already is, and the WG charter we agreed on sa=
ys that we "prefer non-encumbered codecs".

We can discuss the cost of transcoding separately, but the cost to the brow=
sers of extra codecs, especially royalty-encumbered ones, should not be und=
erestimated.

On 03/13/2013 02:14 PM, Xavier Marjou wrote:

Here is a summary of the draft-marjou-rtcweb-audio-codecs-for-interop-00 pr=
esentation that I had prepared for yesterday's session:

- The co-authors want to underline that non-WebRTC voice endpoints usually =
use one of the following codecs: AMR, AMR-WB or G.722, which will result in=
 massive transcoding when there will be communications between WebRTC endpo=
ints and non-WebRTC endpoints.

- On one side, transcoding is bad for many reasons discussed in the draft (=
cost issues, intrinsic quality degradation, degraded interactivity, fallbac=
k from HD to G.711...);

- On the other side, it is recognized that implementing additional codecs i=
n the browsers can generate additional costs.

- In order to reach a compromise, we would like to add some text in the WG =
draft draft-ietf-rtcweb-audio providing incentives for the browser to use t=
hese three codecs: make them mandatory to implement when there is no cost i=
mpact on the browser (e.g. if codec already installed, paid by the device v=
endor...).

Any opinion on that?

Cheers,

Xavier

PS: I will be ready to present the slides on Thursday if time permits it.

(c.f. http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf )



On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie > wrote:
Magnus and I discussed this this morning, and we encourage you to
prepare something.  If the discussion of working group last call items
runs short, we may be able to fit this in at that time or at the end
of day one if its full agenda his finished.  This is not a commitment,
however, so please try and get discussion on the list on the points
from the draft you feel need resolution.

regards,

Ted


On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)
> wrote:
> Hello,
>
>
>
> I would like to request agenda time for:
>
>
>
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
>
>
> The document  presents use-cases underlining why WebRTC needs AMR-WB,  AM=
R
> and G.722 as additional relevant voice codecs to satisfactorily ensure
> interoperability with existing systems.
>
>
>
> A 10-minute time slot should be sufficient for presentation and discussio=
n.
>
>
>
> Regards
>
>
>
> -Espen
>
>
>
>
>
>
> _______________________________________________
> 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


--_000_4FB1AF8D91129944881538CDCC5347CF03206857EEOHDUB02EXCV33_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


=
Section 4.3.1 of  draft-ietf-rtcweb-use-cases-and-requirement=
s-10.txt
has=
 usecases for mobile devices.
 
Here is the exa=
ct wording from the WG charter:
“..The working group c=
annot explicitly rule out the possibility of adopting encumbered 
techno=
logies; however, the working group will try to avoid encumbered 
technol=
ogies that require royalties or other encumbrances that would 
prevent s=
uch technologies from being easy to use in web browsers.”<=
/span>
So the proposal to include support fo=
r AMR/AMR-WB is within the scope of the
current work.
 
Regards,
Kalyani Bogineni=

 
<=
p class=3DMsoNormal>From: rtcweb-bounces@ie=
tf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestra=
nd
Sent: Wednesday, March 13, 2013 10:06 AM
To: rtcweb@=
ietf.org
Subject: Re: [rtcweb] Agenda time request for draft-marj=
ou-rtcweb-audio-codecs-for-interop-01
 
High level =
thoughts from a browser implementor:

- The first target of WebRTC is=
 the browser to browser case. These codecs do not add any capability to the=
 browser to browser case, because OPUS is available.

- In the most c=
ommon browser distribution models, it is an advantage to include at least a=
 fallback version of all available features in the binary, so that the set =
of features available to the user is constant. This means that the browser =
either incurs licensing costs or support costs (to support the variability =
of user scenarios).

- The inclusion of royalty-required codecs sever=
ely crimps the distribution models available for browsers, which makes it e=
ven harder for new browsers to enter the market than it already is, and the=
 WG charter we agreed on says that we "prefer non-encumbered codecs&qu=
ot;.

We can discuss the cost of transcoding separately, but the cost=
 to the browsers of extra codecs, especially royalty-encumbered ones, shoul=
d not be underestimated.

On 03/13/2013 02:14 PM, Xavier Marjou wrote=
:
Here is a summary of the draft-marjou-rtcweb-=
audio-codecs-for-interop-00 presentation that I had prepared for yesterday'=
s session:
- The co-authors want to u=
nderline that non-WebRTC voice endpoints usually use one of the following c=
odecs: AMR, AMR-WB or G.722, which will result in massive transcoding when =
there will be communications between WebRTC endpoints and non-WebRTC endpoi=
nts.
- On one side, transcoding is ba=
d for many reasons discussed in the draft (cost issues, intrinsic quality d=
egradation, degraded interactivity, fallback from HD to G.711...);
- On the other side, it is recognized that im=
plementing additional codecs in the browsers can generate additional costs.=

- In order to reach a compromise, we=
 would like to add some text in the WG draft draft-ietf-rtcweb-audio provid=
ing incentives for the browser to use these three codecs: make them mandato=
ry to implement when there is no cost impact on the browser (e.g. if codec =
already installed, paid by the device vendor...).
Any opinion on that?
Che=
ers,
Xavier
PS: I will be ready to present the slides on Thursday if time =
permits it.
(c.f. http://tools.ietf.or=
g/agenda/86/slides/slides-86-rtcweb-6.pdf )
 
 
<=
div>
On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
Magnus and I discussed this=
 this morning, and we encourage you to
prepare something.  If the d=
iscussion of working group last call items
runs short, we may be able to=
 fit this in at that time or at the end
of day one if its full agenda hi=
s finished.  This is not a commitment,
however, so please try and g=
et discussion on the list on the points
from the draft you feel need res=
olution.

regards,

Ted


On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)
&l=
t;espeberg@cisco.com> wrote:> Hello,
>
>
>
> I would like to request agend=
a time for:
>
>
>
> draft-marjou-rtcweb-audio-codec=
s-for-interop-01
>
>
>
> The document  present=
s use-cases underlining why WebRTC needs AMR-WB,  AMR
> and G.72=
2 as additional relevant voice codecs to satisfactorily ensure
> inte=
roperability with existing systems.
>
>
>
> A 10-mi=
nute time slot should be sufficient for presentation and discussion.
>=
;
>
>
> Regards
>
>
>
> -Espen>
>
>
>
>
>




_______________=
________________________________
rtcweb mailing list
rtcweb@ietf.org<=
o:p>
https://www.ietf.org/mailman/listinfo/rtcweb
 
=

--_000_4FB1AF8D91129944881538CDCC5347CF03206857EEOHDUB02EXCV33_--

From oej@edvina.net  Wed Mar 13 07:38: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 0E71A21F8E0C for ; Wed, 13 Mar 2013 07:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level: 
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.099,  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 iUNtTVdLzIUm for ; Wed, 13 Mar 2013 07:38:37 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 5581221F86EC for ; Wed, 13 Mar 2013 07:38:36 -0700 (PDT)
Received: from [192.168.40.23] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id C368393DE3E; Wed, 13 Mar 2013 14:38:19 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail=_4838ECE4-51C5-4AF3-8E7B-687599231E64"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: "Olle E. Johansson" 
In-Reply-To: <514087BA.7000709@alvestrand.no>
Date: Wed, 13 Mar 2013 15:37:58 +0100
Message-Id: 
References:    <514087BA.7000709@alvestrand.no>
To: Harald Alvestrand 
X-Mailer: Apple Mail (2.1499)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 14:38:39 -0000

--Apple-Mail=_4838ECE4-51C5-4AF3-8E7B-687599231E64
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


13 mar 2013 kl. 15:05 skrev Harald Alvestrand :

>> - The co-authors want to underline that non-WebRTC voice endpoints =
usually use one of the following codecs: AMR, AMR-WB or G.722, which =
will result in massive transcoding when there will be communications =
between WebRTC endpoints and non-WebRTC endpoints.
>>=20
I have a large amount of SIP phones on my desk, none which support AMR =
and/or AMR-WB. I had to pay extra for AMR in a SIP phone for my iPhone.

I don't agree with the standpoint that AMR is implemented on a majority =
of traditional non-WebRTC endpoints.

/O=

--Apple-Mail=_4838ECE4-51C5-4AF3-8E7B-687599231E64
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

harald@alvestrand.no>:
- The =
co-authors want to underline that non-WebRTC voice endpoints usually use =
one of the following codecs: AMR, AMR-WB or G.722, which will result in =
massive transcoding when there will be communications between WebRTC =
endpoints and non-WebRTC endpoints.
I =
have a large amount of SIP phones on my desk, none which support AMR =
and/or AMR-WB. I had to pay extra for AMR in a SIP phone for my =
iPhone.

I don't agree with the standpoint that AMR is =
implemented on a majority of traditional non-WebRTC =
endpoints.

/O
=

--Apple-Mail=_4838ECE4-51C5-4AF3-8E7B-687599231E64--

From oej@edvina.net  Wed Mar 13 07:41: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 731DA21F8D77 for ; Wed, 13 Mar 2013 07:41:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.513
X-Spam-Level: 
X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086,  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 7A6834P8r9z1 for ; Wed, 13 Mar 2013 07:41:21 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id BBA6421F85D4 for ; Wed, 13 Mar 2013 07:41:20 -0700 (PDT)
Received: from [192.168.40.23] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id D685693DE41; Wed, 13 Mar 2013 14:41:04 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: "Olle E. Johansson" 
In-Reply-To: <20130313142732.GE12022@audi.shelbyville.oz>
Date: Wed, 13 Mar 2013 15:40:34 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7897A33F-F73A-4C39-B4DA-16F014A43C5C@edvina.net>
References:    <20130313142732.GE12022@audi.shelbyville.oz>
To: Ron 
X-Mailer: Apple Mail (2.1499)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 14:41:21 -0000

13 mar 2013 kl. 15:27 skrev Ron :

>> these three codecs: make them mandatory to implement when there is no =
cost
>> impact on the browser (e.g. if codec already installed, paid by the =
device
>> vendor...).
I would like to propose that someone (it's out of scope for this group) =
make it mandatory
to implement open APIs so that all applications on these devices can use =
all the
codecs implemented in hardware. That's not the case now.=20

/O=

From xavier.marjou@gmail.com  Wed Mar 13 07:43: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 8DFE121F8B9F for ; Wed, 13 Mar 2013 07:43: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 jjBEKbeyyobN for ; Wed, 13 Mar 2013 07:43:36 -0700 (PDT)
Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id ECD5B21F85D4 for ; Wed, 13 Mar 2013 07:43:35 -0700 (PDT)
Received: by mail-la0-f41.google.com with SMTP id fo12so1218728lab.28 for ; Wed, 13 Mar 2013 07:43:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=eJRoZNf6HQaTCtta3dCg5lJlFPlySNBU2n9KjGnbLaE=; b=vAT9d3XyGx0K09z+DWNcfyEdjQEIFGIBep2R49qIOii4Vt9LfBTuK9IC7k7q5GpLN1 7tJhgntoEYXulW9jDTmUbxrzeC1/s/CR0VxmHDSd0c9tKG0HN/DlVurr+PAHmne1VbJw qsklIBqnmcOSkBXXWcnJw/hP1Ehqed4Rtn0IGd5Weq2XbaPi/3pu4E7lZ702SAnlEQIB iLU724PjeGoMdeFT0xVTI3z/S35EJ6ZzQIH+zwNu4HUF8KwjtBd6dftdRwLeepaMcuOO W63LBNhRVeSSG5aEQ1Yq8YzBFj7xVzxlzEpstUXma56m5PTWlVdKErdhaxhkKhS6X01b /F8g==
MIME-Version: 1.0
X-Received: by 10.112.41.101 with SMTP id e5mr7531091lbl.120.1363185814844; Wed, 13 Mar 2013 07:43:34 -0700 (PDT)
Received: by 10.114.7.167 with HTTP; Wed, 13 Mar 2013 07:43:34 -0700 (PDT)
In-Reply-To: 
References:    <514087BA.7000709@alvestrand.no> 
Date: Wed, 13 Mar 2013 10:43:34 -0400
Message-ID: 
From: Xavier Marjou 
To: rtcweb@ietf.org
Content-Type: multipart/alternative; boundary=e0cb4efe2f9c41d14b04d7cf6e78
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 14:43:37 -0000

--e0cb4efe2f9c41d14b04d7cf6e78
Content-Type: text/plain; charset=ISO-8859-1

---------- Forwarded message ----------
From: Xavier Marjou 
Date: Wed, Mar 13, 2013 at 10:43 AM
Subject: Re: [rtcweb] Agenda time request for
draft-marjou-rtcweb-audio-codecs-for-interop-01
To: Harald Alvestrand 



On Wed, Mar 13, 2013 at 10:05 AM, Harald Alvestrand wrote:

>  High level thoughts from a browser implementor:
>
> - The first target of WebRTC is the browser to browser case. These codecs
> do not add any capability to the browser to browser case, because OPUS is
> available.
>

I agree with that browser to browser communication within a given calling
service is the first target of most players. However, there's the need to
have options for interworking with "legacy" VoIP equipments for players who
also want to open WebRTC communications towards "legacy" devices. Our draft
shows that OPUS and G.711 are really not sufficient for that.


> - In the most common browser distribution models, it is an advantage to
> include at least a fallback version of all available features in the
> binary, so that the set of features available to the user is constant. This
> means that the browser either incurs licensing costs or support costs (to
> support the variability of user scenarios).
>
> - The inclusion of royalty-required codecs severely crimps the
> distribution models available for browsers, which makes it even harder for
> new browsers to enter the market than it already is, and the WG charter we
> agreed on says that we "prefer non-encumbered codecs".
>

Yes, we understand that, and we think the text we propose tries to motivate
all players of the WebRTC ecosystem to open their technologies. I think our
text is really not such a big constraint as I read it as a conditional
statement like "if some conditions are met regarding AMR, or AMR-WB or
G.722, then the browser offers the possibility to use this codec". All
conditions may not be met today for the browser implementor, perhaps only
tomorrow, but at least writing down will provide incentives for all players
to make efforts and go in that direction.


>
> We can discuss the cost of transcoding separately, but the cost to the
> browsers of extra codecs, especially royalty-encumbered ones, should not be
> underestimated.
>
>
> On 03/13/2013 02:14 PM, Xavier Marjou wrote:
>
> Here is a summary of the draft-marjou-rtcweb-audio-codecs-for-interop-00
> presentation that I had prepared for yesterday's session:
>
> - The co-authors want to underline that non-WebRTC voice endpoints usually
> use one of the following codecs: AMR, AMR-WB or G.722, which will result in
> massive transcoding when there will be communications between WebRTC
> endpoints and non-WebRTC endpoints.
>
> - On one side, transcoding is bad for many reasons discussed in the draft
> (cost issues, intrinsic quality degradation, degraded interactivity,
> fallback from HD to G.711...);
>
> - On the other side, it is recognized that implementing additional codecs
> in the browsers can generate additional costs.
>
> - In order to reach a compromise, we would like to add some text in the WG
> draft draft-ietf-rtcweb-audio providing incentives for the browser to use
> these three codecs: make them mandatory to implement when there is no cost
> impact on the browser (e.g. if codec already installed, paid by the device
> vendor...).
>
> Any opinion on that?
>
> Cheers,
>
> Xavier
>
> PS: I will be ready to present the slides on Thursday if time permits it.
>
> (c.f. http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf )
>
>
>
> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie  wrote:
>
>> Magnus and I discussed this this morning, and we encourage you to
>> prepare something.  If the discussion of working group last call items
>> runs short, we may be able to fit this in at that time or at the end
>> of day one if its full agenda his finished.  This is not a commitment,
>> however, so please try and get discussion on the list on the points
>> from the draft you feel need resolution.
>>
>> regards,
>>
>> Ted
>>
>>
>> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)
>>  wrote:
>> > Hello,
>> >
>> >
>> >
>> > I would like to request agenda time for:
>> >
>> >
>> >
>> > draft-marjou-rtcweb-audio-codecs-for-interop-01
>> >
>> >
>> >
>> > The document  presents use-cases underlining why WebRTC needs AMR-WB,
>>  AMR
>> > and G.722 as additional relevant voice codecs to satisfactorily ensure
>> > interoperability with existing systems.
>> >
>> >
>> >
>> > A 10-minute time slot should be sufficient for presentation and
>> discussion.
>> >
>> >
>> >
>> > Regards
>> >
>> >
>> >
>> > -Espen
>> >
>> >
>> >
>> >
>> >
>> >
>>   > _______________________________________________
>> > 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 listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--e0cb4efe2f9c41d14b04d7cf6e78
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



---------- Forwarded message ----------<=
br>From: Xavier Marjou =
<xavier.marjou@gmail.com&=
gt;

Date: Wed, Mar 13, 2013 at 10:43 AM
Subject: Re: [rtcweb] Agenda time re=
quest for draft-marjou-rtcweb-audio-codecs-for-interop-01
To: Harald Alv=
estrand <harald@alvestrand.no>




On Wed, Mar 13, 20=
13 at 10:05 AM, Harald Alvestrand <harald@alvestrand.no> =
wrote:




 =20
   =20
 =20
  

    
High level thoughts from a browser
      implementor:

      

      - The first target of WebRTC is the browser to browser case. These
      codecs do not add any capability to the browser to browser case,
      because OPUS is available.
=A0
=

I agree with that browser to browser communication within a give=
n calling service is the first target of most players. However, there's=
 the need to have=A0options =
for interworking with "legacy" VoIP=A0equipments for players who also want to open Web=
RTC communications towards "legacy" devices. Our draft shows that=
=A0OPUS and G.711 are really not sufficient for that.






      

      - In the most common browser distribution models, it is an
      advantage to include at least a fallback version of all available
      features in the binary, so that the set of features available to
      the user is constant. This means that the browser either incurs
      licensing costs or support costs (to support the variability of
      user scenarios).

      

      - The inclusion of royalty-required codecs severely crimps the
      distribution models available for browsers, which makes it even
      harder for new browsers to enter the market than it already is,
      and the WG charter we agreed on says that we "prefer
      non-encumbered codecs".
=A0
Yes, we understand that, and we think the text we propose trie=
s to motivate all players of the WebRTC ecosystem to open their technologie=
s. I think our text is really not such a big constraint as I read it as a c=
onditional statement like "if some conditions are met regarding AMR, o=
r AMR-WB or G.722, then the browser offers the possibility to use this code=
c". All conditions may not be met today for the browser implementor, p=
erhaps only tomorrow, but at least writing down will provide incentives for=
 all players to make efforts and go in that direction.




=A0

      

      We can discuss the cost of transcoding separately, but the cost to
      the browsers of extra codecs, especially royalty-encumbered ones,
      should not be underestimated.


      

      On 03/13/2013 02:14 PM, Xavier Marjou wrote:

    

    

      
Here is a summary of the
        draft-marjou-rtcweb-audio-codecs-for-interop-00 presentation
        that I had prepared for yesterday's session:

      
- The co-authors want to underline that
        non-WebRTC voice
        endpoints usually use one of the following codecs: AMR, AMR-WB
        or G.722, which
        will result in massive transcoding when there will be
        communications between
        WebRTC endpoints and non-WebRTC endpoints.

      
- On one side, transcoding is bad for many
        reasons
        discussed in the draft (cost issues, intrinsic quality
        degradation, degraded interactivity,
        fallback from HD to G.711...);

      
- On the other side, it is recognized that
        implementing
        additional codecs in the browsers can generate additional costs.
      
- In order to reach a compromise, we would
        like to add
        some text in the WG draft draft-ietf-rtcweb-audio providing
        incentives for the
        browser to use these three codecs: make them mandatory to
        implement when there
        is no cost impact on the browser (e.g. if codec already
        installed, paid by the
        device vendor...).

      
Any opinion on that?

      
Cheers,

      
Xavier

      
PS: I will be ready to present the slides
        on Thursday if time
        permits it.

      
(c.f. http://tools.ietf.org/agenda/86/slides/slid=
es-86-rtcweb-6.pdf
        )

      


      

      

      
On Thu, Mar 7, 2013 at 11:18 AM, Ted
        Hardie <ted.ietf@gmail.com>
        wrote:

        

          Magnus and I discussed this this morning, and we encourage you
          to

          prepare something. =A0If the discussion of working group last
          call items

          runs short, we may be able to fit this in at that time or at
          the end

          of day one if its full agenda his finished. =A0This is not a
          commitment,

          however, so please try and get discussion on the list on the
          points

          from the draft you feel need resolution.

          

          regards,

          

          Ted

          

            


              

              On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)

              <e=
speberg@cisco.com>
              wrote:

              > Hello,

              >

              >

              >

              > I would like to request agenda time for:

              >

              >

              >

              > draft-marjou-rtcweb-audio-codecs-for-interop-01

              >

              >

              >

              > The document =A0presents use-cases underlining why
              WebRTC needs AMR-WB, =A0AMR

              > and G.722 as additional relevant voice codecs to
              satisfactorily ensure

              > interoperability with existing systems.

              >

              >

              >

              > A 10-minute time slot should be sufficient for
              presentation and discussion.

              >

              >

              >

              > Regards

              >

              >

              >

              > -Espen

              >

              >

              >

              >

              >

              >

            

          

          

            
>
              _______________________________________________

              > rtcweb mailing list

              > rtc=
web@ietf.org

              > https://www.ietf.org/mailman/listinfo/rtcweb

              >

              _______________________________________________

              rtcweb mailing list

              rtcweb@i=
etf.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








--e0cb4efe2f9c41d14b04d7cf6e78--

From bo.burman@ericsson.com  Wed Mar 13 07: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 366EC21F8D8E for ; Wed, 13 Mar 2013 07:43:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.091
X-Spam-Level: 
X-Spam-Status: No, score=-6.091 tagged_above=-999 required=5 tests=[AWL=0.158,  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 wTom1GhAnH5i for ; Wed, 13 Mar 2013 07:43:52 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D601821F85D4 for ; Wed, 13 Mar 2013 07:43:51 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f316d0000028db-f9-514090a6c2db
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id CA.8F.10459.6A090415; Wed, 13 Mar 2013 15:43:50 +0100 (CET)
Received: from ESESSMB105.ericsson.se ([169.254.5.124]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0318.004; Wed, 13 Mar 2013 15:43:50 +0100
From: Bo Burman 
To: David Singer , Harald Alvestrand 
Thread-Topic: [rtcweb] Video Codec discussion in Thursday agenda slot
Thread-Index: AQHOH0jrCpt2zE7X8kqlAIlGSGGMOpiiSwCAgAAIloCAAAHrgIABWaoA
Date: Wed, 13 Mar 2013 14:43:49 +0000
Message-ID: 
References: <513F68C0.4010106@ericsson.com>  <513F7745.3020302@alvestrand.no> 
In-Reply-To: 
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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje6yCQ6BBufPGVkc6+tis1j7r53d Yn7/RxYHZo8rE66wemw9+YPNY8mSn0wBzFFcNimpOZllqUX6dglcGRc2/GEq+KJQceDOBsYG xllSXYwcHBICJhKrFpZ3MXICmWISF+6tZ+ti5OIQEjjEKHG/cSMrhLOEUaKh+QYzSBWbgIbE /B13GUFsEQFfid2XN7CD2MwC6hJ3Fp8Ds4UFXCRuvVjGBFHjKvH26QyoejeJP1PawWpYBFQl 1r5/wgZi8wLN+bTrBNTmLYwSzQtawZo5BWwlLj2cCtbAKCArcf/7PRaIZeISt57MZ4I4W0Bi yZ7zzBC2qMTLx/9YIT5TlFjeLwdRriOxYPcnNghbW2LZwtfMEHsFJU7OfMIygVFsFpKps5C0 zELSMgtJywJGllWM7LmJmTnp5YabGIFxc3DLb90djKfOiRxilOZgURLnDXO9ECAkkJ5Ykpqd mlqQWhRfVJqTWnyIkYmDU6qBMfjbr3uTr559VGz5kvd+XVTduo6qMwk5yfEnH5za+2BxaZFR jNst84b/7/krrvat51jkr5LLfv7tTr+Q1OA+C6WVYsbnqwQvxyl//7Jhg5LPj8A5DufMr+y9 IqbZv5CnvvQA0/QQo+pm1VPNriY3s3nOcn2T/7BXV7lvj/WZOmaVtssq9p+PKrEUZyQaajEX FScCACgtweVpAgAA
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 14:43:53 -0000

On Tuesday, March 12, 2013 2:50 PM, David Singer  wrote:

> On Mar 12, 2013, at 11:43 , Harald Alvestrand  wrot=
e:
>
>> On 03/12/2013 07:12 PM, David Singer wrote:
>>> I am sorry, I don't understand.
>>>=20
>>> At the last meeting, the codec discussion was deferred at the request o=
f
>>> one company and with no reason offered.  It was delayed so late that=20
>>> people, such as my colleague, who had flown in for this discussion had=
=20
>>> already arrived when it was deferred.
>>>=20
>>> This time, we have late-breaking news which is missing important detail=
s,=20
>>> warrants significant preparatory discussion before the meeting, and you=
=20
>>> have justified requests for time from multiple companies, and you go ah=
ead?
>>=20
>> I am very sympathetic with the plight of people who don't have time to=20
>> analyze the new information provided. Believe me, we did the best we cou=
ld=20
>> to make it available earlier - but as you know, it is not possible to=20
>> announce a deal until the deal has actually been signed.
>>=20
>> At the last meeting, we knew that this was likely to happen, but we coul=
d=20
>> (of course) not breathe a word about it - it was clear from the traffic =
on=20
>> the mailing list and the arguments being fielded in presentations that i=
n=20
>> the absence of information about the agreement, our assertions about the=
 IPR=20
>> situation of VP8 would simply not be taken at face value. This was the=20
>> reason we requested a delay at that time.
>>=20
>> At this meeting, we believe the important cards are on the table:
>
> The license, Harald; it is not yet available.  The license and licensors.=
 =20
> The price is only one aspect of the license, as I am sure you understand.
>
> Even without this license, this announcement represents a significant cha=
nge,=20
> and people need time to discuss and understand it.
>
>> H.264 is still a royalty-required codec in all its profiles, and has man=
y=20
>> patent holders insisting on royalties being paid both outside and inside=
 the=20
>> MPEG-LA patent pool; VP8 is still a codec where all the IPR holders that=
=20
>> have made declarations have declared their willingness to license on a=20
>> royalty free basis (either directly or via Google).
>
> I think someone has already gently pointed out an existing suit.
>

[Bo B]: I belive this is a big problem

* We know that not even all the organizations that responded to MPEG LA's c=
all
  are part of the deal and Google cannot (yet) comment on why or who they a=
re

* As David mentions above, it seems that there is at least one company who =
did
  _not_ respond to MPEG LA's call and that does not license RF. As VP8 was
  not developed in a SDO, there have been no obligations to declare any
  IPR, and of course there is no requirement to license on specific terms.
  How many others who did not respond to MPEG LA's call but have IPR are th=
ere?

>>=20
>> We appreciate the need to have time to evaluate the specific words of th=
e=20
>> license statements that are forthcoming, and the need for the people who=
=20
>> haven't made their IPR declarations over the last couple of years of=20
>> discussion to do so within the next couple of weeks - but we do think th=
at=20
>> it is important to use the face to face time that we have here in Orland=
o to=20
>> lay to rest any *other* issues than the licensing terms and other issues=
=20
>> derived from Google's announcement.
>
> I am not sure we can have a reasoned consideration of 'other issues deriv=
ed'=20
> at such short notice. =20
>
> Look, I'd like our discussions and decisions to be informed and considere=
d,=20
> and there simply isn't time for either.
>
>>=20
>> Harald
>>=20
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
> David Singer
> Multimedia and Software Standards, Apple Inc.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

From Kalyani.Bogineni@VerizonWireless.com  Wed Mar 13 07:38: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 B36B721F8E4E for ; Wed, 13 Mar 2013 07:38:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 PxOteuXSycPX for ; Wed, 13 Mar 2013 07:38:08 -0700 (PDT)
Received: from vanguard.verizonwireless.com (vanguard.verizonwireless.com [162.115.35.70]) by ietfa.amsl.com (Postfix) with ESMTP id DB3BD21F8E0C for ; Wed, 13 Mar 2013 07:38:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizonwireless.com; i=@verizonwireless.com; l=0; q=dns/txt; s=prodmail; t=1363185489; x=1394721489; h=from:to:cc:date:subject:references:in-reply-to: content-transfer-encoding:mime-version; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=Q7XBE8PVD9c5jOAeovv0LMfEXwNcqNYvgT43sBmgpWNENs46avUE3AbL pmpgjXt3ArzgXwjdCethMJXFLWMBNwOw8KqLj68oE8Xa7bYDtzy9SC7GM rS7dyo8EfHFqLZGAQb1B6ORsV/0E6qWzOhqZChL4YdGxA3PPW9yU4L7Ex Y=;
Received: from ohdub02exhub04.uswin.ad.vzwcorp.com ([10.97.42.166]) by vanguard.verizonwireless.com with ESMTP; 13 Mar 2013 07:38:05 -0700
Received: from OHDUB02EXCV33.uswin.ad.vzwcorp.com ([10.97.42.179]) by OHDUB02EXHUB04.uswin.ad.vzwcorp.com ([10.97.42.166]) with mapi; Wed, 13 Mar 2013 10:37:45 -0400
From: "Bogineni, Kalyani" 
To: 'Ron' , Xavier Marjou , "rtcweb@ietf.org" 
Date: Wed, 13 Mar 2013 10:37:45 -0400
Thread-Topic: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: Ac4f9yCRd71SMvlWQgiwrhnVQCu1vQAAO4Ew
References:    <20130313142732.GE12022@audi.shelbyville.oz>
In-Reply-To: <20130313142732.GE12022@audi.shelbyville.oz>
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
Message-Id: <20130313143808.DB3BD21F8E0C@ietfa.amsl.com>
X-Mailman-Approved-At: Wed, 13 Mar 2013 07:49:54 -0700
Cc: "Bogineni, Kalyani" 
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 14:38:09 -0000

There are 6.4 billion cellular connections worldwide.

http://www.3gpp.org/3GPP-Family-2012-Statistics

Regards,
Kalyani Bogineni

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Ron
Sent: Wednesday, March 13, 2013 10:28 AM
To: Xavier Marjou; rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01


Hi Xavier,

On Wed, Mar 13, 2013 at 09:14:30AM -0400, Xavier Marjou wrote:
> Here is a summary of the=20
> draft-marjou-rtcweb-audio-codecs-for-interop-00
> presentation that I had prepared for yesterday's session:
>=20
> - The co-authors want to underline that non-WebRTC voice endpoints=20
> usually use one of the following codecs: AMR, AMR-WB or G.722, which=20
> will result in massive transcoding when there will be communications=20
> between WebRTC endpoints and non-WebRTC endpoints.

"Massive" seems a little overstated here.  Any system providing a gateway s=
ervice to or between 'low bandwidth' devices is almost surely going to supp=
ort more than just WebRTC, and is going to have to transcode for most or al=
l of them anyway.  Adding an extra burden to WebRTC, especially one that wo=
uld only ever apply to some small subset of users, wouldn't appear to make =
a significant difference in the requirements for such a system.


> - On one side, transcoding is bad for many reasons discussed in the=20
> draft (cost issues, intrinsic quality degradation, degraded=20
> interactivity, fallback from HD to G.711...);

Are you aware of the listening tests presented to the CODEC WG?

In particular the ones that show Opus->AMR and AMR->Opus is not significant=
ly worse than the intrinsic quality degradation suffered by using AMR alone=
?

Or that Opus->G.711->AMR is actually better than AMR->G.711->AMR ?


> - On the other side, it is recognized that implementing additional=20
> codecs in the browsers can generate additional costs.
>=20
> - In order to reach a compromise, we would like to add some text in=20
> the WG draft draft-ietf-rtcweb-audio providing incentives for the=20
> browser to use these three codecs: make them mandatory to implement=20
> when there is no cost impact on the browser (e.g. if codec already=20
> installed, paid by the device vendor...).

Since there is never no cost impact to supporting additional features, that=
 would imply this is never mandatory ...

In which case why bother half-saying otherwise?

I thought it was already quite clear all along, that people who want to or =
have their own good reasons to are free to implement any other codecs they =
please - and that they already have, and certainly will continue to do so?

> Any opinion on that?

I don't really see much point to handwaving about particular niche codecs f=
or particular niche uses unless this is going to be some sort of separate i=
nformational document, that is kept up to date with changes in all the nich=
es that people have an interest in.

That might be useful.  But 'mandating' something that the people who will d=
o it were going to do it anyway, and the people who were not are still not =
going to do, doesn't seem to add any real value here to either users or imp=
lementers.  It won't explain anything to anybody that they don't already kn=
ow if it is of any interest to them.

 Cheers,
 Ron


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

From stockhammer@nomor.de  Wed Mar 13 07:53: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 35CE121F8E43 for ; Wed, 13 Mar 2013 07:53: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]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkRXB-csgajS for ; Wed, 13 Mar 2013 07:53:17 -0700 (PDT)
Received: from mo6-p00-ob.rzone.de (mo6-p00-ob.rzone.de [IPv6:2a01:238:20a:202:5300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E1221F8DDB for ; Wed, 13 Mar 2013 07:53:17 -0700 (PDT)
X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu1/8loZf+4JHTB3Ffz67cQ=
X-RZG-CLASS-ID: mo00
Received: from [192.168.1.15] (188-192-170-70-dynip.superkabel.de [188.192.170.70]) by smtp.strato.de (jored mo40) (RZmta 31.20 DYNA|AUTH) with ESMTPA id L02ae8p2DEfMgG ; Wed, 13 Mar 2013 15:53:08 +0100 (CET)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Stockhammer Thomas 
In-Reply-To: 
Date: Wed, 13 Mar 2013 15:53:10 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <513F68C0.4010106@ericsson.com>  <513F7745.3020302@alvestrand.no>  
To: Bo Burman 
X-Mailer: Apple Mail (2.1499)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 14:53:18 -0000

>  How many others who did not respond to MPEG LA's call but have IPR =
are there?

[TS]  Just one more hypothesis: If I would have, what would be my =
obligation/motivation to do so now?

>>>=20
>>> We appreciate the need to have time to evaluate the specific words =
of the=20
>>> license statements that are forthcoming, and the need for the people =
who=20
>>> haven't made their IPR declarations over the last couple of years of=20=

>>> discussion to do so within the next couple of weeks - but we do =
think that=20
>>> it is important to use the face to face time that we have here in =
Orlando to=20
>>> lay to rest any *other* issues than the licensing terms and other =
issues=20
>>> derived from Google's announcement.
>>=20
>> I am not sure we can have a reasoned consideration of 'other issues =
derived'=20
>> at such short notice. =20
>>=20
>> Look, I'd like our discussions and decisions to be informed and =
considered,=20
>> and there simply isn't time for either.
>>=20
>>>=20
>>> Harald
>>>=20
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>=20
>> David Singer
>> Multimedia and Software Standards, Apple Inc.
>>=20
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>=20

---
Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 =
978980 02 || cell +491725702667 || http://www.nomor-research.com
Nomor Research GmbH  -  Sitz der Gesellschaft: M=FCnchen - =
Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 =
- Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering.




From prvs=07845f9988=aallen@blackberry.com  Wed Mar 13 07:58: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 2B30B21F8D61 for ; Wed, 13 Mar 2013 07:58:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.297
X-Spam-Level: 
X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 rcA-tbLgJnRY for ; Wed, 13 Mar 2013 07:58:23 -0700 (PDT)
Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 75E8E21F8D66 for ; Wed, 13 Mar 2013 07:58:23 -0700 (PDT)
X-AuditID: 0a412830-b7ef86d00000339d-28-5140940d1f5f
Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id CF.27.13213.E0490415; Wed, 13 Mar 2013 09:58:22 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 09:58:20 -0500
From: Andrew Allen 
To: "Olle E. Johansson" , Ron 
Thread-Topic: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOH/jXvfkDZfx4Ek2GP7Tc350WkZijtjrw
Date: Wed, 13 Mar 2013 14:58:19 +0000
Message-ID: 
References:    <20130313142732.GE12022@audi.shelbyville.oz> <7897A33F-F73A-4C39-B4DA-16F014A43C5C@edvina.net>
In-Reply-To: <7897A33F-F73A-4C39-B4DA-16F014A43C5C@edvina.net>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.252]
Content-Type: text/plain; charset="us-ascii"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDKsWRmVeSWpSXmKPExsXC5Zyvpcs3xSHQ4PgWE4uXqw8xW2x+cYPd Yu2/dnYHZo9fbXOZPaatXcnqsWTJT6YA5qgGRpukxJKy4Mz0PH07m8S8vPySxJJUhZTU4mRb JZ/U9MQchYCizLLE5EoFl8zi5JzEzNzUIiWFzBRbJRMlhYKcxOTU3NS8ElulxIKC1LwUJTsu BQxgA1SWmaeQmpecn5KZl26r5Bnsr2thYWqpa6hkp5vQyZPx6P4dloLT7BWTOs4xNTAuZ+ti 5OSQEDCR2HJrIhOELSZx4d56sLiQQBuTxOxbMl2MXED2ZkaJ/Ye/sYAk2AS0gOzpYA0iAnYS q76sZQexmQXUJe4sPgdmCwvES5zfO5cZoiZB4s/n3+wQtpHE/IUbweIsAqoSx2+/BZvDK+Ah 0b1sIxPEsr1MElsnbQa7ghNowdRL3xlBbEYBWYndZ68zQSwTl7j1ZD7U1QISS/acZ4awRSVe Pv7HCmErSjxu6WaBqNeRWLD7ExuErS2xbOFrZojFghInZz5hmcAoNgvJ2FlIWmYhaZmFpGUB I8sqRsHcjGIDM8PkvGS9osxcvbzUkk2MoOThqGGwg/H9e4tDjAIcjEo8vPUtDoFCrIllxZW5 hxglOJiVRHiX5wKFeFMSK6tSi/Lji0pzUosPMboCg2UisxR3cj4wseWVxBsbGODmKInzigSK BgoJpAPTUnZqakFqEcwcJg5OkD1cUiLFwOSSWpRYWpIRD0qB8cXAJCjVwLgjedaiZX6u32Nj GEVWfHe9aHk5IOzEpXpj79hnF+Xjptdcq5jSOVniPmdf4fkll5JEzjywWF5fXKdSPyUzd977 5C9r3kc1WfHPfnv49IHFrrrXri2evYUlLV19y+HGA8u1jfX4lti/fR7Z+27i1bwvZ9MKkxif sXDE7BF5LMVw/odf+bMiXWclluKMREMt5qLiRABLe24GXwMAAA==
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Agenda time request for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 14:58:24 -0000

I think this would be completely out of scope of IETF.

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Olle E. Johansson
Sent: Wednesday, March 13, 2013 10:41 AM
To: Ron
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-code=
cs-for-interop-01


13 mar 2013 kl. 15:27 skrev Ron :

>> these three codecs: make them mandatory to implement when there is no 
>> cost impact on the browser (e.g. if codec already installed, paid by 
>> the device vendor...).
I would like to propose that someone (it's out of scope for this group) make=
 it mandatory to implement open APIs so that all applications on these devic=
es can use all the codecs implemented in hardware. That's not the case now.=
 

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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From xavier.marjou@gmail.com  Wed Mar 13 08:17: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 989C521F8E65 for ; Wed, 13 Mar 2013 08:17:46 -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 uYxeNerSe2E4 for ; Wed, 13 Mar 2013 08:17:46 -0700 (PDT)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id C28CC21F8E2D for ; Wed, 13 Mar 2013 08:17:45 -0700 (PDT)
Received: by mail-la0-f52.google.com with SMTP id fs12so1273348lab.11 for ; Wed, 13 Mar 2013 08:17:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Fh9FH/P2aYX3tJWO8yZ9jb3v9H+898JeOzI8xW7mkLw=; b=LKGHFfsjjyCEN0XEAySDXBXTigIWB/klSegBLyKTs3ozwrC5QZ6yw6zAKzqFPXsa74 McTesqZqlwmh2wLJFXUOCD/FNu0e1MmmMTVacc4u2ek9JYCrneplsEuG4EYj6NgFfMtd jdQIk4JzoMUI+HCv7gu1R0YQq5EOd7ioMVx/D0tdvGnZsq057C0tnT+g2lm8hf9mzruc zwsVyBmPjQO3LfZ4OnWzn79hV3H4VKmbxWIS2kvnQ27totA3PB1nT243TuhOYKt8F446 0ClUwjRjxxNNvMvDSzgBrrgpxmmG/CJFu6JJNqos+YeZZ8d1qXRO6wOxXaLuLjDvhQ06 co5A==
MIME-Version: 1.0
X-Received: by 10.152.109.112 with SMTP id hr16mr18047890lab.38.1363187864583;  Wed, 13 Mar 2013 08:17:44 -0700 (PDT)
Sender: xavier.marjou@gmail.com
Received: by 10.114.7.167 with HTTP; Wed, 13 Mar 2013 08:17:44 -0700 (PDT)
In-Reply-To: <20130313142732.GE12022@audi.shelbyville.oz>
References:    <20130313142732.GE12022@audi.shelbyville.oz>
Date: Wed, 13 Mar 2013 11:17:44 -0400
X-Google-Sender-Auth: Q8AW9iSDuDqfZf7MHS3OWZHz-uo
Message-ID: 
From: Xavier Marjou 
To: Ron 
Content-Type: multipart/alternative; boundary=bcaec54eea706f118c04d7cfe84d
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 15:17:46 -0000

--bcaec54eea706f118c04d7cfe84d
Content-Type: text/plain; charset=ISO-8859-1

WebRTC standard must do the best to avoid transcoding when communications
happen towards "legacy" devices.

Another way to illustrate that is an analogy with human languages: suppose
there are two French native speakers and they have to speak English to talk
with each other: this results in additional efforts, decreased quality of
conversation, additional delays... all these details are significant for
the quality of the communication.

(of course there are some exceptions in my analogy: there exists French
native speakers who can also speak English fluently, in particular some
Quebecois folks on the list ;-)



Are you aware of the listening tests presented to the CODEC WG?
>
> In particular the ones that show Opus->AMR and AMR->Opus is not
> significantly
> worse than the intrinsic quality degradation suffered by using AMR alone?
>
> Or that Opus->G.711->AMR is actually better than AMR->G.711->AMR ?
>
>

--bcaec54eea706f118c04d7cfe84d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

WebRTC standard must do the best to avoid transcoding when communications h=
appen towards "legacy" devices.

Another w=
ay to illustrate that is an analogy with human languages: suppose there are=
 two French native speakers and they have to speak=A0English=A0to talk with=
 each other: this results in additional efforts, decreased quality of conve=
rsation, additional delays... all these details are significant for the qua=
lity of the communication.=A0



(of course there are some exceptions in my analogy: the=
re exists French native speakers who can also speak English fluently, in pa=
rticular some Quebecois folks on the list ;-)







--bcaec54eea706f118c04d7cfe84d--

From oej@edvina.net  Wed Mar 13 08:18: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 06D6B21F8E65 for ; Wed, 13 Mar 2013 08:18:25 -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.075,  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 xhNhch6V6N6n for ; Wed, 13 Mar 2013 08:18:24 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 2D81F21F8F08 for ; Wed, 13 Mar 2013 08:18:24 -0700 (PDT)
Received: from [192.168.40.23] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 566E593DE3E; Wed, 13 Mar 2013 15:18:08 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: "Olle E. Johansson" 
In-Reply-To: 
Date: Wed, 13 Mar 2013 16:17:47 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8B7442F6-5393-4C5C-88B6-A680742F60E7@edvina.net>
References:    <20130313142732.GE12022@audi.shelbyville.oz> <7897A33F-F73A-4C39-B4DA-16F014A43C5C@edvina.net> 
To: Andrew Allen 
X-Mailer: Apple Mail (2.1499)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 15:18:25 -0000

13 mar 2013 kl. 15:58 skrev Andrew Allen :

> I think this would be completely out of scope of IETF.

Agree. So assuming that these codecs are available just because some =
hardware in a device has
a licensed implementation is not a valid assumption for a codec =
selection as long as we can't
assume that any application on that device has access to it.

/O
>=20
> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On =
Behalf Of Olle E. Johansson
> Sent: Wednesday, March 13, 2013 10:41 AM
> To: Ron
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Agenda time request for =
draft-marjou-rtcweb-audio-codecs-for-interop-01
>=20
>=20
> 13 mar 2013 kl. 15:27 skrev Ron :
>=20
>>> these three codecs: make them mandatory to implement when there is =
no
>>> cost impact on the browser (e.g. if codec already installed, paid by
>>> the device vendor...).
> I would like to propose that someone (it's out of scope for this =
group) make it mandatory to implement open APIs so that all applications =
on these devices can use all the codecs implemented in hardware. That's =
not the case now.
>=20
> /O
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>=20
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential =
information, privileged material (including material protected by the =
solicitor-client or other applicable privileges), or constitute =
non-public information. Any use of this information by anyone other than =
the intended recipient is prohibited. If you have received this =
transmission in error, please immediately reply to the sender and delete =
this information from your system. Use, dissemination, distribution, or =
reproduction of this transmission by unintended recipients is not =
authorized and may be unlawful.


From prvs=2784a1a91b=aallen@blackberry.com  Wed Mar 13 08:23: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 9A06321F8E01 for ; Wed, 13 Mar 2013 08:23:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.291
X-Spam-Level: 
X-Spam-Status: No, score=-5.291 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 hVY+dht2zHLH for ; Wed, 13 Mar 2013 08:23:50 -0700 (PDT)
Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id C0A8121F8A99 for ; Wed, 13 Mar 2013 08:23:49 -0700 (PDT)
X-AuditID: 0a41282f-b7fa06d000002431-49-514099fa73f0
Received: from XCT103ADS.rim.net (xct103ads.rim.net [10.67.111.44]) by mhs060cnc.rim.net (SBG) with SMTP id D1.08.09265.AF990415; Wed, 13 Mar 2013 10:23:38 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT103ADS.rim.net ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 10:23:37 -0500
From: Andrew Allen 
To: "Olle E. Johansson" 
Thread-Topic: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOH/4PIkdwNySrF0e3DspnAswwZZijvGsw
Date: Wed, 13 Mar 2013 15:23:36 +0000
Message-ID: 
References:    <20130313142732.GE12022@audi.shelbyville.oz> <7897A33F-F73A-4C39-B4DA-16F014A43C5C@edvina.net>  <8B7442F6-5393-4C5C-88B6-A680742F60E7@edvina.net>
In-Reply-To: <8B7442F6-5393-4C5C-88B6-A680742F60E7@edvina.net>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.252]
Content-Type: text/plain; charset="us-ascii"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDKsWRmVeSWpSXmKPExsXC5Zyvo/trpkOgwZ89whYvVx9ittj84ga7 xdp/7ewOzB6/2uYye0xbu5LVY8mSn0wBzFENjDZJiSVlwZnpefp2Nol5efkliSWpCimpxcm2 Sj6p6Yk5CgFFmWWJyZUKLpnFyTmJmbmpRUoKmSm2SiZKCgU5icmpual5JbZKiQUFqXkpSnZc ChjABqgsM08hNS85PyUzL91WyTPYX9fCwtRS11DJTjehkyej6eo99oLVohXtZ8+xNzCeE+xi 5OSQEDCRaN2xgx3CFpO4cG89WxcjF4eQwEpGiWnfDjBCOJsZJZo/XQKrYhPQkth/eDoTiC0i oCFx4csVNhCbWcBW4t+MlWA1wgLxElePrmCGqEmQOD9nH1S9kcTXlztYQGwWAVWJ40d2gvXy CnhIXF71mRHEFhLYwCzRuCwHxOYUsJNo61sFNpNRQFZi99nrTBC7xCVuPZnPBHG1gMSSPeeZ IWxRiZeP/7FC2IoSj1u6WSDqdSQW7P4Edae2xLKFr5kh9gpKnJz5hGUCo9gsJGNnIWmZhaRl FpKWBYwsqxgFczOKDcwMkvOS9Yoyc/XyUks2MYKSh6OG/g7Gt+8tDjEKcDAq8fBatToECrEm lhVX5h5ilOBgVhLhXZ4LFOJNSaysSi3Kjy8qzUktPsToCgyVicxS3Mn5wMSWVxJvbGCAm6Mk zisSKBooJJAOTEvZqakFqUUwc5g4OEH2cEmJFAOTS2pRYmlJRjwoBcYXA5OgVAOjbx8rj1VA mEbnPq5F13dMXB+0pE1B5lbqq+tz7BRXOM/faDBz7574G37NW3cLT1rj87TdSK+81PjAOt8b Hk7uiefYJuoVVs2PfdlQcTXCtzllkbN3sFzaNWM/4b49jw3288xi2RjRvLTdn1HG6W27567Z brLyChFaU7aKl+k92VTyZ+41d2slluKMREMt5qLiRABdzIHyXwMAAA==
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 15:23:50 -0000

Olle

I agree with you which is why a few months ago I proposed the following text=
 that had the "are available to the browser" caveat

"If other suitable audio codecs are available to the browser to use it is re=
commended that they are also included in the offer in order to maximize the=
 possibility to establish the session without the need for audio transcoding=
"

Andrew

-----Original Message-----
From: Olle E. Johansson [mailto:oej@edvina.net] 
Sent: Wednesday, March 13, 2013 11:18 AM
To: Andrew Allen
Cc: Olle E. Johansson; Ron; rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-code=
cs-for-interop-01


13 mar 2013 kl. 15:58 skrev Andrew Allen :

> I think this would be completely out of scope of IETF.

Agree. So assuming that these codecs are available just because some hardwar=
e in a device has a licensed implementation is not a valid assumption for a=
 codec selection as long as we can't assume that any application on that dev=
ice has access to it.

/O
> 
> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On 
> Behalf Of Olle E. Johansson
> Sent: Wednesday, March 13, 2013 10:41 AM
> To: Ron
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Agenda time request for 
> draft-marjou-rtcweb-audio-codecs-for-interop-01
> 
> 
> 13 mar 2013 kl. 15:27 skrev Ron :
> 
>>> these three codecs: make them mandatory to implement when there is 
>>> no cost impact on the browser (e.g. if codec already installed, paid 
>>> by the device vendor...).
> I would like to propose that someone (it's out of scope for this group) ma=
ke it mandatory to implement open APIs so that all applications on these dev=
ices can use all the codecs implemented in hardware. That's not the case now=
.
> 
> /O
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential inf=
ormation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informatio=
n. Any use of this information by anyone other than the intended recipient i=
s prohibited. If you have received this transmission in error, please immedi=
ately reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From oej@edvina.net  Wed Mar 13 08:43: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 1F4BC21F8CB8 for ; Wed, 13 Mar 2013 08:43:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level: 
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067,  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 Ano7IV-ntREb for ; Wed, 13 Mar 2013 08:43:14 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id D5F3A21F8C82 for ; Wed, 13 Mar 2013 08:43:13 -0700 (PDT)
Received: from [192.168.40.23] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 2628A93DE3E; Wed, 13 Mar 2013 15:42:57 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: "Olle E. Johansson" 
In-Reply-To: 
Date: Wed, 13 Mar 2013 16:42:36 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <3C89A60B-3171-49B0-A78F-304337DF8D3D@edvina.net>
References:    <20130313142732.GE12022@audi.shelbyville.oz> <7897A33F-F73A-4C39-B4DA-16F014A43C5C@edvina.net>  <8B7442F6-5393-4C5C-88B6-A680742F60E7@edvina.net> 
To: Andrew Allen 
X-Mailer: Apple Mail (2.1499)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 15:43:15 -0000

13 mar 2013 kl. 16:23 skrev Andrew Allen :

> Olle
>=20
> I agree with you which is why a few months ago I proposed the =
following text that had the "are available to the browser" caveat
>=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"

Exactly. I don't think everyone gets the that selecting a small subset =
as mandatory for WebRTC does NOT exclude all other codecs. Feel
free to add everything you got. Have fun. Let the best mutual codec with =
the best mutual properties win the session.

/O
>=20
> Andrew
>=20
> -----Original Message-----
> From: Olle E. Johansson [mailto:oej@edvina.net]
> Sent: Wednesday, March 13, 2013 11:18 AM
> To: Andrew Allen
> Cc: Olle E. Johansson; Ron; rtcweb@ietf.org
> Subject: Re: [rtcweb] Agenda time request for =
draft-marjou-rtcweb-audio-codecs-for-interop-01
>=20
>=20
> 13 mar 2013 kl. 15:58 skrev Andrew Allen :
>=20
>> I think this would be completely out of scope of IETF.
>=20
> Agree. So assuming that these codecs are available just because some =
hardware in a device has a licensed implementation is not a valid =
assumption for a codec selection as long as we can't assume that any =
application on that device has access to it.
>=20
> /O
>>=20
>> -----Original Message-----
>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
>> Behalf Of Olle E. Johansson
>> Sent: Wednesday, March 13, 2013 10:41 AM
>> To: Ron
>> Cc: rtcweb@ietf.org
>> Subject: Re: [rtcweb] Agenda time request for
>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>>=20
>>=20
>> 13 mar 2013 kl. 15:27 skrev Ron :
>>=20
>>>> these three codecs: make them mandatory to implement when there is
>>>> no cost impact on the browser (e.g. if codec already installed, =
paid
>>>> by the device vendor...).
>> I would like to propose that someone (it's out of scope for this =
group) make it mandatory to implement open APIs so that all applications =
on these devices can use all the codecs implemented in hardware. That's =
not the case now.
>>=20
>> /O
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>=20
>> ---------------------------------------------------------------------
>> This transmission (including any attachments) may contain =
confidential information, privileged material (including material =
protected by the solicitor-client or other applicable privileges), or =
constitute non-public information. Any use of this information by anyone =
other than the intended recipient is prohibited. If you have received =
this transmission in error, please immediately reply to the sender and =
delete this information from your system. Use, dissemination, =
distribution, or reproduction of this transmission by unintended =
recipients is not authorized and may be unlawful.
>=20
>=20
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential =
information, privileged material (including material protected by the =
solicitor-client or other applicable privileges), or constitute =
non-public information. Any use of this information by anyone other than =
the intended recipient is prohibited. If you have received this =
transmission in error, please immediately reply to the sender and delete =
this information from your system. Use, dissemination, distribution, or =
reproduction of this transmission by unintended recipients is not =
authorized and may be unlawful.


From ron@debian.org  Wed Mar 13 09:05: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 4581221F8B20 for ; Wed, 13 Mar 2013 09:05:46 -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 q992SM9L0wb2 for ; Wed, 13 Mar 2013 09:05:45 -0700 (PDT)
Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 3F75721F8B16 for ; Wed, 13 Mar 2013 09:05:43 -0700 (PDT)
Received: from ppp118-210-121-105.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([118.210.121.105]) by ipmail06.adl2.internode.on.net with ESMTP; 14 Mar 2013 02:35:43 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 26A164F8F3; Thu, 14 Mar 2013 02:23:44 +1030 (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 SHzVIu49I4+B; Thu, 14 Mar 2013 02:23:43 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 04DC64F902; Thu, 14 Mar 2013 02:23:43 +1030 (CST)
Date: Thu, 14 Mar 2013 02:23:42 +1030
From: 'Ron' 
To: "Bogineni, Kalyani" 
Message-ID: <20130313155342.GF12022@audi.shelbyville.oz>
References:    <20130313142732.GE12022@audi.shelbyville.oz> <1363185502_43961@mail.internode.on.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1363185502_43961@mail.internode.on.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: rtcweb@ietf.org, Xavier Marjou 
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 16:05:46 -0000

On Wed, Mar 13, 2013 at 10:37:45AM -0400, Bogineni, Kalyani wrote:
> There are 6.4 billion cellular connections worldwide.
> 
> http://www.3gpp.org/3GPP-Family-2012-Statistics

Sure.  And why do you think that someone with one of those devices,
who wanted to call someone on the legacy network that didn't have
a WebRTC service, would want to do it by going via a WebRTC gateway
service, that they would presumably have to pay extra for, and would
suffer extra hops of latency to use (even without transcoding), when
they could just, you know, call them on their cell phone normally ... ?

Trying to optimise for a case that nobody would actually ever really
use, that only guarantees poorer and more expensive results than using
either WebRTC or their phone as it was actually intended, doesn't seem
like a useful thing to focus on at this stage - let alone something we
need to 'mandate' to create an 'incentive' for.

The people who need this don't need a mandate, and the people who can't
use it are going to (have to) ignore it and none of their users will
ever notice.  That doesn't sound like any sort of mandate material to me.

Or like something that hinges on the number of legacy phones at all
for that matter.

  Ron


> Regards,
> Kalyani Bogineni
> 
> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ron
> Sent: Wednesday, March 13, 2013 10:28 AM
> To: Xavier Marjou; rtcweb@ietf.org
> Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
> 
> 
> Hi Xavier,
> 
> On Wed, Mar 13, 2013 at 09:14:30AM -0400, Xavier Marjou wrote:
> > Here is a summary of the 
> > draft-marjou-rtcweb-audio-codecs-for-interop-00
> > presentation that I had prepared for yesterday's session:
> > 
> > - The co-authors want to underline that non-WebRTC voice endpoints 
> > usually use one of the following codecs: AMR, AMR-WB or G.722, which 
> > will result in massive transcoding when there will be communications 
> > between WebRTC endpoints and non-WebRTC endpoints.
> 
> "Massive" seems a little overstated here.  Any system providing a gateway service to or between 'low bandwidth' devices is almost surely going to support more than just WebRTC, and is going to have to transcode for most or all of them anyway.  Adding an extra burden to WebRTC, especially one that would only ever apply to some small subset of users, wouldn't appear to make a significant difference in the requirements for such a system.
> 
> 
> > - On one side, transcoding is bad for many reasons discussed in the 
> > draft (cost issues, intrinsic quality degradation, degraded 
> > interactivity, fallback from HD to G.711...);
> 
> Are you aware of the listening tests presented to the CODEC WG?
> 
> In particular the ones that show Opus->AMR and AMR->Opus is not significantly worse than the intrinsic quality degradation suffered by using AMR alone?
> 
> Or that Opus->G.711->AMR is actually better than AMR->G.711->AMR ?
> 
> 
> > - On the other side, it is recognized that implementing additional 
> > codecs in the browsers can generate additional costs.
> > 
> > - In order to reach a compromise, we would like to add some text in 
> > the WG draft draft-ietf-rtcweb-audio providing incentives for the 
> > browser to use these three codecs: make them mandatory to implement 
> > when there is no cost impact on the browser (e.g. if codec already 
> > installed, paid by the device vendor...).
> 
> Since there is never no cost impact to supporting additional features, that would imply this is never mandatory ...
> 
> In which case why bother half-saying otherwise?
> 
> I thought it was already quite clear all along, that people who want to or have their own good reasons to are free to implement any other codecs they please - and that they already have, and certainly will continue to do so?
> 
> > Any opinion on that?
> 
> I don't really see much point to handwaving about particular niche codecs for particular niche uses unless this is going to be some sort of separate informational document, that is kept up to date with changes in all the niches that people have an interest in.
> 
> That might be useful.  But 'mandating' something that the people who will do it were going to do it anyway, and the people who were not are still not going to do, doesn't seem to add any real value here to either users or implementers.  It won't explain anything to anybody that they don't already know if it is of any interest to them.
> 
>  Cheers,
>  Ron
> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

From tim@phonefromhere.com  Wed Mar 13 09:11: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 1D90E21F8C3F for ; Wed, 13 Mar 2013 09:11: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 mvE+x+Kdgfed for ; Wed, 13 Mar 2013 09:11:11 -0700 (PDT)
Received: from smtp004.apm-internet.net (smtp004.apm-internet.net [85.119.248.54]) by ietfa.amsl.com (Postfix) with ESMTP id 53BDB21F8BF4 for ; Wed, 13 Mar 2013 09:11:11 -0700 (PDT)
Received: (qmail 80259 invoked from network); 13 Mar 2013 16:11:09 -0000
X-AV-Scan: clean
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp004.apm-internet.net with SMTP; 13 Mar 2013 16:11:09 -0000
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id C1ED518A02A8; Wed, 13 Mar 2013 16:11:09 +0000 (GMT)
Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 9F1C318A022A;  Wed, 13 Mar 2013 16:11:09 +0000 (GMT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Tim Panton 
In-Reply-To: <20130313143808.DB3BD21F8E0C@ietfa.amsl.com>
Date: Wed, 13 Mar 2013 16:11:08 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    <20130313142732.GE12022@audi.shelbyville.oz> <20130313143808.DB3BD21F8E0C@ietfa.amsl.com>
To: "Bogineni, Kalyani" 
X-Mailer: Apple Mail (2.1283)
Cc: "rtcweb@ietf.org" , Xavier Marjou 
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 16:11:13 -0000

On 13 Mar 2013, at 14:37, Bogineni, Kalyani wrote:

> There are 6.4 billion cellular connections worldwide.
>=20
> http://www.3gpp.org/3GPP-Family-2012-Statistics
>=20
> Regards,
> Kalyani Bogineni

Following that logic we'd mandate GSM.610 since _all_ of those 6B =
devices support it.

I'd also like to point out that the "massive" transcoding cited already =
occurs between mobile devices=20
that support various codecs (GSM, AMR etc) and the PSTN - (g711, g729) =
and the sky hasn't fallen yet.

Tim.=

From ron@debian.org  Wed Mar 13 09:25: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 B03FF21F8CC7 for ; Wed, 13 Mar 2013 09:25:45 -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 gsqmvuBZhxmo for ; Wed, 13 Mar 2013 09:25:45 -0700 (PDT)
Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 9054E21F8BF1 for ; Wed, 13 Mar 2013 09:25:43 -0700 (PDT)
Received: from ppp118-210-121-105.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([118.210.121.105]) by ipmail06.adl2.internode.on.net with ESMTP; 14 Mar 2013 02:55:42 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 313A44F8F3; Thu, 14 Mar 2013 02:44:47 +1030 (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 tDNraXuhtQw0; Thu, 14 Mar 2013 02:44:46 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 826FE4F902; Thu, 14 Mar 2013 02:44:46 +1030 (CST)
Date: Thu, 14 Mar 2013 02:44:46 +1030
From: Ron 
To: Xavier Marjou 
Message-ID: <20130313161446.GG12022@audi.shelbyville.oz>
References:    <20130313142732.GE12022@audi.shelbyville.oz> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 16:25:48 -0000

On Wed, Mar 13, 2013 at 11:17:44AM -0400, Xavier Marjou wrote:
> WebRTC standard must do the best to avoid transcoding when communications
> happen towards "legacy" devices.

That's a pretty general and well known principle that doesn't need mandating
specially for WebRTC or is in any way unique to it.

So maybe the "legacy" devices should just add Opus support then :)

It's not like 4 billion of the 6 billion aren't less than 2 years old, or
are not firmware upgradeable ...

And it's not like (the many) people who are jailbreaking them aren't doing
that for themselves already ...


> Another way to illustrate that is an analogy with human languages: suppose
> there are two French native speakers and they have to speak English to talk
> with each other: this results in additional efforts, decreased quality of
> conversation, additional delays... all these details are significant for
> the quality of the communication.
> 
> (of course there are some exceptions in my analogy: there exists French
> native speakers who can also speak English fluently, in particular some
> Quebecois folks on the list ;-)

Right, and the French and English they speak today isn't the same French
and English they spoke in mediaevil times :)

We could equally consider this an incentive for the legacy device makers
to move forward.  That seems like a much better outcome for everyone
than trying to drag the new format backward would bring.

 Doesn't it?
 Ron


> Are you aware of the listening tests presented to the CODEC WG?
> >
> > In particular the ones that show Opus->AMR and AMR->Opus is not
> > significantly
> > worse than the intrinsic quality degradation suffered by using AMR alone?
> >
> > Or that Opus->G.711->AMR is actually better than AMR->G.711->AMR ?


From stephane.proust@orange.com  Wed Mar 13 10:12: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 D025221F8DB6 for ; Wed, 13 Mar 2013 10:12: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, 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 u7iZmsRcnV2w for ; Wed, 13 Mar 2013 10:12:20 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6F61521F8DA2 for ; Wed, 13 Mar 2013 10:12:18 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 5530B22CD9C; Wed, 13 Mar 2013 18:12:17 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 3697E238055; Wed, 13 Mar 2013 18:12:17 +0100 (CET)
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; Wed, 13 Mar 2013 18:12:12 +0100
From: 
To: Tim Panton , "Bogineni, Kalyani" 
Thread-Topic: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIAVlp7b+CzGBakKEUTk/XQOvHZij1z1Q
Date: Wed, 13 Mar 2013 17:12:06 +0000
Message-ID: <3769_1363194737_5140B371_3769_3650_1_6ccb4089-ab79-4913-a456-72b68a77f9a0@PEXCVZYH02.corporate.adroot.infra.ftgroup>
References:    <20130313142732.GE12022@audi.shelbyville.oz> <20130313143808.DB3BD21F8E0C@ietfa.amsl.com> 
In-Reply-To: 
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.13.151516
Cc: MARJOU Xavier OLNC/OLN , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Agenda time request for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 17:12:24 -0000

> I'd also like to point out that the "massive" transcoding cited already o=
ccurs between mobile devices that support various codecs (GSM, AMR etc) and=
 the PSTN - (g711, g729) and the sky hasn't fallen yet.

But transcoding to G.711 has simply absolutely nothing to do in terms of im=
pact on gateways costs and capacities !
Transcoding to G.711 almost cost nothing.
For your information: complexity of G.711 is around 0,01 WMPOS when AMR-WB =
is at 40 WMOPS and OPUS still higher...=20
So we speak about a factor of more than 1000 in terms  transcoding complexi=
ty and related impact on gateways !
And even with respect to AMR, G.722 or AMR-WB, transcoding from/to OPUS wil=
l still be more costly

St=E9phane

-----Message d'origine-----
De=A0: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la part =
de Tim Panton
Envoy=E9=A0: mercredi 13 mars 2013 17:11
=C0=A0: Bogineni, Kalyani
Cc=A0: rtcweb@ietf.org; MARJOU Xavier OLNC/OLN
Objet=A0: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-co=
decs-for-interop-01



On 13 Mar 2013, at 14:37, Bogineni, Kalyani wrote:

> There are 6.4 billion cellular connections worldwide.
>=20
> http://www.3gpp.org/3GPP-Family-2012-Statistics
>=20
> Regards,
> Kalyani Bogineni

Following that logic we'd mandate GSM.610 since _all_ of those 6B devices s=
upport it.

I'd also like to point out that the "massive" transcoding cited already occ=
urs between mobile devices that support various codecs (GSM, AMR etc) and t=
he PSTN - (g711, g729) and the sky hasn't fallen yet.

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

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.


From roman@telurix.com  Wed Mar 13 10: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 C90CA21F8E3B for ; Wed, 13 Mar 2013 10:12:53 -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 nin2ep2Jhk1S for ; Wed, 13 Mar 2013 10:12: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 C395021F8E34 for ; Wed, 13 Mar 2013 10:12:52 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id hm6so994746wib.14 for ; Wed, 13 Mar 2013 10:12:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=MTNh5NsgdhqkLxjZpvDxljUz3mUX3yQtdOJxYkBDF/c=; b=CL1Dpj/LWssK48lceI9EkrM0/FsIE4BN/j1MSCxkoKH7cDi8vfOy3PlmVc+4U0tgwc bLNWZcvyeZNkHTjoK8hEZWIBeYOJK3Dwm4YNg+Lnt/NlrWIBvgtivEClwF/AT2MFOFwL asPtquYMmCxDGzALqjp51sQrVxp9i+20UDLTd3l46bxu34f/oN6p+7Gvj+Me2XPidZkl DWLt/EyeLRP2pc8tWd9fGVGQ3X34CUKX3Fz1mqofeGayjygkJlAl/Q30KPFQCJ/ROaO7 wJPozNlQ8vQQxRMfPLYhm7yLHJ8fsPDpOBtRsGJbbyzH67/VN7n7wKdbcqWV4Qqm1t2n ap+w==
X-Received: by 10.180.90.2 with SMTP id bs2mr33827271wib.0.1363194771960; Wed, 13 Mar 2013 10:12:51 -0700 (PDT)
Received: from mail-wg0-x22a.google.com ([2a00:1450:400c:c00::22a]) by mx.google.com with ESMTPS id bs6sm4338036wib.4.2013.03.13.10.12.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Mar 2013 10:12:51 -0700 (PDT)
Received: by mail-wg0-f42.google.com with SMTP id 12so174148wgh.3 for ; Wed, 13 Mar 2013 10:12:50 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.21.233 with SMTP id y9mr35840949wje.47.1363194770002; Wed, 13 Mar 2013 10:12:50 -0700 (PDT)
Received: by 10.217.107.135 with HTTP; Wed, 13 Mar 2013 10:12:49 -0700 (PDT)
In-Reply-To: <20130313161446.GG12022@audi.shelbyville.oz>
References:    <20130313142732.GE12022@audi.shelbyville.oz>  <20130313161446.GG12022@audi.shelbyville.oz>
Date: Wed, 13 Mar 2013 13:12:49 -0400
Message-ID: 
From: Roman Shpount 
To: rtcweb@ietf.org
Content-Type: multipart/alternative; boundary=047d7b5d277406cea804d7d1846d
X-Gm-Message-State: ALoCoQnV2FCv8SQq+6oIf6Xmmni+rjBGJ19PjldJpzdfE2FK0KO6c1ikBoPLaUvkOpQAPrEH7UbS
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 17:12:53 -0000

--047d7b5d277406cea804d7d1846d
Content-Type: text/plain; charset=ISO-8859-1

Normally, when implementing VoIP devices, unless they are intended for some
sort of walled garden, you try to support as many codecs as possible. This
increases your chances of interoperability with other devices and your
product adoption. In case of WebRTC, it would be adopted regardless of what
codecs are supported. The number of enabled devices would be so great that
all the legacy networks will have to adapt. This has some negative
implications to the legacy networks as far as quality and costs are
concerned, but these challenges are not insurmountable. So, taking this
into consideration, I want to place the same questions differently:

Do web browser implementers currently plan to support any other codecs
except MTI (G.711 and OPUS)?

Is there anything we are going to say here regarding legacy interop that
would make browser manufacturers to change their mind? After all, this
represents additional cost to them with no direct benefit for the use cases
which are most important to them (browser to browser calls).

For me, the desired outcome would be that browsers, at least for the next
few years, do support a reasonable set of other codecs in addition to MTI,
including G.722, AMR, AMR-WB, and may be Speex, . This would give me an
opportunity to migrate from devices that support legacy codecs to devices
that support Opus. The fact that different browser versions would support
different codec sets (like desktop browsers not supporting AMR) is not a
big issue, at least for me, since we always have G.711 or transcoding to
fall back to. The same goes for browsers fazing some of the legacy codecs
out in the future. The end result would still be better then 100% G.711 or
transcoding.
_____________
Roman Shpount

--047d7b5d277406cea804d7d1846d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Normally, when implementing VoIP devices, unless they are intended for=
 some sort of walled garden, you try to support as many codecs as possible.=
 This increases your chances of interoperability with other devices and you=
r product adoption. In case of WebRTC, it would be adopted regardless of wh=
at codecs are supported. The number of enabled devices would be so great th=
at all the legacy networks will have to adapt. This has some negative impli=
cations to the legacy networks as far as quality and costs are concerned, b=
ut these challenges are not insurmountable. So, taking this into=A0consider=
ation, I want to place the same questions differently:



Do web browser implementers currently plan to support a=
ny other codecs except MTI (G.711 and OPUS)?

Is th=
ere anything we are going to say here regarding legacy interop that would m=
ake browser manufacturers to change their mind? After all, this represents =
additional cost to them with no direct benefit for the use cases which are =
most important to them (browser to browser calls).



For me, the desired outcome would be that browsers, at =
least for the next few years, do support a reasonable set of other codecs i=
n addition to MTI, including G.722, AMR, AMR-WB, and may be Speex,=A0. This=
 would give me an opportunity to migrate from devices that support legacy c=
odecs to devices that support Opus. The fact that different browser version=
s would support different codec sets (like desktop browsers not supporting =
AMR) is not a big issue, at least for me, since we always have G.711 or tra=
nscoding to fall back to. The same goes for browsers fazing some of the leg=
acy codecs out in the future. The end result would still be better then 100=
% G.711 or transcoding.


_____________
Roman Shpount





--047d7b5d277406cea804d7d1846d--

From prvs=5784dd8711=aallen@blackberry.com  Wed Mar 13 10:29: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 8AF9121F85D4 for ; Wed, 13 Mar 2013 10:29:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.984
X-Spam-Level: 
X-Spam-Status: No, score=-5.984 tagged_above=-999 required=5 tests=[AWL=0.614,  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 2F5vNxDU+Tfn for ; Wed, 13 Mar 2013 10:29:47 -0700 (PDT)
Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 557E821F8459 for ; Wed, 13 Mar 2013 10:29:47 -0700 (PDT)
X-AuditID: 0a412830-b7ef86d00000339d-6e-5140b77e7df9
Received: from XCT103ADS.rim.net (xct103ads.rim.net [10.67.111.44]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id FE.7D.13213.E77B0415; Wed, 13 Mar 2013 12:29:35 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT103ADS.rim.net ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 12:29:34 -0500
From: Andrew Allen 
To: "roman@telurix.com" , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIBBTajoIOkWHW02dWrWPKwvhNw==
Date: Wed, 13 Mar 2013 17:29:33 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.253]
Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338D28AC3XMB104ADSrimnet_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLKsWRmVeSWpSXmKPExsXC5Zyvo1u/3SHQ4O58DosZF6YyW6z9187u wOSxZMlPJo9bUwoCmKIaGG2SEkvKgjPT8/TtbBLz8vJLEktSFVJSi5NtlXxS0xNzFAKKMssS kysVXDKLk3MSM3NTi5QUMlNslUyUFApyEpNTc1PzSmyVEgsKUvNSlOy4FDCADVBZZp5Cal5y fkpmXrqtkmewv66FhamlrqGSnW5CJ0/GlR8T2QpWWVTMfTCTsYHxjlkXIyeHhICJxIaFe9gg bDGJC/fWA9lcHEICbUwS0/buY4dwNjNKzHi6mBmkik1AS2L/4elMILaIQJDE9r2bwGxhgXiJ +xPvM0LEEyT+fP7NDmHrSXz8MRmsl0VAVaLn+FGwOK+Ah8T8p+fAbE6BQImrfSvBehkFZCV2 n70ONpNZQFzi1pP5TBDXCUgs2XOeGcIWlXj5+B8rhK0o8Xfvd1aI+nyJW9cfs0HMF5Q4OfMJ ywRG4VlIRs1CUjYLSdksRg6guKbE+l36ECWKElO6H7JD2BoSrXPmsiOLL2BkX8UomJtRbGBm mJyXrFeUmauXl1qyiRGUJBw1DHYwvn9vcYhRgINRiYd323SHQCHWxLLiytxDjBIczEoivMtz gUK8KYmVValF+fFFpTmpxYcYg4ABNJFZijs5H5jA8krijQ0MiOQoifOKBIoGCgmkA9NVdmpq QWoRzFAmDk6QpVxSIsXApJNalFhakhEPSo3xxcDkKNXAOI9XwvT6krsnD3WWaXnuy1E+2FT0 4O+t24mHrs23OqkswsZ9aGvzruk7tKbYzn16XKAkMfPK9V9/srdP62Nt/vvp+o4zWVNKf2Wf fP70bngFY4PffK2Hh/1VfjO5abOmbZgnkqlQdeO06LdF/NdzvL7/2d1Q4WIrfEj7o3VBkID5 p0Lu+weuXVFiKc5INNRiLipOBAChL27gYAMAAA==
Subject: Re: [rtcweb] Agenda time request for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 17:29:48 -0000

--_000_BBF5DDFE515C3946BC18D733B20DAD2338D28AC3XMB104ADSrimnet_
Content-Type: text/plain; charset="utf-8"
content-transfer-encoding: base64

DQpJZiB0aGVyZSBpcyBhIGJ1c2luZXNzIGNhc2UgZm9yIGltcGxlbWVudGVycyB0byBzdXBw
b3J0IG90aGVyIGNvZGVjcyBmb3IgaW1wcm92ZWQgaW50ZW9wZXJhYmlsaXR5IHdpdGggb3Ro
ZXIgbmV0d29ya3MgYW5kIGRldmljZXMgdGhlbiB0aGV5IGFyZSB2ZXJ5IGxpa2VseSB0byBk
byBzby4NCg0KDQoNCkZyb206IFJvbWFuIFNocG91bnQgW21haWx0bzpyb21hbkB0ZWx1cml4
LmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMTMsIDIwMTMgMTI6MTIgUE0gQ2VudHJh
bCBTdGFuZGFyZCBUaW1lDQpUbzogcnRjd2ViQGlldGYub3JnIDxydGN3ZWJAaWV0Zi5vcmc+
DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gQWdlbmRhIHRpbWUgcmVxdWVzdCBmb3IgZHJhZnQt
bWFyam91LXJ0Y3dlYi1hdWRpby1jb2RlY3MtZm9yLWludGVyb3AtMDENCg0KTm9ybWFsbHks
IHdoZW4gaW1wbGVtZW50aW5nIFZvSVAgZGV2aWNlcywgdW5sZXNzIHRoZXkgYXJlIGludGVu
ZGVkIGZvciBzb21lIHNvcnQgb2Ygd2FsbGVkIGdhcmRlbiwgeW91IHRyeSB0byBzdXBwb3J0
IGFzIG1hbnkgY29kZWNzIGFzIHBvc3NpYmxlLiBUaGlzIGluY3JlYXNlcyB5b3VyIGNoYW5j
ZXMgb2YgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIG90aGVyIGRldmljZXMgYW5kIHlvdXIgcHJv
ZHVjdCBhZG9wdGlvbi4gSW4gY2FzZSBvZiBXZWJSVEMsIGl0IHdvdWxkIGJlIGFkb3B0ZWQg
cmVnYXJkbGVzcyBvZiB3aGF0IGNvZGVjcyBhcmUgc3VwcG9ydGVkLiBUaGUgbnVtYmVyIG9m
IGVuYWJsZWQgZGV2aWNlcyB3b3VsZCBiZSBzbyBncmVhdCB0aGF0IGFsbCB0aGUgbGVnYWN5
IG5ldHdvcmtzIHdpbGwgaGF2ZSB0byBhZGFwdC4gVGhpcyBoYXMgc29tZSBuZWdhdGl2ZSBp
bXBsaWNhdGlvbnMgdG8gdGhlIGxlZ2FjeSBuZXR3b3JrcyBhcyBmYXIgYXMgcXVhbGl0eSBh
bmQgY29zdHMgYXJlIGNvbmNlcm5lZCwgYnV0IHRoZXNlIGNoYWxsZW5nZXMgYXJlIG5vdCBp
bnN1cm1vdW50YWJsZS4gU28sIHRha2luZyB0aGlzIGludG8gY29uc2lkZXJhdGlvbiwgSSB3
YW50IHRvIHBsYWNlIHRoZSBzYW1lIHF1ZXN0aW9ucyBkaWZmZXJlbnRseToNCg0KRG8gd2Vi
IGJyb3dzZXIgaW1wbGVtZW50ZXJzIGN1cnJlbnRseSBwbGFuIHRvIHN1cHBvcnQgYW55IG90
aGVyIGNvZGVjcyBleGNlcHQgTVRJIChHLjcxMSBhbmQgT1BVUyk/DQoNCklzIHRoZXJlIGFu
eXRoaW5nIHdlIGFyZSBnb2luZyB0byBzYXkgaGVyZSByZWdhcmRpbmcgbGVnYWN5IGludGVy
b3AgdGhhdCB3b3VsZCBtYWtlIGJyb3dzZXIgbWFudWZhY3R1cmVycyB0byBjaGFuZ2UgdGhl
aXIgbWluZD8gQWZ0ZXIgYWxsLCB0aGlzIHJlcHJlc2VudHMgYWRkaXRpb25hbCBjb3N0IHRv
IHRoZW0gd2l0aCBubyBkaXJlY3QgYmVuZWZpdCBmb3IgdGhlIHVzZSBjYXNlcyB3aGljaCBh
cmUgbW9zdCBpbXBvcnRhbnQgdG8gdGhlbSAoYnJvd3NlciB0byBicm93c2VyIGNhbGxzKS4N
Cg0KRm9yIG1lLCB0aGUgZGVzaXJlZCBvdXRjb21lIHdvdWxkIGJlIHRoYXQgYnJvd3NlcnMs
IGF0IGxlYXN0IGZvciB0aGUgbmV4dCBmZXcgeWVhcnMsIGRvIHN1cHBvcnQgYSByZWFzb25h
YmxlIHNldCBvZiBvdGhlciBjb2RlY3MgaW4gYWRkaXRpb24gdG8gTVRJLCBpbmNsdWRpbmcg
Ry43MjIsIEFNUiwgQU1SLVdCLCBhbmQgbWF5IGJlIFNwZWV4LCAuIFRoaXMgd291bGQgZ2l2
ZSBtZSBhbiBvcHBvcnR1bml0eSB0byBtaWdyYXRlIGZyb20gZGV2aWNlcyB0aGF0IHN1cHBv
cnQgbGVnYWN5IGNvZGVjcyB0byBkZXZpY2VzIHRoYXQgc3VwcG9ydCBPcHVzLiBUaGUgZmFj
dCB0aGF0IGRpZmZlcmVudCBicm93c2VyIHZlcnNpb25zIHdvdWxkIHN1cHBvcnQgZGlmZmVy
ZW50IGNvZGVjIHNldHMgKGxpa2UgZGVza3RvcCBicm93c2VycyBub3Qgc3VwcG9ydGluZyBB
TVIpIGlzIG5vdCBhIGJpZyBpc3N1ZSwgYXQgbGVhc3QgZm9yIG1lLCBzaW5jZSB3ZSBhbHdh
eXMgaGF2ZSBHLjcxMSBvciB0cmFuc2NvZGluZyB0byBmYWxsIGJhY2sgdG8uIFRoZSBzYW1l
IGdvZXMgZm9yIGJyb3dzZXJzIGZhemluZyBzb21lIG9mIHRoZSBsZWdhY3kgY29kZWNzIG91
dCBpbiB0aGUgZnV0dXJlLiBUaGUgZW5kIHJlc3VsdCB3b3VsZCBzdGlsbCBiZSBiZXR0ZXIg
dGhlbiAxMDAlIEcuNzExIG9yIHRyYW5zY29kaW5nLg0KX19fX19fX19fX19fXw0KUm9tYW4g
U2hwb3VudA0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIHRyYW5zbWlzc2lvbiAoaW5j
bHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9y
bWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVj
dGVkIGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxpY2FibGUgcHJpdmls
ZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4gQW55IHVzZSBv
ZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCBy
ZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFu
c21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2Vu
ZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2Us
IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMg
dHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QgYXV0aG9yaXpl
ZCBhbmQgbWF5IGJlIHVubGF3ZnVsLg0K

--_000_BBF5DDFE515C3946BC18D733B20DAD2338D28AC3XMB104ADSrimnet_
Content-Type: text/html; charset="utf-8"
content-transfer-encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGZvbnQg
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxicj4NCklmIHRoZXJl
IGlzIGEgYnVzaW5lc3MgY2FzZSBmb3IgaW1wbGVtZW50ZXJzIHRvIHN1cHBvcnQgb3RoZXIg
Y29kZWNzIGZvciBpbXByb3ZlZCBpbnRlb3BlcmFiaWxpdHkgd2l0aCBvdGhlciBuZXR3b3Jr
cyBhbmQgZGV2aWNlcyB0aGVuIHRoZXkgYXJlIHZlcnkgbGlrZWx5IHRvIGRvIHNvLjxicj4N
Cjxicj4NCjwvZm9udD48YnI+DQombmJzcDs8YnI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu
IDBpbiI+DQo8Zm9udCBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGI+RnJvbTwvYj46IFJv
bWFuIFNocG91bnQgW21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0NCjxicj4NCjxiPlNlbnQ8
L2I+OiBXZWRuZXNkYXksIE1hcmNoIDEzLCAyMDEzIDEyOjEyIFBNIENlbnRyYWwgU3RhbmRh
cmQgVGltZTxicj4NCjxiPlRvPC9iPjogcnRjd2ViQGlldGYub3JnICZsdDtydGN3ZWJAaWV0
Zi5vcmcmZ3Q7IDxicj4NCjxiPlN1YmplY3Q8L2I+OiBSZTogW3J0Y3dlYl0gQWdlbmRhIHRp
bWUgcmVxdWVzdCBmb3IgZHJhZnQtbWFyam91LXJ0Y3dlYi1hdWRpby1jb2RlY3MtZm9yLWlu
dGVyb3AtMDENCjxicj4NCjwvZm9udD4mbmJzcDs8YnI+DQo8L2Rpdj4NCjxkaXY+Tm9ybWFs
bHksIHdoZW4gaW1wbGVtZW50aW5nIFZvSVAgZGV2aWNlcywgdW5sZXNzIHRoZXkgYXJlIGlu
dGVuZGVkIGZvciBzb21lIHNvcnQgb2Ygd2FsbGVkIGdhcmRlbiwgeW91IHRyeSB0byBzdXBw
b3J0IGFzIG1hbnkgY29kZWNzIGFzIHBvc3NpYmxlLiBUaGlzIGluY3JlYXNlcyB5b3VyIGNo
YW5jZXMgb2YgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIG90aGVyIGRldmljZXMgYW5kIHlvdXIg
cHJvZHVjdCBhZG9wdGlvbi4gSW4gY2FzZSBvZiBXZWJSVEMsDQogaXQgd291bGQgYmUgYWRv
cHRlZCByZWdhcmRsZXNzIG9mIHdoYXQgY29kZWNzIGFyZSBzdXBwb3J0ZWQuIFRoZSBudW1i
ZXIgb2YgZW5hYmxlZCBkZXZpY2VzIHdvdWxkIGJlIHNvIGdyZWF0IHRoYXQgYWxsIHRoZSBs
ZWdhY3kgbmV0d29ya3Mgd2lsbCBoYXZlIHRvIGFkYXB0LiBUaGlzIGhhcyBzb21lIG5lZ2F0
aXZlIGltcGxpY2F0aW9ucyB0byB0aGUgbGVnYWN5IG5ldHdvcmtzIGFzIGZhciBhcyBxdWFs
aXR5IGFuZCBjb3N0cyBhcmUgY29uY2VybmVkLA0KIGJ1dCB0aGVzZSBjaGFsbGVuZ2VzIGFy
ZSBub3QgaW5zdXJtb3VudGFibGUuIFNvLCB0YWtpbmcgdGhpcyBpbnRvJm5ic3A7Y29uc2lk
ZXJhdGlvbiwgSSB3YW50IHRvIHBsYWNlIHRoZSBzYW1lIHF1ZXN0aW9ucyBkaWZmZXJlbnRs
eTo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkRvIHdlYiBicm93c2VyIGltcGxl
bWVudGVycyBjdXJyZW50bHkgcGxhbiB0byBzdXBwb3J0IGFueSBvdGhlciBjb2RlY3MgZXhj
ZXB0IE1USSAoRy43MTEgYW5kIE9QVVMpPzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk
aXY+SXMgdGhlcmUgYW55dGhpbmcgd2UgYXJlIGdvaW5nIHRvIHNheSBoZXJlIHJlZ2FyZGlu
ZyBsZWdhY3kgaW50ZXJvcCB0aGF0IHdvdWxkIG1ha2UgYnJvd3NlciBtYW51ZmFjdHVyZXJz
IHRvIGNoYW5nZSB0aGVpciBtaW5kPyBBZnRlciBhbGwsIHRoaXMgcmVwcmVzZW50cyBhZGRp
dGlvbmFsIGNvc3QgdG8gdGhlbSB3aXRoIG5vIGRpcmVjdCBiZW5lZml0IGZvciB0aGUgdXNl
IGNhc2VzIHdoaWNoIGFyZSBtb3N0IGltcG9ydGFudCB0byB0aGVtDQogKGJyb3dzZXIgdG8g
YnJvd3NlciBjYWxscykuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Gb3IgbWUs
IHRoZSBkZXNpcmVkIG91dGNvbWUgd291bGQgYmUgdGhhdCBicm93c2VycywgYXQgbGVhc3Qg
Zm9yIHRoZSBuZXh0IGZldyB5ZWFycywgZG8gc3VwcG9ydCBhIHJlYXNvbmFibGUgc2V0IG9m
IG90aGVyIGNvZGVjcyBpbiBhZGRpdGlvbiB0byBNVEksIGluY2x1ZGluZyBHLjcyMiwgQU1S
LCBBTVItV0IsIGFuZCBtYXkgYmUgU3BlZXgsJm5ic3A7LiBUaGlzIHdvdWxkIGdpdmUgbWUg
YW4gb3Bwb3J0dW5pdHkgdG8gbWlncmF0ZSBmcm9tIGRldmljZXMNCiB0aGF0IHN1cHBvcnQg
bGVnYWN5IGNvZGVjcyB0byBkZXZpY2VzIHRoYXQgc3VwcG9ydCBPcHVzLiBUaGUgZmFjdCB0
aGF0IGRpZmZlcmVudCBicm93c2VyIHZlcnNpb25zIHdvdWxkIHN1cHBvcnQgZGlmZmVyZW50
IGNvZGVjIHNldHMgKGxpa2UgZGVza3RvcCBicm93c2VycyBub3Qgc3VwcG9ydGluZyBBTVIp
IGlzIG5vdCBhIGJpZyBpc3N1ZSwgYXQgbGVhc3QgZm9yIG1lLCBzaW5jZSB3ZSBhbHdheXMg
aGF2ZSBHLjcxMSBvciB0cmFuc2NvZGluZyB0bw0KIGZhbGwgYmFjayB0by4gVGhlIHNhbWUg
Z29lcyBmb3IgYnJvd3NlcnMgZmF6aW5nIHNvbWUgb2YgdGhlIGxlZ2FjeSBjb2RlY3Mgb3V0
IGluIHRoZSBmdXR1cmUuIFRoZSBlbmQgcmVzdWx0IHdvdWxkIHN0aWxsIGJlIGJldHRlciB0
aGVuIDEwMCUgRy43MTEgb3IgdHJhbnNjb2RpbmcuPC9kaXY+DQo8ZGl2Pg0KPGRpdj5fX19f
X19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDwvZGl2Pg0KPGJyPg0KPGJyPg0KPC9kaXY+
DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KVGhpcyB0cmFuc21pc3Npb24gKGluY2x1ZGluZyBh
bnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiwg
cHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBieSB0
aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMpLCBv
ciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhpcyBp
bmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50
IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9u
IGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciBhbmQg
ZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNlLCBkaXNzZW1p
bmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIHRyYW5zbWlz
c2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6ZWQgYW5kIG1h
eSBiZSB1bmxhd2Z1bC4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_BBF5DDFE515C3946BC18D733B20DAD2338D28AC3XMB104ADSrimnet_--

From keith.drage@alcatel-lucent.com  Wed Mar 13 10:37: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 19B7F21F8E09 for ; Wed, 13 Mar 2013 10:37:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.173
X-Spam-Level: 
X-Spam-Status: No, score=-110.173 tagged_above=-999 required=5 tests=[AWL=0.425, 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 NqgygSdDg7MB for ; Wed, 13 Mar 2013 10:37:07 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7365D21F8E04 for ; Wed, 13 Mar 2013 10:37:06 -0700 (PDT)
Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r2DHb2Zx025182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Mar 2013 12:37:02 -0500 (CDT)
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r2DHavm6012595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 13 Mar 2013 12:37:02 -0500
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 13 Mar 2013 13:37:00 -0400
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 13 Mar 2013 18:36:59 +0100
From: "DRAGE, Keith (Keith)" 
To: Andrew Allen , "roman@telurix.com" , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Agenda time request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIBBTajoIOkWHW02dWrWPKwvhN5ij4Osg
Date: Wed, 13 Mar 2013 17:36:57 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B013D9D@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References:  
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B013D9DFR712WXCHMBA11zeu_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12
Subject: Re: [rtcweb] Agenda time request	for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 17:37:10 -0000

--_000_949EF20990823C4C85C18D59AA11AD8B013D9DFR712WXCHMBA11zeu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The problem is that the business case for the device vendor or end user may=
 not be the business case for the browser vendor.

To be honest this discussion goes round and round in circles, with people t=
rying to say things are out of scope.

What I believe we need is something that encourages creation of APIs for em=
bedded codecs in the devices. Those API's should then be made available wit=
hin the browser.

This gets even more important when we get to video codecs. I am certainly i=
nterested in gateways from RTCWEB endpoints to other SIP based networks. Ha=
ving to transcode from one video codec to another because of this impasse i=
s a nightmare.

Someone has to break this loop.

Keith

________________________________
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Andrew Allen
Sent: 13 March 2013 17:30
To: roman@telurix.com; rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01


If there is a business case for implementers to support other codecs for im=
proved inteoperability with other networks and devices then they are very l=
ikely to do so.



From: Roman Shpount [mailto:roman@telurix.com]
Sent: Wednesday, March 13, 2013 12:12 PM Central Standard Time
To: rtcweb@ietf.org 
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01

Normally, when implementing VoIP devices, unless they are intended for some=
 sort of walled garden, you try to support as many codecs as possible. This=
 increases your chances of interoperability with other devices and your pro=
duct adoption. In case of WebRTC, it would be adopted regardless of what co=
decs are supported. The number of enabled devices would be so great that al=
l the legacy networks will have to adapt. This has some negative implicatio=
ns to the legacy networks as far as quality and costs are concerned, but th=
ese challenges are not insurmountable. So, taking this into consideration, =
I want to place the same questions differently:

Do web browser implementers currently plan to support any other codecs exce=
pt MTI (G.711 and OPUS)?

Is there anything we are going to say here regarding legacy interop that wo=
uld make browser manufacturers to change their mind? After all, this repres=
ents additional cost to them with no direct benefit for the use cases which=
 are most important to them (browser to browser calls).

For me, the desired outcome would be that browsers, at least for the next f=
ew years, do support a reasonable set of other codecs in addition to MTI, i=
ncluding G.722, AMR, AMR-WB, and may be Speex, . This would give me an oppo=
rtunity to migrate from devices that support legacy codecs to devices that =
support Opus. The fact that different browser versions would support differ=
ent codec sets (like desktop browsers not supporting AMR) is not a big issu=
e, at least for me, since we always have G.711 or transcoding to fall back =
to. The same goes for browsers fazing some of the legacy codecs out in the =
future. The end result would still be better then 100% G.711 or transcoding=
.
_____________
Roman Shpount

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.

--_000_949EF20990823C4C85C18D59AA11AD8B013D9DFR712WXCHMBA11zeu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











The problem is that the business case =
for the device vendor or end user may not be the business case for the brow=
ser vendor.


 


To be honest this discussion goes roun=
d and round in circles, with people trying to say things are out of scope.<=
o:p>


 


What I believe we need is something th=
at encourages creation of APIs for embedded codecs in the devices. Those
API’s should then be m=
ade available within the browser.



 


This gets even more important when we =
get to video codecs. I am certainly interested in gateways from RTCWEB endp=
oints to other SIP based
 networks. Having to transcode from one video codec to another because of t=
his impasse is a nightmare.


 


Someone has to break this loop.


 


Keith


 












From: rtcweb-bounces@ietf.org
 [mailto:rtcweb-bounces@ietf.org] On Be=
half Of 
Andrew Allen

Sent: 13 March 2013 17:30
To: roman@telurix.com; rtcwe=
b@ietf.org

Subject: Re: [rtcweb] Agenda=
 time request for draft-marjou-rtcweb-audio-codecs-for-interop-01




 


=


If there is a business case for implementers to support other codecs for im=
proved inteoperability with other networks and devices then they are very l=
ikely to do so.





 




From: Roma=
n Shpount [mailto:roman@telurix.com]


Sent: Wednesday, 
March 13, 2013 1=
2:12 PM Central Standard Time

To: rtcweb@ietf.org <rtcw=
eb@ietf.org>


Subject: Re: [rtcweb] Agenda=
 time request for draft-marjou-rtcweb-audio-codecs-for-interop-01


 






Normally, when implementing VoIP devices, unless they are intended =
for some sort of walled garden, you try to support as many codecs as possib=
le. This increases your
 chances of interoperability with other devices and your product adoption. =
In case of WebRTC, it would be adopted regardless of what codecs are suppor=
ted. The number of enabled devices would be so great that all the legacy ne=
tworks will have to adapt. This
 has some negative implications to the legacy networks as far as quality an=
d costs are concerned, but these challenges are not insurmountable. So, tak=
ing this into consideration, I want to place the same questions differ=
ently:






 






Do web browser implementers currently plan to support any other cod=
ecs except MTI (G.711 and OPUS)?






 






Is there anything we are going to say here regarding legacy interop=
 that would make browser manufacturers to change their mind? After all, thi=
s represents additional
 cost to them with no direct benefit for the use cases which are most impor=
tant to them (browser to browser calls).






 






For me, the desired outcome would be that browsers, at least for th=
e next few years, do support a reasonable set of other codecs in addition t=
o MTI, including G.722,
AMR, AMR-WB, and may be Speex, . This would give =
me an opportunity to migrate from devices that support legacy codecs to dev=
ices that support Opus. The fact that different
 browser versions would support different codec sets (like desktop browsers=
 not supporting
AMR) is not a big issue, at =
least for me, since we always have G.711 or transcoding to fall back to. Th=
e same goes for browsers fazing some of the legacy codecs out in the future=
. The end result would still be better
 then 100% G.711 or transcoding.








_____________

Roman Shpount




 




-------------------------------------------------------------------=
--


This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information
 by anyone other than the intended recipient is prohibited. If you have rec=
eived this transmission in error, please immediately reply to the sender an=
d delete this information from your system. Use, dissemination, distributio=
n, or reproduction of this transmission
 by unintended recipients is not authorized and may be unlawful. 








--_000_949EF20990823C4C85C18D59AA11AD8B013D9DFR712WXCHMBA11zeu_--

From yekuiw@qti.qualcomm.com  Wed Mar 13 10:40: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 E1D4421F8D98 for ; Wed, 13 Mar 2013 10:40:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.309
X-Spam-Level: 
X-Spam-Status: No, score=-102.309 tagged_above=-999 required=5 tests=[AWL=0.291, 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 Lwydx2gnBsNz for ; Wed, 13 Mar 2013 10:40:01 -0700 (PDT)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 454F821F8D66 for ; Wed, 13 Mar 2013 10: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=1363196401; x=1394732401; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bjcYH7E66hFspy5DxDS5Iu9F/24PClD8Y0ErNCwbHjk=; b=N3KHd84ymwNrFa5s63BebcEfuTjbNTPod9bEiJ8Nzda9u/SrkMbyv5Fg 4l/H7NZ3f5Q9hPC3FvWMl817IV2iFx9ipop29JXam0o4Onfy9OWxF8n8t jTYybz/WfzGO6L81UnT7Md/LWWWYtYbafInftx8LGIBB0gaMj7YhzECCa 0=;
X-IronPort-AV: E=Sophos;i="4.84,838,1355126400"; d="scan'208";a="29810898"
Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth01.qualcomm.com with ESMTP; 13 Mar 2013 10:40:00 -0700
Received: from nasanexhc14.na.qualcomm.com ([172.30.48.23]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 Mar 2013 10:40:00 -0700
Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.64]) by nasanexhc14.na.qualcomm.com ([172.30.48.23]) with mapi id 14.02.0318.004; Wed, 13 Mar 2013 10:40:00 -0700
From: "Wang, Ye-Kui" 
To: Stockhammer Thomas , Bo Burman 
Thread-Topic: [rtcweb] Video Codec discussion in Thursday agenda slot
Thread-Index: AQHOH0jr3vjUB09c8EG4MhtYHbfvE5ii0RyAgAAIloCAAAHrgIABTYKAgAACnQD//7k88A==
Date: Wed, 13 Mar 2013 17:40:00 +0000
Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A8331B17F22@nasanexd02f.na.qualcomm.com>
References: <513F68C0.4010106@ericsson.com>  <513F7745.3020302@alvestrand.no>   
In-Reply-To: 
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: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 17:40:03 -0000

> >  How many others who did not respond to MPEG LA's call but have IPR=20
> > are
> there?
>=20
> [TS]  Just one more hypothesis: If I would have, what would be my=20
> obligation/motivation to do so now?

Speaking of the motivation part; that would depend on who YOU are and what =
kind of business model or plan YOU have in mind.=20

BR, YK

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
> Of Stockhammer Thomas
> Sent: Wednesday, March 13, 2013 7:53 AM
> To: Bo Burman
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
>=20
>=20
> >  How many others who did not respond to MPEG LA's call but have IPR are
> there?
>=20
> [TS]  Just one more hypothesis: If I would have, what would be my
> obligation/motivation to do so now?
>=20
> >>>
> >>> We appreciate the need to have time to evaluate the specific words
> >>> of the license statements that are forthcoming, and the need for the
> >>> people who haven't made their IPR declarations over the last couple
> >>> of years of discussion to do so within the next couple of weeks -
> >>> but we do think that it is important to use the face to face time
> >>> that we have here in Orlando to lay to rest any *other* issues than
> >>> the licensing terms and other issues derived from Google's
> announcement.
> >>
> >> I am not sure we can have a reasoned consideration of 'other issues
> derived'
> >> at such short notice.
> >>
> >> Look, I'd like our discussions and decisions to be informed and
> >> considered, and there simply isn't time for either.
> >>
> >>>
> >>> Harald
> >>>
> >>> _______________________________________________
> >>> rtcweb mailing list
> >>> rtcweb@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/rtcweb
> >>
> >> David Singer
> >> Multimedia and Software Standards, Apple Inc.
> >>
> >> _______________________________________________
> >> rtcweb mailing list
> >> rtcweb@ietf.org
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> >
>=20
> ---
> Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49
> 89 978980 02 || cell +491725702667 || http://www.nomor-research.com
> Nomor Research GmbH  -  Sitz der Gesellschaft: M=FCnchen - Registergerich=
t:
> M=FCnchen, HRB 165856 - Umsatzsteuer-ID: DE238047637 - Gesch=E4ftsf=FChre=
r:
> Dr. Thomas Stockhammer, Dr. Ingo Viering.
>=20
>=20
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

From Kalyani.Bogineni@VerizonWireless.com  Wed Mar 13 08:14: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 5025521F86D9 for ; Wed, 13 Mar 2013 08:14:42 -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=[AWL=-0.000, 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 PzowS1xuovze for ; Wed, 13 Mar 2013 08:14:40 -0700 (PDT)
Received: from vanguard.verizonwireless.com (vanguard.verizonwireless.com [162.115.35.70]) by ietfa.amsl.com (Postfix) with ESMTP id A3F0621F8606 for ; Wed, 13 Mar 2013 08:14:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizonwireless.com; i=@verizonwireless.com; l=0; q=dns/txt; s=prodmail; t=1363187679; x=1394723679; h=from:to:cc:date:subject:references:in-reply-to: mime-version; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=lvZoWWUwcf2sxrdXgOj1EocdysylOG/pu1Vc3PrKi52v7MPVFjnRDGOa 6wq8lRczE6Ned+bxXORUasASBLENElofmTUZKR2TmRt+je+LYjfWO/cWC r+tl2E6J9GOhwC/obm6qxm/MuuO3XDDs5anfWsH6fRl85lHV5xzIi4Dp9 s=;
Received: from ohdub02exhub03.uswin.ad.vzwcorp.com ([10.97.42.165]) by vanguard.verizonwireless.com with ESMTP; 13 Mar 2013 08:14:35 -0700
Received: from OHDUB02EXCV33.uswin.ad.vzwcorp.com ([10.97.42.179]) by OHDUB02EXHUB03.uswin.ad.vzwcorp.com ([10.97.42.165]) with mapi; Wed, 13 Mar 2013 11:14:16 -0400
From: "Bogineni, Kalyani" 
To: 'Andrew Allen' , Xavier Marjou , "rtcweb@ietf.org" 
Date: Wed, 13 Mar 2013 11:14:16 -0400
Thread-Topic: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOH+y5qq47PO3D8ky8VwcKUkGl6pijrV3AgAALMDA=
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: multipart/alternative; boundary="_000_4FB1AF8D91129944881538CDCC5347CF03206857F0OHDUB02EXCV33_"
MIME-Version: 1.0
Message-Id: <20130313151439.A3F0621F8606@ietfa.amsl.com>
X-Mailman-Approved-At: Wed, 13 Mar 2013 10:49:11 -0700
Cc: "Bogineni, Kalyani" 
Subject: Re: [rtcweb] Agenda time request for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 15:14:42 -0000

--_000_4FB1AF8D91129944881538CDCC5347CF03206857F0OHDUB02EXCV33_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

draft-marjou-rtcweb-audio-codecs-for-interop-01 is based on the recommendat=
ion
and clarification from the Chair regarding the conclusion (included below).

Regards,
Kalyani Bogineni

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Jan 28, 2013, at 1:12 AM, Magnus Westerlund  wrote:

> Hi,
>
> We chairs was considering inclusion in draft-ietf-webrtc-audio, but we
> didn't have any strong opinions on this. Based on that several WG
> participants thinks this should be an independent document, I thus
> decided that we will start out with an independent document. If the WG
> feels differently later we can always fold the text into the audio codec
> and processing requirements document.
>
> I would recommend that the individuals interested in contributing a
> codec writes an independent submission with focus on the codec
> considerations around the codec(s) they are interested in. Then we can
> merge this into a common WG document.
>
> Cheers
>
> Magnus

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Andrew Allen
Sent: Wednesday, March 13, 2013 10:30 AM
To: Xavier Marjou; rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01


I think this draft is not consistent with the scope stated by the RTCweb ch=
airs in the decision on this topic  back in February

"Additional Relevant Codecs". That can contain a list of codecs which are r=
elevant in specific  contexts, along with a short description of the contex=
t for each. Specifically there seems to be interest in understanding the  a=
dvantages and costs of G.722, AMR, and AMR-WB. We hope that text would broa=
den understanding of the WebRTC use case contexts.
The current draft goes way beyond that decision in scope and uses MUST and =
SHOULD strength normative language instead of focusing on identifying the a=
dvantages and costs of the specific codecs and the use case contexts of whe=
re they are useful.

I think we should stick to the scope defined by the chairs and remove the n=
ormative language and focus on identifying the advantages and costs of the =
specific codecs and the use case contexts of where they are useful..

Andrew

From: rtcweb-bounces@ietf.org [mailto:rtcwe=
b-bounces@ietf.org] On Behalf Of Xavier Marjou
Sent: Wednesday, March 13, 2013 9:15 AM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01


Here is a summary of the draft-marjou-rtcweb-audio-codecs-for-interop-00 pr=
esentation that I had prepared for yesterday's session:

- The co-authors want to underline that non-WebRTC voice endpoints usually =
use one of the following codecs: AMR, AMR-WB or G.722, which will result in=
 massive transcoding when there will be communications between WebRTC endpo=
ints and non-WebRTC endpoints.

- On one side, transcoding is bad for many reasons discussed in the draft (=
cost issues, intrinsic quality degradation, degraded interactivity, fallbac=
k from HD to G.711...);

- On the other side, it is recognized that implementing additional codecs i=
n the browsers can generate additional costs.

- In order to reach a compromise, we would like to add some text in the WG =
draft draft-ietf-rtcweb-audio providing incentives for the browser to use t=
hese three codecs: make them mandatory to implement when there is no cost i=
mpact on the browser (e.g. if codec already installed, paid by the device v=
endor...).

Any opinion on that?

Cheers,

Xavier

PS: I will be ready to present the slides on Thursday if time permits it.

(c.f. http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf )



On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie > wrote:
Magnus and I discussed this this morning, and we encourage you to
prepare something.  If the discussion of working group last call items
runs short, we may be able to fit this in at that time or at the end
of day one if its full agenda his finished.  This is not a commitment,
however, so please try and get discussion on the list on the points
from the draft you feel need resolution.

regards,

Ted


On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)
> wrote:
> Hello,
>
>
>
> I would like to request agenda time for:
>
>
>
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
>
>
> The document  presents use-cases underlining why WebRTC needs AMR-WB,  AM=
R
> and G.722 as additional relevant voice codecs to satisfactorily ensure
> interoperability with existing systems.
>
>
>
> A 10-minute time slot should be sufficient for presentation and discussio=
n.
>
>
>
> Regards
>
>
>
> -Espen
>
>
>
>
>
>
> _______________________________________________
> 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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.

--_000_4FB1AF8D91129944881538CDCC5347CF03206857F0OHDUB02EXCV33_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=

--_000_4FB1AF8D91129944881538CDCC5347CF03206857F0OHDUB02EXCV33_--

From adam@nostrum.com  Wed Mar 13 10:49: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 46EEC21F874D for ; Wed, 13 Mar 2013 10:49:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.575
X-Spam-Level: 
X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, 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 aooPSenw10Jw for ; Wed, 13 Mar 2013 10:49:37 -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 DA5FD21F8606 for ; Wed, 13 Mar 2013 10:49:30 -0700 (PDT)
Received: from dhcp-5033.meeting.ietf.org (dhcp-5033.meeting.ietf.org [130.129.80.51]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2DHnSID053069 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 13 Mar 2013 12:49:30 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <5140BC2C.90206@nostrum.com>
Date: Wed, 13 Mar 2013 13:49:32 -0400
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References:    <20130313142732.GE12022@audi.shelbyville.oz> <7897A33F-F73A-4C39-B4DA-16F014A43C5C@edvina.net>  <8B7442F6-5393-4C5C-88B6-A680742F60E7@edvina.net>  <3C89A60B-3171-49B0-A78F-304337DF8D3D@edvina.net>
In-Reply-To: <3C89A60B-3171-49B0-A78F-304337DF8D3D@edvina.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 130.129.80.51 is authenticated by a trusted mechanism)
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 17:49:38 -0000

On 3/13/13 11:42, Olle E. Johansson wrote:
> I don't think everyone gets the that selecting a small subset as mandatory for WebRTC does NOT exclude all other codecs. Feel free to add everything you got. Have fun. Let the best mutual codec with the best mutual properties win the session.

Olle hit the nail squarely on the head. This is exactly the purpose of 
offer/answer negotiation: to find the best intersection of endpoint 
capabilities for the desired communication session. I'm bewildered by 
the fairly consistent misinterpretation that having an MTI codec somehow 
implies that every other codec becomes "MNTI".

/a

From roman@telurix.com  Wed Mar 13 11: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 3DCD721F8DA2 for ; Wed, 13 Mar 2013 11:02:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.144
X-Spam-Level: 
X-Spam-Status: No, score=-1.144 tagged_above=-999 required=5 tests=[AWL=-0.833, 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 XOT3bq7HWyzI for ; Wed, 13 Mar 2013 11:02:04 -0700 (PDT)
Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id BA9C921F8D2E for ; Wed, 13 Mar 2013 11:02:00 -0700 (PDT)
Received: by mail-we0-f179.google.com with SMTP id p43so1295974wea.24 for ; Wed, 13 Mar 2013 11:01:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=GjP3JXrleDT8JUk9RCG5OhjtfjYYMmeix17ac56Whko=; b=NHKzXtS1lcFh1y+XcUoN6Dc7UffyK1ltLqVEnbDOCBAnA51z59ruyx5DY14NKVnz0o FRoeSTHWHzQJXi6yMnqhOfyQGWWE3aDI3lioJxgintvSbQoH6wJBHss3+xF5y9TPuhLN wXQ0HFqIIWtk3SZ+HP0mqyKUGB1QenD+2wwr9CqagN7OvUXnx96BUl8QDWPG0XJegmEi XzkIZapdeZQItjngv3yHI7RWIrSE9gacwMimaGkDrnCm+rfB6JfzbtkNylM7EUXA7U2n 8IwRahC1L/sv9EzkeowE7mqckvSwoUxXdqynRyk2IOsl0v9ma9GxFoc/HSZy18M+V7xB ywwA==
X-Received: by 10.180.183.4 with SMTP id ei4mr28645382wic.21.1363197719638; Wed, 13 Mar 2013 11:01:59 -0700 (PDT)
Received: from mail-we0-x22d.google.com ([2a00:1450:400c:c03::22d]) by mx.google.com with ESMTPS id o8sm4239734wix.7.2013.03.13.11.01.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Mar 2013 11:01:58 -0700 (PDT)
Received: by mail-we0-f173.google.com with SMTP id x51so1255756wey.4 for ; Wed, 13 Mar 2013 11:01:57 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.85.97 with SMTP id g1mr29063535wiz.29.1363197717722; Wed, 13 Mar 2013 11:01:57 -0700 (PDT)
Received: by 10.217.107.135 with HTTP; Wed, 13 Mar 2013 11:01:57 -0700 (PDT)
In-Reply-To: <5140BC2C.90206@nostrum.com>
References:    <20130313142732.GE12022@audi.shelbyville.oz> <7897A33F-F73A-4C39-B4DA-16F014A43C5C@edvina.net>  <8B7442F6-5393-4C5C-88B6-A680742F60E7@edvina.net>  <3C89A60B-3171-49B0-A78F-304337DF8D3D@edvina.net> <5140BC2C.90206@nostrum.com>
Date: Wed, 13 Mar 2013 14:01:57 -0400
Message-ID: 
From: Roman Shpount 
To: Adam Roach 
Content-Type: multipart/alternative; boundary=f46d0444036cb940cb04d7d233ed
X-Gm-Message-State: ALoCoQl3TdYBfIErdV4wt+X48zUHDNuJ0odUUOexjaIxZnyKOx23ElZcNFydL3zWe23HX+jOdKdk
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 18:02:05 -0000

--f46d0444036cb940cb04d7d233ed
Content-Type: text/plain; charset=ISO-8859-1

Let's not pretend that we got 500 different implementations of WebRTC and
that every one is making one. We got 4 or 5 that potentially matter, with 3
of them currently sharing the same code based for audio. All of the
currently available WebRTC implementations support G.711. Opus, and (most
likely deprecated in near future) ISAC. So far, the feedback I got was that
if codec is not MTI, it will not be implemented by the major browsers. For
instance, G.722 is part of current WebRTC code base, but it is disabled in
compile time from being accessible in the browsers.

So, if I, or anyone else, is implementing a web browser, I can add other
codecs, but this would serve no purpose whatsoever and is irrelevant to
this discussion.
_____________
Roman Shpount


On Wed, Mar 13, 2013 at 1:49 PM, Adam Roach  wrote:

> On 3/13/13 11:42, Olle E. Johansson wrote:
>
>> I don't think everyone gets the that selecting a small subset as
>> mandatory for WebRTC does NOT exclude all other codecs. Feel free to add
>> everything you got. Have fun. Let the best mutual codec with the best
>> mutual properties win the session.
>>
>
> Olle hit the nail squarely on the head. This is exactly the purpose of
> offer/answer negotiation: to find the best intersection of endpoint
> capabilities for the desired communication session. I'm bewildered by the
> fairly consistent misinterpretation that having an MTI codec somehow
> implies that every other codec becomes "MNTI".
>
> /a
>
> ______________________________**_________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/**listinfo/rtcweb
>

--f46d0444036cb940cb04d7d233ed
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Let's not pretend that we got 500 different implementations of WebRTC a=
nd that every one is making one. We got 4 or 5 that potentially matter, wit=
h 3 of them currently sharing the same code based for audio. All of the cur=
rently available WebRTC implementations support G.711. Opus, and (most like=
ly=A0deprecated=A0in near future) ISAC. So far, the feedback I got was that=
 if codec is not MTI, it will not be implemented by the major browsers. For=
 instance, G.722 is part of current WebRTC code base, but it is disabled in=
 compile time from being=A0accessible=A0in the browsers.


So, if I, or anyone else, is implementing a web browser, I c=
an add other codecs, but this would serve no purpose=A0whatsoever=A0and is =
irrelevant to this discussion.
_____________
Roman Shpount<=
/div>



On Wed, Mar 13, 2013 at 1:49 PM, Adam Ro=
ach <adam@nostrum.com> wrote:


On 3/13/13 11:42, Olle E. Johansson wrote:



I don't think everyone gets the that selecting a small subset as mandat=
ory for WebRTC does NOT exclude all other codecs. Feel free to add everythi=
ng you got. Have fun. Let the best mutual codec with the best mutual proper=
ties win the session.






Olle hit the nail squarely on the head. This is exactly the purpose of offe=
r/answer negotiation: to find the best intersection of endpoint capabilitie=
s for the desired communication session. I'm bewildered by the fairly c=
onsistent misinterpretation that having an MTI codec somehow implies that e=
very other codec becomes "MNTI".




/a


_______________________________________________

rtcweb mailing list

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





--f46d0444036cb940cb04d7d233ed--

From prvs=87842d98f0=aallen@blackberry.com  Wed Mar 13 11:06: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 58CCB21F8E00 for ; Wed, 13 Mar 2013 11:06:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.016
X-Spam-Level: 
X-Spam-Status: No, score=-6.016 tagged_above=-999 required=5 tests=[AWL=0.582,  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 WnRZtjIxhLwV for ; Wed, 13 Mar 2013 11:06:11 -0700 (PDT)
Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id CFEF521F8E0A for ; Wed, 13 Mar 2013 11:06:10 -0700 (PDT)
X-AuditID: 0a41282f-b7fa06d000002431-c7-5140c0058a2d
Received: from XCT105ADS.rim.net (xct105ads.rim.net [10.67.111.46]) by mhs060cnc.rim.net (SBG) with SMTP id 44.ED.09265.500C0415; Wed, 13 Mar 2013 13:05:58 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 13:05:57 -0500
From: Andrew Allen 
To: "keith.drage@alcatel-lucent.com" , "roman@telurix.com" , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Agenda time request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIBFgx2bVevKSSk6ahzAutyevXJij6q5L
Date: Wed, 13 Mar 2013 18:05:56 +0000
Message-ID: 
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B013D9D@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.253]
Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338D28B32XMB104ADSrimnet_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFKsWRmVeSWpSXmKPExsXC5Zyvp8t2wCHQ4Hc3t8XTxrOMFjMuTGW2 WPuvnd2B2aP12V5WjyVLfjJ53JpSEMAc1cBok5RYUhacmZ6nb2eTmJeXX5JYkqqQklqcbKvk k5qemKMQUJRZlphcqeCSWZyck5iZm1qkpJCZYqtkoqRQkJOYnJqbmldiq5RYUJCal6Jkx6WA AWyAyjLzFFLzkvNTMvPSbZU8g/11LSxMLXUNlex0Ezp5Mj7/+cde8GsrY8XKdW9YGhgnbGTs YuTkkBAwkZiycyYzhC0mceHeerYuRi4OIYGVjBLTDrWyQjibGSX+tV9nB6liE9CS2H94OhNI QkRgKqPErvYfYKOEBeIlvj1tZQKxRQQSJDZd7GKEsI0kpu++BraCRUBV4tmK3WCDeAU8JBZd mM8GYnMKREs0bl7FAmIzAp3x/dQasDnMAuISt57MZ4I4T0BiyZ7zUKeKSrx8/I8VwlaU+Lv3 OytEfb7E9+XHoOYLSpyc+YRlAqPwLCSjZiEpm4WkbBYjB1BcU2L9Ln2IEkWJKd0P2SFsDYnW OXPZkcUXMLKvYhTMzSg2MDNIzkvWK8rM1ctLLdnECEofjhr6Oxjfvrc4xCjAwajEwyu+yyFQ iDWxrLgy9xCjBAezkgjv8lygEG9KYmVValF+fFFpTmrxIcYgYABNZJbiTs4Hpra8knhjAwMi OUrivCKBooFCAunApJWdmlqQWgQzlImDE2Qpl5RIMTD1pBYllpZkxIMSZHwxMEVKNTAeeRTi Efc4vrP4yDwLV97sd0wyXVf0nLsni8f9bTYNlK7gbIn2NTzq+O/6Z5fgr2+lw5bttL+t+HFH QGm1xoxchnt3N7l9uhm6ZL100MVMpTl/pq7c0i7SvlDVNmtS79q8N6p53eEth/8HeotXHp5p OsHkmMzs+UvZPgupq4szPoz+9kYtyE2JpTgj0VCLuag4EQAyNO8FbQMAAA==
Subject: Re: [rtcweb] Agenda time request	for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 18:06:12 -0000

--_000_BBF5DDFE515C3946BC18D733B20DAD2338D28B32XMB104ADSrimnet_
Content-Type: text/plain; charset="utf-8"
content-transfer-encoding: base64

DQpLZWl0aA0KDQpUaGF0IGlzIG91dCBvZiBzY29wZSBvZiBJRVRGLiBXaGF0IEkgdGhpbmsg
eW91IGFyZSBzdWdnZXN0aW5nIGFtb3VudHMgdG8gb3BlcmF0aW5nIHN5c3RlbSBzdGFuZGFy
ZGlzYXRpb24uDQoNCklmIHlvdSBiZWxpZXZlIGluIHRoZSBtYXJrZXQgdGhlbiB0aGUgYnVz
aW5lc3MgY2FzZSBvZiB0aGUgYnJvd3NlciBpbXBsZW1lbnRlcnMgYW5kIHRoZSBkZXZpY2Ug
dmVuZG9ycyBzaG91bGQgYWxpZ24gd2l0aCB0aGUgaW50ZXJlc3RzIG9mIHRoZSB1c2VycyAo
SS5lIHRoZWlyIGN1c3RvbWVycykgYXNzdW1pbmcgdGhlIGNvc3RzIGFyZSBub3QgcHJvaGli
aXRpdmUuDQoNCkFuZHJldw0KDQoNCg0KRnJvbTogRFJBR0UsIEtlaXRoIChLZWl0aCkgW21h
aWx0bzprZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb21dDQpTZW50OiBXZWRuZXNkYXks
IE1hcmNoIDEzLCAyMDEzIDEyOjM2IFBNIENlbnRyYWwgU3RhbmRhcmQgVGltZQ0KVG86IEFu
ZHJldyBBbGxlbjsgcm9tYW5AdGVsdXJpeC5jb20gPHJvbWFuQHRlbHVyaXguY29tPjsgcnRj
d2ViQGlldGYub3JnIDxydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW3J0Y3dlYl0g
QWdlbmRhIHRpbWUgcmVxdWVzdCBmb3IgZHJhZnQtbWFyam91LXJ0Y3dlYi1hdWRpby1jb2Rl
Y3MtZm9yLWludGVyb3AtMDENCg0KVGhlIHByb2JsZW0gaXMgdGhhdCB0aGUgYnVzaW5lc3Mg
Y2FzZSBmb3IgdGhlIGRldmljZSB2ZW5kb3Igb3IgZW5kIHVzZXIgbWF5IG5vdCBiZSB0aGUg
YnVzaW5lc3MgY2FzZSBmb3IgdGhlIGJyb3dzZXIgdmVuZG9yLg0KDQpUbyBiZSBob25lc3Qg
dGhpcyBkaXNjdXNzaW9uIGdvZXMgcm91bmQgYW5kIHJvdW5kIGluIGNpcmNsZXMsIHdpdGgg
cGVvcGxlIHRyeWluZyB0byBzYXkgdGhpbmdzIGFyZSBvdXQgb2Ygc2NvcGUuDQoNCldoYXQg
SSBiZWxpZXZlIHdlIG5lZWQgaXMgc29tZXRoaW5nIHRoYXQgZW5jb3VyYWdlcyBjcmVhdGlv
biBvZiBBUElzIGZvciBlbWJlZGRlZCBjb2RlY3MgaW4gdGhlIGRldmljZXMuIFRob3NlIEFQ
SeKAmXMgc2hvdWxkIHRoZW4gYmUgbWFkZSBhdmFpbGFibGUgd2l0aGluIHRoZSBicm93c2Vy
Lg0KDQpUaGlzIGdldHMgZXZlbiBtb3JlIGltcG9ydGFudCB3aGVuIHdlIGdldCB0byB2aWRl
byBjb2RlY3MuIEkgYW0gY2VydGFpbmx5IGludGVyZXN0ZWQgaW4gZ2F0ZXdheXMgZnJvbSBS
VENXRUIgZW5kcG9pbnRzIHRvIG90aGVyIFNJUCBiYXNlZCBuZXR3b3Jrcy4gSGF2aW5nIHRv
IHRyYW5zY29kZSBmcm9tIG9uZSB2aWRlbyBjb2RlYyB0byBhbm90aGVyIGJlY2F1c2Ugb2Yg
dGhpcyBpbXBhc3NlIGlzIGEgbmlnaHRtYXJlLg0KDQpTb21lb25lIGhhcyB0byBicmVhayB0
aGlzIGxvb3AuDQoNCktlaXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQpGcm9tOiBydGN3ZWItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2Vz
QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQW5kcmV3IEFsbGVuDQpTZW50OiAxMyBNYXJjaCAy
MDEzIDE3OjMwDQpUbzogcm9tYW5AdGVsdXJpeC5jb207IHJ0Y3dlYkBpZXRmLm9yZw0KU3Vi
amVjdDogUmU6IFtydGN3ZWJdIEFnZW5kYSB0aW1lIHJlcXVlc3QgZm9yIGRyYWZ0LW1hcmpv
dS1ydGN3ZWItYXVkaW8tY29kZWNzLWZvci1pbnRlcm9wLTAxDQoNCg0KSWYgdGhlcmUgaXMg
YSBidXNpbmVzcyBjYXNlIGZvciBpbXBsZW1lbnRlcnMgdG8gc3VwcG9ydCBvdGhlciBjb2Rl
Y3MgZm9yIGltcHJvdmVkIGludGVvcGVyYWJpbGl0eSB3aXRoIG90aGVyIG5ldHdvcmtzIGFu
ZCBkZXZpY2VzIHRoZW4gdGhleSBhcmUgdmVyeSBsaWtlbHkgdG8gZG8gc28uDQoNCg0KDQpG
cm9tOiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5AdGVsdXJpeC5jb21dDQpTZW50OiBX
ZWRuZXNkYXksIE1hcmNoIDEzLCAyMDEzIDEyOjEyIFBNIENlbnRyYWwgU3RhbmRhcmQgVGlt
ZQ0KVG86IHJ0Y3dlYkBpZXRmLm9yZyA8cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6
IFtydGN3ZWJdIEFnZW5kYSB0aW1lIHJlcXVlc3QgZm9yIGRyYWZ0LW1hcmpvdS1ydGN3ZWIt
YXVkaW8tY29kZWNzLWZvci1pbnRlcm9wLTAxDQoNCk5vcm1hbGx5LCB3aGVuIGltcGxlbWVu
dGluZyBWb0lQIGRldmljZXMsIHVubGVzcyB0aGV5IGFyZSBpbnRlbmRlZCBmb3Igc29tZSBz
b3J0IG9mIHdhbGxlZCBnYXJkZW4sIHlvdSB0cnkgdG8gc3VwcG9ydCBhcyBtYW55IGNvZGVj
cyBhcyBwb3NzaWJsZS4gVGhpcyBpbmNyZWFzZXMgeW91ciBjaGFuY2VzIG9mIGludGVyb3Bl
cmFiaWxpdHkgd2l0aCBvdGhlciBkZXZpY2VzIGFuZCB5b3VyIHByb2R1Y3QgYWRvcHRpb24u
IEluIGNhc2Ugb2YgV2ViUlRDLCBpdCB3b3VsZCBiZSBhZG9wdGVkIHJlZ2FyZGxlc3Mgb2Yg
d2hhdCBjb2RlY3MgYXJlIHN1cHBvcnRlZC4gVGhlIG51bWJlciBvZiBlbmFibGVkIGRldmlj
ZXMgd291bGQgYmUgc28gZ3JlYXQgdGhhdCBhbGwgdGhlIGxlZ2FjeSBuZXR3b3JrcyB3aWxs
IGhhdmUgdG8gYWRhcHQuIFRoaXMgaGFzIHNvbWUgbmVnYXRpdmUgaW1wbGljYXRpb25zIHRv
IHRoZSBsZWdhY3kgbmV0d29ya3MgYXMgZmFyIGFzIHF1YWxpdHkgYW5kIGNvc3RzIGFyZSBj
b25jZXJuZWQsIGJ1dCB0aGVzZSBjaGFsbGVuZ2VzIGFyZSBub3QgaW5zdXJtb3VudGFibGUu
IFNvLCB0YWtpbmcgdGhpcyBpbnRvIGNvbnNpZGVyYXRpb24sIEkgd2FudCB0byBwbGFjZSB0
aGUgc2FtZSBxdWVzdGlvbnMgZGlmZmVyZW50bHk6DQoNCkRvIHdlYiBicm93c2VyIGltcGxl
bWVudGVycyBjdXJyZW50bHkgcGxhbiB0byBzdXBwb3J0IGFueSBvdGhlciBjb2RlY3MgZXhj
ZXB0IE1USSAoRy43MTEgYW5kIE9QVVMpPw0KDQpJcyB0aGVyZSBhbnl0aGluZyB3ZSBhcmUg
Z29pbmcgdG8gc2F5IGhlcmUgcmVnYXJkaW5nIGxlZ2FjeSBpbnRlcm9wIHRoYXQgd291bGQg
bWFrZSBicm93c2VyIG1hbnVmYWN0dXJlcnMgdG8gY2hhbmdlIHRoZWlyIG1pbmQ/IEFmdGVy
IGFsbCwgdGhpcyByZXByZXNlbnRzIGFkZGl0aW9uYWwgY29zdCB0byB0aGVtIHdpdGggbm8g
ZGlyZWN0IGJlbmVmaXQgZm9yIHRoZSB1c2UgY2FzZXMgd2hpY2ggYXJlIG1vc3QgaW1wb3J0
YW50IHRvIHRoZW0gKGJyb3dzZXIgdG8gYnJvd3NlciBjYWxscykuDQoNCkZvciBtZSwgdGhl
IGRlc2lyZWQgb3V0Y29tZSB3b3VsZCBiZSB0aGF0IGJyb3dzZXJzLCBhdCBsZWFzdCBmb3Ig
dGhlIG5leHQgZmV3IHllYXJzLCBkbyBzdXBwb3J0IGEgcmVhc29uYWJsZSBzZXQgb2Ygb3Ro
ZXIgY29kZWNzIGluIGFkZGl0aW9uIHRvIE1USSwgaW5jbHVkaW5nIEcuNzIyLCBBTVIsIEFN
Ui1XQiwgYW5kIG1heSBiZSBTcGVleCwgLiBUaGlzIHdvdWxkIGdpdmUgbWUgYW4gb3Bwb3J0
dW5pdHkgdG8gbWlncmF0ZSBmcm9tIGRldmljZXMgdGhhdCBzdXBwb3J0IGxlZ2FjeSBjb2Rl
Y3MgdG8gZGV2aWNlcyB0aGF0IHN1cHBvcnQgT3B1cy4gVGhlIGZhY3QgdGhhdCBkaWZmZXJl
bnQgYnJvd3NlciB2ZXJzaW9ucyB3b3VsZCBzdXBwb3J0IGRpZmZlcmVudCBjb2RlYyBzZXRz
IChsaWtlIGRlc2t0b3AgYnJvd3NlcnMgbm90IHN1cHBvcnRpbmcgQU1SKSBpcyBub3QgYSBi
aWcgaXNzdWUsIGF0IGxlYXN0IGZvciBtZSwgc2luY2Ugd2UgYWx3YXlzIGhhdmUgRy43MTEg
b3IgdHJhbnNjb2RpbmcgdG8gZmFsbCBiYWNrIHRvLiBUaGUgc2FtZSBnb2VzIGZvciBicm93
c2VycyBmYXppbmcgc29tZSBvZiB0aGUgbGVnYWN5IGNvZGVjcyBvdXQgaW4gdGhlIGZ1dHVy
ZS4gVGhlIGVuZCByZXN1bHQgd291bGQgc3RpbGwgYmUgYmV0dGVyIHRoZW4gMTAwJSBHLjcx
MSBvciB0cmFuc2NvZGluZy4NCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0KLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tDQpUaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2ht
ZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2Vk
IG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xpY2l0
b3ItY2xpZW50IG9yIG90aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1
dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9u
IGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGli
aXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3Is
IHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhp
cyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRp
c3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uIGJ5IHVu
aW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QgYXV0aG9yaXplZCBhbmQgbWF5IGJlIHVubGF3
ZnVsLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgdHJhbnNtaXNzaW9uIChpbmNsdWRpbmcg
YW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24s
IHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkg
dGhlIHNvbGljaXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwg
b3IgY29uc3RpdHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRoaXMg
aW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVu
dCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lv
biBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5k
IGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2Vt
aW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21p
c3Npb24gYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBt
YXkgYmUgdW5sYXdmdWwuDQo=

--_000_BBF5DDFE515C3946BC18D733B20DAD2338D28B32XMB104ADSrimnet_
Content-Type: text/html; charset="utf-8"
content-transfer-encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89
InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu
OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6c3QxPSJ1cm46c2No
ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiIHhtbG5zPSJodHRwOi8vd3d3
LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29u
dGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEg
bmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8IS0tW2lmICFtc29dPg0KPHN0eWxlPg0Kdlw6KiB7YmVoYXZpb3I6dXJs
KCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0K
d1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1
cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPg0KPCFbZW5kaWZdLS0+PG86U21hcnRUYWdU
eXBlIG5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21h
cnR0YWdzIiBuYW1lPSJ0aW1lIiAvPjxvOlNtYXJ0VGFnVHlwZSBuYW1lc3BhY2V1cmk9InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyIgbmFtZT0ic3RvY2t0
aWNrZXIiIC8+PG86U21hcnRUYWdUeXBlIG5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWlj
cm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIiBuYW1lPSJkYXRlIiAvPjwhLS1baWYgIW1z
b10+DQo8c3R5bGU+DQpzdDFcOip7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I2llb291aSkgfQ0K
PC9zdHlsZT4NCjwhW2VuZGlmXS0tPjxzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRp
b25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5v
c2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIg
NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3Nl
LTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBw
Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207
DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m
YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K
CXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk
LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9yOiM2MDY0MjA7DQoJdGV4dC1k
ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpBcmlhbDsNCgljb2xvcjpuYXZ5
O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NTk1LjNwdCA4NDEuOXB0Ow0KCW1hcmdpbjo3
Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2Vj
dGlvbjE7fQ0KLS0+DQo8L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNo
YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl
bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4
dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpz
aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO
LUdCIiBsaW5rPSJibHVlIiB2bGluaz0iIzYwNjQyMCI+DQo8Zm9udCBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PGJyPg0KS2VpdGg8YnI+DQo8YnI+DQpUaGF0
IGlzIG91dCBvZiBzY29wZSBvZiBJRVRGLiBXaGF0IEkgdGhpbmsgeW91IGFyZSBzdWdnZXN0
aW5nIGFtb3VudHMgdG8gb3BlcmF0aW5nIHN5c3RlbSBzdGFuZGFyZGlzYXRpb24uPGJyPg0K
PGJyPg0KSWYgeW91IGJlbGlldmUgaW4gdGhlIG1hcmtldCB0aGVuIHRoZSBidXNpbmVzcyBj
YXNlIG9mIHRoZSBicm93c2VyIGltcGxlbWVudGVycyBhbmQgdGhlIGRldmljZSB2ZW5kb3Jz
IHNob3VsZCBhbGlnbiB3aXRoIHRoZSBpbnRlcmVzdHMgb2YgdGhlIHVzZXJzIChJLmUgdGhl
aXIgY3VzdG9tZXJzKSBhc3N1bWluZyB0aGUgY29zdHMgYXJlIG5vdCBwcm9oaWJpdGl2ZS48
YnI+DQo8YnI+DQpBbmRyZXc8YnI+DQo8YnI+DQo8L2ZvbnQ+PGJyPg0KJm5ic3A7PGJyPg0K
PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0
O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGZvbnQgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDsiPjxiPkZyb208L2I+OiBEUkFHRSwgS2VpdGggKEtlaXRoKSBbbWFpbHRvOmtlaXRo
LmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbV0NCjxicj4NCjxiPlNlbnQ8L2I+OiBXZWRuZXNk
YXksIE1hcmNoIDEzLCAyMDEzIDEyOjM2IFBNIENlbnRyYWwgU3RhbmRhcmQgVGltZTxicj4N
CjxiPlRvPC9iPjogQW5kcmV3IEFsbGVuOyByb21hbkB0ZWx1cml4LmNvbSAmbHQ7cm9tYW5A
dGVsdXJpeC5jb20mZ3Q7OyBydGN3ZWJAaWV0Zi5vcmcgJmx0O3J0Y3dlYkBpZXRmLm9yZyZn
dDsNCjxicj4NCjxiPlN1YmplY3Q8L2I+OiBSRTogW3J0Y3dlYl0gQWdlbmRhIHRpbWUgcmVx
dWVzdCBmb3IgZHJhZnQtbWFyam91LXJ0Y3dlYi1hdWRpby1jb2RlY3MtZm9yLWludGVyb3At
MDENCjxicj4NCjwvZm9udD4mbmJzcDs8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IlNlY3Rp
b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSJuYXZ5
IiBmYWNlPSJBcmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZh
bWlseTpBcmlhbDtjb2xvcjpuYXZ5Ij5UaGUgcHJvYmxlbSBpcyB0aGF0IHRoZSBidXNpbmVz
cyBjYXNlIGZvciB0aGUgZGV2aWNlIHZlbmRvciBvciBlbmQgdXNlciBtYXkgbm90IGJlIHRo
ZSBidXNpbmVzcyBjYXNlIGZvciB0aGUgYnJvd3NlciB2ZW5kb3IuPG86cD48L286cD48L3Nw
YW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNv
bG9yPSJuYXZ5IiBmYWNlPSJBcmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCjEwLjBw
dDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29s
b3I9Im5hdnkiIGZhY2U9IkFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOg0KMTAuMHB0
O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnkiPlRvIGJlIGhvbmVzdCB0aGlzIGRpc2N1
c3Npb24gZ29lcyByb3VuZCBhbmQgcm91bmQgaW4gY2lyY2xlcywgd2l0aCBwZW9wbGUgdHJ5
aW5nIHRvIHNheSB0aGluZ3MgYXJlIG91dCBvZiBzY29wZS48bzpwPjwvbzpwPjwvc3Bhbj48
L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9
Im5hdnkiIGZhY2U9IkFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOg0KMTAuMHB0O2Zv
bnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
Zm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0i
bmF2eSIgZmFjZT0iQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6DQoxMC4wcHQ7Zm9u
dC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSI+V2hhdCBJIGJlbGlldmUgd2UgbmVlZCBpcyBz
b21ldGhpbmcgdGhhdCBlbmNvdXJhZ2VzIGNyZWF0aW9uIG9mIEFQSXMgZm9yIGVtYmVkZGVk
IGNvZGVjcyBpbiB0aGUgZGV2aWNlcy4gVGhvc2UNCjxzdDE6c3RvY2t0aWNrZXIgdzpzdD0i
b24iPkFQSTwvc3QxOnN0b2NrdGlja2VyPuKAmXMgc2hvdWxkIHRoZW4gYmUgbWFkZSBhdmFp
bGFibGUgd2l0aGluIHRoZSBicm93c2VyLg0KPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSJuYXZ5IiBm
YWNlPSJBcmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWls
eTpBcmlhbDtjb2xvcjpuYXZ5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9Im5hdnkiIGZh
Y2U9IkFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5
OkFyaWFsO2NvbG9yOm5hdnkiPlRoaXMgZ2V0cyBldmVuIG1vcmUgaW1wb3J0YW50IHdoZW4g
d2UgZ2V0IHRvIHZpZGVvIGNvZGVjcy4gSSBhbSBjZXJ0YWlubHkgaW50ZXJlc3RlZCBpbiBn
YXRld2F5cyBmcm9tIFJUQ1dFQiBlbmRwb2ludHMgdG8gb3RoZXIgU0lQIGJhc2VkDQogbmV0
d29ya3MuIEhhdmluZyB0byB0cmFuc2NvZGUgZnJvbSBvbmUgdmlkZW8gY29kZWMgdG8gYW5v
dGhlciBiZWNhdXNlIG9mIHRoaXMgaW1wYXNzZSBpcyBhIG5pZ2h0bWFyZS48bzpwPjwvbzpw
Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0i
MiIgY29sb3I9Im5hdnkiIGZhY2U9IkFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOg0K
MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnkiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIy
IiBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6DQox
MC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSI+U29tZW9uZSBoYXMgdG8gYnJl
YWsgdGhpcyBsb29wLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6
bmF2eSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSJuYXZ5IiBmYWNlPSJBcmlhbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpu
YXZ5Ij5LZWl0aDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2
eSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXYgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt
IDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2Vu
dGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxmb250IHNpemU9IjMiIGZhY2U9IlRp
bWVzIE5ldyBSb21hbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIu
MHB0Ij4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciIgdGFiaW5k
ZXg9Ii0xIj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
Yj48Zm9udCBzaXplPSIyIiBmYWNlPSJUYWhvbWEiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWE7Zm9udC13ZWlnaHQ6Ym9s
ZCI+RnJvbTo8L3NwYW4+PC9mb250PjwvYj48Zm9udCBzaXplPSIyIiBmYWNlPSJUYWhvbWEi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTpUYWhvbWEiPiBydGN3ZWItYm91bmNlc0BpZXRmLm9yZw0KIFttYWlsdG86cnRjd2ViLWJv
dW5jZXNAaWV0Zi5vcmddIDxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5PbiBC
ZWhhbGYgT2YgPC9zcGFuPg0KPC9iPkFuZHJldyBBbGxlbjxicj4NCjxiPjxzcGFuIHN0eWxl
PSJmb250LXdlaWdodDpib2xkIj5TZW50Ojwvc3Bhbj48L2I+IDEzIE1hcmNoIDIwMTMgMTc6
MzA8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86PC9zcGFuPjwv
Yj4gcm9tYW5AdGVsdXJpeC5jb207IHJ0Y3dlYkBpZXRmLm9yZzxicj4NCjxiPjxzcGFuIHN0
eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0Ojwvc3Bhbj48L2I+IFJlOiBbcnRjd2Vi
XSBBZ2VuZGEgdGltZSByZXF1ZXN0IGZvciBkcmFmdC1tYXJqb3UtcnRjd2ViLWF1ZGlvLWNv
ZGVjcy1mb3ItaW50ZXJvcC0wMTwvc3Bhbj48L2ZvbnQ+PHNwYW4gbGFuZz0iRU4tVVMiPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv
bnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOg0KMTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9
IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh
bGlicmk7Y29sb3I6IzFGNDk3RCI+PGJyPg0KSWYgdGhlcmUgaXMgYSBidXNpbmVzcyBjYXNl
IGZvciBpbXBsZW1lbnRlcnMgdG8gc3VwcG9ydCBvdGhlciBjb2RlY3MgZm9yIGltcHJvdmVk
IGludGVvcGVyYWJpbGl0eSB3aXRoIG90aGVyIG5ldHdvcmtzIGFuZCBkZXZpY2VzIHRoZW4g
dGhleSBhcmUgdmVyeSBsaWtlbHkgdG8gZG8gc28uPGJyPg0KPGJyPg0KPC9zcGFuPjwvZm9u
dD48YnI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g
MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxmb250IHNpemU9IjIiIGZhY2U9IlRh
aG9tYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpUYWhv
bWE7Zm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IHNpemU9
IjIiIGZhY2U9IlRhaG9tYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6VGFob21hIj46IFJvbWFuIFNocG91bnQgW21haWx0bzpyb21hbkB0ZWx1cml4LmNv
bV0NCjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TZW50PC9zcGFu
PjwvYj46IFdlZG5lc2RheSwgPHN0MTpkYXRlIFllYXI9IjIwMTMiIERheT0iMTMiIE1vbnRo
PSIzIiBscz0idHJhbnMiIHc6c3Q9Im9uIj4NCk1hcmNoIDEzLCAyMDEzPC9zdDE6ZGF0ZT4g
PHN0MTp0aW1lIE1pbnV0ZT0iMTIiIEhvdXI9IjEyIiB3OnN0PSJvbiI+MTI6MTIgUE08L3N0
MTp0aW1lPiBDZW50cmFsIFN0YW5kYXJkIFRpbWU8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9u
dC13ZWlnaHQ6Ym9sZCI+VG88L3NwYW4+PC9iPjogcnRjd2ViQGlldGYub3JnICZsdDtydGN3
ZWJAaWV0Zi5vcmcmZ3Q7DQo8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s
ZCI+U3ViamVjdDwvc3Bhbj48L2I+OiBSZTogW3J0Y3dlYl0gQWdlbmRhIHRpbWUgcmVxdWVz
dCBmb3IgZHJhZnQtbWFyam91LXJ0Y3dlYi1hdWRpby1jb2RlY3MtZm9yLWludGVyb3AtMDEN
Cjxicj4NCjwvc3Bhbj48L2ZvbnQ+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBO
ZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6DQoxMi4wcHQiPk5vcm1hbGx5LCB3
aGVuIGltcGxlbWVudGluZyBWb0lQIGRldmljZXMsIHVubGVzcyB0aGV5IGFyZSBpbnRlbmRl
ZCBmb3Igc29tZSBzb3J0IG9mIHdhbGxlZCBnYXJkZW4sIHlvdSB0cnkgdG8gc3VwcG9ydCBh
cyBtYW55IGNvZGVjcyBhcyBwb3NzaWJsZS4gVGhpcyBpbmNyZWFzZXMgeW91cg0KIGNoYW5j
ZXMgb2YgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIG90aGVyIGRldmljZXMgYW5kIHlvdXIgcHJv
ZHVjdCBhZG9wdGlvbi4gSW4gY2FzZSBvZiBXZWJSVEMsIGl0IHdvdWxkIGJlIGFkb3B0ZWQg
cmVnYXJkbGVzcyBvZiB3aGF0IGNvZGVjcyBhcmUgc3VwcG9ydGVkLiBUaGUgbnVtYmVyIG9m
IGVuYWJsZWQgZGV2aWNlcyB3b3VsZCBiZSBzbyBncmVhdCB0aGF0IGFsbCB0aGUgbGVnYWN5
IG5ldHdvcmtzIHdpbGwgaGF2ZSB0byBhZGFwdC4gVGhpcw0KIGhhcyBzb21lIG5lZ2F0aXZl
IGltcGxpY2F0aW9ucyB0byB0aGUgbGVnYWN5IG5ldHdvcmtzIGFzIGZhciBhcyBxdWFsaXR5
IGFuZCBjb3N0cyBhcmUgY29uY2VybmVkLCBidXQgdGhlc2UgY2hhbGxlbmdlcyBhcmUgbm90
IGluc3VybW91bnRhYmxlLiBTbywgdGFraW5nIHRoaXMgaW50byZuYnNwO2NvbnNpZGVyYXRp
b24sIEkgd2FudCB0byBwbGFjZSB0aGUgc2FtZSBxdWVzdGlvbnMgZGlmZmVyZW50bHk6PG86
cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToNCjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9m
b250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp
emU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToN
CjEyLjBwdCI+RG8gd2ViIGJyb3dzZXIgaW1wbGVtZW50ZXJzIGN1cnJlbnRseSBwbGFuIHRv
IHN1cHBvcnQgYW55IG90aGVyIGNvZGVjcyBleGNlcHQgTVRJIChHLjcxMSBhbmQgT1BVUyk/
PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToNCjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250
IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToNCjEyLjBwdCI+SXMgdGhlcmUgYW55dGhpbmcgd2UgYXJlIGdvaW5nIHRvIHNheSBoZXJl
IHJlZ2FyZGluZyBsZWdhY3kgaW50ZXJvcCB0aGF0IHdvdWxkIG1ha2UgYnJvd3NlciBtYW51
ZmFjdHVyZXJzIHRvIGNoYW5nZSB0aGVpciBtaW5kPyBBZnRlciBhbGwsIHRoaXMgcmVwcmVz
ZW50cyBhZGRpdGlvbmFsDQogY29zdCB0byB0aGVtIHdpdGggbm8gZGlyZWN0IGJlbmVmaXQg
Zm9yIHRoZSB1c2UgY2FzZXMgd2hpY2ggYXJlIG1vc3QgaW1wb3J0YW50IHRvIHRoZW0gKGJy
b3dzZXIgdG8gYnJvd3NlciBjYWxscykuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZh
Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCjEyLjBwdCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21h
biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCjEyLjBwdCI+Rm9yIG1lLCB0aGUgZGVzaXJl
ZCBvdXRjb21lIHdvdWxkIGJlIHRoYXQgYnJvd3NlcnMsIGF0IGxlYXN0IGZvciB0aGUgbmV4
dCBmZXcgeWVhcnMsIGRvIHN1cHBvcnQgYSByZWFzb25hYmxlIHNldCBvZiBvdGhlciBjb2Rl
Y3MgaW4gYWRkaXRpb24gdG8gTVRJLCBpbmNsdWRpbmcgRy43MjIsDQo8c3QxOnN0b2NrdGlj
a2VyIHc6c3Q9Im9uIj5BTVI8L3N0MTpzdG9ja3RpY2tlcj4sIDxzdDE6c3RvY2t0aWNrZXIg
dzpzdD0ib24iPkFNUjwvc3QxOnN0b2NrdGlja2VyPi1XQiwgYW5kIG1heSBiZSBTcGVleCwm
bmJzcDsuIFRoaXMgd291bGQgZ2l2ZSBtZSBhbiBvcHBvcnR1bml0eSB0byBtaWdyYXRlIGZy
b20gZGV2aWNlcyB0aGF0IHN1cHBvcnQgbGVnYWN5IGNvZGVjcyB0byBkZXZpY2VzIHRoYXQg
c3VwcG9ydCBPcHVzLiBUaGUgZmFjdCB0aGF0IGRpZmZlcmVudA0KIGJyb3dzZXIgdmVyc2lv
bnMgd291bGQgc3VwcG9ydCBkaWZmZXJlbnQgY29kZWMgc2V0cyAobGlrZSBkZXNrdG9wIGJy
b3dzZXJzIG5vdCBzdXBwb3J0aW5nDQo8c3QxOnN0b2NrdGlja2VyIHc6c3Q9Im9uIj5BTVI8
L3N0MTpzdG9ja3RpY2tlcj4pIGlzIG5vdCBhIGJpZyBpc3N1ZSwgYXQgbGVhc3QgZm9yIG1l
LCBzaW5jZSB3ZSBhbHdheXMgaGF2ZSBHLjcxMSBvciB0cmFuc2NvZGluZyB0byBmYWxsIGJh
Y2sgdG8uIFRoZSBzYW1lIGdvZXMgZm9yIGJyb3dzZXJzIGZhemluZyBzb21lIG9mIHRoZSBs
ZWdhY3kgY29kZWNzIG91dCBpbiB0aGUgZnV0dXJlLiBUaGUgZW5kIHJlc3VsdCB3b3VsZCBz
dGlsbCBiZSBiZXR0ZXINCiB0aGVuIDEwMCUgRy43MTEgb3IgdHJhbnNjb2RpbmcuPG86cD48
L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6DQoxMi4wcHQiPl9fX19fX19fX19fX188YnI+DQpSb21h
biBTaHBvdW50PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Zm9udCBzaXpl
PSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu
MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6DQoxMi4wcHQiPi0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPGJy
Pg0KVGhpcyB0cmFuc21pc3Npb24gKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIG1heSBj
b250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAo
aW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBv
ciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJs
aWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbg0KIGJ5IGFueW9u
ZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYg
eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBp
bW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1h
dGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlv
biwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uDQogYnkgdW5pbnRlbmRl
ZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIDxv
OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tIDxicj4NClRoaXMgdHJhbnNtaXNzaW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1l
bnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24sIHByaXZpbGVnZWQg
bWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGljaXRv
ci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwgb3IgY29uc3RpdHV0
ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24g
YnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJp
dGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwg
cGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlz
IGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlz
dHJpYnV0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24gYnkgdW5p
bnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdm
dWwuDQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_BBF5DDFE515C3946BC18D733B20DAD2338D28B32XMB104ADSrimnet_--

From prvs=2784a1a91b=aallen@blackberry.com  Wed Mar 13 11:11: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 5407621F8E7B for ; Wed, 13 Mar 2013 11:11:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.348
X-Spam-Level: 
X-Spam-Status: No, score=-5.348 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 lrtX5CjOtDEI for ; Wed, 13 Mar 2013 11:11:40 -0700 (PDT)
Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1F721F8E7A for ; Wed, 13 Mar 2013 11:11:40 -0700 (PDT)
X-AuditID: 0a41282f-b7fa06d000002431-ea-5140c15b4f3e
Received: from XCT104ADS.rim.net (xct104ads.rim.net [10.67.111.45]) by mhs060cnc.rim.net (SBG) with SMTP id F3.1E.09265.B51C0415; Wed, 13 Mar 2013 13:11:39 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 13:11:39 -0500
From: Andrew Allen 
To: "adam@nostrum.com" , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIBMyr0S8clvDH0eEEMyuKlC7H5ij7EJm
Date: Wed, 13 Mar 2013 18:11:37 +0000
Message-ID: 
In-Reply-To: <5140BC2C.90206@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.253]
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGKsWRmVeSWpSXmKPExsXC5Zyvqxt90CHQ4NIVPYs9fxexW6z9187u wOSxZMlPJo9ZO5+wBDBFNTDaJCWWlAVnpufp29kk5uXllySWpCqkpBYn2yr5pKYn5igEFGWW JSZXKrhkFifnJGbmphYpKWSm2CqZKCkU5CQmp+am5pXYKiUWFKTmpSjZcSlgABugssw8hdS8 5PyUzLx0WyXPYH9dCwtTS11DJTvdhE6ejG8/1jEVPOOuOL/jB3MD4wPOLkYODgkBE4m5a3W6 GDmBTDGJC/fWs4HYQgIrGSXaH7B2MXIB2ZsZJV48amMESbAJaEnsPzydCcQWEfCTWNT1igXE FhaIl7g/8T4jRDxB4s/n3+wg80UEjCTmvU8DMVkEVCW+7cgDqeAV8JDYuWAvWDWngKbEtz0T wGxGoBO+n1oDNp1ZQFzi1pP5TBCnCUgs2XOeGcIWlXj5+B8rhK0o8Xfvd1aIej2JG1OnsEHY 2hLLFr5mhtglKHFy5hOWCYwis5CMnYWkZRaSlllIWhYwsqxiFMzNKDYwM0jOS9YryszVy0st 2cQIinhHDf0djG/fWxxiFOBgVOLhFd/lECjEmlhWXJl7iFGCg1lJhHd5LlCINyWxsiq1KD++ qDQntfgQoyswICYyS3En5wOTUV5JvLGBAW6OkjivSKBooJBAOjC9ZKemFqQWwcxh4uAE2cMl JVIMTBKpRYmlJRnxoFQWXwxMZlINjMx6e0IY5pbGcvE9Ek2PV34Sv/r+stAJS/jrJnCKlKcw 3ktWddE/YfKwb0/gzfPG1/7/feW7Ys7LkKupk3w6TG9/ubn+mr166J6Zq8WknZpq74dtFtqw UqWUm9tjapNlq04Tp06JvMCjwicx2p07k/9WftlgOWvbjWuZYsH1dwtuz/joLjT7mBJLcUai oRZzUXEiAEF1kRE5AwAA
Subject: Re: [rtcweb] Agenda time request for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 18:11:41 -0000

+1

It seems clear to me that other codecs will be included by most if not all R=
TCweb compliant browsers but which ones should be left up to implementers ba=
sed on commercial decisions and which ones they include may change over time=
 as codecs become obsoleted by new codecs. The MTIs are the ones that will a=
lways be supported to ensure interoperability other codecs will be supported=
 when it makes sense.

Andrew 



----- Original Message -----
From: Adam Roach [mailto:adam@nostrum.com]
Sent: Wednesday, March 13, 2013 12:49 PM Central Standard Time=0A=
To: rtcweb@ietf.org 
Subject: Re: [rtcweb] Agenda time request for	draft-marjou-rtcweb-audio-code=
cs-for-interop-01

On 3/13/13 11:42, Olle E. Johansson wrote:
> I don't think everyone gets the that selecting a small subset as mandatory=
 for WebRTC does NOT exclude all other codecs. Feel free to add everything y=
ou got. Have fun. Let the best mutual codec with the best mutual properties=
 win the session.

Olle hit the nail squarely on the head. This is exactly the purpose of 
offer/answer negotiation: to find the best intersection of endpoint 
capabilities for the desired communication session. I'm bewildered by 
the fairly consistent misinterpretation that having an MTI codec somehow 
implies that every other codec becomes "MNTI".

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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From cb.list6@gmail.com  Wed Mar 13 11:17: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 6482521F86A8 for ; Wed, 13 Mar 2013 11:17:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.822
X-Spam-Level: 
X-Spam-Status: No, score=-2.822 tagged_above=-999 required=5 tests=[AWL=0.776,  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 T7feDFknOI9g for ; Wed, 13 Mar 2013 11:17:42 -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 DEBE821F8EA8 for ; Wed, 13 Mar 2013 11:17:40 -0700 (PDT)
Received: by mail-wg0-f47.google.com with SMTP id dr13so1226368wgb.2 for ; Wed, 13 Mar 2013 11:17:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=9dEZvE9ZjqCKwY12gBc6NiugIv6bMe7/ozOOLVgloXs=; b=dOUupdDrl2oMQhSAb/N/MtNs6VKl2nNzFxxL1Kg5YH8c06+nPAZIZBfMY6Lp56+57G rXchmKQiFhyPNjDbXBTMUzBem08Q1XDi4HrGGFEftgP27rTu9COyZ3B7Mo9tgk8k1mn/ gp57R/N7GNt5qrxojFoD81aBdXx/CyjAJqUokYioWZLr9wxuBAtCecYIaLT18YaANpSm KaKwZUQGAthdOCzflsFRo2LKpEjMQkmyKuuGuprpNp0sbHTRLj+J3bLVJ3qNyJp7rNx5 o2MzOjseGBqchFPQ3UQZ3Ce9hJwhDCw/KEOE9oG+E39nZGvykOOo2oYMJt3J+omuLF8f /SOw==
MIME-Version: 1.0
X-Received: by 10.180.183.4 with SMTP id ei4mr28744199wic.21.1363198660000; Wed, 13 Mar 2013 11:17:40 -0700 (PDT)
Received: by 10.194.20.35 with HTTP; Wed, 13 Mar 2013 11:17:39 -0700 (PDT)
Received: by 10.194.20.35 with HTTP; Wed, 13 Mar 2013 11:17:39 -0700 (PDT)
In-Reply-To: <20130313143808.DB3BD21F8E0C@ietfa.amsl.com>
References:    <20130313142732.GE12022@audi.shelbyville.oz> <20130313143808.DB3BD21F8E0C@ietfa.amsl.com>
Date: Wed, 13 Mar 2013 11:17:39 -0700
Message-ID: 
From: Cameron Byrne 
To: "Bogineni, Kalyani" 
Content-Type: multipart/alternative; boundary=001a11c22a2ee3441804d7d26b87
Cc: Xavier Marjou , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 18:17:43 -0000

--001a11c22a2ee3441804d7d26b87
Content-Type: text/plain; charset=ISO-8859-1

On Mar 13, 2013 7:50 AM, "Bogineni, Kalyani" <
Kalyani.Bogineni@verizonwireless.com> wrote:
>
> There are 6.4 billion cellular connections worldwide.
>
> http://www.3gpp.org/3GPP-Family-2012-Statistics
>

Then it will really be transformational for them to support Opus as a
webrtc requirement. I look forward to all these Opus devices

CB

> Regards,
> Kalyani Bogineni
>
> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
Of Ron
> Sent: Wednesday, March 13, 2013 10:28 AM
> To: Xavier Marjou; rtcweb@ietf.org
> Subject: Re: [rtcweb] Agenda time request for
draft-marjou-rtcweb-audio-codecs-for-interop-01
>
>
> Hi Xavier,
>
> On Wed, Mar 13, 2013 at 09:14:30AM -0400, Xavier Marjou wrote:
> > Here is a summary of the
> > draft-marjou-rtcweb-audio-codecs-for-interop-00
> > presentation that I had prepared for yesterday's session:
> >
> > - The co-authors want to underline that non-WebRTC voice endpoints
> > usually use one of the following codecs: AMR, AMR-WB or G.722, which
> > will result in massive transcoding when there will be communications
> > between WebRTC endpoints and non-WebRTC endpoints.
>
> "Massive" seems a little overstated here.  Any system providing a gateway
service to or between 'low bandwidth' devices is almost surely going to
support more than just WebRTC, and is going to have to transcode for most
or all of them anyway.  Adding an extra burden to WebRTC, especially one
that would only ever apply to some small subset of users, wouldn't appear
to make a significant difference in the requirements for such a system.
>
>
> > - On one side, transcoding is bad for many reasons discussed in the
> > draft (cost issues, intrinsic quality degradation, degraded
> > interactivity, fallback from HD to G.711...);
>
> Are you aware of the listening tests presented to the CODEC WG?
>
> In particular the ones that show Opus->AMR and AMR->Opus is not
significantly worse than the intrinsic quality degradation suffered by
using AMR alone?
>
> Or that Opus->G.711->AMR is actually better than AMR->G.711->AMR ?
>
>
> > - On the other side, it is recognized that implementing additional
> > codecs in the browsers can generate additional costs.
> >
> > - In order to reach a compromise, we would like to add some text in
> > the WG draft draft-ietf-rtcweb-audio providing incentives for the
> > browser to use these three codecs: make them mandatory to implement
> > when there is no cost impact on the browser (e.g. if codec already
> > installed, paid by the device vendor...).
>
> Since there is never no cost impact to supporting additional features,
that would imply this is never mandatory ...
>
> In which case why bother half-saying otherwise?
>
> I thought it was already quite clear all along, that people who want to
or have their own good reasons to are free to implement any other codecs
they please - and that they already have, and certainly will continue to do
so?
>
> > Any opinion on that?
>
> I don't really see much point to handwaving about particular niche codecs
for particular niche uses unless this is going to be some sort of separate
informational document, that is kept up to date with changes in all the
niches that people have an interest in.
>
> That might be useful.  But 'mandating' something that the people who will
do it were going to do it anyway, and the people who were not are still not
going to do, doesn't seem to add any real value here to either users or
implementers.  It won't explain anything to anybody that they don't already
know if it is of any interest to them.
>
>  Cheers,
>  Ron
>
>
> _______________________________________________
> 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

--001a11c22a2ee3441804d7d26b87
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On Mar 13, 2013 7:50 AM, "Bogineni, Kalyani" <Kalyani.Bogineni@verizonwireless.co=
m> wrote:

>

> There are 6.4 billion cellular connections worldwide.

>

> http://www=
.3gpp.org/3GPP-Family-2012-Statistics

>


Then it will really be transformational for them to support =
Opus as a webrtc requirement. I look forward to all these Opus devices


CB


> Regards,

> Kalyani Bogineni

>

> -----Original Message-----

> From: rtcweb-bounces@ietf.o=
rg [mailto:rtcweb-bounces@ie=
tf.org] On Behalf Of Ron

> Sent: Wednesday, March 13, 2013 10:28 AM

> To: Xavier Marjou; rtcweb@ietf.org<=
/a>

> Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audi=
o-codecs-for-interop-01

>

>

> Hi Xavier,

>

> On Wed, Mar 13, 2013 at 09:14:30AM -0400, Xavier Marjou wrote:

> > Here is a summary of the

> > draft-marjou-rtcweb-audio-codecs-for-interop-00

> > presentation that I had prepared for yesterday's session:

> >

> > - The co-authors want to underline that non-WebRTC voice endpoint=
s

> > usually use one of the following codecs: AMR, AMR-WB or G.722, wh=
ich

> > will result in massive transcoding when there will be communicati=
ons

> > between WebRTC endpoints and non-WebRTC endpoints.

>

> "Massive" seems a little overstated here. =A0Any system prov=
iding a gateway service to or between 'low bandwidth' devices is al=
most surely going to support more than just WebRTC, and is going to have to=
 transcode for most or all of them anyway. =A0Adding an extra burden to Web=
RTC, especially one that would only ever apply to some small subset of user=
s, wouldn't appear to make a significant difference in the requirements=
 for such a system.


>

>

> > - On one side, transcoding is bad for many reasons discussed in t=
he

> > draft (cost issues, intrinsic quality degradation, degraded

> > interactivity, fallback from HD to G.711...);

>

> Are you aware of the listening tests presented to the CODEC WG?

>

> In particular the ones that show Opus->AMR and AMR->Opus is not =
significantly worse than the intrinsic quality degradation suffered by usin=
g AMR alone?

>

> Or that Opus->G.711->AMR is actually better than AMR->G.711-&=
gt;AMR ?

>

>

> > - On the other side, it is recognized that implementing additiona=
l

> > codecs in the browsers can generate additional costs.

> >

> > - In order to reach a compromise, we would like to add some text =
in

> > the WG draft draft-ietf-rtcweb-audio providing incentives for the=


> > browser to use these three codecs: make them mandatory to impleme=
nt

> > when there is no cost impact on the browser (e.g. if codec alread=
y

> > installed, paid by the device vendor...).

>

> Since there is never no cost impact to supporting additional features,=
 that would imply this is never mandatory ...

>

> In which case why bother half-saying otherwise?

>

> I thought it was already quite clear all along, that people who want t=
o or have their own good reasons to are free to implement any other codecs =
they please - and that they already have, and certainly will continue to do=
 so?


>

> > Any opinion on that?

>

> I don't really see much point to handwaving about particular niche=
 codecs for particular niche uses unless this is going to be some sort of s=
eparate informational document, that is kept up to date with changes in all=
 the niches that people have an interest in.


>

> That might be useful. =A0But 'mandating' something that the pe=
ople who will do it were going to do it anyway, and the people who were not=
 are still not going to do, doesn't seem to add any real value here to =
either users or implementers. =A0It won't explain anything to anybody t=
hat they don't already know if it is of any interest to them.


>

> =A0Cheers,

> =A0Ron

>

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.i=
etf.org/mailman/listinfo/rtcweb

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.i=
etf.org/mailman/listinfo/rtcweb




--001a11c22a2ee3441804d7d26b87--

From andrew.hutton@siemens-enterprise.com  Wed Mar 13 11:42: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 5468011E80FE for ; Wed, 13 Mar 2013 11:42:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.557
X-Spam-Level: 
X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.041,  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 lVDhvmvArss2 for ; Wed, 13 Mar 2013 11:42:00 -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 668CF11E80F8 for ; Wed, 13 Mar 2013 11:41:59 -0700 (PDT)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id CE79E1EB854E; Wed, 13 Mar 2013 19:41:58 +0100 (CET)
Received: from MCHP04MSX.global-ad.net ([169.254.1.94]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 19:41:58 +0100
From: "Hutton, Andrew" 
To: Cameron Byrne , "Bogineni, Kalyani" 
Thread-Topic: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIBch9wojYuxtPEungoltqcm2fpij9FlA
Date: Wed, 13 Mar 2013 18:41:57 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF06899848@MCHP04MSX.global-ad.net>
References:    <20130313142732.GE12022@audi.shelbyville.oz> <20130313143808.DB3BD21F8E0C@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: [172.29.42.225]
Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF06899848MCHP04MSXglobal_"
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" , Xavier Marjou 
Subject: Re: [rtcweb] Agenda time request for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 18:42:01 -0000

--_000_9F33F40F6F2CD847824537F3C4E37DDF06899848MCHP04MSXglobal_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All,

I thought the suggested text that came from Andrew Allen a couple of months=
 ago was a good compromise.

I repeat it below.



On 17 January 2013 18:00 Andrew Allen wrote:

>

> I would propose:      :

>

> "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"

>

> This is enough to make implementers think about the transcoding issue.

>



Regards

Andy


From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Cameron Byrne
Sent: 13 March 2013 14:18
To: Bogineni, Kalyani
Cc: Xavier Marjou; rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01


On Mar 13, 2013 7:50 AM, "Bogineni, Kalyani" > wrote:
>
> There are 6.4 billion cellular connections worldwide.
>
> http://www.3gpp.org/3GPP-Family-2012-Statistics
>

Then it will really be transformational for them to support Opus as a webrt=
c requirement. I look forward to all these Opus devices

CB

> Regards,
> Kalyani Bogineni
>
> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtc=
web-bounces@ietf.org] On Behalf Of Ron
> Sent: Wednesday, March 13, 2013 10:28 AM
> To: Xavier Marjou; rtcweb@ietf.org
> Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-c=
odecs-for-interop-01
>
>
> Hi Xavier,
>
> On Wed, Mar 13, 2013 at 09:14:30AM -0400, Xavier Marjou wrote:
> > Here is a summary of the
> > draft-marjou-rtcweb-audio-codecs-for-interop-00
> > presentation that I had prepared for yesterday's session:
> >
> > - The co-authors want to underline that non-WebRTC voice endpoints
> > usually use one of the following codecs: AMR, AMR-WB or G.722, which
> > will result in massive transcoding when there will be communications
> > between WebRTC endpoints and non-WebRTC endpoints.
>
> "Massive" seems a little overstated here.  Any system providing a gateway=
 service to or between 'low bandwidth' devices is almost surely going to su=
pport more than just WebRTC, and is going to have to transcode for most or =
all of them anyway.  Adding an extra burden to WebRTC, especially one that =
would only ever apply to some small subset of users, wouldn't appear to mak=
e a significant difference in the requirements for such a system.
>
>
> > - On one side, transcoding is bad for many reasons discussed in the
> > draft (cost issues, intrinsic quality degradation, degraded
> > interactivity, fallback from HD to G.711...);
>
> Are you aware of the listening tests presented to the CODEC WG?
>
> In particular the ones that show Opus->AMR and AMR->Opus is not significa=
ntly worse than the intrinsic quality degradation suffered by using AMR alo=
ne?
>
> Or that Opus->G.711->AMR is actually better than AMR->G.711->AMR ?
>
>
> > - On the other side, it is recognized that implementing additional
> > codecs in the browsers can generate additional costs.
> >
> > - In order to reach a compromise, we would like to add some text in
> > the WG draft draft-ietf-rtcweb-audio providing incentives for the
> > browser to use these three codecs: make them mandatory to implement
> > when there is no cost impact on the browser (e.g. if codec already
> > installed, paid by the device vendor...).
>
> Since there is never no cost impact to supporting additional features, th=
at would imply this is never mandatory ...
>
> In which case why bother half-saying otherwise?
>
> I thought it was already quite clear all along, that people who want to o=
r have their own good reasons to are free to implement any other codecs the=
y please - and that they already have, and certainly will continue to do so=
?
>
> > Any opinion on that?
>
> I don't really see much point to handwaving about particular niche codecs=
 for particular niche uses unless this is going to be some sort of separate=
 informational document, that is kept up to date with changes in all the ni=
ches that people have an interest in.
>
> That might be useful.  But 'mandating' something that the people who will=
 do it were going to do it anyway, and the people who were not are still no=
t going to do, doesn't seem to add any real value here to either users or i=
mplementers.  It won't explain anything to anybody that they don't already =
know if it is of any interest to them.
>
>  Cheers,
>  Ron
>
>
> _______________________________________________
> 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_9F33F40F6F2CD847824537F3C4E37DDF06899848MCHP04MSXglobal_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi All,=



 <=
/p>

I thought the suggested t=
ext that came from Andrew Allen a couple of months ago was a good compromis=
e.


 <=
/p>

I repeat it below.


 <=
/p>

 <=
/p>

On 17 January 2013 18:00 Andrew Allen wrote:=



> 


> I would propose:    &nbs=
p; :


> 


> "If other suitable audio codecs are ava=
ilable to the browser to use it


> is recommended that they are also included i=
n the offer in order to


> maximize the possibility to establish the se=
ssion without the need for


> audio transcoding"


> 


> This is enough to make implementers think ab=
out the transcoding issue.


> 


 


Regards


Andy


 <=
/p>

 <=
/p>







From: rtcweb-b=
ounces@ietf.org [mailto:rtcweb-bounces@ietf.org]
On Behalf Of Cameron Byrne

Sent: 13 March 2013 14:18

To: Bogineni, Kalyani

Cc: Xavier Marjou; rtcweb@ietf.org

Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-au=
dio-codecs-for-interop-01






 




On Mar 13, 2013 7:50 AM, "Bogineni, Kalyani" <Kalyani.Bogineni@verizonwireless.co=
m> wrote:

>

> There are 6.4 billion cellular connections worldwide.

>

> http://www=
.3gpp.org/3GPP-Family-2012-Statistics

>


Then it will really be transformational for them to support Opus as a we=
brtc requirement. I look forward to all these Opus devices


CB


> Regards,

> Kalyani Bogineni

>

> -----Original Message-----

> From: rtcweb-bounces@ietf.o=
rg [mailto:rtcweb-bounces@ie=
tf.org] On Behalf Of Ron

> Sent: Wednesday, March 13, 2013 10:28 AM

> To: Xavier Marjou; rtcweb@ietf.org<=
/a>

> Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audi=
o-codecs-for-interop-01

>

>

> Hi Xavier,

>

> On Wed, Mar 13, 2013 at 09:14:30AM -0400, Xavier Marjou wrote:

> > Here is a summary of the

> > draft-marjou-rtcweb-audio-codecs-for-interop-00

> > presentation that I had prepared for yesterday's session:

> >

> > - The co-authors want to underline that non-WebRTC voice endpoint=
s

> > usually use one of the following codecs: AMR, AMR-WB or G.722, wh=
ich

> > will result in massive transcoding when there will be communicati=
ons

> > between WebRTC endpoints and non-WebRTC endpoints.

>

> "Massive" seems a little overstated here.  Any system p=
roviding a gateway service to or between 'low bandwidth' devices is almost =
surely going to support more than just WebRTC, and is going to have to tran=
scode for most or all of them anyway.  Adding an extra
 burden to WebRTC, especially one that would only ever apply to some small =
subset of users, wouldn't appear to make a significant difference in the re=
quirements for such a system.

>

>

> > - On one side, transcoding is bad for many reasons discussed in t=
he

> > draft (cost issues, intrinsic quality degradation, degraded

> > interactivity, fallback from HD to G.711...);

>

> Are you aware of the listening tests presented to the CODEC WG?

>

> In particular the ones that show Opus->AMR and AMR->Opus is not =
significantly worse than the intrinsic quality degradation suffered by usin=
g AMR alone?

>

> Or that Opus->G.711->AMR is actually better than AMR->G.711-&=
gt;AMR ?

>

>

> > - On the other side, it is recognized that implementing additiona=
l

> > codecs in the browsers can generate additional costs.

> >

> > - In order to reach a compromise, we would like to add some text =
in

> > the WG draft draft-ietf-rtcweb-audio providing incentives for the=


> > browser to use these three codecs: make them mandatory to impleme=
nt

> > when there is no cost impact on the browser (e.g. if codec alread=
y

> > installed, paid by the device vendor...).

>

> Since there is never no cost impact to supporting additional features,=
 that would imply this is never mandatory ...

>

> In which case why bother half-saying otherwise?

>

> I thought it was already quite clear all along, that people who want t=
o or have their own good reasons to are free to implement any other codecs =
they please - and that they already have, and certainly will continue to do=
 so?

>

> > Any opinion on that?

>

> I don't really see much point to handwaving about particular niche cod=
ecs for particular niche uses unless this is going to be some sort of separ=
ate informational document, that is kept up to date with changes in all the=
 niches that people have an interest
 in.

>

> That might be useful.  But 'mandating' something that the people =
who will do it were going to do it anyway, and the people who were not are =
still not going to do, doesn't seem to add any real value here to either us=
ers or implementers.  It won't explain anything
 to anybody that they don't already know if it is of any interest to them.<=
br>
>

>  Cheers,

>  Ron

>

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.i=
etf.org/mailman/listinfo/rtcweb

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.i=
etf.org/mailman/listinfo/rtcweb








--_000_9F33F40F6F2CD847824537F3C4E37DDF06899848MCHP04MSXglobal_--

From jmvalin@mozilla.com  Wed Mar 13 12:24: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 32FA621F8E36 for ; Wed, 13 Mar 2013 12:24:12 -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 GVtt4mIe7rTk for ; Wed, 13 Mar 2013 12:24:11 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2297021F8DC9 for ; Wed, 13 Mar 2013 12:24:11 -0700 (PDT)
Received: from [130.129.33.249] (dhcp-21f9.meeting.ietf.org [130.129.33.249]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 8119EF22B2;  Wed, 13 Mar 2013 12:24:10 -0700 (PDT)
Message-ID: <5140D259.6010208@mozilla.com>
Date: Wed, 13 Mar 2013 15:24:09 -0400
From: Jean-Marc Valin 
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Xavier Marjou 
References:   
In-Reply-To: 
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 19:24:12 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I'd really like to understand how the chairs coming to the conclusion
that there was *no consensus* on recommended codecs can result in a
draft that includes 3 MUSTs and 1 SHOULD. This draft effectively makes
3 new codecs MTI for a range of devices. I understand that it's an
individual draft and you can write whatever you like in there, but it
definitely goes against the result of the WG discussion.

Cheers,

	Jean-Marc

On 03/13/2013 09:14 AM, Xavier Marjou wrote:
> Here is a summary of the
> draft-marjou-rtcweb-audio-codecs-for-interop-00 presentation that I
> had prepared for yesterday's session:
> 
> - The co-authors want to underline that non-WebRTC voice endpoints 
> usually use one of the following codecs: AMR, AMR-WB or G.722,
> which will result in massive transcoding when there will be
> communications between WebRTC endpoints and non-WebRTC endpoints.
> 
> - On one side, transcoding is bad for many reasons discussed in
> the draft (cost issues, intrinsic quality degradation, degraded 
> interactivity, fallback from HD to G.711...);
> 
> - On the other side, it is recognized that implementing additional 
> codecs in the browsers can generate additional costs.
> 
> - In order to reach a compromise, we would like to add some text in
> the WG draft draft-ietf-rtcweb-audio providing incentives for the
> browser to use these three codecs: make them mandatory to implement
> when there is no cost impact on the browser (e.g. if codec already
> installed, paid by the device vendor...).
> 
> Any opinion on that?
> 
> Cheers,
> 
> Xavier
> 
> PS: I will be ready to present the slides on Thursday if time
> permits it.
> 
> (c.f. http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf
> )
> 
> 
> 
> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie  > wrote:
> 
> Magnus and I discussed this this morning, and we encourage you to 
> prepare something.  If the discussion of working group last call
> items runs short, we may be able to fit this in at that time or at
> the end of day one if its full agenda his finished.  This is not a
> commitment, however, so please try and get discussion on the list
> on the points from the draft you feel need resolution.
> 
> regards,
> 
> Ted
> 
> 
> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg) 
> > wrote:
>> Hello,
>> 
>> 
>> 
>> I would like to request agenda time for:
>> 
>> 
>> 
>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>> 
>> 
>> 
>> The document  presents use-cases underlining why WebRTC needs
> AMR-WB,  AMR
>> and G.722 as additional relevant voice codecs to satisfactorily
>> ensure interoperability with existing systems.
>> 
>> 
>> 
>> A 10-minute time slot should be sufficient for presentation and
> discussion.
>> 
>> 
>> 
>> Regards
>> 
>> 
>> 
>> -Espen
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________ 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
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRQNJZAAoJEJ6/8sItn9q9vNYIAL64nPUsZfKfxSYteqTQRPmg
CzVXzr8GEBtR8gugL6KO5Lxgux+3fYKm7BJHirZyyCF1uPWIvXNevE2ad1KvHFwC
yT9XlzgiiHX79SOEyd3bIn9thycBXBSAAiqyCkz5E/eEYskPFQ4e5AVDezjjvMGF
L1Fx1PtsYuMRWEXZNB8wglH9sk3xeWe02o9s4TqLxwiseTS3CJ1kTwoHfIo5e4oX
26NMjBBiEy/eKK9qtmry9Octjr93OgtFVavPoXN/sNqCW8u8kreVOSxeegJ233n9
WQYhkctybnS22RTjbu3W6mZafpyOGi41rIzdGyUocmTelsFfT3hban5OU+1kQRw=
=P8Jl
-----END PGP SIGNATURE-----

From jmvalin@mozilla.com  Wed Mar 13 12: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 BD28421F8C71 for ; Wed, 13 Mar 2013 12:32:12 -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 ngM0GdBaMPS6 for ; Wed, 13 Mar 2013 12:32:11 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id A494A21F8C5C for ; Wed, 13 Mar 2013 12:32:11 -0700 (PDT)
Received: from [130.129.33.249] (dhcp-21f9.meeting.ietf.org [130.129.33.249]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 1FF5EF2309;  Wed, 13 Mar 2013 12:32:11 -0700 (PDT)
Message-ID: <5140D43A.2050901@mozilla.com>
Date: Wed, 13 Mar 2013 15:32:10 -0400
From: Jean-Marc Valin 
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Tim Panton 
References:    <20130313142732.GE12022@audi.shelbyville.oz> <20130313143808.DB3BD21F8E0C@ietfa.amsl.com> 
In-Reply-To: 
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" , "Bogineni, Kalyani" , Xavier Marjou 
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 19:32:12 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/13/2013 12:11 PM, Tim Panton wrote:
> 
> 
> On 13 Mar 2013, at 14:37, Bogineni, Kalyani wrote:
> 
>> There are 6.4 billion cellular connections worldwide.
>> 
>> http://www.3gpp.org/3GPP-Family-2012-Statistics
>> 
>> Regards, Kalyani Bogineni
> 
> Following that logic we'd mandate GSM.610 since _all_ of those 6B
> devices support it.

Actually, the list of useful legacy codecs should also include Speex,
which is shipped in about 1B Flash-enabled browsers that may not have
WebRTC for some time.

Cheers,

	Jean-Marc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRQNQ6AAoJEJ6/8sItn9q9LTgH/jHIra6PibCID7vycAQ5uekx
/9ejOCy6FhqM+hQ0q5n5IB+rFIy5Uh1gLhQFrIsvo0lE8rjwklelf0QIBx3uxGJH
RzLZeGOHryJaH0kYBoBoFlc4WKzcUPz+BysGXmOv1jhk41Imgo17qBmHp2X99Nj0
n7/J1E15tRqZ0LCCbRbG03EnPEOqlU7AhIHG2GQOBI/k9QTHFIKhh6GQjZBkWhXq
YGsrzeTPPabcY++wt0fOb93UQwz2aJ3YFms0o9Gamgx818O0nn902h8Z0KhpYXQM
6GLZ0S9N+PjctNIXShF5p07n4Gjx9rl9rEaqQ20oKGF+hyrKNl6DAocsEwNpRYI=
=C52A
-----END PGP SIGNATURE-----

From tim@phonefromhere.com  Wed Mar 13 12: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 6A2161F0C74 for ; Wed, 13 Mar 2013 12:35:17 -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 75MGtwWSlMbh for ; Wed, 13 Mar 2013 12:35:16 -0700 (PDT)
Received: from smtp004.apm-internet.net (smtp004.apm-internet.net [85.119.248.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6A42821F8C9F for ; Wed, 13 Mar 2013 12:35:16 -0700 (PDT)
Received: (qmail 8264 invoked from network); 13 Mar 2013 19:35:15 -0000
X-AV-Scan: clean
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp004.apm-internet.net with SMTP; 13 Mar 2013 19:35:15 -0000
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 0FC2A18A02C5; Wed, 13 Mar 2013 19:35:15 +0000 (GMT)
Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id E08B018A029A;  Wed, 13 Mar 2013 19:35:14 +0000 (GMT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=iso-8859-1
From: Tim Panton 
In-Reply-To: <3769_1363194737_5140B371_3769_3650_1_6ccb4089-ab79-4913-a456-72b68a77f9a0@PEXCVZYH02.corporate.adroot.infra.ftgroup>
Date: Wed, 13 Mar 2013 19:35:14 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    <20130313142732.GE12022@audi.shelbyville.oz> <20130313143808.DB3BD21F8E0C@ietfa.amsl.com>  <3769_1363194737_5140B371_3769_3650_1_6ccb4089-ab79-4913-a456-72b68a77f9a0@PEXCVZYH02.corporate.adroot.infra.ftgroup>
To:  
X-Mailer: Apple Mail (2.1283)
Cc: "rtcweb@ietf.org" , "Bogineni, Kalyani" , MARJOU Xavier OLNC/OLN 
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 19:35:17 -0000

On 13 Mar 2013, at 17:12,  =
 wrote:

>> I'd also like to point out that the "massive" transcoding cited =
already occurs between mobile devices that support various codecs (GSM, =
AMR etc) and the PSTN - (g711, g729) and the sky hasn't fallen yet.
>=20
> But transcoding to G.711 has simply absolutely nothing to do in terms =
of impact on gateways costs and capacities !
> Transcoding to G.711 almost cost nothing.
> For your information: complexity of G.711 is around 0,01 WMPOS when =
AMR-WB is at 40 WMOPS and OPUS still higher...=20
> So we speak about a factor of more than 1000 in terms  transcoding =
complexity and related impact on gateways !
> And even with respect to AMR, G.722 or AMR-WB, transcoding from/to =
OPUS will still be more costly
>=20
> St=E9phane


When the PSTN <-> mobile network gateways were first set up the cpus =
were 1000x slower.=20
No one seriously considered imposing G711 on the mobile network, because =
it was unsuitable.

T.


From stephane.proust@orange.com  Wed Mar 13 12:37: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 EE2AE21F8CD3 for ; Wed, 13 Mar 2013 12:37:02 -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 DmlNYnCeXjx3 for ; Wed, 13 Mar 2013 12:37:01 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC0021F8CB1 for ; Wed, 13 Mar 2013 12:37:01 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 944E322CDC4; Wed, 13 Mar 2013 20:37:00 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 718E94C017; Wed, 13 Mar 2013 20:37:00 +0100 (CET)
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; Wed, 13 Mar 2013 20:36:59 +0100
From: 
To: Jean-Marc Valin , MARJOU Xavier OLNC/OLN 
Thread-Topic: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOG09ymYYSjCiSbkqm//fZ3y/fLpijkgEAgABnSICAABKQoA==
Date: Wed, 13 Mar 2013 19:36:52 +0000
Message-ID: <31611_1363203420_5140D55C_31611_11752_1_cb7bfd1e-a4ca-40ba-bbbc-cb23fb3f3edb@PEXCVZYH02.corporate.adroot.infra.ftgroup>
References:    <5140D259.6010208@mozilla.com>
In-Reply-To: <5140D259.6010208@mozilla.com>
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.13.152725
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Agenda time request for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 19:37:03 -0000

Hello

Our understanding is that the reason of the "no consensus" on additional re=
commended codecs was the additional costs for browsers.
The proposal is then to make these "MUST" fully conditional to the case of =
no (or very reduced) additional costs, when the codecs are already availabl=
e on the device and when no additional license fee is required

We could even live with lower level of "requirements" with respectively May=
 and Should (instead of Should and shall) but we think that this proposal i=
s a way to take into account both browser manufacturers concerns on browser=
s costs and telcos concerns on transcoding costs and some other companies s=
hare this view.

St=E9phane=09






-----Message d'origine-----
De=A0: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la part =
de Jean-Marc Valin
Envoy=E9=A0: mercredi 13 mars 2013 20:24
=C0=A0: MARJOU Xavier OLNC/OLN
Cc=A0: rtcweb@ietf.org
Objet=A0: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-co=
decs-for-interop-01

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I'd really like to understand how the chairs coming to the conclusion that =
there was *no consensus* on recommended codecs can result in a draft that i=
ncludes 3 MUSTs and 1 SHOULD. This draft effectively makes
3 new codecs MTI for a range of devices. I understand that it's an individu=
al draft and you can write whatever you like in there, but it definitely go=
es against the result of the WG discussion.

Cheers,

	Jean-Marc

On 03/13/2013 09:14 AM, Xavier Marjou wrote:
> Here is a summary of the
> draft-marjou-rtcweb-audio-codecs-for-interop-00 presentation that I=20
> had prepared for yesterday's session:
>=20
> - The co-authors want to underline that non-WebRTC voice endpoints=20
> usually use one of the following codecs: AMR, AMR-WB or G.722, which=20
> will result in massive transcoding when there will be communications=20
> between WebRTC endpoints and non-WebRTC endpoints.
>=20
> - On one side, transcoding is bad for many reasons discussed in the=20
> draft (cost issues, intrinsic quality degradation, degraded=20
> interactivity, fallback from HD to G.711...);
>=20
> - On the other side, it is recognized that implementing additional=20
> codecs in the browsers can generate additional costs.
>=20
> - In order to reach a compromise, we would like to add some text in=20
> the WG draft draft-ietf-rtcweb-audio providing incentives for the=20
> browser to use these three codecs: make them mandatory to implement=20
> when there is no cost impact on the browser (e.g. if codec already=20
> installed, paid by the device vendor...).
>=20
> Any opinion on that?
>=20
> Cheers,
>=20
> Xavier
>=20
> PS: I will be ready to present the slides on Thursday if time permits=20
> it.
>=20
> (c.f. http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf
> )
>=20
>=20
>=20
> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie  > wrote:
>=20
> Magnus and I discussed this this morning, and we encourage you to=20
> prepare something.  If the discussion of working group last call items=20
> runs short, we may be able to fit this in at that time or at the end=20
> of day one if its full agenda his finished.  This is not a commitment,=20
> however, so please try and get discussion on the list on the points=20
> from the draft you feel need resolution.
>=20
> regards,
>=20
> Ted
>=20
>=20
> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)=20
> > wrote:
>> Hello,
>>=20
>>=20
>>=20
>> I would like to request agenda time for:
>>=20
>>=20
>>=20
>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>>=20
>>=20
>>=20
>> The document  presents use-cases underlining why WebRTC needs
> AMR-WB,  AMR
>> and G.722 as additional relevant voice codecs to satisfactorily=20
>> ensure interoperability with existing systems.
>>=20
>>=20
>>=20
>> A 10-minute time slot should be sufficient for presentation and
> discussion.
>>=20
>>=20
>>=20
>> Regards
>>=20
>>=20
>>=20
>> -Espen
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________ rtcweb mailing list=20
>> rtcweb@ietf.org =20
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>=20
> _______________________________________________ rtcweb mailing list=20
> rtcweb@ietf.org =20
> https://www.ietf.org/mailman/listinfo/rtcweb
>=20
>=20
>=20
>=20
> _______________________________________________ rtcweb mailing list=20
> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
>=20

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRQNJZAAoJEJ6/8sItn9q9vNYIAL64nPUsZfKfxSYteqTQRPmg
CzVXzr8GEBtR8gugL6KO5Lxgux+3fYKm7BJHirZyyCF1uPWIvXNevE2ad1KvHFwC
yT9XlzgiiHX79SOEyd3bIn9thycBXBSAAiqyCkz5E/eEYskPFQ4e5AVDezjjvMGF
L1Fx1PtsYuMRWEXZNB8wglH9sk3xeWe02o9s4TqLxwiseTS3CJ1kTwoHfIo5e4oX
26NMjBBiEy/eKK9qtmry9Octjr93OgtFVavPoXN/sNqCW8u8kreVOSxeegJ233n9
WQYhkctybnS22RTjbu3W6mZafpyOGi41rIzdGyUocmTelsFfT3hban5OU+1kQRw=3D
=3DP8Jl
-----END PGP SIGNATURE-----
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.


From jmvalin@mozilla.com  Wed Mar 13 12:45: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 53A3221F8DC9 for ; Wed, 13 Mar 2013 12:45:03 -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 Kc3NmFHsZhWY for ; Wed, 13 Mar 2013 12:45:02 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 908FB21F8DDB for ; Wed, 13 Mar 2013 12:45:02 -0700 (PDT)
Received: from [130.129.33.249] (dhcp-21f9.meeting.ietf.org [130.129.33.249]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 32249F202D;  Wed, 13 Mar 2013 12:45:02 -0700 (PDT)
Message-ID: <5140D73D.2080209@mozilla.com>
Date: Wed, 13 Mar 2013 15:45:01 -0400
From: Jean-Marc Valin 
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Xavier Marjou 
References:   
In-Reply-To: 
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 19:45:03 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/13/2013 09:14 AM, Xavier Marjou wrote:
> - In order to reach a compromise, we would like to add some text in
> the WG draft draft-ietf-rtcweb-audio providing incentives for the
> browser to use these three codecs: make them mandatory to implement
> when there is no cost impact on the browser (e.g. if codec already
> installed, paid by the device vendor...).

I think this is the main faulty assumption here. "Royalties already
paid" does not imply "free". There's a real cost here because
supporting AMR, AMR-WB, G.722 and any other codecs added to that list
means that:
1) Someone has to write all the code for actually using these codecs
in their RTP stack.
2) There is no standard interface for accessing these codecs, so a
browser vendor would have to write code for each of these (often
undocumented) interface and *test* it on every device.
3) This code needs to be maintained and fixed for security
vulnerabilities.
4) If there's any issue (e.g. buffer overflow) in the platform
implementation of the codec, there's nothing the browser vendor can do
about it.

Oh, and that cost would be paid by pretty much all browser vendors
because they're all running on at least one platform that supports
each of these codecs.

Cheers,

	Jean-Marc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRQNc9AAoJEJ6/8sItn9q9WRYH/jzj4SoGpCQHZJGCO3Y0Ajuh
Eaj0rnJtHVg5LlR0QKEfJjXvqyyECAjfveJPnqFA8ALU8X1z+3McDsGJYisjpFm3
MbZKx3vE/Y/SYqy8jIP7/qPsba5eVuzKdUhoH4XzDNoowfBkQBkoys9JBpkL9osP
O+kRpXoouSu8CMGEuqgnl3gGddu/RayPaZTaDB0XICcxdsJF4S/C7E0RD3+XBr0f
rDcWQN4YkfI6VEaUZ+mGTAbMPBDCuahr8NYUJDwIQeqP7gWaAak/TV59+eZPi1El
o2qrom5fok1ZkWsC1izS4brs0tqmvggxYa9/snYnbjADmB9uOVtlH9Y+lrwHrRo=
=Ptz8
-----END PGP SIGNATURE-----

From jmvalin@mozilla.com  Wed Mar 13 12:55: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 79D8411E809C for ; Wed, 13 Mar 2013 12:55:03 -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 5X5pNHIY9MKY for ; Wed, 13 Mar 2013 12:55:02 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id D906811E80ED for ; Wed, 13 Mar 2013 12:55:02 -0700 (PDT)
Received: from [130.129.33.249] (dhcp-21f9.meeting.ietf.org [130.129.33.249]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 3C6C4F210E;  Wed, 13 Mar 2013 12:55:02 -0700 (PDT)
Message-ID: <5140D995.5050702@mozilla.com>
Date: Wed, 13 Mar 2013 15:55:01 -0400
From: Jean-Marc Valin 
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: stephane.proust@orange.com
References:    <5140D259.6010208@mozilla.com> <31611_1363203420_5140D55C_31611_11752_1_cb7bfd1e-a4ca-40ba-bbbc-cb23fb3f3edb@PEXCVZYH02.corporate.adroot.infra.ftgroup>
In-Reply-To: <31611_1363203420_5140D55C_31611_11752_1_cb7bfd1e-a4ca-40ba-bbbc-cb23fb3f3edb@PEXCVZYH02.corporate.adroot.infra.ftgroup>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" , MARJOU Xavier OLNC/OLN 
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 19:55:03 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/13/2013 03:36 PM, stephane.proust@orange.com wrote:
> Our understanding is that the reason of the "no consensus" on 
> additional recommended codecs was the additional costs for
> browsers. The proposal is then to make these "MUST" fully
> conditional to the case of no (or very reduced) additional costs,
> when the codecs are already available on the device and when no
> additional license fee is required

I think this understanding is wrong, or else there would have been
consensus on recommending G.722. People (including myself) objected on
the basis that SHOULD/RECOMMENDED is too strong for an optional codec.

> We could even live with lower level of "requirements" with 
> respectively May and Should (instead of Should and shall) but we 
> think that this proposal is a way to take into account both
> browser manufacturers concerns on browsers costs and telcos
> concerns on transcoding costs and some other companies share this
> view.

It should all be MAY unless the WG agrees on making any of these
codecs a SHOULD -- which has not happened yet AFAIK.

Cheers,

	Jean-Marc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRQNmVAAoJEJ6/8sItn9q9BJoIAIxTzEW27t64Sxi+uyKKxCc+
IKX5A7F5SCwpcjhaWWybWa1TOYunxOBo24XIXsWyYqambA1nXnlgCcSqCbj7hrbq
onIy+vnzpgBdnFL53DijogWTBoHwIWLZFjxL9oJXrWPoMdlhn3B3PoZcCAWUbd0x
EHnmbtsqwQRzPnB1bJa/mdtWGLHbnz6Zv9pFolipB60h6Ne3PSydk8jEqy7zhugC
XLKzmPND3GCyQL91YNdWjWHFqrpUeYlB0qS27m1GyddH3dp2EI5b7mRmS8/Yi98h
zMJvRlfpr3TVa0xtExzVYZpI44qr9+7QbRoCUnIEiHg45nBKJ+1VlDegZAwvNMs=
=6Ty9
-----END PGP SIGNATURE-----

From tim@phonefromhere.com  Wed Mar 13 13: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 43BA011E80D2 for ; Wed, 13 Mar 2013 13:11:38 -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 K6ovZOdJXNfC for ; Wed, 13 Mar 2013 13:11:37 -0700 (PDT)
Received: from smtp004.apm-internet.net (smtp004.apm-internet.net [85.119.248.54]) by ietfa.amsl.com (Postfix) with ESMTP id 568E111E814B for ; Wed, 13 Mar 2013 13:11:37 -0700 (PDT)
Received: (qmail 17546 invoked from network); 13 Mar 2013 20:11:36 -0000
X-AV-Scan: clean
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp004.apm-internet.net with SMTP; 13 Mar 2013 20:11:36 -0000
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 59A5518A02C5; Wed, 13 Mar 2013 20:11:36 +0000 (GMT)
Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 3A38318A0203;  Wed, 13 Mar 2013 20:11:36 +0000 (GMT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Tim Panton 
In-Reply-To: <5140D73D.2080209@mozilla.com>
Date: Wed, 13 Mar 2013 20:11:35 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    <5140D73D.2080209@mozilla.com>
To: Jean-Marc Valin 
X-Mailer: Apple Mail (2.1283)
Cc: rtcweb@ietf.org, Xavier Marjou 
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 20:11:38 -0000

On 13 Mar 2013, at 19:45, Jean-Marc Valin wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> On 03/13/2013 09:14 AM, Xavier Marjou wrote:
>> - In order to reach a compromise, we would like to add some text in
>> the WG draft draft-ietf-rtcweb-audio providing incentives for the
>> browser to use these three codecs: make them mandatory to implement
>> when there is no cost impact on the browser (e.g. if codec already
>> installed, paid by the device vendor...).
>=20
> I think this is the main faulty assumption here. "Royalties already
> paid" does not imply "free". There's a real cost here because
> supporting AMR, AMR-WB, G.722 and any other codecs added to that list
> means that:
> 1) Someone has to write all the code for actually using these codecs
> in their RTP stack.
> 2) There is no standard interface for accessing these codecs, so a
> browser vendor would have to write code for each of these (often
> undocumented) interface and *test* it on every device.
> 3) This code needs to be maintained and fixed for security
> vulnerabilities.
> 4) If there's any issue (e.g. buffer overflow) in the platform
> implementation of the codec, there's nothing the browser vendor can do
> about it.
>=20
> Oh, and that cost would be paid by pretty much all browser vendors
> because they're all running on at least one platform that supports
> each of these codecs.

And that assumes that the codec license signed by the hardware maker =
permits the use of these 'no-cost' in all the possible ways
the javascript user wants. E.g. is it limited in number of channels ? Is =
the license symmetrical wrt encoding and decoding ?
Is it available to 3rd party browser makers (eg chrome on blackberry? Or =
to products derived from the native browser browsers
or that embed browser objects (like cordova/phonegap) ?

T.





From roman@telurix.com  Wed Mar 13 13:44: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 DA47321F8DB4 for ; Wed, 13 Mar 2013 13:44:11 -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=[AWL=0.278,  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 ghRxB83ois-L for ; Wed, 13 Mar 2013 13:44:11 -0700 (PDT)
Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 49A4221F8DA2 for ; Wed, 13 Mar 2013 13:44:10 -0700 (PDT)
Received: by mail-we0-f182.google.com with SMTP id t57so1446305wey.41 for ; Wed, 13 Mar 2013 13:44:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=hltePgwNGZckzL4dOGsV15DNop6g/cWkUZ3wLN6Lfe0=; b=TbjCa13TjOKovtgD2NE5YO/tlN7G+RBNn5pvckvqIqZTLWx0//3VwEw+te0bG2FErL NnshzHZlBl/uz9SDQBz/Rb3D+c+eF94h6+Wbp1EnsMj9VKIkYwIEiENCcspZklIoeJOT qLgohBFY/E8CNLgsOYkU/fdORs80hU2EwSXzAenhtENCFx9kjxymlxYBeuv3PeYsFf4o b5pFRDTKyRK4RAZpKLJ+MztYdo1zRed0h+gWvkW16GofXtv4ymG1StWg9w94TniDCsiq I7Ksr2gCiBtFwdchCV7FnOmHKff9dv34jem6xGO3mHe1AosXUswubqzIF0eO9wy7wr17 Eong==
X-Received: by 10.180.97.233 with SMTP id ed9mr29448713wib.32.1363207449304; Wed, 13 Mar 2013 13:44:09 -0700 (PDT)
Received: from mail-wg0-x229.google.com ([2a00:1450:400c:c00::229]) by mx.google.com with ESMTPS id o8sm5156263wix.7.2013.03.13.13.44.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Mar 2013 13:44:08 -0700 (PDT)
Received: by mail-wg0-f41.google.com with SMTP id ds1so1042616wgb.0 for ; Wed, 13 Mar 2013 13:44:07 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.76.37 with SMTP id h5mr37267307wjw.21.1363207447480; Wed, 13 Mar 2013 13:44:07 -0700 (PDT)
Received: by 10.217.107.135 with HTTP; Wed, 13 Mar 2013 13:44:07 -0700 (PDT)
In-Reply-To: <5140D73D.2080209@mozilla.com>
References:    <5140D73D.2080209@mozilla.com>
Date: Wed, 13 Mar 2013 16:44:07 -0400
Message-ID: 
From: Roman Shpount 
To: Jean-Marc Valin 
Content-Type: multipart/alternative; boundary=047d7bb03bc4a9965804d7d477e1
X-Gm-Message-State: ALoCoQm+mK1D/gYzxdnef5MqtSP5WCkUgHI2UabiKZgAGtpeUt1yZ0udTErmlTqKj25SiuEdkQ4n
Cc: rtcweb@ietf.org, Xavier Marjou 
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 20:44:12 -0000

--047d7bb03bc4a9965804d7d477e1
Content-Type: text/plain; charset=ISO-8859-1

G.722 is currently part of the browser code base and the cost of adding it
is the cost of adding one define. Availability of G.722 on the platform
itself is irrelevant. Cost of supporting it in the future is a different
matter, but it is fairly small and would be comparable to support cost of
G.711.

I would generally agree that in the long run having too many MTI codecs is
too restricting. What I want to see is some sort of commitment from the
browser manufacturers to support codecs beside MTI, especially initially,
until Opus support is more wide spread.
_____________
Roman Shpount

--047d7bb03bc4a9965804d7d477e1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

G.722 is currently part of the browser code base and the cost of adding it =
is the cost of adding one define.=A0Availability=A0of G.722 on the platform=
 itself is irrelevant. Cost of supporting it in the future is a different m=
atter, but it is fairly small and would be comparable to support cost of G.=
711.


I would generally agree that in the long run having too many=
 MTI codecs is too restricting. What I want to see is some sort of commitme=
nt from the browser manufacturers to support codecs beside MTI, especially =
initially, until Opus support is more wide spread.


_____________
Roman Shpount




--047d7bb03bc4a9965804d7d477e1--

From michael@voip.co.uk  Wed Mar 13 13: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 7FECE11E8114 for ; Wed, 13 Mar 2013 13:54:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.977
X-Spam-Level: 
X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 n8FFJB-+3IsC for ; Wed, 13 Mar 2013 13:54:15 -0700 (PDT)
Received: from na3sys009aog126.obsmtp.com (na3sys009aog126.obsmtp.com [74.125.149.155]) by ietfa.amsl.com (Postfix) with SMTP id A3F5711E8107 for ; Wed, 13 Mar 2013 13:54:14 -0700 (PDT)
Received: from mail-fa0-f71.google.com ([209.85.161.71]) (using TLSv1) by na3sys009aob126.postini.com ([74.125.148.12]) with SMTP ID DSNKUUDnagyS6bPVH1exmo+3atmlmxDIIypB@postini.com; Wed, 13 Mar 2013 13:54:14 PDT
Received: by mail-fa0-f71.google.com with SMTP id t1so2272852fae.10 for ; Wed, 13 Mar 2013 13:53:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=GnW6N80BlYW+WoYGg7zRlAcOYoqirlGtVMvmX146OsM=; b=a7Hvi1HvXbPawKFM9pfh2i72t8/RTBEtE5fWD5uQG4p6IMXRXAmHV0RKSqlxmOQcBI VxkJBaSBFyuXri8kze70tkXYQFNaC2UCqyyZ0Z7C7084lB/oSPoWtUc2oT7AgIAL75wO xYDLPUvI5XTAAzJMAfL4EuVj7FkQENTKRZJUw8a1Xy4fdWIfKgbGYnZLefjwnLCKXpAL EKLNt6as5Kn9prvqGSaOjWYJMU6SGevvS4VzY35FT7PiVvaJSu32ggnxb6Zb/lYABiBD rCzhlg65dNwABvTzOl8wwmruPunzNUxYnLZS6Pm6aiJZryHC6OwXm6MpMztIrfI9yEgN i8UA==
X-Received: by 10.194.172.71 with SMTP id ba7mr36871615wjc.26.1363208025912; Wed, 13 Mar 2013 13:53:45 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.172.71 with SMTP id ba7mr36871609wjc.26.1363208025840; Wed, 13 Mar 2013 13:53:45 -0700 (PDT)
Received: by 10.194.238.198 with HTTP; Wed, 13 Mar 2013 13:53:45 -0700 (PDT)
In-Reply-To: <5140BC2C.90206@nostrum.com>
References:    <20130313142732.GE12022@audi.shelbyville.oz> <7897A33F-F73A-4C39-B4DA-16F014A43C5C@edvina.net>  <8B7442F6-5393-4C5C-88B6-A680742F60E7@edvina.net>  <3C89A60B-3171-49B0-A78F-304337DF8D3D@edvina.net> <5140BC2C.90206@nostrum.com>
Date: Wed, 13 Mar 2013 20:53:45 +0000
Message-ID: 
From: Michael Procter 
To: rtcweb@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQmqZubduZe8eak4zsETPkS/ynLsFsU8gXqYW5kj/c8+iRQt+XU+q8rZWpxWqfm4ITjr7N+0Z8BsuLu6m9sBpaKJsRrKC7Rvqvd5kKrM/wpuo6kjq5XWJhOkNHzExGI5oIE7kA/1IvcQSLHz3qlrwPqgeUYWLA==
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 20:54:15 -0000

On 13 March 2013 17:49, Adam Roach  wrote:
> On 3/13/13 11:42, Olle E. Johansson wrote:
>>
>> I don't think everyone gets the that selecting a small subset as mandatory
>> for WebRTC does NOT exclude all other codecs. Feel free to add everything
>> you got. Have fun. Let the best mutual codec with the best mutual properties
>> win the session.
>
> Olle hit the nail squarely on the head. This is exactly the purpose of
> offer/answer negotiation: to find the best intersection of endpoint
> capabilities for the desired communication session. I'm bewildered by the
> fairly consistent misinterpretation that having an MTI codec somehow implies
> that every other codec becomes "MNTI".
>

This seems to be the key point - we aren't dividing codecs into two
buckets, one labelled MUST implement and one labelled MUST NOT
implement.  Codecs outside the MTI set can still be implemented and
will be implemented if it makes sense to the implementer.

Conversely, even if you get an RFC with dozens of "MUST implement
" in it, there won't be any protocol police to
enforce it if implementers decide it doesn't make sense (economic or
otherwise) for them to support those codecs.  There are plenty of
MUSTs in other RFCs that are routinely ignored, after all.

Michael

From Markus.Isomaki@nokia.com  Wed Mar 13 14:36: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 E5F6C21F8ACE for ; Wed, 13 Mar 2013 14:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.583
X-Spam-Level: 
X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016,  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 xb+Wl8uLwZxC for ; Wed, 13 Mar 2013 14:36:55 -0700 (PDT)
Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2C721F8A43 for ; Wed, 13 Mar 2013 14:36:55 -0700 (PDT)
Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r2DLaq3j026832; Wed, 13 Mar 2013 23:36:52 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 13 Mar 2013 23:36:52 +0200
Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.232]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0328.011; Wed, 13 Mar 2013 21:36:51 +0000
From: 
To: , , 
Thread-Topic: [rtcweb] Agenda time request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOICIoa3mWK5KFLkub0HumI94OcZikIdxQ
Date: Wed, 13 Mar 2013 21:36:51 +0000
Message-ID: 
References:    <5140D259.6010208@mozilla.com> <31611_1363203420_5140D55C_31611_11752_1_cb7bfd1e-a4ca-40ba-bbbc-cb23fb3f3edb@PEXCVZYH02.corporate.adroot.infra.ftgroup>
In-Reply-To: <31611_1363203420_5140D55C_31611_11752_1_cb7bfd1e-a4ca-40ba-bbbc-cb23fb3f3edb@PEXCVZYH02.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.129.67.65]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 13 Mar 2013 21:36:52.0372 (UTC) FILETIME=[E049F540:01CE2032]
X-Nokia-AV: Clean
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time request	for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 21:36:57 -0000

Hi Stephane, Xavier,

I understand the intent of your proposal. I'm not sure if the IETF is the b=
est venue for you to pursue it, however. Perhaps you as a mobile operator s=
hould rather set it as a requirement to your mobile device platforms that t=
hey open up the APIs to AMR and AMR-WB and that at least the in-built defau=
lt browser needs to support it. If there are enough operators setting such =
requirements directly to the device and platform vendors, it probably has a=
 bigger impact than an IETF RFC. Getting that support for user-installed ad=
ditional browsers might be more difficult, but most mobile device users sti=
ck with the default browser anyway.

The RTCWEB codec document needs to definitely explain this case and the ben=
efits, but the conditional MUSTs or SHOULDs you are proposing are perhaps a=
 bit too complicated. Hmm, perhaps we need to do an _informational_ RFC as =
something like "Recommendations for WebRTC on Mobile Devices" addressing th=
e codec and perhaps other issues, that you could use as a reference in your=
 requirements. =20

Markus


>-----Original Message-----
>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
>Of ext stephane.proust@orange.com
>Sent: 13 March, 2013 21:37
>To: Jean-Marc Valin; MARJOU Xavier OLNC/OLN
>Cc: rtcweb@ietf.org
>Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-
>codecs-for-interop-01
>
>Hello
>
>Our understanding is that the reason of the "no consensus" on additional
>recommended codecs was the additional costs for browsers.
>The proposal is then to make these "MUST" fully conditional to the case of=
 no
>(or very reduced) additional costs, when the codecs are already available =
on
>the device and when no additional license fee is required
>
>We could even live with lower level of "requirements" with respectively Ma=
y
>and Should (instead of Should and shall) but we think that this proposal i=
s a
>way to take into account both browser manufacturers concerns on browsers
>costs and telcos concerns on transcoding costs and some other companies
>share this view.
>
>St=E9phane
>
>
>
>
>
>
>-----Message d'origine-----
>De=A0: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la part
>de Jean-Marc Valin Envoy=E9=A0: mercredi 13 mars 2013 20:24 =C0=A0: MARJOU=
 Xavier
>OLNC/OLN Cc=A0: rtcweb@ietf.org Objet=A0: Re: [rtcweb] Agenda time request=
 for
>draft-marjou-rtcweb-audio-codecs-for-interop-01
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi,
>
>I'd really like to understand how the chairs coming to the conclusion that=
 there
>was *no consensus* on recommended codecs can result in a draft that
>includes 3 MUSTs and 1 SHOULD. This draft effectively makes
>3 new codecs MTI for a range of devices. I understand that it's an individ=
ual
>draft and you can write whatever you like in there, but it definitely goes
>against the result of the WG discussion.
>
>Cheers,
>
>	Jean-Marc
>
>On 03/13/2013 09:14 AM, Xavier Marjou wrote:
>> Here is a summary of the
>> draft-marjou-rtcweb-audio-codecs-for-interop-00 presentation that I
>> had prepared for yesterday's session:
>>
>> - The co-authors want to underline that non-WebRTC voice endpoints
>> usually use one of the following codecs: AMR, AMR-WB or G.722, which
>> will result in massive transcoding when there will be communications
>> between WebRTC endpoints and non-WebRTC endpoints.
>>
>> - On one side, transcoding is bad for many reasons discussed in the
>> draft (cost issues, intrinsic quality degradation, degraded
>> interactivity, fallback from HD to G.711...);
>>
>> - On the other side, it is recognized that implementing additional
>> codecs in the browsers can generate additional costs.
>>
>> - In order to reach a compromise, we would like to add some text in
>> the WG draft draft-ietf-rtcweb-audio providing incentives for the
>> browser to use these three codecs: make them mandatory to implement
>> when there is no cost impact on the browser (e.g. if codec already
>> installed, paid by the device vendor...).
>>
>> Any opinion on that?
>>
>> Cheers,
>>
>> Xavier
>>
>> PS: I will be ready to present the slides on Thursday if time permits
>> it.
>>
>> (c.f. http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf
>> )
>>
>>
>>
>> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie > > wrote:
>>
>> Magnus and I discussed this this morning, and we encourage you to
>> prepare something.  If the discussion of working group last call items
>> runs short, we may be able to fit this in at that time or at the end
>> of day one if its full agenda his finished.  This is not a commitment,
>> however, so please try and get discussion on the list on the points
>> from the draft you feel need resolution.
>>
>> regards,
>>
>> Ted
>>
>>
>> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)
>> > wrote:
>>> Hello,
>>>
>>>
>>>
>>> I would like to request agenda time for:
>>>
>>>
>>>
>>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>>>
>>>
>>>
>>> The document  presents use-cases underlining why WebRTC needs
>> AMR-WB,  AMR
>>> and G.722 as additional relevant voice codecs to satisfactorily
>>> ensure interoperability with existing systems.
>>>
>>>
>>>
>>> A 10-minute time slot should be sufficient for presentation and
>> discussion.
>>>
>>>
>>>
>>> Regards
>>>
>>>
>>>
>>> -Espen
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________ 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
>>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.13 (GNU/Linux)
>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
>iQEcBAEBAgAGBQJRQNJZAAoJEJ6/8sItn9q9vNYIAL64nPUsZfKfxSYteqTQRPmg
>CzVXzr8GEBtR8gugL6KO5Lxgux+3fYKm7BJHirZyyCF1uPWIvXNevE2ad1KvHFwC
>yT9XlzgiiHX79SOEyd3bIn9thycBXBSAAiqyCkz5E/eEYskPFQ4e5AVDezjjvMGF
>L1Fx1PtsYuMRWEXZNB8wglH9sk3xeWe02o9s4TqLxwiseTS3CJ1kTwoHfIo5e4o
>X
>26NMjBBiEy/eKK9qtmry9Octjr93OgtFVavPoXN/sNqCW8u8kreVOSxeegJ233n9
>WQYhkctybnS22RTjbu3W6mZafpyOGi41rIzdGyUocmTelsFfT3hban5OU+1kQR
>w=3D
>=3DP8Jl
>-----END PGP SIGNATURE-----
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb
>
>___________________________________________________________
>___________________________________________________________
>___
>
>Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc pas etre diffuses, expl=
oites
>ou copies sans autorisation. Si vous avez recu ce message par erreur, veui=
llez
>le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le=
s
>messages electroniques etant susceptibles d'alteration, France Telecom -
>Orange decline toute responsabilite si ce message a ete altere, deforme ou
>falsifie. Merci.
>
>This message and its attachments may contain confidential or privileged
>information that may be protected by law; they should not be distributed,
>used or copied without authorisation.
>If you have received this email in error, please notify the sender and del=
ete
>this message and its attachments.
>As emails may be altered, France Telecom - Orange is not liable for messag=
es
>that have been modified, changed or falsified.
>Thank you.
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb

From keith.drage@alcatel-lucent.com  Wed Mar 13 15:03: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 095F411E809C for ; Wed, 13 Mar 2013 15:03:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.198
X-Spam-Level: 
X-Spam-Status: No, score=-110.198 tagged_above=-999 required=5 tests=[AWL=0.400, 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 bJbjnCY0ryhr for ; Wed, 13 Mar 2013 15:03:38 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 18BD321F8D39 for ; Wed, 13 Mar 2013 15:03:36 -0700 (PDT)
Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r2DM3UPJ027439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Mar 2013 17:03:30 -0500 (CDT)
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r2DM3S4d006957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 13 Mar 2013 17:03:29 -0500
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 13 Mar 2013 18:03:29 -0400
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 13 Mar 2013 23:03:25 +0100
From: "DRAGE, Keith (Keith)" 
To: Andrew Allen , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Agenda time request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIBFgajoIOkWHW02dWrWPKwvhN5ij6q5LgABAECA=
Date: Wed, 13 Mar 2013 22:03:24 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B014285@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <949EF20990823C4C85C18D59AA11AD8B013D9D@FR712WXCHMBA11.zeu.alcatel-lucent.com> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.41]
Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B014285FR712WXCHMBA11zeu_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9
Subject: Re: [rtcweb] Agenda time request	for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 22:03:42 -0000

--_000_949EF20990823C4C85C18D59AA11AD8B014285FR712WXCHMBA11zeu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

And too many people are hiding behind the statement "we don't own all the p=
roblem" to ensure there will be no solution to the problem.

At the end of the day, the example already given of someone having had to p=
ay for an AMR licence for an i-phone should not exist, because it means the=
re are now two licensed versions of that codec on the i-phone.

Regards

Keith

________________________________
From: Andrew Allen [mailto:aallen@blackberry.com]
Sent: 13 March 2013 18:06
To: DRAGE, Keith (Keith); roman@telurix.com; rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01


Keith

That is out of scope of IETF. What I think you are suggesting amounts to op=
erating system standardisation.

If you believe in the market then the business case of the browser implemen=
ters and the device vendors should align with the interests of the users (I=
.e their customers) assuming the costs are not prohibitive.

Andrew



From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]
Sent: Wednesday, March 13, 2013 12:36 PM Central Standard Time
To: Andrew Allen; roman@telurix.com ; rtcweb@ietf.org 
Subject: RE: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01

The problem is that the business case for the device vendor or end user may=
 not be the business case for the browser vendor.

To be honest this discussion goes round and round in circles, with people t=
rying to say things are out of scope.

What I believe we need is something that encourages creation of APIs for em=
bedded codecs in the devices. Those API's should then be made available wit=
hin the browser.

This gets even more important when we get to video codecs. I am certainly i=
nterested in gateways from RTCWEB endpoints to other SIP based networks. Ha=
ving to transcode from one video codec to another because of this impasse i=
s a nightmare.

Someone has to break this loop.

Keith

________________________________
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Andrew Allen
Sent: 13 March 2013 17:30
To: roman@telurix.com; rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01


If there is a business case for implementers to support other codecs for im=
proved inteoperability with other networks and devices then they are very l=
ikely to do so.



From: Roman Shpount [mailto:roman@telurix.com]
Sent: Wednesday, March 13, 2013 12:12 PM Central Standard Time
To: rtcweb@ietf.org 
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01

Normally, when implementing VoIP devices, unless they are intended for some=
 sort of walled garden, you try to support as many codecs as possible. This=
 increases your chances of interoperability with other devices and your pro=
duct adoption. In case of WebRTC, it would be adopted regardless of what co=
decs are supported. The number of enabled devices would be so great that al=
l the legacy networks will have to adapt. This has some negative implicatio=
ns to the legacy networks as far as quality and costs are concerned, but th=
ese challenges are not insurmountable. So, taking this into consideration, =
I want to place the same questions differently:

Do web browser implementers currently plan to support any other codecs exce=
pt MTI (G.711 and OPUS)?

Is there anything we are going to say here regarding legacy interop that wo=
uld make browser manufacturers to change their mind? After all, this repres=
ents additional cost to them with no direct benefit for the use cases which=
 are most important to them (browser to browser calls).

For me, the desired outcome would be that browsers, at least for the next f=
ew years, do support a reasonable set of other codecs in addition to MTI, i=
ncluding G.722, AMR, AMR-WB, and may be Speex, . This would give me an oppo=
rtunity to migrate from devices that support legacy codecs to devices that =
support Opus. The fact that different browser versions would support differ=
ent codec sets (like desktop browsers not supporting AMR) is not a big issu=
e, at least for me, since we always have G.711 or transcoding to fall back =
to. The same goes for browsers fazing some of the legacy codecs out in the =
future. The end result would still be better then 100% G.711 or transcoding=
.
_____________
Roman Shpount

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.

--_000_949EF20990823C4C85C18D59AA11AD8B014285FR712WXCHMBA11zeu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











And too many people are hiding behind =
the statement “we don’t own all the problem” to ensure th=
ere will be no solution to the problem.


 


At the end of the day, the example alr=
eady given of someone having had to pay for an AMR licence for an i-phone s=
hould not exist, because
 it means there are now two licensed versions of that codec on the i-phone.=



 


Regards


 


Keith


 












From: Andrew Allen
 [mailto:aallen@blackberry.com] 

Sent: 13 March 2013 18:06
To: DRAGE, Keith (Keith); ro=
man@telurix.com; rtcweb@ietf.org

Subject: Re: [rtcweb] Agenda=
 time request for draft-marjou-rtcweb-audio-codecs-for-interop-01




 


=


Keith



That is out of scope of IETF. What I think you are suggesting amounts to op=
erating system standardisation.



If you believe in the market then the business case of the browser implemen=
ters and the device vendors should align with the interests of the users (I=
.e their customers) assuming the costs are not prohibitive.



Andrew





 




From: DRAG=
E, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]


Sent: Wednesday, 
March 13, 2013 1=
2:36 PM Central Standard Time

To: Andrew Allen; roman@telu=
rix.com <roman@telurix.com>; rtcweb@ietf.org <rtcweb@ietf.org>


Subject: RE: [rtcweb] Agenda=
 time request for draft-marjou-rtcweb-audio-codecs-for-interop-01


 




The problem is that the business case =
for the device vendor or end user may not be the business case for the brow=
ser vendor.


 


To be honest this discussion goes roun=
d and round in circles, with people trying to say things are out of scope.<=
o:p>


 


What I believe we need is something th=
at encourages creation of APIs for embedded codecs in the devices. Those
API’s should then be m=
ade available within the browser.



 


This gets even more important when we =
get to video codecs. I am certainly interested in gateways from RTCWEB endp=
oints to other SIP based
 networks. Having to transcode from one video codec to another because of t=
his impasse is a nightmare.


 


Someone has to break this loop.


 


Keith


 












From: rtcweb-bounces@ietf.org
 [mailto:rtcweb-bounces@ietf.org] On Be=
half Of 
Andrew Allen

Sent: 13 March 2013 17:30
To: roman@telurix.com; rtcwe=
b@ietf.org

Subject: Re: [rtcweb] Agenda=
 time request for draft-marjou-rtcweb-audio-codecs-for-interop-01




 


=


If there is a business case for implementers to support other codecs for im=
proved inteoperability with other networks and devices then they are very l=
ikely to do so.





 




From: Roma=
n Shpount [mailto:roman@telurix.com]


Sent: Wednesday, 
March 13, 2013 1=
2:12 PM Central Standard Time

To: rtcweb@ietf.org <rtcw=
eb@ietf.org>


Subject: Re: [rtcweb] Agenda=
 time request for draft-marjou-rtcweb-audio-codecs-for-interop-01


 






Normally, when implementing VoIP devices, unless they are intended =
for some sort of walled garden, you try to support as many codecs as possib=
le. This increases your
 chances of interoperability with other devices and your product adoption. =
In case of WebRTC, it would be adopted regardless of what codecs are suppor=
ted. The number of enabled devices would be so great that all the legacy ne=
tworks will have to adapt. This
 has some negative implications to the legacy networks as far as quality an=
d costs are concerned, but these challenges are not insurmountable. So, tak=
ing this into consideration, I want to place the same questions differ=
ently:






 






Do web browser implementers currently plan to support any other cod=
ecs except MTI (G.711 and OPUS)?






 






Is there anything we are going to say here regarding legacy interop=
 that would make browser manufacturers to change their mind? After all, thi=
s represents additional
 cost to them with no direct benefit for the use cases which are most impor=
tant to them (browser to browser calls).






 






For me, the desired outcome would be that browsers, at least for th=
e next few years, do support a reasonable set of other codecs in addition t=
o MTI, including G.722,
AMR, AMR-WB, and may be Speex, . This would give =
me an opportunity to migrate from devices that support legacy codecs to dev=
ices that support Opus. The fact that different
 browser versions would support different codec sets (like desktop browsers=
 not supporting
AMR) is not a big issue, at =
least for me, since we always have G.711 or transcoding to fall back to. Th=
e same goes for browsers fazing some of the legacy codecs out in the future=
. The end result would still be better
 then 100% G.711 or transcoding.








_____________

Roman Shpount




 




-------------------------------------------------------------------=
--


This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information
 by anyone other than the intended recipient is prohibited. If you have rec=
eived this transmission in error, please immediately reply to the sender an=
d delete this information from your system. Use, dissemination, distributio=
n, or reproduction of this transmission
 by unintended recipients is not authorized and may be unlawful. 




-------------------------------------------------------------------=
--


This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information
 by anyone other than the intended recipient is prohibited. If you have rec=
eived this transmission in error, please immediately reply to the sender an=
d delete this information from your system. Use, dissemination, distributio=
n, or reproduction of this transmission
 by unintended recipients is not authorized and may be unlawful. 








--_000_949EF20990823C4C85C18D59AA11AD8B014285FR712WXCHMBA11zeu_--

From jdrosen@jdrosen.net  Wed Mar 13 15:06: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 0A74421F89CB for ; Wed, 13 Mar 2013 15:06:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.976
X-Spam-Level: 
X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 5J-3Ch--hJ45 for ; Wed, 13 Mar 2013 15:06:49 -0700 (PDT)
Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [70.39.232.100]) by ietfa.amsl.com (Postfix) with ESMTP id D84DF21F85C0 for ; Wed, 13 Mar 2013 15:06:48 -0700 (PDT)
Received: from mail-we0-f173.google.com ([74.125.82.173]:42675) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1UFtot-0003Hn-T8 for rtcweb@ietf.org; Wed, 13 Mar 2013 18:06:48 -0400
Received: by mail-we0-f173.google.com with SMTP id x51so1497459wey.32 for ; Wed, 13 Mar 2013 15:06:47 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.110.136 with SMTP id ia8mr37413397wjb.58.1363212407432;  Wed, 13 Mar 2013 15:06:47 -0700 (PDT)
Received: by 10.194.109.161 with HTTP; Wed, 13 Mar 2013 15:06:47 -0700 (PDT)
Date: Wed, 13 Mar 2013 18:06:47 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7bf198444c7f5904d7d59f9a
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jdrosen.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Subject: [rtcweb] A different perspective on the video codec MTI 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, 13 Mar 2013 22:06:50 -0000

--047d7bf198444c7f5904d7d59f9a
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I=92d like to put a different perspective on the video MTI discussion.

Much of the discussion has been around video quality, IPR, and
standardization status. While those are all important factors, to me they
are secondary to the core question: how does the choice impact uptake of
the webRTC APIs and protocols by developers who build applications ontop of
it? In this regard, I would like to suggest that, at this time, adoption of
VP8 as MTI will slow down adoption of webRTC by turning off developers that
would otherwise embrace it if H.264 were selected.

The reason is simple. For many application developers, what is interesting
about webRTC is NOT just browser to browser communications, but connecting
users in a browser to users elsewhere - on other devices, in other
networks. After all, the vast majority of web application developers do not
have the luxury of a massive social graph, or the luxury of their users
being parked persistently on their website and thus able to receive an
incoming call. Many websites that have customer support or service needs
would love to be able to allow their users to have a video call with an
agent. However, those agents are probably sitting on existing agent systems
which are not web based, and it=92s almost certainly true that they do not
today support VP8, but rather H.264. Many developers would probably love to
connect users on the web with users on mobile apps. Most mobile platforms
today support H264 based hardware acceleration for decode and sometimes
encode, but not yet VP8. Developers who want to build business
communications clients will need to connect those users with other users in
the business, who may be using videophones, PC clients, telepresence units
or video room systems, the vast majority of which do not support VP8 today,
but many of which do support H.264.

The reality is =96 today=92s Internet and IP communications systems are bui=
lt
on H.264. And unless the developer cares only about living within the
island of the web browser =96 a VP8 based solution will simply not meet the=
ir
requirements.

This may not be true down the road. I applaud Google for working hard (and
spending much money no doubt) to secure an RF license for VP8 from these
patent holders. I think they should continue pushing and promoting the
technology because a  free, high quality video codec would be great for the
Internet. But today, it is not the video codec of the Internet. And, given
the relatively early days of video, I am sure there will be video codecs
after VP8. Maybe H.265, maybe the new video codec being developed here at
the IETF. And once those codecs become more broadly implemented and
available on the endpoints that matter, we can revise our specs and mandate
support for them. But this is not about the web of five years from now, its
about the web today. And if we mandate usage of a codec which is not widely
implemented in all the endpoints that matter (not just the browser), I fear
that it will hold developers back from using webRTC and thus prevent us
from ever having the opportunity to add these video codecs in the future.



And so =96 to the supporters of VP8 =96 I applaud your efforts and thank yo=
u
for them. Please continue. And when the industry is ready, we can make VP8
MTI in the browser. But we are not there yet.  I ask you to please put the
needs of the developers ahead of your own, and do not hold back webRTC for
the benefit of your ideals around an RF and open source video codec. WebRTC
is too important for that.

I have one more thing to say - speaking now as a developer.

As some of you may know, I recently returned to Cisco as CTO of the cloud
collaboration group, which is responsible for Webex. Webex was one of the
first services to do voice and video on the web, using plugins of course.
For our business, a key requirement is interoperability with other video
systems in the Cisco portfolio, including our video clients and
telepresence units. Those are all based on H.264. Consequently, much as I
would like to avoid the need for a plugin, the benefits of eliminating the
plugin do not outweigh the drawbacks of having to transcode from VP8 to
H.264. If IETF selects VP8 as the MTI codec, this will make it dramatically
more difficult and expensive for us to use webRTC. If H.264 is the MIT
codec, it will make it much easier for us to use webRTC.


Thx,

Jonathan R.
--=20
Jonathan Rosenberg, Ph.D.
jdrosen@jdrosen.net
http://www.jdrosen.net

--047d7bf198444c7f5904d7d59f9a
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


I=92d like to pu=
t a different
perspective on the video MTI discussion.



Much of the discussion has been
around video quality, IPR, and standardization status. While those are all
important factors, to me they are secondary to the core question: how does =
the
choice impact uptake of the webRTC APIs and protocols by developers who bui=
ld applications ontop of it? In this regard, I would like to suggest that, =
at this
time, adoption of VP8 as MTI will slow down adoption of webRTC by
turning off developers that would otherwise embrace it if H.264 were select=
ed.
The reason is simpl=
e. For many
application developers, what is interesting about webRTC is NOT just browse=
r to
browser communications, but connecting users in a browser to users elsewher=
e - on other devices, in other networks.
After all, the vast majority of web application developers do not have the
luxury of a massive social graph, or the luxury of their users being parked
persistently on their website and thus able to receive an incoming call. Ma=
ny websites
that have customer support or service needs would love to be able to allow
their users to have a video call with an agent. However, those agents are
probably sitting on existing agent systems which are not web based, and it=
=92s
almost certainly true that they do not today support VP8, but rather H.264.
Many developers would probably love to connect users on the web with users =
on
mobile apps. Most mobile platforms today support H264 based hardware accele=
ration
for decode and sometimes encode, but not yet VP8. Developers who want to bu=
ild
business communications clients will need to connect those users with other
users in the business, who may be using videophones, PC clients, telepresen=
ce
units or video room systems, the vast majority of which do not support VP8
today, but many of which do support H.264.



The reality is =96 today=92s Inte=
rnet
and IP communications systems are built on H.264. And unless the developer
cares only about living within the island of the web browser =96 a VP8 base=
d
solution will simply not meet their requirements.



This may not be true down the
road. I applaud Google for working hard (and spending much money no doubt) =
to
secure an RF license for VP8 from these patent holders. I think they should
continue pushing and promoting the technology because a=A0 free, high
quality video codec would be great for the Internet. But today, it is not t=
he
video codec of the Internet. And, given the relatively early days of video,=
 I
am sure there will be video codecs after VP8. Maybe H.265, maybe the new vi=
deo
codec being developed here at the IETF. And once those codecs become more
broadly implemented and available on the endpoints that matter, we can revi=
se
our specs and mandate support for them. But this is not about the web of fi=
ve
years from now, its about the web today. And if we mandate usage of a codec
which is not widely implemented in all the endpoints that matter (not just =
the browser), I fear that it
will hold developers back from using webRTC and thus prevent us from ever h=
aving
the opportunity to add these video codecs in the future.



=A0



And so =96 to the supporters of V=
P8
=96 I applaud your efforts and thank you for them. Please continue. And whe=
n the
industry is ready, we can make VP8 MTI in the browser. But we are not there=
 yet.
=A0I ask you to please put the needs of the developers ahead of your own,
and do not hold back webRTC for the benefit of your ideals around an RF and
open source video codec. WebRTC is too important for that.



I have one more thing to say - sp=
eaking now as a developer.



As some of you may know, I
recently returned to Cisco as CTO of the cloud collaboration group, which i=
s
responsible for Webex. Webex was one of the first services to do voice and
video on the web, using plugins of course. For our business, a key requirem=
ent
is interoperability with other video systems in the Cisco portfolio, includ=
ing
our video clients and telepresence units. Those are all based on H.264.
Consequently, much as I would like to avoid the need for a plugin, the bene=
fits
of eliminating the plugin do not outweigh the drawbacks of having to transc=
ode
from VP8 to H.264. If IETF selects VP8 as the MTI codec, this will make it =
dramatically more difficult and expensive for us to use webRTC. If H.264 is=
 the MIT codec, it will make it much easier for us to use webRTC.=A0=




Thx,
Jonathan R.
-- 




--047d7bf198444c7f5904d7d59f9a--

From stephane.proust@orange.com  Wed Mar 13 15:14: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 CE19121F8A0C for ; Wed, 13 Mar 2013 15:14:54 -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 7j2y2kSd6pWD for ; Wed, 13 Mar 2013 15:14:53 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4021221F894D for ; Wed, 13 Mar 2013 15:14:53 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id D727918CA16; Wed, 13 Mar 2013 23:14:51 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id BB5254C015; Wed, 13 Mar 2013 23:14:51 +0100 (CET)
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; Wed, 13 Mar 2013 23:14:49 +0100
From: 
To: "Markus.Isomaki@nokia.com" , "jmvalin@mozilla.com" 
Thread-Topic: [rtcweb] Agenda time request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOICImTLbKucX2J0SWwNOlz2HgepikFLeAgAAX6kA=
Date: Wed, 13 Mar 2013 22:14:43 +0000
Message-ID: <31611_1363212891_5140FA5B_31611_17197_1_35788a76-852d-49ce-8987-d2be2f21fcaf@PEXCVZYH02.corporate.adroot.infra.ftgroup>
References:    <5140D259.6010208@mozilla.com> <31611_1363203420_5140D55C_31611_11752_1_cb7bfd1e-a4ca-40ba-bbbc-cb23fb3f3edb@PEXCVZYH02.corporate.adroot.infra.ftgroup> 
In-Reply-To: 
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.13.192714
Cc: MARJOU Xavier OLNC/OLN , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Agenda time request	for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 22:14:54 -0000

Dear Markus

Thanks for your attempt to help !

Of course each Telco can handle this directly with vendors and browsers man=
ufacturers at business level. But I don't'think this need of interoperabili=
ty with mobile devices is specific to Orange. I think all mobile operators =
will have the same issue and this is why standardization exist. It's most c=
ost and time efficient to have one common way forward for all the industry.

Then if the issue is that "conditional MUST/SHOULD are a too complicated re=
quirement. We could also live as a compromise with a formulation that has a=
lready been suggested on the reflector:=20

"If other suitable audio codecs are available to the browser to use it is r=
ecommended that they are also included in the offer in order to maximize th=
e possibility to establish the session without the need for audio transcodi=
ng"
If possible with the addition of=20
This is especially the case for AMR, AMR-WB for interoperability with mobil=
e devices and G.722 for interoperability with fixed DECT CAT-iq devices

Would it have one chance to reach consensus ?

I think this Group should at least make one small step so that the interope=
rability issue with mobile terminals be not fully ignored in the RTC Web sp=
ecification considering the huge number of deployed devices. At least somet=
hing must be written on this ! G.711 which is the only codec in addition to=
 OPUS for interoperability purpose is not a proper answer to this.

St=E9phane

-----Message d'origine-----
De=A0: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]=20
Envoy=E9=A0: mercredi 13 mars 2013 22:37
=C0=A0: PROUST Stephane OLNC/OLPS; jmvalin@mozilla.com; MARJOU Xavier OLNC/=
OLN
Cc=A0: rtcweb@ietf.org
Objet=A0: RE: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-co=
decs-for-interop-01

Hi Stephane, Xavier,

I understand the intent of your proposal. I'm not sure if the IETF is the b=
est venue for you to pursue it, however. Perhaps you as a mobile operator s=
hould rather set it as a requirement to your mobile device platforms that t=
hey open up the APIs to AMR and AMR-WB and that at least the in-built defau=
lt browser needs to support it. If there are enough operators setting such =
requirements directly to the device and platform vendors, it probably has a=
 bigger impact than an IETF RFC. Getting that support for user-installed ad=
ditional browsers might be more difficult, but most mobile device users sti=
ck with the default browser anyway.

The RTCWEB codec document needs to definitely explain this case and the ben=
efits, but the conditional MUSTs or SHOULDs you are proposing are perhaps a=
 bit too complicated. Hmm, perhaps we need to do an _informational_ RFC as =
something like "Recommendations for WebRTC on Mobile Devices" addressing th=
e codec and perhaps other issues, that you could use as a reference in your=
 requirements.=20=20

Markus


>-----Original Message-----
>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20
>Behalf Of ext stephane.proust@orange.com
>Sent: 13 March, 2013 21:37
>To: Jean-Marc Valin; MARJOU Xavier OLNC/OLN
>Cc: rtcweb@ietf.org
>Subject: Re: [rtcweb] Agenda time request for=20
>draft-marjou-rtcweb-audio-
>codecs-for-interop-01
>
>Hello
>
>Our understanding is that the reason of the "no consensus" on=20
>additional recommended codecs was the additional costs for browsers.
>The proposal is then to make these "MUST" fully conditional to the case=20
>of no (or very reduced) additional costs, when the codecs are already=20
>available on the device and when no additional license fee is required
>
>We could even live with lower level of "requirements" with respectively=20
>May and Should (instead of Should and shall) but we think that this=20
>proposal is a way to take into account both browser manufacturers=20
>concerns on browsers costs and telcos concerns on transcoding costs and=20
>some other companies share this view.
>
>St=E9phane
>
>
>
>
>
>
>-----Message d'origine-----
>De=A0: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la=20
>part de Jean-Marc Valin Envoy=E9=A0: mercredi 13 mars 2013 20:24 =C0=A0: M=
ARJOU=20
>Xavier OLNC/OLN Cc=A0: rtcweb@ietf.org Objet=A0: Re: [rtcweb] Agenda time=
=20
>request for
>draft-marjou-rtcweb-audio-codecs-for-interop-01
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi,
>
>I'd really like to understand how the chairs coming to the conclusion=20
>that there was *no consensus* on recommended codecs can result in a=20
>draft that includes 3 MUSTs and 1 SHOULD. This draft effectively makes
>3 new codecs MTI for a range of devices. I understand that it's an=20
>individual draft and you can write whatever you like in there, but it=20
>definitely goes against the result of the WG discussion.
>
>Cheers,
>
>	Jean-Marc
>
>On 03/13/2013 09:14 AM, Xavier Marjou wrote:
>> Here is a summary of the
>> draft-marjou-rtcweb-audio-codecs-for-interop-00 presentation that I=20
>> had prepared for yesterday's session:
>>
>> - The co-authors want to underline that non-WebRTC voice endpoints=20
>> usually use one of the following codecs: AMR, AMR-WB or G.722, which=20
>> will result in massive transcoding when there will be communications=20
>> between WebRTC endpoints and non-WebRTC endpoints.
>>
>> - On one side, transcoding is bad for many reasons discussed in the=20
>> draft (cost issues, intrinsic quality degradation, degraded=20
>> interactivity, fallback from HD to G.711...);
>>
>> - On the other side, it is recognized that implementing additional=20
>> codecs in the browsers can generate additional costs.
>>
>> - In order to reach a compromise, we would like to add some text in=20
>> the WG draft draft-ietf-rtcweb-audio providing incentives for the=20
>> browser to use these three codecs: make them mandatory to implement=20
>> when there is no cost impact on the browser (e.g. if codec already=20
>> installed, paid by the device vendor...).
>>
>> Any opinion on that?
>>
>> Cheers,
>>
>> Xavier
>>
>> PS: I will be ready to present the slides on Thursday if time permits=20
>> it.
>>
>> (c.f. http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf
>> )
>>
>>
>>
>> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie > > wrote:
>>
>> Magnus and I discussed this this morning, and we encourage you to=20
>> prepare something.  If the discussion of working group last call=20
>> items runs short, we may be able to fit this in at that time or at=20
>> the end of day one if its full agenda his finished.  This is not a=20
>> commitment, however, so please try and get discussion on the list on=20
>> the points from the draft you feel need resolution.
>>
>> regards,
>>
>> Ted
>>
>>
>> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)=20
>> > wrote:
>>> Hello,
>>>
>>>
>>>
>>> I would like to request agenda time for:
>>>
>>>
>>>
>>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>>>
>>>
>>>
>>> The document  presents use-cases underlining why WebRTC needs
>> AMR-WB,  AMR
>>> and G.722 as additional relevant voice codecs to satisfactorily=20
>>> ensure interoperability with existing systems.
>>>
>>>
>>>
>>> A 10-minute time slot should be sufficient for presentation and
>> discussion.
>>>
>>>
>>>
>>> Regards
>>>
>>>
>>>
>>> -Espen
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________ rtcweb
>mailing list
>>> rtcweb@ietf.org =20
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>> _______________________________________________ rtcweb
>mailing list
>> rtcweb@ietf.org =20
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>>
>>
>> _______________________________________________ rtcweb
>mailing list
>> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.13 (GNU/Linux)
>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
>iQEcBAEBAgAGBQJRQNJZAAoJEJ6/8sItn9q9vNYIAL64nPUsZfKfxSYteqTQRPmg
>CzVXzr8GEBtR8gugL6KO5Lxgux+3fYKm7BJHirZyyCF1uPWIvXNevE2ad1KvHFwC
>yT9XlzgiiHX79SOEyd3bIn9thycBXBSAAiqyCkz5E/eEYskPFQ4e5AVDezjjvMGF
>L1Fx1PtsYuMRWEXZNB8wglH9sk3xeWe02o9s4TqLxwiseTS3CJ1kTwoHfIo5e4o
>X
>26NMjBBiEy/eKK9qtmry9Octjr93OgtFVavPoXN/sNqCW8u8kreVOSxeegJ233n9
>WQYhkctybnS22RTjbu3W6mZafpyOGi41rIzdGyUocmTelsFfT3hban5OU+1kQR
>w=3D
>=3DP8Jl
>-----END PGP SIGNATURE-----
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb
>
>___________________________________________________________
>___________________________________________________________
>___
>
>Ce message et ses pieces jointes peuvent contenir des informations=20
>confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
>exploites ou copies sans autorisation. Si vous avez recu ce message par=20
>erreur, veuillez le signaler a l'expediteur et le detruire ainsi que=20
>les pieces jointes. Les messages electroniques etant susceptibles=20
>d'alteration, France Telecom - Orange decline toute responsabilite si=20
>ce message a ete altere, deforme ou falsifie. Merci.
>
>This message and its attachments may contain confidential or privileged=20
>information that may be protected by law; they should not be=20
>distributed, used or copied without authorisation.
>If you have received this email in error, please notify the sender and=20
>delete this message and its attachments.
>As emails may be altered, France Telecom - Orange is not liable for=20
>messages that have been modified, changed or falsified.
>Thank you.
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.


From prvs=6784c58b3f=aallen@blackberry.com  Wed Mar 13 15:41: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 29E5311E8106 for ; Wed, 13 Mar 2013 15:41:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.329
X-Spam-Level: 
X-Spam-Status: No, score=-5.329 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 cORWeD8GvthE for ; Wed, 13 Mar 2013 15:41:13 -0700 (PDT)
Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 62A3311E80C5 for ; Wed, 13 Mar 2013 15:41:13 -0700 (PDT)
X-AuditID: 0a41282f-b7fa06d000002431-7e-5141007adb3f
Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) by mhs060cnc.rim.net (SBG) with SMTP id 09.B5.09265.B7001415; Wed, 13 Mar 2013 17:40:59 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 17:40:57 -0500
From: Andrew Allen 
To: "stephane.proust@orange.com" , "Markus.Isomaki@nokia.com" , "jmvalin@mozilla.com" 
Thread-Topic: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIDLmevmPLvBPykiIdbrUnYTPZpikg7+A//+zgew=
Date: Wed, 13 Mar 2013 22:40:57 +0000
Message-ID: 
In-Reply-To: <31611_1363212891_5140FA5B_31611_17197_1_35788a76-852d-49ce-8987-d2be2f21fcaf@PEXCVZYH02.corporate.adroot.infra.ftgroup>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.253]
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHKsWRmVeSWpSXmKPExsXC5ZyvpVvN4BhocOGglsX/qRwW5/8uYrNY +6+d3aJ1xhU2iyNb1zI7sHosWfKTyaPvQBerx91bl5g8Wp6dZAtgiWpgtElKLCkLzkzP07ez SczLyy9JLElVSEktTrZV8klNT8xRCCjKLEtMrlRwySxOzknMzE0tUlLITLFVMlFSKMhJTE7N Tc0rsVVKLChIzUtRsuNSwAA2QGWZeQqpecn5KZl56bZKnsH+uhYWppa6hkp2ugmdPBkdX46x FtyJq1je38jawNjl38XIySEhYCKx+3EvC4QtJnHh3nq2LkYuDiGBlYwS264/ZIdwNjNKvNvx lAmkik1AS2L/4elgtojAUkaJ/g1+IDazQIJEx6KlzCC2sEC8xOVtexkhahIk5mz6yQphW0ms fDORDcRmEVCVWPHxEFCcg4NXwEPi6T5bkF2cAq2MEkvfTwO7iFFAVmL32etMEPPFJW49mc8E camAxJI955khbFGJl4//sULYihJ/935nhajXk7gxdQobhK0tsWzha7B6XgFBiZMzn7BMYBSd hWTsLCQts5C0zELSsoCRZRWjYG5GsYGZQXJesl5RZq5eXmrJJkZQAnHU0N/B+Pa9xSFGAQ5G JR5e7ucOgUKsiWXFlbmHGCU4mJVEeO8+BgrxpiRWVqUW5ccXleakFh9idAWGxERmKe7kfGBy yyuJNzYwwM1REucVCRQNFBJIB6af7NTUgtQimDlMHJwge7ikRIqBSSS1KLG0JCMelOrii4HJ TqqB8eyBc0bnNiWlHHSICv4RGBi+7sP3hQ9ZHRjPsN9xqv7mtnGBhYasYlrOH85Dczf+4PM1 nMMwV/1dT6j2vus/6+ZyJ5506v2WslD/QMBh4UUZB+VkDvUKhzlyvD/Wu8Clgs2tYt3thle6 E3VeKAROeLh2le+59tsbL798em06q+OTQ4mTlO8FhiqxFGckGmoxFxUnAgCjUYc4YQMAAA==
Cc: "rtcweb@ietf.org" , "xavier.marjou@orange.com" 
Subject: Re: [rtcweb] Agenda time	request	for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 22:41:15 -0000

No this wouldn't be acceptable to me. 

I don't see a reason to push a particular set of Codecs over any other set o=
f codecs supported on the device. If the device supports the codecs and they=
 are available to the browser then we should recommend that they be offered=
 in the negotiation.

The marjou draft can advertise the merits and reasons why they are good code=
cs to support.


----- Original Message -----
From: stephane.proust@orange.com [mailto:stephane.proust@orange.com]
Sent: Wednesday, March 13, 2013 05:14 PM Central Standard Time=0A=
To: Markus.Isomaki@nokia.com ; jmvalin@mozilla.com=
 
Cc: MARJOU Xavier OLNC/OLN ; rtcweb@ietf.org 
Subject: Re: [rtcweb] Agenda time	request	for	draft-marjou-rtcweb-audio-code=
cs-for-interop-01

Dear Markus

Thanks for your attempt to help !

Of course each Telco can handle this directly with vendors and browsers manu=
facturers at business level. But I don't'think this need of interoperability=
 with mobile devices is specific to Orange. I think all mobile operators wil=
l have the same issue and this is why standardization exist. It's most cost=
 and time efficient to have one common way forward for all the industry.

Then if the issue is that "conditional MUST/SHOULD are a too complicated req=
uirement. We could also live as a compromise with a formulation that has alr=
eady been suggested on the reflector: 

"If other suitable audio codecs are available to the browser to use it is re=
commended that they are also included in the offer in order to maximize the=
 possibility to establish the session without the need for audio transcoding=
"
If possible with the addition of 
This is especially the case for AMR, AMR-WB for interoperability with mobile=
 devices and G.722 for interoperability with fixed DECT CAT-iq devices

Would it have one chance to reach consensus ?

I think this Group should at least make one small step so that the interoper=
ability issue with mobile terminals be not fully ignored in the RTC Web spec=
ification considering the huge number of deployed devices. At least somethin=
g must be written on this ! G.711 which is the only codec in addition to OPU=
S for interoperability purpose is not a proper answer to this.

St=E9phane

-----Message d'origine-----
De=A0: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] 
Envoy=E9=A0: mercredi 13 mars 2013 22:37
=C0=A0: PROUST Stephane OLNC/OLPS; jmvalin@mozilla.com; MARJOU Xavier OLNC/O=
LN
Cc=A0: rtcweb@ietf.org
Objet=A0: RE: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01

Hi Stephane, Xavier,

I understand the intent of your proposal. I'm not sure if the IETF is the be=
st venue for you to pursue it, however. Perhaps you as a mobile operator sho=
uld rather set it as a requirement to your mobile device platforms that they=
 open up the APIs to AMR and AMR-WB and that at least the in-built default b=
rowser needs to support it. If there are enough operators setting such requi=
rements directly to the device and platform vendors, it probably has a bigge=
r impact than an IETF RFC. Getting that support for user-installed additiona=
l browsers might be more difficult, but most mobile device users stick with=
 the default browser anyway.

The RTCWEB codec document needs to definitely explain this case and the bene=
fits, but the conditional MUSTs or SHOULDs you are proposing are perhaps a b=
it too complicated. Hmm, perhaps we need to do an _informational_ RFC as som=
ething like "Recommendations for WebRTC on Mobile Devices" addressing the co=
dec and perhaps other issues, that you could use as a reference in your requ=
irements.  

Markus


>-----Original Message-----
>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On 
>Behalf Of ext stephane.proust@orange.com
>Sent: 13 March, 2013 21:37
>To: Jean-Marc Valin; MARJOU Xavier OLNC/OLN
>Cc: rtcweb@ietf.org
>Subject: Re: [rtcweb] Agenda time request for 
>draft-marjou-rtcweb-audio-
>codecs-for-interop-01
>
>Hello
>
>Our understanding is that the reason of the "no consensus" on 
>additional recommended codecs was the additional costs for browsers.
>The proposal is then to make these "MUST" fully conditional to the case 
>of no (or very reduced) additional costs, when the codecs are already 
>available on the device and when no additional license fee is required
>
>We could even live with lower level of "requirements" with respectively 
>May and Should (instead of Should and shall) but we think that this 
>proposal is a way to take into account both browser manufacturers 
>concerns on browsers costs and telcos concerns on transcoding costs and 
>some other companies share this view.
>
>St=E9phane
>
>
>
>
>
>
>-----Message d'origine-----
>De=A0: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la 
>part de Jean-Marc Valin Envoy=E9=A0: mercredi 13 mars 2013 20:24 =C0=A0: MA=
RJOU 
>Xavier OLNC/OLN Cc=A0: rtcweb@ietf.org Objet=A0: Re: [rtcweb] Agenda time 
>request for
>draft-marjou-rtcweb-audio-codecs-for-interop-01
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi,
>
>I'd really like to understand how the chairs coming to the conclusion 
>that there was *no consensus* on recommended codecs can result in a 
>draft that includes 3 MUSTs and 1 SHOULD. This draft effectively makes
>3 new codecs MTI for a range of devices. I understand that it's an 
>individual draft and you can write whatever you like in there, but it 
>definitely goes against the result of the WG discussion.
>
>Cheers,
>
>	Jean-Marc
>
>On 03/13/2013 09:14 AM, Xavier Marjou wrote:
>> Here is a summary of the
>> draft-marjou-rtcweb-audio-codecs-for-interop-00 presentation that I 
>> had prepared for yesterday's session:
>>
>> - The co-authors want to underline that non-WebRTC voice endpoints 
>> usually use one of the following codecs: AMR, AMR-WB or G.722, which 
>> will result in massive transcoding when there will be communications 
>> between WebRTC endpoints and non-WebRTC endpoints.
>>
>> - On one side, transcoding is bad for many reasons discussed in the 
>> draft (cost issues, intrinsic quality degradation, degraded 
>> interactivity, fallback from HD to G.711...);
>>
>> - On the other side, it is recognized that implementing additional 
>> codecs in the browsers can generate additional costs.
>>
>> - In order to reach a compromise, we would like to add some text in 
>> the WG draft draft-ietf-rtcweb-audio providing incentives for the 
>> browser to use these three codecs: make them mandatory to implement 
>> when there is no cost impact on the browser (e.g. if codec already 
>> installed, paid by the device vendor...).
>>
>> Any opinion on that?
>>
>> Cheers,
>>
>> Xavier
>>
>> PS: I will be ready to present the slides on Thursday if time permits 
>> it.
>>
>> (c.f. http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf
>> )
>>
>>
>>
>> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie > > wrote:
>>
>> Magnus and I discussed this this morning, and we encourage you to 
>> prepare something.  If the discussion of working group last call 
>> items runs short, we may be able to fit this in at that time or at 
>> the end of day one if its full agenda his finished.  This is not a 
>> commitment, however, so please try and get discussion on the list on 
>> the points from the draft you feel need resolution.
>>
>> regards,
>>
>> Ted
>>
>>
>> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg) 
>> > wrote:
>>> Hello,
>>>
>>>
>>>
>>> I would like to request agenda time for:
>>>
>>>
>>>
>>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>>>
>>>
>>>
>>> The document  presents use-cases underlining why WebRTC needs
>> AMR-WB,  AMR
>>> and G.722 as additional relevant voice codecs to satisfactorily 
>>> ensure interoperability with existing systems.
>>>
>>>
>>>
>>> A 10-minute time slot should be sufficient for presentation and
>> discussion.
>>>
>>>
>>>
>>> Regards
>>>
>>>
>>>
>>> -Espen
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________ 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
>>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.13 (GNU/Linux)
>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
>iQEcBAEBAgAGBQJRQNJZAAoJEJ6/8sItn9q9vNYIAL64nPUsZfKfxSYteqTQRPmg
>CzVXzr8GEBtR8gugL6KO5Lxgux+3fYKm7BJHirZyyCF1uPWIvXNevE2ad1KvHFwC
>yT9XlzgiiHX79SOEyd3bIn9thycBXBSAAiqyCkz5E/eEYskPFQ4e5AVDezjjvMGF
>L1Fx1PtsYuMRWEXZNB8wglH9sk3xeWe02o9s4TqLxwiseTS3CJ1kTwoHfIo5e4o
>X
>26NMjBBiEy/eKK9qtmry9Octjr93OgtFVavPoXN/sNqCW8u8kreVOSxeegJ233n9
>WQYhkctybnS22RTjbu3W6mZafpyOGi41rIzdGyUocmTelsFfT3hban5OU+1kQR
>w=3D
>=3DP8Jl
>-----END PGP SIGNATURE-----
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb
>
>___________________________________________________________
>___________________________________________________________
>___
>
>Ce message et ses pieces jointes peuvent contenir des informations 
>confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
>exploites ou copies sans autorisation. Si vous avez recu ce message par 
>erreur, veuillez le signaler a l'expediteur et le detruire ainsi que 
>les pieces jointes. Les messages electroniques etant susceptibles 
>d'alteration, France Telecom - Orange decline toute responsabilite si 
>ce message a ete altere, deforme ou falsifie. Merci.
>
>This message and its attachments may contain confidential or privileged 
>information that may be protected by law; they should not be 
>distributed, used or copied without authorisation.
>If you have received this email in error, please notify the sender and 
>delete this message and its attachments.
>As emails may be altered, France Telecom - Orange is not liable for 
>messages that have been modified, changed or falsified.
>Thank you.
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb

____________________________________________________________________________=
_____________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages ele=
ctroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete alt=
ere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delet=
e this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages=
 that have been modified, changed or falsified.
Thank you.

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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From juberti@google.com  Wed Mar 13 15:41: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 2FF5E11E812C for ; Wed, 13 Mar 2013 15:41:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.676
X-Spam-Level: 
X-Spam-Status: No, score=-97.676 tagged_above=-999 required=5 tests=[AWL=-4.700, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, URIBL_WS_SURBL=10, 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 syeMJp6ebTEl for ; Wed, 13 Mar 2013 15:41:49 -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 B58BD21F84E6 for ; Wed, 13 Mar 2013 15:41:49 -0700 (PDT)
Received: by mail-qe0-f54.google.com with SMTP id i11so932641qej.13 for ; Wed, 13 Mar 2013 15:41:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=dQcMXy1KZ62ZjvwKSyjpDCVGdXqfA2x/qDjVCwQ6aDc=; b=ho7pGJqeJCPPRXt6fauv76tMX3ky170pIYXgf7gIJYjq9iyl1dVYITzEz6aXwaO593 JHSs9QcBCDp6OdVnQMC/q4t8+5MkYt2xsrwYT9nJ3VOdDWZMVg3scQfu5W3+gEb7Nl3X YpiL+b2xAibfCBAeB4GkhZhhcNWkuZqyrn/d+Hm7UqOSLerkxmCwjdAVW4ptOzyxKCtb c2RAOWJuJegX+QGBnfOT+zHJtdICxN6tR43d2zQgm+RvwoMZXF5VTTA2gSQv7jjuQkZd Oo5bEqBwf83gD8+wrwSCx+u3FjEnHKzf7yAbtzOZwMzhmE3MkbSp81ejBfKQ/qYBqnF5 Xh2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=dQcMXy1KZ62ZjvwKSyjpDCVGdXqfA2x/qDjVCwQ6aDc=; b=bPcBwucrmP67Pu8vdYMf0BAMNgP/ugCXyYlEHxsOCudX+l7eExYYpWmmyVPDTzKdXu OYqmmynmFoiKOrUpBMebVc/KkUpyTihoSYTuc072to6UlSc8WgjeNF48Ik6IxO7q8OBY yK/TXLNK0dh7/8hdfe9ju2cVXS/p97IsfZjlom7DVRHZUC7JaajgXyP5sbRQfmkyvg59 S2l/mh9xSYsKtMLTyxXcef8H8xLLnemgChvH3ZgdmcK+YZk2dh9LqlVAQSEId5sBDF22 Gkqw8gCI+FM/kbgU1P0+nkO1+QlTce/pDZ7adAqoStpaVesvLJ9ChzDA1TxR0yK2sidE XpBQ==
X-Received: by 10.229.135.207 with SMTP id o15mr45074qct.34.1363214508966; Wed, 13 Mar 2013 15:41:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.197.131 with HTTP; Wed, 13 Mar 2013 15:41:28 -0700 (PDT)
In-Reply-To: 
References: 
From: Justin Uberti 
Date: Wed, 13 Mar 2013 15:41:28 -0700
Message-ID: 
To: Jonathan Rosenberg 
Content-Type: multipart/alternative; boundary=00248c7690fe8f7c1b04d7d61c1c
X-Gm-Message-State: ALoCoQl7ER0TAnfyfP0Eo9ji1RNiaa+2gWEvySCtb5qOP8DIndf/RD7nJo1+qbFo3LUwzZCsqBduD+4Kxv30MGbf0mQCo4w4Y/YiVaBcxxZOVyqWiY1O0gS2qc3db5CljsMn6EQ//UHcTr1hVJhhNiVWOPkR7Bcc29DyRB8Yt8k8MaJsk4eHwvK30MMHOnIKVhzSoIABBV9W
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] A different perspective on the video codec MTI 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, 13 Mar 2013 22:41:51 -0000

--00248c7690fe8f7c1b04d7d61c1c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Regarding your comment on the "web today", I think it is worthwhile to
point out that within weeks, there will be 2B+ deployed WebRTC endpoints,
across desktop and mobile, that support VP8.

Surely that dwarfs the total number of deployed H.264 endpoints by several
orders of magnitude.


On Wed, Mar 13, 2013 at 3:06 PM, Jonathan Rosenberg wr=
ote:

> I=E2=80=99d like to put a different perspective on the video MTI discussi=
on.
>
> Much of the discussion has been around video quality, IPR, and
> standardization status. While those are all important factors, to me they
> are secondary to the core question: how does the choice impact uptake of
> the webRTC APIs and protocols by developers who build applications ontop =
of
> it? In this regard, I would like to suggest that, at this time, adoption =
of
> VP8 as MTI will slow down adoption of webRTC by turning off developers th=
at
> would otherwise embrace it if H.264 were selected.
>
> The reason is simple. For many application developers, what is interestin=
g
> about webRTC is NOT just browser to browser communications, but connectin=
g
> users in a browser to users elsewhere - on other devices, in other
> networks. After all, the vast majority of web application developers do n=
ot
> have the luxury of a massive social graph, or the luxury of their users
> being parked persistently on their website and thus able to receive an
> incoming call. Many websites that have customer support or service needs
> would love to be able to allow their users to have a video call with an
> agent. However, those agents are probably sitting on existing agent syste=
ms
> which are not web based, and it=E2=80=99s almost certainly true that they=
 do not
> today support VP8, but rather H.264. Many developers would probably love =
to
> connect users on the web with users on mobile apps. Most mobile platforms
> today support H264 based hardware acceleration for decode and sometimes
> encode, but not yet VP8. Developers who want to build business
> communications clients will need to connect those users with other users =
in
> the business, who may be using videophones, PC clients, telepresence unit=
s
> or video room systems, the vast majority of which do not support VP8 toda=
y,
> but many of which do support H.264.
>
> The reality is =E2=80=93 today=E2=80=99s Internet and IP communications s=
ystems are built
> on H.264. And unless the developer cares only about living within the
> island of the web browser =E2=80=93 a VP8 based solution will simply not =
meet their
> requirements.
>
> This may not be true down the road. I applaud Google for working hard (an=
d
> spending much money no doubt) to secure an RF license for VP8 from these
> patent holders. I think they should continue pushing and promoting the
> technology because a  free, high quality video codec would be great for t=
he
> Internet. But today, it is not the video codec of the Internet. And, give=
n
> the relatively early days of video, I am sure there will be video codecs
> after VP8. Maybe H.265, maybe the new video codec being developed here at
> the IETF. And once those codecs become more broadly implemented and
> available on the endpoints that matter, we can revise our specs and manda=
te
> support for them. But this is not about the web of five years from now, i=
ts
> about the web today. And if we mandate usage of a codec which is not wide=
ly
> implemented in all the endpoints that matter (not just the browser), I fe=
ar
> that it will hold developers back from using webRTC and thus prevent us
> from ever having the opportunity to add these video codecs in the future.
>
>
>
> And so =E2=80=93 to the supporters of VP8 =E2=80=93 I applaud your effort=
s and thank you
> for them. Please continue. And when the industry is ready, we can make VP=
8
> MTI in the browser. But we are not there yet.  I ask you to please put th=
e
> needs of the developers ahead of your own, and do not hold back webRTC fo=
r
> the benefit of your ideals around an RF and open source video codec. WebR=
TC
> is too important for that.
>
> I have one more thing to say - speaking now as a developer.
>
> As some of you may know, I recently returned to Cisco as CTO of the cloud
> collaboration group, which is responsible for Webex. Webex was one of the
> first services to do voice and video on the web, using plugins of course.
> For our business, a key requirement is interoperability with other video
> systems in the Cisco portfolio, including our video clients and
> telepresence units. Those are all based on H.264. Consequently, much as I
> would like to avoid the need for a plugin, the benefits of eliminating th=
e
> plugin do not outweigh the drawbacks of having to transcode from VP8 to
> H.264. If IETF selects VP8 as the MTI codec, this will make it dramatical=
ly
> more difficult and expensive for us to use webRTC. If H.264 is the MIT
> codec, it will make it much easier for us to use webRTC.
>
>
> Thx,
>
> Jonathan R.
> --
> Jonathan Rosenberg, Ph.D.
> jdrosen@jdrosen.net
> http://www.jdrosen.net
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--00248c7690fe8f7c1b04d7d61c1c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Regarding your comment on the "web today", I thi=
nk it is worthwhile to point out that within weeks, there will be 2B+ deplo=
yed WebRTC endpoints, across desktop and mobile, that support VP8.=C2=A0



Surely that dwarfs the total number of deployed H.264 endpoints =
by several orders of magnitude.



On Wed, Mar 1=
3, 2013 at 3:06 PM, Jonathan Rosenberg <jdrosen@jdrosen.net> wrote:




I=E2=80=99d like t=
o put a different
perspective on the video MTI discussion.



Much of the discussion has been
around video quality, IPR, and standardization status. While those are all
important factors, to me they are secondary to the core question: how does =
the
choice impact uptake of the webRTC APIs and protocols by developers who bui=
ld applications ontop of it? In this regard, I would like to suggest that, =
at this
time, adoption of VP8 as MTI will slow down adoption of webRTC by
turning off developers that would otherwise embrace it if H.264 were select=
ed.
The reason is simple. For many
application developers, what is interesting about webRTC is NOT just browse=
r to
browser communications, but connecting users in a browser to users elsewher=
e - on other devices, in other networks.
After all, the vast majority of web application developers do not have the
luxury of a massive social graph, or the luxury of their users being parked
persistently on their website and thus able to receive an incoming call. Ma=
ny websites
that have customer support or service needs would love to be able to allow
their users to have a video call with an agent. However, those agents are
probably sitting on existing agent systems which are not web based, and it=
=E2=80=99s
almost certainly true that they do not today support VP8, but rather H.264.
Many developers would probably love to connect users on the web with users =
on
mobile apps. Most mobile platforms today support H264 based hardware accele=
ration
for decode and sometimes encode, but not yet VP8. Developers who want to bu=
ild
business communications clients will need to connect those users with other
users in the business, who may be using videophones, PC clients, telepresen=
ce
units or video room systems, the vast majority of which do not support VP8
today, but many of which do support H.264.



The reality is =E2=80=93 today=E2=80=99s Internet
and IP communications systems are built on H.264. And unless the developer
cares only about living within the island of the web browser =E2=80=93 a VP=
8 based
solution will simply not meet their requirements.



This may not be true down the
road. I applaud Google for working hard (and spending much money no doubt) =
to
secure an RF license for VP8 from these patent holders. I think they should
continue pushing and promoting the technology because a=C2=A0 free, high
quality video codec would be great for the Internet. But today, it is not t=
he
video codec of the Internet. And, given the relatively early days of video,=
 I
am sure there will be video codecs after VP8. Maybe H.265, maybe the new vi=
deo
codec being developed here at the IETF. And once those codecs become more
broadly implemented and available on the endpoints that matter, we can revi=
se
our specs and mandate support for them. But this is not about the web of fi=
ve
years from now, its about the web today. And if we mandate usage of a codec
which is not widely implemented in all the endpoints that matter (not just =
the browser), I fear that it
will hold developers back from using webRTC and thus prevent us from ever h=
aving
the opportunity to add these video codecs in the future.



=C2=A0



And so =E2=80=93 to the supporters of VP8
=E2=80=93 I applaud your efforts and thank you for them. Please continue. A=
nd when the
industry is ready, we can make VP8 MTI in the browser. But we are not there=
 yet.
=C2=A0I ask you to please put the needs of the developers ahead of your own=
,
and do not hold back webRTC for the benefit of your ideals around an RF and
open source video codec. WebRTC is too important for that.



I have one more thing to say - speaking now as a developer.=




As some of you may know, I
recently returned to Cisco as CTO of the cloud collaboration group, which i=
s
responsible for Webex. Webex was one of the first services to do voice and
video on the web, using plugins of course. For our business, a key requirem=
ent
is interoperability with other video systems in the Cisco portfolio, includ=
ing
our video clients and telepresence units. Those are all based on H.264.
Consequently, much as I would like to avoid the need for a plugin, the bene=
fits
of eliminating the plugin do not outweigh the drawbacks of having to transc=
ode
from VP8 to H.264. If IETF selects VP8 as the MTI codec, this will make it =
dramatically more difficult and expensive for us to use webRTC. If H.264 is=
 the MIT codec, it will make it much easier for us to use webRTC.=C2=A0






Thx,
Jonathan R.=

-- 




_______________________________________________

rtcweb mailing list

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





--00248c7690fe8f7c1b04d7d61c1c--

From magnus.westerlund@ericsson.com  Wed Mar 13 15:46: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 1AA5621F8712 for ; Wed, 13 Mar 2013 15:46:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.205
X-Spam-Level: 
X-Spam-Status: No, score=-106.205 tagged_above=-999 required=5 tests=[AWL=0.044, 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 OzYMxUAvptHc for ; Wed, 13 Mar 2013 15:46:50 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2568021F865D for ; Wed, 13 Mar 2013 15:46:49 -0700 (PDT)
X-AuditID: c1b4fb30-b7f0d6d000007e61-f6-514101d97d03
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id AE.03.32353.9D101415; Wed, 13 Mar 2013 23:46:49 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Wed, 13 Mar 2013 23:46:48 +0100
Message-ID: <514101D6.50301@ericsson.com>
Date: Wed, 13 Mar 2013 18:46:46 -0400
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Erik Lagerway 
References: <513F9011.4040900@ericsson.com> <513F997B.50807@nostrum.com> <513F9B90.4090802@ericsson.com> 
In-Reply-To: 
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprELMWRmVeSWpSXmKPExsUyM+Jvje5NRsdAg3mnRSzO3/zNbLH2Xzu7 A5PH+a1LmDyWLPnJFMAUxWWTkpqTWZZapG+XwJWxe/oipoKvrBUPj65jaWD8wtLFyMkhIWAi Me/JanYIW0ziwr31bF2MXBxCAicZJa53bmGEcJYzShz+9R+sg1dAU+Ln/DZmEJtFQFWi4dRa JhCbTcBC4uaPRjYQW1QgWOLnqzNQ9YISJ2c+AbNFBNQkjv/8ANbLLCAsseFiG1hcWMBcYv68 tSwQy9YySsyc3ANWxCkQKHFlxX0miPMkJba8aGeHaNaTmHK1hRHClpdo3jobrF5IQFuioamD dQKj0Cwku2chaZmFpGUBI/MqRvbcxMyc9HLzTYzAcD245bfBDsZN98UOMUpzsCiJ84a7XggQ EkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwLjjpuvKms/zlE025S5StZqj4hmenqer3b95Wt7P Vac+2x14+4Kj5fnT4w8maCx13xFsyS43nevhgv+vp3trhfe+2nTvWQ/DrifLXi9+ZHa/rUIr RKbyr/JOh+TaP45cH1nV730omm7y7HLR3s928zpYDDUi2DrPmua7iPxSvbdzdWDG6WanVVZK LMUZiYZazEXFiQBbJKWuJQIAAA==
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Datachannel adoption confirmation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 22:46:51 -0000

On 2013-03-12 18:08, Erik Lagerway wrote:
> As a remote participant, not sure if I was considered as contributing
> member in that meeting, I did hum for draft-jesup-rtcweb-data-protocol-04.

I did capture some positions in the jabber room, but thanks for the
clarification.

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 stephane.proust@orange.com  Wed Mar 13 15:48: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 7AB6911E8122 for ; Wed, 13 Mar 2013 15:48:13 -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=[AWL=-0.000, 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 AWvHl3Hcf18R for ; Wed, 13 Mar 2013 15:48:12 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 883FD21F8994 for ; Wed, 13 Mar 2013 15:48:11 -0700 (PDT)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id BE64A324290; Wed, 13 Mar 2013 23:48:10 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 9FA1D27C046; Wed, 13 Mar 2013 23:48:10 +0100 (CET)
Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 23:48:08 +0100
From: 
To: Andrew Allen , "Markus.Isomaki@nokia.com" , "jmvalin@mozilla.com" 
Thread-Topic: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIDg15JwC6oe0uUmvMr2j8KRIXJikJnOAgAASLtA=
Date: Wed, 13 Mar 2013 22:48:01 +0000
Message-ID: <3246_1363214890_5141022A_3246_1976_1_34a49fde-fad7-4a0a-8b01-9d48a5b6eeab@PEXCVZYH01.corporate.adroot.infra.ftgroup>
References: <31611_1363212891_5140FA5B_31611_17197_1_35788a76-852d-49ce-8987-d2be2f21fcaf@PEXCVZYH02.corporate.adroot.infra.ftgroup> 
In-Reply-To: 
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.5.94520
Cc: "rtcweb@ietf.org" , MARJOU Xavier OLNC/OLN 
Subject: Re: [rtcweb] Agenda time	request	for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 22:48:13 -0000

The reason is simply that AMR and AMR-WB are supported in billions of devic=
es !

St=E9phane


-----Message d'origine-----
De=A0: Andrew Allen [mailto:aallen@blackberry.com]=20
Envoy=E9=A0: mercredi 13 mars 2013 23:41
=C0=A0: PROUST Stephane OLNC/OLPS; Markus.Isomaki@nokia.com; jmvalin@mozill=
a.com
Cc=A0: MARJOU Xavier OLNC/OLN; rtcweb@ietf.org
Objet=A0: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-co=
decs-for-interop-01


No this wouldn't be acceptable to me.=20

I don't see a reason to push a particular set of Codecs over any other set =
of codecs supported on the device. If the device supports the codecs and th=
ey are available to the browser then we should recommend that they be offer=
ed in the negotiation.

The marjou draft can advertise the merits and reasons why they are good cod=
ecs to support.


----- Original Message -----
From: stephane.proust@orange.com [mailto:stephane.proust@orange.com]
Sent: Wednesday, March 13, 2013 05:14 PM Central Standard Time
To: Markus.Isomaki@nokia.com ; jmvalin@mozilla.co=
m 
Cc: MARJOU Xavier OLNC/OLN ; rtcweb@ietf.org 
Subject: Re: [rtcweb] Agenda time	request	for	draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01

Dear Markus

Thanks for your attempt to help !

Of course each Telco can handle this directly with vendors and browsers man=
ufacturers at business level. But I don't'think this need of interoperabili=
ty with mobile devices is specific to Orange. I think all mobile operators =
will have the same issue and this is why standardization exist. It's most c=
ost and time efficient to have one common way forward for all the industry.

Then if the issue is that "conditional MUST/SHOULD are a too complicated re=
quirement. We could also live as a compromise with a formulation that has a=
lready been suggested on the reflector:=20

"If other suitable audio codecs are available to the browser to use it is r=
ecommended that they are also included in the offer in order to maximize th=
e possibility to establish the session without the need for audio transcodi=
ng"
If possible with the addition of
This is especially the case for AMR, AMR-WB for interoperability with mobil=
e devices and G.722 for interoperability with fixed DECT CAT-iq devices

Would it have one chance to reach consensus ?

I think this Group should at least make one small step so that the interope=
rability issue with mobile terminals be not fully ignored in the RTC Web sp=
ecification considering the huge number of deployed devices. At least somet=
hing must be written on this ! G.711 which is the only codec in addition to=
 OPUS for interoperability purpose is not a proper answer to this.

St=E9phane

-----Message d'origine-----
De=A0: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] Envoy=E9=
=A0: mercredi 13 mars 2013 22:37 =C0=A0: PROUST Stephane OLNC/OLPS; jmvalin=
@mozilla.com; MARJOU Xavier OLNC/OLN Cc=A0: rtcweb@ietf.org Objet=A0: RE: [=
rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-intero=
p-01

Hi Stephane, Xavier,

I understand the intent of your proposal. I'm not sure if the IETF is the b=
est venue for you to pursue it, however. Perhaps you as a mobile operator s=
hould rather set it as a requirement to your mobile device platforms that t=
hey open up the APIs to AMR and AMR-WB and that at least the in-built defau=
lt browser needs to support it. If there are enough operators setting such =
requirements directly to the device and platform vendors, it probably has a=
 bigger impact than an IETF RFC. Getting that support for user-installed ad=
ditional browsers might be more difficult, but most mobile device users sti=
ck with the default browser anyway.

The RTCWEB codec document needs to definitely explain this case and the ben=
efits, but the conditional MUSTs or SHOULDs you are proposing are perhaps a=
 bit too complicated. Hmm, perhaps we need to do an _informational_ RFC as =
something like "Recommendations for WebRTC on Mobile Devices" addressing th=
e codec and perhaps other issues, that you could use as a reference in your=
 requirements.=20=20

Markus


>-----Original Message-----
>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20
>Behalf Of ext stephane.proust@orange.com
>Sent: 13 March, 2013 21:37
>To: Jean-Marc Valin; MARJOU Xavier OLNC/OLN
>Cc: rtcweb@ietf.org
>Subject: Re: [rtcweb] Agenda time request for
>draft-marjou-rtcweb-audio-
>codecs-for-interop-01
>
>Hello
>
>Our understanding is that the reason of the "no consensus" on=20
>additional recommended codecs was the additional costs for browsers.
>The proposal is then to make these "MUST" fully conditional to the case=20
>of no (or very reduced) additional costs, when the codecs are already=20
>available on the device and when no additional license fee is required
>
>We could even live with lower level of "requirements" with respectively=20
>May and Should (instead of Should and shall) but we think that this=20
>proposal is a way to take into account both browser manufacturers=20
>concerns on browsers costs and telcos concerns on transcoding costs and=20
>some other companies share this view.
>
>St=E9phane
>
>
>
>
>
>
>-----Message d'origine-----
>De=A0: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la=20
>part de Jean-Marc Valin Envoy=E9=A0: mercredi 13 mars 2013 20:24 =C0=A0: M=
ARJOU=20
>Xavier OLNC/OLN Cc=A0: rtcweb@ietf.org Objet=A0: Re: [rtcweb] Agenda time=
=20
>request for
>draft-marjou-rtcweb-audio-codecs-for-interop-01
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi,
>
>I'd really like to understand how the chairs coming to the conclusion=20
>that there was *no consensus* on recommended codecs can result in a=20
>draft that includes 3 MUSTs and 1 SHOULD. This draft effectively makes
>3 new codecs MTI for a range of devices. I understand that it's an=20
>individual draft and you can write whatever you like in there, but it=20
>definitely goes against the result of the WG discussion.
>
>Cheers,
>
>	Jean-Marc
>
>On 03/13/2013 09:14 AM, Xavier Marjou wrote:
>> Here is a summary of the
>> draft-marjou-rtcweb-audio-codecs-for-interop-00 presentation that I=20
>> had prepared for yesterday's session:
>>
>> - The co-authors want to underline that non-WebRTC voice endpoints=20
>> usually use one of the following codecs: AMR, AMR-WB or G.722, which=20
>> will result in massive transcoding when there will be communications=20
>> between WebRTC endpoints and non-WebRTC endpoints.
>>
>> - On one side, transcoding is bad for many reasons discussed in the=20
>> draft (cost issues, intrinsic quality degradation, degraded=20
>> interactivity, fallback from HD to G.711...);
>>
>> - On the other side, it is recognized that implementing additional=20
>> codecs in the browsers can generate additional costs.
>>
>> - In order to reach a compromise, we would like to add some text in=20
>> the WG draft draft-ietf-rtcweb-audio providing incentives for the=20
>> browser to use these three codecs: make them mandatory to implement=20
>> when there is no cost impact on the browser (e.g. if codec already=20
>> installed, paid by the device vendor...).
>>
>> Any opinion on that?
>>
>> Cheers,
>>
>> Xavier
>>
>> PS: I will be ready to present the slides on Thursday if time permits=20
>> it.
>>
>> (c.f. http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf
>> )
>>
>>
>>
>> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie > > wrote:
>>
>> Magnus and I discussed this this morning, and we encourage you to=20
>> prepare something.  If the discussion of working group last call=20
>> items runs short, we may be able to fit this in at that time or at=20
>> the end of day one if its full agenda his finished.  This is not a=20
>> commitment, however, so please try and get discussion on the list on=20
>> the points from the draft you feel need resolution.
>>
>> regards,
>>
>> Ted
>>
>>
>> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)=20
>> > wrote:
>>> Hello,
>>>
>>>
>>>
>>> I would like to request agenda time for:
>>>
>>>
>>>
>>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>>>
>>>
>>>
>>> The document  presents use-cases underlining why WebRTC needs
>> AMR-WB,  AMR
>>> and G.722 as additional relevant voice codecs to satisfactorily=20
>>> ensure interoperability with existing systems.
>>>
>>>
>>>
>>> A 10-minute time slot should be sufficient for presentation and
>> discussion.
>>>
>>>
>>>
>>> Regards
>>>
>>>
>>>
>>> -Espen
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________ rtcweb
>mailing list
>>> rtcweb@ietf.org =20
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>> _______________________________________________ rtcweb
>mailing list
>> rtcweb@ietf.org =20
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>>
>>
>> _______________________________________________ rtcweb
>mailing list
>> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.13 (GNU/Linux)
>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
>iQEcBAEBAgAGBQJRQNJZAAoJEJ6/8sItn9q9vNYIAL64nPUsZfKfxSYteqTQRPmg
>CzVXzr8GEBtR8gugL6KO5Lxgux+3fYKm7BJHirZyyCF1uPWIvXNevE2ad1KvHFwC
>yT9XlzgiiHX79SOEyd3bIn9thycBXBSAAiqyCkz5E/eEYskPFQ4e5AVDezjjvMGF
>L1Fx1PtsYuMRWEXZNB8wglH9sk3xeWe02o9s4TqLxwiseTS3CJ1kTwoHfIo5e4o
>X
>26NMjBBiEy/eKK9qtmry9Octjr93OgtFVavPoXN/sNqCW8u8kreVOSxeegJ233n9
>WQYhkctybnS22RTjbu3W6mZafpyOGi41rIzdGyUocmTelsFfT3hban5OU+1kQR
>w=3D
>=3DP8Jl
>-----END PGP SIGNATURE-----
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb
>
>___________________________________________________________
>___________________________________________________________
>___
>
>Ce message et ses pieces jointes peuvent contenir des informations=20
>confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
>exploites ou copies sans autorisation. Si vous avez recu ce message par=20
>erreur, veuillez le signaler a l'expediteur et le detruire ainsi que=20
>les pieces jointes. Les messages electroniques etant susceptibles=20
>d'alteration, France Telecom - Orange decline toute responsabilite si=20
>ce message a ete altere, deforme ou falsifie. Merci.
>
>This message and its attachments may contain confidential or privileged=20
>information that may be protected by law; they should not be=20
>distributed, used or copied without authorisation.
>If you have received this email in error, please notify the sender and=20
>delete this message and its attachments.
>As emails may be altered, France Telecom - Orange is not liable for=20
>messages that have been modified, changed or falsified.
>Thank you.
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou =
copies sans autorisation. Si vous avez recu ce message par erreur, veuillez=
 le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le=
s messages electroniques etant susceptibles d'alteration, France Telecom - =
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law; they should not be distributed, used=
 or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.

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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.


From silviapfeiffer1@gmail.com  Wed Mar 13 15: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 62A8721F8540 for ; Wed, 13 Mar 2013 15:54:37 -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 4tEh09hAGXv2 for ; Wed, 13 Mar 2013 15:54:36 -0700 (PDT)
Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id 9005121F84EF for ; Wed, 13 Mar 2013 15:54:35 -0700 (PDT)
Received: by mail-lb0-f179.google.com with SMTP id j14so1363920lbo.24 for ; Wed, 13 Mar 2013 15:54:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=dms589hww9HbtVd0t2y6OTpFIJTuTqxzj8hqJ4l2bVU=; b=AH+BP6c3M/ZigdTTsm1Hz2gFK5dFlH7jcWiSM8WTJE7GSm7IB6rpUhhkgkiRaWD1ZK 7+shXnwUxkVw6W8+hqtKRmwMQMkwqiV1PbAM+hFDm5KHI03I/O4rOHNydhZN76AxiTeo s1twIcr+5HjY5YMhQbsMaB2kPMOkWyAYeA2XLgifnCFbeYQ3JvjSdQlmBtI/QG2dCV/S aYGbpEgH/QOHjdIUyWUeBzQyavocz5iPbl55gcqNpw6SzkY5H8TeRlEY8QN9sy6pZZhs lmpA9w1pNpjixC45s5fF72FNJ459lN7WppciHSPw+VNxbvYJ+DltrwlkBuT3MxL18ni1 5zpQ==
MIME-Version: 1.0
X-Received: by 10.112.23.232 with SMTP id p8mr260399lbf.38.1363215274465; Wed, 13 Mar 2013 15:54:34 -0700 (PDT)
Received: by 10.112.128.201 with HTTP; Wed, 13 Mar 2013 15:54:33 -0700 (PDT)
Received: by 10.112.128.201 with HTTP; Wed, 13 Mar 2013 15:54:33 -0700 (PDT)
In-Reply-To: 
References:  
Date: Thu, 14 Mar 2013 09:54:33 +1100
Message-ID: 
From: Silvia Pfeiffer 
To: Justin Uberti 
Content-Type: multipart/alternative; boundary=e0cb4efe2d842fe52004d7d64a9e
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] A different perspective on the video codec MTI 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, 13 Mar 2013 22:54:37 -0000

--e0cb4efe2d842fe52004d7d64a9e
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Also, it is worth pointing out that h.264 cannot meet the RF requirements
of W3C, so the only alternatives we can look at are VP8 or delaying the
decision for an MTI until the market decides.

I'd rather we specify for an environment 5 years down the track (and give
companies like CISCO a reason to replace all their old devices with new
ones that support VP8) than continuing decision avoidance.

Regards,
Silvia.
(Speaking for myself)
On 14 Mar 2013 09:42, "Justin Uberti"  wrote:

> Regarding your comment on the "web today", I think it is worthwhile to
> point out that within weeks, there will be 2B+ deployed WebRTC endpoints,
> across desktop and mobile, that support VP8.
>
> Surely that dwarfs the total number of deployed H.264 endpoints by severa=
l
> orders of magnitude.
>
>
> On Wed, Mar 13, 2013 at 3:06 PM, Jonathan Rosenberg =
wrote:
>
>> I=92d like to put a different perspective on the video MTI discussion.
>>
>> Much of the discussion has been around video quality, IPR, and
>> standardization status. While those are all important factors, to me the=
y
>> are secondary to the core question: how does the choice impact uptake of
>> the webRTC APIs and protocols by developers who build applications ontop=
 of
>> it? In this regard, I would like to suggest that, at this time, adoption=
 of
>> VP8 as MTI will slow down adoption of webRTC by turning off developers t=
hat
>> would otherwise embrace it if H.264 were selected.
>>
>> The reason is simple. For many application developers, what is
>> interesting about webRTC is NOT just browser to browser communications, =
but
>> connecting users in a browser to users elsewhere - on other devices, in
>> other networks. After all, the vast majority of web application develope=
rs
>> do not have the luxury of a massive social graph, or the luxury of their
>> users being parked persistently on their website and thus able to receiv=
e
>> an incoming call. Many websites that have customer support or service ne=
eds
>> would love to be able to allow their users to have a video call with an
>> agent. However, those agents are probably sitting on existing agent syst=
ems
>> which are not web based, and it=92s almost certainly true that they do n=
ot
>> today support VP8, but rather H.264. Many developers would probably love=
 to
>> connect users on the web with users on mobile apps. Most mobile platform=
s
>> today support H264 based hardware acceleration for decode and sometimes
>> encode, but not yet VP8. Developers who want to build business
>> communications clients will need to connect those users with other users=
 in
>> the business, who may be using videophones, PC clients, telepresence uni=
ts
>> or video room systems, the vast majority of which do not support VP8 tod=
ay,
>> but many of which do support H.264.
>>
>> The reality is =96 today=92s Internet and IP communications systems are =
built
>> on H.264. And unless the developer cares only about living within the
>> island of the web browser =96 a VP8 based solution will simply not meet =
their
>> requirements.
>>
>> This may not be true down the road. I applaud Google for working hard
>> (and spending much money no doubt) to secure an RF license for VP8 from
>> these patent holders. I think they should continue pushing and promoting
>> the technology because a  free, high quality video codec would be great =
for
>> the Internet. But today, it is not the video codec of the Internet. And,
>> given the relatively early days of video, I am sure there will be video
>> codecs after VP8. Maybe H.265, maybe the new video codec being developed
>> here at the IETF. And once those codecs become more broadly implemented =
and
>> available on the endpoints that matter, we can revise our specs and mand=
ate
>> support for them. But this is not about the web of five years from now, =
its
>> about the web today. And if we mandate usage of a codec which is not wid=
ely
>> implemented in all the endpoints that matter (not just the browser), I f=
ear
>> that it will hold developers back from using webRTC and thus prevent us
>> from ever having the opportunity to add these video codecs in the future=
.
>>
>>
>>
>> And so =96 to the supporters of VP8 =96 I applaud your efforts and thank=
 you
>> for them. Please continue. And when the industry is ready, we can make V=
P8
>> MTI in the browser. But we are not there yet.  I ask you to please put t=
he
>> needs of the developers ahead of your own, and do not hold back webRTC f=
or
>> the benefit of your ideals around an RF and open source video codec. Web=
RTC
>> is too important for that.
>>
>> I have one more thing to say - speaking now as a developer.
>>
>> As some of you may know, I recently returned to Cisco as CTO of the clou=
d
>> collaboration group, which is responsible for Webex. Webex was one of th=
e
>> first services to do voice and video on the web, using plugins of course=
.
>> For our business, a key requirement is interoperability with other video
>> systems in the Cisco portfolio, including our video clients and
>> telepresence units. Those are all based on H.264. Consequently, much as =
I
>> would like to avoid the need for a plugin, the benefits of eliminating t=
he
>> plugin do not outweigh the drawbacks of having to transcode from VP8 to
>> H.264. If IETF selects VP8 as the MTI codec, this will make it dramatica=
lly
>> more difficult and expensive for us to use webRTC. If H.264 is the MIT
>> codec, it will make it much easier for us to use webRTC.
>>
>>
>> Thx,
>>
>> Jonathan R.
>> --
>> Jonathan Rosenberg, Ph.D.
>> jdrosen@jdrosen.net
>> http://www.jdrosen.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
>
>

--e0cb4efe2d842fe52004d7d64a9e
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


Also, it is worth pointing out that h.264 cannot meet the RF=
 requirements of W3C, so the only alternatives we can look at are VP8 or de=
laying the decision for an MTI until the market decides. 


I'd rather we specify for an environment 5 years down th=
e track (and give companies like CISCO a reason to replace all their old de=
vices with new ones that support VP8) than continuing decision avoidance.


Regards,

Silvia.

(Speaking for myself)


On 14 Mar 2013 09:42, "Justin Uberti" =
<juberti@google.com> wrote:=



Regarding your comment on the "web today", I thi=
nk it is worthwhile to point out that within weeks, there will be 2B+ deplo=
yed WebRTC endpoints, across desktop and mobile, that support VP8.=A0
<=
br>



Surely that dwarfs the total number of deployed H.264 endpoints =
by several orders of magnitude.



On Wed, Mar 1=
3, 2013 at 3:06 PM, Jonathan Rosenberg <jdrosen@jdrosen.net> wrote:





I=92d like to put =
a different
perspective on the video MTI discussion.



Much of the discussion has been
around video quality, IPR, and standardization status. While those are all
important factors, to me they are secondary to the core question: how does =
the
choice impact uptake of the webRTC APIs and protocols by developers who bui=
ld applications ontop of it? In this regard, I would like to suggest that, =
at this
time, adoption of VP8 as MTI will slow down adoption of webRTC by
turning off developers that would otherwise embrace it if H.264 were select=
ed.
The reason is simple. For many
application developers, what is interesting about webRTC is NOT just browse=
r to
browser communications, but connecting users in a browser to users elsewher=
e - on other devices, in other networks.
After all, the vast majority of web application developers do not have the
luxury of a massive social graph, or the luxury of their users being parked
persistently on their website and thus able to receive an incoming call. Ma=
ny websites
that have customer support or service needs would love to be able to allow
their users to have a video call with an agent. However, those agents are
probably sitting on existing agent systems which are not web based, and it=
=92s
almost certainly true that they do not today support VP8, but rather H.264.
Many developers would probably love to connect users on the web with users =
on
mobile apps. Most mobile platforms today support H264 based hardware accele=
ration
for decode and sometimes encode, but not yet VP8. Developers who want to bu=
ild
business communications clients will need to connect those users with other
users in the business, who may be using videophones, PC clients, telepresen=
ce
units or video room systems, the vast majority of which do not support VP8
today, but many of which do support H.264.



The reality is =96 today=92s Internet
and IP communications systems are built on H.264. And unless the developer
cares only about living within the island of the web browser =96 a VP8 base=
d
solution will simply not meet their requirements.



This may not be true down the
road. I applaud Google for working hard (and spending much money no doubt) =
to
secure an RF license for VP8 from these patent holders. I think they should
continue pushing and promoting the technology because a=A0 free, high
quality video codec would be great for the Internet. But today, it is not t=
he
video codec of the Internet. And, given the relatively early days of video,=
 I
am sure there will be video codecs after VP8. Maybe H.265, maybe the new vi=
deo
codec being developed here at the IETF. And once those codecs become more
broadly implemented and available on the endpoints that matter, we can revi=
se
our specs and mandate support for them. But this is not about the web of fi=
ve
years from now, its about the web today. And if we mandate usage of a codec
which is not widely implemented in all the endpoints that matter (not just =
the browser), I fear that it
will hold developers back from using webRTC and thus prevent us from ever h=
aving
the opportunity to add these video codecs in the future.



=A0



And so =96 to the supporters of VP8
=96 I applaud your efforts and thank you for them. Please continue. And whe=
n the
industry is ready, we can make VP8 MTI in the browser. But we are not there=
 yet.
=A0I ask you to please put the needs of the developers ahead of your own,
and do not hold back webRTC for the benefit of your ideals around an RF and
open source video codec. WebRTC is too important for that.



I have one more thing to say - speaking now as a developer.=




As some of you may know, I
recently returned to Cisco as CTO of the cloud collaboration group, which i=
s
responsible for Webex. Webex was one of the first services to do voice and
video on the web, using plugins of course. For our business, a key requirem=
ent
is interoperability with other video systems in the Cisco portfolio, includ=
ing
our video clients and telepresence units. Those are all based on H.264.
Consequently, much as I would like to avoid the need for a plugin, the bene=
fits
of eliminating the plugin do not outweigh the drawbacks of having to transc=
ode
from VP8 to H.264. If IETF selects VP8 as the MTI codec, this will make it =
dramatically more difficult and expensive for us to use webRTC. If H.264 is=
 the MIT codec, it will make it much easier for us to use webRTC.=A0=








Thx,
Jonathan R.=

-- 




_______________________________________________

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




--e0cb4efe2d842fe52004d7d64a9e--

From prvs=9784c6078a=aallen@blackberry.com  Wed Mar 13 16:01: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 612E021F8A43 for ; Wed, 13 Mar 2013 16:01:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.512
X-Spam-Level: 
X-Spam-Status: No, score=-4.512 tagged_above=-999 required=5 tests=[AWL=-0.933, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_SHOULD=1.624]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewG2CiZkBo+6 for ; Wed, 13 Mar 2013 16:00:57 -0700 (PDT)
Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 0829E21F8A40 for ; Wed, 13 Mar 2013 16:00:56 -0700 (PDT)
X-AuditID: 0a41282f-b7fa06d000002431-20-514105277c6e
Received: from XCT103ADS.rim.net (xct103ads.rim.net [10.67.111.44]) by mhs060cnc.rim.net (SBG) with SMTP id 1E.F5.09265.72501415; Wed, 13 Mar 2013 18:00:56 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT103ADS.rim.net ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 18:00:54 -0500
From: Andrew Allen 
To: "stephane.proust@orange.com" , "Markus.Isomaki@nokia.com" , "jmvalin@mozilla.com" 
Thread-Topic: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIDLmevmPLvBPykiIdbrUnYTPZpikg7+A//+zgeyAAFXNgP//r8Zg
Date: Wed, 13 Mar 2013 23:00:54 +0000
Message-ID: 
In-Reply-To: <3246_1363214890_5141022A_3246_1976_1_34a49fde-fad7-4a0a-8b01-9d48a5b6eeab@PEXCVZYH01.corporate.adroot.infra.ftgroup>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.253]
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHKsWRmVeSWpSXmKPExsXC5Zyvo6vB6hho0LyLxeL/VA6L838XsVms /dfObtE64wqbxZGta5kdWD2WLPnJ5NF3oIvV4+6tS0weLc9OsgWwRDUw2iQllpQFZ6bn6dvZ JObl5ZcklqQqpKQWJ9sq+aSmJ+YoBBRlliUmVyq4ZBYn5yRm5qYWKSlkptgqmSgpFOQkJqfm puaV2ColFhSk5qUo2XEpYAAboLLMPIXUvOT8lMy8dFslz2B/XQsLU0tdQyU73YROnoz/U/Yx F+wsr9jfdZa9gfFHchcjJ4eEgIlE2/d9LBC2mMSFe+vZuhi5OIQEVjJKtMw6A5YQEtjMKHG/ 2xzEZhPQkth/eDoTiC0isJRRon+DH4jNLJAg0bFoKTOILSwQL3F5215GiJoEiTmbfrJC2G4S O5+8A5vJIqAqsbfvLFicV8BD4vui3ywgizkFmhglJmz9CdbMKCArsfvsdSaIBeISt57MZ4K4 VEBiyZ7zzBC2qMTLx/9YIWxFib97v7NC1OtJ3Jg6hQ3C1pZYtvA1M8QyQYmTM5+wTGAUnYVk 7CwkLbOQtMxC0rKAkWUVo2BuRrGBmUFyXrJeUWauXl5qySZGUAJx1NDfwfj2vcUhRgEORiUe Xu7nDoFCrIllxZW5hxglOJiVRHjvPgYK8aYkVlalFuXHF5XmpBYfYnQFBsVEZinu5Hxgcssr iTc2MMDNURLnFQkUDRQSSAemn+zU1ILUIpg5TBycIHu4pESKgUkktSixtCQjHpTq4ouByU6q gbE0rLD54L68r5GZUzX+s2XFnu46ZGp89gNjf2+Nz8Gb/00+yKyXfbriupyXWv+nu2/5fvPU n3j2XOv0fVeZSJYs08qt5ZUctiFO7TPV5hemTLk2n+3P/p6l8d9qk3WWFi1hmSh2cr0Ft5Tm mcK93s81lgj80Ga4EHXk5P9wjamrbl9u/CrCF63EUpyRaKjFXFScCACtJzV+YQMAAA==
Cc: "rtcweb@ietf.org" , "xavier.marjou@orange.com" 
Subject: Re: [rtcweb] Agenda time	request	for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 23:01:01 -0000

I think the if available to the browser text applies to all codecs regardles=
s of whether there are billions or only hundreds of other devices that suppo=
rt a codec.

It shoulld be appreciated that the number of devices supporting a particular=
 codec are snapshots in time and this will likely change - either increasing=
 or decreasing in the future and the specifications we write now should be a=
s future proof as possible and not have a built in best before date.
 

----- Original Message -----
From: stephane.proust@orange.com [mailto:stephane.proust@orange.com]
Sent: Wednesday, March 13, 2013 05:48 PM Central Standard Time=0A=
To: Andrew Allen; Markus.Isomaki@nokia.com ; jmval=
in@mozilla.com 
Cc: MARJOU Xavier OLNC/OLN ; rtcweb@ietf.org 
Subject: RE: [rtcweb] Agenda time	request	for	draft-marjou-rtcweb-audio-code=
cs-for-interop-01

The reason is simply that AMR and AMR-WB are supported in billions of device=
s !

St=E9phane


-----Message d'origine-----
De=A0: Andrew Allen [mailto:aallen@blackberry.com] 
Envoy=E9=A0: mercredi 13 mars 2013 23:41
=C0=A0: PROUST Stephane OLNC/OLPS; Markus.Isomaki@nokia.com; jmvalin@mozilla=
.com
Cc=A0: MARJOU Xavier OLNC/OLN; rtcweb@ietf.org
Objet=A0: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01


No this wouldn't be acceptable to me. 

I don't see a reason to push a particular set of Codecs over any other set o=
f codecs supported on the device. If the device supports the codecs and they=
 are available to the browser then we should recommend that they be offered=
 in the negotiation.

The marjou draft can advertise the merits and reasons why they are good code=
cs to support.


----- Original Message -----
From: stephane.proust@orange.com [mailto:stephane.proust@orange.com]
Sent: Wednesday, March 13, 2013 05:14 PM Central Standard Time
To: Markus.Isomaki@nokia.com ; jmvalin@mozilla.com=
 
Cc: MARJOU Xavier OLNC/OLN ; rtcweb@ietf.org 
Subject: Re: [rtcweb] Agenda time	request	for	draft-marjou-rtcweb-audio-code=
cs-for-interop-01

Dear Markus

Thanks for your attempt to help !

Of course each Telco can handle this directly with vendors and browsers manu=
facturers at business level. But I don't'think this need of interoperability=
 with mobile devices is specific to Orange. I think all mobile operators wil=
l have the same issue and this is why standardization exist. It's most cost=
 and time efficient to have one common way forward for all the industry.

Then if the issue is that "conditional MUST/SHOULD are a too complicated req=
uirement. We could also live as a compromise with a formulation that has alr=
eady been suggested on the reflector: 

"If other suitable audio codecs are available to the browser to use it is re=
commended that they are also included in the offer in order to maximize the=
 possibility to establish the session without the need for audio transcoding=
"
If possible with the addition of
This is especially the case for AMR, AMR-WB for interoperability with mobile=
 devices and G.722 for interoperability with fixed DECT CAT-iq devices

Would it have one chance to reach consensus ?

I think this Group should at least make one small step so that the interoper=
ability issue with mobile terminals be not fully ignored in the RTC Web spec=
ification considering the huge number of deployed devices. At least somethin=
g must be written on this ! G.711 which is the only codec in addition to OPU=
S for interoperability purpose is not a proper answer to this.

St=E9phane

-----Message d'origine-----
De=A0: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] Envoy=E9=
=A0: mercredi 13 mars 2013 22:37 =C0=A0: PROUST Stephane OLNC/OLPS; jmvalin@=
mozilla.com; MARJOU Xavier OLNC/OLN Cc=A0: rtcweb@ietf.org Objet=A0: RE: [rt=
cweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-0=
1

Hi Stephane, Xavier,

I understand the intent of your proposal. I'm not sure if the IETF is the be=
st venue for you to pursue it, however. Perhaps you as a mobile operator sho=
uld rather set it as a requirement to your mobile device platforms that they=
 open up the APIs to AMR and AMR-WB and that at least the in-built default b=
rowser needs to support it. If there are enough operators setting such requi=
rements directly to the device and platform vendors, it probably has a bigge=
r impact than an IETF RFC. Getting that support for user-installed additiona=
l browsers might be more difficult, but most mobile device users stick with=
 the default browser anyway.

The RTCWEB codec document needs to definitely explain this case and the bene=
fits, but the conditional MUSTs or SHOULDs you are proposing are perhaps a b=
it too complicated. Hmm, perhaps we need to do an _informational_ RFC as som=
ething like "Recommendations for WebRTC on Mobile Devices" addressing the co=
dec and perhaps other issues, that you could use as a reference in your requ=
irements.  

Markus


>-----Original Message-----
>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On 
>Behalf Of ext stephane.proust@orange.com
>Sent: 13 March, 2013 21:37
>To: Jean-Marc Valin; MARJOU Xavier OLNC/OLN
>Cc: rtcweb@ietf.org
>Subject: Re: [rtcweb] Agenda time request for
>draft-marjou-rtcweb-audio-
>codecs-for-interop-01
>
>Hello
>
>Our understanding is that the reason of the "no consensus" on 
>additional recommended codecs was the additional costs for browsers.
>The proposal is then to make these "MUST" fully conditional to the case 
>of no (or very reduced) additional costs, when the codecs are already 
>available on the device and when no additional license fee is required
>
>We could even live with lower level of "requirements" with respectively 
>May and Should (instead of Should and shall) but we think that this 
>proposal is a way to take into account both browser manufacturers 
>concerns on browsers costs and telcos concerns on transcoding costs and 
>some other companies share this view.
>
>St=E9phane
>
>
>
>
>
>
>-----Message d'origine-----
>De=A0: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la 
>part de Jean-Marc Valin Envoy=E9=A0: mercredi 13 mars 2013 20:24 =C0=A0: MA=
RJOU 
>Xavier OLNC/OLN Cc=A0: rtcweb@ietf.org Objet=A0: Re: [rtcweb] Agenda time 
>request for
>draft-marjou-rtcweb-audio-codecs-for-interop-01
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi,
>
>I'd really like to understand how the chairs coming to the conclusion 
>that there was *no consensus* on recommended codecs can result in a 
>draft that includes 3 MUSTs and 1 SHOULD. This draft effectively makes
>3 new codecs MTI for a range of devices. I understand that it's an 
>individual draft and you can write whatever you like in there, but it 
>definitely goes against the result of the WG discussion.
>
>Cheers,
>
>	Jean-Marc
>
>On 03/13/2013 09:14 AM, Xavier Marjou wrote:
>> Here is a summary of the
>> draft-marjou-rtcweb-audio-codecs-for-interop-00 presentation that I 
>> had prepared for yesterday's session:
>>
>> - The co-authors want to underline that non-WebRTC voice endpoints 
>> usually use one of the following codecs: AMR, AMR-WB or G.722, which 
>> will result in massive transcoding when there will be communications 
>> between WebRTC endpoints and non-WebRTC endpoints.
>>
>> - On one side, transcoding is bad for many reasons discussed in the 
>> draft (cost issues, intrinsic quality degradation, degraded 
>> interactivity, fallback from HD to G.711...);
>>
>> - On the other side, it is recognized that implementing additional 
>> codecs in the browsers can generate additional costs.
>>
>> - In order to reach a compromise, we would like to add some text in 
>> the WG draft draft-ietf-rtcweb-audio providing incentives for the 
>> browser to use these three codecs: make them mandatory to implement 
>> when there is no cost impact on the browser (e.g. if codec already 
>> installed, paid by the device vendor...).
>>
>> Any opinion on that?
>>
>> Cheers,
>>
>> Xavier
>>
>> PS: I will be ready to present the slides on Thursday if time permits 
>> it.
>>
>> (c.f. http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf
>> )
>>
>>
>>
>> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie > > wrote:
>>
>> Magnus and I discussed this this morning, and we encourage you to 
>> prepare something.  If the discussion of working group last call 
>> items runs short, we may be able to fit this in at that time or at 
>> the end of day one if its full agenda his finished.  This is not a 
>> commitment, however, so please try and get discussion on the list on 
>> the points from the draft you feel need resolution.
>>
>> regards,
>>
>> Ted
>>
>>
>> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg) 
>> > wrote:
>>> Hello,
>>>
>>>
>>>
>>> I would like to request agenda time for:
>>>
>>>
>>>
>>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>>>
>>>
>>>
>>> The document  presents use-cases underlining why WebRTC needs
>> AMR-WB,  AMR
>>> and G.722 as additional relevant voice codecs to satisfactorily 
>>> ensure interoperability with existing systems.
>>>
>>>
>>>
>>> A 10-minute time slot should be sufficient for presentation and
>> discussion.
>>>
>>>
>>>
>>> Regards
>>>
>>>
>>>
>>> -Espen
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________ 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
>>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.13 (GNU/Linux)
>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
>iQEcBAEBAgAGBQJRQNJZAAoJEJ6/8sItn9q9vNYIAL64nPUsZfKfxSYteqTQRPmg
>CzVXzr8GEBtR8gugL6KO5Lxgux+3fYKm7BJHirZyyCF1uPWIvXNevE2ad1KvHFwC
>yT9XlzgiiHX79SOEyd3bIn9thycBXBSAAiqyCkz5E/eEYskPFQ4e5AVDezjjvMGF
>L1Fx1PtsYuMRWEXZNB8wglH9sk3xeWe02o9s4TqLxwiseTS3CJ1kTwoHfIo5e4o
>X
>26NMjBBiEy/eKK9qtmry9Octjr93OgtFVavPoXN/sNqCW8u8kreVOSxeegJ233n9
>WQYhkctybnS22RTjbu3W6mZafpyOGi41rIzdGyUocmTelsFfT3hban5OU+1kQR
>w=3D
>=3DP8Jl
>-----END PGP SIGNATURE-----
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb
>
>___________________________________________________________
>___________________________________________________________
>___
>
>Ce message et ses pieces jointes peuvent contenir des informations 
>confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
>exploites ou copies sans autorisation. Si vous avez recu ce message par 
>erreur, veuillez le signaler a l'expediteur et le detruire ainsi que 
>les pieces jointes. Les messages electroniques etant susceptibles 
>d'alteration, France Telecom - Orange decline toute responsabilite si 
>ce message a ete altere, deforme ou falsifie. Merci.
>
>This message and its attachments may contain confidential or privileged 
>information that may be protected by law; they should not be 
>distributed, used or copied without authorisation.
>If you have received this email in error, please notify the sender and 
>delete this message and its attachments.
>As emails may be altered, France Telecom - Orange is not liable for 
>messages that have been modified, changed or falsified.
>Thank you.
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb

____________________________________________________________________________=
_____________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou co=
pies sans autorisation. Si vous avez recu ce message par erreur, veuillez le=
 signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les me=
ssages electroniques etant susceptibles d'alteration, France Telecom - Orang=
e decline toute responsabilite si ce message a ete altere, deforme ou falsif=
ie. Merci.

This message and its attachments may contain confidential or privileged info=
rmation that may be protected by law; they should not be distributed, used o=
r copied without authorisation.
If you have received this email in error, please notify the sender and delet=
e this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages=
 that have been modified, changed or falsified.
Thank you.

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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

____________________________________________________________________________=
_____________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages ele=
ctroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete alt=
ere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delet=
e this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages=
 that have been modified, changed or falsified.
Thank you.


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From btv1==784b8d51794==HKaplan@acmepacket.com  Wed Mar 13 16:25: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 58AD011E811D for ; Wed, 13 Mar 2013 16:25:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.696
X-Spam-Level: 
X-Spam-Status: No, score=-2.696 tagged_above=-999 required=5 tests=[AWL=-0.097, 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 8EFw7OwhlFZG for ; Wed, 13 Mar 2013 16:25:12 -0700 (PDT)
Received: from mx2.acmepacket.com (mx2.acmepacket.com [216.41.24.99]) by ietfa.amsl.com (Postfix) with ESMTP id 443AE11E810D for ; Wed, 13 Mar 2013 16:25:12 -0700 (PDT)
X-ASG-Debug-ID: 1363217110-03fc217260f491a0001-4f8tJD
Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx2.acmepacket.com with ESMTP id yYJLb7xie0skom7z (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Mar 2013 19:25:10 -0400 (EDT)
X-Barracuda-Envelope-From: HKaplan@acmepacket.com
Received: from MAIL2.acmepacket.com ([169.254.2.222]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Wed, 13 Mar 2013 19:25:09 -0400
From: Hadriel Kaplan 
To: Ron 
Thread-Topic: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-ASG-Orig-Subj: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIEIA/rs7xzIChkCKAShD3O9vqA==
Date: Wed, 13 Mar 2013 23:25:09 +0000
Message-ID: <01DB04B4-7797-4394-AC1F-D3D6A043727C@acmepacket.com>
References:    <20130313142732.GE12022@audi.shelbyville.oz> <1363185502_43961@mail.internode.on.net> <20130313155342.GF12022@audi.shelbyville.oz>
In-Reply-To: <20130313155342.GF12022@audi.shelbyville.oz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21]
X-Barracuda-Start-Time: 1363217110
X-Barracuda-Encrypted: AES128-SHA
X-Barracuda-URL: http://216.41.24.99:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at acmepacket.com
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.125125 Rule breakdown below pts rule name              description ---- ---------------------- --------------------------------------------------
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 23:25:13 -0000

On Mar 13, 2013, at 11:53 AM, Ron  wrote:

> On Wed, Mar 13, 2013 at 10:37:45AM -0400, Bogineni, Kalyani wrote:
>> There are 6.4 billion cellular connections worldwide.
>>=20
>> http://www.3gpp.org/3GPP-Family-2012-Statistics
>=20
> Sure.  And why do you think that someone with one of those devices,
> who wanted to call someone on the legacy network that didn't have
> a WebRTC service, would want to do it by going via a WebRTC gateway
> service, that they would presumably have to pay extra for, and would
> suffer extra hops of latency to use (even without transcoding), when
> they could just, you know, call them on their cell phone normally =85 ?

Well I can think of one reason: it's a lot cheaper, when traveling internat=
ionally/roaming.  I.e., it's a lot cheaper today to use my cell phone with =
Skype-out on Wifi when I'm in another country, than it is to pay my cell ca=
rrier's price for international roaming charges... even though Skype also c=
harges money for their Skype-out service.  But if my carrier offered me Web=
RTC-calls at a price closer to Skype's, for this roaming usage scenario, I'=
d use that instead.

But I'm not suggesting that means we do/do-not need to mandate other codecs=
 - just pointing out there is a use-case for WebRTC on mobile phones making=
 calls to other cell phones and the PSTN.  Personally I don't think the big=
 fish for mobile happens to be *browsers* using WebRTC, but rather web-base=
d resident *apps* based on things like PhoneGap/Titanium/etc.  But I'm not =
a market analyst for mobile, and I'd expect people in that space to know mo=
re about it.

-hadriel


From ietf@meetecho.com  Wed Mar 13 16:31: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 120CC11E8168 for ; Wed, 13 Mar 2013 16:31:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.664
X-Spam-Level: 
X-Spam-Status: No, score=-0.664 tagged_above=-999 required=5 tests=[AWL=0.055,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mz19Qgzy9Kc1 for ; Wed, 13 Mar 2013 16:31:56 -0700 (PDT)
Received: from smtpdg8.aruba.it (smtpdg226.aruba.it [62.149.158.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE0B11E810D for ; Wed, 13 Mar 2013 16:31:55 -0700 (PDT)
Received: from dell-tcastaldi ([130.129.16.136]) by smtpcmd03.ad.aruba.it with bizsmtp id BBXs1l0082w8SR601BXtua; Thu, 14 Mar 2013 00:31:54 +0100
Date: Wed, 13 Mar 2013 19:31:49 -0400 (EDT)
From: Meetecho Team 
To: rtcweb@ietf.org
Message-ID: <11850652.19.1363217509728.JavaMail.tcastaldi@dell-tcastaldi>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_Part_18_28378327.1363217509727"
Subject: [rtcweb] Meetecho support for RTCWEB_III session
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 13 Mar 2013 23:31:57 -0000

------=_Part_18_28378327.1363217509727
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dear all,

a virtual room has been reserved on the Meetecho system for the 
RTCWEB WG meeting session.
Access to the on-line session (including audio and video streams) will
be made available (just a couple of minutes before session start time) at:
http://www.meetecho.com/ietf86/rtcweb

The Meetecho session automatically logs you into the standard IETF
jabber room. So, from there, you can have an integrated experience
involving all media and allowing you to interact with the room.

A tutorial of interactivity features of the tool can be found at:
	http://www.meetecho.com/ietf86

Cheers,
the Meetecho Team


This email has been automatically generated by The Meetecho Conferencing System


------=_Part_18_28378327.1363217509727--

From jdrosen@jdrosen.net  Wed Mar 13 16:44: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 CF76711E815C for ; Wed, 13 Mar 2013 16:44:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.976
X-Spam-Level: 
X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 hVfMJTEt+Z6o for ; Wed, 13 Mar 2013 16:44:13 -0700 (PDT)
Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [70.39.232.100]) by ietfa.amsl.com (Postfix) with ESMTP id 642F411E810A for ; Wed, 13 Mar 2013 16:44:12 -0700 (PDT)
Received: from mail-wg0-f45.google.com ([74.125.82.45]:34369) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1UFvL9-000749-7f for rtcweb@ietf.org; Wed, 13 Mar 2013 19:44:11 -0400
Received: by mail-wg0-f45.google.com with SMTP id dq12so1489409wgb.0 for ; Wed, 13 Mar 2013 16:44:10 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.88.138 with SMTP id bg10mr407150wjb.13.1363218250959; Wed, 13 Mar 2013 16:44:10 -0700 (PDT)
Received: by 10.194.109.161 with HTTP; Wed, 13 Mar 2013 16:44:10 -0700 (PDT)
In-Reply-To: 
References:   
Date: Wed, 13 Mar 2013 19:44:10 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: Silvia Pfeiffer 
Content-Type: multipart/alternative; boundary=047d7bfd056299950f04d7d6fbda
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jdrosen.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] A different perspective on the video codec MTI 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, 13 Mar 2013 23:44:17 -0000

--047d7bfd056299950f04d7d6fbda
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Justin - my point is that there are non-web endpoints that people care
about - including most importantly mobile endpoints. Its not just about
pure numbers, its about reaching users on the devices/platforms they need
to be reached on.

Surely you don't mean that its not important for developers (like Webex) to
reach users on mobile clients or other video systems outside of the web?

Thx,
Jonathan R.


On Wed, Mar 13, 2013 at 6:54 PM, Silvia Pfeiffer
wrote:

> Also, it is worth pointing out that h.264 cannot meet the RF requirements
> of W3C, so the only alternatives we can look at are VP8 or delaying the
> decision for an MTI until the market decides.
>
> I'd rather we specify for an environment 5 years down the track (and give
> companies like CISCO a reason to replace all their old devices with new
> ones that support VP8) than continuing decision avoidance.
>
> Regards,
> Silvia.
> (Speaking for myself)
> On 14 Mar 2013 09:42, "Justin Uberti"  wrote:
>
>> Regarding your comment on the "web today", I think it is worthwhile to
>> point out that within weeks, there will be 2B+ deployed WebRTC endpoints=
,
>> across desktop and mobile, that support VP8.
>>
>> Surely that dwarfs the total number of deployed H.264 endpoints by
>> several orders of magnitude.
>>
>>
>> On Wed, Mar 13, 2013 at 3:06 PM, Jonathan Rosenberg wrote:
>>
>>> I=92d like to put a different perspective on the video MTI discussion.
>>>
>>> Much of the discussion has been around video quality, IPR, and
>>> standardization status. While those are all important factors, to me th=
ey
>>> are secondary to the core question: how does the choice impact uptake o=
f
>>> the webRTC APIs and protocols by developers who build applications onto=
p of
>>> it? In this regard, I would like to suggest that, at this time, adoptio=
n of
>>> VP8 as MTI will slow down adoption of webRTC by turning off developers =
that
>>> would otherwise embrace it if H.264 were selected.
>>>
>>> The reason is simple. For many application developers, what is
>>> interesting about webRTC is NOT just browser to browser communications,=
 but
>>> connecting users in a browser to users elsewhere - on other devices, in
>>> other networks. After all, the vast majority of web application develop=
ers
>>> do not have the luxury of a massive social graph, or the luxury of thei=
r
>>> users being parked persistently on their website and thus able to recei=
ve
>>> an incoming call. Many websites that have customer support or service n=
eeds
>>> would love to be able to allow their users to have a video call with an
>>> agent. However, those agents are probably sitting on existing agent sys=
tems
>>> which are not web based, and it=92s almost certainly true that they do =
not
>>> today support VP8, but rather H.264. Many developers would probably lov=
e to
>>> connect users on the web with users on mobile apps. Most mobile platfor=
ms
>>> today support H264 based hardware acceleration for decode and sometimes
>>> encode, but not yet VP8. Developers who want to build business
>>> communications clients will need to connect those users with other user=
s in
>>> the business, who may be using videophones, PC clients, telepresence un=
its
>>> or video room systems, the vast majority of which do not support VP8 to=
day,
>>> but many of which do support H.264.
>>>
>>> The reality is =96 today=92s Internet and IP communications systems are
>>> built on H.264. And unless the developer cares only about living within=
 the
>>> island of the web browser =96 a VP8 based solution will simply not meet=
 their
>>> requirements.
>>>
>>> This may not be true down the road. I applaud Google for working hard
>>> (and spending much money no doubt) to secure an RF license for VP8 from
>>> these patent holders. I think they should continue pushing and promotin=
g
>>> the technology because a  free, high quality video codec would be great=
 for
>>> the Internet. But today, it is not the video codec of the Internet. And=
,
>>> given the relatively early days of video, I am sure there will be video
>>> codecs after VP8. Maybe H.265, maybe the new video codec being develope=
d
>>> here at the IETF. And once those codecs become more broadly implemented=
 and
>>> available on the endpoints that matter, we can revise our specs and man=
date
>>> support for them. But this is not about the web of five years from now,=
 its
>>> about the web today. And if we mandate usage of a codec which is not wi=
dely
>>> implemented in all the endpoints that matter (not just the browser), I =
fear
>>> that it will hold developers back from using webRTC and thus prevent us
>>> from ever having the opportunity to add these video codecs in the futur=
e.
>>>
>>>
>>>
>>> And so =96 to the supporters of VP8 =96 I applaud your efforts and than=
k you
>>> for them. Please continue. And when the industry is ready, we can make =
VP8
>>> MTI in the browser. But we are not there yet.  I ask you to please put =
the
>>> needs of the developers ahead of your own, and do not hold back webRTC =
for
>>> the benefit of your ideals around an RF and open source video codec. We=
bRTC
>>> is too important for that.
>>>
>>> I have one more thing to say - speaking now as a developer.
>>>
>>> As some of you may know, I recently returned to Cisco as CTO of the
>>> cloud collaboration group, which is responsible for Webex. Webex was on=
e of
>>> the first services to do voice and video on the web, using plugins of
>>> course. For our business, a key requirement is interoperability with ot=
her
>>> video systems in the Cisco portfolio, including our video clients and
>>> telepresence units. Those are all based on H.264. Consequently, much as=
 I
>>> would like to avoid the need for a plugin, the benefits of eliminating =
the
>>> plugin do not outweigh the drawbacks of having to transcode from VP8 to
>>> H.264. If IETF selects VP8 as the MTI codec, this will make it dramatic=
ally
>>> more difficult and expensive for us to use webRTC. If H.264 is the MIT
>>> codec, it will make it much easier for us to use webRTC.
>>>
>>>
>>> Thx,
>>>
>>> Jonathan R.
>>> --
>>> Jonathan Rosenberg, Ph.D.
>>> jdrosen@jdrosen.net
>>> http://www.jdrosen.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
>>
>>


--=20
Jonathan Rosenberg, Ph.D.
jdrosen@jdrosen.net
http://www.jdrosen.net

--047d7bfd056299950f04d7d6fbda
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


Justin - my point is that there are non-web endpoints that=
 people care about - including most importantly mobile endpoints. Its not j=
ust about pure numbers, its about reaching users on the devices/platforms t=
hey need to be reached on.=A0


Surely you don't mean that its not important for d=
evelopers (like Webex) to reach users on mobile clients or other video syst=
ems outside of the web?

Thx,


Jonathan R.


On Wed, Mar 13, 2013 at 6:54 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:


Also, it is worth pointing ou=
t that h.264 cannot meet the RF requirements of W3C, so the only alternativ=
es we can look at are VP8 or delaying the decision for an MTI until the mar=
ket decides. 



I'd rather we specify for an environment 5 years down th=
e track (and give companies like CISCO a reason to replace all their old de=
vices with new ones that support VP8) than continuing decision avoidance.



Regards,

Silvia.

(Speaking for myself)


On 14 Mar 2013 09:42, "Justin Uberti" =
<juberti@google.=
com> wrote:



Regarding your comment on the "web today", I thi=
nk it is worthwhile to point out that within weeks, there will be 2B+ deplo=
yed WebRTC endpoints, across desktop and mobile, that support VP8.=A0






Surely that dwarfs the total number of deployed H.264 endpoints =
by several orders of magnitude.



On Wed, Mar 1=
3, 2013 at 3:06 PM, Jonathan Rosenberg <jdrosen@jdrosen.net> wrote:






I=92d like to put =
a different
perspective on the video MTI discussion.



Much of the discussion has been
around video quality, IPR, and standardization status. While those are all
important factors, to me they are secondary to the core question: how does =
the
choice impact uptake of the webRTC APIs and protocols by developers who bui=
ld applications ontop of it? In this regard, I would like to suggest that, =
at this
time, adoption of VP8 as MTI will slow down adoption of webRTC by
turning off developers that would otherwise embrace it if H.264 were select=
ed.
The reason is simple. For many
application developers, what is interesting about webRTC is NOT just browse=
r to
browser communications, but connecting users in a browser to users elsewher=
e - on other devices, in other networks.
After all, the vast majority of web application developers do not have the
luxury of a massive social graph, or the luxury of their users being parked
persistently on their website and thus able to receive an incoming call. Ma=
ny websites
that have customer support or service needs would love to be able to allow
their users to have a video call with an agent. However, those agents are
probably sitting on existing agent systems which are not web based, and it=
=92s
almost certainly true that they do not today support VP8, but rather H.264.
Many developers would probably love to connect users on the web with users =
on
mobile apps. Most mobile platforms today support H264 based hardware accele=
ration
for decode and sometimes encode, but not yet VP8. Developers who want to bu=
ild
business communications clients will need to connect those users with other
users in the business, who may be using videophones, PC clients, telepresen=
ce
units or video room systems, the vast majority of which do not support VP8
today, but many of which do support H.264.



The reality is =96 today=92s Internet
and IP communications systems are built on H.264. And unless the developer
cares only about living within the island of the web browser =96 a VP8 base=
d
solution will simply not meet their requirements.



This may not be true down the
road. I applaud Google for working hard (and spending much money no doubt) =
to
secure an RF license for VP8 from these patent holders. I think they should
continue pushing and promoting the technology because a=A0 free, high
quality video codec would be great for the Internet. But today, it is not t=
he
video codec of the Internet. And, given the relatively early days of video,=
 I
am sure there will be video codecs after VP8. Maybe H.265, maybe the new vi=
deo
codec being developed here at the IETF. And once those codecs become more
broadly implemented and available on the endpoints that matter, we can revi=
se
our specs and mandate support for them. But this is not about the web of fi=
ve
years from now, its about the web today. And if we mandate usage of a codec
which is not widely implemented in all the endpoints that matter (not just =
the browser), I fear that it
will hold developers back from using webRTC and thus prevent us from ever h=
aving
the opportunity to add these video codecs in the future.



=A0



And so =96 to the supporters of VP8
=96 I applaud your efforts and thank you for them. Please continue. And whe=
n the
industry is ready, we can make VP8 MTI in the browser. But we are not there=
 yet.
=A0I ask you to please put the needs of the developers ahead of your own,
and do not hold back webRTC for the benefit of your ideals around an RF and
open source video codec. WebRTC is too important for that.



I have one more thing to say - speaking now as a developer.=




As some of you may know, I
recently returned to Cisco as CTO of the cloud collaboration group, which i=
s
responsible for Webex. Webex was one of the first services to do voice and
video on the web, using plugins of course. For our business, a key requirem=
ent
is interoperability with other video systems in the Cisco portfolio, includ=
ing
our video clients and telepresence units. Those are all based on H.264.
Consequently, much as I would like to avoid the need for a plugin, the bene=
fits
of eliminating the plugin do not outweigh the drawbacks of having to transc=
ode
from VP8 to H.264. If IETF selects VP8 as the MTI codec, this will make it =
dramatically more difficult and expensive for us to use webRTC. If H.264 is=
 the MIT codec, it will make it much easier for us to use webRTC.=A0=









Thx,
Jonathan R.=

-- 




_______________________________________________

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







-- 
=





--047d7bfd056299950f04d7d6fbda--

From cb.list6@gmail.com  Wed Mar 13 16: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 BBD6421F8431 for ; Wed, 13 Mar 2013 16:54:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.933
X-Spam-Level: 
X-Spam-Status: No, score=-2.933 tagged_above=-999 required=5 tests=[AWL=0.665,  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 lbfowpPV+OJu for ; Wed, 13 Mar 2013 16:54:30 -0700 (PDT)
Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ietfa.amsl.com (Postfix) with ESMTP id 44DED21F8CD4 for ; Wed, 13 Mar 2013 16:54:17 -0700 (PDT)
Received: by mail-wg0-f53.google.com with SMTP id fn15so1549272wgb.20 for ; Wed, 13 Mar 2013 16:54:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=fDl3sGItlki1Fu587yLrc+FJIeQD81YiHSf3SwW03qQ=; b=T2ZKX2NLUc3OBFiMezne9T5ucNZiywRUPzMH3O8bRupYOyPxCkyMBCiRH1zwF7ONdb NqsSxT4GaN43XVfaIslvpg7tu2yYqfIXKM1lKrvSiZw+d+M4o+3GnNSEaffym+Q9b6lo QpFyv9yyfeywhM/A5M4XDq8T1CNX5GwieIE0gsxaHCYeF9CqD81peOWIRk3fWAirSg4Q F/kX+6oKhs37vFC62wCmAsKRn9ywL8rDDqXnmTa3JdoSuFxT+I2czqbWwu2PmTLBPZSB /bIqOWtJyAd/32YJV4SG5fMuCUTIMJs8pl1o53c2WbfnK4AZ+tya5Lj3bonskK66vMKd JOTQ==
MIME-Version: 1.0
X-Received: by 10.180.75.143 with SMTP id c15mr402304wiw.18.1363218856347; Wed, 13 Mar 2013 16:54:16 -0700 (PDT)
Received: by 10.194.20.35 with HTTP; Wed, 13 Mar 2013 16:54:16 -0700 (PDT)
Received: by 10.194.20.35 with HTTP; Wed, 13 Mar 2013 16:54:16 -0700 (PDT)
In-Reply-To: 
References:    
Date: Wed, 13 Mar 2013 16:54:16 -0700
Message-ID: 
From: Cameron Byrne 
To: Jonathan Rosenberg 
Content-Type: multipart/alternative; boundary=f46d04389555af0eae04d7d71fd0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] A different perspective on the video codec MTI 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, 13 Mar 2013 23:54:34 -0000

--f46d04389555af0eae04d7d71fd0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Mar 13, 2013 4:44 PM, "Jonathan Rosenberg"  wrote:
>
> Justin - my point is that there are non-web endpoints that people care
about - including most importantly mobile endpoints. Its not just about
pure numbers, its about reaching users on the devices/platforms they need
to be reached on.
>
> Surely you don't mean that its not important for developers (like Webex)
to reach users on mobile clients or other video systems outside of the web?
>

They too can have vp8 and opus. And if your legacy gear does not, then it
can negotiate appropriately to something that will work.

As a mobile operator offering fmc today, I look forward to opus and vp8
being ubiquitous in all devices.

CB

> Thx,
> Jonathan R.
>
>
> On Wed, Mar 13, 2013 at 6:54 PM, Silvia Pfeiffer <
silviapfeiffer1@gmail.com> wrote:
>>
>> Also, it is worth pointing out that h.264 cannot meet the RF
requirements of W3C, so the only alternatives we can look at are VP8 or
delaying the decision for an MTI until the market decides.
>>
>> I'd rather we specify for an environment 5 years down the track (and
give companies like CISCO a reason to replace all their old devices with
new ones that support VP8) than continuing decision avoidance.
>>
>> Regards,
>> Silvia.
>> (Speaking for myself)
>>
>> On 14 Mar 2013 09:42, "Justin Uberti"  wrote:
>>>
>>> Regarding your comment on the "web today", I think it is worthwhile to
point out that within weeks, there will be 2B+ deployed WebRTC endpoints,
across desktop and mobile, that support VP8.
>>>
>>> Surely that dwarfs the total number of deployed H.264 endpoints by
several orders of magnitude.
>>>
>>>
>>> On Wed, Mar 13, 2013 at 3:06 PM, Jonathan Rosenberg 
wrote:
>>>>
>>>> I=92d like to put a different perspective on the video MTI discussion.
>>>>
>>>> Much of the discussion has been around video quality, IPR, and
standardization status. While those are all important factors, to me they
are secondary to the core question: how does the choice impact uptake of
the webRTC APIs and protocols by developers who build applications ontop of
it? In this regard, I would like to suggest that, at this time, adoption of
VP8 as MTI will slow down adoption of webRTC by turning off developers that
would otherwise embrace it if H.264 were selected.
>>>>
>>>> The reason is simple. For many application developers, what is
interesting about webRTC is NOT just browser to browser communications, but
connecting users in a browser to users elsewhere - on other devices, in
other networks. After all, the vast majority of web application developers
do not have the luxury of a massive social graph, or the luxury of their
users being parked persistently on their website and thus able to receive
an incoming call. Many websites that have customer support or service needs
would love to be able to allow their users to have a video call with an
agent. However, those agents are probably sitting on existing agent systems
which are not web based, and it=92s almost certainly true that they do not
today support VP8, but rather H.264. Many developers would probably love to
connect users on the web with users on mobile apps. Most mobile platforms
today support H264 based hardware acceleration for decode and sometimes
encode, but not yet VP8. Developers who want to build business
communications clients will need to connect those users with other users in
the business, who may be using videophones, PC clients, telepresence units
or video room systems, the vast majority of which do not support VP8 today,
but many of which do support H.264.
>>>>
>>>> The reality is =96 today=92s Internet and IP communications systems ar=
e
built on H.264. And unless the developer cares only about living within the
island of the web browser =96 a VP8 based solution will simply not meet the=
ir
requirements.
>>>>
>>>> This may not be true down the road. I applaud Google for working hard
(and spending much money no doubt) to secure an RF license for VP8 from
these patent holders. I think they should continue pushing and promoting
the technology because a  free, high quality video codec would be great for
the Internet. But today, it is not the video codec of the Internet. And,
given the relatively early days of video, I am sure there will be video
codecs after VP8. Maybe H.265, maybe the new video codec being developed
here at the IETF. And once those codecs become more broadly implemented and
available on the endpoints that matter, we can revise our specs and mandate
support for them. But this is not about the web of five years from now, its
about the web today. And if we mandate usage of a codec which is not widely
implemented in all the endpoints that matter (not just the browser), I fear
that it will hold developers back from using webRTC and thus prevent us
from ever having the opportunity to add these video codecs in the future.
>>>>
>>>>
>>>>
>>>> And so =96 to the supporters of VP8 =96 I applaud your efforts and tha=
nk
you for them. Please continue. And when the industry is ready, we can make
VP8 MTI in the browser. But we are not there yet.  I ask you to please put
the needs of the developers ahead of your own, and do not hold back webRTC
for the benefit of your ideals around an RF and open source video codec.
WebRTC is too important for that.
>>>>
>>>> I have one more thing to say - speaking now as a developer.
>>>>
>>>> As some of you may know, I recently returned to Cisco as CTO of the
cloud collaboration group, which is responsible for Webex. Webex was one of
the first services to do voice and video on the web, using plugins of
course. For our business, a key requirement is interoperability with other
video systems in the Cisco portfolio, including our video clients and
telepresence units. Those are all based on H.264. Consequently, much as I
would like to avoid the need for a plugin, the benefits of eliminating the
plugin do not outweigh the drawbacks of having to transcode from VP8 to
H.264. If IETF selects VP8 as the MTI codec, this will make it dramatically
more difficult and expensive for us to use webRTC. If H.264 is the MIT
codec, it will make it much easier for us to use webRTC.
>>>>
>>>>
>>>> Thx,
>>>>
>>>> Jonathan R.
>>>>
>>>> --
>>>> Jonathan Rosenberg, Ph.D.
>>>> jdrosen@jdrosen.net
>>>> http://www.jdrosen.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
>>>
>
>
>
> --
> Jonathan Rosenberg, Ph.D.
> jdrosen@jdrosen.net
> http://www.jdrosen.net
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--f46d04389555af0eae04d7d71fd0
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable




On Mar 13, 2013 4:44 PM, "Jonathan Rosenberg" <jdrosen@jdrosen.net> wrote:

>

> Justin - my point is that there are non-web endpoints that people care=
 about - including most importantly mobile endpoints. Its not just about pu=
re numbers, its about reaching users on the devices/platforms they need to =
be reached on.=A0


>

> Surely you don't mean that its not important for developers (like =
Webex) to reach users on mobile clients or other video systems outside of t=
he web?

>


They too can have vp8 and opus. And if your legacy gear does=
 not, then it can negotiate appropriately to something that will work. 


As a mobile operator offering fmc today, I look forward to o=
pus and vp8 being ubiquitous in all devices. 


CB


> Thx,

> Jonathan R.

>

>

> On Wed, Mar 13, 2013 at 6:54 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:

>>

>> Also, it is worth pointing out that h.264 cannot meet the RF requi=
rements of W3C, so the only alternatives we can look at are VP8 or delaying=
 the decision for an MTI until the market decides.

>>

>> I'd rather we specify for an environment 5 years down the trac=
k (and give companies like CISCO a reason to replace all their old devices =
with new ones that support VP8) than continuing decision avoidance.


>>

>> Regards,

>> Silvia.

>> (Speaking for myself)

>>

>> On 14 Mar 2013 09:42, "Justin Uberti" <juberti@google.com> wrote:

>>>

>>> Regarding your comment on the "web today", I think i=
t is worthwhile to point out that within weeks, there will be 2B+ deployed =
WebRTC endpoints, across desktop and mobile, that support VP8.=A0

>>>

>>> Surely that dwarfs the total number of deployed H.264 endpoint=
s by several orders of magnitude.

>>>

>>>

>>> On Wed, Mar 13, 2013 at 3:06 PM, Jonathan Rosenberg <jdrosen@jdrosen.net> wrote:

>>>>

>>>> I=92d like to put a different perspective on the video MTI=
 discussion.

>>>>

>>>> Much of the discussion has been around video quality, IPR,=
 and standardization status. While those are all important factors, to me t=
hey are secondary to the core question: how does the choice impact uptake o=
f the webRTC APIs and protocols by developers who build applications ontop =
of it? In this regard, I would like to suggest that, at this time, adoption=
 of VP8 as MTI will slow down adoption of webRTC by turning off developers =
that would otherwise embrace it if H.264 were selected.


>>>>

>>>> The reason is simple. For many application developers, wha=
t is interesting about webRTC is NOT just browser to browser communications=
, but connecting users in a browser to users elsewhere - on other devices, =
in other networks. After all, the vast majority of web application develope=
rs do not have the luxury of a massive social graph, or the luxury of their=
 users being parked persistently on their website and thus able to receive =
an incoming call. Many websites that have customer support or service needs=
 would love to be able to allow their users to have a video call with an ag=
ent. However, those agents are probably sitting on existing agent systems w=
hich are not web based, and it=92s almost certainly true that they do not t=
oday support VP8, but rather H.264. Many developers would probably love to =
connect users on the web with users on mobile apps. Most mobile platforms t=
oday support H264 based hardware acceleration for decode and sometimes enco=
de, but not yet VP8. Developers who want to build business communications c=
lients will need to connect those users with other users in the business, w=
ho may be using videophones, PC clients, telepresence units or video room s=
ystems, the vast majority of which do not support VP8 today, but many of wh=
ich do support H.264.


>>>>

>>>> The reality is =96 today=92s Internet and IP communication=
s systems are built on H.264. And unless the developer cares only about liv=
ing within the island of the web browser =96 a VP8 based solution will simp=
ly not meet their requirements.


>>>>

>>>> This may not be true down the road. I applaud Google for w=
orking hard (and spending much money no doubt) to secure an RF license for =
VP8 from these patent holders. I think they should continue pushing and pro=
moting the technology because a=A0 free, high quality video codec would be =
great for the Internet. But today, it is not the video codec of the Interne=
t. And, given the relatively early days of video, I am sure there will be v=
ideo codecs after VP8. Maybe H.265, maybe the new video codec being develop=
ed here at the IETF. And once those codecs become more broadly implemented =
and available on the endpoints that matter, we can revise our specs and man=
date support for them. But this is not about the web of five years from now=
, its about the web today. And if we mandate usage of a codec which is not =
widely implemented in all the endpoints that matter (not just the browser),=
 I fear that it will hold developers back from using webRTC and thus preven=
t us from ever having the opportunity to add these video codecs in the futu=
re.


>>>>

>>>> =A0

>>>>

>>>> And so =96 to the supporters of VP8 =96 I applaud your eff=
orts and thank you for them. Please continue. And when the industry is read=
y, we can make VP8 MTI in the browser. But we are not there yet. =A0I ask y=
ou to please put the needs of the developers ahead of your own, and do not =
hold back webRTC for the benefit of your ideals around an RF and open sourc=
e video codec. WebRTC is too important for that.


>>>>

>>>> I have one more thing to say - speaking now as a developer=
.

>>>>

>>>> As some of you may know, I recently returned to Cisco as C=
TO of the cloud collaboration group, which is responsible for Webex. Webex =
was one of the first services to do voice and video on the web, using plugi=
ns of course. For our business, a key requirement is interoperability with =
other video systems in the Cisco portfolio, including our video clients and=
 telepresence units. Those are all based on H.264. Consequently, much as I =
would like to avoid the need for a plugin, the benefits of eliminating the =
plugin do not outweigh the drawbacks of having to transcode from VP8 to H.2=
64. If IETF selects VP8 as the MTI codec, this will make it dramatically mo=
re difficult and expensive for us to use webRTC. If H.264 is the MIT codec,=
 it will make it much easier for us to use webRTC.=A0


>>>>

>>>>

>>>> Thx,

>>>>

>>>> Jonathan R.

>>>>

>>>> -- 

>>>> Jonathan Rosenberg, Ph.D.

>>>> jdrosen@jdrosen.net=


>>>> http://www.jdrosen.net<=
/a>

>>>>

>>>> _______________________________________________

>>>> rtcweb mailing list

>>>> rtcweb@ietf.org

>>>> h=
ttps://www.ietf.org/mailman/listinfo/rtcweb

>>>>

>>>

>>>

>>> _______________________________________________

>>> rtcweb mailing list

>>> rtcweb@ietf.org

>>> https=
://www.ietf.org/mailman/listinfo/rtcweb

>>>

>

>

>

> -- 

> Jonathan Rosenberg, Ph.D.

> jdrosen@jdrosen.net

> http://www.jdrosen.net

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.i=
etf.org/mailman/listinfo/rtcweb

>




--f46d04389555af0eae04d7d71fd0--

From spromano@unina.it  Wed Mar 13 16:55: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 2AE0111E80A6 for ; Wed, 13 Mar 2013 16:55:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.178
X-Spam-Level: 
X-Spam-Status: No, score=-99.178 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, SARE_LWHUGE=1.54, 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 utovLMhevHwR for ; Wed, 13 Mar 2013 16:55:32 -0700 (PDT)
Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0A33D21F8C1A for ; Wed, 13 Mar 2013 16:55:31 -0700 (PDT)
Received: from dhcp-1483.meeting.ietf.org (dhcp-1483.meeting.ietf.org [130.129.20.131]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r2DNtLwg000789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Mar 2013 00:55:23 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_F89EA3D1-4809-4927-AB1F-D54BB85D3083"
From: Simon Pietro Romano 
In-Reply-To: 
Date: Thu, 14 Mar 2013 00:55:21 +0100
Message-Id: 
References: 
To: Jonathan Rosenberg 
X-Mailer: Apple Mail (2.1283)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] A different perspective on the video codec MTI 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, 13 Mar 2013 23:55:33 -0000

--Apple-Mail=_F89EA3D1-4809-4927-AB1F-D54BB85D3083
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hi Jonathan,

> I have one more thing to say - speaking now as a developer.
>=20
> As some of you may know, I recently returned to Cisco as CTO of the =
cloud collaboration group, which is responsible for Webex. Webex was one =
of the first services to do voice and video on the web, using plugins of =
course. For our business, a key requirement is interoperability with =
other video systems in the Cisco portfolio, including our video clients =
and telepresence units. Those are all based on H.264. Consequently, much =
as I would like to avoid the need for a plugin, the benefits of =
eliminating the plugin do not outweigh the drawbacks of having to =
transcode from VP8 to H.264. If IETF selects VP8 as the MTI codec, this =
will make it dramatically more difficult and expensive for us to use =
webRTC. If H.264 is the MIT codec, it will make it much easier for us to =
use webRTC.=20
>=20
>=20

This statement looks quite 'ironic'. Seems like you're asking people to =
stick to H.264 because otherwise you can experience issues in keeping on =
doing your company's business with no modifications to your legacy =
stuff. I don't think this is the right thing to ask to an 'open =
standards' community like the IETF. Let me just tell you that there are =
plenty of young 'iconoclastic' companies out there which are looking at =
WebRTC/RTCWeb as a huge opportunity to enter the market by qualifying =
themselves for adopting cutting-edge technologies (like VP8) and are not =
afraid of putting their hands 'inside' the network by building =
rtcweb-enabled middle-boxes which provide functions going far beyond the =
original browser-to-browser use case.

My 2 cents,

Simon
>=20
> Thx,
>=20
> Jonathan R.
>=20
> --=20
> Jonathan Rosenberg, Ph.D.
> jdrosen@jdrosen.net
> http://www.jdrosen.net
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico =
II
                		     Computer Engineering Department=20
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: spromano@unina.it

		    <>. =
Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            =
(   )
			                                  \_)          ) =
/
                                                                       =
(_/






--Apple-Mail=_F89EA3D1-4809-4927-AB1F-D54BB85D3083
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


I have one more =
thing to say - speaking now as a developer.
As some of you may know, I
recently returned to Cisco as CTO of the cloud collaboration group, =
which is
responsible for Webex. Webex was one of the first services to do voice =
and
video on the web, using plugins of course. For our business, a key =
requirement
is interoperability with other video systems in the Cisco portfolio, =
including
our video clients and telepresence units. Those are all based on H.264.
Consequently, much as I would like to avoid the need for a plugin, the =
benefits
of eliminating the plugin do not outweigh the drawbacks of having to =
transcode
from VP8 to H.264. If IETF selects VP8 as the MTI codec, this will make =
it dramatically more difficult and expensive for us to use webRTC. If =
H.264 is the MIT codec, it will make it much easier for us to use =
webRTC. 


T=
his statement looks quite 'ironic'. Seems like you're asking people to =
stick to H.264 because otherwise you can experience issues in keeping on =
doing your company's business with no modifications to your legacy =
stuff. I don't think this is the right thing to ask to an 'open =
standards' community like the IETF. Let me just tell you that there are =
plenty of young 'iconoclastic' companies out there which are looking at =
WebRTC/RTCWeb as a huge opportunity to enter the market by qualifying =
themselves for adopting cutting-edge technologies (like VP8) and are not =
afraid of putting their hands 'inside' the network by building =
rtcweb-enabled middle-boxes which provide functions going far beyond the =
original browser-to-browser use case.
draft-marjou-rtcweb-audio-codecs-for-interop-01 is based on t=
he recommendation 
and clarification from the Chair regarding the conclusion (=
included below). 
 
Regards,
Kalyani Bogineni
&n=
bsp;
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
 
=
On Jan 28, 2013, at 1:12 AM, Magnus Westerlund <magnus.westerlund at eri=
csson.com> wrote:
 
> Hi,
> 
&g=
t; We chairs was considering inclusion in draft-ietf-webrtc-audio, but we
> didn't have any strong opinions on this. Base=
d on that several WG
> participants thinks th=
is should be an independent document, I thus
>=
; decided that we will start out with an independent document. If the WG
> feels differently later we can always fold the=
 text into the audio codec
> and processing re=
quirements document.
> 
=

> I would recommend that the individuals interested in contributing=
 a
> codec writes an independent submission wi=
th focus on the codec
> considerations around =
the codec(s) they are interested in. Then we can
=
> merge this into a common WG document.
> <=
o:p>
> Cheers
> <=
/o:p>
> Magnus
=
 
=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
<=
b>From:<=
/span> rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Andrew Allen
Sent: Wednesday, March 13, 2013 10:30 AM
=
To: Xavier Marjou; rtcweb@ietf.org
Subject: Re: [rtcweb] Agen=
da time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
 
 
I think this draft is not consistent with the scope stated by the RTCweb =
chairs in the decision on this topic  back in February
"Additional Relevant Codecs". That =
can contain a list of codecs which are relevant in specific  contexts,=
 along with a short description of the context for each. Specifically there=
 seems to be interest in understanding the  advantages and costs of G.=
722, AMR, and AMR-WB. We hope that text would broaden understanding of the =
WebRTC use case contexts.
The cur=
rent draft goes way beyond that decision in scope and uses MUST and SHOULD =
strength normative language instead of focusing on identifying the advantag=
es and costs of the specific codecs and the use case contexts of where they=
 are useful.
 
I think we should stick to the s=
cope defined by the chairs and remove the normative language and focus on i=
dentifying the advantages and costs of the specific codecs and the use case=
 contexts of where they are useful..
 
Andrew
 
From: rtcweb=
-bounces@ietf.org [mailto:rt=
cweb-bounces@ietf.org] On Behalf Of Xavier Marjou
Sent: Wednesday, March 13, 2013 9:15 AM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time r=
equest for draft-marjou-rtcweb-audio-codecs-for-interop-01
 
Here=
 is a summary of the draft-marjou-rtcweb-audio-codecs-for-interop-00 presen=
tation that I had prepared for yesterday's session:
- The co-authors want to underline that non-WebRTC voice en=
dpoints usually use one of the following codecs: AMR, AMR-WB or G.722, whic=
h will result in massive transcoding when there will be communications betw=
een WebRTC endpoints and non-WebRTC endpoints.
- On one side, transcoding is bad for many reasons discussed in t=
he draft (cost issues, intrinsic quality degradation, degraded interactivit=
y, fallback from HD to G.711...);
- O=
n the other side, it is recognized that implementing additional codecs in t=
he browsers can generate additional costs.
- In order to reach a compromise, we would like to add some text in t=
he WG draft draft-ietf-rtcweb-audio providing incentives for the browser to=
 use these three codecs: make them mandatory to implement when there is no =
cost impact on the browser (e.g. if codec already installed, paid by the de=
vice vendor...).
Any opinion on that?=

Cheers,
Xavier
PS: I will be ready =
to present the slides on Thursday if time permits it.
(c.f. http://tools.ietf.org/agenda/86/slides/slides-86-rtcw=
eb-6.pdf )
 
<=
p class=3DMsoNormal> 
On Thu, =
Mar 7, 2013 at 11:18 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
Magnus and I discussed this this morning, and we encourage y=
ou to
prepare something.  If the discussion of working group last c=
all items
runs short, we may be able to fit this in at that time or at t=
he end
of day one if its full agenda his finished.  This is not a c=
ommitment,
however, so please try and get discussion on the list on the =
points
from the draft you feel need resolution.

regards,

T=
ed


On Mon, Mar 4, 2013=
 at 2:31 PM, Espen Berger (espeberg)
<espeberg@cisco.com> wrote:
> Hello,
>
>
=
>
> I would like to request agenda time for:
>
>
&g=
t;
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
><=
br>>
> The document  presents use-cases underlining why WebRT=
C needs AMR-WB,  AMR
> and G.722 as additional relevant voice co=
decs to satisfactorily ensure
> interoperability with existing system=
s.
>
>
>
> A 10-minute time slot should be sufficie=
nt for presentation and discussion.
>
>
>
> Regards=

>
>
>
> -Espen
>
>
>
>
=
>
>
> =
_______________________________________________
> 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/listinf=
o/rtcweb
&nbs=
p;
------------------------------------------=
--------------------------- 
This transmission (including any attachment=
s) may contain confidential information, privileged material (including mat=
erial protected by the solicitor-client or other applicable privileges), or=
 constitute non-public information. Any use of this information by anyone o=
ther than the intended recipient is prohibited. If you have received this t=
ransmission in error, please immediately reply to the sender and delete thi=
s information from your system. Use, dissemination, distribution, or reprod=
uction of this transmission by unintended recipients is not authorized and =
may be unlawful. 

My 2 =
cents,

Simon

Thx,
Jonathan =
R.
-- 



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



      =
               				=
	   =
    _\\|//_
          =
                 				=
      ( O-O )
  =
 ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                  =
  				=
Simon Pietro Romano
          =
    Universita' di Napoli =
Federico II
              =
  	=
	     Computer Engineering =
Department 
	         =
    Phone: +39 081 7683823 -- Fax: +39 081 =
7683816
              =
                    =
         e-mail: spromano@unina.it

		=
    <<Molti mi dicono che lo scoraggiamento =CB =
l'alibi degli 
		   =
 idioti. Ci rifletto un istante; e mi scoraggio>>. =
Magritte.
             =
  			=
                  =
   oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   =
)~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
				=
	                =
 \ (            (   =
)
	=
		              =
                    =
\_)          ) /
      =
                    =
                    =
                    =
     (_/








=

--Apple-Mail=_F89EA3D1-4809-4927-AB1F-D54BB85D3083--

From lorenzo@meetecho.com  Wed Mar 13 16:55: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 D6EAA21F8C1F for ; Wed, 13 Mar 2013 16:55:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level: 
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIrGqCKzKsZz for ; Wed, 13 Mar 2013 16:55:46 -0700 (PDT)
Received: from smtpdg10.aruba.it (smtpdg5.aruba.it [62.149.158.235]) by ietfa.amsl.com (Postfix) with ESMTP id 323E821F8C1A for ; Wed, 13 Mar 2013 16:55:44 -0700 (PDT)
Received: from lminiero-acer ([130.129.133.212]) by smtpcmd05.ad.aruba.it with bizsmtp id BBvg1l00M4b720a01BvhkM; Thu, 14 Mar 2013 00:55:42 +0100
Date: Thu, 14 Mar 2013 00:55:28 +0100
From: Lorenzo Miniero 
To: Jonathan Rosenberg 
Message-ID: <20130314005528.1420e4e9@lminiero-acer>
In-Reply-To: 
References: 
Organization: Meetecho
X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] A different perspective on the video codec MTI 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, 13 Mar 2013 23:55:46 -0000

Il giorno Wed, 13 Mar 2013 18:06:47 -0400
Jonathan Rosenberg  ha scritto:

> I have one more thing to say - speaking now as a developer.
> 
> As some of you may know, I recently returned to Cisco as CTO of the
> cloud collaboration group, which is responsible for Webex. Webex was
> one of the first services to do voice and video on the web, using
> plugins of course. For our business, a key requirement is
> interoperability with other video systems in the Cisco portfolio,
> including our video clients and telepresence units. Those are all
> based on H.264. Consequently, much as I would like to avoid the need
> for a plugin, the benefits of eliminating the plugin do not outweigh
> the drawbacks of having to transcode from VP8 to H.264. If IETF
> selects VP8 as the MTI codec, this will make it dramatically more
> difficult and expensive for us to use webRTC. If H.264 is the MIT
> codec, it will make it much easier for us to use webRTC.
> 

Speaking as a developer working for a company with much less money than
yours, if the IETF selects H.264 as the MTI codec, this will make it
even more dramatically difficult and expensive (if not impossible) for
pretty much everybody else to use webRTC, or at least to develop
services based on it.

Lorenzo

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

From juberti@google.com  Wed Mar 13 16: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 4212D21F8C3B for ; Wed, 13 Mar 2013 16:58:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.168
X-Spam-Level: 
X-Spam-Status: No, score=-100.168 tagged_above=-999 required=5 tests=[AWL=2.492, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, 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 yXEusAtFE0lx for ; Wed, 13 Mar 2013 16:58:43 -0700 (PDT)
Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id C40D221F8C35 for ; Wed, 13 Mar 2013 16:58:42 -0700 (PDT)
Received: by mail-qe0-f50.google.com with SMTP id k5so945198qej.23 for ; Wed, 13 Mar 2013 16:58:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Jyu3tOKR8uwD5vAYG5nfQJGvl2PJskSs0rzfq5AgMUk=; b=QQJ8kegp7WqZLumTPf4E58JBdGtb/QrRZ5JHxsHXlkmGktA7JFCmjavrh2DbqkypXV pFzM+fLGCw4uKUmX1fyGsffgLjpLZ0bLyqasWzN4NDEwLH3j8bfhlPvFYPtqpYhq37FN vFNixve6dntP8Vw0jo+wKNYPHPo7OlhbST+YguQQpOeF7xgBf6l+m18wtDZy+W/aQW9Y cEbt9FnNEfwBo/6OzW8G8Uc6VJl5tMOzPFhtRv4GeRDdj1tJnNMqdMxqVmlKSwl2aJhI SWepeQ2X0iSOa23bJDyiZgwKqwq99kwFX0sKKrUJ74s5ztReEMla23rmK/Xi8rks6JB4 VcRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=Jyu3tOKR8uwD5vAYG5nfQJGvl2PJskSs0rzfq5AgMUk=; b=Qx7tqx1g4oeYUjcnULDj+SrU40SypHxLrSAqoQUnKdBH+HKl4LHW0Oq3LezS45CQBQ oaPpAKQ+4mDR7U0sE6RYc3lvVmxdkJBFbSJeXo0+sjA3Djxt9A5pT79BjrMit7+HZI9U ptUWF214RYDl9WiyagHm3C9/iGqkkqlAGeUj03K5W6lNic7cFFisH0vy6HgU7n/LOD0i 4VgC/9PsAKMOmpdwKDDSHNQa6NU5XEYnRTmdwv+F3RAtR1HPpftHtspJ1MRH+AzBbLLo hyKV8zeh7saEcLHp8PUoN6KgtUZEAH19MMaTdnlnPgV4bifyd61uwOW0w11PMNu8tlRj Bb4w==
X-Received: by 10.224.71.16 with SMTP id f16mr1251341qaj.31.1363219122263; Wed, 13 Mar 2013 16:58:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.197.131 with HTTP; Wed, 13 Mar 2013 16:58:22 -0700 (PDT)
In-Reply-To: 
References:    
From: Justin Uberti 
Date: Wed, 13 Mar 2013 16:58:22 -0700
Message-ID: 
To: Jonathan Rosenberg 
Content-Type: multipart/alternative; boundary=bcaec51b1b9788a21904d7d72fe3
X-Gm-Message-State: ALoCoQl4mgzSeMLoKqsIjORDGrppYvcPQl5HXygCoeX/o1Lh0KdkrdqRIL5mPOwr9OfFSAHfTTdwNNzbsxdcMa3VhHPJCK6KlyIhsp/kstZp66SO8jUkR7eyA13z28jisET2J9qVWtMfz0EQSH5tqCGTXJuTGzVK2IXZXDqI3Av+NPh/qp9pvepEmIUsLIoFhFgF+6uuzOUp
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] A different perspective on the video codec MTI 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, 13 Mar 2013 23:58:44 -0000

--bcaec51b1b9788a21904d7d72fe3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

As I mentioned, hundreds of millions of mobile endpoints will support
WebRTC and VP8 within weeks.

The mobile-device-hardware-codec argument is a non-starter to me, since as
you know, the popular realtime video applications on these platforms
already use software codecs in the vast majority of cases. Regardless,
Android devices have been shipping with HW VP8 codecs for some time now.


On Wed, Mar 13, 2013 at 4:44 PM, Jonathan Rosenberg wr=
ote:

> Justin - my point is that there are non-web endpoints that people care
> about - including most importantly mobile endpoints. Its not just about
> pure numbers, its about reaching users on the devices/platforms they need
> to be reached on.
>
> Surely you don't mean that its not important for developers (like Webex)
> to reach users on mobile clients or other video systems outside of the we=
b?
>
> Thx,
> Jonathan R.
>
>
> On Wed, Mar 13, 2013 at 6:54 PM, Silvia Pfeiffer <
> silviapfeiffer1@gmail.com> wrote:
>
>> Also, it is worth pointing out that h.264 cannot meet the RF requirement=
s
>> of W3C, so the only alternatives we can look at are VP8 or delaying the
>> decision for an MTI until the market decides.
>>
>> I'd rather we specify for an environment 5 years down the track (and giv=
e
>> companies like CISCO a reason to replace all their old devices with new
>> ones that support VP8) than continuing decision avoidance.
>>
>> Regards,
>> Silvia.
>> (Speaking for myself)
>> On 14 Mar 2013 09:42, "Justin Uberti"  wrote:
>>
>>> Regarding your comment on the "web today", I think it is worthwhile to
>>> point out that within weeks, there will be 2B+ deployed WebRTC endpoint=
s,
>>> across desktop and mobile, that support VP8.
>>>
>>> Surely that dwarfs the total number of deployed H.264 endpoints by
>>> several orders of magnitude.
>>>
>>>
>>> On Wed, Mar 13, 2013 at 3:06 PM, Jonathan Rosenberg >> > wrote:
>>>
>>>> I=E2=80=99d like to put a different perspective on the video MTI discu=
ssion.
>>>>
>>>> Much of the discussion has been around video quality, IPR, and
>>>> standardization status. While those are all important factors, to me t=
hey
>>>> are secondary to the core question: how does the choice impact uptake =
of
>>>> the webRTC APIs and protocols by developers who build applications ont=
op of
>>>> it? In this regard, I would like to suggest that, at this time, adopti=
on of
>>>> VP8 as MTI will slow down adoption of webRTC by turning off developers=
 that
>>>> would otherwise embrace it if H.264 were selected.
>>>>
>>>> The reason is simple. For many application developers, what is
>>>> interesting about webRTC is NOT just browser to browser communications=
, but
>>>> connecting users in a browser to users elsewhere - on other devices, i=
n
>>>> other networks. After all, the vast majority of web application develo=
pers
>>>> do not have the luxury of a massive social graph, or the luxury of the=
ir
>>>> users being parked persistently on their website and thus able to rece=
ive
>>>> an incoming call. Many websites that have customer support or service =
needs
>>>> would love to be able to allow their users to have a video call with a=
n
>>>> agent. However, those agents are probably sitting on existing agent sy=
stems
>>>> which are not web based, and it=E2=80=99s almost certainly true that t=
hey do not
>>>> today support VP8, but rather H.264. Many developers would probably lo=
ve to
>>>> connect users on the web with users on mobile apps. Most mobile platfo=
rms
>>>> today support H264 based hardware acceleration for decode and sometime=
s
>>>> encode, but not yet VP8. Developers who want to build business
>>>> communications clients will need to connect those users with other use=
rs in
>>>> the business, who may be using videophones, PC clients, telepresence u=
nits
>>>> or video room systems, the vast majority of which do not support VP8 t=
oday,
>>>> but many of which do support H.264.
>>>>
>>>> The reality is =E2=80=93 today=E2=80=99s Internet and IP communication=
s systems are
>>>> built on H.264. And unless the developer cares only about living withi=
n the
>>>> island of the web browser =E2=80=93 a VP8 based solution will simply n=
ot meet their
>>>> requirements.
>>>>
>>>> This may not be true down the road. I applaud Google for working hard
>>>> (and spending much money no doubt) to secure an RF license for VP8 fro=
m
>>>> these patent holders. I think they should continue pushing and promoti=
ng
>>>> the technology because a  free, high quality video codec would be grea=
t for
>>>> the Internet. But today, it is not the video codec of the Internet. An=
d,
>>>> given the relatively early days of video, I am sure there will be vide=
o
>>>> codecs after VP8. Maybe H.265, maybe the new video codec being develop=
ed
>>>> here at the IETF. And once those codecs become more broadly implemente=
d and
>>>> available on the endpoints that matter, we can revise our specs and ma=
ndate
>>>> support for them. But this is not about the web of five years from now=
, its
>>>> about the web today. And if we mandate usage of a codec which is not w=
idely
>>>> implemented in all the endpoints that matter (not just the browser), I=
 fear
>>>> that it will hold developers back from using webRTC and thus prevent u=
s
>>>> from ever having the opportunity to add these video codecs in the futu=
re.
>>>>
>>>>
>>>>
>>>> And so =E2=80=93 to the supporters of VP8 =E2=80=93 I applaud your eff=
orts and thank
>>>> you for them. Please continue. And when the industry is ready, we can =
make
>>>> VP8 MTI in the browser. But we are not there yet.  I ask you to please=
 put
>>>> the needs of the developers ahead of your own, and do not hold back we=
bRTC
>>>> for the benefit of your ideals around an RF and open source video code=
c.
>>>> WebRTC is too important for that.
>>>>
>>>> I have one more thing to say - speaking now as a developer.
>>>>
>>>> As some of you may know, I recently returned to Cisco as CTO of the
>>>> cloud collaboration group, which is responsible for Webex. Webex was o=
ne of
>>>> the first services to do voice and video on the web, using plugins of
>>>> course. For our business, a key requirement is interoperability with o=
ther
>>>> video systems in the Cisco portfolio, including our video clients and
>>>> telepresence units. Those are all based on H.264. Consequently, much a=
s I
>>>> would like to avoid the need for a plugin, the benefits of eliminating=
 the
>>>> plugin do not outweigh the drawbacks of having to transcode from VP8 t=
o
>>>> H.264. If IETF selects VP8 as the MTI codec, this will make it dramati=
cally
>>>> more difficult and expensive for us to use webRTC. If H.264 is the MIT
>>>> codec, it will make it much easier for us to use webRTC.
>>>>
>>>>
>>>> Thx,
>>>>
>>>> Jonathan R.
>>>> --
>>>> Jonathan Rosenberg, Ph.D.
>>>> jdrosen@jdrosen.net
>>>> http://www.jdrosen.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
>>>
>>>
>
>
> --
> Jonathan Rosenberg, Ph.D.
> jdrosen@jdrosen.net
> http://www.jdrosen.net
>

--bcaec51b1b9788a21904d7d72fe3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


As I mentioned, hundreds of millions of mobile endpoints w=
ill support WebRTC and VP8 within weeks.=C2=A0

The mobil=
e-device-hardware-codec argument is a non-starter to me, since as you know,=
 the popular realtime video applications on these platforms already use sof=
tware codecs in the vast majority of cases. Regardless, Android devices hav=
e been shipping with HW VP8 codecs for some time now.






On Wed, Mar 1=
3, 2013 at 4:44 PM, Jonathan Rosenberg <jdrosen@jdrosen.net> wrote:




Justin - my point is that t=
here are non-web endpoints that people care about - including most importan=
tly mobile endpoints. Its not just about pure numbers, its about reaching u=
sers on the devices/platforms they need to be reached on.=C2=A0





Surely you don't mean that its not important for develop=
ers (like Webex) to reach users on mobile clients or other video systems ou=
tside of the web?

Thx,


Jonathan R.


On Wed, Mar 13, 2013 at 6:54 PM, Silvia Pfeiffer <=
span dir=3D"ltr"><silviapfeiffer1@gmail.com> wrote:





Also, it is worth pointing ou=
t that h.264 cannot meet the RF requirements of W3C, so the only alternativ=
es we can look at are VP8 or delaying the decision for an MTI until the mar=
ket decides. 






I'd rather we specify for an environment 5 years down th=
e track (and give companies like CISCO a reason to replace all their old de=
vices with new ones that support VP8) than continuing decision avoidance.






Regards,

Silvia.

(Speaking for myself)


On 14 Mar 2013 09:42, "Justin Uberti" =
<juberti@google.=
com> wrote:






Regarding your comment on the "web today", I thi=
nk it is worthwhile to point out that within weeks, there will be 2B+ deplo=
yed WebRTC endpoints, across desktop and mobile, that support VP8.=C2=A0








Surely that dwarfs the total number of deployed H.264 endpoints =
by several orders of magnitude.



On Wed, Mar 1=
3, 2013 at 3:06 PM, Jonathan Rosenberg <jdrosen@jdrosen.net> wrote:









I=E2=80=99d like t=
o put a different
perspective on the video MTI discussion.



Much of the discussion has been
around video quality, IPR, and standardization status. While those are all
important factors, to me they are secondary to the core question: how does =
the
choice impact uptake of the webRTC APIs and protocols by developers who bui=
ld applications ontop of it? In this regard, I would like to suggest that, =
at this
time, adoption of VP8 as MTI will slow down adoption of webRTC by
turning off developers that would otherwise embrace it if H.264 were select=
ed.
The reason is simple. For many
application developers, what is interesting about webRTC is NOT just browse=
r to
browser communications, but connecting users in a browser to users elsewher=
e - on other devices, in other networks.
After all, the vast majority of web application developers do not have the
luxury of a massive social graph, or the luxury of their users being parked
persistently on their website and thus able to receive an incoming call. Ma=
ny websites
that have customer support or service needs would love to be able to allow
their users to have a video call with an agent. However, those agents are
probably sitting on existing agent systems which are not web based, and it=
=E2=80=99s
almost certainly true that they do not today support VP8, but rather H.264.
Many developers would probably love to connect users on the web with users =
on
mobile apps. Most mobile platforms today support H264 based hardware accele=
ration
for decode and sometimes encode, but not yet VP8. Developers who want to bu=
ild
business communications clients will need to connect those users with other
users in the business, who may be using videophones, PC clients, telepresen=
ce
units or video room systems, the vast majority of which do not support VP8
today, but many of which do support H.264.



The reality is =E2=80=93 today=E2=80=99s Internet
and IP communications systems are built on H.264. And unless the developer
cares only about living within the island of the web browser =E2=80=93 a VP=
8 based
solution will simply not meet their requirements.



This may not be true down the
road. I applaud Google for working hard (and spending much money no doubt) =
to
secure an RF license for VP8 from these patent holders. I think they should
continue pushing and promoting the technology because a=C2=A0 free, high
quality video codec would be great for the Internet. But today, it is not t=
he
video codec of the Internet. And, given the relatively early days of video,=
 I
am sure there will be video codecs after VP8. Maybe H.265, maybe the new vi=
deo
codec being developed here at the IETF. And once those codecs become more
broadly implemented and available on the endpoints that matter, we can revi=
se
our specs and mandate support for them. But this is not about the web of fi=
ve
years from now, its about the web today. And if we mandate usage of a codec
which is not widely implemented in all the endpoints that matter (not just =
the browser), I fear that it
will hold developers back from using webRTC and thus prevent us from ever h=
aving
the opportunity to add these video codecs in the future.



=C2=A0



And so =E2=80=93 to the supporters of VP8
=E2=80=93 I applaud your efforts and thank you for them. Please continue. A=
nd when the
industry is ready, we can make VP8 MTI in the browser. But we are not there=
 yet.
=C2=A0I ask you to please put the needs of the developers ahead of your own=
,
and do not hold back webRTC for the benefit of your ideals around an RF and
open source video codec. WebRTC is too important for that.



I have one more thing to say - speaking now as a developer.=




As some of you may know, I
recently returned to Cisco as CTO of the cloud collaboration group, which i=
s
responsible for Webex. Webex was one of the first services to do voice and
video on the web, using plugins of course. For our business, a key requirem=
ent
is interoperability with other video systems in the Cisco portfolio, includ=
ing
our video clients and telepresence units. Those are all based on H.264.
Consequently, much as I would like to avoid the need for a plugin, the bene=
fits
of eliminating the plugin do not outweigh the drawbacks of having to transc=
ode
from VP8 to H.264. If IETF selects VP8 as the MTI codec, this will make it =
dramatically more difficult and expensive for us to use webRTC. If H.264 is=
 the MIT codec, it will make it much easier for us to use webRTC.=C2=A0











Thx,
Jonathan R.=

-- 




_______________________________________________

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







-- 
=











--bcaec51b1b9788a21904d7d72fe3--

From harald@alvestrand.no  Wed Mar 13 17:01: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 B7EF711E80E0 for ; Wed, 13 Mar 2013 17:01:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.637
X-Spam-Level: 
X-Spam-Status: No, score=-110.637 tagged_above=-999 required=5 tests=[AWL=-0.039, 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 A9OqfW2L--YV for ; Wed, 13 Mar 2013 17:01:06 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1DE11E80D3 for ; Wed, 13 Mar 2013 17:01:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 39B3839E1EE for ; Thu, 14 Mar 2013 01:01:05 +0100 (CET)
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 wye4RUYdBZUw for ; Thu, 14 Mar 2013 01:01:04 +0100 (CET)
Received: from [IPv6:2001:df8:0:16:dc4b:da73:da24:d309] (unknown [IPv6:2001:df8:0:16:dc4b:da73:da24:d309]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id BA32A39E0C8 for ; Thu, 14 Mar 2013 01:01:03 +0100 (CET)
Message-ID: <5141133D.3040100@alvestrand.no>
Date: Thu, 14 Mar 2013 01:01:01 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary="------------070406070008050004090204"
Subject: [rtcweb] Audio transcoding: CPU costs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 00:01:06 -0000

This is a multi-part message in MIME format.
--------------070406070008050004090204
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

To return to the question of "cost of transcoding":

- AMR is less complex to en/decode than OPUS. So the dominant cost of 
transcoding between OPUS and AMR is the OPUS operation.
- http://www.ietf.org/mail-archive/web/rtcweb/current/msg05236.html 
estimates that OPUS en/decode can be done at ~1000 channels per CPU.
- One machine for one minute on Amazon AWS costs 0.24 cents for a 
medium-sized "high-CPU instance" according to 
http://aws.amazon.com/ec2/pricing/ (0.145 dollars per hour).
- Accordingly, transcoding, if done on fully loaded Amazon AWS 
instances, adds ~0.00024 cents per minute to the cost of a call.

There are other ways to provide such a service. It seems unlikely to 
increase the CPU cost of the call by more than a factor of 100, so we're 
still below 0.024 cents per hour.

I know there are other arguments for avoiding transcoding. But calling 
the CPU cost "negligible" seems appropriate in a world where mobile 
non-"all you can eat" plans still sell for tens of cents per minute.


--------------070406070008050004090204
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    To return to the question of "cost of transcoding":

    

    - AMR is less complex to en/decode than OPUS. So the dominant cost
    of transcoding between OPUS and AMR is the OPUS operation.

    - http://www.ietf.org/mail-archive/web/rtcweb/current/msg05236.html
    estimates that OPUS en/decode can be done at ~1000 channels per CPU.

    - One machine for one minute on Amazon AWS costs 0.24 cents for a
    medium-sized "high-CPU instance" according to
    
    http://aws.amazon.com/ec2/pricing/
    (0.145 dollars per hour).

    - Accordingly, transcoding, if done on fully loaded Amazon AWS
    instances, adds ~0.00024 cents per minute to the cost of a call.

    

    There are other ways to provide such a service. It seems unlikely to
    increase the CPU cost of the call by more than a factor of 100, so
    we're still below 0.024 cents per hour.

    

    I know there are other arguments for avoiding transcoding. But
    calling the CPU cost "negligible" seems appropriate in a world where
    mobile non-"all you can eat" plans still sell for tens of cents per
    minute.

    

  


--------------070406070008050004090204--

From gerardmxf@yahoo.co.uk  Wed Mar 13 17:24: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 B145D21F8614 for ; Wed, 13 Mar 2013 17:24:37 -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 X-G3gyFfkfJe for ; Wed, 13 Mar 2013 17:24:36 -0700 (PDT)
Received: from nm24-vm3.bullet.mail.ird.yahoo.com (nm24-vm3.bullet.mail.ird.yahoo.com [212.82.109.194]) by ietfa.amsl.com (Postfix) with SMTP id 2E56321F860A for ; Wed, 13 Mar 2013 17:24:36 -0700 (PDT)
Received: from [212.82.105.224] by nm24.bullet.mail.ird.yahoo.com with NNFMP; 14 Mar 2013 00:24:35 -0000
Received: from [212.82.108.239] by tm20.bullet.mail.ird.yahoo.com with NNFMP; 14 Mar 2013 00:24:35 -0000
Received: from [127.0.0.1] by omp1004.mail.ird.yahoo.com with NNFMP; 14 Mar 2013 00:24:35 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 230912.32085.bm@omp1004.mail.ird.yahoo.com
Received: (qmail 85450 invoked by uid 60001); 14 Mar 2013 00:24:35 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1363220675; bh=CgR3WP/rKMMwMy9MmYn9ROP7FNgQP3hWzqAsJmMl1F8=; 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=Y+KW2w4I5U7CBtpYnAGbmb22hjR5Ei17b0LoE3niPaCi+veNjKrkPF097aj+WgYvBa4yyI4Fr9DKVQyWVBvpXnPf4KDrjjLi/2SNECSmZCSP3AVF8icYss0REI7P2bQrD2zJ+2tb5u8LqhWJDzf+S8oFpXhfmvbiScDtxMW2NSA=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; 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=Q/sz0cuAg67WuFuNlnJtDOJqS62iD8DwKo1/3k/9oVXrI+Mejcjiw2vUfEd2JxfSIBAIfZ2TAlx6Ht/kmFi+SBDY/LO0yz7mZscM2eeKU9W6LPXm7SKDOSICmwX4ADhqcQ+QVVVlrdkY3dL3FYcVmnTvF07gGVsNy7qp5Hrp8GY=;
X-YMail-OSG: JsF0FBAVM1l2moytQALH5cLt1Ar_NLdHcNrjg5VEki0cClz Jf9OWJYWOcQcNCWyqDztDFSjxOyTNztZlaG6nrus0iIhLJYTBh7a1S.ul2.9 NtRUxvlA65sy2OdlcyH6w1zf4yCFfLGfGDRPNAC918FOuydhGaA0G19C5rbl h8rQEvxsr06OoRAUfT_0KPbU1mQQFd243DQECBuK2chDm2Zp1f2r_15NBEsB 3g8idBg3L30nHyPYqYk9VmFwkL5Ytc3zMkt1DxuAx1gEBuS8TLgPoQubsMAu JLxdtq0p.xqq.rvtWz8wMu.R3Je3m_dNb6ZXO3AEd9N2JJ6Ox3px6ilj9Kv8 635b3g0xh.RDMuuYO1xqlIhW9PVAxEf7L3RGhTtO6jkFFs4Y41ZrubBJhl1b 1lLU1UwsIQrkxv0ziyUh2EQ6lghUE43lc4vSh3LtnEAA3fdi1E8jozKopQsL DI7ugPtsiJmtMJxUhlX7lBecRnuT0lJ.oY_G6p8E_FLYAJZf8P87MVUVySiN cXrN4ezeKOKh7C7on8m1qWK89jjhVMVxFS4bFvRZ1DqWV42La5ZyD.hn6HsB 6qMT5_..XjoV19TOO6A--
Received: from [99.113.35.251] by web132106.mail.ird.yahoo.com via HTTP; Thu, 14 Mar 2013 00:24:34 GMT
X-Rocket-MIMEInfo: 002.001, SGVsbG8gWUssClRoZSBkaXNjbG9zdXJlIHByb2Nlc3MgaW4gTVBFRyBpcyBub3QgYmFzZWQgb24gd2hvIHlvdSBhcmUsIG9yIG9uIHlvdXIgQnVzaW5lc3MgbW9kZWwuCgpLaW5kIHJlZ2FyZHMKCkdlcmFyZAoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEZyb206ICJXYW5nLCBZZS1LdWkiIDx5ZWt1aXdAcXRpLnF1YWxjb21tLmNvbT4KVG86IFN0b2NraGFtbWVyIFRob21hcyA8c3RvY2toYW1tZXJAbm9tb3IuZGU.OyBCbyBCdXJtYW4gPGJvLmJ1cm1hbkBlcmljc3Nvbi5jb20.IApDYzoBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.137.519
References: <513F68C0.4010106@ericsson.com>  <513F7745.3020302@alvestrand.no>    <8BA7D4CEACFFE04BA2D902BF11719A8331B17F22@nasanexd02f.na.qualcomm.com>
Message-ID: <1363220674.82166.YahooMailNeo@web132106.mail.ird.yahoo.com>
Date: Thu, 14 Mar 2013 00:24:34 +0000 (GMT)
From: Gerard Fernando 
To: "\"Wang, Ye-Kui\"" , "\"rtcweb@ietf.org\"" 
In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A8331B17F22@nasanexd02f.na.qualcomm.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-586199313-1905388920-1363220674=:82166"
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Gerard Fernando 
List-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, 14 Mar 2013 00:24:37 -0000

---586199313-1905388920-1363220674=:82166
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hello YK,=0AThe disclosure process in MPEG is not based on who you are, or =
on your Business model.=0A=0AKind regards=0A=0AGerard=0A=0A=0A=0A=0A_______=
_________________________=0A From: "Wang, Ye-Kui" =
=0ATo: Stockhammer Thomas ; Bo Burman  =0ACc: "rtcweb@ietf.org"  =0ASent: Wednesday, 13=
 March 2013, 10:40=0ASubject: Re: [rtcweb] Video Codec discussion in Thursd=
ay agenda slot=0A =0A> >=A0 How many others who did not respond to MPEG LA'=
s call but have IPR =0A> > are=0A> there?=0A> =0A> [TS]=A0 Just one more hy=
pothesis: If I would have, what would be my =0A> obligation/motivation to d=
o so now?=0A=0ASpeaking of the motivation part; that would depend on who YO=
U are and what kind of business model or plan YOU have in mind. =0A=0ABR, Y=
K=0A=0A> -----Original Message-----=0A> From: rtcweb-bounces@ietf.org [mail=
to:rtcweb-bounces@ietf.org] On Behalf=0A> Of Stockhammer Thomas=0A> Sent: W=
ednesday, March 13, 2013 7:53 AM=0A> To: Bo Burman=0A> Cc: rtcweb@ietf.org=
=0A> Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot=
=0A> =0A> =0A> >=A0 How many others who did not respond to MPEG LA's call b=
ut have IPR are=0A> there?=0A> =0A> [TS]=A0 Just one more hypothesis: If I =
would have, what would be my=0A> obligation/motivation to do so now?=0A> =
=0A> >>>=0A> >>> We appreciate the need to have time to evaluate the specif=
ic words=0A> >>> of the license statements that are forthcoming, and the ne=
ed for the=0A> >>> people who haven't made their IPR declarations over the =
last couple=0A> >>> of years of discussion to do so within the next couple =
of weeks -=0A> >>> but we do think that it is important to use the face to =
face time=0A> >>> that we have here in Orlando to lay to rest any *other* i=
ssues than=0A> >>> the licensing terms and other issues derived from Google=
's=0A> announcement.=0A> >>=0A> >> I am not sure we can have a reasoned con=
sideration of 'other issues=0A> derived'=0A> >> at such short notice.=0A> >=
>=0A> >> Look, I'd like our discussions and decisions to be informed and=0A=
> >> considered, and there simply isn't time for either.=0A> >>=0A> >>>=0A>=
 >>> Harald=0A> >>>=0A> >>> _______________________________________________=
=0A> >>> rtcweb mailing list=0A> >>> rtcweb@ietf.org=0A> >>> https://www.ie=
tf.org/mailman/listinfo/rtcweb=0A> >>=0A> >> David Singer=0A> >> Multimedia=
 and Software Standards, Apple Inc.=0A> >>=0A> >> _________________________=
______________________=0A> >> rtcweb mailing list=0A> >> rtcweb@ietf.org=0A=
> >> https://www.ietf.org/mailman/listinfo/rtcweb=0A> >=0A> =0A> ---=0A> Dr=
. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49=0A> 89 9789=
80 02 || cell +491725702667 || http://www.nomor-research.com=0A> Nomor Rese=
arch GmbH=A0 -=A0 Sitz der Gesellschaft: M=FCnchen - Registergericht:=0A> M=
=FCnchen, HRB 165856 - Umsatzsteuer-ID: DE238047637 - Gesch=E4ftsf=FChrer:=
=0A> Dr. Thomas Stockhammer, Dr. Ingo Viering.=0A> =0A> =0A> =0A> _________=
______________________________________=0A> rtcweb mailing list=0A> rtcweb@i=
etf.org=0A> https://www.ietf.org/mailman/listinfo/rtcweb=0A________________=
_______________________________=0Artcweb mailing list=0Artcweb@ietf.org=0Ah=
ttps://www.ietf.org/mailman/listinfo/rtcweb
---586199313-1905388920-1363220674=:82166
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


---586199313-1905388920-1363220674=:82166--

From prvs=078531ca1b=aallen@blackberry.com  Wed Mar 13 19:11: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 1A35521F8E57 for ; Wed, 13 Mar 2013 19:11:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.286
X-Spam-Level: 
X-Spam-Status: No, score=-5.286 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 Wa-yRbVvRufP for ; Wed, 13 Mar 2013 19:11:15 -0700 (PDT)
Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id D6DC621F8E55 for ; Wed, 13 Mar 2013 19:11:14 -0700 (PDT)
X-AuditID: 0a412830-b7ef86d00000339d-6c-514131bb57c1
Received: from XCT103ADS.rim.net (xct103ads.rim.net [10.67.111.44]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 46.19.13213.BB131415; Wed, 13 Mar 2013 21:11:07 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT103ADS.rim.net ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 21:11:07 -0500
From: Andrew Allen 
To: "lorenzo@meetecho.com" , "jdrosen@jdrosen.net" 
Thread-Topic: [rtcweb] A different perspective on the video codec MTI discussion
Thread-Index: AQHOIDcSOkRmQf4WtE6ygJUWSvBGGJikn90A///SE+U=
Date: Thu, 14 Mar 2013 02:11:06 +0000
Message-ID: 
In-Reply-To: <20130314005528.1420e4e9@lminiero-acer>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.253]
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLKsWRmVeSWpSXmKPExsXC5Zyvo7vb0DHQ4PgyY4vm58vYLbZvWcBk sfZfO7sDs8eSJT+ZPFrXz2T06Hh4nz2AOaqB0SYpsaQsODM9T9/OJjEvL78ksSRVISW1ONlW ySc1PTFHIaAosywxuVLBJbM4OScxMze1SEkhM8VWyURJoSAnMTk1NzWvxFYpsaAgNS9FyY5L AQPYAJVl5imk5iXnp2TmpdsqeQb761pYmFrqGirZ6SZ08mS8OmtacEGgYl23aQPjPt4uRk4O CQETiVlzNrJD2GISF+6tZ+ti5OIQEmhjkpjzaRozhLOZUWL5mxtgVWwCWhL7D09nArFFBBIk Hk06yAZiMwuoS9xZfA6sRlggUGLrlN2MEDVBEp/O3WGBsK0kVm06C2azCKhKrHw/C6ieg4NX wEPiQK8DSJgT6KCt0/rAxjMKyErsPnudCWK8uMStJ/OZIA4VkFiy5zwzhC0q8fLxP1YIW1Hi 797vrBD1ehI3pk6BOk1bYtnC12D1vAKCEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypGwdyM YgMzw+S8ZL2izFy9vNSSTYyg9OCoYbCD8f17i0OMAhyMSjy84sqOgUKsiWXFlbmHGCU4mJVE eA/KAoV4UxIrq1KL8uOLSnNSiw8xugIDYiKzFHdyPjB15ZXEGxsY4OYoifOKBIoGCgmkAxNP dmpqQWoRzBwmDk6QPVxSIsXA9JFalFhakhEPSnLxxcA0J9XAuE62UG+HwrppFnLJlx7k8YUd uckalP0oTaYu6PfcpMBrRZ/jWT7qbL6u785c3rSC6XrsgdhLKof8rjfPPT/fw+Sylr8+NwOD nVyl9vQ2ZU4pkeWcd+oKnndUHZ7DU9zqnyCZxGCpLRvjXy2UIWdTp//m9i5Rzn2PL+vtmhIx Re1H6Iet9guUWIozEg21mIuKEwFi0L4oUAMAAA==
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] A different perspective on the video codec MTI 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: Thu, 14 Mar 2013 02:11:16 -0000

Lorenzo

A good piece of advice when shopping is to always beware of the places where=
 the price is not well advertised - the fact that the price is not known in=
 advance does not mean its free - and often quite the opposite!

Andrew

----- Original Message -----
From: Lorenzo Miniero [mailto:lorenzo@meetecho.com]
Sent: Wednesday, March 13, 2013 06:55 PM Central Standard Time=0A=
To: Jonathan Rosenberg 
Cc: rtcweb@ietf.org 
Subject: Re: [rtcweb] A different perspective on the video codec MTI discuss=
ion

Il giorno Wed, 13 Mar 2013 18:06:47 -0400
Jonathan Rosenberg  ha scritto:

> I have one more thing to say - speaking now as a developer.
> 
> As some of you may know, I recently returned to Cisco as CTO of the
> cloud collaboration group, which is responsible for Webex. Webex was
> one of the first services to do voice and video on the web, using
> plugins of course. For our business, a key requirement is
> interoperability with other video systems in the Cisco portfolio,
> including our video clients and telepresence units. Those are all
> based on H.264. Consequently, much as I would like to avoid the need
> for a plugin, the benefits of eliminating the plugin do not outweigh
> the drawbacks of having to transcode from VP8 to H.264. If IETF
> selects VP8 as the MTI codec, this will make it dramatically more
> difficult and expensive for us to use webRTC. If H.264 is the MIT
> codec, it will make it much easier for us to use webRTC.
> 

Speaking as a developer working for a company with much less money than
yours, if the IETF selects H.264 as the MTI codec, this will make it
even more dramatically difficult and expensive (if not impossible) for
pretty much everybody else to use webRTC, or at least to develop
services based on it.

Lorenzo

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From cb.list6@gmail.com  Wed Mar 13 19:26: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 10E3821F8ABD for ; Wed, 13 Mar 2013 19:26:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.431
X-Spam-Level: 
X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168,  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 82+Bpb8rjKfn for ; Wed, 13 Mar 2013 19:26:50 -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 778ED21F8ABA for ; Wed, 13 Mar 2013 19:26:49 -0700 (PDT)
Received: by mail-we0-f180.google.com with SMTP id k14so1616078wer.25 for ; Wed, 13 Mar 2013 19:26:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BdaZksrPrTjbuQSKZKF2qUEW1C7kP7qTTV50o4BMulw=; b=T28Zv5R/n3yp703RF5CwGvL7G5XF7vuradY299PyrGVTRaLJqRH46WUpkzi/XAziXv P5BJLUgOk0P7ILMR2FW1XTWgYoShKesqb9BUa2cgkmukPaZudVavKiZtAi6Hzr9JRl30 j1PIZWb96v9JcGajrKsG9ijeVzVQDbikOADZZ29A/pNKOlGKcp1VK0I4wn5Ua9olm2x2 FxKwHMEquJJPbvAujxMIn4WPu2c8BKwNTDdXLh4UTRkxd2y0pauwScUJwfrm8Q3FeYfw JN40ZG0cZ6wwrAG7Cl4ySzlgHzIzTF1gk6bLLQI/UX4fWwtHXLlKdPWVSMtfTpTdPlS8 3NbQ==
MIME-Version: 1.0
X-Received: by 10.180.105.99 with SMTP id gl3mr891622wib.22.1363228008619; Wed, 13 Mar 2013 19:26:48 -0700 (PDT)
Received: by 10.194.20.35 with HTTP; Wed, 13 Mar 2013 19:26:48 -0700 (PDT)
Received: by 10.194.20.35 with HTTP; Wed, 13 Mar 2013 19:26:48 -0700 (PDT)
In-Reply-To: 
References: <20130314005528.1420e4e9@lminiero-acer> 
Date: Wed, 13 Mar 2013 19:26:48 -0700
Message-ID: 
From: Cameron Byrne 
To: Andrew Allen 
Content-Type: multipart/alternative; boundary=f46d04426d7633a67104d7d94121
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] A different perspective on the video codec MTI 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: Thu, 14 Mar 2013 02:26:51 -0000

--f46d04426d7633a67104d7d94121
Content-Type: text/plain; charset=ISO-8859-1

On Mar 13, 2013 7:11 PM, "Andrew Allen"  wrote:
>
>
>
> Lorenzo
>
> A good piece of advice when shopping is to always beware of the places
where the price is not well advertised - the fact that the price is not
known in advance does not mean its free - and often quite the opposite!
>
> Andrew
>
Since we are handing out advice.

Here is another piece if advice.

If it's free, take 2.

CB
> ----- Original Message -----
> From: Lorenzo Miniero [mailto:lorenzo@meetecho.com]
> Sent: Wednesday, March 13, 2013 06:55 PM Central Standard Time
> To: Jonathan Rosenberg 
> Cc: rtcweb@ietf.org 
> Subject: Re: [rtcweb] A different perspective on the video codec MTI
discussion
>
> Il giorno Wed, 13 Mar 2013 18:06:47 -0400
> Jonathan Rosenberg  ha scritto:
>
> > I have one more thing to say - speaking now as a developer.
> >
> > As some of you may know, I recently returned to Cisco as CTO of the
> > cloud collaboration group, which is responsible for Webex. Webex was
> > one of the first services to do voice and video on the web, using
> > plugins of course. For our business, a key requirement is
> > interoperability with other video systems in the Cisco portfolio,
> > including our video clients and telepresence units. Those are all
> > based on H.264. Consequently, much as I would like to avoid the need
> > for a plugin, the benefits of eliminating the plugin do not outweigh
> > the drawbacks of having to transcode from VP8 to H.264. If IETF
> > selects VP8 as the MTI codec, this will make it dramatically more
> > difficult and expensive for us to use webRTC. If H.264 is the MIT
> > codec, it will make it much easier for us to use webRTC.
> >
>
> Speaking as a developer working for a company with much less money than
> yours, if the IETF selects H.264 as the MTI codec, this will make it
> even more dramatically difficult and expensive (if not impossible) for
> pretty much everybody else to use webRTC, or at least to develop
> services based on it.
>
> Lorenzo
>
> --
> Lorenzo Miniero, COB
>
> Meetecho s.r.l.
> Web Conferencing and Collaboration Tools
> http://www.meetecho.com
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from
your system. Use, dissemination, distribution, or reproduction of this
transmission by unintended recipients is not authorized and may be unlawful.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

--f46d04426d7633a67104d7d94121
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On Mar 13, 2013 7:11 PM, "Andrew Allen" <aallen@blackberry.com> wrote:

>

>

>

> Lorenzo

>

> A good piece of advice when shopping is to always beware of the places=
 where the price is not well advertised - the fact that the price is not kn=
own in advance does not mean its free - and often quite the opposite!


>

> Andrew

>

Since we are handing out advice. 


Here is another piece if advice. 


If it's free, take 2.=A0 


CB

> ----- Original Message -----

> From: Lorenzo Miniero [mailto:=
lorenzo@meetecho.com]

> Sent: Wednesday, March 13, 2013 06:55 PM Central Standard Time

> To: Jonathan Rosenberg <jdro=
sen@jdrosen.net>

> Cc: rtcweb@ietf.org <rtcweb@ietf.org>

> Subject: Re: [rtcweb] A different perspective on the video codec MTI d=
iscussion

>

> Il giorno Wed, 13 Mar 2013 18:06:47 -0400

> Jonathan Rosenberg <jdrosen@=
jdrosen.net> ha scritto:

>

> > I have one more thing to say - speaking now as a developer.

> >

> > As some of you may know, I recently returned to Cisco as CTO of t=
he

> > cloud collaboration group, which is responsible for Webex. Webex =
was

> > one of the first services to do voice and video on the web, using=


> > plugins of course. For our business, a key requirement is

> > interoperability with other video systems in the Cisco portfolio,=


> > including our video clients and telepresence units. Those are all=


> > based on H.264. Consequently, much as I would like to avoid the n=
eed

> > for a plugin, the benefits of eliminating the plugin do not outwe=
igh

> > the drawbacks of having to transcode from VP8 to H.264. If IETF
> > selects VP8 as the MTI codec, this will make it dramatically more=


> > difficult and expensive for us to use webRTC. If H.264 is the MIT=


> > codec, it will make it much easier for us to use webRTC.

> >

>

> Speaking as a developer working for a company with much less money tha=
n

> yours, if the IETF selects H.264 as the MTI codec, this will make it
> even more dramatically difficult and expensive (if not impossible) for=


> pretty much everybody else to use webRTC, or at least to develop

> services based on it.

>

> Lorenzo

>

> --

> Lorenzo Miniero, COB

>

> Meetecho s.r.l.

> Web Conferencing and Collaboration Tools

> http://www.meetecho.com

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.i=
etf.org/mailman/listinfo/rtcweb

>

> ---------------------------------------------------------------------<=
br>
> This transmission (including any attachments) may contain confidential=
 information, privileged material (including material protected by the soli=
citor-client or other applicable privileges), or constitute non-public info=
rmation. Any use of this information by anyone other than the intended reci=
pient is prohibited. If you have received this transmission in error, pleas=
e immediately reply to the sender and delete this information from your sys=
tem. Use, dissemination, distribution, or reproduction of this transmission=
 by unintended recipients is not authorized and may be unlawful.


> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.i=
etf.org/mailman/listinfo/rtcweb




--f46d04426d7633a67104d7d94121--

From ted.ietf@gmail.com  Wed Mar 13 20: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 0F88111E809C for ; Wed, 13 Mar 2013 20:00:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Level: 
X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.012,  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 NOKfFANdYWj9 for ; Wed, 13 Mar 2013 20:00:31 -0700 (PDT)
Received: from mail-ia0-x234.google.com (mail-ia0-x234.google.com [IPv6:2607:f8b0:4001:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 6769821F8AA6 for ; Wed, 13 Mar 2013 20:00:31 -0700 (PDT)
Received: by mail-ia0-f180.google.com with SMTP id f27so1608383iae.25 for ; Wed, 13 Mar 2013 20:00:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=rwOcSthRIyRoUyWuoA4rlXbIKkIq/Zis34Wr2F8N5ac=; b=RoJFpx4D3xudOF7j/s/ZO90M3BBWf5gqS6A5wRWhAspzDXVbcD49cA9GeOlaaeHAPX 2/pNzP17JWFJZYH2TkIHEp6DAbZDVX9z6oYXh5+idsWnEaBdQbAPQnzSLzATfojcxGK6 9tbfnWCabhhuJQhqz1LBpxqV3l0mlGCxBRdTZhOFP0kc5gW+ZJ9M/UlzCyFH3Bw6aAqB DhEO1Vkx82/+i7VJ1gBwbBosqTaCCAtvB73YmB6mfrasO86B2+NO7+ohazLYuxgom2tB UHLNF66Jf9Unpq+wro2AoJaMciTye5PBVv+2Ju8EU5la/NaAESOS9bCV27fUu8CLzd0B aTmQ==
MIME-Version: 1.0
X-Received: by 10.42.201.73 with SMTP id ez9mr665777icb.29.1363230031008; Wed, 13 Mar 2013 20:00:31 -0700 (PDT)
Received: by 10.43.135.202 with HTTP; Wed, 13 Mar 2013 20:00:30 -0700 (PDT)
In-Reply-To: 
References: 
Date: Wed, 13 Mar 2013 23:00:30 -0400
Message-ID: 
From: Ted Hardie 
To: Jonathan Rosenberg 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] A different perspective on the video codec MTI 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: Thu, 14 Mar 2013 03:00:32 -0000

Hi Jonathan,

A quick comment in-line

On Wed, Mar 13, 2013 at 6:06 PM, Jonathan Rosenberg  wrote:
> The reason is simple. For many application developers, what is interesting
> about webRTC is NOT just browser to browser communications, but connecting
> users in a browser to users elsewhere - on other devices, in other networks.
> After all, the vast majority of web application developers do not have the
> luxury of a massive social graph, or the luxury of their users being parked
> persistently on their website and thus able to receive an incoming call.
> Many websites that have customer support or service needs would love to be
> able to allow their users to have a video call with an agent. However, those
> agents are probably sitting on existing agent systems which are not web
> based,

I've made the cut here because the point I want to make isn't really
codec specific. It's that the core requirement of this working group
is laid out as enabling a new real time platform based on the web.
That's set out in the charter in this language:

"There are a number of proprietary implementations that provide direct
    interactive rich communication using audio, video, collaboration,
    games, etc. between two peers' web-browsers. These are not
    interoperable, as they require non-standard extensions or plugins to
    work.  There is a desire to standardize the basis for such
    communication so that interoperable communication can be established
    between *any compatible browsers*. The goal is to enable innovation on
    top of a set of basic components.  One core component is to enable
    real-time media like audio and video, a second is to enable data
    transfer directly between clients."

The emphasis on "*any compatible browsers*" is mine.  That is the
focus of the work; that new, web-based ecology is its reason for
being.

We have understood from the beginning that there are many other
endpoints that it would be useful to interconnect with browsers, but
we have also understood that some choices would mean that those
connections would likely travel through gateways.  There may be agent
systems like those you describe above that are capable of DTLS-SRTP,
continued consent based on ICE, and all the other pieces of our
overall system, but there are certainly also many that are not.
Gatewaying will be common, and I personally hope companies with
histories of producing successful middle boxes enter the market with a
will.

WebRTC will not produce a successful new ecology if it focuses its
technical decisions on full interoperability with non-WebRTC systems;
while the initial opportunity looks bigger, it is ultimately something
that circumscribes the possibilities for success.  You and I have both
seen the complications which arise from following that path, and this
group and its W3C partner group made a conscious decision not to
require it.  Time will tell if the choice was the right one, but, in
the mean time, the charter is clear.  I personally think that was the
right choice, and it is certainly, for me, the more exciting
possibility.

Speaking as an individual, not as chair,

regards,

Ted Hardie

From prvs=7785b5ae25=aallen@blackberry.com  Wed Mar 13 20:03: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 1AB2011E80A4 for ; Wed, 13 Mar 2013 20:03:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.981
X-Spam-Level: 
X-Spam-Status: No, score=-5.981 tagged_above=-999 required=5 tests=[AWL=0.617,  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 z-joCmA+2bfF for ; Wed, 13 Mar 2013 20:03:14 -0700 (PDT)
Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5A67A11E80A3 for ; Wed, 13 Mar 2013 20:03:14 -0700 (PDT)
X-AuditID: 0a41282f-b7fa06d000002431-d8-51413de5a808
Received: from XCT102ADS.rim.net (xct102ads.rim.net [10.67.111.43]) by mhs060cnc.rim.net (SBG) with SMTP id C9.B8.09265.5ED31415; Wed, 13 Mar 2013 22:03:01 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT102ADS.rim.net ([fe80::4806:2e1d:2b7c:cfdf%22]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 22:03:01 -0500
From: Andrew Allen 
To: "cb.list6@gmail.com" 
Thread-Topic: [rtcweb] A different perspective on the video codec MTI discussion
Thread-Index: AQHOIDcSOkRmQf4WtE6ygJUWSvBGGJikn90A///SE+WAAFg1AP//tkz4
Date: Thu, 14 Mar 2013 03:03:00 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.253]
Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338D2906DXMB104ADSrimnet_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDKsWRmVeSWpSXmKPExsXC5ZyvrfvU1jHQ4OQ8U4tVXz4yWTQ/X8Zu sX3LAiaLtf/a2R1YPHbOusvusWTJTyaP1vUzGT06Ht5nD2CJamC0SUosKQvOTM/Tt7NJzMvL L0ksSVVISS1OtlXySU1PzFEIKMosS0yuVHDJLE7OSczMTS1SUshMsVUyUVIoyElMTs1NzSux VUosKEjNS1Gy41LAADZAZZl5Cql5yfkpmXnptkqewf66FhamlrqGSna6CZ08GUfuLGcvWJRc cfLjV5YGxhMJXYycHBICJhKrVvQyQdhiEhfurWcDsYUEVjJKTNhU28XIBWRvZpT492QCI0iC TUBLYv/h6UANHBwiAroS10+kgNQwC7QySiycPJMVpEZYIFBi65TdYPUiAkESn87dYYGw3SSe 3LvJDGKzCKhKvHnbDraYV8BD4uPRnewgMzmBeuc/TwIJMwrISuw+ex2shFlAXOLWk/lQdwpI LNlznhnCFpV4+fgfK4StKPF373dWiPp8iU9LHzJCjBeUODnzCcsERpFZSEbNQlI2C0nZLKAr mAU0Jdbv0ocoUZSY0v2QHcLWkGidM5cdWXwBI/sqRsHcjGIDM4PkvGS9osxcvbzUkk2MoBTj qKG/g/Hte4tDjAIcjEo8vO5GjoFCrIllxZW5hxglOJiVRHgPygKFeFMSK6tSi/Lji0pzUosP MQYBw2cisxR3cj4w/eWVxBsbGBDJURLnFQkUDRQSSAemsOzU1ILUIpihTBycIEu5pESKgYko tSixtCQjHpQu44uBCVOqgfFA9/UTckvn88+smfwv4BTTZCmtqAv1v3a9SBU4I+Z8aQOb1e31 8W3XTzx47XRhbVOfXDqrDbttPo9lWeCHqCNTq//cevpWVHx93jKej6u7FpnFLmBZv3TFo1L1 ySEXYu4mlvCW7WIp5r2wKvU9C4/N86ipC989yjBaahmhVLNA+XW+rKLr3x1KLMUZiYZazEXF iQBtN0Z3fwMAAA==
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] A different perspective on the video codec MTI 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: Thu, 14 Mar 2013 03:03:16 -0000

--_000_BBF5DDFE515C3946BC18D733B20DAD2338D2906DXMB104ADSrimnet_
Content-Type: text/plain; charset="utf-8"
content-transfer-encoding: base64

DQpUaGUgb3BlcmF0aXZlIHdvcmQgYmVpbmcgIklGIiAtIGFuZCBhbHdheXMgcmVhZCB0aGUg
ZmluZSBwcmludCBmaXJzdCENCg0KDQoNCkZyb206IENhbWVyb24gQnlybmUgW21haWx0bzpj
Yi5saXN0NkBnbWFpbC5jb21dDQpTZW50OiBXZWRuZXNkYXksIE1hcmNoIDEzLCAyMDEzIDA5
OjI2IFBNIENlbnRyYWwgU3RhbmRhcmQgVGltZQ0KVG86IEFuZHJldyBBbGxlbg0KQ2M6IGxv
cmVuem9AbWVldGVjaG8uY29tIDxsb3JlbnpvQG1lZXRlY2hvLmNvbT47IHJ0Y3dlYkBpZXRm
Lm9yZyA8cnRjd2ViQGlldGYub3JnPjsgamRyb3NlbkBqZHJvc2VuLm5ldCA8amRyb3NlbkBq
ZHJvc2VuLm5ldD4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBBIGRpZmZlcmVudCBwZXJzcGVj
dGl2ZSBvbiB0aGUgdmlkZW8gY29kZWMgTVRJIGRpc2N1c3Npb24NCg0KDQpPbiBNYXIgMTMs
IDIwMTMgNzoxMSBQTSwgIkFuZHJldyBBbGxlbiIgPGFhbGxlbkBibGFja2JlcnJ5LmNvbTxt
YWlsdG86YWFsbGVuQGJsYWNrYmVycnkuY29tPj4gd3JvdGU6DQo+DQo+DQo+DQo+IExvcmVu
em8NCj4NCj4gQSBnb29kIHBpZWNlIG9mIGFkdmljZSB3aGVuIHNob3BwaW5nIGlzIHRvIGFs
d2F5cyBiZXdhcmUgb2YgdGhlIHBsYWNlcyB3aGVyZSB0aGUgcHJpY2UgaXMgbm90IHdlbGwg
YWR2ZXJ0aXNlZCAtIHRoZSBmYWN0IHRoYXQgdGhlIHByaWNlIGlzIG5vdCBrbm93biBpbiBh
ZHZhbmNlIGRvZXMgbm90IG1lYW4gaXRzIGZyZWUgLSBhbmQgb2Z0ZW4gcXVpdGUgdGhlIG9w
cG9zaXRlIQ0KPg0KPiBBbmRyZXcNCj4NClNpbmNlIHdlIGFyZSBoYW5kaW5nIG91dCBhZHZp
Y2UuDQoNCkhlcmUgaXMgYW5vdGhlciBwaWVjZSBpZiBhZHZpY2UuDQoNCklmIGl0J3MgZnJl
ZSwgdGFrZSAyLg0KDQpDQg0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZy
b206IExvcmVuem8gTWluaWVybyBbbWFpbHRvOmxvcmVuem9AbWVldGVjaG8uY29tPG1haWx0
bzpsb3JlbnpvQG1lZXRlY2hvLmNvbT5dDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMTMs
IDIwMTMgMDY6NTUgUE0gQ2VudHJhbCBTdGFuZGFyZCBUaW1lDQo+IFRvOiBKb25hdGhhbiBS
b3NlbmJlcmcgPGpkcm9zZW5AamRyb3Nlbi5uZXQ8bWFpbHRvOmpkcm9zZW5AamRyb3Nlbi5u
ZXQ+Pg0KPiBDYzogcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+IDxy
dGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQo+IFN1YmplY3Q6IFJl
OiBbcnRjd2ViXSBBIGRpZmZlcmVudCBwZXJzcGVjdGl2ZSBvbiB0aGUgdmlkZW8gY29kZWMg
TVRJIGRpc2N1c3Npb24NCj4NCj4gSWwgZ2lvcm5vIFdlZCwgMTMgTWFyIDIwMTMgMTg6MDY6
NDcgLTA0MDANCj4gSm9uYXRoYW4gUm9zZW5iZXJnIDxqZHJvc2VuQGpkcm9zZW4ubmV0PG1h
aWx0bzpqZHJvc2VuQGpkcm9zZW4ubmV0Pj4gaGEgc2NyaXR0bzoNCj4NCj4gPiBJIGhhdmUg
b25lIG1vcmUgdGhpbmcgdG8gc2F5IC0gc3BlYWtpbmcgbm93IGFzIGEgZGV2ZWxvcGVyLg0K
PiA+DQo+ID4gQXMgc29tZSBvZiB5b3UgbWF5IGtub3csIEkgcmVjZW50bHkgcmV0dXJuZWQg
dG8gQ2lzY28gYXMgQ1RPIG9mIHRoZQ0KPiA+IGNsb3VkIGNvbGxhYm9yYXRpb24gZ3JvdXAs
IHdoaWNoIGlzIHJlc3BvbnNpYmxlIGZvciBXZWJleC4gV2ViZXggd2FzDQo+ID4gb25lIG9m
IHRoZSBmaXJzdCBzZXJ2aWNlcyB0byBkbyB2b2ljZSBhbmQgdmlkZW8gb24gdGhlIHdlYiwg
dXNpbmcNCj4gPiBwbHVnaW5zIG9mIGNvdXJzZS4gRm9yIG91ciBidXNpbmVzcywgYSBrZXkg
cmVxdWlyZW1lbnQgaXMNCj4gPiBpbnRlcm9wZXJhYmlsaXR5IHdpdGggb3RoZXIgdmlkZW8g
c3lzdGVtcyBpbiB0aGUgQ2lzY28gcG9ydGZvbGlvLA0KPiA+IGluY2x1ZGluZyBvdXIgdmlk
ZW8gY2xpZW50cyBhbmQgdGVsZXByZXNlbmNlIHVuaXRzLiBUaG9zZSBhcmUgYWxsDQo+ID4g
YmFzZWQgb24gSC4yNjQuIENvbnNlcXVlbnRseSwgbXVjaCBhcyBJIHdvdWxkIGxpa2UgdG8g
YXZvaWQgdGhlIG5lZWQNCj4gPiBmb3IgYSBwbHVnaW4sIHRoZSBiZW5lZml0cyBvZiBlbGlt
aW5hdGluZyB0aGUgcGx1Z2luIGRvIG5vdCBvdXR3ZWlnaA0KPiA+IHRoZSBkcmF3YmFja3Mg
b2YgaGF2aW5nIHRvIHRyYW5zY29kZSBmcm9tIFZQOCB0byBILjI2NC4gSWYgSUVURg0KPiA+
IHNlbGVjdHMgVlA4IGFzIHRoZSBNVEkgY29kZWMsIHRoaXMgd2lsbCBtYWtlIGl0IGRyYW1h
dGljYWxseSBtb3JlDQo+ID4gZGlmZmljdWx0IGFuZCBleHBlbnNpdmUgZm9yIHVzIHRvIHVz
ZSB3ZWJSVEMuIElmIEguMjY0IGlzIHRoZSBNSVQNCj4gPiBjb2RlYywgaXQgd2lsbCBtYWtl
IGl0IG11Y2ggZWFzaWVyIGZvciB1cyB0byB1c2Ugd2ViUlRDLg0KPiA+DQo+DQo+IFNwZWFr
aW5nIGFzIGEgZGV2ZWxvcGVyIHdvcmtpbmcgZm9yIGEgY29tcGFueSB3aXRoIG11Y2ggbGVz
cyBtb25leSB0aGFuDQo+IHlvdXJzLCBpZiB0aGUgSUVURiBzZWxlY3RzIEguMjY0IGFzIHRo
ZSBNVEkgY29kZWMsIHRoaXMgd2lsbCBtYWtlIGl0DQo+IGV2ZW4gbW9yZSBkcmFtYXRpY2Fs
bHkgZGlmZmljdWx0IGFuZCBleHBlbnNpdmUgKGlmIG5vdCBpbXBvc3NpYmxlKSBmb3INCj4g
cHJldHR5IG11Y2ggZXZlcnlib2R5IGVsc2UgdG8gdXNlIHdlYlJUQywgb3IgYXQgbGVhc3Qg
dG8gZGV2ZWxvcA0KPiBzZXJ2aWNlcyBiYXNlZCBvbiBpdC4NCj4NCj4gTG9yZW56bw0KPg0K
PiAtLQ0KPiBMb3JlbnpvIE1pbmllcm8sIENPQg0KPg0KPiBNZWV0ZWNobyBzLnIubC4NCj4g
V2ViIENvbmZlcmVuY2luZyBhbmQgQ29sbGFib3JhdGlvbiBUb29scw0KPiBodHRwOi8vd3d3
Lm1lZXRlY2hvLmNvbQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KPiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+IHJ0Y3dlYkBpZXRmLm9yZzxt
YWlsdG86cnRjd2ViQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL3J0Y3dlYg0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gVGhpcyB0cmFuc21p
c3Npb24gKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVu
dGlhbCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVy
aWFsIHByb3RlY3RlZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNh
YmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24u
IEFueSB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUg
aW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVk
IHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkg
dG8gdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5
c3RlbS4gVXNlLCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlv
biBvZiB0aGlzIHRyYW5zbWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90
IGF1dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4NCj4gX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcnRjd2ViIG1haWxpbmcgbGlzdA0K
PiBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0KLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
DQpUaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNv
bnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFsIChp
bmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50IG9y
IG90aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1Ymxp
YyBpbmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBv
dGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91
IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1l
ZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlv
biBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwg
b3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVj
aXBpZW50cyBpcyBub3QgYXV0aG9yaXplZCBhbmQgbWF5IGJlIHVubGF3ZnVsLg0K

--_000_BBF5DDFE515C3946BC18D733B20DAD2338D2906DXMB104ADSrimnet_
Content-Type: text/html; charset="utf-8"
content-transfer-encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGZvbnQg
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxicj4NClRoZSBvcGVy
YXRpdmUgd29yZCBiZWluZyAmcXVvdDtJRiZxdW90OyAtIGFuZCBhbHdheXMgcmVhZCB0aGUg
ZmluZSBwcmludCBmaXJzdCE8YnI+DQo8YnI+DQo8L2ZvbnQ+PGJyPg0KJm5ic3A7PGJyPg0K
PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0
O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGZvbnQgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDsiPjxiPkZyb208L2I+OiBDYW1lcm9uIEJ5cm5lIFttYWlsdG86Y2IubGlzdDZAZ21h
aWwuY29tXQ0KPGJyPg0KPGI+U2VudDwvYj46IFdlZG5lc2RheSwgTWFyY2ggMTMsIDIwMTMg
MDk6MjYgUE0gQ2VudHJhbCBTdGFuZGFyZCBUaW1lPGJyPg0KPGI+VG88L2I+OiBBbmRyZXcg
QWxsZW4gPGJyPg0KPGI+Q2M8L2I+OiBsb3JlbnpvQG1lZXRlY2hvLmNvbSAmbHQ7bG9yZW56
b0BtZWV0ZWNoby5jb20mZ3Q7OyBydGN3ZWJAaWV0Zi5vcmcgJmx0O3J0Y3dlYkBpZXRmLm9y
ZyZndDs7IGpkcm9zZW5AamRyb3Nlbi5uZXQgJmx0O2pkcm9zZW5AamRyb3Nlbi5uZXQmZ3Q7
DQo8YnI+DQo8Yj5TdWJqZWN0PC9iPjogUmU6IFtydGN3ZWJdIEEgZGlmZmVyZW50IHBlcnNw
ZWN0aXZlIG9uIHRoZSB2aWRlbyBjb2RlYyBNVEkgZGlzY3Vzc2lvbg0KPGJyPg0KPC9mb250
PiZuYnNwOzxicj4NCjwvZGl2Pg0KPHAgZGlyPSJsdHIiPjxicj4NCk9uIE1hciAxMywgMjAx
MyA3OjExIFBNLCAmcXVvdDtBbmRyZXcgQWxsZW4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0
bzphYWxsZW5AYmxhY2tiZXJyeS5jb20iPmFhbGxlbkBibGFja2JlcnJ5LmNvbTwvYT4mZ3Q7
IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgTG9yZW56
bzxicj4NCiZndDs8YnI+DQomZ3Q7IEEgZ29vZCBwaWVjZSBvZiBhZHZpY2Ugd2hlbiBzaG9w
cGluZyBpcyB0byBhbHdheXMgYmV3YXJlIG9mIHRoZSBwbGFjZXMgd2hlcmUgdGhlIHByaWNl
IGlzIG5vdCB3ZWxsIGFkdmVydGlzZWQgLSB0aGUgZmFjdCB0aGF0IHRoZSBwcmljZSBpcyBu
b3Qga25vd24gaW4gYWR2YW5jZSBkb2VzIG5vdCBtZWFuIGl0cyBmcmVlIC0gYW5kIG9mdGVu
IHF1aXRlIHRoZSBvcHBvc2l0ZSE8YnI+DQomZ3Q7PGJyPg0KJmd0OyBBbmRyZXc8YnI+DQom
Z3Q7PGJyPg0KU2luY2Ugd2UgYXJlIGhhbmRpbmcgb3V0IGFkdmljZS4gPC9wPg0KPHAgZGly
PSJsdHIiPkhlcmUgaXMgYW5vdGhlciBwaWVjZSBpZiBhZHZpY2UuIDwvcD4NCjxwIGRpcj0i
bHRyIj5JZiBpdCdzIGZyZWUsIHRha2UgMi4mbmJzcDsgPC9wPg0KPHAgZGlyPSJsdHIiPkNC
PGJyPg0KJmd0OyAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tPGJyPg0KJmd0OyBGcm9t
OiBMb3JlbnpvIE1pbmllcm8gW21haWx0bzo8YSBocmVmPSJtYWlsdG86bG9yZW56b0BtZWV0
ZWNoby5jb20iPmxvcmVuem9AbWVldGVjaG8uY29tPC9hPl08YnI+DQomZ3Q7IFNlbnQ6IFdl
ZG5lc2RheSwgTWFyY2ggMTMsIDIwMTMgMDY6NTUgUE0gQ2VudHJhbCBTdGFuZGFyZCBUaW1l
PGJyPg0KJmd0OyBUbzogSm9uYXRoYW4gUm9zZW5iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86
amRyb3NlbkBqZHJvc2VuLm5ldCI+amRyb3NlbkBqZHJvc2VuLm5ldDwvYT4mZ3Q7PGJyPg0K
Jmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYu
b3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGll
dGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbcnRjd2ViXSBBIGRpZmZl
cmVudCBwZXJzcGVjdGl2ZSBvbiB0aGUgdmlkZW8gY29kZWMgTVRJIGRpc2N1c3Npb248YnI+
DQomZ3Q7PGJyPg0KJmd0OyBJbCBnaW9ybm8gV2VkLCAxMyBNYXIgMjAxMyAxODowNjo0NyAt
MDQwMDxicj4NCiZndDsgSm9uYXRoYW4gUm9zZW5iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86
amRyb3NlbkBqZHJvc2VuLm5ldCI+amRyb3NlbkBqZHJvc2VuLm5ldDwvYT4mZ3Q7IGhhIHNj
cml0dG86PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyBJIGhhdmUgb25lIG1vcmUgdGhpbmcg
dG8gc2F5IC0gc3BlYWtpbmcgbm93IGFzIGEgZGV2ZWxvcGVyLjxicj4NCiZndDsgJmd0Ozxi
cj4NCiZndDsgJmd0OyBBcyBzb21lIG9mIHlvdSBtYXkga25vdywgSSByZWNlbnRseSByZXR1
cm5lZCB0byBDaXNjbyBhcyBDVE8gb2YgdGhlPGJyPg0KJmd0OyAmZ3Q7IGNsb3VkIGNvbGxh
Ym9yYXRpb24gZ3JvdXAsIHdoaWNoIGlzIHJlc3BvbnNpYmxlIGZvciBXZWJleC4gV2ViZXgg
d2FzPGJyPg0KJmd0OyAmZ3Q7IG9uZSBvZiB0aGUgZmlyc3Qgc2VydmljZXMgdG8gZG8gdm9p
Y2UgYW5kIHZpZGVvIG9uIHRoZSB3ZWIsIHVzaW5nPGJyPg0KJmd0OyAmZ3Q7IHBsdWdpbnMg
b2YgY291cnNlLiBGb3Igb3VyIGJ1c2luZXNzLCBhIGtleSByZXF1aXJlbWVudCBpczxicj4N
CiZndDsgJmd0OyBpbnRlcm9wZXJhYmlsaXR5IHdpdGggb3RoZXIgdmlkZW8gc3lzdGVtcyBp
biB0aGUgQ2lzY28gcG9ydGZvbGlvLDxicj4NCiZndDsgJmd0OyBpbmNsdWRpbmcgb3VyIHZp
ZGVvIGNsaWVudHMgYW5kIHRlbGVwcmVzZW5jZSB1bml0cy4gVGhvc2UgYXJlIGFsbDxicj4N
CiZndDsgJmd0OyBiYXNlZCBvbiBILjI2NC4gQ29uc2VxdWVudGx5LCBtdWNoIGFzIEkgd291
bGQgbGlrZSB0byBhdm9pZCB0aGUgbmVlZDxicj4NCiZndDsgJmd0OyBmb3IgYSBwbHVnaW4s
IHRoZSBiZW5lZml0cyBvZiBlbGltaW5hdGluZyB0aGUgcGx1Z2luIGRvIG5vdCBvdXR3ZWln
aDxicj4NCiZndDsgJmd0OyB0aGUgZHJhd2JhY2tzIG9mIGhhdmluZyB0byB0cmFuc2NvZGUg
ZnJvbSBWUDggdG8gSC4yNjQuIElmIElFVEY8YnI+DQomZ3Q7ICZndDsgc2VsZWN0cyBWUDgg
YXMgdGhlIE1USSBjb2RlYywgdGhpcyB3aWxsIG1ha2UgaXQgZHJhbWF0aWNhbGx5IG1vcmU8
YnI+DQomZ3Q7ICZndDsgZGlmZmljdWx0IGFuZCBleHBlbnNpdmUgZm9yIHVzIHRvIHVzZSB3
ZWJSVEMuIElmIEguMjY0IGlzIHRoZSBNSVQ8YnI+DQomZ3Q7ICZndDsgY29kZWMsIGl0IHdp
bGwgbWFrZSBpdCBtdWNoIGVhc2llciBmb3IgdXMgdG8gdXNlIHdlYlJUQy48YnI+DQomZ3Q7
ICZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBTcGVha2luZyBhcyBhIGRldmVsb3BlciB3b3Jr
aW5nIGZvciBhIGNvbXBhbnkgd2l0aCBtdWNoIGxlc3MgbW9uZXkgdGhhbjxicj4NCiZndDsg
eW91cnMsIGlmIHRoZSBJRVRGIHNlbGVjdHMgSC4yNjQgYXMgdGhlIE1USSBjb2RlYywgdGhp
cyB3aWxsIG1ha2UgaXQ8YnI+DQomZ3Q7IGV2ZW4gbW9yZSBkcmFtYXRpY2FsbHkgZGlmZmlj
dWx0IGFuZCBleHBlbnNpdmUgKGlmIG5vdCBpbXBvc3NpYmxlKSBmb3I8YnI+DQomZ3Q7IHBy
ZXR0eSBtdWNoIGV2ZXJ5Ym9keSBlbHNlIHRvIHVzZSB3ZWJSVEMsIG9yIGF0IGxlYXN0IHRv
IGRldmVsb3A8YnI+DQomZ3Q7IHNlcnZpY2VzIGJhc2VkIG9uIGl0Ljxicj4NCiZndDs8YnI+
DQomZ3Q7IExvcmVuem88YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLTxicj4NCiZndDsgTG9yZW56
byBNaW5pZXJvLCBDT0I8YnI+DQomZ3Q7PGJyPg0KJmd0OyBNZWV0ZWNobyBzLnIubC48YnI+
DQomZ3Q7IFdlYiBDb25mZXJlbmNpbmcgYW5kIENvbGxhYm9yYXRpb24gVG9vbHM8YnI+DQom
Z3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cubWVldGVjaG8uY29tIj5odHRwOi8vd3d3Lm1lZXRl
Y2hvLmNvbTwvYT48YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPGJyPg0KJmd0OyBydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KJmd0
OyA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+
PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL3J0Y3dlYiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3
ZWI8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBU
aGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRh
aW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFsIChpbmNs
dWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90
aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBp
bmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uDQogYnkgYW55b25lIG90
aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3Ug
aGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVk
aWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9u
IGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBv
ciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24NCiBieSB1bmludGVuZGVkIHJl
Y2lwaWVudHMgaXMgbm90IGF1dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC48YnI+DQom
Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy
Pg0KJmd0OyBydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86
cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVm
PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiI+aHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PGJyPg0KPC9wPg0K
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tIDxicj4NClRoaXMgdHJhbnNtaXNzaW9uIChpbmNsdWRpbmcgYW55
IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24sIHBy
aXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkgdGhl
IHNvbGljaXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwgb3Ig
Y29uc3RpdHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRoaXMgaW5m
b3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBp
cyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBp
biBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRl
bGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5h
dGlvbiwgZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Np
b24gYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkg
YmUgdW5sYXdmdWwuDQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_BBF5DDFE515C3946BC18D733B20DAD2338D2906DXMB104ADSrimnet_--

From D.Malas@cablelabs.com  Wed Mar 13 21:18: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 2E2951F0C74 for ; Wed, 13 Mar 2013 21:18:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.463
X-Spam-Level: 
X-Spam-Status: No, score=-100.463 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 DUQm1hFdesxB for ; Wed, 13 Mar 2013 21:18:18 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 786E41F0C6D for ; Wed, 13 Mar 2013 21:18:18 -0700 (PDT)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r2E4IHJW022350; Wed, 13 Mar 2013 22:18:17 -0600
Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 13 Mar 2013 22:18:17 -0600 (MDT)
X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com)
Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 22:18:14 -0600
From: Daryl Malas 
To: Jonathan Rosenberg , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] A different perspective on the video codec MTI discussion
Thread-Index: AQHOIDcYbFpDVsu7rEa3KEkeiqjz/ZiktwQA
Date: Thu, 14 Mar 2013 04:18:13 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.1.130117
x-originating-ip: [10.5.0.27]
Content-Type: multipart/alternative; boundary="_000_FEA80D86BEEC134D88CA45E53A0D3408180DA31BEXCHANGEcablela_"
MIME-Version: 1.0
X-Approved: ondar
Subject: Re: [rtcweb] A different perspective on the video codec MTI 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: Thu, 14 Mar 2013 04:18:20 -0000

--_000_FEA80D86BEEC134D88CA45E53A0D3408180DA31BEXCHANGEcablela_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

I would like to add my support to Jonathan's comments.  I have had discussi=
ons with multiple cable operators, which are evaluating the potential use c=
ases of deploying webRTC.  The resounding comment is that if webRTC support=
s H.264, their flexibility to deploy it in the near-term on a number of dev=
ices improves dramatically.  If VP8 is the only allowable codec, this will =
significantly limit the deployment, because the relevant devices out there =
already support H.264 and not VP8.

In addition, by saying that we will only support a royalty-free codec (VP8)=
, it is effectively saying we will not allow people to pay the necessary li=
cense fees (whether new or already realized) at their choosing in order to =
deploy more webRTC clients and further the overall adoption of webRTC.

Does it really increase the complexity so dramatically by supporting two vi=
deo codecs that it outweighs the potential for faster adoption and deployme=
nt of webRTC?

I also second Jonathan's comments related to, "I applaud your efforts and t=
hank you for them."  This is absolutely valuable from my perspective, and i=
t has great potential for future use.

Regards,

Daryl

From: Jonathan Rosenberg >
Date: Wednesday, March 13, 2013 6:06 PM
To: "rtcweb@ietf.org" >
Subject: [rtcweb] A different perspective on the video codec MTI discussion


I=92d like to put a different perspective on the video MTI discussion.

Much of the discussion has been around video quality, IPR, and standardizat=
ion status. While those are all important factors, to me they are secondary=
 to the core question: how does the choice impact uptake of the webRTC APIs=
 and protocols by developers who build applications ontop of it? In this re=
gard, I would like to suggest that, at this time, adoption of VP8 as MTI wi=
ll slow down adoption of webRTC by turning off developers that would otherw=
ise embrace it if H.264 were selected.

The reason is simple. For many application developers, what is interesting =
about webRTC is NOT just browser to browser communications, but connecting =
users in a browser to users elsewhere - on other devices, in other networks=
. After all, the vast majority of web application developers do not have th=
e luxury of a massive social graph, or the luxury of their users being park=
ed persistently on their website and thus able to receive an incoming call.=
 Many websites that have customer support or service needs would love to be=
 able to allow their users to have a video call with an agent. However, tho=
se agents are probably sitting on existing agent systems which are not web =
based, and it=92s almost certainly true that they do not today support VP8,=
 but rather H.264. Many developers would probably love to connect users on =
the web with users on mobile apps. Most mobile platforms today support H264=
 based hardware acceleration for decode and sometimes encode, but not yet V=
P8. Developers who want to build business communications clients will need =
to connect those users with other users in the business, who may be using v=
ideophones, PC clients, telepresence units or video room systems, the vast =
majority of which do not support VP8 today, but many of which do support H.=
264.

The reality is =96 today=92s Internet and IP communications systems are bui=
lt on H.264. And unless the developer cares only about living within the is=
land of the web browser =96 a VP8 based solution will simply not meet their=
 requirements.

This may not be true down the road. I applaud Google for working hard (and =
spending much money no doubt) to secure an RF license for VP8 from these pa=
tent holders. I think they should continue pushing and promoting the techno=
logy because a  free, high quality video codec would be great for the Inter=
net. But today, it is not the video codec of the Internet. And, given the r=
elatively early days of video, I am sure there will be video codecs after V=
P8. Maybe H.265, maybe the new video codec being developed here at the IETF=
. And once those codecs become more broadly implemented and available on th=
e endpoints that matter, we can revise our specs and mandate support for th=
em. But this is not about the web of five years from now, its about the web=
 today. And if we mandate usage of a codec which is not widely implemented =
in all the endpoints that matter (not just the browser), I fear that it wil=
l hold developers back from using webRTC and thus prevent us from ever havi=
ng the opportunity to add these video codecs in the future.



And so =96 to the supporters of VP8 =96 I applaud your efforts and thank yo=
u for them. Please continue. And when the industry is ready, we can make VP=
8 MTI in the browser. But we are not there yet.  I ask you to please put th=
e needs of the developers ahead of your own, and do not hold back webRTC fo=
r the benefit of your ideals around an RF and open source video codec. WebR=
TC is too important for that.

I have one more thing to say - speaking now as a developer.

As some of you may know, I recently returned to Cisco as CTO of the cloud c=
ollaboration group, which is responsible for Webex. Webex was one of the fi=
rst services to do voice and video on the web, using plugins of course. For=
 our business, a key requirement is interoperability with other video syste=
ms in the Cisco portfolio, including our video clients and telepresence uni=
ts. Those are all based on H.264. Consequently, much as I would like to avo=
id the need for a plugin, the benefits of eliminating the plugin do not out=
weigh the drawbacks of having to transcode from VP8 to H.264. If IETF selec=
ts VP8 as the MTI codec, this will make it dramatically more difficult and =
expensive for us to use webRTC. If H.264 is the MIT codec, it will make it =
much easier for us to use webRTC.


Thx,

Jonathan R.

--
Jonathan Rosenberg, Ph.D.
jdrosen@jdrosen.net
http://www.jdrosen.net

--_000_FEA80D86BEEC134D88CA45E53A0D3408180DA31BEXCHANGEcablela_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <0A2BE5EACB1CDA499F85F2A07829D7B3@cablelabs.com>
Content-Transfer-Encoding: quoted-printable







I would like to add my support to Jonathan's comments.  I have ha=
d discussions with multiple cable operators, which are evaluating the poten=
tial use cases of deploying webRTC.  The resounding comment is th=
at if webRTC supports H.264, their flexibility
 to deploy it in the near-term on a number of devices improves dramatically=
.  If VP8 is the only allowable codec, this will significantly limit t=
he deployment, because the relevant devices out there already support H.264=
 and not VP8.







In addition, by saying that we will only support a royalty-free codec =
(VP8), it is effectively saying we will not allow people to pay the necessa=
ry license fees (whether new or already realized) at their choosing in orde=
r to deploy more webRTC clients
 and further the overall adoption of webRTC.







Does it really increase the complexity so dramatically by supporting t=
wo video codecs that it outweighs the potential for faster adoption and dep=
loyment of webRTC?







I also second Jonathan's comments related to, "I applaud your eff=
orts and thank you for them."  This is absolutely valuable from m=
y perspective, and it has great potential for future use.







Regards,







Daryl









From: Jonathan Rosenberg <jdrosen@jdrosen.net>

Date: Wednesday, March 13, 2013 6:0=
6 PM

To: "rtcweb@ietf.org" <=
rtcweb@ietf.org>

Subject: [rtcweb] A different persp=
ective on the video codec MTI discussion















I=92d like to put a different per=
spective on the video MTI discussion.


Much of the discussion has been a=
round video quality, IPR, and standardization status. While those are all i=
mportant factors, to me they are secondary to the core question: how does t=
he choice impact uptake of the webRTC
 APIs and protocols by developers who build applications ontop of it? In th=
is regard, I would like to suggest that, at this time, adoption of VP8 as M=
TI will slow down adoption of webRTC by turning off developers that would o=
therwise embrace it if H.264 were
 selected.


The reason is simple. For many ap=
plication developers, what is interesting about webRTC is NOT just browser =
to browser communications, but connecting users in a browser to users elsew=
here - on other devices, in other networks.
 After all, the vast majority of web application developers do not have the=
 luxury of a massive social graph, or the luxury of their users being parke=
d persistently on their website and thus able to receive an incoming call. =
Many websites that have customer
 support or service needs would love to be able to allow their users to hav=
e a video call with an agent. However, those agents are probably sitting on=
 existing agent systems which are not web based, and it=92s almost certainl=
y true that they do not today support
 VP8, but rather H.264. Many developers would probably love to connect user=
s on the web with users on mobile apps. Most mobile platforms today support=
 H264 based hardware acceleration for decode and sometimes encode, but not =
yet VP8. Developers who want to
 build business communications clients will need to connect those users wit=
h other users in the business, who may be using videophones, PC clients, te=
lepresence units or video room systems, the vast majority of which do not s=
upport VP8 today, but many of which
 do support H.264.


The reality is =96 today=92s Inte=
rnet and IP communications systems are built on H.264. And unless the devel=
oper cares only about living within the island of the web browser =96 a VP8=
 based solution will simply not meet their
 requirements.


This may not be true down the roa=
d. I applaud Google for working hard (and spending much money no doubt) to =
secure an RF license for VP8 from these patent holders. I think they should=
 continue pushing and promoting the
 technology because a  free, high quality video codec would be great f=
or the Internet. But today, it is not the video codec of the Internet. And,=
 given the relatively early days of video, I am sure there will be video co=
decs after VP8. Maybe H.265, maybe the
 new video codec being developed here at the IETF. And once those codecs be=
come more broadly implemented and available on the endpoints that matter, w=
e can revise our specs and mandate support for them. But this is not about =
the web of five years from now,
 its about the web today. And if we mandate usage of a codec which is not w=
idely implemented in all the endpoints that matter (not just the browser), =
I fear that it will hold developers back from using webRTC and thus prevent=
 us from ever having the opportunity
 to add these video codecs in the future.


 


And so =96 to the supporters of V=
P8 =96 I applaud your efforts and thank you for them. Please continue. And =
when the industry is ready, we can make VP8 MTI in the browser. But we are =
not there yet.  I ask you to please put
 the needs of the developers ahead of your own, and do not hold back webRTC=
 for the benefit of your ideals around an RF and open source video codec. W=
ebRTC is too important for that.


I have one more thing to say - sp=
eaking now as a developer.


As some of you may know, I recent=
ly returned to Cisco as CTO of the cloud collaboration group, which is resp=
onsible for Webex. Webex was one of the first services to do voice and vide=
o on the web, using plugins of course.
 For our business, a key requirement is interoperability with other video s=
ystems in the Cisco portfolio, including our video clients and telepresence=
 units. Those are all based on H.264. Consequently, much as I would like to=
 avoid the need for a plugin, the
 benefits of eliminating the plugin do not outweigh the drawbacks of having=
 to transcode from VP8 to H.264. If IETF selects VP8 as the MTI codec, this=
 will make it dramatically more difficult and expensive for us to use webRT=
C. If H.264 is the MIT codec, it
 will make it much easier for us to use webRTC. 







Thx,


Jonathan R.

-- 












--_000_FEA80D86BEEC134D88CA45E53A0D3408180DA31BEXCHANGEcablela_--

From cb.list6@gmail.com  Wed Mar 13 21:27: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 86DFA21F8D55 for ; Wed, 13 Mar 2013 21:27:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.937
X-Spam-Level: 
X-Spam-Status: No, score=-2.937 tagged_above=-999 required=5 tests=[AWL=0.662,  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 NEa6o7YloRGn for ; Wed, 13 Mar 2013 21:27:00 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 65EE721F8D50 for ; Wed, 13 Mar 2013 21:26:59 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id dr12so1610225wgb.23 for ; Wed, 13 Mar 2013 21:26:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=G9fnfGqaKlvFEsPbjBQt9FrYQLAWWdyPKn87525cuvo=; b=NadTMUQbxqhTR8nHu7V8COUIu0pUSCPFn5ODBOiW/vt5bDuOmWMNaWwMyl69ZIApqM /+ZuE1JxsFzV2WY6u4+ALoP6NEmWMlT4pvhw8tkwVZblivHQAg6r4Jzw2OSHedjxWWwR c0kFjLifTvsCqUSVZIWnhIT+s8u0XQuYDh9eHlJWF+Gpgc3OSffmHzXGsAvP/BCfdWio LKnBieKHCgMWLYu/srvjUiqG8DICbNEsrKJ4+a4gAZ1b1AocwuczZ1ASPl0kMikKQrY0 8npMUpq4kjxmvNT5ZBqU+oUFS189CLLcZEY2P5rGpNUn1QqhUk+gX4NOY46Gqn/7xXFa LVAg==
MIME-Version: 1.0
X-Received: by 10.180.98.232 with SMTP id el8mr31371280wib.22.1363235218502; Wed, 13 Mar 2013 21:26:58 -0700 (PDT)
Received: by 10.194.20.35 with HTTP; Wed, 13 Mar 2013 21:26:58 -0700 (PDT)
In-Reply-To: 
References:  
Date: Wed, 13 Mar 2013 21:26:58 -0700
Message-ID: 
From: Cameron Byrne 
To: Daryl Malas 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] A different perspective on the video codec MTI 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: Thu, 14 Mar 2013 04:27:02 -0000

On Wed, Mar 13, 2013 at 9:18 PM, Daryl Malas  wrote:
> I would like to add my support to Jonathan's comments.  I have had
> discussions with multiple cable operators, which are evaluating the
> potential use cases of deploying webRTC.  The resounding comment is that =
if
> webRTC supports H.264, their flexibility to deploy it in the near-term on=
 a
> number of devices improves dramatically.  If VP8 is the only allowable
> codec, this will significantly limit the deployment, because the relevant
> devices out there already support H.264 and not VP8.
>

You can negotiate any codec you want
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-03#section-3.2

There is now limitation on the number of codecs that you may support.

I hope this helps.

CB

ps.  my position remains that the idea of MTI needs be dropped,
consensus will not be found.  Let the market figure it out.


> In addition, by saying that we will only support a royalty-free codec (VP=
8),
> it is effectively saying we will not allow people to pay the necessary
> license fees (whether new or already realized) at their choosing in order=
 to
> deploy more webRTC clients and further the overall adoption of webRTC.
>
> Does it really increase the complexity so dramatically by supporting two
> video codecs that it outweighs the potential for faster adoption and
> deployment of webRTC?
>




> I also second Jonathan's comments related to, "I applaud your efforts and
> thank you for them."  This is absolutely valuable from my perspective, an=
d
> it has great potential for future use.
>
> Regards,
>
> Daryl
>
> From: Jonathan Rosenberg 
> Date: Wednesday, March 13, 2013 6:06 PM
> To: "rtcweb@ietf.org" 
> Subject: [rtcweb] A different perspective on the video codec MTI discussi=
on
>
> I=92d like to put a different perspective on the video MTI discussion.
>
> Much of the discussion has been around video quality, IPR, and
> standardization status. While those are all important factors, to me they
> are secondary to the core question: how does the choice impact uptake of =
the
> webRTC APIs and protocols by developers who build applications ontop of i=
t?
> In this regard, I would like to suggest that, at this time, adoption of V=
P8
> as MTI will slow down adoption of webRTC by turning off developers that
> would otherwise embrace it if H.264 were selected.
>
> The reason is simple. For many application developers, what is interestin=
g
> about webRTC is NOT just browser to browser communications, but connectin=
g
> users in a browser to users elsewhere - on other devices, in other networ=
ks.
> After all, the vast majority of web application developers do not have th=
e
> luxury of a massive social graph, or the luxury of their users being park=
ed
> persistently on their website and thus able to receive an incoming call.
> Many websites that have customer support or service needs would love to b=
e
> able to allow their users to have a video call with an agent. However, th=
ose
> agents are probably sitting on existing agent systems which are not web
> based, and it=92s almost certainly true that they do not today support VP=
8,
> but rather H.264. Many developers would probably love to connect users on
> the web with users on mobile apps. Most mobile platforms today support H2=
64
> based hardware acceleration for decode and sometimes encode, but not yet
> VP8. Developers who want to build business communications clients will ne=
ed
> to connect those users with other users in the business, who may be using
> videophones, PC clients, telepresence units or video room systems, the va=
st
> majority of which do not support VP8 today, but many of which do support
> H.264.
>
> The reality is =96 today=92s Internet and IP communications systems are b=
uilt on
> H.264. And unless the developer cares only about living within the island=
 of
> the web browser =96 a VP8 based solution will simply not meet their
> requirements.
>
> This may not be true down the road. I applaud Google for working hard (an=
d
> spending much money no doubt) to secure an RF license for VP8 from these
> patent holders. I think they should continue pushing and promoting the
> technology because a  free, high quality video codec would be great for t=
he
> Internet. But today, it is not the video codec of the Internet. And, give=
n
> the relatively early days of video, I am sure there will be video codecs
> after VP8. Maybe H.265, maybe the new video codec being developed here at
> the IETF. And once those codecs become more broadly implemented and
> available on the endpoints that matter, we can revise our specs and manda=
te
> support for them. But this is not about the web of five years from now, i=
ts
> about the web today. And if we mandate usage of a codec which is not wide=
ly
> implemented in all the endpoints that matter (not just the browser), I fe=
ar
> that it will hold developers back from using webRTC and thus prevent us f=
rom
> ever having the opportunity to add these video codecs in the future.
>
>
>
> And so =96 to the supporters of VP8 =96 I applaud your efforts and thank =
you for
> them. Please continue. And when the industry is ready, we can make VP8 MT=
I
> in the browser. But we are not there yet.  I ask you to please put the ne=
eds
> of the developers ahead of your own, and do not hold back webRTC for the
> benefit of your ideals around an RF and open source video codec. WebRTC i=
s
> too important for that.
>
> I have one more thing to say - speaking now as a developer.
>
> As some of you may know, I recently returned to Cisco as CTO of the cloud
> collaboration group, which is responsible for Webex. Webex was one of the
> first services to do voice and video on the web, using plugins of course.
> For our business, a key requirement is interoperability with other video
> systems in the Cisco portfolio, including our video clients and teleprese=
nce
> units. Those are all based on H.264. Consequently, much as I would like t=
o
> avoid the need for a plugin, the benefits of eliminating the plugin do no=
t
> outweigh the drawbacks of having to transcode from VP8 to H.264. If IETF
> selects VP8 as the MTI codec, this will make it dramatically more difficu=
lt
> and expensive for us to use webRTC. If H.264 is the MIT codec, it will ma=
ke
> it much easier for us to use webRTC.
>
>
> Thx,
>
> Jonathan R.
>
> --
> Jonathan Rosenberg, Ph.D.
> jdrosen@jdrosen.net
> http://www.jdrosen.net
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

From yekuiw@qti.qualcomm.com  Wed Mar 13 21:36: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 CE4CB21F86A8 for ; Wed, 13 Mar 2013 21:36:30 -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 7AGLKsEAVWtm for ; Wed, 13 Mar 2013 21:36:29 -0700 (PDT)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1D89321F86D9 for ; Wed, 13 Mar 2013 21:36:28 -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=1363235788; x=1394771788; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QAf/59kGMpffjzEof1kB3zXW2mifP2nL/FXBxG7PjQQ=; b=YZobzHI6Mpe/8sfh2HS9UrJcbr2Cbw2vp+dZCc82qOrZ2Gie9XFKWwXz fxAjsXAut9DrNFg3lATIoGlOGYwvR8edTe9kT3Opx/zRtZgVliFifqAGx 0KgtyApm80ukFtM33FyIYAnupa/sX28oAgWQkQGW9GuLxzqgEXvR/grZl I=;
X-IronPort-AV: E=Sophos;i="4.84,842,1355126400"; d="scan'208,217";a="29901475"
Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP; 13 Mar 2013 21:36:27 -0700
X-IronPort-AV: E=Sophos;i="4.84,842,1355126400";  d="scan'208,217";a="504898879"
Received: from nasanexhc11.na.qualcomm.com ([172.30.39.6]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 Mar 2013 21:36:27 -0700
Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.64]) by nasanexhc11.na.qualcomm.com ([172.30.39.6]) with mapi id 14.02.0318.004; Wed, 13 Mar 2013 21:36:27 -0700
From: "Wang, Ye-Kui" 
To: Gerard Fernando 
Thread-Topic: [rtcweb] Video Codec discussion in Thursday agenda slot
Thread-Index: AQHOH0jr3vjUB09c8EG4MhtYHbfvE5ii0RyAgAAIloCAAAHrgIABTYKAgAACnQD//7k88IAA5mkA///RB+0=
Date: Thu, 14 Mar 2013 04:36:26 +0000
Message-ID: <2981F523-72AC-4330-8D1F-7DC4E2168C5A@qti.qualcomm.com>
References: <513F68C0.4010106@ericsson.com>  <513F7745.3020302@alvestrand.no>    <8BA7D4CEACFFE04BA2D902BF11719A8331B17F22@nasanexd02f.na.qualcomm.com>, <1363220674.82166.YahooMailNeo@web132106.mail.ird.yahoo.com>
In-Reply-To: <1363220674.82166.YahooMailNeo@web132106.mail.ird.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_2981F52372AC43308D1F7DC4E2168C5Aqtiqualcommcom_"
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 04:36:30 -0000

--_000_2981F52372AC43308D1F7DC4E2168C5Aqtiqualcommcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Sure - but that is clearly not the context here.

Sent from my iPhone

On Mar 13, 2013, at 17:24, "Gerard Fernando" > wrote:

Hello YK,

The disclosure process in MPEG is not based on who you are, or on your Busi=
ness model.

Kind regards

Gerard


________________________________
From: "Wang, Ye-Kui" >
To: Stockhammer Thomas >;=
 Bo Burman >
Cc: "rtcweb@ietf.org" >
Sent: Wednesday, 13 March 2013, 10:40
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot

> >  How many others who did not respond to MPEG LA's call but have IPR
> > are
> there?
>
> [TS]  Just one more hypothesis: If I would have, what would be my
> obligation/motivation to do so now?

Speaking of the motivation part; that would depend on who YOU are and what =
kind of business model or plan YOU have in mind.

BR, YK

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtc=
web-bounces@ietf.org] On Behalf
> Of Stockhammer Thomas
> Sent: Wednesday, March 13, 2013 7:53 AM
> To: Bo Burman
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
>
>
> >  How many others who did not respond to MPEG LA's call but have IPR are
> there?
>
> [TS]  Just one more hypothesis: If I would have, what would be my
> obligation/motivation to do so now?
>
> >>>
> >>> We appreciate the need to have time to evaluate the specific words
> >>> of the license statements that are forthcoming, and the need for the
> >>> people who haven't made their IPR declarations over the last couple
> >>> of years of discussion to do so within the next couple of weeks -
> >>> but we do think that it is important to use the face to face time
> >>> that we have here in Orlando to lay to rest any *other* issues than
> >>> the licensing terms and other issues derived from Google's
> announcement.
> >>
> >> I am not sure we can have a reasoned consideration of 'other issues
> derived'
> >> at such short notice.
> >>
> >> Look, I'd like our discussions and decisions to be informed and
> >> considered, and there simply isn't time for either.
> >>
> >>>
> >>> Harald
> >>>
> >>> _______________________________________________
> >>> rtcweb mailing list
> >>> rtcweb@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/rtcweb
> >>
> >> David Singer
> >> Multimedia and Software Standards, Apple Inc.
> >>
> >> _______________________________________________
> >> rtcweb mailing list
> >> rtcweb@ietf.org
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> >
>
> ---
> Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49
> 89 978980 02 || cell +491725702667 || http://www.nomor-research.com
> Nomor Research GmbH  -  Sitz der Gesellschaft: M=FCnchen - Registergerich=
t:
> M=FCnchen, HRB 165856 - Umsatzsteuer-ID: DE238047637 - Gesch=E4ftsf=FChre=
r:
> Dr. Thomas Stockhammer, Dr. Ingo Viering.
>
>
>
> _______________________________________________
> 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

--_000_2981F52372AC43308D1F7DC4E2168C5Aqtiqualcommcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







Sure - but that is clearly not the context here.



Sent from my iPhone




On Mar 13, 2013, at 17:24, "Gerard Fernando" <gerardmxf@yahoo.co.uk> wrote:












Hello YK,







The disclosure process in MPEG is not based on who you are, or on your Busi=
ness model.



Kind regards



Gerard













From: "Wang, Ye-Kui&qu=
ot; <yekuiw@qti.qualcomm.com<=
/a>>

To: Stockhammer Thomas <=
;stockhammer@nomor.de>; Bo B=
urman <bo.burman@ericsson.com<=
/a>>


Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>


Sent: Wednesday, 13 March =
2013, 10:40

Subject: Re: [rtcweb] Vide=
o Codec discussion in Thursday agenda slot





> >  How many others who did not respond to MPEG LA's call but h=
ave IPR 

> > are

> there?

> 

> [TS]  Just one more hypothesis: If I would have, what would be my=
 

> obligation/motivation to do so now?



Speaking of the motivation part; that would depend on who YOU are and what =
kind of business model or plan YOU have in mind.




BR, YK



> -----Original Message-----

> From: 
rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org]=
 On Behalf

> Of Stockhammer Thomas

> Sent: Wednesday, March 13, 2013 7:53 AM

> To: Bo Burman

> Cc: rtcweb@ietf.org

> Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
> 

> 

> >  How many others who did not respond to MPEG LA's call but h=
ave IPR are

> there?

> 

> [TS]  Just one more hypothesis: If I would have, what would be my=


> obligation/motivation to do so now?

> 

> >>>

> >>> We appreciate the need to have time to evaluate the speci=
fic words

> >>> of the license statements that are forthcoming, and the n=
eed for the

> >>> people who haven't made their IPR declarations over the l=
ast couple

> >>> of years of discussion to do so within the next couple of=
 weeks -

> >>> but we do think that it is important to use the face to f=
ace time

> >>> that we have here in Orlando to lay to rest any *other* i=
ssues than

> >>> the licensing terms and other issues derived from Google'=
s

> announcement.

> >>

> >> I am not sure we can have a reasoned consideration of 'other =
issues

> derived'

> >> at such short notice.

> >>

> >> Look, I'd like our discussions and decisions to be informed a=
nd

> >> considered, and there simply isn't time for either.

> >>

> >>>

> >>> Harald

> >>>

> >>> _______________________________________________

> >>> rtcweb mailing list

> >>> rtcweb@ietf.org

> >>> https://www.ietf.org/mailman/listinfo/rtcweb

> >>

> >> David Singer

> >> Multimedia and Software Standards, Apple Inc.

> >>

> >> _______________________________________________

> >> rtcweb mailing list

> >> rtcweb@ietf.org

> >> https://www.ietf.org/mailman/listinfo/rtcweb

> >

> 

> ---

> Dr. Thomas Stockhammer (CEO) || 
stockhammer@nomor.de || phone +49

> 89 978980 02 || cell +491725702667 || 
http://www.nomor-research.com

> Nomor Research GmbH  -  Sitz der Gesellschaft: M=FCnchen - R=
egistergericht:

> M=FCnchen, HRB 165856 - Umsatzsteuer-ID: DE238047637 - Gesch=E4ftsf=FC=
hrer:

> Dr. Thomas Stockhammer, Dr. Ingo Viering.

> 

> 

> 

> _______________________________________________

> rtcweb mailing list

> =
rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________

rtcweb mailing list

rtcwe=
b@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb


















_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.=
ietf.org/mailman/listinfo/rtcweb








--_000_2981F52372AC43308D1F7DC4E2168C5Aqtiqualcommcom_--

From adam@nostrum.com  Wed Mar 13 21: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 5385B11E80DE for ; Wed, 13 Mar 2013 21:42:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.579
X-Spam-Level: 
X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.021, 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 3Yj7fUc9EkcO for ; Wed, 13 Mar 2013 21:42:32 -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 7486D11E809C for ; Wed, 13 Mar 2013 21:42:32 -0700 (PDT)
Received: from dhcp-45f8.meeting.ietf.org (dhcp-45f8.meeting.ietf.org [130.129.69.248]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2E4gUks024755 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 13 Mar 2013 23:42:30 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <51415535.9040203@nostrum.com>
Date: Thu, 14 Mar 2013 00:42:29 -0400
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Daryl Malas 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 130.129.69.248 is authenticated by a trusted mechanism)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] A different perspective on the video codec MTI 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: Thu, 14 Mar 2013 04:42:33 -0000

On 3/14/13 00:18, Daryl Malas wrote:
>  If VP8 is the only allowable codec

We are not having, and will never have, a "mandatory not to implement" 
conversation.

/a

From jmvalin@mozilla.com  Wed Mar 13 21: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 EFA8421F8E47 for ; Wed, 13 Mar 2013 21:55:27 -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 gFN0cvtRPH9D for ; Wed, 13 Mar 2013 21:55:23 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 33F3721F8E46 for ; Wed, 13 Mar 2013 21:55:17 -0700 (PDT)
Received: from [192.168.255.57] (unknown [216.189.219.66]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 30DA7F2111;  Wed, 13 Mar 2013 21:55:16 -0700 (PDT)
Message-ID: <51415833.1050503@mozilla.com>
Date: Thu, 14 Mar 2013 00:55:15 -0400
From: Jean-Marc Valin 
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: stephane.proust@orange.com
References: <31611_1363212891_5140FA5B_31611_17197_1_35788a76-852d-49ce-8987-d2be2f21fcaf@PEXCVZYH02.corporate.adroot.infra.ftgroup>  <3246_1363214890_5141022A_3246_1976_1_34a49fde-fad7-4a0a-8b01-9d48a5b6eeab@PEXCVZYH01.corporate.adroot.infra.ftgroup>
In-Reply-To: <3246_1363214890_5141022A_3246_1976_1_34a49fde-fad7-4a0a-8b01-9d48a5b6eeab@PEXCVZYH01.corporate.adroot.infra.ftgroup>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: "rtcweb@ietf.org" , MARJOU Xavier OLNC/OLN 
Subject: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 04:55:28 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/13/2013 06:48 PM, stephane.proust@orange.com wrote:
> The reason is simply that AMR and AMR-WB are supported in billions
> of devices !

Just curious, why exclude from the list other codecs with similar huge
deployment? I can think of at least:
- - GSM-FR (mobile)
- - Speex (Flash)
- - G.729 (PSTN gateways)
- - iLBC (PSTN gateways)
- - G.726 (DECT)
- - SILK (original non-Opus version in Skype)

(sorry, if I missed someone's favorite codec in this list)

It's not at all clear to me what's so special that makes AMR, AMR-WB
and G.722 different from the other codecs in the list above. Not that
I insist on shipping G.729 :-)

Personally, I'd favor a draft that included a lot more codecs,
describing for each one the benefits of supporting it. Implementers
could then choose which of these they care about for their particular
situation.

Cheers,

	Jean-Marc

> Stéphane
> 
> 
> -----Message d'origine----- De : Andrew Allen
> [mailto:aallen@blackberry.com] Envoyé : mercredi 13 mars 2013
> 23:41 À : PROUST Stephane OLNC/OLPS; Markus.Isomaki@nokia.com;
> jmvalin@mozilla.com Cc : MARJOU Xavier OLNC/OLN; rtcweb@ietf.org 
> Objet : Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
> 
> 
> No this wouldn't be acceptable to me.
> 
> I don't see a reason to push a particular set of Codecs over any
> other set of codecs supported on the device. If the device supports
> the codecs and they are available to the browser then we should
> recommend that they be offered in the negotiation.
> 
> The marjou draft can advertise the merits and reasons why they are
> good codecs to support.
> 
> 
> ----- Original Message ----- From: stephane.proust@orange.com
> [mailto:stephane.proust@orange.com] Sent: Wednesday, March 13, 2013
> 05:14 PM Central Standard Time To: Markus.Isomaki@nokia.com
> ; jmvalin@mozilla.com
>  Cc: MARJOU Xavier OLNC/OLN
> ; rtcweb@ietf.org  
> Subject: Re: [rtcweb] Agenda time	request	for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
> 
> Dear Markus
> 
> Thanks for your attempt to help !
> 
> Of course each Telco can handle this directly with vendors and
> browsers manufacturers at business level. But I don't'think this
> need of interoperability with mobile devices is specific to Orange.
> I think all mobile operators will have the same issue and this is
> why standardization exist. It's most cost and time efficient to
> have one common way forward for all the industry.
> 
> Then if the issue is that "conditional MUST/SHOULD are a too
> complicated requirement. We could also live as a compromise with a
> formulation that has already been suggested on the reflector:
> 
> "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" If possible with the addition of This
> is especially the case for AMR, AMR-WB for interoperability with
> mobile devices and G.722 for interoperability with fixed DECT
> CAT-iq devices
> 
> Would it have one chance to reach consensus ?
> 
> I think this Group should at least make one small step so that the
> interoperability issue with mobile terminals be not fully ignored
> in the RTC Web specification considering the huge number of
> deployed devices. At least something must be written on this !
> G.711 which is the only codec in addition to OPUS for
> interoperability purpose is not a proper answer to this.
> 
> Stéphane
> 
> -----Message d'origine----- De : Markus.Isomaki@nokia.com
> [mailto:Markus.Isomaki@nokia.com] Envoyé : mercredi 13 mars 2013
> 22:37 À : PROUST Stephane OLNC/OLPS; jmvalin@mozilla.com; MARJOU
> Xavier OLNC/OLN Cc : rtcweb@ietf.org Objet : RE: [rtcweb] Agenda
> time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
> 
> Hi Stephane, Xavier,
> 
> I understand the intent of your proposal. I'm not sure if the IETF
> is the best venue for you to pursue it, however. Perhaps you as a
> mobile operator should rather set it as a requirement to your
> mobile device platforms that they open up the APIs to AMR and
> AMR-WB and that at least the in-built default browser needs to
> support it. If there are enough operators setting such requirements
> directly to the device and platform vendors, it probably has a
> bigger impact than an IETF RFC. Getting that support for
> user-installed additional browsers might be more difficult, but
> most mobile device users stick with the default browser anyway.
> 
> The RTCWEB codec document needs to definitely explain this case and
> the benefits, but the conditional MUSTs or SHOULDs you are
> proposing are perhaps a bit too complicated. Hmm, perhaps we need
> to do an _informational_ RFC as something like "Recommendations for
> WebRTC on Mobile Devices" addressing the codec and perhaps other
> issues, that you could use as a reference in your requirements.
> 
> Markus
> 
> 
>> -----Original Message----- From: rtcweb-bounces@ietf.org
>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext
>> stephane.proust@orange.com Sent: 13 March, 2013 21:37 To:
>> Jean-Marc Valin; MARJOU Xavier OLNC/OLN Cc: rtcweb@ietf.org 
>> Subject: Re: [rtcweb] Agenda time request for 
>> draft-marjou-rtcweb-audio- codecs-for-interop-01
>> 
>> Hello
>> 
>> Our understanding is that the reason of the "no consensus" on 
>> additional recommended codecs was the additional costs for
>> browsers. The proposal is then to make these "MUST" fully
>> conditional to the case of no (or very reduced) additional costs,
>> when the codecs are already available on the device and when no
>> additional license fee is required
>> 
>> We could even live with lower level of "requirements" with
>> respectively May and Should (instead of Should and shall) but we
>> think that this proposal is a way to take into account both
>> browser manufacturers concerns on browsers costs and telcos
>> concerns on transcoding costs and some other companies share this
>> view.
>> 
>> Stéphane
>> 
>> 
>> 
>> 
>> 
>> 
>> -----Message d'origine----- De : rtcweb-bounces@ietf.org
>> [mailto:rtcweb-bounces@ietf.org] De la part de Jean-Marc Valin
>> Envoyé : mercredi 13 mars 2013 20:24 À : MARJOU Xavier OLNC/OLN
>> Cc : rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time request
>> for draft-marjou-rtcweb-audio-codecs-for-interop-01
>> 
> Hi,
> 
> I'd really like to understand how the chairs coming to the
> conclusion that there was *no consensus* on recommended codecs can
> result in a draft that includes 3 MUSTs and 1 SHOULD. This draft
> effectively makes 3 new codecs MTI for a range of devices. I
> understand that it's an individual draft and you can write whatever
> you like in there, but it definitely goes against the result of the
> WG discussion.
> 
> Cheers,
> 
> Jean-Marc
> 
> On 03/13/2013 09:14 AM, Xavier Marjou wrote:
>>>> Here is a summary of the 
>>>> draft-marjou-rtcweb-audio-codecs-for-interop-00 presentation
>>>> that I had prepared for yesterday's session:
>>>> 
>>>> - The co-authors want to underline that non-WebRTC voice
>>>> endpoints usually use one of the following codecs: AMR,
>>>> AMR-WB or G.722, which will result in massive transcoding
>>>> when there will be communications between WebRTC endpoints
>>>> and non-WebRTC endpoints.
>>>> 
>>>> - On one side, transcoding is bad for many reasons discussed
>>>> in the draft (cost issues, intrinsic quality degradation,
>>>> degraded interactivity, fallback from HD to G.711...);
>>>> 
>>>> - On the other side, it is recognized that implementing
>>>> additional codecs in the browsers can generate additional
>>>> costs.
>>>> 
>>>> - In order to reach a compromise, we would like to add some
>>>> text in the WG draft draft-ietf-rtcweb-audio providing
>>>> incentives for the browser to use these three codecs: make
>>>> them mandatory to implement when there is no cost impact on
>>>> the browser (e.g. if codec already installed, paid by the
>>>> device vendor...).
>>>> 
>>>> Any opinion on that?
>>>> 
>>>> Cheers,
>>>> 
>>>> Xavier
>>>> 
>>>> PS: I will be ready to present the slides on Thursday if time
>>>> permits it.
>>>> 
>>>> (c.f.
>>>> http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf
>>>>
>>>> 
)
>>>> 
>>>> 
>>>> 
>>>> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie
>>>> > wrote:
>>>> 
>>>> Magnus and I discussed this this morning, and we encourage
>>>> you to prepare something.  If the discussion of working group
>>>> last call items runs short, we may be able to fit this in at
>>>> that time or at the end of day one if its full agenda his
>>>> finished.  This is not a commitment, however, so please try
>>>> and get discussion on the list on the points from the draft
>>>> you feel need resolution.
>>>> 
>>>> regards,
>>>> 
>>>> Ted
>>>> 
>>>> 
>>>> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg) 
>>>> > wrote:
>>>>> Hello,
>>>>> 
>>>>> 
>>>>> 
>>>>> I would like to request agenda time for:
>>>>> 
>>>>> 
>>>>> 
>>>>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>>>>> 
>>>>> 
>>>>> 
>>>>> The document  presents use-cases underlining why WebRTC
>>>>> needs
>>>> AMR-WB,  AMR
>>>>> and G.722 as additional relevant voice codecs to
>>>>> satisfactorily ensure interoperability with existing
>>>>> systems.
>>>>> 
>>>>> 
>>>>> 
>>>>> A 10-minute time slot should be sufficient for presentation
>>>>> and
>>>> discussion.
>>>>> 
>>>>> 
>>>>> 
>>>>> Regards
>>>>> 
>>>>> 
>>>>> 
>>>>> -Espen
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________ 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
>> 
>> ___________________________________________________________ 
>> ___________________________________________________________ ___
>> 
>> Ce message et ses pieces jointes peuvent contenir des
>> informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous
>> avez recu ce message par erreur, veuillez le signaler a
>> l'expediteur et le detruire ainsi que les pieces jointes. Les
>> messages electroniques etant susceptibles d'alteration, France
>> Telecom - Orange decline toute responsabilite si ce message a ete
>> altere, deforme ou falsifie. Merci.
>> 
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law; they should
>> not be distributed, used or copied without authorisation. If you
>> have received this email in error, please notify the sender and 
>> delete this message and its attachments. As emails may be
>> altered, France Telecom - Orange is not liable for messages that
>> have been modified, changed or falsified. Thank you.
>> 
>> _______________________________________________ rtcweb mailing
>> list rtcweb@ietf.org 
>> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _________________________________________________________________________________________________________________________
>
>  Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi que les pieces jointes. Les messages electroniques
> etant susceptibles d'alteration, France Telecom - Orange decline
> toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should
> not be distributed, used or copied without authorisation. If you
> have received this email in error, please notify the sender and
> delete this message and its attachments. As emails may be altered,
> France Telecom - Orange is not liable for messages that have been
> modified, changed or falsified. Thank you.
> 
> _______________________________________________ rtcweb mailing
> list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
> 
> ---------------------------------------------------------------------
>
> 
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.
> 
> _________________________________________________________________________________________________________________________
>
>  Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi que les pieces jointes. Les messages electroniques
> etant susceptibles d'alteration, France Telecom - Orange decline
> toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should
> not be distributed, used or copied without authorisation. If you
> have received this email in error, please notify the sender and
> delete this message and its attachments. As emails may be altered,
> France Telecom - Orange is not liable for messages that have been
> modified, changed or falsified. Thank you.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRQVgzAAoJEJ6/8sItn9q9fgYH/jcWfhRrvPM1hJ22YcE7eR0N
OZzP/RvSrUBiIA6kG+6+Hvn5Lp/tXd+LxUDp5L8B3Toce7TBBAYNJP3M2cr8N8It
SjVvPHtBNKEqhBLbI4FbAouvymNH4utjAWR+MmF9LRySPXZ9nxLN0A13TeUlpZxt
Jaxr/n9AWwkKOk6BIo1Xztbk26MObiGVLhCE+CPoHaHe29bKblPcphBXC935ymHS
SuF2DXiAq0iKwZoVOsLe3RIaGg+bjN7N2MXi3Vphr7cOQK+JpdxURDrvmPh7/L8R
ht1RJt928yl4fEjnKhSKJLd1J+gPBe6vnkSxUp89as03bLirLwN1G2giD3YzfLM=
=K56v
-----END PGP SIGNATURE-----

From roman@telurix.com  Wed Mar 13 22:03: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 0244921F8D19 for ; Wed, 13 Mar 2013 22:03:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.769
X-Spam-Level: 
X-Spam-Status: No, score=-1.769 tagged_above=-999 required=5 tests=[AWL=0.208,  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 oKszQzzCCm+Z for ; Wed, 13 Mar 2013 22:03:23 -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 3A34821F8D22 for ; Wed, 13 Mar 2013 22:03:22 -0700 (PDT)
Received: by mail-wg0-f41.google.com with SMTP id ds1so1323042wgb.2 for ; Wed, 13 Mar 2013 22:03:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=kj7z7QOrasILLUcOPfBl8AQ4sBx1bIIxBkIEanPKe6s=; b=Tw9U8C9ihD8vuy8TLaOuBvOmT/BTrL8+etd3WXisdcHdCiYDlcWm02gAQvm1VzeRAd Hvf0EXIhE1OENaN0ZUJDvq7yJirr+xkCJ5ANiG4MgX53U/a1/OUNnuSI0arUXju5xd+h aam37yW1OjZF0JgUSJvkrXh/crafz5uA8ZDVgqqwPrzW29zl3qfYzxCYiR4+lEeLaUj8 oFsvac7dAyb/h+WDyl/Y1niP+EYNFR8gAV+c1RC+RS/ZOMXWrQ0IxEvLWxbdAwV10OHJ b01KXI7mZKDNhlFnO+xCjzlwFu9jP/CZoAWxt6b6BMb1hUVmwnwiAFdQmsSzcFVYB4+m 0mng==
X-Received: by 10.194.121.6 with SMTP id lg6mr1387918wjb.22.1363237401376; Wed, 13 Mar 2013 22:03:21 -0700 (PDT)
Received: from mail-wi0-x230.google.com ([2a00:1450:400c:c05::230]) by mx.google.com with ESMTPS id ek4sm6644945wib.11.2013.03.13.22.03.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Mar 2013 22:03:20 -0700 (PDT)
Received: by mail-wi0-f176.google.com with SMTP id hm14so3394235wib.3 for ; Wed, 13 Mar 2013 22:03:19 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.92.65 with SMTP id ck1mr1274255wjb.54.1363237399333; Wed, 13 Mar 2013 22:03:19 -0700 (PDT)
Received: by 10.217.107.135 with HTTP; Wed, 13 Mar 2013 22:03:19 -0700 (PDT)
In-Reply-To: <5141133D.3040100@alvestrand.no>
References: <5141133D.3040100@alvestrand.no>
Date: Thu, 14 Mar 2013 01:03:19 -0400
Message-ID: 
From: Roman Shpount 
To: Harald Alvestrand 
Content-Type: multipart/alternative; boundary=047d7bd91f10ee95ac04d7db70e5
X-Gm-Message-State: ALoCoQlZMY1RWmMXHHHFR5RzrO+CZwBDpEB6e0QSRsKKMRvGyzIQjlKFR/TD3pPVT8KgeAx6zsyb
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Audio transcoding: CPU costs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 05:03:24 -0000

--047d7bd91f10ee95ac04d7db70e5
Content-Type: text/plain; charset=ISO-8859-1

Though I generally agree with results of your analysis (CPU cost per minute
of transcoding is small), i would like to point out a few things regarding
this analysis:

1. Based on the message you are quoting, current performance is 150
channels per core. It would require some non-trivial work to get it to 500
channels.
2. Transcoding server would definitely need to purchase AMR/AMR-WB licenses.
3. Transcoding would require jitter buffer and other code which would not
be needed for ICE/SRTP gateway
4. Amazon AWS are not really usable for transcoding or any other real-time
specific operations. You end up with too much jitter when processing media
introduced by a virtualized instance.

Based on my benchmarks and my napkin based estimate ($4000 per
server amortized over 3 years, $300 per server per month to host it, 1000
channels of transcoding per server), the cost of one channel of transcoding
is about $0.4 per month vs about $0.02 per month for ICE/SRTP only gateway
(if transcoding is not needed, server can do 20,000 channels). This does
not take into account management and operation costs which grow
proportionally since you end up needing 20 times as much hardware. It also
does not include costs of software licenses. Depending on how spiky your
traffic is this can translate into different price per minute, but based on
our conference service we do about 12,000 minutes per channel per month
this translates into 0.003 cents per minute, which is not far from your
estimate.

Regards,
_____________
Roman Shpount


On Wed, Mar 13, 2013 at 8:01 PM, Harald Alvestrand wrote:

>  To return to the question of "cost of transcoding":
>
> - AMR is less complex to en/decode than OPUS. So the dominant cost of
> transcoding between OPUS and AMR is the OPUS operation.
> - http://www.ietf.org/mail-archive/web/rtcweb/current/msg05236.htmlestimates that OPUS en/decode can be done at ~1000 channels per CPU.
> - One machine for one minute on Amazon AWS costs 0.24 cents for a
> medium-sized "high-CPU instance" according to
> http://aws.amazon.com/ec2/pricing/ (0.145 dollars per hour).
> - Accordingly, transcoding, if done on fully loaded Amazon AWS instances,
> adds ~0.00024 cents per minute to the cost of a call.
>
> There are other ways to provide such a service. It seems unlikely to
> increase the CPU cost of the call by more than a factor of 100, so we're
> still below 0.024 cents per hour.
>
> I know there are other arguments for avoiding transcoding. But calling the
> CPU cost "negligible" seems appropriate in a world where mobile non-"all
> you can eat" plans still sell for tens of cents per minute.
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--047d7bd91f10ee95ac04d7db70e5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Though I generally agree with results of your analysis (CPU cost per minute=
 of transcoding is small), i would like to point out a few things regarding=
 this analysis:

1. Based on the message you are quo=
ting, current performance is 150 channels per core. It would require some n=
on-trivial work to get it to 500 channels.


2. Transcoding server would definitely need to purchase AMR/AMR-WB lic=
enses.
3. Transcoding would require jitter buffer and other code =
which would not be needed for ICE/SRTP gateway
4. Amazon AWS are =
not really usable for transcoding or any other real-time specific operation=
s. You end up with too much jitter when processing media introduced by a vi=
rtualized instance.



Based on my benchmarks and my napkin based estimate ($4=
000 per server=A0amortized=A0over 3 years, $300 per server per month to hos=
t it, 1000 channels of transcoding per server), the cost of one channel of =
transcoding is about $0.4 per month vs about $0.02 per month for ICE/SRTP o=
nly gateway (if transcoding is not needed, server can do 20,000 channels). =
This does not take into account management and operation costs which grow p=
roportionally since you end up needing 20 times as much hardware. It also d=
oes not include costs of software licenses. Depending on how spiky your tra=
ffic is this can translate into different price per minute, but based on ou=
r conference service we do about 12,000 minutes=A0per channel per month thi=
s translates into 0.003 cents per minute, which is not far from your estima=
te.



Regards,
_____________
Roman S=
hpount



On Wed, Mar 13, 2013 at 8:01 PM, Harald =
Alvestrand <harald@alvestrand.no> wrote:


 =20

   =20
 =20
  

    To return to the question of "cost of transcoding":

    

    - AMR is less complex to en/decode than OPUS. So the dominant cost
    of transcoding between OPUS and AMR is the OPUS operation.

    - http://www.ietf.org/mail-archive/web/rtcweb/curr=
ent/msg05236.html
    estimates that OPUS en/decode can be done at ~1000 channels per CPU.
    - One machine for one minute on Amazon AWS costs 0.24 cents for a
    medium-sized "high-CPU instance" according to
   =20
    http:/=
/aws.amazon.com/ec2/pricing/
    (0.145 dollars per hour).

    - Accordingly, transcoding, if done on fully loaded Amazon AWS
    instances, adds ~0.00024 cents per minute to the cost of a call.

    

    There are other ways to provide such a service. It seems unlikely to
    increase the CPU cost of the call by more than a factor of 100, so
    we're still below 0.024 cents per hour.

    

    I know there are other arguments for avoiding transcoding. But
    calling the CPU cost "negligible" seems appropriate in a worl=
d where
    mobile non-"all you can eat" plans still sell for tens of cen=
ts per
    minute.

    

  



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--047d7bd91f10ee95ac04d7db70e5--

From jmvalin@mozilla.com  Wed Mar 13 22:32: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 7C34021F8EEA for ; Wed, 13 Mar 2013 22:32:25 -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 NaiJ31l+h5eR for ; Wed, 13 Mar 2013 22:32:24 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id B7D7C21F8EF1 for ; Wed, 13 Mar 2013 22:32:24 -0700 (PDT)
Received: from [192.168.255.57] (unknown [216.189.219.66]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 36309F2026;  Wed, 13 Mar 2013 22:32:24 -0700 (PDT)
Message-ID: <514160E7.1090205@mozilla.com>
Date: Thu, 14 Mar 2013 01:32:23 -0400
From: Jean-Marc Valin 
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Roman Shpount 
References: <5141133D.3040100@alvestrand.no> 
In-Reply-To: 
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Audio transcoding: CPU costs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 05:32:25 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/14/2013 01:03 AM, Roman Shpount wrote:
> 1. Based on the message you are quoting, current performance is
> 150 channels per core. It would require some non-trivial work to
> get it to 500 channels.

Yeah, it'd probably take 2-3 weeks to write some assembly. Also, keep
in mind that these numbers were measured using a single core of a
laptop that just turned three years old
(http://ark.intel.com/products/43560/Intel-Core-i7-620M-Processor-4M-Cache-2_66-GHz).
I would expect your servers to have slightly more powerful CPUs :-)

	Jean-Marc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRQWDnAAoJEJ6/8sItn9q9/IAIAKxX5xG8ACKxhQrlMLjhD1eX
uhITi8mVOiE3wGuBbdge4JzAs7IlmJ+Db7sp0w7INmv8G0GgmOT44c3wZgU7l6LF
k5wKE6/UzCC+tFBtLVfuMJtvnswrjPEQvHkp9mM0U4sA1RBzIMv9NyCymt/zgQtG
3jlH9Tr9oD4n5Ug90UbRlF52cT5yfPL+nsDflCPhEcDvsnseckLQtO0N+kIBgabH
9MWh9sq3RFzwtE4iWq5vdzlhWnPd0qp7bAWa8flMA4DAfcgaYkXMh/N8ejo/zo0e
SAkL6jlMm259Nnl3fTVtD0SdPKTPUckRNuggai/GfHsgCrAFz0ua8sePyiQXZgg=
=yLLG
-----END PGP SIGNATURE-----

From oej@edvina.net  Thu Mar 14 00:51: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 E25F121F8DAB for ; Thu, 14 Mar 2013 00:51:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Level: 
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060,  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 uFW1o-mgUFBf for ; Thu, 14 Mar 2013 00:51:55 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF0B21F8A0D for ; Thu, 14 Mar 2013 00:51:50 -0700 (PDT)
Received: from [192.168.40.5] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 2530293DE40; Thu, 14 Mar 2013 07:51:38 +0000 (UTC)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: "Olle E. Johansson" 
In-Reply-To: <3246_1363214890_5141022A_3246_1976_1_34a49fde-fad7-4a0a-8b01-9d48a5b6eeab@PEXCVZYH01.corporate.adroot.infra.ftgroup>
Date: Thu, 14 Mar 2013 08:51:12 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <31611_1363212891_5140FA5B_31611_17197_1_35788a76-852d-49ce-8987-d2be2f21fcaf@PEXCVZYH02.corporate.adroot.infra.ftgroup>  <3246_1363214890_5141022A_3246_1976_1_34a49fde-fad7-4a0a-8b01-9d48a5b6eeab@PEXCVZYH01.corporate.adroot.infra.ftgroup>
To: 
X-Mailer: Apple Mail (2.1499)
Cc: MARJOU Xavier OLNC/OLN , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Agenda time	request	for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 07:51:56 -0000

13 mar 2013 kl. 23:48 skrev :

> The reason is simply that AMR and AMR-WB are supported in billions of =
devices !
I think it's time to stop discussing historical numbers, current numbers =
and future numbers of installed codecs in various devices. We're all =
impressed, but it doesn't seem to change our position on the MTI codec =
list.

This is a very complex matrix and the codec landscape is every changing. =
That's why the offer/answer exchange is open for future additions. SIP =
only mandated a very small set of codecs in RFC 3261 over ten years ago. =
That did not stop the use of AMR, G722, H.264 or other codecs in SIP =
devices today. I've even seen Opus being used in SIP without updating =
RFC 3261.=20

I'm pretty sure I will see quite a lot of offers with both AMR and H264 =
in WebRTC, as I have met them many times in my SIP life.

It seems that we need to clarify this openness to use any codec in the =
specification, since it seems to be widely misunderstood.

/O=

From stefan.lk.hakansson@ericsson.com  Thu Mar 14 02:58: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 59E6321F8F31 for ; Thu, 14 Mar 2013 02:58:55 -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=[AWL=0.000,  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 ClOVaoWSDgVO for ; Thu, 14 Mar 2013 02:58:55 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6F81821F8F2F for ; Thu, 14 Mar 2013 02:58:53 -0700 (PDT)
X-AuditID: c1b4fb25-b7f366d000004d10-63-51419f5c4177
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 30.3F.19728.C5F91415; Thu, 14 Mar 2013 10:58:53 +0100 (CET)
Received: from [150.132.141.119] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Thu, 14 Mar 2013 10:58:52 +0100
Message-ID: <51419F5C.1090002@ericsson.com>
Date: Thu, 14 Mar 2013 10:58:52 +0100
From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References:    <5140D259.6010208@mozilla.com> <31611_1363203420_5140D55C_31611_11752_1_cb7bfd1e-a4ca-40ba-bbbc-cb23fb3f3edb@PEXCVZYH02.corporate.adroot.infra.ftgroup>  <31611_1363212891_5140FA5B_31611_17197_1_35788a76-852d-49ce-8987-d2be2f21fcaf@PEXCVZYH02.corporate.adroot.infra.ftgroup>
In-Reply-To: <31611_1363212891_5140FA5B_31611_17197_1_35788a76-852d-49ce-8987-d2be2f21fcaf@PEXCVZYH02.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+JvjW7sfMdAg/P7mC3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRtPK8IIdrBWXH85iamDcyNLFyMkhIWAiMXPzGkYIW0ziwr31 bF2MXBxCAicZJWbuecoI4axllOh4txCsildAW2Lqmq/MXYwcHCwCqhKXzoqChNkEAiWu///F BBIWFYiSuLLPEqJaUOLkzCdgu0QEhCW2vuplArGFBWIl3uybDDV+I4vE5vM/mUEcToFWRoml 76eBdTAL2EpcmHMdypaX2P52DjOILSSgK/Hu9T3WCYwCs5AsmYWkZRaSlgWMzKsY2XMTM3PS y402MQLD7OCW36o7GO+cEznEKM3BoiTOG+56IUBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD 4+TS5QeqxZcfMvl1W6f9zpe3NhUnFZzWJW85f+R7mI2tSQyTm5S1Npvx42Rls4NXW7Wm/JdX T1uxULzz2CE2FpOzks8/Prz59trCwi9rlDekT5lmv+6jnO6GeFfO+/PXlZutT9Z9PyPg9rpn k9j2muj2KS+c/8vZ/UlT4S6GmyJ+uQ8iBB/WpiixFGckGmoxFxUnAgBpabeKAQIAAA==
Subject: Re: [rtcweb] Agenda time request	for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 09:58:55 -0000

On 2013-03-13 23:14, stephane.proust@orange.com wrote:
...
>
> Then if the issue is that "conditional MUST/SHOULD are a too
> complicated requirement. We could also live as a compromise with a
> formulation that has already been suggested on the reflector:
>
> "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"

To me, that sounds reasonable. The document could also reference some 
informational RFC (to be written) that list codecs, and under what 
circumstances they are suitable.

Stefan


From oej@edvina.net  Thu Mar 14 03:05: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 1B9F421F8DFF for ; Thu, 14 Mar 2013 03:05:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.394
X-Spam-Level: 
X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=-0.095, 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 eq90PtIaE9Tn for ; Thu, 14 Mar 2013 03:05:40 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC0421F8DD5 for ; Thu, 14 Mar 2013 03:05:39 -0700 (PDT)
Received: from [192.168.40.5] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id B23CC93DE3F; Thu, 14 Mar 2013 10:05:23 +0000 (UTC)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: "Olle E. Johansson" 
In-Reply-To: <51419F5C.1090002@ericsson.com>
Date: Thu, 14 Mar 2013 11:04:57 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <5B9BA9A0-9FD8-4A37-9EAC-9BAFEA73DC3B@edvina.net>
References:    <5140D259.6010208@mozilla.com> <31611_1363203420_5140D55C_31611_11752_1_cb7bfd1e-a4ca-40ba-bbbc-cb23fb3f3edb@PEXCVZYH02.corporate.adroot.infra.ftgroup>  <31611_1363212891_5140FA5B_31611_17197_1_35788a76-852d-49ce-8987-d2be2f21fcaf@PEXCVZYH02.corporate.adroot.infra.ftgroup> <51419F5C.1090002@ericsson.com>
To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= 
X-Mailer: Apple Mail (2.1499)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time request	for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 10:05:41 -0000

14 mar 2013 kl. 10:58 skrev Stefan H=E5kansson LK =
:

> On 2013-03-13 23:14, stephane.proust@orange.com wrote:
> ...
>>=20
>> Then if the issue is that "conditional MUST/SHOULD are a too
>> complicated requirement. We could also live as a compromise with a
>> formulation that has already been suggested on the reflector:
>>=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
> To me, that sounds reasonable. The document could also reference some =
informational RFC (to be written) that list codecs, and under what =
circumstances they are suitable.

That informational RFC would count as training material, but that never =
hurts.

I agree with this - but please change "audio codecs" to "multimedia =
codecs" since we now have both audio, video, text and other "codecs" =
under discussion. Also "the browser" is too limiting, since this applies =
to every piece of software using WebRTC, even though browsers have the =
highest priority.

/O=

From stefan.lk.hakansson@ericsson.com  Thu Mar 14 03:42: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 B51DC21F8DF9 for ; Thu, 14 Mar 2013 03:42:06 -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=[AWL=0.000,  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 pBfLmvMReXIE for ; Thu, 14 Mar 2013 03:42:06 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B196521F899E for ; Thu, 14 Mar 2013 03:42:05 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f316d0000028db-15-5141a97c3201
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 43.64.10459.C79A1415; Thu, 14 Mar 2013 11:42:04 +0100 (CET)
Received: from [150.132.141.119] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Thu, 14 Mar 2013 11:42:04 +0100
Message-ID: <5141A97B.6060200@ericsson.com>
Date: Thu, 14 Mar 2013 11:42:03 +0100
From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: "Olle E. Johansson" 
References:    <5140D259.6010208@mozilla.com> <31611_1363203420_5140D55C_31611_11752_1_cb7bfd1e-a4ca-40ba-bbbc-cb23fb3f3edb@PEXCVZYH02.corporate.adroot.infra.ftgroup>  <31611_1363212891_5140FA5B_31611_17197_1_35788a76-852d-49ce-8987-d2be2f21fcaf@PEXCVZYH02.corporate.adroot.infra.ftgroup> <51419F5C.1090002@ericsson.com> <5B9BA9A0-9FD8-4A37-9EAC-9BAFEA73DC3B@edvina.net>
In-Reply-To: <5B9BA9A0-9FD8-4A37-9EAC-9BAFEA73DC3B@edvina.net>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3RrdmpWOgQdcFRYuXqw8xW6z9187u wOQxbe1KVo8lS34yBTBFcdmkpOZklqUW6dslcGX07L7AVnCKu6Jl5QGWBsYlnF2MnBwSAiYS O5e/ZoawxSQu3FvP1sXIxSEkcJJRoun5ZrCEkMBaRolDrVYgNq+AtkTPnPmsIDaLgKrE5rcn wWrYBAIlrv//xdTFyMEhKhAlcWWfJUS5oMTJmU9YQGwRAQ2JC1+usIHYzALCEhsutoHFhQVi Jd7sm8wIsbeZVeLcyWeMIAlOATuJu69/MkM02EpcmHOdBcKWl2jeOhvqNl2Jd6/vsU5gFJyF ZN8sJC2zkLQsYGRexciem5iZk15uuIkRGJIHt/zW3cF46pzIIUZpDhYlcd4w1wsBQgLpiSWp 2ampBalF8UWlOanFhxiZODilGhg1L8w1+icis7dqSqpjp1GvcyWfbKBfxquIyxOzSuPLdD5W Rtvdjnpw0ynG9NI+HaPCahMtmUQm78urml61/mFb+e6EZ/Mjte37QrcU6umvYO7733rcl/OU kQ6r7HYWee7qiW9POa28q7NXwPn5luW8CT7FrNIGh/iMWs48ND1X/CVzRWHuMyWW4oxEQy3m ouJEAGxRZMMXAgAA
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time request	for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 10:42:06 -0000

On 2013-03-14 11:04, Olle E. Johansson wrote:
>
> 14 mar 2013 kl. 10:58 skrev Stefan Håkansson LK
> :
>
>> On 2013-03-13 23:14, stephane.proust@orange.com wrote: ...
>>>
>>> Then if the issue is that "conditional MUST/SHOULD are a too
>>> complicated requirement. We could also live as a compromise with
>>> a formulation that has already been suggested on the reflector:
>>>
>>> "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"
>>
>> To me, that sounds reasonable. The document could also reference
>> some informational RFC (to be written) that list codecs, and under
>> what circumstances they are suitable.
>
> That informational RFC would count as training material, but that
> never hurts.
>
> I agree with this - but please change "audio codecs" to "multimedia
> codecs" since we now have both audio, video, text and other "codecs"
> under discussion.

I think the intention was to add this text to draft-ietf-rtcweb-audio-01 
which would mean that only audio is in scope. But I agree, the sentence 
is equally valid for video.

> Also "the browser" is too limiting, since this
> applies to every piece of software using WebRTC, even though browsers
> have the highest priority.

I agree to this.

>
> /O
>


From tim@phonefromhere.com  Thu Mar 14 04:01: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 0ADE621F8E1D for ; Thu, 14 Mar 2013 04:01: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=[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 R20MyLi4huXL for ; Thu, 14 Mar 2013 04:01:32 -0700 (PDT)
Received: from smtp004.apm-internet.net (smtp004.apm-internet.net [85.119.248.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6C51721F8DF9 for ; Thu, 14 Mar 2013 04:01:30 -0700 (PDT)
Received: (qmail 59010 invoked from network); 14 Mar 2013 11:01:28 -0000
X-AV-Scan: clean
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp004.apm-internet.net with SMTP; 14 Mar 2013 11:01:28 -0000
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id BA8EF18A02BC; Thu, 14 Mar 2013 11:01:28 +0000 (GMT)
Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 9596618A021C;  Thu, 14 Mar 2013 11:01:28 +0000 (GMT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Tim Panton 
In-Reply-To: 
Date: Thu, 14 Mar 2013 11:01:27 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <31611_1363212891_5140FA5B_31611_17197_1_35788a76-852d-49ce-8987-d2be2f21fcaf@PEXCVZYH02.corporate.adroot.infra.ftgroup>  <3246_1363214890_5141022A_3246_1976_1_34a49fde-fad7-4a0a-8b01-9d48a5b6eeab@PEXCVZYH01.corporate.adroot.infra.ftgroup> 
To: Olle E. Johansson 
X-Mailer: Apple Mail (2.1283)
Cc: "rtcweb@ietf.org" , MARJOU Xavier OLNC/OLN 
Subject: Re: [rtcweb] Agenda time	request	for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 11:01:33 -0000

On 14 Mar 2013, at 07:51, Olle E. Johansson wrote:

>=20
> 13 mar 2013 kl. 23:48 skrev :
>=20
>> The reason is simply that AMR and AMR-WB are supported in billions of =
devices !
> I think it's time to stop discussing historical numbers, current =
numbers and future numbers of installed codecs in various devices. We're =
all impressed, but it doesn't seem to change our position on the MTI =
codec list.
>=20
> This is a very complex matrix and the codec landscape is every =
changing. That's why the offer/answer exchange is open for future =
additions. SIP only mandated a very small set of codecs in RFC 3261 over =
ten years ago. That did not stop the use of AMR, G722, H.264 or other =
codecs in SIP devices today. I've even seen Opus being used in SIP =
without updating RFC 3261.=20
>=20
> I'm pretty sure I will see quite a lot of offers with both AMR and =
H264 in WebRTC, as I have met them many times in my SIP life.
>=20
> It seems that we need to clarify this openness to use any codec in the =
specification, since it seems to be widely misunderstood.

What this discussion leads to is the need for application authors to be =
able to dynamically add codecs.
We need an API that supports codec insertion by the hosting web-site.=20
This would have 2 advantages:
	1) sites with specific needs would be able to supply codecs that =
were licensed per-user=20
(so MNOs could supply AMR-WB for the duration of a call, even to devices =
that don't normally support it - e.g. laptops )
(Cisco could supply h264 for a webex session)
	2) we future proof the WebRTC API - so when a new codec arrives =
that is especially good for watching small white dots moving at high =
speed,
the golf sites can use it.

In essence, extending the API using technology like Google's NaCl to =
deliver new codec, this decouples the supported  codec selection =
decision from the browser makers and pushes it up to the Application =
vendors.

Note, I'm not saying we should do this now. I am saying we should do =
this as a revision to webRTC - and yes, this discussion probably belongs =
in w3c land.

Tim.

=20=

From stefan.lk.hakansson@ericsson.com  Thu Mar 14 04:38: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 9C05C21F8FF3 for ; Thu, 14 Mar 2013 04:38:25 -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=[AWL=0.000,  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 E0g9N1Hfq1sj for ; Thu, 14 Mar 2013 04:38:21 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 253C721F8FF2 for ; Thu, 14 Mar 2013 04:38:20 -0700 (PDT)
X-AuditID: c1b4fb25-b7f366d000004d10-49-5141b6ab3807
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A6.B1.19728.BA6B1415; Thu, 14 Mar 2013 12:38:20 +0100 (CET)
Received: from Ericssons-MacBook-Pro-StefanH.local (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Thu, 14 Mar 2013 12:38:20 +0100
Message-ID: <5141B6B8.5020808@ericsson.com>
Date: Thu, 14 Mar 2013 12:38:32 +0100
From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <513F9011.4040900@ericsson.com> <513F997B.50807@nostrum.com> <513F9B90.4090802@ericsson.com> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAJMWRmVeSWpSXmKPExsUyM+Jvje6abY6BBsuWC1qs/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujEX35zAVvJetmHB7LksD43qxLkZODgkBE4mODxdYIGwxiQv3 1rN1MXJxCAmcZJR49XUrK4Szn1FiTdNqJpAqXgFtibNbTzCC2CwCqhLvXm5hB7HZBAIlrv// BVYjKpAssWFaDzNEvaDEyZlPwDaICAhLbH3VC1YjLGAuMX/eWhaIBWsZJWZOhmjgBBp0ZcV9 sCJmAVuJC3Ous0DY8hLNW2eD1QgJ6Eq8e32PdQKjwCwkO2YhaZmFpGUBI/MqRvbcxMyc9HKj TYzAUDu45bfqDsY750QOMUpzsCiJ84a7XggQEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwCgW rHXMupX9cuQ6/cK4E/8evJu5+ot5iviBPxP2TLx4sLVz/uHZ/i6vr4qdusjX+twyQ2fSW0Or L0uXLDtz+ntu1u29b65Z9Pk2S7QcUFhiV53ruHbu5ydcKv8rD3YmVT64KdnZUC/xWmfvEkcF 4fiLa7PqbaKqlQV7Y70jJHJlFIu/+N0UL1ViKc5INNRiLipOBAB3QLh9AwIAAA==
Subject: Re: [rtcweb] Datachannel adoption confirmation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 11:38:25 -0000

On 3/12/13 11:08 PM, Erik Lagerway wrote:
> As a remote participant, not sure if I was considered as contributing
> member in that meeting, I did hum for draft-jesup-rtcweb-data-protocol-04.

For clarification: I did too.

Stefan

>
> Best,
> Erik
>
> **Erik Lagerway  | **Hookflash
> **| 1 (855)**Hookflash ext. 2 | Twitter
>  | WebRTC Blog  **
> ********
>
>
> On Tue, Mar 12, 2013 at 2:18 PM, Magnus Westerlund
> >
> wrote:
>
>     Adam,
>
>     To my knowledge you where in the meeting and thus you don't need to
>     restate any position. I don't want all the person that actually was in
>     the meeting to restate their position here.
>
>     Cheers
>
>     Magnus
>
>     On 2013-03-12 17:09, Adam Roach wrote:
>      > I strongly support the use of draft-jesup-rtcweb-data-protocol as the
>      > basis for a working group document to address this issue.
>      >
>      > /a
>      >
>      > On 3/12/13 16:29, Magnus Westerlund wrote:
>      >> WG,
>      >>
>      >> In today's session we had a call for adopting as WG draft a
>     proposal as
>      >> the starting point for the Data channel management. There was a
>     strong
>      >> consensus in the meeting to pick
>     draft-jesup-rtcweb-data-protocol-04 as
>      >> that document.
>      >>
>      >> This is the confirmation on the mailing list, where people who
>     where not
>      >> present may express their position of which of the three proposals:
>      >>
>      >> - draft-jesup-rtcweb-data-protocol-04
>      >> - draft-thomson-rtcweb-data-00
>      >> - draft-marcon-rtcweb-data-channel-management-00
>      >>
>      >> Please provide any additional input by 19th of March.
>      >>
>      >> 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 
>      >>
>     ----------------------------------------------------------------------
>      >>
>      >> _______________________________________________
>      >> rtcweb mailing list
>      >> rtcweb@ietf.org 
>      >> https://www.ietf.org/mailman/listinfo/rtcweb
>      >
>      >
>      >
>
>
>     --
>
>     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
>     
>     ----------------------------------------------------------------------
>
>     _______________________________________________
>     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 fluffy@iii.ca  Thu Mar 14 05:06: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 E2D9621F8F3C for ; Thu, 14 Mar 2013 05:06:29 -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 IzquHMSHwm-L for ; Thu, 14 Mar 2013 05:06:25 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id CDC3821F8D42 for ; Thu, 14 Mar 2013 05:06:22 -0700 (PDT)
Received: from [130.129.130.30] (unknown [130.129.130.30]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1FA27509BA for ; Thu, 14 Mar 2013 08:06:22 -0400 (EDT)
From: Cullen Jennings 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Message-Id: <402DA32C-FC49-4D71-9BE1-C955C4564A37@iii.ca>
Date: Thu, 14 Mar 2013 07:06:27 -0500
To: "rtcweb@ietf.org" 
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
Subject: [rtcweb] Some videos to download for today presentation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 12:06:30 -0000

Download these two videos and see how you think they compare. Don=92t =
watch them on the dropbox site as it does funky things in it=92s =
playback. I'm going to be discussion them in my talk today and will try =
and show them on the screen but it will be easier to compare them if you =
just download them and play them on your own computer.=20

Video A: https://dl.dropbox.com/u/17089001/VidComp/a.mov

Video B: https://dl.dropbox.com/u/17089001/VidComp/b.mov


From Markus.Isomaki@nokia.com  Thu Mar 14 05:20: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 E701D21F8F86 for ; Thu, 14 Mar 2013 05:20:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4
X-Spam-Level: 
X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[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 l+h1FdFQjMx3 for ; Thu, 14 Mar 2013 05:20:13 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4A42021F8F37 for ; Thu, 14 Mar 2013 05:20:13 -0700 (PDT)
Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r2ECK5o1030418; Thu, 14 Mar 2013 14:20:08 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 14 Mar 2013 14:19:09 +0200
Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.232]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.02.0328.011; Thu, 14 Mar 2013 12:19:08 +0000
From: 
To: , 
Thread-Topic: [rtcweb] A different perspective on the video codec MTI discussion
Thread-Index: AQHOIG5nK5hZEqtrx0+EnSm6TS0GX5ilGeuw
Date: Thu, 14 Mar 2013 12:19:07 +0000
Message-ID: 
References:  <51415535.9040203@nostrum.com>
In-Reply-To: <51415535.9040203@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.129.67.65]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 14 Mar 2013 12:19:09.0131 (UTC) FILETIME=[210E59B0:01CE20AE]
X-Nokia-AV: Clean
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] A different perspective on the video codec MTI	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: Thu, 14 Mar 2013 12:20:14 -0000

Adam Roach wrote:
>
>On 3/14/13 00:18, Daryl Malas wrote:
>>  If VP8 is the only allowable codec
>
>We are not having, and will never have, a "mandatory not to implement"
>conversation.
>

Exect that there have been quite many statements by participants saying the=
y will never implement a particular codec regardless of its merits or  bene=
fits to the users, mainly due to IPR/cost reasons. So we do get a bit of th=
at flavor.=20

Markus =20

From randell-ietf@jesup.org  Thu Mar 14 05:29: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 BE73021F8EA8 for ; Thu, 14 Mar 2013 05:29:41 -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 EJhFYvf6otPa for ; Thu, 14 Mar 2013 05:29:41 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0E421F8E5D for ; Thu, 14 Mar 2013 05:29:41 -0700 (PDT)
Received: from dhcp-1229.meeting.ietf.org ([130.129.18.41]:62492) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UG7Hw-0001cx-KC for rtcweb@ietf.org; Thu, 14 Mar 2013 07:29:40 -0500
Message-ID: <5141C2B8.7020809@jesup.org>
Date: Thu, 14 Mar 2013 08:29:44 -0400
From: Randell Jesup 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
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
Subject: Re: [rtcweb] A different perspective on the video codec MTI 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: Thu, 14 Mar 2013 12:29:41 -0000

On 3/13/2013 6:06 PM, Jonathan Rosenberg wrote:
>
> I’d like to put a different perspective on the video MTI discussion.
>

Note: I haven't read the whole thread yet, but I'll make a comment 
anyways and read the rest this morning. :-)

> Many developers would probably love to connect users on the web with 
> users on mobile apps. Most mobile platforms today support H264 based 
> hardware acceleration for decode and sometimes encode, but not yet 
> VP8. Developers who want to build business communications clients will 
> need to connect those users with other users in the business, who may 
> be using videophones, PC clients, telepresence units or video room 
> systems, the vast majority of which do not support VP8 today, but many 
> of which do support H.264.

I'll note that (no new arguments here):
a) not all H.264 hardware is good at low-delay coding, or will support 
all the knobs we would like for realtime use
b) software encoding generally uses more power, but WiFi at constant 
send/receive and device displays use a lot of power, such that the 
reduction in talk time for software encoding (at least at lower 
resolutions)
c) existing applications using H.264 variants (i.e. Hangouts) are in 
wide use using software encoding (to the best of my knowledge)

Mobile devices without HW encode may be limited by running out of CPU 
due to resolution & framerate.

-- 
Randell Jesup
randell-ietf@jesup.org


From stephane.proust@orange.com  Thu Mar 14 05:36: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 6009D21F8F38 for ; Thu, 14 Mar 2013 05:36:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 Legb56KYYgyb for ; Thu, 14 Mar 2013 05:35:59 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 5269421F8EB1 for ; Thu, 14 Mar 2013 05:35:59 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 34DC13B4976; Thu, 14 Mar 2013 13:35:58 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 0EEFD4C017; Thu, 14 Mar 2013 13:35:58 +0100 (CET)
Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Thu, 14 Mar 2013 13:35:52 +0100
From: 
To: Jean-Marc Valin 
Thread-Topic: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIHAg2ECP5H1T90qzFszqZMyAx5ilHxjg
Date: Thu, 14 Mar 2013 12:35:45 +0000
Message-ID: <12711_1363264558_5141C42E_12711_1015_1_44e82a49-a4d3-4020-b26c-df36435f3ac8@PEXCVZYH01.corporate.adroot.infra.ftgroup>
References: <31611_1363212891_5140FA5B_31611_17197_1_35788a76-852d-49ce-8987-d2be2f21fcaf@PEXCVZYH02.corporate.adroot.infra.ftgroup>  <3246_1363214890_5141022A_3246_1976_1_34a49fde-fad7-4a0a-8b01-9d48a5b6eeab@PEXCVZYH01.corporate.adroot.infra.ftgroup> <51415833.1050503@mozilla.com>
In-Reply-To: <51415833.1050503@mozilla.com>
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.5.94520
Cc: "rtcweb@ietf.org" , MARJOU Xavier OLNC/OLN 
Subject: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 12:36:04 -0000

Hello=20

The short list is aligned to what is specified in 3GPP (mobile) and CAT-iq =
(fixed). Check the related service specifications!
The short list (AMR, AMR-WB, G.722) is a minimal subset of codecs to minimi=
ze interop issues and transcoding costs for telco services.=20
It's not a question of what's the favourite codec for a given application. =
It's interop with billions of mobile phones and with fixed terminals in leg=
acy telephony services.=20

St=E9phane

-----Message d'origine-----
De=A0: Jean-Marc Valin [mailto:jmvalin@mozilla.com]=20
Envoy=E9=A0: jeudi 14 mars 2013 05:55
=C0=A0: PROUST Stephane OLNC/OLPS
Cc=A0: Andrew Allen; Markus.Isomaki@nokia.com; MARJOU Xavier OLNC/OLN; rtcw=
eb@ietf.org
Objet=A0: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-co=
decs-for-interop-01

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/13/2013 06:48 PM, stephane.proust@orange.com wrote:
> The reason is simply that AMR and AMR-WB are supported in billions of=20
> devices !

Just curious, why exclude from the list other codecs with similar huge depl=
oyment? I can think of at least:
- - GSM-FR (mobile)
- - Speex (Flash)
- - G.729 (PSTN gateways)
- - iLBC (PSTN gateways)
- - G.726 (DECT)
- - SILK (original non-Opus version in Skype)

(sorry, if I missed someone's favorite codec in this list)

It's not at all clear to me what's so special that makes AMR, AMR-WB and G.=
722 different from the other codecs in the list above. Not that I insist on=
 shipping G.729 :-)

Personally, I'd favor a draft that included a lot more codecs, describing f=
or each one the benefits of supporting it. Implementers could then choose w=
hich of these they care about for their particular situation.

Cheers,

	Jean-Marc

> St=E9phane
>=20
>=20
> -----Message d'origine----- De : Andrew Allen=20
> [mailto:aallen@blackberry.com] Envoy=E9 : mercredi 13 mars 2013
> 23:41 =C0 : PROUST Stephane OLNC/OLPS; Markus.Isomaki@nokia.com;=20
> jmvalin@mozilla.com Cc : MARJOU Xavier OLNC/OLN; rtcweb@ietf.org Objet=20
> : Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>=20
>=20
> No this wouldn't be acceptable to me.
>=20
> I don't see a reason to push a particular set of Codecs over any other=20
> set of codecs supported on the device. If the device supports the=20
> codecs and they are available to the browser then we should recommend=20
> that they be offered in the negotiation.
>=20
> The marjou draft can advertise the merits and reasons why they are=20
> good codecs to support.
>=20
>=20
> ----- Original Message ----- From: stephane.proust@orange.com=20
> [mailto:stephane.proust@orange.com] Sent: Wednesday, March 13, 2013
> 05:14 PM Central Standard Time To: Markus.Isomaki@nokia.com=20
> ; jmvalin@mozilla.com =20
> Cc: MARJOU Xavier OLNC/OLN ; rtcweb@ietf.org=20
> 
> Subject: Re: [rtcweb] Agenda time	request	for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>=20
> Dear Markus
>=20
> Thanks for your attempt to help !
>=20
> Of course each Telco can handle this directly with vendors and=20
> browsers manufacturers at business level. But I don't'think this need=20
> of interoperability with mobile devices is specific to Orange.
> I think all mobile operators will have the same issue and this is why=20
> standardization exist. It's most cost and time efficient to have one=20
> common way forward for all the industry.
>=20
> Then if the issue is that "conditional MUST/SHOULD are a too=20
> complicated requirement. We could also live as a compromise with a=20
> formulation that has already been suggested on the reflector:
>=20
> "If other suitable audio codecs are available to the browser to use it=20
> is recommended that they are also included in the offer in order to=20
> maximize the possibility to establish the session without the need for=20
> audio transcoding" If possible with the addition of This is especially=20
> the case for AMR, AMR-WB for interoperability with mobile devices and=20
> G.722 for interoperability with fixed DECT CAT-iq devices
>=20
> Would it have one chance to reach consensus ?
>=20
> I think this Group should at least make one small step so that the=20
> interoperability issue with mobile terminals be not fully ignored in=20
> the RTC Web specification considering the huge number of deployed=20
> devices. At least something must be written on this !
> G.711 which is the only codec in addition to OPUS for interoperability=20
> purpose is not a proper answer to this.
>=20
> St=E9phane
>=20
> -----Message d'origine----- De : Markus.Isomaki@nokia.com=20
> [mailto:Markus.Isomaki@nokia.com] Envoy=E9 : mercredi 13 mars 2013
> 22:37 =C0 : PROUST Stephane OLNC/OLPS; jmvalin@mozilla.com; MARJOU=20
> Xavier OLNC/OLN Cc : rtcweb@ietf.org Objet : RE: [rtcweb] Agenda time=20
> request for draft-marjou-rtcweb-audio-codecs-for-interop-01
>=20
> Hi Stephane, Xavier,
>=20
> I understand the intent of your proposal. I'm not sure if the IETF is=20
> the best venue for you to pursue it, however. Perhaps you as a mobile=20
> operator should rather set it as a requirement to your mobile device=20
> platforms that they open up the APIs to AMR and AMR-WB and that at=20
> least the in-built default browser needs to support it. If there are=20
> enough operators setting such requirements directly to the device and=20
> platform vendors, it probably has a bigger impact than an IETF RFC.=20
> Getting that support for user-installed additional browsers might be=20
> more difficult, but most mobile device users stick with the default=20
> browser anyway.
>=20
> The RTCWEB codec document needs to definitely explain this case and=20
> the benefits, but the conditional MUSTs or SHOULDs you are proposing=20
> are perhaps a bit too complicated. Hmm, perhaps we need to do an=20
> _informational_ RFC as something like "Recommendations for WebRTC on=20
> Mobile Devices" addressing the codec and perhaps other issues, that=20
> you could use as a reference in your requirements.
>=20
> Markus
>=20
>=20
>> -----Original Message----- From: rtcweb-bounces@ietf.org=20
>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext=20
>> stephane.proust@orange.com Sent: 13 March, 2013 21:37 To:
>> Jean-Marc Valin; MARJOU Xavier OLNC/OLN Cc: rtcweb@ietf.org
>> Subject: Re: [rtcweb] Agenda time request for
>> draft-marjou-rtcweb-audio- codecs-for-interop-01
>>=20
>> Hello
>>=20
>> Our understanding is that the reason of the "no consensus" on=20
>> additional recommended codecs was the additional costs for browsers.=20
>> The proposal is then to make these "MUST" fully conditional to the=20
>> case of no (or very reduced) additional costs, when the codecs are=20
>> already available on the device and when no additional license fee is=20
>> required
>>=20
>> We could even live with lower level of "requirements" with=20
>> respectively May and Should (instead of Should and shall) but we=20
>> think that this proposal is a way to take into account both browser=20
>> manufacturers concerns on browsers costs and telcos concerns on=20
>> transcoding costs and some other companies share this view.
>>=20
>> St=E9phane
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> -----Message d'origine----- De : rtcweb-bounces@ietf.org=20
>> [mailto:rtcweb-bounces@ietf.org] De la part de Jean-Marc Valin Envoy=E9=
=20
>> : mercredi 13 mars 2013 20:24 =C0 : MARJOU Xavier OLNC/OLN Cc :=20
>> rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time request for=20
>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>>=20
> Hi,
>=20
> I'd really like to understand how the chairs coming to the conclusion=20
> that there was *no consensus* on recommended codecs can result in a=20
> draft that includes 3 MUSTs and 1 SHOULD. This draft effectively makes=20
> 3 new codecs MTI for a range of devices. I understand that it's an=20
> individual draft and you can write whatever you like in there, but it=20
> definitely goes against the result of the WG discussion.
>=20
> Cheers,
>=20
> Jean-Marc
>=20
> On 03/13/2013 09:14 AM, Xavier Marjou wrote:
>>>> Here is a summary of the
>>>> draft-marjou-rtcweb-audio-codecs-for-interop-00 presentation that I=20
>>>> had prepared for yesterday's session:
>>>>=20
>>>> - The co-authors want to underline that non-WebRTC voice endpoints=20
>>>> usually use one of the following codecs: AMR, AMR-WB or G.722,=20
>>>> which will result in massive transcoding when there will be=20
>>>> communications between WebRTC endpoints and non-WebRTC endpoints.
>>>>=20
>>>> - On one side, transcoding is bad for many reasons discussed in the=20
>>>> draft (cost issues, intrinsic quality degradation, degraded=20
>>>> interactivity, fallback from HD to G.711...);
>>>>=20
>>>> - On the other side, it is recognized that implementing additional=20
>>>> codecs in the browsers can generate additional costs.
>>>>=20
>>>> - In order to reach a compromise, we would like to add some text in=20
>>>> the WG draft draft-ietf-rtcweb-audio providing incentives for the=20
>>>> browser to use these three codecs: make them mandatory to implement=20
>>>> when there is no cost impact on the browser (e.g. if codec already=20
>>>> installed, paid by the device vendor...).
>>>>=20
>>>> Any opinion on that?
>>>>=20
>>>> Cheers,
>>>>=20
>>>> Xavier
>>>>=20
>>>> PS: I will be ready to present the slides on Thursday if time=20
>>>> permits it.
>>>>=20
>>>> (c.f.
>>>> http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf
>>>>
>>>>=20
)
>>>>=20
>>>>=20
>>>>=20
>>>> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie >>> > wrote:
>>>>=20
>>>> Magnus and I discussed this this morning, and we encourage you to=20
>>>> prepare something.  If the discussion of working group last call=20
>>>> items runs short, we may be able to fit this in at that time or at=20
>>>> the end of day one if its full agenda his finished.  This is not a=20
>>>> commitment, however, so please try and get discussion on the list=20
>>>> on the points from the draft you feel need resolution.
>>>>=20
>>>> regards,
>>>>=20
>>>> Ted
>>>>=20
>>>>=20
>>>> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)=20
>>>> > wrote:
>>>>> Hello,
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> I would like to request agenda time for:
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> The document  presents use-cases underlining why WebRTC needs
>>>> AMR-WB,  AMR
>>>>> and G.722 as additional relevant voice codecs to satisfactorily=20
>>>>> ensure interoperability with existing systems.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> A 10-minute time slot should be sufficient for presentation and
>>>> discussion.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> Regards
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> -Espen
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________ rtcweb
> mailing list
>>>>> rtcweb@ietf.org =20
>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>>=20
>>>> _______________________________________________ rtcweb
> mailing list
>>>> rtcweb@ietf.org =20
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________ rtcweb
> mailing list
>>>> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
>>>>=20
>=20
>> _______________________________________________ rtcweb mailing list=20
>> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
>>=20
>> ___________________________________________________________
>> ___________________________________________________________ ___
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations=20
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
>> exploites ou copies sans autorisation. Si vous avez recu ce message=20
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20
>> que les pieces jointes. Les messages electroniques etant susceptibles=20
>> d'alteration, France Telecom - Orange decline toute responsabilite si=20
>> ce message a ete altere, deforme ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or=20
>> privileged information that may be protected by law; they should not=20
>> be distributed, used or copied without authorisation. If you have=20
>> received this email in error, please notify the sender and delete=20
>> this message and its attachments. As emails may be altered, France=20
>> Telecom - Orange is not liable for messages that have been modified,=20
>> changed or falsified. Thank you.
>>=20
>> _______________________________________________ rtcweb mailing list=20
>> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
>=20
> ______________________________________________________________________
> ___________________________________________________
>
>  Ce message et ses pieces jointes peuvent contenir des informations=20
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
> exploites ou copies sans autorisation. Si vous avez recu ce message=20
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20
> que les pieces jointes. Les messages electroniques etant susceptibles=20
> d'alteration, France Telecom - Orange decline toute responsabilite si=20
> ce message a ete altere, deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or=20
> privileged information that may be protected by law; they should not=20
> be distributed, used or copied without authorisation. If you have=20
> received this email in error, please notify the sender and delete this=20
> message and its attachments. As emails may be altered, France Telecom=20
> - Orange is not liable for messages that have been modified, changed=20
> or falsified. Thank you.
>=20
> _______________________________________________ rtcweb mailing list=20
> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
>=20
> ---------------------------------------------------------------------
>
>=20
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.
>=20
> ______________________________________________________________________
> ___________________________________________________
>
>  Ce message et ses pieces jointes peuvent contenir des informations=20
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
> exploites ou copies sans autorisation. Si vous avez recu ce message=20
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20
> que les pieces jointes. Les messages electroniques etant susceptibles=20
> d'alteration, France Telecom - Orange decline toute responsabilite si=20
> ce message a ete altere, deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or=20
> privileged information that may be protected by law; they should not=20
> be distributed, used or copied without authorisation. If you have=20
> received this email in error, please notify the sender and delete this=20
> message and its attachments. As emails may be altered, France Telecom=20
> - Orange is not liable for messages that have been modified, changed=20
> or falsified. Thank you.
>=20

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRQVgzAAoJEJ6/8sItn9q9fgYH/jcWfhRrvPM1hJ22YcE7eR0N
OZzP/RvSrUBiIA6kG+6+Hvn5Lp/tXd+LxUDp5L8B3Toce7TBBAYNJP3M2cr8N8It
SjVvPHtBNKEqhBLbI4FbAouvymNH4utjAWR+MmF9LRySPXZ9nxLN0A13TeUlpZxt
Jaxr/n9AWwkKOk6BIo1Xztbk26MObiGVLhCE+CPoHaHe29bKblPcphBXC935ymHS
SuF2DXiAq0iKwZoVOsLe3RIaGg+bjN7N2MXi3Vphr7cOQK+JpdxURDrvmPh7/L8R
ht1RJt928yl4fEjnKhSKJLd1J+gPBe6vnkSxUp89as03bLirLwN1G2giD3YzfLM=3D
=3DK56v
-----END PGP SIGNATURE-----

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.


From espeberg@cisco.com  Thu Mar 14 05:59: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 1723F11E80F5 for ; Thu, 14 Mar 2013 05:59:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level: 
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[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 Tz4sP2sC4VR4 for ; Thu, 14 Mar 2013 05:59:50 -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 C2C5111E80E4 for ; Thu, 14 Mar 2013 05:59:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18574; q=dns/txt; s=iport; t=1363265988; x=1364475588; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=67+I9jKlVHUIV1cZbRqhhRDcWlE+pcsmuEpKA4cTl1o=; b=IQfX3kuRR++D2c+hSPlwxqNoSZx6P/vpVLUAY4MLkF8tyfB6i5R0STzV vFvb9iZIBoOinAiVSXVUVOtfZaqaQcoH1yVexFaFwL4yx+6lESAU3EiMz fXGAdLAG6jc2nJWC1xJJ07DXoiZBwRhrf/IwyPY0X/++YMzjng6cv3KSA M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAEnJQVGtJV2b/2dsb2JhbABDxHqBYhZ0gioBAQECAQEBAQFrCwUHBAIBCBEEAQEBCgsSByEGCxQJCAIEAQ0FCId6AwkGDLckDYlbjEaBCYEQBiAGBQcCBASCVWEDiD6KVYFlgn+KSYUagVSBNoFzNQ
X-IronPort-AV: E=Sophos;i="4.84,845,1355097600"; d="scan'208";a="187201847"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 14 Mar 2013 12:59:47 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2ECxlqO004498 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Mar 2013 12:59:47 GMT
Received: from xmb-rcd-x11.cisco.com ([169.254.1.206]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 07:59:47 -0500
From: "Espen Berger (espeberg)" 
To: "stephane.proust@orange.com" , Jean-Marc Valin 
Thread-Topic: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOILCCzq/6Gd4gs0OnTVUoMe5v55ilJXhg
Date: Thu, 14 Mar 2013 12:59:46 +0000
Message-ID: 
References: <31611_1363212891_5140FA5B_31611_17197_1_35788a76-852d-49ce-8987-d2be2f21fcaf@PEXCVZYH02.corporate.adroot.infra.ftgroup>  <3246_1363214890_5141022A_3246_1976_1_34a49fde-fad7-4a0a-8b01-9d48a5b6eeab@PEXCVZYH01.corporate.adroot.infra.ftgroup> <51415833.1050503@mozilla.com> <12711_1363264558_5141C42E_12711_1015_1_44e82a49-a4d3-4020-b26c-df36435f3ac8@PEXCVZYH01.corporate.adroot.infra.ftgroup>
In-Reply-To: <12711_1363264558_5141C42E_12711_1015_1_44e82a49-a4d3-4020-b26c-df36435f3ac8@PEXCVZYH01.corporate.adroot.infra.ftgroup>
Accept-Language: nb-NO, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.147.112.106]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: MARJOU Xavier OLNC/OLN , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 12:59:56 -0000

I support this statement.=20

The reason to support AMR, AMR-WB and G722 is to have a minimal set of comm=
on audio codecs available to avoid transcoding in the common cases.=20

-Espen=20


-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 stephane.proust@orange.com
Sent: 14. mars 2013 13:36
To: Jean-Marc Valin
Cc: rtcweb@ietf.org; MARJOU Xavier OLNC/OLN
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01

Hello=20

The short list is aligned to what is specified in 3GPP (mobile) and CAT-iq =
(fixed). Check the related service specifications!
The short list (AMR, AMR-WB, G.722) is a minimal subset of codecs to minimi=
ze interop issues and transcoding costs for telco services.=20
It's not a question of what's the favourite codec for a given application. =
It's interop with billions of mobile phones and with fixed terminals in leg=
acy telephony services.=20

St=E9phane

-----Message d'origine-----
De=A0: Jean-Marc Valin [mailto:jmvalin@mozilla.com] Envoy=E9=A0: jeudi 14 m=
ars 2013 05:55 =C0=A0: PROUST Stephane OLNC/OLPS Cc=A0: Andrew Allen; Marku=
s.Isomaki@nokia.com; MARJOU Xavier OLNC/OLN; rtcweb@ietf.org Objet=A0: Re: =
[rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-inter=
op-01

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/13/2013 06:48 PM, stephane.proust@orange.com wrote:
> The reason is simply that AMR and AMR-WB are supported in billions of=20
> devices !

Just curious, why exclude from the list other codecs with similar huge depl=
oyment? I can think of at least:
- - GSM-FR (mobile)
- - Speex (Flash)
- - G.729 (PSTN gateways)
- - iLBC (PSTN gateways)
- - G.726 (DECT)
- - SILK (original non-Opus version in Skype)

(sorry, if I missed someone's favorite codec in this list)

It's not at all clear to me what's so special that makes AMR, AMR-WB and G.=
722 different from the other codecs in the list above. Not that I insist on=
 shipping G.729 :-)

Personally, I'd favor a draft that included a lot more codecs, describing f=
or each one the benefits of supporting it. Implementers could then choose w=
hich of these they care about for their particular situation.

Cheers,

	Jean-Marc

> St=E9phane
>=20
>=20
> -----Message d'origine----- De : Andrew Allen=20
> [mailto:aallen@blackberry.com] Envoy=E9 : mercredi 13 mars 2013
> 23:41 =C0 : PROUST Stephane OLNC/OLPS; Markus.Isomaki@nokia.com;=20
> jmvalin@mozilla.com Cc : MARJOU Xavier OLNC/OLN; rtcweb@ietf.org Objet
> : Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>=20
>=20
> No this wouldn't be acceptable to me.
>=20
> I don't see a reason to push a particular set of Codecs over any other=20
> set of codecs supported on the device. If the device supports the=20
> codecs and they are available to the browser then we should recommend=20
> that they be offered in the negotiation.
>=20
> The marjou draft can advertise the merits and reasons why they are=20
> good codecs to support.
>=20
>=20
> ----- Original Message ----- From: stephane.proust@orange.com=20
> [mailto:stephane.proust@orange.com] Sent: Wednesday, March 13, 2013
> 05:14 PM Central Standard Time To: Markus.Isomaki@nokia.com=20
> ; jmvalin@mozilla.com 
> Cc: MARJOU Xavier OLNC/OLN ; rtcweb@ietf.org=20
> 
> Subject: Re: [rtcweb] Agenda time	request	for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>=20
> Dear Markus
>=20
> Thanks for your attempt to help !
>=20
> Of course each Telco can handle this directly with vendors and=20
> browsers manufacturers at business level. But I don't'think this need=20
> of interoperability with mobile devices is specific to Orange.
> I think all mobile operators will have the same issue and this is why=20
> standardization exist. It's most cost and time efficient to have one=20
> common way forward for all the industry.
>=20
> Then if the issue is that "conditional MUST/SHOULD are a too=20
> complicated requirement. We could also live as a compromise with a=20
> formulation that has already been suggested on the reflector:
>=20
> "If other suitable audio codecs are available to the browser to use it=20
> is recommended that they are also included in the offer in order to=20
> maximize the possibility to establish the session without the need for=20
> audio transcoding" If possible with the addition of This is especially=20
> the case for AMR, AMR-WB for interoperability with mobile devices and
> G.722 for interoperability with fixed DECT CAT-iq devices
>=20
> Would it have one chance to reach consensus ?
>=20
> I think this Group should at least make one small step so that the=20
> interoperability issue with mobile terminals be not fully ignored in=20
> the RTC Web specification considering the huge number of deployed=20
> devices. At least something must be written on this !
> G.711 which is the only codec in addition to OPUS for interoperability=20
> purpose is not a proper answer to this.
>=20
> St=E9phane
>=20
> -----Message d'origine----- De : Markus.Isomaki@nokia.com=20
> [mailto:Markus.Isomaki@nokia.com] Envoy=E9 : mercredi 13 mars 2013
> 22:37 =C0 : PROUST Stephane OLNC/OLPS; jmvalin@mozilla.com; MARJOU=20
> Xavier OLNC/OLN Cc : rtcweb@ietf.org Objet : RE: [rtcweb] Agenda time=20
> request for draft-marjou-rtcweb-audio-codecs-for-interop-01
>=20
> Hi Stephane, Xavier,
>=20
> I understand the intent of your proposal. I'm not sure if the IETF is=20
> the best venue for you to pursue it, however. Perhaps you as a mobile=20
> operator should rather set it as a requirement to your mobile device=20
> platforms that they open up the APIs to AMR and AMR-WB and that at=20
> least the in-built default browser needs to support it. If there are=20
> enough operators setting such requirements directly to the device and=20
> platform vendors, it probably has a bigger impact than an IETF RFC.
> Getting that support for user-installed additional browsers might be=20
> more difficult, but most mobile device users stick with the default=20
> browser anyway.
>=20
> The RTCWEB codec document needs to definitely explain this case and=20
> the benefits, but the conditional MUSTs or SHOULDs you are proposing=20
> are perhaps a bit too complicated. Hmm, perhaps we need to do an=20
> _informational_ RFC as something like "Recommendations for WebRTC on=20
> Mobile Devices" addressing the codec and perhaps other issues, that=20
> you could use as a reference in your requirements.
>=20
> Markus
>=20
>=20
>> -----Original Message----- From: rtcweb-bounces@ietf.org=20
>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext=20
>> stephane.proust@orange.com Sent: 13 March, 2013 21:37 To:
>> Jean-Marc Valin; MARJOU Xavier OLNC/OLN Cc: rtcweb@ietf.org
>> Subject: Re: [rtcweb] Agenda time request for
>> draft-marjou-rtcweb-audio- codecs-for-interop-01
>>=20
>> Hello
>>=20
>> Our understanding is that the reason of the "no consensus" on=20
>> additional recommended codecs was the additional costs for browsers.
>> The proposal is then to make these "MUST" fully conditional to the=20
>> case of no (or very reduced) additional costs, when the codecs are=20
>> already available on the device and when no additional license fee is=20
>> required
>>=20
>> We could even live with lower level of "requirements" with=20
>> respectively May and Should (instead of Should and shall) but we=20
>> think that this proposal is a way to take into account both browser=20
>> manufacturers concerns on browsers costs and telcos concerns on=20
>> transcoding costs and some other companies share this view.
>>=20
>> St=E9phane
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> -----Message d'origine----- De : rtcweb-bounces@ietf.org=20
>> [mailto:rtcweb-bounces@ietf.org] De la part de Jean-Marc Valin Envoy=E9
>> : mercredi 13 mars 2013 20:24 =C0 : MARJOU Xavier OLNC/OLN Cc :=20
>> rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time request for
>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>>=20
> Hi,
>=20
> I'd really like to understand how the chairs coming to the conclusion=20
> that there was *no consensus* on recommended codecs can result in a=20
> draft that includes 3 MUSTs and 1 SHOULD. This draft effectively makes
> 3 new codecs MTI for a range of devices. I understand that it's an=20
> individual draft and you can write whatever you like in there, but it=20
> definitely goes against the result of the WG discussion.
>=20
> Cheers,
>=20
> Jean-Marc
>=20
> On 03/13/2013 09:14 AM, Xavier Marjou wrote:
>>>> Here is a summary of the
>>>> draft-marjou-rtcweb-audio-codecs-for-interop-00 presentation that I=20
>>>> had prepared for yesterday's session:
>>>>=20
>>>> - The co-authors want to underline that non-WebRTC voice endpoints=20
>>>> usually use one of the following codecs: AMR, AMR-WB or G.722,=20
>>>> which will result in massive transcoding when there will be=20
>>>> communications between WebRTC endpoints and non-WebRTC endpoints.
>>>>=20
>>>> - On one side, transcoding is bad for many reasons discussed in the=20
>>>> draft (cost issues, intrinsic quality degradation, degraded=20
>>>> interactivity, fallback from HD to G.711...);
>>>>=20
>>>> - On the other side, it is recognized that implementing additional=20
>>>> codecs in the browsers can generate additional costs.
>>>>=20
>>>> - In order to reach a compromise, we would like to add some text in=20
>>>> the WG draft draft-ietf-rtcweb-audio providing incentives for the=20
>>>> browser to use these three codecs: make them mandatory to implement=20
>>>> when there is no cost impact on the browser (e.g. if codec already=20
>>>> installed, paid by the device vendor...).
>>>>=20
>>>> Any opinion on that?
>>>>=20
>>>> Cheers,
>>>>=20
>>>> Xavier
>>>>=20
>>>> PS: I will be ready to present the slides on Thursday if time=20
>>>> permits it.
>>>>=20
>>>> (c.f.
>>>> http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf
>>>>
>>>>=20
)
>>>>=20
>>>>=20
>>>>=20
>>>> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie >>> > wrote:
>>>>=20
>>>> Magnus and I discussed this this morning, and we encourage you to=20
>>>> prepare something.  If the discussion of working group last call=20
>>>> items runs short, we may be able to fit this in at that time or at=20
>>>> the end of day one if its full agenda his finished.  This is not a=20
>>>> commitment, however, so please try and get discussion on the list=20
>>>> on the points from the draft you feel need resolution.
>>>>=20
>>>> regards,
>>>>=20
>>>> Ted
>>>>=20
>>>>=20
>>>> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)=20
>>>> > wrote:
>>>>> Hello,
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> I would like to request agenda time for:
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> The document  presents use-cases underlining why WebRTC needs
>>>> AMR-WB,  AMR
>>>>> and G.722 as additional relevant voice codecs to satisfactorily=20
>>>>> ensure interoperability with existing systems.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> A 10-minute time slot should be sufficient for presentation and
>>>> discussion.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> Regards
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> -Espen
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________ rtcweb
> mailing list
>>>>> rtcweb@ietf.org =20
>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>>=20
>>>> _______________________________________________ rtcweb
> mailing list
>>>> rtcweb@ietf.org =20
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________ rtcweb
> mailing list
>>>> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
>>>>=20
>=20
>> _______________________________________________ rtcweb mailing list=20
>> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
>>=20
>> ___________________________________________________________
>> ___________________________________________________________ ___
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations=20
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
>> exploites ou copies sans autorisation. Si vous avez recu ce message=20
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20
>> que les pieces jointes. Les messages electroniques etant susceptibles=20
>> d'alteration, France Telecom - Orange decline toute responsabilite si=20
>> ce message a ete altere, deforme ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or=20
>> privileged information that may be protected by law; they should not=20
>> be distributed, used or copied without authorisation. If you have=20
>> received this email in error, please notify the sender and delete=20
>> this message and its attachments. As emails may be altered, France=20
>> Telecom - Orange is not liable for messages that have been modified,=20
>> changed or falsified. Thank you.
>>=20
>> _______________________________________________ rtcweb mailing list=20
>> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
>=20
> ______________________________________________________________________
> ___________________________________________________
>
>  Ce message et ses pieces jointes peuvent contenir des informations=20
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
> exploites ou copies sans autorisation. Si vous avez recu ce message=20
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20
> que les pieces jointes. Les messages electroniques etant susceptibles=20
> d'alteration, France Telecom - Orange decline toute responsabilite si=20
> ce message a ete altere, deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or=20
> privileged information that may be protected by law; they should not=20
> be distributed, used or copied without authorisation. If you have=20
> received this email in error, please notify the sender and delete this=20
> message and its attachments. As emails may be altered, France Telecom
> - Orange is not liable for messages that have been modified, changed=20
> or falsified. Thank you.
>=20
> _______________________________________________ rtcweb mailing list=20
> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
>=20
> ---------------------------------------------------------------------
>
>=20
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.
>=20
> ______________________________________________________________________
> ___________________________________________________
>
>  Ce message et ses pieces jointes peuvent contenir des informations=20
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
> exploites ou copies sans autorisation. Si vous avez recu ce message=20
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20
> que les pieces jointes. Les messages electroniques etant susceptibles=20
> d'alteration, France Telecom - Orange decline toute responsabilite si=20
> ce message a ete altere, deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or=20
> privileged information that may be protected by law; they should not=20
> be distributed, used or copied without authorisation. If you have=20
> received this email in error, please notify the sender and delete this=20
> message and its attachments. As emails may be altered, France Telecom
> - Orange is not liable for messages that have been modified, changed=20
> or falsified. Thank you.
>=20

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRQVgzAAoJEJ6/8sItn9q9fgYH/jcWfhRrvPM1hJ22YcE7eR0N
OZzP/RvSrUBiIA6kG+6+Hvn5Lp/tXd+LxUDp5L8B3Toce7TBBAYNJP3M2cr8N8It
SjVvPHtBNKEqhBLbI4FbAouvymNH4utjAWR+MmF9LRySPXZ9nxLN0A13TeUlpZxt
Jaxr/n9AWwkKOk6BIo1Xztbk26MObiGVLhCE+CPoHaHe29bKblPcphBXC935ymHS
SuF2DXiAq0iKwZoVOsLe3RIaGg+bjN7N2MXi3Vphr7cOQK+JpdxURDrvmPh7/L8R
ht1RJt928yl4fEjnKhSKJLd1J+gPBe6vnkSxUp89as03bLirLwN1G2giD3YzfLM=3D
=3DK56v
-----END PGP SIGNATURE-----

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.

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

From adam@nostrum.com  Thu Mar 14 06:52: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 D075A11E80FE for ; Thu, 14 Mar 2013 06:52:49 -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 P0prJsMXtteB for ; Thu, 14 Mar 2013 06:52:40 -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 DEBE721F8CDD for ; Thu, 14 Mar 2013 06:52:39 -0700 (PDT)
Received: from dhcp-5033.meeting.ietf.org (dhcp-5033.meeting.ietf.org [130.129.80.51]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2EDqcMb094093 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 14 Mar 2013 08:52:39 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <5141D626.8060703@nostrum.com>
Date: Thu, 14 Mar 2013 09:52:38 -0400
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Cullen Jennings 
References: <402DA32C-FC49-4D71-9BE1-C955C4564A37@iii.ca>
In-Reply-To: <402DA32C-FC49-4D71-9BE1-C955C4564A37@iii.ca>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: pass (shaman.nostrum.com: 130.129.80.51 is authenticated by a trusted mechanism)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Some videos to download for today presentation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 13:52:50 -0000

Since Cullen is posting videos to show off the difference between 
hardware encoding and software encoding, I think there's possibly also 
value in showing the difference between VP8 and H.264 encoding. Here's a 
set of video pairs that demonstrate that difference:

http://www.quavlive.com/video_codec_comparison

/a

On 3/14/13 08:06, Cullen Jennings wrote:
> Download these two videos and see how you think they compare. Don’t watch them on the dropbox site as it does funky things in it’s playback. I'm going to be discussion them in my talk today and will try and show them on the screen but it will be easier to compare them if you just download them and play them on your own computer.
>
> Video A: https://dl.dropbox.com/u/17089001/VidComp/a.mov
>
> Video B: https://dl.dropbox.com/u/17089001/VidComp/b.mov
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From adam@nostrum.com  Thu Mar 14 07: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 32B1F11E8171 for ; Thu, 14 Mar 2013 07:11:27 -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 e+yF-X51Es9h for ; Thu, 14 Mar 2013 07:11:22 -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 52A8211E8178 for ; Thu, 14 Mar 2013 07:11:13 -0700 (PDT)
Received: from dhcp-5033.meeting.ietf.org (dhcp-5033.meeting.ietf.org [130.129.80.51]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2EEBCdh096246 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 14 Mar 2013 09:11:12 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <5141DA7F.8060207@nostrum.com>
Date: Thu, 14 Mar 2013 10:11:11 -0400
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Cullen Jennings 
References: <402DA32C-FC49-4D71-9BE1-C955C4564A37@iii.ca> <5141D626.8060703@nostrum.com>
In-Reply-To: <5141D626.8060703@nostrum.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: pass (shaman.nostrum.com: 130.129.80.51 is authenticated by a trusted mechanism)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Some videos to download for today presentation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 14:11:27 -0000

It's been pointed out that some media players may not be able to handle 
.mkv files, such as those present on the comparison page. If your media 
player of choice doesn't render these, I recommend VLC as a 
cross-platform player that plays just about everything:

http://www.videolan.org/vlc/index.html

/a

On 3/14/13 09:52, Adam Roach wrote:
> Since Cullen is posting videos to show off the difference between 
> hardware encoding and software encoding, I think there's possibly also 
> value in showing the difference between VP8 and H.264 encoding. Here's 
> a set of video pairs that demonstrate that difference:
>
> http://www.quavlive.com/video_codec_comparison
>
> /a
>
> On 3/14/13 08:06, Cullen Jennings wrote:
>> Download these two videos and see how you think they compare. Don’t 
>> watch them on the dropbox site as it does funky things in it’s 
>> playback. I'm going to be discussion them in my talk today and will 
>> try and show them on the screen but it will be easier to compare them 
>> if you just download them and play them on your own computer.
>>
>> Video A: https://dl.dropbox.com/u/17089001/VidComp/a.mov
>>
>> Video B: https://dl.dropbox.com/u/17089001/VidComp/b.mov
>>
>> _______________________________________________
>> 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 jkoleszar@google.com  Thu Mar 14 07:12: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 1E2A721F8D57 for ; Thu, 14 Mar 2013 07:12:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.977
X-Spam-Level: 
X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 beYbKouNkiLf for ; Thu, 14 Mar 2013 07:12:51 -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 EFAEC21F87F9 for ; Thu, 14 Mar 2013 07:12:50 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hq4so1834602wib.11 for ; Thu, 14 Mar 2013 07:12:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8si5WD3NcdEujCR5BGCkMcWG61pGMSNbFKgO8JaLC90=; b=YTa4rv6akH8nE37hV4ZFKGC+2QfBUKNBzgtT2SK17T2REHTG6zEfjpMDwdcr/2hxeo SwK0KNZpvUPupLaMg3pePtmQ14G65NyYnnozY9xb5l1MJtUT0IuvItwzqp6Hk+kUZXEo gAX0FuhVEYJReu0idfeE7Mx/utR+p8DHt3Vy3p9U6+X8p5mI+LFkj77W9UecyHeWcBfk x/VJ3eK4u/IgRE5Q+YY7+CzbWRfHo8zjsJ6JqiZHzLVkDMaJgT2Yt3jVLjC17zVhnF61 e6VjIHpkwnp5ox0ob1Ju+Y7mlqh/zeP6+9DGg98wNnR1XBqox0nZqt+klDB2NF91UzJt DPRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=8si5WD3NcdEujCR5BGCkMcWG61pGMSNbFKgO8JaLC90=; b=Aw0nfln1Eh7zA/la37m/jvzZ0ScUI2ln9q1beQAUBzU4uEITFq/TVnivhnFlq2fCmm usUUiJzuhYJ6tGakqoXF6leF3wKqvhDJtFVDq9JVewEqI/AUSopiNUkknIt/KYbAFgWJ SSB8U0hC91nna5FifUBbYo6C8a0q7tf9r2MFIqz4sjBSkSt7NYKbQNkzueNosuFQKEzh 77ZSs66YOixXLtnihk02T7u7QdEQ5Ah0WYPMC1eQEvmsCmUwkXjEcHMvOISCBkPx3OJa ea6vfpc1oWOTbiLI1cnXjJPtBbWQHglNtiHg431gSEcHMOuTNEa7gq/W9wvHbnd1INj+ CFBQ==
MIME-Version: 1.0
X-Received: by 10.194.122.131 with SMTP id ls3mr4352580wjb.55.1363270370053; Thu, 14 Mar 2013 07:12:50 -0700 (PDT)
Received: by 10.194.28.201 with HTTP; Thu, 14 Mar 2013 07:12:49 -0700 (PDT)
In-Reply-To: <402DA32C-FC49-4D71-9BE1-C955C4564A37@iii.ca>
References: <402DA32C-FC49-4D71-9BE1-C955C4564A37@iii.ca>
Date: Thu, 14 Mar 2013 07:12:49 -0700
Message-ID: 
From: John Koleszar 
To: Cullen Jennings 
Content-Type: multipart/alternative; boundary=089e0122903223ed1404d7e31eed
X-Gm-Message-State: ALoCoQl+iuWSYlFCcR3Jn9sa3QPxZ4yo2xFjdFw8R/zdrO1fvJ0leUtA6UjJtw9kMcNHms8zv9S3ASNtURR5XMRmhvyWDr09KZzq+1jnMJOqzciNO6ydqAHA9scR44G4KCXPrf4z+6Yj+wFSMU7DKJ4lA6Zjj3E22HW+WTIUtzXoW7x6+iK/S34QxzVVWKcpu/ej7n3Ue3wS
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Some videos to download for today presentation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 14:12:56 -0000

--089e0122903223ed1404d7e31eed
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

The artifacts in video A are primarily caused by scaling, they're not
artifacts of VP8. Swapping in h264 and keeping all the other pieces the
same would look similar. This is going to affect everything from perceived
quality to achieved bitrate. I'm not sure you can draw any conclusion from
this test, and I don't think it lives up to its goal of "showing good VP8
implementation in best of conditions."




On Thu, Mar 14, 2013 at 5:06 AM, Cullen Jennings  wrote:

>
> Download these two videos and see how you think they compare. Don=92t wat=
ch
> them on the dropbox site as it does funky things in it=92s playback. I'm
> going to be discussion them in my talk today and will try and show them o=
n
> the screen but it will be easier to compare them if you just download the=
m
> and play them on your own computer.
>
> Video A: https://dl.dropbox.com/u/17089001/VidComp/a.mov
>
> Video B: https://dl.dropbox.com/u/17089001/VidComp/b.mov
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--089e0122903223ed1404d7e31eed
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


The artifacts in video A are primarily caused by scaling, =
they're not artifacts of VP8. Swapping in h264 and keeping all the othe=
r pieces the same would look similar. This is going to affect everything fr=
om perceived quality to achieved bitrate. I'm not sure you can draw any=
 conclusion from this test, and I don't think it lives up to its goal o=
f "showing good VP8 implementation in best of conditions."





On Thu, Mar 14, 2013 at 5:06 AM, Cullen Jennings <fluffy@iii=
.ca> wrote:




Download these two videos and see how you think they compare. Don=92t watch=
 them on the dropbox site as it does funky things in it=92s playback. I'=
;m going to be discussion them in my talk today and will try and show them =
on the screen but it will be easier to compare them if you just download th=
em and play them on your own computer.




Video A: https://dl.dropbox.com/u/17089001/VidComp/a.mov



Video B: https://dl.dropbox.com/u/17089001/VidComp/b.mov



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--089e0122903223ed1404d7e31eed--

From jkoleszar@google.com  Thu Mar 14 07:14: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 609C721F8FEB for ; Thu, 14 Mar 2013 07:14:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.144
X-Spam-Level: 
X-Spam-Status: No, score=-101.144 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, 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 fhyheA9zyO-M for ; Thu, 14 Mar 2013 07:14:18 -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 A4C9E1F0D14 for ; Thu, 14 Mar 2013 07:14:13 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hq4so1833601wib.17 for ; Thu, 14 Mar 2013 07:14:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=25MN0UQkVQPVxa58Z09FX9uVAGM89r4aAsDWuTow+Kc=; b=OxLULve+nGVq01CYCzeH0i6X2SAKhL1KFpFWDd3/WqY99zh9jayq2ncZrU3dLZx/ra bovv8G0tN4nw/iqk3oZd2JS3eP7DTLaER+H2OuVU2w25mJOUuAmsCwLeTmPEkqB2QhWn StPn2N9naVIfUZOP6xcLEXnFHyk8zvZmBmdnt3UFwAhm3H23SlsVX0PXPZT5UJyoXntS CRptaiIbYyzwt4qU6PKFfas82K3FPTJhQlP1nQFVv6pDiIZzSjVzXJwkoNRPqU0OO8Z8 Xt3+edAWpuWCJLpiY4ohYs0Be48jWrgsbKS5QWPIm9EK89PsbZrauFBFk6MjOm85APVN R78w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=25MN0UQkVQPVxa58Z09FX9uVAGM89r4aAsDWuTow+Kc=; b=DMwZAMvpuA4JZAPBbpLVtAeF2WhcAS0sm8+GF+a49mokEeqGC9773RO5vr1LL91NGo BtSd3e+pNlmOBD2TlOHSr515WptwBB4ppZIIrgYmohMsvZibNh1m1cfnQb044pnTKsaF RFualN1OQBnjLoryCdgDB/wSlsKamfHC2Km73IJKrOxuSyhWL4J0FvZv8f+Fv37prRE7 CypfHEM/2h68y1i4SrqsdzRPTvb/cM6O028Xd2wIt4Bw9sa3zf1FCnqbARaBvr9fZ/Yv Z7nGEr5F6HfBO9XbabOZdNuhuCfv56jdZTSgwHzbUWEJpJZ6GGRwZFkZGZeZUNIreCti dPcg==
MIME-Version: 1.0
X-Received: by 10.194.87.229 with SMTP id bb5mr4405606wjb.32.1363270452427; Thu, 14 Mar 2013 07:14:12 -0700 (PDT)
Received: by 10.194.28.201 with HTTP; Thu, 14 Mar 2013 07:14:12 -0700 (PDT)
In-Reply-To: <5141D626.8060703@nostrum.com>
References: <402DA32C-FC49-4D71-9BE1-C955C4564A37@iii.ca> <5141D626.8060703@nostrum.com>
Date: Thu, 14 Mar 2013 07:14:12 -0700
Message-ID: 
From: John Koleszar 
To: Adam Roach 
Content-Type: multipart/alternative; boundary=089e0102ffea0cd87a04d7e32385
X-Gm-Message-State: ALoCoQmse70GvCg30OKP0/7OpuhSkQfZi/8jQiijjgHQM3dYstapEO3KqWpoBXxdSQ0SZOsmG+Am4Lo3vvcPCtIm38Lsrmc0Z+bILW7Ztyfcxv0nvxSBw1seFP5a1S6LNcqU6NzqhWy16yjwgJFMd8ZZhgYmy4hlZ/yNw30uYySLBTUmRu55gzPgrS49O3E9FkHlNijZ8K5F
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Some videos to download for today presentation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 14:14:23 -0000

--089e0102ffea0cd87a04d7e32385
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I think the presentations prepared for today are likely to be more relevant
than this one from nearly 3 years ago.


On Thu, Mar 14, 2013 at 6:52 AM, Adam Roach  wrote:

> Since Cullen is posting videos to show off the difference between hardwar=
e
> encoding and software encoding, I think there's possibly also value in
> showing the difference between VP8 and H.264 encoding. Here's a set of
> video pairs that demonstrate that difference:
>
> http://www.quavlive.com/video_**codec_comparison
>
> /a
>
>
> On 3/14/13 08:06, Cullen Jennings wrote:
>
>> Download these two videos and see how you think they compare. Don=92t wa=
tch
>> them on the dropbox site as it does funky things in it=92s playback. I'm
>> going to be discussion them in my talk today and will try and show them =
on
>> the screen but it will be easier to compare them if you just download th=
em
>> and play them on your own computer.
>>
>> Video A: https://dl.dropbox.com/u/**17089001/VidComp/a.mov
>>
>> Video B: https://dl.dropbox.com/u/**17089001/VidComp/b.mov
>>
>> ______________________________**_________________
>> 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
>

--089e0102ffea0cd87a04d7e32385
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


I think the presentations prepared for today are likely to=
 be more relevant than this one from nearly 3 years ago.


On Thu, Mar 14, 2013 at 6:=
52 AM, Adam Roach <adam@nostrum.com> wrote:


Since Cullen is posting videos to show off t=
he difference between hardware encoding and software encoding, I think ther=
e's possibly also value in showing the difference between VP8 and H.264=
 encoding. Here's a set of video pairs that demonstrate that difference=
:




http://www.quavlive.com/video_codec_comparison



/a




On 3/14/13 08:06, Cullen Jennings wrote:



Download these two videos and see how you think they compare. Don=92t watch=
 them on the dropbox site as it does funky things in it=92s playback. I'=
;m going to be discussion them in my talk today and will try and show them =
on the screen but it will be easier to compare them if you just download th=
em and play them on your own computer.




Video A: https://dl.dropbox.com/u/17089001/VidComp/a.mov



Video B: https://dl.dropbox.com/u/17089001/VidComp/b.mov



_______________________________________________

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





--089e0102ffea0cd87a04d7e32385--

From adam@nostrum.com  Thu Mar 14 07:17: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 BED0311E819A for ; Thu, 14 Mar 2013 07:17:00 -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 E0DEfPJCtqJc for ; Thu, 14 Mar 2013 07:17: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 17D4711E8188 for ; Thu, 14 Mar 2013 07:16:45 -0700 (PDT)
Received: from dhcp-5033.meeting.ietf.org (dhcp-5033.meeting.ietf.org [130.129.80.51]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2EEGZno096857 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 14 Mar 2013 09:16:36 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <5141DBC3.2050807@nostrum.com>
Date: Thu, 14 Mar 2013 10:16:35 -0400
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: John Koleszar 
References: <402DA32C-FC49-4D71-9BE1-C955C4564A37@iii.ca> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 130.129.80.51 is authenticated by a trusted mechanism)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Some videos to download for today presentation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 14:17:00 -0000

On 3/14/13 10:12, John Koleszar wrote:
> The artifacts in video A are primarily caused by scaling, they're not 
> artifacts of VP8. Swapping in h264 and keeping all the other pieces 
> the same would look similar. This is going to affect everything from 
> perceived quality to achieved bitrate. I'm not sure you can draw any 
> conclusion from this test, and I don't think it lives up to its goal 
> of "showing good VP8 implementation in best of conditions."

Right. If we attempt to draw conclusions from these videos, they would 
include wild fallacies such as "VP8 cannot encode video with a correct 
aspect ratio."

/a

From adam@nostrum.com  Thu Mar 14 07:31: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 2F01C11E817D for ; Thu, 14 Mar 2013 07:31:43 -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 Ai2aJgveOAQ4 for ; Thu, 14 Mar 2013 07:31:42 -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 7897611E8184 for ; Thu, 14 Mar 2013 07:31:30 -0700 (PDT)
Received: from dhcp-5033.meeting.ietf.org (dhcp-5033.meeting.ietf.org [130.129.80.51]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2EEV3BH098585 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 14 Mar 2013 09:31:04 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <5141DF27.2070204@nostrum.com>
Date: Thu, 14 Mar 2013 10:31:03 -0400
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: John Koleszar 
References: <402DA32C-FC49-4D71-9BE1-C955C4564A37@iii.ca> <5141D626.8060703@nostrum.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 130.129.80.51 is authenticated by a trusted mechanism)
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Some videos to download for today presentation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 14:31:43 -0000

On 3/14/13 10:14, John Koleszar wrote:
> I think the presentations prepared for today are likely to be more 
> relevant than this one from nearly 3 years ago.

Interesting. What's changed?

/a

From rhglidden@gmail.com  Thu Mar 14 08:47: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 BD93911E8230 for ; Thu, 14 Mar 2013 08:47:54 -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 xDFHKx-0PWYZ for ; Thu, 14 Mar 2013 08:47:50 -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 AD7B311E821F for ; Thu, 14 Mar 2013 08:47:50 -0700 (PDT)
Received: by mail-qa0-f52.google.com with SMTP id bs12so1304611qab.18 for ; Thu, 14 Mar 2013 08:47:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type; bh=KNgvPG36r/Q4X3RYcpZx+kZQ+daGAfDQVKEvdTQlnJQ=; b=fwElQseGFSFbd6RVhcqavejdBVZvEXEA0vy2TMYiYDMZUXix3ErQ/ravb5mnpO+3mG 2RVQhrzxtsOG48kDv6qiiMVWy0Lu8Iabyp4K8NoL/wqNTZ0fqtOQ3HKa5HxJObVsGzPy tEYSLO6V41P1J9/YWLIxDVCnoPvm1lJQTcP5zpa2uRzShAVB/6Ls7dQm+koypM26eiNN PLCtkp1avsdrpl7w+WxKBppxshsFN8uM0an/wLxPNt1/fQdAItyIippHk0fs5aD9Nm+T gMoyuGQZnY+HzR5bkI0il+3/aWDrOHMSBPgn6ya7NR4iBt7bFfmcItWoCKQy0jfqBNFI XUFA==
X-Received: by 10.224.207.72 with SMTP id fx8mr3461466qab.66.1363276070151; Thu, 14 Mar 2013 08:47:50 -0700 (PDT)
Received: from [10.0.0.10] (99-25-33-39.lightspeed.sntcca.sbcglobal.net. [99.25.33.39]) by mx.google.com with ESMTPS id q6sm3949348qeu.1.2013.03.14.08.47.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 08:47:49 -0700 (PDT)
Message-ID: <5141F120.3020400@gmail.com>
Date: Thu, 14 Mar 2013 08:47:44 -0700
From: Rob Glidden 
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: "Wang, Ye-Kui" ,  "rtcweb@ietf.org" 
References: <513F68C0.4010106@ericsson.com>  <513F7745.3020302@alvestrand.no>    <8BA7D4CEACFFE04BA2D902BF11719A8331B17F22@nasanexd02f.na.qualcomm.com>, <1363220674.82166.YahooMailNeo@web132106.mail.ird.yahoo.com> <2981F523-72AC-4330-8D1F-7DC4E2168C5A@qti.qualcomm.com>
In-Reply-To: <2981F523-72AC-4330-8D1F-7DC4E2168C5A@qti.qualcomm.com>
Content-Type: multipart/alternative; boundary="------------070907060301060800010909"
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 15:47:54 -0000

This is a multi-part message in MIME format.
--------------070907060301060800010909
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Sure it is, there's an open MPEG meeting resolution on the MPEG VP8 
proposal to that effect, apparently even National Body comment.

Rob

On 3/13/2013 9:36 PM, Wang, Ye-Kui wrote:
> Sure - but that is clearly not the context here.
>
> Sent from my iPhone
>
> On Mar 13, 2013, at 17:24, "Gerard Fernando"  > wrote:
>
>> Hello YK,
>>
>> The disclosure process in MPEG is not based on who you are, or on 
>> your Business model.
>>
>> Kind regards
>>
>> Gerard
>>
>>
>> ------------------------------------------------------------------------
>> *From:* "Wang, Ye-Kui" > >
>> *To:* Stockhammer Thomas > >; Bo Burman > >
>> *Cc:* "rtcweb@ietf.org " > >
>> *Sent:* Wednesday, 13 March 2013, 10:40
>> *Subject:* Re: [rtcweb] Video Codec discussion in Thursday agenda slot
>>
>> > >  How many others who did not respond to MPEG LA's call but have IPR
>> > > are
>> > there?
>> >
>> > [TS]  Just one more hypothesis: If I would have, what would be my
>> > obligation/motivation to do so now?
>>
>> Speaking of the motivation part; that would depend on who YOU are and 
>> what kind of business model or plan YOU have in mind.
>>
>> BR, YK
>>
>> > -----Original Message-----
>> > From: rtcweb-bounces@ietf.org  
>> [mailto:rtcweb-bounces@ietf.org ] On 
>> Behalf
>> > Of Stockhammer Thomas
>> > Sent: Wednesday, March 13, 2013 7:53 AM
>> > To: Bo Burman
>> > Cc: rtcweb@ietf.org 
>> > Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
>> >
>> >
>> > >  How many others who did not respond to MPEG LA's call but have 
>> IPR are
>> > there?
>> >
>> > [TS]  Just one more hypothesis: If I would have, what would be my
>> > obligation/motivation to do so now?
>> >
>> > >>>
>> > >>> We appreciate the need to have time to evaluate the specific words
>> > >>> of the license statements that are forthcoming, and the need 
>> for the
>> > >>> people who haven't made their IPR declarations over the last couple
>> > >>> of years of discussion to do so within the next couple of weeks -
>> > >>> but we do think that it is important to use the face to face time
>> > >>> that we have here in Orlando to lay to rest any *other* issues than
>> > >>> the licensing terms and other issues derived from Google's
>> > announcement.
>> > >>
>> > >> I am not sure we can have a reasoned consideration of 'other issues
>> > derived'
>> > >> at such short notice.
>> > >>
>> > >> Look, I'd like our discussions and decisions to be informed and
>> > >> considered, and there simply isn't time for either.
>> > >>
>> > >>>
>> > >>> Harald
>> > >>>
>> > >>> _______________________________________________
>> > >>> rtcweb mailing list
>> > >>> rtcweb@ietf.org 
>> > >>> https://www.ietf.org/mailman/listinfo/rtcweb
>> > >>
>> > >> David Singer
>> > >> Multimedia and Software Standards, Apple Inc.
>> > >>
>> > >> _______________________________________________
>> > >> rtcweb mailing list
>> > >> rtcweb@ietf.org 
>> > >> https://www.ietf.org/mailman/listinfo/rtcweb
>> > >
>> >
>> > ---
>> > Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de 
>>  || phone +49
>> > 89 978980 02 || cell +491725702667 || http://www.nomor-research.com 
>> 
>> > Nomor Research GmbH  -  Sitz der Gesellschaft: München - 
>> Registergericht:
>> > München, HRB 165856 - Umsatzsteuer-ID: DE238047637 - Geschäftsführer:
>> > Dr. Thomas Stockhammer, Dr. Ingo Viering.
>> >
>> >
>> >
>> > _______________________________________________
>> > 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


--------------070907060301060800010909
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Sure it is, there's an open MPEG
      meeting resolution on the MPEG VP8 proposal to that effect,
      apparently even National Body comment.

      

      Rob

      

      On 3/13/2013 9:36 PM, Wang, Ye-Kui wrote:

    

    

      
      
Sure - but that is clearly not the context here.

        

        Sent from my iPhone

      


        On Mar 13, 2013, at 17:24, "Gerard Fernando" <gerardmxf@yahoo.co.uk>
        wrote:

        

      

      

        

          

            
Hello YK,

            

              

              

            The disclosure process in MPEG is not based on who you are,
            or on your Business model.

            

            Kind regards

            

            Gerard

            

            

            

              

                

                    

                    From:
                    "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>

                    To:
                    Stockhammer Thomas <stockhammer@nomor.de>;
                    Bo Burman <bo.burman@ericsson.com>
                    

                    Cc: "rtcweb@ietf.org"
                    <rtcweb@ietf.org>
                    

                    Sent:
                    Wednesday, 13 March 2013, 10:40

                    Subject:
                    Re: [rtcweb] Video Codec discussion in Thursday
                    agenda slot

                  

                

                > >  How many others who did not respond to MPEG
                LA's call but have IPR 

                > > are

                > there?

                > 

                > [TS]  Just one more hypothesis: If I would have,
                what would be my 

                > obligation/motivation to do so now?

                

                Speaking of the motivation part; that would depend on
                who YOU are and what kind of business model or plan YOU
                have in mind.
                

                

                BR, YK

                

                > -----Original Message-----

                > From: 
                  rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org]
                On Behalf

                > Of Stockhammer Thomas

                > Sent: Wednesday, March 13, 2013 7:53 AM

                > To: Bo Burman

                > Cc: rtcweb@ietf.org

                > Subject: Re: [rtcweb] Video Codec discussion in
                Thursday agenda slot

                > 

                > 

                > >  How many others who did not respond to MPEG
                LA's call but have IPR are

                > there?

                > 

                > [TS]  Just one more hypothesis: If I would have,
                what would be my

                > obligation/motivation to do so now?

                > 

                > >>>

                > >>> We appreciate the need to have time to
                evaluate the specific words

                > >>> of the license statements that are
                forthcoming, and the need for the

                > >>> people who haven't made their IPR
                declarations over the last couple

                > >>> of years of discussion to do so within
                the next couple of weeks -

                > >>> but we do think that it is important
                to use the face to face time

                > >>> that we have here in Orlando to lay to
                rest any *other* issues than

                > >>> the licensing terms and other issues
                derived from Google's

                > announcement.

                > >>

                > >> I am not sure we can have a reasoned
                consideration of 'other issues

                > derived'

                > >> at such short notice.

                > >>

                > >> Look, I'd like our discussions and
                decisions to be informed and

                > >> considered, and there simply isn't time
                for either.

                > >>

                > >>>

                > >>> Harald

                > >>>

                > >>>
                _______________________________________________

                > >>> rtcweb mailing list

                > >>> rtcweb@ietf.org

                > >>> https://www.ietf.org/mailman/listinfo/rtcweb

                > >>

                > >> David Singer

                > >> Multimedia and Software Standards, Apple
                Inc.

                > >>

                > >>
                _______________________________________________

                > >> rtcweb mailing list

                > >> rtcweb@ietf.org

                > >> https://www.ietf.org/mailman/listinfo/rtcweb

                > >

                > 

                > ---

                > Dr. Thomas Stockhammer (CEO) || 
                  stockhammer@nomor.de || phone +49

                > 89 978980 02 || cell +491725702667 || 
                  http://www.nomor-research.com

                > Nomor Research GmbH  -  Sitz der Gesellschaft:
                München - Registergericht:

                > München, HRB 165856 - Umsatzsteuer-ID: DE238047637
                - Geschäftsführer:

                > Dr. Thomas Stockhammer, Dr. Ingo Viering.

                > 

                > 

                > 

                > _______________________________________________

                > 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


    

    

  


--------------070907060301060800010909--

From ben@vline.me  Thu Mar 14 09:24: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 B3A7A11E80B8 for ; Thu, 14 Mar 2013 09:24:43 -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 6IOgWLajcutU for ; Thu, 14 Mar 2013 09:24:39 -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 4C84F21F8F2F for ; Thu, 14 Mar 2013 09:24:38 -0700 (PDT)
Received: by mail-wi0-f172.google.com with SMTP id ez12so3969352wid.17 for ; Thu, 14 Mar 2013 09:24:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=wbJgRpCVEoXQ+tFkDoBkl3BZF2kYTOlfyUmXg9xYceY=; b=hErJMcnxOOGDcUx5vTMvOLbobeA3bkF0/cf0c4N0jw5BOv/PBzKQM5s8qazSvhj1Ke FkkMnU5gIUVfGANbguEWS6x6s8X8oLlBHJT+wS8inIMpRj0mjfLfX3sBrdn8gMUap/dn UABpuF0KBg/aPKLwEG9FNeHrZB6p6tisQDNoMvANTaZ/lkmxxOpxk55n7MNQ1qakjUab 78ft3p4I6kNzwFpVNc66Gv3h+REWAi0+axN3zDA1HpOe33no7euxdiW0YBvKwtvzrOuV KHsb+uOTIdRKyjg+TU3rQh//S8/irTp38KhULy+ELNQOmGXgLjtT7+Z7FLX5xVl/+jeP 3y5g==
MIME-Version: 1.0
X-Received: by 10.180.189.169 with SMTP id gj9mr5324834wic.5.1363278277127; Thu, 14 Mar 2013 09:24:37 -0700 (PDT)
Sender: ben@vline.me
Received: by 10.227.8.226 with HTTP; Thu, 14 Mar 2013 09:24:36 -0700 (PDT)
In-Reply-To: 
References: 
Date: Thu, 14 Mar 2013 11:24:36 -0500
X-Google-Sender-Auth: 9zzXjlhCo3tpLOyN1MumTuL9AuU
Message-ID: 
From: Ben Strong 
To: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c34a627044b504d7e4f526
X-Gm-Message-State: ALoCoQnnMrpTMLZCBhNLCTU+BQhRo86Te7o+/sbHPiEICr0bxly8J+wZpAsZsPV7p9WxjvhMlHlV
Subject: Re: [rtcweb] A different perspective on the video codec MTI 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: Thu, 14 Mar 2013 16:26:08 -0000

--001a11c34a627044b504d7e4f526
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I've been talking to developers who are interested in building WebRTC apps
regularly for the past year and have drawn the opposite conclusion about
their preferences.

Before going into what they want and why, let me give you a flavor of who
I'm talking to: These are primarily inbound contacts who are interested in
the vLine WebRTC platform. I think they're pretty representative of the
non-legacy use-cases for WebRTC, but almost certainly under-represent the
existing enterprise market.

* Over half are building apps for healthcare or education. I'd say it's a
pretty even split between those categories, and within each category it's a
pretty even split between startups and more established organizations.
Non-profits make up a substantial fraction of both groups.

* Over half are outside the US, with most of the international interest
coming from developing countries (e.g., India, Brazil, and China).

* Not one of them has been interested in enabling video for customer
service calls (though a number have been interested in voice). I mention
this because it's frequently cited as an important use-case and I expected
it to be an important market for us, but I'm beginning to wonder if
businesses actually want this. I'll admit that those who _are_ interested
are more likely to be talking to Jonathan than to me, so take this with a
grain of salt.

* A sampling of other apps people are building: translation services (both
for foreign languages and sign language), social commerce services, and
social apps with all sorts of interesting new interaction models.

Here's what I've heard from them:

* The only questions I have ever gotten about interop with legacy equipment
are in regard to voice. I do occasionally talk to people with existing
investments in video conferencing systems, but they are mostly interested
in moving away from them (huge sample bias here, of course).

* Very rarely does the subject of codecs come up other than the context of
whether the browsers will all interoperate. The only concerns I ever hear
about VP8 quality are from people who haven't actually used WebRTC in
Chrome. The feedback I get from people who have used it is consistently
that they are surprised by how good the video quality is.

* All of them care about having a good mobile experience and
do occasionally express concerns about the battery life and performance
impact of software codecs.

* _Everyone_ is concerned about cross-browser interoperability. It is far
and away the biggest concern I hear about WebRTC, and I can't remember the
last time it didn't come up in a conversation with a customer.

Finally, here's my take on it all:

>From a power and performance point of view, H.264 is undoubtedly a better
option on devices with a hardware codec for it. Implementations on those
devices should by all means support it and attempt to negotiate it.
Implementations on other platforms where it is feasible to support it,
either because the implementation vendor has a license or the OS includes
it, should by all means support it as well, for the sake of allowing mobile
devices with a hardware codec to use it whenever possible.

I'm happy to grant that H.264 is technically superior to VP8 in every way
(though I think the differences are negligible in real-world use). By all
means implementations that wish to should attempt to negotiate it for that
reason, as well.

However, I fail to see how either one of those points has any bearing on
the MTI decision. The whole point of MTI is guaranteed interoperability
across all WebRTC implementations, which is absolutely critical to WebRTC
adoption. The only criteria should be the best quality codec which can be
supported by all implementations. And because some implementations are open
source, it absolutely must be royalty free.

I've already gone on too long here, but I want to make one final point on
open source. There are two new mobile platforms that have the potential to
drive innovation around mobile apps in general and the mobile web in
particular, and both are open source: FirefoxOS and Ubuntu Mobile. Neither
will be able to be WebRTC compatible unless a royalty-free codec is chosen.

I would argue that FirefoxOS and Ubuntu should be of special concern to the
working group for three reasons: 1) They support web apps as first class
citizens. Since the main goal of WebRTC is to make it possible to build
rich apps entirely with web technologies, I would hope that the innovators
in that arena will be able to support it. 2) I expect that some of the
areas where WebRTC will have the biggest impact (e.g., telemedicine in
rural India) will be most concerned about using a low-cost, open source
platform. 3) Even without every being market-share leaders, open source
platforms tend to drive innovation across the whole market. The best
example of this is how Firefox kickstarted a decade of innovation in
browsers and web apps. I have high hopes that FirefoxOS will do the same.

Adopting a codec that will more firmly entrench legacy providers at the
expense of some of the most innovative new platforms out there seems like a
bad trade-off to me.

Ben

[this post will probably need moderator approval, so apologies if it shows
up after the conversation has moved on]

--
Ben Strong
ben@vline.com



On Wed, Mar 13, 2013 at 5:06 PM, Jonathan Rosenberg wr=
ote:

> I=92d like to put a different perspective on the video MTI discussion.
>
> Much of the discussion has been around video quality, IPR, and
> standardization status. While those are all important factors, to me they
> are secondary to the core question: how does the choice impact uptake of
> the webRTC APIs and protocols by developers who build applications ontop =
of
> it? In this regard, I would like to suggest that, at this time, adoption =
of
> VP8 as MTI will slow down adoption of webRTC by turning off developers th=
at
> would otherwise embrace it if H.264 were selected.
>
> The reason is simple. For many application developers, what is interestin=
g
> about webRTC is NOT just browser to browser communications, but connectin=
g
> users in a browser to users elsewhere - on other devices, in other
> networks. After all, the vast majority of web application developers do n=
ot
> have the luxury of a massive social graph, or the luxury of their users
> being parked persistently on their website and thus able to receive an
> incoming call. Many websites that have customer support or service needs
> would love to be able to allow their users to have a video call with an
> agent. However, those agents are probably sitting on existing agent syste=
ms
> which are not web based, and it=92s almost certainly true that they do no=
t
> today support VP8, but rather H.264. Many developers would probably love =
to
> connect users on the web with users on mobile apps. Most mobile platforms
> today support H264 based hardware acceleration for decode and sometimes
> encode, but not yet VP8. Developers who want to build business
> communications clients will need to connect those users with other users =
in
> the business, who may be using videophones, PC clients, telepresence unit=
s
> or video room systems, the vast majority of which do not support VP8 toda=
y,
> but many of which do support H.264.
>
> The reality is =96 today=92s Internet and IP communications systems are b=
uilt
> on H.264. And unless the developer cares only about living within the
> island of the web browser =96 a VP8 based solution will simply not meet t=
heir
> requirements.
>
> This may not be true down the road. I applaud Google for working hard (an=
d
> spending much money no doubt) to secure an RF license for VP8 from these
> patent holders. I think they should continue pushing and promoting the
> technology because a  free, high quality video codec would be great for t=
he
> Internet. But today, it is not the video codec of the Internet. And, give=
n
> the relatively early days of video, I am sure there will be video codecs
> after VP8. Maybe H.265, maybe the new video codec being developed here at
> the IETF. And once those codecs become more broadly implemented and
> available on the endpoints that matter, we can revise our specs and manda=
te
> support for them. But this is not about the web of five years from now, i=
ts
> about the web today. And if we mandate usage of a codec which is not wide=
ly
> implemented in all the endpoints that matter (not just the browser), I fe=
ar
> that it will hold developers back from using webRTC and thus prevent us
> from ever having the opportunity to add these video codecs in the future.
>
>
>
> And so =96 to the supporters of VP8 =96 I applaud your efforts and thank =
you
> for them. Please continue. And when the industry is ready, we can make VP=
8
> MTI in the browser. But we are not there yet.  I ask you to please put th=
e
> needs of the developers ahead of your own, and do not hold back webRTC fo=
r
> the benefit of your ideals around an RF and open source video codec. WebR=
TC
> is too important for that.
>
> I have one more thing to say - speaking now as a developer.
>
> As some of you may know, I recently returned to Cisco as CTO of the cloud
> collaboration group, which is responsible for Webex. Webex was one of the
> first services to do voice and video on the web, using plugins of course.
> For our business, a key requirement is interoperability with other video
> systems in the Cisco portfolio, including our video clients and
> telepresence units. Those are all based on H.264. Consequently, much as I
> would like to avoid the need for a plugin, the benefits of eliminating th=
e
> plugin do not outweigh the drawbacks of having to transcode from VP8 to
> H.264. If IETF selects VP8 as the MTI codec, this will make it dramatical=
ly
> more difficult and expensive for us to use webRTC. If H.264 is the MIT
> codec, it will make it much easier for us to use webRTC.
>
>
> Thx,
>
> Jonathan R.
> --
> Jonathan Rosenberg, Ph.D.
> jdrosen@jdrosen.net
> http://www.jdrosen.net
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--001a11c34a627044b504d7e4f526
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


Hello YK,<=
/span>

The disclosure process in MPEG=
 is not based on who you are, or on your Business model.

Kind regard=
s

Gerard


 
 
  
  From: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
 <=
b>To: Stockhammer Thomas <=
stockhammer@nomor.de>; Bo Burman <bo.burman@ericsson.com> 
<=
span
 style=3D"font-weight: bold;">Cc: "rtcweb@ietf.org" <rtcweb@i=
etf.org> 
 Sent: Wed=
nesday, 13 March 2013, 10:40
 Subj=
ect: Re: [rtcweb] Video Codec discussion in Thursday agenda slot=

  
 
> >  How many others who did not respond=
 to MPEG LA's call but have IPR 
> > are
> there?
> > [TS]  Just one more hypothesis: If I would have, what would be =
my 
> obligation/motivation to do so now?

Speaking of the moti=
vation part; that would depend on who YOU are and what kind of business mod=
el or plan YOU have in mind. 

BR, YK

> -----Original Messa=
ge-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Be=
half
> Of Stockhammer Thomas
> Sent: Wednesday, March 13, 2013 =
7:53 AM
> To: Bo Burman
> Cc: rtcweb@ietf.org
> Subject: R=
e: [rtcweb] Video Codec discussion in Thursday agenda slot
> 
>=
 
> >  How many others who did not respond to MPEG LA's call =
but have IPR are
> there?
> 
> [TS]  Just one more h=
ypothesis: If I would have, what would be my
> obligation/motivation =
to do so now?
> 
> >>>
> >>> We appreci=
ate the need to have time to evaluate the specific words
> >>&g=
t; of the license statements that are forthcoming, and the need for the
=
> >>> people who haven't made their IPR declarations over the l=
ast couple
> >>> of years of discussion to do so within the
 next couple of weeks -
> >>> but we do think that it is imp=
ortant to use the face to face time
> >>> that we have here =
in Orlando to lay to rest any *other* issues than
> >>> the =
licensing terms and other issues derived from Google's
> announcement=
.
> >>
> >> I am not sure we can have a reasoned co=
nsideration of 'other issues
> derived'
> >> at such shor=
t notice.
> >>
> >> Look, I'd like our discussions =
and decisions to be informed and
> >> considered, and there sim=
ply isn't time for either.
> >>
> >>>
> &g=
t;>> Harald
> >>>
> >>> _______________=
________________________________
> >>> rtcweb mailing list> >>> rtcweb@ietf.org
> >>> ht=
tps://www.ietf.org/mailman/listinfo/rtcweb
> >>
> >=
;> David Singer
> >> Multimedia and Software Standards, Appl=
e Inc.
> >>
> >> __________________________________=
_____________
> >> rtcweb mailing list
> >> rtcweb@ietf.=
org
> >> https://www.ietf.org/mailman/listinfo/rtcweb> >
> 
> ---
> Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49
> 89 978980 02 || cell +4917=
25702667 || ht=
tp://www.nomor-research.com
> Nomor Research GmbH  -  S=
itz der
 Gesellschaft: M=FCnchen - Registergericht:
> M=FCnchen, HRB 165856 -=
 Umsatzsteuer-ID: DE238047637 - Gesch=E4ftsf=FChrer:
> Dr. Thomas Sto=
ckhammer, Dr. Ingo Viering.
> 
> 
> 
> ____________=
___________________________________
> rtcweb mailing list
> rtcweb@i=
etf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
___=
____________________________________________
rtcweb mailing list
rtcweb@ie=
tf.org
https://www.ietf.org/mailman/listinfo/rtcweb


 =

 
  
I've been talking to developers who are interested in =
building WebRTC apps regularly for the past year and have drawn the opposit=
e conclusion about their preferences.

Before going into =
what they want and why, let me give you a flavor of who I'm talking to:=
 These are primarily inbound contacts who are interested in the vLine WebRT=
C platform. I think they're pretty representative of the non-legacy use=
-cases for WebRTC, but almost certainly under-represent the existing enterp=
rise market.



* Over half are building apps for healthcare or educati=
on. I'd say it's a pretty even split between those categories, and =
within each category it's a pretty even split between startups and more=
 established organizations. Non-profits make up a substantial fraction of b=
oth groups.



* Over half are outside the US, with most of the intern=
ational interest coming from developing countries (e.g., India, Brazil, and=
 China).

* Not one of them has been intereste=
d in enabling video for customer service calls (though a number have been i=
nterested in voice). I mention this because it's frequently cited as an=
 important use-case and I expected it to be an important market for us, but=
 I'm beginning to wonder if businesses actually want this. I'll adm=
it that those who _are_ interested are more likely to be talking to Jonatha=
n than to me, so take this with a grain of salt.



* A sampling of other apps people are building: t=
ranslation services (both for foreign languages and sign language), social =
commerce services, and social apps with all sorts of interesting new intera=
ction models.



Here's what I've heard from them:
* The only questions I have ever gotten about interop with lega=
cy equipment are in regard to voice. I do=A0occasionally talk to people wit=
h existing investments in video conferencing systems, but they are mostly i=
nterested in moving away from them (huge sample bias here, of course).


* Very rarely does the subject of codecs come up other =
than the context of whether the browsers will all interoperate. The only co=
ncerns I ever hear about VP8 quality are from people who haven't actual=
ly used WebRTC in Chrome. The feedback I get from people who have used it i=
s consistently that they are surprised by how good the video quality is.


* All of them care about having a good mobile experienc=
e and do=A0occasionally=A0express concerns about the battery life and perfo=
rmance impact of software codecs.

* _Everyone_=
 is concerned about cross-browser interoperability. It is far and away the =
biggest concern I hear about WebRTC, and I can't remember the last time=
 it didn't come up in a conversation with a customer.



Finally, here's my take on it all:

From a power and performance point of view, H.264 is undoubtedly a=
 better option on devices with a hardware codec for it. Implementations on =
those devices should by all means support it and attempt to negotiate it. I=
mplementations on other platforms where it is feasible to support it, eithe=
r because the implementation vendor has a license or the OS includes it, sh=
ould by all means support it as well, for the sake of allowing mobile devic=
es with a hardware codec to use it whenever possible.



I'm happy to grant that H.264 is technically superi=
or to VP8 in every way (though I think the differences are negligible in re=
al-world use). By all means implementations that wish to should attempt to =
negotiate it for that reason, as well.



However, I fail to see how either one of those points h=
as any bearing on the MTI decision. The whole point of MTI is guaranteed in=
teroperability across all WebRTC implementations, which is absolutely criti=
cal to WebRTC adoption. The only criteria should be the best quality codec =
which can be supported by all implementations. And because some implementat=
ions are open source, it absolutely must be royalty free.



I've already gone on too long here, but I want to m=
ake one final point on open source. There are two new mobile platforms that=
 have the potential to drive innovation around mobile apps in general and t=
he mobile web in particular, and both are open source: FirefoxOS and Ubuntu=
 Mobile. Neither will be able to be WebRTC compatible unless a royalty-free=
 codec is chosen.



I would argue that FirefoxOS and Ubuntu should be of sp=
ecial concern to the working group for three reasons: 1) They support web a=
pps as first class citizens. Since the main goal of WebRTC is to make it po=
ssible to build rich apps entirely with web technologies, I would hope that=
 the innovators in that arena will be able to support it. 2) I expect that =
some of the areas where WebRTC will have the biggest impact (e.g., telemedi=
cine in rural India) will be most concerned about using a low-cost, open so=
urce platform. 3) Even without every being market-share leaders, open sourc=
e platforms tend to drive innovation across the whole market. The best exam=
ple of this is how Firefox kickstarted a decade of innovation in browsers a=
nd web apps. I have high hopes that FirefoxOS will do the same.



Adopting a codec that will more firmly entrench legacy =
providers at the expense of some of the most innovative new platforms out t=
here seems like a bad trade-off to me.

Ben



[this post will probably need moderator approval, so ap=
ologies if it shows up after the conversation has moved on]

<=
/div>
--
Ben Strong





On Wed, Mar 13, 2013 at 5:06 PM, Jonathan Rosenberg <jdrosen@jdr=
osen.net> wrote:


I=92d like t=
o put a different
perspective on the video MTI discussion.



Much of the discussion has been
around video quality, IPR, and standardization status. While those are all
important factors, to me they are secondary to the core question: how does =
the
choice impact uptake of the webRTC APIs and protocols by developers who bui=
ld applications ontop of it? In this regard, I would like to suggest that, =
at this
time, adoption of VP8 as MTI will slow down adoption of webRTC by
turning off developers that would otherwise embrace it if H.264 were select=
ed.
The reason is simple. For many
application developers, what is interesting about webRTC is NOT just browse=
r to
browser communications, but connecting users in a browser to users elsewher=
e - on other devices, in other networks.
After all, the vast majority of web application developers do not have the
luxury of a massive social graph, or the luxury of their users being parked
persistently on their website and thus able to receive an incoming call. Ma=
ny websites
that have customer support or service needs would love to be able to allow
their users to have a video call with an agent. However, those agents are
probably sitting on existing agent systems which are not web based, and it=
=92s
almost certainly true that they do not today support VP8, but rather H.264.
Many developers would probably love to connect users on the web with users =
on
mobile apps. Most mobile platforms today support H264 based hardware accele=
ration
for decode and sometimes encode, but not yet VP8. Developers who want to bu=
ild
business communications clients will need to connect those users with other
users in the business, who may be using videophones, PC clients, telepresen=
ce
units or video room systems, the vast majority of which do not support VP8
today, but many of which do support H.264.



The reality is =96 today=92s Internet
and IP communications systems are built on H.264. And unless the developer
cares only about living within the island of the web browser =96 a VP8 base=
d
solution will simply not meet their requirements.



This may not be true down the
road. I applaud Google for working hard (and spending much money no doubt) =
to
secure an RF license for VP8 from these patent holders. I think they should
continue pushing and promoting the technology because a=A0 free, high
quality video codec would be great for the Internet. But today, it is not t=
he
video codec of the Internet. And, given the relatively early days of video,=
 I
am sure there will be video codecs after VP8. Maybe H.265, maybe the new vi=
deo
codec being developed here at the IETF. And once those codecs become more
broadly implemented and available on the endpoints that matter, we can revi=
se
our specs and mandate support for them. But this is not about the web of fi=
ve
years from now, its about the web today. And if we mandate usage of a codec
which is not widely implemented in all the endpoints that matter (not just =
the browser), I fear that it
will hold developers back from using webRTC and thus prevent us from ever h=
aving
the opportunity to add these video codecs in the future.



=A0



And so =96 to the supporters of VP8
=96 I applaud your efforts and thank you for them. Please continue. And whe=
n the
industry is ready, we can make VP8 MTI in the browser. But we are not there=
 yet.
=A0I ask you to please put the needs of the developers ahead of your own,
and do not hold back webRTC for the benefit of your ideals around an RF and
open source video codec. WebRTC is too important for that.



I have one more thing to say - speaking now as a developer.<=
/span>



As some of you may know, I
recently returned to Cisco as CTO of the cloud collaboration group, which i=
s
responsible for Webex. Webex was one of the first services to do voice and
video on the web, using plugins of course. For our business, a key requirem=
ent
is interoperability with other video systems in the Cisco portfolio, includ=
ing
our video clients and telepresence units. Those are all based on H.264.
Consequently, much as I would like to avoid the need for a plugin, the bene=
fits
of eliminating the plugin do not outweigh the drawbacks of having to transc=
ode
from VP8 to H.264. If IETF selects VP8 as the MTI codec, this will make it =
dramatically more difficult and expensive for us to use webRTC. If H.264 is=
 the MIT codec, it will make it much easier for us to use webRTC.=A0=





Thx,
=
Jonathan R.
-- 



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--001a11c34a627044b504d7e4f526--

From singer@apple.com  Thu Mar 14 09:44: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 C494411E80E7 for ; Thu, 14 Mar 2013 09:44:15 -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 uBd78YRrF-K4 for ; Thu, 14 Mar 2013 09:44:15 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3C521F8545 for ; Thu, 14 Mar 2013 09:44:15 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay2.apple.com ([17.128.113.67]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MJN00BOPT5MKRA0@mail-out.apple.com> for rtcweb@ietf.org; Thu, 14 Mar 2013 09:44:14 -0700 (PDT)
X-AuditID: 11807143-b7f896d000006d55-82-5141fe5ea550
Received: from cardamom.apple.com (cardamom.apple.com [17.128.115.94]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay2.apple.com (Apple SCV relay) with SMTP id 07.CF.27989.E5EF1415; Thu, 14 Mar 2013 09:44:14 -0700 (PDT)
Received: from singda.apple.com ([17.197.32.11]) by cardamom.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MJN0062MT5QN250@cardamom.apple.com> for rtcweb@ietf.org; Thu, 14 Mar 2013 09:44:14 -0700 (PDT)
From: David Singer 
In-reply-to: 
Date: Thu, 14 Mar 2013 09:44:14 -0700
Message-id: 
References:  
To: "rtcweb@ietf.org" 
X-Mailer: Apple Mail (2.1499)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCLMWRmVeSWpSXmKPExsUi2FAcpxv3zzHQoOeascXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKmNT1iLngPHfFyW/vmBsYV3B2MXJySAiYSKzd0cMOYYtJXLi3 ng3EFhKYyCRx9nxQFyMXkD2TSeLd5heMXYwcHMwCehL3L2qBmLxA5qT9QSDlwgL+Epv3LWQC sdkEVCUezDkGVs0pECxx5k4iiMkCFP49IwakgllAW+LJuwusIDavgI1E27crrFCLGCUmXNkH NkZEQF3i8sMLUJfJSqyY2ss0gZF/FsINsxBumIVk6gJG5lWMAkWpOYmVRnqJBQU5qXrJ+bmb GMFhVei8g/HYMqtDjAIcjEo8vA4PHQOFWBPLiitzDzFKcDArifDu+gsU4k1JrKxKLcqPLyrN SS0+xCjNwaIkzru+wz5QSCA9sSQ1OzW1ILUIJsvEwSnVwMjbe5BXszI8/cX9twxrmeewnNRK 3njfI6KzOqM7SrngcNwy+3vp+ceyJsjI79XW3fm3u9tt1y6zKjdmVfmskoS999o28GsdERbl 9GGWFlDXfdb+keHl/TPPK42sbjNuO71Gumm7abnp6xvl9Tknpk8xdl/l9uG5xQL59U42F1RL q+TZChsllFiKMxINtZiLihMB+oCayCcCAAA=
Subject: Re: [rtcweb] A different perspective on the video codec MTI	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: Thu, 14 Mar 2013 16:44:15 -0000

On Mar 14, 2013, at 9:24 , Ben Strong  wrote:

> However, I fail to see how either one of those points has any bearing on the MTI decision. The whole point of MTI is guaranteed interoperability across all WebRTC implementations, which is absolutely critical to WebRTC adoption. The only criteria should be the best quality codec which can be supported by all implementations. And because some implementations are open source, it absolutely must be royalty free.

I think you make a key point here; making a mandate that doesn't have consensus is empty, as if (for example) companies are forced to choose between formally complying with the mandate, or taking on excessive risk, they'll probably be risk-averse. Or a mandate that carries a license fee will be ignored by those who don't pay such fees on principle.

We all need a decision we can all stand behind, and we're making progress to that goal, and I appreciate all the data and efforts.  There is some very important data (notably, the names of the 11 and the resulting license) which is promised to be available in only a few weeks. Let's not decide in haste (and possibly repent at leisure).


By the way, open-source and license fees are not in direct conflict; it's the principles that are.  To pick a directly-relevant example, there are open-source implementations of H.264 (AVC).

David Singer
Multimedia and Software Standards, Apple Inc.


From basilgohar@librevideo.org  Thu Mar 14 10:18: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 E665A21F8EA7 for ; Thu, 14 Mar 2013 10:18:57 -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 FDY144SjHDSz for ; Thu, 14 Mar 2013 10:18:52 -0700 (PDT)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 91B5811E81B4 for ; Thu, 14 Mar 2013 10:18:52 -0700 (PDT)
Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 6820D656DE5 for ; Thu, 14 Mar 2013 13:18:51 -0400 (EDT)
Message-ID: <51420679.2060909@librevideo.org>
Date: Thu, 14 Mar 2013 13:18:49 -0400
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References:   
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] A different perspective on the video codec MTI	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: Thu, 14 Mar 2013 17:18:58 -0000

On 03/14/2013 12:44 PM, David Singer wrote:
> By the way, open-source and license fees are not in direct conflict;
> it's the principles that are. To pick a directly-relevant example,
> there are open-source implementations of H.264 (AVC).  
This is skirting the issue by using the vague term "open-source" in a
way that illustrates the discrepancy of the argument.  For this purpose,
it is important to outline the main argument against the usage of H.264
(AVC) in terms of the free software definition, which can be found here:
https://www.gnu.org/philosophy/free-sw.html
>
> A program is free software if the program's users have the four
> essential freedoms:
>
>   * The freedom to run the program, for any purpose (freedom 0).
>   * The freedom to study how the program works, and change it so it
>     does your computing as you wish (freedom 1). Access to the source
>     code is a precondition for this.
>   * The freedom to redistribute copies so you can help your neighbor
>     (freedom 2).
>   * The freedom to distribute copies of your modified versions to
>     others (freedom 3). By doing this you can give the whole community
>     a chance to benefit from your changes. Access to the source code
>     is a precondition for this.
>
*Requiring* a license fee to allow one or more of these points would
directly intervene in that freedom being available without restriction,
and thus, would prevent the implementation from being free software
according to the above definition.  Though I am not as familiar with
OSI's Open Source Definition (http://opensource.org/osd-annotated), a
cursory reading also indicates that a *requirement* of a license fee
would, by necessity, exclude it from fitting the open source definition
as well.

MPEG-LA's licensing structure for H.264 is strange in that it is a
license for /end-users/, meaning, such as the people that finally use a
product (e.g., the web browser him/herself).  So, the producers of the
software may themselves not require a license, but their users would. 
This is the issue by which a *required* licensing fee (which, due to
encumbrance by patents, is legally binding at this time by choice of the
owners of said patents in many jurisdictions) excludes something from
being free, open source software in this situation.

I talked about this with direct answers from the MPEG-LA here:
http://www.librevideo.org/blog/2010/06/14/mpeg-la-answers-some-questions-about-avch-264-licensing/

The point you make above is, apparently, talking from the perspective of
software producers.  Free software advocates always talk from the
perspective of the *users*, which includes software producers that use
other free software.  The blurring of the meaning of the term
open-source to imply only the software developers/producers is why many
prefer the term free software to this date.

The conclusion of this is that, yes, actually, licensing fee and
open-source (and also free) software are in direct conflict, by
definition.  The fact that some software is released under an
open-source license does not mean all users of that software have access
to it under the conditions of that license.

-- 
Libre Video
http://librevideo.org


From singer@apple.com  Thu Mar 14 10:30: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 4544621F910C for ; Thu, 14 Mar 2013 10:30: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=[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 8F-O4mghh6uG for ; Thu, 14 Mar 2013 10:30:32 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 74FF611E80D9 for ; Thu, 14 Mar 2013 10:30:32 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay7.apple.com ([17.128.113.101]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MJN00M99VAWXO51@mail-out.apple.com> for rtcweb@ietf.org; Thu, 14 Mar 2013 10:30:32 -0700 (PDT)
X-AuditID: 11807165-b7fb26d00000796b-8d-51420938bd41
Received: from cardamom.apple.com (cardamom.apple.com [17.128.115.94]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay7.apple.com (Apple SCV relay) with SMTP id A5.AC.31083.83902415; Thu, 14 Mar 2013 10:30:32 -0700 (PDT)
Received: from singda.apple.com ([17.197.32.11]) by cardamom.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MJN006VGVAVN260@cardamom.apple.com> for rtcweb@ietf.org; Thu, 14 Mar 2013 10:30:32 -0700 (PDT)
From: David Singer 
In-reply-to: <51420679.2060909@librevideo.org>
Date: Thu, 14 Mar 2013 10:30:32 -0700
Message-id: <21CA7207-0D35-4B9A-B463-D95F5C76275C@apple.com>
References:    <51420679.2060909@librevideo.org>
To: "rtcweb@ietf.org" 
X-Mailer: Apple Mail (2.1499)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUi2FAcp2vB6RRosPuFgMXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKaFqwib2gn63i5tzPbA2Mn1i6GDk5JARMJJYtusoEYYtJXLi3 nq2LkYtDSGAik8TJxQuZIJyZTBK7Z+4Bq2IW0JJYv/M4kM3BwSugJzFpfxBIWFjAX2L7uqns IDabgKrEgznHGEFKOIFKXh3TATFZgMLffgVBDNGWePLuAiuIzStgI3F21S5WiE0fGCX6Li5n BkmICKhLXH54gR3iNlmJFVN7mSYw8s9CcsQshCNmIRm7gJF5FaNAUWpOYqW5XmJBQU6qXnJ+ 7iZGcHAVpu5gbFxudYhRgINRiYd3xmPHQCHWxLLiytxDjBIczEoivLv+AoV4UxIrq1KL8uOL SnNSiw8xSnOwKInzbuqwDxQSSE8sSc1OTS1ILYLJMnFwSjUw+pT/iPmX3Xds/vsl2zK/bNJj PvqovNO5Z6mtp+Ry6QXSPirCzT6tGzLzb/FkXtyUXjefJbx8l/dTk3O7NENLLKPmc2yd9Pxb TJG/3g2Hia0Xt504yVnyhVt+a5kGY1H/+byPNyx3ss3nnJrtv1PpW8yaSU4GE4N7Hmira7O7 8S3hSd6tbZ+rxFKckWioxVxUnAgAhgWKHSoCAAA=
Subject: Re: [rtcweb] A different perspective on the video codec	MTI	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: Thu, 14 Mar 2013 17:30:33 -0000

On Mar 14, 2013, at 10:18 , Basil Mohamed Gohar  wrote:

> On 03/14/2013 12:44 PM, David Singer wrote:
>> By the way, open-source and license fees are not in direct conflict;
>> it's the principles that are. To pick a directly-relevant example,
>> there are open-source implementations of H.264 (AVC).  
> This is skirting the issue by using the vague term "open-source" in a
> way that illustrates the discrepancy of the argument.  

I think you'll see that in general I agree with you, in that I said it was principles other than simply open-source that were at work here; you work it out in more detail, to be sure.  (It wasn't me that used the term initially.)

David Singer
Multimedia and Software Standards, Apple Inc.


From xiphmont@gmail.com  Thu Mar 14 10:37: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 379BB11E80E9 for ; Thu, 14 Mar 2013 10:37:29 -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 lk+JfIzLn8fM for ; Thu, 14 Mar 2013 10:37:22 -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 C1CA011E8192 for ; Thu, 14 Mar 2013 10:37:22 -0700 (PDT)
Received: by mail-ob0-f179.google.com with SMTP id un3so2402977obb.38 for ; Thu, 14 Mar 2013 10:37:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=758+5Mm+JvTSVBx1D5RIR/PKywzhkbnb8VhkYyG/HaE=; b=DN0SF9uLcz2mOndtDixxXOSvOSSW/bgPpUen0YaTOQ6hLOWaUh+Zl42M1cQWF2CWx5 bB64s82JeTrYBTCYsR/hA1zLItnF1ISE7ILaxOE5bSWrNODPShOtndEdzSVQQ6DbioAj xa/qwL+taeVsKQkRUuUzjjL8hVZnyeeohoIA9OZFF+eiOT1p9OVwyDgQesJnSG2dWc3y G1BfZhEvSmjEMYHlJWKjrcVsok2M95XVCzRUh6KZPyIzVqWffFKRrpiTGEGPemPVwaHG 11sAsEYNujA8Pg3biaO4g5SR64SkRUq+UlzRMIhW8ugy/mQ31fp8RiA+A8v1+D6Vt6VZ L8Cw==
MIME-Version: 1.0
X-Received: by 10.60.27.169 with SMTP id u9mr1559599oeg.138.1363282642386; Thu, 14 Mar 2013 10:37:22 -0700 (PDT)
Received: by 10.182.180.107 with HTTP; Thu, 14 Mar 2013 10:37:22 -0700 (PDT)
In-Reply-To: 
References:   
Date: Thu, 14 Mar 2013 13:37:22 -0400
Message-ID: 
From: Monty Montgomery 
To: David Singer 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] A different perspective on the video codec MTI 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: Thu, 14 Mar 2013 17:37:29 -0000

> To pick a directly-relevant example, there are open-source implementations of H.264 (AVC).

Also directly relevant, I'm not allowed to use these implementations
without negotiating a license which MPEG LA will not sell me.  The
restriction/control element is more important than the money.

It's clear by inference that Ben was speaking of fully FOSS software.

Monty
Xiph.Org

From btv1==7857ef4b335==HKaplan@acmepacket.com  Thu Mar 14 10:39: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 6139721F8D43 for ; Thu, 14 Mar 2013 10:39:19 -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 VTxg4mqHhHG0 for ; Thu, 14 Mar 2013 10:39:06 -0700 (PDT)
Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2A921F8496 for ; Thu, 14 Mar 2013 10:39:06 -0700 (PDT)
X-ASG-Debug-ID: 1363282744-03fc200f255b80e0001-4f8tJD
Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx1.acmepacket.com with ESMTP id PdW85Lm9HRCkzWJM (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Mar 2013 13:39:04 -0400 (EDT)
X-Barracuda-Envelope-From: HKaplan@acmepacket.com
Received: from MAIL2.acmepacket.com ([169.254.2.222]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Thu, 14 Mar 2013 13:39:04 -0400
From: Hadriel Kaplan 
To: Basil Mohamed Gohar 
Thread-Topic: [rtcweb] A different perspective on the video codec	MTI discussion
X-ASG-Orig-Subj: Re: [rtcweb] A different perspective on the video codec	MTI discussion
Thread-Index: AQHOINrRAXo8sskPHEayoYA4tD8vhQ==
Date: Thu, 14 Mar 2013 17:39:03 +0000
Message-ID: <34944444-4FEB-4AD0-A90D-1EE8C56C0253@acmepacket.com>
References:    <51420679.2060909@librevideo.org>
In-Reply-To: <51420679.2060909@librevideo.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7CA7E7CB2A27EE46B5435993956F545F@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21]
X-Barracuda-Start-Time: 1363282744
X-Barracuda-Encrypted: AES128-SHA
X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at acmepacket.com
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.125198 Rule breakdown below pts rule name              description ---- ---------------------- --------------------------------------------------
Cc: "" 
Subject: Re: [rtcweb] A different perspective on the video codec	MTI	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: Thu, 14 Mar 2013 17:40:19 -0000

On Mar 14, 2013, at 1:18 PM, Basil Mohamed Gohar 
 wrote:

> I talked about this with direct answers from the MPEG-LA here:
> http://www.librevideo.org/blog/2010/06/14/mpeg-la-answers-some-questions-=
about-avch-264-licensing/

Interesting - I hadn't realized their license was as viral to 'derivative' =
works as GPLv3.

So does this mean if a mobile phone vendor had the license for H.264 in the=
ir hardware encoder/decoder, and provided an API to applications to use tha=
t hardware, that any application using the API would also be a new end-prod=
uct and have to acquire the license as well?

Likewise, if a web-based app framework such as PhoneGap/Titanium/etc. acqui=
red a license for H.264 and provided an API for using it to their customers=
'(the app creators) code, that their customers (the app creators) would als=
o need to get the license?

-hadriel


From lorenzo@meetecho.com  Thu Mar 14 10:56: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 2869111E813F for ; Thu, 14 Mar 2013 10:56:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level: 
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwtTJby+QNSM for ; Thu, 14 Mar 2013 10:56:09 -0700 (PDT)
Received: from smtpdg10.aruba.it (smtpdg4.aruba.it [62.149.158.234]) by ietfa.amsl.com (Postfix) with ESMTP id C548021F8952 for ; Thu, 14 Mar 2013 10:56:08 -0700 (PDT)
Received: from lminiero-acer ([130.129.20.132]) by smtpcmd04.ad.aruba.it with bizsmtp id BVw21l01f2qyxt601Vw3VQ; Thu, 14 Mar 2013 18:56:06 +0100
Date: Thu, 14 Mar 2013 18:55:51 +0100
From: Lorenzo Miniero 
To: Hadriel Kaplan 
Message-ID: <20130314185551.58f0bc1a@lminiero-acer>
In-Reply-To: <34944444-4FEB-4AD0-A90D-1EE8C56C0253@acmepacket.com>
References:    <51420679.2060909@librevideo.org> <34944444-4FEB-4AD0-A90D-1EE8C56C0253@acmepacket.com>
Organization: Meetecho
X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: "" 
Subject: Re: [rtcweb] A different perspective on the video codec	MTI 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: Thu, 14 Mar 2013 17:56:10 -0000

Il giorno Thu, 14 Mar 2013 17:39:03 +0000
Hadriel Kaplan  ha scritto:

> 
> On Mar 14, 2013, at 1:18 PM, Basil Mohamed Gohar
>  wrote:
> 
> > I talked about this with direct answers from the MPEG-LA here:
> > http://www.librevideo.org/blog/2010/06/14/mpeg-la-answers-some-questions-about-avch-264-licensing/
> 
> Interesting - I hadn't realized their license was as viral to
> 'derivative' works as GPLv3.
> 
> So does this mean if a mobile phone vendor had the license for H.264
> in their hardware encoder/decoder, and provided an API to
> applications to use that hardware, that any application using the API
> would also be a new end-product and have to acquire the license as
> well?
> 
> Likewise, if a web-based app framework such as PhoneGap/Titanium/etc.
> acquired a license for H.264 and provided an API for using it to
> their customers'(the app creators) code, that their customers (the
> app creators) would also need to get the license?
> 
> -hadriel
> 


This is indeed an interesting read, thanks Basil for sharing this.

Lorenzo

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



-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

From suhasietf@gmail.com  Thu Mar 14 10:59: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 06CDA11E80F2 for ; Thu, 14 Mar 2013 10:59:04 -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 3of5LfGOqOtG for ; Thu, 14 Mar 2013 10:59:03 -0700 (PDT)
Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6BA11E814D for ; Thu, 14 Mar 2013 10:59:02 -0700 (PDT)
Received: by mail-we0-f179.google.com with SMTP id p43so2429224wea.24 for ; Thu, 14 Mar 2013 10:59:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=OFt1iTix5wp8GFWGD+UUTjEpamNZsQmqim8urwxj1YA=; b=kYO4k0GCgWG4UXVBkB10jZ2AjNJyNgr74wJWoPqsLNow/8bShNy8fkl12MaBFVyIQa QDWwUDHy/39g7KJB2Ur5s+rNIKAhIwzGxEWd6PXLVy+YwVaU/xp2i5KejctPGXIxOSSm MJuLdvVopYKJAR26nH4INumdx1hzzK+OB2k5p0MbtqC5bZByrq20ZPv3okTlZNlX7cuZ HzEPy+4IImJ/v9gRuu8mXF1OzN1u/pjEe81SMZueLG6uBDjQZODNRSnCr7uGIW6YwZLP HjdBKIDvpNuJf/red3uwRuPg7I/1gmVHKWnJx/Jy9y2rb1AHW5qE8wDTjGiMtdk6JQn+ Ddiw==
MIME-Version: 1.0
X-Received: by 10.180.85.97 with SMTP id g1mr36150193wiz.29.1363283941277; Thu, 14 Mar 2013 10:59:01 -0700 (PDT)
Received: by 10.194.16.170 with HTTP; Thu, 14 Mar 2013 10:59:00 -0700 (PDT)
Date: Thu, 14 Mar 2013 10:59:00 -0700
Message-ID: 
From: Suhas Nandakumar 
To: rtcweb@ietf.org
Content-Type: multipart/alternative; boundary=f46d0444036c0c480204d7e6472f
Subject: [rtcweb] Video Codec MTI & User Experience == 1
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 17:59:04 -0000

--f46d0444036c0c480204d7e6472f
Content-Type: text/plain; charset=ISO-8859-1

 I feel a good user experience is as important as MTI being successfully
negotiated. Users will turn off their video and de-escalate to audio only
interaction if they look terribly bad in any kind of use-cases dealt within
RTCWeb.

We should be avoiding this at any cause since it defeats the purpose of
RTCWeb to enable rich interactions via audio, video.

This is my personal opinion.

Thanks
./Suhas
 [ one of the end-users]

--f46d0444036c0c480204d7e6472f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



=A0I feel a good user experien=
ce is as important as MTI being successfully negotiated. Users will turn of=
f their video and de-escalate to audio only interaction if they look terrib=
ly bad in any kind of use-cases dealt within RTCWeb.=A0



We should be avoiding this at any cause since it defeat=
s the purpose of RTCWeb to enable rich interactions via audio, video.
=


This is my personal opinion.


Thanks
./Suhas
=A0[ one of the end-users]


--f46d0444036c0c480204d7e6472f--

From basilgohar@librevideo.org  Thu Mar 14 11:03: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 56D8311E8153 for ; Thu, 14 Mar 2013 11:03:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.953
X-Spam-Level: 
X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2th+a5oZVznU for ; Thu, 14 Mar 2013 11:03:54 -0700 (PDT)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id C383B11E8129 for ; Thu, 14 Mar 2013 11:03:54 -0700 (PDT)
Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 73736652968 for ; Thu, 14 Mar 2013 14:03:53 -0400 (EDT)
Message-ID: <51421106.7040803@librevideo.org>
Date: Thu, 14 Mar 2013 14:03:50 -0400
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3
MIME-Version: 1.0
CC: "" 
References:    <51420679.2060909@librevideo.org> <34944444-4FEB-4AD0-A90D-1EE8C56C0253@acmepacket.com>
In-Reply-To: <34944444-4FEB-4AD0-A90D-1EE8C56C0253@acmepacket.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] A different perspective on the video codec	MTI 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: Thu, 14 Mar 2013 18:03:55 -0000

On 03/14/2013 01:39 PM, Hadriel Kaplan wrote:
> On Mar 14, 2013, at 1:18 PM, Basil Mohamed Gohar 
>  wrote:
>> I talked about this with direct answers from the MPEG-LA here:
>> http://www.librevideo.org/blog/2010/06/14/mpeg-la-answers-some-questions-about-avch-264-licensing/
> Interesting - I hadn't realized their license was as viral to 'derivative' works as GPLv3.
>
> So does this mean if a mobile phone vendor had the license for H.264 in their hardware encoder/decoder, and provided an API to applications to use that hardware, that any application using the API would also be a new end-product and have to acquire the license as well?
>
> Likewise, if a web-based app framework such as PhoneGap/Titanium/etc. acquired a license for H.264 and provided an API for using it to their customers'(the app creators) code, that their customers (the app creators) would also need to get the license?
>
> -hadriel
Hadriel,

If you read the documentation that comes with your, for example, AVCHD
camcorder, you'll see that the licensee (the hardware manufacturer) can
give to their users is a private, non-commericial license to the usage
of the encoded media produced by it.  Windows users, as well, are
granted a license via Microsoft to the usage of the decoder shipped with
the OS for the same limited usages.  Commercial usages beyond this would
seem to require an additional license (e.g., a paid performance where an
H.264 video is played on a Windows machine, perhaps?).

I don't know what to say about the other issues you've raised.  IANAL
and such. :)  Such questions may be directed to MPEG-LA.

-- 
Libre Video
http://librevideo.org


From basilgohar@librevideo.org  Thu Mar 14 11:06: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 D46C111E8129 for ; Thu, 14 Mar 2013 11:06:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.276
X-Spam-Level: 
X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323,  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 T1hBILpk7wRh for ; Thu, 14 Mar 2013 11:06:53 -0700 (PDT)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 1575411E8194 for ; Thu, 14 Mar 2013 11:06:53 -0700 (PDT)
Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 2E1D8656E42 for ; Thu, 14 Mar 2013 14:06:49 -0400 (EDT)
Message-ID: <514211B6.1010202@librevideo.org>
Date: Thu, 14 Mar 2013 14:06:46 -0400
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3
MIME-Version: 1.0
To: "" 
References:    <51420679.2060909@librevideo.org> <34944444-4FEB-4AD0-A90D-1EE8C56C0253@acmepacket.com>
In-Reply-To: <34944444-4FEB-4AD0-A90D-1EE8C56C0253@acmepacket.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] A different perspective on the video codec	MTI 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: Thu, 14 Mar 2013 18:06:54 -0000

On 03/14/2013 01:39 PM, Hadriel Kaplan wrote:
> On Mar 14, 2013, at 1:18 PM, Basil Mohamed Gohar 
>  wrote:
>
>> I talked about this with direct answers from the MPEG-LA here:
>> http://www.librevideo.org/blog/2010/06/14/mpeg-la-answers-some-questions-about-avch-264-licensing/
> Interesting - I hadn't realized their license was as viral to 'derivative' works as GPLv3.
I forgot to point out in my last reply that the observation I made about
CC-licensed material might not be completely sound, from a legal
standpoint.  The confusion, however, is definitely present, but the
point is that that case may not be present.  Your license via CC
basically doesn't overlap with the need for licensing.  If I can find
the relevant text about that, I will try to share it and/or post again
on the blog.

-- 
Libre Video
http://librevideo.org


From roman@telurix.com  Thu Mar 14 11:11: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 C8CB811E81B0 for ; Thu, 14 Mar 2013 11:11: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 HmN5XiNulhhX for ; Thu, 14 Mar 2013 11:11:57 -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 B72D011E81AC for ; Thu, 14 Mar 2013 11:11:56 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id hm6so2099969wib.8 for ; Thu, 14 Mar 2013 11:11:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=IzyZrW0iE+hWhZI0UNVnTIr87TKc6SbCp43KQPF8IIU=; b=nfLqem+ng4Wq14C7Xq1+4ZeofcSrfeWaDOohTWyCrNbEXoXKRpZDbkg9LBzq87+rxY C4Xevv2CVlOe2HqzxYICHHKfonvMrz3///FFQ0dFcuQ++dFsS0Htez9xI20tGsxQOlGz Kch2i7qqnYd7t3/oYLSW6gQjAFk47gwmYxzBhd8R3UHcBUyCJGcs63eubPIpgRAKZPf4 TVMYq5s+zYWMrTl70/7tESFQMUW5dQRr5vH0De0qQ3aLEF2wj3WcQ8B70okYAhaMXN/a oYD2YB5y5dO4w9Dp31XBVfH8r6KZbx1tvN5YTuDDOMQp/wHW3MI6L4RoJbXxnxHEbyvD bOOw==
X-Received: by 10.180.100.10 with SMTP id eu10mr36041068wib.4.1363284715895; Thu, 14 Mar 2013 11:11:55 -0700 (PDT)
Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by mx.google.com with ESMTPS id c15sm5655274wiw.3.2013.03.14.11.11.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 11:11:54 -0700 (PDT)
Received: by mail-wg0-f52.google.com with SMTP id 15so1335489wgd.7 for ; Thu, 14 Mar 2013 11:11:53 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.87.98 with SMTP id w2mr5970261wiz.30.1363284713720; Thu, 14 Mar 2013 11:11:53 -0700 (PDT)
Received: by 10.217.107.135 with HTTP; Thu, 14 Mar 2013 11:11:53 -0700 (PDT)
In-Reply-To: <514211B6.1010202@librevideo.org>
References:    <51420679.2060909@librevideo.org> <34944444-4FEB-4AD0-A90D-1EE8C56C0253@acmepacket.com> <514211B6.1010202@librevideo.org>
Date: Thu, 14 Mar 2013 14:11:53 -0400
Message-ID: 
From: Roman Shpount 
To: Basil Mohamed Gohar 
Content-Type: multipart/alternative; boundary=f46d0418261616cfbe04d7e67589
X-Gm-Message-State: ALoCoQkYunuii5tQrvTCBAtQX/aSRlGaohCpLw8/pZCyexQ17pPj1CigPGhRlV6nQIYYK7C3oXmm
Cc: "" 
Subject: Re: [rtcweb] A different perspective on the video codec MTI 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: Thu, 14 Mar 2013 18:11:57 -0000

--f46d0418261616cfbe04d7e67589
Content-Type: text/plain; charset=ISO-8859-1

One thing that was not clear for me from your blog was if an application
running on Windows OS and using OS provided API for H.264 playback is
licensed to do so.
_____________
Roman Shpount


On Thu, Mar 14, 2013 at 2:06 PM, Basil Mohamed Gohar <
basilgohar@librevideo.org> wrote:

> On 03/14/2013 01:39 PM, Hadriel Kaplan wrote:
> > On Mar 14, 2013, at 1:18 PM, Basil Mohamed Gohar <
> basilgohar@librevideo.org>
> >  wrote:
> >
> >> I talked about this with direct answers from the MPEG-LA here:
> >>
> http://www.librevideo.org/blog/2010/06/14/mpeg-la-answers-some-questions-about-avch-264-licensing/
> > Interesting - I hadn't realized their license was as viral to
> 'derivative' works as GPLv3.
> I forgot to point out in my last reply that the observation I made about
> CC-licensed material might not be completely sound, from a legal
> standpoint.  The confusion, however, is definitely present, but the
> point is that that case may not be present.  Your license via CC
> basically doesn't overlap with the need for licensing.  If I can find
> the relevant text about that, I will try to share it and/or post again
> on the blog.
>
> --
> Libre Video
> http://librevideo.org
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--f46d0418261616cfbe04d7e67589
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

One thing that was not clear for me from your blog was if an application ru=
nning on Windows OS and using OS provided API for H.264 playback is license=
d to do so.
_____________
Roman Shpount



On Thu, Mar 14, 2013 at 2:06 PM, Basil M=
ohamed Gohar <basilgohar@librevideo.org> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">
On 03/14/2013 01:39 PM, Hadriel Kaplan wrote:

> On Mar 14, 2013, at 1:18 PM, Basil Mohamed Gohar <basilgohar@librevideo.org>

> =A0wrote:

>

>> I talked about this with direct answers from the MPEG-LA here:

>> http://www.l=
ibrevideo.org/blog/2010/06/14/mpeg-la-answers-some-questions-about-avch-264=
-licensing/


> Interesting - I hadn't realized their license was as viral to '=
;derivative' works as GPLv3.

I forgot to point out in my last reply that the observation I made about
CC-licensed material might not be completely sound, from a legal

standpoint. =A0The confusion, however, is definitely present, but the

point is that that case may not be present. =A0Your license via CC

basically doesn't overlap with the need for licensing. =A0If I can find=


the relevant text about that, I will try to share it and/or post again

on the blog.



--

Libre Video

http://librevideo.org



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--f46d0418261616cfbe04d7e67589--

From bo.burman@ericsson.com  Thu Mar 14 11:13: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 DB9FF21F8A98 for ; Thu, 14 Mar 2013 11:13:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 Wle91j1ikYL5 for ; Thu, 14 Mar 2013 11:13:54 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2E02821F8A14 for ; Thu, 14 Mar 2013 11:13:54 -0700 (PDT)
X-AuditID: c1b4fb30-b7f0d6d000007e61-64-5142136069db
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 12.BA.32353.06312415; Thu, 14 Mar 2013 19:13:53 +0100 (CET)
Received: from ESESSMB105.ericsson.se ([169.254.5.124]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 19:13:52 +0100
From: Bo Burman 
To: "rtcweb@ietf.org" 
Thread-Topic: Cross-check of Google VP8 vs H.264 comparison
Thread-Index: Ac4g366CgEkg0T+ZQYGtOXBTo83Dpw==
Date: Thu, 14 Mar 2013 18:13:52 +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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM+JvjW6isFOgwbrNnBZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4//0k8wFp1gqdk6dxdTAeJG5i5GTQ0LARGLlu31QtpjEhXvr 2boYuTiEBA4xSuydsxvKWcIoMaXjBiNIFZuAhsT8HXfBbBEBdYnLDy+wg9jCAmYSbR0nmSHi 1hIXHk1kh7D1JHY9us/UxcjBwSKgKjF7vg5ImFfAV+LcvrVgYxgFZCXuf7/HAmIzC4hL3Hoy nwniIAGJJXvOQx0nKvHy8T9WkDESAooSy/vlIMp1JBbs/sQGYWtLLFv4mhlivKDEyZlPWCYw Cs9CMnUWkpZZSFpmIWlZwMiyipE9NzEzJ73cfBMjMIgPbvltsINx032xQ4zSHCxK4rzhrhcC hATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTBur81hLcu+/F1Qeunnx4vDt93PU2C6ws5zQXil qoZ7+9atc005U5W5ryR7JuTK/yo4pSvqcztclK3ha/B0w7LNPktK5T7qXSuvTZuxZ/p+roZG hoNLRAVPpW04p9onK5/9WCbe3WO/qO2klJkfgj1/CQokSkQLu1kwpZWFzFbM3f+cL++UohJL cUaioRZzUXEiAF4grskwAgAA
Subject: [rtcweb] Cross-check of Google VP8 vs H.264 comparison
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 18:13:55 -0000

Hi,

As said on the microphone today, we have cross-checked Google's VP8 vs H.26=
4 comparison. Google reported bit rate gains for VP8 of 19%. However, the H=
.264 was at an unfair advantage due to the fact that the --tune psnr flag w=
as not used in x264. This should of course be used when doing psnr-measurem=
ents. For vp8, this flag is set to psnr by default.=20

When re-running the tests with --tune psnr for x264, and using version 130 =
of x264 instead of version 128 that was used in the Google test, the differ=
ence disappeared (1% difference).=20

Cheers,
Bo

From basilgohar@librevideo.org  Thu Mar 14 12:08: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 3FE6111E81AB for ; Thu, 14 Mar 2013 12:08:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.384
X-Spam-Level: 
X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215,  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 jOOiGfBtru5c for ; Thu, 14 Mar 2013 12:08:25 -0700 (PDT)
Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 81D5111E80F2 for ; Thu, 14 Mar 2013 12:08:25 -0700 (PDT)
Received: from [10.10.40.120] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id DB054656F5C for ; Thu, 14 Mar 2013 15:08:24 -0400 (EDT)
Message-ID: <51422025.8020108@librevideo.org>
Date: Thu, 14 Mar 2013 15:08:21 -0400
From: Basil Mohamed Gohar 
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3
MIME-Version: 1.0
To: "" 
References:    <51420679.2060909@librevideo.org> <34944444-4FEB-4AD0-A90D-1EE8C56C0253@acmepacket.com> <514211B6.1010202@librevideo.org> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] A different perspective on the video codec MTI 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: Thu, 14 Mar 2013 19:08:26 -0000

On 03/14/2013 02:11 PM, Roman Shpount wrote:
> One thing that was not clear for me from your blog was if an
> application running on Windows OS and using OS provided API for H.264
> playback is licensed to do so.
Roman,

I again have to put out there *very clearly* that I am not a lawyer.  I
can only take some clear statements I've been given and/or read and
present them together.  But the license that Microsoft provides their
users as stated in the manual is a private, non-commercial license.  So,
if the usage fits those definitions, it seems to be the case.  The
attorney from MPEG-LA made clear that their licensing is for end-user
products.  That's why someone can write an H.264 decoder or encoder, and
ship it without much problem, but it's the *users* of said
decoder/encoder that would face the licensing question.

Does that make sense?  This is what I mean by the licensing being
somewhat odd.  It's totally not a problem (maybe not *totally*, but I
hope you get the idea) for software producers.  It's *totally* a problem
for the users.

It's a shame that people like me, who do not have any real legal
background, and the ones having to explain this, and people that
actually know better are either not speaking about it or are not being
heard.  The problems posed by H.264 licensing for users, and thus the
free software community, are very severe and confusing.

-- 
Libre Video
http://librevideo.org


From yekuiw@qti.qualcomm.com  Thu Mar 14 12:08: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 432F121F8E57 for ; Thu, 14 Mar 2013 12:08:36 -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 ahWgnsvar+FY for ; Thu, 14 Mar 2013 12:08:35 -0700 (PDT)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id D92E721F8E43 for ; Thu, 14 Mar 2013 12:08:34 -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=1363288114; x=1394824114; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=udifaZXOVy9Z7pcSFE3LFUyz2zDWjy3R3e+Yr2XXnvM=; b=xvCiDZDSwJ5ArBXSsDbs2xD4u7A8ggGOiEvnu37+i6C5geeQluJF5D9+ fv2tDf3G0csWvdzvGhwvIK3NnsUgpIPMDriRCvBHHUybXQMYttv9940R1 v6AG/w8EYXPNoXui5B2JrwuagFYPa/kPdFg+mTDWFvWywBWYTtc32c24Z 4=;
X-IronPort-AV: E=Sophos;i="4.84,846,1355126400"; d="scan'208,217";a="30014145"
Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP; 14 Mar 2013 12:08:34 -0700
X-IronPort-AV: E=Sophos;i="4.84,846,1355126400";  d="scan'208,217";a="451622000"
Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 14 Mar 2013 12:08:34 -0700
Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.64]) by nasanexhc10.na.qualcomm.com ([172.30.48.3]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 12:08:33 -0700
From: "Wang, Ye-Kui" 
To: Rob Glidden , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Video Codec discussion in Thursday agenda slot
Thread-Index: AQHOH0jr3vjUB09c8EG4MhtYHbfvE5ii0RyAgAAIloCAAAHrgIABTYKAgAACnQD//7k88IAA5mkA///RB+2AATDnAP//wfZQ
Date: Thu, 14 Mar 2013 19:08:33 +0000
Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A8331B19D77@nasanexd02f.na.qualcomm.com>
References: <513F68C0.4010106@ericsson.com>  <513F7745.3020302@alvestrand.no>    <8BA7D4CEACFFE04BA2D902BF11719A8331B17F22@nasanexd02f.na.qualcomm.com>,  <1363220674.82166.YahooMailNeo@web132106.mail.ird.yahoo.com> <2981F523-72AC-4330-8D1F-7DC4E2168C5A@qti.qualcomm.com> <5141F120.3020400@gmail.com>
In-Reply-To: <5141F120.3020400@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.202.210]
Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A8331B19D77nasanexd02fnaqu_"
MIME-Version: 1.0
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 19:08:36 -0000

--_000_8BA7D4CEACFFE04BA2D902BF11719A8331B19D77nasanexd02fnaqu_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Surely it is not.

Note that the context here is on the MTI codec discussion in IETF, not at a=
ll the context the POSSIBLE standardization of VP8 in MPEG (which, if to ha=
ppen, would most likely be subject to more development taking the current V=
P8 as the basis rather than rubberstamping as is).

BR, YK

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Rob Glidden
Sent: Thursday, March 14, 2013 8:48 AM
To: Wang, Ye-Kui; rtcweb@ietf.org
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot

Sure it is, there's an open MPEG meeting resolution on the MPEG VP8 proposa=
l to that effect, apparently even National Body comment.

Rob

On 3/13/2013 9:36 PM, Wang, Ye-Kui wrote:
Sure - but that is clearly not the context here.

Sent from my iPhone

On Mar 13, 2013, at 17:24, "Gerard Fernando" > wrote:
Hello YK,

The disclosure process in MPEG is not based on who you are, or on your Busi=
ness model.

Kind regards

Gerard

________________________________
From: "Wang, Ye-Kui" >
To: Stockhammer Thomas >;=
 Bo Burman >
Cc: "rtcweb@ietf.org" >
Sent: Wednesday, 13 March 2013, 10:40
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot

> >  How many others who did not respond to MPEG LA's call but have IPR
> > are
> there?
>
> [TS]  Just one more hypothesis: If I would have, what would be my
> obligation/motivation to do so now?

Speaking of the motivation part; that would depend on who YOU are and what =
kind of business model or plan YOU have in mind.

BR, YK

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtc=
web-bounces@ietf.org] On Behalf
> Of Stockhammer Thomas
> Sent: Wednesday, March 13, 2013 7:53 AM
> To: Bo Burman
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
>
>
> >  How many others who did not respond to MPEG LA's call but have IPR are
> there?
>
> [TS]  Just one more hypothesis: If I would have, what would be my
> obligation/motivation to do so now?
>
> >>>
> >>> We appreciate the need to have time to evaluate the specific words
> >>> of the license statements that are forthcoming, and the need for the
> >>> people who haven't made their IPR declarations over the last couple
> >>> of years of discussion to do so within the next couple of weeks -
> >>> but we do think that it is important to use the face to face time
> >>> that we have here in Orlando to lay to rest any *other* issues than
> >>> the licensing terms and other issues derived from Google's
> announcement.
> >>
> >> I am not sure we can have a reasoned consideration of 'other issues
> derived'
> >> at such short notice.
> >>
> >> Look, I'd like our discussions and decisions to be informed and
> >> considered, and there simply isn't time for either.
> >>
> >>>
> >>> Harald
> >>>
> >>> _______________________________________________
> >>> rtcweb mailing list
> >>> rtcweb@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/rtcweb
> >>
> >> David Singer
> >> Multimedia and Software Standards, Apple Inc.
> >>
> >> _______________________________________________
> >> rtcweb mailing list
> >> rtcweb@ietf.org
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> >
>
> ---
> Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49
> 89 978980 02 || cell +491725702667 || http://www.nomor-research.com
> Nomor Research GmbH  -  Sitz der Gesellschaft: M=FCnchen - Registergerich=
t:
> M=FCnchen, HRB 165856 - Umsatzsteuer-ID: DE238047637 - Gesch=E4ftsf=FChre=
r:
> Dr. Thomas Stockhammer, Dr. Ingo Viering.
>
>
>
> _______________________________________________
> 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


--_000_8BA7D4CEACFFE04BA2D902BF11719A8331B19D77nasanexd02fnaqu_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Surely it is not.


 <=
/p>

Note that the context her=
e is on the MTI codec discussion in IETF, not at all the context the POSSIB=
LE standardization of VP8 in MPEG (which, if to happen,
 would most likely be subject to more development taking the current VP8 as=
 the basis rather than rubberstamping as is).


 <=
/p>

BR, YK<=
/p>

 <=
/p>







From:=
 rtcweb-bounces@ietf=
.org [mailto:rtcweb-bounces@ietf.org]
On Behalf Of Rob Glidden

Sent: Thursday, March 14, 2013 8:48 AM

To: Wang, Ye-Kui; rtcweb@ietf.org

Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot=







 




Sure it is, there's an open MPEG meeting resolution =
on the MPEG VP8 proposal to that effect, apparently even National Body comm=
ent.



Rob



On 3/13/2013 9:36 PM, Wang, Ye-Kui wrote:








Sure - but that is clearly not the context here.



Sent from my iPhone








On Mar 13, 2013, at 17:24, "Gerard Fernando" <gerardmxf@yahoo.co.uk> wrote:











Hello YK,






 




The disclosure process in MPEG is not based on=
 who you are, or on your Business model.



Kind regards



Gerard



















From: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>

To: Stockhammer Thomas <s=
tockhammer@nomor.de>; Bo Burman <bo.burman@ericsson.com>


Cc: "rtcweb@ietf.org&quo=
t; <rtcweb@ietf.org>


Sent: Wednesday, 13 March 2013, 10:40

Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot=







> >  How many others who did not respond to MPEG LA's call but h=
ave IPR 

> > are

> there?

> 

> [TS]  Just one more hypothesis: If I would have, what would be my=
 

> obligation/motivation to do so now?



Speaking of the motivation part; that would depend on who YOU are and what =
kind of business model or plan YOU have in mind.




BR, YK



> -----Original Message-----

> From: rtcweb-bounces@ietf.o=
rg [mailto:rtcweb-bounces@ie=
tf.org] On Behalf

> Of Stockhammer Thomas

> Sent: Wednesday, March 13, 2013 7:53 AM

> To: Bo Burman

> Cc: rtcweb@ietf.org

> Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
> 

> 

> >  How many others who did not respond to MPEG LA's call but h=
ave IPR are

> there?

> 

> [TS]  Just one more hypothesis: If I would have, what would be my=


> obligation/motivation to do so now?

> 

> >>>

> >>> We appreciate the need to have time to evaluate the speci=
fic words

> >>> of the license statements that are forthcoming, and the n=
eed for the

> >>> people who haven't made their IPR declarations over the l=
ast couple

> >>> of years of discussion to do so within the next couple of=
 weeks -

> >>> but we do think that it is important to use the face to f=
ace time

> >>> that we have here in Orlando to lay to rest any *other* i=
ssues than

> >>> the licensing terms and other issues derived from Google'=
s

> announcement.

> >>

> >> I am not sure we can have a reasoned consideration of 'other =
issues

> derived'

> >> at such short notice.

> >>

> >> Look, I'd like our discussions and decisions to be informed a=
nd

> >> considered, and there simply isn't time for either.

> >>

> >>>

> >>> Harald

> >>>

> >>> _______________________________________________

> >>> rtcweb mailing list

> >>> rtcweb@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/rtcweb

> >>

> >> David Singer

> >> Multimedia and Software Standards, Apple Inc.

> >>

> >> _______________________________________________

> >> rtcweb mailing list

> >> rtcweb@ietf.org

> >> https://www.ietf.org/mailman/listinfo/rtcweb

> >

> 

> ---

> Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49

> 89 978980 02 || cell +491725702667 || 
http://www.nomor-research.com

> Nomor Research GmbH  -  Sitz der Gesellschaft: M=FCnchen - R=
egistergericht:

> M=FCnchen, HRB 165856 - Umsatzsteuer-ID: DE238047637 - Gesch=E4ftsf=FC=
hrer:

> Dr. Thomas Stockhammer, Dr. Ingo Viering.

> 

> 

> 

> _______________________________________________

> 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.o=
rg/mailman/listinfo/rtcweb















_______________________________________________


rtcweb mailing list


rtcweb@ietf.org

https://www.i=
etf.org/mailman/listinfo/rtcweb




 








--_000_8BA7D4CEACFFE04BA2D902BF11719A8331B19D77nasanexd02fnaqu_--

From btv1==7857ef4b335==HKaplan@acmepacket.com  Thu Mar 14 12:23: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 91BE711E812A for ; Thu, 14 Mar 2013 12:23:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.466
X-Spam-Level: 
X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133,  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 yDt7n2upYKfK for ; Thu, 14 Mar 2013 12:23:42 -0700 (PDT)
Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFA811E80F2 for ; Thu, 14 Mar 2013 12:23:42 -0700 (PDT)
X-ASG-Debug-ID: 1363289013-03fc200f265c39d0001-4f8tJD
Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx1.acmepacket.com with ESMTP id 081VGN0AqxJEdvPP (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Mar 2013 15:23:33 -0400 (EDT)
X-Barracuda-Envelope-From: HKaplan@acmepacket.com
Received: from MAIL2.acmepacket.com ([169.254.2.222]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Thu, 14 Mar 2013 15:23:33 -0400
From: Hadriel Kaplan 
To: Suhas Nandakumar 
Thread-Topic: [rtcweb] Video Codec MTI & User Experience == 1
X-ASG-Orig-Subj: Re: [rtcweb] Video Codec MTI & User Experience == 1
Thread-Index: AQHOIOlqOBwpPfyVPU2s5T4qQkHCPA==
Date: Thu, 14 Mar 2013 19:23:33 +0000
Message-ID: <7EE4B84B-FEDE-4878-A21A-9CB8968E62D5@acmepacket.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <9A282570229FF145875A36C437227328@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21]
X-Barracuda-Start-Time: 1363289013
X-Barracuda-Encrypted: AES128-SHA
X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at acmepacket.com
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.125204 Rule breakdown below pts rule name              description ---- ---------------------- --------------------------------------------------
Cc: "" 
Subject: Re: [rtcweb] Video Codec MTI & User Experience == 1
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 19:23:44 -0000

On Mar 14, 2013, at 1:59 PM, Suhas Nandakumar  wrote:

>  I feel a good user experience is as important as MTI being successfully =
negotiated. Users will turn off their video and de-escalate to audio only i=
nteraction if they look terribly bad in any kind of use-cases dealt within =
RTCWeb.=20

Yes, but that's the point - a *user* can choose to do it.  And a user can c=
hoose to instead live with whatever crappy video they can get.  The great t=
hing is it would be the user's choice.  But if we don't pick at least one M=
TI, no matter how good or bad it is, then the user won't have that choice..=
. because there will be no video if the two ends don't happen to implement =
the same one.

And I'm not saying that with respect to either VP8 or H.264 - as far as I c=
an tell neither of them can be an MTI codec right now, since we've been tol=
d each group of vendors can't live with the other's codec.


> We should be avoiding this at any cause since it defeats the purpose of R=
TCWeb to enable rich interactions via audio, video.

Define "rich interactions".  Obviously choosing an MTI codec that provides =
4-pixel video would be a waste of our time.  But is H.261 sufficient to 'ri=
chly' communicate?  If I communicate with my wife/kids/siblings while I'm t=
raveling, of course I'd prefer it be great quality video, but I can live wi=
th H.261.  What I won't put up with is having my browser decide the video's=
 "not good enough for me", or having to make us all use the same browser ve=
ndor. (we don't)

Just my 2 cents.

-hadriel


From ben@vline.me  Thu Mar 14 12:45: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 2060611E821C for ; Thu, 14 Mar 2013 12:45:08 -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 0BS8luh+GNcm for ; Thu, 14 Mar 2013 12:45:07 -0700 (PDT)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 08B8A11E8166 for ; Thu, 14 Mar 2013 12:45:06 -0700 (PDT)
Received: by mail-wi0-f169.google.com with SMTP id l13so4572344wie.0 for ; Thu, 14 Mar 2013 12:44:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=bdWHOBlOFuBV+bf42ZaQ2JiYdP8Ypu440IewFxWR4+I=; b=oYFkNqfgcZFrY/lepjOl3hChN1Sm19VrC8Wd1nIrORkAgbjGFxb7ueA3HRFsX8bsJX SZCfCn5tBWjYs8hGTTr3DD9PaxhT8mh+C0zeoxGEj7oGdcgkClHKdHTPi4m6hULFha1L zX+i0RzKHZ+lSD/7ZuO6znSEwXIdm5JGgdkWpSqYOb40tTW5pIDCiPAFGFczCFVjqZQ/ Edv7scx+Pm0jC1mm/a2RKznV4FxbwAkmiTvCm5qJomRocwPOBc8M5MoDP4QbeAO1J7dD oyE4a1QTn++1jzFSiPBLNVnI0JHjH1nLtLrBU3WcaUYpJ8UZlV3IN/Kl0VFE8ShghfFs g41A==
MIME-Version: 1.0
X-Received: by 10.180.97.132 with SMTP id ea4mr6445730wib.23.1363290295916; Thu, 14 Mar 2013 12:44:55 -0700 (PDT)
Sender: ben@vline.me
Received: by 10.227.8.226 with HTTP; Thu, 14 Mar 2013 12:44:55 -0700 (PDT)
In-Reply-To: 
References:    
Date: Thu, 14 Mar 2013 14:44:55 -0500
X-Google-Sender-Auth: hZWBWx8JjHYlD2Ap1bHbjaZ-l3E
Message-ID: 
From: Ben Strong 
To: Monty Montgomery 
Content-Type: multipart/alternative; boundary=f46d04426c4ed06d9c04d7e7c12b
X-Gm-Message-State: ALoCoQlh7kBrkUr8PrvptxTk0MrIUdcgoUC3G6kvV3+owtOMKvcG6ZL1+9XqAcsSM1N+tI6HbYyM
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] A different perspective on the video codec MTI 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: Thu, 14 Mar 2013 19:45:08 -0000

--f46d04426c4ed06d9c04d7e7c12b
Content-Type: text/plain; charset=ISO-8859-1

> It's clear by inference that Ben was speaking of fully FOSS software.
>

Thanks for clarifying. That's what I should have said. Let me try to say
the whole thing more briefly:

Choosing H.264 means that there will be no standards-compliant FOSS
implementations. So to any argument for H.264, you can tack on "which is
more important that having FOSS implementations".

Real developers (at least the ones I talk to) care a lot about the
practical interoperability problems this will cause. They care _more_ about
this than they care about most of the other arguments that come up. And
they are much more concerned about interoperability among browsers than
between browsers and legacy equipment.

Ben

--f46d04426c4ed06d9c04d7e7c12b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



=



It's clear by inference that Ben was speaking of fully FOSS software.

Thanks for clarifying. That's what I=
 should have said. Let me try to say the whole thing more briefly:



Choosing H.264 means that there will be no standa=
rds-compliant FOSS implementations. So to any argument for H.264, you can t=
ack on "which is more important that having FOSS implementations"=
.=A0



Real developers (at least the ones I talk t=
o) care a lot about the practical interoperability problems this will cause=
. They care _more_ about this than they care about most of the other argume=
nts that come up. And they are much more concerned about interoperability a=
mong browsers than between browsers and legacy equipment.



Ben


--f46d04426c4ed06d9c04d7e7c12b--

From mark.weidick@tenhands.net  Thu Mar 14 13:11: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 1A47611E815E for ; Thu, 14 Mar 2013 13:11:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.202
X-Spam-Level: 
X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 3uDUKfVa6Gl9 for ; Thu, 14 Mar 2013 13:11:39 -0700 (PDT)
Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by ietfa.amsl.com (Postfix) with ESMTP id 6CADA11E81B5 for ; Thu, 14 Mar 2013 13:11:39 -0700 (PDT)
Received: by mail-pb0-f53.google.com with SMTP id un1so2728316pbc.12 for ; Thu, 14 Mar 2013 13:11:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:user-agent:date:subject:from:to:message-id:thread-topic :in-reply-to:mime-version:content-type:x-gm-message-state; bh=JP1+3iCRRa5Kbl/PgSHRg90xUm8k9BxCkqlinEqdKGE=; b=TakcNEBchS4S01u0p4oB16JlSo4CcQxsHKK5s6VOkYUgmyMLS0lGVxg7ckESJFrvJ9 lrv3ayDFtllD3T8766Ap56wCEa8TUYgRK3NoZDqtjQ5OqWsuyUDQFDiDLrdVoNIrFsvC ld1FmmxaQ4rVkd1n3TzS5sR9uRqnkwx5pCdn3kwfaK3Yqwf/Cf10jhnPSicu3b6J8b0E 4pwUJK/87Q9KFYLi8uHaaUcwGAyc96DSB0ox6LjCQjHjdAJVkwiVl9+ZHQkAFeagXVWS a2qOCIyWd2tIHTkcpIbNIt0qq8hPWc3ehiAZWtdGWDQxdCfMSQu+zUwZQIWSJVpfl/uF 03tw==
X-Received: by 10.68.171.99 with SMTP id at3mr8969238pbc.136.1363291898940; Thu, 14 Mar 2013 13:11:38 -0700 (PDT)
Received: from [192.168.1.12] ([67.21.4.204]) by mx.google.com with ESMTPS id eg1sm4738493pbb.33.2013.03.14.13.11.32 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 14 Mar 2013 13:11:37 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.12.0.110505
Date: Thu, 14 Mar 2013 13:11:28 -0800
From: Mark Weidick 
To: "rtcweb@ietf.org" 
Message-ID: 
Thread-Topic: [rtcweb] A different perspective on the video codec MTI discussion
In-Reply-To: 
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3446111493_173583095"
X-Gm-Message-State: ALoCoQmcqJPVQWIp6i1YnYkp6dSjGOhYottfoE7Hr1aKmwTGEgg7KFUP3UHkRa33u29MyII54Ws5
Subject: Re: [rtcweb] A different perspective on the video codec MTI 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: Thu, 14 Mar 2013 20:11:46 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3446111493_173583095
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

+1
Ben has this right based on our in market experience to make a commercially
viable service based on WebRTC - and we can corroborate his analysis with
real data. =20

We have more than 1,000 businesses using our reference application and
dozens of companies have used our APIs to embed WebRTC based video within
their applications.  They care most about 1) working in the browser of thei=
r
choice, so cross-browser interop in Ben's words, 2) mobile and 3) cost.

Based on our real world interaction and across each of the use cases that
Ben highlights, interop with legacy endpoints isn't even on the radar.  In
fact, with increasing frequency we encounter video "room systems" that
consist of a flat panel display, a webcam, a PC/Mac and a browser that can
run a WebRTC app.  The so-called legacy endpoints seem to be going to zero
in terms of relevancy.

Mark

From:  Ben Strong 
Date:  Thu, 14 Mar 2013 11:24:36 -0500
To:  "rtcweb@ietf.org" 
Subject:  Re: [rtcweb] A different perspective on the video codec MTI
discussion

I've been talking to developers who are interested in building WebRTC apps
regularly for the past year and have drawn the opposite conclusion about
their preferences.

Before going into what they want and why, let me give you a flavor of who
I'm talking to: These are primarily inbound contacts who are interested in
the vLine WebRTC platform. I think they're pretty representative of the
non-legacy use-cases for WebRTC, but almost certainly under-represent the
existing enterprise market.

* Over half are building apps for healthcare or education. I'd say it's a
pretty even split between those categories, and within each category it's a
pretty even split between startups and more established organizations.
Non-profits make up a substantial fraction of both groups.

* Over half are outside the US, with most of the international interest
coming from developing countries (e.g., India, Brazil, and China).

* Not one of them has been interested in enabling video for customer servic=
e
calls (though a number have been interested in voice). I mention this
because it's frequently cited as an important use-case and I expected it to
be an important market for us, but I'm beginning to wonder if businesses
actually want this. I'll admit that those who _are_ interested are more
likely to be talking to Jonathan than to me, so take this with a grain of
salt.

* A sampling of other apps people are building: translation services (both
for foreign languages and sign language), social commerce services, and
social apps with all sorts of interesting new interaction models.

Here's what I've heard from them:

* The only questions I have ever gotten about interop with legacy equipment
are in regard to voice. I do occasionally talk to people with existing
investments in video conferencing systems, but they are mostly interested i=
n
moving away from them (huge sample bias here, of course).

* Very rarely does the subject of codecs come up other than the context of
whether the browsers will all interoperate. The only concerns I ever hear
about VP8 quality are from people who haven't actually used WebRTC in
Chrome. The feedback I get from people who have used it is consistently tha=
t
they are surprised by how good the video quality is.

* All of them care about having a good mobile experience and do occasionall=
y
express concerns about the battery life and performance impact of software
codecs.

* _Everyone_ is concerned about cross-browser interoperability. It is far
and away the biggest concern I hear about WebRTC, and I can't remember the
last time it didn't come up in a conversation with a customer.

Finally, here's my take on it all:

>From a power and performance point of view, H.264 is undoubtedly a better
option on devices with a hardware codec for it. Implementations on those
devices should by all means support it and attempt to negotiate it.
Implementations on other platforms where it is feasible to support it,
either because the implementation vendor has a license or the OS includes
it, should by all means support it as well, for the sake of allowing mobile
devices with a hardware codec to use it whenever possible.

I'm happy to grant that H.264 is technically superior to VP8 in every way
(though I think the differences are negligible in real-world use). By all
means implementations that wish to should attempt to negotiate it for that
reason, as well.

However, I fail to see how either one of those points has any bearing on th=
e
MTI decision. The whole point of MTI is guaranteed interoperability across
all WebRTC implementations, which is absolutely critical to WebRTC adoption=
.
The only criteria should be the best quality codec which can be supported b=
y
all implementations. And because some implementations are open source, it
absolutely must be royalty free.

I've already gone on too long here, but I want to make one final point on
open source. There are two new mobile platforms that have the potential to
drive innovation around mobile apps in general and the mobile web in
particular, and both are open source: FirefoxOS and Ubuntu Mobile. Neither
will be able to be WebRTC compatible unless a royalty-free codec is chosen.

I would argue that FirefoxOS and Ubuntu should be of special concern to the
working group for three reasons: 1) They support web apps as first class
citizens. Since the main goal of WebRTC is to make it possible to build ric=
h
apps entirely with web technologies, I would hope that the innovators in
that arena will be able to support it. 2) I expect that some of the areas
where WebRTC will have the biggest impact (e.g., telemedicine in rural
India) will be most concerned about using a low-cost, open source platform.
3) Even without every being market-share leaders, open source platforms ten=
d
to drive innovation across the whole market. The best example of this is ho=
w
Firefox kickstarted a decade of innovation in browsers and web apps. I have
high hopes that FirefoxOS will do the same.

Adopting a codec that will more firmly entrench legacy providers at the
expense of some of the most innovative new platforms out there seems like a
bad trade-off to me.

Ben

[this post will probably need moderator approval, so apologies if it shows
up after the conversation has moved on]

--
Ben Strong
ben@vline.com



On Wed, Mar 13, 2013 at 5:06 PM, Jonathan Rosenberg 
wrote:
> I=B9d like to put a different perspective on the video MTI discussion.
>=20
> Much of the discussion has been around video quality, IPR, and standardiz=
ation
> status. While those are all important factors, to me they are secondary t=
o the
> core question: how does the choice impact uptake of the webRTC APIs and
> protocols by developers who build applications ontop of it? In this regar=
d, I
> would like to suggest that, at this time, adoption of VP8 as MTI will slo=
w
> down adoption of webRTC by turning off developers that would otherwise em=
brace
> it if H.264 were selected.
>=20
> The reason is simple. For many application developers, what is interestin=
g
> about webRTC is NOT just browser to browser communications, but connectin=
g
> users in a browser to users elsewhere - on other devices, in other networ=
ks.
> After all, the vast majority of web application developers do not have th=
e
> luxury of a massive social graph, or the luxury of their users being park=
ed
> persistently on their website and thus able to receive an incoming call. =
Many
> websites that have customer support or service needs would love to be abl=
e to
> allow their users to have a video call with an agent. However, those agen=
ts
> are probably sitting on existing agent systems which are not web based, a=
nd
> it=B9s almost certainly true that they do not today support VP8, but rather
> H.264. Many developers would probably love to connect users on the web wi=
th
> users on mobile apps. Most mobile platforms today support H264 based hard=
ware
> acceleration for decode and sometimes encode, but not yet VP8. Developers=
 who
> want to build business communications clients will need to connect those =
users
> with other users in the business, who may be using videophones, PC client=
s,
> telepresence units or video room systems, the vast majority of which do n=
ot
> support VP8 today, but many of which do support H.264.
>=20
> The reality is =AD today=B9s Internet and IP communications systems are built=
 on
> H.264. And unless the developer cares only about living within the island=
 of
> the web browser =AD a VP8 based solution will simply not meet their
> requirements.
>=20
> This may not be true down the road. I applaud Google for working hard (an=
d
> spending much money no doubt) to secure an RF license for VP8 from these
> patent holders. I think they should continue pushing and promoting the
> technology because a  free, high quality video codec would be great for t=
he
> Internet. But today, it is not the video codec of the Internet. And, give=
n the
> relatively early days of video, I am sure there will be video codecs afte=
r
> VP8. Maybe H.265, maybe the new video codec being developed here at the I=
ETF.
> And once those codecs become more broadly implemented and available on th=
e
> endpoints that matter, we can revise our specs and mandate support for th=
em.
> But this is not about the web of five years from now, its about the web t=
oday.
> And if we mandate usage of a codec which is not widely implemented in all=
 the
> endpoints that matter (not just the browser), I fear that it will hold
> developers back from using webRTC and thus prevent us from ever having th=
e
> opportunity to add these video codecs in the future.
>=20
> =20
>=20
> And so =AD to the supporters of VP8 =AD I applaud your efforts and thank you =
for
> them. Please continue. And when the industry is ready, we can make VP8 MT=
I in
> the browser. But we are not there yet.  I ask you to please put the needs=
 of
> the developers ahead of your own, and do not hold back webRTC for the ben=
efit
> of your ideals around an RF and open source video codec. WebRTC is too
> important for that.
>=20
> I have one more thing to say - speaking now as a developer.
>=20
> As some of you may know, I recently returned to Cisco as CTO of the cloud
> collaboration group, which is responsible for Webex. Webex was one of the
> first services to do voice and video on the web, using plugins of course.=
 For
> our business, a key requirement is interoperability with other video syst=
ems
> in the Cisco portfolio, including our video clients and telepresence unit=
s.
> Those are all based on H.264. Consequently, much as I would like to avoid=
 the
> need for a plugin, the benefits of eliminating the plugin do not outweigh=
 the
> drawbacks of having to transcode from VP8 to H.264. If IETF selects VP8 a=
s the
> MTI codec, this will make it dramatically more difficult and expensive fo=
r us
> to use webRTC. If H.264 is the MIT codec, it will make it much easier for=
 us
> to use webRTC.=20
>=20
>=20
>=20
> Thx,
>=20
> Jonathan R.
> --=20
> Jonathan Rosenberg, Ph.D.
> jdrosen@jdrosen.net
> http://www.jdrosen.net
>=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


--B_3446111493_173583095
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable


+1
Ben h=
as this right based on our in market experience to make a commercially viabl=
e service based on WebRTC - and we can corroborate his analysis with real da=
ta.  

We have more than 1,000 businesses using=
 our reference application and dozens of companies have used our APIs to emb=
ed WebRTC based video within their applications.  They care most about =
1) working in the browser of their choice, so cross-browser interop in Ben's=
 words, 2) mobile and 3) cost.  

Based on our =
real world interaction and across each of the use cases that Ben highlights,=
 interop with legacy endpoints isn't even on the radar.  In fact, with =
increasing frequency we encounter video "room systems" that consist of a fla=
t panel display, a webcam, a PC/Mac and a browser that can run a WebRTC app.=
  The so-called legacy endpoints seem to be going to zero in terms of r=
elevancy.

Mark

From:  Ben Strong <ben@vline.com>
Date:  Thu, 14 Mar 2013 11:24:36 -0500
To:  "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject:  Re: [rtcweb] A different perspective on the video codec M=
TI discussion

I've been talking to de=
velopers who are interested in building WebRTC apps regularly for the past y=
ear and have drawn the opposite conclusion about their preferences.

=

Before going into what they want and why, let me give you a flavo=
r of who I'm talking to: These are primarily inbound contacts who are intere=
sted in the vLine WebRTC platform. I think they're pretty representative of =
the non-legacy use-cases for WebRTC, but almost certainly under-represent th=
e existing enterprise market.

* Over half are build=
ing apps for healthcare or education. I'd say it's a pretty even split betwe=
en those categories, and within each category it's a pretty even split betwe=
en startups and more established organizations. Non-profits make up a substa=
ntial fraction of both groups.

* Over half are outs=
ide the US, with most of the international interest coming from developing c=
ountries (e.g., India, Brazil, and China).

* N=
ot one of them has been interested in enabling video for customer service ca=
lls (though a number have been interested in voice). I mention this because =
it's frequently cited as an important use-case and I expected it to be an im=
portant market for us, but I'm beginning to wonder if businesses actually wa=
nt this. I'll admit that those who _are_ interested are more likely to be ta=
lking to Jonathan than to me, so take this with a grain of salt.
=


* A sampling of other apps people are building: translat=
ion services (both for foreign languages and sign language), social commerce=
 services, and social apps with all sorts of interesting new interaction mod=
els.

Here's what I've heard from them:
* The only questions I have ever gotten about interop with lega=
cy equipment are in regard to voice. I do occasionally talk to people w=
ith existing investments in video conferencing systems, but they are mostly =
interested in moving away from them (huge sample bias here, of course).

* Very rarely does the subject of codecs come up other =
than the context of whether the browsers will all interoperate. The only con=
cerns I ever hear about VP8 quality are from people who haven't actually use=
d WebRTC in Chrome. The feedback I get from people who have used it is consi=
stently that they are surprised by how good the video quality is.
=

* All of them care about having a good mobile experience and =
do occasionally express concerns about the battery life and perfor=
mance impact of software codecs.

* _Everyone_ i=
s concerned about cross-browser interoperability. It is far and away the big=
gest concern I hear about WebRTC, and I can't remember the last time it didn=
't come up in a conversation with a customer.

Final=
ly, here's my take on it all:

From a power and perf=
ormance point of view, H.264 is undoubtedly a better option on devices with =
a hardware codec for it. Implementations on those devices should by all mean=
s support it and attempt to negotiate it. Implementations on other platforms=
 where it is feasible to support it, either because the implementation vendo=
r has a license or the OS includes it, should by all means support it as wel=
l, for the sake of allowing mobile devices with a hardware codec to use it w=
henever possible.

I'm happy to grant that H.264 is =
technically superior to VP8 in every way (though I think the differences are=
 negligible in real-world use). By all means implementations that wish to sh=
ould attempt to negotiate it for that reason, as well.

<=
div>However, I fail to see how either one of those points has any bearing on=
 the MTI decision. The whole point of MTI is guaranteed interoperability acr=
oss all WebRTC implementations, which is absolutely critical to WebRTC adopt=
ion. The only criteria should be the best quality codec which can be support=
ed by all implementations. And because some implementations are open source,=
 it absolutely must be royalty free.

I've already g=
one on too long here, but I want to make one final point on open source. The=
re are two new mobile platforms that have the potential to drive innovation =
around mobile apps in general and the mobile web in particular, and both are=
 open source: FirefoxOS and Ubuntu Mobile. Neither will be able to be WebRTC=
 compatible unless a royalty-free codec is chosen.

=
I would argue that FirefoxOS and Ubuntu should be of special concern to the =
working group for three reasons: 1) They support web apps as first class cit=
izens. Since the main goal of WebRTC is to make it possible to build rich ap=
ps entirely with web technologies, I would hope that the innovators in that =
arena will be able to support it. 2) I expect that some of the areas where W=
ebRTC will have the biggest impact (e.g., telemedicine in rural India) will =
be most concerned about using a low-cost, open source platform. 3) Even with=
out every being market-share leaders, open source platforms tend to drive in=
novation across the whole market. The best example of this is how Firefox ki=
ckstarted a decade of innovation in browsers and web apps. I have high hopes=
 that FirefoxOS will do the same.

Adopting a codec =
that will more firmly entrench legacy providers at the expense of some of th=
e most innovative new platforms out there seems like a bad trade-off to me.<=
/div>

Ben

[this post will probab=
ly need moderator approval, so apologies if it shows up after the conversati=
on has moved on]

--
Ben Strong

<=
div class=3D"gmail_extra">

On Wed, Mar 13, 201=
3 at 5:06 PM, Jonathan Rosenberg <jdrosen@jdrosen.net> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex">
I’d like to =
put a different
perspective on the video MTI discussion.
Much o=
f the discussion has been
around video quality, IPR, and standardization status. While those are all
important factors, to me they are secondary to the core question: how does =
the
choice impact uptake of the webRTC APIs and protocols by developers who bui=
ld applications ontop of it? In this regard, I would like to suggest that, a=
t this
time, adoption of VP8 as MTI will slow down adoption of webRTC by
turning off developers that would otherwise embrace it if H.264 were select=
ed.
The reason is simple. For many
application developers, what is interesting about webRTC is NOT just browse=
r to
browser communications, but connecting users in a browser to users elsewher=
e - on other devices, in other networks.
After all, the vast majority of web application developers do not have the
luxury of a massive social graph, or the luxury of their users being parked=
persistently on their website and thus able to receive an incoming call. Ma=
ny websites
that have customer support or service needs would love to be able to allow
their users to have a video call with an agent. However, those agents are
probably sitting on existing agent systems which are not web based, and it&=
#8217;s
almost certainly true that they do not today support VP8, but rather H.264.=
Many developers would probably love to connect users on the web with users =
on
mobile apps. Most mobile platforms today support H264 based hardware accele=
ration
for decode and sometimes encode, but not yet VP8. Developers who want to bu=
ild
business communications clients will need to connect those users with other=
users in the business, who may be using videophones, PC clients, telepresen=
ce
units or video room systems, the vast majority of which do not support VP8
today, but many of which do support H.264.
The =
reality is – today’s Internet
and IP communications systems are built on H.264. And unless the developer
cares only about living within the island of the web browser – a VP8 =
based
solution will simply not meet their requirements.
This may not be true down the
road. I applaud Google for working hard (and spending much money no doubt) =
to
secure an RF license for VP8 from these patent holders. I think they should=
continue pushing and promoting the technology because a  free, high
quality video codec would be great for the Internet. But today, it is not t=
he
video codec of the Internet. And, given the relatively early days of video,=
 I
am sure there will be video codecs after VP8. Maybe H.265, maybe the new vi=
deo
codec being developed here at the IETF. And once those codecs become more
broadly implemented and available on the endpoints that matter, we can revi=
se
our specs and mandate support for them. But this is not about the web of fi=
ve
years from now, its about the web today. And if we mandate usage of a codec=
which is not widely implemented in all the endpoints that matter (not just =
the browser), I fear that it
will hold developers back from using webRTC and thus prevent us from ever h=
aving
the opportunity to add these video codecs in the future.
 
And so – to the supporter=
s of VP8
– I applaud your efforts and thank you for them. Please continue. And=
 when the
industry is ready, we can make VP8 MTI in the browser. But we are not there=
 yet.
 I ask you to please put the needs of the developers ahead of your own=
,
and do not hold back webRTC for the benefit of your ideals around an RF and=
open source video codec. WebRTC is too important for that.
I have one more thing to say - speaking now as a developer.
As some of you may know, I
recently returned to Cisco as CTO of the cloud collaboration group, which i=
s
responsible for Webex. Webex was one of the first services to do voice and
video on the web, using plugins of course. For our business, a key requirem=
ent
is interoperability with other video systems in the Cisco portfolio, includ=
ing
our video clients and telepresence units. Those are all based on H.264.
Consequently, much as I would like to avoid the need for a plugin, the bene=
fits
of eliminating the plugin do not outweigh the drawbacks of having to transc=
ode
from VP8 to H.264. If IETF selects VP8 as the MTI codec, this will make it =
dramatically more difficult and expensive for us to use webRTC. If H.264 is =
the MIT codec, it will make it much easier for us to use webRTC. 

Thx,
Jonathan R.
-- 
=


_______________________________________________

rtcweb mailing list
rtcweb@ietf.org=

h=
ttps://www.ietf.org/mailman/listinfo/rtcweb


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


--B_3446111493_173583095--



From koen.vos@skype.net  Thu Mar 14 13:32: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 8FBC311E8103 for ; Thu, 14 Mar 2013 13:32:50 -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 Xwx4S6BRfm5j for ; Thu, 14 Mar 2013 13:32:48 -0700 (PDT)
Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.93]) by ietfa.amsl.com (Postfix) with ESMTP id 65DEC11E80F2 for ; Thu, 14 Mar 2013 13:32:48 -0700 (PDT)
Received: from BLUSR01CA101.namsdf01.sdf.exchangelabs.com (10.255.124.146) by BLUSR01MB601.namsdf01.sdf.exchangelabs.com (10.255.124.166) with Microsoft SMTP Server (TLS) id 15.0.651.5; Thu, 14 Mar 2013 20:32:44 +0000
Received: from BY1FFOFD001.ffo.gbl (64.4.22.89) by BLUSR01CA101.outlook.office365.com (10.255.124.146) with Microsoft SMTP Server (TLS) id 15.0.658.2 via Frontend Transport; Thu, 14 Mar 2013 20:32:44 +0000
Received: from hybrid.exchange.microsoft.com (131.107.1.17) by BY1FFOFD001.mail.o365filtering.com (10.1.16.83) with Microsoft SMTP Server (TLS) id 15.0.651.3 via Frontend Transport; Thu, 14 Mar 2013 20:32:43 +0000
Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com (157.54.109.44) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.3.123.1; Thu, 14 Mar 2013 13:32:22 -0700
Received: from DFM-CO1MBX15-01.exchange.corp.microsoft.com (157.59.247.7) by DFM-TK5MBX15-05.exchange.corp.microsoft.com (157.54.109.44) with Microsoft SMTP Server (TLS) id 15.0.620.25; Thu, 14 Mar 2013 13:32:21 -0700
Received: from DFM-CO1MBX15-04.exchange.corp.microsoft.com (157.59.247.11) by DFM-CO1MBX15-01.exchange.corp.microsoft.com (157.59.247.7) with Microsoft SMTP Server (TLS) id 15.0.620.25; Thu, 14 Mar 2013 13:32:21 -0700
Received: from DFM-CO1MBX15-04.exchange.corp.microsoft.com ([157.59.247.11]) by DFM-CO1MBX15-04.exchange.corp.microsoft.com ([169.254.5.131]) with mapi id 15.00.0620.020; Thu, 14 Mar 2013 13:32:20 -0700
From: Koen Vos 
To: "Espen Berger (espeberg)" , "stephane.proust@orange.com" 
Thread-Topic: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOILCGfudZD3fORU+GZVQpFyRR25ilm5IA///wQ8E=
Date: Thu, 14 Mar 2013 20:32:20 +0000
Message-ID: 
References: <31611_1363212891_5140FA5B_31611_17197_1_35788a76-852d-49ce-8987-d2be2f21fcaf@PEXCVZYH02.corporate.adroot.infra.ftgroup>  <3246_1363214890_5141022A_3246_1976_1_34a49fde-fad7-4a0a-8b01-9d48a5b6eeab@PEXCVZYH01.corporate.adroot.infra.ftgroup> <51415833.1050503@mozilla.com> <12711_1363264558_5141C42E_12711_1015_1_44e82a49-a4d3-4020-b26c-df36435f3ac8@PEXCVZYH01.corporate.adroot.infra.ftgroup>, 
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.13]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.1.17; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(55784001)(199002)(54524001)(13464002)(60454001)(189002)(243025002)(38284002)(51704002)(24454001)(377454001)(479174001)(56816002)(5343655001)(31966008)(74502001)(876001)(23756002)(44976002)(4396001)(54316002)(69226001)(65816001)(49866001)(53806001)(46102001)(47736001)(5343645001)(5343635001)(79102001)(20776003)(47976001)(51856001)(54356001)(47776003)(63696002)(15202345002)(76482001)(16406001)(33646001)(66066001)(80022001)(561944001)(47446002)(50466001)(77982001)(74662001)(56776001)(50986001)(59766001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUSR01MB601; H:hybrid.exchange.microsoft.com; RD:mail1.exchange.microsoft.com; A:1; MX:1; LANG:en; 
X-Forefront-PRVS: 0785459C39
X-OriginatorOrg: msft.ccsctp.net
Cc: "rtcweb@ietf.org" , MARJOU Xavier OLNC/OLN 
Subject: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 20:32:50 -0000

> It's interop with billions of mobile phones and with fixed terminals in l=
egacy telephony services.=0A=
=0A=
The problem is that WebRTC and legacy services live in separate networks: t=
he open Web vs proprietary Telco networks.=0A=
=0A=
WebRTC connecting to a Telco network would have to go through a Gateway.  T=
he PSTN termination providers who run these Gateways support G.711, G.729 a=
nd perhaps some other  codecs like iLBC.  They do not, however, support the=
 codecs you are advocating for.=0A=
=0A=
The lack of support for Transcoding-Free Operation by Telcos to the rest of=
 the world has been hurting interop voice quality for a long time, but unfo=
rtunately we can't fix that here at the IETF.=0A=
=0A=
We can fit our cars with your costly railroad wheels, but you still wouldn'=
t let us on your tracks.=0A=
=0A=
koen.=0A=
=0A=
=0A=
-----Original Message-----=0A=
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 stephane.proust@orange.com=0A=
Sent: 14. mars 2013 13:36=0A=
To: Jean-Marc Valin=0A=
Cc: rtcweb@ietf.org; MARJOU Xavier OLNC/OLN=0A=
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01=0A=
=0A=
Hello=0A=
=0A=
The short list is aligned to what is specified in 3GPP (mobile) and CAT-iq =
(fixed). Check the related service specifications!=0A=
The short list (AMR, AMR-WB, G.722) is a minimal subset of codecs to minimi=
ze interop issues and transcoding costs for telco services.=0A=
It's not a question of what's the favourite codec for a given application. =
It's interop with billions of mobile phones and with fixed terminals in leg=
acy telephony services.=0A=
=0A=
St=E9phane=0A=
=0A=
-----Message d'origine-----=0A=
De : Jean-Marc Valin [mailto:jmvalin@mozilla.com] Envoy=E9 : jeudi 14 mars =
2013 05:55 =C0 : PROUST Stephane OLNC/OLPS Cc : Andrew Allen; Markus.Isomak=
i@nokia.com; MARJOU Xavier OLNC/OLN; rtcweb@ietf.org Objet : Re: [rtcweb] A=
genda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01=0A=
=0A=
-----BEGIN PGP SIGNED MESSAGE-----=0A=
Hash: SHA1=0A=
=0A=
On 03/13/2013 06:48 PM, stephane.proust@orange.com wrote:=0A=
> The reason is simply that AMR and AMR-WB are supported in billions of=0A=
> devices !=0A=
=0A=
Just curious, why exclude from the list other codecs with similar huge depl=
oyment? I can think of at least:=0A=
- - GSM-FR (mobile)=0A=
- - Speex (Flash)=0A=
- - G.729 (PSTN gateways)=0A=
- - iLBC (PSTN gateways)=0A=
- - G.726 (DECT)=0A=
- - SILK (original non-Opus version in Skype)=0A=
=0A=
(sorry, if I missed someone's favorite codec in this list)=0A=
=0A=
It's not at all clear to me what's so special that makes AMR, AMR-WB and G.=
722 different from the other codecs in the list above. Not that I insist on=
 shipping G.729 :-)=0A=
=0A=
Personally, I'd favor a draft that included a lot more codecs, describing f=
or each one the benefits of supporting it. Implementers could then choose w=
hich of these they care about for their particular situation.=0A=
=0A=
Cheers,=0A=
=0A=
        Jean-Marc=0A=
=0A=
> St=E9phane=0A=
>=0A=
>=0A=
> -----Message d'origine----- De : Andrew Allen=0A=
> [mailto:aallen@blackberry.com] Envoy=E9 : mercredi 13 mars 2013=0A=
> 23:41 =C0 : PROUST Stephane OLNC/OLPS; Markus.Isomaki@nokia.com;=0A=
> jmvalin@mozilla.com Cc : MARJOU Xavier OLNC/OLN; rtcweb@ietf.org Objet=0A=
> : Re: [rtcweb] Agenda time request for=0A=
> draft-marjou-rtcweb-audio-codecs-for-interop-01=0A=
>=0A=
>=0A=
> No this wouldn't be acceptable to me.=0A=
>=0A=
> I don't see a reason to push a particular set of Codecs over any other=0A=
> set of codecs supported on the device. If the device supports the=0A=
> codecs and they are available to the browser then we should recommend=0A=
> that they be offered in the negotiation.=0A=
>=0A=
> The marjou draft can advertise the merits and reasons why they are=0A=
> good codecs to support.=0A=
>=0A=
>=0A=
> ----- Original Message ----- From: stephane.proust@orange.com=0A=
> [mailto:stephane.proust@orange.com] Sent: Wednesday, March 13, 2013=0A=
> 05:14 PM Central Standard Time To: Markus.Isomaki@nokia.com=0A=
> ; jmvalin@mozilla.com =0A=
> Cc: MARJOU Xavier OLNC/OLN ; rtcweb@ietf.org=0A=
> =0A=
> Subject: Re: [rtcweb] Agenda time     request for=0A=
> draft-marjou-rtcweb-audio-codecs-for-interop-01=0A=
>=0A=
> Dear Markus=0A=
>=0A=
> Thanks for your attempt to help !=0A=
>=0A=
> Of course each Telco can handle this directly with vendors and=0A=
> browsers manufacturers at business level. But I don't'think this need=0A=
> of interoperability with mobile devices is specific to Orange.=0A=
> I think all mobile operators will have the same issue and this is why=0A=
> standardization exist. It's most cost and time efficient to have one=0A=
> common way forward for all the industry.=0A=
>=0A=
> Then if the issue is that "conditional MUST/SHOULD are a too=0A=
> complicated requirement. We could also live as a compromise with a=0A=
> formulation that has already been suggested on the reflector:=0A=
>=0A=
> "If other suitable audio codecs are available to the browser to use it=0A=
> is recommended that they are also included in the offer in order to=0A=
> maximize the possibility to establish the session without the need for=0A=
> audio transcoding" If possible with the addition of This is especially=0A=
> the case for AMR, AMR-WB for interoperability with mobile devices and=0A=
> G.722 for interoperability with fixed DECT CAT-iq devices=0A=
>=0A=
> Would it have one chance to reach consensus ?=0A=
>=0A=
> I think this Group should at least make one small step so that the=0A=
> interoperability issue with mobile terminals be not fully ignored in=0A=
> the RTC Web specification considering the huge number of deployed=0A=
> devices. At least something must be written on this !=0A=
> G.711 which is the only codec in addition to OPUS for interoperability=0A=
> purpose is not a proper answer to this.=0A=
>=0A=
> St=E9phane=0A=
>=0A=
> -----Message d'origine----- De : Markus.Isomaki@nokia.com=0A=
> [mailto:Markus.Isomaki@nokia.com] Envoy=E9 : mercredi 13 mars 2013=0A=
> 22:37 =C0 : PROUST Stephane OLNC/OLPS; jmvalin@mozilla.com; MARJOU=0A=
> Xavier OLNC/OLN Cc : rtcweb@ietf.org Objet : RE: [rtcweb] Agenda time=0A=
> request for draft-marjou-rtcweb-audio-codecs-for-interop-01=0A=
>=0A=
> Hi Stephane, Xavier,=0A=
>=0A=
> I understand the intent of your proposal. I'm not sure if the IETF is=0A=
> the best venue for you to pursue it, however. Perhaps you as a mobile=0A=
> operator should rather set it as a requirement to your mobile device=0A=
> platforms that they open up the APIs to AMR and AMR-WB and that at=0A=
> least the in-built default browser needs to support it. If there are=0A=
> enough operators setting such requirements directly to the device and=0A=
> platform vendors, it probably has a bigger impact than an IETF RFC.=0A=
> Getting that support for user-installed additional browsers might be=0A=
> more difficult, but most mobile device users stick with the default=0A=
> browser anyway.=0A=
>=0A=
> The RTCWEB codec document needs to definitely explain this case and=0A=
> the benefits, but the conditional MUSTs or SHOULDs you are proposing=0A=
> are perhaps a bit too complicated. Hmm, perhaps we need to do an=0A=
> _informational_ RFC as something like "Recommendations for WebRTC on=0A=
> Mobile Devices" addressing the codec and perhaps other issues, that=0A=
> you could use as a reference in your requirements.=0A=
>=0A=
> Markus=0A=
>=0A=
>=0A=
>> -----Original Message----- From: rtcweb-bounces@ietf.org=0A=
>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext=0A=
>> stephane.proust@orange.com Sent: 13 March, 2013 21:37 To:=0A=
>> Jean-Marc Valin; MARJOU Xavier OLNC/OLN Cc: rtcweb@ietf.org=0A=
>> Subject: Re: [rtcweb] Agenda time request for=0A=
>> draft-marjou-rtcweb-audio- codecs-for-interop-01=0A=
>>=0A=
>> Hello=0A=
>>=0A=
>> Our understanding is that the reason of the "no consensus" on=0A=
>> additional recommended codecs was the additional costs for browsers.=0A=
>> The proposal is then to make these "MUST" fully conditional to the=0A=
>> case of no (or very reduced) additional costs, when the codecs are=0A=
>> already available on the device and when no additional license fee is=0A=
>> required=0A=
>>=0A=
>> We could even live with lower level of "requirements" with=0A=
>> respectively May and Should (instead of Should and shall) but we=0A=
>> think that this proposal is a way to take into account both browser=0A=
>> manufacturers concerns on browsers costs and telcos concerns on=0A=
>> transcoding costs and some other companies share this view.=0A=
>>=0A=
>> St=E9phane=0A=
>>=0A=
>>=0A=
>>=0A=
>>=0A=
>>=0A=
>>=0A=
>> -----Message d'origine----- De : rtcweb-bounces@ietf.org=0A=
>> [mailto:rtcweb-bounces@ietf.org] De la part de Jean-Marc Valin Envoy=E9=
=0A=
>> : mercredi 13 mars 2013 20:24 =C0 : MARJOU Xavier OLNC/OLN Cc :=0A=
>> rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time request for=0A=
>> draft-marjou-rtcweb-audio-codecs-for-interop-01=0A=
>>=0A=
> Hi,=0A=
>=0A=
> I'd really like to understand how the chairs coming to the conclusion=0A=
> that there was *no consensus* on recommended codecs can result in a=0A=
> draft that includes 3 MUSTs and 1 SHOULD. This draft effectively makes=0A=
> 3 new codecs MTI for a range of devices. I understand that it's an=0A=
> individual draft and you can write whatever you like in there, but it=0A=
> definitely goes against the result of the WG discussion.=0A=
>=0A=
> Cheers,=0A=
>=0A=
> Jean-Marc=0A=
>=0A=
> On 03/13/2013 09:14 AM, Xavier Marjou wrote:=0A=
>>>> Here is a summary of the=0A=
>>>> draft-marjou-rtcweb-audio-codecs-for-interop-00 presentation that I=0A=
>>>> had prepared for yesterday's session:=0A=
>>>>=0A=
>>>> - The co-authors want to underline that non-WebRTC voice endpoints=0A=
>>>> usually use one of the following codecs: AMR, AMR-WB or G.722,=0A=
>>>> which will result in massive transcoding when there will be=0A=
>>>> communications between WebRTC endpoints and non-WebRTC endpoints.=0A=
>>>>=0A=
>>>> - On one side, transcoding is bad for many reasons discussed in the=0A=
>>>> draft (cost issues, intrinsic quality degradation, degraded=0A=
>>>> interactivity, fallback from HD to G.711...);=0A=
>>>>=0A=
>>>> - On the other side, it is recognized that implementing additional=0A=
>>>> codecs in the browsers can generate additional costs.=0A=
>>>>=0A=
>>>> - In order to reach a compromise, we would like to add some text in=0A=
>>>> the WG draft draft-ietf-rtcweb-audio providing incentives for the=0A=
>>>> browser to use these three codecs: make them mandatory to implement=0A=
>>>> when there is no cost impact on the browser (e.g. if codec already=0A=
>>>> installed, paid by the device vendor...).=0A=
>>>>=0A=
>>>> Any opinion on that?=0A=
>>>>=0A=
>>>> Cheers,=0A=
>>>>=0A=
>>>> Xavier=0A=
>>>>=0A=
>>>> PS: I will be ready to present the slides on Thursday if time=0A=
>>>> permits it.=0A=
>>>>=0A=
>>>> (c.f.=0A=
>>>> http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf=0A=
>>>>=0A=
>>>>=0A=
)=0A=
>>>>=0A=
>>>>=0A=
>>>>=0A=
>>>> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie >>> > wrote:=0A=
>>>>=0A=
>>>> Magnus and I discussed this this morning, and we encourage you to=0A=
>>>> prepare something.  If the discussion of working group last call=0A=
>>>> items runs short, we may be able to fit this in at that time or at=0A=
>>>> the end of day one if its full agenda his finished.  This is not a=0A=
>>>> commitment, however, so please try and get discussion on the list=0A=
>>>> on the points from the draft you feel need resolution.=0A=
>>>>=0A=
>>>> regards,=0A=
>>>>=0A=
>>>> Ted=0A=
>>>>=0A=
>>>>=0A=
>>>> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)=0A=
>>>> > wrote:=0A=
>>>>> Hello,=0A=
>>>>>=0A=
>>>>>=0A=
>>>>>=0A=
>>>>> I would like to request agenda time for:=0A=
>>>>>=0A=
>>>>>=0A=
>>>>>=0A=
>>>>> draft-marjou-rtcweb-audio-codecs-for-interop-01=0A=
>>>>>=0A=
>>>>>=0A=
>>>>>=0A=
>>>>> The document  presents use-cases underlining why WebRTC needs=0A=
>>>> AMR-WB,  AMR=0A=
>>>>> and G.722 as additional relevant voice codecs to satisfactorily=0A=
>>>>> ensure interoperability with existing systems.=0A=
>>>>>=0A=
>>>>>=0A=
>>>>>=0A=
>>>>> A 10-minute time slot should be sufficient for presentation and=0A=
>>>> discussion.=0A=
>>>>>=0A=
>>>>>=0A=
>>>>>=0A=
>>>>> Regards=0A=
>>>>>=0A=
>>>>>=0A=
>>>>>=0A=
>>>>> -Espen=0A=
>>>>>=0A=
>>>>>=0A=
>>>>>=0A=
>>>>>=0A=
>>>>>=0A=
>>>>>=0A=
>>>>> _______________________________________________ rtcweb=0A=
> mailing list=0A=
>>>>> rtcweb@ietf.org =0A=
>>>>> https://www.ietf.org/mailman/listinfo/rtcweb=0A=
>>>>>=0A=
>>>> _______________________________________________ rtcweb=0A=
> mailing list=0A=
>>>> rtcweb@ietf.org =0A=
>>>> https://www.ietf.org/mailman/listinfo/rtcweb=0A=
>>>>=0A=
>>>>=0A=
>>>>=0A=
>>>>=0A=
>>>> _______________________________________________ rtcweb=0A=
> mailing list=0A=
>>>> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb=0A=
>>>>=0A=
>=0A=
>> _______________________________________________ rtcweb mailing list=0A=
>> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb=0A=
>>=0A=
>> ___________________________________________________________=0A=
>> ___________________________________________________________ ___=0A=
>>=0A=
>> Ce message et ses pieces jointes peuvent contenir des informations=0A=
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=0A=
>> exploites ou copies sans autorisation. Si vous avez recu ce message=0A=
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=0A=
>> que les pieces jointes. Les messages electroniques etant susceptibles=0A=
>> d'alteration, France Telecom - Orange decline toute responsabilite si=0A=
>> ce message a ete altere, deforme ou falsifie. Merci.=0A=
>>=0A=
>> This message and its attachments may contain confidential or=0A=
>> privileged information that may be protected by law; they should not=0A=
>> be distributed, used or copied without authorisation. If you have=0A=
>> received this email in error, please notify the sender and delete=0A=
>> this message and its attachments. As emails may be altered, France=0A=
>> Telecom - Orange is not liable for messages that have been modified,=0A=
>> changed or falsified. Thank you.=0A=
>>=0A=
>> _______________________________________________ rtcweb mailing list=0A=
>> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb=0A=
>=0A=
> ______________________________________________________________________=0A=
> ___________________________________________________=0A=
>=0A=
>  Ce message et ses pieces jointes peuvent contenir des informations=0A=
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=0A=
> exploites ou copies sans autorisation. Si vous avez recu ce message=0A=
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=0A=
> que les pieces jointes. Les messages electroniques etant susceptibles=0A=
> d'alteration, France Telecom - Orange decline toute responsabilite si=0A=
> ce message a ete altere, deforme ou falsifie. Merci.=0A=
>=0A=
> This message and its attachments may contain confidential or=0A=
> privileged information that may be protected by law; they should not=0A=
> be distributed, used or copied without authorisation. If you have=0A=
> received this email in error, please notify the sender and delete this=0A=
> message and its attachments. As emails may be altered, France Telecom=0A=
> - Orange is not liable for messages that have been modified, changed=0A=
> or falsified. Thank you.=0A=
>=0A=
> _______________________________________________ rtcweb mailing list=0A=
> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb=0A=
>=0A=
> ---------------------------------------------------------------------=0A=
>=0A=
>=0A=
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.=0A=
>=0A=
> ______________________________________________________________________=0A=
> ___________________________________________________=0A=
>=0A=
>  Ce message et ses pieces jointes peuvent contenir des informations=0A=
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=0A=
> exploites ou copies sans autorisation. Si vous avez recu ce message=0A=
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=0A=
> que les pieces jointes. Les messages electroniques etant susceptibles=0A=
> d'alteration, France Telecom - Orange decline toute responsabilite si=0A=
> ce message a ete altere, deforme ou falsifie. Merci.=0A=
>=0A=
> This message and its attachments may contain confidential or=0A=
> privileged information that may be protected by law; they should not=0A=
> be distributed, used or copied without authorisation. If you have=0A=
> received this email in error, please notify the sender and delete this=0A=
> message and its attachments. As emails may be altered, France Telecom=0A=
> - Orange is not liable for messages that have been modified, changed=0A=
> or falsified. Thank you.=0A=
>=0A=
=0A=
-----BEGIN PGP SIGNATURE-----=0A=
Version: GnuPG v1.4.13 (GNU/Linux)=0A=
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/=0A=
=0A=
iQEcBAEBAgAGBQJRQVgzAAoJEJ6/8sItn9q9fgYH/jcWfhRrvPM1hJ22YcE7eR0N=0A=
OZzP/RvSrUBiIA6kG+6+Hvn5Lp/tXd+LxUDp5L8B3Toce7TBBAYNJP3M2cr8N8It=0A=
SjVvPHtBNKEqhBLbI4FbAouvymNH4utjAWR+MmF9LRySPXZ9nxLN0A13TeUlpZxt=0A=
Jaxr/n9AWwkKOk6BIo1Xztbk26MObiGVLhCE+CPoHaHe29bKblPcphBXC935ymHS=0A=
SuF2DXiAq0iKwZoVOsLe3RIaGg+bjN7N2MXi3Vphr7cOQK+JpdxURDrvmPh7/L8R=0A=
ht1RJt928yl4fEjnKhSKJLd1J+gPBe6vnkSxUp89as03bLirLwN1G2giD3YzfLM=3D=0A=
=3DK56v=0A=
-----END PGP SIGNATURE-----=0A=
=0A=
___________________________________________________________________________=
______________________________________________=0A=
=0A=
Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc=0A=
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler=0A=
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,=0A=
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.=0A=
=0A=
This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;=0A=
they should not be distributed, used or copied without authorisation.=0A=
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.=0A=
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.=0A=
Thank you.=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=

From roman@telurix.com  Thu Mar 14 13:42: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 4BC4011E80F2 for ; Thu, 14 Mar 2013 13:42:00 -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 rQ2xH2LXJLrn for ; Thu, 14 Mar 2013 13:41:59 -0700 (PDT)
Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2BC11E80D9 for ; Thu, 14 Mar 2013 13:41:59 -0700 (PDT)
Received: by mail-we0-f181.google.com with SMTP id t44so2568772wey.40 for ; Thu, 14 Mar 2013 13:41:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=isdyHsjdB4cQGtZzVLa3wdTpEzJyyOH1dhMUp80iMzs=; b=UtbOJ2L52hauTaXvCc7ALmLmUSxi5bKIKoRmj6BtoiKJXjRan5EuvR2cBrshObawew V56fbugf4bN0lajkKPJInlv2SUH45vyHDdHnA0ML4w570+OsJDGLzNLMlcU5RWexSClN jwIDCogzeT0yubbXVYt41EAIm13uOpBO9HwBSPwAa4pNQ02P+Yo5ApBk9pVXtkx3E1HS aG3rAKCulrVCHDMlr7J/uC7cl+plF7GWVlMizD7aI8L69qUPh8mlyv3ZDMzZSZAXYy9G 0Eve3hGze2Zrs/QubIS1JQVais9Jm4Fv1mD9d3RDL9/SRqfAh6eDjdGep/wccE6NO3gc Xy6w==
X-Received: by 10.194.123.130 with SMTP id ma2mr6821258wjb.46.1363293718369; Thu, 14 Mar 2013 13:41:58 -0700 (PDT)
Received: from mail-wi0-x231.google.com ([2a00:1450:400c:c05::231]) by mx.google.com with ESMTPS id fx5sm6422009wib.11.2013.03.14.13.41.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 13:41:57 -0700 (PDT)
Received: by mail-wi0-f177.google.com with SMTP id hm14so2228128wib.4 for ; Thu, 14 Mar 2013 13:41:56 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.21.233 with SMTP id y9mr6872244wje.47.1363293716160; Thu, 14 Mar 2013 13:41:56 -0700 (PDT)
Received: by 10.217.107.135 with HTTP; Thu, 14 Mar 2013 13:41:55 -0700 (PDT)
In-Reply-To: 
References: <31611_1363212891_5140FA5B_31611_17197_1_35788a76-852d-49ce-8987-d2be2f21fcaf@PEXCVZYH02.corporate.adroot.infra.ftgroup>  <3246_1363214890_5141022A_3246_1976_1_34a49fde-fad7-4a0a-8b01-9d48a5b6eeab@PEXCVZYH01.corporate.adroot.infra.ftgroup> <51415833.1050503@mozilla.com> <12711_1363264558_5141C42E_12711_1015_1_44e82a49-a4d3-4020-b26c-df36435f3ac8@PEXCVZYH01.corporate.adroot.infra.ftgroup>  
Date: Thu, 14 Mar 2013 16:41:55 -0400
Message-ID: 
From: Roman Shpount 
To: Koen Vos 
Content-Type: multipart/alternative; boundary=047d7b5d2774ad2ad104d7e88d40
X-Gm-Message-State: ALoCoQkdGThU46v5ju/r+FDHbpgPiMDsQnzu2C8q+A0ljgMQ+15RHmoVTYW8zaI/mxBSu0tzPJOT
Cc: MARJOU Xavier OLNC/OLN , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 20:42:00 -0000

--047d7b5d2774ad2ad104d7e88d40
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Mar 14, 2013 at 4:32 PM, Koen Vos  wrote:

> WebRTC connecting to a Telco network would have to go through a Gateway.
>  The PSTN termination providers who run these Gateways support G.711, G.729
> and perhaps some other  codecs like iLBC.  They do not, however, support
> the codecs you are advocating for.
>
> The lack of support for Transcoding-Free Operation by Telcos to the rest
> of the world has been hurting interop voice quality for a long time, but
> unfortunately we can't fix that here at the IETF.
>
> We can fit our cars with your costly railroad wheels, but you still
> wouldn't let us on your tracks.
>
>
I would got to agree with you regarding cell phone operators, since we've
been trying to get access to native AMR-WB for years.

On the other hand, this is kind of interesting to hear coming from someone
from Skype, which does not allow connections using SILK from outside of
their own network, which has been hurting interop voice quality for a long
time as well.

Finally, it is possible to connect to almost any hosted PBX provider, as
well as quite a few premise based PBXs, using G.722, as long as their end
points support it.
_____________
Roman Shpount

--047d7b5d2774ad2ad104d7e88d40
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Thu, Mar 14, 2013 at 4:32 PM, =
Koen Vos <koen.vos@skype.net> wrote:


WebRTC connecting to a Telco network would have to go thr=
ough a Gateway. =A0The PSTN termination providers who run these Gateways su=
pport G.711, G.729 and perhaps some other =A0codecs like iLBC. =A0They do n=
ot, however, support the codecs you are advocating for.




The lack of support for Transcoding-Free Operation by Telcos to the rest of=
 the world has been hurting interop voice quality for a long time, but unfo=
rtunately we can't fix that here at the IETF.



We can fit our cars with your costly railroad wheels, but you still wouldn&=
#39;t let us on your tracks.



I would got to agree with you regarding cell phone o=
perators, since we've been trying to get access to native AMR-WB for ye=
ars.



On the other hand, this is kind of interesting to hear=
=A0coming=A0from someone from Skype, which does not allow connections using=
 SILK from outside of their own network, which has been hurting interop voi=
ce quality for a long time as well.



Finally, it is possible to connect to almost any hosted=
 PBX provider, as well as quite a few premise based PBXs, using G.722, as l=
ong as their end points support it.
_____________
Roman Shpoun=
t


=A0


--047d7b5d2774ad2ad104d7e88d40--

From sergio.garcia.murillo@gmail.com  Thu Mar 14 13:43: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 78EA821F8460 for ; Thu, 14 Mar 2013 13:43:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.716
X-Spam-Level: 
X-Spam-Status: No, score=-0.716 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, 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 up501RebWj1X for ; Thu, 14 Mar 2013 13:43:45 -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 5D7D921F90D6 for ; Thu, 14 Mar 2013 13:43:45 -0700 (PDT)
Received: by mail-wi0-f179.google.com with SMTP id ez12so2225944wid.6 for ; Thu, 14 Mar 2013 13:43:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type; bh=jokOwYaZtrwsUjgLY1bcPnuhi0lXuqOQmha24td+XAw=; b=ZMdNK+XeOZaHCrh+uCYLJCvEPkkZ7QIBCiycQkaTwrSsd5iT1K4TSULH95B01+LLVN 2qdQUQDDHkaf1ydCvsu9p5Xfz5nFas/uDyi7CC6xKPqwkCS2hCmk6Ghl9DKyu19swUDn eDP6suaQ452a9sMT4NoTRjJETefB3z3LUzgmPtpfuD+s9xoaHNRec2JqL2AS60NjQEcY X+4Ek5sx+j0hqk2yk5hAYIgASremQ1u9r5EoYbuKJRMMMr4Vyj53ng+5PSZdPe/Vijo5 CEHqluBVytS8JTm8sabfJ4y+6txIzD3vdoNKnLkYLs+dBe/0DcLLspzG2O9ytfDBNI4b 2WYQ==
X-Received: by 10.180.77.9 with SMTP id o9mr36910546wiw.16.1363293824269; Thu, 14 Mar 2013 13:43:44 -0700 (PDT)
Received: from [192.168.1.2] (114.pool80-103-142.dynamic.orange.es. [80.103.142.114]) by mx.google.com with ESMTPS id j4sm11221769wiz.10.2013.03.14.13.43.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 13:43:43 -0700 (PDT)
Message-ID: <5142367D.5010800@gmail.com>
Date: Thu, 14 Mar 2013 21:43:41 +0100
From: Sergio Garcia Murillo 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: rtcweb@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040406010802070404090409"
Subject: Re: [rtcweb] Cross-check of Google VP8 vs H.264 comparison
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 20:43:46 -0000

This is a multi-part message in MIME format.
--------------040406010802070404090409
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

I also cross-posted the x264 encoding parameters used in the comparison 
in the x264-devel list:

http://mailman.videolan.org/pipermail/x264-devel/2013-March/009920.html

>/  What would be the best encoding parameters for x264 in these scenario?
/
1.  Set the slowest preset you're willing to tolerate.
2.  Set --tune to psnr or ssim (based on the one you're testing).
3.  Since they're doing CBR streaming for WebRTC, they need to set
appropriate ratecontrol settings.  Some examples:
1 second of latency: --vbv-maxrate $b --vbv-bufsize $b
0.25 seconds of latency: --vbv-maxrate $b --vbv-bufsize $b/4
low latency streaming with capped frame size: --vbv-maxrate $b
--vbv-bufsize $b/fps

In addition, if they care about latency, they'd want to make sure both
encoders are set with appropriate low-latency settings.  They'd also
need to verify how well both encoders are abiding by these


Best regards
Sergio

El 14/03/2013 19:13, Bo Burman escribió:
> Hi,
>
> As said on the microphone today, we have cross-checked Google's VP8 vs H.264 comparison. Google reported bit rate gains for VP8 of 19%. However, the H.264 was at an unfair advantage due to the fact that the --tune psnr flag was not used in x264. This should of course be used when doing psnr-measurements. For vp8, this flag is set to psnr by default.
>
> When re-running the tests with --tune psnr for x264, and using version 130 of x264 instead of version 128 that was used in the Google test, the difference disappeared (1% difference).
>
> Cheers,
> Bo
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--------------040406010802070404090409
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Hi,

      

      I also cross-posted the x264 encoding parameters used in the
      comparison in the x264-devel list:

      

      http://mailman.videolan.org/pipermail/x264-devel/2013-March/009920.html

      

      
> What would be the best encoding parameters for x264 in these scenario?

1.  Set the slowest preset you're willing to tolerate.
2.  Set --tune to psnr or ssim (based on the one you're testing).
3.  Since they're doing CBR streaming for WebRTC, they need to set
appropriate ratecontrol settings.  Some examples:
1 second of latency: --vbv-maxrate $b --vbv-bufsize $b
0.25 seconds of latency: --vbv-maxrate $b --vbv-bufsize $b/4
low latency streaming with capped frame size: --vbv-maxrate $b
--vbv-bufsize $b/fps

In addition, if they care about latency, they'd want to make sure both
encoders are set with appropriate low-latency settings.  They'd also
need to verify how well both encoders are abiding by these

      

      Best regards

      Sergio

      

      El 14/03/2013 19:13, Bo Burman escribió:

    

    

      
Hi,

As said on the microphone today, we have cross-checked Google's VP8 vs H.264 comparison. Google reported bit rate gains for VP8 of 19%. However, the H.264 was at an unfair advantage due to the fact that the --tune psnr flag was not used in x264. This should of course be used when doing psnr-measurements. For vp8, this flag is set to psnr by default. 

When re-running the tests with --tune psnr for x264, and using version 130 of x264 instead of version 128 that was used in the Google test, the difference disappeared (1% difference). 

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


    

    

  


--------------040406010802070404090409--

From koen.vos@skype.net  Thu Mar 14 13:57: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 14CD411E81F4 for ; Thu, 14 Mar 2013 13:57:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.441
X-Spam-Level: 
X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k41BMhbzR20i for ; Thu, 14 Mar 2013 13:57:40 -0700 (PDT)
Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.90]) by ietfa.amsl.com (Postfix) with ESMTP id 4E96911E81F0 for ; Thu, 14 Mar 2013 13:57:40 -0700 (PDT)
Received: from CH1SR01CA103.namsdf01.sdf.exchangelabs.com (10.255.157.20) by BY2SR01MB609.namsdf01.sdf.exchangelabs.com (10.255.93.168) with Microsoft SMTP Server (TLS) id 15.0.651.5; Thu, 14 Mar 2013 20:57:38 +0000
Received: from BY1FFOFD003.ffo.gbl (64.4.22.87) by CH1SR01CA103.outlook.office365.com (10.255.157.20) with Microsoft SMTP Server (TLS) id 15.0.658.2 via Frontend Transport; Thu, 14 Mar 2013 20:57:37 +0000
Received: from hybrid.exchange.microsoft.com (131.107.1.27) by BY1FFOFD003.mail.o365filtering.com (10.1.16.90) with Microsoft SMTP Server (TLS) id 15.0.651.3 via Frontend Transport; Thu, 14 Mar 2013 20:57:37 +0000
Received: from DFM-TK5MBX15-07.exchange.corp.microsoft.com (157.54.109.46) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.3.123.1; Thu, 14 Mar 2013 13:57:13 -0700
Received: from DFM-CO1MBX15-02.exchange.corp.microsoft.com (157.59.247.79) by DFM-TK5MBX15-07.exchange.corp.microsoft.com (157.54.109.46) with Microsoft SMTP Server (TLS) id 15.0.620.14; Thu, 14 Mar 2013 13:57:08 -0700
Received: from DFM-CO1MBX15-04.exchange.corp.microsoft.com (157.59.247.11) by DFM-CO1MBX15-02.exchange.corp.microsoft.com (157.59.247.79) with Microsoft SMTP Server (TLS) id 15.0.620.25; Thu, 14 Mar 2013 13:57:07 -0700
Received: from DFM-CO1MBX15-04.exchange.corp.microsoft.com ([157.59.247.11]) by DFM-CO1MBX15-04.exchange.corp.microsoft.com ([169.254.5.131]) with mapi id 15.00.0620.020; Thu, 14 Mar 2013 13:57:07 -0700
From: Koen Vos 
To: Roman Shpount 
Thread-Topic: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIPRnkpncK0k0RUO4cgAAO7xNfZilp6hF
Date: Thu, 14 Mar 2013 20:57:06 +0000
Message-ID: 
References: <31611_1363212891_5140FA5B_31611_17197_1_35788a76-852d-49ce-8987-d2be2f21fcaf@PEXCVZYH02.corporate.adroot.infra.ftgroup>  <3246_1363214890_5141022A_3246_1976_1_34a49fde-fad7-4a0a-8b01-9d48a5b6eeab@PEXCVZYH01.corporate.adroot.infra.ftgroup> <51415833.1050503@mozilla.com> <12711_1363264558_5141C42E_12711_1015_1_44e82a49-a4d3-4020-b26c-df36435f3ac8@PEXCVZYH01.corporate.adroot.infra.ftgroup>  , 
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.13]
Content-Type: multipart/alternative; boundary="_000_aa03077fa902416bb7d6c776b95b4749DFMCO1MBX1504exchangeco_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.1.27; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(189002)(24454001)(199002)(80022001)(512954001)(56776001)(20776003)(47736001)(876001)(33646001)(4396001)(74502001)(59766001)(66066001)(63696002)(5343645001)(46102001)(47446002)(54316002)(16406001)(79102001)(31966008)(74662001)(49866001)(65816001)(47976001)(56816002)(54356001)(53806001)(44976002)(50986001)(51856001)(76482001)(16236675001)(77982001)(69226001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2SR01MB609; H:hybrid.exchange.microsoft.com; RD:mail7.exchange.microsoft.com; MX:1; A:1; LANG:en; 
X-Forefront-PRVS: 0785459C39
X-OriginatorOrg: msft.ccsctp.net
Cc: MARJOU Xavier OLNC/OLN , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 20:57:41 -0000

--_000_aa03077fa902416bb7d6c776b95b4749DFMCO1MBX1504exchangeco_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

> On the other hand, this is kind of interesting to hear coming from someon=
e from Skype, which
> does not allow connections using SILK from outside of their own network, =
which has been
> hurting interop voice quality for a long time as well.

Skype has ever used "interop with the 100s of millions of our endpoints" as=
 an argument :)

koen.

________________________________
From: Roman Shpount
Sent: Thursday, March 14, 2013 1:41 PM
To: Koen Vos
Cc: Espen Berger (espeberg); stephane.proust@orange.com; rtcweb@ietf.org; M=
ARJOU Xavier OLNC/OLN
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01


On Thu, Mar 14, 2013 at 4:32 PM, Koen Vos > wrote:
WebRTC connecting to a Telco network would have to go through a Gateway.  T=
he PSTN termination providers who run these Gateways support G.711, G.729 a=
nd perhaps some other  codecs like iLBC.  They do not, however, support the=
 codecs you are advocating for.

The lack of support for Transcoding-Free Operation by Telcos to the rest of=
 the world has been hurting interop voice quality for a long time, but unfo=
rtunately we can't fix that here at the IETF.

We can fit our cars with your costly railroad wheels, but you still wouldn'=
t let us on your tracks.


I would got to agree with you regarding cell phone operators, since we've b=
een trying to get access to native AMR-WB for years.

On the other hand, this is kind of interesting to hear coming from someone =
from Skype, which does not allow connections using SILK from outside of the=
ir own network, which has been hurting interop voice quality for a long tim=
e as well.

Finally, it is possible to connect to almost any hosted PBX provider, as we=
ll as quite a few premise based PBXs, using G.722, as long as their end poi=
nts support it.
_____________
Roman Shpount


--_000_aa03077fa902416bb7d6c776b95b4749DFMCO1MBX1504exchangeco_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









> On the other hand, this is kind of interesting to hear coming&nbs=
p;from someone from Skype, which


> does not allow connections using SILK from outside of their own networ=
k, which has been


> hurting interop voice quality for a long time as well.



Skype has ever used "interop with the 100s of millions of our endpoint=
s" as an argument :)



koen.








From: Roman Shpount

Sent: Thursday, March 14, 2013 1:41 PM

To: Koen Vos

Cc: Espen Berger (espeberg); stephane.proust@orange.com; rtcweb@ietf=
.org; MARJOU Xavier OLNC/OLN

Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-au=
dio-codecs-for-interop-01

 











On Thu, Mar 14, 2013 at 4:32 PM, Koen Vos 
<koen.vos@skype.=
net> wrote:




WebRTC connecting to a Telco network would have to go thr=
ough a Gateway.  The PSTN termination providers who run these Gateways=
 support G.711, G.729 and perhaps some other  codecs like iLBC.  =
They do not, however, support the codecs you are
 advocating for.



The lack of support for Transcoding-Free Operation by Telcos to the rest of=
 the world has been hurting interop voice quality for a long time, but unfo=
rtunately we can't fix that here at the IETF.



We can fit our cars with your costly railroad wheels, but you still wouldn'=
t let us on your tracks.











I would got to agree with you regarding cell phone operators, since we=
've been trying to get access to native AMR-WB for years.







On the other hand, this is kind of interesting to hear coming&nbs=
p;from someone from Skype, which does not allow connections using SILK from=
 outside of their own network, which has been hurting interop voice quality=
 for a long time as well.







Finally, it is possible to connect to almost any hosted PBX provider, =
as well as quite a few premise based PBXs, using G.722, as long as their en=
d points support it.


_____________

Roman Shpount


 












--_000_aa03077fa902416bb7d6c776b95b4749DFMCO1MBX1504exchangeco_--

From prvs=9785d53dd1=aallen@blackberry.com  Thu Mar 14 14:09: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 B84CA11E822A for ; Thu, 14 Mar 2013 14:09:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.175
X-Spam-Level: 
X-Spam-Status: No, score=-5.175 tagged_above=-999 required=5 tests=[AWL=0.028,  BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 z3mjP9ZOVxMF for ; Thu, 14 Mar 2013 14:09:50 -0700 (PDT)
Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8290011E8229 for ; Thu, 14 Mar 2013 14:09:49 -0700 (PDT)
X-AuditID: 0a412830-b7ef86d00000339d-26-51423c907eb8
Received: from XCT104ADS.rim.net (xct104ads.rim.net [10.67.111.45]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 11.F3.13213.09C32415; Thu, 14 Mar 2013 16:09:36 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.02.0328.009; Thu, 14 Mar 2013 16:09:36 -0500
From: Andrew Allen 
To: "koen.vos@skype.net" , "espeberg@cisco.com" , "stephane.proust@orange.com" 
Thread-Topic: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIHAgQ3Oi2P7DjEKDSnUvQoKufpilc9aAgAAGtgCAAH5yAP//tpYY
Date: Thu, 14 Mar 2013 21:09:35 +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: [10.67.110.253]
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDKsWRmVeSWpSXmKPExsXC5ZyvqzvBxinQYNJRG4svDckWrT+/MVus /dfObtE64wqbxZGta5kdWD2m/N7I6rFkyU8mj5ZnJ9k8bj2YxBbAEtXAaJOUWFIWnJmep29n k5iXl1+SWJKqkJJanGyr5JOanpijEFCUWZaYXKngklmcnJOYmZtapKSQmWKrZKKkUJCTmJya m5pXYquUWFCQmpeiZMelgAFsgMoy8xRS85LzUzLz0m2VPIP9dS0sTC11DZXsdBM6eTK2dJ5m Kzg7i7HiwuLt7A2MuxoYuxg5OCQETCTOXtDtYuQEMsUkLtxbzwZiCwm0MUm8nJQJYW9mlGh5 4QFiswloSew/PJ2pi5GLQ0RgOqPEnz/P2UESzAIJEv39a5lAZgoLxEs0nyoECYsAhaf8mMMM YbtJfHvbxgZSwiKgKvF9eiRImFfAQ+LTmx1gazkFoiVenu4BsxmBzvl+ag0TxHRxiVtP5jNB nCkgsWTPeWYIW1Ti5eN/rBC2osTfvd9ZIer1JG5MncIGYWtLLFv4mhlil6DEyZlPWCYwis5C MnYWkpZZSFpmIWlZwMiyilEwN6PYwMwwOS9ZrygzVy8vtWQTIyh5OGoY7GB8/97iEKMAB6MS D+8BM6dAIdbEsuLK3EOMEhzMSiK8u/46BgrxpiRWVqUW5ccXleakFh9idAUGxERmKe7kfGBi yyuJNzYwwM1REuct0wSaK5AOTD3ZqakFqUUwc5g4OEH2cEmJFAMTSGpRYmlJRjwozcUXAxOd VAOj5evT88V4Z6SW+a+avO69ks3xtrSAHT+XPG3rUd79pt90jZ5zaKGtLq+nX3lGXaqI3+IS 4SXOjGeXcx71iJ9kZfDyEWtsRmjuhT9/6qdVcQseeffwTIXP6Y83PVt2ZrO0cifciNue0/ef 98ve5I56htkGLrfuHzb42bdIYJbu5qrpmUcnHLqtxFKckWioxVxUnAgAjZupEV8DAAA=
Cc: "xavier.marjou@orange.com" , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 21:09:52 -0000

Koen is right that there are many more obstacles to RTCweb and legacy networ=
k interop than just a common codec. First there will need to be RTCweb signa=
ling gateways to interface between the RTCweb signaling and the legacy netwo=
rks (SIP, H.323 etc) and there will need to be in place mechanisms for peeri=
ng, federation and address resolution between networks as well as service ag=
reements in place between the players.

Until those are resolved supporting codecs used in those networks is pointle=
ss.

Andrew

----- Original Message -----
From: Koen Vos [mailto:koen.vos@skype.net]
Sent: Thursday, March 14, 2013 03:32 PM Central Standard Time=0A=
To: Espen Berger (espeberg) ; stephane.proust@orange.com=
 
Cc: rtcweb@ietf.org ; MARJOU Xavier OLNC/OLN 
Subject: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-code=
cs-for-interop-01

> It's interop with billions of mobile phones and with fixed terminals in le=
gacy telephony services.

The problem is that WebRTC and legacy services live in separate networks: th=
e open Web vs proprietary Telco networks.

WebRTC connecting to a Telco network would have to go through a Gateway.  Th=
e PSTN termination providers who run these Gateways support G.711, G.729 and=
 perhaps some other  codecs like iLBC.  They do not, however, support the co=
decs you are advocating for.

The lack of support for Transcoding-Free Operation by Telcos to the rest of=
 the world has been hurting interop voice quality for a long time, but unfor=
tunately we can't fix that here at the IETF.

We can fit our cars with your costly railroad wheels, but you still wouldn't=
 let us on your tracks.

koen.


-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 stephane.proust@orange.com
Sent: 14. mars 2013 13:36
To: Jean-Marc Valin
Cc: rtcweb@ietf.org; MARJOU Xavier OLNC/OLN
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-code=
cs-for-interop-01

Hello

The short list is aligned to what is specified in 3GPP (mobile) and CAT-iq (=
fixed). Check the related service specifications!
The short list (AMR, AMR-WB, G.722) is a minimal subset of codecs to minimiz=
e interop issues and transcoding costs for telco services.
It's not a question of what's the favourite codec for a given application. I=
t's interop with billions of mobile phones and with fixed terminals in legac=
y telephony services.

St=E9phane

-----Message d'origine-----
De : Jean-Marc Valin [mailto:jmvalin@mozilla.com] Envoy=E9 : jeudi 14 mars 2=
013 05:55 =C0 : PROUST Stephane OLNC/OLPS Cc : Andrew Allen; Markus.Isomaki@=
nokia.com; MARJOU Xavier OLNC/OLN; rtcweb@ietf.org Objet : Re: [rtcweb] Agen=
da time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/13/2013 06:48 PM, stephane.proust@orange.com wrote:
> The reason is simply that AMR and AMR-WB are supported in billions of
> devices !

Just curious, why exclude from the list other codecs with similar huge deplo=
yment? I can think of at least:
- - GSM-FR (mobile)
- - Speex (Flash)
- - G.729 (PSTN gateways)
- - iLBC (PSTN gateways)
- - G.726 (DECT)
- - SILK (original non-Opus version in Skype)

(sorry, if I missed someone's favorite codec in this list)

It's not at all clear to me what's so special that makes AMR, AMR-WB and G.7=
22 different from the other codecs in the list above. Not that I insist on s=
hipping G.729 :-)

Personally, I'd favor a draft that included a lot more codecs, describing fo=
r each one the benefits of supporting it. Implementers could then choose whi=
ch of these they care about for their particular situation.

Cheers,

        Jean-Marc

> St=E9phane
>
>
> -----Message d'origine----- De : Andrew Allen
> [mailto:aallen@blackberry.com] Envoy=E9 : mercredi 13 mars 2013
> 23:41 =C0 : PROUST Stephane OLNC/OLPS; Markus.Isomaki@nokia.com;
> jmvalin@mozilla.com Cc : MARJOU Xavier OLNC/OLN; rtcweb@ietf.org Objet
> : Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
>
> No this wouldn't be acceptable to me.
>
> I don't see a reason to push a particular set of Codecs over any other
> set of codecs supported on the device. If the device supports the
> codecs and they are available to the browser then we should recommend
> that they be offered in the negotiation.
>
> The marjou draft can advertise the merits and reasons why they are
> good codecs to support.
>
>
> ----- Original Message ----- From: stephane.proust@orange.com
> [mailto:stephane.proust@orange.com] Sent: Wednesday, March 13, 2013
> 05:14 PM Central Standard Time To: Markus.Isomaki@nokia.com
> ; jmvalin@mozilla.com 
> Cc: MARJOU Xavier OLNC/OLN ; rtcweb@ietf.org
> 
> Subject: Re: [rtcweb] Agenda time     request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> Dear Markus
>
> Thanks for your attempt to help !
>
> Of course each Telco can handle this directly with vendors and
> browsers manufacturers at business level. But I don't'think this need
> of interoperability with mobile devices is specific to Orange.
> I think all mobile operators will have the same issue and this is why
> standardization exist. It's most cost and time efficient to have one
> common way forward for all the industry.
>
> Then if the issue is that "conditional MUST/SHOULD are a too
> complicated requirement. We could also live as a compromise with a
> formulation that has already been suggested on the reflector:
>
> "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" If possible with the addition of This is especially
> the case for AMR, AMR-WB for interoperability with mobile devices and
> G.722 for interoperability with fixed DECT CAT-iq devices
>
> Would it have one chance to reach consensus ?
>
> I think this Group should at least make one small step so that the
> interoperability issue with mobile terminals be not fully ignored in
> the RTC Web specification considering the huge number of deployed
> devices. At least something must be written on this !
> G.711 which is the only codec in addition to OPUS for interoperability
> purpose is not a proper answer to this.
>
> St=E9phane
>
> -----Message d'origine----- De : Markus.Isomaki@nokia.com
> [mailto:Markus.Isomaki@nokia.com] Envoy=E9 : mercredi 13 mars 2013
> 22:37 =C0 : PROUST Stephane OLNC/OLPS; jmvalin@mozilla.com; MARJOU
> Xavier OLNC/OLN Cc : rtcweb@ietf.org Objet : RE: [rtcweb] Agenda time
> request for draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> Hi Stephane, Xavier,
>
> I understand the intent of your proposal. I'm not sure if the IETF is
> the best venue for you to pursue it, however. Perhaps you as a mobile
> operator should rather set it as a requirement to your mobile device
> platforms that they open up the APIs to AMR and AMR-WB and that at
> least the in-built default browser needs to support it. If there are
> enough operators setting such requirements directly to the device and
> platform vendors, it probably has a bigger impact than an IETF RFC.
> Getting that support for user-installed additional browsers might be
> more difficult, but most mobile device users stick with the default
> browser anyway.
>
> The RTCWEB codec document needs to definitely explain this case and
> the benefits, but the conditional MUSTs or SHOULDs you are proposing
> are perhaps a bit too complicated. Hmm, perhaps we need to do an
> _informational_ RFC as something like "Recommendations for WebRTC on
> Mobile Devices" addressing the codec and perhaps other issues, that
> you could use as a reference in your requirements.
>
> Markus
>
>
>> -----Original Message----- From: rtcweb-bounces@ietf.org
>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext
>> stephane.proust@orange.com Sent: 13 March, 2013 21:37 To:
>> Jean-Marc Valin; MARJOU Xavier OLNC/OLN Cc: rtcweb@ietf.org
>> Subject: Re: [rtcweb] Agenda time request for
>> draft-marjou-rtcweb-audio- codecs-for-interop-01
>>
>> Hello
>>
>> Our understanding is that the reason of the "no consensus" on
>> additional recommended codecs was the additional costs for browsers.
>> The proposal is then to make these "MUST" fully conditional to the
>> case of no (or very reduced) additional costs, when the codecs are
>> already available on the device and when no additional license fee is
>> required
>>
>> We could even live with lower level of "requirements" with
>> respectively May and Should (instead of Should and shall) but we
>> think that this proposal is a way to take into account both browser
>> manufacturers concerns on browsers costs and telcos concerns on
>> transcoding costs and some other companies share this view.
>>
>> St=E9phane
>>
>>
>>
>>
>>
>>
>> -----Message d'origine----- De : rtcweb-bounces@ietf.org
>> [mailto:rtcweb-bounces@ietf.org] De la part de Jean-Marc Valin Envoy=E9
>> : mercredi 13 mars 2013 20:24 =C0 : MARJOU Xavier OLNC/OLN Cc :
>> rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time request for
>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>>
> Hi,
>
> I'd really like to understand how the chairs coming to the conclusion
> that there was *no consensus* on recommended codecs can result in a
> draft that includes 3 MUSTs and 1 SHOULD. This draft effectively makes
> 3 new codecs MTI for a range of devices. I understand that it's an
> individual draft and you can write whatever you like in there, but it
> definitely goes against the result of the WG discussion.
>
> Cheers,
>
> Jean-Marc
>
> On 03/13/2013 09:14 AM, Xavier Marjou wrote:
>>>> Here is a summary of the
>>>> draft-marjou-rtcweb-audio-codecs-for-interop-00 presentation that I
>>>> had prepared for yesterday's session:
>>>>
>>>> - The co-authors want to underline that non-WebRTC voice endpoints
>>>> usually use one of the following codecs: AMR, AMR-WB or G.722,
>>>> which will result in massive transcoding when there will be
>>>> communications between WebRTC endpoints and non-WebRTC endpoints.
>>>>
>>>> - On one side, transcoding is bad for many reasons discussed in the
>>>> draft (cost issues, intrinsic quality degradation, degraded
>>>> interactivity, fallback from HD to G.711...);
>>>>
>>>> - On the other side, it is recognized that implementing additional
>>>> codecs in the browsers can generate additional costs.
>>>>
>>>> - In order to reach a compromise, we would like to add some text in
>>>> the WG draft draft-ietf-rtcweb-audio providing incentives for the
>>>> browser to use these three codecs: make them mandatory to implement
>>>> when there is no cost impact on the browser (e.g. if codec already
>>>> installed, paid by the device vendor...).
>>>>
>>>> Any opinion on that?
>>>>
>>>> Cheers,
>>>>
>>>> Xavier
>>>>
>>>> PS: I will be ready to present the slides on Thursday if time
>>>> permits it.
>>>>
>>>> (c.f.
>>>> http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf
>>>>
>>>>
)
>>>>
>>>>
>>>>
>>>> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie >>> > wrote:
>>>>
>>>> Magnus and I discussed this this morning, and we encourage you to
>>>> prepare something.  If the discussion of working group last call
>>>> items runs short, we may be able to fit this in at that time or at
>>>> the end of day one if its full agenda his finished.  This is not a
>>>> commitment, however, so please try and get discussion on the list
>>>> on the points from the draft you feel need resolution.
>>>>
>>>> regards,
>>>>
>>>> Ted
>>>>
>>>>
>>>> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)
>>>> > wrote:
>>>>> Hello,
>>>>>
>>>>>
>>>>>
>>>>> I would like to request agenda time for:
>>>>>
>>>>>
>>>>>
>>>>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>>>>>
>>>>>
>>>>>
>>>>> The document  presents use-cases underlining why WebRTC needs
>>>> AMR-WB,  AMR
>>>>> and G.722 as additional relevant voice codecs to satisfactorily
>>>>> ensure interoperability with existing systems.
>>>>>
>>>>>
>>>>>
>>>>> A 10-minute time slot should be sufficient for presentation and
>>>> discussion.
>>>>>
>>>>>
>>>>>
>>>>> Regards
>>>>>
>>>>>
>>>>>
>>>>> -Espen
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________ 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
>>
>> ___________________________________________________________
>> ___________________________________________________________ ___
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>> exploites ou copies sans autorisation. Si vous avez recu ce message
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
>> que les pieces jointes. Les messages electroniques etant susceptibles
>> d'alteration, France Telecom - Orange decline toute responsabilite si
>> ce message a ete altere, deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law; they should not
>> be distributed, used or copied without authorisation. If you have
>> received this email in error, please notify the sender and delete
>> this message and its attachments. As emails may be altered, France
>> Telecom - Orange is not liable for messages that have been modified,
>> changed or falsified. Thank you.
>>
>> _______________________________________________ rtcweb mailing list
>> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
>
> ______________________________________________________________________
> ___________________________________________________
>
>  Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> que les pieces jointes. Les messages electroniques etant susceptibles
> d'alteration, France Telecom - Orange decline toute responsabilite si
> ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should not
> be distributed, used or copied without authorisation. If you have
> received this email in error, please notify the sender and delete this
> message and its attachments. As emails may be altered, France Telecom
> - Orange is not liable for messages that have been modified, changed
> or falsified. Thank you.
>
> _______________________________________________ rtcweb mailing list
> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
>
> ---------------------------------------------------------------------
>
>
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.
>
> ______________________________________________________________________
> ___________________________________________________
>
>  Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> que les pieces jointes. Les messages electroniques etant susceptibles
> d'alteration, France Telecom - Orange decline toute responsabilite si
> ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should not
> be distributed, used or copied without authorisation. If you have
> received this email in error, please notify the sender and delete this
> message and its attachments. As emails may be altered, France Telecom
> - Orange is not liable for messages that have been modified, changed
> or falsified. Thank you.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRQVgzAAoJEJ6/8sItn9q9fgYH/jcWfhRrvPM1hJ22YcE7eR0N
OZzP/RvSrUBiIA6kG+6+Hvn5Lp/tXd+LxUDp5L8B3Toce7TBBAYNJP3M2cr8N8It
SjVvPHtBNKEqhBLbI4FbAouvymNH4utjAWR+MmF9LRySPXZ9nxLN0A13TeUlpZxt
Jaxr/n9AWwkKOk6BIo1Xztbk26MObiGVLhCE+CPoHaHe29bKblPcphBXC935ymHS
SuF2DXiAq0iKwZoVOsLe3RIaGg+bjN7N2MXi3Vphr7cOQK+JpdxURDrvmPh7/L8R
ht1RJt928yl4fEjnKhSKJLd1J+gPBe6vnkSxUp89as03bLirLwN1G2giD3YzfLM=3D
=3DK56v
-----END PGP SIGNATURE-----

____________________________________________________________________________=
_____________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages ele=
ctroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete alt=
ere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delet=
e this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages=
 that have been modified, changed or falsified.
Thank you.

_______________________________________________
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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From roman@telurix.com  Thu Mar 14 14:17: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 5D39E11E814D for ; Thu, 14 Mar 2013 14:17:17 -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 RSxnu1V8I824 for ; Thu, 14 Mar 2013 14:17:16 -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 F414211E80D7 for ; Thu, 14 Mar 2013 14:17:15 -0700 (PDT)
Received: by mail-wi0-f173.google.com with SMTP id hq4so4229989wib.0 for ; Thu, 14 Mar 2013 14:17:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ieW+Lm5X2CU3cWThOuyFpdrN5+WtrwibxjBVRB8DX0E=; b=aXEVBWVtiMOwTlpczo5YjIERnVcA0mLslItehNfytJsgYxiIxTaF7lfT6kNj5rOimr OCcmDSbezArLarRzVY1X5k2RAJmNQt/b84+OZQg4+2/uLqeFVpwR53f9VLdSsQxBpM6M yyg2sWncMYp2hwyfBHDX64VK06Hyq7ykFpCQhKBCGR2ST5CAynOIkCgR/1amHXtmYuYa tFgZKYiLVTf1gn2zBG31/dba1Cg8QM0Ytv+bEr9zXW2dgkKVVu4yTyFz704QsFGHG+wJ BQy54BWzZnleHQ40q1pecH1SQiBvnMyhqxsX/iMegBk5OpdvDvj6VsQpE7oV5dc0jLvT 9ikQ==
X-Received: by 10.180.185.176 with SMTP id fd16mr6766393wic.31.1363295834914;  Thu, 14 Mar 2013 14:17:14 -0700 (PDT)
Received: from mail-wi0-x22a.google.com ([2a00:1450:400c:c05::22a]) by mx.google.com with ESMTPS id ek4sm11381736wib.11.2013.03.14.14.17.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 14:17:13 -0700 (PDT)
Received: by mail-wi0-f170.google.com with SMTP id hm11so4654077wib.3 for ; Thu, 14 Mar 2013 14:17:12 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.21.233 with SMTP id y9mr7010694wje.47.1363295832266; Thu, 14 Mar 2013 14:17:12 -0700 (PDT)
Received: by 10.217.107.135 with HTTP; Thu, 14 Mar 2013 14:17:11 -0700 (PDT)
In-Reply-To: 
References:  
Date: Thu, 14 Mar 2013 17:17:11 -0400
Message-ID: 
From: Roman Shpount 
To: Andrew Allen 
Content-Type: multipart/alternative; boundary=047d7b5d2774ce614b04d7e90b19
X-Gm-Message-State: ALoCoQnsz8htja4dB5Z/4MZAufZrEvAyizIMFeCaONJinXvGC4hBIEl4k+olzS84bKbiMZXzi8n5
Cc: "rtcweb@ietf.org" , "xavier.marjou@orange.com" 
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 21:17:17 -0000

--047d7b5d2774ce614b04d7e90b19
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Mar 14, 2013 at 5:09 PM, Andrew Allen  wrote:

>
> Koen is right that there are many more obstacles to RTCweb and legacy
> network interop than just a common codec. First there will need to be
> RTCweb signaling gateways to interface between the RTCweb signaling and the
> legacy networks (SIP, H.323 etc) and there will need to be in place
> mechanisms for peering, federation and address resolution between networks
> as well as service agreements in place between the players.
>
> Until those are resolved supporting codecs used in those networks is
> pointless.
>

These issues are resolved. See one example here: http://webrtc2sip.org/.
These solutions do suffer from the need to transcode, this is why this
codec discussion has been going on.
_____________
Roman Shpount

--047d7b5d2774ce614b04d7e90b19
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Thu, Mar 14, 2013 at 5:09 PM, =
Andrew Allen <aallen@blackberry.com> wrote:



Koen is right that there are many more obstacles to RTCweb and legacy netwo=
rk interop than just a common codec. First there will need to be RTCweb sig=
naling gateways to interface between the RTCweb signaling and the legacy ne=
tworks (SIP, H.323 etc) and there will need to be in place mechanisms for p=
eering, federation and address resolution between networks as well as servi=
ce agreements in place between the players.




Until those are resolved supporting codecs used in those networks is pointl=
ess.



_____________
Roman Shpount
=A0


--047d7b5d2774ce614b04d7e90b19--

From espeberg@cisco.com  Thu Mar 14 14:29: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 8982B11E8191 for ; Thu, 14 Mar 2013 14:29:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.3
X-Spam-Level: 
X-Spam-Status: No, score=-9.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 7ky09BZXHblJ for ; Thu, 14 Mar 2013 14:29:15 -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 9076011E814D for ; Thu, 14 Mar 2013 14:29:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1868; q=dns/txt; s=iport; t=1363296555; x=1364506155; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=aw/x1Mm5XlT52zuWz8D1Jbpb4iRbMvpVlKAZHB1INlI=; b=lWVqDev/yi8daK0z86/DOM0r9EgRm0HYg7Uub6L1mWZtwTQNQIxA3I0s EMNrU9fhJYLPFnbhTp8ICqLL0ZfbA+7CQqy0xzimnA4aASupybFxnCWAS GOWmsJ1d4+NjfEw3nFnt3/P7+JUBXed6NiBXgPXbOjZp6ghCvOYIcq95S s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAMk/QlGtJXHA/2dsb2JhbABDxQKBZRZ0gisBAQEEAQEBNzQLDAQCAQgRBAEBAQoUCQcnCxQJCAIEAQ0FCIgMDMIJjmUxBwaCWWEDp1qDCoIo
X-IronPort-AV: E=Sophos;i="4.84,846,1355097600"; d="scan'208";a="187412498"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 14 Mar 2013 21:29:14 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2ELTDsu019634 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Mar 2013 21:29:13 GMT
Received: from xmb-rcd-x11.cisco.com ([169.254.1.206]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 16:29:13 -0500
From: "Espen Berger (espeberg)" 
To: Jean-Marc Valin , Roman Shpount 
Thread-Topic: [rtcweb] Audio transcoding: CPU costs
Thread-Index: AQHOIEcKbSPQS+qPR0i9uWInpsZm+pik9cCAgAAIH4CAALKJcA==
Date: Thu, 14 Mar 2013 21:29:12 +0000
Message-ID: 
References: <5141133D.3040100@alvestrand.no>  <514160E7.1090205@mozilla.com>
In-Reply-To: <514160E7.1090205@mozilla.com>
Accept-Language: nb-NO, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.55.89.104]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Audio transcoding: CPU costs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 21:29:16 -0000

Transcoding is not the only cost when mapping from one audio codec to anoth=
er one in some infrastructure component.=20

* You need to re-encrypt to get secure calls
* Map between resilience techniques from different codecs =20
* Rate adaptation from one bitrate to another=20

-Espen=20


-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Jean-Marc Valin
Sent: 14. mars 2013 06:32
To: Roman Shpount
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Audio transcoding: CPU costs

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/14/2013 01:03 AM, Roman Shpount wrote:
> 1. Based on the message you are quoting, current performance is
> 150 channels per core. It would require some non-trivial work to get=20
> it to 500 channels.

Yeah, it'd probably take 2-3 weeks to write some assembly. Also, keep in mi=
nd that these numbers were measured using a single core of a laptop that ju=
st turned three years old (http://ark.intel.com/products/43560/Intel-Core-i=
7-620M-Processor-4M-Cache-2_66-GHz).
I would expect your servers to have slightly more powerful CPUs :-)

	Jean-Marc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRQWDnAAoJEJ6/8sItn9q9/IAIAKxX5xG8ACKxhQrlMLjhD1eX
uhITi8mVOiE3wGuBbdge4JzAs7IlmJ+Db7sp0w7INmv8G0GgmOT44c3wZgU7l6LF
k5wKE6/UzCC+tFBtLVfuMJtvnswrjPEQvHkp9mM0U4sA1RBzIMv9NyCymt/zgQtG
3jlH9Tr9oD4n5Ug90UbRlF52cT5yfPL+nsDflCPhEcDvsnseckLQtO0N+kIBgabH
9MWh9sq3RFzwtE4iWq5vdzlhWnPd0qp7bAWa8flMA4DAfcgaYkXMh/N8ejo/zo0e
SAkL6jlMm259Nnl3fTVtD0SdPKTPUckRNuggai/GfHsgCrAFz0ua8sePyiQXZgg=3D
=3DyLLG
-----END PGP SIGNATURE-----
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

From rhglidden@gmail.com  Thu Mar 14 15:12: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 916F61F0D19 for ; Thu, 14 Mar 2013 15:12:55 -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 dyaumCCdAe0C for ; Thu, 14 Mar 2013 15:12:54 -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 DD1811F0D11 for ; Thu, 14 Mar 2013 15:12:53 -0700 (PDT)
Received: by mail-qa0-f44.google.com with SMTP id bv4so3128111qab.3 for ; Thu, 14 Mar 2013 15:12:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type; bh=rIsAJhtNKapde9zYJYtsjYF0KuJLs84BDvPNpnI36oY=; b=h9I2GuB8LwC30vq0MnDUH5kTY0mxaCGQtFkCK5YY3aRFkN+PZFt9Hj0COyMzD7BfCB VNDnZOi0KyCMB3Uj5typDS9WKHx+hAF0j6Cq6+OFWLKpq0vkf/+u0xuEviJNUa3gzAmY lADj/lGX57bpL6S1Phz91pvelM31Zjt5uOE1Nd/sr69JYnRO/1e5sFR+dU8K05cDUrR6 6euEh3DUEWpY0BlZe4DXgm2cHplrxR/fb17Tl61B8SHPbbvoc8l234mZ7IEv03e4t7H5 8l8Q0C+6Me9FPdV6y+VaBYU4o2nmrTAa/mXkXzehvSlQn9MiqR/C2a4rKrzgzYuwhzQQ LwmA==
X-Received: by 10.224.220.211 with SMTP id hz19mr2551147qab.49.1363299173171;  Thu, 14 Mar 2013 15:12:53 -0700 (PDT)
Received: from [10.0.0.10] (99-25-33-39.lightspeed.sntcca.sbcglobal.net. [99.25.33.39]) by mx.google.com with ESMTPS id gw9sm533376qab.10.2013.03.14.15.12.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 15:12:52 -0700 (PDT)
Message-ID: <51424B5F.9090600@gmail.com>
Date: Thu, 14 Mar 2013 15:12:47 -0700
From: Rob Glidden 
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: "Wang, Ye-Kui" ,  "rtcweb@ietf.org" 
References: <513F68C0.4010106@ericsson.com>  <513F7745.3020302@alvestrand.no>    <8BA7D4CEACFFE04BA2D902BF11719A8331B17F22@nasanexd02f.na.qualcomm.com>, <1363220674.82166.YahooMailNeo@web132106.mail.ird.yahoo.com> <2981F523-72AC-4330-8D1F-7DC4E2168C5A@qti.qualcomm.com> <5141F120.3020400@gmail.com> <8BA7D4CEACFFE04BA2D902BF11719A8331B19D77@nasanexd02f.na.qualcomm.com>
In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A8331B19D77@nasanexd02f.na.qualcomm.com>
Content-Type: multipart/alternative; boundary="------------080608040809040302090304"
Subject: Re: [rtcweb] Video Codec discussion in Thursday agenda slot
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 22:12:55 -0000

This is a multi-part message in MIME format.
--------------080608040809040302090304
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Agreed as to MPEG rubberstamping VP8, the Google proposal circulated to 
this list didn't recommend that either, rather that it be adopted as 
reference model and advanced to working draft.

Nonetheless, the submission of VP8 to ISO/MPEG as a proof-point for MTI 
in IETF is right on slide 3.

And the supporting doc says Google expects ISO to execute its ordinary 
process for resolution of IPR issues.

Rob

On 3/14/2013 12:08 PM, Wang, Ye-Kui wrote:
>
> Surely it is not.
>
> Note that the context here is on the MTI codec discussion in IETF, not 
> at all the context the POSSIBLE standardization of VP8 in MPEG (which, 
> if to happen, would most likely be subject to more development taking 
> the current VP8 as the basis rather than rubberstamping as is).
>
> BR, YK
>
> *From:*rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On 
> Behalf Of *Rob Glidden
> *Sent:* Thursday, March 14, 2013 8:48 AM
> *To:* Wang, Ye-Kui; rtcweb@ietf.org
> *Subject:* Re: [rtcweb] Video Codec discussion in Thursday agenda slot
>
> Sure it is, there's an open MPEG meeting resolution on the MPEG VP8 
> proposal to that effect, apparently even National Body comment.
>
> Rob
>
> On 3/13/2013 9:36 PM, Wang, Ye-Kui wrote:
>
>     Sure - but that is clearly not the context here.
>
>     Sent from my iPhone
>
>
>     On Mar 13, 2013, at 17:24, "Gerard Fernando"
>     > wrote:
>
>         Hello YK,
>
>         The disclosure process in MPEG is not based on who you are, or
>         on your Business model.
>
>         Kind regards
>
>         Gerard
>
>         ------------------------------------------------------------------------
>
>         *From:*"Wang, Ye-Kui"          >
>         *To:* Stockhammer Thomas          >; Bo Burman
>         >
>         *Cc:* "rtcweb@ietf.org "
>         >
>         *Sent:* Wednesday, 13 March 2013, 10:40
>         *Subject:* Re: [rtcweb] Video Codec discussion in Thursday
>         agenda slot
>
>
>         > >  How many others who did not respond to MPEG LA's call but
>         have IPR
>         > > are
>         > there?
>         >
>         > [TS]  Just one more hypothesis: If I would have, what would
>         be my
>         > obligation/motivation to do so now?
>
>         Speaking of the motivation part; that would depend on who YOU
>         are and what kind of business model or plan YOU have in mind.
>
>         BR, YK
>
>         > -----Original Message-----
>         > From: rtcweb-bounces@ietf.org
>         
>         [mailto:rtcweb-bounces@ietf.org
>         ] On Behalf
>         > Of Stockhammer Thomas
>         > Sent: Wednesday, March 13, 2013 7:53 AM
>         > To: Bo Burman
>         > Cc: rtcweb@ietf.org 
>         > Subject: Re: [rtcweb] Video Codec discussion in Thursday
>         agenda slot
>         >
>         >
>         > >  How many others who did not respond to MPEG LA's call but
>         have IPR are
>         > there?
>         >
>         > [TS]  Just one more hypothesis: If I would have, what would
>         be my
>         > obligation/motivation to do so now?
>         >
>         > >>>
>         > >>> We appreciate the need to have time to evaluate the
>         specific words
>         > >>> of the license statements that are forthcoming, and the
>         need for the
>         > >>> people who haven't made their IPR declarations over the
>         last couple
>         > >>> of years of discussion to do so within the next couple
>         of weeks -
>         > >>> but we do think that it is important to use the face to
>         face time
>         > >>> that we have here in Orlando to lay to rest any *other*
>         issues than
>         > >>> the licensing terms and other issues derived from Google's
>         > announcement.
>         > >>
>         > >> I am not sure we can have a reasoned consideration of
>         'other issues
>         > derived'
>         > >> at such short notice.
>         > >>
>         > >> Look, I'd like our discussions and decisions to be
>         informed and
>         > >> considered, and there simply isn't time for either.
>         > >>
>         > >>>
>         > >>> Harald
>         > >>>
>         > >>> _______________________________________________
>         > >>> rtcweb mailing list
>         > >>> rtcweb@ietf.org 
>         > >>> https://www.ietf.org/mailman/listinfo/rtcweb
>         > >>
>         > >> David Singer
>         > >> Multimedia and Software Standards, Apple Inc.
>         > >>
>         > >> _______________________________________________
>         > >> rtcweb mailing list
>         > >> rtcweb@ietf.org 
>         > >> https://www.ietf.org/mailman/listinfo/rtcweb
>         > >
>         >
>         > ---
>         > Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de
>          || phone +49
>         > 89 978980 02 || cell +491725702667 ||
>         http://www.nomor-research.com 
>         > Nomor Research GmbH  -  Sitz der Gesellschaft: München -
>         Registergericht:
>         > München, HRB 165856 - Umsatzsteuer-ID: DE238047637 -
>         Geschäftsführer:
>         > Dr. Thomas Stockhammer, Dr. Ingo Viering.
>         >
>         >
>         >
>         > _______________________________________________
>         > 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
>


--------------080608040809040302090304
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Agreed as to MPEG rubberstamping VP8,
      the Google proposal circulated to this list didn't recommend that
      either, rather that it be adopted as reference model and advanced
      to working draft.

      

      Nonetheless, the submission of VP8 to ISO/MPEG as a proof-point
      for MTI in IETF is right on slide 3. 

      

      And the supporting doc says Google expects ISO to execute its
      ordinary process for resolution of IPR issues.

      

      Rob

      

      On 3/14/2013 12:08 PM, Wang, Ye-Kui wrote:

    

    

      
      
      
      
      

        
Surely
            it is not.

        
 

        
Note
            that the context here is on the MTI codec discussion in
            IETF, not at all the context the POSSIBLE standardization of
            VP8 in MPEG (which, if to happen, would most likely be
            subject to more development taking the current VP8 as the
            basis rather than rubberstamping as is).

        
 

        
BR,
            YK

        
 

        

          

            

              
From: rtcweb-bounces@ietf.org
                  [mailto:rtcweb-bounces@ietf.org]
                  On Behalf Of Rob Glidden

                  Sent: Thursday, March 14, 2013 8:48 AM

                  To: Wang, Ye-Kui; rtcweb@ietf.org

                  Subject: Re: [rtcweb] Video Codec discussion in
                  Thursday agenda slot

            

          

          
 

          

            
Sure it is, there's an open MPEG
              meeting resolution on the MPEG VP8 proposal to that
              effect, apparently even National Body comment.

              

              Rob

              

              On 3/13/2013 9:36 PM, Wang, Ye-Kui wrote:

          

          

            

              
Sure - but that is clearly not the
                context here.

                

                Sent from my iPhone

            

            

              


                On Mar 13, 2013, at 17:24, "Gerard Fernando" <gerardmxf@yahoo.co.uk>
                wrote:

            

            

              

                

                  

                    
Hello YK,

                  

                  

                    
 

                  

                  
The disclosure process in
                      MPEG is not based on who you are, or on your
                      Business model.

                      

                      Kind regards

                      

                      Gerard

                      

                      

                  

                    

                      

                        

                          
                            

                          

                        
From:
                            "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>

                            To: Stockhammer Thomas <stockhammer@nomor.de>;
                            Bo Burman <bo.burman@ericsson.com>
                            

                            Cc: "rtcweb@ietf.org"
                            <rtcweb@ietf.org>
                            

                            Sent: Wednesday, 13 March 2013, 10:40

                            Subject: Re: [rtcweb] Video Codec
                            discussion in Thursday agenda slot

                      

                      


                        > >  How many others who did not respond
                        to MPEG LA's call but have IPR 

                        > > are

                        > there?

                        > 

                        > [TS]  Just one more hypothesis: If I would
                        have, what would be my 

                        > obligation/motivation to do so now?

                        

                        Speaking of the motivation part; that would
                        depend on who YOU are and what kind of business
                        model or plan YOU have in mind.
                        

                        

                        BR, YK

                        

                        > -----Original Message-----

                        > From: rtcweb-bounces@ietf.org
                        [mailto:rtcweb-bounces@ietf.org]
                        On Behalf

                        > Of Stockhammer Thomas

                        > Sent: Wednesday, March 13, 2013 7:53 AM

                        > To: Bo Burman

                        > Cc: rtcweb@ietf.org

                        > Subject: Re: [rtcweb] Video Codec
                        discussion in Thursday agenda slot

                        > 

                        > 

                        > >  How many others who did not respond
                        to MPEG LA's call but have IPR are

                        > there?

                        > 

                        > [TS]  Just one more hypothesis: If I would
                        have, what would be my

                        > obligation/motivation to do so now?

                        > 

                        > >>>

                        > >>> We appreciate the need to have
                        time to evaluate the specific words

                        > >>> of the license statements that
                        are forthcoming, and the need for the

                        > >>> people who haven't made their
                        IPR declarations over the last couple

                        > >>> of years of discussion to do
                        so within the next couple of weeks -

                        > >>> but we do think that it is
                        important to use the face to face time

                        > >>> that we have here in Orlando
                        to lay to rest any *other* issues than

                        > >>> the licensing terms and other
                        issues derived from Google's

                        > announcement.

                        > >>

                        > >> I am not sure we can have a
                        reasoned consideration of 'other issues

                        > derived'

                        > >> at such short notice.

                        > >>

                        > >> Look, I'd like our discussions and
                        decisions to be informed and

                        > >> considered, and there simply isn't
                        time for either.

                        > >>

                        > >>>

                        > >>> Harald

                        > >>>

                        > >>>
                        _______________________________________________

                        > >>> rtcweb mailing list

                        > >>> rtcweb@ietf.org

                        > >>> https://www.ietf.org/mailman/listinfo/rtcweb

                        > >>

                        > >> David Singer

                        > >> Multimedia and Software Standards,
                        Apple Inc.

                        > >>

                        > >>
                        _______________________________________________

                        > >> rtcweb mailing list

                        > >> rtcweb@ietf.org

                        > >> https://www.ietf.org/mailman/listinfo/rtcweb

                        > >

                        > 

                        > ---

                        > Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de
                        || phone +49

                        > 89 978980 02 || cell +491725702667 || 
                          http://www.nomor-research.com

                        > Nomor Research GmbH  -  Sitz der
                        Gesellschaft: München - Registergericht:

                        > München, HRB 165856 - Umsatzsteuer-ID:
                        DE238047637 - Geschäftsführer:

                        > Dr. Thomas Stockhammer, Dr. Ingo Viering.

                        > 

                        > 

                        > 

                        >
                        _______________________________________________

                        > 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

          

          
 

        

      

    

    

  


--------------080608040809040302090304--

From btv1==7857ef4b335==HKaplan@acmepacket.com  Thu Mar 14 15:37: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 2087411E81AF for ; Thu, 14 Mar 2013 15:37:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.511
X-Spam-Level: 
X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088,  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 icugInT5GA3j for ; Thu, 14 Mar 2013 15:37:31 -0700 (PDT)
Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5BC11E8133 for ; Thu, 14 Mar 2013 15:37:31 -0700 (PDT)
X-ASG-Debug-ID: 1363300650-03fc200f255d56f0001-4f8tJD
Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx1.acmepacket.com with ESMTP id 9TxiMuB40WUEwP2x (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Mar 2013 18:37:30 -0400 (EDT)
X-Barracuda-Envelope-From: HKaplan@acmepacket.com
Received: from MAIL2.acmepacket.com ([169.254.2.222]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Thu, 14 Mar 2013 18:37:30 -0400
From: Hadriel Kaplan 
To: Andrew Allen 
Thread-Topic: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-ASG-Orig-Subj: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIQSCFxA/IgmPbEepPdD9tS6rDw==
Date: Thu, 14 Mar 2013 22:37:29 +0000
Message-ID: <21233D03-64FD-43D0-863E-18FC55BD0924@acmepacket.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21]
X-Barracuda-Start-Time: 1363300650
X-Barracuda-Encrypted: AES128-SHA
X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at acmepacket.com
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.125218 Rule breakdown below pts rule name              description ---- ---------------------- --------------------------------------------------
Cc: "rtcweb@ietf.org" , "xavier.marjou@orange.com" 
Subject: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 14 Mar 2013 22:37:32 -0000

On Mar 14, 2013, at 5:09 PM, Andrew Allen 
 wrote:

> Koen is right that there are many more obstacles to RTCweb and legacy net=
work interop than just a common codec. First there will need to be RTCweb s=
ignaling gateways to interface between the RTCweb signaling and the legacy =
networks (SIP, H.323 etc) and there will need to be in place mechanisms for=
 peering, federation and address resolution between networks as well as ser=
vice agreements in place between the players.
>=20
> Until those are resolved supporting codecs used in those networks is poin=
tless.

There are already WebRTC-SIP gateways, as I think you know.  I know of two =
SBC vendors who are in customer labs with it, for example, and there are pr=
obably more.  And yes at least one of them, and probably both, can transcod=
e the audio... though it's by no means free.  I don't know if the business =
case justifies the cost or not for WebRTC use-cases - it appears to in some=
 cases, not others.

It costs far more than has been discussed on this list though, because we t=
hink like engineers and consider the cost as a CAPEX issue; whereas in prac=
tice the OPEX costs often dwarf the CAPEX ones.  In some data centers, for =
example, the local Real-Estate costs dwarf CAPEX too, and using less rack-s=
pace can pay for a product in no time. (there's an entire company out there=
 that built its business leveraging this fact, replacing POTS switches with=
 much-higher-density ones purely based on rack-space usage savings)

Anyway... moving on to your other point of federation/peering/etc. - I thin=
k the use-case that mobile operators have in mind is fairly obvious, and it=
 clearly doesn't have that problem.  Whether you agree with helping that us=
e-case or not is up to you and the rest of this WG, of course.  I'm just no=
ting that peering isn't an obstacle for it.

-hadriel
p.s. Transcoding video, on the other hand, is untenable for pretty much any=
one.  I have never heard of a business-case which justifies it, because it =
simply doesn't scale.  Except for maybe companies that live on other revenu=
e sources, for whom all of this stuff is a rounding error in their IT budge=
t. ;)


From chris@chriswendt.net  Thu Mar 14 15:41: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 5D4CD11E81A2 for ; Thu, 14 Mar 2013 15:41:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.044
X-Spam-Level: 
X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QImuHutFLnVP for ; Thu, 14 Mar 2013 15:41:11 -0700 (PDT)
Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id E323411E8158 for ; Thu, 14 Mar 2013 15:41:11 -0700 (PDT)
Received: by mail-pb0-f45.google.com with SMTP id ro8so2899469pbb.4 for ; Thu, 14 Mar 2013 15:41:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Mm677Xly+aexbwgbKFLhAMmUUT4KLDdkroY34oD09QQ=; b=OSIGVk7opZAvm9xSvZfGH/2Tnv4bya2uS7wFoPuAE6l8UzyiqOMJYp2FGjszBRhU8o riaAHi66kBFB3kTjWdAOlDTEnAJ/yfgrysUHRa84XkiQ/huzef0ob40IMcUN4DcKBSyz 1FIbGkxXQQm18RLamQvlwnHm7qa7QfmNY/VlvGMmL/x9vbCTTwJ9tY648wJcXak79Bek 62OZqxsacHYpjdjpkDV/x8YUlCQ9e9glz/buA0dWoxlDPcKjAhHFfBVHjC4mz0GBy1GN LrhMfVs2YZRWEzS2jNALcghVQ6+4ZWor1GegWQNOSDd15bDAoWwHYLMkAGc4wLQtxMwS JJDQ==
X-Received: by 10.68.220.9 with SMTP id ps9mr9724783pbc.38.1363300871223; Thu, 14 Mar 2013 15:41:11 -0700 (PDT)
Received: from dhcp-474b.meeting.ietf.org (dhcp-474b.meeting.ietf.org. [130.129.71.75]) by mx.google.com with ESMTPS id tm1sm5242286pbc.11.2013.03.14.15.41.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 15:41:10 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Chris Wendt 
In-Reply-To: 
Date: Thu, 14 Mar 2013 18:41:09 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: "rtcweb@ietf.org" 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQnxx6v3Zv/yOw18FGJ7CjRGO51Ee+ZpStwNyXrQdI+uOsEglM4R0kfw8FcOtf4VyxTjJ8+/
Subject: Re: [rtcweb] A different perspective on the video codec MTI 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: Thu, 14 Mar 2013 22:41:12 -0000

As mostly an observer over the past year or two, this issue of MTI has =
come a long way, both good and bad. =20

First, I will state, my employer, Comcast, has millions of boxes =
deployed and more in the pipeline where one could imagine webrtc =
capabilities being utilized. =20
Short term, VP8 does pose us the most challenge in terms of either =
suboptimal or total lack of support because of limited cpu/gpu =
capabilities, etc.=20
Longer term, this would be less of an issue, certainly, but perhaps in =
that time frame we will be talking the virtue of a brand new set of =
codecs anyway.

In terms of quality per bit/cpu/transistor, I believe nobody can =
credibly say that either codec is a horrible choice.  To me, any further =
argument or quantitative/perceptual testing on that is wasting time.

IPR, I'm not going to comment, because the clarity of the IPR situation =
is in the eye of the beholder.

While it would be wonderful if everybody agreed on a single video codec, =
I don't see any possibility that one can satisfy all use-cases in any =
practical way.  Whether it's browser to browser or browser to terminal, =
one can argue that her use-case is more valuable than the other, but we =
can't all agree on that either.

To me, the only choice left, and I think many others agree and some have =
stated it already, is either to make both codecs MTI or remove the MTI =
requirement.  The former, likely would take an act of God and for =
various reasons I don't think is the right choice anyway.  So, I would =
strongly encourage the latter, in full acknowledgement that there have =
been decisions made against this. =20
(ASCII codec being a third choice, but I haven't seen the draft )
Note, regardless of either choice, we would likely be required to =
implement both codecs anyway to avoid the transcoding penalty if we want =
to reasonably support interoperability.

In the end, we currently sit in the likely position that the market will =
decide this debate anyway, it already seems to be underway, so why keep =
wasting time debating.  Besides being a complete waste of valuable brain =
cycles, and delaying more important work to resolve, I think it has =
become or is close to becoming much more destructive to the process than =
the value of having a half-supported, forced choice MTI codec.

-Chris



From trac+rtcweb@trac.tools.ietf.org  Thu Mar 14 16:04: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 DD5CB21F8DFC for ; Thu, 14 Mar 2013 16:04:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 pxdexsOoyozI for ; Thu, 14 Mar 2013 16:04:39 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 55E1521F8DF2 for ; Thu, 14 Mar 2013 16:04:39 -0700 (PDT)
Received: from localhost ([127.0.0.1]:60721 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UGHCL-0005NV-7Z; Fri, 15 Mar 2013 00:04:33 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "rtcweb issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-rtcweb-audio@tools.ietf.org, bernard_aboba@hotmail.com
X-Trac-Project: rtcweb
Date: Thu, 14 Mar 2013 23:04:33 -0000
X-URL: http://tools.ietf.org/rtcweb/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/12
Message-ID: <066.e577661121b1333f935325b114453742@trac.tools.ietf.org>
X-Trac-Ticket-ID: 12
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-audio@tools.ietf.org, bernard_aboba@hotmail.com, rtcweb@ietf.org
X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: cary.bran@plantronics.com, jmvalin@jmvalin.ca
Resent-Message-Id: <20130314230439.55E1521F8DF2@ietfa.amsl.com>
Resent-Date: Thu, 14 Mar 2013 16:04:39 -0700 (PDT)
Resent-From: trac+rtcweb@trac.tools.ietf.org
Cc: rtcweb@ietf.org
Subject: [rtcweb]  #12: Support for other existing and future audio codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
List-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, 14 Mar 2013 23:04:40 -0000

#12: Support for other existing and future audio codecs

 Please add the following sentence at the end of the first paragraph in
 Section 3, which would then read as follows:

 "To ensure a baseline level of interoperability between WebRTC
 clients, a minimum set of required codecs are specified below.  While this
 section specifies the codecs that will be mandated for all WebRTC client
 implementations, it leaves the question of supporting additional codecs to
 the will of the implementer.
 Implementers MAY add support for any audio codec and offer these codecs at
 negotiation time.  In other words, all other existing and future audio
 codecs are OPTIONAL."

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-rtcweb-
  bernard_aboba@hotmail.com          |  audio@tools.ietf.org
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:  milestone1
Component:  audio                    |    Version:  1.0
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: 
rtcweb 


From elagerway@gmail.com  Thu Mar 14 17:17: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 162EA11E8104 for ; Thu, 14 Mar 2013 17:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.422
X-Spam-Level: 
X-Spam-Status: No, score=-0.422 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SSLX+mkf0mi for ; Thu, 14 Mar 2013 17:17:38 -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 052F811E80D9 for ; Thu, 14 Mar 2013 17:17:37 -0700 (PDT)
Received: by mail-wi0-f174.google.com with SMTP id hi8so27466wib.7 for ; Thu, 14 Mar 2013 17:17:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Jyefbu25JaH/geNZOOr9r0Ixt14k7lBDjcNC7TqIT98=; b=S85UylK8MXGV4yDi8ATZ2BVdVOEl07mMO8/4P5PPEQrDFWI6zXJepLReU2WEkdSj6f N1tx/AE8QsR+cpacIzUiqMaF97yFroZg3vupKHoDQqDJ4g61BlS8VseOyfWHAEC05VA9 eEN+n2Cf6GSeSVqTf+KBkCmVF4OmlYbUTQ7cwYutZITfu2zGBvRpnlmq+S4ut1O7nHSr 4mnnNyMOGPOPivnCYc8VmhCbs0F3YmgoRrESy68uwMPMgHr2hgYhnJoFHVJRYqTlKLkr MSSBBGRaNoi6zJZhJOCertDqUKelsZoxeBPGBwM3K3GlkuB2rZvNQ2n2HT/am4JrnYU2 +erw==
MIME-Version: 1.0
X-Received: by 10.180.81.2 with SMTP id v2mr21564wix.17.1363306657153; Thu, 14 Mar 2013 17:17:37 -0700 (PDT)
Sender: elagerway@gmail.com
Received: by 10.216.206.65 with HTTP; Thu, 14 Mar 2013 17:17:36 -0700 (PDT)
In-Reply-To: 
References:  
Date: Thu, 14 Mar 2013 17:17:36 -0700
X-Google-Sender-Auth: SG-JxHGejm8f_2WL172rqDkxKnE
Message-ID: 
From: Erik Lagerway 
To: Chris Wendt 
Content-Type: multipart/alternative; boundary=f46d04428296050a3004d7eb91f4
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] A different perspective on the video codec MTI 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, 15 Mar 2013 00:17:40 -0000

--f46d04428296050a3004d7eb91f4
Content-Type: text/plain; charset=ISO-8859-1

+1

Well said Chris, this is pretty much what I wrote earlier today...
http://blog.webrtc.is/2013/03/14/rtcweb-webrtc-mti-video-codec-debate-continues/

The WG has been through this debate many times and it seems rather obvious
that this is not likely to get resolved anytime soon.

Let's remove the MTI video codec requirement now and get on with life.

/Erik
****


On Thu, Mar 14, 2013 at 3:41 PM, Chris Wendt  wrote:

> As mostly an observer over the past year or two, this issue of MTI has
> come a long way, both good and bad.
>
> First, I will state, my employer, Comcast, has millions of boxes deployed
> and more in the pipeline where one could imagine webrtc capabilities being
> utilized.
> Short term, VP8 does pose us the most challenge in terms of either
> suboptimal or total lack of support because of limited cpu/gpu
> capabilities, etc.
> Longer term, this would be less of an issue, certainly, but perhaps in
> that time frame we will be talking the virtue of a brand new set of codecs
> anyway.
>
> In terms of quality per bit/cpu/transistor, I believe nobody can credibly
> say that either codec is a horrible choice.  To me, any further argument or
> quantitative/perceptual testing on that is wasting time.
>
> IPR, I'm not going to comment, because the clarity of the IPR situation is
> in the eye of the beholder.
>
> While it would be wonderful if everybody agreed on a single video codec, I
> don't see any possibility that one can satisfy all use-cases in any
> practical way.  Whether it's browser to browser or browser to terminal, one
> can argue that her use-case is more valuable than the other, but we can't
> all agree on that either.
>
> To me, the only choice left, and I think many others agree and some have
> stated it already, is either to make both codecs MTI or remove the MTI
> requirement.  The former, likely would take an act of God and for various
> reasons I don't think is the right choice anyway.  So, I would strongly
> encourage the latter, in full acknowledgement that there have been
> decisions made against this.
> (ASCII codec being a third choice, but I haven't seen the draft )
> Note, regardless of either choice, we would likely be required to
> implement both codecs anyway to avoid the transcoding penalty if we want to
> reasonably support interoperability.
>
> In the end, we currently sit in the likely position that the market will
> decide this debate anyway, it already seems to be underway, so why keep
> wasting time debating.  Besides being a complete waste of valuable brain
> cycles, and delaying more important work to resolve, I think it has become
> or is close to becoming much more destructive to the process than the value
> of having a half-supported, forced choice MTI codec.
>
> -Chris
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--f46d04428296050a3004d7eb91f4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


+1

Well said Chris, this is pretty much what =
I wrote earlier today...
http://blog.webrtc.is/2013/03=
/14/rtcweb-webrtc-mti-video-codec-debate-continues/



The WG has been through this debate many times and it s=
eems rather obvious that this is not likely to get resolved anytime soon.

Let's remove the MTI video codec requirement no=
w and get on with life.



/Erik
<=
/span>




On Thu, Mar 14, 2013 at 3:41 PM, Chris W=
endt <chris@chriswendt.net> wrote:

As mostly an observer over the past year or two, this issue of MTI has come=
 a long way, both good and bad.



First, I will state, my employer, Comcast, has millions of boxes deployed a=
nd more in the pipeline where one could imagine webrtc capabilities being u=
tilized.

Short term, VP8 does pose us the most challenge in terms of either suboptim=
al or total lack of support because of limited cpu/gpu capabilities, etc.
Longer term, this would be less of an issue, certainly, but perhaps in that=
 time frame we will be talking the virtue of a brand new set of codecs anyw=
ay.



In terms of quality per bit/cpu/transistor, I believe nobody can credibly s=
ay that either codec is a horrible choice. =A0To me, any further argument o=
r quantitative/perceptual testing on that is wasting time.



IPR, I'm not going to comment, because the clarity of the IPR situation=
 is in the eye of the beholder.



While it would be wonderful if everybody agreed on a single video codec, I =
don't see any possibility that one can satisfy all use-cases in any pra=
ctical way. =A0Whether it's browser to browser or browser to terminal, =
one can argue that her use-case is more valuable than the other, but we can=
't all agree on that either.




To me, the only choice left, and I think many others agree and some have st=
ated it already, is either to make both codecs MTI or remove the MTI requir=
ement. =A0The former, likely would take an act of God and for various reaso=
ns I don't think is the right choice anyway. =A0So, I would strongly en=
courage the latter, in full acknowledgement that there have been decisions =
made against this.


(ASCII codec being a third choice, but I haven't seen the draft )

Note, regardless of either choice, we would likely be required to implement=
 both codecs anyway to avoid the transcoding penalty if we want to reasonab=
ly support interoperability.



In the end, we currently sit in the likely position that the market will de=
cide this debate anyway, it already seems to be underway, so why keep wasti=
ng time debating. =A0Besides being a complete waste of valuable brain cycle=
s, and delaying more important work to resolve, I think it has become or is=
 close to becoming much more destructive to the process than the value of h=
aving a half-supported, forced choice MTI codec.




-Chris






_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--f46d04428296050a3004d7eb91f4--

From R.Jesske@telekom.de  Fri Mar 15 02:44: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 2EDC921F91E4 for ; Fri, 15 Mar 2013 02:44:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.949
X-Spam-Level: 
X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_LOAN=2.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 3okPV7RqiyAt for ; Fri, 15 Mar 2013 02:44:40 -0700 (PDT)
Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 78D4121F91AA for ; Fri, 15 Mar 2013 02:44:38 -0700 (PDT)
X-Mailbb-Crypt: true
Received: from he111467.emea1.cds.t-internal.com (HELO he111467) ([10.206.92.85]) by tcmail91.telekom.de with ESMTP/TLS/RC4-MD5; 15 Mar 2013 10:44:35 +0100
Received: from TCMAIL91.dmznet.de.t-internal.com ([10.206.242.136]) by TrustMail (Totemo SMTP Server) with SMTP ID 806; Fri, 15 Mar 2013 10:44:34 +0100 (CET)
X-Mailbb-Crypt: true
X-Mailbb-SentCrypt: true
Received: from he113676.emea1.cds.t-internal.com ([10.134.99.29]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 15 Mar 2013 10:44:32 +0100
Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113676.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 15 Mar 2013 10:44:33 +0100
From: 
To: , , , 
Date: Fri, 15 Mar 2013 10:44:31 +0100
Thread-Topic: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIHAgQ3Oi2P7DjEKDSnUvQoKufpilc9aAgAAGtgCAAH5yAP//tpYYgADR0CA=
Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D16E4408A5A@HE111648.emea1.cds.t-internal.com>
References:  
In-Reply-To: 
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: rtcweb@ietf.org, xavier.marjou@orange.com
Subject: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 15 Mar 2013 09:44:42 -0000

Hi Andrew,
but where will you start and where will you end.
The codec discussion appears now so why not try to solve this now?
And one proposal is to use these codecs and I fully support it.

Roland

> -----Urspr=FCngliche Nachricht-----
> Von: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org]
> Im Auftrag von Andrew Allen
> Gesendet: Donnerstag, 14. M=E4rz 2013 22:10
> An: koen.vos@skype.net; espeberg@cisco.com; stephane.proust@orange.com
> Cc: xavier.marjou@orange.com; rtcweb@ietf.org
> Betreff: Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
>
> Koen is right that there are many more obstacles to RTCweb
> and legacy network interop than just a common codec. First
> there will need to be RTCweb signaling gateways to interface
> between the RTCweb signaling and the legacy networks (SIP,
> H.323 etc) and there will need to be in place mechanisms for
> peering, federation and address resolution between networks
> as well as service agreements in place between the players.
>
> Until those are resolved supporting codecs used in those
> networks is pointless.
>
> Andrew
>
> ----- Original Message -----
> From: Koen Vos [mailto:koen.vos@skype.net]
> Sent: Thursday, March 14, 2013 03:32 PM Central Standard Time
> To: Espen Berger (espeberg) ;
> stephane.proust@orange.com 
> Cc: rtcweb@ietf.org ; MARJOU Xavier OLNC/OLN
> 
> Subject: Re: [rtcweb] Agenda time     request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> > It's interop with billions of mobile phones and with fixed
> terminals in legacy telephony services.
>
> The problem is that WebRTC and legacy services live in
> separate networks: the open Web vs proprietary Telco networks.
>
> WebRTC connecting to a Telco network would have to go through
> a Gateway.  The PSTN termination providers who run these
> Gateways support G.711, G.729 and perhaps some other  codecs
> like iLBC.  They do not, however, support the codecs you are
> advocating for.
>
> The lack of support for Transcoding-Free Operation by Telcos
> to the rest of the world has been hurting interop voice
> quality for a long time, but unfortunately we can't fix that
> here at the IETF.
>
> We can fit our cars with your costly railroad wheels, but you
> still wouldn't let us on your tracks.
>
> koen.
>
>
> -----Original Message-----
> From: rtcweb-bounces@ietf.org
> [mailto:rtcweb-bounces@ietf.org] On Behalf Of
> stephane.proust@orange.com
> Sent: 14. mars 2013 13:36
> To: Jean-Marc Valin
> Cc: rtcweb@ietf.org; MARJOU Xavier OLNC/OLN
> Subject: Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> Hello
>
> The short list is aligned to what is specified in 3GPP
> (mobile) and CAT-iq (fixed). Check the related service specifications!
> The short list (AMR, AMR-WB, G.722) is a minimal subset of
> codecs to minimize interop issues and transcoding costs for
> telco services.
> It's not a question of what's the favourite codec for a given
> application. It's interop with billions of mobile phones and
> with fixed terminals in legacy telephony services.
>
> St=E9phane
>
> -----Message d'origine-----
> De : Jean-Marc Valin [mailto:jmvalin@mozilla.com] Envoy=E9 :
> jeudi 14 mars 2013 05:55 =C0 : PROUST Stephane OLNC/OLPS Cc :
> Andrew Allen; Markus.Isomaki@nokia.com; MARJOU Xavier
> OLNC/OLN; rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time
> request for draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/13/2013 06:48 PM, stephane.proust@orange.com wrote:
> > The reason is simply that AMR and AMR-WB are supported in
> billions of
> > devices !
>
> Just curious, why exclude from the list other codecs with
> similar huge deployment? I can think of at least:
> - - GSM-FR (mobile)
> - - Speex (Flash)
> - - G.729 (PSTN gateways)
> - - iLBC (PSTN gateways)
> - - G.726 (DECT)
> - - SILK (original non-Opus version in Skype)
>
> (sorry, if I missed someone's favorite codec in this list)
>
> It's not at all clear to me what's so special that makes AMR,
> AMR-WB and G.722 different from the other codecs in the list
> above. Not that I insist on shipping G.729 :-)
>
> Personally, I'd favor a draft that included a lot more
> codecs, describing for each one the benefits of supporting
> it. Implementers could then choose which of these they care
> about for their particular situation.
>
> Cheers,
>
>         Jean-Marc
>
> > St=E9phane
> >
> >
> > -----Message d'origine----- De : Andrew Allen
> > [mailto:aallen@blackberry.com] Envoy=E9 : mercredi 13 mars 2013
> > 23:41 =C0 : PROUST Stephane OLNC/OLPS; Markus.Isomaki@nokia.com;
> > jmvalin@mozilla.com Cc : MARJOU Xavier OLNC/OLN;
> rtcweb@ietf.org Objet
> > : Re: [rtcweb] Agenda time request for
> > draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> >
> > No this wouldn't be acceptable to me.
> >
> > I don't see a reason to push a particular set of Codecs
> over any other
> > set of codecs supported on the device. If the device supports the
> > codecs and they are available to the browser then we should
> recommend
> > that they be offered in the negotiation.
> >
> > The marjou draft can advertise the merits and reasons why they are
> > good codecs to support.
> >
> >
> > ----- Original Message ----- From: stephane.proust@orange.com
> > [mailto:stephane.proust@orange.com] Sent: Wednesday, March 13, 2013
> > 05:14 PM Central Standard Time To: Markus.Isomaki@nokia.com
> > ; jmvalin@mozilla.com
> 
> > Cc: MARJOU Xavier OLNC/OLN ;
> rtcweb@ietf.org
> > 
> > Subject: Re: [rtcweb] Agenda time     request for
> > draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> > Dear Markus
> >
> > Thanks for your attempt to help !
> >
> > Of course each Telco can handle this directly with vendors and
> > browsers manufacturers at business level. But I don't'think
> this need
> > of interoperability with mobile devices is specific to Orange.
> > I think all mobile operators will have the same issue and
> this is why
> > standardization exist. It's most cost and time efficient to
> have one
> > common way forward for all the industry.
> >
> > Then if the issue is that "conditional MUST/SHOULD are a too
> > complicated requirement. We could also live as a compromise with a
> > formulation that has already been suggested on the reflector:
> >
> > "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" If possible with the addition of This is
> especially
> > the case for AMR, AMR-WB for interoperability with mobile
> devices and
> > G.722 for interoperability with fixed DECT CAT-iq devices
> >
> > Would it have one chance to reach consensus ?
> >
> > I think this Group should at least make one small step so that the
> > interoperability issue with mobile terminals be not fully
> ignored in
> > the RTC Web specification considering the huge number of deployed
> > devices. At least something must be written on this !
> > G.711 which is the only codec in addition to OPUS for
> interoperability
> > purpose is not a proper answer to this.
> >
> > St=E9phane
> >
> > -----Message d'origine----- De : Markus.Isomaki@nokia.com
> > [mailto:Markus.Isomaki@nokia.com] Envoy=E9 : mercredi 13 mars 2013
> > 22:37 =C0 : PROUST Stephane OLNC/OLPS; jmvalin@mozilla.com; MARJOU
> > Xavier OLNC/OLN Cc : rtcweb@ietf.org Objet : RE: [rtcweb]
> Agenda time
> > request for draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> > Hi Stephane, Xavier,
> >
> > I understand the intent of your proposal. I'm not sure if
> the IETF is
> > the best venue for you to pursue it, however. Perhaps you
> as a mobile
> > operator should rather set it as a requirement to your
> mobile device
> > platforms that they open up the APIs to AMR and AMR-WB and that at
> > least the in-built default browser needs to support it. If
> there are
> > enough operators setting such requirements directly to the
> device and
> > platform vendors, it probably has a bigger impact than an IETF RFC.
> > Getting that support for user-installed additional browsers
> might be
> > more difficult, but most mobile device users stick with the default
> > browser anyway.
> >
> > The RTCWEB codec document needs to definitely explain this case and
> > the benefits, but the conditional MUSTs or SHOULDs you are
> proposing
> > are perhaps a bit too complicated. Hmm, perhaps we need to do an
> > _informational_ RFC as something like "Recommendations for
> WebRTC on
> > Mobile Devices" addressing the codec and perhaps other issues, that
> > you could use as a reference in your requirements.
> >
> > Markus
> >
> >
> >> -----Original Message----- From: rtcweb-bounces@ietf.org
> >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext
> >> stephane.proust@orange.com Sent: 13 March, 2013 21:37 To:
> >> Jean-Marc Valin; MARJOU Xavier OLNC/OLN Cc: rtcweb@ietf.org
> >> Subject: Re: [rtcweb] Agenda time request for
> >> draft-marjou-rtcweb-audio- codecs-for-interop-01
> >>
> >> Hello
> >>
> >> Our understanding is that the reason of the "no consensus" on
> >> additional recommended codecs was the additional costs for
> browsers.
> >> The proposal is then to make these "MUST" fully conditional to the
> >> case of no (or very reduced) additional costs, when the codecs are
> >> already available on the device and when no additional
> license fee is
> >> required
> >>
> >> We could even live with lower level of "requirements" with
> >> respectively May and Should (instead of Should and shall) but we
> >> think that this proposal is a way to take into account
> both browser
> >> manufacturers concerns on browsers costs and telcos concerns on
> >> transcoding costs and some other companies share this view.
> >>
> >> St=E9phane
> >>
> >>
> >>
> >>
> >>
> >>
> >> -----Message d'origine----- De : rtcweb-bounces@ietf.org
> >> [mailto:rtcweb-bounces@ietf.org] De la part de Jean-Marc
> Valin Envoy=E9
> >> : mercredi 13 mars 2013 20:24 =C0 : MARJOU Xavier OLNC/OLN Cc :
> >> rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time request for
> >> draft-marjou-rtcweb-audio-codecs-for-interop-01
> >>
> > Hi,
> >
> > I'd really like to understand how the chairs coming to the
> conclusion
> > that there was *no consensus* on recommended codecs can result in a
> > draft that includes 3 MUSTs and 1 SHOULD. This draft
> effectively makes
> > 3 new codecs MTI for a range of devices. I understand that it's an
> > individual draft and you can write whatever you like in
> there, but it
> > definitely goes against the result of the WG discussion.
> >
> > Cheers,
> >
> > Jean-Marc
> >
> > On 03/13/2013 09:14 AM, Xavier Marjou wrote:
> >>>> Here is a summary of the
> >>>> draft-marjou-rtcweb-audio-codecs-for-interop-00
> presentation that I
> >>>> had prepared for yesterday's session:
> >>>>
> >>>> - The co-authors want to underline that non-WebRTC voice
> endpoints
> >>>> usually use one of the following codecs: AMR, AMR-WB or G.722,
> >>>> which will result in massive transcoding when there will be
> >>>> communications between WebRTC endpoints and non-WebRTC endpoints.
> >>>>
> >>>> - On one side, transcoding is bad for many reasons
> discussed in the
> >>>> draft (cost issues, intrinsic quality degradation, degraded
> >>>> interactivity, fallback from HD to G.711...);
> >>>>
> >>>> - On the other side, it is recognized that implementing
> additional
> >>>> codecs in the browsers can generate additional costs.
> >>>>
> >>>> - In order to reach a compromise, we would like to add
> some text in
> >>>> the WG draft draft-ietf-rtcweb-audio providing
> incentives for the
> >>>> browser to use these three codecs: make them mandatory
> to implement
> >>>> when there is no cost impact on the browser (e.g. if
> codec already
> >>>> installed, paid by the device vendor...).
> >>>>
> >>>> Any opinion on that?
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Xavier
> >>>>
> >>>> PS: I will be ready to present the slides on Thursday if time
> >>>> permits it.
> >>>>
> >>>> (c.f.
> >>>> http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf
> >>>>
> >>>>
> )
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie  >>>> > wrote:
> >>>>
> >>>> Magnus and I discussed this this morning, and we
> encourage you to
> >>>> prepare something.  If the discussion of working group last call
> >>>> items runs short, we may be able to fit this in at that
> time or at
> >>>> the end of day one if its full agenda his finished.
> This is not a
> >>>> commitment, however, so please try and get discussion on
> the list
> >>>> on the points from the draft you feel need resolution.
> >>>>
> >>>> regards,
> >>>>
> >>>> Ted
> >>>>
> >>>>
> >>>> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)
> >>>> > wrote:
> >>>>> Hello,
> >>>>>
> >>>>>
> >>>>>
> >>>>> I would like to request agenda time for:
> >>>>>
> >>>>>
> >>>>>
> >>>>> draft-marjou-rtcweb-audio-codecs-for-interop-01
> >>>>>
> >>>>>
> >>>>>
> >>>>> The document  presents use-cases underlining why WebRTC needs
> >>>> AMR-WB,  AMR
> >>>>> and G.722 as additional relevant voice codecs to satisfactorily
> >>>>> ensure interoperability with existing systems.
> >>>>>
> >>>>>
> >>>>>
> >>>>> A 10-minute time slot should be sufficient for presentation and
> >>>> discussion.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Regards
> >>>>>
> >>>>>
> >>>>>
> >>>>> -Espen
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________ 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
> >>
> >> ___________________________________________________________
> >> ___________________________________________________________ ___
> >>
> >> Ce message et ses pieces jointes peuvent contenir des informations
> >> confidentielles ou privilegiees et ne doivent donc pas
> etre diffuses,
> >> exploites ou copies sans autorisation. Si vous avez recu
> ce message
> >> par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> >> que les pieces jointes. Les messages electroniques etant
> susceptibles
> >> d'alteration, France Telecom - Orange decline toute
> responsabilite si
> >> ce message a ete altere, deforme ou falsifie. Merci.
> >>
> >> This message and its attachments may contain confidential or
> >> privileged information that may be protected by law; they
> should not
> >> be distributed, used or copied without authorisation. If you have
> >> received this email in error, please notify the sender and delete
> >> this message and its attachments. As emails may be altered, France
> >> Telecom - Orange is not liable for messages that have been
> modified,
> >> changed or falsified. Thank you.
> >>
> >> _______________________________________________ rtcweb
> mailing list
> >> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> ______________________________________________________________________
> > ___________________________________________________
> >
> >  Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> > que les pieces jointes. Les messages electroniques etant
> susceptibles
> > d'alteration, France Telecom - Orange decline toute
> responsabilite si
> > ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they
> should not
> > be distributed, used or copied without authorisation. If you have
> > received this email in error, please notify the sender and
> delete this
> > message and its attachments. As emails may be altered,
> France Telecom
> > - Orange is not liable for messages that have been
> modified, changed
> > or falsified. Thank you.
> >
> > _______________________________________________ rtcweb mailing list
> > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> ---------------------------------------------------------------------
> >
> >
> This transmission (including any attachments) may contain
> confidential information, privileged material (including
> material protected by the solicitor-client or other
> applicable privileges), or constitute non-public information.
> Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender
> and delete this information from your system. Use,
> dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and
> may be unlawful.
> >
> >
> ______________________________________________________________________
> > ___________________________________________________
> >
> >  Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> > que les pieces jointes. Les messages electroniques etant
> susceptibles
> > d'alteration, France Telecom - Orange decline toute
> responsabilite si
> > ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they
> should not
> > be distributed, used or copied without authorisation. If you have
> > received this email in error, please notify the sender and
> delete this
> > message and its attachments. As emails may be altered,
> France Telecom
> > - Orange is not liable for messages that have been
> modified, changed
> > or falsified. Thank you.
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJRQVgzAAoJEJ6/8sItn9q9fgYH/jcWfhRrvPM1hJ22YcE7eR0N
> OZzP/RvSrUBiIA6kG+6+Hvn5Lp/tXd+LxUDp5L8B3Toce7TBBAYNJP3M2cr8N8It
> SjVvPHtBNKEqhBLbI4FbAouvymNH4utjAWR+MmF9LRySPXZ9nxLN0A13TeUlpZxt
> Jaxr/n9AWwkKOk6BIo1Xztbk26MObiGVLhCE+CPoHaHe29bKblPcphBXC935ymHS
> SuF2DXiAq0iKwZoVOsLe3RIaGg+bjN7N2MXi3Vphr7cOQK+JpdxURDrvmPh7/L8R
> ht1RJt928yl4fEjnKhSKJLd1J+gPBe6vnkSxUp89as03bLirLwN1G2giD3YzfLM=3D
> =3DK56v
> -----END PGP SIGNATURE-----
>
> ______________________________________________________________
> ___________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des
> informations confidentielles ou privilegiees et ne doivent
> donc pas etre diffuses, exploites ou copies sans
> autorisation. Si vous avez recu ce message par erreur,
> veuillez le signaler a l'expediteur et le detruire ainsi que
> les pieces jointes. Les messages electroniques etant
> susceptibles d'alteration, France Telecom - Orange decline
> toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they
> should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the
> sender and delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not
> liable for messages that have been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> 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
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain
> confidential information, privileged material (including
> material protected by the solicitor-client or other
> applicable privileges), or constitute non-public information.
> Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender
> and delete this information from your system. Use,
> dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and
> may be unlawful.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

From harald@alvestrand.no  Fri Mar 15 05:00: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 38CE121F9164 for ; Fri, 15 Mar 2013 05:00:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.264
X-Spam-Level: 
X-Spam-Status: No, score=-109.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, 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 kvEy7uxb0Yrk for ; Fri, 15 Mar 2013 05:00:11 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5D52A21F9161 for ; Fri, 15 Mar 2013 05:00:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 10B8B39E130; Fri, 15 Mar 2013 13:00:10 +0100 (CET)
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 Dox75eo38yzb; Fri, 15 Mar 2013 13:00:08 +0100 (CET)
Received: from [10.184.11.202] (host-95-199-139-202.mobileonline.telia.com [95.199.139.202]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 596EE39E03A; Fri, 15 Mar 2013 13:00:07 +0100 (CET)
User-Agent: K-9 Mail for Android
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----B6KH5HPWWJ65SE986YX89C804XWN5Y"
From: Harald Alvestrand 
Date: Fri, 15 Mar 2013 11:19:11 +0100
To: Bo Burman ,"rtcweb@ietf.org" 
Message-ID: <547ec7c4-976d-4076-900e-b67da5dae0d3@email.android.com>
Subject: Re: [rtcweb] Cross-check of Google VP8 vs H.264 comparison
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 15 Mar 2013 12:00:12 -0000

------B6KH5HPWWJ65SE986YX89C804XWN5Y
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 8bit

Bo, did you run tests on our clips or your own clips, and with the rest of the settings our way or your way? Clip selection seems to matter a lot - which is why we published ours.

Bo Burman  wrote:

>
>Hi,
>
>As said on the microphone today, we have cross-checked Google's VP8 vs
>H.264 comparison. Google reported bit rate gains for VP8 of 19%.
>However, the H.264 was at an unfair advantage due to the fact that the
>--tune psnr flag was not used in x264. This should of course be used
>when doing psnr-measurements. For vp8, this flag is set to psnr by
>default. 
>
>When re-running the tests with --tune psnr for x264, and using version
>130 of x264 instead of version 128 that was used in the Google test,
>the difference disappeared (1% difference). 
>
>Cheers,
>Bo
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
------B6KH5HPWWJ65SE986YX89C804XWN5Y
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: 8bit

Bo, did you run tests on our clips or your own clips, and with the rest of the settings our way or your way? Clip selection seems to matter a lot - which is why we published ours.

Bo Burman <bo.burman@ericsson.com> wrote:



Hi,

As said on the microphone today, we have cross-checked Google's VP8 vs H.264 comparison. Google reported bit rate gains for VP8 of 19%. However, the H.264 was at an unfair advantage due to the fact that the --tune psnr flag was not used in x264. This should of course be used when doing psnr-measurements. For vp8, this flag is set to psnr by default. 

When re-running the tests with --tune psnr for x264, and using version 130 of x264 instead of version 128 that was used in the Google test, the difference disappeared (1% difference). 

Cheers,
Bo

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


-- 

Sent from my Android phone with K-9 Mail. Please excuse my brevity.
------B6KH5HPWWJ65SE986YX89C804XWN5Y--


From adam@nostrum.com  Fri Mar 15 05:42: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 2029521F9138 for ; Fri, 15 Mar 2013 05:42:20 -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 NSDG8dplX17V for ; Fri, 15 Mar 2013 05:42:19 -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 7BE5221F905F for ; Fri, 15 Mar 2013 05:42:19 -0700 (PDT)
Received: from dhcp-5033.meeting.ietf.org (dhcp-5033.meeting.ietf.org [130.129.80.51]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2FCgECJ052245 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 15 Mar 2013 07:42:15 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <51431729.10608@nostrum.com>
Date: Fri, 15 Mar 2013 08:42:17 -0400
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Andrew Allen 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 130.129.80.51 is authenticated by a trusted mechanism)
Cc: "rtcweb@ietf.org" , "xavier.marjou@orange.com" 
Subject: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 15 Mar 2013 12:42:20 -0000

On 3/14/13 17:09, Andrew Allen wrote:
> Koen is right that there are many more obstacles to RTCweb and legacy network interop than just a common codec. First there will need to be RTCweb signaling gateways to interface between the RTCweb signaling and the legacy networks (SIP, H.323 etc) and there will need to be in place mechanisms for peering, federation and address resolution between networks as well as service agreements in place between the players.


We had this mostly working at the SIPit in Boston, using the SIP over 
Websockets spec. The only reason we weren't actually setting calls up 
was that we couldn't find any clients there that supported both ICE and 
DTLS-SRTP. What's neat is that this isn't even really "gatewaying" in 
the way that you mean it -- all you need is a SIP proxy that supports 
one more (easy-to-implement) transport protocol.

And once you hit that proxy, all of the peering, federation, and address 
resolution solutions developed for SIP apply.

I don't think this points to a need to push AMR into the web browsers, 
mind you. To take Justin's earlier point a few steps further: if we're 
going on number of shipping units, the mere existence of Chrome and 
Firefox's WebRTC implementation means that the number of deployed Opus 
codecs far overwhelms the number of deployed AMR codecs. Appeals to the 
size of codec deployment would more reasonably reach the conclusion that 
Opus should be MTI for the next 3GPP release. ;-)

/a

From denglingli@chinamobile.com  Fri Mar 15 05:55: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 D86CB21F9142 for ; Fri, 15 Mar 2013 05:55:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.076
X-Spam-Level: 
X-Spam-Status: No, score=0.076 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 a493QKydcy6m for ; Fri, 15 Mar 2013 05:55:33 -0700 (PDT)
Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 2C56821F913E for ; Fri, 15 Mar 2013 05:55:31 -0700 (PDT)
Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee151431a24915-12915; Fri, 15 Mar 2013 20:55:00 +0800 (CST)
X-RM-TRANSID: 2ee151431a24915-12915
Received: from cmccPC (unknown[172.16.20.82]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee351431a1d91d-406e2; Fri, 15 Mar 2013 20:54:59 +0800 (CST)
X-RM-TRANSID: 2ee351431a1d91d-406e2
From: =?utf-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= 
To: "'Harald Alvestrand'" , "'Bo Burman'" , 
References:  <547ec7c4-976d-4076-900e-b67da5dae0d3@email.android.com>
In-Reply-To: <547ec7c4-976d-4076-900e-b67da5dae0d3@email.android.com>
Date: Fri, 15 Mar 2013 20:55:17 +0800
Message-ID: <037501ce217c$59727e20$0c577a60$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0376_01CE21BF.6795BE20"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac4hdnhjUXO6aYJDRd6tXlbpNM1tMgAAWqDQ
Content-Language: zh-cn
Subject: [rtcweb] =?utf-8?b?562U5aSNOiAgQ3Jvc3MtY2hlY2sgb2YgR29vZ2xlIFZQ?= =?utf-8?q?8_vs_H=2E264_comparison?=
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 15 Mar 2013 12:55:34 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0376_01CE21BF.6795BE20
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi Bo and Harald,

=20

To be honest, from the perspective of a user, I really don=E2=80=99t see =
real difference between these two or the reason to do further quality =
tests. (PSNR is not the best choice to do objective tests, let alone =
objective tests are not to be replaced by subjective tests.)

=20

I am not a codec expert either. But I have both seen cool face-time and =
bad voip apps using software H.264, as well as really cool RCS app demos =
using VP8 (not as bad as yesterday=E2=80=99s show). And I am sure Google =
would cover it up for mobile devices should VP8 was chose to be MTI.

=20

I voted for H.264 yesterday. And here are my thoughts:

=20

First of all, I would definitely not go with no MTI option. Since we =
have seen real-time transcoding simply for audio calls can eat up to 75% =
throughput of an interop gateway in our network. No one would expect =
anything better for high-quality video transcoding, I suppose. =
That=E2=80=99s expensive~

=20

On the top of my list in considering the suitable MTI codec would be:=20

1)       To VP8, my concern is whether or not the other patent holders =
would hold me responsible if I provide the service?

2)       To H.264, my concern is  whether or not the device platforms =
would open sufficient API for browsers to allow good-quality video =
communication? And of course if the patent holders would hold me =
responsible if I provide the service?

3)       To both, a further concern is whether or not the cost for =
interop with legacy systems is easy and cheap?

=20

Since no clear answers are provided for questions 1) or 2), I chose to =
go with the answer to 3). Because the most existing systems and =
end-points supports H.264. At this moment, I have no choice but to live =
with it, at least for some time unless someone resolves questions 1) or =
2) for me^^

=20

BR

Lingli

China Mobile

=20

=E5=8F=91=E4=BB=B6=E4=BA=BA: rtcweb-bounces@ietf.org =
[mailto:rtcweb-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Harald Alvestrand
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B43=E6=9C=8815=E6=97=A5 =
18:19
=E6=94=B6=E4=BB=B6=E4=BA=BA: Bo Burman; rtcweb@ietf.org
=E4=B8=BB=E9=A2=98: Re: [rtcweb] Cross-check of Google VP8 vs H.264 =
comparison

=20

Bo, did you run tests on our clips or your own clips, and with the rest =
of the settings our way or your way? Clip selection seems to matter a =
lot - which is why we published ours.

Bo Burman  wrote:


Hi,

As said on the microphone today, we have cross-checked Google's VP8 vs =
H.264 comparison. Google reported bit rate gains for VP8 of 19%. =
However, the H.264 was at an unfair advantage due to the fact that the =
--tune psnr flag was not used in x264. This should of course be used =
when doing psnr-measurements. For vp8, this flag is set to psnr by =
default.=20

When re-running the tests with --tune psnr for x264, and using version =
130 of x264 instead of version 128 that was used in the Google test, the =
difference disappeared (1% difference).=20

Cheers,
Bo

  _____ =20


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


--=20
Sent from my Android phone with K-9 Mail. Please excuse my brevity.


------=_NextPart_000_0376_01CE21BF.6795BE20
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Hi Bo and Harald,
 
To be honest, from the perspective of a user, I really don=E2=80=99t =
see real difference between these two or the reason to do further =
quality tests. (PSNR is not the best choice to do objective tests, let =
alone objective tests are not to be replaced by subjective =
tests.)
 
I am not a codec expert either. But I have both seen cool face-time =
and bad voip apps using software H.264, as well as really cool RCS app =
demos using VP8 (not as bad as yesterday=E2=80=99s show). And I am sure =
Google would cover it up for mobile devices should VP8 was chose to be =
MTI.
 
I voted for H.264 yesterday. And here are my =
thoughts:
 
First of all, I would definitely not go with no MTI option. Since we =
have seen real-time transcoding simply for audio calls can eat up to 75% =
throughput of an interop gateway in our network. No one would expect =
anything better for high-quality video transcoding, I suppose. =
That=E2=80=99s expensive~
 
On the top of my list in considering the suitable MTI codec would be: =

1)       =
To VP8, my concern is whether or not the other patent holders would =
hold me responsible if I provide the service?
2)       =
To H.264, my concern is=C2=A0 whether or not the device platforms =
would open sufficient API for browsers to allow good-quality video =
communication? And of course if the patent holders would hold me =
responsible if I provide the service?
3)       =
To both, a further concern is whether or not the cost for interop =
with legacy systems is easy and cheap?
 
Since no clear answers are provided for questions 1) or 2), I chose =
to go with the answer to 3). Because the most existing systems and =
end-points supports H.264. At this moment, I have no choice but to live =
with it, at least for some time unless someone resolves questions 1) or =
2) for me^^
 
BR
Lingli
China Mobile
 
 
Bo, =
did you run tests on our clips or your own clips, and with the rest of =
the settings our way or your way? Clip selection seems to matter a lot - =
which is why we published ours.
Bo Burman <bo.burman@ericsson.com> =
wrote:

Hi,

As said on the =
microphone today, we have cross-checked Google's VP8 vs H.264 =
comparison. Google reported bit rate gains for VP8 of 19%. However, the =
H.264 was at an unfair advantage due to the fact that the --tune psnr =
flag was not used in x264. This should of course be used when doing =
psnr-measurements. For vp8, this flag is set to psnr by default. =


When re-running the tests with --tune psnr for x264, and using =
version 130 of x264 instead of version 128 that was used in the Google =
test, the difference disappeared (1% difference). =


Cheers,
Bo

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

-- 
Sent from my Android =
phone with K-9 Mail. Please excuse my =
brevity.

------=_NextPart_000_0376_01CE21BF.6795BE20--




From xavier.marjou@gmail.com  Fri Mar 15 06: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 C30F221F8533 for ; Fri, 15 Mar 2013 06:51:10 -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 5ar7VVBfACNN for ; Fri, 15 Mar 2013 06:51:10 -0700 (PDT)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id EE21D21F853D for ; Fri, 15 Mar 2013 06:51:06 -0700 (PDT)
Received: by mail-la0-f43.google.com with SMTP id ek20so3789868lab.16 for ; Fri, 15 Mar 2013 06:51:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jzqJmQpiGTyErLjUEvLESS5bLXcSy8MHj3a4c+cb4pw=; b=kiF93c6jQvG/Xs1MCnfuNzfpVroSk+AYjyhwM2BELzq/7pRNBXmbeuceo2auo9NILc s7WpoOpsuWBKckxcwtwXPMbOMcys7wBK7Ib8ZsdhR99YvYfgtSJVpmKqdCclJzsnqjRd NoFcMZhIwMPcqunPff1F8aD5n+V+wW0Q7KoYBPga3c/x9QI5baQ62kg2RQEtYuwjxQig 9hWlRg7LBB0zUXE/dHoCb7mIYb7eE2G9Y8Tell1ZioM9xWN5jmT6P17gRIiCg4CDeeNt RJ3HgO9ijLmtmc5irEaDTCO66BNlQl01M6cCHEhixNODkxgJ0ENxkYil9+cF38x1noEr EogA==
MIME-Version: 1.0
X-Received: by 10.152.133.67 with SMTP id pa3mr5686171lab.44.1363355465927; Fri, 15 Mar 2013 06:51:05 -0700 (PDT)
Received: by 10.114.7.167 with HTTP; Fri, 15 Mar 2013 06:51:05 -0700 (PDT)
In-Reply-To: <51431729.10608@nostrum.com>
References:  <51431729.10608@nostrum.com>
Date: Fri, 15 Mar 2013 14:51:05 +0100
Message-ID: 
From: Xavier Marjou 
To: Adam Roach 
Content-Type: multipart/alternative; boundary=f46d0434c3963fd98704d7f6eeb5
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 15 Mar 2013 13:51:10 -0000

--f46d0434c3963fd98704d7f6eeb5
Content-Type: text/plain; charset=ISO-8859-1

Again, this threads deals with interoperability (i.e. communications
between a WebRTC device and a non-WebRTC device).
Non-WebRTC devices mean nearly all of existing phones in the world; they
are already deployed and there's no way to upgrade them all with OPUS on
them.

Xavier

On Fri, Mar 15, 2013 at 1:42 PM, Adam Roach  wrote:

>
> I don't think this points to a need to push AMR into the web browsers,
> mind you. To take Justin's earlier point a few steps further: if we're
> going on number of shipping units, the mere existence of Chrome and
> Firefox's WebRTC implementation means that the number of deployed Opus
> codecs far overwhelms the number of deployed AMR codecs. Appeals to the
> size of codec deployment would more reasonably reach the conclusion that
> Opus should be MTI for the next 3GPP release. ;-)
>
> /a
>
>

--f46d0434c3963fd98704d7f6eeb5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Again, this threads deals with interoperability (i.e. c=
ommunications between a WebRTC device and a non-WebRTC device).=A0
Non-WebRTC devices mean nearly all of existing phones in the world; they =
are already deployed and there's no way to upgrade them all with OPUS o=
n them.



Xavier

On Fri, Mar 15=
, 2013 at 1:42 PM, Adam Roach <adam@nostrum.com> wrote:




I don't think this points to a need to push AMR into the web browsers, =
mind you. To take Justin's earlier point a few steps further: if we'=
;re going on number of shipping units, the mere existence of Chrome and Fir=
efox's WebRTC implementation means that the number of deployed Opus cod=
ecs far overwhelms the number of deployed AMR codecs. Appeals to the size o=
f codec deployment would more reasonably reach the conclusion that Opus sho=
uld be MTI for the next 3GPP release. ;-)




/a



--f46d0434c3963fd98704d7f6eeb5--

From prvs=778627bb81=aallen@blackberry.com  Fri Mar 15 06:55: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 4717821F85A1 for ; Fri, 15 Mar 2013 06:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.185
X-Spam-Level: 
X-Spam-Status: No, score=-5.185 tagged_above=-999 required=5 tests=[AWL=0.018,  BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 QS8bjxTsLX4x for ; Fri, 15 Mar 2013 06:55:30 -0700 (PDT)
Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBC221F859A for ; Fri, 15 Mar 2013 06:55:29 -0700 (PDT)
X-AuditID: 0a412830-b7ef86d00000339d-e0-51432841f108
Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id D4.A1.13213.24823415; Fri, 15 Mar 2013 08:55:14 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.02.0328.009; Fri, 15 Mar 2013 08:55:13 -0500
From: Andrew Allen 
To: "HKaplan@acmepacket.com" 
Thread-Topic: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIHAgQ3Oi2P7DjEKDSnUvQoKufpilc9aAgAAGtgCAAH5yAP//tpYYgABsYoCAAKyWnw==
Date: Fri, 15 Mar 2013 13:55:13 +0000
Message-ID: 
In-Reply-To: <21233D03-64FD-43D0-863E-18FC55BD0924@acmepacket.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.253]
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOKsWRmVeSWpSXmKPExsXC5Zyvpeuk4RxoMOOmpMWXhmSLuZefs1u0 /vzGbLH2XzuQNeMKm8WRrWuZHdg8Nk3ezOYx5fdGVo8lS34yebQ8O8nmcevBJLYA1qgGRpuk xJKy4Mz0PH07m8S8vPySxJJUhZTU4mRbJZ/U9MQchYCizLLE5EoFl8zi5JzEzNzUIiWFzBRb JRMlhYKcxOTU3NS8ElulxIKC1LwUJTsuBQxgA1SWmaeQmpecn5KZl26r5Bnsr2thYWqpa6hk p5vQyZNxYU4za8Fz6Yo9+26wNTBeE+ti5OSQEDCR2DDtAguELSZx4d56ti5GLg4hgTYmicWz 9rBDOJsZJebd6QarYhPQkth/eDoTiC0iYCrx93I3WAezwFdGiS3rjgIVcXAIC8RLNJ8qhKhJ kJjyYw4zhB0m0d50mxHEZhFQlVi/cjkriM0r4CHx4MVOJpBWTgEniT3Py0DCjAKyErvPXgdb xSwgLnHryXwmiEMFJJbsOc8MYYtKvHz8jxXCVpT4u/c7K0S9nsSNqVPYIGxtiWULXzNDrBKU ODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjEK5mYUG5gZJucl6xVl5urlpZZsYgSlFEcNgx2M 799bHGIU4GBU4uHNEXMOFGJNLCuuzD3EKMHBrCTC+/GiU6AQb0piZVVqUX58UWlOavEhRldg QExkluJOzgemu7ySeGMDA9wcJXHeMk2gIQLpwOSTnZpakFoEM4eJgxNkD5eUSDEwhaQWJZaW ZMSDEl18MTDVSTUw9rkqlm3KrDt94JzluhlT3vuxMLCvuC0UL/jL4t1+Gf+yv/YLjj/+MVXk wNlFaY8fHa49cCsmLnC/151ilo0zJ6R+1Hf8FvGzavuCDU2nC/K71qw1D354weel01yZuB25 l+19j326LrltV8Hm9+tdAn/KX50jFmmz4W2LYlvstIJjbx+cuGGZvlaJpTgj0VCLuag4EQAt +bzRagMAAA==
Cc: "rtcweb@ietf.org" , "xavier.marjou@orange.com" 
Subject: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 15 Mar 2013 13:55:31 -0000

My response was directed to the current deployment situation and the comment=
/concern that currently the pre standard RTCweb browser implementations do n=
ot support Codecs used in some legacy networks.

While the technology may be there and the products even available they are n=
ot widely deployed today so currently there is not a business case for brows=
er vendors to include these codecs as today practical interoperability is no=
t possible.

Right now browser implementors are focused solely on achieving interoperabil=
ity between browsers I expect. The additional codecs for legacy interop will=
 I expect come in the future when the infrastructure is deployed to make thi=
s possible and if the right business case is there to make it commercially v=
iable.

Andrew

----- Original Message -----
From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]
Sent: Thursday, March 14, 2013 05:37 PM Central Standard Time=0A=
To: Andrew Allen
Cc: koen.vos@skype.net ; espeberg@cisco.com ; stephane.proust@orange.com ; xavier.ma=
rjou@orange.com ; rtcweb@ietf.org 
Subject: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-code=
cs-for-interop-01


On Mar 14, 2013, at 5:09 PM, Andrew Allen 
 wrote:

> Koen is right that there are many more obstacles to RTCweb and legacy netw=
ork interop than just a common codec. First there will need to be RTCweb sig=
naling gateways to interface between the RTCweb signaling and the legacy net=
works (SIP, H.323 etc) and there will need to be in place mechanisms for pee=
ring, federation and address resolution between networks as well as service=
 agreements in place between the players.
> 
> Until those are resolved supporting codecs used in those networks is point=
less.

There are already WebRTC-SIP gateways, as I think you know.  I know of two S=
BC vendors who are in customer labs with it, for example, and there are prob=
ably more.  And yes at least one of them, and probably both, can transcode t=
he audio... though it's by no means free.  I don't know if the business case=
 justifies the cost or not for WebRTC use-cases - it appears to in some case=
s, not others.

It costs far more than has been discussed on this list though, because we th=
ink like engineers and consider the cost as a CAPEX issue; whereas in practi=
ce the OPEX costs often dwarf the CAPEX ones.  In some data centers, for exa=
mple, the local Real-Estate costs dwarf CAPEX too, and using less rack-space=
 can pay for a product in no time. (there's an entire company out there that=
 built its business leveraging this fact, replacing POTS switches with much-=
higher-density ones purely based on rack-space usage savings)

Anyway... moving on to your other point of federation/peering/etc. - I think=
 the use-case that mobile operators have in mind is fairly obvious, and it c=
learly doesn't have that problem.  Whether you agree with helping that use-c=
ase or not is up to you and the rest of this WG, of course.  I'm just noting=
 that peering isn't an obstacle for it.

-hadriel
p.s. Transcoding video, on the other hand, is untenable for pretty much anyo=
ne.  I have never heard of a business-case which justifies it, because it si=
mply doesn't scale.  Except for maybe companies that live on other revenue s=
ources, for whom all of this stuff is a rounding error in their IT budget. ;=
)


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From prvs=878646dd34=aallen@blackberry.com  Fri Mar 15 07:56: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 7A04021F886D for ; Fri, 15 Mar 2013 07:56:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.039
X-Spam-Level: 
X-Spam-Status: No, score=-4.039 tagged_above=-999 required=5 tests=[AWL=-1.136, BAYES_00=-2.599, MANGLED_LOAN=2.3, MIME_QP_LONG_LINE=1.396, 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 FZjWaO31zp5u for ; Fri, 15 Mar 2013 07:56:07 -0700 (PDT)
Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5D78B21F887F for ; Fri, 15 Mar 2013 07:56:07 -0700 (PDT)
X-AuditID: 0a41282f-b7fa06d000002431-0f-5143367b6fc5
Received: from XCT103ADS.rim.net (xct103ads.rim.net [10.67.111.44]) by mhs060cnc.rim.net (SBG) with SMTP id C8.52.09265.B7633415; Fri, 15 Mar 2013 09:55:55 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT103ADS.rim.net ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.02.0328.009; Fri, 15 Mar 2013 09:55:55 -0500
From: Andrew Allen 
To: "R.Jesske@telekom.de" , "koen.vos@skype.net" , "espeberg@cisco.com" , "stephane.proust@orange.com" 
Thread-Topic: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIHAgQ3Oi2P7DjEKDSnUvQoKufpilc9aAgAAGtgCAAH5yAP//tpYYgADR0CCAAFbNYA==
Date: Fri, 15 Mar 2013 14:55:54 +0000
Message-ID: 
References:   <580BEA5E3B99744AB1F5BFF5E9A3C67D16E4408A5A@HE111648.emea1.cds.t-internal.com>
In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D16E4408A5A@HE111648.emea1.cds.t-internal.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.253]
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKKsWRmVeSWpSXmKPExsXC5Zyvo1tt5hxocO6ngcWXhmSL1p/fmC2a 7nSxWaz9185u0TrjCpvFka1rmR3YPKb83sjqsWTJTyaPlmcn2TxuPZjE5tH2UiGANaqB0SYp saQsODM9T9/OJjEvL78ksSRVISW1ONlWySc1PTFHIaAosywxuVLBJbM4OScxMze1SEkhM8VW yURJoSAnMTk1NzWvxFYpsaAgNS9FyY5LAQPYAJVl5imk5iXnp2TmpdsqeQb761pYmFrqGirZ 6SZ08mTMPbCZseD7TsaK7b1/WRsYp8xg7GLk5JAQMJGY2fqaFcIWk7hwbz1bFyMXh5DASkaJ 9l8zWCCczYwSUxsus4BUsQloSew/PJ0JJCEicIRR4mrvPLAEs0CCRMeipcwgtrBAvMTkzndg tghQfMqPOUA2B5AdJvHrEBdImEVAVWLBpp/sIDavgIfEzE1voZa9YpR49L6dEaSeUyBaYuvv fJAaRgFZid1nrzNBrBKXuPVkPhPE1QISS/acZ4awRSVePv4H9Y2ixN+931kh6vUkbkydwgZh a0ssW/iaGWKvoMTJmU9YJjCKzUIydhaSlllIWmYhaVnAyLKKUTA3o9jAzCA5L1mvKDNXLy+1 ZBMjKN04aujvYHz73uIQowAHoxIPb5KYc6AQa2JZcWXuIUYJDmYlEd53+kAh3pTEyqrUovz4 otKc1OJDjK7AUJnILMWdnA9MhXkl8cYGBrg5SuK8ZZpOgUIC6cDUlJ2aWpBaBDOHiYMTZA+X lEgxMMGkFiWWlmTEg9JgfDEwEUo1ME4P7n245zPf25y07v0pE6oeMfnG1V1J2ronWNsrV54l LbR2vriVw+qI3eqxese/z2tQSexfeWQ162UlhalNR6dxM7tHs92alBt4s7RbK1cgtLWg6al9 W/T37zsqjT493Dopf3W876TvqYXvrm2L3Xg+6Qmfg2jCvF/fJ383u33g6hxHG2XPLiWW4oxE Qy3mouJEAPud/rt4AwAA
Cc: "rtcweb@ietf.org" , "xavier.marjou@orange.com" 
Subject: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 15 Mar 2013 14:56:09 -0000

Roland

I have proposed that we add the following text to address the interoperabili=
ty concerns

"If other suitable audio codecs are available to the browser to use it is re=
commended that they are also included in the offer in order to maximize the=
 possibility to establish the session without the need for audio transcoding=
."

The MTI Audio Codecs are defined to ensure a basic level of interoperability=
 and will need to be always supported for that reason. Support for additiona=
l audio codecs is an implementation and business case decision and the addit=
ional audio codecs that it makes sense to support will change over time (as=
 codecs become obsolete and new ones are developed and deployed. So addition=
al audio codecs should not be specified in the RTCweb RFCs.

Andrew

-----Original Message-----
From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] 
Sent: Friday, March 15, 2013 5:45 AM
To: Andrew Allen; koen.vos@skype.net; espeberg@cisco.com; stephane.proust@or=
ange.com
Cc: xavier.marjou@orange.com; rtcweb@ietf.org
Subject: AW: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-code=
cs-for-interop-01

Hi Andrew,
but where will you start and where will you end.
The codec discussion appears now so why not try to solve this now?
And one proposal is to use these codecs and I fully support it.

Roland

> -----Urspr=FCngliche Nachricht-----
> Von: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] Im 
> Auftrag von Andrew Allen
> Gesendet: Donnerstag, 14. M=E4rz 2013 22:10
> An: koen.vos@skype.net; espeberg@cisco.com; stephane.proust@orange.com
> Cc: xavier.marjou@orange.com; rtcweb@ietf.org
> Betreff: Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
>
> Koen is right that there are many more obstacles to RTCweb and legacy 
> network interop than just a common codec. First there will need to be 
> RTCweb signaling gateways to interface between the RTCweb signaling 
> and the legacy networks (SIP,
> H.323 etc) and there will need to be in place mechanisms for peering, 
> federation and address resolution between networks as well as service 
> agreements in place between the players.
>
> Until those are resolved supporting codecs used in those networks is 
> pointless.
>
> Andrew
>
> ----- Original Message -----
> From: Koen Vos [mailto:koen.vos@skype.net]
> Sent: Thursday, March 14, 2013 03:32 PM Central Standard Time
> To: Espen Berger (espeberg) ; 
> stephane.proust@orange.com 
> Cc: rtcweb@ietf.org ; MARJOU Xavier OLNC/OLN 
> 
> Subject: Re: [rtcweb] Agenda time     request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> > It's interop with billions of mobile phones and with fixed
> terminals in legacy telephony services.
>
> The problem is that WebRTC and legacy services live in separate 
> networks: the open Web vs proprietary Telco networks.
>
> WebRTC connecting to a Telco network would have to go through a 
> Gateway.  The PSTN termination providers who run these Gateways 
> support G.711, G.729 and perhaps some other  codecs like iLBC.  They 
> do not, however, support the codecs you are advocating for.
>
> The lack of support for Transcoding-Free Operation by Telcos to the 
> rest of the world has been hurting interop voice quality for a long 
> time, but unfortunately we can't fix that here at the IETF.
>
> We can fit our cars with your costly railroad wheels, but you still 
> wouldn't let us on your tracks.
>
> koen.
>
>
> -----Original Message-----
> From: rtcweb-bounces@ietf.org
> [mailto:rtcweb-bounces@ietf.org] On Behalf Of 
> stephane.proust@orange.com
> Sent: 14. mars 2013 13:36
> To: Jean-Marc Valin
> Cc: rtcweb@ietf.org; MARJOU Xavier OLNC/OLN
> Subject: Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> Hello
>
> The short list is aligned to what is specified in 3GPP
> (mobile) and CAT-iq (fixed). Check the related service specifications!
> The short list (AMR, AMR-WB, G.722) is a minimal subset of codecs to 
> minimize interop issues and transcoding costs for telco services.
> It's not a question of what's the favourite codec for a given 
> application. It's interop with billions of mobile phones and with 
> fixed terminals in legacy telephony services.
>
> St=E9phane
>
> -----Message d'origine-----
> De : Jean-Marc Valin [mailto:jmvalin@mozilla.com] Envoy=E9 :
> jeudi 14 mars 2013 05:55 =C0 : PROUST Stephane OLNC/OLPS Cc :
> Andrew Allen; Markus.Isomaki@nokia.com; MARJOU Xavier OLNC/OLN; 
> rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time request for 
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/13/2013 06:48 PM, stephane.proust@orange.com wrote:
> > The reason is simply that AMR and AMR-WB are supported in
> billions of
> > devices !
>
> Just curious, why exclude from the list other codecs with similar huge 
> deployment? I can think of at least:
> - - GSM-FR (mobile)
> - - Speex (Flash)
> - - G.729 (PSTN gateways)
> - - iLBC (PSTN gateways)
> - - G.726 (DECT)
> - - SILK (original non-Opus version in Skype)
>
> (sorry, if I missed someone's favorite codec in this list)
>
> It's not at all clear to me what's so special that makes AMR, AMR-WB 
> and G.722 different from the other codecs in the list above. Not that 
> I insist on shipping G.729 :-)
>
> Personally, I'd favor a draft that included a lot more codecs, 
> describing for each one the benefits of supporting it. Implementers 
> could then choose which of these they care about for their particular 
> situation.
>
> Cheers,
>
>         Jean-Marc
>
> > St=E9phane
> >
> >
> > -----Message d'origine----- De : Andrew Allen 
> > [mailto:aallen@blackberry.com] Envoy=E9 : mercredi 13 mars 2013
> > 23:41 =C0 : PROUST Stephane OLNC/OLPS; Markus.Isomaki@nokia.com; 
> > jmvalin@mozilla.com Cc : MARJOU Xavier OLNC/OLN;
> rtcweb@ietf.org Objet
> > : Re: [rtcweb] Agenda time request for
> > draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> >
> > No this wouldn't be acceptable to me.
> >
> > I don't see a reason to push a particular set of Codecs
> over any other
> > set of codecs supported on the device. If the device supports the 
> > codecs and they are available to the browser then we should
> recommend
> > that they be offered in the negotiation.
> >
> > The marjou draft can advertise the merits and reasons why they are 
> > good codecs to support.
> >
> >
> > ----- Original Message ----- From: stephane.proust@orange.com 
> > [mailto:stephane.proust@orange.com] Sent: Wednesday, March 13, 2013
> > 05:14 PM Central Standard Time To: Markus.Isomaki@nokia.com 
> > ; jmvalin@mozilla.com
> 
> > Cc: MARJOU Xavier OLNC/OLN ;
> rtcweb@ietf.org
> > 
> > Subject: Re: [rtcweb] Agenda time     request for
> > draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> > Dear Markus
> >
> > Thanks for your attempt to help !
> >
> > Of course each Telco can handle this directly with vendors and 
> > browsers manufacturers at business level. But I don't'think
> this need
> > of interoperability with mobile devices is specific to Orange.
> > I think all mobile operators will have the same issue and
> this is why
> > standardization exist. It's most cost and time efficient to
> have one
> > common way forward for all the industry.
> >
> > Then if the issue is that "conditional MUST/SHOULD are a too 
> > complicated requirement. We could also live as a compromise with a 
> > formulation that has already been suggested on the reflector:
> >
> > "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" If possible with the addition of This is
> especially
> > the case for AMR, AMR-WB for interoperability with mobile
> devices and
> > G.722 for interoperability with fixed DECT CAT-iq devices
> >
> > Would it have one chance to reach consensus ?
> >
> > I think this Group should at least make one small step so that the 
> > interoperability issue with mobile terminals be not fully
> ignored in
> > the RTC Web specification considering the huge number of deployed 
> > devices. At least something must be written on this !
> > G.711 which is the only codec in addition to OPUS for
> interoperability
> > purpose is not a proper answer to this.
> >
> > St=E9phane
> >
> > -----Message d'origine----- De : Markus.Isomaki@nokia.com 
> > [mailto:Markus.Isomaki@nokia.com] Envoy=E9 : mercredi 13 mars 2013
> > 22:37 =C0 : PROUST Stephane OLNC/OLPS; jmvalin@mozilla.com; MARJOU 
> > Xavier OLNC/OLN Cc : rtcweb@ietf.org Objet : RE: [rtcweb]
> Agenda time
> > request for draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> > Hi Stephane, Xavier,
> >
> > I understand the intent of your proposal. I'm not sure if
> the IETF is
> > the best venue for you to pursue it, however. Perhaps you
> as a mobile
> > operator should rather set it as a requirement to your
> mobile device
> > platforms that they open up the APIs to AMR and AMR-WB and that at 
> > least the in-built default browser needs to support it. If
> there are
> > enough operators setting such requirements directly to the
> device and
> > platform vendors, it probably has a bigger impact than an IETF RFC.
> > Getting that support for user-installed additional browsers
> might be
> > more difficult, but most mobile device users stick with the default 
> > browser anyway.
> >
> > The RTCWEB codec document needs to definitely explain this case and 
> > the benefits, but the conditional MUSTs or SHOULDs you are
> proposing
> > are perhaps a bit too complicated. Hmm, perhaps we need to do an 
> > _informational_ RFC as something like "Recommendations for
> WebRTC on
> > Mobile Devices" addressing the codec and perhaps other issues, that 
> > you could use as a reference in your requirements.
> >
> > Markus
> >
> >
> >> -----Original Message----- From: rtcweb-bounces@ietf.org 
> >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext 
> >> stephane.proust@orange.com Sent: 13 March, 2013 21:37 To:
> >> Jean-Marc Valin; MARJOU Xavier OLNC/OLN Cc: rtcweb@ietf.org
> >> Subject: Re: [rtcweb] Agenda time request for
> >> draft-marjou-rtcweb-audio- codecs-for-interop-01
> >>
> >> Hello
> >>
> >> Our understanding is that the reason of the "no consensus" on 
> >> additional recommended codecs was the additional costs for
> browsers.
> >> The proposal is then to make these "MUST" fully conditional to the 
> >> case of no (or very reduced) additional costs, when the codecs are 
> >> already available on the device and when no additional
> license fee is
> >> required
> >>
> >> We could even live with lower level of "requirements" with 
> >> respectively May and Should (instead of Should and shall) but we 
> >> think that this proposal is a way to take into account
> both browser
> >> manufacturers concerns on browsers costs and telcos concerns on 
> >> transcoding costs and some other companies share this view.
> >>
> >> St=E9phane
> >>
> >>
> >>
> >>
> >>
> >>
> >> -----Message d'origine----- De : rtcweb-bounces@ietf.org 
> >> [mailto:rtcweb-bounces@ietf.org] De la part de Jean-Marc
> Valin Envoy=E9
> >> : mercredi 13 mars 2013 20:24 =C0 : MARJOU Xavier OLNC/OLN Cc :
> >> rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time request for
> >> draft-marjou-rtcweb-audio-codecs-for-interop-01
> >>
> > Hi,
> >
> > I'd really like to understand how the chairs coming to the
> conclusion
> > that there was *no consensus* on recommended codecs can result in a 
> > draft that includes 3 MUSTs and 1 SHOULD. This draft
> effectively makes
> > 3 new codecs MTI for a range of devices. I understand that it's an 
> > individual draft and you can write whatever you like in
> there, but it
> > definitely goes against the result of the WG discussion.
> >
> > Cheers,
> >
> > Jean-Marc
> >
> > On 03/13/2013 09:14 AM, Xavier Marjou wrote:
> >>>> Here is a summary of the
> >>>> draft-marjou-rtcweb-audio-codecs-for-interop-00
> presentation that I
> >>>> had prepared for yesterday's session:
> >>>>
> >>>> - The co-authors want to underline that non-WebRTC voice
> endpoints
> >>>> usually use one of the following codecs: AMR, AMR-WB or G.722, 
> >>>> which will result in massive transcoding when there will be 
> >>>> communications between WebRTC endpoints and non-WebRTC endpoints.
> >>>>
> >>>> - On one side, transcoding is bad for many reasons
> discussed in the
> >>>> draft (cost issues, intrinsic quality degradation, degraded 
> >>>> interactivity, fallback from HD to G.711...);
> >>>>
> >>>> - On the other side, it is recognized that implementing
> additional
> >>>> codecs in the browsers can generate additional costs.
> >>>>
> >>>> - In order to reach a compromise, we would like to add
> some text in
> >>>> the WG draft draft-ietf-rtcweb-audio providing
> incentives for the
> >>>> browser to use these three codecs: make them mandatory
> to implement
> >>>> when there is no cost impact on the browser (e.g. if
> codec already
> >>>> installed, paid by the device vendor...).
> >>>>
> >>>> Any opinion on that?
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Xavier
> >>>>
> >>>> PS: I will be ready to present the slides on Thursday if time 
> >>>> permits it.
> >>>>
> >>>> (c.f.
> >>>> http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf
> >>>>
> >>>>
> )
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie  >>>> > wrote:
> >>>>
> >>>> Magnus and I discussed this this morning, and we
> encourage you to
> >>>> prepare something.  If the discussion of working group last call 
> >>>> items runs short, we may be able to fit this in at that
> time or at
> >>>> the end of day one if its full agenda his finished.
> This is not a
> >>>> commitment, however, so please try and get discussion on
> the list
> >>>> on the points from the draft you feel need resolution.
> >>>>
> >>>> regards,
> >>>>
> >>>> Ted
> >>>>
> >>>>
> >>>> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg) 
> >>>> > wrote:
> >>>>> Hello,
> >>>>>
> >>>>>
> >>>>>
> >>>>> I would like to request agenda time for:
> >>>>>
> >>>>>
> >>>>>
> >>>>> draft-marjou-rtcweb-audio-codecs-for-interop-01
> >>>>>
> >>>>>
> >>>>>
> >>>>> The document  presents use-cases underlining why WebRTC needs
> >>>> AMR-WB,  AMR
> >>>>> and G.722 as additional relevant voice codecs to satisfactorily 
> >>>>> ensure interoperability with existing systems.
> >>>>>
> >>>>>
> >>>>>
> >>>>> A 10-minute time slot should be sufficient for presentation and
> >>>> discussion.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Regards
> >>>>>
> >>>>>
> >>>>>
> >>>>> -Espen
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________ 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
> >>
> >> ___________________________________________________________
> >> ___________________________________________________________ ___
> >>
> >> Ce message et ses pieces jointes peuvent contenir des informations 
> >> confidentielles ou privilegiees et ne doivent donc pas
> etre diffuses,
> >> exploites ou copies sans autorisation. Si vous avez recu
> ce message
> >> par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> >> que les pieces jointes. Les messages electroniques etant
> susceptibles
> >> d'alteration, France Telecom - Orange decline toute
> responsabilite si
> >> ce message a ete altere, deforme ou falsifie. Merci.
> >>
> >> This message and its attachments may contain confidential or 
> >> privileged information that may be protected by law; they
> should not
> >> be distributed, used or copied without authorisation. If you have 
> >> received this email in error, please notify the sender and delete 
> >> this message and its attachments. As emails may be altered, France 
> >> Telecom - Orange is not liable for messages that have been
> modified,
> >> changed or falsified. Thank you.
> >>
> >> _______________________________________________ rtcweb
> mailing list
> >> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> ______________________________________________________________________
> > ___________________________________________________
> >
> >  Ce message et ses pieces jointes peuvent contenir des informations 
> > confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message 
> > par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> > que les pieces jointes. Les messages electroniques etant
> susceptibles
> > d'alteration, France Telecom - Orange decline toute
> responsabilite si
> > ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or 
> > privileged information that may be protected by law; they
> should not
> > be distributed, used or copied without authorisation. If you have 
> > received this email in error, please notify the sender and
> delete this
> > message and its attachments. As emails may be altered,
> France Telecom
> > - Orange is not liable for messages that have been
> modified, changed
> > or falsified. Thank you.
> >
> > _______________________________________________ rtcweb mailing list 
> > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> ---------------------------------------------------------------------
> >
> >
> This transmission (including any attachments) may contain confidential 
> information, privileged material (including material protected by the 
> solicitor-client or other applicable privileges), or constitute 
> non-public information.
> Any use of this information by anyone other than the intended 
> recipient is prohibited. If you have received this transmission in 
> error, please immediately reply to the sender and delete this 
> information from your system. Use, dissemination, distribution, or 
> reproduction of this transmission by unintended recipients is not 
> authorized and may be unlawful.
> >
> >
> ______________________________________________________________________
> > ___________________________________________________
> >
> >  Ce message et ses pieces jointes peuvent contenir des informations 
> > confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message 
> > par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> > que les pieces jointes. Les messages electroniques etant
> susceptibles
> > d'alteration, France Telecom - Orange decline toute
> responsabilite si
> > ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or 
> > privileged information that may be protected by law; they
> should not
> > be distributed, used or copied without authorisation. If you have 
> > received this email in error, please notify the sender and
> delete this
> > message and its attachments. As emails may be altered,
> France Telecom
> > - Orange is not liable for messages that have been
> modified, changed
> > or falsified. Thank you.
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJRQVgzAAoJEJ6/8sItn9q9fgYH/jcWfhRrvPM1hJ22YcE7eR0N
> OZzP/RvSrUBiIA6kG+6+Hvn5Lp/tXd+LxUDp5L8B3Toce7TBBAYNJP3M2cr8N8It
> SjVvPHtBNKEqhBLbI4FbAouvymNH4utjAWR+MmF9LRySPXZ9nxLN0A13TeUlpZxt
> Jaxr/n9AWwkKOk6BIo1Xztbk26MObiGVLhCE+CPoHaHe29bKblPcphBXC935ymHS
> SuF2DXiAq0iKwZoVOsLe3RIaGg+bjN7N2MXi3Vphr7cOQK+JpdxURDrvmPh7/L8R
> ht1RJt928yl4fEjnKhSKJLd1J+gPBe6vnkSxUp89as03bLirLwN1G2giD3YzfLM=3D
> =3DK56v
> -----END PGP SIGNATURE-----
>
> ______________________________________________________________
> ___________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi 
> que les pieces jointes. Les messages electroniques etant susceptibles 
> d'alteration, France Telecom - Orange decline toute responsabilite si 
> ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not 
> be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and 
> delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for 
> messages that have been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> 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
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential 
> information, privileged material (including material protected by the 
> solicitor-client or other applicable privileges), or constitute 
> non-public information.
> Any use of this information by anyone other than the intended 
> recipient is prohibited. If you have received this transmission in 
> error, please immediately reply to the sender and delete this 
> information from your system. Use, dissemination, distribution, or 
> reproduction of this transmission by unintended recipients is not 
> authorized and may be unlawful.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From D.Malas@cablelabs.com  Fri Mar 15 08:41: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 E1E7C21F8814 for ; Fri, 15 Mar 2013 08:41:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.907
X-Spam-Level: 
X-Spam-Status: No, score=-98.907 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24, SARE_MILLIONSOF=0.315, 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 XvCpmznzGk1n for ; Fri, 15 Mar 2013 08:41:50 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id C56C821F8788 for ; Fri, 15 Mar 2013 08:41:49 -0700 (PDT)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r2FFfbqs020384; Fri, 15 Mar 2013 09:41:37 -0600
Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Fri, 15 Mar 2013 09:41:37 -0600 (MDT)
X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com)
Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.02.0328.009; Fri, 15 Mar 2013 09:41:37 -0600
From: Daryl Malas 
To: Erik Lagerway , Chris Wendt 
Thread-Topic: [rtcweb] A different perspective on the video codec MTI discussion
Thread-Index: AQHOIZOUBmVMnR9C5ke57MnWAvfegg==
Date: Fri, 15 Mar 2013 15:41:37 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.1.130117
x-originating-ip: [10.5.0.27]
Content-Type: multipart/alternative; boundary="_000_FEA80D86BEEC134D88CA45E53A0D3408180DDD04EXCHANGEcablela_"
MIME-Version: 1.0
X-Approved: ondar
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] A different perspective on the video codec MTI 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, 15 Mar 2013 15:41:51 -0000

--_000_FEA80D86BEEC134D88CA45E53A0D3408180DDD04EXCHANGEcablela_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

+1 to both Chris and Erik's follow-up.

--Daryl

From: Erik Lagerway >
Date: Thursday, March 14, 2013 8:17 PM
To: Chris Wendt >
Cc: "rtcweb@ietf.org" >
Subject: Re: [rtcweb] A different perspective on the video codec MTI discus=
sion

+1

Well said Chris, this is pretty much what I wrote earlier today...
http://blog.webrtc.is/2013/03/14/rtcweb-webrtc-mti-video-codec-debate-conti=
nues/

The WG has been through this debate many times and it seems rather obvious =
that this is not likely to get resolved anytime soon.

Let's remove the MTI video codec requirement now and get on with life.

/Erik


On Thu, Mar 14, 2013 at 3:41 PM, Chris Wendt > wrote:
As mostly an observer over the past year or two, this issue of MTI has come=
 a long way, both good and bad.

First, I will state, my employer, Comcast, has millions of boxes deployed a=
nd more in the pipeline where one could imagine webrtc capabilities being u=
tilized.
Short term, VP8 does pose us the most challenge in terms of either suboptim=
al or total lack of support because of limited cpu/gpu capabilities, etc.
Longer term, this would be less of an issue, certainly, but perhaps in that=
 time frame we will be talking the virtue of a brand new set of codecs anyw=
ay.

In terms of quality per bit/cpu/transistor, I believe nobody can credibly s=
ay that either codec is a horrible choice.  To me, any further argument or =
quantitative/perceptual testing on that is wasting time.

IPR, I'm not going to comment, because the clarity of the IPR situation is =
in the eye of the beholder.

While it would be wonderful if everybody agreed on a single video codec, I =
don't see any possibility that one can satisfy all use-cases in any practic=
al way.  Whether it's browser to browser or browser to terminal, one can ar=
gue that her use-case is more valuable than the other, but we can't all agr=
ee on that either.

To me, the only choice left, and I think many others agree and some have st=
ated it already, is either to make both codecs MTI or remove the MTI requir=
ement.  The former, likely would take an act of God and for various reasons=
 I don't think is the right choice anyway.  So, I would strongly encourage =
the latter, in full acknowledgement that there have been decisions made aga=
inst this.
(ASCII codec being a third choice, but I haven't seen the draft )
Note, regardless of either choice, we would likely be required to implement=
 both codecs anyway to avoid the transcoding penalty if we want to reasonab=
ly support interoperability.

In the end, we currently sit in the likely position that the market will de=
cide this debate anyway, it already seems to be underway, so why keep wasti=
ng time debating.  Besides being a complete waste of valuable brain cycles,=
 and delaying more important work to resolve, I think it has become or is c=
lose to becoming much more destructive to the process than the value of hav=
ing a half-supported, forced choice MTI codec.

-Chris


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


--_000_FEA80D86BEEC134D88CA45E53A0D3408180DDD04EXCHANGEcablela_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







+1 to both Chris and Erik's follow-up.







--Daryl









From: Erik Lagerway <erik@hookflash.com>

Date: Thursday, March 14, 2013 8:17=
 PM

To: Chris Wendt <chris@chriswendt.net>

Cc: "rtcweb@ietf.org" <=
rtcweb@ietf.org>

Subject: Re: [rtcweb] A different p=
erspective on the video codec MTI discussion













+1







Well said Chris, this is pretty much what I wrote earlier today...

http://blog.webrtc.is/2013/03/14/rtcweb-webrtc-mti-video-=
codec-debate-continues/







The WG has been through this debate many times and it seems rather obv=
ious that this is not likely to get resolved anytime soon.







Let's remove the MTI video codec requirement now and get on with life.=








/Erik








On Thu, Mar 14, 2013 at 3:41 PM, Chris Wendt 
<chris@chriswe=
ndt.net> wrote:



As mostly an observer over the past year or two, this issue of MTI has come=
 a long way, both good and bad.



First, I will state, my employer, Comcast, has millions of boxes deployed a=
nd more in the pipeline where one could imagine webrtc capabilities being u=
tilized.

Short term, VP8 does pose us the most challenge in terms of either suboptim=
al or total lack of support because of limited cpu/gpu capabilities, etc.
Longer term, this would be less of an issue, certainly, but perhaps in that=
 time frame we will be talking the virtue of a brand new set of codecs anyw=
ay.



In terms of quality per bit/cpu/transistor, I believe nobody can credibly s=
ay that either codec is a horrible choice.  To me, any further argumen=
t or quantitative/perceptual testing on that is wasting time.



IPR, I'm not going to comment, because the clarity of the IPR situation is =
in the eye of the beholder.



While it would be wonderful if everybody agreed on a single video codec, I =
don't see any possibility that one can satisfy all use-cases in any practic=
al way.  Whether it's browser to browser or browser to terminal, one c=
an argue that her use-case is more valuable
 than the other, but we can't all agree on that either.



To me, the only choice left, and I think many others agree and some have st=
ated it already, is either to make both codecs MTI or remove the MTI requir=
ement.  The former, likely would take an act of God and for various re=
asons I don't think is the right choice
 anyway.  So, I would strongly encourage the latter, in full acknowled=
gement that there have been decisions made against this.

(ASCII codec being a third choice, but I haven't seen the draft )

Note, regardless of either choice, we would likely be required to implement=
 both codecs anyway to avoid the transcoding penalty if we want to reasonab=
ly support interoperability.



In the end, we currently sit in the likely position that the market will de=
cide this debate anyway, it already seems to be underway, so why keep wasti=
ng time debating.  Besides being a complete waste of valuable brain cy=
cles, and delaying more important work
 to resolve, I think it has become or is close to becoming much more destru=
ctive to the process than the value of having a half-supported, forced choi=
ce MTI codec.



-Chris









_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb



















--_000_FEA80D86BEEC134D88CA45E53A0D3408180DDD04EXCHANGEcablela_--

From stephane.proust@orange.com  Fri Mar 15 08:50: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 1721821F86D5 for ; Fri, 15 Mar 2013 08:50:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.149
X-Spam-Level: 
X-Spam-Status: No, score=-0.149 tagged_above=-999 required=5 tests=[AWL=0.149,  BAYES_00=-2.599, MANGLED_LOAN=2.3, 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 oyrdXOf7Dka5 for ; Fri, 15 Mar 2013 08:50:35 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 47EED21F86CE for ; Fri, 15 Mar 2013 08:50:34 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id DE4ED22C5A1; Fri, 15 Mar 2013 16:50:29 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id BACC623804B; Fri, 15 Mar 2013 16:50:29 +0100 (CET)
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; Fri, 15 Mar 2013 16:50:26 +0100
From: 
To: Andrew Allen , "R.Jesske@telekom.de" , "koen.vos@skype.net" , "espeberg@cisco.com" 
Thread-Topic: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIHAg2ECP5H1T90qzFszqZMyAx5ilHxjg///23wCAAH5yAIAACmiAgADS7YCAAFcAAIAAHUoA
Date: Fri, 15 Mar 2013 15:50:18 +0000
Message-ID: <4507_1363362629_51434345_4507_361_1_6af2514e-a2f2-4248-b7a9-5d0452f3abf7@PEXCVZYH02.corporate.adroot.infra.ftgroup>
References:   <580BEA5E3B99744AB1F5BFF5E9A3C67D16E4408A5A@HE111648.emea1.cds.t-internal.com> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.5]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.15.83027
Cc: "rtcweb@ietf.org" , MARJOU Xavier OLNC/OLN 
Subject: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 15 Mar 2013 15:50:37 -0000

Hello

As mentioned earlier, this kind of general statement makes sense and would =
be acceptable for us only if it gives some minimum guidance on what "suitab=
le" means. It means: the codecs that are especially important to be conside=
red because their support would solve the interoperability issue for a huge=
 number of calls and because they can be made available to the browsers on =
a high number of devices:=20

"If other suitable audio codecs are available to the browser to use it is r=
ecommended that they are also included in the offer in order to maximize th=
e possibility to establish the session without the need for audio transcodi=
ng."
This is especially the case for AMR and AMR-WB for interoperability with 3G=
PP mobile devices and G.722 for interoperability with fixed ETSI/DECT CAT-i=
q devices


Stephane Proust



-----Message d'origine-----
De=A0: Andrew Allen [mailto:aallen@blackberry.com]=20
Envoy=E9=A0: vendredi 15 mars 2013 15:56
=C0=A0: R.Jesske@telekom.de; koen.vos@skype.net; espeberg@cisco.com; PROUST=
 Stephane OLNC/OLPS
Cc=A0: MARJOU Xavier OLNC/OLN; rtcweb@ietf.org
Objet=A0: RE: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-co=
decs-for-interop-01

Roland

I have proposed that we add the following text to address the interoperabil=
ity concerns

"If other suitable audio codecs are available to the browser to use it is r=
ecommended that they are also included in the offer in order to maximize th=
e possibility to establish the session without the need for audio transcodi=
ng."

The MTI Audio Codecs are defined to ensure a basic level of interoperabilit=
y and will need to be always supported for that reason. Support for additio=
nal audio codecs is an implementation and business case decision and the ad=
ditional audio codecs that it makes sense to support will change over time =
(as codecs become obsolete and new ones are developed and deployed. So addi=
tional audio codecs should not be specified in the RTCweb RFCs.

Andrew

-----Original Message-----
From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]
Sent: Friday, March 15, 2013 5:45 AM
To: Andrew Allen; koen.vos@skype.net; espeberg@cisco.com; stephane.proust@o=
range.com
Cc: xavier.marjou@orange.com; rtcweb@ietf.org
Subject: AW: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01

Hi Andrew,
but where will you start and where will you end.
The codec discussion appears now so why not try to solve this now?
And one proposal is to use these codecs and I fully support it.

Roland

> -----Urspr=FCngliche Nachricht-----
> Von: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] Im=20
> Auftrag von Andrew Allen
> Gesendet: Donnerstag, 14. M=E4rz 2013 22:10
> An: koen.vos@skype.net; espeberg@cisco.com; stephane.proust@orange.com
> Cc: xavier.marjou@orange.com; rtcweb@ietf.org
> Betreff: Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
>
> Koen is right that there are many more obstacles to RTCweb and legacy=20
> network interop than just a common codec. First there will need to be=20
> RTCweb signaling gateways to interface between the RTCweb signaling=20
> and the legacy networks (SIP,
> H.323 etc) and there will need to be in place mechanisms for peering,=20
> federation and address resolution between networks as well as service=20
> agreements in place between the players.
>
> Until those are resolved supporting codecs used in those networks is=20
> pointless.
>
> Andrew
>
> ----- Original Message -----
> From: Koen Vos [mailto:koen.vos@skype.net]
> Sent: Thursday, March 14, 2013 03:32 PM Central Standard Time
> To: Espen Berger (espeberg) ;=20
> stephane.proust@orange.com 
> Cc: rtcweb@ietf.org ; MARJOU Xavier OLNC/OLN=20
> 
> Subject: Re: [rtcweb] Agenda time     request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> > It's interop with billions of mobile phones and with fixed
> terminals in legacy telephony services.
>
> The problem is that WebRTC and legacy services live in separate
> networks: the open Web vs proprietary Telco networks.
>
> WebRTC connecting to a Telco network would have to go through a=20
> Gateway.  The PSTN termination providers who run these Gateways=20
> support G.711, G.729 and perhaps some other  codecs like iLBC.  They=20
> do not, however, support the codecs you are advocating for.
>
> The lack of support for Transcoding-Free Operation by Telcos to the=20
> rest of the world has been hurting interop voice quality for a long=20
> time, but unfortunately we can't fix that here at the IETF.
>
> We can fit our cars with your costly railroad wheels, but you still=20
> wouldn't let us on your tracks.
>
> koen.
>
>
> -----Original Message-----
> From: rtcweb-bounces@ietf.org
> [mailto:rtcweb-bounces@ietf.org] On Behalf Of=20
> stephane.proust@orange.com
> Sent: 14. mars 2013 13:36
> To: Jean-Marc Valin
> Cc: rtcweb@ietf.org; MARJOU Xavier OLNC/OLN
> Subject: Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> Hello
>
> The short list is aligned to what is specified in 3GPP
> (mobile) and CAT-iq (fixed). Check the related service specifications!
> The short list (AMR, AMR-WB, G.722) is a minimal subset of codecs to=20
> minimize interop issues and transcoding costs for telco services.
> It's not a question of what's the favourite codec for a given=20
> application. It's interop with billions of mobile phones and with=20
> fixed terminals in legacy telephony services.
>
> St=E9phane
>
> -----Message d'origine-----
> De : Jean-Marc Valin [mailto:jmvalin@mozilla.com] Envoy=E9 :
> jeudi 14 mars 2013 05:55 =C0 : PROUST Stephane OLNC/OLPS Cc :
> Andrew Allen; Markus.Isomaki@nokia.com; MARJOU Xavier OLNC/OLN;=20
> rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/13/2013 06:48 PM, stephane.proust@orange.com wrote:
> > The reason is simply that AMR and AMR-WB are supported in
> billions of
> > devices !
>
> Just curious, why exclude from the list other codecs with similar huge=20
> deployment? I can think of at least:
> - - GSM-FR (mobile)
> - - Speex (Flash)
> - - G.729 (PSTN gateways)
> - - iLBC (PSTN gateways)
> - - G.726 (DECT)
> - - SILK (original non-Opus version in Skype)
>
> (sorry, if I missed someone's favorite codec in this list)
>
> It's not at all clear to me what's so special that makes AMR, AMR-WB=20
> and G.722 different from the other codecs in the list above. Not that=20
> I insist on shipping G.729 :-)
>
> Personally, I'd favor a draft that included a lot more codecs,=20
> describing for each one the benefits of supporting it. Implementers=20
> could then choose which of these they care about for their particular=20
> situation.
>
> Cheers,
>
>         Jean-Marc
>
> > St=E9phane
> >
> >
> > -----Message d'origine----- De : Andrew Allen=20
> > [mailto:aallen@blackberry.com] Envoy=E9 : mercredi 13 mars 2013
> > 23:41 =C0 : PROUST Stephane OLNC/OLPS; Markus.Isomaki@nokia.com;=20
> > jmvalin@mozilla.com Cc : MARJOU Xavier OLNC/OLN;
> rtcweb@ietf.org Objet
> > : Re: [rtcweb] Agenda time request for
> > draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> >
> > No this wouldn't be acceptable to me.
> >
> > I don't see a reason to push a particular set of Codecs
> over any other
> > set of codecs supported on the device. If the device supports the=20
> > codecs and they are available to the browser then we should
> recommend
> > that they be offered in the negotiation.
> >
> > The marjou draft can advertise the merits and reasons why they are=20
> > good codecs to support.
> >
> >
> > ----- Original Message ----- From: stephane.proust@orange.com=20
> > [mailto:stephane.proust@orange.com] Sent: Wednesday, March 13, 2013
> > 05:14 PM Central Standard Time To: Markus.Isomaki@nokia.com=20
> > ; jmvalin@mozilla.com
> 
> > Cc: MARJOU Xavier OLNC/OLN ;
> rtcweb@ietf.org
> > 
> > Subject: Re: [rtcweb] Agenda time     request for
> > draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> > Dear Markus
> >
> > Thanks for your attempt to help !
> >
> > Of course each Telco can handle this directly with vendors and=20
> > browsers manufacturers at business level. But I don't'think
> this need
> > of interoperability with mobile devices is specific to Orange.
> > I think all mobile operators will have the same issue and
> this is why
> > standardization exist. It's most cost and time efficient to
> have one
> > common way forward for all the industry.
> >
> > Then if the issue is that "conditional MUST/SHOULD are a too=20
> > complicated requirement. We could also live as a compromise with a=20
> > formulation that has already been suggested on the reflector:
> >
> > "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=20
> > maximize the possibility to establish the session without
> the need for
> > audio transcoding" If possible with the addition of This is
> especially
> > the case for AMR, AMR-WB for interoperability with mobile
> devices and
> > G.722 for interoperability with fixed DECT CAT-iq devices
> >
> > Would it have one chance to reach consensus ?
> >
> > I think this Group should at least make one small step so that the=20
> > interoperability issue with mobile terminals be not fully
> ignored in
> > the RTC Web specification considering the huge number of deployed=20
> > devices. At least something must be written on this !
> > G.711 which is the only codec in addition to OPUS for
> interoperability
> > purpose is not a proper answer to this.
> >
> > St=E9phane
> >
> > -----Message d'origine----- De : Markus.Isomaki@nokia.com=20
> > [mailto:Markus.Isomaki@nokia.com] Envoy=E9 : mercredi 13 mars 2013
> > 22:37 =C0 : PROUST Stephane OLNC/OLPS; jmvalin@mozilla.com; MARJOU=20
> > Xavier OLNC/OLN Cc : rtcweb@ietf.org Objet : RE: [rtcweb]
> Agenda time
> > request for draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> > Hi Stephane, Xavier,
> >
> > I understand the intent of your proposal. I'm not sure if
> the IETF is
> > the best venue for you to pursue it, however. Perhaps you
> as a mobile
> > operator should rather set it as a requirement to your
> mobile device
> > platforms that they open up the APIs to AMR and AMR-WB and that at=20
> > least the in-built default browser needs to support it. If
> there are
> > enough operators setting such requirements directly to the
> device and
> > platform vendors, it probably has a bigger impact than an IETF RFC.
> > Getting that support for user-installed additional browsers
> might be
> > more difficult, but most mobile device users stick with the default=20
> > browser anyway.
> >
> > The RTCWEB codec document needs to definitely explain this case and=20
> > the benefits, but the conditional MUSTs or SHOULDs you are
> proposing
> > are perhaps a bit too complicated. Hmm, perhaps we need to do an=20
> > _informational_ RFC as something like "Recommendations for
> WebRTC on
> > Mobile Devices" addressing the codec and perhaps other issues, that=20
> > you could use as a reference in your requirements.
> >
> > Markus
> >
> >
> >> -----Original Message----- From: rtcweb-bounces@ietf.org=20
> >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext=20
> >> stephane.proust@orange.com Sent: 13 March, 2013 21:37 To:
> >> Jean-Marc Valin; MARJOU Xavier OLNC/OLN Cc: rtcweb@ietf.org
> >> Subject: Re: [rtcweb] Agenda time request for
> >> draft-marjou-rtcweb-audio- codecs-for-interop-01
> >>
> >> Hello
> >>
> >> Our understanding is that the reason of the "no consensus" on=20
> >> additional recommended codecs was the additional costs for
> browsers.
> >> The proposal is then to make these "MUST" fully conditional to the=20
> >> case of no (or very reduced) additional costs, when the codecs are=20
> >> already available on the device and when no additional
> license fee is
> >> required
> >>
> >> We could even live with lower level of "requirements" with=20
> >> respectively May and Should (instead of Should and shall) but we=20
> >> think that this proposal is a way to take into account
> both browser
> >> manufacturers concerns on browsers costs and telcos concerns on=20
> >> transcoding costs and some other companies share this view.
> >>
> >> St=E9phane
> >>
> >>
> >>
> >>
> >>
> >>
> >> -----Message d'origine----- De : rtcweb-bounces@ietf.org=20
> >> [mailto:rtcweb-bounces@ietf.org] De la part de Jean-Marc
> Valin Envoy=E9
> >> : mercredi 13 mars 2013 20:24 =C0 : MARJOU Xavier OLNC/OLN Cc :
> >> rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time request for
> >> draft-marjou-rtcweb-audio-codecs-for-interop-01
> >>
> > Hi,
> >
> > I'd really like to understand how the chairs coming to the
> conclusion
> > that there was *no consensus* on recommended codecs can result in a=20
> > draft that includes 3 MUSTs and 1 SHOULD. This draft
> effectively makes
> > 3 new codecs MTI for a range of devices. I understand that it's an=20
> > individual draft and you can write whatever you like in
> there, but it
> > definitely goes against the result of the WG discussion.
> >
> > Cheers,
> >
> > Jean-Marc
> >
> > On 03/13/2013 09:14 AM, Xavier Marjou wrote:
> >>>> Here is a summary of the
> >>>> draft-marjou-rtcweb-audio-codecs-for-interop-00
> presentation that I
> >>>> had prepared for yesterday's session:
> >>>>
> >>>> - The co-authors want to underline that non-WebRTC voice
> endpoints
> >>>> usually use one of the following codecs: AMR, AMR-WB or G.722,=20
> >>>> which will result in massive transcoding when there will be=20
> >>>> communications between WebRTC endpoints and non-WebRTC endpoints.
> >>>>
> >>>> - On one side, transcoding is bad for many reasons
> discussed in the
> >>>> draft (cost issues, intrinsic quality degradation, degraded=20
> >>>> interactivity, fallback from HD to G.711...);
> >>>>
> >>>> - On the other side, it is recognized that implementing
> additional
> >>>> codecs in the browsers can generate additional costs.
> >>>>
> >>>> - In order to reach a compromise, we would like to add
> some text in
> >>>> the WG draft draft-ietf-rtcweb-audio providing
> incentives for the
> >>>> browser to use these three codecs: make them mandatory
> to implement
> >>>> when there is no cost impact on the browser (e.g. if
> codec already
> >>>> installed, paid by the device vendor...).
> >>>>
> >>>> Any opinion on that?
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Xavier
> >>>>
> >>>> PS: I will be ready to present the slides on Thursday if time=20
> >>>> permits it.
> >>>>
> >>>> (c.f.
> >>>> http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf
> >>>>
> >>>>
> )
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie  >>>> > wrote:
> >>>>
> >>>> Magnus and I discussed this this morning, and we
> encourage you to
> >>>> prepare something.  If the discussion of working group last call=20
> >>>> items runs short, we may be able to fit this in at that
> time or at
> >>>> the end of day one if its full agenda his finished.
> This is not a
> >>>> commitment, however, so please try and get discussion on
> the list
> >>>> on the points from the draft you feel need resolution.
> >>>>
> >>>> regards,
> >>>>
> >>>> Ted
> >>>>
> >>>>
> >>>> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)=20
> >>>> > wrote:
> >>>>> Hello,
> >>>>>
> >>>>>
> >>>>>
> >>>>> I would like to request agenda time for:
> >>>>>
> >>>>>
> >>>>>
> >>>>> draft-marjou-rtcweb-audio-codecs-for-interop-01
> >>>>>
> >>>>>
> >>>>>
> >>>>> The document  presents use-cases underlining why WebRTC needs
> >>>> AMR-WB,  AMR
> >>>>> and G.722 as additional relevant voice codecs to satisfactorily=20
> >>>>> ensure interoperability with existing systems.
> >>>>>
> >>>>>
> >>>>>
> >>>>> A 10-minute time slot should be sufficient for presentation and
> >>>> discussion.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Regards
> >>>>>
> >>>>>
> >>>>>
> >>>>> -Espen
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________ rtcweb
> > mailing list
> >>>>> rtcweb@ietf.org =20
> >>>>> https://www.ietf.org/mailman/listinfo/rtcweb
> >>>>>
> >>>> _______________________________________________ rtcweb
> > mailing list
> >>>> rtcweb@ietf.org =20
> >>>> 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
> >>
> >> ___________________________________________________________
> >> ___________________________________________________________ ___
> >>
> >> Ce message et ses pieces jointes peuvent contenir des informations=20
> >> confidentielles ou privilegiees et ne doivent donc pas
> etre diffuses,
> >> exploites ou copies sans autorisation. Si vous avez recu
> ce message
> >> par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> >> que les pieces jointes. Les messages electroniques etant
> susceptibles
> >> d'alteration, France Telecom - Orange decline toute
> responsabilite si
> >> ce message a ete altere, deforme ou falsifie. Merci.
> >>
> >> This message and its attachments may contain confidential or=20
> >> privileged information that may be protected by law; they
> should not
> >> be distributed, used or copied without authorisation. If you have=20
> >> received this email in error, please notify the sender and delete=20
> >> this message and its attachments. As emails may be altered, France=20
> >> Telecom - Orange is not liable for messages that have been
> modified,
> >> changed or falsified. Thank you.
> >>
> >> _______________________________________________ rtcweb
> mailing list
> >> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> ______________________________________________________________________
> > ___________________________________________________
> >
> >  Ce message et ses pieces jointes peuvent contenir des informations=20
> > confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message=20
> > par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> > que les pieces jointes. Les messages electroniques etant
> susceptibles
> > d'alteration, France Telecom - Orange decline toute
> responsabilite si
> > ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or=20
> > privileged information that may be protected by law; they
> should not
> > be distributed, used or copied without authorisation. If you have=20
> > received this email in error, please notify the sender and
> delete this
> > message and its attachments. As emails may be altered,
> France Telecom
> > - Orange is not liable for messages that have been
> modified, changed
> > or falsified. Thank you.
> >
> > _______________________________________________ rtcweb mailing list=20
> > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> ---------------------------------------------------------------------
> >
> >
> This transmission (including any attachments) may contain confidential=20
> information, privileged material (including material protected by the=20
> solicitor-client or other applicable privileges), or constitute=20
> non-public information.
> Any use of this information by anyone other than the intended=20
> recipient is prohibited. If you have received this transmission in=20
> error, please immediately reply to the sender and delete this=20
> information from your system. Use, dissemination, distribution, or=20
> reproduction of this transmission by unintended recipients is not=20
> authorized and may be unlawful.
> >
> >
> ______________________________________________________________________
> > ___________________________________________________
> >
> >  Ce message et ses pieces jointes peuvent contenir des informations=20
> > confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message=20
> > par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> > que les pieces jointes. Les messages electroniques etant
> susceptibles
> > d'alteration, France Telecom - Orange decline toute
> responsabilite si
> > ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or=20
> > privileged information that may be protected by law; they
> should not
> > be distributed, used or copied without authorisation. If you have=20
> > received this email in error, please notify the sender and
> delete this
> > message and its attachments. As emails may be altered,
> France Telecom
> > - Orange is not liable for messages that have been
> modified, changed
> > or falsified. Thank you.
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJRQVgzAAoJEJ6/8sItn9q9fgYH/jcWfhRrvPM1hJ22YcE7eR0N
> OZzP/RvSrUBiIA6kG+6+Hvn5Lp/tXd+LxUDp5L8B3Toce7TBBAYNJP3M2cr8N8It
> SjVvPHtBNKEqhBLbI4FbAouvymNH4utjAWR+MmF9LRySPXZ9nxLN0A13TeUlpZxt
> Jaxr/n9AWwkKOk6BIo1Xztbk26MObiGVLhCE+CPoHaHe29bKblPcphBXC935ymHS
> SuF2DXiAq0iKwZoVOsLe3RIaGg+bjN7N2MXi3Vphr7cOQK+JpdxURDrvmPh7/L8R
> ht1RJt928yl4fEjnKhSKJLd1J+gPBe6vnkSxUp89as03bLirLwN1G2giD3YzfLM=3D
> =3DK56v
> -----END PGP SIGNATURE-----
>
> ______________________________________________________________
> ___________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations=20
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
> exploites ou copies sans autorisation. Si vous avez recu ce message=20
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20
> que les pieces jointes. Les messages electroniques etant susceptibles=20
> d'alteration, France Telecom - Orange decline toute responsabilite si=20
> ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or=20
> privileged information that may be protected by law; they should not=20
> be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and=20
> delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for=20
> messages that have been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> 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
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential=20
> information, privileged material (including material protected by the=20
> solicitor-client or other applicable privileges), or constitute=20
> non-public information.
> Any use of this information by anyone other than the intended=20
> recipient is prohibited. If you have received this transmission in=20
> error, please immediately reply to the sender and delete this=20
> information from your system. Use, dissemination, distribution, or=20
> reproduction of this transmission by unintended recipients is not=20
> authorized and may be unlawful.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.


From prvs=778627bb81=aallen@blackberry.com  Fri Mar 15 08:58: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 A5F7821F85BB for ; Fri, 15 Mar 2013 08:58:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.812
X-Spam-Level: 
X-Spam-Status: No, score=-3.812 tagged_above=-999 required=5 tests=[AWL=-0.909, BAYES_00=-2.599, MANGLED_LOAN=2.3, MIME_QP_LONG_LINE=1.396, 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 fA8-eUv2+5EK for ; Fri, 15 Mar 2013 08:58:34 -0700 (PDT)
Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id C8B8D21F863F for ; Fri, 15 Mar 2013 08:58:33 -0700 (PDT)
X-AuditID: 0a41282f-b7fa06d000002431-65-514345215763
Received: from XCT105ADS.rim.net (xct105ads.rim.net [10.67.111.46]) by mhs060cnc.rim.net (SBG) with SMTP id AD.E4.09265.12543415; Fri, 15 Mar 2013 10:58:25 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.02.0328.009; Fri, 15 Mar 2013 10:58:24 -0500
From: Andrew Allen 
To: "stephane.proust@orange.com" , "R.Jesske@telekom.de" , "koen.vos@skype.net" , "espeberg@cisco.com" 
Thread-Topic: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIHAgQ3Oi2P7DjEKDSnUvQoKufpilc9aAgAAGtgCAAH5yAP//tpYYgADR0CCAAFbNYIAAZFUA//+ucTg=
Date: Fri, 15 Mar 2013 15:58:23 +0000
Message-ID: 
In-Reply-To: <4507_1363362629_51434345_4507_361_1_6af2514e-a2f2-4248-b7a9-5d0452f3abf7@PEXCVZYH02.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.253]
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGKsWRmVeSWpSXmKPExsXC5Zyvp6vo6hxocH2bkcWXhmSL1p/fmC2a 7nSxWaz9185u0TrjCpvFka1rmR3YPKb83sjqsWTJTyaPlmcn2TxuPZjE5tH2UiGANaqB0SYp saQsODM9T9/OJjEvL78ksSRVISW1ONlWySc1PTFHIaAosywxuVLBJbM4OScxMze1SEkhM8VW yURJoSAnMTk1NzWvxFYpsaAgNS9FyY5LAQPYAJVl5imk5iXnp2TmpdsqeQb761pYmFrqGirZ 6SZ08mR0/pjDXLDwJmPFjdMrWBoYt29i7GLk4JAQMJFouaTTxcgJZIpJXLi3nq2LkYtDSGAl o8Tec79ZQRJCApsZJZavSwSx2QS0JPYfns4EUiQicIRR4sib3YwgCWaBBImORUuZQYYKC8RL NJ8qBAmLAIWnAG2GsJMkFnZtYwMpYRFQlTjyTh0kzCvgIfHq1CWwKZwCjYwSh4+EgNiMQPd8 P7WGCWK6uMStJ/OZIO4UkFiy5zwzhC0q8fLxP1YIW1Hi797vrBD1ehI3pk5hg7C1JZYtfM0M sUtQ4uTMJywTGEVnIRk7C0nLLCQts5C0LGBkWcUomJtRbGBmkJyXrFeUmauXl1qyiRGUUBw1 9Hcwvn1vcYhRgINRiYfXyNk5UIg1say4MvcQowQHs5II7zt9oBBvSmJlVWpRfnxRaU5q8SFG V2BATGSW4k7OBya7vJJ4YwMD3Bwlcd4yTadAIYF0YPLJTk0tSC2CmcPEwQmyh0tKpBiYQlKL EktLMuJBiS6+GJjqpBoYGVe0MDexaMXXJh4P7+j986f84IlFh3K5zRy3zyj5dTBgslqfjKrl 3jUPb6vsZFjFa7KnOtQ1pXdr8b7etccs1LZYGmZ2K4XLCZZui7H22d05o0b+meJ2Nc2vXy+3 LPxj05nw+0vs3ORrX52DplWs94rfu1Qru8Or7ZYFs+f75LVfTmrOPiirxFKckWioxVxUnAgA AqarSmkDAAA=
Cc: "rtcweb@ietf.org" , "xavier.marjou@orange.com" 
Subject: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 15 Mar 2013 15:58:36 -0000

Suitable to me means suitable for the application context i.e if the applica=
tion is conversational real time audio then all audio codecs suitable for co=
nversational real time audio the browser has the ability to use are recommen=
ded to be included in the offer.

I don't agree to mention specific codecs - all codecs that meet the suitabil=
ity for the application apply and we shouldn't give the impression that its=
 more important to include some codecs than others that are available to the=
 browser to use. 


----- Original Message -----
From: stephane.proust@orange.com [mailto:stephane.proust@orange.com]
Sent: Friday, March 15, 2013 10:50 AM Central Standard Time=0A=
To: Andrew Allen; R.Jesske@telekom.de ; koen.vos@skype.=
net ; espeberg@cisco.com 
Cc: MARJOU Xavier OLNC/OLN ; rtcweb@ietf.org 
Subject: RE: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-code=
cs-for-interop-01

Hello

As mentioned earlier, this kind of general statement makes sense and would b=
e acceptable for us only if it gives some minimum guidance on what "suitable=
" means. It means: the codecs that are especially important to be considered=
 because their support would solve the interoperability issue for a huge num=
ber of calls and because they can be made available to the browsers on a hig=
h number of devices: 

"If other suitable audio codecs are available to the browser to use it is re=
commended that they are also included in the offer in order to maximize the=
 possibility to establish the session without the need for audio transcoding=
."
This is especially the case for AMR and AMR-WB for interoperability with 3GP=
P mobile devices and G.722 for interoperability with fixed ETSI/DECT CAT-iq=
 devices


Stephane Proust



-----Message d'origine-----
De=A0: Andrew Allen [mailto:aallen@blackberry.com] 
Envoy=E9=A0: vendredi 15 mars 2013 15:56
=C0=A0: R.Jesske@telekom.de; koen.vos@skype.net; espeberg@cisco.com; PROUST=
 Stephane OLNC/OLPS
Cc=A0: MARJOU Xavier OLNC/OLN; rtcweb@ietf.org
Objet=A0: RE: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01

Roland

I have proposed that we add the following text to address the interoperabili=
ty concerns

"If other suitable audio codecs are available to the browser to use it is re=
commended that they are also included in the offer in order to maximize the=
 possibility to establish the session without the need for audio transcoding=
."

The MTI Audio Codecs are defined to ensure a basic level of interoperability=
 and will need to be always supported for that reason. Support for additiona=
l audio codecs is an implementation and business case decision and the addit=
ional audio codecs that it makes sense to support will change over time (as=
 codecs become obsolete and new ones are developed and deployed. So addition=
al audio codecs should not be specified in the RTCweb RFCs.

Andrew

-----Original Message-----
From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]
Sent: Friday, March 15, 2013 5:45 AM
To: Andrew Allen; koen.vos@skype.net; espeberg@cisco.com; stephane.proust@or=
ange.com
Cc: xavier.marjou@orange.com; rtcweb@ietf.org
Subject: AW: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-code=
cs-for-interop-01

Hi Andrew,
but where will you start and where will you end.
The codec discussion appears now so why not try to solve this now?
And one proposal is to use these codecs and I fully support it.

Roland

> -----Urspr=FCngliche Nachricht-----
> Von: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] Im 
> Auftrag von Andrew Allen
> Gesendet: Donnerstag, 14. M=E4rz 2013 22:10
> An: koen.vos@skype.net; espeberg@cisco.com; stephane.proust@orange.com
> Cc: xavier.marjou@orange.com; rtcweb@ietf.org
> Betreff: Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
>
> Koen is right that there are many more obstacles to RTCweb and legacy 
> network interop than just a common codec. First there will need to be 
> RTCweb signaling gateways to interface between the RTCweb signaling 
> and the legacy networks (SIP,
> H.323 etc) and there will need to be in place mechanisms for peering, 
> federation and address resolution between networks as well as service 
> agreements in place between the players.
>
> Until those are resolved supporting codecs used in those networks is 
> pointless.
>
> Andrew
>
> ----- Original Message -----
> From: Koen Vos [mailto:koen.vos@skype.net]
> Sent: Thursday, March 14, 2013 03:32 PM Central Standard Time
> To: Espen Berger (espeberg) ; 
> stephane.proust@orange.com 
> Cc: rtcweb@ietf.org ; MARJOU Xavier OLNC/OLN 
> 
> Subject: Re: [rtcweb] Agenda time     request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> > It's interop with billions of mobile phones and with fixed
> terminals in legacy telephony services.
>
> The problem is that WebRTC and legacy services live in separate
> networks: the open Web vs proprietary Telco networks.
>
> WebRTC connecting to a Telco network would have to go through a 
> Gateway.  The PSTN termination providers who run these Gateways 
> support G.711, G.729 and perhaps some other  codecs like iLBC.  They 
> do not, however, support the codecs you are advocating for.
>
> The lack of support for Transcoding-Free Operation by Telcos to the 
> rest of the world has been hurting interop voice quality for a long 
> time, but unfortunately we can't fix that here at the IETF.
>
> We can fit our cars with your costly railroad wheels, but you still 
> wouldn't let us on your tracks.
>
> koen.
>
>
> -----Original Message-----
> From: rtcweb-bounces@ietf.org
> [mailto:rtcweb-bounces@ietf.org] On Behalf Of 
> stephane.proust@orange.com
> Sent: 14. mars 2013 13:36
> To: Jean-Marc Valin
> Cc: rtcweb@ietf.org; MARJOU Xavier OLNC/OLN
> Subject: Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> Hello
>
> The short list is aligned to what is specified in 3GPP
> (mobile) and CAT-iq (fixed). Check the related service specifications!
> The short list (AMR, AMR-WB, G.722) is a minimal subset of codecs to 
> minimize interop issues and transcoding costs for telco services.
> It's not a question of what's the favourite codec for a given 
> application. It's interop with billions of mobile phones and with 
> fixed terminals in legacy telephony services.
>
> St=E9phane
>
> -----Message d'origine-----
> De : Jean-Marc Valin [mailto:jmvalin@mozilla.com] Envoy=E9 :
> jeudi 14 mars 2013 05:55 =C0 : PROUST Stephane OLNC/OLPS Cc :
> Andrew Allen; Markus.Isomaki@nokia.com; MARJOU Xavier OLNC/OLN; 
> rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/13/2013 06:48 PM, stephane.proust@orange.com wrote:
> > The reason is simply that AMR and AMR-WB are supported in
> billions of
> > devices !
>
> Just curious, why exclude from the list other codecs with similar huge 
> deployment? I can think of at least:
> - - GSM-FR (mobile)
> - - Speex (Flash)
> - - G.729 (PSTN gateways)
> - - iLBC (PSTN gateways)
> - - G.726 (DECT)
> - - SILK (original non-Opus version in Skype)
>
> (sorry, if I missed someone's favorite codec in this list)
>
> It's not at all clear to me what's so special that makes AMR, AMR-WB 
> and G.722 different from the other codecs in the list above. Not that 
> I insist on shipping G.729 :-)
>
> Personally, I'd favor a draft that included a lot more codecs, 
> describing for each one the benefits of supporting it. Implementers 
> could then choose which of these they care about for their particular 
> situation.
>
> Cheers,
>
>         Jean-Marc
>
> > St=E9phane
> >
> >
> > -----Message d'origine----- De : Andrew Allen 
> > [mailto:aallen@blackberry.com] Envoy=E9 : mercredi 13 mars 2013
> > 23:41 =C0 : PROUST Stephane OLNC/OLPS; Markus.Isomaki@nokia.com; 
> > jmvalin@mozilla.com Cc : MARJOU Xavier OLNC/OLN;
> rtcweb@ietf.org Objet
> > : Re: [rtcweb] Agenda time request for
> > draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> >
> > No this wouldn't be acceptable to me.
> >
> > I don't see a reason to push a particular set of Codecs
> over any other
> > set of codecs supported on the device. If the device supports the 
> > codecs and they are available to the browser then we should
> recommend
> > that they be offered in the negotiation.
> >
> > The marjou draft can advertise the merits and reasons why they are 
> > good codecs to support.
> >
> >
> > ----- Original Message ----- From: stephane.proust@orange.com 
> > [mailto:stephane.proust@orange.com] Sent: Wednesday, March 13, 2013
> > 05:14 PM Central Standard Time To: Markus.Isomaki@nokia.com 
> > ; jmvalin@mozilla.com
> 
> > Cc: MARJOU Xavier OLNC/OLN ;
> rtcweb@ietf.org
> > 
> > Subject: Re: [rtcweb] Agenda time     request for
> > draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> > Dear Markus
> >
> > Thanks for your attempt to help !
> >
> > Of course each Telco can handle this directly with vendors and 
> > browsers manufacturers at business level. But I don't'think
> this need
> > of interoperability with mobile devices is specific to Orange.
> > I think all mobile operators will have the same issue and
> this is why
> > standardization exist. It's most cost and time efficient to
> have one
> > common way forward for all the industry.
> >
> > Then if the issue is that "conditional MUST/SHOULD are a too 
> > complicated requirement. We could also live as a compromise with a 
> > formulation that has already been suggested on the reflector:
> >
> > "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" If possible with the addition of This is
> especially
> > the case for AMR, AMR-WB for interoperability with mobile
> devices and
> > G.722 for interoperability with fixed DECT CAT-iq devices
> >
> > Would it have one chance to reach consensus ?
> >
> > I think this Group should at least make one small step so that the 
> > interoperability issue with mobile terminals be not fully
> ignored in
> > the RTC Web specification considering the huge number of deployed 
> > devices. At least something must be written on this !
> > G.711 which is the only codec in addition to OPUS for
> interoperability
> > purpose is not a proper answer to this.
> >
> > St=E9phane
> >
> > -----Message d'origine----- De : Markus.Isomaki@nokia.com 
> > [mailto:Markus.Isomaki@nokia.com] Envoy=E9 : mercredi 13 mars 2013
> > 22:37 =C0 : PROUST Stephane OLNC/OLPS; jmvalin@mozilla.com; MARJOU 
> > Xavier OLNC/OLN Cc : rtcweb@ietf.org Objet : RE: [rtcweb]
> Agenda time
> > request for draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> > Hi Stephane, Xavier,
> >
> > I understand the intent of your proposal. I'm not sure if
> the IETF is
> > the best venue for you to pursue it, however. Perhaps you
> as a mobile
> > operator should rather set it as a requirement to your
> mobile device
> > platforms that they open up the APIs to AMR and AMR-WB and that at 
> > least the in-built default browser needs to support it. If
> there are
> > enough operators setting such requirements directly to the
> device and
> > platform vendors, it probably has a bigger impact than an IETF RFC.
> > Getting that support for user-installed additional browsers
> might be
> > more difficult, but most mobile device users stick with the default 
> > browser anyway.
> >
> > The RTCWEB codec document needs to definitely explain this case and 
> > the benefits, but the conditional MUSTs or SHOULDs you are
> proposing
> > are perhaps a bit too complicated. Hmm, perhaps we need to do an 
> > _informational_ RFC as something like "Recommendations for
> WebRTC on
> > Mobile Devices" addressing the codec and perhaps other issues, that 
> > you could use as a reference in your requirements.
> >
> > Markus
> >
> >
> >> -----Original Message----- From: rtcweb-bounces@ietf.org 
> >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext 
> >> stephane.proust@orange.com Sent: 13 March, 2013 21:37 To:
> >> Jean-Marc Valin; MARJOU Xavier OLNC/OLN Cc: rtcweb@ietf.org
> >> Subject: Re: [rtcweb] Agenda time request for
> >> draft-marjou-rtcweb-audio- codecs-for-interop-01
> >>
> >> Hello
> >>
> >> Our understanding is that the reason of the "no consensus" on 
> >> additional recommended codecs was the additional costs for
> browsers.
> >> The proposal is then to make these "MUST" fully conditional to the 
> >> case of no (or very reduced) additional costs, when the codecs are 
> >> already available on the device and when no additional
> license fee is
> >> required
> >>
> >> We could even live with lower level of "requirements" with 
> >> respectively May and Should (instead of Should and shall) but we 
> >> think that this proposal is a way to take into account
> both browser
> >> manufacturers concerns on browsers costs and telcos concerns on 
> >> transcoding costs and some other companies share this view.
> >>
> >> St=E9phane
> >>
> >>
> >>
> >>
> >>
> >>
> >> -----Message d'origine----- De : rtcweb-bounces@ietf.org 
> >> [mailto:rtcweb-bounces@ietf.org] De la part de Jean-Marc
> Valin Envoy=E9
> >> : mercredi 13 mars 2013 20:24 =C0 : MARJOU Xavier OLNC/OLN Cc :
> >> rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time request for
> >> draft-marjou-rtcweb-audio-codecs-for-interop-01
> >>
> > Hi,
> >
> > I'd really like to understand how the chairs coming to the
> conclusion
> > that there was *no consensus* on recommended codecs can result in a 
> > draft that includes 3 MUSTs and 1 SHOULD. This draft
> effectively makes
> > 3 new codecs MTI for a range of devices. I understand that it's an 
> > individual draft and you can write whatever you like in
> there, but it
> > definitely goes against the result of the WG discussion.
> >
> > Cheers,
> >
> > Jean-Marc
> >
> > On 03/13/2013 09:14 AM, Xavier Marjou wrote:
> >>>> Here is a summary of the
> >>>> draft-marjou-rtcweb-audio-codecs-for-interop-00
> presentation that I
> >>>> had prepared for yesterday's session:
> >>>>
> >>>> - The co-authors want to underline that non-WebRTC voice
> endpoints
> >>>> usually use one of the following codecs: AMR, AMR-WB or G.722, 
> >>>> which will result in massive transcoding when there will be 
> >>>> communications between WebRTC endpoints and non-WebRTC endpoints.
> >>>>
> >>>> - On one side, transcoding is bad for many reasons
> discussed in the
> >>>> draft (cost issues, intrinsic quality degradation, degraded 
> >>>> interactivity, fallback from HD to G.711...);
> >>>>
> >>>> - On the other side, it is recognized that implementing
> additional
> >>>> codecs in the browsers can generate additional costs.
> >>>>
> >>>> - In order to reach a compromise, we would like to add
> some text in
> >>>> the WG draft draft-ietf-rtcweb-audio providing
> incentives for the
> >>>> browser to use these three codecs: make them mandatory
> to implement
> >>>> when there is no cost impact on the browser (e.g. if
> codec already
> >>>> installed, paid by the device vendor...).
> >>>>
> >>>> Any opinion on that?
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Xavier
> >>>>
> >>>> PS: I will be ready to present the slides on Thursday if time 
> >>>> permits it.
> >>>>
> >>>> (c.f.
> >>>> http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf
> >>>>
> >>>>
> )
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie  >>>> > wrote:
> >>>>
> >>>> Magnus and I discussed this this morning, and we
> encourage you to
> >>>> prepare something.  If the discussion of working group last call 
> >>>> items runs short, we may be able to fit this in at that
> time or at
> >>>> the end of day one if its full agenda his finished.
> This is not a
> >>>> commitment, however, so please try and get discussion on
> the list
> >>>> on the points from the draft you feel need resolution.
> >>>>
> >>>> regards,
> >>>>
> >>>> Ted
> >>>>
> >>>>
> >>>> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg) 
> >>>> > wrote:
> >>>>> Hello,
> >>>>>
> >>>>>
> >>>>>
> >>>>> I would like to request agenda time for:
> >>>>>
> >>>>>
> >>>>>
> >>>>> draft-marjou-rtcweb-audio-codecs-for-interop-01
> >>>>>
> >>>>>
> >>>>>
> >>>>> The document  presents use-cases underlining why WebRTC needs
> >>>> AMR-WB,  AMR
> >>>>> and G.722 as additional relevant voice codecs to satisfactorily 
> >>>>> ensure interoperability with existing systems.
> >>>>>
> >>>>>
> >>>>>
> >>>>> A 10-minute time slot should be sufficient for presentation and
> >>>> discussion.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Regards
> >>>>>
> >>>>>
> >>>>>
> >>>>> -Espen
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________ 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
> >>
> >> ___________________________________________________________
> >> ___________________________________________________________ ___
> >>
> >> Ce message et ses pieces jointes peuvent contenir des informations 
> >> confidentielles ou privilegiees et ne doivent donc pas
> etre diffuses,
> >> exploites ou copies sans autorisation. Si vous avez recu
> ce message
> >> par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> >> que les pieces jointes. Les messages electroniques etant
> susceptibles
> >> d'alteration, France Telecom - Orange decline toute
> responsabilite si
> >> ce message a ete altere, deforme ou falsifie. Merci.
> >>
> >> This message and its attachments may contain confidential or 
> >> privileged information that may be protected by law; they
> should not
> >> be distributed, used or copied without authorisation. If you have 
> >> received this email in error, please notify the sender and delete 
> >> this message and its attachments. As emails may be altered, France 
> >> Telecom - Orange is not liable for messages that have been
> modified,
> >> changed or falsified. Thank you.
> >>
> >> _______________________________________________ rtcweb
> mailing list
> >> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> ______________________________________________________________________
> > ___________________________________________________
> >
> >  Ce message et ses pieces jointes peuvent contenir des informations 
> > confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message 
> > par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> > que les pieces jointes. Les messages electroniques etant
> susceptibles
> > d'alteration, France Telecom - Orange decline toute
> responsabilite si
> > ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or 
> > privileged information that may be protected by law; they
> should not
> > be distributed, used or copied without authorisation. If you have 
> > received this email in error, please notify the sender and
> delete this
> > message and its attachments. As emails may be altered,
> France Telecom
> > - Orange is not liable for messages that have been
> modified, changed
> > or falsified. Thank you.
> >
> > _______________________________________________ rtcweb mailing list 
> > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> ---------------------------------------------------------------------
> >
> >
> This transmission (including any attachments) may contain confidential 
> information, privileged material (including material protected by the 
> solicitor-client or other applicable privileges), or constitute 
> non-public information.
> Any use of this information by anyone other than the intended 
> recipient is prohibited. If you have received this transmission in 
> error, please immediately reply to the sender and delete this 
> information from your system. Use, dissemination, distribution, or 
> reproduction of this transmission by unintended recipients is not 
> authorized and may be unlawful.
> >
> >
> ______________________________________________________________________
> > ___________________________________________________
> >
> >  Ce message et ses pieces jointes peuvent contenir des informations 
> > confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message 
> > par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> > que les pieces jointes. Les messages electroniques etant
> susceptibles
> > d'alteration, France Telecom - Orange decline toute
> responsabilite si
> > ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or 
> > privileged information that may be protected by law; they
> should not
> > be distributed, used or copied without authorisation. If you have 
> > received this email in error, please notify the sender and
> delete this
> > message and its attachments. As emails may be altered,
> France Telecom
> > - Orange is not liable for messages that have been
> modified, changed
> > or falsified. Thank you.
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJRQVgzAAoJEJ6/8sItn9q9fgYH/jcWfhRrvPM1hJ22YcE7eR0N
> OZzP/RvSrUBiIA6kG+6+Hvn5Lp/tXd+LxUDp5L8B3Toce7TBBAYNJP3M2cr8N8It
> SjVvPHtBNKEqhBLbI4FbAouvymNH4utjAWR+MmF9LRySPXZ9nxLN0A13TeUlpZxt
> Jaxr/n9AWwkKOk6BIo1Xztbk26MObiGVLhCE+CPoHaHe29bKblPcphBXC935ymHS
> SuF2DXiAq0iKwZoVOsLe3RIaGg+bjN7N2MXi3Vphr7cOQK+JpdxURDrvmPh7/L8R
> ht1RJt928yl4fEjnKhSKJLd1J+gPBe6vnkSxUp89as03bLirLwN1G2giD3YzfLM=3D
> =3DK56v
> -----END PGP SIGNATURE-----
>
> ______________________________________________________________
> ___________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi 
> que les pieces jointes. Les messages electroniques etant susceptibles 
> d'alteration, France Telecom - Orange decline toute responsabilite si 
> ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not 
> be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and 
> delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for 
> messages that have been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> 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
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential 
> information, privileged material (including material protected by the 
> solicitor-client or other applicable privileges), or constitute 
> non-public information.
> Any use of this information by anyone other than the intended 
> recipient is prohibited. If you have received this transmission in 
> error, please immediately reply to the sender and delete this 
> information from your system. Use, dissemination, distribution, or 
> reproduction of this transmission by unintended recipients is not 
> authorized and may be unlawful.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

____________________________________________________________________________=
_____________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages ele=
ctroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete alt=
ere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delet=
e this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages=
 that have been modified, changed or falsified.
Thank you.


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From giles@thaumas.net  Fri Mar 15 09:08: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 90B5221F87B3 for ; Fri, 15 Mar 2013 09:08:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.048
X-Spam-Level: 
X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=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 MnF+q7d+Ihdh for ; Fri, 15 Mar 2013 09:08:07 -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 57AF821F8461 for ; Fri, 15 Mar 2013 09:07:58 -0700 (PDT)
Received: by mail-ie0-f173.google.com with SMTP id 9so4601048iec.18 for ; Fri, 15 Mar 2013 09:07:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received: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=noKNq6iK6cLAf+JUHrB8cWGV4bEfjFh7pGBoELAnL9c=; b=fn6QqWllrW6qcS1MD7Dn5vk7MsEWV7WvBLQHYYW6he2MlOeNgCZF+NYrC1dAiPfSRJ PJvbtXyvoZPRYmZA+To2fSpIJNArfHuW/gSQtlHnbP3inS0Vi56wf15e/fdqjsDG5ba3 Xf9THlerIoeb+bKyBdsn6DJEgjO1i3YpAWgiCSR2T/5AekhmR3BZjjXDiJtIv3e4ZPDG FtDxT15XqTVrV/zcdiNhrioJWz71dxxI3ojc3+ACS3kvpbymhTJ2aUKit7d5xoa6Xzig R1nWz3b12BDeNTVOJ6QT6Xn6yGfl5QNTVEF60z45+8jn6lz8nFrkqwmN8R3ktSkFM20K XXkA==
X-Received: by 10.50.180.197 with SMTP id dq5mr1542366igc.22.1363363677680; Fri, 15 Mar 2013 09:07:57 -0700 (PDT)
Received: from Glaucomys.local ([66.207.208.98]) by mx.google.com with ESMTPS id ew5sm2152402igc.2.2013.03.15.09.07.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Mar 2013 09:07:56 -0700 (PDT)
Message-ID: <5143475A.8070101@thaumas.net>
Date: Fri, 15 Mar 2013 12:07:54 -0400
From: Ralph Giles 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Roman Shpount 
References:    <20130313142732.GE12022@audi.shelbyville.oz> <7897A33F-F73A-4C39-B4DA-16F014A43C5C@edvina.net>  <8B7442F6-5393-4C5C-88B6-A680742F60E7@edvina.net>  <3C89A60B-3171-49B0-A78F-304337DF8D3D@edvina.net> <5140BC2C.90206@nostrum.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQnO8u8U6bH8A5YPMC8bTtDSK0izugA8NnTbOM4GD3UB6uS2g5rtb0hvRx6O0pUaxLEp8XZf
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 15 Mar 2013 16:08:08 -0000

On 13-03-13 2:01 PM, Roman Shpount wrote:

> All of the currently available WebRTC implementations support G.711.
> Opus, and (most likely deprecated in near future) ISAC.

Our implementation in Firefox doesn't support ISAC.

 -r

From bo.burman@ericsson.com  Fri Mar 15 09:08: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 6A5A421F8838 for ; Fri, 15 Mar 2013 09:08:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.248
X-Spam-Level: 
X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 cfle-Shhs41x for ; Fri, 15 Mar 2013 09:08:32 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 67BFE21F8820 for ; Fri, 15 Mar 2013 09:08:31 -0700 (PDT)
X-AuditID: c1b4fb25-b7f366d000004d10-b1-5143477e0ed0
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id CD.C8.19728.E7743415; Fri, 15 Mar 2013 17:08:30 +0100 (CET)
Received: from ESESSMB105.ericsson.se ([169.254.5.124]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0318.004; Fri, 15 Mar 2013 17:08:29 +0100
From: Bo Burman 
To: Harald Alvestrand , "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Cross-check of Google VP8 vs H.264 comparison
Thread-Index: Ac4g366CgEkg0T+ZQYGtOXBTo83DpwAfnjGAAA4cpCA=
Date: Fri, 15 Mar 2013 16:08:28 +0000
Message-ID: 
References:  <547ec7c4-976d-4076-900e-b67da5dae0d3@email.android.com>
In-Reply-To: <547ec7c4-976d-4076-900e-b67da5dae0d3@email.android.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: multipart/mixed; boundary="_005_BBE9739C2C302046BD34B42713A1E2A22DE32C48ESESSMB105erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMIsWRmVeSWpSXmKPExsUyM+JvjW6du3OgwazVYhbH+rrYLNb+a2d3 YPK4MuEKq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDLeHP7MXtB+hqXi96GFrA2MT7ezdDFyckgI mEisuHyGDcIWk7hwbz2QzcUhJHCIUWLr56msEM4SRolbEz4zgVSxCWhIzN9xlxHEFhEIluh9 /h7MFhZwlpjzsZ29i5EDKO4ice2UOESJlcS/pUvAWlkEVCX+b+1lBCnhFfCVaGtWgBjfwShx c8s3sBpOAVeJva1PwEYyCshK3P9+D+xQZgFxiVtP5jNBHCoi8fDiaaijRSVePv7HCjJTQkBR Ynm/HIjJLJApMXejHkgFr4CgxMmZT1gmMIrMQjJoFkLVLCRVECX5EocftkDZOhILdn9ig7C1 JZYtfM0MY5858JgJU9xR4uqM+1C2mcTupjPsEPZBRonD60whbEWJKd0PoeKuEr9mzGeGOMdK 4nSb9SxgmDALHGWUOHlsHyOy+gWMAqsY2XMTM3PSy402MQITwsEtv1V3MN45J3KIUZqDRUmc N9z1QoCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxqTvNddN2UuXCKwX6tmzrraok/9v/pfg l79Oaa774xMe0CduGHdtvsyO2KqE/eXmB5amW336v/lVeF76e4FtdQ1PT/Tl/j2+f4nRD/ZF vvHbomz19vXohy/JXF+QvTKcZ78l89qXmrXHO7WT7kt/C+x6Ir6rX6mJzcN0q7Fc7JE19ywF KsSVlViKMxINtZiLihMB1Z3BGtYCAAA=
Subject: Re: [rtcweb] Cross-check of Google VP8 vs H.264 comparison
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 15 Mar 2013 16:08:33 -0000

--_005_BBE9739C2C302046BD34B42713A1E2A22DE32C48ESESSMB105erics_
Content-Type: multipart/alternative;
	boundary="_000_BBE9739C2C302046BD34B42713A1E2A22DE32C48ESESSMB105erics_"

--_000_BBE9739C2C302046BD34B42713A1E2A22DE32C48ESESSMB105erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

We used the Google set of clips:
desktop_640_360_30
gipsrecmotion_1280_720_50
gipsrecstat_1280_720_50
kirland_640_480_30
macmarcomoving_640_480_30
macmarcostationary_640_480_30
niklas_1280_720_30
niklas_640_480_30
tacomanarrows_640_480_30
tacomasmallcameramovement_640_480_30
thaloundeskmtg_640_480_30
I also attach two files showing more detailed results, with and without the=
 --tune psnr option for x264

Cheers,
Bo.

________________________________
From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Friday, March 15, 2013 6:19 AM
To: Bo Burman; rtcweb@ietf.org
Subject: Re: [rtcweb] Cross-check of Google VP8 vs H.264 comparison

Bo, did you run tests on our clips or your own clips, and with the rest of =
the settings our way or your way? Clip selection seems to matter a lot - wh=
ich is why we published ours.

Bo Burman  wrote:

Hi,

As said on the microphone today, we have cross-checked Google's VP8 vs H.26=
4 comparison. Google reported bit rate gains for VP8 of 19%. However, the H=
.264 was at an unfair advantage due to the fact that the --tune psnr flag w=
as not used in x264. This should of course be used when doing psnr-measurem=
ents. For vp8, this flag is set to psnr by default.

When re-running the tests with --tune psnr for x264, and using version 130 =
of x264 instead of version 128 that was used in the Google test, the differ=
ence disappeared (1% difference).

Cheers,
Bo
________________________________

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

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

--_000_BBE9739C2C302046BD34B42713A1E2A22DE32C48ESESSMB105erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









We used the Google set of clips:<=
/font>


desktop_640_360_30

gipsrecmotion_1280_720_50

gipsrecstat_1280_720_50

kirland_640_480_30

macmarcomoving_640_480_30

macmarcostationary_640_480_30

niklas_1280_720_30

niklas_640_480_30

tacomanarrows_640_480_30

tacomasmallcameramovement_640_480_30

thaloundeskmtg_640_480_30




I also attach two files showing&n=
bsp;more detailed results, with and without the --tune psnr option for=
 x264


 


Cheers,


Bo.







From: Harald Alvestrand [mailto:har=
ald@alvestrand.no]


Sent: Friday, March 15, 2013 6:19 AM

To: Bo Burman; rtcweb@ietf.org

Subject: Re: [rtcweb] Cross-check of Google VP8 vs H.264 comparison<=
br>






Bo, did you run tests on our clips or your own clips, and with the rest of =
the settings our way or your way? Clip selection seems to matter a lot - wh=
ich is why we published ours.




Bo Burman <bo.burman@ericsson.com> wrote:




Hi,

As said on the microphone today, =
we have cross-checked Google's VP8 vs H.264 comparison. Google reported bit=
 rate gains for VP8 of 19%. However, the H.264 was at an unfair advantage d=
ue to the fact that the --tune psnr flag was not used in x264. This should =
of course be used when doing psnr-measurements. For vp8, this flag is set t=
o psnr by default. 

When re-running the tests with --tune psnr for x=
264, and using version 130 of x264 instead of version 128 that was used in =
the Google test, the difference disappeared (1% difference). 

Cheers=
,
Bo

rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/lis=
tinfo/rtcweb







-- 

Sent from my Android phone with K-9 Mail. Please excuse my brevity.



--_000_BBE9739C2C302046BD34B42713A1E2A22DE32C48ESESSMB105erics_--

--_005_BBE9739C2C302046BD34B42713A1E2A22DE32C48ESESSMB105erics_
Content-Type: text/html; name="vp8_vs_h264_quality_tunepsnr.html"
Content-Description: vp8_vs_h264_quality_tunepsnr.html
Content-Disposition: attachment;
	filename="vp8_vs_h264_quality_tunepsnr.html"; size=25096;
	creation-date="Fri, 15 Mar 2013 16:08:27 GMT";
	modification-date="Fri, 15 Mar 2013 16:08:27 GMT"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIGh0bWw+DQo8aHRtbCBsYW5nPSJlbiI+DQo8aGVhZD4NCjxtZXRhIGNoYXJzZXQ9
InV0Zi04Ij4NCjx0aXRsZT5Db21wYXJhdGl2ZSBSZXN1bHRzPC90aXRsZT4NCjxzdHlsZSB0eXBl
PSJ0ZXh0L2NzcyI+DQo8IS0tIEJlZ2luIDk2MCByZXNldCAtLT4NCmEsYWJicixhY3JvbnltLGFk
ZHJlc3MsYXBwbGV0LGFydGljbGUsYXNpZGUsYXVkaW8sYixiaWcsYmxvY2txdW90ZSxib2R5LGNh
bnZhcyxjYXB0aW9uLGNlbnRlcixjaXRlLGMNCm9kZSxkZCxkZWwsZGV0YWlscyxkZm4sZGlhbG9n
LGRpdixkbCxkdCxlbSxlbWJlZCxmaWVsZHNldCxmaWdjYXB0aW9uLGZpZ3VyZSxmb250LGZvb3Rl
cixmb3JtLGgxLGgyLGgNCjMsaDQsaDUsaDYsaGVhZGVyLGhncm91cCxocixodG1sLGksaWZyYW1l
LGltZyxpbnMsa2JkLGxhYmVsLGxlZ2VuZCxsaSxtYXJrLG1lbnUsbWV0ZXIsbmF2LG9iamVjdCxv
bCwNCm91dHB1dCxwLHByZSxwcm9ncmVzcyxxLHJwLHJ0LHJ1YnkscyxzYW1wLHNlY3Rpb24sc21h
bGwsc3BhbixzdHJpa2Usc3Ryb25nLHN1YixzdW1tYXJ5LHN1cCx0YWJsZSx0Ym8NCmR5LHRkLHRm
b290LHRoLHRoZWFkLHRpbWUsdHIsdHQsdSx1bCx2YXIsdmlkZW8seG1we2JvcmRlcjowO21hcmdp
bjowO3BhZGRpbmc6MDtmb250LXNpemU6MTAwJX1odG1sLGINCm9keXtoZWlnaHQ6MTAwJX1hcnRp
Y2xlLGFzaWRlLGRldGFpbHMsZmlnY2FwdGlvbixmaWd1cmUsZm9vdGVyLGhlYWRlcixoZ3JvdXAs
bWVudSxuYXYsc2VjdGlvbntkaXNwbGENCnk6YmxvY2t9YixzdHJvbmd7Zm9udC13ZWlnaHQ6Ym9s
ZH1pbWd7Y29sb3I6dHJhbnNwYXJlbnQ7Zm9udC1zaXplOjA7dmVydGljYWwtYWxpZ246bWlkZGxl
Oy1tcy1pbnRlcnANCm9sYXRpb24tbW9kZTpiaWN1YmljfW9sLHVse2xpc3Qtc3R5bGU6bm9uZX1s
aXtkaXNwbGF5Omxpc3QtaXRlbX10YWJsZXtib3JkZXItY29sbGFwc2U6Y29sbGFwc2U7Ym9yZGUN
CnItc3BhY2luZzowfXRoLHRkLGNhcHRpb257Zm9udC13ZWlnaHQ6bm9ybWFsO3ZlcnRpY2FsLWFs
aWduOnRvcDt0ZXh0LWFsaWduOmxlZnR9cXtxdW90ZXM6bm9uZX1xOmJlZm8NCnJlLHE6YWZ0ZXJ7
Y29udGVudDonJztjb250ZW50Om5vbmV9c3ViLHN1cCxzbWFsbHtmb250LXNpemU6NzUlfXN1Yixz
dXB7bGluZS1oZWlnaHQ6MDtwb3NpdGlvbjpyZWxhdGkNCnZlO3ZlcnRpY2FsLWFsaWduOmJhc2Vs
aW5lfXN1Yntib3R0b206LTAuMjVlbX1zdXB7dG9wOi0wLjVlbX1zdmd7b3ZlcmZsb3c6aGlkZGVu
fQ0KPCEtLSBFbmQgOTYwIHJlc2V0IC0tPg0KPCEtLSBCZWdpbiA5NjAgdGV4dCAtLT4NCmJvZHl7
Zm9udDoxM3B4LzEuNSAnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLCdMaWJlcmF0aW9uIFNhbnMnLEZy
ZWVTYW5zLHNhbnMtc2VyaWZ9cHJlLGNvZGV7Zm9udC1mYW1pbHkNCjonRGVqYVZ1IFNhbnMgTW9u
bycsTWVubG8sQ29uc29sYXMsbW9ub3NwYWNlfWhye2JvcmRlcjowICNjY2Mgc29saWQ7Ym9yZGVy
LXRvcC13aWR0aDoxcHg7Y2xlYXI6Ym90aDsNCmhlaWdodDowfWgxe2ZvbnQtc2l6ZToyNXB4fWgy
e2ZvbnQtc2l6ZToyM3B4fWgze2ZvbnQtc2l6ZToyMXB4fWg0e2ZvbnQtc2l6ZToxOXB4fWg1e2Zv
bnQtc2l6ZToxN3B4fWgNCjZ7Zm9udC1zaXplOjE1cHh9b2x7bGlzdC1zdHlsZTpkZWNpbWFsfXVs
e2xpc3Qtc3R5bGU6ZGlzY31saXttYXJnaW4tbGVmdDozMHB4fXAsZGwsaHIsaDEsaDIsaDMsaDQs
aDUNCixoNixvbCx1bCxwcmUsdGFibGUsYWRkcmVzcyxmaWVsZHNldCxmaWd1cmV7bWFyZ2luLWJv
dHRvbToyMHB4fQ0KPCEtLSBFbmQgOTYwIHRleHQgLS0+DQo8IS0tIEJlZ2luIDk2MCBncmlkIChm
bHVpZCB2YXJpYW50KQ0KICAgICAxMiBjb2x1bW5zLCAxMTUycHggdG90YWwgd2lkdGgNCiAgICAg
aHR0cDovLzk2MC5ncy8gfCBodHRwOi8vZ3JpZHMuaGVyb2t1LmNvbS8gLS0+DQouY29udGFpbmVy
XzEye3dpZHRoOjkyJTttYXJnaW4tbGVmdDo0JTttYXJnaW4tcmlnaHQ6NCV9LmdyaWRfMSwuZ3Jp
ZF8yLC5ncmlkXzMsLmdyaWRfNCwuZ3JpZF81LC5ncmlkDQpfNiwuZ3JpZF83LC5ncmlkXzgsLmdy
aWRfOSwuZ3JpZF8xMCwuZ3JpZF8xMSwuZ3JpZF8xMntkaXNwbGF5OmlubGluZTtmbG9hdDpsZWZ0
O3Bvc2l0aW9uOnJlbGF0aXZlO21hDQpyZ2luLWxlZnQ6MSU7bWFyZ2luLXJpZ2h0OjElfS5hbHBo
YXttYXJnaW4tbGVmdDowfS5vbWVnYXttYXJnaW4tcmlnaHQ6MH0uY29udGFpbmVyXzEyIC5ncmlk
XzF7d2lkdGg6DQo2LjMzMyV9LmNvbnRhaW5lcl8xMiAuZ3JpZF8ye3dpZHRoOjE0LjY2NyV9LmNv
bnRhaW5lcl8xMiAuZ3JpZF8ze3dpZHRoOjIzLjAlfS5jb250YWluZXJfMTIgLmdyaWRfNHt3DQpp
ZHRoOjMxLjMzMyV9LmNvbnRhaW5lcl8xMiAuZ3JpZF81e3dpZHRoOjM5LjY2NyV9LmNvbnRhaW5l
cl8xMiAuZ3JpZF82e3dpZHRoOjQ4LjAlfS5jb250YWluZXJfMTIgLmdyDQppZF83e3dpZHRoOjU2
LjMzMyV9LmNvbnRhaW5lcl8xMiAuZ3JpZF84e3dpZHRoOjY0LjY2NyV9LmNvbnRhaW5lcl8xMiAu
Z3JpZF85e3dpZHRoOjczLjAlfS5jb250YWluZXJfDQoxMiAuZ3JpZF8xMHt3aWR0aDo4MS4zMzMl
fS5jb250YWluZXJfMTIgLmdyaWRfMTF7d2lkdGg6ODkuNjY3JX0uY29udGFpbmVyXzEyIC5ncmlk
XzEye3dpZHRoOjk4LjAlfS5jDQpvbnRhaW5lcl8xMiAucHJlZml4XzF7cGFkZGluZy1sZWZ0Ojgu
MzMzJX0uY29udGFpbmVyXzEyIC5wcmVmaXhfMntwYWRkaW5nLWxlZnQ6MTYuNjY3JX0uY29udGFp
bmVyXzEyDQogLnByZWZpeF8ze3BhZGRpbmctbGVmdDoyNS4wJX0uY29udGFpbmVyXzEyIC5wcmVm
aXhfNHtwYWRkaW5nLWxlZnQ6MzMuMzMzJX0uY29udGFpbmVyXzEyIC5wcmVmaXhfNXtwDQphZGRp
bmctbGVmdDo0MS42NjclfS5jb250YWluZXJfMTIgLnByZWZpeF82e3BhZGRpbmctbGVmdDo1MC4w
JX0uY29udGFpbmVyXzEyIC5wcmVmaXhfN3twYWRkaW5nLWxlZnQ6DQo1OC4zMzMlfS5jb250YWlu
ZXJfMTIgLnByZWZpeF84e3BhZGRpbmctbGVmdDo2Ni42NjclfS5jb250YWluZXJfMTIgLnByZWZp
eF85e3BhZGRpbmctbGVmdDo3NS4wJX0uY29uDQp0YWluZXJfMTIgLnByZWZpeF8xMHtwYWRkaW5n
LWxlZnQ6ODMuMzMzJX0uY29udGFpbmVyXzEyIC5wcmVmaXhfMTF7cGFkZGluZy1sZWZ0OjkxLjY2
NyV9LmNvbnRhaW5lcl8xDQoyIC5zdWZmaXhfMXtwYWRkaW5nLXJpZ2h0OjguMzMzJX0uY29udGFp
bmVyXzEyIC5zdWZmaXhfMntwYWRkaW5nLXJpZ2h0OjE2LjY2NyV9LmNvbnRhaW5lcl8xMiAuc3Vm
Zml4DQpfM3twYWRkaW5nLXJpZ2h0OjI1LjAlfS5jb250YWluZXJfMTIgLnN1ZmZpeF80e3BhZGRp
bmctcmlnaHQ6MzMuMzMzJX0uY29udGFpbmVyXzEyIC5zdWZmaXhfNXtwYWRkaW5nDQotcmlnaHQ6
NDEuNjY3JX0uY29udGFpbmVyXzEyIC5zdWZmaXhfNntwYWRkaW5nLXJpZ2h0OjUwLjAlfS5jb250
YWluZXJfMTIgLnN1ZmZpeF83e3BhZGRpbmctcmlnaHQ6NTguDQozMzMlfS5jb250YWluZXJfMTIg
LnN1ZmZpeF84e3BhZGRpbmctcmlnaHQ6NjYuNjY3JX0uY29udGFpbmVyXzEyIC5zdWZmaXhfOXtw
YWRkaW5nLXJpZ2h0Ojc1LjAlfS5jb250DQphaW5lcl8xMiAuc3VmZml4XzEwe3BhZGRpbmctcmln
aHQ6ODMuMzMzJX0uY29udGFpbmVyXzEyIC5zdWZmaXhfMTF7cGFkZGluZy1yaWdodDo5MS42Njcl
fS5jb250YWluZXJfDQoxMiAucHVzaF8xe2xlZnQ6OC4zMzMlfS5jb250YWluZXJfMTIgLnB1c2hf
MntsZWZ0OjE2LjY2NyV9LmNvbnRhaW5lcl8xMiAucHVzaF8ze2xlZnQ6MjUuMCV9LmNvbnRhaW5l
DQpyXzEyIC5wdXNoXzR7bGVmdDozMy4zMzMlfS5jb250YWluZXJfMTIgLnB1c2hfNXtsZWZ0OjQx
LjY2NyV9LmNvbnRhaW5lcl8xMiAucHVzaF82e2xlZnQ6NTAuMCV9LmNvbnRhDQppbmVyXzEyIC5w
dXNoXzd7bGVmdDo1OC4zMzMlfS5jb250YWluZXJfMTIgLnB1c2hfOHtsZWZ0OjY2LjY2NyV9LmNv
bnRhaW5lcl8xMiAucHVzaF85e2xlZnQ6NzUuMCV9LmNvDQpudGFpbmVyXzEyIC5wdXNoXzEwe2xl
ZnQ6ODMuMzMzJX0uY29udGFpbmVyXzEyIC5wdXNoXzExe2xlZnQ6OTEuNjY3JX0uY29udGFpbmVy
XzEyIC5wdWxsXzF7bGVmdDotOC4zDQozMyV9LmNvbnRhaW5lcl8xMiAucHVsbF8ye2xlZnQ6LTE2
LjY2NyV9LmNvbnRhaW5lcl8xMiAucHVsbF8ze2xlZnQ6LTI1LjAlfS5jb250YWluZXJfMTIgLnB1
bGxfNHtsZWZ0DQo6LTMzLjMzMyV9LmNvbnRhaW5lcl8xMiAucHVsbF81e2xlZnQ6LTQxLjY2NyV9
LmNvbnRhaW5lcl8xMiAucHVsbF82e2xlZnQ6LTUwLjAlfS5jb250YWluZXJfMTIgLnB1bGxfDQo3
e2xlZnQ6LTU4LjMzMyV9LmNvbnRhaW5lcl8xMiAucHVsbF84e2xlZnQ6LTY2LjY2NyV9LmNvbnRh
aW5lcl8xMiAucHVsbF85e2xlZnQ6LTc1LjAlfS5jb250YWluZXJfMTINCi5wdWxsXzEwe2xlZnQ6
LTgzLjMzMyV9LmNvbnRhaW5lcl8xMiAucHVsbF8xMXtsZWZ0Oi05MS42NjclfS5jbGVhcntjbGVh
cjpib3RoO2Rpc3BsYXk6YmxvY2s7b3ZlcmZsb3cNCjpoaWRkZW47dmlzaWJpbGl0eTpoaWRkZW47
d2lkdGg6MDtoZWlnaHQ6MH0uY2xlYXJmaXg6YWZ0ZXJ7Y2xlYXI6Ym90aDtjb250ZW50OicgJztk
aXNwbGF5OmJsb2NrO2ZvbnQNCi1zaXplOjA7bGluZS1oZWlnaHQ6MDt2aXNpYmlsaXR5OmhpZGRl
bjt3aWR0aDowO2hlaWdodDowfS5jbGVhcmZpeHtkaXNwbGF5OmlubGluZS1ibG9ja30qIGh0bWwg
LmNsZWENCnJmaXh7aGVpZ2h0OjElfS5jbGVhcmZpeHtkaXNwbGF5OmJsb2NrfQ0KPCEtLSBFbmQg
OTYwIGdyaWQgLS0+DQoNCmRpdi5tZXRyaWNncmFwaCB7DQoNCn0NCg0KYm9keSB7DQoNCn0NCg0K
ZGl2LmhlYWRlciB7DQogIGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsNCn0NCg0KZGl2
LmhlYWRlciBoMiB7DQogIG1hcmdpbjogLjVlbSBhdXRvOw0KfQ0KDQpkaXYucmFkaW8gew0KICBm
b250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7DQogIG1hcmdpbi1ib3R0b206IDFlbTsNCn0N
Cg0KZGl2Lm1haW4gew0KDQp9DQoNCmRpdi5jbGlwbGlzdCB7DQogIGZvbnQtZmFtaWx5OiBBcmlh
bCwgc2Fucy1zZXJpZjsNCiAgbWFyZ2luLXRvcDogNnB4Ow0KfQ0KDQpkaXYuY2hhcnRhcmVhIHsN
CiAgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOw0KfQ0KDQpkaXYuaW5kaWNhdG9ycyB7
DQogIGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsNCiAgZm9udC1zaXplOiAxM3B4Ow0K
ICBtYXJnaW4tdG9wOiA2cHg7DQogIG1pbi1oZWlnaHQ6IDYwMHB4Ow0KICBiYWNrZ3JvdW5kLWNv
bG9yOiAjZjdmN2Y3Ow0KfQ0KDQpkaXYuaW5kaWNhdG9ycyBkaXYuY29udGVudCB7DQogIG1hcmdp
bjogMWVtOw0KfQ0KDQpkaXYuaW5kaWNhdG9ycyBkaXYuY29udGVudCBoNSB7DQogIGZvbnQtc2l6
ZTogMTNweDsNCiAgdGV4dC1hbGlnbjogY2VudGVyOw0KICBtYXJnaW46IDA7DQp9DQoNCmRpdi5p
bmRpY2F0b3JzIGRpdi5jb250ZW50IHVsIHsNCiAgbWFyZ2luLWxlZnQ6IDA7DQogIHBhZGRpbmct
bGVmdDogMDsNCiAgbWFyZ2luLXRvcDogMDsNCn0NCg0KZGl2LmluZGljYXRvcnMgZGl2LmNvbnRl
bnQgdWwgbGkgew0KICBtYXJnaW4tbGVmdDogMS41ZW07DQp9DQoNCmRpdi5pbmRpY2F0b3JzIGRp
di5jb250ZW50IHA6Zmlyc3QtY2hpbGQgew0KICBtYXJnaW4tYm90dG9tOiAuNWVtOw0KfQ0KDQpz
cGFuLmdvb2dsZS12aXN1YWxpemF0aW9uLXRhYmxlLXNvcnRpbmQgew0KICBjb2xvcjogIzAwMDsN
Cn0NCg0KLmhlYWRlci1zdHlsZSB7DQogIGZvbnQtd2VpZ2h0OiBib2xkOw0KICBib3JkZXI6IDFw
eCBzb2xpZCAjZmZmOw0KICBiYWNrZ3JvdW5kLWNvbG9yOiAjY2NjOw0KfQ0KDQp0ZC5oZWFkZXIt
c3R5bGUrdGQgew0KDQp9DQoNCi5vcmFuZ2UtYmFja2dyb3VuZCB7DQogIGJhY2tncm91bmQtY29s
b3I6IG9yYW5nZTsNCn0NCg0KLmxpZ2h0LWdyYXktYmFja2dyb3VuZCB7DQogIGJhY2tncm91bmQt
Y29sb3I6ICNmMGYwZjA7DQp9DQo8L3N0eWxlPg0KPHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3Jp
cHQiIHNyYz0iaHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS9qc2FwaSI+PC9zY3JpcHQ+DQo8c2NyaXB0
IHR5cGU9InRleHQvamF2YXNjcmlwdCI+DQpnb29nbGUubG9hZCgndmlzdWFsaXphdGlvbicsICcx
LjEnLCB7J3BhY2thZ2VzJzpbJ3RhYmxlJ119KTsNCnZhciBjaGFydF9sZWZ0ICAgPSA2MDsNCnZh
ciBjaGFydF90b3AgICAgPSA2Ow0KdmFyIGNoYXJ0X2hlaWdodCA9IGRvY3VtZW50LmRvY3VtZW50
RWxlbWVudC5jbGllbnRIZWlnaHQtMTAwOw0KdmFyIGNoYXJ0X3dpZHRoICA9ICIxMDAlIjsNCmZ0
YWJsZT0nZmlsZXN0YWJsZV9hdmcnDQp2YXIgc25ycyA9IFtdOw0KdmFyIGZpbGVzdGFibGVfZHNu
ciA9IFtdOw0KdmFyIGZpbGVzdGFibGVfZHJhdGUgPSBbXTsNCnZhciBmaWxlc3RhYmxlX2F2ZyA9
IFtdOw0KDQovLyBQeXRob24gdGVtcGxhdGUgY29kZSByZXBsYWNlcyB0aGUgZm9sbG93aW5nIDIg
bGluZXMuDQpmaWxlc3RhYmxlX2RzbnJbMV09eyJyb3dzIjpbeyJjIjpbeyJ2IjoiZGVza3RvcF82
NDBfMzYwXzMwIn0seyJ2IjotMC40NzU0NzE4NTgyODY4NjYzM31dfSx7ImMiOlt7InYiOiJnaXBz
cmVjbW90aW9uXzEyODBfNzIwXzUwIn0seyJ2IjowLjg0MTg2NzQ1NDI5ODA5NTUxfV19LHsiYyI6
W3sidiI6ImdpcHNyZWNzdGF0XzEyODBfNzIwXzUwIn0seyJ2IjowLjc0OTI1OTE1MjIxMjA4NDcy
fV19LHsiYyI6W3sidiI6ImtpcmxhbmRfNjQwXzQ4MF8zMCJ9LHsidiI6LTAuMTc4NTI4NTA4MDE1
ODI1OTV9XX0seyJjIjpbeyJ2IjoibWFjbWFyY29tb3ZpbmdfNjQwXzQ4MF8zMCJ9LHsidiI6MC41
NDE4MTk3MDI0MDY3Mzk3MX1dfSx7ImMiOlt7InYiOiJtYWNtYXJjb3N0YXRpb25hcnlfNjQwXzQ4
MF8zMCJ9LHsidiI6MC4wMTE5MDYzNzIyNDUyNjMxMDV9XX0seyJjIjpbeyJ2IjoibmlrbGFzXzEy
ODBfNzIwXzMwIn0seyJ2IjowLjQxMDc5MDYyOTE5NDgxMDN9XX0seyJjIjpbeyJ2IjoibmlrbGFz
XzY0MF80ODBfMzAifSx7InYiOjAuMzA5MDA2MDAxNzExODkyNDF9XX0seyJjIjpbeyJ2IjoidGFj
b21hbmFycm93c182NDBfNDgwXzMwIn0seyJ2IjotMC4wODMyMDE1MTI4NDMwMjExM31dfSx7ImMi
Olt7InYiOiJ0YWNvbWFzbWFsbGNhbWVyYW1vdmVtZW50XzY0MF80ODBfMzAifSx7InYiOjAuMTc5
MTkxOTY0ODIzNTA5MTl9XX0seyJjIjpbeyJ2IjoidGhhbG91bmRlc2ttdGdfNjQwXzQ4MF8zMCJ9
LHsidiI6LTAuMDE4MjQwNzM0NDQxNzUyNzk5fV19LHsiYyI6W3sidiI6Ik9WRVJBTEwifSx7InYi
OjAuMjA4MDM2MjQyMTE4NjI5ODl9XX1dLCJjb2xzIjpbeyJ0eXBlIjoic3RyaW5nIiwiaWQiOiJm
aWxlIiwibGFiZWwiOiJGaWxlIn0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy92cDgiLCJs
YWJlbCI6InN0YXRzL3ZwOCJ9XX0NCg0KZmlsZXN0YWJsZV9hdmdbMV09eyJyb3dzIjpbeyJjIjpb
eyJ2IjoiZGVza3RvcF82NDBfMzYwXzMwIn0seyJ2IjotMTIuNjEyMDczMDkxNDQwNzc1fV19LHsi
YyI6W3sidiI6ImdpcHNyZWNtb3Rpb25fMTI4MF83MjBfNTAifSx7InYiOjIxLjc2MzIxNDA2MjI5
ODcyfV19LHsiYyI6W3sidiI6ImdpcHNyZWNzdGF0XzEyODBfNzIwXzUwIn0seyJ2IjoyMy4zNDEw
MDc1NTk5NjEwMDN9XX0seyJjIjpbeyJ2Ijoia2lybGFuZF82NDBfNDgwXzMwIn0seyJ2IjotMTUu
OTA5MzI5NjExMTkzNTg4fV19LHsiYyI6W3sidiI6Im1hY21hcmNvbW92aW5nXzY0MF80ODBfMzAi
fSx7InYiOjkuNDQ2MDA5NjIxNjcyMDE0fV19LHsiYyI6W3sidiI6Im1hY21hcmNvc3RhdGlvbmFy
eV82NDBfNDgwXzMwIn0seyJ2IjotOS45MTY5MDg1MDk1Mzk4NzF9XX0seyJjIjpbeyJ2Ijoibmlr
bGFzXzEyODBfNzIwXzMwIn0seyJ2IjoxMS40Njk3OTg4NTA4MTU5NTJ9XX0seyJjIjpbeyJ2Ijoi
bmlrbGFzXzY0MF80ODBfMzAifSx7InYiOjQuMzM2ODYxNTIzMzEwNDM2fV19LHsiYyI6W3sidiI6
InRhY29tYW5hcnJvd3NfNjQwXzQ4MF8zMCJ9LHsidiI6LTExLjM4MzAzNzE2MjE1ODk1fV19LHsi
YyI6W3sidiI6InRhY29tYXNtYWxsY2FtZXJhbW92ZW1lbnRfNjQwXzQ4MF8zMCJ9LHsidiI6LTIu
MjAxMzI5MDkxNzI3NDV9XX0seyJjIjpbeyJ2IjoidGhhbG91bmRlc2ttdGdfNjQwXzQ4MF8zMCJ9
LHsidiI6LTQuMTQ1NzQ2MDEyOTM3MTU3fV19LHsiYyI6W3sidiI6Ik9WRVJBTEwifSx7InYiOjEu
Mjg5ODYwNzM5OTE0NTc1NH1dfV0sImNvbHMiOlt7InR5cGUiOiJzdHJpbmciLCJpZCI6ImZpbGUi
LCJsYWJlbCI6IkZpbGUifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL3ZwOCIsImxhYmVs
Ijoic3RhdHMvdnA4In1dfQ0KDQpmaWxlc3RhYmxlX2RyYXRlWzFdPXsicm93cyI6W3siYyI6W3si
diI6ImRlc2t0b3BfNjQwXzM2MF8zMCJ9LHsidiI6LTExLjQzMTE5OTY4NjI1MzAyNH1dfSx7ImMi
Olt7InYiOiJnaXBzcmVjbW90aW9uXzEyODBfNzIwXzUwIn0seyJ2IjoyMi4wNzQ5NDQ1NTc5NzQ0
NX1dfSx7ImMiOlt7InYiOiJnaXBzcmVjc3RhdF8xMjgwXzcyMF81MCJ9LHsidiI6MjIuMzA3Njc2
NjMwMTgwNzE1fV19LHsiYyI6W3sidiI6ImtpcmxhbmRfNjQwXzQ4MF8zMCJ9LHsidiI6LTQuMTIz
NTYxNjQ3MDE3OTA0fV19LHsiYyI6W3sidiI6Im1hY21hcmNvbW92aW5nXzY0MF80ODBfMzAifSx7
InYiOjE0LjkwMjA2NjMyNzkyMzE2OX1dfSx7ImMiOlt7InYiOiJtYWNtYXJjb3N0YXRpb25hcnlf
NjQwXzQ4MF8zMCJ9LHsidiI6LTAuMjg4OTc2NzY3MjcyMDk3NzZ9XX0seyJjIjpbeyJ2Ijoibmlr
bGFzXzEyODBfNzIwXzMwIn0seyJ2IjoxMS42NjkwNzI4OTkxMjY1OTd9XX0seyJjIjpbeyJ2Ijoi
bmlrbGFzXzY0MF80ODBfMzAifSx7InYiOjYuNDU2NzkwNjE4NTg0OTA3fV19LHsiYyI6W3sidiI6
InRhY29tYW5hcnJvd3NfNjQwXzQ4MF8zMCJ9LHsidiI6LTUuNTcwODYwMjU3MjY2NzYzfV19LHsi
YyI6W3sidiI6InRhY29tYXNtYWxsY2FtZXJhbW92ZW1lbnRfNjQwXzQ4MF8zMCJ9LHsidiI6MS4x
NzA2MzQxNDUzMzA5ODQzfV19LHsiYyI6W3sidiI6InRoYWxvdW5kZXNrbXRnXzY0MF80ODBfMzAi
fSx7InYiOjEuMzUxMzczMDI0NDMwOTM1Mn1dfSx7ImMiOlt7InYiOiJPVkVSQUxMIn0seyJ2Ijo1
LjMxOTgxNDUzMTQzMTA4ODV9XX1dLCJjb2xzIjpbeyJ0eXBlIjoic3RyaW5nIiwiaWQiOiJmaWxl
IiwibGFiZWwiOiJGaWxlIn0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy92cDgiLCJsYWJl
bCI6InN0YXRzL3ZwOCJ9XX0NCg0Kc25yc1sxXSA9IFsneyJyb3dzIjpbeyJjIjpbeyJ2IjoxNjku
MH0sbnVsbCx7InYiOjMyLjI5M31dfSx7ImMiOlt7InYiOjIwNC4wfSxudWxsLHsidiI6MzMuNDU2
fV19LHsiYyI6W3sidiI6MzA0LjB9LG51bGwseyJ2IjozNC43OTl9XX0seyJjIjpbeyJ2Ijo0MDQu
MH0sbnVsbCx7InYiOjM1Ljc0Nn1dfSx7ImMiOlt7InYiOjUwNC4wfSxudWxsLHsidiI6MzYuNTEz
fV19LHsiYyI6W3sidiI6NjA2LjB9LG51bGwseyJ2IjozNy4xMjF9XX0seyJjIjpbeyJ2Ijo3MDYu
MH0sbnVsbCx7InYiOjM3LjU5OX1dfSx7ImMiOlt7InYiOjgwNi4wfSxudWxsLHsidiI6MzguMDI0
fV19LHsiYyI6W3sidiI6OTUuMH0seyJ2IjozMC4xNTF9LG51bGxdfSx7ImMiOlt7InYiOjE5Ni4w
fSx7InYiOjMzLjQzMX0sbnVsbF19LHsiYyI6W3sidiI6Mjk4LjB9LHsidiI6MzUuMTYzfSxudWxs
XX0seyJjIjpbeyJ2Ijo0MDAuMH0seyJ2IjozNi4yNn0sbnVsbF19LHsiYyI6W3sidiI6NTAxLjB9
LHsidiI6MzcuMDgzfSxudWxsXX0seyJjIjpbeyJ2Ijo2MDIuMH0seyJ2IjozNy43MTh9LG51bGxd
fSx7ImMiOlt7InYiOjcwMi4wfSx7InYiOjM4LjI0NH0sbnVsbF19LHsiYyI6W3sidiI6ODAyLjB9
LHsidiI6MzguNjgxfSxudWxsXX1dLCJjb2xzIjpbeyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJkYXRh
cmF0ZSIsImxhYmVsIjoiRGF0YXJhdGUifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL2gy
NjQiLCJsYWJlbCI6InN0YXRzL2gyNjQifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL3Zw
OCIsImxhYmVsIjoic3RhdHMvdnA4In1dfScsJ3sicm93cyI6W3siYyI6W3sidiI6ODY2LjB9LG51
bGwseyJ2IjozNS43NjN9XX0seyJjIjpbeyJ2Ijo5NDguMH0sbnVsbCx7InYiOjM2LjE4NH1dfSx7
ImMiOlt7InYiOjEwMzkuMH0sbnVsbCx7InYiOjM2LjUxNn1dfSx7ImMiOlt7InYiOjExMzYuMH0s
bnVsbCx7InYiOjM2Ljg3OH1dfSx7ImMiOlt7InYiOjEyMzYuMH0sbnVsbCx7InYiOjM3LjE1Nn1d
fSx7ImMiOlt7InYiOjEzMzYuMH0sbnVsbCx7InYiOjM3LjQ2M31dfSx7ImMiOlt7InYiOjE0Mzku
MH0sbnVsbCx7InYiOjM3Ljc0OX1dfSx7ImMiOlt7InYiOjE1MzguMH0sbnVsbCx7InYiOjM4LjAx
MX1dfSx7ImMiOlt7InYiOjc4NC4wfSx7InYiOjM0LjI2M30sbnVsbF19LHsiYyI6W3sidiI6ODgz
LjB9LHsidiI6MzQuODM0fSxudWxsXX0seyJjIjpbeyJ2Ijo5ODMuMH0seyJ2IjozNS4zNX0sbnVs
bF19LHsiYyI6W3sidiI6MTA4MS4wfSx7InYiOjM1Ljc5M30sbnVsbF19LHsiYyI6W3sidiI6MTE4
My4wfSx7InYiOjM2LjIwM30sbnVsbF19LHsiYyI6W3sidiI6MTI4My4wfSx7InYiOjM2LjU3fSxu
dWxsXX0seyJjIjpbeyJ2IjoxMzg2LjB9LHsidiI6MzYuOTJ9LG51bGxdfSx7ImMiOlt7InYiOjE0
ODguMH0seyJ2IjozNy4yNH0sbnVsbF19XSwiY29scyI6W3sidHlwZSI6Im51bWJlciIsImlkIjoi
ZGF0YXJhdGUiLCJsYWJlbCI6IkRhdGFyYXRlIn0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0
cy9oMjY0IiwibGFiZWwiOiJzdGF0cy9oMjY0In0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0
cy92cDgiLCJsYWJlbCI6InN0YXRzL3ZwOCJ9XX0nLCd7InJvd3MiOlt7ImMiOlt7InYiOjgzMC4w
fSxudWxsLHsidiI6MzkuMTAzfV19LHsiYyI6W3sidiI6OTMwLjB9LG51bGwseyJ2IjozOS4zNjl9
XX0seyJjIjpbeyJ2IjoxMDMyLjB9LG51bGwseyJ2IjozOS42NDl9XX0seyJjIjpbeyJ2IjoxMTMx
LjB9LG51bGwseyJ2IjozOS45MzF9XX0seyJjIjpbeyJ2IjoxMjM1LjB9LG51bGwseyJ2Ijo0MC4x
NjV9XX0seyJjIjpbeyJ2IjoxMzM4LjB9LG51bGwseyJ2Ijo0MC4zOTh9XX0seyJjIjpbeyJ2Ijox
NDM2LjB9LG51bGwseyJ2Ijo0MC41ODV9XX0seyJjIjpbeyJ2IjoxNTM4LjB9LG51bGwseyJ2Ijo0
MC43ODZ9XX0seyJjIjpbeyJ2Ijo2MDMuMH0seyJ2IjozNi41NzJ9LG51bGxdfSx7ImMiOlt7InYi
OjY5OS4wfSx7InYiOjM3LjE5NX0sbnVsbF19LHsiYyI6W3sidiI6NzkzLjB9LHsidiI6MzcuNzcx
fSxudWxsXX0seyJjIjpbeyJ2Ijo4ODcuMH0seyJ2IjozOC4yNzV9LG51bGxdfSx7ImMiOlt7InYi
Ojk4Ny4wfSx7InYiOjM4LjcyM30sbnVsbF19LHsiYyI6W3sidiI6MTA4OS4wfSx7InYiOjM5LjE0
NH0sbnVsbF19LHsiYyI6W3sidiI6MTE5MC4wfSx7InYiOjM5LjUxNX0sbnVsbF19LHsiYyI6W3si
diI6MTI5NC4wfSx7InYiOjM5Ljg1NH0sbnVsbF19XSwiY29scyI6W3sidHlwZSI6Im51bWJlciIs
ImlkIjoiZGF0YXJhdGUiLCJsYWJlbCI6IkRhdGFyYXRlIn0seyJ0eXBlIjoibnVtYmVyIiwiaWQi
OiJzdGF0cy9oMjY0IiwibGFiZWwiOiJzdGF0cy9oMjY0In0seyJ0eXBlIjoibnVtYmVyIiwiaWQi
OiJzdGF0cy92cDgiLCJsYWJlbCI6InN0YXRzL3ZwOCJ9XX0nLCd7InJvd3MiOlt7ImMiOlt7InYi
OjEwNS4wfSxudWxsLHsidiI6NDEuOTYyfV19LHsiYyI6W3sidiI6MjExLjB9LG51bGwseyJ2Ijo0
My45MDR9XX0seyJjIjpbeyJ2IjozMTAuMH0sbnVsbCx7InYiOjQ0LjQ0fV19LHsiYyI6W3sidiI6
NDA5LjB9LG51bGwseyJ2Ijo0NC44ODZ9XX0seyJjIjpbeyJ2Ijo1MDguMH0sbnVsbCx7InYiOjQ1
LjI3Mn1dfSx7ImMiOlt7InYiOjYwNy4wfSxudWxsLHsidiI6NDUuNjU0fV19LHsiYyI6W3sidiI6
NzA2LjB9LG51bGwseyJ2Ijo0Ni4wMDF9XX0seyJjIjpbeyJ2Ijo4MDYuMH0sbnVsbCx7InYiOjQ2
LjI2fV19LHsiYyI6W3sidiI6NTQuMH0seyJ2IjozNi44MDd9LG51bGxdfSx7ImMiOlt7InYiOjEx
Mi4wfSx7InYiOjQxLjI1Nn0sbnVsbF19LHsiYyI6W3sidiI6MjAwLjB9LHsidiI6NDMuNTd9LG51
bGxdfSx7ImMiOlt7InYiOjMyMS4wfSx7InYiOjQ0Ljk1MX0sbnVsbF19LHsiYyI6W3sidiI6NDU0
LjB9LHsidiI6NDUuODV9LG51bGxdfSx7ImMiOlt7InYiOjU3MC4wfSx7InYiOjQ2LjQxN30sbnVs
bF19LHsiYyI6W3sidiI6NjcyLjB9LHsidiI6NDYuODE5fSxudWxsXX0seyJjIjpbeyJ2Ijo3NzQu
MH0seyJ2Ijo0Ny4xNDd9LG51bGxdfV0sImNvbHMiOlt7InR5cGUiOiJudW1iZXIiLCJpZCI6ImRh
dGFyYXRlIiwibGFiZWwiOiJEYXRhcmF0ZSJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMv
aDI2NCIsImxhYmVsIjoic3RhdHMvaDI2NCJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMv
dnA4IiwibGFiZWwiOiJzdGF0cy92cDgifV19JywneyJyb3dzIjpbeyJjIjpbeyJ2IjoxNDYuMH0s
bnVsbCx7InYiOjM1Ljg3NX1dfSx7ImMiOlt7InYiOjIwNS4wfSxudWxsLHsidiI6MzcuMzY5fV19
LHsiYyI6W3sidiI6MzA1LjB9LG51bGwseyJ2IjozOC42Nn1dfSx7ImMiOlt7InYiOjQwNC4wfSxu
dWxsLHsidiI6MzkuNDA3fV19LHsiYyI6W3sidiI6NTA1LjB9LG51bGwseyJ2IjozOS45NjR9XX0s
eyJjIjpbeyJ2Ijo2MDYuMH0sbnVsbCx7InYiOjQwLjM4MX1dfSx7ImMiOlt7InYiOjcwNy4wfSxu
dWxsLHsidiI6NDAuNzJ9XX0seyJjIjpbeyJ2Ijo4MDcuMH0sbnVsbCx7InYiOjQwLjk5NH1dfSx7
ImMiOlt7InYiOjk5LjB9LHsidiI6MzEuNjU5fSxudWxsXX0seyJjIjpbeyJ2IjoxOTQuMH0seyJ2
IjozNS45MTl9LG51bGxdfSx7ImMiOlt7InYiOjI5Mi4wfSx7InYiOjM3LjkxM30sbnVsbF19LHsi
YyI6W3sidiI6MzkzLjB9LHsidiI6MzkuMDczfSxudWxsXX0seyJjIjpbeyJ2Ijo0OTUuMH0seyJ2
IjozOS44MzJ9LG51bGxdfSx7ImMiOlt7InYiOjU5NS4wfSx7InYiOjQwLjM3Mn0sbnVsbF19LHsi
YyI6W3sidiI6Njk2LjB9LHsidiI6NDAuNzk1fSxudWxsXX0seyJjIjpbeyJ2Ijo3OTYuMH0seyJ2
Ijo0MS4xMzN9LG51bGxdfV0sImNvbHMiOlt7InR5cGUiOiJudW1iZXIiLCJpZCI6ImRhdGFyYXRl
IiwibGFiZWwiOiJEYXRhcmF0ZSJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMvaDI2NCIs
ImxhYmVsIjoic3RhdHMvaDI2NCJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMvdnA4Iiwi
bGFiZWwiOiJzdGF0cy92cDgifV19JywneyJyb3dzIjpbeyJjIjpbeyJ2IjoxMDYuMH0sbnVsbCx7
InYiOjM3LjR9XX0seyJjIjpbeyJ2IjoyMDYuMH0sbnVsbCx7InYiOjM4LjYzN31dfSx7ImMiOlt7
InYiOjMwNi4wfSxudWxsLHsidiI6MzkuMjM4fV19LHsiYyI6W3sidiI6NDA2LjB9LG51bGwseyJ2
IjozOS43MDJ9XX0seyJjIjpbeyJ2Ijo1MDcuMH0sbnVsbCx7InYiOjQwLjAxM31dfSx7ImMiOlt7
InYiOjYwOC4wfSxudWxsLHsidiI6NDAuMzA4fV19LHsiYyI6W3sidiI6NzA5LjB9LG51bGwseyJ2
Ijo0MC41NDV9XX0seyJjIjpbeyJ2Ijo4MTAuMH0sbnVsbCx7InYiOjQwLjc1Mn1dfSx7ImMiOlt7
InYiOjY1LjB9LHsidiI6MzQuMzM4fSxudWxsXX0seyJjIjpbeyJ2IjoxMzMuMH0seyJ2IjozNy4y
Nn0sbnVsbF19LHsiYyI6W3sidiI6MjQ3LjB9LHsidiI6MzguODh9LG51bGxdfSx7ImMiOlt7InYi
OjM4MC4wfSx7InYiOjM5Ljc3OH0sbnVsbF19LHsiYyI6W3sidiI6NDkwLjB9LHsidiI6NDAuMzE4
fSxudWxsXX0seyJjIjpbeyJ2Ijo1OTUuMH0seyJ2Ijo0MC43MDV9LG51bGxdfSx7ImMiOlt7InYi
OjY5OC4wfSx7InYiOjQxLjAwM30sbnVsbF19LHsiYyI6W3sidiI6ODAxLjB9LHsidiI6NDEuMjZ9
LG51bGxdfV0sImNvbHMiOlt7InR5cGUiOiJudW1iZXIiLCJpZCI6ImRhdGFyYXRlIiwibGFiZWwi
OiJEYXRhcmF0ZSJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMvaDI2NCIsImxhYmVsIjoi
c3RhdHMvaDI2NCJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMvdnA4IiwibGFiZWwiOiJz
dGF0cy92cDgifV19JywneyJyb3dzIjpbeyJjIjpbeyJ2Ijo4MzQuMH0sbnVsbCx7InYiOjM4LjY3
MX1dfSx7ImMiOlt7InYiOjkzNi4wfSxudWxsLHsidiI6MzkuMDgyfV19LHsiYyI6W3sidiI6MTAz
OS4wfSxudWxsLHsidiI6MzkuMzU2fV19LHsiYyI6W3sidiI6MTEzOS4wfSxudWxsLHsidiI6Mzku
NjY5fV19LHsiYyI6W3sidiI6MTI0NS4wfSxudWxsLHsidiI6MzkuOTI5fV19LHsiYyI6W3sidiI6
MTM0MC4wfSxudWxsLHsidiI6NDAuMTI5fV19LHsiYyI6W3sidiI6MTQ0MS4wfSxudWxsLHsidiI6
NDAuMzM0fV19LHsiYyI6W3sidiI6MTU0MC4wfSxudWxsLHsidiI6NDAuNTE2fV19LHsiYyI6W3si
diI6NzA5LjB9LHsidiI6MzcuMjE2fSxudWxsXX0seyJjIjpbeyJ2Ijo4MDYuMH0seyJ2IjozNy44
MjN9LG51bGxdfSx7ImMiOlt7InYiOjkwNS4wfSx7InYiOjM4LjM1Nn0sbnVsbF19LHsiYyI6W3si
diI6MTAwNC4wfSx7InYiOjM4Ljc5OX0sbnVsbF19LHsiYyI6W3sidiI6MTEwNy4wfSx7InYiOjM5
LjE5OH0sbnVsbF19LHsiYyI6W3sidiI6MTIwOS4wfSx7InYiOjM5LjU0NH0sbnVsbF19LHsiYyI6
W3sidiI6MTMxMC4wfSx7InYiOjM5Ljg0MX0sbnVsbF19LHsiYyI6W3sidiI6MTQwOC4wfSx7InYi
OjQwLjA5Mn0sbnVsbF19XSwiY29scyI6W3sidHlwZSI6Im51bWJlciIsImlkIjoiZGF0YXJhdGUi
LCJsYWJlbCI6IkRhdGFyYXRlIn0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy9oMjY0Iiwi
bGFiZWwiOiJzdGF0cy9oMjY0In0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy92cDgiLCJs
YWJlbCI6InN0YXRzL3ZwOCJ9XX0nLCd7InJvd3MiOlt7ImMiOlt7InYiOjE2Ni4wfSxudWxsLHsi
diI6MzMuMzEzfV19LHsiYyI6W3sidiI6MjEzLjB9LG51bGwseyJ2IjozNC44MjF9XX0seyJjIjpb
eyJ2IjozMTQuMH0sbnVsbCx7InYiOjM2LjcxOX1dfSx7ImMiOlt7InYiOjQxNS4wfSxudWxsLHsi
diI6MzcuOTgxfV19LHsiYyI6W3sidiI6NTE3LjB9LG51bGwseyJ2IjozOC44NTh9XX0seyJjIjpb
eyJ2Ijo2MTcuMH0sbnVsbCx7InYiOjM5LjV9XX0seyJjIjpbeyJ2Ijo3MTcuMH0sbnVsbCx7InYi
OjQwLjA5OX1dfSx7ImMiOlt7InYiOjgyMC4wfSxudWxsLHsidiI6NDAuNjQyfV19LHsiYyI6W3si
diI6OTcuMH0seyJ2IjoyOS4zNDZ9LG51bGxdfSx7ImMiOlt7InYiOjE5MS4wfSx7InYiOjMzLjd9
LG51bGxdfSx7ImMiOlt7InYiOjI4Ny4wfSx7InYiOjM1Ljc3N30sbnVsbF19LHsiYyI6W3sidiI6
MzgzLjB9LHsidiI6MzcuMjQ3fSxudWxsXX0seyJjIjpbeyJ2Ijo0ODAuMH0seyJ2IjozOC4zNTV9
LG51bGxdfSx7ImMiOlt7InYiOjU3Ni4wfSx7InYiOjM5LjI1fSxudWxsXX0seyJjIjpbeyJ2Ijo2
NzMuMH0seyJ2IjozOS45Nzl9LG51bGxdfSx7ImMiOlt7InYiOjc2OS4wfSx7InYiOjQwLjU4OH0s
bnVsbF19XSwiY29scyI6W3sidHlwZSI6Im51bWJlciIsImlkIjoiZGF0YXJhdGUiLCJsYWJlbCI6
IkRhdGFyYXRlIn0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy9oMjY0IiwibGFiZWwiOiJz
dGF0cy9oMjY0In0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy92cDgiLCJsYWJlbCI6InN0
YXRzL3ZwOCJ9XX0nLCd7InJvd3MiOlt7ImMiOlt7InYiOjEwNi4wfSxudWxsLHsidiI6NDIuMzEx
fV19LHsiYyI6W3sidiI6MjA4LjB9LG51bGwseyJ2Ijo0My42Mjh9XX0seyJjIjpbeyJ2IjozMDku
MH0sbnVsbCx7InYiOjQ0LjA5N31dfSx7ImMiOlt7InYiOjQxMC4wfSxudWxsLHsidiI6NDQuNTJ9
XX0seyJjIjpbeyJ2Ijo1MTEuMH0sbnVsbCx7InYiOjQ0LjkyOH1dfSx7ImMiOlt7InYiOjYxMy4w
fSxudWxsLHsidiI6NDUuMzA0fV19LHsiYyI6W3sidiI6NzEzLjB9LG51bGwseyJ2Ijo0NS42NDV9
XX0seyJjIjpbeyJ2Ijo4MTMuMH0sbnVsbCx7InYiOjQ1Ljg3OX1dfSx7ImMiOlt7InYiOjUyLjB9
LHsidiI6MzcuMjE3fSxudWxsXX0seyJjIjpbeyJ2Ijo5OS4wfSx7InYiOjQxLjAxNX0sbnVsbF19
LHsiYyI6W3sidiI6MTc1LjB9LHsidiI6NDMuMDYzfSxudWxsXX0seyJjIjpbeyJ2IjozMDUuMH0s
eyJ2Ijo0NC40MDF9LG51bGxdfSx7ImMiOlt7InYiOjQ1Ni4wfSx7InYiOjQ1LjE4NH0sbnVsbF19
LHsiYyI6W3sidiI6NTY0LjB9LHsidiI6NDUuNjY2fSxudWxsXX0seyJjIjpbeyJ2Ijo2NjYuMH0s
eyJ2Ijo0Ni4wNX0sbnVsbF19LHsiYyI6W3sidiI6NzY5LjB9LHsidiI6NDYuMzYxfSxudWxsXX1d
LCJjb2xzIjpbeyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJkYXRhcmF0ZSIsImxhYmVsIjoiRGF0YXJh
dGUifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL2gyNjQiLCJsYWJlbCI6InN0YXRzL2gy
NjQifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL3ZwOCIsImxhYmVsIjoic3RhdHMvdnA4
In1dfScsJ3sicm93cyI6W3siYyI6W3sidiI6MTE0LjB9LG51bGwseyJ2IjozNi42MTl9XX0seyJj
IjpbeyJ2IjoyMTUuMH0sbnVsbCx7InYiOjM4Ljc4OH1dfSx7ImMiOlt7InYiOjMxMS4wfSxudWxs
LHsidiI6MzkuNzI5fV19LHsiYyI6W3sidiI6NDEwLjB9LG51bGwseyJ2Ijo0MC41NTN9XX0seyJj
IjpbeyJ2Ijo1MDkuMH0sbnVsbCx7InYiOjQxLjM0fV19LHsiYyI6W3sidiI6NjA5LjB9LG51bGws
eyJ2Ijo0MS45Njd9XX0seyJjIjpbeyJ2Ijo3MTQuMH0sbnVsbCx7InYiOjQyLjU3M31dfSx7ImMi
Olt7InYiOjgxNi4wfSxudWxsLHsidiI6NDIuOTU4fV19LHsiYyI6W3sidiI6OTEuMH0seyJ2Ijoz
My4xOTN9LG51bGxdfSx7ImMiOlt7InYiOjE3Ni4wfSx7InYiOjM3LjE4OH0sbnVsbF19LHsiYyI6
W3sidiI6MjczLjB9LHsidiI6MzkuNDA4fSxudWxsXX0seyJjIjpbeyJ2IjozODEuMH0seyJ2Ijo0
MC43Nzd9LG51bGxdfSx7ImMiOlt7InYiOjQ5Ny4wfSx7InYiOjQxLjc2Nn0sbnVsbF19LHsiYyI6
W3sidiI6NjAyLjB9LHsidiI6NDIuNDM0fSxudWxsXX0seyJjIjpbeyJ2Ijo3MDQuMH0seyJ2Ijo0
Mi45ODh9LG51bGxdfSx7ImMiOlt7InYiOjgwNi4wfSx7InYiOjQzLjQ0NH0sbnVsbF19XSwiY29s
cyI6W3sidHlwZSI6Im51bWJlciIsImlkIjoiZGF0YXJhdGUiLCJsYWJlbCI6IkRhdGFyYXRlIn0s
eyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy9oMjY0IiwibGFiZWwiOiJzdGF0cy9oMjY0In0s
eyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy92cDgiLCJsYWJlbCI6InN0YXRzL3ZwOCJ9XX0n
LCd7InJvd3MiOlt7ImMiOlt7InYiOjEzMC4wfSxudWxsLHsidiI6MzMuMDI0fV19LHsiYyI6W3si
diI6MjIyLjB9LG51bGwseyJ2IjozNi4yMjd9XX0seyJjIjpbeyJ2IjozMjUuMH0sbnVsbCx7InYi
OjM3LjMxMn1dfSx7ImMiOlt7InYiOjQyOC4wfSxudWxsLHsidiI6MzguMTQ0fV19LHsiYyI6W3si
diI6NTI4LjB9LG51bGwseyJ2IjozOS4xMjF9XX0seyJjIjpbeyJ2Ijo2MzIuMH0sbnVsbCx7InYi
OjM5LjU4OH1dfSx7ImMiOlt7InYiOjczNC4wfSxudWxsLHsidiI6NDAuMDczfV19LHsiYyI6W3si
diI6ODMzLjB9LG51bGwseyJ2Ijo0MC4zMjl9XX0seyJjIjpbeyJ2Ijo3Ny4wfSx7InYiOjI5LjM1
MX0sbnVsbF19LHsiYyI6W3sidiI6MTQ3LjB9LHsidiI6MzMuNDI5fSxudWxsXX0seyJjIjpbeyJ2
IjoyMzAuMH0seyJ2IjozNS45MTV9LG51bGxdfSx7ImMiOlt7InYiOjM0NC4wfSx7InYiOjM3Ljcx
Mn0sbnVsbF19LHsiYyI6W3sidiI6NDcyLjB9LHsidiI6MzguODkxfSxudWxsXX0seyJjIjpbeyJ2
Ijo1NzkuMH0seyJ2IjozOS43Nn0sbnVsbF19LHsiYyI6W3sidiI6Njc5LjB9LHsidiI6NDAuMzU5
fSxudWxsXX0seyJjIjpbeyJ2Ijo3ODQuMH0seyJ2Ijo0MC45MjJ9LG51bGxdfV0sImNvbHMiOlt7
InR5cGUiOiJudW1iZXIiLCJpZCI6ImRhdGFyYXRlIiwibGFiZWwiOiJEYXRhcmF0ZSJ9LHsidHlw
ZSI6Im51bWJlciIsImlkIjoic3RhdHMvaDI2NCIsImxhYmVsIjoic3RhdHMvaDI2NCJ9LHsidHlw
ZSI6Im51bWJlciIsImlkIjoic3RhdHMvdnA4IiwibGFiZWwiOiJzdGF0cy92cDgifV19JyxdDQoN
Cg0KdmFyIHNlbGVjdGVkID0gMA0KdmFyIGltYWdlc3RyID0gJyc7DQp2YXIgYmV0dGVydGFibGU9
MDsNCnZhciBjaGFydD0wOw0KdmFyIGJldHRlcj0wOw0KdmFyIG1ldHJpY2RhdGE9MDsNCnZhciBt
ZXRyaWN2aWV3PTA7DQp2YXIgY29sdW1uPTE7DQp2YXIgZm9ybWF0dGVyPTA7DQoNCmZ1bmN0aW9u
IGNoYW5nZUNvbHVtbihjb2wpIHsNCiAgY29sdW1uID0gY29sOw0KICBkcmF3X2ZpbGVzKCk7DQp9
DQoNCmZ1bmN0aW9uIGNoYW5nZU1ldHJpYyhtKSB7DQogIGZ0YWJsZT1tDQogIGRyYXdfZmlsZXMo
KQ0KfQ0KDQpmdW5jdGlvbiBzZXR1cF92aXMoKSB7DQogIGNoYXJ0ID0gbmV3IGdvb2dsZS52aXN1
YWxpemF0aW9uLlNjYXR0ZXJDaGFydCgNCiAgICAgIGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCJt
ZXRyaWNncmFwaCIpKTsNCg0KICBiZXR0ZXJ0YWJsZSA9IG5ldyBnb29nbGUudmlzdWFsaXphdGlv
bi5UYWJsZSgNCiAgICAgIGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCJiZXR0ZXJ0YWJsZSIpKTsN
Cg0KICBkcmF3X2ZpbGVzKCk7DQp9DQoNCmZ1bmN0aW9uIGRyYXdfZmlsZXMoKSB7DQogIHZhciBj
c3NDbGFzc05hbWVzID0gew0KICAgICAgJ2hlYWRlclJvdyc6ICdibHVlLWZvbnQgc21hbGwtZm9u
dCBib2xkLWZvbnQgc21hbGwtbWFyZ2luJywNCiAgICAgICd0YWJsZVJvdyc6ICdzbWFsbC1mb250
IHNtYWxsLW1hcmdpbicsDQogICAgICAnb2RkVGFibGVSb3cnOiAnbGlnaHQtZ3JheS1iYWNrZ3Jv
dW5kIHNtYWxsLWZvbnQgc21hbGwtbWFyZ2luJywNCiAgICAgICdzZWxlY3RlZFRhYmxlUm93Jzog
J29yYW5nZS1iYWNrZ3JvdW5kIHNtYWxsLWZvbnQnLA0KICAgICAgJ2hvdmVyVGFibGVSb3cnOiAn
c21hbGwtZm9udCBoZWFkZXItc3R5bGUnLA0KICAgICAgJ2hlYWRlckNlbGwnOiAnaGVhZGVyLXN0
eWxlIHNtYWxsLW1hcmdpbicsDQogICAgICAndGFibGVDZWxsJzogJ3NtYWxsLW1hcmdpbid9Ow0K
DQogIHZhciBvcHRpb25zID0geydhbGxvd0h0bWwnOiB0cnVlfTsNCiAgaWYgKGJldHRlciAhPSAw
KSBkZWxldGUgYmV0dGVyOw0KDQogIGNvbD1ldmFsKGZ0YWJsZSsnW2NvbHVtbl0nKQ0KICBiZXR0
ZXIgPSBuZXcgZ29vZ2xlLnZpc3VhbGl6YXRpb24uRGF0YVRhYmxlKGNvbCkNCg0KICAvLyBQeXRo
b24gVGVtcGxhdGUgY29kZSByZXBsYWNlcyB0aGUgZm9sbG93aW5nIGxpbmUgd2l0aCBhIGxpc3Qg
b2YNCiAgLy8gZm9ybWF0dGVycy4NCiAgaWYgKGZ0YWJsZSA9PSAnZmlsZXN0YWJsZV9kc25yJykN
CiAgICBmb3JtYXR0ZXIgPSBuZXcgZ29vZ2xlLnZpc3VhbGl6YXRpb24uTnVtYmVyRm9ybWF0KA0K
ICAgICAge2ZyYWN0aW9uRGlnaXRzOiA0LCBzdWZmaXg6IiBkYiJ9KTsNCiAgZWxzZQ0KICAgIGZv
cm1hdHRlciA9IG5ldyBnb29nbGUudmlzdWFsaXphdGlvbi5OdW1iZXJGb3JtYXQoDQogICAgICAg
e2ZyYWN0aW9uRGlnaXRzOiA0LCBzdWZmaXg6IiUifSk7DQoNCiAgICAgZm9ybWF0dGVyLmZvcm1h
dChiZXR0ZXIsIDEpOw0KDQogIGJldHRlcnRhYmxlLmRyYXcoYmV0dGVyLG9wdGlvbnMpOw0KICBn
b29nbGUudmlzdWFsaXphdGlvbi5ldmVudHMuYWRkTGlzdGVuZXIoYmV0dGVydGFibGUsICdzZWxl
Y3QnLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2VsZWN0QmV0
dGVySGFuZGxlcik7DQogIHF1ZXJ5X2ZpbGUoKQ0KfQ0KDQpmdW5jdGlvbiBxdWVyeV9maWxlKCkg
ew0KICBpbWFnZXN0ciA9IGJldHRlci5nZXRGb3JtYXR0ZWRWYWx1ZShzZWxlY3RlZCwgMCkNCiAg
dmFyIG1ldHJpY2pzb24gPSBldmFsKCcoJyArIHNucnNbY29sdW1uXVtzZWxlY3RlZF0gKyAnKScp
Ow0KICBtZXRyaWNkYXRhID0gbmV3IGdvb2dsZS52aXN1YWxpemF0aW9uLkRhdGFUYWJsZShtZXRy
aWNqc29uLCAwLjYpOw0KICBpZiggbWV0cmljdmlldyAhPSAwICkgZGVsZXRlIG1ldHJpY3ZpZXc7
DQogIG1ldHJpY3ZpZXcgPSBuZXcgZ29vZ2xlLnZpc3VhbGl6YXRpb24uRGF0YVZpZXcobWV0cmlj
ZGF0YSk7DQoNCiAgY2hhcnQuZHJhdyhtZXRyaWN2aWV3LCB7Y3VydmVUeXBlOidmdW5jdGlvbics
DQogICAgICBjaGFydEFyZWE6e2xlZnQ6Y2hhcnRfbGVmdCwgdG9wOmNoYXJ0X3RvcCwgd2lkdGg6
Y2hhcnRfd2lkdGgsDQogICAgICBoZWlnaHQ6Y2hhcnRfaGVpZ2h0LTkwfSwNCiAgICAgIGhBeGlz
Ont0aXRsZToiZGF0YXJhdGUgaW4ga2JwcyJ9LCB2QXhpczp7dGl0bGU6InF1YWxpdHkgaW4gZGVj
aWJlbHMifSwNCiAgICAgIGxlZ2VuZDp7cG9zaXRpb246ImluIn0sIHRpdGxlOmltYWdlc3RyLCBw
b2ludFNpemU6MiwgbGluZVdpZHRoOjEsDQogICAgICB3aWR0aDpjaGFydF93aWR0aCwgaGVpZ2h0
OmNoYXJ0X2hlaWdodC01MCB9KTsNCg0KICBnb29nbGUudmlzdWFsaXphdGlvbi5ldmVudHMuYWRk
TGlzdGVuZXIoY2hhcnQsICdzZWxlY3QnLCBjaGFydFNlbGVjdCk7DQogIGdvb2dsZS52aXN1YWxp
emF0aW9uLmV2ZW50cy5hZGRMaXN0ZW5lcihjaGFydCwgJ29ubW91c2VvdmVyJywgY2hhcnRNb3Vz
ZU92ZXIpOw0KICBnb29nbGUudmlzdWFsaXphdGlvbi5ldmVudHMuYWRkTGlzdGVuZXIoY2hhcnQs
ICdvbm1vdXNlb3V0JywgY2hhcnRNb3VzZU91dCk7DQp9DQoNCmZ1bmN0aW9uIGNoYXJ0TW91c2VP
dXQoZSkgew0KICBzdGF0dXNiYXIgPSBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgnc3RhdHVzJyk7
DQogIHN0YXR1c2Jhci5zdHlsZS5kaXNwbGF5ID0gJ25vbmUnOw0KfQ0KDQpmdW5jdGlvbiBjaGFy
dE1vdXNlT3ZlcihlKSB7DQogIHBvaW50RGlmZmVyZW5jZShlLnJvdywgZS5jb2x1bW4pDQp9DQoN
CmZ1bmN0aW9uIHBvaW50RGlmZmVyZW5jZShyb3csIGNvbCkgew0KICBpZighcm93IHx8ICFjb2wp
DQogICAgcmV0dXJuOw0KDQogIHZhciBjb2xzID0gbWV0cmljZGF0YS5nZXROdW1iZXJPZkNvbHVt
bnMoKTsNCiAgdmFyIHJvd3MgPSBtZXRyaWNkYXRhLmdldE51bWJlck9mUm93cygpOw0KDQogIHZh
ciBzZWxfYml0cmF0ZSA9IG1ldHJpY3ZpZXcuZ2V0VmFsdWUocm93LCAwICk7DQogIHZhciBzZWxf
bWV0cmljID0gbWV0cmljdmlldy5nZXRWYWx1ZShyb3csIGNvbCk7DQoNCiAgdmFyIG1lc3NhZ2Ug
PSAiQXQgIiArIHNlbF9tZXRyaWMudG9GaXhlZCgyKSArICIgZGVjaWJlbHMsIDxlbT4iDQogIG1l
c3NhZ2UgPSBtZXNzYWdlICsgbWV0cmljZGF0YS5nZXRDb2x1bW5MYWJlbChjb2wpICsgIjwvZW0+
IGlzIDx1bD4iDQoNCiAgLy8gY29sIDAgaXMgZGF0YXJhdGUNCiAgZm9yKCB2YXIgaT0xO2k8Y29s
czsrK2kpIHsNCg0KICAgIHZhciBtZXRyaWNfZ3JlYXRlc3RfdGhhdHNfbGVzcyA9IDA7DQogICAg
dmFyIHJhdGVfZ3JlYXRlc3RfdGhhdHNfbGVzcyA9IDA7DQogICAgdmFyIG1ldHJpY19zbWFsbGVz
dF90aGF0c19ncmVhdGVyID0gOTk5Ow0KICAgIHZhciByYXRlX3NtYWxsZXN0X3RoYXRzX2dyZWF0
ZXIgPSAwOw0KDQogICAgaWYoaT09Y29sKQ0KICAgICAgY29udGludWU7DQoNCiAgICAvLyBGaW5k
IHRoZSBsb3dlc3QgbWV0cmljIGZvciB0aGUgY29sdW1uIHRoYXQncyBncmVhdGVyIHRoYW4gc2Vs
X21ldHJpYyBhbmQNCiAgICAvLyB0aGUgaGlnaGVzdCBtZXRyaWMgZm9yIHRoaXMgY29sdW1uIHRo
YXQncyBsZXNzIHRoYW4gdGhlIG1ldHJpYy4NCiAgICBmb3IodmFyIGxpbmVfY291bnQgPSAwOyBs
aW5lX2NvdW50IDwgcm93czsgKytsaW5lX2NvdW50KSB7DQogICAgICB0aGlzX21ldHJpYyA9IG1l
dHJpY2RhdGEuZ2V0VmFsdWUobGluZV9jb3VudCwgaSkNCiAgICAgIHRoaXNfcmF0ZSA9IG1ldHJp
Y2RhdGEuZ2V0VmFsdWUobGluZV9jb3VudCwgMCkNCiAgICAgIGlmKCF0aGlzX21ldHJpYykNCiAg
ICAgICAgY29udGludWU7DQoNCiAgICAgIGlmKHRoaXNfbWV0cmljID4gbWV0cmljX2dyZWF0ZXN0
X3RoYXRzX2xlc3MgJiYNCiAgICAgICAgIHRoaXNfbWV0cmljIDwgc2VsX21ldHJpYykgew0KICAg
ICAgICBtZXRyaWNfZ3JlYXRlc3RfdGhhdHNfbGVzcyA9IHRoaXNfbWV0cmljOw0KICAgICAgICBy
YXRlX2dyZWF0ZXN0X3RoYXRzX2xlc3MgPSB0aGlzX3JhdGU7DQogICAgICB9DQogICAgICBpZih0
aGlzX21ldHJpYyA8IG1ldHJpY19zbWFsbGVzdF90aGF0c19ncmVhdGVyICYmDQogICAgICAgIHRo
aXNfbWV0cmljID4gc2VsX21ldHJpYykgew0KICAgICAgICBtZXRyaWNfc21hbGxlc3RfdGhhdHNf
Z3JlYXRlciA9IHRoaXNfbWV0cmljOw0KICAgICAgICByYXRlX3NtYWxsZXN0X3RoYXRzX2dyZWF0
ZXIgPSB0aGlzX3JhdGU7DQogICAgICB9DQogICAgfQ0KDQogICAgaWYocmF0ZV9zbWFsbGVzdF90
aGF0c19ncmVhdGVyID09IDAgfHwgcmF0ZV9ncmVhdGVzdF90aGF0c19sZXNzID09IDApIHsNCiAg
ICAgIG1lc3NhZ2UgPSBtZXNzYWdlICsgIiA8bGk+IENvdWxkbid0IGZpbmQgYSBwb2ludCBvbiBi
b3RoIHNpZGVzLjwvbGk+Ig0KICAgIH0gZWxzZSB7DQogICAgICBtZXRyaWNfc2xvcGUgPSAoIHJh
dGVfc21hbGxlc3RfdGhhdHNfZ3JlYXRlciAtIHJhdGVfZ3JlYXRlc3RfdGhhdHNfbGVzcykgLw0K
ICAgICAgICAgICggbWV0cmljX3NtYWxsZXN0X3RoYXRzX2dyZWF0ZXIgLSBtZXRyaWNfZ3JlYXRl
c3RfdGhhdHNfbGVzcyk7DQoNCiAgICAgIHByb2plY3RlZF9yYXRlID0gKCBzZWxfbWV0cmljIC0g
bWV0cmljX2dyZWF0ZXN0X3RoYXRzX2xlc3MpICoNCiAgICAgICAgICBtZXRyaWNfc2xvcGUgKyBy
YXRlX2dyZWF0ZXN0X3RoYXRzX2xlc3M7DQoNCiAgICAgIGRpZmZlcmVuY2UgPSAxMDAgKiAocHJv
amVjdGVkX3JhdGUgLyBzZWxfYml0cmF0ZSAtIDEpOw0KDQoNCiAgICAgIGlmIChkaWZmZXJlbmNl
ID4gMCkNCiAgICAgICAgbWVzc2FnZSA9IG1lc3NhZ2UgKyAiPGxpPiAgIiArIGRpZmZlcmVuY2Uu
dG9GaXhlZCgyKSArDQogICAgICAgICAgICAgICAgICAiJSBzbWFsbGVyIHRoYW4gPGVtPiIgKw0K
ICAgICAgICAgICAgICAgICAgbWV0cmljZGF0YS5nZXRDb2x1bW5MYWJlbChpKSArICI8L2VtPjwv
bGk+ICINCiAgICAgIGVsc2UNCiAgICAgICAgbWVzc2FnZSA9IG1lc3NhZ2UgKyAiPGxpPiAgIiAr
IC1kaWZmZXJlbmNlLnRvRml4ZWQoMikgKw0KICAgICAgICAgICAgICAgICAgIiUgYmlnZ2VyIHRo
YW4gPGVtPiIgKw0KICAgICAgICAgICAgICAgICAgbWV0cmljZGF0YS5nZXRDb2x1bW5MYWJlbChp
KSArICI8L2VtPjwvbGk+ICINCiAgICB9DQoNCiAgfQ0KICBtZXNzYWdlID0gbWVzc2FnZSArICI8
L3VsPiINCiAgc3RhdHVzYmFyID0gZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoJ3N0YXR1cycpOw0K
ICBzdGF0dXNiYXIuaW5uZXJIVE1MID0gIjxwPiIgKyBtZXNzYWdlICsgIjwvcD4iOw0KICBzdGF0
dXNiYXIuc3R5bGUuZGlzcGxheSA9ICdibG9jayc7DQp9DQoNCmZ1bmN0aW9uIGNoYXJ0U2VsZWN0
KCkgew0KICB2YXIgc2VsZWN0aW9uID0gY2hhcnQuZ2V0U2VsZWN0aW9uKCk7DQogIHZhciBtZXNz
YWdlID0gJyc7DQogIHZhciBtaW4gPSBtZXRyaWN2aWV3LmdldEZvcm1hdHRlZFZhbHVlKHNlbGVj
dGlvblswXS5yb3csIDApOw0KICB2YXIgbWF4ID0gbWV0cmljdmlldy5nZXRGb3JtYXR0ZWRWYWx1
ZShzZWxlY3Rpb25bc2VsZWN0aW9uLmxlbmd0aC0xXS5yb3csIDApOw0KICB2YXIgdmFsID0gbWV0
cmljdmlldy5nZXRGb3JtYXR0ZWRWYWx1ZShzZWxlY3Rpb25bMF0ucm93LHNlbGVjdGlvblswXS5j
b2x1bW4pOw0KDQogIHBvaW50RGlmZmVyZW5jZShzZWxlY3Rpb25bMF0ucm93LCBzZWxlY3Rpb25b
MF0uY29sdW1uKQ0KICBtaW4gPSBtaW4gLyAzDQogIG1heCA9IG1heCAqIDMNCiAgbWV0cmljdmll
dy5zZXRSb3dzKG1ldHJpY2RhdGEuZ2V0RmlsdGVyZWRSb3dzKA0KICAgICAgW3tjb2x1bW46IDAs
bWluVmFsdWU6IG1pbiwgbWF4VmFsdWU6bWF4fV0pKTsNCg0KICBjaGFydC5kcmF3KG1ldHJpY3Zp
ZXcsIHtjdXJ2ZVR5cGU6J2Z1bmN0aW9uJywNCiAgICAgIGNoYXJ0QXJlYTp7bGVmdDo0MCwgdG9w
OjEwLCB3aWR0aDpjaGFydF93aWR0aCwgaGVpZ2h0OmNoYXJ0X2hlaWdodCAtIDExMH0sDQogICAg
ICBoQXhpczp7dGl0bGU6ImRhdGFyYXRlIGluIGticHMifSwgdkF4aXM6e3RpdGxlOiJxdWFsaXR5
IGluIGRlY2liZWxzIn0sDQogICAgICBsZWdlbmQ6e3Bvc2l0aW9uOiJpbiJ9LCB0aXRsZTppbWFn
ZXN0ciwgcG9pbnRTaXplOjIsIGxpbmVXaWR0aDoxLA0KICAgICAgd2lkdGg6Y2hhcnRfd2lkdGgs
IGhlaWdodDpjaGFydF9oZWlnaHQgLSA1MH0pOw0KfQ0KDQpmdW5jdGlvbiBzZWxlY3RCZXR0ZXJI
YW5kbGVyKCkgew0KICB2YXIgc2VsZWN0aW9uID0gYmV0dGVydGFibGUuZ2V0U2VsZWN0aW9uKCk7
DQogIGZvciAodmFyIGkgPSAwOyBpIDwgc2VsZWN0aW9uLmxlbmd0aDsgaSsrKSB7DQogICAgaXRl
bSA9IHNlbGVjdGlvbltpXTsNCiAgfQ0KICBzZWxlY3RlZCA9IGl0ZW0ucm93DQogIHF1ZXJ5X2Zp
bGUoKQ0KfQ0KDQpnb29nbGUubG9hZCgndmlzdWFsaXphdGlvbicsICcxJywgeydwYWNrYWdlcycg
OiBbJ2NvcmVjaGFydCcsJ3RhYmxlJ119KTsNCmdvb2dsZS5zZXRPbkxvYWRDYWxsYmFjayhzZXR1
cF92aXMpOw0KPC9zY3JpcHQ+DQo8L2hlYWQ+DQoNCjxib2R5Pg0KDQogIDxkaXYgY2xhc3M9ImNv
bnRhaW5lcl8xMiI+DQoNCiAgICA8ZGl2IGNsYXNzPSJncmlkXzEyIGhlYWRlciI+DQogICAgICA8
aDI+VlA4IFJlc3VsdHM8L2gyPg0KICAgIDwvZGl2Pg0KDQogICAgPGRpdiBjbGFzcz0iZ3JpZF8x
MiByYWRpbyI+DQoNCiAgICA8ZGl2IGNsYXNzPSJncmlkXzEyIG1haW4iPg0KDQogICAgICA8ZGl2
IGNsYXNzPSJncmlkXzUgYWxwaGEgY2xpcGxpc3QiPg0KICAgICAgICA8ZGl2IGlkPSJiZXR0ZXJ0
YWJsZSI+PC9kaXY+DQogICAgICA8L2Rpdj4NCg0KICAgICAgPGRpdiBjbGFzcz0iZ3JpZF81IGNo
YXJ0YXJlYSI+DQogICAgICAgIDxkaXYgaWQ9Im1ldHJpY2dyYXBoIj48L2Rpdj4NCiAgICAgIDwv
ZGl2Pg0KDQogICAgICA8ZGl2IGNsYXNzPSJncmlkXzIgb21lZ2EgaW5kaWNhdG9ycyI+DQogICAg
ICAgIDxkaXYgY2xhc3M9ImNvbnRlbnQiPg0KICAgICAgICAgIDxoNT5JbmRpY2F0b3JzPC9oNT4N
CiAgICAgICAgICA8aHI+DQogICAgICAgICAgPGRpdiBpZD0ic3RhdHVzIj48L2Rpdj4NCiAgICAg
ICAgPC9kaXY+DQogICAgICA8L2Rpdj4NCg0KICAgIDwvZGl2Pg0KDQogIDwvZGl2Pg0KDQo8L2Jv
ZHk+DQo8L2h0bWw+DQoNCg==

--_005_BBE9739C2C302046BD34B42713A1E2A22DE32C48ESESSMB105erics_
Content-Type: text/html; name="vp8_vs_h264_quality_verification.html"
Content-Description: vp8_vs_h264_quality_verification.html
Content-Disposition: attachment;
	filename="vp8_vs_h264_quality_verification.html"; size=25082;
	creation-date="Fri, 15 Mar 2013 16:08:28 GMT";
	modification-date="Fri, 15 Mar 2013 16:08:28 GMT"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIGh0bWw+DQo8aHRtbCBsYW5nPSJlbiI+DQo8aGVhZD4NCjxtZXRhIGNoYXJzZXQ9
InV0Zi04Ij4NCjx0aXRsZT5Db21wYXJhdGl2ZSBSZXN1bHRzPC90aXRsZT4NCjxzdHlsZSB0eXBl
PSJ0ZXh0L2NzcyI+DQo8IS0tIEJlZ2luIDk2MCByZXNldCAtLT4NCmEsYWJicixhY3JvbnltLGFk
ZHJlc3MsYXBwbGV0LGFydGljbGUsYXNpZGUsYXVkaW8sYixiaWcsYmxvY2txdW90ZSxib2R5LGNh
bnZhcyxjYXB0aW9uLGNlbnRlcixjaXRlLGMNCm9kZSxkZCxkZWwsZGV0YWlscyxkZm4sZGlhbG9n
LGRpdixkbCxkdCxlbSxlbWJlZCxmaWVsZHNldCxmaWdjYXB0aW9uLGZpZ3VyZSxmb250LGZvb3Rl
cixmb3JtLGgxLGgyLGgNCjMsaDQsaDUsaDYsaGVhZGVyLGhncm91cCxocixodG1sLGksaWZyYW1l
LGltZyxpbnMsa2JkLGxhYmVsLGxlZ2VuZCxsaSxtYXJrLG1lbnUsbWV0ZXIsbmF2LG9iamVjdCxv
bCwNCm91dHB1dCxwLHByZSxwcm9ncmVzcyxxLHJwLHJ0LHJ1YnkscyxzYW1wLHNlY3Rpb24sc21h
bGwsc3BhbixzdHJpa2Usc3Ryb25nLHN1YixzdW1tYXJ5LHN1cCx0YWJsZSx0Ym8NCmR5LHRkLHRm
b290LHRoLHRoZWFkLHRpbWUsdHIsdHQsdSx1bCx2YXIsdmlkZW8seG1we2JvcmRlcjowO21hcmdp
bjowO3BhZGRpbmc6MDtmb250LXNpemU6MTAwJX1odG1sLGINCm9keXtoZWlnaHQ6MTAwJX1hcnRp
Y2xlLGFzaWRlLGRldGFpbHMsZmlnY2FwdGlvbixmaWd1cmUsZm9vdGVyLGhlYWRlcixoZ3JvdXAs
bWVudSxuYXYsc2VjdGlvbntkaXNwbGENCnk6YmxvY2t9YixzdHJvbmd7Zm9udC13ZWlnaHQ6Ym9s
ZH1pbWd7Y29sb3I6dHJhbnNwYXJlbnQ7Zm9udC1zaXplOjA7dmVydGljYWwtYWxpZ246bWlkZGxl
Oy1tcy1pbnRlcnANCm9sYXRpb24tbW9kZTpiaWN1YmljfW9sLHVse2xpc3Qtc3R5bGU6bm9uZX1s
aXtkaXNwbGF5Omxpc3QtaXRlbX10YWJsZXtib3JkZXItY29sbGFwc2U6Y29sbGFwc2U7Ym9yZGUN
CnItc3BhY2luZzowfXRoLHRkLGNhcHRpb257Zm9udC13ZWlnaHQ6bm9ybWFsO3ZlcnRpY2FsLWFs
aWduOnRvcDt0ZXh0LWFsaWduOmxlZnR9cXtxdW90ZXM6bm9uZX1xOmJlZm8NCnJlLHE6YWZ0ZXJ7
Y29udGVudDonJztjb250ZW50Om5vbmV9c3ViLHN1cCxzbWFsbHtmb250LXNpemU6NzUlfXN1Yixz
dXB7bGluZS1oZWlnaHQ6MDtwb3NpdGlvbjpyZWxhdGkNCnZlO3ZlcnRpY2FsLWFsaWduOmJhc2Vs
aW5lfXN1Yntib3R0b206LTAuMjVlbX1zdXB7dG9wOi0wLjVlbX1zdmd7b3ZlcmZsb3c6aGlkZGVu
fQ0KPCEtLSBFbmQgOTYwIHJlc2V0IC0tPg0KPCEtLSBCZWdpbiA5NjAgdGV4dCAtLT4NCmJvZHl7
Zm9udDoxM3B4LzEuNSAnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLCdMaWJlcmF0aW9uIFNhbnMnLEZy
ZWVTYW5zLHNhbnMtc2VyaWZ9cHJlLGNvZGV7Zm9udC1mYW1pbHkNCjonRGVqYVZ1IFNhbnMgTW9u
bycsTWVubG8sQ29uc29sYXMsbW9ub3NwYWNlfWhye2JvcmRlcjowICNjY2Mgc29saWQ7Ym9yZGVy
LXRvcC13aWR0aDoxcHg7Y2xlYXI6Ym90aDsNCmhlaWdodDowfWgxe2ZvbnQtc2l6ZToyNXB4fWgy
e2ZvbnQtc2l6ZToyM3B4fWgze2ZvbnQtc2l6ZToyMXB4fWg0e2ZvbnQtc2l6ZToxOXB4fWg1e2Zv
bnQtc2l6ZToxN3B4fWgNCjZ7Zm9udC1zaXplOjE1cHh9b2x7bGlzdC1zdHlsZTpkZWNpbWFsfXVs
e2xpc3Qtc3R5bGU6ZGlzY31saXttYXJnaW4tbGVmdDozMHB4fXAsZGwsaHIsaDEsaDIsaDMsaDQs
aDUNCixoNixvbCx1bCxwcmUsdGFibGUsYWRkcmVzcyxmaWVsZHNldCxmaWd1cmV7bWFyZ2luLWJv
dHRvbToyMHB4fQ0KPCEtLSBFbmQgOTYwIHRleHQgLS0+DQo8IS0tIEJlZ2luIDk2MCBncmlkIChm
bHVpZCB2YXJpYW50KQ0KICAgICAxMiBjb2x1bW5zLCAxMTUycHggdG90YWwgd2lkdGgNCiAgICAg
aHR0cDovLzk2MC5ncy8gfCBodHRwOi8vZ3JpZHMuaGVyb2t1LmNvbS8gLS0+DQouY29udGFpbmVy
XzEye3dpZHRoOjkyJTttYXJnaW4tbGVmdDo0JTttYXJnaW4tcmlnaHQ6NCV9LmdyaWRfMSwuZ3Jp
ZF8yLC5ncmlkXzMsLmdyaWRfNCwuZ3JpZF81LC5ncmlkDQpfNiwuZ3JpZF83LC5ncmlkXzgsLmdy
aWRfOSwuZ3JpZF8xMCwuZ3JpZF8xMSwuZ3JpZF8xMntkaXNwbGF5OmlubGluZTtmbG9hdDpsZWZ0
O3Bvc2l0aW9uOnJlbGF0aXZlO21hDQpyZ2luLWxlZnQ6MSU7bWFyZ2luLXJpZ2h0OjElfS5hbHBo
YXttYXJnaW4tbGVmdDowfS5vbWVnYXttYXJnaW4tcmlnaHQ6MH0uY29udGFpbmVyXzEyIC5ncmlk
XzF7d2lkdGg6DQo2LjMzMyV9LmNvbnRhaW5lcl8xMiAuZ3JpZF8ye3dpZHRoOjE0LjY2NyV9LmNv
bnRhaW5lcl8xMiAuZ3JpZF8ze3dpZHRoOjIzLjAlfS5jb250YWluZXJfMTIgLmdyaWRfNHt3DQpp
ZHRoOjMxLjMzMyV9LmNvbnRhaW5lcl8xMiAuZ3JpZF81e3dpZHRoOjM5LjY2NyV9LmNvbnRhaW5l
cl8xMiAuZ3JpZF82e3dpZHRoOjQ4LjAlfS5jb250YWluZXJfMTIgLmdyDQppZF83e3dpZHRoOjU2
LjMzMyV9LmNvbnRhaW5lcl8xMiAuZ3JpZF84e3dpZHRoOjY0LjY2NyV9LmNvbnRhaW5lcl8xMiAu
Z3JpZF85e3dpZHRoOjczLjAlfS5jb250YWluZXJfDQoxMiAuZ3JpZF8xMHt3aWR0aDo4MS4zMzMl
fS5jb250YWluZXJfMTIgLmdyaWRfMTF7d2lkdGg6ODkuNjY3JX0uY29udGFpbmVyXzEyIC5ncmlk
XzEye3dpZHRoOjk4LjAlfS5jDQpvbnRhaW5lcl8xMiAucHJlZml4XzF7cGFkZGluZy1sZWZ0Ojgu
MzMzJX0uY29udGFpbmVyXzEyIC5wcmVmaXhfMntwYWRkaW5nLWxlZnQ6MTYuNjY3JX0uY29udGFp
bmVyXzEyDQogLnByZWZpeF8ze3BhZGRpbmctbGVmdDoyNS4wJX0uY29udGFpbmVyXzEyIC5wcmVm
aXhfNHtwYWRkaW5nLWxlZnQ6MzMuMzMzJX0uY29udGFpbmVyXzEyIC5wcmVmaXhfNXtwDQphZGRp
bmctbGVmdDo0MS42NjclfS5jb250YWluZXJfMTIgLnByZWZpeF82e3BhZGRpbmctbGVmdDo1MC4w
JX0uY29udGFpbmVyXzEyIC5wcmVmaXhfN3twYWRkaW5nLWxlZnQ6DQo1OC4zMzMlfS5jb250YWlu
ZXJfMTIgLnByZWZpeF84e3BhZGRpbmctbGVmdDo2Ni42NjclfS5jb250YWluZXJfMTIgLnByZWZp
eF85e3BhZGRpbmctbGVmdDo3NS4wJX0uY29uDQp0YWluZXJfMTIgLnByZWZpeF8xMHtwYWRkaW5n
LWxlZnQ6ODMuMzMzJX0uY29udGFpbmVyXzEyIC5wcmVmaXhfMTF7cGFkZGluZy1sZWZ0OjkxLjY2
NyV9LmNvbnRhaW5lcl8xDQoyIC5zdWZmaXhfMXtwYWRkaW5nLXJpZ2h0OjguMzMzJX0uY29udGFp
bmVyXzEyIC5zdWZmaXhfMntwYWRkaW5nLXJpZ2h0OjE2LjY2NyV9LmNvbnRhaW5lcl8xMiAuc3Vm
Zml4DQpfM3twYWRkaW5nLXJpZ2h0OjI1LjAlfS5jb250YWluZXJfMTIgLnN1ZmZpeF80e3BhZGRp
bmctcmlnaHQ6MzMuMzMzJX0uY29udGFpbmVyXzEyIC5zdWZmaXhfNXtwYWRkaW5nDQotcmlnaHQ6
NDEuNjY3JX0uY29udGFpbmVyXzEyIC5zdWZmaXhfNntwYWRkaW5nLXJpZ2h0OjUwLjAlfS5jb250
YWluZXJfMTIgLnN1ZmZpeF83e3BhZGRpbmctcmlnaHQ6NTguDQozMzMlfS5jb250YWluZXJfMTIg
LnN1ZmZpeF84e3BhZGRpbmctcmlnaHQ6NjYuNjY3JX0uY29udGFpbmVyXzEyIC5zdWZmaXhfOXtw
YWRkaW5nLXJpZ2h0Ojc1LjAlfS5jb250DQphaW5lcl8xMiAuc3VmZml4XzEwe3BhZGRpbmctcmln
aHQ6ODMuMzMzJX0uY29udGFpbmVyXzEyIC5zdWZmaXhfMTF7cGFkZGluZy1yaWdodDo5MS42Njcl
fS5jb250YWluZXJfDQoxMiAucHVzaF8xe2xlZnQ6OC4zMzMlfS5jb250YWluZXJfMTIgLnB1c2hf
MntsZWZ0OjE2LjY2NyV9LmNvbnRhaW5lcl8xMiAucHVzaF8ze2xlZnQ6MjUuMCV9LmNvbnRhaW5l
DQpyXzEyIC5wdXNoXzR7bGVmdDozMy4zMzMlfS5jb250YWluZXJfMTIgLnB1c2hfNXtsZWZ0OjQx
LjY2NyV9LmNvbnRhaW5lcl8xMiAucHVzaF82e2xlZnQ6NTAuMCV9LmNvbnRhDQppbmVyXzEyIC5w
dXNoXzd7bGVmdDo1OC4zMzMlfS5jb250YWluZXJfMTIgLnB1c2hfOHtsZWZ0OjY2LjY2NyV9LmNv
bnRhaW5lcl8xMiAucHVzaF85e2xlZnQ6NzUuMCV9LmNvDQpudGFpbmVyXzEyIC5wdXNoXzEwe2xl
ZnQ6ODMuMzMzJX0uY29udGFpbmVyXzEyIC5wdXNoXzExe2xlZnQ6OTEuNjY3JX0uY29udGFpbmVy
XzEyIC5wdWxsXzF7bGVmdDotOC4zDQozMyV9LmNvbnRhaW5lcl8xMiAucHVsbF8ye2xlZnQ6LTE2
LjY2NyV9LmNvbnRhaW5lcl8xMiAucHVsbF8ze2xlZnQ6LTI1LjAlfS5jb250YWluZXJfMTIgLnB1
bGxfNHtsZWZ0DQo6LTMzLjMzMyV9LmNvbnRhaW5lcl8xMiAucHVsbF81e2xlZnQ6LTQxLjY2NyV9
LmNvbnRhaW5lcl8xMiAucHVsbF82e2xlZnQ6LTUwLjAlfS5jb250YWluZXJfMTIgLnB1bGxfDQo3
e2xlZnQ6LTU4LjMzMyV9LmNvbnRhaW5lcl8xMiAucHVsbF84e2xlZnQ6LTY2LjY2NyV9LmNvbnRh
aW5lcl8xMiAucHVsbF85e2xlZnQ6LTc1LjAlfS5jb250YWluZXJfMTINCi5wdWxsXzEwe2xlZnQ6
LTgzLjMzMyV9LmNvbnRhaW5lcl8xMiAucHVsbF8xMXtsZWZ0Oi05MS42NjclfS5jbGVhcntjbGVh
cjpib3RoO2Rpc3BsYXk6YmxvY2s7b3ZlcmZsb3cNCjpoaWRkZW47dmlzaWJpbGl0eTpoaWRkZW47
d2lkdGg6MDtoZWlnaHQ6MH0uY2xlYXJmaXg6YWZ0ZXJ7Y2xlYXI6Ym90aDtjb250ZW50OicgJztk
aXNwbGF5OmJsb2NrO2ZvbnQNCi1zaXplOjA7bGluZS1oZWlnaHQ6MDt2aXNpYmlsaXR5OmhpZGRl
bjt3aWR0aDowO2hlaWdodDowfS5jbGVhcmZpeHtkaXNwbGF5OmlubGluZS1ibG9ja30qIGh0bWwg
LmNsZWENCnJmaXh7aGVpZ2h0OjElfS5jbGVhcmZpeHtkaXNwbGF5OmJsb2NrfQ0KPCEtLSBFbmQg
OTYwIGdyaWQgLS0+DQoNCmRpdi5tZXRyaWNncmFwaCB7DQoNCn0NCg0KYm9keSB7DQoNCn0NCg0K
ZGl2LmhlYWRlciB7DQogIGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsNCn0NCg0KZGl2
LmhlYWRlciBoMiB7DQogIG1hcmdpbjogLjVlbSBhdXRvOw0KfQ0KDQpkaXYucmFkaW8gew0KICBm
b250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7DQogIG1hcmdpbi1ib3R0b206IDFlbTsNCn0N
Cg0KZGl2Lm1haW4gew0KDQp9DQoNCmRpdi5jbGlwbGlzdCB7DQogIGZvbnQtZmFtaWx5OiBBcmlh
bCwgc2Fucy1zZXJpZjsNCiAgbWFyZ2luLXRvcDogNnB4Ow0KfQ0KDQpkaXYuY2hhcnRhcmVhIHsN
CiAgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOw0KfQ0KDQpkaXYuaW5kaWNhdG9ycyB7
DQogIGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsNCiAgZm9udC1zaXplOiAxM3B4Ow0K
ICBtYXJnaW4tdG9wOiA2cHg7DQogIG1pbi1oZWlnaHQ6IDYwMHB4Ow0KICBiYWNrZ3JvdW5kLWNv
bG9yOiAjZjdmN2Y3Ow0KfQ0KDQpkaXYuaW5kaWNhdG9ycyBkaXYuY29udGVudCB7DQogIG1hcmdp
bjogMWVtOw0KfQ0KDQpkaXYuaW5kaWNhdG9ycyBkaXYuY29udGVudCBoNSB7DQogIGZvbnQtc2l6
ZTogMTNweDsNCiAgdGV4dC1hbGlnbjogY2VudGVyOw0KICBtYXJnaW46IDA7DQp9DQoNCmRpdi5p
bmRpY2F0b3JzIGRpdi5jb250ZW50IHVsIHsNCiAgbWFyZ2luLWxlZnQ6IDA7DQogIHBhZGRpbmct
bGVmdDogMDsNCiAgbWFyZ2luLXRvcDogMDsNCn0NCg0KZGl2LmluZGljYXRvcnMgZGl2LmNvbnRl
bnQgdWwgbGkgew0KICBtYXJnaW4tbGVmdDogMS41ZW07DQp9DQoNCmRpdi5pbmRpY2F0b3JzIGRp
di5jb250ZW50IHA6Zmlyc3QtY2hpbGQgew0KICBtYXJnaW4tYm90dG9tOiAuNWVtOw0KfQ0KDQpz
cGFuLmdvb2dsZS12aXN1YWxpemF0aW9uLXRhYmxlLXNvcnRpbmQgew0KICBjb2xvcjogIzAwMDsN
Cn0NCg0KLmhlYWRlci1zdHlsZSB7DQogIGZvbnQtd2VpZ2h0OiBib2xkOw0KICBib3JkZXI6IDFw
eCBzb2xpZCAjZmZmOw0KICBiYWNrZ3JvdW5kLWNvbG9yOiAjY2NjOw0KfQ0KDQp0ZC5oZWFkZXIt
c3R5bGUrdGQgew0KDQp9DQoNCi5vcmFuZ2UtYmFja2dyb3VuZCB7DQogIGJhY2tncm91bmQtY29s
b3I6IG9yYW5nZTsNCn0NCg0KLmxpZ2h0LWdyYXktYmFja2dyb3VuZCB7DQogIGJhY2tncm91bmQt
Y29sb3I6ICNmMGYwZjA7DQp9DQo8L3N0eWxlPg0KPHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3Jp
cHQiIHNyYz0iaHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS9qc2FwaSI+PC9zY3JpcHQ+DQo8c2NyaXB0
IHR5cGU9InRleHQvamF2YXNjcmlwdCI+DQpnb29nbGUubG9hZCgndmlzdWFsaXphdGlvbicsICcx
LjEnLCB7J3BhY2thZ2VzJzpbJ3RhYmxlJ119KTsNCnZhciBjaGFydF9sZWZ0ICAgPSA2MDsNCnZh
ciBjaGFydF90b3AgICAgPSA2Ow0KdmFyIGNoYXJ0X2hlaWdodCA9IGRvY3VtZW50LmRvY3VtZW50
RWxlbWVudC5jbGllbnRIZWlnaHQtMTAwOw0KdmFyIGNoYXJ0X3dpZHRoICA9ICIxMDAlIjsNCmZ0
YWJsZT0nZmlsZXN0YWJsZV9hdmcnDQp2YXIgc25ycyA9IFtdOw0KdmFyIGZpbGVzdGFibGVfZHNu
ciA9IFtdOw0KdmFyIGZpbGVzdGFibGVfZHJhdGUgPSBbXTsNCnZhciBmaWxlc3RhYmxlX2F2ZyA9
IFtdOw0KDQovLyBQeXRob24gdGVtcGxhdGUgY29kZSByZXBsYWNlcyB0aGUgZm9sbG93aW5nIDIg
bGluZXMuDQpmaWxlc3RhYmxlX2RzbnJbMV09eyJyb3dzIjpbeyJjIjpbeyJ2IjoiZGVza3RvcF82
NDBfMzYwXzMwIn0seyJ2IjotMC4wNDc5NTc2MjQ3OTM3MjQ4NDd9XX0seyJjIjpbeyJ2IjoiZ2lw
c3JlY21vdGlvbl8xMjgwXzcyMF81MCJ9LHsidiI6MS40NDgxMjAzMDM2NTI5MjI0fV19LHsiYyI6
W3sidiI6ImdpcHNyZWNzdGF0XzEyODBfNzIwXzUwIn0seyJ2IjoxLjA0ODU0ODY3NDM2MDI2N31d
fSx7ImMiOlt7InYiOiJraXJsYW5kXzY0MF80ODBfMzAifSx7InYiOjAuMzkzMDAxNjU4NzY1OTk0
OTd9XX0seyJjIjpbeyJ2IjoibWFjbWFyY29tb3ZpbmdfNjQwXzQ4MF8zMCJ9LHsidiI6MS4zNjg4
NTc5NjkyNzc2MTI0fV19LHsiYyI6W3sidiI6Im1hY21hcmNvc3RhdGlvbmFyeV82NDBfNDgwXzMw
In0seyJ2IjowLjMwODUzNzQ4OTkxMTEwNzc0fV19LHsiYyI6W3sidiI6Im5pa2xhc18xMjgwXzcy
MF8zMCJ9LHsidiI6MS4xMTM3NjgwNzk0NjQyODA2fV19LHsiYyI6W3sidiI6Im5pa2xhc182NDBf
NDgwXzMwIn0seyJ2IjoxLjEwOTU5NTMxMTE1MzYzMX1dfSx7ImMiOlt7InYiOiJ0YWNvbWFuYXJy
b3dzXzY0MF80ODBfMzAifSx7InYiOjAuMDU4MTM2MTg5OTk2ODc3Mzg0fV19LHsiYyI6W3sidiI6
InRhY29tYXNtYWxsY2FtZXJhbW92ZW1lbnRfNjQwXzQ4MF8zMCJ9LHsidiI6MC40ODE0MzMyMzA4
MTMzNzIxOX1dfSx7ImMiOlt7InYiOiJ0aGFsb3VuZGVza210Z182NDBfNDgwXzMwIn0seyJ2Ijow
LjM0ODY0MTgyNDYwNDM3OTc2fV19LHsiYyI6W3sidiI6Ik9WRVJBTEwifSx7InYiOjAuNjkzNjk4
NDY0MjkxNTIwMTZ9XX1dLCJjb2xzIjpbeyJ0eXBlIjoic3RyaW5nIiwiaWQiOiJmaWxlIiwibGFi
ZWwiOiJGaWxlIn0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy92cDgiLCJsYWJlbCI6InN0
YXRzL3ZwOCJ9XX0NCg0KZmlsZXN0YWJsZV9hdmdbMV09eyJyb3dzIjpbeyJjIjpbeyJ2IjoiZGVz
a3RvcF82NDBfMzYwXzMwIn0seyJ2IjotMy4zMTQzMTg2MTg5NTI0OTQyfV19LHsiYyI6W3sidiI6
ImdpcHNyZWNtb3Rpb25fMTI4MF83MjBfNTAifSx7InYiOjM5LjUzMDI0MzQ5ODgzNjQwNn1dfSx7
ImMiOlt7InYiOiJnaXBzcmVjc3RhdF8xMjgwXzcyMF81MCJ9LHsidiI6MzYuNjYzNTUxMTY3NTA4
OTM1fV19LHsiYyI6W3sidiI6ImtpcmxhbmRfNjQwXzQ4MF8zMCJ9LHsidiI6Ni44OTg1MDYwNDQ3
MDczMzl9XX0seyJjIjpbeyJ2IjoibWFjbWFyY29tb3ZpbmdfNjQwXzQ4MF8zMCJ9LHsidiI6Mzku
ODgxMjg4MDE5NzkxODZ9XX0seyJjIjpbeyJ2IjoibWFjbWFyY29zdGF0aW9uYXJ5XzY0MF80ODBf
MzAifSx7InYiOjQuNjU3Mzg2MTEwNTUxOTgyNX1dfSx7ImMiOlt7InYiOiJuaWtsYXNfMTI4MF83
MjBfMzAifSx7InYiOjM0LjQ3MDYzMjgyMjM0MTg4NH1dfSx7ImMiOlt7InYiOiJuaWtsYXNfNjQw
XzQ4MF8zMCJ9LHsidiI6MjMuMDczMTY3MzY3ODI1MDE1fV19LHsiYyI6W3sidiI6InRhY29tYW5h
cnJvd3NfNjQwXzQ4MF8zMCJ9LHsidiI6LTguNzI5NzE1MDgwNjgyOTd9XX0seyJjIjpbeyJ2Ijoi
dGFjb21hc21hbGxjYW1lcmFtb3ZlbWVudF82NDBfNDgwXzMwIn0seyJ2IjoxLjQwOTg4NzQzMDY1
NjUwMTV9XX0seyJjIjpbeyJ2IjoidGhhbG91bmRlc2ttdGdfNjQwXzQ4MF8zMCJ9LHsidiI6LTAu
MTM2MDY4Njk1NTg5NjMxODZ9XX0seyJjIjpbeyJ2IjoiT1ZFUkFMTCJ9LHsidiI6MTUuODU0OTYw
MDA2MDkwNDM5fV19XSwiY29scyI6W3sidHlwZSI6InN0cmluZyIsImlkIjoiZmlsZSIsImxhYmVs
IjoiRmlsZSJ9LHsidHlwZSI6Im51bWJlciIsImlkIjoic3RhdHMvdnA4IiwibGFiZWwiOiJzdGF0
cy92cDgifV19DQoNCmZpbGVzdGFibGVfZHJhdGVbMV09eyJyb3dzIjpbeyJjIjpbeyJ2IjoiZGVz
a3RvcF82NDBfMzYwXzMwIn0seyJ2IjotMC43NzMxMDg2NDg0OTMxMjZ9XX0seyJjIjpbeyJ2Ijoi
Z2lwc3JlY21vdGlvbl8xMjgwXzcyMF81MCJ9LHsidiI6MzkuODU4Mzk1MTI4NDQzMjV9XX0seyJj
IjpbeyJ2IjoiZ2lwc3JlY3N0YXRfMTI4MF83MjBfNTAifSx7InYiOjM2LjQ1MzYyOTI0NTM5NzQx
fV19LHsiYyI6W3sidiI6ImtpcmxhbmRfNjQwXzQ4MF8zMCJ9LHsidiI6MTcuMDY3ODE3NDcxMTgx
OTF9XX0seyJjIjpbeyJ2IjoibWFjbWFyY29tb3ZpbmdfNjQwXzQ4MF8zMCJ9LHsidiI6NDUuMzk5
NjQ1NTY3MTcxOTV9XX0seyJjIjpbeyJ2IjoibWFjbWFyY29zdGF0aW9uYXJ5XzY0MF80ODBfMzAi
fSx7InYiOjE0LjMzMzk2NDMxMjA0MjY4fV19LHsiYyI6W3sidiI6Im5pa2xhc18xMjgwXzcyMF8z
MCJ9LHsidiI6MzQuODIzNjYxNTM3MTExODI1fV19LHsiYyI6W3sidiI6Im5pa2xhc182NDBfNDgw
XzMwIn0seyJ2IjoyNS42MjgyMDQwMTkyNzYxNDd9XX0seyJjIjpbeyJ2IjoidGFjb21hbmFycm93
c182NDBfNDgwXzMwIn0seyJ2IjotMy42OTYyNjk3MjE5MDEyNzk3fV19LHsiYyI6W3sidiI6InRh
Y29tYXNtYWxsY2FtZXJhbW92ZW1lbnRfNjQwXzQ4MF8zMCJ9LHsidiI6Ny44Nzk2MzEwOTQ4MDI5
NDF9XX0seyJjIjpbeyJ2IjoidGhhbG91bmRlc2ttdGdfNjQwXzQ4MF8zMCJ9LHsidiI6OS4yMTM3
MzE1MTExNTEzN31dfSx7ImMiOlt7InYiOiJPVkVSQUxMIn0seyJ2IjoyMC41NjI2NjM3NzQxOTg2
NH1dfV0sImNvbHMiOlt7InR5cGUiOiJzdHJpbmciLCJpZCI6ImZpbGUiLCJsYWJlbCI6IkZpbGUi
fSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL3ZwOCIsImxhYmVsIjoic3RhdHMvdnA4In1d
fQ0KDQpzbnJzWzFdID0gWyd7InJvd3MiOlt7ImMiOlt7InYiOjE2OS4wfSxudWxsLHsidiI6MzIu
MjkzfV19LHsiYyI6W3sidiI6MjA0LjB9LG51bGwseyJ2IjozMy40NTZ9XX0seyJjIjpbeyJ2Ijoz
MDQuMH0sbnVsbCx7InYiOjM0Ljc5OX1dfSx7ImMiOlt7InYiOjQwNC4wfSxudWxsLHsidiI6MzUu
NzQ2fV19LHsiYyI6W3sidiI6NTA0LjB9LG51bGwseyJ2IjozNi41MTN9XX0seyJjIjpbeyJ2Ijo2
MDYuMH0sbnVsbCx7InYiOjM3LjEyMX1dfSx7ImMiOlt7InYiOjcwNi4wfSxudWxsLHsidiI6Mzcu
NTk5fV19LHsiYyI6W3sidiI6ODA2LjB9LG51bGwseyJ2IjozOC4wMjR9XX0seyJjIjpbeyJ2Ijo5
My4wfSx7InYiOjI5LjU0Nn0sbnVsbF19LHsiYyI6W3sidiI6MTkzLjB9LHsidiI6MzIuODExfSxu
dWxsXX0seyJjIjpbeyJ2IjoyOTUuMH0seyJ2IjozNC42NDJ9LG51bGxdfSx7ImMiOlt7InYiOjM5
OS4wfSx7InYiOjM1LjgzM30sbnVsbF19LHsiYyI6W3sidiI6NTAwLjB9LHsidiI6MzYuNzE0fSxu
dWxsXX0seyJjIjpbeyJ2Ijo2MDEuMH0seyJ2IjozNy4zOTh9LG51bGxdfSx7ImMiOlt7InYiOjcw
MS4wfSx7InYiOjM3Ljk1MX0sbnVsbF19LHsiYyI6W3sidiI6ODAyLjB9LHsidiI6MzguNDEzfSxu
dWxsXX1dLCJjb2xzIjpbeyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJkYXRhcmF0ZSIsImxhYmVsIjoi
RGF0YXJhdGUifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL2gyNjQiLCJsYWJlbCI6InN0
YXRzL2gyNjQifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL3ZwOCIsImxhYmVsIjoic3Rh
dHMvdnA4In1dfScsJ3sicm93cyI6W3siYyI6W3sidiI6ODY2LjB9LG51bGwseyJ2IjozNS43NjN9
XX0seyJjIjpbeyJ2Ijo5NDguMH0sbnVsbCx7InYiOjM2LjE4NH1dfSx7ImMiOlt7InYiOjEwMzku
MH0sbnVsbCx7InYiOjM2LjUxNn1dfSx7ImMiOlt7InYiOjExMzYuMH0sbnVsbCx7InYiOjM2Ljg3
OH1dfSx7ImMiOlt7InYiOjEyMzYuMH0sbnVsbCx7InYiOjM3LjE1Nn1dfSx7ImMiOlt7InYiOjEz
MzYuMH0sbnVsbCx7InYiOjM3LjQ2M31dfSx7ImMiOlt7InYiOjE0MzkuMH0sbnVsbCx7InYiOjM3
Ljc0OX1dfSx7ImMiOlt7InYiOjE1MzguMH0sbnVsbCx7InYiOjM4LjAxMX1dfSx7ImMiOlt7InYi
Ojc3OS4wfSx7InYiOjMzLjUxNX0sbnVsbF19LHsiYyI6W3sidiI6ODc3LjB9LHsidiI6MzQuMTM0
fSxudWxsXX0seyJjIjpbeyJ2Ijo5NzYuMH0seyJ2IjozNC42OH0sbnVsbF19LHsiYyI6W3sidiI6
MTA3NC4wfSx7InYiOjM1LjE1Nn0sbnVsbF19LHsiYyI6W3sidiI6MTE3NS4wfSx7InYiOjM1LjU3
NX0sbnVsbF19LHsiYyI6W3sidiI6MTI3NC4wfSx7InYiOjM1Ljk2NH0sbnVsbF19LHsiYyI6W3si
diI6MTM3NC4wfSx7InYiOjM2LjMxOH0sbnVsbF19LHsiYyI6W3sidiI6MTQ3NS4wfSx7InYiOjM2
LjY2fSxudWxsXX1dLCJjb2xzIjpbeyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJkYXRhcmF0ZSIsImxh
YmVsIjoiRGF0YXJhdGUifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL2gyNjQiLCJsYWJl
bCI6InN0YXRzL2gyNjQifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL3ZwOCIsImxhYmVs
Ijoic3RhdHMvdnA4In1dfScsJ3sicm93cyI6W3siYyI6W3sidiI6ODMwLjB9LG51bGwseyJ2Ijoz
OS4xMDN9XX0seyJjIjpbeyJ2Ijo5MzAuMH0sbnVsbCx7InYiOjM5LjM2OX1dfSx7ImMiOlt7InYi
OjEwMzIuMH0sbnVsbCx7InYiOjM5LjY0OX1dfSx7ImMiOlt7InYiOjExMzEuMH0sbnVsbCx7InYi
OjM5LjkzMX1dfSx7ImMiOlt7InYiOjEyMzUuMH0sbnVsbCx7InYiOjQwLjE2NX1dfSx7ImMiOlt7
InYiOjEzMzguMH0sbnVsbCx7InYiOjQwLjM5OH1dfSx7ImMiOlt7InYiOjE0MzYuMH0sbnVsbCx7
InYiOjQwLjU4NX1dfSx7ImMiOlt7InYiOjE1MzguMH0sbnVsbCx7InYiOjQwLjc4Nn1dfSx7ImMi
Olt7InYiOjUyMi4wfSx7InYiOjM1Ljc0OX0sbnVsbF19LHsiYyI6W3sidiI6NjAyLjB9LHsidiI6
MzYuNDExfSxudWxsXX0seyJjIjpbeyJ2Ijo2ODguMH0seyJ2IjozNi45ODd9LG51bGxdfSx7ImMi
Olt7InYiOjc4My4wfSx7InYiOjM3LjUyNX0sbnVsbF19LHsiYyI6W3sidiI6ODc2LjB9LHsidiI6
MzguMDA3fSxudWxsXX0seyJjIjpbeyJ2Ijo5NzYuMH0seyJ2IjozOC40NDJ9LG51bGxdfSx7ImMi
Olt7InYiOjEwNzcuMH0seyJ2IjozOC44NX0sbnVsbF19LHsiYyI6W3sidiI6MTE4Mi4wfSx7InYi
OjM5LjIyNH0sbnVsbF19XSwiY29scyI6W3sidHlwZSI6Im51bWJlciIsImlkIjoiZGF0YXJhdGUi
LCJsYWJlbCI6IkRhdGFyYXRlIn0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy9oMjY0Iiwi
bGFiZWwiOiJzdGF0cy9oMjY0In0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy92cDgiLCJs
YWJlbCI6InN0YXRzL3ZwOCJ9XX0nLCd7InJvd3MiOlt7ImMiOlt7InYiOjEwNS4wfSxudWxsLHsi
diI6NDEuOTYyfV19LHsiYyI6W3sidiI6MjExLjB9LG51bGwseyJ2Ijo0My45MDR9XX0seyJjIjpb
eyJ2IjozMTAuMH0sbnVsbCx7InYiOjQ0LjQ0fV19LHsiYyI6W3sidiI6NDA5LjB9LG51bGwseyJ2
Ijo0NC44ODZ9XX0seyJjIjpbeyJ2Ijo1MDguMH0sbnVsbCx7InYiOjQ1LjI3Mn1dfSx7ImMiOlt7
InYiOjYwNy4wfSxudWxsLHsidiI6NDUuNjU0fV19LHsiYyI6W3sidiI6NzA2LjB9LG51bGwseyJ2
Ijo0Ni4wMDF9XX0seyJjIjpbeyJ2Ijo4MDYuMH0sbnVsbCx7InYiOjQ2LjI2fV19LHsiYyI6W3si
diI6NDUuMH0seyJ2IjozNi4wNTh9LG51bGxdfSx7ImMiOlt7InYiOjg3LjB9LHsidiI6MzkuODQ1
fSxudWxsXX0seyJjIjpbeyJ2IjoxNTEuMH0seyJ2Ijo0Mi4wOTJ9LG51bGxdfSx7ImMiOlt7InYi
OjI0Ny4wfSx7InYiOjQzLjY0M30sbnVsbF19LHsiYyI6W3sidiI6MzY1LjB9LHsidiI6NDQuNzA4
fSxudWxsXX0seyJjIjpbeyJ2Ijo1MTIuMH0seyJ2Ijo0NS40NzR9LG51bGxdfSx7ImMiOlt7InYi
OjY0Mi4wfSx7InYiOjQ1Ljk4NH0sbnVsbF19LHsiYyI6W3sidiI6NzU0LjB9LHsidiI6NDYuMzY1
fSxudWxsXX1dLCJjb2xzIjpbeyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJkYXRhcmF0ZSIsImxhYmVs
IjoiRGF0YXJhdGUifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL2gyNjQiLCJsYWJlbCI6
InN0YXRzL2gyNjQifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL3ZwOCIsImxhYmVsIjoi
c3RhdHMvdnA4In1dfScsJ3sicm93cyI6W3siYyI6W3sidiI6MTQ2LjB9LG51bGwseyJ2IjozNS44
NzV9XX0seyJjIjpbeyJ2IjoyMDUuMH0sbnVsbCx7InYiOjM3LjM2OX1dfSx7ImMiOlt7InYiOjMw
NS4wfSxudWxsLHsidiI6MzguNjZ9XX0seyJjIjpbeyJ2Ijo0MDQuMH0sbnVsbCx7InYiOjM5LjQw
N31dfSx7ImMiOlt7InYiOjUwNS4wfSxudWxsLHsidiI6MzkuOTY0fV19LHsiYyI6W3sidiI6NjA2
LjB9LG51bGwseyJ2Ijo0MC4zODF9XX0seyJjIjpbeyJ2Ijo3MDcuMH0sbnVsbCx7InYiOjQwLjcy
fV19LHsiYyI6W3sidiI6ODA3LjB9LG51bGwseyJ2Ijo0MC45OTR9XX0seyJjIjpbeyJ2Ijo5OS4w
fSx7InYiOjMwLjk0OX0sbnVsbF19LHsiYyI6W3sidiI6MTkzLjB9LHsidiI6MzQuOTY5fSxudWxs
XX0seyJjIjpbeyJ2IjoyOTEuMH0seyJ2IjozNi45OTl9LG51bGxdfSx7ImMiOlt7InYiOjM5My4w
fSx7InYiOjM4LjI0OH0sbnVsbF19LHsiYyI6W3sidiI6NDk1LjB9LHsidiI6MzkuMDc3fSxudWxs
XX0seyJjIjpbeyJ2Ijo1OTcuMH0seyJ2IjozOS42Njd9LG51bGxdfSx7ImMiOlt7InYiOjY5OC4w
fSx7InYiOjQwLjEyN30sbnVsbF19LHsiYyI6W3sidiI6Nzk5LjB9LHsidiI6NDAuNDkyfSxudWxs
XX1dLCJjb2xzIjpbeyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJkYXRhcmF0ZSIsImxhYmVsIjoiRGF0
YXJhdGUifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL2gyNjQiLCJsYWJlbCI6InN0YXRz
L2gyNjQifSx7InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL3ZwOCIsImxhYmVsIjoic3RhdHMv
dnA4In1dfScsJ3sicm93cyI6W3siYyI6W3sidiI6MTA2LjB9LG51bGwseyJ2IjozNy40fV19LHsi
YyI6W3sidiI6MjA2LjB9LG51bGwseyJ2IjozOC42Mzd9XX0seyJjIjpbeyJ2IjozMDYuMH0sbnVs
bCx7InYiOjM5LjIzOH1dfSx7ImMiOlt7InYiOjQwNi4wfSxudWxsLHsidiI6MzkuNzAyfV19LHsi
YyI6W3sidiI6NTA3LjB9LG51bGwseyJ2Ijo0MC4wMTN9XX0seyJjIjpbeyJ2Ijo2MDguMH0sbnVs
bCx7InYiOjQwLjMwOH1dfSx7ImMiOlt7InYiOjcwOS4wfSxudWxsLHsidiI6NDAuNTQ1fV19LHsi
YyI6W3sidiI6ODEwLjB9LG51bGwseyJ2Ijo0MC43NTJ9XX0seyJjIjpbeyJ2Ijo2My4wfSx7InYi
OjMzLjd9LG51bGxdfSx7ImMiOlt7InYiOjEyNi4wfSx7InYiOjM2Ljc5OX0sbnVsbF19LHsiYyI6
W3sidiI6MjQ5LjB9LHsidiI6MzguNTY4fSxudWxsXX0seyJjIjpbeyJ2IjozODMuMH0seyJ2Ijoz
OS40ODZ9LG51bGxdfSx7ImMiOlt7InYiOjQ5Ny4wfSx7InYiOjQwLjA2NX0sbnVsbF19LHsiYyI6
W3sidiI6NjAzLjB9LHsidiI6NDAuNDQ2fSxudWxsXX0seyJjIjpbeyJ2Ijo3MDUuMH0seyJ2Ijo0
MC43Mzl9LG51bGxdfSx7ImMiOlt7InYiOjgwNy4wfSx7InYiOjQwLjk4NH0sbnVsbF19XSwiY29s
cyI6W3sidHlwZSI6Im51bWJlciIsImlkIjoiZGF0YXJhdGUiLCJsYWJlbCI6IkRhdGFyYXRlIn0s
eyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy9oMjY0IiwibGFiZWwiOiJzdGF0cy9oMjY0In0s
eyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy92cDgiLCJsYWJlbCI6InN0YXRzL3ZwOCJ9XX0n
LCd7InJvd3MiOlt7ImMiOlt7InYiOjgzNC4wfSxudWxsLHsidiI6MzguNjcxfV19LHsiYyI6W3si
diI6OTM2LjB9LG51bGwseyJ2IjozOS4wODJ9XX0seyJjIjpbeyJ2IjoxMDM5LjB9LG51bGwseyJ2
IjozOS4zNTZ9XX0seyJjIjpbeyJ2IjoxMTM5LjB9LG51bGwseyJ2IjozOS42Njl9XX0seyJjIjpb
eyJ2IjoxMjQ1LjB9LG51bGwseyJ2IjozOS45Mjl9XX0seyJjIjpbeyJ2IjoxMzQwLjB9LG51bGws
eyJ2Ijo0MC4xMjl9XX0seyJjIjpbeyJ2IjoxNDQxLjB9LG51bGwseyJ2Ijo0MC4zMzR9XX0seyJj
IjpbeyJ2IjoxNTQwLjB9LG51bGwseyJ2Ijo0MC41MTZ9XX0seyJjIjpbeyJ2Ijo2ODAuMH0seyJ2
IjozNi4yMjN9LG51bGxdfSx7ImMiOlt7InYiOjc3Mi4wfSx7InYiOjM2Ljg0OX0sbnVsbF19LHsi
YyI6W3sidiI6ODY1LjB9LHsidiI6MzcuNDA3fSxudWxsXX0seyJjIjpbeyJ2Ijo5NjMuMH0seyJ2
IjozNy45MX0sbnVsbF19LHsiYyI6W3sidiI6MTA2Mi4wfSx7InYiOjM4LjMzOH0sbnVsbF19LHsi
YyI6W3sidiI6MTE2Mi4wfSx7InYiOjM4LjcyNn0sbnVsbF19LHsiYyI6W3sidiI6MTI2NS4wfSx7
InYiOjM5LjA3Mn0sbnVsbF19LHsiYyI6W3sidiI6MTM2Mi4wfSx7InYiOjM5LjM3MX0sbnVsbF19
XSwiY29scyI6W3sidHlwZSI6Im51bWJlciIsImlkIjoiZGF0YXJhdGUiLCJsYWJlbCI6IkRhdGFy
YXRlIn0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy9oMjY0IiwibGFiZWwiOiJzdGF0cy9o
MjY0In0seyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJzdGF0cy92cDgiLCJsYWJlbCI6InN0YXRzL3Zw
OCJ9XX0nLCd7InJvd3MiOlt7ImMiOlt7InYiOjE2Ni4wfSxudWxsLHsidiI6MzMuMzEzfV19LHsi
YyI6W3sidiI6MjEzLjB9LG51bGwseyJ2IjozNC44MjF9XX0seyJjIjpbeyJ2IjozMTQuMH0sbnVs
bCx7InYiOjM2LjcxOX1dfSx7ImMiOlt7InYiOjQxNS4wfSxudWxsLHsidiI6MzcuOTgxfV19LHsi
YyI6W3sidiI6NTE3LjB9LG51bGwseyJ2IjozOC44NTh9XX0seyJjIjpbeyJ2Ijo2MTcuMH0sbnVs
bCx7InYiOjM5LjV9XX0seyJjIjpbeyJ2Ijo3MTcuMH0sbnVsbCx7InYiOjQwLjA5OX1dfSx7ImMi
Olt7InYiOjgyMC4wfSxudWxsLHsidiI6NDAuNjQyfV19LHsiYyI6W3sidiI6OTYuMH0seyJ2Ijoy
OC42MjZ9LG51bGxdfSx7ImMiOlt7InYiOjE4OC4wfSx7InYiOjMyLjY2MX0sbnVsbF19LHsiYyI6
W3sidiI6MjgxLjB9LHsidiI6MzQuODV9LG51bGxdfSx7ImMiOlt7InYiOjM3Ny4wfSx7InYiOjM2
LjM3MX0sbnVsbF19LHsiYyI6W3sidiI6NDczLjB9LHsidiI6MzcuNTU5fSxudWxsXX0seyJjIjpb
eyJ2Ijo1NzIuMH0seyJ2IjozOC41MDV9LG51bGxdfSx7ImMiOlt7InYiOjY2OS4wfSx7InYiOjM5
LjI2OX0sbnVsbF19LHsiYyI6W3sidiI6NzY1LjB9LHsidiI6MzkuOTM3fSxudWxsXX1dLCJjb2xz
IjpbeyJ0eXBlIjoibnVtYmVyIiwiaWQiOiJkYXRhcmF0ZSIsImxhYmVsIjoiRGF0YXJhdGUifSx7
InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL2gyNjQiLCJsYWJlbCI6InN0YXRzL2gyNjQifSx7
InR5cGUiOiJudW1iZXIiLCJpZCI6InN0YXRzL3ZwOCIsImxhYmVsIjoic3RhdHMvdnA4In1dfScs
J3sicm93cyI6W3siYyI6W3sidiI6MTA2LjB9LG51bGwseyJ2Ijo0Mi4zMTF9XX0seyJjIjpbeyJ2
IjoyMDguMH0sbnVsbCx7InYiOjQzLjYyOH1dfSx7ImMiOlt7InYiOjMwOS4wfSxudWxsLHsidiI6
NDQuMDk3fV19LHsiYyI6W3sidiI6NDEwLjB9LG51bGwseyJ2Ijo0NC41Mn1dfSx7ImMiOlt7InYi
OjUxMS4wfSxudWxsLHsidiI6NDQuOTI4fV19LHsiYyI6W3sidiI6NjEzLjB9LG51bGwseyJ2Ijo0
NS4zMDR9XX0seyJjIjpbeyJ2Ijo3MTMuMH0sbnVsbCx7InYiOjQ1LjY0NX1dfSx7ImMiOlt7InYi
OjgxMy4wfSxudWxsLHsidiI6NDUuODc5fV19LHsiYyI6W3sidiI6NDQuMH0seyJ2IjozNS43MDJ9
LG51bGxdfSx7ImMiOlt7InYiOjgyLjB9LHsidiI6MzkuNDQzfSxudWxsXX0seyJjIjpbeyJ2Ijox
MzIuMH0seyJ2Ijo0MS43Njh9LG51bGxdfSx7ImMiOlt7InYiOjIwNC4wfSx7InYiOjQzLjI0M30s
bnVsbF19LHsiYyI6W3sidiI6MzA3LjB9LHsidiI6NDQuMzg2fSxudWxsXX0seyJjIjpbeyJ2Ijo0
NDguMH0seyJ2Ijo0NS4yNTN9LG51bGxdfSx7ImMiOlt7InYiOjYwNi4wfSx7InYiOjQ1Ljg4MX0s
bnVsbF19LHsiYyI6W3sidiI6NzUzLjB9LHsidiI6NDYuMjY4fSxudWxsXX1dLCJjb2xzIjpbeyJ0
eXBlIjoibnVtYmVyIiwiaWQiOiJkYXRhcmF0ZSIsImxhYmVsIjoiRGF0YXJhdGUifSx7InR5cGUi
OiJudW1iZXIiLCJpZCI6InN0YXRzL2gyNjQiLCJsYWJlbCI6InN0YXRzL2gyNjQifSx7InR5cGUi
OiJudW1iZXIiLCJpZCI6InN0YXRzL3ZwOCIsImxhYmVsIjoic3RhdHMvdnA4In1dfScsJ3sicm93
cyI6W3siYyI6W3sidiI6MTE0LjB9LG51bGwseyJ2IjozNi42MTl9XX0seyJjIjpbeyJ2IjoyMTUu
MH0sbnVsbCx7InYiOjM4Ljc4OH1dfSx7ImMiOlt7InYiOjMxMS4wfSxudWxsLHsidiI6MzkuNzI5
fV19LHsiYyI6W3sidiI6NDEwLjB9LG51bGwseyJ2Ijo0MC41NTN9XX0seyJjIjpbeyJ2Ijo1MDku
MH0sbnVsbCx7InYiOjQxLjM0fV19LHsiYyI6W3sidiI6NjA5LjB9LG51bGwseyJ2Ijo0MS45Njd9
XX0seyJjIjpbeyJ2Ijo3MTQuMH0sbnVsbCx7InYiOjQyLjU3M31dfSx7ImMiOlt7InYiOjgxNi4w
fSxudWxsLHsidiI6NDIuOTU4fV19LHsiYyI6W3sidiI6OTAuMH0seyJ2IjozMi42NjF9LG51bGxd
fSx7ImMiOlt7InYiOjE2NS4wfSx7InYiOjM2LjQ1MX0sbnVsbF19LHsiYyI6W3sidiI6MjU1LjB9
LHsidiI6MzguODIyfSxudWxsXX0seyJjIjpbeyJ2IjozNjMuMH0seyJ2Ijo0MC4zMTR9LG51bGxd
fSx7ImMiOlt7InYiOjQ3Mi4wfSx7InYiOjQxLjM1OH0sbnVsbF19LHsiYyI6W3sidiI6NTg3LjB9
LHsidiI6NDIuMTJ9LG51bGxdfSx7ImMiOlt7InYiOjY5Ny4wfSx7InYiOjQyLjY5fSxudWxsXX0s
eyJjIjpbeyJ2Ijo4MDAuMH0seyJ2Ijo0My4xMzd9LG51bGxdfV0sImNvbHMiOlt7InR5cGUiOiJu
dW1iZXIiLCJpZCI6ImRhdGFyYXRlIiwibGFiZWwiOiJEYXRhcmF0ZSJ9LHsidHlwZSI6Im51bWJl
ciIsImlkIjoic3RhdHMvaDI2NCIsImxhYmVsIjoic3RhdHMvaDI2NCJ9LHsidHlwZSI6Im51bWJl
ciIsImlkIjoic3RhdHMvdnA4IiwibGFiZWwiOiJzdGF0cy92cDgifV19JywneyJyb3dzIjpbeyJj
IjpbeyJ2IjoxMzAuMH0sbnVsbCx7InYiOjMzLjAyNH1dfSx7ImMiOlt7InYiOjIyMi4wfSxudWxs
LHsidiI6MzYuMjI3fV19LHsiYyI6W3sidiI6MzI1LjB9LG51bGwseyJ2IjozNy4zMTJ9XX0seyJj
IjpbeyJ2Ijo0MjguMH0sbnVsbCx7InYiOjM4LjE0NH1dfSx7ImMiOlt7InYiOjUyOC4wfSxudWxs
LHsidiI6MzkuMTIxfV19LHsiYyI6W3sidiI6NjMyLjB9LG51bGwseyJ2IjozOS41ODh9XX0seyJj
IjpbeyJ2Ijo3MzQuMH0sbnVsbCx7InYiOjQwLjA3M31dfSx7ImMiOlt7InYiOjgzMy4wfSxudWxs
LHsidiI6NDAuMzI5fV19LHsiYyI6W3sidiI6NzUuMH0seyJ2IjoyOC44MzV9LG51bGxdfSx7ImMi
Olt7InYiOjE0NS4wfSx7InYiOjMyLjYyNH0sbnVsbF19LHsiYyI6W3sidiI6MjIyLjB9LHsidiI6
MzUuMTY3fSxudWxsXX0seyJjIjpbeyJ2IjozMTAuMH0seyJ2IjozNi45MzV9LG51bGxdfSx7ImMi
Olt7InYiOjQxOS4wfSx7InYiOjM4LjMxMX0sbnVsbF19LHsiYyI6W3sidiI6NTM4LjB9LHsidiI6
MzkuMzY4fSxudWxsXX0seyJjIjpbeyJ2Ijo2NjguMH0seyJ2Ijo0MC4xNjd9LG51bGxdfSx7ImMi
Olt7InYiOjc3MC4wfSx7InYiOjQwLjc2fSxudWxsXX1dLCJjb2xzIjpbeyJ0eXBlIjoibnVtYmVy
IiwiaWQiOiJkYXRhcmF0ZSIsImxhYmVsIjoiRGF0YXJhdGUifSx7InR5cGUiOiJudW1iZXIiLCJp
ZCI6InN0YXRzL2gyNjQiLCJsYWJlbCI6InN0YXRzL2gyNjQifSx7InR5cGUiOiJudW1iZXIiLCJp
ZCI6InN0YXRzL3ZwOCIsImxhYmVsIjoic3RhdHMvdnA4In1dfScsXQ0KDQoNCnZhciBzZWxlY3Rl
ZCA9IDANCnZhciBpbWFnZXN0ciA9ICcnOw0KdmFyIGJldHRlcnRhYmxlPTA7DQp2YXIgY2hhcnQ9
MDsNCnZhciBiZXR0ZXI9MDsNCnZhciBtZXRyaWNkYXRhPTA7DQp2YXIgbWV0cmljdmlldz0wOw0K
dmFyIGNvbHVtbj0xOw0KdmFyIGZvcm1hdHRlcj0wOw0KDQpmdW5jdGlvbiBjaGFuZ2VDb2x1bW4o
Y29sKSB7DQogIGNvbHVtbiA9IGNvbDsNCiAgZHJhd19maWxlcygpOw0KfQ0KDQpmdW5jdGlvbiBj
aGFuZ2VNZXRyaWMobSkgew0KICBmdGFibGU9bQ0KICBkcmF3X2ZpbGVzKCkNCn0NCg0KZnVuY3Rp
b24gc2V0dXBfdmlzKCkgew0KICBjaGFydCA9IG5ldyBnb29nbGUudmlzdWFsaXphdGlvbi5TY2F0
dGVyQ2hhcnQoDQogICAgICBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgibWV0cmljZ3JhcGgiKSk7
DQoNCiAgYmV0dGVydGFibGUgPSBuZXcgZ29vZ2xlLnZpc3VhbGl6YXRpb24uVGFibGUoDQogICAg
ICBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgiYmV0dGVydGFibGUiKSk7DQoNCiAgZHJhd19maWxl
cygpOw0KfQ0KDQpmdW5jdGlvbiBkcmF3X2ZpbGVzKCkgew0KICB2YXIgY3NzQ2xhc3NOYW1lcyA9
IHsNCiAgICAgICdoZWFkZXJSb3cnOiAnYmx1ZS1mb250IHNtYWxsLWZvbnQgYm9sZC1mb250IHNt
YWxsLW1hcmdpbicsDQogICAgICAndGFibGVSb3cnOiAnc21hbGwtZm9udCBzbWFsbC1tYXJnaW4n
LA0KICAgICAgJ29kZFRhYmxlUm93JzogJ2xpZ2h0LWdyYXktYmFja2dyb3VuZCBzbWFsbC1mb250
IHNtYWxsLW1hcmdpbicsDQogICAgICAnc2VsZWN0ZWRUYWJsZVJvdyc6ICdvcmFuZ2UtYmFja2dy
b3VuZCBzbWFsbC1mb250JywNCiAgICAgICdob3ZlclRhYmxlUm93JzogJ3NtYWxsLWZvbnQgaGVh
ZGVyLXN0eWxlJywNCiAgICAgICdoZWFkZXJDZWxsJzogJ2hlYWRlci1zdHlsZSBzbWFsbC1tYXJn
aW4nLA0KICAgICAgJ3RhYmxlQ2VsbCc6ICdzbWFsbC1tYXJnaW4nfTsNCg0KICB2YXIgb3B0aW9u
cyA9IHsnYWxsb3dIdG1sJzogdHJ1ZX07DQogIGlmIChiZXR0ZXIgIT0gMCkgZGVsZXRlIGJldHRl
cjsNCg0KICBjb2w9ZXZhbChmdGFibGUrJ1tjb2x1bW5dJykNCiAgYmV0dGVyID0gbmV3IGdvb2ds
ZS52aXN1YWxpemF0aW9uLkRhdGFUYWJsZShjb2wpDQoNCiAgLy8gUHl0aG9uIFRlbXBsYXRlIGNv
ZGUgcmVwbGFjZXMgdGhlIGZvbGxvd2luZyBsaW5lIHdpdGggYSBsaXN0IG9mDQogIC8vIGZvcm1h
dHRlcnMuDQogIGlmIChmdGFibGUgPT0gJ2ZpbGVzdGFibGVfZHNucicpDQogICAgZm9ybWF0dGVy
ID0gbmV3IGdvb2dsZS52aXN1YWxpemF0aW9uLk51bWJlckZvcm1hdCgNCiAgICAgIHtmcmFjdGlv
bkRpZ2l0czogNCwgc3VmZml4OiIgZGIifSk7DQogIGVsc2UNCiAgICBmb3JtYXR0ZXIgPSBuZXcg
Z29vZ2xlLnZpc3VhbGl6YXRpb24uTnVtYmVyRm9ybWF0KA0KICAgICAgIHtmcmFjdGlvbkRpZ2l0
czogNCwgc3VmZml4OiIlIn0pOw0KDQogICAgIGZvcm1hdHRlci5mb3JtYXQoYmV0dGVyLCAxKTsN
Cg0KICBiZXR0ZXJ0YWJsZS5kcmF3KGJldHRlcixvcHRpb25zKTsNCiAgZ29vZ2xlLnZpc3VhbGl6
YXRpb24uZXZlbnRzLmFkZExpc3RlbmVyKGJldHRlcnRhYmxlLCAnc2VsZWN0JywNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNlbGVjdEJldHRlckhhbmRsZXIpOw0K
ICBxdWVyeV9maWxlKCkNCn0NCg0KZnVuY3Rpb24gcXVlcnlfZmlsZSgpIHsNCiAgaW1hZ2VzdHIg
PSBiZXR0ZXIuZ2V0Rm9ybWF0dGVkVmFsdWUoc2VsZWN0ZWQsIDApDQogIHZhciBtZXRyaWNqc29u
ID0gZXZhbCgnKCcgKyBzbnJzW2NvbHVtbl1bc2VsZWN0ZWRdICsgJyknKTsNCiAgbWV0cmljZGF0
YSA9IG5ldyBnb29nbGUudmlzdWFsaXphdGlvbi5EYXRhVGFibGUobWV0cmljanNvbiwgMC42KTsN
CiAgaWYoIG1ldHJpY3ZpZXcgIT0gMCApIGRlbGV0ZSBtZXRyaWN2aWV3Ow0KICBtZXRyaWN2aWV3
ID0gbmV3IGdvb2dsZS52aXN1YWxpemF0aW9uLkRhdGFWaWV3KG1ldHJpY2RhdGEpOw0KDQogIGNo
YXJ0LmRyYXcobWV0cmljdmlldywge2N1cnZlVHlwZTonZnVuY3Rpb24nLA0KICAgICAgY2hhcnRB
cmVhOntsZWZ0OmNoYXJ0X2xlZnQsIHRvcDpjaGFydF90b3AsIHdpZHRoOmNoYXJ0X3dpZHRoLA0K
ICAgICAgaGVpZ2h0OmNoYXJ0X2hlaWdodC05MH0sDQogICAgICBoQXhpczp7dGl0bGU6ImRhdGFy
YXRlIGluIGticHMifSwgdkF4aXM6e3RpdGxlOiJxdWFsaXR5IGluIGRlY2liZWxzIn0sDQogICAg
ICBsZWdlbmQ6e3Bvc2l0aW9uOiJpbiJ9LCB0aXRsZTppbWFnZXN0ciwgcG9pbnRTaXplOjIsIGxp
bmVXaWR0aDoxLA0KICAgICAgd2lkdGg6Y2hhcnRfd2lkdGgsIGhlaWdodDpjaGFydF9oZWlnaHQt
NTAgfSk7DQoNCiAgZ29vZ2xlLnZpc3VhbGl6YXRpb24uZXZlbnRzLmFkZExpc3RlbmVyKGNoYXJ0
LCAnc2VsZWN0JywgY2hhcnRTZWxlY3QpOw0KICBnb29nbGUudmlzdWFsaXphdGlvbi5ldmVudHMu
YWRkTGlzdGVuZXIoY2hhcnQsICdvbm1vdXNlb3ZlcicsIGNoYXJ0TW91c2VPdmVyKTsNCiAgZ29v
Z2xlLnZpc3VhbGl6YXRpb24uZXZlbnRzLmFkZExpc3RlbmVyKGNoYXJ0LCAnb25tb3VzZW91dCcs
IGNoYXJ0TW91c2VPdXQpOw0KfQ0KDQpmdW5jdGlvbiBjaGFydE1vdXNlT3V0KGUpIHsNCiAgc3Rh
dHVzYmFyID0gZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoJ3N0YXR1cycpOw0KICBzdGF0dXNiYXIu
c3R5bGUuZGlzcGxheSA9ICdub25lJzsNCn0NCg0KZnVuY3Rpb24gY2hhcnRNb3VzZU92ZXIoZSkg
ew0KICBwb2ludERpZmZlcmVuY2UoZS5yb3csIGUuY29sdW1uKQ0KfQ0KDQpmdW5jdGlvbiBwb2lu
dERpZmZlcmVuY2Uocm93LCBjb2wpIHsNCiAgaWYoIXJvdyB8fCAhY29sKQ0KICAgIHJldHVybjsN
Cg0KICB2YXIgY29scyA9IG1ldHJpY2RhdGEuZ2V0TnVtYmVyT2ZDb2x1bW5zKCk7DQogIHZhciBy
b3dzID0gbWV0cmljZGF0YS5nZXROdW1iZXJPZlJvd3MoKTsNCg0KICB2YXIgc2VsX2JpdHJhdGUg
PSBtZXRyaWN2aWV3LmdldFZhbHVlKHJvdywgMCApOw0KICB2YXIgc2VsX21ldHJpYyA9IG1ldHJp
Y3ZpZXcuZ2V0VmFsdWUocm93LCBjb2wpOw0KDQogIHZhciBtZXNzYWdlID0gIkF0ICIgKyBzZWxf
bWV0cmljLnRvRml4ZWQoMikgKyAiIGRlY2liZWxzLCA8ZW0+Ig0KICBtZXNzYWdlID0gbWVzc2Fn
ZSArIG1ldHJpY2RhdGEuZ2V0Q29sdW1uTGFiZWwoY29sKSArICI8L2VtPiBpcyA8dWw+Ig0KDQog
IC8vIGNvbCAwIGlzIGRhdGFyYXRlDQogIGZvciggdmFyIGk9MTtpPGNvbHM7KytpKSB7DQoNCiAg
ICB2YXIgbWV0cmljX2dyZWF0ZXN0X3RoYXRzX2xlc3MgPSAwOw0KICAgIHZhciByYXRlX2dyZWF0
ZXN0X3RoYXRzX2xlc3MgPSAwOw0KICAgIHZhciBtZXRyaWNfc21hbGxlc3RfdGhhdHNfZ3JlYXRl
ciA9IDk5OTsNCiAgICB2YXIgcmF0ZV9zbWFsbGVzdF90aGF0c19ncmVhdGVyID0gMDsNCg0KICAg
IGlmKGk9PWNvbCkNCiAgICAgIGNvbnRpbnVlOw0KDQogICAgLy8gRmluZCB0aGUgbG93ZXN0IG1l
dHJpYyBmb3IgdGhlIGNvbHVtbiB0aGF0J3MgZ3JlYXRlciB0aGFuIHNlbF9tZXRyaWMgYW5kDQog
ICAgLy8gdGhlIGhpZ2hlc3QgbWV0cmljIGZvciB0aGlzIGNvbHVtbiB0aGF0J3MgbGVzcyB0aGFu
IHRoZSBtZXRyaWMuDQogICAgZm9yKHZhciBsaW5lX2NvdW50ID0gMDsgbGluZV9jb3VudCA8IHJv
d3M7ICsrbGluZV9jb3VudCkgew0KICAgICAgdGhpc19tZXRyaWMgPSBtZXRyaWNkYXRhLmdldFZh
bHVlKGxpbmVfY291bnQsIGkpDQogICAgICB0aGlzX3JhdGUgPSBtZXRyaWNkYXRhLmdldFZhbHVl
KGxpbmVfY291bnQsIDApDQogICAgICBpZighdGhpc19tZXRyaWMpDQogICAgICAgIGNvbnRpbnVl
Ow0KDQogICAgICBpZih0aGlzX21ldHJpYyA+IG1ldHJpY19ncmVhdGVzdF90aGF0c19sZXNzICYm
DQogICAgICAgICB0aGlzX21ldHJpYyA8IHNlbF9tZXRyaWMpIHsNCiAgICAgICAgbWV0cmljX2dy
ZWF0ZXN0X3RoYXRzX2xlc3MgPSB0aGlzX21ldHJpYzsNCiAgICAgICAgcmF0ZV9ncmVhdGVzdF90
aGF0c19sZXNzID0gdGhpc19yYXRlOw0KICAgICAgfQ0KICAgICAgaWYodGhpc19tZXRyaWMgPCBt
ZXRyaWNfc21hbGxlc3RfdGhhdHNfZ3JlYXRlciAmJg0KICAgICAgICB0aGlzX21ldHJpYyA+IHNl
bF9tZXRyaWMpIHsNCiAgICAgICAgbWV0cmljX3NtYWxsZXN0X3RoYXRzX2dyZWF0ZXIgPSB0aGlz
X21ldHJpYzsNCiAgICAgICAgcmF0ZV9zbWFsbGVzdF90aGF0c19ncmVhdGVyID0gdGhpc19yYXRl
Ow0KICAgICAgfQ0KICAgIH0NCg0KICAgIGlmKHJhdGVfc21hbGxlc3RfdGhhdHNfZ3JlYXRlciA9
PSAwIHx8IHJhdGVfZ3JlYXRlc3RfdGhhdHNfbGVzcyA9PSAwKSB7DQogICAgICBtZXNzYWdlID0g
bWVzc2FnZSArICIgPGxpPiBDb3VsZG4ndCBmaW5kIGEgcG9pbnQgb24gYm90aCBzaWRlcy48L2xp
PiINCiAgICB9IGVsc2Ugew0KICAgICAgbWV0cmljX3Nsb3BlID0gKCByYXRlX3NtYWxsZXN0X3Ro
YXRzX2dyZWF0ZXIgLSByYXRlX2dyZWF0ZXN0X3RoYXRzX2xlc3MpIC8NCiAgICAgICAgICAoIG1l
dHJpY19zbWFsbGVzdF90aGF0c19ncmVhdGVyIC0gbWV0cmljX2dyZWF0ZXN0X3RoYXRzX2xlc3Mp
Ow0KDQogICAgICBwcm9qZWN0ZWRfcmF0ZSA9ICggc2VsX21ldHJpYyAtIG1ldHJpY19ncmVhdGVz
dF90aGF0c19sZXNzKSAqDQogICAgICAgICAgbWV0cmljX3Nsb3BlICsgcmF0ZV9ncmVhdGVzdF90
aGF0c19sZXNzOw0KDQogICAgICBkaWZmZXJlbmNlID0gMTAwICogKHByb2plY3RlZF9yYXRlIC8g
c2VsX2JpdHJhdGUgLSAxKTsNCg0KDQogICAgICBpZiAoZGlmZmVyZW5jZSA+IDApDQogICAgICAg
IG1lc3NhZ2UgPSBtZXNzYWdlICsgIjxsaT4gICIgKyBkaWZmZXJlbmNlLnRvRml4ZWQoMikgKw0K
ICAgICAgICAgICAgICAgICAgIiUgc21hbGxlciB0aGFuIDxlbT4iICsNCiAgICAgICAgICAgICAg
ICAgIG1ldHJpY2RhdGEuZ2V0Q29sdW1uTGFiZWwoaSkgKyAiPC9lbT48L2xpPiAiDQogICAgICBl
bHNlDQogICAgICAgIG1lc3NhZ2UgPSBtZXNzYWdlICsgIjxsaT4gICIgKyAtZGlmZmVyZW5jZS50
b0ZpeGVkKDIpICsNCiAgICAgICAgICAgICAgICAgICIlIGJpZ2dlciB0aGFuIDxlbT4iICsNCiAg
ICAgICAgICAgICAgICAgIG1ldHJpY2RhdGEuZ2V0Q29sdW1uTGFiZWwoaSkgKyAiPC9lbT48L2xp
PiAiDQogICAgfQ0KDQogIH0NCiAgbWVzc2FnZSA9IG1lc3NhZ2UgKyAiPC91bD4iDQogIHN0YXR1
c2JhciA9IGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCdzdGF0dXMnKTsNCiAgc3RhdHVzYmFyLmlu
bmVySFRNTCA9ICI8cD4iICsgbWVzc2FnZSArICI8L3A+IjsNCiAgc3RhdHVzYmFyLnN0eWxlLmRp
c3BsYXkgPSAnYmxvY2snOw0KfQ0KDQpmdW5jdGlvbiBjaGFydFNlbGVjdCgpIHsNCiAgdmFyIHNl
bGVjdGlvbiA9IGNoYXJ0LmdldFNlbGVjdGlvbigpOw0KICB2YXIgbWVzc2FnZSA9ICcnOw0KICB2
YXIgbWluID0gbWV0cmljdmlldy5nZXRGb3JtYXR0ZWRWYWx1ZShzZWxlY3Rpb25bMF0ucm93LCAw
KTsNCiAgdmFyIG1heCA9IG1ldHJpY3ZpZXcuZ2V0Rm9ybWF0dGVkVmFsdWUoc2VsZWN0aW9uW3Nl
bGVjdGlvbi5sZW5ndGgtMV0ucm93LCAwKTsNCiAgdmFyIHZhbCA9IG1ldHJpY3ZpZXcuZ2V0Rm9y
bWF0dGVkVmFsdWUoc2VsZWN0aW9uWzBdLnJvdyxzZWxlY3Rpb25bMF0uY29sdW1uKTsNCg0KICBw
b2ludERpZmZlcmVuY2Uoc2VsZWN0aW9uWzBdLnJvdywgc2VsZWN0aW9uWzBdLmNvbHVtbikNCiAg
bWluID0gbWluIC8gMw0KICBtYXggPSBtYXggKiAzDQogIG1ldHJpY3ZpZXcuc2V0Um93cyhtZXRy
aWNkYXRhLmdldEZpbHRlcmVkUm93cygNCiAgICAgIFt7Y29sdW1uOiAwLG1pblZhbHVlOiBtaW4s
IG1heFZhbHVlOm1heH1dKSk7DQoNCiAgY2hhcnQuZHJhdyhtZXRyaWN2aWV3LCB7Y3VydmVUeXBl
OidmdW5jdGlvbicsDQogICAgICBjaGFydEFyZWE6e2xlZnQ6NDAsIHRvcDoxMCwgd2lkdGg6Y2hh
cnRfd2lkdGgsIGhlaWdodDpjaGFydF9oZWlnaHQgLSAxMTB9LA0KICAgICAgaEF4aXM6e3RpdGxl
OiJkYXRhcmF0ZSBpbiBrYnBzIn0sIHZBeGlzOnt0aXRsZToicXVhbGl0eSBpbiBkZWNpYmVscyJ9
LA0KICAgICAgbGVnZW5kOntwb3NpdGlvbjoiaW4ifSwgdGl0bGU6aW1hZ2VzdHIsIHBvaW50U2l6
ZToyLCBsaW5lV2lkdGg6MSwNCiAgICAgIHdpZHRoOmNoYXJ0X3dpZHRoLCBoZWlnaHQ6Y2hhcnRf
aGVpZ2h0IC0gNTB9KTsNCn0NCg0KZnVuY3Rpb24gc2VsZWN0QmV0dGVySGFuZGxlcigpIHsNCiAg
dmFyIHNlbGVjdGlvbiA9IGJldHRlcnRhYmxlLmdldFNlbGVjdGlvbigpOw0KICBmb3IgKHZhciBp
ID0gMDsgaSA8IHNlbGVjdGlvbi5sZW5ndGg7IGkrKykgew0KICAgIGl0ZW0gPSBzZWxlY3Rpb25b
aV07DQogIH0NCiAgc2VsZWN0ZWQgPSBpdGVtLnJvdw0KICBxdWVyeV9maWxlKCkNCn0NCg0KZ29v
Z2xlLmxvYWQoJ3Zpc3VhbGl6YXRpb24nLCAnMScsIHsncGFja2FnZXMnIDogWydjb3JlY2hhcnQn
LCd0YWJsZSddfSk7DQpnb29nbGUuc2V0T25Mb2FkQ2FsbGJhY2soc2V0dXBfdmlzKTsNCjwvc2Ny
aXB0Pg0KPC9oZWFkPg0KDQo8Ym9keT4NCg0KICA8ZGl2IGNsYXNzPSJjb250YWluZXJfMTIiPg0K
DQogICAgPGRpdiBjbGFzcz0iZ3JpZF8xMiBoZWFkZXIiPg0KICAgICAgPGgyPlZQOCBSZXN1bHRz
PC9oMj4NCiAgICA8L2Rpdj4NCg0KICAgIDxkaXYgY2xhc3M9ImdyaWRfMTIgcmFkaW8iPg0KDQog
ICAgPGRpdiBjbGFzcz0iZ3JpZF8xMiBtYWluIj4NCg0KICAgICAgPGRpdiBjbGFzcz0iZ3JpZF81
IGFscGhhIGNsaXBsaXN0Ij4NCiAgICAgICAgPGRpdiBpZD0iYmV0dGVydGFibGUiPjwvZGl2Pg0K
ICAgICAgPC9kaXY+DQoNCiAgICAgIDxkaXYgY2xhc3M9ImdyaWRfNSBjaGFydGFyZWEiPg0KICAg
ICAgICA8ZGl2IGlkPSJtZXRyaWNncmFwaCI+PC9kaXY+DQogICAgICA8L2Rpdj4NCg0KICAgICAg
PGRpdiBjbGFzcz0iZ3JpZF8yIG9tZWdhIGluZGljYXRvcnMiPg0KICAgICAgICA8ZGl2IGNsYXNz
PSJjb250ZW50Ij4NCiAgICAgICAgICA8aDU+SW5kaWNhdG9yczwvaDU+DQogICAgICAgICAgPGhy
Pg0KICAgICAgICAgIDxkaXYgaWQ9InN0YXR1cyI+PC9kaXY+DQogICAgICAgIDwvZGl2Pg0KICAg
ICAgPC9kaXY+DQoNCiAgICA8L2Rpdj4NCg0KICA8L2Rpdj4NCg0KPC9ib2R5Pg0KPC9odG1sPg0K
DQo=

--_005_BBE9739C2C302046BD34B42713A1E2A22DE32C48ESESSMB105erics_--

From stephane.proust@orange.com  Fri Mar 15 09:08: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 A9AEF21F84B0 for ; Fri, 15 Mar 2013 09:08:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.066
X-Spam-Level: 
X-Spam-Status: No, score=-0.066 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, MANGLED_LOAN=2.3, SARE_MILLIONSOF=0.315, 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 Y4kTRObI-8aV for ; Fri, 15 Mar 2013 09:08:32 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 142D721F8835 for ; Fri, 15 Mar 2013 09:08:32 -0700 (PDT)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 732D82DC1A5; Fri, 15 Mar 2013 17:08:31 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 520EB35C055; Fri, 15 Mar 2013 17:08:31 +0100 (CET)
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; Fri, 15 Mar 2013 17:08:26 +0100
From: 
To: Andrew Allen , "R.Jesske@telekom.de" , "koen.vos@skype.net" , "espeberg@cisco.com" 
Thread-Topic: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIHAg2ECP5H1T90qzFszqZMyAx5ilHxjg///23wCAAH5yAIAACmiAgADS7YCAAFcAAIAAHUoA///0K4CAABElMA==
Date: Fri, 15 Mar 2013 16:08:17 +0000
Message-ID: <15570_1363363711_5143477F_15570_5387_1_61f74e36-8baf-42a5-b86d-d947dd4f193f@PEXCVZYH02.corporate.adroot.infra.ftgroup>
References: <4507_1363362629_51434345_4507_361_1_6af2514e-a2f2-4248-b7a9-5d0452f3abf7@PEXCVZYH02.corporate.adroot.infra.ftgroup> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.5]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.15.151524
Cc: "rtcweb@ietf.org" , MARJOU Xavier OLNC/OLN 
Subject: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 15 Mar 2013 16:08:34 -0000

>>we shouldn't give the impression that its more important to include some =
codecs than others that are available to the browser to use.

But Why shouldn't we give that impression ?

Because obviously YES it is more important to support codecs that are imple=
mented in billions of devices and the support of which will improve the qua=
lity for millions of customers and reduce the costs in networks than codecs=
 of specific and limited usage.

And since AMR AMR-WB stay the mandatory codecs for 4G VoLTE I don't think t=
he importance of these codecs can ben challenged for the future

St=E9phane


-----Message d'origine-----
De=A0: Andrew Allen [mailto:aallen@blackberry.com]=20
Envoy=E9=A0: vendredi 15 mars 2013 16:58
=C0=A0: PROUST Stephane OLNC/OLPS; R.Jesske@telekom.de; koen.vos@skype.net;=
 espeberg@cisco.com
Cc=A0: MARJOU Xavier OLNC/OLN; rtcweb@ietf.org
Objet=A0: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-co=
decs-for-interop-01


Suitable to me means suitable for the application context i.e if the applic=
ation is conversational real time audio then all audio codecs suitable for =
conversational real time audio the browser has the ability to use are recom=
mended to be included in the offer.

I don't agree to mention specific codecs - all codecs that meet the suitabi=
lity for the application apply and we shouldn't give the impression that it=
s more important to include some codecs than others that are available to t=
he browser to use.=20


----- Original Message -----
From: stephane.proust@orange.com [mailto:stephane.proust@orange.com]
Sent: Friday, March 15, 2013 10:50 AM Central Standard Time
To: Andrew Allen; R.Jesske@telekom.de ; koen.vos@skype=
.net ; espeberg@cisco.com 
Cc: MARJOU Xavier OLNC/OLN ; rtcweb@ietf.org 
Subject: RE: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01

Hello

As mentioned earlier, this kind of general statement makes sense and would =
be acceptable for us only if it gives some minimum guidance on what "suitab=
le" means. It means: the codecs that are especially important to be conside=
red because their support would solve the interoperability issue for a huge=
 number of calls and because they can be made available to the browsers on =
a high number of devices:=20

"If other suitable audio codecs are available to the browser to use it is r=
ecommended that they are also included in the offer in order to maximize th=
e possibility to establish the session without the need for audio transcodi=
ng."
This is especially the case for AMR and AMR-WB for interoperability with 3G=
PP mobile devices and G.722 for interoperability with fixed ETSI/DECT CAT-i=
q devices


Stephane Proust



-----Message d'origine-----
De=A0: Andrew Allen [mailto:aallen@blackberry.com] Envoy=E9=A0: vendredi 15=
 mars 2013 15:56 =C0=A0: R.Jesske@telekom.de; koen.vos@skype.net; espeberg@=
cisco.com; PROUST Stephane OLNC/OLPS Cc=A0: MARJOU Xavier OLNC/OLN; rtcweb@=
ietf.org Objet=A0: RE: [rtcweb] Agenda time request for draft-marjou-rtcweb=
-audio-codecs-for-interop-01

Roland

I have proposed that we add the following text to address the interoperabil=
ity concerns

"If other suitable audio codecs are available to the browser to use it is r=
ecommended that they are also included in the offer in order to maximize th=
e possibility to establish the session without the need for audio transcodi=
ng."

The MTI Audio Codecs are defined to ensure a basic level of interoperabilit=
y and will need to be always supported for that reason. Support for additio=
nal audio codecs is an implementation and business case decision and the ad=
ditional audio codecs that it makes sense to support will change over time =
(as codecs become obsolete and new ones are developed and deployed. So addi=
tional audio codecs should not be specified in the RTCweb RFCs.

Andrew

-----Original Message-----
From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]
Sent: Friday, March 15, 2013 5:45 AM
To: Andrew Allen; koen.vos@skype.net; espeberg@cisco.com; stephane.proust@o=
range.com
Cc: xavier.marjou@orange.com; rtcweb@ietf.org
Subject: AW: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01

Hi Andrew,
but where will you start and where will you end.
The codec discussion appears now so why not try to solve this now?
And one proposal is to use these codecs and I fully support it.

Roland

> -----Urspr=FCngliche Nachricht-----
> Von: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] Im=20
> Auftrag von Andrew Allen
> Gesendet: Donnerstag, 14. M=E4rz 2013 22:10
> An: koen.vos@skype.net; espeberg@cisco.com; stephane.proust@orange.com
> Cc: xavier.marjou@orange.com; rtcweb@ietf.org
> Betreff: Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
>
> Koen is right that there are many more obstacles to RTCweb and legacy=20
> network interop than just a common codec. First there will need to be=20
> RTCweb signaling gateways to interface between the RTCweb signaling=20
> and the legacy networks (SIP,
> H.323 etc) and there will need to be in place mechanisms for peering,=20
> federation and address resolution between networks as well as service=20
> agreements in place between the players.
>
> Until those are resolved supporting codecs used in those networks is=20
> pointless.
>
> Andrew
>
> ----- Original Message -----
> From: Koen Vos [mailto:koen.vos@skype.net]
> Sent: Thursday, March 14, 2013 03:32 PM Central Standard Time
> To: Espen Berger (espeberg) ;=20
> stephane.proust@orange.com 
> Cc: rtcweb@ietf.org ; MARJOU Xavier OLNC/OLN=20
> 
> Subject: Re: [rtcweb] Agenda time     request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> > It's interop with billions of mobile phones and with fixed
> terminals in legacy telephony services.
>
> The problem is that WebRTC and legacy services live in separate
> networks: the open Web vs proprietary Telco networks.
>
> WebRTC connecting to a Telco network would have to go through a=20
> Gateway.  The PSTN termination providers who run these Gateways=20
> support G.711, G.729 and perhaps some other  codecs like iLBC.  They=20
> do not, however, support the codecs you are advocating for.
>
> The lack of support for Transcoding-Free Operation by Telcos to the=20
> rest of the world has been hurting interop voice quality for a long=20
> time, but unfortunately we can't fix that here at the IETF.
>
> We can fit our cars with your costly railroad wheels, but you still=20
> wouldn't let us on your tracks.
>
> koen.
>
>
> -----Original Message-----
> From: rtcweb-bounces@ietf.org
> [mailto:rtcweb-bounces@ietf.org] On Behalf Of=20
> stephane.proust@orange.com
> Sent: 14. mars 2013 13:36
> To: Jean-Marc Valin
> Cc: rtcweb@ietf.org; MARJOU Xavier OLNC/OLN
> Subject: Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> Hello
>
> The short list is aligned to what is specified in 3GPP
> (mobile) and CAT-iq (fixed). Check the related service specifications!
> The short list (AMR, AMR-WB, G.722) is a minimal subset of codecs to=20
> minimize interop issues and transcoding costs for telco services.
> It's not a question of what's the favourite codec for a given=20
> application. It's interop with billions of mobile phones and with=20
> fixed terminals in legacy telephony services.
>
> St=E9phane
>
> -----Message d'origine-----
> De : Jean-Marc Valin [mailto:jmvalin@mozilla.com] Envoy=E9 :
> jeudi 14 mars 2013 05:55 =C0 : PROUST Stephane OLNC/OLPS Cc :
> Andrew Allen; Markus.Isomaki@nokia.com; MARJOU Xavier OLNC/OLN;=20
> rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/13/2013 06:48 PM, stephane.proust@orange.com wrote:
> > The reason is simply that AMR and AMR-WB are supported in
> billions of
> > devices !
>
> Just curious, why exclude from the list other codecs with similar huge=20
> deployment? I can think of at least:
> - - GSM-FR (mobile)
> - - Speex (Flash)
> - - G.729 (PSTN gateways)
> - - iLBC (PSTN gateways)
> - - G.726 (DECT)
> - - SILK (original non-Opus version in Skype)
>
> (sorry, if I missed someone's favorite codec in this list)
>
> It's not at all clear to me what's so special that makes AMR, AMR-WB=20
> and G.722 different from the other codecs in the list above. Not that=20
> I insist on shipping G.729 :-)
>
> Personally, I'd favor a draft that included a lot more codecs,=20
> describing for each one the benefits of supporting it. Implementers=20
> could then choose which of these they care about for their particular=20
> situation.
>
> Cheers,
>
>         Jean-Marc
>
> > St=E9phane
> >
> >
> > -----Message d'origine----- De : Andrew Allen=20
> > [mailto:aallen@blackberry.com] Envoy=E9 : mercredi 13 mars 2013
> > 23:41 =C0 : PROUST Stephane OLNC/OLPS; Markus.Isomaki@nokia.com;=20
> > jmvalin@mozilla.com Cc : MARJOU Xavier OLNC/OLN;
> rtcweb@ietf.org Objet
> > : Re: [rtcweb] Agenda time request for
> > draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> >
> > No this wouldn't be acceptable to me.
> >
> > I don't see a reason to push a particular set of Codecs
> over any other
> > set of codecs supported on the device. If the device supports the=20
> > codecs and they are available to the browser then we should
> recommend
> > that they be offered in the negotiation.
> >
> > The marjou draft can advertise the merits and reasons why they are=20
> > good codecs to support.
> >
> >
> > ----- Original Message ----- From: stephane.proust@orange.com=20
> > [mailto:stephane.proust@orange.com] Sent: Wednesday, March 13, 2013
> > 05:14 PM Central Standard Time To: Markus.Isomaki@nokia.com=20
> > ; jmvalin@mozilla.com
> 
> > Cc: MARJOU Xavier OLNC/OLN ;
> rtcweb@ietf.org
> > 
> > Subject: Re: [rtcweb] Agenda time     request for
> > draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> > Dear Markus
> >
> > Thanks for your attempt to help !
> >
> > Of course each Telco can handle this directly with vendors and=20
> > browsers manufacturers at business level. But I don't'think
> this need
> > of interoperability with mobile devices is specific to Orange.
> > I think all mobile operators will have the same issue and
> this is why
> > standardization exist. It's most cost and time efficient to
> have one
> > common way forward for all the industry.
> >
> > Then if the issue is that "conditional MUST/SHOULD are a too=20
> > complicated requirement. We could also live as a compromise with a=20
> > formulation that has already been suggested on the reflector:
> >
> > "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=20
> > maximize the possibility to establish the session without
> the need for
> > audio transcoding" If possible with the addition of This is
> especially
> > the case for AMR, AMR-WB for interoperability with mobile
> devices and
> > G.722 for interoperability with fixed DECT CAT-iq devices
> >
> > Would it have one chance to reach consensus ?
> >
> > I think this Group should at least make one small step so that the=20
> > interoperability issue with mobile terminals be not fully
> ignored in
> > the RTC Web specification considering the huge number of deployed=20
> > devices. At least something must be written on this !
> > G.711 which is the only codec in addition to OPUS for
> interoperability
> > purpose is not a proper answer to this.
> >
> > St=E9phane
> >
> > -----Message d'origine----- De : Markus.Isomaki@nokia.com=20
> > [mailto:Markus.Isomaki@nokia.com] Envoy=E9 : mercredi 13 mars 2013
> > 22:37 =C0 : PROUST Stephane OLNC/OLPS; jmvalin@mozilla.com; MARJOU=20
> > Xavier OLNC/OLN Cc : rtcweb@ietf.org Objet : RE: [rtcweb]
> Agenda time
> > request for draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> > Hi Stephane, Xavier,
> >
> > I understand the intent of your proposal. I'm not sure if
> the IETF is
> > the best venue for you to pursue it, however. Perhaps you
> as a mobile
> > operator should rather set it as a requirement to your
> mobile device
> > platforms that they open up the APIs to AMR and AMR-WB and that at=20
> > least the in-built default browser needs to support it. If
> there are
> > enough operators setting such requirements directly to the
> device and
> > platform vendors, it probably has a bigger impact than an IETF RFC.
> > Getting that support for user-installed additional browsers
> might be
> > more difficult, but most mobile device users stick with the default=20
> > browser anyway.
> >
> > The RTCWEB codec document needs to definitely explain this case and=20
> > the benefits, but the conditional MUSTs or SHOULDs you are
> proposing
> > are perhaps a bit too complicated. Hmm, perhaps we need to do an=20
> > _informational_ RFC as something like "Recommendations for
> WebRTC on
> > Mobile Devices" addressing the codec and perhaps other issues, that=20
> > you could use as a reference in your requirements.
> >
> > Markus
> >
> >
> >> -----Original Message----- From: rtcweb-bounces@ietf.org=20
> >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext=20
> >> stephane.proust@orange.com Sent: 13 March, 2013 21:37 To:
> >> Jean-Marc Valin; MARJOU Xavier OLNC/OLN Cc: rtcweb@ietf.org
> >> Subject: Re: [rtcweb] Agenda time request for
> >> draft-marjou-rtcweb-audio- codecs-for-interop-01
> >>
> >> Hello
> >>
> >> Our understanding is that the reason of the "no consensus" on=20
> >> additional recommended codecs was the additional costs for
> browsers.
> >> The proposal is then to make these "MUST" fully conditional to the=20
> >> case of no (or very reduced) additional costs, when the codecs are=20
> >> already available on the device and when no additional
> license fee is
> >> required
> >>
> >> We could even live with lower level of "requirements" with=20
> >> respectively May and Should (instead of Should and shall) but we=20
> >> think that this proposal is a way to take into account
> both browser
> >> manufacturers concerns on browsers costs and telcos concerns on=20
> >> transcoding costs and some other companies share this view.
> >>
> >> St=E9phane
> >>
> >>
> >>
> >>
> >>
> >>
> >> -----Message d'origine----- De : rtcweb-bounces@ietf.org=20
> >> [mailto:rtcweb-bounces@ietf.org] De la part de Jean-Marc
> Valin Envoy=E9
> >> : mercredi 13 mars 2013 20:24 =C0 : MARJOU Xavier OLNC/OLN Cc :
> >> rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time request for
> >> draft-marjou-rtcweb-audio-codecs-for-interop-01
> >>
> > Hi,
> >
> > I'd really like to understand how the chairs coming to the
> conclusion
> > that there was *no consensus* on recommended codecs can result in a=20
> > draft that includes 3 MUSTs and 1 SHOULD. This draft
> effectively makes
> > 3 new codecs MTI for a range of devices. I understand that it's an=20
> > individual draft and you can write whatever you like in
> there, but it
> > definitely goes against the result of the WG discussion.
> >
> > Cheers,
> >
> > Jean-Marc
> >
> > On 03/13/2013 09:14 AM, Xavier Marjou wrote:
> >>>> Here is a summary of the
> >>>> draft-marjou-rtcweb-audio-codecs-for-interop-00
> presentation that I
> >>>> had prepared for yesterday's session:
> >>>>
> >>>> - The co-authors want to underline that non-WebRTC voice
> endpoints
> >>>> usually use one of the following codecs: AMR, AMR-WB or G.722,=20
> >>>> which will result in massive transcoding when there will be=20
> >>>> communications between WebRTC endpoints and non-WebRTC endpoints.
> >>>>
> >>>> - On one side, transcoding is bad for many reasons
> discussed in the
> >>>> draft (cost issues, intrinsic quality degradation, degraded=20
> >>>> interactivity, fallback from HD to G.711...);
> >>>>
> >>>> - On the other side, it is recognized that implementing
> additional
> >>>> codecs in the browsers can generate additional costs.
> >>>>
> >>>> - In order to reach a compromise, we would like to add
> some text in
> >>>> the WG draft draft-ietf-rtcweb-audio providing
> incentives for the
> >>>> browser to use these three codecs: make them mandatory
> to implement
> >>>> when there is no cost impact on the browser (e.g. if
> codec already
> >>>> installed, paid by the device vendor...).
> >>>>
> >>>> Any opinion on that?
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Xavier
> >>>>
> >>>> PS: I will be ready to present the slides on Thursday if time=20
> >>>> permits it.
> >>>>
> >>>> (c.f.
> >>>> http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf
> >>>>
> >>>>
> )
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie  >>>> > wrote:
> >>>>
> >>>> Magnus and I discussed this this morning, and we
> encourage you to
> >>>> prepare something.  If the discussion of working group last call=20
> >>>> items runs short, we may be able to fit this in at that
> time or at
> >>>> the end of day one if its full agenda his finished.
> This is not a
> >>>> commitment, however, so please try and get discussion on
> the list
> >>>> on the points from the draft you feel need resolution.
> >>>>
> >>>> regards,
> >>>>
> >>>> Ted
> >>>>
> >>>>
> >>>> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)=20
> >>>> > wrote:
> >>>>> Hello,
> >>>>>
> >>>>>
> >>>>>
> >>>>> I would like to request agenda time for:
> >>>>>
> >>>>>
> >>>>>
> >>>>> draft-marjou-rtcweb-audio-codecs-for-interop-01
> >>>>>
> >>>>>
> >>>>>
> >>>>> The document  presents use-cases underlining why WebRTC needs
> >>>> AMR-WB,  AMR
> >>>>> and G.722 as additional relevant voice codecs to satisfactorily=20
> >>>>> ensure interoperability with existing systems.
> >>>>>
> >>>>>
> >>>>>
> >>>>> A 10-minute time slot should be sufficient for presentation and
> >>>> discussion.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Regards
> >>>>>
> >>>>>
> >>>>>
> >>>>> -Espen
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________ rtcweb
> > mailing list
> >>>>> rtcweb@ietf.org =20
> >>>>> https://www.ietf.org/mailman/listinfo/rtcweb
> >>>>>
> >>>> _______________________________________________ rtcweb
> > mailing list
> >>>> rtcweb@ietf.org =20
> >>>> 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
> >>
> >> ___________________________________________________________
> >> ___________________________________________________________ ___
> >>
> >> Ce message et ses pieces jointes peuvent contenir des informations=20
> >> confidentielles ou privilegiees et ne doivent donc pas
> etre diffuses,
> >> exploites ou copies sans autorisation. Si vous avez recu
> ce message
> >> par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> >> que les pieces jointes. Les messages electroniques etant
> susceptibles
> >> d'alteration, France Telecom - Orange decline toute
> responsabilite si
> >> ce message a ete altere, deforme ou falsifie. Merci.
> >>
> >> This message and its attachments may contain confidential or=20
> >> privileged information that may be protected by law; they
> should not
> >> be distributed, used or copied without authorisation. If you have=20
> >> received this email in error, please notify the sender and delete=20
> >> this message and its attachments. As emails may be altered, France=20
> >> Telecom - Orange is not liable for messages that have been
> modified,
> >> changed or falsified. Thank you.
> >>
> >> _______________________________________________ rtcweb
> mailing list
> >> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> ______________________________________________________________________
> > ___________________________________________________
> >
> >  Ce message et ses pieces jointes peuvent contenir des informations=20
> > confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message=20
> > par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> > que les pieces jointes. Les messages electroniques etant
> susceptibles
> > d'alteration, France Telecom - Orange decline toute
> responsabilite si
> > ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or=20
> > privileged information that may be protected by law; they
> should not
> > be distributed, used or copied without authorisation. If you have=20
> > received this email in error, please notify the sender and
> delete this
> > message and its attachments. As emails may be altered,
> France Telecom
> > - Orange is not liable for messages that have been
> modified, changed
> > or falsified. Thank you.
> >
> > _______________________________________________ rtcweb mailing list=20
> > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> ---------------------------------------------------------------------
> >
> >
> This transmission (including any attachments) may contain confidential=20
> information, privileged material (including material protected by the=20
> solicitor-client or other applicable privileges), or constitute=20
> non-public information.
> Any use of this information by anyone other than the intended=20
> recipient is prohibited. If you have received this transmission in=20
> error, please immediately reply to the sender and delete this=20
> information from your system. Use, dissemination, distribution, or=20
> reproduction of this transmission by unintended recipients is not=20
> authorized and may be unlawful.
> >
> >
> ______________________________________________________________________
> > ___________________________________________________
> >
> >  Ce message et ses pieces jointes peuvent contenir des informations=20
> > confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message=20
> > par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> > que les pieces jointes. Les messages electroniques etant
> susceptibles
> > d'alteration, France Telecom - Orange decline toute
> responsabilite si
> > ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or=20
> > privileged information that may be protected by law; they
> should not
> > be distributed, used or copied without authorisation. If you have=20
> > received this email in error, please notify the sender and
> delete this
> > message and its attachments. As emails may be altered,
> France Telecom
> > - Orange is not liable for messages that have been
> modified, changed
> > or falsified. Thank you.
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJRQVgzAAoJEJ6/8sItn9q9fgYH/jcWfhRrvPM1hJ22YcE7eR0N
> OZzP/RvSrUBiIA6kG+6+Hvn5Lp/tXd+LxUDp5L8B3Toce7TBBAYNJP3M2cr8N8It
> SjVvPHtBNKEqhBLbI4FbAouvymNH4utjAWR+MmF9LRySPXZ9nxLN0A13TeUlpZxt
> Jaxr/n9AWwkKOk6BIo1Xztbk26MObiGVLhCE+CPoHaHe29bKblPcphBXC935ymHS
> SuF2DXiAq0iKwZoVOsLe3RIaGg+bjN7N2MXi3Vphr7cOQK+JpdxURDrvmPh7/L8R
> ht1RJt928yl4fEjnKhSKJLd1J+gPBe6vnkSxUp89as03bLirLwN1G2giD3YzfLM=3D
> =3DK56v
> -----END PGP SIGNATURE-----
>
> ______________________________________________________________
> ___________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations=20
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
> exploites ou copies sans autorisation. Si vous avez recu ce message=20
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20
> que les pieces jointes. Les messages electroniques etant susceptibles=20
> d'alteration, France Telecom - Orange decline toute responsabilite si=20
> ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or=20
> privileged information that may be protected by law; they should not=20
> be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and=20
> delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for=20
> messages that have been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> 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
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential=20
> information, privileged material (including material protected by the=20
> solicitor-client or other applicable privileges), or constitute=20
> non-public information.
> Any use of this information by anyone other than the intended=20
> recipient is prohibited. If you have received this transmission in=20
> error, please immediately reply to the sender and delete this=20
> information from your system. Use, dissemination, distribution, or=20
> reproduction of this transmission by unintended recipients is not=20
> authorized and may be unlawful.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou =
copies sans autorisation. Si vous avez recu ce message par erreur, veuillez=
 le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le=
s messages electroniques etant susceptibles d'alteration, France Telecom - =
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law; they should not be distributed, used=
 or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.


From prvs=778627bb81=aallen@blackberry.com  Fri Mar 15 09:08: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 7AA1521F8566 for ; Fri, 15 Mar 2013 09:08:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.661
X-Spam-Level: 
X-Spam-Status: No, score=-3.661 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_00=-2.599, MANGLED_LOAN=2.3, MIME_QP_LONG_LINE=1.396, 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 g3V-QI5YlpOc for ; Fri, 15 Mar 2013 09:08:36 -0700 (PDT)
Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id D1E0C21F84D8 for ; Fri, 15 Mar 2013 09:08:35 -0700 (PDT)
X-AuditID: 0a41282f-b7fa06d000002431-b2-5143478252b8
Received: from XCT102ADS.rim.net (xct102ads.rim.net [10.67.111.43]) by mhs060cnc.rim.net (SBG) with SMTP id CB.45.09265.28743415; Fri, 15 Mar 2013 11:08:35 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT102ADS.rim.net ([fe80::4806:2e1d:2b7c:cfdf%22]) with mapi id 14.02.0328.009; Fri, 15 Mar 2013 11:08:34 -0500
From: Andrew Allen 
To: "stephane.proust@orange.com" , "R.Jesske@telekom.de" , "koen.vos@skype.net" , "espeberg@cisco.com" 
Thread-Topic: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIHAgQ3Oi2P7DjEKDSnUvQoKufpilc9aAgAAGtgCAAH5yAP//tpYYgADR0CCAAFbNYIAAZFUA//+ucTiAAALX3w==
Date: Fri, 15 Mar 2013 16:08:33 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.253]
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOKsWRmVeSWpSXmKPExsXC5Zyvrdvs7hxocHg5q8WXhmSL1p/fmC2a 7nSxWaz9185u0TrjCpvFka1rmR3YPKb83sjqsWTJTyaPlmcn2TxuPZjE5tH2UiGANaqB0SYp saQsODM9T9/OJjEvL78ksSRVISW1ONlWySc1PTFHIaAosywxuVLBJbM4OScxMze1SEkhM8VW yURJoSAnMTk1NzWvxFYpsaAgNS9FyY5LAQPYAJVl5imk5iXnp2TmpdsqeQb761pYmFrqGirZ 6SZ08mTs3+dZsPEZY8Wq7euYGhjv7mXsYuTkkBAwkXi8sBHKFpO4cG89WxcjF4eQwEpGibmL TzCDJIQENjNKHNkOVsQmoCWx//B0JpAiEYEjQPE3u8ESzAIJEv39a4ESHBzCAvESzacKQcIi QOEpP+YwQ9hZEn+nvWEHsVkEVCUW7d7NBGLzCnhIXH64EWwMp4CnxKU5O8FqGAVkJXafvc4E MV5c4taT+UwQhwpILNlznhnCFpV4+fgfK4StKPF373dWiHo9iRtTp7BB2NoSyxa+ZobYJShx cuYTlgmMorOQjJ2FpGUWkpZZSFoWMLKsYhTMzSg2MDNIzkvWK8rM1ctLLdnECEopjhr6Oxjf vrc4xCjAwajEw2vk7BwoxJpYVlyZe4hRgoNZSYT3nT5QiDclsbIqtSg/vqg0J7X4EKMrMCQm MktxJ+cD011eSbyxgQFujpI4b5mmU6CQQDow/WSnphakFsHMYeLgBNnDJSVSDEwiqUWJpSUZ 8aBUF18MTHZSDYwlUvMXrA47c2GLzuFlLT2R0vN31sys3Ht/gbhY3MpV1m5ea3e+fCPVsK38 wAGBlqgJe5daligqX+846/N+seiTswq7ko/FbOLemVpz6tYkHV6/h7MOTnHy2/3OS/cz05Ru +ThTM/XAiw8d9Bdb2l6NXBJ/5eCt3t2Sc5YFNP7suOwRyG5pzz1TiaU4I9FQi7moOBEAM+es KGoDAAA=
Cc: "xavier.marjou@orange.com" , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 15 Mar 2013 16:08:38 -0000

Based on the clarification I just made I propose revised text

"If other audio codecs suitable for use by the application are available to=
 the browser to use it is recommended that they are also included in the off=
er in order to maximize the possibility to establish the session without the=
 need for audio transcoding."


----- Original Message -----
From: Andrew Allen [mailto:aallen@blackberry.com]
Sent: Friday, March 15, 2013 10:58 AM Central Standard Time=0A=
To: stephane.proust@orange.com ; R.Jesske@teleko=
m.de ; koen.vos@skype.net ; espeber=
g@cisco.com 
Cc: rtcweb@ietf.org ; xavier.marjou@orange.com 
Subject: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-code=
cs-for-interop-01


Suitable to me means suitable for the application context i.e if the applica=
tion is conversational real time audio then all audio codecs suitable for co=
nversational real time audio the browser has the ability to use are recommen=
ded to be included in the offer.

I don't agree to mention specific codecs - all codecs that meet the suitabil=
ity for the application apply and we shouldn't give the impression that its=
 more important to include some codecs than others that are available to the=
 browser to use. 


----- Original Message -----
From: stephane.proust@orange.com [mailto:stephane.proust@orange.com]
Sent: Friday, March 15, 2013 10:50 AM Central Standard Time
To: Andrew Allen; R.Jesske@telekom.de ; koen.vos@skype.=
net ; espeberg@cisco.com 
Cc: MARJOU Xavier OLNC/OLN ; rtcweb@ietf.org 
Subject: RE: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-code=
cs-for-interop-01

Hello

As mentioned earlier, this kind of general statement makes sense and would b=
e acceptable for us only if it gives some minimum guidance on what "suitable=
" means. It means: the codecs that are especially important to be considered=
 because their support would solve the interoperability issue for a huge num=
ber of calls and because they can be made available to the browsers on a hig=
h number of devices: 

"If other suitable audio codecs are available to the browser to use it is re=
commended that they are also included in the offer in order to maximize the=
 possibility to establish the session without the need for audio transcoding=
."
This is especially the case for AMR and AMR-WB for interoperability with 3GP=
P mobile devices and G.722 for interoperability with fixed ETSI/DECT CAT-iq=
 devices


Stephane Proust



-----Message d'origine-----
De=A0: Andrew Allen [mailto:aallen@blackberry.com] 
Envoy=E9=A0: vendredi 15 mars 2013 15:56
=C0=A0: R.Jesske@telekom.de; koen.vos@skype.net; espeberg@cisco.com; PROUST=
 Stephane OLNC/OLPS
Cc=A0: MARJOU Xavier OLNC/OLN; rtcweb@ietf.org
Objet=A0: RE: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01

Roland

I have proposed that we add the following text to address the interoperabili=
ty concerns

"If other suitable audio codecs are available to the browser to use it is re=
commended that they are also included in the offer in order to maximize the=
 possibility to establish the session without the need for audio transcoding=
."

The MTI Audio Codecs are defined to ensure a basic level of interoperability=
 and will need to be always supported for that reason. Support for additiona=
l audio codecs is an implementation and business case decision and the addit=
ional audio codecs that it makes sense to support will change over time (as=
 codecs become obsolete and new ones are developed and deployed. So addition=
al audio codecs should not be specified in the RTCweb RFCs.

Andrew

-----Original Message-----
From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]
Sent: Friday, March 15, 2013 5:45 AM
To: Andrew Allen; koen.vos@skype.net; espeberg@cisco.com; stephane.proust@or=
ange.com
Cc: xavier.marjou@orange.com; rtcweb@ietf.org
Subject: AW: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-code=
cs-for-interop-01

Hi Andrew,
but where will you start and where will you end.
The codec discussion appears now so why not try to solve this now?
And one proposal is to use these codecs and I fully support it.

Roland

> -----Urspr=FCngliche Nachricht-----
> Von: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] Im 
> Auftrag von Andrew Allen
> Gesendet: Donnerstag, 14. M=E4rz 2013 22:10
> An: koen.vos@skype.net; espeberg@cisco.com; stephane.proust@orange.com
> Cc: xavier.marjou@orange.com; rtcweb@ietf.org
> Betreff: Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
>
> Koen is right that there are many more obstacles to RTCweb and legacy 
> network interop than just a common codec. First there will need to be 
> RTCweb signaling gateways to interface between the RTCweb signaling 
> and the legacy networks (SIP,
> H.323 etc) and there will need to be in place mechanisms for peering, 
> federation and address resolution between networks as well as service 
> agreements in place between the players.
>
> Until those are resolved supporting codecs used in those networks is 
> pointless.
>
> Andrew
>
> ----- Original Message -----
> From: Koen Vos [mailto:koen.vos@skype.net]
> Sent: Thursday, March 14, 2013 03:32 PM Central Standard Time
> To: Espen Berger (espeberg) ; 
> stephane.proust@orange.com 
> Cc: rtcweb@ietf.org ; MARJOU Xavier OLNC/OLN 
> 
> Subject: Re: [rtcweb] Agenda time     request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> > It's interop with billions of mobile phones and with fixed
> terminals in legacy telephony services.
>
> The problem is that WebRTC and legacy services live in separate
> networks: the open Web vs proprietary Telco networks.
>
> WebRTC connecting to a Telco network would have to go through a 
> Gateway.  The PSTN termination providers who run these Gateways 
> support G.711, G.729 and perhaps some other  codecs like iLBC.  They 
> do not, however, support the codecs you are advocating for.
>
> The lack of support for Transcoding-Free Operation by Telcos to the 
> rest of the world has been hurting interop voice quality for a long 
> time, but unfortunately we can't fix that here at the IETF.
>
> We can fit our cars with your costly railroad wheels, but you still 
> wouldn't let us on your tracks.
>
> koen.
>
>
> -----Original Message-----
> From: rtcweb-bounces@ietf.org
> [mailto:rtcweb-bounces@ietf.org] On Behalf Of 
> stephane.proust@orange.com
> Sent: 14. mars 2013 13:36
> To: Jean-Marc Valin
> Cc: rtcweb@ietf.org; MARJOU Xavier OLNC/OLN
> Subject: Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> Hello
>
> The short list is aligned to what is specified in 3GPP
> (mobile) and CAT-iq (fixed). Check the related service specifications!
> The short list (AMR, AMR-WB, G.722) is a minimal subset of codecs to 
> minimize interop issues and transcoding costs for telco services.
> It's not a question of what's the favourite codec for a given 
> application. It's interop with billions of mobile phones and with 
> fixed terminals in legacy telephony services.
>
> St=E9phane
>
> -----Message d'origine-----
> De : Jean-Marc Valin [mailto:jmvalin@mozilla.com] Envoy=E9 :
> jeudi 14 mars 2013 05:55 =C0 : PROUST Stephane OLNC/OLPS Cc :
> Andrew Allen; Markus.Isomaki@nokia.com; MARJOU Xavier OLNC/OLN; 
> rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/13/2013 06:48 PM, stephane.proust@orange.com wrote:
> > The reason is simply that AMR and AMR-WB are supported in
> billions of
> > devices !
>
> Just curious, why exclude from the list other codecs with similar huge 
> deployment? I can think of at least:
> - - GSM-FR (mobile)
> - - Speex (Flash)
> - - G.729 (PSTN gateways)
> - - iLBC (PSTN gateways)
> - - G.726 (DECT)
> - - SILK (original non-Opus version in Skype)
>
> (sorry, if I missed someone's favorite codec in this list)
>
> It's not at all clear to me what's so special that makes AMR, AMR-WB 
> and G.722 different from the other codecs in the list above. Not that 
> I insist on shipping G.729 :-)
>
> Personally, I'd favor a draft that included a lot more codecs, 
> describing for each one the benefits of supporting it. Implementers 
> could then choose which of these they care about for their particular 
> situation.
>
> Cheers,
>
>         Jean-Marc
>
> > St=E9phane
> >
> >
> > -----Message d'origine----- De : Andrew Allen 
> > [mailto:aallen@blackberry.com] Envoy=E9 : mercredi 13 mars 2013
> > 23:41 =C0 : PROUST Stephane OLNC/OLPS; Markus.Isomaki@nokia.com; 
> > jmvalin@mozilla.com Cc : MARJOU Xavier OLNC/OLN;
> rtcweb@ietf.org Objet
> > : Re: [rtcweb] Agenda time request for
> > draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> >
> > No this wouldn't be acceptable to me.
> >
> > I don't see a reason to push a particular set of Codecs
> over any other
> > set of codecs supported on the device. If the device supports the 
> > codecs and they are available to the browser then we should
> recommend
> > that they be offered in the negotiation.
> >
> > The marjou draft can advertise the merits and reasons why they are 
> > good codecs to support.
> >
> >
> > ----- Original Message ----- From: stephane.proust@orange.com 
> > [mailto:stephane.proust@orange.com] Sent: Wednesday, March 13, 2013
> > 05:14 PM Central Standard Time To: Markus.Isomaki@nokia.com 
> > ; jmvalin@mozilla.com
> 
> > Cc: MARJOU Xavier OLNC/OLN ;
> rtcweb@ietf.org
> > 
> > Subject: Re: [rtcweb] Agenda time     request for
> > draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> > Dear Markus
> >
> > Thanks for your attempt to help !
> >
> > Of course each Telco can handle this directly with vendors and 
> > browsers manufacturers at business level. But I don't'think
> this need
> > of interoperability with mobile devices is specific to Orange.
> > I think all mobile operators will have the same issue and
> this is why
> > standardization exist. It's most cost and time efficient to
> have one
> > common way forward for all the industry.
> >
> > Then if the issue is that "conditional MUST/SHOULD are a too 
> > complicated requirement. We could also live as a compromise with a 
> > formulation that has already been suggested on the reflector:
> >
> > "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" If possible with the addition of This is
> especially
> > the case for AMR, AMR-WB for interoperability with mobile
> devices and
> > G.722 for interoperability with fixed DECT CAT-iq devices
> >
> > Would it have one chance to reach consensus ?
> >
> > I think this Group should at least make one small step so that the 
> > interoperability issue with mobile terminals be not fully
> ignored in
> > the RTC Web specification considering the huge number of deployed 
> > devices. At least something must be written on this !
> > G.711 which is the only codec in addition to OPUS for
> interoperability
> > purpose is not a proper answer to this.
> >
> > St=E9phane
> >
> > -----Message d'origine----- De : Markus.Isomaki@nokia.com 
> > [mailto:Markus.Isomaki@nokia.com] Envoy=E9 : mercredi 13 mars 2013
> > 22:37 =C0 : PROUST Stephane OLNC/OLPS; jmvalin@mozilla.com; MARJOU 
> > Xavier OLNC/OLN Cc : rtcweb@ietf.org Objet : RE: [rtcweb]
> Agenda time
> > request for draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> > Hi Stephane, Xavier,
> >
> > I understand the intent of your proposal. I'm not sure if
> the IETF is
> > the best venue for you to pursue it, however. Perhaps you
> as a mobile
> > operator should rather set it as a requirement to your
> mobile device
> > platforms that they open up the APIs to AMR and AMR-WB and that at 
> > least the in-built default browser needs to support it. If
> there are
> > enough operators setting such requirements directly to the
> device and
> > platform vendors, it probably has a bigger impact than an IETF RFC.
> > Getting that support for user-installed additional browsers
> might be
> > more difficult, but most mobile device users stick with the default 
> > browser anyway.
> >
> > The RTCWEB codec document needs to definitely explain this case and 
> > the benefits, but the conditional MUSTs or SHOULDs you are
> proposing
> > are perhaps a bit too complicated. Hmm, perhaps we need to do an 
> > _informational_ RFC as something like "Recommendations for
> WebRTC on
> > Mobile Devices" addressing the codec and perhaps other issues, that 
> > you could use as a reference in your requirements.
> >
> > Markus
> >
> >
> >> -----Original Message----- From: rtcweb-bounces@ietf.org 
> >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext 
> >> stephane.proust@orange.com Sent: 13 March, 2013 21:37 To:
> >> Jean-Marc Valin; MARJOU Xavier OLNC/OLN Cc: rtcweb@ietf.org
> >> Subject: Re: [rtcweb] Agenda time request for
> >> draft-marjou-rtcweb-audio- codecs-for-interop-01
> >>
> >> Hello
> >>
> >> Our understanding is that the reason of the "no consensus" on 
> >> additional recommended codecs was the additional costs for
> browsers.
> >> The proposal is then to make these "MUST" fully conditional to the 
> >> case of no (or very reduced) additional costs, when the codecs are 
> >> already available on the device and when no additional
> license fee is
> >> required
> >>
> >> We could even live with lower level of "requirements" with 
> >> respectively May and Should (instead of Should and shall) but we 
> >> think that this proposal is a way to take into account
> both browser
> >> manufacturers concerns on browsers costs and telcos concerns on 
> >> transcoding costs and some other companies share this view.
> >>
> >> St=E9phane
> >>
> >>
> >>
> >>
> >>
> >>
> >> -----Message d'origine----- De : rtcweb-bounces@ietf.org 
> >> [mailto:rtcweb-bounces@ietf.org] De la part de Jean-Marc
> Valin Envoy=E9
> >> : mercredi 13 mars 2013 20:24 =C0 : MARJOU Xavier OLNC/OLN Cc :
> >> rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time request for
> >> draft-marjou-rtcweb-audio-codecs-for-interop-01
> >>
> > Hi,
> >
> > I'd really like to understand how the chairs coming to the
> conclusion
> > that there was *no consensus* on recommended codecs can result in a 
> > draft that includes 3 MUSTs and 1 SHOULD. This draft
> effectively makes
> > 3 new codecs MTI for a range of devices. I understand that it's an 
> > individual draft and you can write whatever you like in
> there, but it
> > definitely goes against the result of the WG discussion.
> >
> > Cheers,
> >
> > Jean-Marc
> >
> > On 03/13/2013 09:14 AM, Xavier Marjou wrote:
> >>>> Here is a summary of the
> >>>> draft-marjou-rtcweb-audio-codecs-for-interop-00
> presentation that I
> >>>> had prepared for yesterday's session:
> >>>>
> >>>> - The co-authors want to underline that non-WebRTC voice
> endpoints
> >>>> usually use one of the following codecs: AMR, AMR-WB or G.722, 
> >>>> which will result in massive transcoding when there will be 
> >>>> communications between WebRTC endpoints and non-WebRTC endpoints.
> >>>>
> >>>> - On one side, transcoding is bad for many reasons
> discussed in the
> >>>> draft (cost issues, intrinsic quality degradation, degraded 
> >>>> interactivity, fallback from HD to G.711...);
> >>>>
> >>>> - On the other side, it is recognized that implementing
> additional
> >>>> codecs in the browsers can generate additional costs.
> >>>>
> >>>> - In order to reach a compromise, we would like to add
> some text in
> >>>> the WG draft draft-ietf-rtcweb-audio providing
> incentives for the
> >>>> browser to use these three codecs: make them mandatory
> to implement
> >>>> when there is no cost impact on the browser (e.g. if
> codec already
> >>>> installed, paid by the device vendor...).
> >>>>
> >>>> Any opinion on that?
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Xavier
> >>>>
> >>>> PS: I will be ready to present the slides on Thursday if time 
> >>>> permits it.
> >>>>
> >>>> (c.f.
> >>>> http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf
> >>>>
> >>>>
> )
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie  >>>> > wrote:
> >>>>
> >>>> Magnus and I discussed this this morning, and we
> encourage you to
> >>>> prepare something.  If the discussion of working group last call 
> >>>> items runs short, we may be able to fit this in at that
> time or at
> >>>> the end of day one if its full agenda his finished.
> This is not a
> >>>> commitment, however, so please try and get discussion on
> the list
> >>>> on the points from the draft you feel need resolution.
> >>>>
> >>>> regards,
> >>>>
> >>>> Ted
> >>>>
> >>>>
> >>>> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg) 
> >>>> > wrote:
> >>>>> Hello,
> >>>>>
> >>>>>
> >>>>>
> >>>>> I would like to request agenda time for:
> >>>>>
> >>>>>
> >>>>>
> >>>>> draft-marjou-rtcweb-audio-codecs-for-interop-01
> >>>>>
> >>>>>
> >>>>>
> >>>>> The document  presents use-cases underlining why WebRTC needs
> >>>> AMR-WB,  AMR
> >>>>> and G.722 as additional relevant voice codecs to satisfactorily 
> >>>>> ensure interoperability with existing systems.
> >>>>>
> >>>>>
> >>>>>
> >>>>> A 10-minute time slot should be sufficient for presentation and
> >>>> discussion.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Regards
> >>>>>
> >>>>>
> >>>>>
> >>>>> -Espen
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________ 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
> >>
> >> ___________________________________________________________
> >> ___________________________________________________________ ___
> >>
> >> Ce message et ses pieces jointes peuvent contenir des informations 
> >> confidentielles ou privilegiees et ne doivent donc pas
> etre diffuses,
> >> exploites ou copies sans autorisation. Si vous avez recu
> ce message
> >> par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> >> que les pieces jointes. Les messages electroniques etant
> susceptibles
> >> d'alteration, France Telecom - Orange decline toute
> responsabilite si
> >> ce message a ete altere, deforme ou falsifie. Merci.
> >>
> >> This message and its attachments may contain confidential or 
> >> privileged information that may be protected by law; they
> should not
> >> be distributed, used or copied without authorisation. If you have 
> >> received this email in error, please notify the sender and delete 
> >> this message and its attachments. As emails may be altered, France 
> >> Telecom - Orange is not liable for messages that have been
> modified,
> >> changed or falsified. Thank you.
> >>
> >> _______________________________________________ rtcweb
> mailing list
> >> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> ______________________________________________________________________
> > ___________________________________________________
> >
> >  Ce message et ses pieces jointes peuvent contenir des informations 
> > confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message 
> > par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> > que les pieces jointes. Les messages electroniques etant
> susceptibles
> > d'alteration, France Telecom - Orange decline toute
> responsabilite si
> > ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or 
> > privileged information that may be protected by law; they
> should not
> > be distributed, used or copied without authorisation. If you have 
> > received this email in error, please notify the sender and
> delete this
> > message and its attachments. As emails may be altered,
> France Telecom
> > - Orange is not liable for messages that have been
> modified, changed
> > or falsified. Thank you.
> >
> > _______________________________________________ rtcweb mailing list 
> > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> ---------------------------------------------------------------------
> >
> >
> This transmission (including any attachments) may contain confidential 
> information, privileged material (including material protected by the 
> solicitor-client or other applicable privileges), or constitute 
> non-public information.
> Any use of this information by anyone other than the intended 
> recipient is prohibited. If you have received this transmission in 
> error, please immediately reply to the sender and delete this 
> information from your system. Use, dissemination, distribution, or 
> reproduction of this transmission by unintended recipients is not 
> authorized and may be unlawful.
> >
> >
> ______________________________________________________________________
> > ___________________________________________________
> >
> >  Ce message et ses pieces jointes peuvent contenir des informations 
> > confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message 
> > par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> > que les pieces jointes. Les messages electroniques etant
> susceptibles
> > d'alteration, France Telecom - Orange decline toute
> responsabilite si
> > ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or 
> > privileged information that may be protected by law; they
> should not
> > be distributed, used or copied without authorisation. If you have 
> > received this email in error, please notify the sender and
> delete this
> > message and its attachments. As emails may be altered,
> France Telecom
> > - Orange is not liable for messages that have been
> modified, changed
> > or falsified. Thank you.
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJRQVgzAAoJEJ6/8sItn9q9fgYH/jcWfhRrvPM1hJ22YcE7eR0N
> OZzP/RvSrUBiIA6kG+6+Hvn5Lp/tXd+LxUDp5L8B3Toce7TBBAYNJP3M2cr8N8It
> SjVvPHtBNKEqhBLbI4FbAouvymNH4utjAWR+MmF9LRySPXZ9nxLN0A13TeUlpZxt
> Jaxr/n9AWwkKOk6BIo1Xztbk26MObiGVLhCE+CPoHaHe29bKblPcphBXC935ymHS
> SuF2DXiAq0iKwZoVOsLe3RIaGg+bjN7N2MXi3Vphr7cOQK+JpdxURDrvmPh7/L8R
> ht1RJt928yl4fEjnKhSKJLd1J+gPBe6vnkSxUp89as03bLirLwN1G2giD3YzfLM=3D
> =3DK56v
> -----END PGP SIGNATURE-----
>
> ______________________________________________________________
> ___________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi 
> que les pieces jointes. Les messages electroniques etant susceptibles 
> d'alteration, France Telecom - Orange decline toute responsabilite si 
> ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not 
> be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and 
> delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for 
> messages that have been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> 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
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential 
> information, privileged material (including material protected by the 
> solicitor-client or other applicable privileges), or constitute 
> non-public information.
> Any use of this information by anyone other than the intended 
> recipient is prohibited. If you have received this transmission in 
> error, please immediately reply to the sender and delete this 
> information from your system. Use, dissemination, distribution, or 
> reproduction of this transmission by unintended recipients is not 
> authorized and may be unlawful.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

____________________________________________________________________________=
_____________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages ele=
ctroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete alt=
ere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delet=
e this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages=
 that have been modified, changed or falsified.
Thank you.


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From Kalyani.Bogineni@VerizonWireless.com  Fri Mar 15 09:49: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 E3E7721F8431 for ; Fri, 15 Mar 2013 09:48:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.299
X-Spam-Level: 
X-Spam-Status: No, score=-100.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_LOAN=2.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 D5448qdNn4Ht for ; Fri, 15 Mar 2013 09:48:57 -0700 (PDT)
Received: from vanguard.verizonwireless.com (vanguard.verizonwireless.com [162.115.35.70]) by ietfa.amsl.com (Postfix) with ESMTP id 59A9421F841D for ; Fri, 15 Mar 2013 09:48:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizonwireless.com; i=@verizonwireless.com; l=0; q=dns/txt; s=prodmail; t=1363366135; x=1394902135; h=from:to:cc:date:subject:references:in-reply-to: content-transfer-encoding:mime-version; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=HlMCkXcQLgtJLDFmaK5g3MGhyev2n8KJLgIp3m6wFnAGbJC62dXC7N0g FVuOY3hJ4+ZjwtOzu1Ks/ZpdDXeh4BNqMOPV1rxXRx0TSpu7k8uH/EjnO 7PXkGtGdaF27kTyWVPVcTVxsytqw2PYEwYZt3rVWPwJEB3BFINIvBXFa3 g=;
Received: from ohdub02exhub04.uswin.ad.vzwcorp.com ([10.97.42.166]) by vanguard.verizonwireless.com with ESMTP; 15 Mar 2013 09:46:35 -0700
Received: from OHDUB02EXCV33.uswin.ad.vzwcorp.com ([10.97.42.179]) by OHDUB02EXHUB04.uswin.ad.vzwcorp.com ([10.97.42.166]) with mapi; Fri, 15 Mar 2013 12:46:34 -0400
From: "Bogineni, Kalyani" 
To: 'Andrew Allen' , "stephane.proust@orange.com" , "R.Jesske@telekom.de" ,  "koen.vos@skype.net" , "espeberg@cisco.com" 
Date: Fri, 15 Mar 2013 12:46:34 -0400
Thread-Topic: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIHAgQ3Oi2P7DjEKDSnUvQoKufpilc9aAgAAGtgCAAH5yAP//tpYYgADR0CCAAFbNYIAAZFUA//+ucTiAAALX34AACgxg
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: <20130315164854.59A9421F841D@ietfa.amsl.com>
Cc: "rtcweb@ietf.org" , "xavier.marjou@orange.com" 
Subject: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 15 Mar 2013 16:49:01 -0000

Here is a slight variation with an example for clarifying what 'suitable' m=
eans.


"If other audio codecs suitable for use by the application are available to=
 the browser (e.g. AMR/AMR-WB for 3GPP devices) to use it is recommended th=
at 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

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 Andrew Allen
Sent: Friday, March 15, 2013 12:09 PM
To: stephane.proust@orange.com; R.Jesske@telekom.de; koen.vos@skype.net; es=
peberg@cisco.com
Cc: xavier.marjou@orange.com; rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01


Based on the clarification I just made I propose revised text

"If other audio codecs suitable for use by the application are available to=
 the browser to use it is recommended that they are also included in the of=
fer in order to maximize the possibility to establish the session without t=
he need for audio transcoding."


----- Original Message -----
From: Andrew Allen [mailto:aallen@blackberry.com]
Sent: Friday, March 15, 2013 10:58 AM Central Standard Time
To: stephane.proust@orange.com ; R.Jesske@telek=
om.de ; koen.vos@skype.net ; espeb=
erg@cisco.com 
Cc: rtcweb@ietf.org ; xavier.marjou@orange.com 
Subject: Re: [rtcweb] Agenda time       request for draft-marjou-rtcweb-aud=
io-codecs-for-interop-01


Suitable to me means suitable for the application context i.e if the applic=
ation is conversational real time audio then all audio codecs suitable for =
conversational real time audio the browser has the ability to use are recom=
mended to be included in the offer.

I don't agree to mention specific codecs - all codecs that meet the suitabi=
lity for the application apply and we shouldn't give the impression that it=
s more important to include some codecs than others that are available to t=
he browser to use.


----- Original Message -----
From: stephane.proust@orange.com [mailto:stephane.proust@orange.com]
Sent: Friday, March 15, 2013 10:50 AM Central Standard Time
To: Andrew Allen; R.Jesske@telekom.de ; koen.vos@skype=
.net ; espeberg@cisco.com 
Cc: MARJOU Xavier OLNC/OLN ; rtcweb@ietf.org 
Subject: RE: [rtcweb] Agenda time       request for draft-marjou-rtcweb-aud=
io-codecs-for-interop-01

Hello

As mentioned earlier, this kind of general statement makes sense and would =
be acceptable for us only if it gives some minimum guidance on what "suitab=
le" means. It means: the codecs that are especially important to be conside=
red because their support would solve the interoperability issue for a huge=
 number of calls and because they can be made available to the browsers on =
a high number of devices:

"If other suitable audio codecs are available to the browser to use it is r=
ecommended that they are also included in the offer in order to maximize th=
e possibility to establish the session without the need for audio transcodi=
ng."
This is especially the case for AMR and AMR-WB for interoperability with 3G=
PP mobile devices and G.722 for interoperability with fixed ETSI/DECT CAT-i=
q devices


Stephane Proust



-----Message d'origine-----
De : Andrew Allen [mailto:aallen@blackberry.com] Envoy=E9 : vendredi 15 mar=
s 2013 15:56 =C0 : R.Jesske@telekom.de; koen.vos@skype.net; espeberg@cisco.=
com; PROUST Stephane OLNC/OLPS Cc : MARJOU Xavier OLNC/OLN; rtcweb@ietf.org=
 Objet : RE: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01

Roland

I have proposed that we add the following text to address the interoperabil=
ity concerns

"If other suitable audio codecs are available to the browser to use it is r=
ecommended that they are also included in the offer in order to maximize th=
e possibility to establish the session without the need for audio transcodi=
ng."

The MTI Audio Codecs are defined to ensure a basic level of interoperabilit=
y and will need to be always supported for that reason. Support for additio=
nal audio codecs is an implementation and business case decision and the ad=
ditional audio codecs that it makes sense to support will change over time =
(as codecs become obsolete and new ones are developed and deployed. So addi=
tional audio codecs should not be specified in the RTCweb RFCs.

Andrew

-----Original Message-----
From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]
Sent: Friday, March 15, 2013 5:45 AM
To: Andrew Allen; koen.vos@skype.net; espeberg@cisco.com; stephane.proust@o=
range.com
Cc: xavier.marjou@orange.com; rtcweb@ietf.org
Subject: AW: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01

Hi Andrew,
but where will you start and where will you end.
The codec discussion appears now so why not try to solve this now?
And one proposal is to use these codecs and I fully support it.

Roland

> -----Urspr=FCngliche Nachricht-----
> Von: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] Im
> Auftrag von Andrew Allen
> Gesendet: Donnerstag, 14. M=E4rz 2013 22:10
> An: koen.vos@skype.net; espeberg@cisco.com; stephane.proust@orange.com
> Cc: xavier.marjou@orange.com; rtcweb@ietf.org
> Betreff: Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
>
> Koen is right that there are many more obstacles to RTCweb and legacy
> network interop than just a common codec. First there will need to be
> RTCweb signaling gateways to interface between the RTCweb signaling
> and the legacy networks (SIP,
> H.323 etc) and there will need to be in place mechanisms for peering,
> federation and address resolution between networks as well as service
> agreements in place between the players.
>
> Until those are resolved supporting codecs used in those networks is
> pointless.
>
> Andrew
>
> ----- Original Message -----
> From: Koen Vos [mailto:koen.vos@skype.net]
> Sent: Thursday, March 14, 2013 03:32 PM Central Standard Time
> To: Espen Berger (espeberg) ;
> stephane.proust@orange.com 
> Cc: rtcweb@ietf.org ; MARJOU Xavier OLNC/OLN
> 
> Subject: Re: [rtcweb] Agenda time     request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> > It's interop with billions of mobile phones and with fixed
> terminals in legacy telephony services.
>
> The problem is that WebRTC and legacy services live in separate
> networks: the open Web vs proprietary Telco networks.
>
> WebRTC connecting to a Telco network would have to go through a
> Gateway.  The PSTN termination providers who run these Gateways
> support G.711, G.729 and perhaps some other  codecs like iLBC.  They
> do not, however, support the codecs you are advocating for.
>
> The lack of support for Transcoding-Free Operation by Telcos to the
> rest of the world has been hurting interop voice quality for a long
> time, but unfortunately we can't fix that here at the IETF.
>
> We can fit our cars with your costly railroad wheels, but you still
> wouldn't let us on your tracks.
>
> koen.
>
>
> -----Original Message-----
> From: rtcweb-bounces@ietf.org
> [mailto:rtcweb-bounces@ietf.org] On Behalf Of
> stephane.proust@orange.com
> Sent: 14. mars 2013 13:36
> To: Jean-Marc Valin
> Cc: rtcweb@ietf.org; MARJOU Xavier OLNC/OLN
> Subject: Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> Hello
>
> The short list is aligned to what is specified in 3GPP
> (mobile) and CAT-iq (fixed). Check the related service specifications!
> The short list (AMR, AMR-WB, G.722) is a minimal subset of codecs to
> minimize interop issues and transcoding costs for telco services.
> It's not a question of what's the favourite codec for a given
> application. It's interop with billions of mobile phones and with
> fixed terminals in legacy telephony services.
>
> St=E9phane
>
> -----Message d'origine-----
> De : Jean-Marc Valin [mailto:jmvalin@mozilla.com] Envoy=E9 :
> jeudi 14 mars 2013 05:55 =C0 : PROUST Stephane OLNC/OLPS Cc :
> Andrew Allen; Markus.Isomaki@nokia.com; MARJOU Xavier OLNC/OLN;
> rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/13/2013 06:48 PM, stephane.proust@orange.com wrote:
> > The reason is simply that AMR and AMR-WB are supported in
> billions of
> > devices !
>
> Just curious, why exclude from the list other codecs with similar huge
> deployment? I can think of at least:
> - - GSM-FR (mobile)
> - - Speex (Flash)
> - - G.729 (PSTN gateways)
> - - iLBC (PSTN gateways)
> - - G.726 (DECT)
> - - SILK (original non-Opus version in Skype)
>
> (sorry, if I missed someone's favorite codec in this list)
>
> It's not at all clear to me what's so special that makes AMR, AMR-WB
> and G.722 different from the other codecs in the list above. Not that
> I insist on shipping G.729 :-)
>
> Personally, I'd favor a draft that included a lot more codecs,
> describing for each one the benefits of supporting it. Implementers
> could then choose which of these they care about for their particular
> situation.
>
> Cheers,
>
>         Jean-Marc
>
> > St=E9phane
> >
> >
> > -----Message d'origine----- De : Andrew Allen
> > [mailto:aallen@blackberry.com] Envoy=E9 : mercredi 13 mars 2013
> > 23:41 =C0 : PROUST Stephane OLNC/OLPS; Markus.Isomaki@nokia.com;
> > jmvalin@mozilla.com Cc : MARJOU Xavier OLNC/OLN;
> rtcweb@ietf.org Objet
> > : Re: [rtcweb] Agenda time request for
> > draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> >
> > No this wouldn't be acceptable to me.
> >
> > I don't see a reason to push a particular set of Codecs
> over any other
> > set of codecs supported on the device. If the device supports the
> > codecs and they are available to the browser then we should
> recommend
> > that they be offered in the negotiation.
> >
> > The marjou draft can advertise the merits and reasons why they are
> > good codecs to support.
> >
> >
> > ----- Original Message ----- From: stephane.proust@orange.com
> > [mailto:stephane.proust@orange.com] Sent: Wednesday, March 13, 2013
> > 05:14 PM Central Standard Time To: Markus.Isomaki@nokia.com
> > ; jmvalin@mozilla.com
> 
> > Cc: MARJOU Xavier OLNC/OLN ;
> rtcweb@ietf.org
> > 
> > Subject: Re: [rtcweb] Agenda time     request for
> > draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> > Dear Markus
> >
> > Thanks for your attempt to help !
> >
> > Of course each Telco can handle this directly with vendors and
> > browsers manufacturers at business level. But I don't'think
> this need
> > of interoperability with mobile devices is specific to Orange.
> > I think all mobile operators will have the same issue and
> this is why
> > standardization exist. It's most cost and time efficient to
> have one
> > common way forward for all the industry.
> >
> > Then if the issue is that "conditional MUST/SHOULD are a too
> > complicated requirement. We could also live as a compromise with a
> > formulation that has already been suggested on the reflector:
> >
> > "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" If possible with the addition of This is
> especially
> > the case for AMR, AMR-WB for interoperability with mobile
> devices and
> > G.722 for interoperability with fixed DECT CAT-iq devices
> >
> > Would it have one chance to reach consensus ?
> >
> > I think this Group should at least make one small step so that the
> > interoperability issue with mobile terminals be not fully
> ignored in
> > the RTC Web specification considering the huge number of deployed
> > devices. At least something must be written on this !
> > G.711 which is the only codec in addition to OPUS for
> interoperability
> > purpose is not a proper answer to this.
> >
> > St=E9phane
> >
> > -----Message d'origine----- De : Markus.Isomaki@nokia.com
> > [mailto:Markus.Isomaki@nokia.com] Envoy=E9 : mercredi 13 mars 2013
> > 22:37 =C0 : PROUST Stephane OLNC/OLPS; jmvalin@mozilla.com; MARJOU
> > Xavier OLNC/OLN Cc : rtcweb@ietf.org Objet : RE: [rtcweb]
> Agenda time
> > request for draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> > Hi Stephane, Xavier,
> >
> > I understand the intent of your proposal. I'm not sure if
> the IETF is
> > the best venue for you to pursue it, however. Perhaps you
> as a mobile
> > operator should rather set it as a requirement to your
> mobile device
> > platforms that they open up the APIs to AMR and AMR-WB and that at
> > least the in-built default browser needs to support it. If
> there are
> > enough operators setting such requirements directly to the
> device and
> > platform vendors, it probably has a bigger impact than an IETF RFC.
> > Getting that support for user-installed additional browsers
> might be
> > more difficult, but most mobile device users stick with the default
> > browser anyway.
> >
> > The RTCWEB codec document needs to definitely explain this case and
> > the benefits, but the conditional MUSTs or SHOULDs you are
> proposing
> > are perhaps a bit too complicated. Hmm, perhaps we need to do an
> > _informational_ RFC as something like "Recommendations for
> WebRTC on
> > Mobile Devices" addressing the codec and perhaps other issues, that
> > you could use as a reference in your requirements.
> >
> > Markus
> >
> >
> >> -----Original Message----- From: rtcweb-bounces@ietf.org
> >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext
> >> stephane.proust@orange.com Sent: 13 March, 2013 21:37 To:
> >> Jean-Marc Valin; MARJOU Xavier OLNC/OLN Cc: rtcweb@ietf.org
> >> Subject: Re: [rtcweb] Agenda time request for
> >> draft-marjou-rtcweb-audio- codecs-for-interop-01
> >>
> >> Hello
> >>
> >> Our understanding is that the reason of the "no consensus" on
> >> additional recommended codecs was the additional costs for
> browsers.
> >> The proposal is then to make these "MUST" fully conditional to the
> >> case of no (or very reduced) additional costs, when the codecs are
> >> already available on the device and when no additional
> license fee is
> >> required
> >>
> >> We could even live with lower level of "requirements" with
> >> respectively May and Should (instead of Should and shall) but we
> >> think that this proposal is a way to take into account
> both browser
> >> manufacturers concerns on browsers costs and telcos concerns on
> >> transcoding costs and some other companies share this view.
> >>
> >> St=E9phane
> >>
> >>
> >>
> >>
> >>
> >>
> >> -----Message d'origine----- De : rtcweb-bounces@ietf.org
> >> [mailto:rtcweb-bounces@ietf.org] De la part de Jean-Marc
> Valin Envoy=E9
> >> : mercredi 13 mars 2013 20:24 =C0 : MARJOU Xavier OLNC/OLN Cc :
> >> rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time request for
> >> draft-marjou-rtcweb-audio-codecs-for-interop-01
> >>
> > Hi,
> >
> > I'd really like to understand how the chairs coming to the
> conclusion
> > that there was *no consensus* on recommended codecs can result in a
> > draft that includes 3 MUSTs and 1 SHOULD. This draft
> effectively makes
> > 3 new codecs MTI for a range of devices. I understand that it's an
> > individual draft and you can write whatever you like in
> there, but it
> > definitely goes against the result of the WG discussion.
> >
> > Cheers,
> >
> > Jean-Marc
> >
> > On 03/13/2013 09:14 AM, Xavier Marjou wrote:
> >>>> Here is a summary of the
> >>>> draft-marjou-rtcweb-audio-codecs-for-interop-00
> presentation that I
> >>>> had prepared for yesterday's session:
> >>>>
> >>>> - The co-authors want to underline that non-WebRTC voice
> endpoints
> >>>> usually use one of the following codecs: AMR, AMR-WB or G.722,
> >>>> which will result in massive transcoding when there will be
> >>>> communications between WebRTC endpoints and non-WebRTC endpoints.
> >>>>
> >>>> - On one side, transcoding is bad for many reasons
> discussed in the
> >>>> draft (cost issues, intrinsic quality degradation, degraded
> >>>> interactivity, fallback from HD to G.711...);
> >>>>
> >>>> - On the other side, it is recognized that implementing
> additional
> >>>> codecs in the browsers can generate additional costs.
> >>>>
> >>>> - In order to reach a compromise, we would like to add
> some text in
> >>>> the WG draft draft-ietf-rtcweb-audio providing
> incentives for the
> >>>> browser to use these three codecs: make them mandatory
> to implement
> >>>> when there is no cost impact on the browser (e.g. if
> codec already
> >>>> installed, paid by the device vendor...).
> >>>>
> >>>> Any opinion on that?
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Xavier
> >>>>
> >>>> PS: I will be ready to present the slides on Thursday if time
> >>>> permits it.
> >>>>
> >>>> (c.f.
> >>>> http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf
> >>>>
> >>>>
> )
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie  >>>> > wrote:
> >>>>
> >>>> Magnus and I discussed this this morning, and we
> encourage you to
> >>>> prepare something.  If the discussion of working group last call
> >>>> items runs short, we may be able to fit this in at that
> time or at
> >>>> the end of day one if its full agenda his finished.
> This is not a
> >>>> commitment, however, so please try and get discussion on
> the list
> >>>> on the points from the draft you feel need resolution.
> >>>>
> >>>> regards,
> >>>>
> >>>> Ted
> >>>>
> >>>>
> >>>> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)
> >>>> > wrote:
> >>>>> Hello,
> >>>>>
> >>>>>
> >>>>>
> >>>>> I would like to request agenda time for:
> >>>>>
> >>>>>
> >>>>>
> >>>>> draft-marjou-rtcweb-audio-codecs-for-interop-01
> >>>>>
> >>>>>
> >>>>>
> >>>>> The document  presents use-cases underlining why WebRTC needs
> >>>> AMR-WB,  AMR
> >>>>> and G.722 as additional relevant voice codecs to satisfactorily
> >>>>> ensure interoperability with existing systems.
> >>>>>
> >>>>>
> >>>>>
> >>>>> A 10-minute time slot should be sufficient for presentation and
> >>>> discussion.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Regards
> >>>>>
> >>>>>
> >>>>>
> >>>>> -Espen
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________ 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
> >>
> >> ___________________________________________________________
> >> ___________________________________________________________ ___
> >>
> >> Ce message et ses pieces jointes peuvent contenir des informations
> >> confidentielles ou privilegiees et ne doivent donc pas
> etre diffuses,
> >> exploites ou copies sans autorisation. Si vous avez recu
> ce message
> >> par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> >> que les pieces jointes. Les messages electroniques etant
> susceptibles
> >> d'alteration, France Telecom - Orange decline toute
> responsabilite si
> >> ce message a ete altere, deforme ou falsifie. Merci.
> >>
> >> This message and its attachments may contain confidential or
> >> privileged information that may be protected by law; they
> should not
> >> be distributed, used or copied without authorisation. If you have
> >> received this email in error, please notify the sender and delete
> >> this message and its attachments. As emails may be altered, France
> >> Telecom - Orange is not liable for messages that have been
> modified,
> >> changed or falsified. Thank you.
> >>
> >> _______________________________________________ rtcweb
> mailing list
> >> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> ______________________________________________________________________
> > ___________________________________________________
> >
> >  Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> > que les pieces jointes. Les messages electroniques etant
> susceptibles
> > d'alteration, France Telecom - Orange decline toute
> responsabilite si
> > ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they
> should not
> > be distributed, used or copied without authorisation. If you have
> > received this email in error, please notify the sender and
> delete this
> > message and its attachments. As emails may be altered,
> France Telecom
> > - Orange is not liable for messages that have been
> modified, changed
> > or falsified. Thank you.
> >
> > _______________________________________________ rtcweb mailing list
> > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> ---------------------------------------------------------------------
> >
> >
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
> non-public information.
> Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in
> error, please immediately reply to the sender and delete this
> information from your system. Use, dissemination, distribution, or
> reproduction of this transmission by unintended recipients is not
> authorized and may be unlawful.
> >
> >
> ______________________________________________________________________
> > ___________________________________________________
> >
> >  Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> > que les pieces jointes. Les messages electroniques etant
> susceptibles
> > d'alteration, France Telecom - Orange decline toute
> responsabilite si
> > ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they
> should not
> > be distributed, used or copied without authorisation. If you have
> > received this email in error, please notify the sender and
> delete this
> > message and its attachments. As emails may be altered,
> France Telecom
> > - Orange is not liable for messages that have been
> modified, changed
> > or falsified. Thank you.
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJRQVgzAAoJEJ6/8sItn9q9fgYH/jcWfhRrvPM1hJ22YcE7eR0N
> OZzP/RvSrUBiIA6kG+6+Hvn5Lp/tXd+LxUDp5L8B3Toce7TBBAYNJP3M2cr8N8It
> SjVvPHtBNKEqhBLbI4FbAouvymNH4utjAWR+MmF9LRySPXZ9nxLN0A13TeUlpZxt
> Jaxr/n9AWwkKOk6BIo1Xztbk26MObiGVLhCE+CPoHaHe29bKblPcphBXC935ymHS
> SuF2DXiAq0iKwZoVOsLe3RIaGg+bjN7N2MXi3Vphr7cOQK+JpdxURDrvmPh7/L8R
> ht1RJt928yl4fEjnKhSKJLd1J+gPBe6vnkSxUp89as03bLirLwN1G2giD3YzfLM=3D
> =3DK56v
> -----END PGP SIGNATURE-----
>
> ______________________________________________________________
> ___________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> que les pieces jointes. Les messages electroniques etant susceptibles
> d'alteration, France Telecom - Orange decline toute responsabilite si
> ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should not
> be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for
> messages that have been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> 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
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
> non-public information.
> Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in
> error, please immediately reply to the sender and delete this
> information from your system. Use, dissemination, distribution, or
> reproduction of this transmission by unintended recipients is not
> authorized and may be unlawful.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou =
copies sans autorisation. Si vous avez recu ce message par erreur, veuillez=
 le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le=
s messages electroniques etant susceptibles d'alteration, France Telecom - =
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law; they should not be distributed, used=
 or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

From adam@nostrum.com  Fri Mar 15 09:52: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 54DFB21F8454 for ; Fri, 15 Mar 2013 09:52:47 -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=[AWL=0.000,  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 ubaW8+hYEHAu for ; Fri, 15 Mar 2013 09:52:46 -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 AE93F21F843E for ; Fri, 15 Mar 2013 09:52:45 -0700 (PDT)
Received: from dhcp-5033.meeting.ietf.org (dhcp-5033.meeting.ietf.org [130.129.80.51]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2FGqf3l080293 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 15 Mar 2013 11:52:42 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <514351DD.7070705@nostrum.com>
Date: Fri, 15 Mar 2013 12:52:45 -0400
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Andrew Allen 
References:   <580BEA5E3B99744AB1F5BFF5E9A3C67D16E4408A5A@HE111648.emea1.cds.t-internal.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 130.129.80.51 is authenticated by a trusted mechanism)
Cc: "xavier.marjou@orange.com" , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 15 Mar 2013 16:52:47 -0000

On 3/15/13 10:55, Andrew Allen wrote:
> Roland
>
> I have proposed that we add the following text to address the interoperability concerns
>
> "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."
>

For the record, I find this statement non-objectionable.

/a

From roman@telurix.com  Fri Mar 15 09: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 BEE9021F868B for ; Fri, 15 Mar 2013 09:53:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.826
X-Spam-Level: 
X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_LOAN=2.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 wt1oUsP0NvKv for ; Fri, 15 Mar 2013 09:53:50 -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 3E26321F84B0 for ; Fri, 15 Mar 2013 09:53:44 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hq4so729377wib.5 for ; Fri, 15 Mar 2013 09:53:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=FH74iy/qplmp90u/m+V6mCv+AFad9ClTpGz3YQwH8PY=; b=Z/Va3MghYZ7Z9UEt74sH0pcysDoS2NvnF9gwr+py/BkWNsJ1G5x2AEL8mFUV33gW7g I0emSDroPJHTfz2HTGoJvw2fZce1ANNqwtRzHVwc9XtsE+sNGEfAzjS0fqBj2TJ6EF7i qzBbKjpYajB9Q22QdwsdQAVn3YXr54b9e+h8lvwrBi1bLYpRyZDLoCrAZgixpiqcwqyu WR7yC0gnnLiRNmMcu6PtMqdZOz/aJxR7++BXMo5pvizbBMBEwPnXfO7DLVKOOrsBAFDm bJyGLiGbuF+8n2sMOV2nCaB3xXIPOnoCpinjIEvdE/nqoeIFJUZb/djcECYdkxynNSsK aGcg==
X-Received: by 10.180.103.40 with SMTP id ft8mr4356473wib.28.1363366423685; Fri, 15 Mar 2013 09:53:43 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by mx.google.com with ESMTPS id bs6sm4295050wib.4.2013.03.15.09.53.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Mar 2013 09:53:42 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id dr12so3174765wgb.23 for ; Fri, 15 Mar 2013 09:53:40 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.181.11.164 with SMTP id ej4mr4558813wid.29.1363366420616; Fri, 15 Mar 2013 09:53:40 -0700 (PDT)
Received: by 10.217.107.135 with HTTP; Fri, 15 Mar 2013 09:53:40 -0700 (PDT)
In-Reply-To: <4507_1363362629_51434345_4507_361_1_6af2514e-a2f2-4248-b7a9-5d0452f3abf7@PEXCVZYH02.corporate.adroot.infra.ftgroup>
References:   <580BEA5E3B99744AB1F5BFF5E9A3C67D16E4408A5A@HE111648.emea1.cds.t-internal.com>  <4507_1363362629_51434345_4507_361_1_6af2514e-a2f2-4248-b7a9-5d0452f3abf7@PEXCVZYH02.corporate.adroot.infra.ftgroup>
Date: Fri, 15 Mar 2013 12:53:40 -0400
Message-ID: 
From: Roman Shpount 
To: stephane.proust@orange.com
Content-Type: multipart/alternative; boundary=f46d0438914b3321bc04d7f97b43
X-Gm-Message-State: ALoCoQm0bgw7n1n0H/qa1tX4wZXXWB/jrgk/KSpaiZx/JZv1aCwP+gLqw9JmwXGcb7g28kflG0vi
Cc: MARJOU Xavier OLNC/OLN , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 15 Mar 2013 16:53:54 -0000

--f46d0438914b3321bc04d7f97b43
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Out of curiosity, since you are pushing so hard for AMR/AMR-WB support, how
would one connect to devices on Orange network using these codecs? Is there
currently a way to connect without going through G.711 transcoding?
_____________
Roman Shpount


On Fri, Mar 15, 2013 at 11:50 AM,  wrote:

> Hello
>
> As mentioned earlier, this kind of general statement makes sense and woul=
d
> be acceptable for us only if it gives some minimum guidance on what
> "suitable" means. It means: the codecs that are especially important to b=
e
> considered because their support would solve the interoperability issue f=
or
> a huge number of calls and because they can be made available to the
> browsers on a high number of devices:
>
> "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."
> This is especially the case for AMR and AMR-WB for interoperability with
> 3GPP mobile devices and G.722 for interoperability with fixed ETSI/DECT
> CAT-iq devices
>
>
> Stephane Proust
>
>
>
> -----Message d'origine-----
> De : Andrew Allen [mailto:aallen@blackberry.com]
> Envoy=E9 : vendredi 15 mars 2013 15:56
> =C0 : R.Jesske@telekom.de; koen.vos@skype.net; espeberg@cisco.com; PROUST
> Stephane OLNC/OLPS
> Cc : MARJOU Xavier OLNC/OLN; rtcweb@ietf.org
> Objet : RE: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> Roland
>
> I have proposed that we add the following text to address the
> interoperability concerns
>
> "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."
>
> The MTI Audio Codecs are defined to ensure a basic level of
> interoperability and will need to be always supported for that reason.
> Support for additional audio codecs is an implementation and business cas=
e
> decision and the additional audio codecs that it makes sense to support
> will change over time (as codecs become obsolete and new ones are develop=
ed
> and deployed. So additional audio codecs should not be specified in the
> RTCweb RFCs.
>
> Andrew
>
> -----Original Message-----
> From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]
> Sent: Friday, March 15, 2013 5:45 AM
> To: Andrew Allen; koen.vos@skype.net; espeberg@cisco.com;
> stephane.proust@orange.com
> Cc: xavier.marjou@orange.com; rtcweb@ietf.org
> Subject: AW: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> Hi Andrew,
> but where will you start and where will you end.
> The codec discussion appears now so why not try to solve this now?
> And one proposal is to use these codecs and I fully support it.
>
> Roland
>
> > -----Urspr=FCngliche Nachricht-----
> > Von: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] Im
> > Auftrag von Andrew Allen
> > Gesendet: Donnerstag, 14. M=E4rz 2013 22:10
> > An: koen.vos@skype.net; espeberg@cisco.com; stephane.proust@orange.com
> > Cc: xavier.marjou@orange.com; rtcweb@ietf.org
> > Betreff: Re: [rtcweb] Agenda time request for
> > draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> >
> > Koen is right that there are many more obstacles to RTCweb and legacy
> > network interop than just a common codec. First there will need to be
> > RTCweb signaling gateways to interface between the RTCweb signaling
> > and the legacy networks (SIP,
> > H.323 etc) and there will need to be in place mechanisms for peering,
> > federation and address resolution between networks as well as service
> > agreements in place between the players.
> >
> > Until those are resolved supporting codecs used in those networks is
> > pointless.
> >
> > Andrew
> >
> > ----- Original Message -----
> > From: Koen Vos [mailto:koen.vos@skype.net]
> > Sent: Thursday, March 14, 2013 03:32 PM Central Standard Time
> > To: Espen Berger (espeberg) ;
> > stephane.proust@orange.com 
> > Cc: rtcweb@ietf.org ; MARJOU Xavier OLNC/OLN
> > 
> > Subject: Re: [rtcweb] Agenda time     request for
> > draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> > > It's interop with billions of mobile phones and with fixed
> > terminals in legacy telephony services.
> >
> > The problem is that WebRTC and legacy services live in separate
> > networks: the open Web vs proprietary Telco networks.
> >
> > WebRTC connecting to a Telco network would have to go through a
> > Gateway.  The PSTN termination providers who run these Gateways
> > support G.711, G.729 and perhaps some other  codecs like iLBC.  They
> > do not, however, support the codecs you are advocating for.
> >
> > The lack of support for Transcoding-Free Operation by Telcos to the
> > rest of the world has been hurting interop voice quality for a long
> > time, but unfortunately we can't fix that here at the IETF.
> >
> > We can fit our cars with your costly railroad wheels, but you still
> > wouldn't let us on your tracks.
> >
> > koen.
> >
> >
> > -----Original Message-----
> > From: rtcweb-bounces@ietf.org
> > [mailto:rtcweb-bounces@ietf.org] On Behalf Of
> > stephane.proust@orange.com
> > Sent: 14. mars 2013 13:36
> > To: Jean-Marc Valin
> > Cc: rtcweb@ietf.org; MARJOU Xavier OLNC/OLN
> > Subject: Re: [rtcweb] Agenda time request for
> > draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> > Hello
> >
> > The short list is aligned to what is specified in 3GPP
> > (mobile) and CAT-iq (fixed). Check the related service specifications!
> > The short list (AMR, AMR-WB, G.722) is a minimal subset of codecs to
> > minimize interop issues and transcoding costs for telco services.
> > It's not a question of what's the favourite codec for a given
> > application. It's interop with billions of mobile phones and with
> > fixed terminals in legacy telephony services.
> >
> > St=E9phane
> >
> > -----Message d'origine-----
> > De : Jean-Marc Valin [mailto:jmvalin@mozilla.com] Envoy=E9 :
> > jeudi 14 mars 2013 05:55 =C0 : PROUST Stephane OLNC/OLPS Cc :
> > Andrew Allen; Markus.Isomaki@nokia.com; MARJOU Xavier OLNC/OLN;
> > rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time request for
> > draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 03/13/2013 06:48 PM, stephane.proust@orange.com wrote:
> > > The reason is simply that AMR and AMR-WB are supported in
> > billions of
> > > devices !
> >
> > Just curious, why exclude from the list other codecs with similar huge
> > deployment? I can think of at least:
> > - - GSM-FR (mobile)
> > - - Speex (Flash)
> > - - G.729 (PSTN gateways)
> > - - iLBC (PSTN gateways)
> > - - G.726 (DECT)
> > - - SILK (original non-Opus version in Skype)
> >
> > (sorry, if I missed someone's favorite codec in this list)
> >
> > It's not at all clear to me what's so special that makes AMR, AMR-WB
> > and G.722 different from the other codecs in the list above. Not that
> > I insist on shipping G.729 :-)
> >
> > Personally, I'd favor a draft that included a lot more codecs,
> > describing for each one the benefits of supporting it. Implementers
> > could then choose which of these they care about for their particular
> > situation.
> >
> > Cheers,
> >
> >         Jean-Marc
> >
> > > St=E9phane
> > >
> > >
> > > -----Message d'origine----- De : Andrew Allen
> > > [mailto:aallen@blackberry.com] Envoy=E9 : mercredi 13 mars 2013
> > > 23:41 =C0 : PROUST Stephane OLNC/OLPS; Markus.Isomaki@nokia.com;
> > > jmvalin@mozilla.com Cc : MARJOU Xavier OLNC/OLN;
> > rtcweb@ietf.org Objet
> > > : Re: [rtcweb] Agenda time request for
> > > draft-marjou-rtcweb-audio-codecs-for-interop-01
> > >
> > >
> > > No this wouldn't be acceptable to me.
> > >
> > > I don't see a reason to push a particular set of Codecs
> > over any other
> > > set of codecs supported on the device. If the device supports the
> > > codecs and they are available to the browser then we should
> > recommend
> > > that they be offered in the negotiation.
> > >
> > > The marjou draft can advertise the merits and reasons why they are
> > > good codecs to support.
> > >
> > >
> > > ----- Original Message ----- From: stephane.proust@orange.com
> > > [mailto:stephane.proust@orange.com] Sent: Wednesday, March 13, 2013
> > > 05:14 PM Central Standard Time To: Markus.Isomaki@nokia.com
> > > ; jmvalin@mozilla.com
> > 
> > > Cc: MARJOU Xavier OLNC/OLN ;
> > rtcweb@ietf.org
> > > 
> > > Subject: Re: [rtcweb] Agenda time     request for
> > > draft-marjou-rtcweb-audio-codecs-for-interop-01
> > >
> > > Dear Markus
> > >
> > > Thanks for your attempt to help !
> > >
> > > Of course each Telco can handle this directly with vendors and
> > > browsers manufacturers at business level. But I don't'think
> > this need
> > > of interoperability with mobile devices is specific to Orange.
> > > I think all mobile operators will have the same issue and
> > this is why
> > > standardization exist. It's most cost and time efficient to
> > have one
> > > common way forward for all the industry.
> > >
> > > Then if the issue is that "conditional MUST/SHOULD are a too
> > > complicated requirement. We could also live as a compromise with a
> > > formulation that has already been suggested on the reflector:
> > >
> > > "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" If possible with the addition of This is
> > especially
> > > the case for AMR, AMR-WB for interoperability with mobile
> > devices and
> > > G.722 for interoperability with fixed DECT CAT-iq devices
> > >
> > > Would it have one chance to reach consensus ?
> > >
> > > I think this Group should at least make one small step so that the
> > > interoperability issue with mobile terminals be not fully
> > ignored in
> > > the RTC Web specification considering the huge number of deployed
> > > devices. At least something must be written on this !
> > > G.711 which is the only codec in addition to OPUS for
> > interoperability
> > > purpose is not a proper answer to this.
> > >
> > > St=E9phane
> > >
> > > -----Message d'origine----- De : Markus.Isomaki@nokia.com
> > > [mailto:Markus.Isomaki@nokia.com] Envoy=E9 : mercredi 13 mars 2013
> > > 22:37 =C0 : PROUST Stephane OLNC/OLPS; jmvalin@mozilla.com; MARJOU
> > > Xavier OLNC/OLN Cc : rtcweb@ietf.org Objet : RE: [rtcweb]
> > Agenda time
> > > request for draft-marjou-rtcweb-audio-codecs-for-interop-01
> > >
> > > Hi Stephane, Xavier,
> > >
> > > I understand the intent of your proposal. I'm not sure if
> > the IETF is
> > > the best venue for you to pursue it, however. Perhaps you
> > as a mobile
> > > operator should rather set it as a requirement to your
> > mobile device
> > > platforms that they open up the APIs to AMR and AMR-WB and that at
> > > least the in-built default browser needs to support it. If
> > there are
> > > enough operators setting such requirements directly to the
> > device and
> > > platform vendors, it probably has a bigger impact than an IETF RFC.
> > > Getting that support for user-installed additional browsers
> > might be
> > > more difficult, but most mobile device users stick with the default
> > > browser anyway.
> > >
> > > The RTCWEB codec document needs to definitely explain this case and
> > > the benefits, but the conditional MUSTs or SHOULDs you are
> > proposing
> > > are perhaps a bit too complicated. Hmm, perhaps we need to do an
> > > _informational_ RFC as something like "Recommendations for
> > WebRTC on
> > > Mobile Devices" addressing the codec and perhaps other issues, that
> > > you could use as a reference in your requirements.
> > >
> > > Markus
> > >
> > >
> > >> -----Original Message----- From: rtcweb-bounces@ietf.org
> > >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext
> > >> stephane.proust@orange.com Sent: 13 March, 2013 21:37 To:
> > >> Jean-Marc Valin; MARJOU Xavier OLNC/OLN Cc: rtcweb@ietf.org
> > >> Subject: Re: [rtcweb] Agenda time request for
> > >> draft-marjou-rtcweb-audio- codecs-for-interop-01
> > >>
> > >> Hello
> > >>
> > >> Our understanding is that the reason of the "no consensus" on
> > >> additional recommended codecs was the additional costs for
> > browsers.
> > >> The proposal is then to make these "MUST" fully conditional to the
> > >> case of no (or very reduced) additional costs, when the codecs are
> > >> already available on the device and when no additional
> > license fee is
> > >> required
> > >>
> > >> We could even live with lower level of "requirements" with
> > >> respectively May and Should (instead of Should and shall) but we
> > >> think that this proposal is a way to take into account
> > both browser
> > >> manufacturers concerns on browsers costs and telcos concerns on
> > >> transcoding costs and some other companies share this view.
> > >>
> > >> St=E9phane
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> -----Message d'origine----- De : rtcweb-bounces@ietf.org
> > >> [mailto:rtcweb-bounces@ietf.org] De la part de Jean-Marc
> > Valin Envoy=E9
> > >> : mercredi 13 mars 2013 20:24 =C0 : MARJOU Xavier OLNC/OLN Cc :
> > >> rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time request for
> > >> draft-marjou-rtcweb-audio-codecs-for-interop-01
> > >>
> > > Hi,
> > >
> > > I'd really like to understand how the chairs coming to the
> > conclusion
> > > that there was *no consensus* on recommended codecs can result in a
> > > draft that includes 3 MUSTs and 1 SHOULD. This draft
> > effectively makes
> > > 3 new codecs MTI for a range of devices. I understand that it's an
> > > individual draft and you can write whatever you like in
> > there, but it
> > > definitely goes against the result of the WG discussion.
> > >
> > > Cheers,
> > >
> > > Jean-Marc
> > >
> > > On 03/13/2013 09:14 AM, Xavier Marjou wrote:
> > >>>> Here is a summary of the
> > >>>> draft-marjou-rtcweb-audio-codecs-for-interop-00
> > presentation that I
> > >>>> had prepared for yesterday's session:
> > >>>>
> > >>>> - The co-authors want to underline that non-WebRTC voice
> > endpoints
> > >>>> usually use one of the following codecs: AMR, AMR-WB or G.722,
> > >>>> which will result in massive transcoding when there will be
> > >>>> communications between WebRTC endpoints and non-WebRTC endpoints.
> > >>>>
> > >>>> - On one side, transcoding is bad for many reasons
> > discussed in the
> > >>>> draft (cost issues, intrinsic quality degradation, degraded
> > >>>> interactivity, fallback from HD to G.711...);
> > >>>>
> > >>>> - On the other side, it is recognized that implementing
> > additional
> > >>>> codecs in the browsers can generate additional costs.
> > >>>>
> > >>>> - In order to reach a compromise, we would like to add
> > some text in
> > >>>> the WG draft draft-ietf-rtcweb-audio providing
> > incentives for the
> > >>>> browser to use these three codecs: make them mandatory
> > to implement
> > >>>> when there is no cost impact on the browser (e.g. if
> > codec already
> > >>>> installed, paid by the device vendor...).
> > >>>>
> > >>>> Any opinion on that?
> > >>>>
> > >>>> Cheers,
> > >>>>
> > >>>> Xavier
> > >>>>
> > >>>> PS: I will be ready to present the slides on Thursday if time
> > >>>> permits it.
> > >>>>
> > >>>> (c.f.
> > >>>> http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf
> > >>>>
> > >>>>
> > )
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie  > >>>> > wrote:
> > >>>>
> > >>>> Magnus and I discussed this this morning, and we
> > encourage you to
> > >>>> prepare something.  If the discussion of working group last call
> > >>>> items runs short, we may be able to fit this in at that
> > time or at
> > >>>> the end of day one if its full agenda his finished.
> > This is not a
> > >>>> commitment, however, so please try and get discussion on
> > the list
> > >>>> on the points from the draft you feel need resolution.
> > >>>>
> > >>>> regards,
> > >>>>
> > >>>> Ted
> > >>>>
> > >>>>
> > >>>> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)
> > >>>> > wrote:
> > >>>>> Hello,
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> I would like to request agenda time for:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> draft-marjou-rtcweb-audio-codecs-for-interop-01
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> The document  presents use-cases underlining why WebRTC needs
> > >>>> AMR-WB,  AMR
> > >>>>> and G.722 as additional relevant voice codecs to satisfactorily
> > >>>>> ensure interoperability with existing systems.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> A 10-minute time slot should be sufficient for presentation and
> > >>>> discussion.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> Regards
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> -Espen
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> _______________________________________________ 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
> > >>
> > >> ___________________________________________________________
> > >> ___________________________________________________________ ___
> > >>
> > >> Ce message et ses pieces jointes peuvent contenir des informations
> > >> confidentielles ou privilegiees et ne doivent donc pas
> > etre diffuses,
> > >> exploites ou copies sans autorisation. Si vous avez recu
> > ce message
> > >> par erreur, veuillez le signaler a l'expediteur et le
> > detruire ainsi
> > >> que les pieces jointes. Les messages electroniques etant
> > susceptibles
> > >> d'alteration, France Telecom - Orange decline toute
> > responsabilite si
> > >> ce message a ete altere, deforme ou falsifie. Merci.
> > >>
> > >> This message and its attachments may contain confidential or
> > >> privileged information that may be protected by law; they
> > should not
> > >> be distributed, used or copied without authorisation. If you have
> > >> received this email in error, please notify the sender and delete
> > >> this message and its attachments. As emails may be altered, France
> > >> Telecom - Orange is not liable for messages that have been
> > modified,
> > >> changed or falsified. Thank you.
> > >>
> > >> _______________________________________________ rtcweb
> > mailing list
> > >> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
> > >
> > >
> > ______________________________________________________________________
> > > ___________________________________________________
> > >
> > >  Ce message et ses pieces jointes peuvent contenir des informations
> > > confidentielles ou privilegiees et ne doivent donc pas etre
> > diffuses,
> > > exploites ou copies sans autorisation. Si vous avez recu ce message
> > > par erreur, veuillez le signaler a l'expediteur et le
> > detruire ainsi
> > > que les pieces jointes. Les messages electroniques etant
> > susceptibles
> > > d'alteration, France Telecom - Orange decline toute
> > responsabilite si
> > > ce message a ete altere, deforme ou falsifie. Merci.
> > >
> > > This message and its attachments may contain confidential or
> > > privileged information that may be protected by law; they
> > should not
> > > be distributed, used or copied without authorisation. If you have
> > > received this email in error, please notify the sender and
> > delete this
> > > message and its attachments. As emails may be altered,
> > France Telecom
> > > - Orange is not liable for messages that have been
> > modified, changed
> > > or falsified. Thank you.
> > >
> > > _______________________________________________ rtcweb mailing list
> > > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
> > >
> > >
> > ---------------------------------------------------------------------
> > >
> > >
> > This transmission (including any attachments) may contain confidential
> > information, privileged material (including material protected by the
> > solicitor-client or other applicable privileges), or constitute
> > non-public information.
> > Any use of this information by anyone other than the intended
> > recipient is prohibited. If you have received this transmission in
> > error, please immediately reply to the sender and delete this
> > information from your system. Use, dissemination, distribution, or
> > reproduction of this transmission by unintended recipients is not
> > authorized and may be unlawful.
> > >
> > >
> > ______________________________________________________________________
> > > ___________________________________________________
> > >
> > >  Ce message et ses pieces jointes peuvent contenir des informations
> > > confidentielles ou privilegiees et ne doivent donc pas etre
> > diffuses,
> > > exploites ou copies sans autorisation. Si vous avez recu ce message
> > > par erreur, veuillez le signaler a l'expediteur et le
> > detruire ainsi
> > > que les pieces jointes. Les messages electroniques etant
> > susceptibles
> > > d'alteration, France Telecom - Orange decline toute
> > responsabilite si
> > > ce message a ete altere, deforme ou falsifie. Merci.
> > >
> > > This message and its attachments may contain confidential or
> > > privileged information that may be protected by law; they
> > should not
> > > be distributed, used or copied without authorisation. If you have
> > > received this email in error, please notify the sender and
> > delete this
> > > message and its attachments. As emails may be altered,
> > France Telecom
> > > - Orange is not liable for messages that have been
> > modified, changed
> > > or falsified. Thank you.
> > >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.13 (GNU/Linux)
> > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> > iQEcBAEBAgAGBQJRQVgzAAoJEJ6/8sItn9q9fgYH/jcWfhRrvPM1hJ22YcE7eR0N
> > OZzP/RvSrUBiIA6kG+6+Hvn5Lp/tXd+LxUDp5L8B3Toce7TBBAYNJP3M2cr8N8It
> > SjVvPHtBNKEqhBLbI4FbAouvymNH4utjAWR+MmF9LRySPXZ9nxLN0A13TeUlpZxt
> > Jaxr/n9AWwkKOk6BIo1Xztbk26MObiGVLhCE+CPoHaHe29bKblPcphBXC935ymHS
> > SuF2DXiAq0iKwZoVOsLe3RIaGg+bjN7N2MXi3Vphr7cOQK+JpdxURDrvmPh7/L8R
> > ht1RJt928yl4fEjnKhSKJLd1J+gPBe6vnkSxUp89as03bLirLwN1G2giD3YzfLM=3D
> > =3DK56v
> > -----END PGP SIGNATURE-----
> >
> > ______________________________________________________________
> > ___________________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> > que les pieces jointes. Les messages electroniques etant susceptibles
> > d'alteration, France Telecom - Orange decline toute responsabilite si
> > ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not
> > be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender and
> > delete this message and its attachments.
> > As emails may be altered, France Telecom - Orange is not liable for
> > messages that have been modified, changed or falsified.
> > Thank you.
> >
> > _______________________________________________
> > 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
> >
> > ---------------------------------------------------------------------
> > This transmission (including any attachments) may contain confidential
> > information, privileged material (including material protected by the
> > solicitor-client or other applicable privileges), or constitute
> > non-public information.
> > Any use of this information by anyone other than the intended
> > recipient is prohibited. If you have received this transmission in
> > error, please immediately reply to the sender and delete this
> > information from your system. Use, dissemination, distribution, or
> > reproduction of this transmission by unintended recipients is not
> > authorized and may be unlawful.
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-publi=
c
> information. Any use of this information by anyone other than the intende=
d
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawf=
ul.
>
>
> _________________________________________________________________________=
________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a ete
> altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for
> messages that have been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--f46d0438914b3321bc04d7f97b43
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Out of curiosity, since you are pushing so hard for AMR/AMR-WB support, how=
 would one connect to devices on Orange network using these codecs? Is ther=
e currently a way to connect without going through G.711 transcoding?


_____________
Roman Shpount



On Fri, Mar 15, 2013 at 11:50 AM,  <stephane.proust@orange.com> wrote:

Hello



As mentioned earlier, this kind of general statement makes sense and would =
be acceptable for us only if it gives some minimum guidance on what "s=
uitable" means. It means: the codecs that are especially important to =
be considered because their support would solve the interoperability issue =
for a huge number of calls and because they can be made available to the br=
owsers on a high number of devices:





"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 maximi=
ze the possibility to establish the session without the need for audio tran=
scoding."



This is especially the case for AMR and AMR-WB for interoperability w=
ith 3GPP mobile devices and G.722 for interoperability with fixed ETSI/DECT=
 CAT-iq devices





Stephane Proust








-----Message d'origine-----

De=A0: Andrew Allen [mailto:aallen=
@blackberry.com]


Envoy=E9=A0: vendredi 15 mars 2013 15:56

=C0=A0: R.Jesske@telekom.de; koen.vos@skype.net; espeberg@cisco.com; PROUST Stephane OLNC/OLPS


Cc=A0: MARJOU Xavier OLNC/OLN; rtcweb@ietf.org


Objet=A0: RE: [rtcweb] Agenda time request for draft-marjou-rtcweb-au=
dio-codecs-for-interop-01




Roland



I have proposed that we add the following text to address the interoperabil=
ity concerns



"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 maximi=
ze the possibility to establish the session without the need for audio tran=
scoding."




The MTI Audio Codecs are defined to ensure a basic level of interoperabilit=
y and will need to be always supported for that reason. Support for additio=
nal audio codecs is an implementation and business case decision and the ad=
ditional audio codecs that it makes sense to support will change over time =
(as codecs become obsolete and new ones are developed and deployed. So addi=
tional audio codecs should not be specified in the RTCweb RFCs.




Andrew



-----Original Message-----

From: R.Jesske@telekom.de [mailt=
o:R.Jesske@telekom.de]

Sent: Friday, March 15, 2013 5:45 AM

To: Andrew Allen; koen.vos@skype.net<=
/a>; espeberg@cisco.com; stephane.proust@orange.com

Cc: xavier.marjou@orange.com; rtcweb@ietf.org

Subject: AW: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01



Hi Andrew,

but where will you start and where will you end.

The codec discussion appears now so why not try to solve this now?

And one proposal is to use these codecs and I fully support it.



Roland



> -----Urspr=FCngliche Nachricht-----

> Von: rtcweb-bounces@ietf.or=
g [mailto:rtcweb-bounces@iet=
f.org] Im

> Auftrag von Andrew Allen

> Gesendet: Donnerstag, 14. M=E4rz 2013 22:10

> An: koen.vos@skype.net; espeberg@cisco.com; stephane.proust@orange.com

> Cc: xavier.marjou@orange.c=
om; rtcweb@ietf.org

> Betreff: Re: [rtcweb] Agenda time request for

> draft-marjou-rtcweb-audio-codecs-for-interop-01

>

>

> Koen is right that there are many more obstacles to RTCweb and legacy<=
br>
> network interop than just a common codec. First there will need to be<=
br>
> RTCweb signaling gateways to interface between the RTCweb signaling
> and the legacy networks (SIP,

> H.323 etc) and there will need to be in place mechanisms for peering,<=
br>
> federation and address resolution between networks as well as service<=
br>
> agreements in place between the players.

>

> Until those are resolved supporting codecs used in those networks is
> pointless.

>

> Andrew

>

> ----- Original Message -----

> From: Koen Vos [mailto:koen.vos@=
skype.net]

> Sent: Thursday, March 14, 2013 03:32 PM Central Standard Time

> To: Espen Berger (espeberg) <=
espeberg@cisco.com>;

> stephane.proust@orange.c=
om <stephane.proust@or=
ange.com>

> Cc: rtcweb@ietf.org <rtcweb@ietf.org>; MARJOU Xavier OLNC/OLN=


> <xavier.marjou@orange.c=
om>

> Subject: Re: [rtcweb] Agenda time =A0 =A0 request for

> draft-marjou-rtcweb-audio-codecs-for-interop-01

>

> > It's interop with billions of mobile phones and with fixed
> terminals in legacy telephony services.

>

> The problem is that WebRTC and legacy services live in separate

> networks: the open Web vs proprietary Telco networks.

>

> WebRTC connecting to a Telco network would have to go through a

> Gateway. =A0The PSTN termination providers who run these Gateways

> support G.711, G.729 and perhaps some other =A0codecs like iLBC. =A0Th=
ey

> do not, however, support the codecs you are advocating for.

>

> The lack of support for Transcoding-Free Operation by Telcos to the
> rest of the world has been hurting interop voice quality for a long
> time, but unfortunately we can't fix that here at the IETF.

>

> We can fit our cars with your costly railroad wheels, but you still
> wouldn't let us on your tracks.

>

> koen.

>

>

> -----Original Message-----

> From: rtcweb-bounces@ietf.o=
rg

> [mailto:rtcweb-bounces@ietf=
.org] On Behalf Of

> stephane.proust@orange.c=
om

> Sent: 14. mars 2013 13:36

> To: Jean-Marc Valin

> Cc: rtcweb@ietf.org; MARJOU Xav=
ier OLNC/OLN

> Subject: Re: [rtcweb] Agenda time request for

> draft-marjou-rtcweb-audio-codecs-for-interop-01

>

> Hello

>

> The short list is aligned to what is specified in 3GPP

> (mobile) and CAT-iq (fixed). Check the related service specifications!=


> The short list (AMR, AMR-WB, G.722) is a minimal subset of codecs to
> minimize interop issues and transcoding costs for telco services.

> It's not a question of what's the favourite codec for a given<=
br>
> application. It's interop with billions of mobile phones and with<=
br>
> fixed terminals in legacy telephony services.

>

> St=E9phane

>

> -----Message d'origine-----

> De : Jean-Marc Valin [mailto:jm=
valin@mozilla.com] Envoy=E9 :

> jeudi 14 mars 2013 05:55 =C0 : PROUST Stephane OLNC/OLPS Cc :

> Andrew Allen; Markus.Isoma=
ki@nokia.com; MARJOU Xavier OLNC/OLN;

> rtcweb@ietf.org Objet : Re: [rt=
cweb] Agenda time request for

> draft-marjou-rtcweb-audio-codecs-for-interop-01

>

> -----BEGIN PGP SIGNED MESSAGE-----

> Hash: SHA1

>

> On 03/13/2013 06:48 PM, =
stephane.proust@orange.com wrote:

> > The reason is simply that AMR and AMR-WB are supported in

> billions of

> > devices !

>

> Just curious, why exclude from the list other codecs with similar huge=


> deployment? I can think of at least:

> - - GSM-FR (mobile)

> - - Speex (Flash)

> - - G.729 (PSTN gateways)

> - - iLBC (PSTN gateways)

> - - G.726 (DECT)

> - - SILK (original non-Opus version in Skype)

>

> (sorry, if I missed someone's favorite codec in this list)

>

> It's not at all clear to me what's so special that makes AMR, =
AMR-WB

> and G.722 different from the other codecs in the list above. Not that<=
br>
> I insist on shipping G.729 :-)

>

> Personally, I'd favor a draft that included a lot more codecs,

> describing for each one the benefits of supporting it. Implementers
> could then choose which of these they care about for their particular<=
br>
> situation.

>

> Cheers,

>

> =A0 =A0 =A0 =A0 Jean-Marc

>

> > St=E9phane

> >

> >

> > -----Message d'origine----- De : Andrew Allen

> > [mailto:aallen@blackberr=
y.com] Envoy=E9 : mercredi 13 mars 2013

> > 23:41 =C0 : PROUST Stephane OLNC/OLPS; Markus.Isomaki@nokia.com;

> > jmvalin@mozilla.com Cc=
 : MARJOU Xavier OLNC/OLN;

> rtcweb@ietf.org Objet

> > : Re: [rtcweb] Agenda time request for

> > draft-marjou-rtcweb-audio-codecs-for-interop-01

> >

> >

> > No this wouldn't be acceptable to me.

> >

> > I don't see a reason to push a particular set of Codecs

> over any other

> > set of codecs supported on the device. If the device supports the=


> > codecs and they are available to the browser then we should

> recommend

> > that they be offered in the negotiation.

> >

> > The marjou draft can advertise the merits and reasons why they ar=
e

> > good codecs to support.

> >

> >

> > ----- Original Message ----- From: stephane.proust@orange.com

> > [mailto:stephane.pr=
oust@orange.com] Sent: Wednesday, March 13, 2013

> > 05:14 PM Central Standard Time To: Markus.Isomaki@nokia.com

> > <Markus.Isomaki@no=
kia.com>; jmvalin@mozilla.com=


> <jmvalin@mozilla.com>=


> > Cc: MARJOU Xavier OLNC/OLN <xavier.marjou@orange.com>;

> rtcweb@ietf.org

> > <rtcweb@ietf.org>
> > Subject: Re: [rtcweb] Agenda time =A0 =A0 request for

> > draft-marjou-rtcweb-audio-codecs-for-interop-01

> >

> > Dear Markus

> >

> > Thanks for your attempt to help !

> >

> > Of course each Telco can handle this directly with vendors and
> > browsers manufacturers at business level. But I don't'thi=
nk

> this need

> > of interoperability with mobile devices is specific to Orange.
> > I think all mobile operators will have the same issue and

> this is why

> > standardization exist. It's most cost and time efficient to
> have one

> > common way forward for all the industry.

> >

> > Then if the issue is that "conditional MUST/SHOULD are a too=


> > complicated requirement. We could also live as a compromise with =
a

> > formulation that has already been suggested on the reflector:

> >

> > "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" If possible with the addition of This is<=
br>
> especially

> > the case for AMR, AMR-WB for interoperability with mobile

> devices and

> > G.722 for interoperability with fixed DECT CAT-iq devices

> >

> > Would it have one chance to reach consensus ?

> >

> > I think this Group should at least make one small step so that th=
e

> > interoperability issue with mobile terminals be not fully

> ignored in

> > the RTC Web specification considering the huge number of deployed=


> > devices. At least something must be written on this !

> > G.711 which is the only codec in addition to OPUS for

> interoperability

> > purpose is not a proper answer to this.

> >

> > St=E9phane

> >

> > -----Message d'origine----- De : Markus.Isomaki@nokia.com

> > [mailto:Markus.Isomak=
i@nokia.com] Envoy=E9 : mercredi 13 mars 2013

> > 22:37 =C0 : PROUST Stephane OLNC/OLPS; jmvalin@mozilla.com; MARJOU

> > Xavier OLNC/OLN Cc : rtcweb@ie=
tf.org Objet : RE: [rtcweb]

> Agenda time

> > request for draft-marjou-rtcweb-audio-codecs-for-interop-01

> >

> > Hi Stephane, Xavier,

> >

> > I understand the intent of your proposal. I'm not sure if

> the IETF is

> > the best venue for you to pursue it, however. Perhaps you

> as a mobile

> > operator should rather set it as a requirement to your

> mobile device

> > platforms that they open up the APIs to AMR and AMR-WB and that a=
t

> > least the in-built default browser needs to support it. If

> there are

> > enough operators setting such requirements directly to the

> device and

> > platform vendors, it probably has a bigger impact than an IETF RF=
C.

> > Getting that support for user-installed additional browsers

> might be

> > more difficult, but most mobile device users stick with the defau=
lt

> > browser anyway.

> >

> > The RTCWEB codec document needs to definitely explain this case a=
nd

> > the benefits, but the conditional MUSTs or SHOULDs you are

> proposing

> > are perhaps a bit too complicated. Hmm, perhaps we need to do an<=
br>
> > _informational_ RFC as something like "Recommendations for
> WebRTC on

> > Mobile Devices" addressing the codec and perhaps other issue=
s, that

> > you could use as a reference in your requirements.

> >

> > Markus

> >

> >

> >> -----Original Message----- From: rtcweb-bounces@ietf.org

> >> [mailto:rtcweb-bou=
nces@ietf.org] On Behalf Of ext

> >> stephane.proust=
@orange.com Sent: 13 March, 2013 21:37 To:

> >> Jean-Marc Valin; MARJOU Xavier OLNC/OLN Cc: rtcweb@ietf.org

> >> Subject: Re: [rtcweb] Agenda time request for

> >> draft-marjou-rtcweb-audio- codecs-for-interop-01

> >>

> >> Hello

> >>

> >> Our understanding is that the reason of the "no consensu=
s" on

> >> additional recommended codecs was the additional costs for
> browsers.

> >> The proposal is then to make these "MUST" fully con=
ditional to the

> >> case of no (or very reduced) additional costs, when the codec=
s are

> >> already available on the device and when no additional

> license fee is

> >> required

> >>

> >> We could even live with lower level of "requirements&quo=
t; with

> >> respectively May and Should (instead of Should and shall) but=
 we

> >> think that this proposal is a way to take into account

> both browser

> >> manufacturers concerns on browsers costs and telcos concerns =
on

> >> transcoding costs and some other companies share this view.
> >>

> >> St=E9phane

> >>

> >>

> >>

> >>

> >>

> >>

> >> -----Message d'origine----- De : rtcweb-bounces@ietf.org

> >> [mailto:rtcweb-bou=
nces@ietf.org] De la part de Jean-Marc

> Valin Envoy=E9

> >> : mercredi 13 mars 2013 20:24 =C0 : MARJOU Xavier OLNC/OLN Cc=
 :

> >> rtcweb@ietf.org Objet =
: Re: [rtcweb] Agenda time request for

> >> draft-marjou-rtcweb-audio-codecs-for-interop-01

> >>

> > Hi,

> >

> > I'd really like to understand how the chairs coming to the
> conclusion

> > that there was *no consensus* on recommended codecs can result in=
 a

> > draft that includes 3 MUSTs and 1 SHOULD. This draft

> effectively makes

> > 3 new codecs MTI for a range of devices. I understand that it'=
;s an

> > individual draft and you can write whatever you like in

> there, but it

> > definitely goes against the result of the WG discussion.

> >

> > Cheers,

> >

> > Jean-Marc

> >

> > On 03/13/2013 09:14 AM, Xavier Marjou wrote:

> >>>> Here is a summary of the

> >>>> draft-marjou-rtcweb-audio-codecs-for-interop-00

> presentation that I

> >>>> had prepared for yesterday's session:

> >>>>

> >>>> - The co-authors want to underline that non-WebRTC vo=
ice

> endpoints

> >>>> usually use one of the following codecs: AMR, AMR-WB =
or G.722,

> >>>> which will result in massive transcoding when there w=
ill be

> >>>> communications between WebRTC endpoints and non-WebRT=
C endpoints.

> >>>>

> >>>> - On one side, transcoding is bad for many reasons
> discussed in the

> >>>> draft (cost issues, intrinsic quality degradation, de=
graded

> >>>> interactivity, fallback from HD to G.711...);

> >>>>

> >>>> - On the other side, it is recognized that implementi=
ng

> additional

> >>>> codecs in the browsers can generate additional costs.=


> >>>>

> >>>> - In order to reach a compromise, we would like to ad=
d

> some text in

> >>>> the WG draft draft-ietf-rtcweb-audio providing

> incentives for the

> >>>> browser to use these three codecs: make them mandator=
y

> to implement

> >>>> when there is no cost impact on the browser (e.g. if<=
br>
> codec already

> >>>> installed, paid by the device vendor...).

> >>>>

> >>>> Any opinion on that?

> >>>>

> >>>> Cheers,

> >>>>

> >>>> Xavier

> >>>>

> >>>> PS: I will be ready to present the slides on Thursday=
 if time

> >>>> permits it.

> >>>>

> >>>> (c.f.

> >>>> http://tools.ietf.org/agenda/86/slid=
es/slides-86-rtcweb-6.pdf

> >>>>

> >>>>

> )

> >>>>

> >>>>

> >>>>

> >>>> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie <ted.ietf@gmail.com

> >>>> <mailto:ted.=
ietf@gmail.com>> wrote:

> >>>>

> >>>> Magnus and I discussed this this morning, and we

> encourage you to

> >>>> prepare something. =A0If the discussion of working gr=
oup last call

> >>>> items runs short, we may be able to fit this in at th=
at

> time or at

> >>>> the end of day one if its full agenda his finished.
> This is not a

> >>>> commitment, however, so please try and get discussion=
 on

> the list

> >>>> on the points from the draft you feel need resolution=
.

> >>>>

> >>>> regards,

> >>>>

> >>>> Ted

> >>>>

> >>>>

> >>>> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeber=
g)

> >>>> <espeberg@ci=
sco.com <mailto:espeberg@cisco=
.com>> wrote:

> >>>>> Hello,

> >>>>>

> >>>>>

> >>>>>

> >>>>> I would like to request agenda time for:

> >>>>>

> >>>>>

> >>>>>

> >>>>> draft-marjou-rtcweb-audio-codecs-for-interop-01
> >>>>>

> >>>>>

> >>>>>

> >>>>> The document =A0presents use-cases underlining wh=
y WebRTC needs

> >>>> AMR-WB, =A0AMR

> >>>>> and G.722 as additional relevant voice codecs to =
satisfactorily

> >>>>> ensure interoperability with existing systems.
> >>>>>

> >>>>>

> >>>>>

> >>>>> A 10-minute time slot should be sufficient for pr=
esentation and

> >>>> discussion.

> >>>>>

> >>>>>

> >>>>>

> >>>>> Regards

> >>>>>

> >>>>>

> >>>>>

> >>>>> -Espen

> >>>>>

> >>>>>

> >>>>>

> >>>>>

> >>>>>

> >>>>>

> >>>>> _______________________________________________ r=
tcweb

> > mailing list

> >>>>> rtcweb@ietf.or=
g <mailto:rtcweb@ietf.org>=


> >>>>> https://www.ietf.org/mailman/listinfo/rtcweb<=
br>
> >>>>>

> >>>> _______________________________________________ rtcwe=
b

> > mailing list

> >>>> rtcweb@ietf.org <mailto:rtcweb@ietf.org>

> >>>> https://www.ietf.org/mailman/listinfo/rtcweb

> >>>>

> >>>>

> >>>>

> >>>>

> >>>> _______________________________________________ rtcwe=
b

> > 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

> >>

> >> ___________________________________________________________
> >> ___________________________________________________________ _=
__

> >>

> >> Ce message et ses pieces jointes peuvent contenir des informa=
tions

> >> confidentielles ou privilegiees et ne doivent donc pas

> etre diffuses,

> >> exploites ou copies sans autorisation. Si vous avez recu

> ce message

> >> par erreur, veuillez le signaler a l'expediteur et le

> detruire ainsi

> >> que les pieces jointes. Les messages electroniques etant

> susceptibles

> >> d'alteration, France Telecom - Orange decline toute

> responsabilite si

> >> ce message a ete altere, deforme ou falsifie. Merci.

> >>

> >> This message and its attachments may contain confidential or<=
br>
> >> privileged information that may be protected by law; they

> should not

> >> be distributed, used or copied without authorisation. If you =
have

> >> received this email in error, please notify the sender and de=
lete

> >> this message and its attachments. As emails may be altered, F=
rance

> >> Telecom - Orange is not liable for messages that have been
> modified,

> >> changed or falsified. Thank you.

> >>

> >> _______________________________________________ rtcweb

> mailing list

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

> >

> >

> ______________________________________________________________________=


> > ___________________________________________________

> >

> > =A0Ce message et ses pieces jointes peuvent contenir des informat=
ions

> > confidentielles ou privilegiees et ne doivent donc pas etre

> diffuses,

> > exploites ou copies sans autorisation. Si vous avez recu ce messa=
ge

> > par erreur, veuillez le signaler a l'expediteur et le

> detruire ainsi

> > que les pieces jointes. Les messages electroniques etant

> susceptibles

> > d'alteration, France Telecom - Orange decline toute

> responsabilite si

> > ce message a ete altere, deforme ou falsifie. Merci.

> >

> > This message and its attachments may contain confidential or

> > privileged information that may be protected by law; they

> should not

> > be distributed, used or copied without authorisation. If you have=


> > received this email in error, please notify the sender and

> delete this

> > message and its attachments. As emails may be altered,

> France Telecom

> > - Orange is not liable for messages that have been

> modified, changed

> > or falsified. Thank you.

> >

> > _______________________________________________ rtcweb mailing li=
st

> > rtcweb@ietf.org https://ww=
w.ietf.org/mailman/listinfo/rtcweb

> >

> >

> ---------------------------------------------------------------------<=
br>
> >

> >

> This transmission (including any attachments) may contain confidential=


> information, privileged material (including material protected by the<=
br>
> solicitor-client or other applicable privileges), or constitute

> non-public information.

> Any use of this information by anyone other than the intended

> recipient is prohibited. If you have received this transmission in

> error, please immediately reply to the sender and delete this

> information from your system. Use, dissemination, distribution, or

> reproduction of this transmission by unintended recipients is not

> authorized and may be unlawful.

> >

> >

> ______________________________________________________________________=


> > ___________________________________________________

> >

> > =A0Ce message et ses pieces jointes peuvent contenir des informat=
ions

> > confidentielles ou privilegiees et ne doivent donc pas etre

> diffuses,

> > exploites ou copies sans autorisation. Si vous avez recu ce messa=
ge

> > par erreur, veuillez le signaler a l'expediteur et le

> detruire ainsi

> > que les pieces jointes. Les messages electroniques etant

> susceptibles

> > d'alteration, France Telecom - Orange decline toute

> responsabilite si

> > ce message a ete altere, deforme ou falsifie. Merci.

> >

> > This message and its attachments may contain confidential or

> > privileged information that may be protected by law; they

> should not

> > be distributed, used or copied without authorisation. If you have=


> > received this email in error, please notify the sender and

> delete this

> > message and its attachments. As emails may be altered,

> France Telecom

> > - Orange is not liable for messages that have been

> modified, changed

> > or falsified. Thank you.

> >

>

> -----BEGIN PGP SIGNATURE-----

> Version: GnuPG v1.4.13 (GNU/Linux)

> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

>

> iQEcBAEBAgAGBQJRQVgzAAoJEJ6/8sItn9q9fgYH/jcWfhRrvPM1hJ22YcE7eR0N

> OZzP/RvSrUBiIA6kG+6+Hvn5Lp/tXd+LxUDp5L8B3Toce7TBBAYNJP3M2cr8N8It

> SjVvPHtBNKEqhBLbI4FbAouvymNH4utjAWR+MmF9LRySPXZ9nxLN0A13TeUlpZxt

> Jaxr/n9AWwkKOk6BIo1Xztbk26MObiGVLhCE+CPoHaHe29bKblPcphBXC935ymHS

> SuF2DXiAq0iKwZoVOsLe3RIaGg+bjN7N2MXi3Vphr7cOQK+JpdxURDrvmPh7/L8R

> ht1RJt928yl4fEjnKhSKJLd1J+gPBe6vnkSxUp89as03bLirLwN1G2giD3YzfLM=3D

> =3DK56v

> -----END PGP SIGNATURE-----

>

> ______________________________________________________________

> ___________________________________________________________

>

> Ce message et ses pieces jointes peuvent contenir des informations

> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,<=
br>
> exploites ou copies sans autorisation. Si vous avez recu ce message
> par erreur, veuillez le signaler a l'expediteur et le detruire ain=
si

> que les pieces jointes. Les messages electroniques etant susceptibles<=
br>
> d'alteration, France Telecom - Orange decline toute responsabilite=
 si

> ce message a ete altere, deforme ou falsifie. Merci.

>

> This message and its attachments may contain confidential or

> privileged information that may be protected by law; they should not
> be distributed, used or copied without authorisation.

> If you have received this email in error, please notify the sender and=


> delete this message and its attachments.

> As emails may be altered, France Telecom - Orange is not liable for
> messages that have been modified, changed or falsified.

> Thank you.

>

> _______________________________________________

> 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

>

> ---------------------------------------------------------------------<=
br>
> This transmission (including any attachments) may contain confidential=


> information, privileged material (including material protected by the<=
br>
> solicitor-client or other applicable privileges), or constitute

> non-public information.

> Any use of this information by anyone other than the intended

> recipient is prohibited. If you have received this transmission in

> error, please immediately reply to the sender and delete this

> information from your system. Use, dissemination, distribution, or

> reproduction of this transmission by unintended recipients is not

> authorized and may be unlawful.

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb

>



---------------------------------------------------------------------

This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.





_______________________________________________________________=
__________________________________________________________




Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,

France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and dele=
te this message and its attachments.

As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.

Thank you.



_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

=
https://www.ietf.org/mailman/listinfo/rtcweb





--f46d0438914b3321bc04d7f97b43--

From Bernhard.Feiten@telekom.de  Fri Mar 15 10:00: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 4037D21F8775 for ; Fri, 15 Mar 2013 10:00:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.949
X-Spam-Level: 
X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_LOAN=2.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 jrWIu2a1u3XV for ; Fri, 15 Mar 2013 10:00:36 -0700 (PDT)
Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id F23E321F88B9 for ; Fri, 15 Mar 2013 09:59:58 -0700 (PDT)
X-Mailbb-Crypt: true
Received: from he111469.emea1.cds.t-internal.com (HELO he111469) ([10.175.91.11]) by tcmail41.telekom.de with ESMTP; 15 Mar 2013 17:59:42 +0100
Received: from TCMAIL11.dmznet.de.t-internal.com ([10.175.242.132]) by TrustMail (Totemo SMTP Server) with SMTP ID 28; Fri, 15 Mar 2013 17:59:41 +0100 (CET)
X-Mailbb-Crypt: true
X-Mailbb-SentCrypt: true
Received: from he111296.emea1.cds.t-internal.com ([10.125.90.14]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 15 Mar 2013 17:59:40 +0100
Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.94]) by HE111296.EMEA1.CDS.T-INTERNAL.COM ([fe80::19ac:3fb4:a382:6df4%16]) with mapi; Fri, 15 Mar 2013 17:59:40 +0100
From: 
To: , , , , 
Date: Fri, 15 Mar 2013 17:59:37 +0100
Thread-Topic: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIHAg2ECP5H1T90qzFszqZMyAx5ilHxjg///23wCAAH5yAIAACmiAgADS7YCAAFcAAIAAHUoAgAAS5VA=
Message-ID: 
References:   <580BEA5E3B99744AB1F5BFF5E9A3C67D16E4408A5A@HE111648.emea1.cds.t-internal.com>  <4507_1363362629_51434345_4507_361_1_6af2514e-a2f2-4248-b7a9-5d0452f3abf7@PEXCVZYH02.corporate.adroot.infra.ftgroup>
In-Reply-To: <4507_1363362629_51434345_4507_361_1_6af2514e-a2f2-4248-b7a9-5d0452f3abf7@PEXCVZYH02.corporate.adroot.infra.ftgroup>
Accept-Language: de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: xavier.marjou@orange.com, rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 15 Mar 2013 17:00:38 -0000

Hi,

+1
I support to have a general statement as given below and I very much suppor=
t to state which cases and codecs would be important to be supported. This =
also would make clear to the implementer what relevance and potential the i=
mplementation of a certain codec for WebRTC has.

Best regards,
Bernhard Feiten


-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of=
 stephane.proust@orange.com
Sent: Freitag, 15. M=E4rz 2013 16:50
To: Andrew Allen; Jesske, Roland; koen.vos@skype.net; espeberg@cisco.com
Cc: rtcweb@ietf.org; MARJOU Xavier OLNC/OLN
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01

Hello

As mentioned earlier, this kind of general statement makes sense and would =
be acceptable for us only if it gives some minimum guidance on what "suitab=
le" means. It means: the codecs that are especially important to be conside=
red because their support would solve the interoperability issue for a huge=
 number of calls and because they can be made available to the browsers on =
a high number of devices:

"If other suitable audio codecs are available to the browser to use it is r=
ecommended that they are also included in the offer in order to maximize th=
e possibility to establish the session without the need for audio transcodi=
ng."
This is especially the case for AMR and AMR-WB for interoperability with 3G=
PP mobile devices and G.722 for interoperability with fixed ETSI/DECT CAT-i=
q devices


Stephane Proust



-----Message d'origine-----
De : Andrew Allen [mailto:aallen@blackberry.com] Envoy=E9 : vendredi 15 mar=
s 2013 15:56 =C0 : R.Jesske@telekom.de; koen.vos@skype.net; espeberg@cisco.=
com; PROUST Stephane OLNC/OLPS Cc : MARJOU Xavier OLNC/OLN; rtcweb@ietf.org=
 Objet : RE: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01

Roland

I have proposed that we add the following text to address the interoperabil=
ity concerns

"If other suitable audio codecs are available to the browser to use it is r=
ecommended that they are also included in the offer in order to maximize th=
e possibility to establish the session without the need for audio transcodi=
ng."

The MTI Audio Codecs are defined to ensure a basic level of interoperabilit=
y and will need to be always supported for that reason. Support for additio=
nal audio codecs is an implementation and business case decision and the ad=
ditional audio codecs that it makes sense to support will change over time =
(as codecs become obsolete and new ones are developed and deployed. So addi=
tional audio codecs should not be specified in the RTCweb RFCs.

Andrew

-----Original Message-----
From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]
Sent: Friday, March 15, 2013 5:45 AM
To: Andrew Allen; koen.vos@skype.net; espeberg@cisco.com; stephane.proust@o=
range.com
Cc: xavier.marjou@orange.com; rtcweb@ietf.org
Subject: AW: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01

Hi Andrew,
but where will you start and where will you end.
The codec discussion appears now so why not try to solve this now?
And one proposal is to use these codecs and I fully support it.

Roland

> -----Urspr=FCngliche Nachricht-----
> Von: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] Im
> Auftrag von Andrew Allen
> Gesendet: Donnerstag, 14. M=E4rz 2013 22:10
> An: koen.vos@skype.net; espeberg@cisco.com; stephane.proust@orange.com
> Cc: xavier.marjou@orange.com; rtcweb@ietf.org
> Betreff: Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
>
> Koen is right that there are many more obstacles to RTCweb and legacy
> network interop than just a common codec. First there will need to be
> RTCweb signaling gateways to interface between the RTCweb signaling
> and the legacy networks (SIP,
> H.323 etc) and there will need to be in place mechanisms for peering,
> federation and address resolution between networks as well as service
> agreements in place between the players.
>
> Until those are resolved supporting codecs used in those networks is
> pointless.
>
> Andrew
>
> ----- Original Message -----
> From: Koen Vos [mailto:koen.vos@skype.net]
> Sent: Thursday, March 14, 2013 03:32 PM Central Standard Time
> To: Espen Berger (espeberg) ;
> stephane.proust@orange.com 
> Cc: rtcweb@ietf.org ; MARJOU Xavier OLNC/OLN
> 
> Subject: Re: [rtcweb] Agenda time     request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> > It's interop with billions of mobile phones and with fixed
> terminals in legacy telephony services.
>
> The problem is that WebRTC and legacy services live in separate
> networks: the open Web vs proprietary Telco networks.
>
> WebRTC connecting to a Telco network would have to go through a
> Gateway.  The PSTN termination providers who run these Gateways
> support G.711, G.729 and perhaps some other  codecs like iLBC.  They
> do not, however, support the codecs you are advocating for.
>
> The lack of support for Transcoding-Free Operation by Telcos to the
> rest of the world has been hurting interop voice quality for a long
> time, but unfortunately we can't fix that here at the IETF.
>
> We can fit our cars with your costly railroad wheels, but you still
> wouldn't let us on your tracks.
>
> koen.
>
>
> -----Original Message-----
> From: rtcweb-bounces@ietf.org
> [mailto:rtcweb-bounces@ietf.org] On Behalf Of
> stephane.proust@orange.com
> Sent: 14. mars 2013 13:36
> To: Jean-Marc Valin
> Cc: rtcweb@ietf.org; MARJOU Xavier OLNC/OLN
> Subject: Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> Hello
>
> The short list is aligned to what is specified in 3GPP
> (mobile) and CAT-iq (fixed). Check the related service specifications!
> The short list (AMR, AMR-WB, G.722) is a minimal subset of codecs to
> minimize interop issues and transcoding costs for telco services.
> It's not a question of what's the favourite codec for a given
> application. It's interop with billions of mobile phones and with
> fixed terminals in legacy telephony services.
>
> St=E9phane
>
> -----Message d'origine-----
> De : Jean-Marc Valin [mailto:jmvalin@mozilla.com] Envoy=E9 :
> jeudi 14 mars 2013 05:55 =C0 : PROUST Stephane OLNC/OLPS Cc :
> Andrew Allen; Markus.Isomaki@nokia.com; MARJOU Xavier OLNC/OLN;
> rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/13/2013 06:48 PM, stephane.proust@orange.com wrote:
> > The reason is simply that AMR and AMR-WB are supported in
> billions of
> > devices !
>
> Just curious, why exclude from the list other codecs with similar huge
> deployment? I can think of at least:
> - - GSM-FR (mobile)
> - - Speex (Flash)
> - - G.729 (PSTN gateways)
> - - iLBC (PSTN gateways)
> - - G.726 (DECT)
> - - SILK (original non-Opus version in Skype)
>
> (sorry, if I missed someone's favorite codec in this list)
>
> It's not at all clear to me what's so special that makes AMR, AMR-WB
> and G.722 different from the other codecs in the list above. Not that
> I insist on shipping G.729 :-)
>
> Personally, I'd favor a draft that included a lot more codecs,
> describing for each one the benefits of supporting it. Implementers
> could then choose which of these they care about for their particular
> situation.
>
> Cheers,
>
>         Jean-Marc
>
> > St=E9phane
> >
> >
> > -----Message d'origine----- De : Andrew Allen
> > [mailto:aallen@blackberry.com] Envoy=E9 : mercredi 13 mars 2013
> > 23:41 =C0 : PROUST Stephane OLNC/OLPS; Markus.Isomaki@nokia.com;
> > jmvalin@mozilla.com Cc : MARJOU Xavier OLNC/OLN;
> rtcweb@ietf.org Objet
> > : Re: [rtcweb] Agenda time request for
> > draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> >
> > No this wouldn't be acceptable to me.
> >
> > I don't see a reason to push a particular set of Codecs
> over any other
> > set of codecs supported on the device. If the device supports the
> > codecs and they are available to the browser then we should
> recommend
> > that they be offered in the negotiation.
> >
> > The marjou draft can advertise the merits and reasons why they are
> > good codecs to support.
> >
> >
> > ----- Original Message ----- From: stephane.proust@orange.com
> > [mailto:stephane.proust@orange.com] Sent: Wednesday, March 13, 2013
> > 05:14 PM Central Standard Time To: Markus.Isomaki@nokia.com
> > ; jmvalin@mozilla.com
> 
> > Cc: MARJOU Xavier OLNC/OLN ;
> rtcweb@ietf.org
> > 
> > Subject: Re: [rtcweb] Agenda time     request for
> > draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> > Dear Markus
> >
> > Thanks for your attempt to help !
> >
> > Of course each Telco can handle this directly with vendors and
> > browsers manufacturers at business level. But I don't'think
> this need
> > of interoperability with mobile devices is specific to Orange.
> > I think all mobile operators will have the same issue and
> this is why
> > standardization exist. It's most cost and time efficient to
> have one
> > common way forward for all the industry.
> >
> > Then if the issue is that "conditional MUST/SHOULD are a too
> > complicated requirement. We could also live as a compromise with a
> > formulation that has already been suggested on the reflector:
> >
> > "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" If possible with the addition of This is
> especially
> > the case for AMR, AMR-WB for interoperability with mobile
> devices and
> > G.722 for interoperability with fixed DECT CAT-iq devices
> >
> > Would it have one chance to reach consensus ?
> >
> > I think this Group should at least make one small step so that the
> > interoperability issue with mobile terminals be not fully
> ignored in
> > the RTC Web specification considering the huge number of deployed
> > devices. At least something must be written on this !
> > G.711 which is the only codec in addition to OPUS for
> interoperability
> > purpose is not a proper answer to this.
> >
> > St=E9phane
> >
> > -----Message d'origine----- De : Markus.Isomaki@nokia.com
> > [mailto:Markus.Isomaki@nokia.com] Envoy=E9 : mercredi 13 mars 2013
> > 22:37 =C0 : PROUST Stephane OLNC/OLPS; jmvalin@mozilla.com; MARJOU
> > Xavier OLNC/OLN Cc : rtcweb@ietf.org Objet : RE: [rtcweb]
> Agenda time
> > request for draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> > Hi Stephane, Xavier,
> >
> > I understand the intent of your proposal. I'm not sure if
> the IETF is
> > the best venue for you to pursue it, however. Perhaps you
> as a mobile
> > operator should rather set it as a requirement to your
> mobile device
> > platforms that they open up the APIs to AMR and AMR-WB and that at
> > least the in-built default browser needs to support it. If
> there are
> > enough operators setting such requirements directly to the
> device and
> > platform vendors, it probably has a bigger impact than an IETF RFC.
> > Getting that support for user-installed additional browsers
> might be
> > more difficult, but most mobile device users stick with the default
> > browser anyway.
> >
> > The RTCWEB codec document needs to definitely explain this case and
> > the benefits, but the conditional MUSTs or SHOULDs you are
> proposing
> > are perhaps a bit too complicated. Hmm, perhaps we need to do an
> > _informational_ RFC as something like "Recommendations for
> WebRTC on
> > Mobile Devices" addressing the codec and perhaps other issues, that
> > you could use as a reference in your requirements.
> >
> > Markus
> >
> >
> >> -----Original Message----- From: rtcweb-bounces@ietf.org
> >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext
> >> stephane.proust@orange.com Sent: 13 March, 2013 21:37 To:
> >> Jean-Marc Valin; MARJOU Xavier OLNC/OLN Cc: rtcweb@ietf.org
> >> Subject: Re: [rtcweb] Agenda time request for
> >> draft-marjou-rtcweb-audio- codecs-for-interop-01
> >>
> >> Hello
> >>
> >> Our understanding is that the reason of the "no consensus" on
> >> additional recommended codecs was the additional costs for
> browsers.
> >> The proposal is then to make these "MUST" fully conditional to the
> >> case of no (or very reduced) additional costs, when the codecs are
> >> already available on the device and when no additional
> license fee is
> >> required
> >>
> >> We could even live with lower level of "requirements" with
> >> respectively May and Should (instead of Should and shall) but we
> >> think that this proposal is a way to take into account
> both browser
> >> manufacturers concerns on browsers costs and telcos concerns on
> >> transcoding costs and some other companies share this view.
> >>
> >> St=E9phane
> >>
> >>
> >>
> >>
> >>
> >>
> >> -----Message d'origine----- De : rtcweb-bounces@ietf.org
> >> [mailto:rtcweb-bounces@ietf.org] De la part de Jean-Marc
> Valin Envoy=E9
> >> : mercredi 13 mars 2013 20:24 =C0 : MARJOU Xavier OLNC/OLN Cc :
> >> rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time request for
> >> draft-marjou-rtcweb-audio-codecs-for-interop-01
> >>
> > Hi,
> >
> > I'd really like to understand how the chairs coming to the
> conclusion
> > that there was *no consensus* on recommended codecs can result in a
> > draft that includes 3 MUSTs and 1 SHOULD. This draft
> effectively makes
> > 3 new codecs MTI for a range of devices. I understand that it's an
> > individual draft and you can write whatever you like in
> there, but it
> > definitely goes against the result of the WG discussion.
> >
> > Cheers,
> >
> > Jean-Marc
> >
> > On 03/13/2013 09:14 AM, Xavier Marjou wrote:
> >>>> Here is a summary of the
> >>>> draft-marjou-rtcweb-audio-codecs-for-interop-00
> presentation that I
> >>>> had prepared for yesterday's session:
> >>>>
> >>>> - The co-authors want to underline that non-WebRTC voice
> endpoints
> >>>> usually use one of the following codecs: AMR, AMR-WB or G.722,
> >>>> which will result in massive transcoding when there will be
> >>>> communications between WebRTC endpoints and non-WebRTC endpoints.
> >>>>
> >>>> - On one side, transcoding is bad for many reasons
> discussed in the
> >>>> draft (cost issues, intrinsic quality degradation, degraded
> >>>> interactivity, fallback from HD to G.711...);
> >>>>
> >>>> - On the other side, it is recognized that implementing
> additional
> >>>> codecs in the browsers can generate additional costs.
> >>>>
> >>>> - In order to reach a compromise, we would like to add
> some text in
> >>>> the WG draft draft-ietf-rtcweb-audio providing
> incentives for the
> >>>> browser to use these three codecs: make them mandatory
> to implement
> >>>> when there is no cost impact on the browser (e.g. if
> codec already
> >>>> installed, paid by the device vendor...).
> >>>>
> >>>> Any opinion on that?
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Xavier
> >>>>
> >>>> PS: I will be ready to present the slides on Thursday if time
> >>>> permits it.
> >>>>
> >>>> (c.f.
> >>>> http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf
> >>>>
> >>>>
> )
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie  >>>> > wrote:
> >>>>
> >>>> Magnus and I discussed this this morning, and we
> encourage you to
> >>>> prepare something.  If the discussion of working group last call
> >>>> items runs short, we may be able to fit this in at that
> time or at
> >>>> the end of day one if its full agenda his finished.
> This is not a
> >>>> commitment, however, so please try and get discussion on
> the list
> >>>> on the points from the draft you feel need resolution.
> >>>>
> >>>> regards,
> >>>>
> >>>> Ted
> >>>>
> >>>>
> >>>> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)
> >>>> > wrote:
> >>>>> Hello,
> >>>>>
> >>>>>
> >>>>>
> >>>>> I would like to request agenda time for:
> >>>>>
> >>>>>
> >>>>>
> >>>>> draft-marjou-rtcweb-audio-codecs-for-interop-01
> >>>>>
> >>>>>
> >>>>>
> >>>>> The document  presents use-cases underlining why WebRTC needs
> >>>> AMR-WB,  AMR
> >>>>> and G.722 as additional relevant voice codecs to satisfactorily
> >>>>> ensure interoperability with existing systems.
> >>>>>
> >>>>>
> >>>>>
> >>>>> A 10-minute time slot should be sufficient for presentation and
> >>>> discussion.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Regards
> >>>>>
> >>>>>
> >>>>>
> >>>>> -Espen
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________ 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
> >>
> >> ___________________________________________________________
> >> ___________________________________________________________ ___
> >>
> >> Ce message et ses pieces jointes peuvent contenir des informations
> >> confidentielles ou privilegiees et ne doivent donc pas
> etre diffuses,
> >> exploites ou copies sans autorisation. Si vous avez recu
> ce message
> >> par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> >> que les pieces jointes. Les messages electroniques etant
> susceptibles
> >> d'alteration, France Telecom - Orange decline toute
> responsabilite si
> >> ce message a ete altere, deforme ou falsifie. Merci.
> >>
> >> This message and its attachments may contain confidential or
> >> privileged information that may be protected by law; they
> should not
> >> be distributed, used or copied without authorisation. If you have
> >> received this email in error, please notify the sender and delete
> >> this message and its attachments. As emails may be altered, France
> >> Telecom - Orange is not liable for messages that have been
> modified,
> >> changed or falsified. Thank you.
> >>
> >> _______________________________________________ rtcweb
> mailing list
> >> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> ______________________________________________________________________
> > ___________________________________________________
> >
> >  Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> > que les pieces jointes. Les messages electroniques etant
> susceptibles
> > d'alteration, France Telecom - Orange decline toute
> responsabilite si
> > ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they
> should not
> > be distributed, used or copied without authorisation. If you have
> > received this email in error, please notify the sender and
> delete this
> > message and its attachments. As emails may be altered,
> France Telecom
> > - Orange is not liable for messages that have been
> modified, changed
> > or falsified. Thank you.
> >
> > _______________________________________________ rtcweb mailing list
> > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> ---------------------------------------------------------------------
> >
> >
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
> non-public information.
> Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in
> error, please immediately reply to the sender and delete this
> information from your system. Use, dissemination, distribution, or
> reproduction of this transmission by unintended recipients is not
> authorized and may be unlawful.
> >
> >
> ______________________________________________________________________
> > ___________________________________________________
> >
> >  Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> > que les pieces jointes. Les messages electroniques etant
> susceptibles
> > d'alteration, France Telecom - Orange decline toute
> responsabilite si
> > ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they
> should not
> > be distributed, used or copied without authorisation. If you have
> > received this email in error, please notify the sender and
> delete this
> > message and its attachments. As emails may be altered,
> France Telecom
> > - Orange is not liable for messages that have been
> modified, changed
> > or falsified. Thank you.
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJRQVgzAAoJEJ6/8sItn9q9fgYH/jcWfhRrvPM1hJ22YcE7eR0N
> OZzP/RvSrUBiIA6kG+6+Hvn5Lp/tXd+LxUDp5L8B3Toce7TBBAYNJP3M2cr8N8It
> SjVvPHtBNKEqhBLbI4FbAouvymNH4utjAWR+MmF9LRySPXZ9nxLN0A13TeUlpZxt
> Jaxr/n9AWwkKOk6BIo1Xztbk26MObiGVLhCE+CPoHaHe29bKblPcphBXC935ymHS
> SuF2DXiAq0iKwZoVOsLe3RIaGg+bjN7N2MXi3Vphr7cOQK+JpdxURDrvmPh7/L8R
> ht1RJt928yl4fEjnKhSKJLd1J+gPBe6vnkSxUp89as03bLirLwN1G2giD3YzfLM=3D
> =3DK56v
> -----END PGP SIGNATURE-----
>
> ______________________________________________________________
> ___________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> que les pieces jointes. Les messages electroniques etant susceptibles
> d'alteration, France Telecom - Orange decline toute responsabilite si
> ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should not
> be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for
> messages that have been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> 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
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
> non-public information.
> Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in
> error, please immediately reply to the sender and delete this
> information from your system. Use, dissemination, distribution, or
> reproduction of this transmission by unintended recipients is not
> authorized and may be unlawful.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou =
copies sans autorisation. Si vous avez recu ce message par erreur, veuillez=
 le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le=
s messages electroniques etant susceptibles d'alteration, France Telecom - =
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law; they should not be distributed, used=
 or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.

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

From prvs=4786c35e20=aallen@blackberry.com  Fri Mar 15 10:03: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 0469B21F8463 for ; Fri, 15 Mar 2013 10:03:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.395
X-Spam-Level: 
X-Spam-Status: No, score=-3.395 tagged_above=-999 required=5 tests=[AWL=-0.807, BAYES_00=-2.599, MANGLED_LOAN=2.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76VurvqwSE+H for ; Fri, 15 Mar 2013 10:03:41 -0700 (PDT)
Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 13D0721F85AD for ; Fri, 15 Mar 2013 10:03:39 -0700 (PDT)
X-AuditID: 0a412830-b7ef86d00000339d-2a-5143546283dd
Received: from XCT104ADS.rim.net (xct104ads.rim.net [10.67.111.45]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 92.E9.13213.26453415; Fri, 15 Mar 2013 12:03:30 -0500 (CDT)
Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.02.0328.009; Fri, 15 Mar 2013 12:03:29 -0500
From: Andrew Allen 
To: "stephane.proust@orange.com" , "R.Jesske@telekom.de" , "koen.vos@skype.net" , "espeberg@cisco.com" 
Thread-Topic: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIHAgQ3Oi2P7DjEKDSnUvQoKufpilc9aAgAAGtgCAAH5yAP//tpYYgADR0CCAAFbNYIAAZFUA//+ucTiAAFaWgP//u5kB
Date: Fri, 15 Mar 2013 17:03:28 +0000
Message-ID: 
In-Reply-To: <15570_1363363711_5143477F_15570_5387_1_61f74e36-8baf-42a5-b86d-d947dd4f193f@PEXCVZYH02.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.253]
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFKsWRmVeSWpSXmKPExsXC5Zyvq5sU4hxosPWCtcWXhmSL1p/fmC2a 7nSxWaz9185u0TrjCpvFka1rmR3YPKb83sjqsWTJTyaPlmcn2TxuPZjE5tH2UiGANaqB0SYp saQsODM9T9/OJjEvL78ksSRVISW1ONlWySc1PTFHIaAosywxuVLBJbM4OScxMze1SEkhM8VW yURJoSAnMTk1NzWvxFYpsaAgNS9FyY5LAQPYAJVl5imk5iXnp2TmpdsqeQb761pYmFrqGirZ 6SZ08mR8ufKErWDhD8aKnkvbWBsYV55h7GLk5JAQMJFYOnMHC4QtJnHh3nq2LkYuDiGBNiaJ K2dnskA4mxklFm97D9bBJqAlsf/wdCaQhIjAEUaJI292gyWYBRIkOhYtZe5i5OAQFoiXaD5V CBIWAQpP+TGHGcLOk7jYchTMZhFQlWh61Q9m8wp4SLS1L2IEmckp0MIo8fL4LlaQBCPQSd9P rWGCmC8ucevJfCaIUwUkluw5zwxhi0q8fPyPFcJWlPi79zsrRL2exI2pU9ggbG2JZQtfQy0T lDg58wnLBEbRWUjGzkLSMgtJyywkLQsYWVYxCuZmFBuYGSbnJesVZebq5aWWbGIEJRZHDYMd jO/fWxxiFOBgVOLh1QpwDhRiTSwrrsw9xCjBwawkwvtOHyjEm5JYWZValB9fVJqTWnyI0RUY FBOZpbiT84FJL68k3tjAADdHSZy3TNMpUEggHZiEslNTC1KLYOYwcXCC7OGSEikGppLUosTS kox4UMKLLwamPKkGxhZVjQ6/J4ylSzYZbTmvoG4p+VZg/WWFDRXMMbUnRb3OhyoFSe7ZFWLR yVo410DhU9wD3QdPg1hT/9R7/pJ7+3XNleQJNY/XZJq6reNZs+bPHLETHm+yHC/a3jHTtHks c2wnk0TQ9Ig7Kr9/XrBaGzLdXNhd1f+pVVPY6oLCHXckp7z38+B/rcRSnJFoqMVcVJwIAC+K nh5tAwAA
Cc: "rtcweb@ietf.org" , "xavier.marjou@orange.com" 
Subject: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 15 Mar 2013 17:03:45 -0000

Stephane

I don't think the numbers of devices currently supported is relevant. As has=
 already been pointed out these are snapshots in time. We are writing a stan=
dard for the next 20 years at least and 20 years ago GSM would have been one=
 of the codecs that some people would have been advocating as the most impor=
tant.

I think realistically browsers are not likely to natively support encumbered=
 codecs like AMR regardless whether we recomend it in RTCweb or not, but all=
 mobile devices will support AMR (at least in the near term) and I fully exp=
ect those devices will have a browser that has access to the embedded AMR co=
dec which will I think mostly address your use case.

Andrew. 



----- Original Message -----
From: stephane.proust@orange.com [mailto:stephane.proust@orange.com]
Sent: Friday, March 15, 2013 11:08 AM Central Standard Time=0A=
To: Andrew Allen; R.Jesske@telekom.de ; koen.vos@skype.=
net ; espeberg@cisco.com 
Cc: MARJOU Xavier OLNC/OLN ; rtcweb@ietf.org 
Subject: RE: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-code=
cs-for-interop-01

>>we shouldn't give the impression that its more important to include some c=
odecs than others that are available to the browser to use.

But Why shouldn't we give that impression ?

Because obviously YES it is more important to support codecs that are implem=
ented in billions of devices and the support of which will improve the quali=
ty for millions of customers and reduce the costs in networks than codecs of=
 specific and limited usage.

And since AMR AMR-WB stay the mandatory codecs for 4G VoLTE I don't think th=
e importance of these codecs can ben challenged for the future

St=E9phane


-----Message d'origine-----
De=A0: Andrew Allen [mailto:aallen@blackberry.com] 
Envoy=E9=A0: vendredi 15 mars 2013 16:58
=C0=A0: PROUST Stephane OLNC/OLPS; R.Jesske@telekom.de; koen.vos@skype.net;=
 espeberg@cisco.com
Cc=A0: MARJOU Xavier OLNC/OLN; rtcweb@ietf.org
Objet=A0: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01


Suitable to me means suitable for the application context i.e if the applica=
tion is conversational real time audio then all audio codecs suitable for co=
nversational real time audio the browser has the ability to use are recommen=
ded to be included in the offer.

I don't agree to mention specific codecs - all codecs that meet the suitabil=
ity for the application apply and we shouldn't give the impression that its=
 more important to include some codecs than others that are available to the=
 browser to use. 


----- Original Message -----
From: stephane.proust@orange.com [mailto:stephane.proust@orange.com]
Sent: Friday, March 15, 2013 10:50 AM Central Standard Time
To: Andrew Allen; R.Jesske@telekom.de ; koen.vos@skype.=
net ; espeberg@cisco.com 
Cc: MARJOU Xavier OLNC/OLN ; rtcweb@ietf.org 
Subject: RE: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-code=
cs-for-interop-01

Hello

As mentioned earlier, this kind of general statement makes sense and would b=
e acceptable for us only if it gives some minimum guidance on what "suitable=
" means. It means: the codecs that are especially important to be considered=
 because their support would solve the interoperability issue for a huge num=
ber of calls and because they can be made available to the browsers on a hig=
h number of devices: 

"If other suitable audio codecs are available to the browser to use it is re=
commended that they are also included in the offer in order to maximize the=
 possibility to establish the session without the need for audio transcoding=
."
This is especially the case for AMR and AMR-WB for interoperability with 3GP=
P mobile devices and G.722 for interoperability with fixed ETSI/DECT CAT-iq=
 devices


Stephane Proust



-----Message d'origine-----
De=A0: Andrew Allen [mailto:aallen@blackberry.com] Envoy=E9=A0: vendredi 15=
 mars 2013 15:56 =C0=A0: R.Jesske@telekom.de; koen.vos@skype.net; espeberg@c=
isco.com; PROUST Stephane OLNC/OLPS Cc=A0: MARJOU Xavier OLNC/OLN; rtcweb@ie=
tf.org Objet=A0: RE: [rtcweb] Agenda time request for draft-marjou-rtcweb-au=
dio-codecs-for-interop-01

Roland

I have proposed that we add the following text to address the interoperabili=
ty concerns

"If other suitable audio codecs are available to the browser to use it is re=
commended that they are also included in the offer in order to maximize the=
 possibility to establish the session without the need for audio transcoding=
."

The MTI Audio Codecs are defined to ensure a basic level of interoperability=
 and will need to be always supported for that reason. Support for additiona=
l audio codecs is an implementation and business case decision and the addit=
ional audio codecs that it makes sense to support will change over time (as=
 codecs become obsolete and new ones are developed and deployed. So addition=
al audio codecs should not be specified in the RTCweb RFCs.

Andrew

-----Original Message-----
From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]
Sent: Friday, March 15, 2013 5:45 AM
To: Andrew Allen; koen.vos@skype.net; espeberg@cisco.com; stephane.proust@or=
ange.com
Cc: xavier.marjou@orange.com; rtcweb@ietf.org
Subject: AW: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-code=
cs-for-interop-01

Hi Andrew,
but where will you start and where will you end.
The codec discussion appears now so why not try to solve this now?
And one proposal is to use these codecs and I fully support it.

Roland

> -----Urspr=FCngliche Nachricht-----
> Von: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] Im 
> Auftrag von Andrew Allen
> Gesendet: Donnerstag, 14. M=E4rz 2013 22:10
> An: koen.vos@skype.net; espeberg@cisco.com; stephane.proust@orange.com
> Cc: xavier.marjou@orange.com; rtcweb@ietf.org
> Betreff: Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
>
> Koen is right that there are many more obstacles to RTCweb and legacy 
> network interop than just a common codec. First there will need to be 
> RTCweb signaling gateways to interface between the RTCweb signaling 
> and the legacy networks (SIP,
> H.323 etc) and there will need to be in place mechanisms for peering, 
> federation and address resolution between networks as well as service 
> agreements in place between the players.
>
> Until those are resolved supporting codecs used in those networks is 
> pointless.
>
> Andrew
>
> ----- Original Message -----
> From: Koen Vos [mailto:koen.vos@skype.net]
> Sent: Thursday, March 14, 2013 03:32 PM Central Standard Time
> To: Espen Berger (espeberg) ; 
> stephane.proust@orange.com 
> Cc: rtcweb@ietf.org ; MARJOU Xavier OLNC/OLN 
> 
> Subject: Re: [rtcweb] Agenda time     request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> > It's interop with billions of mobile phones and with fixed
> terminals in legacy telephony services.
>
> The problem is that WebRTC and legacy services live in separate
> networks: the open Web vs proprietary Telco networks.
>
> WebRTC connecting to a Telco network would have to go through a 
> Gateway.  The PSTN termination providers who run these Gateways 
> support G.711, G.729 and perhaps some other  codecs like iLBC.  They 
> do not, however, support the codecs you are advocating for.
>
> The lack of support for Transcoding-Free Operation by Telcos to the 
> rest of the world has been hurting interop voice quality for a long 
> time, but unfortunately we can't fix that here at the IETF.
>
> We can fit our cars with your costly railroad wheels, but you still 
> wouldn't let us on your tracks.
>
> koen.
>
>
> -----Original Message-----
> From: rtcweb-bounces@ietf.org
> [mailto:rtcweb-bounces@ietf.org] On Behalf Of 
> stephane.proust@orange.com
> Sent: 14. mars 2013 13:36
> To: Jean-Marc Valin
> Cc: rtcweb@ietf.org; MARJOU Xavier OLNC/OLN
> Subject: Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> Hello
>
> The short list is aligned to what is specified in 3GPP
> (mobile) and CAT-iq (fixed). Check the related service specifications!
> The short list (AMR, AMR-WB, G.722) is a minimal subset of codecs to 
> minimize interop issues and transcoding costs for telco services.
> It's not a question of what's the favourite codec for a given 
> application. It's interop with billions of mobile phones and with 
> fixed terminals in legacy telephony services.
>
> St=E9phane
>
> -----Message d'origine-----
> De : Jean-Marc Valin [mailto:jmvalin@mozilla.com] Envoy=E9 :
> jeudi 14 mars 2013 05:55 =C0 : PROUST Stephane OLNC/OLPS Cc :
> Andrew Allen; Markus.Isomaki@nokia.com; MARJOU Xavier OLNC/OLN; 
> rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/13/2013 06:48 PM, stephane.proust@orange.com wrote:
> > The reason is simply that AMR and AMR-WB are supported in
> billions of
> > devices !
>
> Just curious, why exclude from the list other codecs with similar huge 
> deployment? I can think of at least:
> - - GSM-FR (mobile)
> - - Speex (Flash)
> - - G.729 (PSTN gateways)
> - - iLBC (PSTN gateways)
> - - G.726 (DECT)
> - - SILK (original non-Opus version in Skype)
>
> (sorry, if I missed someone's favorite codec in this list)
>
> It's not at all clear to me what's so special that makes AMR, AMR-WB 
> and G.722 different from the other codecs in the list above. Not that 
> I insist on shipping G.729 :-)
>
> Personally, I'd favor a draft that included a lot more codecs, 
> describing for each one the benefits of supporting it. Implementers 
> could then choose which of these they care about for their particular 
> situation.
>
> Cheers,
>
>         Jean-Marc
>
> > St=E9phane
> >
> >
> > -----Message d'origine----- De : Andrew Allen 
> > [mailto:aallen@blackberry.com] Envoy=E9 : mercredi 13 mars 2013
> > 23:41 =C0 : PROUST Stephane OLNC/OLPS; Markus.Isomaki@nokia.com; 
> > jmvalin@mozilla.com Cc : MARJOU Xavier OLNC/OLN;
> rtcweb@ietf.org Objet
> > : Re: [rtcweb] Agenda time request for
> > draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> >
> > No this wouldn't be acceptable to me.
> >
> > I don't see a reason to push a particular set of Codecs
> over any other
> > set of codecs supported on the device. If the device supports the 
> > codecs and they are available to the browser then we should
> recommend
> > that they be offered in the negotiation.
> >
> > The marjou draft can advertise the merits and reasons why they are 
> > good codecs to support.
> >
> >
> > ----- Original Message ----- From: stephane.proust@orange.com 
> > [mailto:stephane.proust@orange.com] Sent: Wednesday, March 13, 2013
> > 05:14 PM Central Standard Time To: Markus.Isomaki@nokia.com 
> > ; jmvalin@mozilla.com
> 
> > Cc: MARJOU Xavier OLNC/OLN ;
> rtcweb@ietf.org
> > 
> > Subject: Re: [rtcweb] Agenda time     request for
> > draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> > Dear Markus
> >
> > Thanks for your attempt to help !
> >
> > Of course each Telco can handle this directly with vendors and 
> > browsers manufacturers at business level. But I don't'think
> this need
> > of interoperability with mobile devices is specific to Orange.
> > I think all mobile operators will have the same issue and
> this is why
> > standardization exist. It's most cost and time efficient to
> have one
> > common way forward for all the industry.
> >
> > Then if the issue is that "conditional MUST/SHOULD are a too 
> > complicated requirement. We could also live as a compromise with a 
> > formulation that has already been suggested on the reflector:
> >
> > "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" If possible with the addition of This is
> especially
> > the case for AMR, AMR-WB for interoperability with mobile
> devices and
> > G.722 for interoperability with fixed DECT CAT-iq devices
> >
> > Would it have one chance to reach consensus ?
> >
> > I think this Group should at least make one small step so that the 
> > interoperability issue with mobile terminals be not fully
> ignored in
> > the RTC Web specification considering the huge number of deployed 
> > devices. At least something must be written on this !
> > G.711 which is the only codec in addition to OPUS for
> interoperability
> > purpose is not a proper answer to this.
> >
> > St=E9phane
> >
> > -----Message d'origine----- De : Markus.Isomaki@nokia.com 
> > [mailto:Markus.Isomaki@nokia.com] Envoy=E9 : mercredi 13 mars 2013
> > 22:37 =C0 : PROUST Stephane OLNC/OLPS; jmvalin@mozilla.com; MARJOU 
> > Xavier OLNC/OLN Cc : rtcweb@ietf.org Objet : RE: [rtcweb]
> Agenda time
> > request for draft-marjou-rtcweb-audio-codecs-for-interop-01
> >
> > Hi Stephane, Xavier,
> >
> > I understand the intent of your proposal. I'm not sure if
> the IETF is
> > the best venue for you to pursue it, however. Perhaps you
> as a mobile
> > operator should rather set it as a requirement to your
> mobile device
> > platforms that they open up the APIs to AMR and AMR-WB and that at 
> > least the in-built default browser needs to support it. If
> there are
> > enough operators setting such requirements directly to the
> device and
> > platform vendors, it probably has a bigger impact than an IETF RFC.
> > Getting that support for user-installed additional browsers
> might be
> > more difficult, but most mobile device users stick with the default 
> > browser anyway.
> >
> > The RTCWEB codec document needs to definitely explain this case and 
> > the benefits, but the conditional MUSTs or SHOULDs you are
> proposing
> > are perhaps a bit too complicated. Hmm, perhaps we need to do an 
> > _informational_ RFC as something like "Recommendations for
> WebRTC on
> > Mobile Devices" addressing the codec and perhaps other issues, that 
> > you could use as a reference in your requirements.
> >
> > Markus
> >
> >
> >> -----Original Message----- From: rtcweb-bounces@ietf.org 
> >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext 
> >> stephane.proust@orange.com Sent: 13 March, 2013 21:37 To:
> >> Jean-Marc Valin; MARJOU Xavier OLNC/OLN Cc: rtcweb@ietf.org
> >> Subject: Re: [rtcweb] Agenda time request for
> >> draft-marjou-rtcweb-audio- codecs-for-interop-01
> >>
> >> Hello
> >>
> >> Our understanding is that the reason of the "no consensus" on 
> >> additional recommended codecs was the additional costs for
> browsers.
> >> The proposal is then to make these "MUST" fully conditional to the 
> >> case of no (or very reduced) additional costs, when the codecs are 
> >> already available on the device and when no additional
> license fee is
> >> required
> >>
> >> We could even live with lower level of "requirements" with 
> >> respectively May and Should (instead of Should and shall) but we 
> >> think that this proposal is a way to take into account
> both browser
> >> manufacturers concerns on browsers costs and telcos concerns on 
> >> transcoding costs and some other companies share this view.
> >>
> >> St=E9phane
> >>
> >>
> >>
> >>
> >>
> >>
> >> -----Message d'origine----- De : rtcweb-bounces@ietf.org 
> >> [mailto:rtcweb-bounces@ietf.org] De la part de Jean-Marc
> Valin Envoy=E9
> >> : mercredi 13 mars 2013 20:24 =C0 : MARJOU Xavier OLNC/OLN Cc :
> >> rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time request for
> >> draft-marjou-rtcweb-audio-codecs-for-interop-01
> >>
> > Hi,
> >
> > I'd really like to understand how the chairs coming to the
> conclusion
> > that there was *no consensus* on recommended codecs can result in a 
> > draft that includes 3 MUSTs and 1 SHOULD. This draft
> effectively makes
> > 3 new codecs MTI for a range of devices. I understand that it's an 
> > individual draft and you can write whatever you like in
> there, but it
> > definitely goes against the result of the WG discussion.
> >
> > Cheers,
> >
> > Jean-Marc
> >
> > On 03/13/2013 09:14 AM, Xavier Marjou wrote:
> >>>> Here is a summary of the
> >>>> draft-marjou-rtcweb-audio-codecs-for-interop-00
> presentation that I
> >>>> had prepared for yesterday's session:
> >>>>
> >>>> - The co-authors want to underline that non-WebRTC voice
> endpoints
> >>>> usually use one of the following codecs: AMR, AMR-WB or G.722, 
> >>>> which will result in massive transcoding when there will be 
> >>>> communications between WebRTC endpoints and non-WebRTC endpoints.
> >>>>
> >>>> - On one side, transcoding is bad for many reasons
> discussed in the
> >>>> draft (cost issues, intrinsic quality degradation, degraded 
> >>>> interactivity, fallback from HD to G.711...);
> >>>>
> >>>> - On the other side, it is recognized that implementing
> additional
> >>>> codecs in the browsers can generate additional costs.
> >>>>
> >>>> - In order to reach a compromise, we would like to add
> some text in
> >>>> the WG draft draft-ietf-rtcweb-audio providing
> incentives for the
> >>>> browser to use these three codecs: make them mandatory
> to implement
> >>>> when there is no cost impact on the browser (e.g. if
> codec already
> >>>> installed, paid by the device vendor...).
> >>>>
> >>>> Any opinion on that?
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Xavier
> >>>>
> >>>> PS: I will be ready to present the slides on Thursday if time 
> >>>> permits it.
> >>>>
> >>>> (c.f.
> >>>> http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf
> >>>>
> >>>>
> )
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie  >>>> > wrote:
> >>>>
> >>>> Magnus and I discussed this this morning, and we
> encourage you to
> >>>> prepare something.  If the discussion of working group last call 
> >>>> items runs short, we may be able to fit this in at that
> time or at
> >>>> the end of day one if its full agenda his finished.
> This is not a
> >>>> commitment, however, so please try and get discussion on
> the list
> >>>> on the points from the draft you feel need resolution.
> >>>>
> >>>> regards,
> >>>>
> >>>> Ted
> >>>>
> >>>>
> >>>> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg) 
> >>>> > wrote:
> >>>>> Hello,
> >>>>>
> >>>>>
> >>>>>
> >>>>> I would like to request agenda time for:
> >>>>>
> >>>>>
> >>>>>
> >>>>> draft-marjou-rtcweb-audio-codecs-for-interop-01
> >>>>>
> >>>>>
> >>>>>
> >>>>> The document  presents use-cases underlining why WebRTC needs
> >>>> AMR-WB,  AMR
> >>>>> and G.722 as additional relevant voice codecs to satisfactorily 
> >>>>> ensure interoperability with existing systems.
> >>>>>
> >>>>>
> >>>>>
> >>>>> A 10-minute time slot should be sufficient for presentation and
> >>>> discussion.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Regards
> >>>>>
> >>>>>
> >>>>>
> >>>>> -Espen
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________ 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
> >>
> >> ___________________________________________________________
> >> ___________________________________________________________ ___
> >>
> >> Ce message et ses pieces jointes peuvent contenir des informations 
> >> confidentielles ou privilegiees et ne doivent donc pas
> etre diffuses,
> >> exploites ou copies sans autorisation. Si vous avez recu
> ce message
> >> par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> >> que les pieces jointes. Les messages electroniques etant
> susceptibles
> >> d'alteration, France Telecom - Orange decline toute
> responsabilite si
> >> ce message a ete altere, deforme ou falsifie. Merci.
> >>
> >> This message and its attachments may contain confidential or 
> >> privileged information that may be protected by law; they
> should not
> >> be distributed, used or copied without authorisation. If you have 
> >> received this email in error, please notify the sender and delete 
> >> this message and its attachments. As emails may be altered, France 
> >> Telecom - Orange is not liable for messages that have been
> modified,
> >> changed or falsified. Thank you.
> >>
> >> _______________________________________________ rtcweb
> mailing list
> >> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> ______________________________________________________________________
> > ___________________________________________________
> >
> >  Ce message et ses pieces jointes peuvent contenir des informations 
> > confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message 
> > par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> > que les pieces jointes. Les messages electroniques etant
> susceptibles
> > d'alteration, France Telecom - Orange decline toute
> responsabilite si
> > ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or 
> > privileged information that may be protected by law; they
> should not
> > be distributed, used or copied without authorisation. If you have 
> > received this email in error, please notify the sender and
> delete this
> > message and its attachments. As emails may be altered,
> France Telecom
> > - Orange is not liable for messages that have been
> modified, changed
> > or falsified. Thank you.
> >
> > _______________________________________________ rtcweb mailing list 
> > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> ---------------------------------------------------------------------
> >
> >
> This transmission (including any attachments) may contain confidential 
> information, privileged material (including material protected by the 
> solicitor-client or other applicable privileges), or constitute 
> non-public information.
> Any use of this information by anyone other than the intended 
> recipient is prohibited. If you have received this transmission in 
> error, please immediately reply to the sender and delete this 
> information from your system. Use, dissemination, distribution, or 
> reproduction of this transmission by unintended recipients is not 
> authorized and may be unlawful.
> >
> >
> ______________________________________________________________________
> > ___________________________________________________
> >
> >  Ce message et ses pieces jointes peuvent contenir des informations 
> > confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message 
> > par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
> > que les pieces jointes. Les messages electroniques etant
> susceptibles
> > d'alteration, France Telecom - Orange decline toute
> responsabilite si
> > ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or 
> > privileged information that may be protected by law; they
> should not
> > be distributed, used or copied without authorisation. If you have 
> > received this email in error, please notify the sender and
> delete this
> > message and its attachments. As emails may be altered,
> France Telecom
> > - Orange is not liable for messages that have been
> modified, changed
> > or falsified. Thank you.
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJRQVgzAAoJEJ6/8sItn9q9fgYH/jcWfhRrvPM1hJ22YcE7eR0N
> OZzP/RvSrUBiIA6kG+6+Hvn5Lp/tXd+LxUDp5L8B3Toce7TBBAYNJP3M2cr8N8It
> SjVvPHtBNKEqhBLbI4FbAouvymNH4utjAWR+MmF9LRySPXZ9nxLN0A13TeUlpZxt
> Jaxr/n9AWwkKOk6BIo1Xztbk26MObiGVLhCE+CPoHaHe29bKblPcphBXC935ymHS
> SuF2DXiAq0iKwZoVOsLe3RIaGg+bjN7N2MXi3Vphr7cOQK+JpdxURDrvmPh7/L8R
> ht1RJt928yl4fEjnKhSKJLd1J+gPBe6vnkSxUp89as03bLirLwN1G2giD3YzfLM=3D
> =3DK56v
> -----END PGP SIGNATURE-----
>
> ______________________________________________________________
> ___________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi 
> que les pieces jointes. Les messages electroniques etant susceptibles 
> d'alteration, France Telecom - Orange decline toute responsabilite si 
> ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not 
> be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and 
> delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for 
> messages that have been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> 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
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential 
> information, privileged material (including material protected by the 
> solicitor-client or other applicable privileges), or constitute 
> non-public information.
> Any use of this information by anyone other than the intended 
> recipient is prohibited. If you have received this transmission in 
> error, please immediately reply to the sender and delete this 
> information from your system. Use, dissemination, distribution, or 
> reproduction of this transmission by unintended recipients is not 
> authorized and may be unlawful.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

____________________________________________________________________________=
_____________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou co=
pies sans autorisation. Si vous avez recu ce message par erreur, veuillez le=
 signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les me=
ssages electroniques etant susceptibles d'alteration, France Telecom - Orang=
e decline toute responsabilite si ce message a ete altere, deforme ou falsif=
ie. Merci.

This message and its attachments may contain confidential or privileged info=
rmation that may be protected by law; they should not be distributed, used o=
r copied without authorisation.
If you have received this email in error, please notify the sender and delet=
e this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages=
 that have been modified, changed or falsified.
Thank you.


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

____________________________________________________________________________=
_____________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages ele=
ctroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete alt=
ere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delet=
e this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages=
 that have been modified, changed or falsified.
Thank you.


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From koen.vos@skype.net  Fri Mar 15 10:34: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 5393121F88EA for ; Fri, 15 Mar 2013 10:34:46 -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.079,  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 XBwxfIrQ+ZUt for ; Fri, 15 Mar 2013 10:34:45 -0700 (PDT)
Received: from na01-sn2-obe.outbound.o365filtering.com (na01-sn2-obe.ptr.o365filtering.com [157.55.158.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6D58021F88D8 for ; Fri, 15 Mar 2013 10:34:45 -0700 (PDT)
Received: from BY2SR01CA103.namsdf01.sdf.exchangelabs.com (10.255.93.148) by BY2SR01MB608.namsdf01.sdf.exchangelabs.com (10.255.93.167) with Microsoft SMTP Server (TLS) id 15.0.651.5; Fri, 15 Mar 2013 17:34:42 +0000
Received: from BY1FFOFD002.ffo.gbl (64.4.22.88) by BY2SR01CA103.outlook.office365.com (10.255.93.148) with Microsoft SMTP Server (TLS) id 15.0.658.4 via Frontend Transport; Fri, 15 Mar 2013 17:34:42 +0000
Received: from hybrid.exchange.microsoft.com (131.107.1.27) by BY1FFOFD002.mail.o365filtering.com (10.1.16.84) with Microsoft SMTP Server (TLS) id 15.0.651.3 via Frontend Transport; Fri, 15 Mar 2013 17:34:41 +0000
Received: from DFM-TK5MBX15-07.exchange.corp.microsoft.com (157.54.109.46) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.3.123.1; Fri, 15 Mar 2013 10:34:20 -0700
Received: from DFM-CO1MBX15-02.exchange.corp.microsoft.com (157.59.247.79) by DFM-TK5MBX15-07.exchange.corp.microsoft.com (157.54.109.46) with Microsoft SMTP Server (TLS) id 15.0.620.14; Fri, 15 Mar 2013 10:34:19 -0700
Received: from DFM-CO1MBX15-04.exchange.corp.microsoft.com (157.59.247.11) by DFM-CO1MBX15-02.exchange.corp.microsoft.com (157.59.247.79) with Microsoft SMTP Server (TLS) id 15.0.620.25; Fri, 15 Mar 2013 10:34:11 -0700
Received: from DFM-CO1MBX15-04.exchange.corp.microsoft.com ([157.59.247.11]) by DFM-CO1MBX15-04.exchange.corp.microsoft.com ([169.254.5.131]) with mapi id 15.00.0620.020; Fri, 15 Mar 2013 10:34:11 -0700
From: Koen Vos 
To: Xavier Marjou , Adam Roach 
Thread-Topic: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIYQ1+zdMWf7pVEmNxXCLOF5pPpim/3BI
Date: Fri, 15 Mar 2013 17:34:10 +0000
Message-ID: <80aba69060a14004acfebca95b1ddf7a@DFM-CO1MBX15-04.exchange.corp.microsoft.com>
References:  <51431729.10608@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.13]
Content-Type: multipart/alternative; boundary="_000_80aba69060a14004acfebca95b1ddf7aDFMCO1MBX1504exchangeco_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.1.27; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(24454001)(189002)(199002)(59766001)(56776001)(54316002)(69226001)(16236675001)(47976001)(66066001)(49866001)(44976002)(80022001)(74662001)(77982001)(50986001)(20776003)(46102001)(65816001)(53806001)(31966008)(512954001)(5343655001)(16406001)(51856001)(56816002)(4396001)(79102001)(74502001)(5343635001)(33646001)(47446002)(876001)(54356001)(63696002)(47736001)(76482001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2SR01MB608; H:hybrid.exchange.microsoft.com; RD:mail7.exchange.microsoft.com; MX:1; A:1; LANG:en; 
X-Forefront-PRVS: 078693968A
X-OriginatorOrg: msft.ccsctp.net
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Agenda time request for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 15 Mar 2013 17:34:46 -0000

--_000_80aba69060a14004acfebca95b1ddf7aDFMCO1MBX1504exchangeco_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xavier Marjou wrote:
> Again, this threads deals with interoperability (i.e. communications betw=
een a WebRTC device and a non-WebRTC device).

Given that it's currently impossible to connect to a mobile phone in a lega=
cy network without transcoding, could you tell us a bit about Orange/3GPP's=
 plans to provide the kind of interop you describe?  If those plans  don't =
exist, how could this thread (or the IETF) be dealing with such interoperab=
ility?

koen.


________________________________
From: rtcweb-bounces@ietf.org on behalf of Xavier Marjou
Sent: Friday, March 15, 2013 6:51 AM
To: Adam Roach
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-cod=
ecs-for-interop-01


Again, this threads deals with interoperability (i.e. communications betwee=
n a WebRTC device and a non-WebRTC device).
Non-WebRTC devices mean nearly all of existing phones in the world; they ar=
e already deployed and there's no way to upgrade them all with OPUS on them=
.

Xavier

On Fri, Mar 15, 2013 at 1:42 PM, Adam Roach > wrote:

I don't think this points to a need to push AMR into the web browsers, mind=
 you. To take Justin's earlier point a few steps further: if we're going on=
 number of shipping units, the mere existence of Chrome and Firefox's WebRT=
C implementation means that the number of deployed Opus codecs far overwhel=
ms the number of deployed AMR codecs. Appeals to the size of codec deployme=
nt would more reasonably reach the conclusion that Opus should be MTI for t=
he next 3GPP release. ;-)

/a


--_000_80aba69060a14004acfebca95b1ddf7aDFMCO1MBX1504exchangeco_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









Xavier Marjou wrote:

> Again, this threads deals with interoperability (i.e. communications b=
etween a WebRTC device and a non-WebRTC device).




Given that it's currently impossible to connect to a mobile phone in a lega=
cy network without transcoding, could you tell us a bit about Orange/3GPP's=
 plans to provide the kind of interop you describe?  If those plans&nb=
sp; don't exist, how could this thread (or
 the IETF) be dealing with such interoperability?



koen.










From: rtcweb-bounces@ietf.=
org on behalf of Xavier Marjou

Sent: Friday, March 15, 2013 6:51 AM

To: Adam Roach

Cc: rtcweb@ietf.org

Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-au=
dio-codecs-for-interop-01

 











Again, this threads deals with interoperability (i.e. communications b=
etween a WebRTC device and a non-WebRTC device). 


Non-WebRTC devices mean nearly all of existing phones in the world; th=
ey are already deployed and there's no way to upgrade them all with OPUS on=
 them.
















--_000_80aba69060a14004acfebca95b1ddf7aDFMCO1MBX1504exchangeco_--

From harald@alvestrand.no  Fri Mar 15 10:37: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 03E4821F8952 for ; Fri, 15 Mar 2013 10:37: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=[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 3eywAdWyijef for ; Fri, 15 Mar 2013 10:37:05 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E252921F8976 for ; Fri, 15 Mar 2013 10:36:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D256639E23A; Fri, 15 Mar 2013 18:36:55 +0100 (CET)
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 EuPnuMOGYwWS; Fri, 15 Mar 2013 18:36:55 +0100 (CET)
Received: from [IPv6:2001:470:de0a:27:dc4b:da73:da24:d309] (unknown [IPv6:2001:470:de0a:27:dc4b:da73:da24:d309]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id D90CB39E03A; Fri, 15 Mar 2013 18:36:54 +0100 (CET)
Message-ID: <51435C36.4060102@alvestrand.no>
Date: Fri, 15 Mar 2013 18:36:54 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: Roman Shpount 
References: <5141133D.3040100@alvestrand.no> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Audio transcoding: CPU costs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 15 Mar 2013 17:37:06 -0000

On 03/14/2013 06:03 AM, Roman Shpount wrote:
> Though I generally agree with results of your analysis (CPU cost per 
> minute of transcoding is small), i would like to point out a few 
> things regarding this analysis:
>
> 1. Based on the message you are quoting, current performance is 150 
> channels per core. It would require some non-trivial work to get it to 
> 500 channels.

That was 150 channels for one CPU of an old laptop. I don't know how 
many cores Amazon's servers have, but I picked the "CPU-heavy" variant 
for that reason.

> 2. Transcoding server would definitely need to purchase AMR/AMR-WB 
> licenses.
I'm glad you brought that up :-)
The nice thing about this way of doing it is that all the licensing cost 
falls on the users of that service, and no licensing costs are incurred 
by anyone who doesn't want to use this particular service - unlike 
solutions that are shippped by default to users whether they use it or not.


> 3. Transcoding would require jitter buffer and other code which would 
> not be needed for ICE/SRTP gateway

Yep. As I said, there are other things than cost to consider - I wanted 
to focus on this particular item in this thread.

> 4. Amazon AWS are not really usable for transcoding or any other 
> real-time specific operations. You end up with too much jitter when 
> processing media introduced by a virtualized instance.


>
> Based on my benchmarks and my napkin based estimate ($4000 per 
> server amortized over 3 years, $300 per server per month to host it, 
> 1000 channels of transcoding per server), the cost of one channel of 
> transcoding is about $0.4 per month vs about $0.02 per month for 
> ICE/SRTP only gateway (if transcoding is not needed, server can do 
> 20,000 channels).

Yep. I used their price as "this is a reasonable approximation for what 
it costs to operate a server at bulk rates". Your estimates seem to land 
in the same ballpark, so it wasn't entirely off into left field. 40 
cents per month is 0.00093 cents per minute (ignoring the need to have 
idle capacity).

> This does not take into account management and operation costs which 
> grow proportionally since you end up needing 20 times as much 
> hardware. It also does not include costs of software licenses. 
> Depending on how spiky your traffic is this can translate into 
> different price per minute, but based on our conference service we do 
> about 12,000 minutes per channel per month this translates into 0.003 
> cents per minute, which is not far from your estimate.

At least we've agreed that the cost of transcoding audio is not 
significant. Nice to agree on something!


From jmvalin@mozilla.com  Fri Mar 15 10:48: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 E856021F89EE for ; Fri, 15 Mar 2013 10:48:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.062
X-Spam-Level: 
X-Spam-Status: No, score=-0.062 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KASVW1EODjDq for ; Fri, 15 Mar 2013 10:48:32 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id F116321F89E1 for ; Fri, 15 Mar 2013 10:48:31 -0700 (PDT)
Received: from [130.129.33.249] (dhcp-21f9.meeting.ietf.org [130.129.33.249]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 9A8ABF2376;  Fri, 15 Mar 2013 10:48:30 -0700 (PDT)
Message-ID: <51435EED.2060608@mozilla.com>
Date: Fri, 15 Mar 2013 13:48:29 -0400
From: Jean-Marc Valin 
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: stephane.proust@orange.com
References: <4507_1363362629_51434345_4507_361_1_6af2514e-a2f2-4248-b7a9-5d0452f3abf7@PEXCVZYH02.corporate.adroot.infra.ftgroup>  <15570_1363363711_5143477F_15570_5387_1_61f74e36-8baf-42a5-b86d-d947dd4f193f@PEXCVZYH02.corporate.adroot.infra.ftgroup>
In-Reply-To: <15570_1363363711_5143477F_15570_5387_1_61f74e36-8baf-42a5-b86d-d947dd4f193f@PEXCVZYH02.corporate.adroot.infra.ftgroup>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: MARJOU Xavier OLNC/OLN , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 15 Mar 2013 17:48:34 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Seriously, I think this whole issue is adequately addressed by this
audio draft ticket by Bernard:
http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/12

Cheers,

	Jean-Marc

On 03/15/2013 12:08 PM, stephane.proust@orange.com wrote:
>>> we shouldn't give the impression that its more important to
>>> include some codecs than others that are available to the
>>> browser to use.
> 
> But Why shouldn't we give that impression ?
> 
> Because obviously YES it is more important to support codecs that
> are implemented in billions of devices and the support of which
> will improve the quality for millions of customers and reduce the
> costs in networks than codecs of specific and limited usage.
> 
> And since AMR AMR-WB stay the mandatory codecs for 4G VoLTE I don't
> think the importance of these codecs can ben challenged for the
> future
> 
> Stéphane
> 
> 
> -----Message d'origine----- De : Andrew Allen
> [mailto:aallen@blackberry.com] Envoyé : vendredi 15 mars 2013
> 16:58 À : PROUST Stephane OLNC/OLPS; R.Jesske@telekom.de;
> koen.vos@skype.net; espeberg@cisco.com Cc : MARJOU Xavier OLNC/OLN;
> rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
> 
> 
> Suitable to me means suitable for the application context i.e if
> the application is conversational real time audio then all audio
> codecs suitable for conversational real time audio the browser has
> the ability to use are recommended to be included in the offer.
> 
> I don't agree to mention specific codecs - all codecs that meet the
> suitability for the application apply and we shouldn't give the
> impression that its more important to include some codecs than
> others that are available to the browser to use.
> 
> 
> ----- Original Message ----- From: stephane.proust@orange.com
> [mailto:stephane.proust@orange.com] Sent: Friday, March 15, 2013
> 10:50 AM Central Standard Time To: Andrew Allen;
> R.Jesske@telekom.de ; koen.vos@skype.net
> ; espeberg@cisco.com  Cc:
> MARJOU Xavier OLNC/OLN ; rtcweb@ietf.org
>  Subject: RE: [rtcweb] Agenda time	request	for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
> 
> Hello
> 
> As mentioned earlier, this kind of general statement makes sense
> and would be acceptable for us only if it gives some minimum
> guidance on what "suitable" means. It means: the codecs that are
> especially important to be considered because their support would
> solve the interoperability issue for a huge number of calls and
> because they can be made available to the browsers on a high number
> of devices:
> 
> "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." This is especially the case for AMR
> and AMR-WB for interoperability with 3GPP mobile devices and G.722
> for interoperability with fixed ETSI/DECT CAT-iq devices
> 
> 
> Stephane Proust
> 
> 
> 
> -----Message d'origine----- De : Andrew Allen
> [mailto:aallen@blackberry.com] Envoyé : vendredi 15 mars 2013 15:56
> À : R.Jesske@telekom.de; koen.vos@skype.net; espeberg@cisco.com;
> PROUST Stephane OLNC/OLPS Cc : MARJOU Xavier OLNC/OLN;
> rtcweb@ietf.org Objet : RE: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
> 
> Roland
> 
> I have proposed that we add the following text to address the
> interoperability concerns
> 
> "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."
> 
> The MTI Audio Codecs are defined to ensure a basic level of
> interoperability and will need to be always supported for that
> reason. Support for additional audio codecs is an implementation
> and business case decision and the additional audio codecs that it
> makes sense to support will change over time (as codecs become
> obsolete and new ones are developed and deployed. So additional
> audio codecs should not be specified in the RTCweb RFCs.
> 
> Andrew
> 
> -----Original Message----- From: R.Jesske@telekom.de
> [mailto:R.Jesske@telekom.de] Sent: Friday, March 15, 2013 5:45 AM 
> To: Andrew Allen; koen.vos@skype.net; espeberg@cisco.com;
> stephane.proust@orange.com Cc: xavier.marjou@orange.com;
> rtcweb@ietf.org Subject: AW: [rtcweb] Agenda time request for
> draft-marjou-rtcweb-audio-codecs-for-interop-01
> 
> Hi Andrew, but where will you start and where will you end. The
> codec discussion appears now so why not try to solve this now? And
> one proposal is to use these codecs and I fully support it.
> 
> Roland
> 
>> -----Ursprüngliche Nachricht----- Von: rtcweb-bounces@ietf.org
>> [mailto:rtcweb-bounces@ietf.org] Im Auftrag von Andrew Allen 
>> Gesendet: Donnerstag, 14. März 2013 22:10 An: koen.vos@skype.net;
>> espeberg@cisco.com; stephane.proust@orange.com Cc:
>> xavier.marjou@orange.com; rtcweb@ietf.org Betreff: Re: [rtcweb]
>> Agenda time request for 
>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>> 
>> 
>> Koen is right that there are many more obstacles to RTCweb and
>> legacy network interop than just a common codec. First there will
>> need to be RTCweb signaling gateways to interface between the
>> RTCweb signaling and the legacy networks (SIP, H.323 etc) and
>> there will need to be in place mechanisms for peering, federation
>> and address resolution between networks as well as service 
>> agreements in place between the players.
>> 
>> Until those are resolved supporting codecs used in those networks
>> is pointless.
>> 
>> Andrew
>> 
>> ----- Original Message ----- From: Koen Vos
>> [mailto:koen.vos@skype.net] Sent: Thursday, March 14, 2013 03:32
>> PM Central Standard Time To: Espen Berger (espeberg)
>> ; stephane.proust@orange.com
>>  Cc: rtcweb@ietf.org
>> ; MARJOU Xavier OLNC/OLN 
>>  Subject: Re: [rtcweb] Agenda time
>> request for draft-marjou-rtcweb-audio-codecs-for-interop-01
>> 
>>> It's interop with billions of mobile phones and with fixed
>> terminals in legacy telephony services.
>> 
>> The problem is that WebRTC and legacy services live in separate 
>> networks: the open Web vs proprietary Telco networks.
>> 
>> WebRTC connecting to a Telco network would have to go through a 
>> Gateway.  The PSTN termination providers who run these Gateways 
>> support G.711, G.729 and perhaps some other  codecs like iLBC.
>> They do not, however, support the codecs you are advocating for.
>> 
>> The lack of support for Transcoding-Free Operation by Telcos to
>> the rest of the world has been hurting interop voice quality for
>> a long time, but unfortunately we can't fix that here at the
>> IETF.
>> 
>> We can fit our cars with your costly railroad wheels, but you
>> still wouldn't let us on your tracks.
>> 
>> koen.
>> 
>> 
>> -----Original Message----- From: rtcweb-bounces@ietf.org 
>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of 
>> stephane.proust@orange.com Sent: 14. mars 2013 13:36 To:
>> Jean-Marc Valin Cc: rtcweb@ietf.org; MARJOU Xavier OLNC/OLN 
>> Subject: Re: [rtcweb] Agenda time request for 
>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>> 
>> Hello
>> 
>> The short list is aligned to what is specified in 3GPP (mobile)
>> and CAT-iq (fixed). Check the related service specifications! The
>> short list (AMR, AMR-WB, G.722) is a minimal subset of codecs to
>>  minimize interop issues and transcoding costs for telco
>> services. It's not a question of what's the favourite codec for a
>> given application. It's interop with billions of mobile phones
>> and with fixed terminals in legacy telephony services.
>> 
>> Stéphane
>> 
>> -----Message d'origine----- De : Jean-Marc Valin
>> [mailto:jmvalin@mozilla.com] Envoyé : jeudi 14 mars 2013 05:55 À
>> : PROUST Stephane OLNC/OLPS Cc : Andrew Allen;
>> Markus.Isomaki@nokia.com; MARJOU Xavier OLNC/OLN; rtcweb@ietf.org
>> Objet : Re: [rtcweb] Agenda time request for 
>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>> 
> On 03/13/2013 06:48 PM, stephane.proust@orange.com wrote:
>>>> The reason is simply that AMR and AMR-WB are supported in
> billions of
>>>> devices !
> 
> Just curious, why exclude from the list other codecs with similar
> huge deployment? I can think of at least: - GSM-FR (mobile) - Speex
> (Flash) - G.729 (PSTN gateways) - iLBC (PSTN gateways) - G.726
> (DECT) - SILK (original non-Opus version in Skype)
> 
> (sorry, if I missed someone's favorite codec in this list)
> 
> It's not at all clear to me what's so special that makes AMR,
> AMR-WB and G.722 different from the other codecs in the list above.
> Not that I insist on shipping G.729 :-)
> 
> Personally, I'd favor a draft that included a lot more codecs, 
> describing for each one the benefits of supporting it. Implementers
>  could then choose which of these they care about for their
> particular situation.
> 
> Cheers,
> 
> Jean-Marc
> 
>>>> Stéphane
>>>> 
>>>> 
>>>> -----Message d'origine----- De : Andrew Allen 
>>>> [mailto:aallen@blackberry.com] Envoyé : mercredi 13 mars
>>>> 2013 23:41 À : PROUST Stephane OLNC/OLPS;
>>>> Markus.Isomaki@nokia.com; jmvalin@mozilla.com Cc : MARJOU
>>>> Xavier OLNC/OLN;
> rtcweb@ietf.org Objet
>>>> : Re: [rtcweb] Agenda time request for 
>>>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>>>> 
>>>> 
>>>> No this wouldn't be acceptable to me.
>>>> 
>>>> I don't see a reason to push a particular set of Codecs
> over any other
>>>> set of codecs supported on the device. If the device supports
>>>> the codecs and they are available to the browser then we
>>>> should
> recommend
>>>> that they be offered in the negotiation.
>>>> 
>>>> The marjou draft can advertise the merits and reasons why
>>>> they are good codecs to support.
>>>> 
>>>> 
>>>> ----- Original Message ----- From: stephane.proust@orange.com
>>>>  [mailto:stephane.proust@orange.com] Sent: Wednesday, March
>>>> 13, 2013 05:14 PM Central Standard Time To:
>>>> Markus.Isomaki@nokia.com ;
>>>> jmvalin@mozilla.com
> 
>>>> Cc: MARJOU Xavier OLNC/OLN ;
> rtcweb@ietf.org
>>>>  Subject: Re: [rtcweb] Agenda time
>>>> request for draft-marjou-rtcweb-audio-codecs-for-interop-01
>>>> 
>>>> Dear Markus
>>>> 
>>>> Thanks for your attempt to help !
>>>> 
>>>> Of course each Telco can handle this directly with vendors
>>>> and browsers manufacturers at business level. But I
>>>> don't'think
> this need
>>>> of interoperability with mobile devices is specific to
>>>> Orange. I think all mobile operators will have the same issue
>>>> and
> this is why
>>>> standardization exist. It's most cost and time efficient to
> have one
>>>> common way forward for all the industry.
>>>> 
>>>> Then if the issue is that "conditional MUST/SHOULD are a too
>>>>  complicated requirement. We could also live as a compromise
>>>> with a formulation that has already been suggested on the
>>>> reflector:
>>>> 
>>>> "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" If possible with the addition of This is
> especially
>>>> the case for AMR, AMR-WB for interoperability with mobile
> devices and
>>>> G.722 for interoperability with fixed DECT CAT-iq devices
>>>> 
>>>> Would it have one chance to reach consensus ?
>>>> 
>>>> I think this Group should at least make one small step so
>>>> that the interoperability issue with mobile terminals be not
>>>> fully
> ignored in
>>>> the RTC Web specification considering the huge number of
>>>> deployed devices. At least something must be written on this
>>>> ! G.711 which is the only codec in addition to OPUS for
> interoperability
>>>> purpose is not a proper answer to this.
>>>> 
>>>> Stéphane
>>>> 
>>>> -----Message d'origine----- De : Markus.Isomaki@nokia.com 
>>>> [mailto:Markus.Isomaki@nokia.com] Envoyé : mercredi 13 mars
>>>> 2013 22:37 À : PROUST Stephane OLNC/OLPS;
>>>> jmvalin@mozilla.com; MARJOU Xavier OLNC/OLN Cc :
>>>> rtcweb@ietf.org Objet : RE: [rtcweb]
> Agenda time
>>>> request for draft-marjou-rtcweb-audio-codecs-for-interop-01
>>>> 
>>>> Hi Stephane, Xavier,
>>>> 
>>>> I understand the intent of your proposal. I'm not sure if
> the IETF is
>>>> the best venue for you to pursue it, however. Perhaps you
> as a mobile
>>>> operator should rather set it as a requirement to your
> mobile device
>>>> platforms that they open up the APIs to AMR and AMR-WB and
>>>> that at least the in-built default browser needs to support
>>>> it. If
> there are
>>>> enough operators setting such requirements directly to the
> device and
>>>> platform vendors, it probably has a bigger impact than an
>>>> IETF RFC. Getting that support for user-installed additional
>>>> browsers
> might be
>>>> more difficult, but most mobile device users stick with the
>>>> default browser anyway.
>>>> 
>>>> The RTCWEB codec document needs to definitely explain this
>>>> case and the benefits, but the conditional MUSTs or SHOULDs
>>>> you are
> proposing
>>>> are perhaps a bit too complicated. Hmm, perhaps we need to do
>>>> an _informational_ RFC as something like "Recommendations
>>>> for
> WebRTC on
>>>> Mobile Devices" addressing the codec and perhaps other
>>>> issues, that you could use as a reference in your
>>>> requirements.
>>>> 
>>>> Markus
>>>> 
>>>> 
>>>>> -----Original Message----- From: rtcweb-bounces@ietf.org 
>>>>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext 
>>>>> stephane.proust@orange.com Sent: 13 March, 2013 21:37 To: 
>>>>> Jean-Marc Valin; MARJOU Xavier OLNC/OLN Cc:
>>>>> rtcweb@ietf.org Subject: Re: [rtcweb] Agenda time request
>>>>> for draft-marjou-rtcweb-audio- codecs-for-interop-01
>>>>> 
>>>>> Hello
>>>>> 
>>>>> Our understanding is that the reason of the "no consensus"
>>>>> on additional recommended codecs was the additional costs
>>>>> for
> browsers.
>>>>> The proposal is then to make these "MUST" fully conditional
>>>>> to the case of no (or very reduced) additional costs, when
>>>>> the codecs are already available on the device and when no
>>>>> additional
> license fee is
>>>>> required
>>>>> 
>>>>> We could even live with lower level of "requirements" with
>>>>>  respectively May and Should (instead of Should and shall)
>>>>> but we think that this proposal is a way to take into
>>>>> account
> both browser
>>>>> manufacturers concerns on browsers costs and telcos
>>>>> concerns on transcoding costs and some other companies
>>>>> share this view.
>>>>> 
>>>>> Stéphane
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> -----Message d'origine----- De : rtcweb-bounces@ietf.org 
>>>>> [mailto:rtcweb-bounces@ietf.org] De la part de Jean-Marc
> Valin Envoyé
>>>>> : mercredi 13 mars 2013 20:24 À : MARJOU Xavier OLNC/OLN Cc
>>>>> : rtcweb@ietf.org Objet : Re: [rtcweb] Agenda time request
>>>>> for draft-marjou-rtcweb-audio-codecs-for-interop-01
>>>>> 
>>>> Hi,
>>>> 
>>>> I'd really like to understand how the chairs coming to the
> conclusion
>>>> that there was *no consensus* on recommended codecs can
>>>> result in a draft that includes 3 MUSTs and 1 SHOULD. This
>>>> draft
> effectively makes
>>>> 3 new codecs MTI for a range of devices. I understand that
>>>> it's an individual draft and you can write whatever you like
>>>> in
> there, but it
>>>> definitely goes against the result of the WG discussion.
>>>> 
>>>> Cheers,
>>>> 
>>>> Jean-Marc
>>>> 
>>>> On 03/13/2013 09:14 AM, Xavier Marjou wrote:
>>>>>>> Here is a summary of the 
>>>>>>> draft-marjou-rtcweb-audio-codecs-for-interop-00
> presentation that I
>>>>>>> had prepared for yesterday's session:
>>>>>>> 
>>>>>>> - The co-authors want to underline that non-WebRTC
>>>>>>> voice
> endpoints
>>>>>>> usually use one of the following codecs: AMR, AMR-WB or
>>>>>>> G.722, which will result in massive transcoding when
>>>>>>> there will be communications between WebRTC endpoints
>>>>>>> and non-WebRTC endpoints.
>>>>>>> 
>>>>>>> - On one side, transcoding is bad for many reasons
> discussed in the
>>>>>>> draft (cost issues, intrinsic quality degradation,
>>>>>>> degraded interactivity, fallback from HD to G.711...);
>>>>>>> 
>>>>>>> - On the other side, it is recognized that
>>>>>>> implementing
> additional
>>>>>>> codecs in the browsers can generate additional costs.
>>>>>>> 
>>>>>>> - In order to reach a compromise, we would like to add
> some text in
>>>>>>> the WG draft draft-ietf-rtcweb-audio providing
> incentives for the
>>>>>>> browser to use these three codecs: make them mandatory
> to implement
>>>>>>> when there is no cost impact on the browser (e.g. if
> codec already
>>>>>>> installed, paid by the device vendor...).
>>>>>>> 
>>>>>>> Any opinion on that?
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> 
>>>>>>> Xavier
>>>>>>> 
>>>>>>> PS: I will be ready to present the slides on Thursday
>>>>>>> if time permits it.
>>>>>>> 
>>>>>>> (c.f. 
>>>>>>> http://tools.ietf.org/agenda/86/slides/slides-86-rtcweb-6.pdf
>>>>>>>
>>>>>>>
>
>>>>>>> 
)
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie
>>>>>>> >
>>>>>>> wrote:
>>>>>>> 
>>>>>>> Magnus and I discussed this this morning, and we
> encourage you to
>>>>>>> prepare something.  If the discussion of working group
>>>>>>> last call items runs short, we may be able to fit this
>>>>>>> in at that
> time or at
>>>>>>> the end of day one if its full agenda his finished.
> This is not a
>>>>>>> commitment, however, so please try and get discussion
>>>>>>> on
> the list
>>>>>>> on the points from the draft you feel need resolution.
>>>>>>> 
>>>>>>> regards,
>>>>>>> 
>>>>>>> Ted
>>>>>>> 
>>>>>>> 
>>>>>>> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg)
>>>>>>>  >
>>>>>>> wrote:
>>>>>>>> Hello,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I would like to request agenda time for:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> The document  presents use-cases underlining why
>>>>>>>> WebRTC needs
>>>>>>> AMR-WB,  AMR
>>>>>>>> and G.722 as additional relevant voice codecs to
>>>>>>>> satisfactorily ensure interoperability with existing
>>>>>>>> systems.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> A 10-minute time slot should be sufficient for
>>>>>>>> presentation and
>>>>>>> discussion.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Regards
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -Espen
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>> 
>>>>> ___________________________________________________________
>>>>>
>>>>> 
___________________________________________________________ ___
>>>>> 
>>>>> Ce message et ses pieces jointes peuvent contenir des
>>>>> informations confidentielles ou privilegiees et ne doivent
>>>>> donc pas
> etre diffuses,
>>>>> exploites ou copies sans autorisation. Si vous avez recu
> ce message
>>>>> par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi
>>>>> que les pieces jointes. Les messages electroniques etant
> susceptibles
>>>>> d'alteration, France Telecom - Orange decline toute
> responsabilite si
>>>>> ce message a ete altere, deforme ou falsifie. Merci.
>>>>> 
>>>>> This message and its attachments may contain confidential
>>>>> or privileged information that may be protected by law;
>>>>> they
> should not
>>>>> be distributed, used or copied without authorisation. If
>>>>> you have received this email in error, please notify the
>>>>> sender and delete this message and its attachments. As
>>>>> emails may be altered, France Telecom - Orange is not
>>>>> liable for messages that have been
> modified,
>>>>> changed or falsified. Thank you.
>>>>> 
>>>>> _______________________________________________ rtcweb
> mailing list
>>>>> rtcweb@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>> 
>>>> 
> ______________________________________________________________________
>>>>
> 
___________________________________________________
>>>> 
>>>> Ce message et ses pieces jointes peuvent contenir des
>>>> informations confidentielles ou privilegiees et ne doivent
>>>> donc pas etre
> diffuses,
>>>> exploites ou copies sans autorisation. Si vous avez recu ce
>>>> message par erreur, veuillez le signaler a l'expediteur et
>>>> le
> detruire ainsi
>>>> que les pieces jointes. Les messages electroniques etant
> susceptibles
>>>> d'alteration, France Telecom - Orange decline toute
> responsabilite si
>>>> ce message a ete altere, deforme ou falsifie. Merci.
>>>> 
>>>> This message and its attachments may contain confidential or
>>>>  privileged information that may be protected by law; they
> should not
>>>> be distributed, used or copied without authorisation. If you
>>>> have received this email in error, please notify the sender
>>>> and
> delete this
>>>> message and its attachments. As emails may be altered,
> France Telecom
>>>> - Orange is not liable for messages that have been
> modified, changed
>>>> or falsified. Thank you.
>>>> 
>>>> _______________________________________________ rtcweb
>>>> mailing list rtcweb@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>> 
>>>> 
> ---------------------------------------------------------------------
>>>>
>>>>
>
> 
This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by
> the solicitor-client or other applicable privileges), or constitute
>  non-public information. Any use of this information by anyone
> other than the intended recipient is prohibited. If you have
> received this transmission in error, please immediately reply to
> the sender and delete this information from your system. Use,
> dissemination, distribution, or reproduction of this transmission
> by unintended recipients is not authorized and may be unlawful.
>>>> 
>>>> 
> ______________________________________________________________________
>>>>
> 
___________________________________________________
>>>> 
>>>> Ce message et ses pieces jointes peuvent contenir des
>>>> informations confidentielles ou privilegiees et ne doivent
>>>> donc pas etre
> diffuses,
>>>> exploites ou copies sans autorisation. Si vous avez recu ce
>>>> message par erreur, veuillez le signaler a l'expediteur et
>>>> le
> detruire ainsi
>>>> que les pieces jointes. Les messages electroniques etant
> susceptibles
>>>> d'alteration, France Telecom - Orange decline toute
> responsabilite si
>>>> ce message a ete altere, deforme ou falsifie. Merci.
>>>> 
>>>> This message and its attachments may contain confidential or
>>>>  privileged information that may be protected by law; they
> should not
>>>> be distributed, used or copied without authorisation. If you
>>>> have received this email in error, please notify the sender
>>>> and
> delete this
>>>> message and its attachments. As emails may be altered,
> France Telecom
>>>> - Orange is not liable for messages that have been
> modified, changed
>>>> or falsified. Thank you.
>>>> 
> 
>> 
>> ______________________________________________________________ 
>> ___________________________________________________________
>> 
>> Ce message et ses pieces jointes peuvent contenir des
>> informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous
>> avez recu ce message par erreur, veuillez le signaler a
>> l'expediteur et le detruire ainsi que les pieces jointes. Les
>> messages electroniques etant susceptibles d'alteration, France
>> Telecom - Orange decline toute responsabilite si ce message a ete
>> altere, deforme ou falsifie. Merci.
>> 
>> This message and its attachments may contain confidential or 
>> privileged information that may be protected by law; they should
>> not be distributed, used or copied without authorisation. If you
>> have received this email in error, please notify the sender and 
>> delete this message and its attachments. As emails may be
>> altered, France Telecom - Orange is not liable for messages that
>> have been modified, changed or falsified. Thank you.
>> 
>> _______________________________________________ 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
>> 
>> ---------------------------------------------------------------------
>>
>> 
This transmission (including any attachments) may contain confidential
>> information, privileged material (including material protected by
>> the solicitor-client or other applicable privileges), or
>> constitute non-public information. Any use of this information by
>> anyone other than the intended recipient is prohibited. If you
>> have received this transmission in error, please immediately
>> reply to the sender and delete this information from your system.
>> Use, dissemination, distribution, or reproduction of this
>> transmission by unintended recipients is not authorized and may
>> be unlawful. _______________________________________________ 
>> rtcweb mailing list rtcweb@ietf.org 
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
> 
> ---------------------------------------------------------------------
>
> 
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.
> 
> _________________________________________________________________________________________________________________________
>
>  Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi que les pieces jointes. Les messages electroniques
> etant susceptibles d'alteration, France Telecom - Orange decline
> toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should
> not be distributed, used or copied without authorisation. If you
> have received this email in error, please notify the sender and
> delete this message and its attachments. As emails may be altered,
> France Telecom - Orange is not liable for messages that have been
> modified, changed or falsified. Thank you.
> 
> 
> ---------------------------------------------------------------------
>
> 
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.
> 
> _________________________________________________________________________________________________________________________
>
>  Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi que les pieces jointes. Les messages electroniques
> etant susceptibles d'alteration, France Telecom - Orange decline
> toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should
> not be distributed, used or copied without authorisation. If you
> have received this email in error, please notify the sender and
> delete this message and its attachments. As emails may be altered,
> France Telecom - Orange is not liable for messages that have been
> modified, changed or falsified. Thank you.
> 
> _______________________________________________ rtcweb mailing
> list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRQ17tAAoJEJ6/8sItn9q9YdoH/2HVJh4g53Jj3YDnTqDlUURh
0zBFn6wfokAQ+iUS5rqai98cNZybgiC3bp2T43uvMk5S4b54wmd1faq9sVgFCOQ4
mc4Rl1T49zp+L+K3xXd0Ww02PTDrJzdYP0uHK34rl0m7SInzZvS9Wl1D7yADvwJm
Oz3Brd44O4QrKt+QBAQ6BpLv+AjAJg2RQjS262ivu0agSHqi2Tjiq6nw1C2iHzYV
wQpfLy1ND49M/+VQC9Yj5A0KgXHa1dEEJBUtHMRJ64e1ZUMhen8f3heUIarjbmT/
ZajUmawvk7GxkDdvkeMM/RkuXpB0EJKNt32SIvvujZNfgSyp985xfoJ6mLZxfoU=
=s5I2
-----END PGP SIGNATURE-----

From harald@alvestrand.no  Fri Mar 15 11:31: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 6F65721F8667 for ; Fri, 15 Mar 2013 11:31:26 -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 96OyKUyjo0U3 for ; Fri, 15 Mar 2013 11:31:26 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2A18121F867B for ; Fri, 15 Mar 2013 11:31:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0DB1839E23A; Fri, 15 Mar 2013 19:31:17 +0100 (CET)
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 zklXZbGDg5HO; Fri, 15 Mar 2013 19:31:16 +0100 (CET)
Received: from [IPv6:2001:470:de0a:27:dc4b:da73:da24:d309] (unknown [IPv6:2001:470:de0a:27:dc4b:da73:da24:d309]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 36AA839E03A; Fri, 15 Mar 2013 19:31:16 +0100 (CET)
Message-ID: <514368F3.2010401@alvestrand.no>
Date: Fri, 15 Mar 2013 19:31:15 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: Daryl Malas 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080607000506020900030108"
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] A different perspective on the video codec MTI 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, 15 Mar 2013 18:31:26 -0000

This is a multi-part message in MIME format.
--------------080607000506020900030108
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 03/14/2013 05:18 AM, Daryl Malas wrote:
> I would like to add my support to Jonathan's comments.  I have had 
> discussions with multiple cable operators, which are evaluating the 
> potential use cases of deploying webRTC.  The resounding comment is 
> that if webRTC supports H.264, their flexibility to deploy it in the 
> near-term on a number of devices improves dramatically.  If VP8 is the 
> only allowable codec, this will significantly limit the deployment, 
> because the relevant devices out there already support H.264 and not VP8.
Repeat message: There will never be a restriction on additional codecs.
It's a business decision by product vendors which codecs they offer in 
addition to the MTI.


--------------080607000506020900030108
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 03/14/2013 05:18 AM, Daryl Malas
      wrote:

    

    

      
      
I would like to add my support to Jonathan's comments.  I
        have had discussions with multiple cable operators, which are
        evaluating the potential use cases of deploying webRTC.  The
        resounding comment is that if webRTC supports H.264, their
        flexibility to deploy it in the near-term on a number of devices
        improves dramatically.  If VP8 is the only allowable codec, this
        will significantly limit the deployment, because the relevant
        devices out there already support H.264 and not VP8.

    

    Repeat message: There will never be a restriction on additional
    codecs.

    It's a business decision by product vendors which codecs they offer
    in addition to the MTI.

    

  


--------------080607000506020900030108--

From harald@alvestrand.no  Fri Mar 15 11:37: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 DCD0721F8A7B for ; Fri, 15 Mar 2013 11:37:35 -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=[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 vQ12GZ2iZWSR for ; Fri, 15 Mar 2013 11:37:35 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id EA7DD21F8A0C for ; Fri, 15 Mar 2013 11:37:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0488139E23A for ; Fri, 15 Mar 2013 19:37:34 +0100 (CET)
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 ob5yewZV2bh7 for ; Fri, 15 Mar 2013 19:37:33 +0100 (CET)
Received: from [IPv6:2001:470:de0a:27:dc4b:da73:da24:d309] (unknown [IPv6:2001:470:de0a:27:dc4b:da73:da24:d309]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id ED70239E03A for ; Fri, 15 Mar 2013 19:37:32 +0100 (CET)
Message-ID: <51436A6C.2020204@alvestrand.no>
Date: Fri, 15 Mar 2013 19:37:32 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020203050209060203070605"
Subject: Re: [rtcweb] A different perspective on the video codec MTI 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, 15 Mar 2013 18:37:36 -0000

This is a multi-part message in MIME format.
--------------020203050209060203070605
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

At a very high level, I find this line of argument puzzling.
I understand a lot of the details presented, but not this line....

"when the industry is ready, we can make VP8 MTI in the browser."

We live in a growing market.

When we have a growing market, and are intending to do a change, we 
always have a choice between early and late change.

The later we leave the change, the more devices there will be out there 
with "before-the-change" technology deployed.

If we think the switch to VP8 makes sense at any time in the future, 
it's less expensive to start the switch now than to start the switch later.

              Harald




--------------020203050209060203070605
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
At a very high level, I find this line
      of argument puzzling.

      I understand a lot of the details presented, but not this line....

      

      "when the
        industry is ready, we can make VP8 MTI in the browser."

      

      We live in a growing market.

      

      When we have a growing market, and are intending to do a change,
      we always have a choice between early and late change.

      

      The later we leave the change, the more devices there will be out
      there with "before-the-change" technology deployed.

      

      If we think the switch to VP8 makes sense at any time in the
      future, it's less expensive to start the switch now than to start
      the switch later.

      

                   Harald

      

      

      

    

  


--------------020203050209060203070605--

From keith.drage@alcatel-lucent.com  Fri Mar 15 19:14: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 5A8F71F0D32 for ; Fri, 15 Mar 2013 19:14:36 -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 BQaw4jklQy+N for ; Fri, 15 Mar 2013 19:14:35 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id F04EE1F0D0E for ; Fri, 15 Mar 2013 19:14:34 -0700 (PDT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r2G2EUqY027454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 15 Mar 2013 21:14:30 -0500 (CDT)
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r2G2ESth003636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Mar 2013 22:14:28 -0400
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 15 Mar 2013 22:14:28 -0400
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Sat, 16 Mar 2013 03:14:25 +0100
From: "DRAGE, Keith (Keith)" 
To: Adam Roach , Andrew Allen 
Thread-Topic: [rtcweb] Agenda time	request	for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIXqjNj8OwNOx7UOetzMEtPQUh5inWccA
Date: Sat, 16 Mar 2013 02:14:25 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B016D88@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References:  <51431729.10608@nostrum.com>
In-Reply-To: <51431729.10608@nostrum.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.38]
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.39
Cc: "xavier.marjou@orange.com" , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Agenda time	request	for	draft-marjou-rtcweb-audio-codecs-for-interop-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 16 Mar 2013 02:14:36 -0000

> I don't think this points to a need to push AMR into the web browsers,
> mind you. To take Justin's earlier point a few steps further: if we're
> going on number of shipping units, the mere existence of Chrome and
> Firefox's WebRTC implementation means that the number of deployed Opus
> codecs far overwhelms the number of deployed AMR codecs. Appeals to the
> size of codec deployment would more reasonably reach the conclusion that
> Opus should be MTI for the next 3GPP release. ;-)

You are welcome to create the relevant work item in 3GPP SA4 if you think i=
t appropriate.

That of course will not solve the need to transcode with all the phones pri=
or to the release where that work item is adopted.

Keith

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
> Of Adam Roach
> Sent: 15 March 2013 12:42
> To: Andrew Allen
> Cc: rtcweb@ietf.org; xavier.marjou@orange.com
> Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-
> codecs-for-interop-01
>=20
> On 3/14/13 17:09, Andrew Allen wrote:
> > Koen is right that there are many more obstacles to RTCweb and legacy
> network interop than just a common codec. First there will need to be
> RTCweb signaling gateways to interface between the RTCweb signaling and
> the legacy networks (SIP, H.323 etc) and there will need to be in place
> mechanisms for peering, federation and address resolution between network=
s
> as well as service agreements in place between the players.
>=20
>=20
> We had this mostly working at the SIPit in Boston, using the SIP over
> Websockets spec. The only reason we weren't actually setting calls up
> was that we couldn't find any clients there that supported both ICE and
> DTLS-SRTP. What's neat is that this isn't even really "gatewaying" in
> the way that you mean it -- all you need is a SIP proxy that supports
> one more (easy-to-implement) transport protocol.
>=20
> And once you hit that proxy, all of the peering, federation, and address
> resolution solutions developed for SIP apply.
>=20
> I don't think this points to a need to push AMR into the web browsers,
> mind you. To take Justin's earlier point a few steps further: if we're
> going on number of shipping units, the mere existence of Chrome and
> Firefox's WebRTC implementation means that the number of deployed Opus
> codecs far overwhelms the number of deployed AMR codecs. Appeals to the
> size of codec deployment would more reasonably reach the conclusion that
> Opus should be MTI for the next 3GPP release. ;-)
>=20
> /a
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

From ietf@meetecho.com  Sat Mar 16 10:17: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 F38F921F88ED for ; Sat, 16 Mar 2013 10:17:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level: 
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shMwoXArlkHT for ; Sat, 16 Mar 2013 10:17:00 -0700 (PDT)
Received: from smtpdg3.aruba.it (smtpdg221.aruba.it [62.149.158.221]) by ietfa.amsl.com (Postfix) with ESMTP id DD79721F88C1 for ; Sat, 16 Mar 2013 10:16:59 -0700 (PDT)
Received: from dell-tcastaldi ([87.16.35.204]) by smtpcmd01.ad.aruba.it with bizsmtp id CHGw1l00U4QFnDT01HGxR7; Sat, 16 Mar 2013 18:16:57 +0100
Date: Sat, 16 Mar 2013 13:16:52 -0400 (EDT)
From: Meetecho Team 
To: rtcweb@ietf.org
Message-ID: <860069.1.1363454212914.JavaMail.tcastaldi@dell-tcastaldi>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_Part_0_2614099.1363454212869"
Subject: [rtcweb] RTCWEB session recording available
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 16 Mar 2013 17:17:01 -0000

------=_Part_0_2614099.1363454212869
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dear all,

the full recording (synchronized video, audio, slides and jabber room) of the 
RTCWEB WG session at IETF 86 is available at the following URL:
http://ietf86.conf.meetecho.com/index.php/Recorded_Sessions#RTCWEB

In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com.

For the chair(s): please feel free to put the link to the recording in the minutes,
if you think this might be useful.

Cheers,
the Meetecho Team


This email has been automatically generated by The Meetecho Conferencing System


------=_Part_0_2614099.1363454212869--

From lgeyser@gmail.com  Sat Mar 16 12:14: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 C03B821F8788 for ; Sat, 16 Mar 2013 12:14:22 -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 4bUcfpxDCM+9 for ; Sat, 16 Mar 2013 12:14:20 -0700 (PDT)
Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by ietfa.amsl.com (Postfix) with ESMTP id 4771821F8780 for ; Sat, 16 Mar 2013 12:14:20 -0700 (PDT)
Received: by mail-lb0-f181.google.com with SMTP id gm6so3675981lbb.12 for ; Sat, 16 Mar 2013 12:14:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=xe6Xzq2kxOuHLWwbX+KsOWv3OVYw1+J1QMJ8fOl2f64=; b=k3p0aVWlQ97Th4j3zRITdWXMmGA999Yb0LVO2f+xlAfr5OWuQyK0JRsDYcRr1atwu5 v3S/eCmAPBHiFepqhVNhE+wP1FMYkQcoAPi1lM+UvvF0JvmZ3Gk4kF6gAPL03S0pOIFc du4/G6d8X5SW9/5YCH1UrrqMYTmfIfQKYz4I0fjlp0saYRVbK7g4q6ULm26PhxEILY2L dLNSre9XuNINooJ8WfgL7s4ieeMMZKq2pBIZseBte6SVuxTnxrJc4Ps9BB8EjaQMRwZX yR35IasgjeUkEB0c83ETcKPEo2chqtJ1kUdD3PxVMCdxm1Zvbv72+FFRwSVvNSiDE3CP 79GA==
MIME-Version: 1.0
X-Received: by 10.112.10.102 with SMTP id h6mr4076353lbb.75.1363461259114; Sat, 16 Mar 2013 12:14:19 -0700 (PDT)
Received: by 10.114.2.76 with HTTP; Sat, 16 Mar 2013 12:14:18 -0700 (PDT)
Date: Sat, 16 Mar 2013 21:14:18 +0200
Message-ID: 
From: Leon Geyser 
To: rtcweb@ietf.org
Content-Type: multipart/alternative; boundary=e0cb4efe305003c17c04d80f9052
Subject: [rtcweb] Interoperability between browsers (MTI Video)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 16 Mar 2013 19:18:45 -0000

--e0cb4efe305003c17c04d80f9052
Content-Type: text/plain; charset=ISO-8859-1

In my opinion there really is a need for a MTI video codec for
interoperability between browsers.

Here are some scenarios on MTI decisions:

-- Decide on no MTI codec:
This would split the browers in two sides.
Those who support VP8 and those who support H.264. The only way these would
be able to communicate with each other is by using a a transcoding server
between the two browsers. (I don't know what the cost impact would be.)
Or
No video stream is sent when two incompatible browsers communicate. Just
audio. Not ideal.

-- Decide on H.264:
This really is not an option unless it can be royalty free with no strings
attached. Only a few browser vendors would be able to implement H.264. This
will also result in: No video stream is sent when to incompatible browsers
communicate. Just audio. Not ideal.

--Decide on VP8:
This would be the ideal choice and there shouldn't be a reason not to
implement VP8.

--Decide on H.261:
This might be old tech, but browsers might be able to use H.261 without
paying any royalties and without transcoding.
The codec can be used at 352x288 resolution from 64Kbit/s to 2Mbit/s
Remember this is just a fallback for interoperability. Browsers will still
implement VP8 and/or H.264.

Here are some examples of what might happen:
Firefox/Chrome/Opera to Firefox/Chrome/Opera: VP8
Safari/IE to Safari/IE : H.264
Firefox/Chrome/Opera to Safari/IE : H.261 fallback

Atleast there is video instead of no Video. Any opinions?

--e0cb4efe305003c17c04d80f9052
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

In my opinion there really is a need for a MTI video codec for interoperabi=
lity between browsers.

Here are some scenarios on MTI decisions:
=

-- Decide on no MTI codec:
This would split the browers in two sides=
.

Those who support VP8 and those who support H.264. The only way these would=
 be able to communicate with each other is by using a a transcoding server =
between the two browsers. (I don't know what the cost impact would be.)=
 

Or
No video stream is sent when two incompatible browsers communicate. J=
ust audio. Not ideal. 

-- Decide on H.264:
This really is not an =
option unless it can be royalty free with no strings attached. Only a few b=
rowser vendors would be able to implement H.264. This will also result in: =
No video stream is sent when to incompatible browsers communicate. Just aud=
io. Not ideal. 

=A0
--Decide on VP8:
This would be the ideal choice and there shouldn=
't be a reason not to implement VP8.

--Decide on H.261:
This =
might be old tech, but browsers might be able to use H.261 without paying a=
ny royalties and without transcoding.

The codec can be used at 352x288 resolution from 64Kbit/s to 2Mbit/s
Rem=
ember this is just a fallback for interoperability. Browsers will still imp=
lement VP8 and/or H.264.

Here are some examples of what might happen=
:

Firefox/Chrome/Opera to Firefox/Chrome/Opera: VP8
Safari/IE to Safari/IE=
 : H.264
Firefox/Chrome/Opera to Safari/IE : H.261 fallback

Atlea=
st there is video instead of no Video. Any opinions?


--e0cb4efe305003c17c04d80f9052--

From btv1==78736fa84fe==HKaplan@acmepacket.com  Sat Mar 16 13:08: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 DD9F621F8489 for ; Sat, 16 Mar 2013 13:08:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.473
X-Spam-Level: 
X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126,  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 Yb44e068tX1a for ; Sat, 16 Mar 2013 13:08:46 -0700 (PDT)
Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 07B5021F8461 for ; Sat, 16 Mar 2013 13:08:45 -0700 (PDT)
X-ASG-Debug-ID: 1363464521-03fc200f2569ba00001-4f8tJD
Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx1.acmepacket.com with ESMTP id mKL7co965lFyPtoG (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Sat, 16 Mar 2013 16:08:41 -0400 (EDT)
X-Barracuda-Envelope-From: HKaplan@acmepacket.com
Received: from MAIL2.acmepacket.com ([169.254.2.222]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Sat, 16 Mar 2013 16:08:41 -0400
From: Hadriel Kaplan 
To: Leon Geyser 
Thread-Topic: [rtcweb] Interoperability between browsers (MTI Video)
X-ASG-Orig-Subj: Re: [rtcweb] Interoperability between browsers (MTI Video)
Thread-Index: AQHOIoINB2FLs5eFwEWPBpfdI6hh5g==
Date: Sat, 16 Mar 2013 20:08:40 +0000
Message-ID: <05D1DDF1-A153-41F2-9726-351AA22075C4@acmepacket.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <7D97CC476304A64884EAA8F49DD14D5A@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21]
X-Barracuda-Start-Time: 1363464521
X-Barracuda-Encrypted: AES128-SHA
X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at acmepacket.com
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.125384 Rule breakdown below pts rule name              description ---- ---------------------- --------------------------------------------------
Cc: "" 
Subject: Re: [rtcweb] Interoperability between browsers (MTI Video)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 16 Mar 2013 20:08:47 -0000

On Mar 16, 2013, at 3:14 PM, Leon Geyser  wrote:

> --Decide on VP8:
> This would be the ideal choice and there shouldn't be a reason not to imp=
lement VP8.

I believe the jury's still out on that.  From what I understand, some of th=
e vendors are concerned that VP8 may still be encumbered by patents outside=
 of MPEG-LA, and besides the details of the RF usage for VP8 from MPEG-LA h=
ave still not been disclosed. (e.g., the strings attached to the usage migh=
t be unacceptable to some vendors)


> --Decide on H.261:
> This might be old tech, but browsers might be able to use H.261 without p=
aying any royalties and without transcoding.
> The codec can be used at 352x288 resolution from 64Kbit/s to 2Mbit/s
> Remember this is just a fallback for interoperability. Browsers will stil=
l implement VP8 and/or H.264.
> ...
> Atleast there is video instead of no Video. Any opinions?

I agree this would be better than nothing, as mentioned on the thread title=
d "Video Codec MTI & User Experience =3D=3D 1".
I also asked a few vendors after this week's meetings whether their existin=
g devices support H.261, but they didn't know.  If most existing video devi=
ces do, then having H.261 as the MTI would also facilitate interop with leg=
acy equipment.  I.e., it would follow the same rationale for why we chose G=
.711 as one of the MTI audio codecs.

-hadriel



From enrico.marocco@telecomitalia.it  Sat Mar 16 13:41: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 03E4C21F8675 for ; Sat, 16 Mar 2013 13:41:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.719
X-Spam-Level: 
X-Spam-Status: No, score=-101.719 tagged_above=-999 required=5 tests=[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 TGN4YllcEPxJ for ; Sat, 16 Mar 2013 13:41:14 -0700 (PDT)
Received: from GRFEDG702RM001.telecomitalia.it (grfedg702rm001.telecomitalia.it [217.169.121.21]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0CD21F8623 for ; Sat, 16 Mar 2013 13:41:14 -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; Sat, 16 Mar 2013 21:41:04 +0100
Received: from airlab.local (163.162.180.246) by smtp.telecomitalia.it (10.19.9.235) with Microsoft SMTP Server (TLS) id 8.3.297.1; Sat, 16 Mar 2013 21:41:02 +0100
Message-ID: <5144D8D7.5080401@telecomitalia.it>
Date: Sat, 16 Mar 2013 16:40:55 -0400
From: Enrico Marocco 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Hadriel Kaplan 
References:  <05D1DDF1-A153-41F2-9726-351AA22075C4@acmepacket.com>
In-Reply-To: <05D1DDF1-A153-41F2-9726-351AA22075C4@acmepacket.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030100060901070000090005"
X-TI-Disclaimer: Disclaimer1
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Interoperability between browsers (MTI Video)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 16 Mar 2013 20:41:15 -0000

--------------ms030100060901070000090005
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

On 3/16/13 4:08 PM, Hadriel Kaplan wrote:
>> --Decide on H.261: This might be old tech, but browsers might be
>> able to use H.261 without paying any royalties and without
>> transcoding. The codec can be used at 352x288 resolution from
>> 64Kbit/s to 2Mbit/s Remember this is just a fallback for
>> interoperability. Browsers will still implement VP8 and/or H.264.
>> ... Atleast there is video instead of no Video. Any opinions?
>
> I agree this would be better than nothing, as mentioned on the thread
> titled "Video Codec MTI & User Experience =3D=3D 1". I also asked a few=

> vendors after this week's meetings whether their existing devices
> support H.261, but they didn't know.  If most existing video devices
> do, then having H.261 as the MTI would also facilitate interop with
> legacy equipment.  I.e., it would follow the same rationale for why
> we chose G.711 as one of the MTI audio codecs.

Not only that. It would also foster competition and innovation. Crappy=20
quality when negotiation falls back on H.261 will be a big incentive for =

the communicating parties to switch to a common browser. In the end the=20
fluctuations in browser market share will take care themselves to set=20
the de-facto standard.

At this point crappy quality may be a feature rather than a bug..

Enrico


--------------ms030100060901070000090005
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
oIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAzMTYy
MDQwNTVaMCMGCSqGSIb3DQEJBDEWBBQUaRudx2Ie4Qgg/P6GYOpZGEPLkTBsBgkqhkiG9w0B
CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEE
AYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T
dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBKfoMIGn
BgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2
BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB
AgMEp+gwDQYJKoZIhvcNAQEBBQAEggEAGIpAyoB3Mhw0GvIHGtiSNqlU5IJMcVE6ivn8t6uy
d6rHbX6o4k1SDYqA5jT0aQRNGtLFREph8oGoNeawNERkeWU31NHiMoUF/UCgWTDGo6RpkalN
AK+Qg0l1fbKtnP+GhSwKF9qzYRDBRFsrQMiBxBWpQ821/mfGdfCoN/0SYt0LPVk0t78kJ8iz
QkoEqg1Rpa4FABhMMGRTFjnM+QjdlnI4c3o5T/vr+npYOsW8ZgQDXIR8Y54F5GQDz7cjfQiL
cWcmH3ynYVVCEz0LhCisnWNtrMoBvh4iEAptN+7ijbbmQn84jJTASrNbiYUuIPFP4SVG1BmD
HpMFSB1XIuaDwAAAAAAAAA==
--------------ms030100060901070000090005--

From bernard_aboba@hotmail.com  Sat Mar 16 13:58: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 C759C21F8464 for ; Sat, 16 Mar 2013 13:58:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.203
X-Spam-Level: 
X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 JkdDgiRieKVk for ; Sat, 16 Mar 2013 13:58:06 -0700 (PDT)
Received: from blu0-omc2-s24.blu0.hotmail.com (blu0-omc2-s24.blu0.hotmail.com [65.55.111.99]) by ietfa.amsl.com (Postfix) with ESMTP id 46F0921F8463 for ; Sat, 16 Mar 2013 13:58:06 -0700 (PDT)
Received: from BLU404-EAS209 ([65.55.111.72]) by blu0-omc2-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 16 Mar 2013 13:58:06 -0700
X-EIP: [s2ybKojTdV/rmuF61U4hrjbyeJpdFrl4]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
References:  <05D1DDF1-A153-41F2-9726-351AA22075C4@acmepacket.com>
From: Bernard Aboba 
MIME-Version: 1.0 (1.0)
In-Reply-To: <05D1DDF1-A153-41F2-9726-351AA22075C4@acmepacket.com>
Date: Sat, 16 Mar 2013 16:58:07 -0400
To: Hadriel Kaplan 
X-OriginalArrivalTime: 16 Mar 2013 20:58:06.0047 (UTC) FILETIME=[F4EE2EF0:01CE2288]
Cc: "" 
Subject: Re: [rtcweb] Interoperability between browsers (MTI Video)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 16 Mar 2013 20:58:06 -0000

On Mar 16, 2013, at 16:08, "Hadriel Kaplan"  wrote:

> I agree this would be better than nothing, as mentioned on the thread titl=
ed "Video Codec MTI & User Experience =3D=3D 1".
> I also asked a few vendors after this week's meetings whether their existi=
ng devices support H.261, but they didn't know.=20

[BA] H.261 is so old and moldy that most vendors ripped it out long ago.  I w=
ent through a dozen different video clients and couldn't find any that suppo=
rted it (though H.263 was included in some cases).=

From bernard_aboba@hotmail.com  Sat Mar 16 14:17: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 784DA21F883C for ; Sat, 16 Mar 2013 14:17:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.203
X-Spam-Level: 
X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 6HcqlO2RBOzp for ; Sat, 16 Mar 2013 14:17:07 -0700 (PDT)
Received: from blu0-omc3-s18.blu0.hotmail.com (blu0-omc3-s18.blu0.hotmail.com [65.55.116.93]) by ietfa.amsl.com (Postfix) with ESMTP id F382321F8838 for ; Sat, 16 Mar 2013 14:17:06 -0700 (PDT)
Received: from BLU402-EAS28 ([65.55.116.74]) by blu0-omc3-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Sat, 16 Mar 2013 14:17:07 -0700
X-EIP: [7LUi99uKz9U4ypodGUlYXzrwMcVOrqID]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
References: 
From: Bernard Aboba 
MIME-Version: 1.0 (1.0)
In-Reply-To: 
Date: Sat, 16 Mar 2013 17:17:08 -0400
To: Leon Geyser 
X-OriginalArrivalTime: 16 Mar 2013 21:17:07.0270 (UTC) FILETIME=[9D26FE60:01CE228B]
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Interoperability between browsers (MTI Video)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 16 Mar 2013 21:17:07 -0000

On Mar 16, 2013, at 15:18, "Leon Geyser"  wrote:

> In my opinion there really is a need for a MTI video codec for interoperab=
ility between browsers.
>=20
> Here are some scenarios on MTI decisions:
>=20
> -- Decide on no MTI codec:
> This would split the browers in two sides.

[BA] No. It just removes the stick that each side can use to beat the other s=
ide.  The need for interoperability still remains, and most likely will eith=
er be addressed by the marketplace choosing one over the other decisively, o=
r if deployment is split, by support for (limited) codec extensibility.=

From lgeyser@gmail.com  Sat Mar 16 15:02: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 6E5DC21F86C9 for ; Sat, 16 Mar 2013 15:02:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.77
X-Spam-Level: 
X-Spam-Status: No, score=-2.77 tagged_above=-999 required=5 tests=[AWL=0.828,  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 MALuzGVLs37r for ; Sat, 16 Mar 2013 15:02:25 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF1721F86C5 for ; Sat, 16 Mar 2013 15:02:25 -0700 (PDT)
Received: by mail-lb0-f172.google.com with SMTP id n8so3717231lbj.31 for ; Sat, 16 Mar 2013 15:02:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Wh23iFE96HqT99Rh89pH7Pj1ebR87S4qxLZrQ4F84ps=; b=DcYScDxXeAUpz8dsg/lwXJXGe9NAwhQiRpmpgFpxlFT/YNHFVoLg1N71HwflJGA3ZV dgNXxFPIbk4bIxGjdCBOYbUg5P1tNdHoVkwTKohFnY8p17SIZBorJ90XTlhR3Hsk4Uk8 2BPHI2oHrPqfii4+qI4hLUrjDk2ex1lHAsaSYqmCVo7C9IPubGV8Iz3WOnVggxrFvScA j7BmI2k9aryVx8WtWDN1jVTYpr6yk+qw9l4EOOv1mRNvTFrB1/EHuLLcF/OpV4ZHUMpW gPEBaUUn/RMzfE3gqQfZO3EMDkpM+EscYGp8ahVe5JQ8IbJvMNILTzAJJJayTwZ0udOe qfog==
MIME-Version: 1.0
X-Received: by 10.152.108.1 with SMTP id hg1mr9731322lab.12.1363471344410; Sat, 16 Mar 2013 15:02:24 -0700 (PDT)
Received: by 10.114.2.76 with HTTP; Sat, 16 Mar 2013 15:02:24 -0700 (PDT)
In-Reply-To: 
References:  
Date: Sun, 17 Mar 2013 00:02:24 +0200
Message-ID: 
From: Leon Geyser 
To: Bernard Aboba 
Content-Type: multipart/alternative; boundary=bcaec54ee22425253104d811e96b
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Interoperability between browsers (MTI Video)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 16 Mar 2013 22:02:26 -0000

--bcaec54ee22425253104d811e96b
Content-Type: text/plain; charset=ISO-8859-1

>
> [BA] No. It just removes the stick that each side can use to beat the
> other side.  The need for interoperability still remains, and most likely
> will either be addressed by the marketplace choosing one over the other
> decisively
>

I don't see how that would address it unless the browser vendors really
care about interoperability. My browser implements the WebRTC without a MTI
video codec spec and implements H.264; why whould I care about the others?
I mean the 

 or if deployment is split, by support for (limited) codec extensibility
Sorry, I don't really understand. How would this '(li=
mited) codec extensibility' work?

On =
16 March 2013 23:17, Bernard Aboba <bernard_aboba@hotmail.com&=
gt; wrote:






On Mar 16, 2013, at 15:18, "Leon Geyser" <lgeyser@gmail.com> wrote:



> In my opinion there really is a need for a MTI video codec for interop=
erability between browsers.

>

> Here are some scenarios on MTI decisions:

>

> -- Decide on no MTI codec:

> This would split the browers in two sides.




[BA] No. It just removes the stick that each side can use to beat the=
 other side. =A0The need for interoperability still remains, and most likel=
y will either be addressed by the marketplace choosing one over the other d=
ecisively, or if deployment is split, by support for (limited) codec extens=
ibility.





--bcaec54ee22425253104d811e96b--

From silviapfeiffer1@gmail.com  Sat Mar 16 16:03: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 E2F7321F8605 for ; Sat, 16 Mar 2013 16:03:26 -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 yuLfotEfyRkE for ; Sat, 16 Mar 2013 16:03:26 -0700 (PDT)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id DA7CE21F859D for ; Sat, 16 Mar 2013 16:03:25 -0700 (PDT)
Received: by mail-la0-f52.google.com with SMTP id fs12so4942289lab.11 for ; Sat, 16 Mar 2013 16:03:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=aVda3TqvGYh2hqojT9TQ1jmWhwIC4R5vPIyixZUusII=; b=kyQ1rMxT6JllwktJU18e+llsBwrwnxk9N88d9ZKtG0YNdKAEL9AHPgBiYjxBuqJGum /915n3nchyjtVHVu7DRAyXg9BniEKZlwtNguVqyhq0Lkjw2Rk5Djc5Y3aBfNpdldCMrg SsHiu+IqB3FqPtCC3c+Jv+zStxnLw5/mNYXuQdgfuLathc6H4B/2csxXfVVeFG809sM7 iVVlwlGPFWRVhkXeVXBU6k4RsYjPElpu6GqlhBObeKN18Ds9YiZLV3HxwtrFtnpvJxkJ 4SDt26Kw2PFIbsLWUGyEYMgsV8HCzQGv0LObZC2VrCeIrmhp7YlVyChXEroGDT7/ORvX V/lA==
X-Received: by 10.112.83.133 with SMTP id q5mr4445398lby.25.1363475004731; Sat, 16 Mar 2013 16:03:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.128.201 with HTTP; Sat, 16 Mar 2013 16:03:03 -0700 (PDT)
In-Reply-To: 
References:   
From: Silvia Pfeiffer 
Date: Sun, 17 Mar 2013 10:03:03 +1100
Message-ID: 
To: Leon Geyser 
Content-Type: multipart/alternative; boundary=f46d04016c2d51428d04d812c3e3
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Interoperability between browsers (MTI Video)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 16 Mar 2013 23:03:27 -0000

--f46d04016c2d51428d04d812c3e3
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Mar 17, 2013 at 9:02 AM, Leon Geyser  wrote:

> [BA] No. It just removes the stick that each side can use to beat the
>> other side.  The need for interoperability still remains, and most likely
>> will either be addressed by the marketplace choosing one over the other
>> decisively
>>
>
> I don't see how that would address it unless the browser vendors really
> care about interoperability. My browser implements the WebRTC without a MTI
> video codec spec and implements H.264; why whould I care about the others?
> I mean the