From bill.wu@huawei.com Thu Mar 1 02:58:48 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA9521F870B for ; Thu, 1 Mar 2012 02:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.343 X-Spam-Level: X-Spam-Status: No, score=-4.343 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_BASE64_TEXT=1.753, 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 f2ASyZugufrL for ; Thu, 1 Mar 2012 02:58:47 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFF321F866B for ; Thu, 1 Mar 2012 02:58:46 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M07002Z7D5MX8@szxga05-in.huawei.com> for avt@ietf.org; Thu, 01 Mar 2012 18:58:34 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0700FK6D5LY8@szxga05-in.huawei.com> for avt@ietf.org; Thu, 01 Mar 2012 18:58:34 +0800 (CST) Received: from szxeml211-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHE25269; Thu, 01 Mar 2012 18:57:47 +0800 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 01 Mar 2012 18:57:15 +0800 Received: from w53375q (10.138.41.149) by szxeml408-hub.china.huawei.com (10.82.67.95) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 01 Mar 2012 18:57:43 +0800 Date: Thu, 01 Mar 2012 18:57:42 +0800 From: Qin Wu X-Originating-IP: [10.138.41.149] To: Magnus Westerlund Message-id: <31521F79682242FC99A0E172329AFA72@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <4F3BB9C2.3020509@ericsson.com> <94DC837519784483ABEA2D7891C9CC08@china.huawei.com> <4F4E30F6.2060800@ericsson.com> Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-monarch-09 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 10:58:48 -0000 SGksIE1hZ251czoNClNlZSBpbmxpbmUgYmVsb3dzLg0KDQpSZWdhcmRzIQ0KLVFpbg0KLS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJNYWdudXMgV2VzdGVybHVuZCIgPG1hZ251 cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4NClRvOiAiUWluIFd1IiA8YmlsbC53dUBodWF3ZWku Y29tPg0KQ2M6ICJJRVRGIEFWVENvcmUgV0ciIDxhdnRAaWV0Zi5vcmc+DQpTZW50OiBXZWRuZXNk YXksIEZlYnJ1YXJ5IDI5LCAyMDEyIDEwOjA2IFBNDQpTdWJqZWN0OiBSZTogW0FWVENPUkVdIENv bW1lbnRzIG9uIGRyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoLTA5DQoNCg0KPiBIaSwNCj4gDQo+ IFRoYW5rcyBmb3IgYWRkcmVzc2luZyBteSBjb21tZW50LiBTZWUgaW5saW5lIHRoZSBvbmVzIHdo ZXJlIEkgaGF2ZQ0KPiBjb21tZW50cyBvciBmZWVkYmFjayBvbiB0aGUgc3VnZ2VzdGlvbnMgZm9y IGZpeGluZyB0aGUgaXNzdWVzLg0KPiANCj4gDQo+IA0KPiBPbiAyMDEyLTAyLTI0IDEwOjEzLCBR aW4gV3Ugd3JvdGU6DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPj4gMy4gSW4gZ2VuZXJhbCBJIHRoaW5rIDMuMSBzaG91bGQgZGlzY3VzcyB3aGF0IGV4 aXN0IGFscmVhZHkgZm9yDQo+PiBtb25pdG9yaW5nIHdoaWNoIHRoZXJlIGlzIG5vIGRpc2N1c3Np b24uIExpa2UgdGhlIFJUUCBNSUIuIEkgY2FuIGFsc28NCj4+IHNlZSBvdGhlciBzb2x1dGlvbnMg bGlrZSB1c2luZyBJUGZpeCB0byBjYXB0dXJlIGEgcGFja2V0IGZsb3cgYW5kIHRoZW4NCj4+IHBy b2Nlc3MgdXNpbmcgYW4gUlRQIGFuZCBSVENQIHJlY2VpdmVyLg0KPj4gIA0KPj4gDQo+PiBbUWlu XSBJIGFncmVlLiBJbiBvcmRlciB0byBmaXggdGhpcywgV2UgcHJvcG9zZQ0KPj4gDQo+PiB0aGUg Zm9sbG93aW5nIHRleHQgYXQgdGhlIGJlZ2lubmluZyBvZiBzZWN0aW9uDQo+PiANCj4+IDMuMSB0 byBzYXk6DQo+PiANCj4+IJMNCj4+IA0KPj4gVGhlcmUgYXJlIG1hbnkgd2F5cyBpbiB3aGljaCB0 aGUgcGVyZm9ybWFuY2UNCj4+IA0KPj4gb2YgYW4gUlRQIHNlc3Npb24gY2FuIGJlIG1vbml0b3Jl ZC4gVGhlc2UNCj4+IA0KPj4gaW5jbHVkZSBSVFAtYmFzZWQgbWVjaGFuaXNtcyBzdWNoIGFzIHRo ZSBSVFANCj4+IA0KPj4gU05NUCBNSUIgW1JGQzI5NTldLCBvciB0aGUgU0lQIGV2ZW50IHBhY2th Z2UNCj4+IA0KPj4gZm9yIFJUQ1Agc3VtbWFyeSByZXBvcnRzIFtSRkM2MDM1XSwgb3Igbm9uLVJU UA0KPj4gDQo+PiBtZWNoYW5pc21zIHN1Y2ggYXMgZ2VuZXJpYyBNSUJzLCBOZXRGbG93LCBJUEZp eCwNCj4+IA0KPj4gYW5kIHNvIG9uLiBUb2dldGhlciwgdGhlc2UgcHJvdmlkZSB1c2VmdWwNCj4+ IA0KPj4gbWVjaGFuaXNtcyBmb3IgZXhwb3J0aW5nIGRhdGEgb24gdGhlIHBlcmZvcm1hbmNlDQo+ PiANCj4+IG9mIGFuIFJUUCBzZXNzaW9uIHRvIG5vbi1SVFAgbmV0d29yayBtYW5hZ2VtZW50DQo+ PiANCj4+IHN5c3RlbXMuIEl0IGlzIGRlc2lyYWJsZSB0byBhbHNvIHBlcmZvcm0gaW4tc2Vzc2lv bg0KPj4gDQo+PiBtb25pdG9yaW5nIG9mIFJUUCBwZXJmb3JtYW5jZS4gUlRDUCBwcm92aWRlcyB0 aGUNCj4+IA0KPj4gbWVhbnMgdG8gZG8gdGhpcy4gSW4gdGhlIGZvbGxvd2luZywgd2Ugc3BlY2lm eSBhbg0KPj4gDQo+PiBhcmNoaXRlY3R1cmUgZm9yIHVzaW5nIGFuZCBleHRlbmRpbmcgUlRDUCBm b3INCj4+IA0KPj4gbW9uaXRvcmluZyBSVFAgc2Vzc2lvbnMuIE9uZSBtYWpvciBiZW5lZml0IG9m DQo+PiANCj4+IHN1Y2ggYXJjaGl0ZWN0dXJlIGlzIHdpdGggZWFzZSBvZiBpbnRlZ3JhdGlvbg0K Pj4gDQo+PiB3aXRoIG90aGVyIFJUUC9SVENQIG1lY2hhbmlzbS4NCj4+IA0KPj4glA0KPiANCj4g WWVzLCB0aGF0IG1ha2VzIHRoZSBzY29wZSBhbmQgY29udGV4dCBtdWNoIG1vcmUgY2xlYXJlci4N Cg0KW1Fpbl06IEdyZWF0IGFuZCBoYXMgZml4ZWQgaW4gdmVyc2lvbiAoLTEwKS4NCg0KPiANCj4+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiA0LiBUaGUgZG9jdW1l bnQgYXJndWVzIGZvciBSVENQIFhSIGJhc2VkIG1vbml0b3JpbmcsIGJ1dCBjYW4geW91IHBsZWFz ZQ0KPj4gcHJvdmlkZSBhIGNsZWFyIGluZGljYXRpb24gb2Ygd2hhdCB0aGUgYmVuZWZpdHMgYXJl Lg0KPj4gIA0KPj4gDQo+PiBbUWluXTogT25lIG1ham9yIGJlbmVmaXQgSSB0aGluayBpcyBFYXNl IG9mDQo+PiANCj4+IGludGVncmF0aW9uIHdpdGggb3RoZXIgUlRQL1JUQ1AgbWVjaGFuaXNtcy4N Cj4+IA0KPj4gQW5vdGhlciBiZW5lZml0IEkgY2FuIHNlZSBpcyBSVENQLWJhc2VkIG1vbml0b3Jp bmcNCj4+IA0KPj4gVGFrZXMgYm90aCB0cmFuc3BvcnQgcXVhbGl0eSBhbmQgYXBwbGljYXRpb24g cXVhbGl0eQ0KPj4gDQo+PiBpbnRvIGFjY291bnQgYW5kIGNhbiBwcm92aWRlIG1vcmUgYWNjdXJh dGUgbWVhc3VyZW1lbnQNCj4+IA0KPj4gZm9yIHRoZSBSZWFsIHRpbWUgYXBwbGljYXRpb24gcXVh bGl0eS4NCj4gDQo+IE15IGludGVudGlvbiB3YXMgdG8gaGF2ZSB0aGF0IG1hZGUgY2xlYXIgaW4g dGhlIGRyYWZ0Lg0KDQpbUWluXTogSSAgc2VlIGFuZCBsaWtlIHRvIHB1dCBhZGRpdGlvbmFsIHRl eHQgaW4gdGhlIGFib3ZlIHByb3Bvc2VkIHRleHQgYXQgdGhlIGJlZ2lubmluZyBvZiBzZWN0aW9u IDMuMS4NCj4gDQo+PiA2LiBTZWN0aW9uIDEuDQo+PiAgICJBcyBtb3JlIHVzZXJzIGFuZCBzdWJz Y3JpYmVycyByZWx5IG9uIHJlYWwgdGltZSBhcHBsaWNhdGlvbiBzZXJ2aWNlcywNCj4+ICAgIHVu Y2VydGFpbnRpZXMgaW4gdGhlIHBlcmZvcm1hbmNlIGFuZCBhdmFpbGFiaWxpdHkgb2YgdGhlc2Ug c2VydmljZXMNCj4+ICAgIGFyZSBkcml2aW5nIHRoZSBuZWVkIHRvIHN1cHBvcnQgbmV3IHN0YW5k YXJkIG1ldGhvZHMgZm9yIGdhdGhlcmluZw0KPj4gICAgcGVyZm9ybWFuY2UgbWV0cmljcyBmcm9t IFJUUCBhcHBsaWNhdGlvbnMuIg0KPj4gDQo+PiBXaGF0IHVzZXJzIGFuZCBzdWJzY3JpYmVycyBh cmUgeW91IGRpc2N1c3NpbmcgYWJvdmU/IFRoZSBvbmVzIHVzaW5nIFJUUA0KPj4gdG8gYnVpbGQg c2VydmljZXMgb3IgdGhlIGFjdHVhbCB1c2VyIG9mIHRoZSBzZXJ2aWNlIHVzaW5nIFJUUD8NCj4+ ICANCj4+IA0KPj4gW1Fpbl06IEkgdGhpbmsgaXQgaXMgdGhlIGxhdHRlci4gSG93IGFib3V0IGNo YW5nZSBpdCBhczoNCj4+IA0KPj4gkw0KPj4gDQo+PiBBcyB0aGUgZGVsaXZlcnkgb2YgbXVsdGlt ZWRpYSBzZXJ2aWNlcyB1c2luZyB0aGUgUmVhbC1UaW1lDQo+PiANCj4+ICBUcmFuc3BvcnQgUHJv dG9jb2wgKFJUUCkgb3ZlciBJUCBuZXR3b3JrIGlzIGdhaW5pbmcgYW4NCj4+IA0KPj4gaW5jcmVh c2luZyBwb3B1bGFyaXR5LCB1bmNlcnRhaW50aWVzIGluIHRoZSBwZXJmb3JtYW5jZSBhbmQNCj4+ IA0KPj4gIGF2YWlsYWJpbGl0eSBvZiB0aGVzZSBzZXJ2aWNlcyBhcmUgZHJpdmluZyB0aGUgbmVl ZCB0bw0KPj4gDQo+PiBzdXBwb3J0IG5ldyBzdGFuZGFyZCBtZXRob2RzIGZvciBnYXRoZXJpbmcg cGVyZm9ybWFuY2UNCj4+IA0KPj4gbWV0cmljcyBmcm9tIFJUUCBhcHBsaWNhdGlvbnMuDQo+PiAN Cj4gDQo+IA0KPiBZZXMsIHRoYXQgaXMgY2xlYXJlci4NCg0KW1Fpbl06IEdyZWF0IGFuZCBoYXMg YWxyZWFkeSBmaXhlZCBpbiB0aGUgdmVyc2lvbiAoLTEwKS4NCg0KPiANCj4+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gOC4gU2VjdGlvbiAxLiAiIFF1YWxpdHkg b2YgRXhwZXJpZW5jZSAoUW9FKS4iIENhbiB5b3UgcGxlYXNlIGluY2x1ZGUNCj4+IHNvbWUgcmVm ZXJlbmNlIHRoYXQgZXhwbGFpbnMgdGhlIGNvbmNlcHQgb2YgUW9FPw0KPj4gIA0KPj4gDQo+PiBb UWluXTogR29vZCBzdWdnZXN0aW9uLCBJIHRoaW5rIHdlIHNob3VsZCByZWZlcmVuY2UNCj4+IA0K Pj4gUkZDNjM5MCBvciBQLjEwL0cuMTAwIEFtZW5kbWVudCAyLiBJIHByZWZlciB0byB1c2UNCj4+ IA0KPj4gUkZDNjM5MC4NCj4gDQo+IFJGQyA2MzkwIGlzIGZpbmUuDQoNCltRaW5dOiBHcmVhdCBh bmQgaGFzIGFscmVhZHkgZml4ZWQgaW4gdGhlIHZlcnNpb24gKC0xMCkuDQoNCj4+IA0KPj4gDQo+ PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiA5LiBTZWN0aW9uIDE6 ICJTaW5jZSBkaWZmZXJlbnQgYXBwbGljYXRpb25zIGxheWVyZWQgb24gUlRQIG1heSBoYXZlDQo+ PiAgICBzb21lIG1vbml0b3JpbmcgcmVxdWlyZW1lbnRzIGluIGNvbW1vbiwgdGhlcmVmb3JlIHRo ZXNlIG1ldHJpY3MNCj4+ICAgIHNob3VsZCBiZSBzYXRpc2ZpZWQgYnkgYSBjb21tb24gZGVzaWdu LiINCj4+ICANCj4+IFRoZSBhYm92ZSBzZW50ZW5jZSBuZWVkcyB0byBiZSByZWZvcm11bGF0ZWQu DQo+PiAgDQo+PiANCj4+IFtRaW5dOiBIb3cgYWJvdXQgcmVwaHJhc2UgbGlrZToNCj4+IA0KPj4g k0dpdmVuIHRoYXQgZGlmZmVyZW50IGFwcGxpY2F0aW9ucyBsYXllcmVkIG9uIFJUUCBtYXkgaGF2 ZQ0KPj4gDQo+PiAgICBzb21lIG1vbml0b3JpbmcgcmVxdWlyZW1lbnRzIGluIGNvbW1vbiwgdGhl c2UgbWV0cmljcw0KPj4gDQo+PiAgICBzaG91bGQgYmUgc2F0aXNmaWVkIGJ5IGEgY29tbW9uIGRl c2lnbi4NCj4+IA0KPiANCj4gSG1tLCBJIGd1ZXNzIGl0IHdvcmtzIGluIHRoZSBjb250ZXh0IGl0 IGlzIHVzZWQgaW4uDQoNCltRaW5dOiBPa2F5LCBzbyB5b3UgYWdyZWUgaXQgZml0cyBpbnRvIHRo ZSBkb2N1bWVudD8hDQoNCj4gDQo+PiAxMS4gU2VjdGlvbiAyOiBPbmUgZXhhbXBsZSBvZiBzdWNo IG1ldHJpY3MgaXMgdGhlIFFvRSBNZXRyaWMNCj4+ICAgICAgIHNwZWNpZmllZCBpbiBRb0UgbWV0 cmljIHJlcG9ydGluZyBCbG9jayBbTVFdLg0KPj4gDQo+PiBJIGRvbid0IHRoaW5rIHRoYXQgcmVm ZXJlbmNlIGlzIGEgZ29vZCBleGFtcGxlLiBUaGUgcmVmZXJlbmNlIGRlZmluZXMNCj4+IGhvdyB0 byB0cmFuc3BvcnQgYW5kIGlkZW50aWZ5IGEgbGFyZ2UgbnVtYmVyIG9mIGFwcGxpY2F0aW9uIGxl dmVsDQo+PiBtZXRyaWNzIGluIFJUQ1AgWFIsIHJhdGhlciB0aGFuIGJlaW5nIGFuIGV4YW1wbGUg b2YgYSBtZXRyaWMuDQo+PiAgDQo+PiANCj4+IFtRaW5dOiBEbyB3ZSBoYXZlIGJldHRlciByZWZl cmVuY2UgdGhhbiB0aGlzIG9uZS4NCj4+IA0KPj4gSSBhbSBhd2FyZSB0aGF0IHNvbWUgSVRVLVQg ZG9jdW1lbnRzIChlLmcuLCBJVFUtVCBQLk5BTVMsDQo+PiANCj4+IFAuTkJBTVMpIGRlZmluZSBt ZWFzdXJlbWVudCBtZXRob2QgYW5kIG1vZGVsIGZvcg0KPj4gDQo+PiBRb0UgZXZhbHVhdGlvbiB3 aGlsZSBvdGhlciBkb2N1bWVudHMgbGlrZSBSRkM2MzkwLA0KPj4gDQo+PiBFLjgwMCwgUC4xMC9H LjEwMCBBbWVuZG1lbnQgMiBvbmx5IGdpdmUgZGVmaW5pdGlvbg0KPj4gDQo+PiBvZiBRb0UuIEFs c28gSSB0aGluayBRb0UgbWV0cmljIHJlcG9ydGluZyBCbG9jayBbTVFdDQo+PiANCj4+IG5vdCBv bmx5IGRlZmluZSBkYXRhIGZvcm1hdCBmb3IgUW9FIG1ldHJpYyBhbmQgYnV0DQo+PiANCj4+IGFs c28gcHJvdmlkZSBNZXRyaWMgbmFtZSBhbmQgZGVzY3JpcHRpb24gZm9yIFFvRSBtZXRyaWMuDQo+ PiANCj4+IElmIHlvdSByZWFsbHkgY29uY2VybnMgdGhpcywgSSBjYW4gcmVtb3ZlIHRoaXMgc2Vu dGVuY2UuDQo+IA0KPiBObywgSSBjYW4gbGl2ZSB3aXRoIHdoYXQgaXMgdGhlcmUuDQoNCltRaW5d OiBHcmVhdC4gDQo+PiANCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4g MTIuIFNlY3Rpb24gMjoNCj4+IENvbXBvc2VkIG1ldHJpY3MNCj4+IA0KPj4gICAgICAgTWV0cmlj cyB0aGF0IGFyZSBjYWxjdWxhdGVkIGJhc2VkIG9uIGRpcmVjdCBtZXRyaWMgb3IgY29tYmluYXRp b24NCj4+ICAgICAgIG9mIGRpcmVjdCBtZXRyaWMgYW5kIGRlcml2ZWQgbWV0cmljcy4NCj4+IA0K Pj4gV2hhdCBpcyBhbiBkZXJpdmVkIG1ldHJpYz8gQXBwZWFycyB0byBiZSBhbiByZWZlcmVuY2Ug d2l0aG91dCBhbg0KPj4gZXhwbGFuYXRpb24uDQo+PiANCj4+IFtRaW5dOiBEZXJpdmVkIG1ldHJp YyBpcyBhY3R1YWxseSBvbmUga2luZCBvZiBjb21wb3NlZCBtZXRyaWMuDQo+PiANCj4+IEhvdyBh Ym91dCBmaXggdGhpcyBsaWtlOg0KPj4gDQo+PiCTDQo+PiANCj4+IENvbXBvc2VkIG1ldHJpY3MN Cj4+IA0KPj4gICAgICBNZXRyaWNzIHRoYXQgYXJlIGNhbGN1bGF0ZWQgYmFzZWQgb24gRGlyZWN0 IG1ldHJpYyB0aGF0IGhhdmUgYmVlbg0KPj4gICAgICBtZWFzdXJlZCBvciBjb21iaW5hdGlvbiBv ZiBEaXJlY3QgbWV0cmljcyB0aGF0IGFyZSBpZGVudGljYWwgdG8gdGhlDQo+PiAgICAgIG1ldHJp YyBiZWluZyBjb21wb3NlZC4NCj4+IJQNCj4gDQo+IFNvcnJ5LCB0aGF0IGxvb2tzIHN0cmFuZ2Ug aW4gdGhlIHNlY29uZCBwYXJ0OiAiY29tYmluYXRpb24gb2YgRGlyZWN0DQo+IG1ldHJpY3MgdGhh dCBhcmUgaWRlbnRpY2FsIHRvIHRoZSBtZXRyaWMgYmVpbmcgY29tcG9zZWQiIEhvdyBjYW4gdGhl eSBiZQ0KPiBpZGVudGljYWwgd2hlbiB0aGV5IGFyZSBhIGNvbWJpbmF0aW9uPw0KDQoNCltRaW5d OiBJIGFncmVlIGl0IGlzIGNvbmZ1c2luZy4gSSBhbSBqdXN0IHRoaW5raW5nIHdlIG1heSBoYXZl IGNhc2Ugd2hlcmUgb25lIG1ldHJpYyANCkEgaXMgY2FsY3VsYXRlZCBieSBvbmUgZGlyZWN0IG1l dHJpYyBCIGFuZCBhbm90aGVyIG1ldHJpYyBDIGFuZCB0aGUgbWV0cmljIEMgaXMgDQpjYWxjdWxh dGVkIGZyb20gdGhlIHNhbWUgZGlyZWN0IG1ldHJpYyBCLiANCkFsc28gd2UgbWF5IGhhdmUgdGhl IGNhc2Ugd2hlcmUgb25lIG1ldHJpYyBEIGlzIGNhbGN1bGF0ZWQgZnJvbSB0d28gb3RoZXIgDQpj b21wb3NlZCBtZXRyaWNzIEUgYW5kIEYuICBJbiB0aGVzZSB0d28gY2FzZXMsIEEsQyxELEUsRiBh cmUgYWxsIGNvbXBvc2VkIG1ldHJpY3MuIA0KSG93IGFib3V0IGNoYW5nZSBpdCBhczoNCpMNCiBD b21wb3NlZCBtZXRyaWNzDQogDQogICAgICBNZXRyaWNzIHRoYXQgYXJlIG5vdCBkaXJlY3RseSBt ZWFzdXJlZCBhbmQgZGVyaXZlZCBmcm9tIG90aGVyIG1ldHJpY3MuIA0KICAgICAgT25lIGV4YW1w bGUgb2Ygc3VjaCBtZXRyaWNzIGlzIHRoZSBvbmVzIGNhbGN1bGF0ZWQgYmFzZWQgb24gRGlyZWN0 IA0KICAgICBtZXRyaWMgdGhhdCBoYXZlIGJlZW4gbWVhc3VyZWQuDQqUDQoNCj4gDQo+IA0KPj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gMTMuIFNl Y3Rpb24gMjoNCj4+ICAgIEludGVydmFsIG1ldHJpY3MNCj4+IA0KPj4gICAgICAgSXQgaXMgcmVm ZXJyZWQgdG8gYXMgdGhlIG1ldHJpY3Mgb2Ygd2hpY2ggdGhlIHJlcG9ydGVkIHZhbHVlcw0KPj4g ICAgICAgYXBwbHkgdG8gdGhlIG1vc3QgcmVjZW50IG1lYXN1cmVtZW50IGludGVydmFsIGR1cmF0 aW9uIGJldHdlZW4NCj4+ICAgICAgIHN1Y2Nlc3NpdmUgbWV0cmljcyByZXBvcnRzDQo+PiANCj4+ IElzICJpbnRlcnZhbCBkdXJhdGlvbiIgYWN0dWFsbHkgZ29vZCBFbmdsaXNoPyBUbyBtZSB0aGUg ZHVyYXRpb24gb2YgYW4NCj4+IGludGVydmFsIGlzIHRoZSBhY3R1YWwgaW50ZXJ2YWwuDQo+PiAg DQo+PiBbUWluXTpNeSB1bmRlcnN0YW5kaW5nIGlzIFllcywgSW50ZXJ2YWwgbWV0cmljcyBpcyBk ZWZpbmVkDQo+PiAgaW4gcmVsYXRpb24gdG8gk2N1bXVsYXRpdmUgbWV0cmljlCBhcyBhIG1ldHJp YyB0aGF0IGFwcGx5DQo+PiAgdG8gdGhlIGR1cmF0aW9uIG9mIGFuIGludGVydmFsLiBUaGUgaW50 ZXJ2YWwgc2hvdWxkIGJlIHRoZQ0KPj4gbW9zdCByZWNlbnQgaW50ZXJ2YWwgdG8gYmUgbWVhc3Vy ZWQgcmF0aGVyIHRoYW4gYWNjdW11bGF0aXZlDQo+PiAgcGVyaW9kIHdpdGhpbiB0aGUgd2hvbGUg c2Vzc2lvbi4NCj4gDQo+IEhtbSwgbGV0IHNlZSBpZiBzb21lb25lIGVsc2UgZ2V0cyB0cmlwcGVk IHVwIGJ5IHRoaXMuDQoNCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4+IDE0LiBTZWN0aW9uIDI6DQo+PiAgICBTYW1wbGVkIG1ldHJpY3MNCj4+ IA0KPj4gICAgICAgSXQgaXMgcmVmZXJyZWQgdG8gYXMgdGhlIG1ldHJpY3Mgb2Ygd2hpY2ggdGhl IHJlcG9ydGVkIHZhbHVlcyBvbmx5DQo+PiAgICAgICBhcHBseSB0byB0aGUgdmFsdWUgb2YgYSBj b250aW51b3VzbHkgbWVhc3VyZWQgb3IgY2FsY3VsYXRlZCB0aGF0DQo+PiAgICAgICBoYXMgYmVl biBzYW1wbGVkIGF0IGVuZCBvZiB0aGUgaW50ZXJ2YWwuDQo+PiANCj4+IERvZXNuJ3QgdGhlIGFi b3ZlIGV4Y2x1ZGUgbWV0cmljcyBtZWFzdXJlZCBhdCBnaXZlIGluc3RhbmNlLiBPciBpcyB0aGF0 DQo+PiB3aGF0ICJzYW1wbGVkIGF0IGVuZCBvZiB0aGUgaW50ZXJ2YWwiIG1lYW5zPyBCdXQgdGhl biBpdCBpc24ndCBhY3R1YWxseQ0KPj4gYW4gaW50ZXJ2YWwsIGlzIGl0Pw0KPj4gIA0KPj4gW1Fp bl06IElkZWFsbHksIEkgdGhpbmsgc2FtcGxlIG1ldHJpYyBjYW4gYmUgYXBwbGllZCB0byBhbnkN Cj4+IGluc3RhbmNlIG9mIG9uZSBtZWFzdXJlbWVudCBpbnRlcnZhbC4gQnV0IEkgYXNzdW1lIHRo ZSBtb3JlDQo+PiBzYW1wbGVkIGRhdGEgeW91IGdhdGhlciBkdXJpbmcgb25lIG1lYXN1cmVtZW50 IGludGVydmFsLCB0aGUNCj4+IG1vcmUgYWNjdXJhdGUgdGhlIHNhbXBsZWQgbWV0cmljIHlvdSBj YW4gY2FsY3VsYXRlLiBEb2VzIHRoaXMNCj4+IG1ha2Ugc2Vuc2U/DQo+IA0KPiBObywgdGhlcmUg aXMgdG8gbXVjaCBjb250ZXh0IG1pc3Npbmcgb2Ygd2hhdCB0eXBlIG9mIG1ldGVyaW5nIG9uZQ0K PiBhdHRlbXB0cyBhbmQgdGhlIGJlaGF2aW9yIG9mIHRoZSBzdWJqZWN0IG9mIHRoZSBtZXRlcmlu Zy4NCg0KIFtRaW5dIFNhbXBsZSBtZXRyaWMgaXMgb25lIG1ldHJpYyB0aGF0IGlzIGRpZmZlcmVu dCBmcm9tIGludGVydmFsIG1ldHJpYyBhbmQgY3VtdWxhdGl2ZSBtZXRyaWMuDQpUYWtlIGludGVy YXJyaXZhbCBqaXR0ZXIgZGVmaW5lZCBpbiBTZWN0aW9uIDYuNC4xIG9mIFtSRkMzNTUwXSBhcyBh IGV4YW1wbGUsIHRoZSB2YWx1ZSBKKGkpIGlzDQogdGhlIGV4YW1wbGUgb2Ygc2FtcGxlZCBtZXRy aWMgYW5kIHNob3VsZCBiZSBjYWxjdWxhdGVkIGFjY29yZGluZyB0byBbUkZDMzU1MF0gYXQgdGhl IHRpbWUgDQp0aGUgcmVwb3J0IGlzIGdlbmVyYXRlZCwgaS5lLiwNCkooaSkgPSBKKGktMSkgKyAo fEQoaS0xLGkpfCAtIEooaS0xKSkvMTYNClRoZXJlZm9yZSBJIHRoaW5rIHlvdXIgc3VnZ2VzdGlv biBpcyByZWFzb25hYmxlLiBUaGF0IGlzIHRvIHNheSwgdGhlIHNhbXBsZWQgbWV0cmljIGNhbiBi ZSANCmNhbGN1bGF0ZWQgYXQgYW55IGluc3RhbmNlIG9mIG1lYXN1cmVtZW50IGludGVydmFsIHJh dGhlciB0aGFuIG9ubHkgYXQgdGhlIGVuZCBvZiBtZWFzdXJlbWVudCANCmludGVydmFsLiBJZiB5 b3UgYWdyZWUgd2l0aCB0aGlzLCBJIGxpa2UgdG8gcHJvcG9zZSB0aGUgZm9sbG93aW5nIGNoYW5n ZSB0byBzYW1wbGVkIG1ldHJpY3MgZGVmaW5pdGlvbjoNCpMNCiAgICBTYW1wbGVkIG1ldHJpY3MN CiANCiAgICAgICBJdCBpcyByZWZlcnJlZCB0byBhcyB0aGUgbWV0cmljcyBvZiB3aGljaCB0aGUg cmVwb3J0ZWQgdmFsdWVzIG9ubHkNCiAgICAgICBhcHBseSB0byB0aGUgdmFsdWUgb2YgYSBjb250 aW51b3VzbHkgbWVhc3VyZWQgb3IgY2FsY3VsYXRlZCB0aGF0DQogICAgICAgaGFzIGJlZW4gc2Ft cGxlZCBhdCBhbnkgZ2l2ZW4gaW5zdGFuY2Ugb2YgdGhlIGludGVydmFsLg0KlA0KRG9lcyB0aGlz IGFkZHJlc3MgeW91ciBjb21tZW50cz8NCj4gDQo+IA0KPiANCj4+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IDE3LiBTZWN0aW9uIDMuMjoN Cj4+ICAgIG8gIFJUQ1AgTkFDSyBpcyB1c2VkIHRvIHByb3ZpZGUgZmVlZGJhY2sgb24gdGhlIFJU UCBzZXF1ZW5jZSBudW1iZXINCj4+ICAgICAgIG9mIHRoZSBsb3N0IHBhY2tldHMgW1JGQzQ1ODVd Lg0KPj4gDQo+PiBJbiB0aGlzIGNhc2UgSSB3b3VsZCBiZSBhIGJpdCBjYXJlZnVsLiBCZWNhdXNl IHRoZSBzZXF1ZW5jZSBudW1iZXJzDQo+PiByZXBvcnRlZCBvbiBpbiBOQUNLIG1heSBpbiBmYWN0 IGJlIGEgc3Vic2V0IG9mIGFsbCBsb3N0IHBhY2tldHMuIEFscmVhZHkNCj4+IHRoZSBtZWRpYSBz dHJlYW0gcmVjZWl2ZXIgY3JlYXRpbmcgTkFDSyByZXF1ZXN0cyBtYXkgaW4gZmFjdCBmaWx0ZXIg b24NCj4+IHdoaWNoIHNlcXVlbmNlIG51bWJlciBpcyByZXBvcnRlZC4gVGhlcmUgd2FzIGEgcHJv cG9zYWwgZm9yIGENCj4+IGluZm9ybWF0aXZlIGJsb2NrIChkcmFmdC1pZXRmLWF2dC1ydHAtc2Vs cmV0LTA1LnR4dCkgdGhhdCBhbGxvd2VkIGZvcg0KPj4gdGhpcyB0eXBlIG9mIGluZm9ybWF0aW9u LiBUaGVyZSBpcyBvdGhlciBjYXNlcyB3aGVyZSBhIHJlY2VpdmVyIHdpbGwgYmUNCj4+IGFibGUg dG8gZGV0ZXJtaW5lIHRoYXQgaXQgZG9lc24ndCBuZWVkIHRvIGFzayBmb3Igc29tZSBsb3N0IHBh Y2tldHMuDQo+PiAgDQo+PiANCj4+IFtRaW5dOiBPa2F5LCBIb3cgYWJvdXQgcmVwaHJhc2UgdGhp cyBzZW50ZW5jZSBhczoNCj4+IA0KPj4gkw0KPj4gDQo+PiAgICBvICBSVENQIE5BQ0sgaXMgdXNl ZCB0byBwcm92aWRlIGZlZWRiYWNrIG9uIHRoZSBSVFAgc2VxdWVuY2UgbnVtYmVyDQo+PiANCj4+ ICAgICAgIG9uIGEgc3Vic2V0IG9mIHRoZSBsb3N0IHBhY2tldHMgb3IgdGhlIHRvdGFsIGxvc3Qg cGFja2V0c1tSRkM0NTg1XS4NCj4+IA0KPj4glA0KPiANCj4gRXhjZXB0IHRoYXQgIm51bWJlcnMi IGFuZCAiZm9yIGEgc3Vic2V0Ii4gSSBhbHNvIHRoaW5rICJ0b3RhbCIgaXMgbGlrZWx5DQo+IHdy b25nIGFuZCAiYWxsIHRoZSBjdXJyZW50bHkiDQoNCltRaW5dOiBEbyB5b3Ugc3VnZ2VzdCB0byB0 aGUgZm9sbG93aW5nIGNoYW5nZToNCpMNClJUQ1AgTkFDSyBpcyB1c2VkIHRvIHByb3ZpZGUgZmVl ZGJhY2sgb24gdGhlIFJUUCBzZXF1ZW5jZSBudW1iZXJzIA0KZm9yIGEgc3Vic2V0IG9mIHRoZSBs b3N0IHBhY2tldHMgb3IgYWxsIHRoZSBjdXJyZW50bHkgbG9zdCBwYWNrZXRzIFtSRkM0NTg1XS4N Cg0KlA0KSWYgeWVzLCBJIGxpa2UgdG8gZml4IHRoaXMgYXMgeW91IHN1Z2dlc3RlZC4gSWYgbm90 LCBwbGVhc2UgbGV0IG1lIGtub3cuDQoNCj4gDQo+IENoZWVycw0KPiANCj4gTWFnbnVzIFdlc3Rl cmx1bmQNCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gTXVsdGltZWRpYSBUZWNobm9sb2dpZXMsIEVy aWNzc29uIFJlc2VhcmNoIEVBQi9UVk0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBFcmljc3NvbiBBQiAg ICAgICAgICAgICAgICB8IFBob25lICArNDYgMTAgNzE0ODI4Nw0KPiBG5HL2Z2F0YW4gNiAgICAg ICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KPiBTRS0xNjQgODAgU3RvY2tob2xt LCBTd2VkZW58IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4= From christer.holmberg@ericsson.com Thu Mar 1 03:06:05 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F250421F86F6 for ; Thu, 1 Mar 2012 03:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.206 X-Spam-Level: X-Spam-Status: No, score=-10.206 tagged_above=-999 required=5 tests=[AWL=0.393, 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 H7zAzEchUbsr for ; Thu, 1 Mar 2012 03:06:04 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id DE3AB21F86DA for ; Thu, 1 Mar 2012 03:06:03 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-bc-4f4f581af094 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 33.F8.27041.A185F4F4; Thu, 1 Mar 2012 12:06:03 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.31]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Thu, 1 Mar 2012 12:06:02 +0100 From: Christer Holmberg To: Roni Even , 'Harald Alvestrand' , Magnus Westerlund Date: Thu, 1 Mar 2012 12:06:03 +0100 Thread-Topic: [AVTCORE] avtcore - session for IETF 83 - requests for agenda time. Thread-Index: Acz2uvMc/pPJ3mKjR3WPwMGfHGVfggAADqlwADfvR4A= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3F6AADE0@ESESSCMS0356.eemea.ericsson.se> References: <4f47cc67.c77d0e0a.7c07.ffffe4bb@mx.google.com> <4F4CAC2D.5000704@ericsson.com> <4F4DDFB6.2080008@alvestrand.no> <4f4de0fc.c8b80e0a.77c3.ffffba3e@mx.google.com> In-Reply-To: <4f4de0fc.c8b80e0a.77c3.ffffba3e@mx.google.com> 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 X-Brightmail-Tracker: AAAAAA== Cc: "avt@ietf.org" Subject: Re: [AVTCORE] avtcore - session for IETF 83 - requests for agenda time. X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 11:06:05 -0000 Hi, I also support this agenda request. According to the current agenda (2012-02-27), however, there is a conflict = between the second AVTCORE session and the SESSIONID session. So, if possib= le, I would request the chairs to put this on the agenda for the first AVTC= ORE session (currently there are at least no other RAI meetings scheduled f= or that session). Regards, Christer =20 -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni = Even Sent: 29. helmikuuta 2012 10:25 To: 'Harald Alvestrand'; Magnus Westerlund Cc: avt@ietf.org Subject: Re: [AVTCORE] avtcore - session for IETF 83 - requests for agenda = time. Hi Harald, OK, I will add your draft to the topic, I assume you will have some slides = to present BTW: note that the deadline for 01 draft submission is March 12. BR Roni > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: Wednesday, February 29, 2012 10:20 AM > To: Magnus Westerlund > Cc: Roni Even; avt@ietf.org > Subject: Re: [AVTCORE] avtcore - session for IETF 83 - requests for=20 > agenda time. >=20 > On 02/28/2012 11:27 AM, Magnus Westerlund wrote: > > WG, > > > > I will in my role as individual contributor request agenda time for=20 > > continuing the discussion in Taipei around RTP multiplexing in > general > > and the specific topic of multiplexing multiple RTP session on a=20 > > single UDP flow. There will be updated drafts for both these topics=20 > > before the draft update cut-off. >=20 > I support this request. Please include discussion of draft-alvestrand-=20 > rtp-sess-neutral-00.txt in this agenda topic. >=20 > (Comments on this draft are still welcome, and if they come in this=20 > week, there MAY be an -01 version before the deadline. So far, there=20 > have been no comments.) >=20 > Harald > > > > Magnus > > > > On 2012-02-24 18:43, Roni Even wrote: > >> Hi, > >> > >> This is the schedule for AVTcore. Note that the agenda is not=20 > >> final > and can change. Final meeting agenda will be published on March 2^nd . > >> > >> > >> > >> MONDAY, March 26, 2012 > >> > >> > >> > >> 1300-1500 Afternoon Session I > >> > >> 252B RAI avtcore > >> Audio/Video Transport Core Maintenance WG > >> > >> > >> > >> 1510-1610 Afternoon Session II > >> > >> 252B RAI avtcore > >> Audio/Video Transport Core Maintenance WG > >> > >> > >> > >> > >> > >> If you wish to have agenda time at the upcoming meeting in Paris=20 > >> regarding AVTcore work, please send an agenda request to the=20 > >> AVTcore chairs. We are trying to prepare the agenda early and not=20 > >> wait for the last minute. > >> > >> > >> > >> Payload WG is not meeting in Paris and we may allocate some time to=20 > >> resolve open issues regarding payload drafts time permitting. > >> > >> > >> > >> Note the document submission deadline are March 5^th for initial=20 > >> document (00 drafts) and March 12^th is the final submission date. > >> > >> > >> > >> Roni Even > >> > >> AVTcore co-chair > >> > >> > >> > >> > >> > >> > >> > > _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From Even.roni@huawei.com Thu Mar 1 03:19:32 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE9D21F857D for ; Thu, 1 Mar 2012 03:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.582 X-Spam-Level: X-Spam-Status: No, score=-106.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 7qoyyufe1GVC for ; Thu, 1 Mar 2012 03:19:32 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id B219A21F859A for ; Thu, 1 Mar 2012 03:19:31 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0700HQ9E3H5C@szxga03-in.huawei.com> for avt@ietf.org; Thu, 01 Mar 2012 19:18:53 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0700K70E3GED@szxga03-in.huawei.com> for avt@ietf.org; Thu, 01 Mar 2012 19:18:53 +0800 (CST) Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHN40356; Thu, 01 Mar 2012 19:18:39 +0800 Received: from SZXEML439-HUB.china.huawei.com (10.72.61.74) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 01 Mar 2012 19:18:08 +0800 Received: from SZXEML536-MBX.china.huawei.com ([169.254.4.220]) by szxeml439-hub.china.huawei.com ([10.72.61.74]) with mapi id 14.01.0323.003; Thu, 01 Mar 2012 19:18:38 +0800 Date: Thu, 01 Mar 2012 11:18:37 +0000 From: Roni even In-reply-to: <7F2072F1E0DE894DA4B517B93C6A05852C3F6AADE0@ESESSCMS0356.eemea.ericsson.se> X-Originating-IP: [172.24.1.46] To: Christer Holmberg , Roni Even , 'Harald Alvestrand' , Magnus Westerlund Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [AVTCORE] avtcore - session for IETF 83 - requests for agenda time. Thread-index: AQHM95tTDS7YJKqMb0KL02ZWibOKvZZVSlrs X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4f47cc67.c77d0e0a.7c07.ffffe4bb@mx.google.com> <4F4CAC2D.5000704@ericsson.com> <4F4DDFB6.2080008@alvestrand.no> <4f4de0fc.c8b80e0a.77c3.ffffba3e@mx.google.com> <7F2072F1E0DE894DA4B517B93C6A05852C3F6AADE0@ESESSCMS0356.eemea.ericsson.se> Cc: "avt@ietf.org" Subject: Re: [AVTCORE] avtcore - session for IETF 83 - requests for agenda time. X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 11:19:32 -0000 Hi Christer, I had other requests to handle this topic in the first session and I see no problem since anyhow it is of high interest Roni ________________________________________ From: avt-bounces@ietf.org [avt-bounces@ietf.org] on behalf of Christer Holmberg [christer.holmberg@ericsson.com] Sent: Thursday, March 01, 2012 13:06 To: Roni Even; 'Harald Alvestrand'; Magnus Westerlund Cc: avt@ietf.org Subject: Re: [AVTCORE] avtcore - session for IETF 83 - requests for agenda time. Hi, I also support this agenda request. According to the current agenda (2012-02-27), however, there is a conflict between the second AVTCORE session and the SESSIONID session. So, if possible, I would request the chairs to put this on the agenda for the first AVTCORE session (currently there are at least no other RAI meetings scheduled for that session). Regards, Christer -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even Sent: 29. helmikuuta 2012 10:25 To: 'Harald Alvestrand'; Magnus Westerlund Cc: avt@ietf.org Subject: Re: [AVTCORE] avtcore - session for IETF 83 - requests for agenda time. Hi Harald, OK, I will add your draft to the topic, I assume you will have some slides to present BTW: note that the deadline for 01 draft submission is March 12. BR Roni > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: Wednesday, February 29, 2012 10:20 AM > To: Magnus Westerlund > Cc: Roni Even; avt@ietf.org > Subject: Re: [AVTCORE] avtcore - session for IETF 83 - requests for > agenda time. > > On 02/28/2012 11:27 AM, Magnus Westerlund wrote: > > WG, > > > > I will in my role as individual contributor request agenda time for > > continuing the discussion in Taipei around RTP multiplexing in > general > > and the specific topic of multiplexing multiple RTP session on a > > single UDP flow. There will be updated drafts for both these topics > > before the draft update cut-off. > > I support this request. Please include discussion of draft-alvestrand- > rtp-sess-neutral-00.txt in this agenda topic. > > (Comments on this draft are still welcome, and if they come in this > week, there MAY be an -01 version before the deadline. So far, there > have been no comments.) > > Harald > > > > Magnus > > > > On 2012-02-24 18:43, Roni Even wrote: > >> Hi, > >> > >> This is the schedule for AVTcore. Note that the agenda is not > >> final > and can change. Final meeting agenda will be published on March 2^nd . > >> > >> > >> > >> MONDAY, March 26, 2012 > >> > >> > >> > >> 1300-1500 Afternoon Session I > >> > >> 252B RAI avtcore > >> Audio/Video Transport Core Maintenance WG > >> > >> > >> > >> 1510-1610 Afternoon Session II > >> > >> 252B RAI avtcore > >> Audio/Video Transport Core Maintenance WG > >> > >> > >> > >> > >> > >> If you wish to have agenda time at the upcoming meeting in Paris > >> regarding AVTcore work, please send an agenda request to the > >> AVTcore chairs. We are trying to prepare the agenda early and not > >> wait for the last minute. > >> > >> > >> > >> Payload WG is not meeting in Paris and we may allocate some time to > >> resolve open issues regarding payload drafts time permitting. > >> > >> > >> > >> Note the document submission deadline are March 5^th for initial > >> document (00 drafts) and March 12^th is the final submission date. > >> > >> > >> > >> Roni Even > >> > >> AVTcore co-chair > >> > >> > >> > >> > >> > >> > >> > > _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From rjsparks@nostrum.com Thu Mar 1 14:27:18 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072AE21E8396 for ; Thu, 1 Mar 2012 14:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, 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 tzY+aChNZQWG for ; Thu, 1 Mar 2012 14:27:17 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 59E6A21E8357 for ; Thu, 1 Mar 2012 14:27:17 -0800 (PST) Received: from unexplicable.local (pool-71-170-125-181.dllstx.fios.verizon.net [71.170.125.181]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q21MRDG3047052 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 1 Mar 2012 16:27:14 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <4F4FF7C1.6040501@nostrum.com> Date: Thu, 01 Mar 2012 16:27:13 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: avt@ietf.org, avtcore-chairs@tools.ietf.org, draft-ietf-avtcore-feedback-suppression-rtp@tools.ietf.org, Gonzalo Camarillo Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 71.170.125.181 is authenticated by a trusted mechanism) Subject: [AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-rtp-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 22:27:18 -0000 Summary: There are some clarifications needed (and some questions to discuss) before forwarding this to IETF LC. 1) Section 3, paragraph 3, says a receiver MUST follow the rules for NACK suppression on receipt of a third partly loss report. Section 4 says receivers MAY ignore third party lost reports, and then confusingly says the SHOULD not ignore them. The security considerations section says that receivers would be "well advised to ignore" (effectively SHOULD ignore) third party reports unless they are authenticated. This needs to be reconciled. Are you trying to say the following? *) MUST follow the suppression rules if packets are authenticated *) SHOULD NOT follow the suppression rules if the packets are not authenticated Or something else? Either way, please make the document internally consistent. 2) Why aren't RFC3711 and RFC5124 normative references? They're the only offered tools for authenticating these messages in the document. Even if other mechanisms might exist, there needs to be discussion somewhere of what's required of this authentication, and the security consideration sections of those documents would suffice. 3) The first part of the IANA considerations section is not clear. Is this trying to create a new registry with two initial values, or add two values to an existing registry. If it's creating a new one, please provide a registry name, and suggest where it should appear. 4) The security considerations section speaks about attacks based on spurious reports, but doesn't really discuss more directed attacks. In particular, if a receiver accepts unauthenticated feedback suppression messages, an attacker could cause packetloss disrupting an important part of a session, preemptively sending feedback suppression. An attacker that is also a receiver has enough information to suppress _all_ feedback from any other listeners that don't unauthenticated packets. Please make it clearer that these risks exist. 5) At the end of section 3, the document says messages SHOULD be suppressed "for a period of time". Can that be made more precise? Editorial suggestions: Please expand acronyms on first use (There are a _lot_ of acronyms, many of which need references to where they are defined. Consider adding a glossary so you can get that out of the way without interrupting the flow of the text). The protocol definition part of this document (section 4) is a bit of a puzzle for a new reader. It would help to guide the reader through the definition more directly. Here's a suggested modification - feel free to ignore it: Before section 4.1 say "The following two sections each define a third party loss report message. Both messages are feedback messages as defined in section 6.1 of RFC4585, and use the header format defined there. Each section defines how to populate the PT, FMT, length, SSRC or packet sender, SSRC of media source, and FCI fields in that header." That will make it more obvious to the reader that they need to go look at the referenced section in 4585 right away, and makes it possible to simplify the text in 4.1 and 4.2. 4.1 can state clearly and early that it is defining the TLLEI, etc. Whether you choose to act on this suggestion or not, please change the TBDs to TBD1 and TBD2, and say "length field in the" instead of "length of" when talking about setting the length field in each message. Nits sent directly to editors. From Aidan.Williams@audinate.com Thu Mar 1 15:41:40 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36EE221E83E1 for ; Thu, 1 Mar 2012 15:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUbEDjuClhwq for ; Thu, 1 Mar 2012 15:41:39 -0800 (PST) Received: from sydney.audinate.com (sydney.audinate.com [150.101.200.21]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFC021E82BA for ; Thu, 1 Mar 2012 15:41:39 -0800 (PST) Received: from zimbra.audinate.com (zimbra.audinate.com [10.12.0.6]) by sydney.audinate.com (Postfix) with ESMTP id 92F44180075 for ; Fri, 2 Mar 2012 10:41:37 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by zimbra.audinate.com (Postfix) with ESMTP id 840BD9E03B6 for ; Fri, 2 Mar 2012 10:41:37 +1100 (EST) X-Virus-Scanned: amavisd-new at zimbra.audinate.com Received: from zimbra.audinate.com ([127.0.0.1]) by localhost (zimbra.audinate.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sp1nFD6DzliC for ; Fri, 2 Mar 2012 10:41:36 +1100 (EST) Received: from praxis.local (unknown [10.12.0.199]) by zimbra.audinate.com (Postfix) with ESMTPSA id 6E95B9DFCA5 for ; Fri, 2 Mar 2012 10:41:36 +1100 (EST) Message-ID: <4F500930.70406@audinate.com> Date: Fri, 02 Mar 2012 10:41:36 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: avt@ietf.org References: <20120229032609.24943.98302.idtracker@ietfa.amsl.com> In-Reply-To: <20120229032609.24943.98302.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [AVTCORE] New draft: draft-williams-avtcore-clksrc-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 23:41:40 -0000 Hi all, A new draft has been submitted describing how to signal the clock source (e.g. NTP, IEEE 1588, etc) used for RTP timestamps. This draft combines the clock source signalling parts from from draft-ietf-avtcore-idms-02 specification and draft-williams-avtext-avbsync-02 into a separate building block document. Comments are welcome. regards aidan ____ :wq! -------- Original Message -------- Subject: I-D Action: draft-williams-avtcore-clksrc-00.txt Date: Tue, 28 Feb 2012 19:26:09 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RTP Clock Source Signalling Author(s) : Aidan Williams Ray van Brandenburg Filename : draft-williams-avtcore-clksrc-00.txt Pages : 16 Date : 2012-02-27 NTP timestamps are used by several RTP protocols for synchronisation and statistical measurement. This memo specificies SDP signalling identifying NTP timestamp clock sources and SDP signalling identifying the media clock sources in a multimedia session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-williams-avtcore-clksrc-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-williams-avtcore-clksrc-00.txt _______________________________________________ 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 orftp://ftp.ietf.org/ietf/1shadow-sites.txt From bill.wu@huawei.com Thu Mar 1 20:53:14 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E2821E811E for ; Thu, 1 Mar 2012 20:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.518 X-Spam-Level: X-Spam-Status: No, score=-5.518 tagged_above=-999 required=5 tests=[AWL=1.081, 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 vPQr2-Fm0A1p for ; Thu, 1 Mar 2012 20:53:14 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3377321E8113 for ; Thu, 1 Mar 2012 20:53:13 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0800GIBQWGTU@szxga03-in.huawei.com> for avt@ietf.org; Fri, 02 Mar 2012 12:53:04 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0800HE1QWGBH@szxga03-in.huawei.com> for avt@ietf.org; Fri, 02 Mar 2012 12:53:04 +0800 (CST) Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHN79099; Fri, 02 Mar 2012 12:53:02 +0800 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 02 Mar 2012 12:52:30 +0800 Received: from w53375q (10.138.41.149) by szxeml417-hub.china.huawei.com (10.82.67.156) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 02 Mar 2012 12:53:00 +0800 Date: Fri, 02 Mar 2012 12:52:59 +0800 From: Qin Wu X-Originating-IP: [10.138.41.149] To: Robert Sparks , avt@ietf.org, avtcore-chairs@tools.ietf.org, draft-ietf-avtcore-feedback-suppression-rtp@tools.ietf.org, Gonzalo Camarillo Message-id: <93213B506E254BE7941B02E9630EAB00@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <4F4FF7C1.6040501@nostrum.com> Subject: Re: [AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-rtp-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 04:53:15 -0000 Hi, Robert: Thank for your valuable review, please see my replies inline below. Regards! -Qin ----- Original Message ----- From: "Robert Sparks" To: ; ; ; "Gonzalo Camarillo" Sent: Friday, March 02, 2012 6:27 AM Subject: [AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-rtp-13 > Summary: There are some clarifications needed (and some questions to > discuss) before forwarding this to IETF LC. > > 1) Section 3, paragraph 3, says a receiver MUST follow the rules for > NACK suppression on receipt of a third partly loss report. Section 4 > says receivers MAY ignore third party lost reports, and then confusingly > says the SHOULD not ignore them. The security considerations section > says that receivers would be "well advised to ignore" (effectively > SHOULD ignore) third party reports unless they are authenticated. This > needs to be reconciled. > > Are you trying to say the following? > > *) MUST follow the suppression rules if packets are authenticated > *) SHOULD NOT follow the suppression rules if the packets are not > authenticated > > Or something else? Either way, please make the document internally > consistent. [Qin]: The reason to use "MUST" is it was suggested by the reviewer since RFC4585 that uses "MUST" in the context of client feedback suppression. But I agree this description does not clarify in what circumstance to apply MUST. To be consistent with what we described in the security section, I agree with your suggestion to the security section, that is to say the suppression rule is only applied when the packet are integrity protected and authenticated. I can put some text to make this clear. > > 2) Why aren't RFC3711 and RFC5124 normative references? They're the only > offered tools for authenticating these messages in the document. Even if > other mechanisms might exist, there needs to be discussion somewhere of > what's required of this authentication, and the security consideration > sections of those documents would suffice. [Qin] Agree, for discussion on where the authentication is required, I like to follow your suggestion, please see above clarification. Also I will move RFC3711 and RFC5124 to normative references. Does this address your comment? > > 3) The first part of the IANA considerations section is not clear. Is > this trying to create a new registry with two initial values, or add two > values to an existing registry. If it's creating a new one, please > provide a registry name, and suggest where it should appear. [Qin]: I think it is latter. To make it clear, I propose the following change: OLD Text: " For use with "nack" [RFC4585], a joint sub-registry has been set up that registers the following two values: The value registration for the attribute value "nack": " New Text: " For use with "nack" [RFC4585], this document instructs IANA to add two values in "ack" and "nack" Attribute Values registry: The value registration for the attribute value "nack": " > 4) The security considerations section speaks about attacks based on > spurious reports, but doesn't really discuss more directed attacks. In > particular, if a receiver accepts unauthenticated feedback suppression > messages, an attacker could cause packetloss disrupting an important > part of a session, preemptively sending feedback suppression. An > attacker that is also a receiver has enough information to suppress > _all_ feedback from any other listeners that don't unauthenticated > packets. Please make it clearer that these risks exist. [Qin]: Okay. Based on your above suggestion, I like to propose the following change to the section 7,3rd paragraph: OLD text: " Sending the spurious Third Party Loss Report (e.g., the Third Party Loss Report with the wrong sequence number of lost packet) that causes missing RTP packets to not be repaired in a timely fashion. " New Text: " Sending the spurious Third Party Loss Report packet (e.g., the Third Party Loss Report with the wrong sequence number of lost packet) that causes missing RTP packets to not be repaired in a timely fashion. If a receiver accepts such unauthenticated packet, an attacker could cause packet loss disrupting an important part of a session, preemptively sending feedback suppression. An attacker that is also a receiver has enough information to suppress all the feedbacks from any other listeners that don't accept unauthenticated packets. " Does this address your comment? > 5) At the end of section 3, the document says messages SHOULD be > suppressed "for a period of time". Can that be made more precise? [Qin]: Sorry, I forgot to clear that nits in the previous version. Since we follow the feedback suppression rule we defined in RFC4585, I think the receivers should suppress the further feedback for the same packet loss. Therefore I like to remove "for a period of time". > Editorial suggestions: > > Please expand acronyms on first use (There are a _lot_ of acronyms, many > of which need references to where they are defined. Consider adding a > glossary so you can get that out of the way without interrupting the > flow of the text). [Qin]: Okay. > The protocol definition part of this document (section 4) is a bit of a > puzzle for a new reader. It would help to guide the reader through the > definition more directly. Here's a suggested modification - feel free to > ignore it: > > Before section 4.1 say "The following two sections each define a third > party loss report message. Both messages are feedback messages as > defined in section 6.1 of RFC4585, and use the header format defined > there. Each section defines how to populate the PT, FMT, length, SSRC or > packet sender, SSRC of media source, and FCI fields in that header." > > That will make it more obvious to the reader that they need to go look > at the referenced section in 4585 right away, and makes it possible to > simplify the text in 4.1 and 4.2. 4.1 can state clearly and early that > it is defining the TLLEI, etc. [Qin]: Looks good to me. > Whether you choose to act on this suggestion or not, please change the > TBDs to TBD1 and TBD2, and say "length field in the" instead of "length > of" when talking about setting the length field in each message. [Qin]: Okay. > Nits sent directly to editors. [Qin]: Thanks. > > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From internet-drafts@ietf.org Thu Mar 1 23:53:25 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1B421F885B; Thu, 1 Mar 2012 23:53:25 -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, 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 N-l37Y4PRG2i; Thu, 1 Mar 2012 23:53:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165BD21F8857; Thu, 1 Mar 2012 23:53:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120302075325.15464.64953.idtracker@ietfa.amsl.com> Date: Thu, 01 Mar 2012 23:53:25 -0800 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-feedback-supression-rtp-14.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 07:53:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenanc= e Working Group of the IETF. Title : RTCP Extension for Third-party Loss Report Author(s) : Qin Wu Frank Xia Roni Even Filename : draft-ietf-avtcore-feedback-supression-rtp-14.txt Pages : 18 Date : 2012-03-01 In a large RTP session using the RTCP feedback mechanism defined in RFC 4585, a feedback target may experience transient overload if some event causes a large number of receivers to send feedback at once. This overload is usually avoided by ensuring that feedback reports are forwarded to all receivers, allowing them to avoid sending duplicate feedback reports. However, there are cases where it is not recommended to forward feedback reports, and this may allow feedback implosion. This memo discusses these cases and defines a new RTCP third-party loss report that can be used to inform receivers that the feedback target is aware of some loss event, allowing them to suppress feedback. Associated SDP signalling is also defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-= rtp-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-r= tp-14.txt From internet-drafts@ietf.org Fri Mar 2 00:09:25 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F95921E805C; Fri, 2 Mar 2012 00:09:25 -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, 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 X4k3TX5g83Ee; Fri, 2 Mar 2012 00:09:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FA621E8045; Fri, 2 Mar 2012 00:09:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120302080924.19936.87559.idtracker@ietfa.amsl.com> Date: Fri, 02 Mar 2012 00:09:24 -0800 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-11.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 08:09:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenanc= e Working Group of the IETF. Title : Monitoring Architecture for RTP Author(s) : Qin Wu Geoff Hunt Philip Arden Filename : draft-ietf-avtcore-monarch-11.txt Pages : 29 Date : 2012-03-02 This memo proposes an architecture for extending RTP Control Protocol (RTCP) with a new RTCP Extended Reports (XR) (RFC3611) block type to report new metrics regarding media transmission or reception quality, following RTCP guideline established in RFC5968. This memo suggests that a new block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics which attempt to provide full coverage of all those parameters of concern to a specific application. Applications may then "mix and match" to create a set of blocks which covers their set of concerns. Where possible, a specific block should be designed to be re-usable across more than one application, for example, for all of voice, streaming audio and video. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-11.txt From tom.van_caenegem@alcatel-lucent.com Fri Mar 2 04:55:28 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B9E21F8B2E for ; Fri, 2 Mar 2012 04:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.726 X-Spam-Level: X-Spam-Status: No, score=-9.726 tagged_above=-999 required=5 tests=[AWL=0.523, 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 L6XVQOTkQzlr for ; Fri, 2 Mar 2012 04:55:27 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id B7EC321F8B1D for ; Fri, 2 Mar 2012 04:55:21 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q22Ct16b009003 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 Mar 2012 13:55:01 +0100 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 2 Mar 2012 13:54:02 +0100 From: "Van Caenegem, Tom (Tom)" To: Qin Wu , Robert Sparks , "avt@ietf.org" , "avtcore-chairs@tools.ietf.org" , "draft-ietf-avtcore-feedback-suppression-rtp@tools.ietf.org" , Gonzalo Camarillo Date: Fri, 2 Mar 2012 13:54:00 +0100 Thread-Topic: [AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-rtp-13 Thread-Index: Acz4MGQ/T0rMqLzzT/mMDsrbarDmQAAQoeyg Message-ID: References: <4F4FF7C1.6040501@nostrum.com> <93213B506E254BE7941B02E9630EAB00@china.huawei.com> In-Reply-To: <93213B506E254BE7941B02E9630EAB00@china.huawei.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US 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.13 Subject: Re: [AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-rtp-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 12:55:28 -0000 Hi Qin, "I agree with your suggestion to the security section, that is to say the s= uppression rule is only=20 applied when the packet are integrity protected and authenticated. I can pu= t some text to make this clear." I think you will have to explain/rationalise why receivers MUST suppress f= eedback when receiving (unauthenticated) NACK packets (RFC 4585), whereas f= or 3rd party loss messages, feedback suppression is only required when the = sender can be authenticated. Tom =20 -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Qin W= u Sent: vrijdag 2 maart 2012 5:53 To: Robert Sparks; avt@ietf.org; avtcore-chairs@tools.ietf.org; draft-ietf-= avtcore-feedback-suppression-rtp@tools.ietf.org; Gonzalo Camarillo Subject: Re: [AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-r= tp-13 Hi, Robert: Thank for your valuable review, please see my replies inline below. Regards! -Qin ----- Original Message ----- From: "Robert Sparks" To: ; ; ; "Gonzalo Camarillo" Sent: Friday, March 02, 2012 6:27 AM Subject: [AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-rtp-1= 3 > Summary: There are some clarifications needed (and some questions to=20 > discuss) before forwarding this to IETF LC. >=20 > 1) Section 3, paragraph 3, says a receiver MUST follow the rules for=20 > NACK suppression on receipt of a third partly loss report. Section 4=20 > says receivers MAY ignore third party lost reports, and then confusingly= =20 > says the SHOULD not ignore them. The security considerations section=20 > says that receivers would be "well advised to ignore" (effectively=20 > SHOULD ignore) third party reports unless they are authenticated. This=20 > needs to be reconciled. >=20 > Are you trying to say the following? >=20 > *) MUST follow the suppression rules if packets are authenticated > *) SHOULD NOT follow the suppression rules if the packets are not=20 > authenticated >=20 > Or something else? Either way, please make the document internally=20 > consistent. [Qin]: The reason to use "MUST" is it was suggested by the reviewer since R= FC4585 that uses "MUST"=20 in the context of client feedback suppression. But I agree this description= does not clarify in what=20 circumstance to apply MUST. To be consistent with what we described in the = security section,=20 I agree with your suggestion to the security section, that is to say the su= ppression rule is only=20 applied when the packet are integrity protected and authenticated. I can pu= t some text to make this clear. >=20 > 2) Why aren't RFC3711 and RFC5124 normative references? They're the only= =20 > offered tools for authenticating these messages in the document. Even if= =20 > other mechanisms might exist, there needs to be discussion somewhere of=20 > what's required of this authentication, and the security consideration=20 > sections of those documents would suffice. [Qin] Agree, for discussion on where the authentication is required,=20 I like to follow your suggestion, please see above clarification. Also I will move RFC3711 and RFC5124 to normative references. Does this address your comment? >=20 > 3) The first part of the IANA considerations section is not clear. Is=20 > this trying to create a new registry with two initial values, or add two= =20 > values to an existing registry. If it's creating a new one, please=20 > provide a registry name, and suggest where it should appear. [Qin]: I think it is latter. To make it clear, I propose the following chan= ge: OLD Text: " For use with "nack" [RFC4585], a joint sub-registry has been set up that registers the following two values: The value registration for the attribute value "nack": " New Text: " For use with "nack" [RFC4585], this document instructs IANA to add two valu= es in "ack" and "nack" Attribute Values registry: The value registration for the attribute value "nack": " > 4) The security considerations section speaks about attacks based on=20 > spurious reports, but doesn't really discuss more directed attacks. In=20 > particular, if a receiver accepts unauthenticated feedback suppression=20 > messages, an attacker could cause packetloss disrupting an important=20 > part of a session, preemptively sending feedback suppression. An=20 > attacker that is also a receiver has enough information to suppress=20 > _all_ feedback from any other listeners that don't unauthenticated=20 > packets. Please make it clearer that these risks exist. [Qin]: Okay. Based on your above suggestion, I like to propose the followin= g change to the section 7,3rd paragraph: OLD text: " Sending the spurious Third Party Loss Report (e.g., the Third Party Loss Report with the wrong sequence number of lost packet) that causes missing RTP packets to not be repaired in a timely fashion. " New Text: " Sending the spurious Third Party Loss Report packet (e.g., the Third Party Loss Report with the wrong sequence number of lost packet) that causes missing RTP packets to not be repaired in a timely fashion.=20 If a receiver accepts such unauthenticated packet,=20 an attacker could cause packet loss disrupting an important=20 part of a session, preemptively sending feedback suppression. An=20 attacker that is also a receiver has enough information to suppress=20 all the feedbacks from any other listeners that don't accept unauthenticate= d=20 packets. " Does this address your comment? > 5) At the end of section 3, the document says messages SHOULD be=20 > suppressed "for a period of time". Can that be made more precise? [Qin]: Sorry, I forgot to clear that nits in the previous version. Since we= follow the feedback suppression rule we defined in RFC4585, I think the receivers= =20 should suppress the further feedback for the same packet loss. Therefore I = like to remove "for a period of time". > Editorial suggestions: >=20 > Please expand acronyms on first use (There are a _lot_ of acronyms, many= =20 > of which need references to where they are defined. Consider adding a=20 > glossary so you can get that out of the way without interrupting the=20 > flow of the text). [Qin]: Okay. > The protocol definition part of this document (section 4) is a bit of a=20 > puzzle for a new reader. It would help to guide the reader through the=20 > definition more directly. Here's a suggested modification - feel free to= =20 > ignore it: >=20 > Before section 4.1 say "The following two sections each define a third=20 > party loss report message. Both messages are feedback messages as=20 > defined in section 6.1 of RFC4585, and use the header format defined=20 > there. Each section defines how to populate the PT, FMT, length, SSRC or= =20 > packet sender, SSRC of media source, and FCI fields in that header." >=20 > That will make it more obvious to the reader that they need to go look=20 > at the referenced section in 4585 right away, and makes it possible to=20 > simplify the text in 4.1 and 4.2. 4.1 can state clearly and early that=20 > it is defining the TLLEI, etc. [Qin]: Looks good to me. > Whether you choose to act on this suggestion or not, please change the=20 > TBDs to TBD1 and TBD2, and say "length field in the" instead of "length=20 > of" when talking about setting the length field in each message. [Qin]: Okay. > Nits sent directly to editors. [Qin]: Thanks. >=20 >=20 >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From bill.wu@huawei.com Fri Mar 2 05:43:11 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A9621F87A8 for ; Fri, 2 Mar 2012 05:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.708 X-Spam-Level: X-Spam-Status: No, score=-0.708 tagged_above=-999 required=5 tests=[AWL=-3.757, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_53=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgtyyznGcXnA for ; Fri, 2 Mar 2012 05:43:11 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 584DE21F879F for ; Fri, 2 Mar 2012 05:43:10 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0900KMYFFT8V@szxga05-in.huawei.com> for avt@ietf.org; Fri, 02 Mar 2012 21:43:05 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M09002RHFFTVE@szxga05-in.huawei.com> for avt@ietf.org; Fri, 02 Mar 2012 21:43:05 +0800 (CST) Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHO17714; Fri, 02 Mar 2012 21:41:22 +0800 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 02 Mar 2012 21:40:46 +0800 Received: from SZXEML523-MBX.china.huawei.com ([169.254.3.103]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Fri, 02 Mar 2012 21:41:17 +0800 Date: Fri, 02 Mar 2012 13:41:17 +0000 From: Qin Wu In-reply-to: X-Originating-IP: [172.24.1.67] To: "Van Caenegem, Tom (Tom)" , Robert Sparks , "avt@ietf.org" , "avtcore-chairs@tools.ietf.org" , "draft-ietf-avtcore-feedback-suppression-rtp@tools.ietf.org" , Gonzalo Camarillo Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-rtp-13 Thread-index: AQHM+DFvbkSO17iyBkqHk8KRhJpUNZZWcJQAgACPMyY= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4F4FF7C1.6040501@nostrum.com> <93213B506E254BE7941B02E9630EAB00@china.huawei.com> Subject: [AVTCORE] =?gb2312?b?tPC4tDogIEFEIHJldmlldzoJZHJhZnQtaWV0Zi1hdnRj?= =?gb2312?b?b3JlLWZlZWRiYWNrLXN1cHByZXNzaW9uLXJ0cC0xMw==?= X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 13:43:11 -0000 SGksIFRvbToNCkkgdGhpbmsgVFBMUiBzaG91bGQgYmUgZGVhbHQgaW4gdGhlIHNhbWUgd2F5IGFz IE5BQ0sgcHJvY2Vzc2luZyBhdCB0aGUgcmVjZWl2ZXIuDQpBbmQgSSBjaGVjayB0aGUgc2VjdGlv biAzLjUuMiBvZiBSRkM0NTg1IGZvciB0aGUgZmVlZGJhY2sgc3VwcHJlc3Npb24gcnVsZS5Zb3Ug YXJlDQpyaWdodCx0aGUgcmVjaWV2ZXIgc2hvdWxkIHN1cHByZXNzIGFueSBmZWVkYmFjayBoZSB1 bmRlcnN0YW5kLCBubyBtYXR0ZXIgd2hldGhlciB0aGlzIEZlZWRiYWNrDQppcyBhdXRoZW50aWNh dGVkIG9yIG5vdC4NCk1heWJlIEkgYW0gd3JvbmcgdG8gcHV0IGFkZGl0aW9uYWwgcmVzdHJpY3Rp b24gdG8gdGhhdCBNVVNUIHN0YXRlbWVudC4gDQpIb3cgYWJvdXQganVzdCByZW1vdmUgc3VjaCBy ZXN0cmljdGlvbiwgaS5lLiwid2hlbiB0aGUgcGFja2V0IGFyZSBpbnRlZ3JpdHkgcHJvdGVjdGVk IGFuZCBhdXRoZW50aWNhdGVkIi4NCkkgdGhpbmsgcHV0dGluZyBhIGZldyBkaXNjdXNzaW9uIG9u IHdoYXQncyByZXF1aXJlZCBvZiBzdWNoIGF1dGhlbnRpY2F0aW9uIGluIHRoZSBzZWN1cml0eSBz ZWN0aW9uIHdpbGwgDQpiZSBlbm91Z2guDQoNClRvbSwgZG9lcyB0aGlzIGFkZHJlc3MgeW91ciBj b21tZW50Pw0KDQpSZWdhcmRzIQ0KLVFpbg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0Kt6K8/sjLOiBWYW4gQ2FlbmVnZW0sIFRvbSAoVG9tKSBbdG9tLnZhbl9jYWVu ZWdlbUBhbGNhdGVsLWx1Y2VudC5jb21dDQq3osvNyrG85DogMjAxMsTqM9TCMsjVIDIwOjU0DQq1 vTogUWluIFd1OyBSb2JlcnQgU3BhcmtzOyBhdnRAaWV0Zi5vcmc7IGF2dGNvcmUtY2hhaXJzQHRv b2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLWF2dGNvcmUtZmVlZGJhY2stc3VwcHJlc3Npb24tcnRw QHRvb2xzLmlldGYub3JnOyBHb256YWxvIENhbWFyaWxsbw0K1vfM4jogUkU6IFtBVlRDT1JFXSBB RCByZXZpZXc6ICAgIGRyYWZ0LWlldGYtYXZ0Y29yZS1mZWVkYmFjay1zdXBwcmVzc2lvbi1ydHAt MTMNCg0KSGkgUWluLA0KDQoiSSBhZ3JlZSB3aXRoIHlvdXIgc3VnZ2VzdGlvbiB0byB0aGUgc2Vj dXJpdHkgc2VjdGlvbiwgdGhhdCBpcyB0byBzYXkgdGhlIHN1cHByZXNzaW9uIHJ1bGUgaXMgb25s eQ0KYXBwbGllZCB3aGVuIHRoZSBwYWNrZXQgYXJlIGludGVncml0eSBwcm90ZWN0ZWQgYW5kIGF1 dGhlbnRpY2F0ZWQuIEkgY2FuIHB1dCBzb21lIHRleHQgdG8gbWFrZSB0aGlzIGNsZWFyLiINCg0K SSB0aGluayB5b3Ugd2lsbCBoYXZlIHRvIGV4cGxhaW4vcmF0aW9uYWxpc2Ugd2h5IHJlY2VpdmVy cyBNVVNUICBzdXBwcmVzcyBmZWVkYmFjayB3aGVuIHJlY2VpdmluZyAodW5hdXRoZW50aWNhdGVk KSBOQUNLIHBhY2tldHMgKFJGQyA0NTg1KSwgd2hlcmVhcyBmb3IgM3JkIHBhcnR5IGxvc3MgbWVz c2FnZXMsIGZlZWRiYWNrIHN1cHByZXNzaW9uIGlzIG9ubHkgcmVxdWlyZWQgd2hlbiB0aGUgc2Vu ZGVyIGNhbiBiZSBhdXRoZW50aWNhdGVkLg0KVG9tDQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IGF2dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXZ0LWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBRaW4gV3UNClNlbnQ6IHZyaWpkYWcgMiBtYWFydCAy MDEyIDU6NTMNClRvOiBSb2JlcnQgU3BhcmtzOyBhdnRAaWV0Zi5vcmc7IGF2dGNvcmUtY2hhaXJz QHRvb2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLWF2dGNvcmUtZmVlZGJhY2stc3VwcHJlc3Npb24t cnRwQHRvb2xzLmlldGYub3JnOyBHb256YWxvIENhbWFyaWxsbw0KU3ViamVjdDogUmU6IFtBVlRD T1JFXSBBRCByZXZpZXc6IGRyYWZ0LWlldGYtYXZ0Y29yZS1mZWVkYmFjay1zdXBwcmVzc2lvbi1y dHAtMTMNCg0KSGksIFJvYmVydDoNClRoYW5rIGZvciB5b3VyIHZhbHVhYmxlIHJldmlldywgcGxl YXNlIHNlZSBteSByZXBsaWVzIGlubGluZSBiZWxvdy4NCg0KUmVnYXJkcyENCi1RaW4NCi0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206ICJSb2JlcnQgU3BhcmtzIiA8cmpzcGFya3NA bm9zdHJ1bS5jb20+DQpUbzogPGF2dEBpZXRmLm9yZz47IDxhdnRjb3JlLWNoYWlyc0B0b29scy5p ZXRmLm9yZz47IDxkcmFmdC1pZXRmLWF2dGNvcmUtZmVlZGJhY2stc3VwcHJlc3Npb24tcnRwQHRv b2xzLmlldGYub3JnPjsgIkdvbnphbG8gQ2FtYXJpbGxvIiA8R29uemFsby5DYW1hcmlsbG9AZXJp Y3Nzb24uY29tPg0KU2VudDogRnJpZGF5LCBNYXJjaCAwMiwgMjAxMiA2OjI3IEFNDQpTdWJqZWN0 OiBbQVZUQ09SRV0gQUQgcmV2aWV3OiBkcmFmdC1pZXRmLWF2dGNvcmUtZmVlZGJhY2stc3VwcHJl c3Npb24tcnRwLTEzDQoNCg0KPiBTdW1tYXJ5OiBUaGVyZSBhcmUgc29tZSBjbGFyaWZpY2F0aW9u cyBuZWVkZWQgKGFuZCBzb21lIHF1ZXN0aW9ucyB0bw0KPiBkaXNjdXNzKSBiZWZvcmUgZm9yd2Fy ZGluZyB0aGlzIHRvIElFVEYgTEMuDQo+DQo+IDEpIFNlY3Rpb24gMywgcGFyYWdyYXBoIDMsIHNh eXMgYSByZWNlaXZlciBNVVNUIGZvbGxvdyB0aGUgcnVsZXMgZm9yDQo+IE5BQ0sgc3VwcHJlc3Np b24gb24gcmVjZWlwdCBvZiBhIHRoaXJkIHBhcnRseSBsb3NzIHJlcG9ydC4gU2VjdGlvbiA0DQo+ IHNheXMgcmVjZWl2ZXJzIE1BWSBpZ25vcmUgdGhpcmQgcGFydHkgbG9zdCByZXBvcnRzLCBhbmQg dGhlbiBjb25mdXNpbmdseQ0KPiBzYXlzIHRoZSBTSE9VTEQgbm90IGlnbm9yZSB0aGVtLiBUaGUg c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbg0KPiBzYXlzIHRoYXQgcmVjZWl2ZXJzIHdv dWxkIGJlICJ3ZWxsIGFkdmlzZWQgdG8gaWdub3JlIiAoZWZmZWN0aXZlbHkNCj4gU0hPVUxEIGln bm9yZSkgdGhpcmQgcGFydHkgcmVwb3J0cyB1bmxlc3MgdGhleSBhcmUgYXV0aGVudGljYXRlZC4g VGhpcw0KPiBuZWVkcyB0byBiZSByZWNvbmNpbGVkLg0KPg0KPiBBcmUgeW91IHRyeWluZyB0byBz YXkgdGhlIGZvbGxvd2luZz8NCj4NCj4gICAgKikgTVVTVCBmb2xsb3cgdGhlIHN1cHByZXNzaW9u IHJ1bGVzIGlmIHBhY2tldHMgYXJlIGF1dGhlbnRpY2F0ZWQNCj4gICAgKikgU0hPVUxEIE5PVCBm b2xsb3cgdGhlIHN1cHByZXNzaW9uIHJ1bGVzIGlmIHRoZSBwYWNrZXRzIGFyZSBub3QNCj4gYXV0 aGVudGljYXRlZA0KPg0KPiBPciBzb21ldGhpbmcgZWxzZT8gRWl0aGVyIHdheSwgcGxlYXNlIG1h a2UgdGhlIGRvY3VtZW50IGludGVybmFsbHkNCj4gY29uc2lzdGVudC4NCg0KW1Fpbl06IFRoZSBy ZWFzb24gdG8gdXNlICJNVVNUIiBpcyBpdCB3YXMgc3VnZ2VzdGVkIGJ5IHRoZSByZXZpZXdlciBz aW5jZSBSRkM0NTg1IHRoYXQgdXNlcyAiTVVTVCINCmluIHRoZSBjb250ZXh0IG9mIGNsaWVudCBm ZWVkYmFjayBzdXBwcmVzc2lvbi4gQnV0IEkgYWdyZWUgdGhpcyBkZXNjcmlwdGlvbiBkb2VzIG5v dCBjbGFyaWZ5IGluIHdoYXQNCmNpcmN1bXN0YW5jZSB0byBhcHBseSBNVVNULiBUbyBiZSBjb25z aXN0ZW50IHdpdGggd2hhdCB3ZSBkZXNjcmliZWQgaW4gdGhlIHNlY3VyaXR5IHNlY3Rpb24sDQpJ IGFncmVlIHdpdGggeW91ciBzdWdnZXN0aW9uIHRvIHRoZSBzZWN1cml0eSBzZWN0aW9uLCB0aGF0 IGlzIHRvIHNheSB0aGUgc3VwcHJlc3Npb24gcnVsZSBpcyBvbmx5DQphcHBsaWVkIHdoZW4gdGhl IHBhY2tldCBhcmUgaW50ZWdyaXR5IHByb3RlY3RlZCBhbmQgYXV0aGVudGljYXRlZC4gSSBjYW4g cHV0IHNvbWUgdGV4dCB0byBtYWtlIHRoaXMgY2xlYXIuDQoNCj4NCj4gMikgV2h5IGFyZW4ndCBS RkMzNzExIGFuZCBSRkM1MTI0IG5vcm1hdGl2ZSByZWZlcmVuY2VzPyBUaGV5J3JlIHRoZSBvbmx5 DQo+IG9mZmVyZWQgdG9vbHMgZm9yIGF1dGhlbnRpY2F0aW5nIHRoZXNlIG1lc3NhZ2VzIGluIHRo ZSBkb2N1bWVudC4gRXZlbiBpZg0KPiBvdGhlciBtZWNoYW5pc21zIG1pZ2h0IGV4aXN0LCB0aGVy ZSBuZWVkcyB0byBiZSBkaXNjdXNzaW9uIHNvbWV3aGVyZSBvZg0KPiB3aGF0J3MgcmVxdWlyZWQg b2YgdGhpcyBhdXRoZW50aWNhdGlvbiwgYW5kIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uDQo+ IHNlY3Rpb25zIG9mIHRob3NlIGRvY3VtZW50cyB3b3VsZCBzdWZmaWNlLg0KDQpbUWluXSBBZ3Jl ZSwgZm9yIGRpc2N1c3Npb24gb24gd2hlcmUgdGhlIGF1dGhlbnRpY2F0aW9uIGlzIHJlcXVpcmVk LA0KDQpJIGxpa2UgdG8gZm9sbG93IHlvdXIgc3VnZ2VzdGlvbiwgcGxlYXNlIHNlZSBhYm92ZSBj bGFyaWZpY2F0aW9uLiBBbHNvDQoNCiBJIHdpbGwgbW92ZSBSRkMzNzExIGFuZCBSRkM1MTI0IHRv IG5vcm1hdGl2ZSByZWZlcmVuY2VzLg0KDQpEb2VzIHRoaXMgYWRkcmVzcyB5b3VyIGNvbW1lbnQ/ DQoNCj4NCj4gMykgVGhlIGZpcnN0IHBhcnQgb2YgdGhlIElBTkEgY29uc2lkZXJhdGlvbnMgc2Vj dGlvbiBpcyBub3QgY2xlYXIuIElzDQo+IHRoaXMgdHJ5aW5nIHRvIGNyZWF0ZSBhIG5ldyByZWdp c3RyeSB3aXRoIHR3byBpbml0aWFsIHZhbHVlcywgb3IgYWRkIHR3bw0KPiB2YWx1ZXMgdG8gYW4g ZXhpc3RpbmcgcmVnaXN0cnkuIElmIGl0J3MgY3JlYXRpbmcgYSBuZXcgb25lLCBwbGVhc2UNCj4g cHJvdmlkZSBhIHJlZ2lzdHJ5IG5hbWUsIGFuZCBzdWdnZXN0IHdoZXJlIGl0IHNob3VsZCBhcHBl YXIuDQoNCg0KDQpbUWluXTogSSB0aGluayBpdCBpcyBsYXR0ZXIuIFRvIG1ha2UgaXQgY2xlYXIs IEkgcHJvcG9zZSB0aGUgZm9sbG93aW5nIGNoYW5nZToNCg0KT0xEIFRleHQ6DQoNCiINCg0KICAg Rm9yIHVzZSB3aXRoICJuYWNrIiBbUkZDNDU4NV0sIGEgam9pbnQgc3ViLXJlZ2lzdHJ5IGhhcyBi ZWVuIHNldCB1cA0KDQogICB0aGF0IHJlZ2lzdGVycyB0aGUgZm9sbG93aW5nIHR3byB2YWx1ZXM6 DQoNCiAgVGhlIHZhbHVlIHJlZ2lzdHJhdGlvbiBmb3IgdGhlIGF0dHJpYnV0ZSB2YWx1ZSAibmFj ayI6DQoNCiINCk5ldyBUZXh0Og0KDQoiDQoNCkZvciB1c2Ugd2l0aCAibmFjayIgW1JGQzQ1ODVd LCB0aGlzIGRvY3VtZW50IGluc3RydWN0cyBJQU5BIHRvIGFkZCB0d28gdmFsdWVzIGluDQoNCiJh Y2siIGFuZCAibmFjayIgQXR0cmlidXRlIFZhbHVlcyByZWdpc3RyeToNCg0KVGhlIHZhbHVlIHJl Z2lzdHJhdGlvbiBmb3IgdGhlIGF0dHJpYnV0ZSB2YWx1ZSAibmFjayI6DQoNCiINCg0KDQoNCj4g NCkgVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gc3BlYWtzIGFib3V0IGF0dGFj a3MgYmFzZWQgb24NCj4gc3B1cmlvdXMgcmVwb3J0cywgYnV0IGRvZXNuJ3QgcmVhbGx5IGRpc2N1 c3MgbW9yZSBkaXJlY3RlZCBhdHRhY2tzLiBJbg0KPiBwYXJ0aWN1bGFyLCBpZiBhIHJlY2VpdmVy IGFjY2VwdHMgdW5hdXRoZW50aWNhdGVkIGZlZWRiYWNrIHN1cHByZXNzaW9uDQo+IG1lc3NhZ2Vz LCBhbiBhdHRhY2tlciBjb3VsZCBjYXVzZSBwYWNrZXRsb3NzIGRpc3J1cHRpbmcgYW4gaW1wb3J0 YW50DQo+IHBhcnQgb2YgYSBzZXNzaW9uLCBwcmVlbXB0aXZlbHkgc2VuZGluZyBmZWVkYmFjayBz dXBwcmVzc2lvbi4gQW4NCj4gYXR0YWNrZXIgdGhhdCBpcyBhbHNvIGEgcmVjZWl2ZXIgaGFzIGVu b3VnaCBpbmZvcm1hdGlvbiB0byBzdXBwcmVzcw0KPiBfYWxsXyBmZWVkYmFjayBmcm9tIGFueSBv dGhlciBsaXN0ZW5lcnMgdGhhdCBkb24ndCB1bmF1dGhlbnRpY2F0ZWQNCj4gcGFja2V0cy4gUGxl YXNlIG1ha2UgaXQgY2xlYXJlciB0aGF0IHRoZXNlIHJpc2tzIGV4aXN0Lg0KDQpbUWluXTogT2th eS4gQmFzZWQgb24geW91ciBhYm92ZSBzdWdnZXN0aW9uLCBJIGxpa2UgdG8gcHJvcG9zZSB0aGUg Zm9sbG93aW5nIGNoYW5nZSB0byB0aGUgc2VjdGlvbiA3LDNyZCBwYXJhZ3JhcGg6DQoNCk9MRCB0 ZXh0Og0KDQoiDQoNClNlbmRpbmcgdGhlIHNwdXJpb3VzIFRoaXJkIFBhcnR5IExvc3MgUmVwb3J0 IChlLmcuLCB0aGUgVGhpcmQgUGFydHkNCg0KICAgTG9zcyBSZXBvcnQgd2l0aCB0aGUgd3Jvbmcg c2VxdWVuY2UgbnVtYmVyIG9mIGxvc3QgcGFja2V0KSB0aGF0DQoNCiAgIGNhdXNlcyBtaXNzaW5n IFJUUCBwYWNrZXRzIHRvIG5vdCBiZSByZXBhaXJlZCBpbiBhIHRpbWVseSBmYXNoaW9uLg0KDQoi DQoNCk5ldyBUZXh0Og0KDQoiDQoNClNlbmRpbmcgdGhlIHNwdXJpb3VzIFRoaXJkIFBhcnR5IExv c3MgUmVwb3J0IHBhY2tldCAoZS5nLiwgdGhlIFRoaXJkIFBhcnR5DQoNCiAgIExvc3MgUmVwb3J0 IHdpdGggdGhlIHdyb25nIHNlcXVlbmNlIG51bWJlciBvZiBsb3N0IHBhY2tldCkgdGhhdA0KDQog ICBjYXVzZXMgbWlzc2luZyBSVFAgcGFja2V0cyB0byBub3QgYmUgcmVwYWlyZWQgaW4gYSB0aW1l bHkgZmFzaGlvbi4NCg0KSWYgYSByZWNlaXZlciBhY2NlcHRzIHN1Y2ggdW5hdXRoZW50aWNhdGVk IHBhY2tldCwNCg0KYW4gYXR0YWNrZXIgY291bGQgY2F1c2UgcGFja2V0IGxvc3MgZGlzcnVwdGlu ZyBhbiBpbXBvcnRhbnQNCnBhcnQgb2YgYSBzZXNzaW9uLCBwcmVlbXB0aXZlbHkgc2VuZGluZyBm ZWVkYmFjayBzdXBwcmVzc2lvbi4gQW4NCmF0dGFja2VyIHRoYXQgaXMgYWxzbyBhIHJlY2VpdmVy IGhhcyBlbm91Z2ggaW5mb3JtYXRpb24gdG8gc3VwcHJlc3MNCmFsbCB0aGUgZmVlZGJhY2tzIGZy b20gYW55IG90aGVyIGxpc3RlbmVycyB0aGF0IGRvbid0IGFjY2VwdCB1bmF1dGhlbnRpY2F0ZWQN CnBhY2tldHMuDQoNCiINCg0KRG9lcyB0aGlzIGFkZHJlc3MgeW91ciBjb21tZW50Pw0KDQoNCj4g NSkgQXQgdGhlIGVuZCBvZiBzZWN0aW9uIDMsIHRoZSBkb2N1bWVudCBzYXlzIG1lc3NhZ2VzIFNI T1VMRCBiZQ0KPiBzdXBwcmVzc2VkICJmb3IgYSBwZXJpb2Qgb2YgdGltZSIuIENhbiB0aGF0IGJl IG1hZGUgbW9yZSBwcmVjaXNlPw0KDQpbUWluXTogU29ycnksIEkgZm9yZ290IHRvIGNsZWFyIHRo YXQgbml0cyBpbiB0aGUgcHJldmlvdXMgdmVyc2lvbi4gU2luY2Ugd2UgZm9sbG93DQoNCiB0aGUg ZmVlZGJhY2sgc3VwcHJlc3Npb24gcnVsZSB3ZSBkZWZpbmVkIGluIFJGQzQ1ODUsIEkgdGhpbmsg dGhlIHJlY2VpdmVycw0KDQpzaG91bGQgc3VwcHJlc3MgdGhlIGZ1cnRoZXIgZmVlZGJhY2sgZm9y IHRoZSBzYW1lIHBhY2tldCBsb3NzLiBUaGVyZWZvcmUgSSBsaWtlDQoNCiB0byByZW1vdmUgImZv ciBhIHBlcmlvZCBvZiB0aW1lIi4NCg0KDQo+IEVkaXRvcmlhbCBzdWdnZXN0aW9uczoNCj4NCj4g UGxlYXNlIGV4cGFuZCBhY3JvbnltcyBvbiBmaXJzdCB1c2UgKFRoZXJlIGFyZSBhIF9sb3RfIG9m IGFjcm9ueW1zLCBtYW55DQo+IG9mIHdoaWNoIG5lZWQgcmVmZXJlbmNlcyB0byB3aGVyZSB0aGV5 IGFyZSBkZWZpbmVkLiBDb25zaWRlciBhZGRpbmcgYQ0KPiBnbG9zc2FyeSBzbyB5b3UgY2FuIGdl dCB0aGF0IG91dCBvZiB0aGUgd2F5IHdpdGhvdXQgaW50ZXJydXB0aW5nIHRoZQ0KPiBmbG93IG9m IHRoZSB0ZXh0KS4NCg0KW1Fpbl06IE9rYXkuDQoNCj4gVGhlIHByb3RvY29sIGRlZmluaXRpb24g cGFydCBvZiB0aGlzIGRvY3VtZW50IChzZWN0aW9uIDQpIGlzIGEgYml0IG9mIGENCj4gcHV6emxl IGZvciBhIG5ldyByZWFkZXIuIEl0IHdvdWxkIGhlbHAgdG8gZ3VpZGUgdGhlIHJlYWRlciB0aHJv dWdoIHRoZQ0KPiBkZWZpbml0aW9uIG1vcmUgZGlyZWN0bHkuIEhlcmUncyBhIHN1Z2dlc3RlZCBt b2RpZmljYXRpb24gLSBmZWVsIGZyZWUgdG8NCj4gaWdub3JlIGl0Og0KPg0KPiBCZWZvcmUgc2Vj dGlvbiA0LjEgc2F5ICJUaGUgZm9sbG93aW5nIHR3byBzZWN0aW9ucyBlYWNoIGRlZmluZSBhIHRo aXJkDQo+IHBhcnR5IGxvc3MgcmVwb3J0IG1lc3NhZ2UuIEJvdGggbWVzc2FnZXMgYXJlIGZlZWRi YWNrIG1lc3NhZ2VzIGFzDQo+IGRlZmluZWQgaW4gc2VjdGlvbiA2LjEgb2YgUkZDNDU4NSwgYW5k IHVzZSB0aGUgaGVhZGVyIGZvcm1hdCBkZWZpbmVkDQo+IHRoZXJlLiBFYWNoIHNlY3Rpb24gZGVm aW5lcyBob3cgdG8gcG9wdWxhdGUgdGhlIFBULCBGTVQsIGxlbmd0aCwgU1NSQyBvcg0KPiBwYWNr ZXQgc2VuZGVyLCBTU1JDIG9mIG1lZGlhIHNvdXJjZSwgYW5kIEZDSSBmaWVsZHMgaW4gdGhhdCBo ZWFkZXIuIg0KPg0KPiBUaGF0IHdpbGwgbWFrZSBpdCBtb3JlIG9idmlvdXMgdG8gdGhlIHJlYWRl ciB0aGF0IHRoZXkgbmVlZCB0byBnbyBsb29rDQo+IGF0IHRoZSByZWZlcmVuY2VkIHNlY3Rpb24g aW4gNDU4NSByaWdodCBhd2F5LCBhbmQgbWFrZXMgaXQgcG9zc2libGUgdG8NCj4gc2ltcGxpZnkg dGhlIHRleHQgaW4gNC4xIGFuZCA0LjIuIDQuMSBjYW4gc3RhdGUgY2xlYXJseSBhbmQgZWFybHkg dGhhdA0KPiBpdCBpcyBkZWZpbmluZyB0aGUgVExMRUksIGV0Yy4NCg0KW1Fpbl06IExvb2tzIGdv b2QgdG8gbWUuDQoNCg0KPiBXaGV0aGVyIHlvdSBjaG9vc2UgdG8gYWN0IG9uIHRoaXMgc3VnZ2Vz dGlvbiBvciBub3QsIHBsZWFzZSBjaGFuZ2UgdGhlDQo+IFRCRHMgdG8gVEJEMSBhbmQgVEJEMiwg YW5kIHNheSAibGVuZ3RoIGZpZWxkIGluIHRoZSIgaW5zdGVhZCBvZiAibGVuZ3RoDQo+IG9mIiB3 aGVuIHRhbGtpbmcgYWJvdXQgc2V0dGluZyB0aGUgbGVuZ3RoIGZpZWxkIGluIGVhY2ggbWVzc2Fn ZS4NCg0KW1Fpbl06IE9rYXkuDQoNCg0KPiBOaXRzIHNlbnQgZGlyZWN0bHkgdG8gZWRpdG9ycy4N Cg0KIFtRaW5dOiBUaGFua3MuDQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50 ZW5hbmNlDQo+IGF2dEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2F2dA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQphdnRAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQo= From tom.van_caenegem@alcatel-lucent.com Fri Mar 2 05:48:13 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BB021F87F9 for ; Fri, 2 Mar 2012 05:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.499 X-Spam-Level: X-Spam-Status: No, score=-7.499 tagged_above=-999 required=5 tests=[AWL=-2.053, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_53=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 35w8aB9sFaF8 for ; Fri, 2 Mar 2012 05:48:12 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2B121F87F8 for ; Fri, 2 Mar 2012 05:48:12 -0800 (PST) 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 q22Din12020913 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 Mar 2012 14:47:22 +0100 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 2 Mar 2012 14:46:54 +0100 From: "Van Caenegem, Tom (Tom)" To: Qin Wu , Robert Sparks , "avt@ietf.org" , "avtcore-chairs@tools.ietf.org" , "draft-ietf-avtcore-feedback-suppression-rtp@tools.ietf.org" , Gonzalo Camarillo Date: Fri, 2 Mar 2012 14:46:52 +0100 Thread-Topic: [AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-rtp-13 Thread-Index: AQHM+DFvbkSO17iyBkqHk8KRhJpUNZZWcJQAgACPMyaAAAUb0A== Message-ID: References: <4F4FF7C1.6040501@nostrum.com> <93213B506E254BE7941B02E9630EAB00@china.huawei.com> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-rtp-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 13:48:13 -0000 SSBjYW5ub3QgdGhpbmsgb2YgYSByZWFzb24gdG8gZGlmZmVyZW50aWF0ZSB0aGUgcmVjZWl2ZXIg RkIgc3VwcHJlc3Npb24gYmVoYXZpb3VyICB3aGVuIHJlY2VpdmluZyBOQUNLcyB2ZXJzdXMgVFBM IG1lc3NhZ2VzLCBzbyB0aGlzIGFkZHJlc3NlcyBteSBjb21tZW50LiBUaHgNClRvbQ0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUWluIFd1IFttYWlsdG86YmlsbC53dUBodWF3 ZWkuY29tXSANClNlbnQ6IHZyaWpkYWcgMiBtYWFydCAyMDEyIDE0OjQxDQpUbzogVmFuIENhZW5l Z2VtLCBUb20gKFRvbSk7IFJvYmVydCBTcGFya3M7IGF2dEBpZXRmLm9yZzsgYXZ0Y29yZS1jaGFp cnNAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWlldGYtYXZ0Y29yZS1mZWVkYmFjay1zdXBwcmVzc2lv bi1ydHBAdG9vbHMuaWV0Zi5vcmc7IEdvbnphbG8gQ2FtYXJpbGxvDQpTdWJqZWN0OiC08Li0OiBb QVZUQ09SRV0gQUQgcmV2aWV3OiBkcmFmdC1pZXRmLWF2dGNvcmUtZmVlZGJhY2stc3VwcHJlc3Np b24tcnRwLTEzDQoNCkhpLCBUb206DQpJIHRoaW5rIFRQTFIgc2hvdWxkIGJlIGRlYWx0IGluIHRo ZSBzYW1lIHdheSBhcyBOQUNLIHByb2Nlc3NpbmcgYXQgdGhlIHJlY2VpdmVyLg0KQW5kIEkgY2hl Y2sgdGhlIHNlY3Rpb24gMy41LjIgb2YgUkZDNDU4NSBmb3IgdGhlIGZlZWRiYWNrIHN1cHByZXNz aW9uIHJ1bGUuWW91IGFyZSByaWdodCx0aGUgcmVjaWV2ZXIgc2hvdWxkIHN1cHByZXNzIGFueSBm ZWVkYmFjayBoZSB1bmRlcnN0YW5kLCBubyBtYXR0ZXIgd2hldGhlciB0aGlzIEZlZWRiYWNrIGlz IGF1dGhlbnRpY2F0ZWQgb3Igbm90Lg0KTWF5YmUgSSBhbSB3cm9uZyB0byBwdXQgYWRkaXRpb25h bCByZXN0cmljdGlvbiB0byB0aGF0IE1VU1Qgc3RhdGVtZW50LiANCkhvdyBhYm91dCBqdXN0IHJl bW92ZSBzdWNoIHJlc3RyaWN0aW9uLCBpLmUuLCJ3aGVuIHRoZSBwYWNrZXQgYXJlIGludGVncml0 eSBwcm90ZWN0ZWQgYW5kIGF1dGhlbnRpY2F0ZWQiLg0KSSB0aGluayBwdXR0aW5nIGEgZmV3IGRp c2N1c3Npb24gb24gd2hhdCdzIHJlcXVpcmVkIG9mIHN1Y2ggYXV0aGVudGljYXRpb24gaW4gdGhl IHNlY3VyaXR5IHNlY3Rpb24gd2lsbCBiZSBlbm91Z2guDQoNClRvbSwgZG9lcyB0aGlzIGFkZHJl c3MgeW91ciBjb21tZW50Pw0KDQpSZWdhcmRzIQ0KLVFpbg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBWYW4gQ2FlbmVnZW0sIFRvbSAoVG9tKSBbdG9t LnZhbl9jYWVuZWdlbUBhbGNhdGVsLWx1Y2VudC5jb21dDQq3osvNyrG85DogMjAxMsTqM9TCMsjV IDIwOjU0DQq1vTogUWluIFd1OyBSb2JlcnQgU3BhcmtzOyBhdnRAaWV0Zi5vcmc7IGF2dGNvcmUt Y2hhaXJzQHRvb2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLWF2dGNvcmUtZmVlZGJhY2stc3VwcHJl c3Npb24tcnRwQHRvb2xzLmlldGYub3JnOyBHb256YWxvIENhbWFyaWxsbw0K1vfM4jogUkU6IFtB VlRDT1JFXSBBRCByZXZpZXc6ICAgIGRyYWZ0LWlldGYtYXZ0Y29yZS1mZWVkYmFjay1zdXBwcmVz c2lvbi1ydHAtMTMNCg0KSGkgUWluLA0KDQoiSSBhZ3JlZSB3aXRoIHlvdXIgc3VnZ2VzdGlvbiB0 byB0aGUgc2VjdXJpdHkgc2VjdGlvbiwgdGhhdCBpcyB0byBzYXkgdGhlIHN1cHByZXNzaW9uIHJ1 bGUgaXMgb25seSBhcHBsaWVkIHdoZW4gdGhlIHBhY2tldCBhcmUgaW50ZWdyaXR5IHByb3RlY3Rl ZCBhbmQgYXV0aGVudGljYXRlZC4gSSBjYW4gcHV0IHNvbWUgdGV4dCB0byBtYWtlIHRoaXMgY2xl YXIuIg0KDQpJIHRoaW5rIHlvdSB3aWxsIGhhdmUgdG8gZXhwbGFpbi9yYXRpb25hbGlzZSB3aHkg cmVjZWl2ZXJzIE1VU1QgIHN1cHByZXNzIGZlZWRiYWNrIHdoZW4gcmVjZWl2aW5nICh1bmF1dGhl bnRpY2F0ZWQpIE5BQ0sgcGFja2V0cyAoUkZDIDQ1ODUpLCB3aGVyZWFzIGZvciAzcmQgcGFydHkg bG9zcyBtZXNzYWdlcywgZmVlZGJhY2sgc3VwcHJlc3Npb24gaXMgb25seSByZXF1aXJlZCB3aGVu IHRoZSBzZW5kZXIgY2FuIGJlIGF1dGhlbnRpY2F0ZWQuDQpUb20NCg0KDQoNCg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogYXZ0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzph dnQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFFpbiBXdQ0KU2VudDogdnJpamRhZyAy IG1hYXJ0IDIwMTIgNTo1Mw0KVG86IFJvYmVydCBTcGFya3M7IGF2dEBpZXRmLm9yZzsgYXZ0Y29y ZS1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWlldGYtYXZ0Y29yZS1mZWVkYmFjay1zdXBw cmVzc2lvbi1ydHBAdG9vbHMuaWV0Zi5vcmc7IEdvbnphbG8gQ2FtYXJpbGxvDQpTdWJqZWN0OiBS ZTogW0FWVENPUkVdIEFEIHJldmlldzogZHJhZnQtaWV0Zi1hdnRjb3JlLWZlZWRiYWNrLXN1cHBy ZXNzaW9uLXJ0cC0xMw0KDQpIaSwgUm9iZXJ0Og0KVGhhbmsgZm9yIHlvdXIgdmFsdWFibGUgcmV2 aWV3LCBwbGVhc2Ugc2VlIG15IHJlcGxpZXMgaW5saW5lIGJlbG93Lg0KDQpSZWdhcmRzIQ0KLVFp bg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIlJvYmVydCBTcGFya3MiIDxy anNwYXJrc0Bub3N0cnVtLmNvbT4NClRvOiA8YXZ0QGlldGYub3JnPjsgPGF2dGNvcmUtY2hhaXJz QHRvb2xzLmlldGYub3JnPjsgPGRyYWZ0LWlldGYtYXZ0Y29yZS1mZWVkYmFjay1zdXBwcmVzc2lv bi1ydHBAdG9vbHMuaWV0Zi5vcmc+OyAiR29uemFsbyBDYW1hcmlsbG8iIDxHb256YWxvLkNhbWFy aWxsb0Blcmljc3Nvbi5jb20+DQpTZW50OiBGcmlkYXksIE1hcmNoIDAyLCAyMDEyIDY6MjcgQU0N ClN1YmplY3Q6IFtBVlRDT1JFXSBBRCByZXZpZXc6IGRyYWZ0LWlldGYtYXZ0Y29yZS1mZWVkYmFj ay1zdXBwcmVzc2lvbi1ydHAtMTMNCg0KDQo+IFN1bW1hcnk6IFRoZXJlIGFyZSBzb21lIGNsYXJp ZmljYXRpb25zIG5lZWRlZCAoYW5kIHNvbWUgcXVlc3Rpb25zIHRvDQo+IGRpc2N1c3MpIGJlZm9y ZSBmb3J3YXJkaW5nIHRoaXMgdG8gSUVURiBMQy4NCj4NCj4gMSkgU2VjdGlvbiAzLCBwYXJhZ3Jh cGggMywgc2F5cyBhIHJlY2VpdmVyIE1VU1QgZm9sbG93IHRoZSBydWxlcyBmb3IgDQo+IE5BQ0sg c3VwcHJlc3Npb24gb24gcmVjZWlwdCBvZiBhIHRoaXJkIHBhcnRseSBsb3NzIHJlcG9ydC4gU2Vj dGlvbiA0IA0KPiBzYXlzIHJlY2VpdmVycyBNQVkgaWdub3JlIHRoaXJkIHBhcnR5IGxvc3QgcmVw b3J0cywgYW5kIHRoZW4gDQo+IGNvbmZ1c2luZ2x5IHNheXMgdGhlIFNIT1VMRCBub3QgaWdub3Jl IHRoZW0uIFRoZSBzZWN1cml0eSANCj4gY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBzYXlzIHRoYXQg cmVjZWl2ZXJzIHdvdWxkIGJlICJ3ZWxsIGFkdmlzZWQgdG8gDQo+IGlnbm9yZSIgKGVmZmVjdGl2 ZWx5IFNIT1VMRCBpZ25vcmUpIHRoaXJkIHBhcnR5IHJlcG9ydHMgdW5sZXNzIHRoZXkgDQo+IGFy ZSBhdXRoZW50aWNhdGVkLiBUaGlzIG5lZWRzIHRvIGJlIHJlY29uY2lsZWQuDQo+DQo+IEFyZSB5 b3UgdHJ5aW5nIHRvIHNheSB0aGUgZm9sbG93aW5nPw0KPg0KPiAgICAqKSBNVVNUIGZvbGxvdyB0 aGUgc3VwcHJlc3Npb24gcnVsZXMgaWYgcGFja2V0cyBhcmUgYXV0aGVudGljYXRlZA0KPiAgICAq KSBTSE9VTEQgTk9UIGZvbGxvdyB0aGUgc3VwcHJlc3Npb24gcnVsZXMgaWYgdGhlIHBhY2tldHMg YXJlIG5vdCANCj4gYXV0aGVudGljYXRlZA0KPg0KPiBPciBzb21ldGhpbmcgZWxzZT8gRWl0aGVy IHdheSwgcGxlYXNlIG1ha2UgdGhlIGRvY3VtZW50IGludGVybmFsbHkgDQo+IGNvbnNpc3RlbnQu DQoNCltRaW5dOiBUaGUgcmVhc29uIHRvIHVzZSAiTVVTVCIgaXMgaXQgd2FzIHN1Z2dlc3RlZCBi eSB0aGUgcmV2aWV3ZXIgc2luY2UgUkZDNDU4NSB0aGF0IHVzZXMgIk1VU1QiDQppbiB0aGUgY29u dGV4dCBvZiBjbGllbnQgZmVlZGJhY2sgc3VwcHJlc3Npb24uIEJ1dCBJIGFncmVlIHRoaXMgZGVz Y3JpcHRpb24gZG9lcyBub3QgY2xhcmlmeSBpbiB3aGF0IGNpcmN1bXN0YW5jZSB0byBhcHBseSBN VVNULiBUbyBiZSBjb25zaXN0ZW50IHdpdGggd2hhdCB3ZSBkZXNjcmliZWQgaW4gdGhlIHNlY3Vy aXR5IHNlY3Rpb24sIEkgYWdyZWUgd2l0aCB5b3VyIHN1Z2dlc3Rpb24gdG8gdGhlIHNlY3VyaXR5 IHNlY3Rpb24sIHRoYXQgaXMgdG8gc2F5IHRoZSBzdXBwcmVzc2lvbiBydWxlIGlzIG9ubHkgYXBw bGllZCB3aGVuIHRoZSBwYWNrZXQgYXJlIGludGVncml0eSBwcm90ZWN0ZWQgYW5kIGF1dGhlbnRp Y2F0ZWQuIEkgY2FuIHB1dCBzb21lIHRleHQgdG8gbWFrZSB0aGlzIGNsZWFyLg0KDQo+DQo+IDIp IFdoeSBhcmVuJ3QgUkZDMzcxMSBhbmQgUkZDNTEyNCBub3JtYXRpdmUgcmVmZXJlbmNlcz8gVGhl eSdyZSB0aGUgDQo+IG9ubHkgb2ZmZXJlZCB0b29scyBmb3IgYXV0aGVudGljYXRpbmcgdGhlc2Ug bWVzc2FnZXMgaW4gdGhlIGRvY3VtZW50LiANCj4gRXZlbiBpZiBvdGhlciBtZWNoYW5pc21zIG1p Z2h0IGV4aXN0LCB0aGVyZSBuZWVkcyB0byBiZSBkaXNjdXNzaW9uIA0KPiBzb21ld2hlcmUgb2Yg d2hhdCdzIHJlcXVpcmVkIG9mIHRoaXMgYXV0aGVudGljYXRpb24sIGFuZCB0aGUgc2VjdXJpdHkg DQo+IGNvbnNpZGVyYXRpb24gc2VjdGlvbnMgb2YgdGhvc2UgZG9jdW1lbnRzIHdvdWxkIHN1ZmZp Y2UuDQoNCltRaW5dIEFncmVlLCBmb3IgZGlzY3Vzc2lvbiBvbiB3aGVyZSB0aGUgYXV0aGVudGlj YXRpb24gaXMgcmVxdWlyZWQsDQoNCkkgbGlrZSB0byBmb2xsb3cgeW91ciBzdWdnZXN0aW9uLCBw bGVhc2Ugc2VlIGFib3ZlIGNsYXJpZmljYXRpb24uIEFsc28NCg0KIEkgd2lsbCBtb3ZlIFJGQzM3 MTEgYW5kIFJGQzUxMjQgdG8gbm9ybWF0aXZlIHJlZmVyZW5jZXMuDQoNCkRvZXMgdGhpcyBhZGRy ZXNzIHlvdXIgY29tbWVudD8NCg0KPg0KPiAzKSBUaGUgZmlyc3QgcGFydCBvZiB0aGUgSUFOQSBj b25zaWRlcmF0aW9ucyBzZWN0aW9uIGlzIG5vdCBjbGVhci4gSXMgDQo+IHRoaXMgdHJ5aW5nIHRv IGNyZWF0ZSBhIG5ldyByZWdpc3RyeSB3aXRoIHR3byBpbml0aWFsIHZhbHVlcywgb3IgYWRkIA0K PiB0d28gdmFsdWVzIHRvIGFuIGV4aXN0aW5nIHJlZ2lzdHJ5LiBJZiBpdCdzIGNyZWF0aW5nIGEg bmV3IG9uZSwgcGxlYXNlIA0KPiBwcm92aWRlIGEgcmVnaXN0cnkgbmFtZSwgYW5kIHN1Z2dlc3Qg d2hlcmUgaXQgc2hvdWxkIGFwcGVhci4NCg0KDQoNCltRaW5dOiBJIHRoaW5rIGl0IGlzIGxhdHRl ci4gVG8gbWFrZSBpdCBjbGVhciwgSSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgY2hhbmdlOg0KDQpP TEQgVGV4dDoNCg0KIg0KDQogICBGb3IgdXNlIHdpdGggIm5hY2siIFtSRkM0NTg1XSwgYSBqb2lu dCBzdWItcmVnaXN0cnkgaGFzIGJlZW4gc2V0IHVwDQoNCiAgIHRoYXQgcmVnaXN0ZXJzIHRoZSBm b2xsb3dpbmcgdHdvIHZhbHVlczoNCg0KICBUaGUgdmFsdWUgcmVnaXN0cmF0aW9uIGZvciB0aGUg YXR0cmlidXRlIHZhbHVlICJuYWNrIjoNCg0KIg0KTmV3IFRleHQ6DQoNCiINCg0KRm9yIHVzZSB3 aXRoICJuYWNrIiBbUkZDNDU4NV0sIHRoaXMgZG9jdW1lbnQgaW5zdHJ1Y3RzIElBTkEgdG8gYWRk IHR3byB2YWx1ZXMgaW4NCg0KImFjayIgYW5kICJuYWNrIiBBdHRyaWJ1dGUgVmFsdWVzIHJlZ2lz dHJ5Og0KDQpUaGUgdmFsdWUgcmVnaXN0cmF0aW9uIGZvciB0aGUgYXR0cmlidXRlIHZhbHVlICJu YWNrIjoNCg0KIg0KDQoNCg0KPiA0KSBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlv biBzcGVha3MgYWJvdXQgYXR0YWNrcyBiYXNlZCBvbiANCj4gc3B1cmlvdXMgcmVwb3J0cywgYnV0 IGRvZXNuJ3QgcmVhbGx5IGRpc2N1c3MgbW9yZSBkaXJlY3RlZCBhdHRhY2tzLiBJbiANCj4gcGFy dGljdWxhciwgaWYgYSByZWNlaXZlciBhY2NlcHRzIHVuYXV0aGVudGljYXRlZCBmZWVkYmFjayBz dXBwcmVzc2lvbiANCj4gbWVzc2FnZXMsIGFuIGF0dGFja2VyIGNvdWxkIGNhdXNlIHBhY2tldGxv c3MgZGlzcnVwdGluZyBhbiBpbXBvcnRhbnQgDQo+IHBhcnQgb2YgYSBzZXNzaW9uLCBwcmVlbXB0 aXZlbHkgc2VuZGluZyBmZWVkYmFjayBzdXBwcmVzc2lvbi4gQW4gDQo+IGF0dGFja2VyIHRoYXQg aXMgYWxzbyBhIHJlY2VpdmVyIGhhcyBlbm91Z2ggaW5mb3JtYXRpb24gdG8gc3VwcHJlc3MgDQo+ IF9hbGxfIGZlZWRiYWNrIGZyb20gYW55IG90aGVyIGxpc3RlbmVycyB0aGF0IGRvbid0IHVuYXV0 aGVudGljYXRlZCANCj4gcGFja2V0cy4gUGxlYXNlIG1ha2UgaXQgY2xlYXJlciB0aGF0IHRoZXNl IHJpc2tzIGV4aXN0Lg0KDQpbUWluXTogT2theS4gQmFzZWQgb24geW91ciBhYm92ZSBzdWdnZXN0 aW9uLCBJIGxpa2UgdG8gcHJvcG9zZSB0aGUgZm9sbG93aW5nIGNoYW5nZSB0byB0aGUgc2VjdGlv biA3LDNyZCBwYXJhZ3JhcGg6DQoNCk9MRCB0ZXh0Og0KDQoiDQoNClNlbmRpbmcgdGhlIHNwdXJp b3VzIFRoaXJkIFBhcnR5IExvc3MgUmVwb3J0IChlLmcuLCB0aGUgVGhpcmQgUGFydHkNCg0KICAg TG9zcyBSZXBvcnQgd2l0aCB0aGUgd3Jvbmcgc2VxdWVuY2UgbnVtYmVyIG9mIGxvc3QgcGFja2V0 KSB0aGF0DQoNCiAgIGNhdXNlcyBtaXNzaW5nIFJUUCBwYWNrZXRzIHRvIG5vdCBiZSByZXBhaXJl ZCBpbiBhIHRpbWVseSBmYXNoaW9uLg0KDQoiDQoNCk5ldyBUZXh0Og0KDQoiDQoNClNlbmRpbmcg dGhlIHNwdXJpb3VzIFRoaXJkIFBhcnR5IExvc3MgUmVwb3J0IHBhY2tldCAoZS5nLiwgdGhlIFRo aXJkIFBhcnR5DQoNCiAgIExvc3MgUmVwb3J0IHdpdGggdGhlIHdyb25nIHNlcXVlbmNlIG51bWJl ciBvZiBsb3N0IHBhY2tldCkgdGhhdA0KDQogICBjYXVzZXMgbWlzc2luZyBSVFAgcGFja2V0cyB0 byBub3QgYmUgcmVwYWlyZWQgaW4gYSB0aW1lbHkgZmFzaGlvbi4NCg0KSWYgYSByZWNlaXZlciBh Y2NlcHRzIHN1Y2ggdW5hdXRoZW50aWNhdGVkIHBhY2tldCwNCg0KYW4gYXR0YWNrZXIgY291bGQg Y2F1c2UgcGFja2V0IGxvc3MgZGlzcnVwdGluZyBhbiBpbXBvcnRhbnQgcGFydCBvZiBhIHNlc3Np b24sIHByZWVtcHRpdmVseSBzZW5kaW5nIGZlZWRiYWNrIHN1cHByZXNzaW9uLiBBbiBhdHRhY2tl ciB0aGF0IGlzIGFsc28gYSByZWNlaXZlciBoYXMgZW5vdWdoIGluZm9ybWF0aW9uIHRvIHN1cHBy ZXNzIGFsbCB0aGUgZmVlZGJhY2tzIGZyb20gYW55IG90aGVyIGxpc3RlbmVycyB0aGF0IGRvbid0 IGFjY2VwdCB1bmF1dGhlbnRpY2F0ZWQgcGFja2V0cy4NCg0KIg0KDQpEb2VzIHRoaXMgYWRkcmVz cyB5b3VyIGNvbW1lbnQ/DQoNCg0KPiA1KSBBdCB0aGUgZW5kIG9mIHNlY3Rpb24gMywgdGhlIGRv Y3VtZW50IHNheXMgbWVzc2FnZXMgU0hPVUxEIGJlIA0KPiBzdXBwcmVzc2VkICJmb3IgYSBwZXJp b2Qgb2YgdGltZSIuIENhbiB0aGF0IGJlIG1hZGUgbW9yZSBwcmVjaXNlPw0KDQpbUWluXTogU29y cnksIEkgZm9yZ290IHRvIGNsZWFyIHRoYXQgbml0cyBpbiB0aGUgcHJldmlvdXMgdmVyc2lvbi4g U2luY2Ugd2UgZm9sbG93DQoNCiB0aGUgZmVlZGJhY2sgc3VwcHJlc3Npb24gcnVsZSB3ZSBkZWZp bmVkIGluIFJGQzQ1ODUsIEkgdGhpbmsgdGhlIHJlY2VpdmVycw0KDQpzaG91bGQgc3VwcHJlc3Mg dGhlIGZ1cnRoZXIgZmVlZGJhY2sgZm9yIHRoZSBzYW1lIHBhY2tldCBsb3NzLiBUaGVyZWZvcmUg SSBsaWtlDQoNCiB0byByZW1vdmUgImZvciBhIHBlcmlvZCBvZiB0aW1lIi4NCg0KDQo+IEVkaXRv cmlhbCBzdWdnZXN0aW9uczoNCj4NCj4gUGxlYXNlIGV4cGFuZCBhY3JvbnltcyBvbiBmaXJzdCB1 c2UgKFRoZXJlIGFyZSBhIF9sb3RfIG9mIGFjcm9ueW1zLCANCj4gbWFueSBvZiB3aGljaCBuZWVk IHJlZmVyZW5jZXMgdG8gd2hlcmUgdGhleSBhcmUgZGVmaW5lZC4gQ29uc2lkZXIgDQo+IGFkZGlu ZyBhIGdsb3NzYXJ5IHNvIHlvdSBjYW4gZ2V0IHRoYXQgb3V0IG9mIHRoZSB3YXkgd2l0aG91dCAN Cj4gaW50ZXJydXB0aW5nIHRoZSBmbG93IG9mIHRoZSB0ZXh0KS4NCg0KW1Fpbl06IE9rYXkuDQoN Cj4gVGhlIHByb3RvY29sIGRlZmluaXRpb24gcGFydCBvZiB0aGlzIGRvY3VtZW50IChzZWN0aW9u IDQpIGlzIGEgYml0IG9mIA0KPiBhIHB1enpsZSBmb3IgYSBuZXcgcmVhZGVyLiBJdCB3b3VsZCBo ZWxwIHRvIGd1aWRlIHRoZSByZWFkZXIgdGhyb3VnaCANCj4gdGhlIGRlZmluaXRpb24gbW9yZSBk aXJlY3RseS4gSGVyZSdzIGEgc3VnZ2VzdGVkIG1vZGlmaWNhdGlvbiAtIGZlZWwgDQo+IGZyZWUg dG8gaWdub3JlIGl0Og0KPg0KPiBCZWZvcmUgc2VjdGlvbiA0LjEgc2F5ICJUaGUgZm9sbG93aW5n IHR3byBzZWN0aW9ucyBlYWNoIGRlZmluZSBhIHRoaXJkIA0KPiBwYXJ0eSBsb3NzIHJlcG9ydCBt ZXNzYWdlLiBCb3RoIG1lc3NhZ2VzIGFyZSBmZWVkYmFjayBtZXNzYWdlcyBhcyANCj4gZGVmaW5l ZCBpbiBzZWN0aW9uIDYuMSBvZiBSRkM0NTg1LCBhbmQgdXNlIHRoZSBoZWFkZXIgZm9ybWF0IGRl ZmluZWQgDQo+IHRoZXJlLiBFYWNoIHNlY3Rpb24gZGVmaW5lcyBob3cgdG8gcG9wdWxhdGUgdGhl IFBULCBGTVQsIGxlbmd0aCwgU1NSQyANCj4gb3IgcGFja2V0IHNlbmRlciwgU1NSQyBvZiBtZWRp YSBzb3VyY2UsIGFuZCBGQ0kgZmllbGRzIGluIHRoYXQgaGVhZGVyLiINCj4NCj4gVGhhdCB3aWxs IG1ha2UgaXQgbW9yZSBvYnZpb3VzIHRvIHRoZSByZWFkZXIgdGhhdCB0aGV5IG5lZWQgdG8gZ28g bG9vayANCj4gYXQgdGhlIHJlZmVyZW5jZWQgc2VjdGlvbiBpbiA0NTg1IHJpZ2h0IGF3YXksIGFu ZCBtYWtlcyBpdCBwb3NzaWJsZSB0byANCj4gc2ltcGxpZnkgdGhlIHRleHQgaW4gNC4xIGFuZCA0 LjIuIDQuMSBjYW4gc3RhdGUgY2xlYXJseSBhbmQgZWFybHkgdGhhdCANCj4gaXQgaXMgZGVmaW5p bmcgdGhlIFRMTEVJLCBldGMuDQoNCltRaW5dOiBMb29rcyBnb29kIHRvIG1lLg0KDQoNCj4gV2hl dGhlciB5b3UgY2hvb3NlIHRvIGFjdCBvbiB0aGlzIHN1Z2dlc3Rpb24gb3Igbm90LCBwbGVhc2Ug Y2hhbmdlIHRoZSANCj4gVEJEcyB0byBUQkQxIGFuZCBUQkQyLCBhbmQgc2F5ICJsZW5ndGggZmll bGQgaW4gdGhlIiBpbnN0ZWFkIG9mIA0KPiAibGVuZ3RoIG9mIiB3aGVuIHRhbGtpbmcgYWJvdXQg c2V0dGluZyB0aGUgbGVuZ3RoIGZpZWxkIGluIGVhY2ggbWVzc2FnZS4NCg0KW1Fpbl06IE9rYXku DQoNCg0KPiBOaXRzIHNlbnQgZGlyZWN0bHkgdG8gZWRpdG9ycy4NCg0KIFtRaW5dOiBUaGFua3Mu DQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlIGF2dEBpZXRmLm9y ZyANCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnQNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBdWRpby9WaWRlbyBUcmFu c3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KYXZ0QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2F2dA0K From magnus.westerlund@ericsson.com Sun Mar 4 23:39:21 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DACA11E8074 for ; Sun, 4 Mar 2012 23:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.997 X-Spam-Level: X-Spam-Status: No, score=-109.997 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 4QWkBOjrH10Y for ; Sun, 4 Mar 2012 23:39:19 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 40DDE21F861B for ; Sun, 4 Mar 2012 23:39:19 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-62-4f546da5be30 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 37.3A.27041.5AD645F4; Mon, 5 Mar 2012 08:39:17 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Mon, 5 Mar 2012 08:39:17 +0100 Message-ID: <4F546DA1.2030708@ericsson.com> Date: Mon, 5 Mar 2012 08:39:13 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Qin Wu References: <4F3BB9C2.3020509@ericsson.com> <94DC837519784483ABEA2D7891C9CC08@china.huawei.com> <4F4E30F6.2060800@ericsson.com> <31521F79682242FC99A0E172329AFA72@china.huawei.com> In-Reply-To: <31521F79682242FC99A0E172329AFA72@china.huawei.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-monarch-09 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 07:39:21 -0000 Hi, I think the fixes are good enough. Now I am hoping for some broader review during the WG last call which I will start in a separate message. Cheers Magnus On 2012-03-01 11:57, Qin Wu wrote: > Hi, Magnus: > See inline belows. > > Regards! > -Qin > ----- Original Message ----- > From: "Magnus Westerlund" > To: "Qin Wu" > Cc: "IETF AVTCore WG" > Sent: Wednesday, February 29, 2012 10:06 PM > Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-monarch-09 > > >> Hi, >> >> Thanks for addressing my comment. See inline the ones where I have >> comments or feedback on the suggestions for fixing the issues. >> >> >> >> On 2012-02-24 10:13, Qin Wu wrote: >>> -------------------------------------------- >>> 3. In general I think 3.1 should discuss what exist already for >>> monitoring which there is no discussion. Like the RTP MIB. I can also >>> see other solutions like using IPfix to capture a packet flow and then >>> process using an RTP and RTCP receiver. >>> >>> >>> [Qin] I agree. In order to fix this, We propose >>> >>> the following text at the beginning of section >>> >>> 3.1 to say: >>> >>> “ >>> >>> There are many ways in which the performance >>> >>> of an RTP session can be monitored. These >>> >>> include RTP-based mechanisms such as the RTP >>> >>> SNMP MIB [RFC2959], or the SIP event package >>> >>> for RTCP summary reports [RFC6035], or non-RTP >>> >>> mechanisms such as generic MIBs, NetFlow, IPFix, >>> >>> and so on. Together, these provide useful >>> >>> mechanisms for exporting data on the performance >>> >>> of an RTP session to non-RTP network management >>> >>> systems. It is desirable to also perform in-session >>> >>> monitoring of RTP performance. RTCP provides the >>> >>> means to do this. In the following, we specify an >>> >>> architecture for using and extending RTCP for >>> >>> monitoring RTP sessions. One major benefit of >>> >>> such architecture is with ease of integration >>> >>> with other RTP/RTCP mechanism. >>> >>> ” >> >> Yes, that makes the scope and context much more clearer. > > [Qin]: Great and has fixed in version (-10). > >> >>> -------------------------------------- >>> 4. The document argues for RTCP XR based monitoring, but can you please >>> provide a clear indication of what the benefits are. >>> >>> >>> [Qin]: One major benefit I think is Ease of >>> >>> integration with other RTP/RTCP mechanisms. >>> >>> Another benefit I can see is RTCP-based monitoring >>> >>> Takes both transport quality and application quality >>> >>> into account and can provide more accurate measurement >>> >>> for the Real time application quality. >> >> My intention was to have that made clear in the draft. > > [Qin]: I see and like to put additional text in the above proposed text at the beginning of section 3.1. >> >>> 6. Section 1. >>> "As more users and subscribers rely on real time application services, >>> uncertainties in the performance and availability of these services >>> are driving the need to support new standard methods for gathering >>> performance metrics from RTP applications." >>> >>> What users and subscribers are you discussing above? The ones using RTP >>> to build services or the actual user of the service using RTP? >>> >>> >>> [Qin]: I think it is the latter. How about change it as: >>> >>> “ >>> >>> As the delivery of multimedia services using the Real-Time >>> >>> Transport Protocol (RTP) over IP network is gaining an >>> >>> increasing popularity, uncertainties in the performance and >>> >>> availability of these services are driving the need to >>> >>> support new standard methods for gathering performance >>> >>> metrics from RTP applications. >>> >> >> >> Yes, that is clearer. > > [Qin]: Great and has already fixed in the version (-10). > >> >>> --------------------------------------- >>> 8. Section 1. " Quality of Experience (QoE)." Can you please include >>> some reference that explains the concept of QoE? >>> >>> >>> [Qin]: Good suggestion, I think we should reference >>> >>> RFC6390 or P.10/G.100 Amendment 2. I prefer to use >>> >>> RFC6390. >> >> RFC 6390 is fine. > > [Qin]: Great and has already fixed in the version (-10). > >>> >>> >>> ------------------------------------- >>> 9. Section 1: "Since different applications layered on RTP may have >>> some monitoring requirements in common, therefore these metrics >>> should be satisfied by a common design." >>> >>> The above sentence needs to be reformulated. >>> >>> >>> [Qin]: How about rephrase like: >>> >>> “Given that different applications layered on RTP may have >>> >>> some monitoring requirements in common, these metrics >>> >>> should be satisfied by a common design. >>> >> >> Hmm, I guess it works in the context it is used in. > > [Qin]: Okay, so you agree it fits into the document?! > >> >>> 11. Section 2: One example of such metrics is the QoE Metric >>> specified in QoE metric reporting Block [MQ]. >>> >>> I don't think that reference is a good example. The reference defines >>> how to transport and identify a large number of application level >>> metrics in RTCP XR, rather than being an example of a metric. >>> >>> >>> [Qin]: Do we have better reference than this one. >>> >>> I am aware that some ITU-T documents (e.g., ITU-T P.NAMS, >>> >>> P.NBAMS) define measurement method and model for >>> >>> QoE evaluation while other documents like RFC6390, >>> >>> E.800, P.10/G.100 Amendment 2 only give definition >>> >>> of QoE. Also I think QoE metric reporting Block [MQ] >>> >>> not only define data format for QoE metric and but >>> >>> also provide Metric name and description for QoE metric. >>> >>> If you really concerns this, I can remove this sentence. >> >> No, I can live with what is there. > > [Qin]: Great. >>> >>> --------------------------------- >>> 12. Section 2: >>> Composed metrics >>> >>> Metrics that are calculated based on direct metric or combination >>> of direct metric and derived metrics. >>> >>> What is an derived metric? Appears to be an reference without an >>> explanation. >>> >>> [Qin]: Derived metric is actually one kind of composed metric. >>> >>> How about fix this like: >>> >>> “ >>> >>> Composed metrics >>> >>> Metrics that are calculated based on Direct metric that have been >>> measured or combination of Direct metrics that are identical to the >>> metric being composed. >>> ” >> >> Sorry, that looks strange in the second part: "combination of Direct >> metrics that are identical to the metric being composed" How can they be >> identical when they are a combination? > > > [Qin]: I agree it is confusing. I am just thinking we may have case where one metric > A is calculated by one direct metric B and another metric C and the metric C is > calculated from the same direct metric B. > Also we may have the case where one metric D is calculated from two other > composed metrics E and F. In these two cases, A,C,D,E,F are all composed metrics. > How about change it as: > “ > Composed metrics > > Metrics that are not directly measured and derived from other metrics. > One example of such metrics is the ones calculated based on Direct > metric that have been measured. > ” > >> >> >>> ---------------------------------------------- >>> 13. Section 2: >>> Interval metrics >>> >>> It is referred to as the metrics of which the reported values >>> apply to the most recent measurement interval duration between >>> successive metrics reports >>> >>> Is "interval duration" actually good English? To me the duration of an >>> interval is the actual interval. >>> >>> [Qin]:My understanding is Yes, Interval metrics is defined >>> in relation to “cumulative metric” as a metric that apply >>> to the duration of an interval. The interval should be the >>> most recent interval to be measured rather than accumulative >>> period within the whole session. >> >> Hmm, let see if someone else gets tripped up by this. > >>> ------------------------------------------------- >>> 14. Section 2: >>> Sampled metrics >>> >>> It is referred to as the metrics of which the reported values only >>> apply to the value of a continuously measured or calculated that >>> has been sampled at end of the interval. >>> >>> Doesn't the above exclude metrics measured at give instance. Or is that >>> what "sampled at end of the interval" means? But then it isn't actually >>> an interval, is it? >>> >>> [Qin]: Ideally, I think sample metric can be applied to any >>> instance of one measurement interval. But I assume the more >>> sampled data you gather during one measurement interval, the >>> more accurate the sampled metric you can calculate. Does this >>> make sense? >> >> No, there is to much context missing of what type of metering one >> attempts and the behavior of the subject of the metering. > > [Qin] Sample metric is one metric that is different from interval metric and cumulative metric. > Take interarrival jitter defined in Section 6.4.1 of [RFC3550] as a example, the value J(i) is > the example of sampled metric and should be calculated according to [RFC3550] at the time > the report is generated, i.e., > J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16 > Therefore I think your suggestion is reasonable. That is to say, the sampled metric can be > calculated at any instance of measurement interval rather than only at the end of measurement > interval. If you agree with this, I like to propose the following change to sampled metrics definition: > “ > Sampled metrics > > It is referred to as the metrics of which the reported values only > apply to the value of a continuously measured or calculated that > has been sampled at any given instance of the interval. > ” > Does this address your comments? >> >> >> >>> ---------------------------------------------------- >>> 17. Section 3.2: >>> o RTCP NACK is used to provide feedback on the RTP sequence number >>> of the lost packets [RFC4585]. >>> >>> In this case I would be a bit careful. Because the sequence numbers >>> reported on in NACK may in fact be a subset of all lost packets. Already >>> the media stream receiver creating NACK requests may in fact filter on >>> which sequence number is reported. There was a proposal for a >>> informative block (draft-ietf-avt-rtp-selret-05.txt) that allowed for >>> this type of information. There is other cases where a receiver will be >>> able to determine that it doesn't need to ask for some lost packets. >>> >>> >>> [Qin]: Okay, How about rephrase this sentence as: >>> >>> “ >>> >>> o RTCP NACK is used to provide feedback on the RTP sequence number >>> >>> on a subset of the lost packets or the total lost packets[RFC4585]. >>> >>> ” >> >> Except that "numbers" and "for a subset". I also think "total" is likely >> wrong and "all the currently" > > [Qin]: Do you suggest to the following change: > “ > RTCP NACK is used to provide feedback on the RTP sequence numbers > for a subset of the lost packets or all the currently lost packets [RFC4585]. > > ” > If yes, I like to fix this as you suggested. If not, please let me know. > >> >> 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 >> ---------------------------------------------------------------------- >> > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- 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 magnus.westerlund@ericsson.com Sun Mar 4 23:44:33 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69DB21F8535 for ; Sun, 4 Mar 2012 23:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.297 X-Spam-Level: X-Spam-Status: No, score=-110.297 tagged_above=-999 required=5 tests=[AWL=0.301, 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 Tj7wVTnqtub7 for ; Sun, 4 Mar 2012 23:44:33 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9E321F8513 for ; Sun, 4 Mar 2012 23:44:32 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-04-4f546edf0aa8 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EE.4B.27041.FDE645F4; Mon, 5 Mar 2012 08:44:32 +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.213.0; Mon, 5 Mar 2012 08:44:31 +0100 Message-ID: <4F546EDF.10203@ericsson.com> Date: Mon, 5 Mar 2012 08:44:31 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVTCORE] WG last call on Monitoring Architecture for RTP (draft-ietf-avtcore-monarch-11) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 07:44:34 -0000 WG, This initiates the Working group last call on Monitoring Architecture for RTP (draft-ietf-avtcore-monarch-11) to be published as Informational RFC. The WG last call will run for three weeks and end Monday the 26th. The draft can be retrieved from here: https://datatracker.ietf.org/doc/draft-ietf-avtcore-monarch/ Please provide feedback if you have read it, even if you have no comments or think it is good enough, this is important information in judging the support and readiness for publication. Thanks 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 magnus.westerlund@ericsson.com Mon Mar 5 02:03:09 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C2A21F867A for ; Mon, 5 Mar 2012 02:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.314 X-Spam-Level: X-Spam-Status: No, score=-110.314 tagged_above=-999 required=5 tests=[AWL=0.285, 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 v0wJvDOSca7E for ; Mon, 5 Mar 2012 02:03:09 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8AB21F85B5 for ; Mon, 5 Mar 2012 02:03:08 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-93-4f548f5b9fca Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E3.A4.01970.B5F845F4; Mon, 5 Mar 2012 11:03: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.213.0; Mon, 5 Mar 2012 11:03:06 +0100 Message-ID: <4F548F59.8020603@ericsson.com> Date: Mon, 5 Mar 2012 11:03:05 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Van Caenegem, Tom (Tom)" References: <4F4FF7C1.6040501@nostrum.com> <93213B506E254BE7941B02E9630EAB00@china.huawei.com> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avt@ietf.org" , "draft-ietf-avtcore-feedback-suppression-rtp@tools.ietf.org" , "avtcore-chairs@tools.ietf.org" Subject: Re: [AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-rtp-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 10:03:10 -0000 Hi, Agree that there should be no difference between authenticated and non-authenticated messages. I still don't think you have resolved the issue that Robert pointed out: > 1) Section 3, paragraph 3, says a receiver MUST follow the rules for > NACK suppression on receipt of a third partly loss report. Section 4 > says receivers MAY ignore third party lost reports, and then confusingly > says the SHOULD not ignore them. The security considerations section > says that receivers would be "well advised to ignore" (effectively > SHOULD ignore) third party reports unless they are authenticated. This > needs to be reconciled. > > Are you trying to say the following? > > *) MUST follow the suppression rules if packets are authenticated > *) SHOULD NOT follow the suppression rules if the packets are not > authenticated > > Or something else? Either way, please make the document internally > consistent. My impression is that the paragraph 3 is about the RFC4585 based suppression of sending additional RTCP message with the same meaning. The text in in section 4 is that upon receiving a TPLR message a receiver can treat it as an indication and chose to disregard it. However, the criteria is vague. I also think the formulation of using MAY plus should could just as well be replaced by a SHOULD formulation, like: Receivers SHOULD react to TPLR messages unless .... What does other say? We still need an updated version prior to IETF LC. 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 rjsparks@nostrum.com Mon Mar 5 09:01:38 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A37E21F87D2 for ; Mon, 5 Mar 2012 09:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcUj8hUl61an for ; Mon, 5 Mar 2012 09:01:37 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9547D21F87C4 for ; Mon, 5 Mar 2012 09:01:36 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q25H1Ktd004524 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 5 Mar 2012 11:01:21 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <4F54F162.5010608@nostrum.com> Date: Mon, 05 Mar 2012 11:01:22 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Qin Wu References: <4F4FF7C1.6040501@nostrum.com> <93213B506E254BE7941B02E9630EAB00@china.huawei.com> In-Reply-To: <93213B506E254BE7941B02E9630EAB00@china.huawei.com> Content-Type: multipart/alternative; boundary="------------030902010600070705050904" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: draft-ietf-avtcore-feedback-suppression-rtp@tools.ietf.org, avtcore-chairs@tools.ietf.org, avt@ietf.org Subject: [AVTCORE] draft-ietf-avtcore-feedback-supression-rtp-14 (was Re: AD review: draft-ietf-avtcore-feedback-suppression-rtp-13) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 17:01:38 -0000 This is a multi-part message in MIME format. --------------030902010600070705050904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Qin - Version 14 still has some issues. I'm confused about the changes made to address Item 1), and it looks like Magnus still has questions about that too. Please resolve that by replying to Magnus' message. The first part of the IANA registration section is still unclear. From your response below, I gather you are trying to create a new registry instead of trying to put values in an existing registry, but your proposed text still looks like it's trying to add a value to some table that already exists. Where are you expecting IANA to put this new registry? Are you expecting it to be a subregistry of the RTP Parameters registry? If so, say so, and provide a name for the registry. You also need to provide a policy for adding other values. See RFC5226 section 4.2. That said, why are you trying to put these in a registry in the first place? Looking at the document, it seems that you are only wanting to make these be standardized strings that can appear in the production of an SDP rtcp-fb-nack-param line. You've done that with the grammar defined in this document. I don't see any change in this revision to address the following comment: On 3/1/12 10:52 PM, Qin Wu wrote: > >> 5) At the end of section 3, the document says messages SHOULD be >> suppressed "for a period of time". Can that be made more precise? > [Qin]: Sorry, I forgot to clear that nits in the previous version. Since we follow > > the feedback suppression rule we defined in RFC4585, I think the receivers > > should suppress the further feedback for the same packet loss. Therefore I like > > to remove "for a period of time". --------------030902010600070705050904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Qin -

Version 14 still has some issues.

I'm confused about the changes made to address Item 1), and it looks like Magnus still has questions
about that too. Please resolve that by replying to Magnus' message.

The first part of the IANA registration section is still unclear. From your response below, I gather you
are trying to create a new registry instead of trying to put values in an existing registry, but your proposed
text still looks like it's trying to add a value to some table that already exists.

Where are you expecting IANA to put this new registry? Are you expecting it to be a subregistry of
the RTP Parameters registry? If so, say so, and provide a name for the registry. You also need to
provide a policy for adding other values. See RFC5226 section 4.2.

That said, why are you trying to put these in a registry in the first place?  Looking at the document,
it seems that you are only wanting to make these be standardized strings that can appear in
the production of an SDP rtcp-fb-nack-param line. You've done that with the grammar defined in this
document.

I don't see any change in this revision to address the following comment:

On 3/1/12 10:52 PM, Qin Wu wrote:

<snip/>

5) At the end of section 3, the document says messages SHOULD be 
suppressed "for a period of time". Can that be made more precise?

[Qin]: Sorry, I forgot to clear that nits in the previous version. Since we follow

 the feedback suppression rule we defined in RFC4585, I think the receivers 

should suppress the further feedback for the same packet loss. Therefore I like

 to remove "for a period of time".
--------------030902010600070705050904-- From rjsparks@nostrum.com Mon Mar 5 10:21:41 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0DF21F88A0 for ; Mon, 5 Mar 2012 10:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hg2+fcB7VPv7 for ; Mon, 5 Mar 2012 10:21:41 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 549F421F888B for ; Mon, 5 Mar 2012 10:21:40 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q25ILVj8017666 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 5 Mar 2012 12:21:32 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <4F55042F.9050606@nostrum.com> Date: Mon, 05 Mar 2012 12:21:35 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Qin Wu References: <4F4FF7C1.6040501@nostrum.com> <93213B506E254BE7941B02E9630EAB00@china.huawei.com> <4F54F162.5010608@nostrum.com> In-Reply-To: <4F54F162.5010608@nostrum.com> Content-Type: multipart/alternative; boundary="------------060705030700000708010503" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: avtcore-chairs@tools.ietf.org, avt@ietf.org, draft-ietf-avtcore-feedback-supression-rtp@tools.ietf.org Subject: Re: [AVTCORE] draft-ietf-avtcore-feedback-supression-rtp-14 (was Re: AD review: draft-ietf-avtcore-feedback-suppression-rtp-13) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 18:21:42 -0000 This is a multi-part message in MIME format. --------------060705030700000708010503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Inline On 3/5/12 11:01 AM, Robert Sparks wrote: > Hi Qin - > > Version 14 still has some issues. > > I'm confused about the changes made to address Item 1), and it looks > like Magnus still has questions > about that too. Please resolve that by replying to Magnus' message. > > The first part of the IANA registration section is still unclear. From > your response below, I gather you > are trying to create a new registry instead of trying to put values in > an existing registry, but your proposed > text still looks like it's trying to add a value to some table that > already exists. > > Where are you expecting IANA to put this new registry? Are you > expecting it to be a subregistry of > the RTP Parameters registry? If so, say so, and provide a name for the > registry. You also need to > provide a policy for adding other values. See RFC5226 section 4.2. > > That said, why are you trying to put these in a registry in the first > place? Looking at the document, > it seems that you are only wanting to make these be standardized > strings that can appear in > the production of an SDP rtcp-fb-nack-param line. You've done that > with the grammar defined in this > document. Ah - that thought should have answered my question by itself instantly. You are trying to put these values in this registry The text you added for -14 is close - I suggest this change: OLD: This document instructs IANA to add two values in "ack" and "nack" Attribute Values registry for use with "nack"[RFC4585]: NEW: This document instructs IANA to add two values to the '"ack" and "nack" Attribute Values' sub-registry [RFC4585] of the 'Session Description Protocol (SDP) Parameters' registry. > > I don't see any change in this revision to address the following comment: > > On 3/1/12 10:52 PM, Qin Wu wrote: > > >> >>> 5) At the end of section 3, the document says messages SHOULD be >>> suppressed "for a period of time". Can that be made more precise? >> [Qin]: Sorry, I forgot to clear that nits in the previous version. Since we follow >> >> the feedback suppression rule we defined in RFC4585, I think the receivers >> >> should suppress the further feedback for the same packet loss. Therefore I like >> >> to remove "for a period of time". > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --------------060705030700000708010503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Inline

On 3/5/12 11:01 AM, Robert Sparks wrote:
Hi Qin -

Version 14 still has some issues.

I'm confused about the changes made to address Item 1), and it looks like Magnus still has questions
about that too. Please resolve that by replying to Magnus' message.

The first part of the IANA registration section is still unclear. From your response below, I gather you
are trying to create a new registry instead of trying to put values in an existing registry, but your proposed
text still looks like it's trying to add a value to some table that already exists.

Where are you expecting IANA to put this new registry? Are you expecting it to be a subregistry of
the RTP Parameters registry? If so, say so, and provide a name for the registry. You also need to
provide a policy for adding other values. See RFC5226 section 4.2.

That said, why are you trying to put these in a registry in the first place?  Looking at the document,
it seems that you are only wanting to make these be standardized strings that can appear in
the production of an SDP rtcp-fb-nack-param line. You've done that with the grammar defined in this
document.
Ah - that thought should have answered my question by itself instantly.
You are trying to put these values in this registry
<http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml#sdp-parameters-15>

The text you added for -14 is close - I suggest this change:

OLD:
  This document instructs IANA to add two values in "ack" and "nack"
   Attribute Values registry for use with "nack"[RFC4585]:

NEW:

  This document instructs IANA to add two values to the '"ack" and "nack"
   Attribute Values' sub-registry [RFC4585] of the 'Session Description
   Protocol (SDP) Parameters' registry.


I don't see any change in this revision to address the following comment:

On 3/1/12 10:52 PM, Qin Wu wrote:

<snip/>

5) At the end of section 3, the document says messages SHOULD be 
suppressed "for a period of time". Can that be made more precise?

[Qin]: Sorry, I forgot to clear that nits in the previous version. Since we follow

 the feedback suppression rule we defined in RFC4585, I think the receivers 

should suppress the further feedback for the same packet loss. Therefore I like

 to remove "for a period of time".



_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt
--------------060705030700000708010503-- From ron.even.tlv@gmail.com Mon Mar 5 10:25:31 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D5421F8792 for ; Mon, 5 Mar 2012 10:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.463 X-Spam-Level: X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.135, 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 OGOIvnmpOMRU for ; Mon, 5 Mar 2012 10:25:30 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 30D4721F85BB for ; Mon, 5 Mar 2012 10:25:19 -0800 (PST) Received: by eaaq11 with SMTP id q11so1510138eaa.31 for ; Mon, 05 Mar 2012 10:25:18 -0800 (PST) Received-SPF: pass (google.com: domain of ron.even.tlv@gmail.com designates 10.213.8.79 as permitted sender) client-ip=10.213.8.79; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ron.even.tlv@gmail.com designates 10.213.8.79 as permitted sender) smtp.mail=ron.even.tlv@gmail.com; dkim=pass header.i=ron.even.tlv@gmail.com Received: from mr.google.com ([10.213.8.79]) by 10.213.8.79 with SMTP id g15mr2062776ebg.108.1330971918424 (num_hops = 1); Mon, 05 Mar 2012 10:25:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=f/XA9QrUFwRfBy03Gwh3gPf2Nn+c9r+LR+C37aGHOkc=; b=wBTJn752mZrYEPxCPd59M0t92Wy+Tu2ujT8kXAdtdu3ToyltL5AkOCkT1rBEdH5mtT njRIEl+6FETs8v5XJV34nG71sjxI1vCVqaIawUH2zXyDgLppzBK8IquIn7uPomXF91Wk 9k5moLmEc95aDEBu4qixQa19737cE8++kWF6XQtxwxAj5T6TDK+RccMwj965JlnBx2rN f9QnJg4hNdVcGzrroREfX9/4/zSwHjS9vymo626nwMCB78WobzbX05fz/x8l/vUCSg0a GqALCB9sEoMWyq64zJFJGq74qIr37bKcRRaQD4C5ZPjVd6D9n/fATvPQLUTIYBbvLvGm ME2g== Received: by 10.213.8.79 with SMTP id g15mr1530882ebg.108.1330971918276; Mon, 05 Mar 2012 10:25:18 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id y11sm3029933eem.3.2012.03.05.10.25.14 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Mar 2012 10:25:17 -0800 (PST) From: "Roni Even" To: "'Robert Sparks'" , "'Qin Wu'" References: <4F4FF7C1.6040501@nostrum.com> <93213B506E254BE7941B02E9630EAB00@china.huawei.com> <4F54F162.5010608@nostrum.com> In-Reply-To: <4F54F162.5010608@nostrum.com> Date: Mon, 5 Mar 2012 20:24:09 +0200 Message-ID: <4f55050d.8bbb0e0a.7217.ffff8876@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_062B_01CCFB0D.EE6A6B00" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acz68aWkqyw6/IYsQCGrbwd3HBGnwgACyhsA Content-Language: en-us Cc: draft-ietf-avtcore-feedback-suppression-rtp@tools.ietf.org, avtcore-chairs@tools.ietf.org, avt@ietf.org Subject: Re: [AVTCORE] draft-ietf-avtcore-feedback-supression-rtp-14 (was Re: AD review: draft-ietf-avtcore-feedback-suppression-rtp-13) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 18:25:31 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_062B_01CCFB0D.EE6A6B00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Robert, The IANA registration adds value to an existing registry called ack and nack Attribute Values and this what the IANA section says " This document instructs IANA to add two values in "ack" and "nack" Attribute Values registry for use with "nack"[RFC4585 ]:" It is defined in RFC 4584 see below. For use with both "ack" and "nack", a joint sub-registry has been set up that initially registers the following values: Initial value registration for the attribute values "ack" and "nack": Value name: sli Long name: Slice Loss Indication Usable with: nack Reference: RFC 4585. Value name: pli Long name: Picture Loss Indication Usable with: nack Reference: RFC 4585. Value name: rpsi Long name: Reference Picture Selection Indication Usable with: ack, nack Reference: RFC 4585. Value name: app Long name: Application layer feedback Usable with: ack, nack Reference: RFC 4585. Further entries may be registered on a first-come first-serve basis. Each registration needs to indicate the parameter name, the syntax of possible additional arguments, and whether the parameter is applicable to "ack" or "nack" feedback or both or some different "rtcp-fb" attribute parameter. For each new registration, it is mandatory that a permanent, stable, and publicly accessible document exists that specifies the semantics of the registered parameter, the syntax and semantics of its parameters as well as corresponding feedback packet formats (if needed). The general registration procedures of [3] apply. Roni Even From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Robert Sparks Sent: Monday, March 05, 2012 7:01 PM To: Qin Wu Cc: draft-ietf-avtcore-feedback-suppression-rtp@tools.ietf.org; avtcore-chairs@tools.ietf.org; avt@ietf.org Subject: [AVTCORE] draft-ietf-avtcore-feedback-supression-rtp-14 (was Re: AD review: draft-ietf-avtcore-feedback-suppression-rtp-13) Hi Qin - Version 14 still has some issues. I'm confused about the changes made to address Item 1), and it looks like Magnus still has questions about that too. Please resolve that by replying to Magnus' message. The first part of the IANA registration section is still unclear. From your response below, I gather you are trying to create a new registry instead of trying to put values in an existing registry, but your proposed text still looks like it's trying to add a value to some table that already exists. Where are you expecting IANA to put this new registry? Are you expecting it to be a subregistry of the RTP Parameters registry? If so, say so, and provide a name for the registry. You also need to provide a policy for adding other values. See RFC5226 section 4.2. That said, why are you trying to put these in a registry in the first place? Looking at the document, it seems that you are only wanting to make these be standardized strings that can appear in the production of an SDP rtcp-fb-nack-param line. You've done that with the grammar defined in this document. I don't see any change in this revision to address the following comment: On 3/1/12 10:52 PM, Qin Wu wrote: 5) At the end of section 3, the document says messages SHOULD be suppressed "for a period of time". Can that be made more precise? [Qin]: Sorry, I forgot to clear that nits in the previous version. Since we follow the feedback suppression rule we defined in RFC4585, I think the receivers should suppress the further feedback for the same packet loss. Therefore I like to remove "for a period of time". ------=_NextPart_000_062B_01CCFB0D.EE6A6B00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Robert,

The IANA registration adds value to an existing registry called ack =
and nack Attribute Values and this what the IANA section says =
" This document instructs IANA to add two =
values in "ack" and =
"nack"
   =
Attribute Values registry for use with "nack"[RFC4585]:"
 

 

It is defined in RFC 4584 see below.

 

For use with both "ack" and = "nack", a joint sub-registry has been = set

   up that initially registers the = following values:

 

   Initial value registration for the = attribute values "ack" and = "nack":

 

     Value = name:     sli

     Long = name:      Slice Loss = Indication

     Usable = with:    nack

    =  Reference:      RFC = 4585.

 

     Value = name:     pli

     Long = name:      Picture Loss = Indication

     Usable = with:    nack

     = Reference:      RFC = 4585.

 

     Value = name:     rpsi

     Long = name:      Reference Picture Selection = Indication

     Usable = with:    ack, nack

     = Reference:      RFC = 4585.

 

     Value = name:     app

     Long = name:      Application layer = feedback

     Usable = with:    ack, nack

     = Reference:      RFC = 4585.

 

   Further entries may be registered on = a first-come first-serve basis.

   Each registration needs to indicate = the parameter name, the syntax of

   possible additional arguments, and = whether the parameter is

   applicable to "ack" or = "nack" feedback or both or some = different

   "rtcp-fb" attribute = parameter.  For each new registration, it = is

   mandatory that a permanent, stable, = and publicly accessible document

   exists that specifies the semantics = of the registered parameter, the

   syntax and semantics of its = parameters as well as corresponding

   feedback packet formats (if = needed).  The general registration

   procedures of [3] = apply.

 

Roni Even

 

 

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Robert Sparks
Sent: Monday, March 05, 2012 7:01 = PM
To: Qin Wu
Cc: = draft-ietf-avtcore-feedback-suppression-rtp@tools.ietf.org; = avtcore-chairs@tools.ietf.org; avt@ietf.org
Subject: [AVTCORE] = draft-ietf-avtcore-feedback-supression-rtp-14 (was Re: AD review: = draft-ietf-avtcore-feedback-suppression-rtp-13)

 

Hi Qin -

Version 14 still has some = issues.

I'm confused about the changes made to address Item 1), = and it looks like Magnus still has questions
about that too. Please = resolve that by replying to Magnus' message.

The first part of = the IANA registration section is still unclear. From your response = below, I gather you
are trying to create a new registry instead of = trying to put values in an existing registry, but your proposed
text = still looks like it's trying to add a value to some table that already = exists.

Where are you expecting IANA to put this new registry? = Are you expecting it to be a subregistry of
the RTP Parameters = registry? If so, say so, and provide a name for the registry. You also = need to
provide a policy for adding other values. See RFC5226 section = 4.2.

That said, why are you trying to put these in a registry in = the first place?  Looking at the document,
it seems that you are = only wanting to make these be standardized strings that can appear = in
the production of an SDP rtcp-fb-nack-param line. You've done that = with the grammar defined in this
document.

I don't see any = change in this revision to address the following comment:

On = 3/1/12 10:52 PM, Qin Wu = wrote:

<snip/>



5) At the end of section =
3, the document says messages SHOULD be 
suppressed =
"for a period of time". Can that be made more =
precise?
 
[Qin]: Sorry, =
I forgot to clear that nits in the previous version. Since we =
follow
 
 the feedback =
suppression rule we defined in RFC4585, I think the receivers =

 
should suppress the =
further feedback for the same packet loss. Therefore I =
like
 
 to remove =
"for a period of =
time".
------=_NextPart_000_062B_01CCFB0D.EE6A6B00-- From rjsparks@nostrum.com Mon Mar 5 11:01:46 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903BD21F88A6 for ; Mon, 5 Mar 2012 11:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7p2ez1Owhhb for ; Mon, 5 Mar 2012 11:01:45 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 560C821F86B6 for ; Mon, 5 Mar 2012 11:01:45 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q25J1e42023975 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 5 Mar 2012 13:01:40 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <4F550D99.4020200@nostrum.com> Date: Mon, 05 Mar 2012 13:01:45 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Roni Even References: <4F4FF7C1.6040501@nostrum.com> <93213B506E254BE7941B02E9630EAB00@china.huawei.com> <4F54F162.5010608@nostrum.com> <4f55050d.8bbb0e0a.7217.ffff8876@mx.google.com> In-Reply-To: <4f55050d.8bbb0e0a.7217.ffff8876@mx.google.com> Content-Type: multipart/alternative; boundary="------------000908040007060906090206" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: draft-ietf-avtcore-feedback-suppression-rtp@tools.ietf.org, avtcore-chairs@tools.ietf.org, avt@ietf.org Subject: Re: [AVTCORE] draft-ietf-avtcore-feedback-supression-rtp-14 (was Re: AD review: draft-ietf-avtcore-feedback-suppression-rtp-13) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 19:01:46 -0000 This is a multi-part message in MIME format. --------------000908040007060906090206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Yep - caught that already and suggested text that should be easier for IANA. On 3/5/12 12:24 PM, Roni Even wrote: > > Hi Robert, > > The IANA registration adds value to an existing registry called ack and nack Attribute Values and this what the IANA section says " This document instructs IANA to add two values in "ack" and "nack" > Attribute Values registry for use with "nack"[RFC4585 ]:" > > > It is defined in RFC 4584 see below. > > For use with both "ack" and "nack", a joint sub-registry has been set > > up that initially registers the following values: > > Initial value registration for the attribute values "ack" and "nack": > > Value name: sli > > Long name: Slice Loss Indication > > Usable with: nack > > Reference: RFC 4585. > > Value name: pli > > Long name: Picture Loss Indication > > Usable with: nack > > Reference: RFC 4585. > > Value name: rpsi > > Long name: Reference Picture Selection Indication > > Usable with: ack, nack > > Reference: RFC 4585. > > Value name: app > > Long name: Application layer feedback > > Usable with: ack, nack > > Reference: RFC 4585. > > Further entries may be registered on a first-come first-serve basis. > > Each registration needs to indicate the parameter name, the syntax of > > possible additional arguments, and whether the parameter is > > applicable to "ack" or "nack" feedback or both or some different > > "rtcp-fb" attribute parameter. For each new registration, it is > > mandatory that a permanent, stable, and publicly accessible document > > exists that specifies the semantics of the registered parameter, the > > syntax and semantics of its parameters as well as corresponding > > feedback packet formats (if needed). The general registration > > procedures of [3] apply. > > Roni Even > > *From:*avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] *On Behalf > Of *Robert Sparks > *Sent:* Monday, March 05, 2012 7:01 PM > *To:* Qin Wu > *Cc:* draft-ietf-avtcore-feedback-suppression-rtp@tools.ietf.org; > avtcore-chairs@tools.ietf.org; avt@ietf.org > *Subject:* [AVTCORE] draft-ietf-avtcore-feedback-supression-rtp-14 > (was Re: AD review: draft-ietf-avtcore-feedback-suppression-rtp-13) > > Hi Qin - > > Version 14 still has some issues. > > I'm confused about the changes made to address Item 1), and it looks > like Magnus still has questions > about that too. Please resolve that by replying to Magnus' message. > > The first part of the IANA registration section is still unclear. From > your response below, I gather you > are trying to create a new registry instead of trying to put values in > an existing registry, but your proposed > text still looks like it's trying to add a value to some table that > already exists. > > Where are you expecting IANA to put this new registry? Are you > expecting it to be a subregistry of > the RTP Parameters registry? If so, say so, and provide a name for the > registry. You also need to > provide a policy for adding other values. See RFC5226 section 4.2. > > That said, why are you trying to put these in a registry in the first > place? Looking at the document, > it seems that you are only wanting to make these be standardized > strings that can appear in > the production of an SDP rtcp-fb-nack-param line. You've done that > with the grammar defined in this > document. > > I don't see any change in this revision to address the following comment: > > On 3/1/12 10:52 PM, Qin Wu wrote: > > > > > > 5) At the end of section 3, the document says messages SHOULD be > suppressed "for a period of time". Can that be made more precise? > > [Qin]: Sorry, I forgot to clear that nits in the previous version. Since we follow > > the feedback suppression rule we defined in RFC4585, I think the receivers > > should suppress the further feedback for the same packet loss. Therefore I like > > to remove "for a period of time". --------------000908040007060906090206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yep - caught that already and suggested text that should be easier for IANA.

On 3/5/12 12:24 PM, Roni Even wrote:

Hi Robert,

The IANA registration adds value to an existing registry called ack and nack Attribute Values and this what the IANA section says " This document instructs IANA to add two values in "ack" and "nack"
   Attribute Values registry for use with "nack"[RFC4585]:"
 

 

It is defined in RFC 4584 see below.

 

For use with both "ack" and "nack", a joint sub-registry has been set

   up that initially registers the following values:

 

   Initial value registration for the attribute values "ack" and "nack":

 

     Value name:     sli

     Long name:      Slice Loss Indication

     Usable with:    nack

     Reference:      RFC 4585.

 

     Value name:     pli

     Long name:      Picture Loss Indication

     Usable with:    nack

     Reference:      RFC 4585.

 

     Value name:     rpsi

     Long name:      Reference Picture Selection Indication

     Usable with:    ack, nack

     Reference:      RFC 4585.

 

     Value name:     app

     Long name:      Application layer feedback

     Usable with:    ack, nack

     Reference:      RFC 4585.

 

   Further entries may be registered on a first-come first-serve basis.

   Each registration needs to indicate the parameter name, the syntax of

   possible additional arguments, and whether the parameter is

   applicable to "ack" or "nack" feedback or both or some different

   "rtcp-fb" attribute parameter.  For each new registration, it is

   mandatory that a permanent, stable, and publicly accessible document

   exists that specifies the semantics of the registered parameter, the

   syntax and semantics of its parameters as well as corresponding

   feedback packet formats (if needed).  The general registration

   procedures of [3] apply.

 

Roni Even

 

 

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Robert Sparks
Sent: Monday, March 05, 2012 7:01 PM
To: Qin Wu
Cc: draft-ietf-avtcore-feedback-suppression-rtp@tools.ietf.org; avtcore-chairs@tools.ietf.org; avt@ietf.org
Subject: [AVTCORE] draft-ietf-avtcore-feedback-supression-rtp-14 (was Re: AD review: draft-ietf-avtcore-feedback-suppression-rtp-13)

 

Hi Qin -

Version 14 still has some issues.

I'm confused about the changes made to address Item 1), and it looks like Magnus still has questions
about that too. Please resolve that by replying to Magnus' message.

The first part of the IANA registration section is still unclear. From your response below, I gather you
are trying to create a new registry instead of trying to put values in an existing registry, but your proposed
text still looks like it's trying to add a value to some table that already exists.

Where are you expecting IANA to put this new registry? Are you expecting it to be a subregistry of
the RTP Parameters registry? If so, say so, and provide a name for the registry. You also need to
provide a policy for adding other values. See RFC5226 section 4.2.

That said, why are you trying to put these in a registry in the first place?  Looking at the document,
it seems that you are only wanting to make these be standardized strings that can appear in
the production of an SDP rtcp-fb-nack-param line. You've done that with the grammar defined in this
document.

I don't see any change in this revision to address the following comment:

On 3/1/12 10:52 PM, Qin Wu wrote:

<snip/>



5) At the end of section 3, the document says messages SHOULD be 
suppressed "for a period of time". Can that be made more precise?
 
[Qin]: Sorry, I forgot to clear that nits in the previous version. Since we follow
 
 the feedback suppression rule we defined in RFC4585, I think the receivers 
 
should suppress the further feedback for the same packet loss. Therefore I like
 
 to remove "for a period of time".
--------------000908040007060906090206-- From JA.Berryman@us.bosch.com Mon Mar 5 13:40:32 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EEC21F8864 for ; Mon, 5 Mar 2012 13:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.292 X-Spam-Level: X-Spam-Status: No, score=-7.292 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3Pz8vz3ilkS for ; Mon, 5 Mar 2012 13:40:30 -0800 (PST) Received: from smtp2-v.fe.bosch.de (smtp2-v.fe.bosch.de [139.15.237.6]) by ietfa.amsl.com (Postfix) with ESMTP id 18B7221F881F for ; Mon, 5 Mar 2012 13:40:30 -0800 (PST) Received: from vsmta12.fe.internet.bosch.com (unknown [10.4.98.30]) by imta23.fe.bosch.de (Postfix) with ESMTP id 13FB95820799; Mon, 5 Mar 2012 22:40:29 +0100 (CET) Received: from localhost (vsgw1.fe.internet.bosch.com [10.4.98.15]) by vsmta12.fe.internet.bosch.com (Postfix) with SMTP id F1E21121049B; Mon, 5 Mar 2012 22:40:28 +0100 (CET) Received: from SI-MBX82.de.bosch.com ([10.3.153.131]) by si-hub06.de.bosch.com ([10.3.153.48]) with mapi; Mon, 5 Mar 2012 22:40:25 +0100 From: "Berryman Jeff (ST-CO/ENS-CA)" To: "avt@ietf.org" Date: Mon, 5 Mar 2012 22:40:22 +0100 Thread-Topic: Comments on draft-williams-avtcore-clksrc-00, "RTP Clock Source Signalling", 2012.02.28 Thread-Index: Acz7GJGVkEdPBiRKTTaWOKdN7t8JcA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_ADEC3923341B7F4AA99AFE50084F61993A78910DB6SIMBX82debosc_" MIME-Version: 1.0 Subject: [AVTCORE] Comments on draft-williams-avtcore-clksrc-00, "RTP Clock Source Signalling", 2012.02.28 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 21:40:32 -0000 --_004_ADEC3923341B7F4AA99AFE50084F61993A78910DB6SIMBX82debosc_ Content-Type: multipart/alternative; boundary="_000_ADEC3923341B7F4AA99AFE50084F61993A78910DB6SIMBX82debosc_" --_000_ADEC3923341B7F4AA99AFE50084F61993A78910DB6SIMBX82debosc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings Attached please find comments on draft-williams-avtcore-clksrc-00, 2012.02.= 28. Jeff Berryman Senior Scientist Bosch Security Systems Inc. Communications Systems Division 12000 Portland Avenue South Burnsville, Minnesota USA 55337 http://www.boschsecurity.us/ Tel +1 519 924 0105 Mobile +1 952 457 5445 Time zone GMT-5 (winter), GMT-4 (summer) ja.berryman@us.bosch.com --_000_ADEC3923341B7F4AA99AFE50084F61993A78910DB6SIMBX82debosc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings

Attached please find comments on draft-williams-avtcore-clksrc-00, 2012.02.28= .


Jeff Berryman

Senior Scientist
Bosch Security Systems Inc.
Communications Systems Division
12000 Portland Avenue South
Burnsville, Minnesota
USA 55337
http://www.boschsecurity.us/=

Tel          &nb= sp;    +1 519 924 0105
Mobile          +1 952 457 5445
Time zone     GMT-5 (winter), GMT-4 (summer)
ja.berryman@us.bosch.com=

&nb= sp;

--_000_ADEC3923341B7F4AA99AFE50084F61993A78910DB6SIMBX82debosc_-- --_004_ADEC3923341B7F4AA99AFE50084F61993A78910DB6SIMBX82debosc_ Content-Type: text/plain; name="draft-williams-avtcore-clksrc-00 - J Berryman comments .txt" Content-Description: draft-williams-avtcore-clksrc-00 - J Berryman comments .txt Content-Disposition: attachment; filename="draft-williams-avtcore-clksrc-00 - J Berryman comments .txt"; size=4220; creation-date="Sat, 03 Mar 2012 08:24:44 GMT"; modification-date="Mon, 05 Mar 2012 21:39:15 GMT" Content-Transfer-Encoding: base64 Q29tbWVudHMgb24gZHJhZnQtd2lsbGlhbXMtYXZ0Y29yZS1jbGtzcmMtMDAsIDIwMTIuMDIuMjgN Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 DQoNCmRhdGUgdHJhbnNtaXR0ZWQ6ICAgMjAxMi4wMy4wNSAoTW9uZGF5KQ0KDQpmcm9tOiAgIEpl ZmYgQmVycnltYW4NCiAgICAgICAgU2VuaW9yIFNjaWVudGlzdA0KICAgICAgICBCb3NjaCBTZWN1 cml0eSBTeXN0ZW1zIEluYy4NCiAgICAgICAgQ29tbXVuaWNhdGlvbnMgU3lzdGVtcyBEaXZpc2lv bg0KICAgICAgICAxMjAwMCBQb3J0bGFuZCBBdmVudWUgU291dGgNCiAgICAgICAgQnVybnN2aWxs ZSwgTWlubmVzb3RhDQogICAgICAgIFVTQSA1NTMzNw0KICAgICAgICBodHRwOi8vd3d3LmJvc2No c2VjdXJpdHkudXMvDQogICAgICAgIFRlbCAJKzEgNTE5IDkyNCAwMTA1DQogICAgICAgIE1vYmls ZSAJKzEgOTUyIDQ1NyA1NDQ1DQogICAgICAgIFRpbWUgem9uZSAJR01ULTUgKHdpbnRlciksIEdN VC00IChzdW1tZXIpDQogICAgICAgIGphLmJlcnJ5bWFuQHVzLmJvc2NoLmNvbQ0KDQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KDQogTC4gMTM4ICAgICBMYXN0IHdvcmQgaW4gbGluZSAiYSIgc2hvdWxkIGJlICJh biIuDQogDQogTC4gMTg4ICAgICAiTmV0d29rZWQiIHNob3VsZCBiZSAiTmV0d29ya2VkIi4NCiAN CiBMLiAxODgtMTk3IENyaXRpY2FsIHN5bmNocm9uaXNhdGlvbiByZXF1aXJlbWVudHMgYXJpc2Ug Zm9yIGxvdWRzcGVha2VycyANCiAgICAgICAgICAgIG11bHRpcGxlIGxvdWRzcGVha2VycyBzaGFy ZSB0aGUgc2FtZSBhY291c3RpYyBzcGFjZS4gIFRoZQ0KICAgICAgICAgICAgZnVuZGFtZW50YWwg cHJvYmxlbSBpcyB0byBjb250cm9sIHdhdmUgaW50ZXJmZXJlbmNlIGluIHN1Y2gNCiAgICAgICAg ICAgIGEgd2F5IGFzIHRvIG1pbmltaXplIGZyZXF1ZW5jeSByZXNwb25zZSBhbmQgZGlyZWN0aXZp dHkNCiAgICAgICAgICAgIGlycmVndWxhcml0aWVzLiBUaGUgYmlnIGRpZmZlcmVuY2UgYmV0d2Vl biBhdWRpbyBhbmQgdmlkZW8NCiAgICAgICAgICAgIGluIHRoaXMgcmVnYXJkIGlzIHBhcnRseSBw ZXJjZXB0dWFsLCBhcyB5b3Ugbm90ZSwgYnV0IGl0IGlzDQogICAgICAgICAgICBqdXN0IGFzIG11 Y2ggdGhlIGZhY3QgdGhhdCB2aWRlbyBpcyBsaWdodCB3YXZlcywgd2hpY2ggYXJlDQogICAgICAg ICAgICBpbmNvaGVyZW50bHkgc3VtbWVkLCB3aGlsZSBhdWRpbyBpcyBzb3VuZCB3YXZlcywgd2hp Y2ggYXJlDQogICAgICAgICAgICBjb2hlcmVudGx5IHN1bW1lZC4NCg0KICAgICAgICAgICAgQWxs IHRoaXMgc2FpZCwgSSBhbSBub3Qgd2FudGluZyB0aGlzIHBhcmFncmFwaCB0byB0dXJuIGludG8N CiAgICAgICAgICAgIGEgcGh5c2ljcyBsZXNzb24gIEhvdyBhYm91dCBzb21ldGhpbmcgbGlrZSB0 aGlzOg0KDQogICAgICAgICAgICAiTmV0d29ya2VkIGxvdWRzcGVha2VycywgYW1wbGlmaWVycywg bWljcm9waG9uZXMsIGFuZCBvdGhlcg0KICAgICAgICAgICAgZGV2aWNlcyB0cmFuc21pdHRpbmcg b3IgcmVjZWl2aW5nIGF1ZGlvIHNpZ25hbHMgY2FuIGJlDQogICAgICAgICAgICBpbnRlcmNvbm5l Y3RlZCB2aWEgUlRQLCBvdmVyIHNob3J0IG9yIGxvbmcgZGlzdGFuY2VzLiAgV2hlbg0KICAgICAg ICAgICAgdGhlIGludGVyY29ubmVjdGVkIGRldmljZXMgc2hhcmUgdGhlIHNhbWUgYWNvdXN0aWMg c3BhY2UsDQogICAgICAgICAgICBzdWNoIGFzIHdoZW4gbXVsdGlwbGUgbG91ZHNwZWFrZXJzIGFy ZSB1c2VkIHRvIHByb3ZpZGUgc291bmQNCiAgICAgICAgICAgIGZvciBhIGxhcmdlIHJvb20sIHN5 bmNocm9uaXphdGlvbiByZXF1aXJlbWVudHMgc2lnbmlmaWNhbnRseSBleGNlZWQNCiAgICAgICAg ICAgIHRob3NlIG9mIHZpZGVvLiAgSW4gb3JkZXIgdG8gbWFpbnRhaW4gcGhhc2UtYWNjdXJhdGUg c3VtbWF0aW9uIG9mDQogICAgICAgICAgICBtdWx0aXBsZSBhY291c3RpYyBzaWduYWxzIG92ZXIg dGhlIGZ1bGwgYXVkaW8gZnJlcXVlbmN5IHJhbmdlLA0KICAgICAgICAgICAgc3luY2hyb25pemF0 aW9uIGFjY3VyYWN5IG9mIGZpdmUgbWljcm9zZWNvbmRzIG9yIGxlc3MgY2FuIGJlDQogICAgICAg ICAgICByZXF1aXJlZC4iDQoNCkwuIDI1OSAgICAgIEkgYmVsaWV2ZSAidGFraW5nIiBzaG91bGQg YmUgInRha2VuIi4gIE9yIHBlcmhhcHMgaXQgbWlnaHQNCiAgICAgICAgICAgIG1vcmUgcHJlY2lz ZSB0byBzYXkgIlRoZSBOVFAgdGltZXN0YW1wIHZhbHVlcyB1c2VkIGJ5IFJUUA0KICAgICAgICAg ICAgYXJlIGFjcXVpcmVkIGJ5IHJlYWRpbmcgYSBsb2NhbCBjbG9jayAuLi4iDQoNCkwuIDI2NiAg ICAgIFN1Z2dlc3QgYWRkIGNvbW1hIGFmdGVyICJzaWduYWxsaW5nIi4NCg0KTC4gMjg4ICAgICAg SSB0aGluayB0aGUgd29yZCAicmVjZWl2ZXJzIiBuZWVkcyBkZWxldGlvbi4NCg0KTC4gMzAxICAg ICAgInRvIGV4cGxpY3RseSBpbmRpY2F0ZSIgLSBzcGxpdCBpbmZpbml0aXZlLiAgU2hvdWxkIGJl ICJ0bw0KICAgICAgICAgICAgaW5kaWNhdGUgZXhwbGljaXRseS4iICA8SSdtIGZ1c3N5LCBJIGtu b3c+DQoNCkwuIDMwNiAgICAgICJpcyBpZGVudGlmaWVkIGJ5IiAgaXMgcmVwbGljYXRlZC4NCg0K TC4gMzEwICAgICAgIi4uLnNlcnZlcnMgbWF5IGJlIGxpc3RlZC4uLiIuICBTb3JyeSBmb3IgbXkg aWdub3JhbmNlOiBsaXN0ZWQNCiAgICAgICAgICAgIHdoZXJlPw0KDQpMLiAzMjIgICAgICAicHJv dmlkZSIgc2hvdWxkIGJlICJwcm92aWRlcyIgKHN1YmplY3QgaXMgImZhbWlseSIpLg0KDQpMLiAz NjggICAgICBTdWdnZXN0IGFkZGluZyBjb21tYSBhZnRlciAiZG9tYWlucyIuDQoNCkwuIDM3MSAg ICAgIFN1Z2dlc3QgY2hhbmdpbmcgImFuZCIgdG8gImJ1dCIsIGFuZCBhZGRpbmcgYSBjb21tYSBh ZnRlciAibmFtZSIuDQoNCkwuIDM3MyAgICAgIFN1Z2dlc3QgYmVnaW5uaW5nIGEgbmV3IHBhcmFn cmFwaCBmcm9tICJUaGlzIHNwZWNpZmljYXRpb24iLg0KDQpMLiAzODAgICAgICBFaXRoZXIgZGVs ZXRlICJmYW1pbHkgb2YiIG9yIGNoYW5nZSAiZW1wbG95IiB0byAiZW1wbG95cyIuDQoNCkwuIDM4 MSAgICAgIEFkZCBjbG9zaW5nIGRvdWJsZXF1b3RlIGFmdGVyICJBbGdvcml0aG0iLg0KDQpMLiAz ODQgICAgICAicHJlZmZlcnJlZCIgc2hvdWxkIGJlICJwcmVmZXJyZWQiLg0KDQpMLiAzOTggICAg ICAidHJhY2FibGUiIHNob3VsZCBiZSAidHJhY2VhYmxlIi4NCg0KTC4gNDAwICAgICAgIkdhbGxp bGVvIiBzaG91bGQgYmUgIkdhbGlsZW8iLCB1bmxlc3MgdGhpcyBpcyBhIHRyaWNrIHNwZWxsaW5n Lg0KDQpMLiA0MDYgICAgICAiY2xvY2siIHNob3VsZCBiZSAiY2xvY2tzIiAodG8gcGFyYWxsZWwg cGx1cmFsIGluICJzZW5kZXJzL3JlY2VpdmVycyIpLg0KDQpMLiA0MTAgICAgICAidGltZXRzYW1w IiAtPj4gInRpbWVzdGFtcCINCg0KTC4gNDMwICAgICAgTWlnaHQgYmUgY2xlYXJlIHRvIHNheSAi U2luY2UgYWxsIE5UUCBhbmQgUFRQIHNlcnZlcnMNCiAgICAgICAgICAgIHByb3ZpZGluZyB0cmFj ZWFibGUgdGltZSBjYW4gYmUgY29uc2lkZXJlZCBlcXVpdmFsZW50LCAuLi4iDQoNCkwuIDQzNiAg ICAgIFdoYXQgZG9lcyBpdCBtZWFuIHRvIHNheSB0aGF0IGEgX3Byb3RvY29sXyBleGNoYW5nZXMg YSBtZXNzYWdlPw0KICAgICAgICAgICAgU2hvdWxkIHRoaXMgbGluZSBzYXkgInRpbWUgcHJvdG9j b2wgaW1wbGVtZW50YXRpb25zIiwgb3INCiAgICAgICAgICAgICJ0aW1lIHByb3RvY29sIHNlcnZp Y2VzIiwgb3Igc29tZXRoaW5nIGxpa2UgdGhhdD8NCg0KTC4gNDc2ICAgICAgU2hvdWxkIHRoaXMg cmVhZCAiLi4uIGNsb2NrIHNvdXJjZSBtYXkgYmUgZ2l2ZW4gYXQgYWxsIC4uLiIgPw0KDQpMLiA1 MTRmZiAgICBGb3Igc21vb3RoIHJlYWRpbmcsIGEgcHJlcGFyYXRvcnkgcmVmZXJlbmNlIHRvIEZp Z3VyZSAxIHdvdWxkIGJlDQogICAgICAgICAgICBoZWxwZnVsIGhlcmUuDQoNCkwuIDcyMi03MzUg IEkgY2FuJ3QgcGFyc2UgdGhlIHRleHQgaW4gdGhlc2UgbGluZXMuICBJcyBzb21ldGhpbmcgbWlz c2luZz8NCg0KTC4gNzcwZmYgICAgS2V2aW4ncyBjb250YWN0IGluZm9ybWF0aW9uIGlzIG1pc3Np bmcuDQoNCg0KDQoNCg0KDQoNCiAgICAgICAgICAgIA0KDQogICAgICAgICAgICANCiAgICAgICAg DQo= --_004_ADEC3923341B7F4AA99AFE50084F61993A78910DB6SIMBX82debosc_-- From csp@csperkins.org Mon Mar 5 15:32:55 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF8021E803C for ; Mon, 5 Mar 2012 15:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 waK046Lb-TqY for ; Mon, 5 Mar 2012 15:32:50 -0800 (PST) Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by ietfa.amsl.com (Postfix) with ESMTP id 61F1821E8049 for ; Mon, 5 Mar 2012 15:32:50 -0800 (PST) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.30]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1S4hOb-0006Pe-mu; Mon, 05 Mar 2012 23:32:49 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Colin Perkins Date: Mon, 5 Mar 2012 23:32:47 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <766FE318-7DE3-4481-B3C4-C45F2A94C881@csperkins.org> References: <20120305201759.24406.49431.idtracker@ietfa.amsl.com> To: rtp-congestion@alvestrand.no X-Mailer: Apple Mail (2.1257) Cc: "avt@ietf.org WG" Subject: [AVTCORE] Fwd: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 23:32:55 -0000 Here's our initial attempt at a "circuit breakers" draft for RTCWeb. = Comments welcome - this is very much a straw-man for discussion, rather = than a final solution. Colin Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt > Date: 5 March 2012 20:17:59 GMT > To: i-d-announce@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : RTP Congestion Control: Circuit Breakers for = Unicast Sessions > Author(s) : Colin Perkins > Varun Singh > Filename : = draft-perkins-avtcore-rtp-circuit-breakers-00.txt > Pages : 14 > Date : 2012-03-05 >=20 > The Real-time Transport Protocol (RTP) is widely used for telephony, > video conferencing, and telepresence applications. These > applications are often used over best-effort UDP/IP networks. If > congestion control is not implemented then network congestion will > deteriorate the user's multimedia experience. This document does = not > propose a congestion control algorithm. Instead, it specifies a > minimal set of "circuit-breakers". Circuit-breakers are conditions > under which an RTP flow should cease to transmit media to protect = the > network from excessive congestion. It is expected that all RTP > applications running on best-effort networks will be able to run > without triggering these circuit breakers in normal operation. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-brea= kers-00.txt --=20 Colin Perkins http://csperkins.org/ From bill.wu@huawei.com Mon Mar 5 19:47:01 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9988221F86A5 for ; Mon, 5 Mar 2012 19:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.485 X-Spam-Level: X-Spam-Status: No, score=-5.485 tagged_above=-999 required=5 tests=[AWL=1.114, 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 kWNFoI8HRynJ for ; Mon, 5 Mar 2012 19:47:01 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7C121F86A0 for ; Mon, 5 Mar 2012 19:47:00 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0G00G582GGOF@szxga05-in.huawei.com> for avt@ietf.org; Tue, 06 Mar 2012 11:45:53 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0G00EBA2GGKY@szxga05-in.huawei.com> for avt@ietf.org; Tue, 06 Mar 2012 11:45:52 +0800 (CST) Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHP52919; Tue, 06 Mar 2012 11:45:52 +0800 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 06 Mar 2012 11:45:11 +0800 Received: from w53375 (10.138.41.149) by SZXEML414-HUB.china.huawei.com (10.82.67.153) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 06 Mar 2012 11:45:50 +0800 Date: Tue, 06 Mar 2012 11:45:49 +0800 From: Qin Wu X-Originating-IP: [10.138.41.149] To: Magnus Westerlund , "Van Caenegem, Tom (Tom)" Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <4F4FF7C1.6040501@nostrum.com> <93213B506E254BE7941B02E9630EAB00@china.huawei.com> <4F548F59.8020603@ericsson.com> Cc: draft-ietf-avtcore-feedback-suppression-rtp@tools.ietf.org, avtcore-chairs@tools.ietf.org, avt@ietf.org Subject: Re: [AVTCORE] AD review:draft-ietf-avtcore-feedback-suppression-rtp-13 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 03:47:01 -0000 SGksIE1hZ251czoNClRoYW5rIGZvciB5b3VyIHZhbHVhYmxlIGNvbW1lbnRzLiBQbGVhc2Ugc2Vl IG15IHJlcGxpZXMgaW5saW5lIGJlbG93Lg0KDQpSZWdhcmRzIQ0KLVFpbg0KLS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJNYWdudXMgV2VzdGVybHVuZCIgPG1hZ251cy53ZXN0 ZXJsdW5kQGVyaWNzc29uLmNvbT4NClRvOiAiVmFuIENhZW5lZ2VtLCBUb20gKFRvbSkiIDx0b20u dmFuX2NhZW5lZ2VtQGFsY2F0ZWwtbHVjZW50LmNvbT4NCkNjOiA8YXZ0QGlldGYub3JnPjsgPGRy YWZ0LWlldGYtYXZ0Y29yZS1mZWVkYmFjay1zdXBwcmVzc2lvbi1ydHBAdG9vbHMuaWV0Zi5vcmc+ OyA8YXZ0Y29yZS1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQpTZW50OiBNb25kYXksIE1hcmNoIDA1 LCAyMDEyIDY6MDMgUE0NClN1YmplY3Q6IFJlOiBbQVZUQ09SRV0gQUQgcmV2aWV3OmRyYWZ0LWll dGYtYXZ0Y29yZS1mZWVkYmFjay1zdXBwcmVzc2lvbi1ydHAtMTMNCg0KDQo+IEhpLA0KPiANCj4g QWdyZWUgdGhhdCB0aGVyZSBzaG91bGQgYmUgbm8gZGlmZmVyZW5jZSBiZXR3ZWVuIGF1dGhlbnRp Y2F0ZWQgYW5kDQo+IG5vbi1hdXRoZW50aWNhdGVkIG1lc3NhZ2VzLg0KPiANCj4gSSBzdGlsbCBk b24ndCB0aGluayB5b3UgaGF2ZSByZXNvbHZlZCB0aGUgaXNzdWUgdGhhdCBSb2JlcnQgcG9pbnRl ZCBvdXQ6DQo+PiAxKSBTZWN0aW9uIDMsIHBhcmFncmFwaCAzLCBzYXlzIGEgcmVjZWl2ZXIgTVVT VCBmb2xsb3cgdGhlIHJ1bGVzIGZvciANCj4+IE5BQ0sgc3VwcHJlc3Npb24gb24gcmVjZWlwdCBv ZiBhIHRoaXJkIHBhcnRseSBsb3NzIHJlcG9ydC4gU2VjdGlvbiA0IA0KPj4gc2F5cyByZWNlaXZl cnMgTUFZIGlnbm9yZSB0aGlyZCBwYXJ0eSBsb3N0IHJlcG9ydHMsIGFuZCB0aGVuIGNvbmZ1c2lu Z2x5IA0KPj4gc2F5cyB0aGUgU0hPVUxEIG5vdCBpZ25vcmUgdGhlbS4gVGhlIHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zIHNlY3Rpb24gDQo+PiBzYXlzIHRoYXQgcmVjZWl2ZXJzIHdvdWxkIGJlICJ3 ZWxsIGFkdmlzZWQgdG8gaWdub3JlIiAoZWZmZWN0aXZlbHkgDQo+PiBTSE9VTEQgaWdub3JlKSB0 aGlyZCBwYXJ0eSByZXBvcnRzIHVubGVzcyB0aGV5IGFyZSBhdXRoZW50aWNhdGVkLiBUaGlzIA0K Pj4gbmVlZHMgdG8gYmUgcmVjb25jaWxlZC4NCj4+IA0KPj4gQXJlIHlvdSB0cnlpbmcgdG8gc2F5 IHRoZSBmb2xsb3dpbmc/DQo+PiANCj4+ICAgICAqKSBNVVNUIGZvbGxvdyB0aGUgc3VwcHJlc3Np b24gcnVsZXMgaWYgcGFja2V0cyBhcmUgYXV0aGVudGljYXRlZA0KPj4gICAgICopIFNIT1VMRCBO T1QgZm9sbG93IHRoZSBzdXBwcmVzc2lvbiBydWxlcyBpZiB0aGUgcGFja2V0cyBhcmUgbm90IA0K Pj4gYXV0aGVudGljYXRlZA0KPj4gDQo+PiBPciBzb21ldGhpbmcgZWxzZT8gRWl0aGVyIHdheSwg cGxlYXNlIG1ha2UgdGhlIGRvY3VtZW50IGludGVybmFsbHkgDQo+PiBjb25zaXN0ZW50Lg0KPiAN Cj4gTXkgaW1wcmVzc2lvbiBpcyB0aGF0IHRoZSBwYXJhZ3JhcGggMyBpcyBhYm91dCB0aGUgUkZD NDU4NSBiYXNlZA0KPiBzdXBwcmVzc2lvbiBvZiBzZW5kaW5nIGFkZGl0aW9uYWwgUlRDUCBtZXNz YWdlIHdpdGggdGhlIHNhbWUgbWVhbmluZy4NCj4gDQo+IFRoZSB0ZXh0IGluIGluIHNlY3Rpb24g NCBpcyB0aGF0IHVwb24gcmVjZWl2aW5nIGEgVFBMUiBtZXNzYWdlIGENCj4gcmVjZWl2ZXIgY2Fu IHRyZWF0IGl0IGFzIGFuIGluZGljYXRpb24gYW5kIGNob3NlIHRvIGRpc3JlZ2FyZCBpdC4NCj4g SG93ZXZlciwgdGhlIGNyaXRlcmlhIGlzIHZhZ3VlLiBJIGFsc28gdGhpbmsgdGhlIGZvcm11bGF0 aW9uIG9mIHVzaW5nDQo+IE1BWSBwbHVzIHNob3VsZCBjb3VsZCBqdXN0IGFzIHdlbGwgYmUgcmVw bGFjZWQgYnkgYSBTSE9VTEQgZm9ybXVsYXRpb24sDQo+IGxpa2U6IFJlY2VpdmVycyBTSE9VTEQg cmVhY3QgdG8gVFBMUiBtZXNzYWdlcyB1bmxlc3MgLi4uLg0KPiANCj4gV2hhdCBkb2VzIG90aGVy IHNheT8NCg0KW1Fpbl06IEkgYWdyZWUgd2l0aCB5b3VyIHByb3Bvc2VkIGNoYW5nZS4NCmFuZCBJ IGhhdmUgYSBmdXJ0aGVyIHRoaW5raW5nLCB0aGF0IGlzIHRvIHNheToNCg0KRG8gd2UgaGF2ZSBn b29kIHJlYXNvbnMgZm9yIHJlY2VpdmVycyB0byB0byBzdGlsbCBzZW5kDQpmZWVkYmFjayBtZXNz YWdlcyBkZXNwaXRlIGhhdmluZyBiZWVuIHJlcXVlc3RlZCB0byBzdXBwcmVzcyB0aGVtPw0KDQpJ ZiB0aGUgYW53ZXIgaXMgbm8sIEkgdGhpbmsgYW5vdGhlciBzdHJhaWdodGZvcndhcmQgd2F5IHRv IGZpeCB0aGlzIGlzc3VlIGlzIGp1c3QgcmVtb3ZlIHRoZSBsYXN0IHNlbnRlbmNlDQppbiB0aGUg cGFyYWdyYXBoIDEgb2Ygc2VjdGlvbiA0Lg0KDQpNYWdudXMsIHdoYXQgZG8geW91IHRoaW5rIG9m IHRoaXM/DQoNCj4gDQo+IFdlIHN0aWxsIG5lZWQgYW4gdXBkYXRlZCB2ZXJzaW9uIHByaW9yIHRv IElFVEYgTEMuDQo+IA0KPiBDaGVlcnMNCj4gDQo+IE1hZ251cyBXZXN0ZXJsdW5kDQo+IA0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+IE11bHRpbWVkaWEgVGVjaG5vbG9naWVzLCBFcmljc3NvbiBSZXNlYXJj aCBFQUIvVFZNDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRXJpY3Nzb24gQUIgICAgICAgICAgICAgICAg fCBQaG9uZSAgKzQ2IDEwIDcxNDgyODcNCj4gRsOkcsO2Z2F0YW4gNiAgICAgICAgICAgICAgICB8 IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KPiBTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW58IG1h aWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEF1 ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQo+IGF2dEBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dA0KPg== From bill.wu@huawei.com Mon Mar 5 21:08:10 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 547B421E809B for ; Mon, 5 Mar 2012 21:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.756 X-Spam-Level: X-Spam-Status: No, score=-4.756 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_34=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 9x3n18ZrW-mE for ; Mon, 5 Mar 2012 21:08:09 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id C3F6621E8086 for ; Mon, 5 Mar 2012 21:08:08 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0G00MXI67W3D@szxga03-in.huawei.com> for avt@ietf.org; Tue, 06 Mar 2012 13:07:08 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0G00MRX67WRT@szxga03-in.huawei.com> for avt@ietf.org; Tue, 06 Mar 2012 13:07:08 +0800 (CST) Received: from szxeml210-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHG45305; Tue, 06 Mar 2012 13:06:33 +0800 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 06 Mar 2012 13:06:03 +0800 Received: from w53375 (10.138.41.149) by szxeml408-hub.china.huawei.com (10.82.67.95) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 06 Mar 2012 13:06:30 +0800 Date: Tue, 06 Mar 2012 13:06:29 +0800 From: Qin Wu X-Originating-IP: [10.138.41.149] To: Robert Sparks Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: multipart/alternative; boundary="Boundary_(ID_M+CF2yB1XMniC3e05lVfWw)" X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <4F4FF7C1.6040501@nostrum.com> <93213B506E254BE7941B02E9630EAB00@china.huawei.com> <4F54F162.5010608@nostrum.com> Cc: draft-ietf-avtcore-feedback-suppression-rtp@tools.ietf.org, avtcore-chairs@tools.ietf.org, avt@ietf.org Subject: Re: [AVTCORE] draft-ietf-avtcore-feedback-supression-rtp-14 (was Re: AD review: draft-ietf-avtcore-feedback-suppression-rtp-13) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 05:08:10 -0000 --Boundary_(ID_M+CF2yB1XMniC3e05lVfWw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, Robert: Thanks for your feedback. please see my replies inline below. Regards! -Qin ----- Original Message ----- From: Robert Sparks To: Qin Wu Cc: avt@ietf.org ; avtcore-chairs@tools.ietf.org ; draft-ietf-avtcore-feedback-suppression-rtp@tools.ietf.org ; Gonzalo Camarillo Sent: Tuesday, March 06, 2012 1:01 AM Subject: draft-ietf-avtcore-feedback-supression-rtp-14 (was Re: [AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-rtp-13) Hi Qin - Version 14 still has some issues. I'm confused about the changes made to address Item 1), >> 1) Section 3, paragraph 3, says a receiver MUST follow the rules for >> NACK suppression on receipt of a third partly loss report. Section 4 >> says receivers MAY ignore third party lost reports, and then confusingly >> says the SHOULD not ignore them. The security considerations section >> says that receivers would be "well advised to ignore" (effectively >> SHOULD ignore) third party reports unless they are authenticated. This >> needs to be reconciled. [Qin]: Just for clarification.as you said, the text in section 3,4 and security sections seems to lack consistency. I agree that section 3 and section 4 does lack consistency since according to RFC4585 feedback suppression rule, the receiver should not ignore any feedback message including TPLR. To fix this issue, my proposed change is to remove the last sentence in the 1st paragraph of section 4 or use Magnus's proposed change. Regarding the consistency between section 3,4 and Security section you pointed out. I think section 3.4 and Security consideration section emphasize different thing. Section 3,4 emphasize TPLR MUST follow the same RFC4585 suppresion rule for NACK while security section more emphasize that the feedback message must be sent from authenticated feedback sender. I think this security rule should apply to all the feedback messages. Does this Clarify? and it looks like Magnus still has questions about that too. Please resolve that by replying to Magnus' message. [Qin]: Okay and have replied to Magnus in a separate message. >The first part of the IANA registration section is still unclear. From your response below, I gather you >are trying to create a new registry instead of trying to put values in an existing registry, but your proposed >text still looks like it's trying to add a value to some table that already exists. [Qin]: Yes. >Where are you expecting IANA to put this new registry? Are you expecting it to be a subregistry of >the RTP Parameters registry? If so, say so, and provide a name for the registry. You also need to >provide a policy for adding other values. See RFC5226 section 4.2. [Qin]: Yes,this should be put in the ack and nack Attribute Values registry available at: http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml. As described in RFC4585, policy rule should be based on a first-come first-serve. >That said, why are you trying to put these in a registry in the first place? Looking at the document, >it seems that you are only wanting to make these be standardized strings that can appear in >the production of an SDP rtcp-fb-nack-param line. You've done that with the grammar defined in this >document. [Qin]: That's not enough. RFC4585 has already assigned 4 initial values for for the attribute values "ack". This document intends to assign two more new value for the attribute values "ack". >I don't see any change in this revision to address the following comment: [Qin]: Sorry, I forgot to incorporate the change and will fix this in the update. >On 3/1/12 10:52 PM, Qin Wu wrote: > 5) At the end of section 3, the document says messages SHOULD be suppressed "for a period of time". Can that be made more precise? [Qin]: Sorry, I forgot to clear that nits in the previous version. Since we follow the feedback suppression rule we defined in RFC4585, I think the receivers should suppress the further feedback for the same packet loss. Therefore I like to remove "for a period of time". --Boundary_(ID_M+CF2yB1XMniC3e05lVfWw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi, Robert:
Thanks for your feedback. please see my replies inline below.
 
Regards!
-Qin
----- Original Message -----
To: Qin Wu
Sent: Tuesday, March 06, 2012 1:01 AM
Subject: draft-ietf-avtcore-feedback-supression-rtp-14 (was Re: [AVTCORE] AD review: draft-ietf-avtcore-feedback-suppression-rtp-13)

Hi Qin -

Version 14 still has some issues.

I'm confused about the changes made to address Item 1),
>> 1) Section 3, paragraph 3, says a receiver MUST follow the rules for
>> NACK suppression on receipt of a third partly loss report. Section 4
>> says receivers MAY ignore third party lost reports, and then confusingly
>> says the SHOULD not ignore them. The security considerations section
>> says that receivers would be "well advised to ignore" (effectively
>> SHOULD ignore) third party reports unless they are authenticated. This
>> needs to be reconciled.
[Qin]: Just for clarification.as you said, the text in section 3,4 and security sections seems to lack consistency.
I agree that section 3 and section 4 does lack consistency since according to RFC4585 feedback suppression rule,
the receiver should not ignore any feedback message including TPLR.
To fix this issue, my proposed change is to remove the last sentence in the 1st paragraph of section 4
or use Magnus's proposed change.
 
Regarding the consistency between section 3,4 and Security section you pointed out. I think section 3.4 and Security consideration
section emphasize different thing. Section 3,4 emphasize TPLR MUST follow the same RFC4585 suppresion rule for NACK
while security section more emphasize that the feedback message must be sent from authenticated feedback sender. I think
this security rule should apply to all the feedback messages.
 
Does this Clarify?
 
and it looks like Magnus still has questions
about that too. Please resolve that by replying to Magnus' message.
[Qin]: Okay and have replied to Magnus in a separate message.
 
>The first part of the IANA registration section is still unclear. From your response below, I gather you
>are trying to create a new registry instead of trying to put values in an existing registry, but your proposed
>text still looks like it's trying to add a value to some table that already exists.
 
[Qin]: Yes.

>Where are you expecting IANA to put this new registry? Are you expecting it to be a subregistry of
>the RTP Parameters registry? If so, say so, and provide a name for the registry. You also need to
>provide a policy for adding other values. See RFC5226 section 4.2.
 
[Qin]: Yes,this should be put in the ack and nack Attribute Values registry available at:
As described in RFC4585, policy rule should be based on a first-come first-serve.

>That said, why are you trying to put these in a registry in the first place?  Looking at the document,
>it seems that you are only wanting to make these be standardized strings that can appear in
>the production of an SDP rtcp-fb-nack-param line. You've done that with the grammar defined in this
>document.
 
[Qin]: That's not enough. RFC4585 has already assigned 4 initial values for for the attribute values "ack".
This document intends to assign two more new value for the attribute values "ack".

>I don't see any change in this revision to address the following comment:
 
[Qin]: Sorry, I forgot to incorporate the change and will fix this in the update.

>On 3/1/12 10:52 PM, Qin Wu wrote:

><snip/>

5) At the end of section 3, the document says messages SHOULD be 
suppressed "for a period of time". Can that be made more precise?

[Qin]: Sorry, I forgot to clear that nits in the previous version. Since we follow

 the feedback suppression rule we defined in RFC4585, I think the receivers 

should suppress the further feedback for the same packet loss. Therefore I like

 to remove "for a period of time".
--Boundary_(ID_M+CF2yB1XMniC3e05lVfWw)-- From bill.wu@huawei.com Mon Mar 5 21:09:03 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA26621E8086 for ; Mon, 5 Mar 2012 21:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.061 X-Spam-Level: X-Spam-Status: No, score=-5.061 tagged_above=-999 required=5 tests=[AWL=0.653, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 3SKlwJKswtQo for ; Mon, 5 Mar 2012 21:09:03 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id B209E21E809B for ; Mon, 5 Mar 2012 21:09:02 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0G00CS26AK2N@szxga03-in.huawei.com> for avt@ietf.org; Tue, 06 Mar 2012 13:08:44 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0G00EI76AJ5Q@szxga03-in.huawei.com> for avt@ietf.org; Tue, 06 Mar 2012 13:08:44 +0800 (CST) Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHP58094; Tue, 06 Mar 2012 13:08:16 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 06 Mar 2012 13:07:39 +0800 Received: from w53375 (10.138.41.149) by szxeml405-hub.china.huawei.com (10.82.67.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 06 Mar 2012 13:08:13 +0800 Date: Tue, 06 Mar 2012 13:08:12 +0800 From: Qin Wu X-Originating-IP: [10.138.41.149] To: Robert Sparks Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: multipart/alternative; boundary="Boundary_(ID_pIpWeujI7nUrEXufGP9/8A)" X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <4F4FF7C1.6040501@nostrum.com> <93213B506E254BE7941B02E9630EAB00@china.huawei.com> <4F54F162.5010608@nostrum.com> <4F55042F.9050606@nostrum.com> Cc: avtcore-chairs@tools.ietf.org, avt@ietf.org, draft-ietf-avtcore-feedback-supression-rtp@tools.ietf.org Subject: Re: [AVTCORE] draft-ietf-avtcore-feedback-supression-rtp-14 (was Re: AD review: draft-ietf-avtcore-feedback-suppression-rtp-13) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 05:09:04 -0000 --Boundary_(ID_pIpWeujI7nUrEXufGP9/8A) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi,Robert: I will follow your suggested change. Thanks. Regards! -Qin ----- Original Message ----- From: Robert Sparks To: Qin Wu Cc: draft-ietf-avtcore-feedback-supression-rtp@tools.ietf.org ; avtcore-chairs@tools.ietf.org ; avt@ietf.org Sent: Tuesday, March 06, 2012 2:21 AM Subject: Re: [AVTCORE] draft-ietf-avtcore-feedback-supression-rtp-14 (was Re: AD review: draft-ietf-avtcore-feedback-suppression-rtp-13) Inline On 3/5/12 11:01 AM, Robert Sparks wrote: Hi Qin - Version 14 still has some issues. I'm confused about the changes made to address Item 1), and it looks like Magnus still has questions about that too. Please resolve that by replying to Magnus' message. The first part of the IANA registration section is still unclear. From your response below, I gather you are trying to create a new registry instead of trying to put values in an existing registry, but your proposed text still looks like it's trying to add a value to some table that already exists. Where are you expecting IANA to put this new registry? Are you expecting it to be a subregistry of the RTP Parameters registry? If so, say so, and provide a name for the registry. You also need to provide a policy for adding other values. See RFC5226 section 4.2. That said, why are you trying to put these in a registry in the first place? Looking at the document, it seems that you are only wanting to make these be standardized strings that can appear in the production of an SDP rtcp-fb-nack-param line. You've done that with the grammar defined in this document. Ah - that thought should have answered my question by itself instantly. You are trying to put these values in this registry The text you added for -14 is close - I suggest this change: OLD: This document instructs IANA to add two values in "ack" and "nack" Attribute Values registry for use with "nack"[RFC4585]: NEW: This document instructs IANA to add two values to the '"ack" and "nack" Attribute Values' sub-registry [RFC4585] of the 'Session Description Protocol (SDP) Parameters' registry. I don't see any change in this revision to address the following comment: On 3/1/12 10:52 PM, Qin Wu wrote: 5) At the end of section 3, the document says messages SHOULD be suppressed "for a period of time". Can that be made more precise? [Qin]: Sorry, I forgot to clear that nits in the previous version. Since we follow the feedback suppression rule we defined in RFC4585, I think the receivers should suppress the further feedback for the same packet loss. Therefore I like to remove "for a period of time". _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --Boundary_(ID_pIpWeujI7nUrEXufGP9/8A) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi,Robert:
I will follow your suggested change. Thanks.
 
Regards!
-Qin
----- Original Message -----
To: Qin Wu
Sent: Tuesday, March 06, 2012 2:21 AM
Subject: Re: [AVTCORE] draft-ietf-avtcore-feedback-supression-rtp-14 (was Re: AD review: draft-ietf-avtcore-feedback-suppression-rtp-13)

Inline

On 3/5/12 11:01 AM, Robert Sparks wrote:
Hi Qin -

Version 14 still has some issues.

I'm confused about the changes made to address Item 1), and it looks like Magnus still has questions
about that too. Please resolve that by replying to Magnus' message.

The first part of the IANA registration section is still unclear. From your response below, I gather you
are trying to create a new registry instead of trying to put values in an existing registry, but your proposed
text still looks like it's trying to add a value to some table that already exists.

Where are you expecting IANA to put this new registry? Are you expecting it to be a subregistry of
the RTP Parameters registry? If so, say so, and provide a name for the registry. You also need to
provide a policy for adding other values. See RFC5226 section 4.2.

That said, why are you trying to put these in a registry in the first place?  Looking at the document,
it seems that you are only wanting to make these be standardized strings that can appear in
the production of an SDP rtcp-fb-nack-param line. You've done that with the grammar defined in this
document.
Ah - that thought should have answered my question by itself instantly.
You are trying to put these values in this registry
<http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml#sdp-parameters-15>

The text you added for -14 is close - I suggest this change:

OLD:
  This document instructs IANA to add two values in "ack" and "nack"
   Attribute Values registry for use with "nack"[RFC4585]:

NEW:

  This document instructs IANA to add two values to the '"ack" and "nack"
   Attribute Values' sub-registry [RFC4585] of the 'Session Description
   Protocol (SDP) Parameters' registry.


I don't see any change in this revision to address the following comment:

On 3/1/12 10:52 PM, Qin Wu wrote:

<snip/>

5) At the end of section 3, the document says messages SHOULD be 
suppressed "for a period of time". Can that be made more precise?

[Qin]: Sorry, I forgot to clear that nits in the previous version. Since we follow

 the feedback suppression rule we defined in RFC4585, I think the receivers 

should suppress the further feedback for the same packet loss. Therefore I like

 to remove "for a period of time".



_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt
--Boundary_(ID_pIpWeujI7nUrEXufGP9/8A)-- From harald@alvestrand.no Mon Mar 5 23:53:02 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5047121F8797 for ; Mon, 5 Mar 2012 23:53:02 -0800 (PST) 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 EdEw1Zd6KCYW for ; Mon, 5 Mar 2012 23:53:01 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2324B21F878B for ; Mon, 5 Mar 2012 23:53:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9FAE939E107; Tue, 6 Mar 2012 08:52:59 +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 gmH3t0Te-deA; Tue, 6 Mar 2012 08:52:58 +0100 (CET) Received: from [192.168.11.193] (c213-89-143-9.bredband.comhem.se [213.89.143.9]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 6D6CE39E090; Tue, 6 Mar 2012 08:52:58 +0100 (CET) Message-ID: <4F55C25A.9010407@alvestrand.no> Date: Tue, 06 Mar 2012 08:52:58 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Colin Perkins References: <20120305201759.24406.49431.idtracker@ietfa.amsl.com> <766FE318-7DE3-4481-B3C4-C45F2A94C881@csperkins.org> In-Reply-To: <766FE318-7DE3-4481-B3C4-C45F2A94C881@csperkins.org> Content-Type: multipart/alternative; boundary="------------000708040804020905030709" Cc: rtp-congestion@alvestrand.no, "avt@ietf.org WG" Subject: Re: [AVTCORE] [R-C] Fwd: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 07:53:02 -0000 This is a multi-part message in MIME format. --------------000708040804020905030709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 03/06/2012 12:32 AM, Colin Perkins wrote: > Here's our initial attempt at a "circuit breakers" draft for RTCWeb. Comments welcome - this is very much a straw-man for discussion, rather than a final solution. > > Colin > > > > Begin forwarded message: >> From: internet-drafts@ietf.org >> Subject: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt >> Date: 5 March 2012 20:17:59 GMT >> To: i-d-announce@ietf.org >> Reply-To: internet-drafts@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> Title : RTP Congestion Control: Circuit Breakers for Unicast Sessions >> Author(s) : Colin Perkins >> Varun Singh >> Filename : draft-perkins-avtcore-rtp-circuit-breakers-00.txt >> Pages : 14 >> Date : 2012-03-05 >> >> The Real-time Transport Protocol (RTP) is widely used for telephony, >> video conferencing, and telepresence applications. These >> applications are often used over best-effort UDP/IP networks. If >> congestion control is not implemented then network congestion will >> deteriorate the user's multimedia experience. This document does not >> propose a congestion control algorithm. Instead, it specifies a >> minimal set of "circuit-breakers". Circuit-breakers are conditions >> under which an RTP flow should cease to transmit media to protect the >> network from excessive congestion. It is expected that all RTP >> applications running on best-effort networks will be able to run >> without triggering these circuit breakers in normal operation. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-breakers-00.txt Thanks for this work! A few questions (to make sure I get them noted down): Section 4.1: Accordingly, if a sender of RTP data packets receives two or more consecutive RTCP RR packets from the same receiver that correspond to its transmission and have a non-increasing extended highest sequence number received field, then that sender SHOULD cease transmission. If I see RTCP packets with 1: highest sequence number = 2 2: highest sequence number = 2 3: highest sequence number = 2 do I cease transmission after packet 3 has arrived, or after packet 2 has arrived? I *think* the logical time is after packet 3 has arrived, but I'm a little unsure that the words are unambiguously saying that; it's not 100% clear to me whether packet 1 is considered included in the set of "non-increasing highest sequence number". Section 4.2: Is it reasonable to replace, for the purposes of this calculation, "an order of magnitude" with "a factor of ten"? (for those who don't have a physics background, putting text somewhere that says that an order of magnitude is "somewhere around a factor of ten" might be appropriate.) We might also want to add the words about doing a dramatically reduced rate if we can from section 4.1 here, factor it out as a general statement, or say that it is not appropriate here if it's not. Security considerations (missing section): For an end node that implements this specification, an active attacker can cut the transmission by faking two RTCP packets that get accepted instead of the recipient's RTCP packets. This may be worthy of a note, and pointer to appropriate defenses. Good stuff! Harald --------------000708040804020905030709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 03/06/2012 12:32 AM, Colin Perkins wrote: 
Here's our initial attempt at a "circuit breakers" draft for RTCWeb. Comments welcome - this is very much a straw-man for discussion, rather than a final solution.

Colin



Begin forwarded message:

From: internet-drafts@ietf.org
Subject: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt
Date: 5 March 2012 20:17:59 GMT
To: i-d-announce@ietf.org
Reply-To: internet-drafts@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : RTP Congestion Control: Circuit Breakers for Unicast Sessions
	Author(s)       : Colin Perkins
                         Varun Singh
	Filename        : draft-perkins-avtcore-rtp-circuit-breakers-00.txt
	Pages           : 14
	Date            : 2012-03-05

  The Real-time Transport Protocol (RTP) is widely used for telephony,
  video conferencing, and telepresence applications.  These
  applications are often used over best-effort UDP/IP networks.  If
  congestion control is not implemented then network congestion will
  deteriorate the user's multimedia experience.  This document does not
  propose a congestion control algorithm.  Instead, it specifies a
  minimal set of "circuit-breakers".  Circuit-breakers are conditions
  under which an RTP flow should cease to transmit media to protect the
  network from excessive congestion.  It is expected that all RTP
  applications running on best-effort networks will be able to run
  without triggering these circuit breakers in normal operation.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-breakers-00.txt


    

    Thanks for this work!

    

    A few questions (to make sure I get them noted down):

    

    Section 4.1:

    

    
    
   Accordingly, if a
   sender of RTP data packets receives two or more consecutive RTCP RR
   packets from the same receiver that correspond to its transmission
   and have a non-increasing extended highest sequence number received
   field, then that sender SHOULD cease transmission.



    If I see RTCP packets with

    

    1: highest sequence number = 2

    2: highest sequence number = 2

    3: highest sequence number = 2

    

    do I cease transmission after packet 3 has arrived, or after packet
    2 has arrived?

    I *think* the logical time is after packet 3 has arrived, but I'm a
    little unsure that the words are

    unambiguously saying that; it's not 100% clear to me whether packet
    1 is considered included in the set of "non-increasing highest
    sequence number".

    

    Section 4.2: Is it reasonable to replace, for the purposes of this
    calculation, "an order of magnitude" with "a factor of ten"? (for
    those who don't have a physics background, putting text somewhere
    that says that an order of magnitude is "somewhere around a factor
    of ten" might be appropriate.)

    

    We might also want to add the words about doing a dramatically
    reduced rate if we can from section 4.1 here, factor it out as a
    general statement, or say that it is not appropriate here if it's
    not.

    

    Security considerations (missing section): For an end node that
    implements this specification, an active attacker can cut the
    transmission by faking two RTCP packets that get accepted instead of
    the recipient's RTCP packets. This may be worthy of a note, and
    pointer to appropriate defenses.

    

    Good stuff!

    

                         Harald

    

    

    

     

    

    

  


--------------000708040804020905030709--

From vsingh.ietf@gmail.com  Tue Mar  6 01:21:46 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B4221F87CF for ; Tue,  6 Mar 2012 01:21:45 -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.000,  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 qcgOivT6KJTd for ; Tue,  6 Mar 2012 01:21:44 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 091A521F87C6 for ; Tue,  6 Mar 2012 01:21:28 -0800 (PST)
Received: by wgbdr13 with SMTP id dr13so3015083wgb.13 for ; Tue, 06 Mar 2012 01:21:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=AbQzTEKExUNKTBwLWlrgtkGCHPlWEIP0sZQg5lppvyo=; b=eHTJetSe3WhsTCcMzDNRGsWC8eh84IE6FZGDxqmMimiHIazaAwDiGlWa2fYUM6YSf9 3EO6XoHDQWy163hix6TQOPSccWKbb3iNxkkKC8GZwS/k0k/VLInQQFsYYCYJy4xtpds8 ILjG455cWKxurpvjE9X87dIsrBOR+iH+CxraKdJbnE/ipoT8Rj2U59kSs0O/gbQihHQc aHGJUA6NbH1+rXR79Of6jPCI4wuK5mQcvy8Z02e7joWEzabLRI9JLyfR4si6K3OLpq0Q XAqdX93L+WmNVsF/ib5WB8THMR4WxhBq7t7rSawpX01ypEmJNTVP6VL9Vbr97XN079c3 32RA==
Received: by 10.180.78.130 with SMTP id b2mr17366092wix.1.1331025688232; Tue, 06 Mar 2012 01:21:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.96.134 with HTTP; Tue, 6 Mar 2012 01:21:08 -0800 (PST)
In-Reply-To: <4F55C25A.9010407@alvestrand.no>
References: <20120305201759.24406.49431.idtracker@ietfa.amsl.com> <766FE318-7DE3-4481-B3C4-C45F2A94C881@csperkins.org> <4F55C25A.9010407@alvestrand.no>
From: Varun Singh 
Date: Tue, 6 Mar 2012 11:21:08 +0200
Message-ID: 
To: Harald Alvestrand 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Colin Perkins , "avt@ietf.org WG" , rtp-congestion@alvestrand.no
Subject: Re: [AVTCORE] [R-C] Fwd: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Mar 2012 09:21:46 -0000

Hi Harald,

comments inline

On Tue, Mar 6, 2012 at 09:52, Harald Alvestrand  wrote:

[snip!]

> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-breakers-00.txt
>
> Thanks for this work!
>
> A few questions (to make sure I get them noted down):
>
> Section 4.1:
>
>    Accordingly, if a
>    sender of RTP data packets receives two or more consecutive RTCP RR
>    packets from the same receiver that correspond to its transmission
>    and have a non-increasing extended highest sequence number received
>    field, then that sender SHOULD cease transmission.
>
> If I see RTCP packets with
>
> 1: highest sequence number = 2
> 2: highest sequence number = 2
> 3: highest sequence number = 2
>
> do I cease transmission after packet 3 has arrived, or after packet 2 has
> arrived?

After 3. The idea is for the sender to wait for two RTCP intervals
(which corresponds to two additional reports).
for the reported HSN to increase.

Example:
SR               |                              |
        |                     X
      ----------------------------------------------------------------------------------------------------------->
time
RR   |                              N                              N
                           N

The N are RTCP RRs that carry the same HSN value. X means terminate session.

We could clarify this in the next iteration.

> I *think* the logical time is after packet 3 has arrived, but I'm a little
> unsure that the words are
> unambiguously saying that; it's not 100% clear to me whether packet 1 is
> considered included in the set of "non-increasing highest sequence number".
>
> Section 4.2: Is it reasonable to replace, for the purposes of this
> calculation, "an order of magnitude" with "a factor of ten"? (for those who
> don't have a physics background, putting text somewhere that says that an
> order of magnitude is "somewhere around a factor of ten" might be
> appropriate.)
>
> We might also want to add the words about doing a dramatically reduced rate
> if we can from section 4.1 here, factor it out as a general statement, or
> say that it is not appropriate here if it's not.
>
> Security considerations (missing section): For an end node that implements
> this specification, an active attacker can cut the transmission by faking
> two RTCP packets that get accepted instead of the recipient's RTCP packets.
> This may be worthy of a note, and pointer to appropriate defenses.

This is a valid attack. However, if we consider no early-feedback (the
draft currently only follows RFC3550 timing rules) then the attacker's
second fake report may be ignored by the sender because it is too
early. Meanwhile, the actual receiver may get to deliver its RTCP RR.


Example:
SR               |                          |
        |                      I
      ----------------------------------------------------------------------------------------------------------->
time
RR   |                   F          |              F          |
   F              F      |

| are valid SR and RR, F are Fake RTCPs (replaying the last valid RTCP
report). So, instead of waiting for 3 RTCP reports to arrive the
sender MUST wait two RTCP intervals?


Cheers,
Varun

-- 
http://www.netlab.tkk.fi/~varun/

From harald@alvestrand.no  Tue Mar  6 01:51:52 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7616721F8722 for ; Tue,  6 Mar 2012 01:51:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.527
X-Spam-Level: 
X-Spam-Status: No, score=-110.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 NCnsXJuEfm8i for ; Tue,  6 Mar 2012 01:51:51 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2F72E21F871B for ; Tue,  6 Mar 2012 01:51:51 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6088939E107; Tue,  6 Mar 2012 10:51:50 +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 SL1sQf2o745y; Tue,  6 Mar 2012 10:51:49 +0100 (CET)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id CE1E839E090; Tue,  6 Mar 2012 10:51:49 +0100 (CET)
Message-ID: <4F55DE35.6060104@alvestrand.no>
Date: Tue, 06 Mar 2012 10:51:49 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19
MIME-Version: 1.0
To: Varun Singh 
References: <20120305201759.24406.49431.idtracker@ietfa.amsl.com> <766FE318-7DE3-4481-B3C4-C45F2A94C881@csperkins.org> <4F55C25A.9010407@alvestrand.no> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Colin Perkins , "avt@ietf.org WG" , rtp-congestion@alvestrand.no
Subject: Re: [AVTCORE] [R-C] Fwd: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Mar 2012 09:51:52 -0000

On 03/06/2012 10:21 AM, Varun Singh wrote:
> Hi Harald,
>
> comments inline
>
> On Tue, Mar 6, 2012 at 09:52, Harald Alvestrand  wrote:
>
> [snip!]
Thanks for the quick response!

[snip]
>> Security considerations (missing section): For an end node that implements
>> this specification, an active attacker can cut the transmission by faking
>> two RTCP packets that get accepted instead of the recipient's RTCP packets.
>> This may be worthy of a note, and pointer to appropriate defenses.
> This is a valid attack. However, if we consider no early-feedback (the
> draft currently only follows RFC3550 timing rules) then the attacker's
> second fake report may be ignored by the sender because it is too
> early. Meanwhile, the actual receiver may get to deliver its RTCP RR.
>
>
> Example:
> SR               |                          |
>          |                      I
>        ----------------------------------------------------------------------------------------------------------->
> time
> RR   |                   F          |              F          |
>     F              F      |
>
> | are valid SR and RR, F are Fake RTCPs (replaying the last valid RTCP
> report). So, instead of waiting for 3 RTCP reports to arrive the
> sender MUST wait two RTCP intervals?
Yes, I think stating that the sender waits two RTCP intervals before 
drawing a conclusion is a reasonable defense against this version of the 
attack.

Another interesting version is what happens if the attacker bumps up the 
"highest sequence number received" - the security considerations may 
want to say that RRs with a "highest sequence number received" larger 
than the highest sequence number sent MAY be part of an attack, so 
SHOULD be disregarded.

But of course, using SRTP on the RTCP channel is also an option for the 
defender; that allows the receiver to detect that the replays are 
replays, and discard them for that reason.

From vsingh.ietf@gmail.com  Tue Mar  6 05:27:09 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF5021F86E1 for ; Tue,  6 Mar 2012 05:27:09 -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.000,  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 IRKH37as+vaa for ; Tue,  6 Mar 2012 05:27:08 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 384CF21F86B0 for ; Tue,  6 Mar 2012 05:27:08 -0800 (PST)
Received: by wgbdr13 with SMTP id dr13so3168265wgb.13 for ; Tue, 06 Mar 2012 05:27:07 -0800 (PST)
Received-SPF: pass (google.com: domain of vsingh.ietf@gmail.com designates 10.216.133.93 as permitted sender) client-ip=10.216.133.93; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of vsingh.ietf@gmail.com designates 10.216.133.93 as permitted sender) smtp.mail=vsingh.ietf@gmail.com; dkim=pass header.i=vsingh.ietf@gmail.com
Received: from mr.google.com ([10.216.133.93]) by 10.216.133.93 with SMTP id p71mr8410576wei.10.1331040427468 (num_hops = 1); Tue, 06 Mar 2012 05:27:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=1tW/N3I57jQNWSOEOcJ6Zh7YEmUxNPySOJCiwfp4qoc=; b=OC6KHedAByJfzce2vsysCOGyUsiRvT6xogU/lcNw9HEjZd9CyKmahZTigkZoTjTLQ1 cp0oqpG4jVvjvEzh4u6aon+JOrAPH1kDVTGTWTLc35BJ+D+80aN2+nqCBT6lXor0GgOd GCgvXLB4FK2lqLsPSfeCGTKMIsVCbbwPgvgjuTrvQV5L9HF1zsZVyCGVDTieVXNWmOVG Xg9HdmyV+WF74XnVPMWp21r1puV+uMiyY2Z+8mlsR62TV6pu3NY3hN8VL7muOTb5ltqg kAq0QTxAgpLabVx0qqZ7SlPk9dm7gdehH1xsEiVVLmOj4713XjMnkjn+ThZ3lqHkzSlC +kHQ==
Received: by 10.216.133.93 with SMTP id p71mr6694353wei.10.1331040427373; Tue, 06 Mar 2012 05:27:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.96.134 with HTTP; Tue, 6 Mar 2012 05:26:47 -0800 (PST)
In-Reply-To: <4F55DE35.6060104@alvestrand.no>
References: <20120305201759.24406.49431.idtracker@ietfa.amsl.com> <766FE318-7DE3-4481-B3C4-C45F2A94C881@csperkins.org> <4F55C25A.9010407@alvestrand.no>  <4F55DE35.6060104@alvestrand.no>
From: Varun Singh 
Date: Tue, 6 Mar 2012 15:26:47 +0200
Message-ID: 
To: Harald Alvestrand 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Colin Perkins , "avt@ietf.org WG" , rtp-congestion@alvestrand.no
Subject: Re: [AVTCORE] [R-C] Fwd: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Mar 2012 13:27:09 -0000

Hi Harald,

Comment inline.

On Tue, Mar 6, 2012 at 11:51, Harald Alvestrand  wrot=
e:
> On 03/06/2012 10:21 AM, Varun Singh wrote:
>>
>
>>> Security considerations (missing section): For an end node that
>>> implements
>>> this specification, an active attacker can cut the transmission by faki=
ng
>>> two RTCP packets that get accepted instead of the recipient's RTCP
>>> packets.
>>> This may be worthy of a note, and pointer to appropriate defenses.
>>
>> This is a valid attack. However, if we consider no early-feedback (the
>> draft currently only follows RFC3550 timing rules) then the attacker's
>> second fake report may be ignored by the sender because it is too
>> early. Meanwhile, the actual receiver may get to deliver its RTCP RR.
>>
>>
>> Example:
>> SR =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0|
>> =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I
>>
>> ------------------------------------------------------------------------=
----------------------------------->
>> time
>> RR =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 F =A0 =A0 =A0 =A0 =A0| =A0 =
=A0 =A0 =A0 =A0 =A0 =A0F =A0 =A0 =A0 =A0 =A0|
>> =A0 =A0F =A0 =A0 =A0 =A0 =A0 =A0 =A0F =A0 =A0 =A0|
>>
>> | are valid SR and RR, F are Fake RTCPs (replaying the last valid RTCP
>> report). So, instead of waiting for 3 RTCP reports to arrive the
>> sender MUST wait two RTCP intervals?
>
> Yes, I think stating that the sender waits two RTCP intervals before draw=
ing
> a conclusion is a reasonable defense against this version of the attack.
>
> Another interesting version is what happens if the attacker bumps up the
> "highest sequence number received" - the security considerations may want=
 to
> say that RRs with a "highest sequence number received" larger than the
> highest sequence number sent MAY be part of an attack, so SHOULD be
> disregarded.

I am not sure if an endpoint reporting a HSN_received larger than the
HSN_sent trips any circuit breaker, but if the endpoint doesn't ignore
the report then the endpoint may reset its timeout counter.

A plan for action for the Security considerations can be to list the
values in the fake RTCP report that can trip a circuit breakers and
then see how the endpoint can detect or protect against that kind of
attack.

> But of course, using SRTP on the RTCP channel is also an option for the
> defender; that allows the receiver to detect that the replays are replays=
,
> and discard them for that reason.

Yes.

--=20
http://www.netlab.tkk.fi/~varun/

From csp@csperkins.org  Tue Mar  6 14:23:26 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F7D21E80CA for ; Tue,  6 Mar 2012 14:23:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.598
X-Spam-Level: 
X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 aeIujspWNxiA for ; Tue,  6 Mar 2012 14:23:25 -0800 (PST)
Received: from lon1-msapost-3.mail.demon.net (lon1-msapost-3.mail.demon.net [195.173.77.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0131721E8013 for ; Tue,  6 Mar 2012 14:23:25 -0800 (PST)
Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.30]) by lon1-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1S52mX-0001aI-dH; Tue, 06 Mar 2012 22:23:23 +0000
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D57FDCE6-D3BD-4F78-A9B9-57BD1BA50C91"
From: Colin Perkins 
In-Reply-To: <4F55C25A.9010407@alvestrand.no>
Date: Tue, 6 Mar 2012 22:22:49 +0000
Message-Id: <312FF88C-92AC-4BD7-AE80-56BE51DFD626@csperkins.org>
References: <20120305201759.24406.49431.idtracker@ietfa.amsl.com> <766FE318-7DE3-4481-B3C4-C45F2A94C881@csperkins.org> <4F55C25A.9010407@alvestrand.no>
To: Harald Alvestrand 
X-Mailer: Apple Mail (2.1257)
Cc: rtp-congestion@alvestrand.no, "avt@ietf.org WG" 
Subject: Re: [AVTCORE] [R-C] I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Mar 2012 22:23:26 -0000

--Apple-Mail=_D57FDCE6-D3BD-4F78-A9B9-57BD1BA50C91
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

On 6 Mar 2012, at 07:52, Harald Alvestrand wrote:
> On 03/06/2012 12:32 AM, Colin Perkins wrote:
>>=20
>> Here's our initial attempt at a "circuit breakers" draft for RTCWeb. =
Comments welcome - this is very much a straw-man for discussion, rather =
than a final solution.
>>=20
>> Colin
>>=20
>>=20
>>=20
>> Begin forwarded message:
>>> From: internet-drafts@ietf.org
>>> Subject: I-D Action: =
draft-perkins-avtcore-rtp-circuit-breakers-00.txt
>>> Date: 5 March 2012 20:17:59 GMT
>>> To: i-d-announce@ietf.org
>>> Reply-To: internet-drafts@ietf.org
>>>=20
>>>=20
>>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>>>=20
>>> 	Title           : RTP Congestion Control: Circuit Breakers for =
Unicast Sessions
>>> 	Author(s)       : Colin Perkins
>>>                          Varun Singh
>>> 	Filename        : =
draft-perkins-avtcore-rtp-circuit-breakers-00.txt
>>> 	Pages           : 14
>>> 	Date            : 2012-03-05
>>>=20
>>>   The Real-time Transport Protocol (RTP) is widely used for =
telephony,
>>>   video conferencing, and telepresence applications.  These
>>>   applications are often used over best-effort UDP/IP networks.  If
>>>   congestion control is not implemented then network congestion will
>>>   deteriorate the user's multimedia experience.  This document does =
not
>>>   propose a congestion control algorithm.  Instead, it specifies a
>>>   minimal set of "circuit-breakers".  Circuit-breakers are =
conditions
>>>   under which an RTP flow should cease to transmit media to protect =
the
>>>   network from excessive congestion.  It is expected that all RTP
>>>   applications running on best-effort networks will be able to run
>>>   without triggering these circuit breakers in normal operation.
>>>=20
>>>=20
>>> A URL for this Internet-Draft is:
>>> =
http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-brea=
kers-00.txt
> Thanks for this work!
>=20
> A few questions (to make sure I get them noted down):
>=20
> Section 4.1:
>=20
>    Accordingly, if a
>    sender of RTP data packets receives two or more consecutive RTCP RR
>    packets from the same receiver that correspond to its transmission
>    and have a non-increasing extended highest sequence number received
>    field, then that sender SHOULD cease transmission.
>=20
> If I see RTCP packets with
>=20
> 1: highest sequence number =3D 2
> 2: highest sequence number =3D 2
> 3: highest sequence number =3D 2
>=20
> do I cease transmission after packet 3 has arrived, or after packet 2 =
has arrived?
> I *think* the logical time is after packet 3 has arrived, but I'm a =
little unsure that the words are
> unambiguously saying that; it's not 100% clear to me whether packet 1 =
is considered included in the set of "non-increasing highest sequence =
number".

We should clarify. My feeling is that either way would work, depending =
on how aggressive we want the circuit breaker to be.=20

> Section 4.2: Is it reasonable to replace, for the purposes of this =
calculation, "an order of magnitude" with "a factor of ten"? (for those =
who don't have a physics background, putting text somewhere that says =
that an order of magnitude is "somewhere around a factor of ten" might =
be appropriate.)

Sure, will clarify.=20

> We might also want to add the words about doing a dramatically reduced =
rate if we can from section 4.1 here, factor it out as a general =
statement, or say that it is not appropriate here if it's not.

Yes.

> Security considerations (missing section): For an end node that =
implements this specification, an active attacker can cut the =
transmission by faking two RTCP packets that get accepted instead of the =
recipient's RTCP packets. This may be worthy of a note, and pointer to =
appropriate defenses.

Agreed.

> Good stuff!
>=20
>                      Harald
>=20
>=20
>=20
> =20
>=20
>=20
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion@alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion



--=20
Colin Perkins
http://csperkins.org/




--Apple-Mail=_D57FDCE6-D3BD-4F78-A9B9-57BD1BA50C91
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1


 =20
    
 =20
  

    On 03/06/2012 12:32 AM, Colin Perkins wrote:
    

      
Here's our initial attempt at a "circuit breakers" =
draft for RTCWeb. Comments welcome - this is very much a straw-man for =
discussion, rather than a final solution.

Colin



Begin forwarded message:


      

        
From: internet-drafts@ietf.org
Subject: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt
Date: 5 March 2012 20:17:59 GMT
To: i-d-announce@ietf.org
Reply-To: internet-drafts@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts =
directories.

	Title           : RTP Congestion Control: Circuit Breakers for =
Unicast Sessions
	Author(s)       : Colin Perkins
                         Varun Singh
	Filename        : =
draft-perkins-avtcore-rtp-circuit-breakers-00.txt
	Pages           : 14
	Date            : 2012-03-05

  The Real-time Transport Protocol (RTP) is widely used for telephony,
  video conferencing, and telepresence applications.  These
  applications are often used over best-effort UDP/IP networks.  If
  congestion control is not implemented then network congestion will
  deteriorate the user's multimedia experience.  This document does not
  propose a congestion control algorithm.  Instead, it specifies a
  minimal set of "circuit-breakers".  Circuit-breakers are conditions
  under which an RTP flow should cease to transmit media to protect the
  network from excessive congestion.  It is expected that all RTP
  applications running on best-effort networks will be able to run
  without triggering these circuit breakers in normal operation.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-perkins-avt=
core-rtp-circuit-breakers-00.txt


      

      

    

    Thanks for this work!

    

    A few questions (to make sure I get them noted down):

    

    Section 4.1:

    

    
    
   =
Accordingly, if a
   sender of RTP data packets receives two or more consecutive RTCP RR
   packets from the same receiver that correspond to its transmission
   and have a non-increasing extended highest sequence number received
   field, then that sender SHOULD cease transmission.



    If I see RTCP packets with

    

    1: highest sequence number =3D 2

    2: highest sequence number =3D 2

    3: highest sequence number =3D 2

    

    do I cease transmission after packet 3 has arrived, or after packet
    2 has arrived?

    I *think* the logical time is after packet 3 has arrived, but I'm a
    little unsure that the words are

    unambiguously saying that; it's not 100% clear to me whether packet
    1 is considered included in the set of "non-increasing highest
    sequence number".

We =
should clarify. My feeling is that either way would work, depending on =
how aggressive we want the circuit breaker to =
be. 


    Section 4.2: Is it reasonable to replace, for the purposes of this
    calculation, "an order of magnitude" with "a factor of ten"? (for
    those who don't have a physics background, putting text somewhere
    that says that an order of magnitude is "somewhere around a factor
    of ten" might be =
appropriate.)

Sure, will =
clarify. 


    We might also want to add the words about doing a dramatically
    reduced rate if we can from section 4.1 here, factor it out as a
    general statement, or say that it is not appropriate here if it's
    =
not.

Yes.


    Security considerations (missing section): For an end node that
    implements this specification, an active attacker can cut the
    transmission by faking two RTCP packets that get accepted instead of
    the recipient's RTCP packets. This may be worthy of a note, and
    pointer to appropriate =
defenses.

Agreed.


    Good stuff!

    

    =
            &n=
bsp;        Harald

    

    

    

     

    

    

  


_______________________________________________
Rtp-congestion =
mailing list
Rtp-congestion@alvestrand.no<=
/a>
http://www.alvestrand.no/mailman/listinfo/rtp-congestion





-- 
Colin Perkins





=

--Apple-Mail=_D57FDCE6-D3BD-4F78-A9B9-57BD1BA50C91--

From jmpolk@cisco.com  Tue Mar  6 15:16:35 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0537121E805D for ; Tue,  6 Mar 2012 15:16:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.635
X-Spam-Level: 
X-Spam-Status: No, score=-109.635 tagged_above=-999 required=5 tests=[AWL=0.964, 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 Cp-+FYY9wTwg for ; Tue,  6 Mar 2012 15:16:34 -0800 (PST)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 24C0F21E800F for ; Tue,  6 Mar 2012 15:16:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=4828; q=dns/txt; s=iport; t=1331075794; x=1332285394; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=kKe6T846ZgAqMiO14BGwRQIXmBc8C8+v85Zwl623G/Q=; b=WnIVraH8IbL95VaDfPSFu0RmzF6bx1pQq9BGzW9Ucq/UsmBgN3UI2H46 0Xo1JbqYNaHxvjWLbgSbU432h8dSv12gyTCvSrH6d3AhIBj/xdcsl1XmG pPNzqEV/OpNAYFaA1mx2Yc7Awpe9Am1suLzJnDcz7iUShH7ukzMFgyzzE 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EANmZVk+rRDoJ/2dsb2JhbABDtQKBB4F9AQEBBAEBAQ8BJQI0CxAHFQMBAgEeCQcZDh8JCAYBEgkSB4dkDJo9AZ8VkHAEiFKdA4MC
X-IronPort-AV: E=Sophos;i="4.73,542,1325462400"; d="scan'208";a="32188984"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 06 Mar 2012 23:16:33 +0000
Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q26NGXvZ018119; Tue, 6 Mar 2012 23:16:33 GMT
Message-Id: <201203062316.q26NGXvZ018119@mtv-core-4.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 06 Mar 2012 17:16:31 -0600
To: Harald Alvestrand , Colin Perkins 
From: "James M. Polk" 
In-Reply-To: <4F55C25A.9010407@alvestrand.no>
References: <20120305201759.24406.49431.idtracker@ietfa.amsl.com> <766FE318-7DE3-4481-B3C4-C45F2A94C881@csperkins.org> <4F55C25A.9010407@alvestrand.no>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: rtp-congestion@alvestrand.no, "avt@ietf.org WG" 
Subject: [AVTCORE] rtp-circuit-breakers-00 when not using BE?
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Mar 2012 23:16:35 -0000

Colin

I'm curious about this RTP extension for the cases in which DiffServ 
is actually used, but there's more load than capacity to serve the DS node(s)?

What happens then?

Also, in the fairly rare case that reservations are used, many times 
RTCP feedback will be used to invoke or cause a source to reduce 
resolution or to otherwise change audio codecs, which can be planned 
for *without* the need for this circuit breaker mode of just cease 
transmitting.

Would you be relying on the application at each end to know the 
difference as to whether that endpoint is within a BE network, a DS 
network that's congested or a network that uses (say) reservations, 
but still experiences problems?

James

At 01:52 AM 3/6/2012, Harald Alvestrand wrote:
>On 03/06/2012 12:32 AM, Colin Perkins wrote:
>>
>>Here's our initial attempt at a "circuit breakers" draft for 
>>RTCWeb. Comments welcome - this is very much a straw-man for 
>>discussion, rather than a final solution.
>>
>>Colin
>>
>>
>>
>>Begin forwarded message:
>>>
>>>From: internet-drafts@ietf.org
>>>Subject: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt
>>>Date: 5 March 2012 20:17:59 GMT
>>>To: i-d-announce@ietf.org
>>>Reply-To: internet-drafts@ietf.org
>>>
>>>
>>>A New Internet-Draft is available from the on-line Internet-Drafts 
>>>directories.
>>>
>>>         Title           : RTP Congestion Control: Circuit 
>>> Breakers for Unicast Sessions
>>>         Author(s)       : Colin Perkins
>>>                          Varun Singh
>>>         Filename        : draft-perkins-avtcore-rtp-circuit-breakers-00.txt
>>>         Pages           : 14
>>>         Date            : 2012-03-05
>>>
>>>   The Real-time Transport Protocol (RTP) is widely used for telephony,
>>>   video conferencing, and telepresence applications.  These
>>>   applications are often used over best-effort UDP/IP networks.  If
>>>   congestion control is not implemented then network congestion will
>>>   deteriorate the user's multimedia experience.  This document does not
>>>   propose a congestion control algorithm.  Instead, it specifies a
>>>   minimal set of "circuit-breakers".  Circuit-breakers are conditions
>>>   under which an RTP flow should cease to transmit media to protect the
>>>   network from excessive congestion.  It is expected that all RTP
>>>   applications running on best-effort networks will be able to run
>>>   without triggering these circuit breakers in normal operation.
>>>
>>>
>>>A URL for this Internet-Draft is:
>>>http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-breakers-00.txt
>>
>>
>Thanks for this work!
>
>A few questions (to make sure I get them noted down):
>
>Section 4.1:
>
>
>    Accordingly, if a
>    sender of RTP data packets receives two or more consecutive RTCP RR
>    packets from the same receiver that correspond to its transmission
>    and have a non-increasing extended highest sequence number received
>    field, then that sender SHOULD cease transmission.
>
>
>If I see RTCP packets with
>
>1: highest sequence number = 2
>2: highest sequence number = 2
>3: highest sequence number = 2
>
>do I cease transmission after packet 3 has arrived, or after packet 
>2 has arrived?
>I *think* the logical time is after packet 3 has arrived, but I'm a 
>little unsure that the words are
>unambiguously saying that; it's not 100% clear to me whether packet 
>1 is considered included in the set of "non-increasing highest 
>sequence number".
>
>Section 4.2: Is it reasonable to replace, for the purposes of this 
>calculation, "an order of magnitude" with "a factor of ten"? (for 
>those who don't have a physics background, putting text somewhere 
>that says that an order of magnitude is "somewhere around a factor 
>of ten" might be appropriate.)
>
>We might also want to add the words about doing a dramatically 
>reduced rate if we can from section 4.1 here, factor it out as a 
>general statement, or say that it is not appropriate here if it's not.
>
>Security considerations (missing section): For an end node that 
>implements this specification, an active attacker can cut the 
>transmission by faking two RTCP packets that get accepted instead of 
>the recipient's RTCP packets. This may be worthy of a note, and 
>pointer to appropriate defenses.
>Good stuff!
>
>                      Harald
>
>
>
>
>
>
>_______________________________________________
>Rtp-congestion mailing list
>Rtp-congestion@alvestrand.no
>http://www.alvestrand.no/mailman/listinfo/rtp-congestion


From harald@alvestrand.no  Wed Mar  7 01:22:11 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A2E21F8652 for ; Wed,  7 Mar 2012 01:22:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.14
X-Spam-Level: 
X-Spam-Status: No, score=-110.14 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, 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 GZW01IkZQT92 for ; Wed,  7 Mar 2012 01:22:11 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9111221F864F for ; Wed,  7 Mar 2012 01:22:10 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8114139E17B; Wed,  7 Mar 2012 10:22:09 +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 6ACtSBEP9aVg; Wed,  7 Mar 2012 10:22:09 +0100 (CET)
Received: from [192.168.11.193] (c213-89-143-9.bredband.comhem.se [213.89.143.9]) by eikenes.alvestrand.no (Postfix) with ESMTPS id C5E1F39E17A; Wed,  7 Mar 2012 10:22:08 +0100 (CET)
Message-ID: <4F5728C0.8040803@alvestrand.no>
Date: Wed, 07 Mar 2012 10:22:08 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Varun Singh 
References: <20120305201759.24406.49431.idtracker@ietfa.amsl.com> <766FE318-7DE3-4481-B3C4-C45F2A94C881@csperkins.org> <4F55C25A.9010407@alvestrand.no>  <4F55DE35.6060104@alvestrand.no> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Colin Perkins , "avt@ietf.org WG" , rtp-congestion@alvestrand.no
Subject: Re: [AVTCORE] [R-C] Fwd: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Mar 2012 09:22:12 -0000

On 03/06/2012 02:26 PM, Varun Singh wrote:
> Hi Harald,
>
> Comment inline.
>
> On Tue, Mar 6, 2012 at 11:51, Harald Alvestrand  wrote:
>> On 03/06/2012 10:21 AM, Varun Singh wrote:
>>>> Security considerations (missing section): For an end node that
>>>> implements
>>>> this specification, an active attacker can cut the transmission by faking
>>>> two RTCP packets that get accepted instead of the recipient's RTCP
>>>> packets.
>>>> This may be worthy of a note, and pointer to appropriate defenses.
>>> This is a valid attack. However, if we consider no early-feedback (the
>>> draft currently only follows RFC3550 timing rules) then the attacker's
>>> second fake report may be ignored by the sender because it is too
>>> early. Meanwhile, the actual receiver may get to deliver its RTCP RR.
>>>
>>>
>>> Example:
>>> SR               |                          |
>>>          |                      I
>>>
>>> ----------------------------------------------------------------------------------------------------------->
>>> time
>>> RR   |                   F          |              F          |
>>>     F              F      |
>>>
>>> | are valid SR and RR, F are Fake RTCPs (replaying the last valid RTCP
>>> report). So, instead of waiting for 3 RTCP reports to arrive the
>>> sender MUST wait two RTCP intervals?
>> Yes, I think stating that the sender waits two RTCP intervals before drawing
>> a conclusion is a reasonable defense against this version of the attack.
>>
>> Another interesting version is what happens if the attacker bumps up the
>> "highest sequence number received" - the security considerations may want to
>> say that RRs with a "highest sequence number received" larger than the
>> highest sequence number sent MAY be part of an attack, so SHOULD be
>> disregarded.
> I am not sure if an endpoint reporting a HSN_received larger than the
> HSN_sent trips any circuit breaker, but if the endpoint doesn't ignore
> the report then the endpoint may reset its timeout counter.
What could happen is this:

Victim receiver:RTCP, HSN(low)
Attacker: RTCP, HSN(high)
Victim sender: OK, HSN is (high)
Victim receiver:RTCP,  HSN(low+some)
Victim sender: Oops, HSN did not increase
Victim receiver:RTCP, HSN(low+some+some)
Victim sener: Oops, HSN did not increase for two RTCP intervals. Shut down.

One-packet denial of service.

If HSN is always verified against last-sent, and the report is discarded 
as erroneous if it is higher than last-sent, this attack cannot occur.

>
> A plan for action for the Security considerations can be to list the
> values in the fake RTCP report that can trip a circuit breakers and
> then see how the endpoint can detect or protect against that kind of
> attack.
>
>> But of course, using SRTP on the RTCP channel is also an option for the
>> defender; that allows the receiver to detect that the replays are replays,
>> and discard them for that reason.
> Yes.
>


From ron.even.tlv@gmail.com  Wed Mar  7 01:29:57 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE64C21F86BE; Wed,  7 Mar 2012 01:29:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.478
X-Spam-Level: 
X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=0.120,  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 bG7-i3qa-Pi7; Wed,  7 Mar 2012 01:29:53 -0800 (PST)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0F68721F84C8; Wed,  7 Mar 2012 01:29:49 -0800 (PST)
Received: by eaaq11 with SMTP id q11so2118725eaa.31 for ; Wed, 07 Mar 2012 01:29:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=vOo47U//rEIqyeKKRwITcYKGIb6/pWyqF5pYvl0Mx7U=; b=vVaAZkRtyfXE34hk7TF6f86m1maY/CRwJDNQZuTS+l1dC8x8yzkQ29zFmIFLGffUbk a8Fb+jSwZbebfWLG+I01pmflABfD3Ql/z2gGHjnLgIPS1jcWaXvPzopaqp9sj5BCKbAa Y1BapJfBWNseCeqVDc97s1WZowt92XFLTVh2jCEZreKWJdCZ9qB9O2cIlSvcK36OyJ72 F+4OiUMlD7VQRfbH8PPOsi++RuFHLTSMYgpAgQ6gF0gcN7HIvaOfjQLs43Ezgk6hWbU4 Wu81laxXJnPzTneE3X88v445z1Diq8qRjPzHkctZqkZu2kfYQ74HPppaa896Jonbsbp4 6D4A==
Received: by 10.213.13.72 with SMTP id b8mr402723eba.150.1331112584829; Wed, 07 Mar 2012 01:29:44 -0800 (PST)
Received: from windows8d787f9 (bzq-109-67-208-29.red.bezeqint.net. [109.67.208.29]) by mx.google.com with ESMTPS id n55sm45257657eef.6.2012.03.07.01.29.41 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Mar 2012 01:29:43 -0800 (PST)
From: "Roni Even" 
To: , "'Robert Sparks'" 
Date: Wed, 7 Mar 2012 11:28:33 +0200
Message-ID: <4f572a87.cf5e0e0a.5211.0ced@mx.google.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0747_01CCFC55.700817A0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acz8RKoajj/ViPyvStGuRbH4qT7UQQ==
Content-Language: en-us
Cc: 'Magnus Westerlund' , draft-ietf-avtcore-ecn-for-rtp.all@tools.ietf.org, avt@ietf.org
Subject: [AVTCORE] Request to publish draft-ietf-avtcore-ecn-for-rtp-06
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Mar 2012 09:29:57 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0747_01CCFC55.700817A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Robert,

I'd like to request that draft-ietf-avtcore-ecn-for-rtp-06, Explicit
Congestion Notification (ECN) for RTP over UDP, be published as Standard
Track RFC. 

I've reviewed the draft in detail, and the AVTCore working group was given
the opportunity to comment. The draft doesn't conflict with other work in
AVTCore. Accordingly, please consider it for publication.

 

Thanks,

Roni Even

 

 

(1.a) Who is the Document Shepherd for this document? Has the

        Document Shepherd personally reviewed this version of the 

        document and, in particular, does he or she believe this 

        version is ready for forwarding to the IESG for publication? 

 

The document shepherd is Roni Even. I have reviewed the document, and
believe it is ready for publication.

 

  (1.b) Has the document had adequate review both from key WG members 

        and from key non-WG members? Does the Document Shepherd have 

        any concerns about the depth or breadth of the reviews that 

        have been performed?  

 

The document is the result of an effort done by key WG members. It went
through Working Group last call and people had enough time to review it. The
document shepherd feels comfortable with the review it got.

Note that the document started at AVT before it was moved to the new AVTCore
WG.

 

  (1.c) Does the Document Shepherd have concerns that the document 

        needs more review from a particular or broader perspective, 

        e.g., security, operational complexity, someone familiar with 

        AAA, internationalization or XML? 

 

No concerns

 

 

  (1.d) Does the Document Shepherd have any specific concerns or 

        issues with this document that the Responsible Area Director

        and/or the IESG should be aware of? For example, perhaps he 

        or she is uncomfortable with certain parts of the document, or 

        has concerns whether there really is a need for it. In any 

        event, if the WG has discussed those issues and has indicated 

        that it still wishes to advance the document, detail those 

        concerns here. Has an IPR disclosure related to this document 

        been filed? If so, please include a reference to the 

        disclosure and summarize the WG discussion and conclusion on 

        this issue. 

 

No Concerns. No IPR disclosure related to this document or the previous
individual draft and AVT version was filed.

 

(1.e) How solid is the WG consensus behind this document? Does it 

        represent the strong concurrence of a few individuals, with 

        others being silent, or does the WG as a whole understand and 

        agree with it? 

 

The document has strong consensus the members of the AVTCore WG.

  

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme 

        discontent? If so, please summarise the areas of conflict in 

        separate email messages to the Responsible Area Director. (It 

        should be in a separate email because this questionnaire is 

        entered into the ID Tracker.)

 

No

  (1.g) Has the Document Shepherd personally verified that the 

document satisfies all ID nits?(See the Checklist and idnits
 ).Boilerplate checks are not enough;
this check needs to be thorough. Has the document met all formal review
criteria it needs to, such as the MIB Doctor, media type and URI type
reviews? 

 

There is one warning that is relevant:

 

== There are 3 instances of lines with private range IPv4 addresses in

   the document.  If these are generic example addresses, they should

   be changed to use any of the ranges defined in RFC 5735 (or

   successor): 192.0.2.x, 198.51.100.x or 203.0.113.x.

 

They are intentional as we have an SDP example of an end-point that is NATed
with the address 10.0.1.4. Both the o= and the ICE candidate list thus
contains such an 10.0.1.4 address. Thus I don't see an issue of using
private address ranges in the example.

 

  (1.h) Has the document split its references into normative and 

        informative? Are there normative references to documents that 

        are not ready for advancement or are otherwise in an unclear 

        state? If such normative references exist, what is the 

        strategy for their completion? Are there normative references 

        that are downward references, as described in [RFC3967]? If 

        so, list these downward references to support the Area 

        Director in the Last Call procedure for them [RFC3967]. 

  

 

References are split. There are no normative references to documents which
are not in RFC state

 

(1.i) Has the Document Shepherd verified that the document IANA 

        consideration section exists and is consistent with the body 

        of the document? If the document specifies protocol 

        extensions, are reservations requested in appropriate IANA 

        registries? Are the IANA registries clearly identified? If 

        the document creates a new registry, does it define the 

        proposed initial contents of the registry and an allocation 

        procedure for future registrations? Does it suggest a 

        reasonable name for the new registry? See [RFC5226]. If the 

        document describes an Expert Review process has Shepherd 

        conferred with the Responsible Area Director so that the IESG 

        can appoint the needed Expert during the IESG Evaluation?

 

 

The IANA consideration section exists and is inline with the body of the
document.

 

  (1.j) Has the Document Shepherd verified that sections of the 

        document that are written in a formal language, such as XML 

        code, BNF rules, MIB definitions, etc., validate correctly in 

        an automated checker? 

 

The document shepherd verified that the SDP signaling examples  in section
12 are correct.

 

  (1.k) The IESG approval announcement includes a Document 

        Announcement Write-Up. Please provide such a Document 

        Announcement Write-Up? Recent examples can be found in the

        "Action" announcements for approved documents. The approval 

        announcement contains the following sections: 

     

Technical Summary 

        Relevant content can frequently be found in the abstract 

        and/or introduction of the document. If not, this may be 

        an indication that there are deficiencies in the abstract 

        or introduction. 

     

"This memo specifies how Explicit Congestion Notification (ECN) can be

   used with the Real-time Transport Protocol (RTP) running over UDP,

   using RTP Control Protocol (RTCP) as a feedback mechanism.  It

   defines a new RTCP Extended Report (XR) block for periodic ECN

   feedback, a new RTCP transport feedback message for timely reporting

   of congestion events, and a Session Traversal Utilities for NAT

   (STUN) extension used in the optional initialization method using

   Interactive Connectivity Establishment (ICE).  Signalling and

   procedures for negotiation of capabilities and initialization methods

   are also defined."

 

 

Working Group Summary 

        Was there anything in WG process that is worth noting? For 

        example, was there controversy about particular points or 

        were there decisions where the consensus was particularly 

        rough? 

     

There were no controversy about the proposed solution and there was
consensus on all discussion points

 

 

 

Document Quality 

        Are there existing implementations of the protocol? Have a 

        significant number of vendors indicated their plan to 

        implement the specification? Are there any reviewers that 

        merit special mention as having done a thorough review, 

        e.g., one that resulted in important changes or a 

        conclusion that the document had no substantive issues? If 

        there was a MIB Doctor, Media Type or other expert review, 

        what was its course (briefly)? In the case of a Media Type 

        review, on what date was the request posted? 

 

The document shepherd is not aware of current implementations. There was
interest in this work by other standard bodies like 3GPP and ITU-T SG16 who
need to reference it.

The SDP attributes and ICE options defined in the document were sent to
review in MMUSIC on September 30, 2011

 


------=_NextPart_000_0747_01CCFC55.700817A0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi =
Robert,
I'd like to request that =
draft-ietf-avtcore-ecn-for-rtp-06, Explicit Congestion Notification =
(ECN) for RTP over UDP, be published as Standard Track RFC. =

I've =
reviewed the draft in detail, and the AVTCore working group was given =
the opportunity to comment. The draft doesn't conflict with other work =
in AVTCore. Accordingly, please consider it for =
publication.
 
Thanks,
Roni Even
 
 
(1.a) Who =
is the Document Shepherd for this document? Has =
the
  =
;      Document Shepherd personally reviewed =
this version of the 
  =
;      document and, in particular, does =
he or she believe this 
  =
;      version is ready for forwarding to =
the IESG for publication? 
 =

The =
document shepherd is Roni Even. I have reviewed the document, and =
believe it is ready for publication.
 =

  =
(1.b) Has the document had adequate review both from key WG members =

  =
;      and from key non-WG members? Does =
the Document Shepherd have 
  =
;      any concerns about the depth or =
breadth of the reviews that 
  =
;      have been performed?  =

 =

The =
document is the result of an effort done by key WG members. It went =
through Working Group last call and people had enough time to review it. =
The document shepherd feels comfortable with the review it =
got.
Note that =
the document started at AVT before it was moved to the new AVTCore =
WG.
 =

  =
(1.c) Does the Document Shepherd have concerns that the document =

  =
;      needs more review from a particular =
or broader perspective, 
  =
;      e.g., security, operational =
complexity, someone familiar with 
  =
;      AAA, internationalization or XML? =

 =

No =
concerns
 =

 =

  =
(1.d) Does the Document Shepherd have any specific concerns or =

  =
;      issues with this document that the =
Responsible Area Director
  =
;      and/or the IESG should be aware of? For =
example, perhaps he 
  =
;      or she is uncomfortable with =
certain parts of the document, or 
  =
;      has concerns whether there really =
is a need for it. In any 
  =
;      event, if the WG has discussed =
those issues and has indicated 
  =
;      that it still wishes to advance the =
document, detail those 
  =
;      concerns here. Has an IPR =
disclosure related to this document 
  =
;      been filed? If so, please include a =
reference to the 
  =
;      disclosure and summarize the WG =
discussion and conclusion on 
  =
;      this issue. =

 =

No =
Concerns. No IPR disclosure related to this document or the previous =
individual draft and AVT version was filed.
 =

 (1.e) How =
solid is the WG consensus behind this document? Does it =

  =
;      represent the strong concurrence of =
a few individuals, with 
  =
;      others being silent, or does the WG =
as a whole understand and 
  =
;      agree with it? =

 =

The =
document has strong consensus the members of the AVTCore =
WG.
  =

  =
;(1.f) Has anyone threatened an appeal or otherwise indicated extreme =

  =
;      discontent? If so, please summarise =
the areas of conflict in 
  =
;      separate email messages to the =
Responsible Area Director. (It 
  =
;      should be in a separate email =
because this questionnaire is 
  =
;      entered into the ID =
Tracker.)
 =

No
 =

  =
;(1.g) Has the Document Shepherd personally verified that the =

document =
satisfies all ID nits?(See the Checklist and idnits).Boilerplate =
checks are not enough; this check needs to be thorough. Has the document =
met all formal review criteria it needs to, such as the MIB Doctor, =
media type and URI type reviews? 
 =

There is one warning that is =
relevant:
 
=3D=3D =
There are 3 instances of lines with private range IPv4 addresses =
in
  =
; the document.  If these are generic example addresses, they =
should
  =
; be changed to use any of the ranges defined in RFC 5735 =
(or
  =
; successor): 192.0.2.x, 198.51.100.x or =
203.0.113.x.
 =

They are =
intentional as we have an SDP example of an end-point that is NATed with =
the address 10.0.1.4. Both the o=3D and the ICE candidate list thus =
contains such an 10.0.1.4 address. Thus I don't see an issue of using =
private address ranges in the example.
 =

  =
(1.h) Has the document split its references into normative and =

  =
;      informative? Are there normative =
references to documents that 
  =
;      are not ready for advancement or =
are otherwise in an unclear 
  =
;      state? If such normative references =
exist, what is the 
  =
;      strategy for their completion? Are =
there normative references 
  =
;      that are downward references, as =
described in [RFC3967]? If 
  =
;      so, list these downward references =
to support the Area 
  =
;      Director in the Last Call procedure =
for them [RFC3967]. 
  =
;
 =

References =
are split. There are no normative references to documents which are not =
in RFC state
 =

(1.i) Has =
the Document Shepherd verified that the document IANA =

  =
;      consideration section exists and is =
consistent with the body 
  =
;      of the document? If the document =
specifies protocol 
  =
;      extensions, are reservations =
requested in appropriate IANA 
  =
;      registries? Are the IANA registries =
clearly identified? If 
  =
;      the document creates a new =
registry, does it define the 
  =
;      proposed initial contents of the =
registry and an allocation 
  =
;      procedure for future registrations? =
Does it suggest a 
  =
;      reasonable name for the new =
registry? See [RFC5226]. If the 
  =
;      document describes an Expert Review =
process has Shepherd 
  =
;      conferred with the Responsible Area =
Director so that the IESG 
  =
;      can appoint the needed Expert =
during the IESG Evaluation?
 =

 =

The IANA =
consideration section exists and is inline with the body of the =
document.
 =

 =

  =
;(1.j) Has the Document Shepherd verified that sections of the =

  =
;      document that are written in a =
formal language, such as XML 
  =
;      code, BNF rules, MIB definitions, =
etc., validate correctly in 
  =
;      an automated checker? =

 =

The =
document shepherd verified that the SDP signaling examples  in =
section 12 are correct.
 =

  =
(1.k) The IESG approval announcement includes a Document =

  =
;      Announcement Write-Up. Please =
provide such a Document 
  =
;      Announcement Write-Up? Recent =
examples can be found in the
  =
;      "Action" announcements for =
approved documents. The approval 
  =
;      announcement contains the following =
sections: 
  =
;   
Technical =
Summary 
  =
;      Relevant content can frequently be =
found in the abstract 
  =
;      and/or introduction of the =
document. If not, this may be 
  =
;      an indication that there are =
deficiencies in the abstract 
  =
;      or introduction. =

  =
;   
R=
20;This memo specifies how Explicit =
Congestion Notification (ECN) can be
   used with the Real-time Transport =
Protocol (RTP) running over UDP,
   using RTP Control Protocol (RTCP) =
as a feedback mechanism.  It
   defines a new RTCP Extended Report =
(XR) block for periodic ECN
   feedback, a new RTCP transport =
feedback message for timely reporting
   of congestion events, and a Session =
Traversal Utilities for NAT
   (STUN) extension used in the =
optional initialization method using
   Interactive Connectivity =
Establishment (ICE).  Signalling and
   procedures for negotiation of =
capabilities and initialization methods
   are also =
defined.”
 =

 =

Working =
Group Summary 
  =
;      Was there anything in WG process =
that is worth noting? For 
  =
;      example, was there controversy =
about particular points or 
  =
;      were there decisions where the =
consensus was particularly 
  =
;      rough? 
  =
;   
There were =
no controversy about the proposed solution and there was consensus on =
all discussion points
 =

 =

 =

Document =
Quality 
  =
;      Are there existing implementations =
of the protocol? Have a 
  =
;      significant number of vendors =
indicated their plan to 
  =
;      implement the specification? Are =
there any reviewers that 
  =
;      merit special mention as having =
done a thorough review, 
  =
;      e.g., one that resulted in =
important changes or a 
  =
;      conclusion that the document had no =
substantive issues? If 
  =
;      there was a MIB Doctor, Media Type =
or other expert review, 
  =
;      what was its course (briefly)? In =
the case of a Media Type 
  =
;      review, on what date was the =
request posted? 
 
The document =
shepherd is not aware of current implementations. There was interest in =
this work by other standard bodies like 3GPP and ITU-T SG16 who need to =
reference it.
The SDP attributes and =
ICE options defined in the document were sent to review in MMUSIC on =
September 30, 2011
 

------=_NextPart_000_0747_01CCFC55.700817A0--


From csp@csperkins.org  Wed Mar  7 01:43:54 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA53221F8792 for ; Wed,  7 Mar 2012 01:43:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.879
X-Spam-Level: 
X-Spam-Status: No, score=-102.879 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, J_CHICKENPOX_84=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 WRtcEqdnr4su for ; Wed,  7 Mar 2012 01:43:54 -0800 (PST)
Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id E538B21F878E for ; Wed,  7 Mar 2012 01:43:53 -0800 (PST)
Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1S5DPR-0005ah-aE; Wed, 07 Mar 2012 09:43:49 +0000
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Colin Perkins 
In-Reply-To: <4F5728C0.8040803@alvestrand.no>
Date: Wed, 7 Mar 2012 09:43:46 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <88E14028-090E-4482-85F3-863C32647EA0@csperkins.org>
References: <20120305201759.24406.49431.idtracker@ietfa.amsl.com> <766FE318-7DE3-4481-B3C4-C45F2A94C881@csperkins.org> <4F55C25A.9010407@alvestrand.no>  <4F55DE35.6060104@alvestrand.no>  <4F5728C0.8040803@alvestrand.no>
To: Harald Alvestrand 
X-Mailer: Apple Mail (2.1257)
Cc: rtp-congestion@alvestrand.no, "avt@ietf.org WG" 
Subject: Re: [AVTCORE] [R-C] Fwd: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Mar 2012 09:43:55 -0000

On 7 Mar 2012, at 09:22, Harald Alvestrand wrote:

> On 03/06/2012 02:26 PM, Varun Singh wrote:
>> Hi Harald,
>>=20
>> Comment inline.
>>=20
>> On Tue, Mar 6, 2012 at 11:51, Harald Alvestrand =
 wrote:
>>> On 03/06/2012 10:21 AM, Varun Singh wrote:
>>>>> Security considerations (missing section): For an end node that
>>>>> implements
>>>>> this specification, an active attacker can cut the transmission by =
faking
>>>>> two RTCP packets that get accepted instead of the recipient's RTCP
>>>>> packets.
>>>>> This may be worthy of a note, and pointer to appropriate defenses.
>>>> This is a valid attack. However, if we consider no early-feedback =
(the
>>>> draft currently only follows RFC3550 timing rules) then the =
attacker's
>>>> second fake report may be ignored by the sender because it is too
>>>> early. Meanwhile, the actual receiver may get to deliver its RTCP =
RR.
>>>>=20
>>>>=20
>>>> Example:
>>>> SR               |                          |
>>>>         |                      I
>>>>=20
>>>> =
--------------------------------------------------------------------------=
--------------------------------->
>>>> time
>>>> RR   |                   F          |              F          |
>>>>    F              F      |
>>>>=20
>>>> | are valid SR and RR, F are Fake RTCPs (replaying the last valid =
RTCP
>>>> report). So, instead of waiting for 3 RTCP reports to arrive the
>>>> sender MUST wait two RTCP intervals?
>>> Yes, I think stating that the sender waits two RTCP intervals before =
drawing
>>> a conclusion is a reasonable defense against this version of the =
attack.
>>>=20
>>> Another interesting version is what happens if the attacker bumps up =
the
>>> "highest sequence number received" - the security considerations may =
want to
>>> say that RRs with a "highest sequence number received" larger than =
the
>>> highest sequence number sent MAY be part of an attack, so SHOULD be
>>> disregarded.
>> I am not sure if an endpoint reporting a HSN_received larger than the
>> HSN_sent trips any circuit breaker, but if the endpoint doesn't =
ignore
>> the report then the endpoint may reset its timeout counter.
> What could happen is this:
>=20
> Victim receiver:RTCP, HSN(low)
> Attacker: RTCP, HSN(high)
> Victim sender: OK, HSN is (high)
> Victim receiver:RTCP,  HSN(low+some)
> Victim sender: Oops, HSN did not increase
> Victim receiver:RTCP, HSN(low+some+some)
> Victim sener: Oops, HSN did not increase for two RTCP intervals. Shut =
down.
>=20
> One-packet denial of service.
>=20
> If HSN is always verified against last-sent, and the report is =
discarded as erroneous if it is higher than last-sent, this attack =
cannot occur.


Sure - the Extended Highest Sequence Number received needs to be =
compared with the sequence numbers being sent. This is also why you can =
get away with only using two RTCP packets to determine if there's =
persistent loss: you don't just check that the highest sequence numbers =
in the packets are non-increasing in isolation, you check that they =
don't increase to match the sequence number you send.=20

Maybe the draft need clarifying on this.


--=20
Colin Perkins
http://csperkins.org/




From harald@alvestrand.no  Wed Mar  7 02:38:43 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B9C21F8638 for ; Wed,  7 Mar 2012 02:38:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.229
X-Spam-Level: 
X-Spam-Status: No, score=-110.229 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, 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 XVojsJ1RclkF for ; Wed,  7 Mar 2012 02:38:42 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 87B2B21F8602 for ; Wed,  7 Mar 2012 02:38:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BD43F39E17B; Wed,  7 Mar 2012 11:38:41 +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 9hZnDTdMU-9O; Wed,  7 Mar 2012 11:38:41 +0100 (CET)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id DE3DF39E17A; Wed,  7 Mar 2012 11:38:40 +0100 (CET)
Message-ID: <4F573AB0.30105@alvestrand.no>
Date: Wed, 07 Mar 2012 11:38:40 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19
MIME-Version: 1.0
To: Colin Perkins 
References: <20120305201759.24406.49431.idtracker@ietfa.amsl.com> <766FE318-7DE3-4481-B3C4-C45F2A94C881@csperkins.org> <4F55C25A.9010407@alvestrand.no>  <4F55DE35.6060104@alvestrand.no>  <4F5728C0.8040803@alvestrand.no> <88E14028-090E-4482-85F3-863C32647EA0@csperkins.org>
In-Reply-To: <88E14028-090E-4482-85F3-863C32647EA0@csperkins.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: rtp-congestion@alvestrand.no, "avt@ietf.org WG" 
Subject: Re: [AVTCORE] [R-C] Fwd: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Mar 2012 10:38:43 -0000

On 03/07/2012 10:43 AM, Colin Perkins wrote:
> On 7 Mar 2012, at 09:22, Harald Alvestrand wrote:
>
>> On 03/06/2012 02:26 PM, Varun Singh wrote:
>>> Hi Harald,
>>>
>>> Comment inline.
>>>
>>> On Tue, Mar 6, 2012 at 11:51, Harald Alvestrand   wrote:
>>>> On 03/06/2012 10:21 AM, Varun Singh wrote:
>>>>>> Security considerations (missing section): For an end node that
>>>>>> implements
>>>>>> this specification, an active attacker can cut the transmission by faking
>>>>>> two RTCP packets that get accepted instead of the recipient's RTCP
>>>>>> packets.
>>>>>> This may be worthy of a note, and pointer to appropriate defenses.
>>>>> This is a valid attack. However, if we consider no early-feedback (the
>>>>> draft currently only follows RFC3550 timing rules) then the attacker's
>>>>> second fake report may be ignored by the sender because it is too
>>>>> early. Meanwhile, the actual receiver may get to deliver its RTCP RR.
>>>>>
>>>>>
>>>>> Example:
>>>>> SR               |                          |
>>>>>          |                      I
>>>>>
>>>>> ----------------------------------------------------------------------------------------------------------->
>>>>> time
>>>>> RR   |                   F          |              F          |
>>>>>     F              F      |
>>>>>
>>>>> | are valid SR and RR, F are Fake RTCPs (replaying the last valid RTCP
>>>>> report). So, instead of waiting for 3 RTCP reports to arrive the
>>>>> sender MUST wait two RTCP intervals?
>>>> Yes, I think stating that the sender waits two RTCP intervals before drawing
>>>> a conclusion is a reasonable defense against this version of the attack.
>>>>
>>>> Another interesting version is what happens if the attacker bumps up the
>>>> "highest sequence number received" - the security considerations may want to
>>>> say that RRs with a "highest sequence number received" larger than the
>>>> highest sequence number sent MAY be part of an attack, so SHOULD be
>>>> disregarded.
>>> I am not sure if an endpoint reporting a HSN_received larger than the
>>> HSN_sent trips any circuit breaker, but if the endpoint doesn't ignore
>>> the report then the endpoint may reset its timeout counter.
>> What could happen is this:
>>
>> Victim receiver:RTCP, HSN(low)
>> Attacker: RTCP, HSN(high)
>> Victim sender: OK, HSN is (high)
>> Victim receiver:RTCP,  HSN(low+some)
>> Victim sender: Oops, HSN did not increase
>> Victim receiver:RTCP, HSN(low+some+some)
>> Victim sener: Oops, HSN did not increase for two RTCP intervals. Shut down.
>>
>> One-packet denial of service.
>>
>> If HSN is always verified against last-sent, and the report is discarded as erroneous if it is higher than last-sent, this attack cannot occur.
>
> Sure - the Extended Highest Sequence Number received needs to be compared with the sequence numbers being sent. This is also why you can get away with only using two RTCP packets to determine if there's persistent loss: you don't just check that the highest sequence numbers in the packets are non-increasing in isolation, you check that they don't increase to match the sequence number you send.
>
> Maybe the draft need clarifying on this.
Or just make it explicit that this is obvious sense, but not made 
explicit elsewhere.
It's kind of a clarification to RFC 3550 section A.2 - the checks there 
seem to have been written at a time when you did not consider the 
possibility that someone was out to get you...




From bo.burman@ericsson.com  Thu Mar  8 05:01:04 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C564221F866D for ; Thu,  8 Mar 2012 05:01:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.448
X-Spam-Level: 
X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7SYVTOxXA6M for ; Thu,  8 Mar 2012 05:01:03 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6522B21F8685 for ; Thu,  8 Mar 2012 05:01:03 -0800 (PST)
X-AuditID: c1b4fb39-b7bf2ae0000069a1-40-4f58ad8e60b6
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C5.34.27041.E8DA85F4; Thu,  8 Mar 2012 14:01:02 +0100 (CET)
Received: from ESESSCMS0361.eemea.ericsson.se ([169.254.1.209]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 8 Mar 2012 14:01:02 +0100
From: Bo Burman 
To: "avt@ietf.org" 
Date: Thu, 8 Mar 2012 14:01:01 +0100
Thread-Topic: New draft on controlling codec parameters; draft-westerlund-avtext-codec-operation-point-00
Thread-Index: Acz9K4Mk4Ni1QiFCRPyc3aPqDf2Qvg==
Message-ID: <05F760EF51FA6A4F804F9759C239313A3A72087207@ESESSCMS0361.eemea.ericsson.se>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: sv-SE, en-US
Content-Type: multipart/alternative; boundary="_000_05F760EF51FA6A4F804F9759C239313A3A72087207ESESSCMS0361e_"
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: [AVTCORE] New draft on controlling codec parameters; draft-westerlund-avtext-codec-operation-point-00
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: "avtext@ietf.org" 
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Mar 2012 13:01:04 -0000

--_000_05F760EF51FA6A4F804F9759C239313A3A72087207ESESSCMS0361e_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

My colleagues and I have a proposal for an RTCP extension to AVPF CCM allow=
ing a media receiver to dynamically ask the media sender to use a certain c=
odec configuration (called a Codec Operation Point, COP). We see this as be=
ing used both in WEBRTC (RTCWEB WG) and Video Conferencing / Telepresence (=
CLUE WG). Additional applications are expected.

The proposal is not intended to replace or conflict with codec negotiation =
taking place during SDP Offer / Answer, but rather optimize and fine-tune c=
odec usage within the limits established by SDP O/A.

The draft defines a set of what is believed generally useful and reasonably=
 codec-independent set of parameters. Those parameters can be used by a med=
ia sender to describe the codec configuration (Codec Operation Point) used =
to generate the media stream to the media receiver. The media receiver can =
in turn examine the parameter values in the announced Codec Operation Point=
 and use the same set of defined parameters to ask the media sender to use =
other, more suitable values for those parameters. It is the media sender's =
responsibility to decide if such request can be honored or not. If the requ=
est is accepted, the media sender then changes the media stream accordingly=
 and sends another Codec Operation Point announcement with the changed para=
meter values.

One possible example is to let a video media receiver control the encoded v=
ideo resolution based on decoded video window display size.

https://datatracker.ietf.org/doc/draft-westerlund-avtext-codec-operation-po=
int/

This draft is designed to:

* Allow for minimal implementation. The media sender need only announce COP=
 support for the payload types it wishes to make controllable. It is not a =
requirement to support all parameter types, and receive support for each pa=
rameter type is signaled explicitly in SDP. Unsupported parameter types can=
 safely be ignored.

* Be extensible. It is for example easy to define more parameter types in e=
xtensions to this draft. New message types and result codes can also be def=
ined as extensions.

* Be possible to use both in point-to-point, in multipoint (conferencing), =
and even some specific multicast situations.

* Be responsive. The user at the media receiver can request and experience =
the result of changes in a dynamic and interactive fashion. The codec contr=
ol signaling need only traverse the media path and uses the most responsive=
 RTCP mode available, AVPF.

* Support single layer as well as multi-layered (scalable) media streams. A=
 multi-layered media stream can easily be described and configured by using=
 multiple, simultaneously active Codec Operation Points.

* Be as media and codec agnostic as possible. The defined parameter types a=
re chosen to be as generic as possible and should therefore apply to many d=
ifferent codecs. Some media type awareness is however included in the chose=
n set of parameters.

* Be robust. It leaves to the media sender to decide exactly what is change=
d. A media sender that receives a request to set a certain value for a para=
meter can choose another value that is seen as more appropriate, or even ch=
oose to not change anything at all. "Unreasonable" requests can thus safely=
 be ignored.

* Be flexible in what type of parameter value restrictions that can be desc=
ribed. A request can use either an exact single value, an open-ended minimu=
m or maximum restriction, or a range of values. It is also possible to use =
a "target" value, standalone or in combination with a range, to express a p=
reference. It is even possible to specify a set of prioritized, alternative=
 configurations that the media sender can choose from.

* Allow for advertised, synchronized configuration changes. The Codec Opera=
tion Point notification can be time stamped some time into the future, allo=
wing the media receiver some time for informed preparation (if needed) befo=
re the actual media stream change occurs.

We would like to see this work as WG item in AVTEXT WG.

If you have input, please provide comments to the AVTEXT WG (reply-to set t=
here).

Best Regards

Bo Burman

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7141311
F=E4r=F6gatan 6                 | Mobile +46 73 0949021
SE-164 80 Stockholm, Sweden | mailto: bo.burman@ericsson.com
----------------------------------------------------------------------



--_000_05F760EF51FA6A4F804F9759C239313A3A72087207ESESSCMS0361e_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi,


 


My colleagues and I have a proposal for an RTCP extension to AVPF CCM =
allowing a media receiver to dynamically ask the media sender to use a cert=
ain codec configuration (called a Codec Operation Point, COP). We see this =
as being used both in WEBRTC (RTCWEB
WG) and Video Conferencing / Telepresence (CLUE WG). Additional application=
s are expected.


 


The proposal is not intended to replace or conflict with codec negotia=
tion taking place during SDP Offer / Answer, but rather optimize and fine-t=
une codec usage within the limits established by SDP O/A.


 


The draft defines a set of what is believed generally useful and reaso=
nably codec-independent set of parameters. Those parameters can be used by =
a media sender to describe the codec configuration (Codec Operation Point) =
used to generate the media stream
to the media receiver. The media receiver can in turn examine the parameter=
 values in the announced Codec Operation Point and use the same set of defi=
ned parameters to ask the media sender to use other, more suitable values f=
or those parameters. It is the media
sender's responsibility to decide if such request can be honored or not. If=
 the request is accepted, the media sender then changes the media stream ac=
cordingly and sends another Codec Operation Point announcement with the cha=
nged parameter values.


 


One possible example is to let a video media receiver control the enco=
ded video resolution based on decoded video window display size.


 



 


This draft is designed to:


 


* Allow for minimal implementation. The media sender need only announc=
e COP support for the payload types it wishes to make controllable. It is n=
ot a requirement to support all parameter types, and receive support for ea=
ch parameter type is signaled explicitly
in SDP. Unsupported parameter types can safely be ignored.


 


* Be extensible. It is for example easy to define more parameter types=
 in extensions to this draft. New message types and result codes can also b=
e defined as extensions.


 


* Be possible to use both in point-to-point, in multipoint (conferenci=
ng), and even some specific multicast situations.


 


* Be responsive. The user at the media receiver can request and experi=
ence the result of changes in a dynamic and interactive fashion. The codec =
control signaling need only traverse the media path and uses the most respo=
nsive RTCP mode available, AVPF.


 


* Support single layer as well as multi-layered (scalable) media strea=
ms. A multi-layered media stream can easily be described and configured by =
using multiple, simultaneously active Codec Operation Points.


 


* Be as media and codec agnostic as possible. The defined parameter ty=
pes are chosen to be as generic as possible and should therefore apply to m=
any different codecs. Some media type awareness is however included in the =
chosen set of parameters.


 


* Be robust. It leaves to the media sender to decide exactly what is c=
hanged. A media sender that receives a request to set a certain value for a=
 parameter can choose another value that is seen as more appropriate, or ev=
en choose to not change anything
at all. "Unreasonable" requests can thus safely be ignored.


 


* Be flexible in what type of parameter value restrictions that can be=
 described. A request can use either an exact single value, an open-ended m=
inimum or maximum restriction, or a range of values. It is also possible to=
 use a "target" value, standalone
or in combination with a range, to express a preference. It is even possibl=
e to specify a set of prioritized, alternative configurations that the medi=
a sender can choose from.


 


* Allow for advertised, synchronized configuration changes. The Codec =
Operation Point notification can be time stamped some time into the future,=
 allowing the media receiver some time for informed preparation (if needed)=
 before the actual media stream
change occurs.


 


We would like to see this work as WG item in AVTEXT WG.


 


If you have input, please provide comments to the AVTEXT WG (reply-to =
set there).


 


Best Regards


 


Bo Burman


 


----------------------------------------------------------------------=



Multimedia Technologies, Ericsson Research EAB/TVM


----------------------------------------------------------------------=



Ericsson AB          =
;       | Phone  +46 10 7141311

F=E4r=F6gatan 6         &=
nbsp;       | Mobile +46 73 0949021


SE-164 80 Stockholm, Sweden | mailto: bo.burman@ericsson.com


----------------------------------------------------------------------=



 


 





--_000_05F760EF51FA6A4F804F9759C239313A3A72087207ESESSCMS0361e_--

From rjsparks@nostrum.com  Thu Mar  8 11:34:17 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7733621E8021 for ; Thu,  8 Mar 2012 11:34:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.546
X-Spam-Level: 
X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9FYwsMRv1SP for ; Thu,  8 Mar 2012 11:34:17 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A993421E8019 for ; Thu,  8 Mar 2012 11:34:14 -0800 (PST)
Received: from unexplicable.local (pool-71-170-125-181.dllstx.fios.verizon.net [71.170.125.181]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q28JYDc8015925 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 8 Mar 2012 13:34:14 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Message-ID: <4F5909B5.9010603@nostrum.com>
Date: Thu, 08 Mar 2012 13:34:13 -0600
From: Robert Sparks 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: avt@ietf.org, draft-ietf-avtcore-ecn-for-rtp@tools.ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 71.170.125.181 is authenticated by a trusted mechanism)
Subject: [AVTCORE] AD review: draft-ietf-avtcore-ecn-for-rtp-06
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Mar 2012 19:34:17 -0000

Summary: Ready for IETF LC with minor issues to address during LC. Watch 
for the IETF LC announcement shortly.

Chairs/shepherd: Please request a review from the SDP directorate.

Please treat these as LC comments:

*) ietf-avt-rtp-no-op is very expired. Are there plans to progress it? 
If not, can you point to something else?

*) Section 5.2's definition of "Block Length" has a bug. This length is 
counting 32-bit words. "not a multiple of five octets" does not make 
sense. It should simply be "not a multiple of five". It might also help 
to say "The number of 32-bit words in the report block" instead of "The 
length of the report block" as the first sentence of the definition?

*) In section 5.1, why is this sentence using 2119: "Thus handling of 
wrapping of these counters MUST be supported".  It's not clear what "be 
supported" means, so it's hard to know what the MUST is constraining.
Is this anything more than a implementation consideration saying "don't 
write code that will crash when
the counter overflows"?

*) Section 7.3.3 paragraph 2. Given this MUST, was the intent to require 
that any such "other reactions"
only be deployed if they were standardized? In the IETF? Can this be 
clarified?

*) In section 10.6, What name are you asking IANA to put in the 
attribute registry? It's not obvious when
reading section 7.2.2. Do you want that to be "ECN", or would it be 
better if it were "ECN-CHECK"?

*) Why isn't the reference to RFC4566 (SDP) normative?

Nits:

Section 1 paragraph 2 first sentence: "is getting attention" will not 
age well.
Section 7.2.2 last paragraph: "SHALL be discard"->"SHALL be discarded"
Section 7.4 first paragraph: How do you reduce an assumption? Should 
this say "The probability this assumption is correct" is reduced?
Section 7.4.1 3rd paragraph: "then the two possible"->"then two possible"
Section 11 first "Denial of service" section: "sender disable the 
usage"->"sender disables the usage"



From iesg-secretary@ietf.org  Thu Mar  8 12:26:28 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D35221F8649; Thu,  8 Mar 2012 12:26:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.55
X-Spam-Level: 
X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 fM0lmgRWlurw; Thu,  8 Mar 2012 12:26:28 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB6E21F866E; Thu,  8 Mar 2012 12:26:28 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120308202628.22298.45519.idtracker@ietfa.amsl.com>
Date: Thu, 08 Mar 2012 12:26:28 -0800
Cc: avt@ietf.org
Subject: [AVTCORE] Last Call:  (Explicit	Congestion Notification (ECN) for RTP over UDP) to Proposed Standard
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ietf@ietf.org
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Mar 2012 20:26:28 -0000

The IESG has received a request from the Audio/Video Transport Core
Maintenance WG (avtcore) to consider the following document:
- 'Explicit Congestion Notification (ECN) for RTP over UDP'
   as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-03-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This memo specifies how Explicit Congestion Notification (ECN) can be
   used with the Real-time Transport Protocol (RTP) running over UDP,
   using RTP Control Protocol (RTCP) as a feedback mechanism.  It
   defines a new RTCP Extended Report (XR) block for periodic ECN
   feedback, a new RTCP transport feedback message for timely reporting
   of congestion events, and a Session Traversal Utilities for NAT
   (STUN) extension used in the optional initialization method using
   Interactive Connectivity Establishment (ICE).  Signalling and
   procedures for negotiation of capabilities and initialization methods
   are also defined.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-avtcore-ecn-for-rtp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-avtcore-ecn-for-rtp/ballot/


No IPR declarations have been submitted directly on this I-D.



From internet-drafts@ietf.org  Thu Mar  8 23:53:30 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7882121F8618; Thu,  8 Mar 2012 23:53:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.573
X-Spam-Level: 
X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 XCfAKeMbuoeQ; Thu,  8 Mar 2012 23:53:29 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8040321F855A; Thu,  8 Mar 2012 23:53:29 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120309075329.797.69155.idtracker@ietfa.amsl.com>
Date: Thu, 08 Mar 2012 23:53:29 -0800
Cc: avt@ietf.org
Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-feedback-supression-rtp-15.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Mar 2012 07:53:30 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Audio/Video Transport Core Maintenanc=
e Working Group of the IETF.

	Title           : RTCP Extension for Third-party Loss Report
	Author(s)       : Qin Wu
                          Frank Xia
                          Roni Even
	Filename        : draft-ietf-avtcore-feedback-supression-rtp-15.txt
	Pages           : 19
	Date            : 2012-03-08

   In a large RTP session using the RTCP feedback mechanism defined in
   RFC 4585, a feedback target may experience transient overload if some
   event causes a large number of receivers to send feedback at once.
   This overload is usually avoided by ensuring that feedback reports
   are forwarded to all receivers, allowing them to avoid sending
   duplicate feedback reports.  However, there are cases where it is not
   recommended to forward feedback reports, and this may allow feedback
   implosion.  This memo discusses these cases and defines a new RTCP
   third-party loss report that can be used to inform receivers that the
   feedback target is aware of some loss event, allowing them to
   suppress feedback.  Associated SDP signalling is also defined.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-=
rtp-15.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-r=
tp-15.txt


From internet-drafts@ietf.org  Fri Mar  9 04:22:37 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F3621F862B; Fri,  9 Mar 2012 04:22:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.58
X-Spam-Level: 
X-Spam-Status: No, score=-98.58 tagged_above=-999 required=5 tests=[AWL=-3.957, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, 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 4OT7mVpDdeEi; Fri,  9 Mar 2012 04:22:37 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5071021F8624; Fri,  9 Mar 2012 04:22:37 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120309122237.25104.56533.idtracker@ietfa.amsl.com>
Date: Fri, 09 Mar 2012 04:22:37 -0800
Cc: avt@ietf.org
Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-idms-03.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Mar 2012 12:22:37 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Audio/Video Transport Core Maintenanc=
e Working Group of the IETF.

	Title           : RTCP for inter-destination media synchronization
	Author(s)       : Ray van Brandenburg
                          Hans Stokking
                          Fernando Boronat
                          Mario Montagud
                          Kevin Gross
	Filename        : draft-ietf-avtcore-idms-03.txt
	Pages           : 21
	Date            : 2012-03-09

   This document gives information on an RTCP Packet Type and RTCP XR
   Block Type including associated SDP parameters for Inter-Destination
   Media Synchronization (IDMS).  The RTCP XR Block Type, registered
   with IANA based on an ETSI specification, is used to collect media
   playout information from participants in a group playing-out
   (watching, listening, etc.) a specific RTP media stream.  The RTCP
   packet type specified by this document is used to distribute a common
   target playout point to which all the distributed receivers, sharing
   a media experience, can synchronize.

   Typical use cases in which IDMS is usefull are social TV, shared
   service control (i.e. applications where two or more geographically
   separated users are watching a media stream together), distance
   learning, networked video walls, networked loudspeakers, etc.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avtcore-idms-03.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-idms-03.txt


From ray.vanbrandenburg@tno.nl  Fri Mar  9 04:32:20 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F4921F863E for ; Fri,  9 Mar 2012 04:32:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.713
X-Spam-Level: ***
X-Spam-Status: No, score=3.713 tagged_above=-999 required=5 tests=[AWL=-3.759,  BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKl8N0+8PYXZ for ; Fri,  9 Mar 2012 04:32:20 -0800 (PST)
Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id DB25721F8629 for ; Fri,  9 Mar 2012 04:32:19 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.73,558,1325458800"; d="scan'208";a="14723451"
Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1b.tno.nl with ESMTP; 09 Mar 2012 13:32:05 +0100
Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.160]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0283.003; Fri, 9 Mar 2012 13:32:05 +0100
From: "Brandenburg, R. (Ray) van" 
To: "avt@ietf.org" 
Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avtcore-idms-03.txt
Thread-Index: AQHM/e9WZrCbhMWfl0uMWOmjS+SZrZZh49Zw
Date: Fri, 9 Mar 2012 12:32:04 +0000
Message-ID: 
References: <20120309122237.25104.56533.idtracker@ietfa.amsl.com>
In-Reply-To: <20120309122237.25104.56533.idtracker@ietfa.amsl.com>
Accept-Language: en-US, nl-NL
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [134.221.225.191]
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-idms-03.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Mar 2012 12:32:21 -0000

Hi all,

As you can see, we've uploaded a new version of the IDMS draft.=20

http://www.ietf.org/internet-drafts/draft-ietf-avtcore-idms-03.txt
Diff from -02: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-idms=
-03.txt

The main difference from the last version is that we moved all clock-source=
 related stuff to a separate draft (draft-williams-avtcore-clksrc-00), as a=
greed during the Taipei meeting. This way, we have a more modular approach.=
 Furthermore, we have done a clean-up of the rest of the document, especial=
ly regarding language and terminology.=20

During the Paris meeting, we hope to present both the Clock Source draft an=
d the changes to the IDMS draft.=20

Best regards,

Ray van Brandenburg



-----Original Message-----
From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of inter=
net-drafts@ietf.org
Sent: vrijdag 9 maart 2012 13:23
To: i-d-announce@ietf.org
Cc: avt@ietf.org
Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-idms-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Audio/Video Transport Core Maintenanc=
e Working Group of the IETF.

	Title           : RTCP for inter-destination media synchronization
	Author(s)       : Ray van Brandenburg
                          Hans Stokking
                          Fernando Boronat
                          Mario Montagud
                          Kevin Gross
	Filename        : draft-ietf-avtcore-idms-03.txt
	Pages           : 21
	Date            : 2012-03-09

   This document gives information on an RTCP Packet Type and RTCP XR
   Block Type including associated SDP parameters for Inter-Destination
   Media Synchronization (IDMS).  The RTCP XR Block Type, registered
   with IANA based on an ETSI specification, is used to collect media
   playout information from participants in a group playing-out
   (watching, listening, etc.) a specific RTP media stream.  The RTCP
   packet type specified by this document is used to distribute a common
   target playout point to which all the distributed receivers, sharing
   a media experience, can synchronize.

   Typical use cases in which IDMS is usefull are social TV, shared
   service control (i.e. applications where two or more geographically
   separated users are watching a media stream together), distance
   learning, networked video walls, networked loudspeakers, etc.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avtcore-idms-03.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-idms-03.txt

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt
This e-mail and its contents are subject to the DISCLAIMER at http://www.tn=
o.nl/emaildisclaimer


From jonathan@vidyo.com  Fri Mar  9 15:59:22 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A456221F84D2 for ; Fri,  9 Mar 2012 15:59:22 -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 tnpjnCohFWOI for ; Fri,  9 Mar 2012 15:59:22 -0800 (PST)
Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 0E40B21F84BF for ; Fri,  9 Mar 2012 15:59:22 -0800 (PST)
Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 60725553B25 for ; Fri,  9 Mar 2012 18:59:21 -0500 (EST)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from HUB023.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id F2C3B553B5F for ; Fri,  9 Mar 2012 18:59:20 -0500 (EST)
Received: from BE235.mail.lan ([10.110.32.235]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Fri, 9 Mar 2012 18:59:14 -0500
From: Jonathan Lennox 
To: IETF AVTCore WG 
Date: Fri, 9 Mar 2012 18:59:19 -0500
Thread-Topic: I-D Action: draft-lennox-avtcore-rtp-topo-offer-answer-00.txt
Thread-Index: Acz+UKR6NWmv24w7TpinCrioOF59zA==
Message-ID: <3A00EA94-E3D3-404A-8283-599D156481D8@vidyo.com>
References: <20120305215535.22939.91509.idtracker@ietfa.amsl.com>
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
Subject: [AVTCORE] Fwd: I-D Action: draft-lennox-avtcore-rtp-topo-offer-answer-00.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Mar 2012 23:59:22 -0000

Hi, all -- I've submitted this draft discussing the interaction of SDP Offe=
r/Answer with RTP topologies -- specifically, why the RTP topology Topo-Tra=
nsport-Translator can't be created with offer/answer, and why this is actua=
lly a good thing.

This is a generalization of a some issues that came up in the discussion of=
 BUNDLE in Taipei.

Comments are welcome.

Begin forwarded message:

> From: "internet-drafts@ietf.org" 
> Date: March 5, 2012 4:55:35 PM EST
> To: "i-d-announce@ietf.org" 
> Subject: I-D Action: draft-lennox-avtcore-rtp-topo-offer-answer-00.txt
> Reply-To: "internet-drafts@ietf.org" 
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
>=20
> 	Title           : Real-Time Transport Protocol (RTP) Topology Considerat=
ions for Offer/ Answer-Initiated Sessions.
> 	Author(s)       : Jonathan Lennox
> 	Filename        : draft-lennox-avtcore-rtp-topo-offer-answer-00.txt
> 	Pages           : 11
> 	Date            : 2012-03-05
>=20
>   This document discusses a number of considerations related to the
>   topologies of Real-Time Transport Protocol (RTP) sessions initated
>   using the Session Description (SDP) unicast Offer/Answer Model,
>   especially as applied to source-multiplexed sessions.
>=20
>   The primary observation is that certain topologies cannot be created
>   by unicast SDP Offer/Answer.  Notably, the it is not possible to
>   negotiate the topology that RFC 5117 calls Topo-Transport-Translator
>   (or "relay").
>=20
>   As a consequence of this limitation, certain topological assumptions
>   can safely be made for RTP sessions initiated using unicast SDP
>   Offer/Answer; and therefore, certain optimizations to RTP are
>   possible in such sessions.  This document also describes the
>   optimizations that these assumptions make possible.
>=20
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-lennox-avtcore-rtp-topo-offer-a=
nswer-00.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-lennox-avtcore-rtp-topo-offer-an=
swer-00.txt
>=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
>=20

--
Jonathan Lennox
jonathan@vidyo.com



From magnus.westerlund@ericsson.com  Sat Mar 10 02:38:04 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11FD21F866B for ; Sat, 10 Mar 2012 02:38:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.355
X-Spam-Level: 
X-Spam-Status: No, score=-110.355 tagged_above=-999 required=5 tests=[AWL=0.244, 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 KfdBNABXoNpN for ; Sat, 10 Mar 2012 02:38:04 -0800 (PST)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id EAB6C21F8668 for ; Sat, 10 Mar 2012 02:38:03 -0800 (PST)
X-AuditID: c1b4fb3d-b7c6fae0000045c0-3d-4f5b2f0a95bd
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 77.43.17856.A0F2B5F4; Sat, 10 Mar 2012 11:38:02 +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.213.0; Sat, 10 Mar 2012 11:38:01 +0100
Message-ID: <4F5B2F09.2090704@ericsson.com>
Date: Sat, 10 Mar 2012 11:38:01 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: IETF AVTCore WG 
X-Enigmail-Version: 1.3.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Subject: [AVTCORE] Regarding draft-ietf-avtcore-feedback-supression-rtp-15
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 10 Mar 2012 10:38:04 -0000

Hi,

Qin Wu has been very diligent in addressing raised comments. I want to
state that I believe that this latest version do address the ADs
comments in a reasonable way. I do want to point out to the WG that the
authors choice of how to resolve one issue was to remove the whole
problematic sentence. I personally believe this is right, but if any in
the WG thinks it is problematic then speak up during the IETF last call.

   In other words, receivers MAY ignore RTCP TPLR messages, but SHOULD
   react to them unless they have good reason to still send	
   feedback messages despite having been requested to suppress them.

Cheers

Magnus Westerlund
AVTCORE WG chair

----------------------------------------------------------------------
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 rjsparks@nostrum.com  Sat Mar 10 07:49:24 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5C521F8599 for ; Sat, 10 Mar 2012 07:49:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.548
X-Spam-Level: 
X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.052, 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 TFjvmhOHaRQg for ; Sat, 10 Mar 2012 07:49:24 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1C55D21F851D for ; Sat, 10 Mar 2012 07:49:23 -0800 (PST)
Received: from unexplicable.local (pool-71-170-125-181.dllstx.fios.verizon.net [71.170.125.181]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q2AFnNvM042936 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 10 Mar 2012 09:49:23 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Message-ID: <4F5B7804.1040208@nostrum.com>
Date: Sat, 10 Mar 2012 09:49:24 -0600
From: Robert Sparks 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: avt@ietf.org
References: <20120309075329.797.50670.idtracker@ietfa.amsl.com>
In-Reply-To: <20120309075329.797.50670.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 71.170.125.181 is authenticated by a trusted mechanism)
Cc: avtcore-chairs@tools.ietf.org, draft-ietf-avtcore-feedback-supression-rtp@tools.ietf.org
Subject: Re: [AVTCORE] New Version Notification - draft-ietf-avtcore-feedback-supression-rtp-15.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 10 Mar 2012 15:49:24 -0000

I've requested IETFLC on this version.

RjS

On 3/9/12 1:53 AM, internet-drafts@ietf.org wrote:
> New version (-15) has been submitted for draft-ietf-avtcore-feedback-supression-rtp-15.txt.
> http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-rtp-15.txt
> Sub state has been changed to<b>AD Followup</b> from<b>Revised ID Needed</b>
>
> Diff from previous version:
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-feedback-supression-rtp-15
>
> IETF Secretariat.

From abegen@cisco.com  Sat Mar 10 19:39:35 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F8B21F84A5 for ; Sat, 10 Mar 2012 19:39:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.377
X-Spam-Level: 
X-Spam-Status: No, score=-10.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 xi8KebedlYc3 for ; Sat, 10 Mar 2012 19:39:35 -0800 (PST)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id BC9CE21F848B for ; Sat, 10 Mar 2012 19:39:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=2136; q=dns/txt; s=iport; t=1331437174; x=1332646774; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=AVpJveJ4V1rceG8TGUqeFaiee47KQYl49KRCae2Ny08=; b=maMAkWrh/HatVs0rxxVShJ9hOuZ57+HaBCO4KShfGmvzjB/lgn4anoEu V3tTP6Ayi5D3rha64mRQpTSmNQQoExGhNEH0Sy1WmQulkeXcH3lPz5gZ+ iUaGAp0p32tVR5EOZt8UTCV4+kXrhNYJUSR+tYHkjj0vVygvUQzpwKSfg w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAB8eXE+rRDoH/2dsb2JhbABChTevDnuBB4IJAQEBBBIBEBFDDgQCAQgRBAEBAwIGHQMCAgIwFAEGAQEFAwIEEwgah2cBC5wDAYxrkREEgS+OPDNjBKVvgmM
X-IronPort-AV: E=Sophos;i="4.73,565,1325462400"; d="scan'208";a="35424000"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 11 Mar 2012 03:39:34 +0000
Received: from xht-rcd-x02-p.cisco.com (xht-rcd-x02-p.cisco.com [173.37.178.213]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2B3dYVp020991 for ; Sun, 11 Mar 2012 03:39:34 GMT
Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.137]) by xht-rcd-x02-p.cisco.com ([173.37.178.213]) with mapi id 14.02.0283.003; Sat, 10 Mar 2012 19:39:33 -0800
From: "Ali C. Begen (abegen)" 
To: "avt@ietf.org" 
Thread-Topic: New Version Notification for draft-begen-avtcore-rtp-duplication-01.txt
Thread-Index: AQHM/zgiW3Ga/7ja406iAvYi8fmwJZZkcg3w
Date: Sun, 11 Mar 2012 03:39:32 +0000
Message-ID: 
References: <20120311033623.30342.94667.idtracker@ietfa.amsl.com>
In-Reply-To: <20120311033623.30342.94667.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [173.37.178.200]
x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18766.001
x-tm-as-result: No--25.558200-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: [AVTCORE] FW: New Version Notification for	draft-begen-avtcore-rtp-duplication-01.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 11 Mar 2012 03:39:35 -0000

V2UgcmV2aXNlZCB0aGUgUlRQIGR1cGxpY2F0aW9uIGRyYWZ0IGFuZCBwbGFuIHRvIHByZXNlbnQg
aXQgaW4gdGhlIEFWVCBzZXNzaW9uIGZvciBXRyBhZG9wdGlvbi4gQ29tbWVudHMgYXJlIHdlbGNv
bWUuDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1iZWdlbi1hdnRjb3Jl
LXJ0cC1kdXBsaWNhdGlvbi8NCg0KLWFjYmVnZW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0
c0BpZXRmLm9yZ10gDQpTZW50OiBTYXR1cmRheSwgTWFyY2ggMTAsIDIwMTIgMTA6MzYgUE0NClRv
OiBBbGkgQy4gQmVnZW4gKGFiZWdlbikNCkNjOiBjc3BAY3NwZXJraW5zLm9yZw0KU3ViamVjdDog
TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1iZWdlbi1hdnRjb3JlLXJ0cC1kdXBs
aWNhdGlvbi0wMS50eHQNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWJlZ2VuLWF2dGNv
cmUtcnRwLWR1cGxpY2F0aW9uLTAxLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk
IGJ5IEFsaSBCZWdlbiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVu
YW1lOgkgZHJhZnQtYmVnZW4tYXZ0Y29yZS1ydHAtZHVwbGljYXRpb24NClJldmlzaW9uOgkgMDEN
ClRpdGxlOgkJIER1cGxpY2F0aW5nIFJUUCBTdHJlYW1zDQpDcmVhdGlvbiBkYXRlOgkgMjAxMi0w
My0xMA0KV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDEx
DQoNCkFic3RyYWN0Og0KICAgUGFja2V0IGxvc3MgaXMgdW5kZXNpcmFibGUgZm9yIHJlYWwtdGlt
ZSBtdWx0aW1lZGlhIHNlc3Npb25zLCBidXQgY2FuDQogICBvY2N1ciBkdWUgdG8gY29uZ2VzdGlv
biwgb3Igb3RoZXIgdW5wbGFubmVkIG5ldHdvcmsgb3V0YWdlcy4gIFRoaXMgaXMNCiAgIGVzcGVj
aWFsbHkgdHJ1ZSBmb3IgSVAgbXVsdGljYXN0IG5ldHdvcmtzLCB3aGVyZSBwYWNrZXQgbG9zcyBw
YXR0ZXJucw0KICAgY2FuIHZhcnkgZ3JlYXRseSBiZXR3ZWVuIHJlY2VpdmVycy4gIE9uZSB0ZWNo
bmlxdWUgdGhhdCBjYW4gYmUgdXNlZA0KICAgdG8gcmVjb3ZlciBmcm9tIHBhY2tldCBsb3NzIHdp
dGhvdXQgaW5jdXJyaW5nIHVuYm91bmRlZCBkZWxheSBmb3IgYWxsDQogICB0aGUgcmVjZWl2ZXJz
IGlzIHRvIGR1cGxpY2F0ZSB0aGUgcGFja2V0cyBhbmQgc2VuZCB0aGVtIGluIHNlcGFyYXRlDQog
ICByZWR1bmRhbnQgc3RyZWFtcy4gIFRoaXMgZG9jdW1lbnQgZXhwbGFpbnMgaG93IFJlYWwtdGlt
ZSBUcmFuc3BvcnQNCiAgIFByb3RvY29sIChSVFApIHN0cmVhbXMgY2FuIGJlIGR1cGxpY2F0ZWQg
d2l0aG91dCBicmVha2luZyBSVFAgbWVkaWENCiAgIHN0cmVhbXMsIG9yIFJUUCBDb250cm9sIFBy
b3RvY29sIChSVENQKSBydWxlcy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRo
ZSBJRVRGIFNlY3JldGFyaWF0DQo=

From ron.even.tlv@gmail.com  Sun Mar 11 16:07:15 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522C221F85D2 for ; Sun, 11 Mar 2012 16:07:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.445
X-Spam-Level: 
X-Spam-Status: No, score=-1.445 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, 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 fosRYrqRg7Zb for ; Sun, 11 Mar 2012 16:07:14 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFCB21F85A4 for ; Sun, 11 Mar 2012 16:06:54 -0700 (PDT)
Received: by wibhq7 with SMTP id hq7so2324849wib.13 for ; Sun, 11 Mar 2012 16:06:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=he8TBZ975LVyuVc/qx+FaKVPeYipOo1zRxb3sp9Bug4=; b=jdYIl8h8WnTzaX49J+vvNUwCk6aUIYJZ0tG37X5JylaDeBkQsbkzirT/pFANqebqF8 JZ2x/y9HvVHJQS6gFNKRnkpQg9x9r5YaymscaCVdA9UCBklUXAl+UvNxx19+/gyUtA87 HKyDqV4Sa5eyXZTyxvDEVC2/RpZp3xfHojbyRWMROZW1rD5h+z8ujYdkM4bDQPeZwewr dlACGC+aAt6yLpCQ8JQRNrCf7wEqQ5kgjjfY9H6jGw803aiF9rPP2QPolnKWAvDfHQd9 e5VAysyj8jzUnNfcI7FQkPPbBQehsicV3nvyt9C649Fs5hRCw1ZYbmv1l8VgPGMle6Sc rWJg==
Received: by 10.180.99.65 with SMTP id eo1mr22400969wib.13.1331507213380; Sun, 11 Mar 2012 16:06:53 -0700 (PDT)
Received: from windows8d787f9 (bzq-79-179-219-130.red.bezeqint.net. [79.179.219.130]) by mx.google.com with ESMTPS id d7sm49132325wiz.6.2012.03.11.16.06.51 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Mar 2012 16:06:52 -0700 (PDT)
From: "Roni Even" 
To: "'Jonathan Lennox'" , "'IETF AVTCore WG'" 
References: <20120305215535.22939.91509.idtracker@ietfa.amsl.com> <3A00EA94-E3D3-404A-8283-599D156481D8@vidyo.com>
In-Reply-To: <3A00EA94-E3D3-404A-8283-599D156481D8@vidyo.com>
Date: Mon, 12 Mar 2012 01:06:03 +0200
Message-ID: <4f5d300c.0755b40a.44ab.ffffc16a@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acz+UKR6NWmv24w7TpinCrioOF59zABh5Nzw
Content-Language: en-us
Subject: Re: [AVTCORE] Fwd: I-D Action:	draft-lennox-avtcore-rtp-topo-offer-answer-00.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 11 Mar 2012 23:07:15 -0000

Hi Jonathan,
I read the draft and I assume you are talking about a relay architecture
without signaling, is this the case, is it only for point to point?
If the Topo-Transport-Translator need also to relay to multiple parties you
need also for SRTP to discuss the key distribution and synchronization since
not all parties join at the same time. This is discussed in
drafty-ietf-avt-srtp-ekt.

As for the offer answer discussion in section 4 the central box can enforce
a single view which it calls the common mode. The participants who cannot
support this common mode are second class participants. The assumption is
that there will be at least a common audio mode (used to be G.711) or in
RTCWeb the mandatory audio codec so second class participants will have the
audio connection. The assumption is that most of the parameters you
specified in section 4 are not fixed values but maximum values and any value
bellow it is also supported.

I think that another issue that should be discussed in the topo-offer-answer
is how the offer size scales if there are multiple streams and if the SSRC
attribute is used to distribute the list of all participants for source
selection. You have some information in
draft-lennox-mmusic-sdp-source-selection but it does not discuss the issue
of the offer size. 

Roni Even 

> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of
> Jonathan Lennox
> Sent: Saturday, March 10, 2012 1:59 AM
> To: IETF AVTCore WG
> Subject: [AVTCORE] Fwd: I-D Action: draft-lennox-avtcore-rtp-topo-
> offer-answer-00.txt
> 
> Hi, all -- I've submitted this draft discussing the interaction of SDP
> Offer/Answer with RTP topologies -- specifically, why the RTP topology
> Topo-Transport-Translator can't be created with offer/answer, and why
> this is actually a good thing.
> 
> This is a generalization of a some issues that came up in the
> discussion of BUNDLE in Taipei.
> 
> Comments are welcome.
> 
> Begin forwarded message:
> 
> > From: "internet-drafts@ietf.org" 
> > Date: March 5, 2012 4:55:35 PM EST
> > To: "i-d-announce@ietf.org" 
> > Subject: I-D Action: draft-lennox-avtcore-rtp-topo-offer-answer-
> 00.txt
> > Reply-To: "internet-drafts@ietf.org" 
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >
> > 	Title           : Real-Time Transport Protocol (RTP) Topology
> Considerations for Offer/ Answer-Initiated Sessions.
> > 	Author(s)       : Jonathan Lennox
> > 	Filename        : draft-lennox-avtcore-rtp-topo-offer-answer-
> 00.txt
> > 	Pages           : 11
> > 	Date            : 2012-03-05
> >
> >   This document discusses a number of considerations related to the
> >   topologies of Real-Time Transport Protocol (RTP) sessions initated
> >   using the Session Description (SDP) unicast Offer/Answer Model,
> >   especially as applied to source-multiplexed sessions.
> >
> >   The primary observation is that certain topologies cannot be
> created
> >   by unicast SDP Offer/Answer.  Notably, the it is not possible to
> >   negotiate the topology that RFC 5117 calls Topo-Transport-
> Translator
> >   (or "relay").
> >
> >   As a consequence of this limitation, certain topological
> assumptions
> >   can safely be made for RTP sessions initiated using unicast SDP
> >   Offer/Answer; and therefore, certain optimizations to RTP are
> >   possible in such sessions.  This document also describes the
> >   optimizations that these assumptions make possible.
> >
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-lennox-avtcore-rtp-topo-
> offe
> > r-answer-00.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > This Internet-Draft can be retrieved at:
> > ftp://ftp.ietf.org/internet-drafts/draft-lennox-avtcore-rtp-topo-
> offer
> > -answer-00.txt
> >
> > _______________________________________________
> > 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
> >
> 
> --
> Jonathan Lennox
> jonathan@vidyo.com
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt


From tom.van_caenegem@alcatel-lucent.com  Mon Mar 12 02:42:55 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE3121F8713 for ; Mon, 12 Mar 2012 02:42:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.087
X-Spam-Level: 
X-Spam-Status: No, score=-7.087 tagged_above=-999 required=5 tests=[AWL=-1.438, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_75=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 4UhV+NNhHLhu for ; Mon, 12 Mar 2012 02:42:54 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 98D6B21F86EF for ; Mon, 12 Mar 2012 02:42:54 -0700 (PDT)
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 q2C9gpWU018363 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 12 Mar 2012 10:42:51 +0100
Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 12 Mar 2012 10:42:51 +0100
From: "Van Caenegem, Tom (Tom)" 
To: Magnus Westerlund , IETF AVTCore WG 
Date: Mon, 12 Mar 2012 10:42:50 +0100
Thread-Topic: [AVTCORE] Regarding draft-ietf-avtcore-feedback-supression-rtp-15
Thread-Index: Acz+qeNOr/0gHbQpR3WyBU/PKJGR1QBhzV+A
Message-ID: 
References: <4F5B2F09.2090704@ericsson.com>
In-Reply-To: <4F5B2F09.2090704@ericsson.com>
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: nl-NL, en-US
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: [AVTCORE] Regarding draft-ietf-avtcore-feedback-supression-rtp-15
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Mar 2012 09:42:55 -0000

Hi Magnus  (, Qin)


Version 15 makes the following three statements:


1)Section 3:

"When a receiver gets a RTCP TPLR message, it MUST follow the rules
for NACK suppression in RFC4585 [RFC4585]and refrain from sending a
feedback request (e.g., NACK or FIR) for the missing packets reported
in the message,which is dealt with in the same way as receiving NACK"

2)Section 3:

"A receiver may have sent a Feedback message according to the RTP/AVPF
scheduling algorithm of RFC4585 [RFC4585] before receiving a RTCP
TPLR message, but further feedback messages for those sequence
numbers SHOULD be suppressed after receiving the RTCP TPLR"


3)Section 7:

"Also note that endpoints that receive a Third Party Loss Report would
be well-advised to ignore it, unless the security is in place to
authenticate the sender of the Third Party Loss Report"


These statements are still not aligned with each other.=20

1) -> indicates that a TPLR message always results in FB suppression (MUST)=
, and aligned with RFC 4585

2) -> why does the case where a receiver sent a NACK before receiving a TPL=
R, represents an exception on the receiver behaviour defined in the 1st sta=
tement (SHOULD instead of MUST)

3) -> is effective a SHOULD for non-authenticated TPLR messages.
=20


Magnus, from your statement below, I take it that you propose a receiver be=
haviour different from the one defined in RFC 4585 (so SHOULD suppress feed=
back instead of MUST suppress feedback in RFC 4585).

If you do this , it requires some explicit reasoning that explains this dif=
ference , and explicit indication that this behaviour is different from fee=
dback suppression rule defined in RFC 4585.
Tom


-----Original Message-----
From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Magnu=
s Westerlund
Sent: zaterdag 10 maart 2012 11:38
To: IETF AVTCore WG
Subject: [AVTCORE] Regarding draft-ietf-avtcore-feedback-supression-rtp-15

Hi,

Qin Wu has been very diligent in addressing raised comments. I want to stat=
e that I believe that this latest version do address the ADs comments in a =
reasonable way. I do want to point out to the WG that the authors choice of=
 how to resolve one issue was to remove the whole problematic sentence. I p=
ersonally believe this is right, but if any in the WG thinks it is problema=
tic then speak up during the IETF last call.

   In other words, receivers MAY ignore RTCP TPLR messages, but SHOULD
   react to them unless they have good reason to still send=09
   feedback messages despite having been requested to suppress them.

Cheers

Magnus Westerlund
AVTCORE WG chair

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

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt

From albrecht.schwarz@alcatel-lucent.com  Mon Mar 12 04:46:32 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6F621F875A; Mon, 12 Mar 2012 04:46:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.533
X-Spam-Level: 
X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=1.562,  BAYES_00=-2.599, FRT_BELOW2=2.154, 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 eazRj-tDx1XZ; Mon, 12 Mar 2012 04:46:32 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id B640921F86EE; Mon, 12 Mar 2012 04:46:31 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2CBisoR027386 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 12 Mar 2012 12:46:29 +0100
Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.50]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 12 Mar 2012 12:46:23 +0100
From: "Schwarz, Albrecht (Albrecht)" 
To: "'Jonathan Lennox'" , "'IETF AVTCore WG'" 
Date: Mon, 12 Mar 2012 12:46:22 +0100
Thread-Topic: RTPTOPO & H.248; RE: [AVTCORE] Fwd: I-D Action: draft-lennox-avtcore-rtp-topo-offer-answer-00.txt
Thread-Index: Acz+UKR6NWmv24w7TpinCrioOF59zABh5NzwABrCenA=
Message-ID: <5F7BCCF5541B7444830A2288ABBEBC9621626AD838@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com>
References: <20120305215535.22939.91509.idtracker@ietfa.amsl.com> <3A00EA94-E3D3-404A-8283-599D156481D8@vidyo.com> <4f5d300c.0755b40a.44ab.ffffc16a@mx.google.com>
In-Reply-To: <4f5d300c.0755b40a.44ab.ffffc16a@mx.google.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE, en-US
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
Cc: megaco 
Subject: [AVTCORE] RTPTOPO & H.248; RE: Fwd: I-D Action: draft-lennox-avtcore-rtp-topo-offer-answer-00.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Mar 2012 11:46:33 -0000

Hello Jonathan,

like to open a separate email thread (because not related to Roni's comment=
s):

Scope of your draft is related to RTP TOPO considerations, complemented by =
SDP O/A exchange.=20
Like to note that this subject is also addressed by ITU-T SG16 Q.3 for "RTP=
 topology functions" located in decomposed gateways according H.248.
The work item is called
H.248.RTPTOPO "RTP topology dependent RTCP handling by H.248 Media Gateways=
 with IP Terminations"

You may find a draft document under e.g.
http://wftp3.itu.int/av-arch/avc-site/2009-2012/1202_Gen/AVD-4162.zip=20

There are some overlappings between your considerations and H.248.RTPTOPO, =
primarily on "topology awareness", "topology configuration/control".

H.248.RTPTOPO considers all your four indicated RTP topologies.
The SDP O/A procedures are processed by the H.248 Media Gateway Controller =
(MGC). The RTP functions are embedded in the H.248 Media Gateway.

Appendix I provides some initial ideas how the RTP topology could be contro=
lled via H.248 ("possibly triggered by SDP O/A").

Appendix II indicates also the correlation between SRTP vs RTP topologies.

Regards,
Albrecht


-----Original Message-----
From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni =
Even
Sent: Montag, 12. M=E4rz 2012 00:06
To: 'Jonathan Lennox'; 'IETF AVTCore WG'
Subject: Re: [AVTCORE] Fwd: I-D Action: draft-lennox-avtcore-rtp-topo-offer=
-answer-00.txt

Hi Jonathan,
I read the draft and I assume you are talking about a relay architecture
without signaling, is this the case, is it only for point to point?
If the Topo-Transport-Translator need also to relay to multiple parties you
need also for SRTP to discuss the key distribution and synchronization sinc=
e
not all parties join at the same time. This is discussed in
drafty-ietf-avt-srtp-ekt.

As for the offer answer discussion in section 4 the central box can enforce
a single view which it calls the common mode. The participants who cannot
support this common mode are second class participants. The assumption is
that there will be at least a common audio mode (used to be G.711) or in
RTCWeb the mandatory audio codec so second class participants will have the
audio connection. The assumption is that most of the parameters you
specified in section 4 are not fixed values but maximum values and any valu=
e
bellow it is also supported.

I think that another issue that should be discussed in the topo-offer-answe=
r
is how the offer size scales if there are multiple streams and if the SSRC
attribute is used to distribute the list of all participants for source
selection. You have some information in
draft-lennox-mmusic-sdp-source-selection but it does not discuss the issue
of the offer size.=20

Roni Even=20

> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of
> Jonathan Lennox
> Sent: Saturday, March 10, 2012 1:59 AM
> To: IETF AVTCore WG
> Subject: [AVTCORE] Fwd: I-D Action: draft-lennox-avtcore-rtp-topo-
> offer-answer-00.txt
>=20
> Hi, all -- I've submitted this draft discussing the interaction of SDP
> Offer/Answer with RTP topologies -- specifically, why the RTP topology
> Topo-Transport-Translator can't be created with offer/answer, and why
> this is actually a good thing.
>=20
> This is a generalization of a some issues that came up in the
> discussion of BUNDLE in Taipei.
>=20
> Comments are welcome.
>=20
> Begin forwarded message:
>=20
> > From: "internet-drafts@ietf.org" 
> > Date: March 5, 2012 4:55:35 PM EST
> > To: "i-d-announce@ietf.org" 
> > Subject: I-D Action: draft-lennox-avtcore-rtp-topo-offer-answer-
> 00.txt
> > Reply-To: "internet-drafts@ietf.org" 
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >
> > 	Title           : Real-Time Transport Protocol (RTP) Topology
> Considerations for Offer/ Answer-Initiated Sessions.
> > 	Author(s)       : Jonathan Lennox
> > 	Filename        : draft-lennox-avtcore-rtp-topo-offer-answer-
> 00.txt
> > 	Pages           : 11
> > 	Date            : 2012-03-05
> >
> >   This document discusses a number of considerations related to the
> >   topologies of Real-Time Transport Protocol (RTP) sessions initated
> >   using the Session Description (SDP) unicast Offer/Answer Model,
> >   especially as applied to source-multiplexed sessions.
> >
> >   The primary observation is that certain topologies cannot be
> created
> >   by unicast SDP Offer/Answer.  Notably, the it is not possible to
> >   negotiate the topology that RFC 5117 calls Topo-Transport-
> Translator
> >   (or "relay").
> >
> >   As a consequence of this limitation, certain topological
> assumptions
> >   can safely be made for RTP sessions initiated using unicast SDP
> >   Offer/Answer; and therefore, certain optimizations to RTP are
> >   possible in such sessions.  This document also describes the
> >   optimizations that these assumptions make possible.
> >
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-lennox-avtcore-rtp-topo-
> offe
> > r-answer-00.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > This Internet-Draft can be retrieved at:
> > ftp://ftp.ietf.org/internet-drafts/draft-lennox-avtcore-rtp-topo-
> offer
> > -answer-00.txt
> >
> > _______________________________________________
> > 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
> >
>=20
> --
> Jonathan Lennox
> jonathan@vidyo.com
>=20
>=20
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt

From iesg-secretary@ietf.org  Mon Mar 12 06:56:43 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F323221E800C; Mon, 12 Mar 2012 06:56:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.498
X-Spam-Level: 
X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 2Do3Mi05bdpC; Mon, 12 Mar 2012 06:56:42 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7473B21F86D0; Mon, 12 Mar 2012 06:56:42 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120312135642.32640.29423.idtracker@ietfa.amsl.com>
Date: Mon, 12 Mar 2012 06:56:42 -0700
Cc: avt@ietf.org
Subject: [AVTCORE] Last Call:  (RTCP	Extension for Third-party Loss Report) to Proposed Standard
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ietf@ietf.org
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Mar 2012 13:56:43 -0000

The IESG has received a request from the Audio/Video Transport Core
Maintenance WG (avtcore) to consider the following document:
- 'RTCP Extension for Third-party Loss Report'
   as a Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-03-26. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   In a large RTP session using the RTCP feedback mechanism defined in
   RFC 4585, a feedback target may experience transient overload if some
   event causes a large number of receivers to send feedback at once.
   This overload is usually avoided by ensuring that feedback reports
   are forwarded to all receivers, allowing them to avoid sending
   duplicate feedback reports.  However, there are cases where it is not
   recommended to forward feedback reports, and this may allow feedback
   implosion.  This memo discusses these cases and defines a new RTCP
   third-party loss report that can be used to inform receivers that the
   feedback target is aware of some loss event, allowing them to
   suppress feedback.  Associated SDP signalling is also defined.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-avtcore-feedback-supression-rtp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-avtcore-feedback-supression-rtp/ballot/


No IPR declarations have been submitted directly on this I-D.



From wwwrun@rfc-editor.org  Mon Mar 12 15:55:26 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2174D21E814E; Mon, 12 Mar 2012 15:55:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.2
X-Spam-Level: 
X-Spam-Status: No, score=-102.2 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 QJq6Dh1rMr83; Mon, 12 Mar 2012 15:55:25 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id E11D421E8172; Mon, 12 Mar 2012 15:55:23 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 1495E72E002; Mon, 12 Mar 2012 15:54:56 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20120312225456.1495E72E002@rfc-editor.org>
Date: Mon, 12 Mar 2012 15:54:56 -0700 (PDT)
Cc: avt@ietf.org, rfc-editor@rfc-editor.org
Subject: [AVTCORE] RFC 6562 on Guidelines for the Use of Variable Bit Rate Audio with Secure RTP
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Mar 2012 22:55:26 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6562

        Title:      Guidelines for the Use of 
                    Variable Bit Rate Audio with Secure 
                    RTP 
        Author:     C. Perkins, JM. Valin
        Status:     Standards Track
        Stream:     IETF
        Date:       March 2012
        Mailbox:    csp@csperkins.org, 
                    jmvalin@jmvalin.ca
        Pages:      6
        Characters: 14288
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-avtcore-srtp-vbr-audio-04.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6562.txt

This memo discusses potential security issues that arise when using
variable bit rate (VBR) audio with the secure RTP profile.  Guidelines to
mitigate these issues are suggested.  [STANDARDS-TRACK]

This document is a product of the Audio/Video Transport Core Maintenance Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From bill.wu@huawei.com  Mon Mar 12 18:47:05 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B8921F8859 for ; Mon, 12 Mar 2012 18:47:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.337
X-Spam-Level: 
X-Spam-Status: No, score=-4.337 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, J_CHICKENPOX_75=0.6, MIME_BASE64_TEXT=1.753, 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 uMHD39A4YokP for ; Mon, 12 Mar 2012 18:47:04 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 55F2D21F8853 for ; Mon, 12 Mar 2012 18:47:04 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0S009OIVJ8W1@szxga04-in.huawei.com> for avt@ietf.org; Tue, 13 Mar 2012 09:45:08 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0S000GSVJ8XM@szxga04-in.huawei.com> for avt@ietf.org; Tue, 13 Mar 2012 09:45:08 +0800 (CST)
Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AHU09627; Tue, 13 Mar 2012 09:45:02 +0800
Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Mar 2012 09:44:31 +0800
Received: from w53375 (10.138.41.149) by szxeml416-hub.china.huawei.com (10.82.67.155) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Mar 2012 09:44:56 +0800
Date: Tue, 13 Mar 2012 09:44:53 +0800
From: Qin Wu 
X-Originating-IP: [10.138.41.149]
To: "Van Caenegem, Tom (Tom)" , Magnus Westerlund , IETF AVTCore WG 
Message-id: <10EE199408404E20922B52A3D8B367CD@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: base64
X-Priority: 3
X-MSMail-priority: Normal
X-CFilter-Loop: Reflected
References: <4F5B2F09.2090704@ericsson.com> 
Subject: Re: [AVTCORE] Regarding draft-ietf-avtcore-feedback-supression-rtp-15
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Mar 2012 01:47:05 -0000

SGksIGFsbDoNCj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KPkZyb206ICJWYW4gQ2Fl
bmVnZW0sIFRvbSAoVG9tKSIgPHRvbS52YW5fY2FlbmVnZW1AYWxjYXRlbC1sdWNlbnQuY29tPg0K
PlRvOiAiTWFnbnVzIFdlc3Rlcmx1bmQiIDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+
OyAiSUVURiBBVlRDb3JlIFdHIiA8YXZ0QGlldGYub3JnPg0KPlNlbnQ6IE1vbmRheSwgTWFyY2gg
MTIsIDIwMTIgNTo0MiBQTQ0KPlN1YmplY3Q6IFJlOiBbQVZUQ09SRV0gUmVnYXJkaW5nIGRyYWZ0
LWlldGYtYXZ0Y29yZS1mZWVkYmFjay1zdXByZXNzaW9uLXJ0cC0xNQ0KDQoNCj5IaSBNYWdudXMg
ICgsIFFpbikNCg0KDQo+VmVyc2lvbiAxNSBtYWtlcyB0aGUgZm9sbG93aW5nIHRocmVlIHN0YXRl
bWVudHM6DQoNCg0KPjEpU2VjdGlvbiAzOg0KDQo+IldoZW4gYSByZWNlaXZlciBnZXRzIGEgUlRD
UCBUUExSIG1lc3NhZ2UsIGl0IE1VU1QgZm9sbG93IHRoZSBydWxlcw0KPmZvciBOQUNLIHN1cHBy
ZXNzaW9uIGluIFJGQzQ1ODUgW1JGQzQ1ODVdYW5kIHJlZnJhaW4gZnJvbSBzZW5kaW5nIGENCj5m
ZWVkYmFjayByZXF1ZXN0IChlLmcuLCBOQUNLIG9yIEZJUikgZm9yIHRoZSBtaXNzaW5nIHBhY2tl
dHMgcmVwb3J0ZWQNCj5pbiB0aGUgbWVzc2FnZSx3aGljaCBpcyBkZWFsdCB3aXRoIGluIHRoZSBz
YW1lIHdheSBhcyByZWNlaXZpbmcgTkFDSyINCg0KPjIpU2VjdGlvbiAzOg0KDQo+IkEgcmVjZWl2
ZXIgbWF5IGhhdmUgc2VudCBhIEZlZWRiYWNrIG1lc3NhZ2UgYWNjb3JkaW5nIHRvIHRoZSBSVFAv
QVZQRg0KPnNjaGVkdWxpbmcgYWxnb3JpdGhtIG9mIFJGQzQ1ODUgW1JGQzQ1ODVdIGJlZm9yZSBy
ZWNlaXZpbmcgYSBSVENQDQo+VFBMUiBtZXNzYWdlLCBidXQgZnVydGhlciBmZWVkYmFjayBtZXNz
YWdlcyBmb3IgdGhvc2Ugc2VxdWVuY2UNCj5udW1iZXJzIFNIT1VMRCBiZSBzdXBwcmVzc2VkIGFm
dGVyIHJlY2VpdmluZyB0aGUgUlRDUCBUUExSIg0KDQoNCj4zKVNlY3Rpb24gNzoNCg0KPiJBbHNv
IG5vdGUgdGhhdCBlbmRwb2ludHMgdGhhdCByZWNlaXZlIGEgVGhpcmQgUGFydHkgTG9zcyBSZXBv
cnQgd291bGQNCj5iZSB3ZWxsLWFkdmlzZWQgdG8gaWdub3JlIGl0LCB1bmxlc3MgdGhlIHNlY3Vy
aXR5IGlzIGluIHBsYWNlIHRvDQo+YXV0aGVudGljYXRlIHRoZSBzZW5kZXIgb2YgdGhlIFRoaXJk
IFBhcnR5IExvc3MgUmVwb3J0Ig0KDQoNCj5UaGVzZSBzdGF0ZW1lbnRzIGFyZSBzdGlsbCBub3Qg
YWxpZ25lZCB3aXRoIGVhY2ggb3RoZXIuIA0KDQo+MSkgLT4gaW5kaWNhdGVzIHRoYXQgYSBUUExS
IG1lc3NhZ2UgYWx3YXlzIHJlc3VsdHMgaW4gRkIgc3VwcHJlc3Npb24gKE1VU1QpLCBhbmQgYWxp
Z25lZCB3aXRoIFJGQyA0NTg1DQoNCj4yKSAtPiB3aHkgZG9lcyB0aGUgY2FzZSB3aGVyZSBhIHJl
Y2VpdmVyIHNlbnQgYSBOQUNLIGJlZm9yZSByZWNlaXZpbmcgYSBUUExSLCByZXByZXNlbnRzIGFu
IGV4Y2VwdGlvbiBvbiB0aGUgcmVjZWl2ZXIgYmVoYXZpb3VyIGRlZmluZWQgaW4gdGhlIDFzdCBz
dGF0ZW1lbnQgKFNIT1VMRCBpbnN0ZWFkIG9mIE1VU1QpDQoNCj5bUWluXTogSSB0aGluayBzdGF0
ZW1lbnQgMikgY2FuIHVzZSB0aGUgIk1VU1QiIHRvIGdldCBhbGlnbm1lbnQgd2l0aCBzdGF0ZW1l
bnQgMSkuDQoNCj4zKSAtPiBpcyBlZmZlY3RpdmUgYSBTSE9VTEQgZm9yIG5vbi1hdXRoZW50aWNh
dGVkIFRQTFIgbWVzc2FnZXMuDQogDQpbUWluXTogQXMgSSBjbGFyaWZpZWQgZWFybGllciB0byBB
RCByZXZpZXcsIHN0YXRlbWVudCAzKSBlbXBoYXNpemVzIHRoZSBkaWZmZXJlbnQgdGhpbmcsIGku
ZSwgaG93IHRvIHByZXZlbnQgYXR0YWNrcyB1c2luZyBmYWxzZSBSVENQIHBhY2tldHMgZnJvbSBt
YWxpY2lvdXMgZ3JvdXAgbWVtYmVycy4NClRoaXMgc3RhdGVtZW50IGdldHMgYWxpZ25tZW50IHdp
dGggd2hhdCBSRkM0NTg1IHNhaWQgaW4gdGhlIGxhc3QgcGFyYWdyYXBoIG9mIHNlY3Rpb24gODoN
CiINCiAgIEF0dGFja3MgdXNpbmcgZmFsc2UgUlRDUCBwYWNrZXRzIChSZWd1bGFyIGFzIHdlbGwg
YXMgRWFybHkgb25lcykgY2FuDQogICBiZSBhdm9pZGVkIGJ5IGF1dGhlbnRpY2F0aW5nIGFsbCBS
VENQIG1lc3NhZ2VzLiAgVGhpcyBjYW4gYmUgYWNoaWV2ZWQNCiAgIGJ5IHVzaW5nIHRoZSBBVlBG
IHByb2ZpbGUgdG9nZXRoZXIgd2l0aCB0aGUgU2VjdXJlIFJUUCBwcm9maWxlIGFzDQogICBkZWZp
bmVkIGluIFsyMl07IGFzIGEgcHJlcmVxdWlzaXRlLCBhbiBhcHByb3ByaWF0ZSBjb21iaW5hdGlv
biBvZg0KICAgdGhvc2UgdHdvIHByb2ZpbGVzIChhbiAiU0FWUEYiKSBpcyBiZWluZyBzcGVjaWZp
ZWQgWzIxXS4gIE5vdGUgdGhhdCwNCiAgIHdoZW4gZW1wbG95aW5nIGdyb3VwIGF1dGhlbnRpY2F0
aW9uIChhcyBvcHBvc2VkIHRvIHNvdXJjZQ0KICAgYXV0aGVudGljYXRpb24pLCB0aGUgYWZvcmVt
ZW50aW9uZWQgYXR0YWNrcyBtYXkgYmUgY2FycmllZCBvdXQgYnkNCiAgIG1hbGljaW91cyBvciBt
YWxmdW5jdGlvbmluZyBncm91cCBtZW1iZXJzIGluIHBvc3Nlc3Npb24gb2YgdGhlIHJpZ2h0DQog
ICBrZXlpbmcgbWF0ZXJpYWwuDQoiDQpTbyBJIGRvbid0IHRoaW5rIHRoaXMgc3RhdGVtZW50IDMp
IGNvbmZsaWN0cyB3aXRoIHN0YXRlbWVudCAxKSBhbmQgMikuIEFsc28gSSBtdXN0IGVtcGhhc2l6
ZSBjb3VudGVybWVhc3VyZXMgd2UgcHJvcG9zZWQgaGVyZSBpbiB0aGUgc3RhdGVtZW50IDMpIA0K
c2hvdWxkIGFwcGx5IHRvIGFueSBGZWVkYmFjayBtZXNzYWdlcyBpbmNsdWRpbmcgTkFDSywgVFBM
Ui4NCkhvcGUgdGhpcyBjbGFyaWZpZXMuDQoNCj5NYWdudXMsIGZyb20geW91ciBzdGF0ZW1lbnQg
YmVsb3csIEkgdGFrZSBpdCB0aGF0IHlvdSBwcm9wb3NlIGEgcmVjZWl2ZXIgYmVoYXZpb3VyIGRp
ZmZlcmVudCBmcm9tIHRoZSBvbmUgZGVmaW5lZCBpbiBSRkMgNDU4NSAoc28gU0hPVUxEIHN1cHBy
ZXNzIGZlZWRiYWNrIGluc3RlYWQgb2YgTVVTVCBzdXBwcmVzcyBmZWVkYmFjayBpbiA+UkZDIDQ1
ODUpLg0KDQo+SWYgeW91IGRvIHRoaXMgLCBpdCByZXF1aXJlcyBzb21lIGV4cGxpY2l0IHJlYXNv
bmluZyB0aGF0IGV4cGxhaW5zIHRoaXMgZGlmZmVyZW5jZSAsIGFuZCBleHBsaWNpdCBpbmRpY2F0
aW9uIHRoYXQgdGhpcyBiZWhhdmlvdXIgaXMgZGlmZmVyZW50IGZyb20gZmVlZGJhY2sgc3VwcHJl
c3Npb24gcnVsZSBkZWZpbmVkIGluIFJGQyA0NTg1Lg0KPlRvbQ0KDQoNCj4tLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KPkZyb206IGF2dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXZ0LWJv
dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYWdudXMgV2VzdGVybHVuZA0KPlNlbnQ6IHph
dGVyZGFnIDEwIG1hYXJ0IDIwMTIgMTE6MzgNCj5UbzogSUVURiBBVlRDb3JlIFdHDQo+U3ViamVj
dDogW0FWVENPUkVdIFJlZ2FyZGluZyBkcmFmdC1pZXRmLWF2dGNvcmUtZmVlZGJhY2stc3VwcmVz
c2lvbi1ydHAtMTUNCg0KPkhpLA0KDQo+UWluIFd1IGhhcyBiZWVuIHZlcnkgZGlsaWdlbnQgaW4g
YWRkcmVzc2luZyByYWlzZWQgY29tbWVudHMuIEkgd2FudCB0byBzdGF0ZSB0aGF0IEkgYmVsaWV2
ZSB0aGF0IHRoaXMgbGF0ZXN0IHZlcnNpb24gZG8gYWRkcmVzcyB0aGUgQURzIGNvbW1lbnRzIGlu
IGEgcmVhc29uYWJsZSB3YXkuIEkgZG8gd2FudCB0byBwb2ludCBvdXQgdG8gdGhlIFdHIHRoYXQg
PnRoZSBhdXRob3JzIGNob2ljZSBvZiBob3cgdG8gcmVzb2x2ZSBvbmUgaXNzdWUgd2FzIHRvIHJl
bW92ZSB0aGUgd2hvbGUgcHJvYmxlbWF0aWMgc2VudGVuY2UuIEkgcGVyc29uYWxseSBiZWxpZXZl
IHRoaXMgaXMgcmlnaHQsIGJ1dCBpZiBhbnkgaW4gdGhlIFdHIHRoaW5rcyBpdCBpcyBwcm9ibGVt
YXRpYyB0aGVuIHNwZWFrIHVwIGR1cmluZyB0aGUgSUVURiA+bGFzdCBjYWxsLg0KDQo+ICAgSW4g
b3RoZXIgd29yZHMsIHJlY2VpdmVycyBNQVkgaWdub3JlIFJUQ1AgVFBMUiBtZXNzYWdlcywgYnV0
IFNIT1VMRA0KPiAgIHJlYWN0IHRvIHRoZW0gdW5sZXNzIHRoZXkgaGF2ZSBnb29kIHJlYXNvbiB0
byBzdGlsbCBzZW5kIA0KID4gIGZlZWRiYWNrIG1lc3NhZ2VzIGRlc3BpdGUgaGF2aW5nIGJlZW4g
cmVxdWVzdGVkIHRvIHN1cHByZXNzIHRoZW0uDQoNCj5DaGVlcnMNCg0KPk1hZ251cyBXZXN0ZXJs
dW5kDQo+QVZUQ09SRSBXRyBjaGFpcg0KDQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPk11bHRpbWVkaWEgVGVj
aG5vbG9naWVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFZNDQotLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+RXJp
Y3Nzb24gQUIgICAgICAgICAgICAgICAgfCBQaG9uZSAgKzQ2IDEwIDcxNDgyODcNCj5G5HL2Z2F0
YW4gNiAgICAgICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KPlNFLTE2NCA4MCBT
dG9ja2hvbG0sIFN3ZWRlbnwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20N
Cj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tDQoNCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KPkF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQo+YXZ0
QGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnQNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+QXVkaW8vVmlk
ZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UNCj5hdnRAaWV0Zi5vcmcNCj5odHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dA==


From ron.even.tlv@gmail.com  Tue Mar 13 00:23:33 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38C911E8085; Tue, 13 Mar 2012 00:23:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.429
X-Spam-Level: 
X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, 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 5M+qXkCSF-xG; Tue, 13 Mar 2012 00:23:33 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4E67D11E8079; Tue, 13 Mar 2012 00:23:32 -0700 (PDT)
Received: by werb10 with SMTP id b10so236632wer.31 for ; Tue, 13 Mar 2012 00:23:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=uRXPr//wTuNVLFj7tQK9hUb7ZtCFQleFCb2Kxgcup7M=; b=HZtP97mB26FzpWTXzq/Rtri8Z3pQpiFTEYll27+ZTjPQ/wWzuOxmJw4yV2ufwC482m 0wLRumWGLOEBJ/eeDb1oVlDtWh+S59gP/oAstoOE8F6VsZq6jtFkAlq/7W+UvfxeaTQ8 RTxKqRR9sWdWdTGQSbk2AmWddhPQzL4csj6QZWP1idppsr1FmG/o1X6Gu4exflGKgZjD QdB0EBbZmpdnBSvcWtRnXDd93rq/EL4iMlulzJ7igKKRMcLMkwsXEY9bs6xA51apAIZm VAdOZqKPdOjiJjdw5ANazOMBHBEpWsK7J0eFSXcXY62YhaB07GPX7gSOyUlm9moTZ5Un +ayA==
Received: by 10.180.100.228 with SMTP id fb4mr4772676wib.1.1331623410984; Tue, 13 Mar 2012 00:23:30 -0700 (PDT)
Received: from windows8d787f9 (bzq-79-179-219-130.red.bezeqint.net. [79.179.219.130]) by mx.google.com with ESMTPS id n8sm69536435wix.10.2012.03.13.00.23.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Mar 2012 00:23:29 -0700 (PDT)
From: "Roni Even" 
To: "'IETF AVTCore WG'" 
Date: Tue, 13 Mar 2012 09:22:38 +0200
Message-ID: <4f5ef5f1.0850b40a.2c3f.ffffe33c@mx.google.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_00E3_01CD00FA.D6BA25C0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac0A6hGBVnmRA0ADQR6uMnLdAUm2Og==
Content-Language: en-us
Cc: payload@ietf.org
Subject: [AVTCORE] Agenda for AVTcore IETF83
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Mar 2012 07:23:33 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_00E3_01CD00FA.D6BA25C0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_00E4_01CD00FA.D6BA25C0"


------=_NextPart_001_00E4_01CD00FA.D6BA25C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

This is the preliminary agenda for the AVTcore session in Paris. Please
review and comment.

 

We have two adjacent time slots and we will have a 10 minutes break in the
middle.

 

We had requests to present some payload WG drafts, they will be presented
during AVText time slot on Tuesday 15:20-17:00.

 

Attached is the html version

 

Thanks

Roni Even

AVTcore co-chair

 

 

 

 

Audio/Video Transport Core Maintenance  (AVTCore) Working Group

===============================================================

 

CHAIRS:  Magnus Westerlund       

         Roni Even         

 

AGENDA

 

Monday, 26 March 2012 at 13:00-16:10 (252B)

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

13:00   AVTCore Status Update                               (Chairs, 15)

 

13:15   Why RTP Sessions Should Be Content Neutral(Harald Alvestrand , 15)

        draft-alvestrand-rtp-sess-neutral-00

 

13:30   RTP Multiplexing Architecture           (Magnus Westerlund , 20)

        draft-westerlund-avtcore-multiplex-architecture-01

 

13:50   Multiple RTP Session on a Single Lower-Layer Transport(Magnus
Westerlund , 35)

        draft-westerlund-avtcore-transport-multiplexing-02

 

14:25   RTP Congestion Control: Circuit Breakers for Unicast Sessions(Colin
Perkins , 15)

        draft-perkins-avtcore-rtp-circuit-breakers-00

 

14:40   RTP Topology Considerations for Offer/Answer-Initiated
Sessions(Jonathan Lennox, 20)

        draft-lennox-avtcore-rtp-topo-offer-answer-00

 

15:00   Break (if needed)                                         (, 10)

 

15:10   RTCP for inter-destination media synchronization(Ray van
Brandenburg, 10)

        draft-ietf-avtcore-idms-03

 

15:20   RTP Clock Source Signalling            (Ray van Brandenburg, 10)

        draft-williams-avtcore-clksrc-00

 

15:30   Duplicating RTP Streams                              (Begen, 10)

        draft-begen-avtcore-rtp-duplication-01

 

15:40   Multipath RTP                                  (Varun Singh, 10)

        draft-singh-avt-mprtp-04

 

15:50   End


------=_NextPart_001_00E4_01CD00FA.D6BA25C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi,
This is the =
preliminary agenda for the AVTcore session in Paris. Please review and =
comment.
 
We have two adjacent time slots and we will have a 10 =
minutes break in the middle.
 
We had =
requests to present some payload WG drafts, they will be presented =
during AVText time slot on Tuesday 15:20-17:00.
 
Attached is =
the html version
 
Thanks
Roni =
Even
AVTcore =
co-chair
 
 
 
 
Audio/Video =
Transport Core Maintenance  (AVTCore) Working =
Group
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
<=
p class=3DMsoNormal> 
CHAIRS:  Magnus =
Westerlund       =
<magnus.westerlund@ericsson.com>
         Roni =
Even         =
<even.roni@huawei.com>
 
AGENDA
 
Monday, 26 =
March 2012 at 13:00-16:10 (252B)
-------------------------------------------<=
/p>
13:00   AVTCore Status =
Update           &=
nbsp;           &n=
bsp;       (Chairs, 15)
 
13:15   Why RTP Sessions Should Be Content =
Neutral(Harald Alvestrand , 15)
        =
draft-alvestrand-rtp-sess-neutral-00
 
13:30   RTP Multiplexing =
Architecture           =
(Magnus Westerlund , 20)
        =
draft-westerlund-avtcore-multiplex-architecture-01
 
13:50   Multiple RTP Session on a Single =
Lower-Layer Transport(Magnus Westerlund , 35)
        =
draft-westerlund-avtcore-transport-multiplexing-02
 
14:25   RTP Congestion Control: Circuit =
Breakers for Unicast Sessions(Colin Perkins , 15)
        =
draft-perkins-avtcore-rtp-circuit-breakers-00
 
14:40   RTP Topology Considerations for =
Offer/Answer-Initiated Sessions(Jonathan Lennox, 20)
        =
draft-lennox-avtcore-rtp-topo-offer-answer-00
 
15:00   Break (if =
needed)           =
            &=
nbsp;           &n=
bsp;     (, 10)
 
15:10   RTCP for inter-destination media =
synchronization(Ray van Brandenburg, 10)
        =
draft-ietf-avtcore-idms-03
 
15:20   RTP Clock Source =
Signalling          &nb=
sp; (Ray van Brandenburg, 10)
        =
draft-williams-avtcore-clksrc-00
 
15:30   Duplicating RTP =
Streams           =
            &=
nbsp;      (Begen, 10)
        =
draft-begen-avtcore-rtp-duplication-01
 
15:40   Multipath =
RTP           &nbs=
p;            =
;          (Varun Singh, =
10)
        =
draft-singh-avt-mprtp-04
 
15:50   =
End

------=_NextPart_001_00E4_01CD00FA.D6BA25C0--

------=_NextPart_000_00E3_01CD00FA.D6BA25C0
Content-Type: text/html;
	name="agenda.html"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="agenda.html"



Audio/Video Transport Core Maintenance  (AVTCore) Working Group =
Agenda


Audio/Video Transport Core Maintenance  =
(AVTCore) Working Group Agenda







Chairs: Magnus Westerlund       , Roni =
Even         





Monday, 26 March 2012 at 13:00-16:10 (252B)







13:00
AVTCore Status UpdateChairs


13:15
Why RTP Sessions Should Be Content NeutralHarald Alvestrand=20



dr=
aft-alvestrand-rtp-sess-neutral-00


13:30
RTP Multiplexing ArchitectureMagnus Westerlund=20



draft-westerlund-avtcore-multiplex-architecture-01


13:50
Multiple RTP Session on a Single Lower-Layer =
TransportMagnus Westerlund=20



draft-westerlund-avtcore-transport-multiplexing-02


14:25
RTP Congestion Control: Circuit Breakers for Unicast =
SessionsColin Perkins=20



draft-perkins-avtcore-rtp-circuit-breakers-00


14:40
RTP Topology Considerations for =
Offer/Answer-Initiated SessionsJonathan Lennox



draft-lennox-avtcore-rtp-topo-offer-answer-00


15:00
Break (if needed)


15:10
RTCP for inter-destination media synchronizationRay van Brandenburg



draft-ietf-a=
vtcore-idms-03


15:20
RTP Clock Source SignallingRay van =
Brandenburg



draft-=
williams-avtcore-clksrc-00


15:30
Duplicating RTP StreamsBegen



=
draft-begen-avtcore-rtp-duplication-01


15:40
Multipath RTP Varun Singh



draft-singh-av=
t-mprtp-04


15:50
End


------=_NextPart_000_00E3_01CD00FA.D6BA25C0--


From tom.van_caenegem@alcatel-lucent.com  Tue Mar 13 07:00:10 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D6821F88F0 for ; Tue, 13 Mar 2012 07:00:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.8
X-Spam-Level: 
X-Spam-Status: No, score=-8.8 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_75=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 muJk2eT3H8Nt for ; Tue, 13 Mar 2012 07:00:09 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6006221F88ED for ; Tue, 13 Mar 2012 07:00:09 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2DDpoip026498 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 13 Mar 2012 14:59:51 +0100
Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 13 Mar 2012 14:59:44 +0100
From: "Van Caenegem, Tom (Tom)" 
To: Qin Wu , Magnus Westerlund , IETF AVTCore WG 
Date: Tue, 13 Mar 2012 14:59:43 +0100
Thread-Topic: [AVTCORE] Regarding draft-ietf-avtcore-feedback-supression-rtp-15
Thread-Index: Ac0AuzKweg6AnRdXRG6RhMcbz285OgAUX53Q
Message-ID: 
References: <4F5B2F09.2090704@ericsson.com>  <10EE199408404E20922B52A3D8B367CD@china.huawei.com>
In-Reply-To: <10EE199408404E20922B52A3D8B367CD@china.huawei.com>
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: nl-NL, en-US
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: [AVTCORE] Regarding draft-ietf-avtcore-feedback-supression-rtp-15
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Mar 2012 14:00:10 -0000

Hi Qin,

The issue on statement 2 : OK

IMO your statement 3 ("Also note that endpoints that receive a Third Party =
Loss Report would=20
be well-advised to ignore it, unless the security is in place to authentica=
te the sender of the Third Party Loss Report") is an advice (/requirement?)=
 that goes well beyond the recommendations in the security section 8 of RFC=
 4585.=20

The latter indicates that senders/receivers should behave conservatively wh=
en observing strange reporting behaviour.=20

The section also states that false RTCP packets can be avoided by authentic=
ating RTCP messages. =20

(see below the exact phrasing that I copied for your convenience)

In line with these RFC 4585 recommendation, you seem to interprete "unauthe=
nticated" RTCP messages as an example of "strange" reporting behavior, whic=
h I do not think was the intention from RFC 4585.

My proposal would be to just indicate in your security section that a solut=
ion to minimise the risk on false TPLR messages from a malicious source (wh=
ich results in unneeded suppression feedback at the target victim receiver(=
s), is to make use of an authentication framework (in line with RFC 4585).=
=20

Regards
Tom


RFC 4585, section 8 (Security):

(..)

Senders as well as receivers SHOULD behave conservatively when
   observing strange reporting behavior.  For excessive failure
   reporting from one or a few receivers, the sender MAY decide to no
   longer consider this feedback when adapting its transmission behavior
   for the media stream.  In any case, senders and receivers SHOULD
   still adhere to the maximum RTCP bandwidth but make sure that they
   are capable of transmitting at least regularly scheduled RTCP
   packets.  Senders SHOULD carefully consider how to adjust their
   transmission bandwidth when encountering strange reporting behavior;
   they MUST NOT increase their transmission bandwidth even if ignoring
   suspicious feedback.

   Attacks using false RTCP packets (Regular as well as Early ones) can
   be avoided by authenticating all RTCP messages.  This can be achieved
   by using the AVPF profile together with the Secure RTP profile as
   defined in [22]; as a prerequisite, an appropriate combination of
   those two profiles (an "SAVPF") is being specified [21].  Note that,
   when employing group authentication (as opposed to source
   authentication), the aforementioned attacks may be carried out by
   malicious or malfunctioning group members in possession of the right
   keying material.

-----Original Message-----
From: Qin Wu [mailto:bill.wu@huawei.com]=20
Sent: dinsdag 13 maart 2012 2:45
To: Van Caenegem, Tom (Tom); Magnus Westerlund; IETF AVTCore WG
Subject: Re: [AVTCORE] Regarding draft-ietf-avtcore-feedback-supression-rtp=
-15

Hi, all:
>----- Original Message -----
>From: "Van Caenegem, Tom (Tom)" 
>To: "Magnus Westerlund" ; "IETF AVTCore=20
>WG" 
>Sent: Monday, March 12, 2012 5:42 PM
>Subject: Re: [AVTCORE] Regarding=20
>draft-ietf-avtcore-feedback-supression-rtp-15


>Hi Magnus  (, Qin)


>Version 15 makes the following three statements:


>1)Section 3:

>"When a receiver gets a RTCP TPLR message, it MUST follow the rules for=20
>NACK suppression in RFC4585 [RFC4585]and refrain from sending a=20
>feedback request (e.g., NACK or FIR) for the missing packets reported=20
>in the message,which is dealt with in the same way as receiving NACK"

>2)Section 3:

>"A receiver may have sent a Feedback message according to the RTP/AVPF=20
>scheduling algorithm of RFC4585 [RFC4585] before receiving a RTCP TPLR=20
>message, but further feedback messages for those sequence numbers=20
>SHOULD be suppressed after receiving the RTCP TPLR"


>3)Section 7:

>"Also note that endpoints that receive a Third Party Loss Report would=20
>be well-advised to ignore it, unless the security is in place to=20
>authenticate the sender of the Third Party Loss Report"


>These statements are still not aligned with each other.=20

>1) -> indicates that a TPLR message always results in FB suppression=20
>(MUST), and aligned with RFC 4585

>2) -> why does the case where a receiver sent a NACK before receiving a=20
>TPLR, represents an exception on the receiver behaviour defined in the=20
>1st statement (SHOULD instead of MUST)

>[Qin]: I think statement 2) can use the "MUST" to get alignment with state=
ment 1).

>3) -> is effective a SHOULD for non-authenticated TPLR messages.
=20
[Qin]: As I clarified earlier to AD review, statement 3) emphasizes the dif=
ferent thing, i.e, how to prevent attacks using false RTCP packets from mal=
icious group members.
This statement gets alignment with what RFC4585 said in the last paragraph =
of section 8:
"
   Attacks using false RTCP packets (Regular as well as Early ones) can
   be avoided by authenticating all RTCP messages.  This can be achieved
   by using the AVPF profile together with the Secure RTP profile as
   defined in [22]; as a prerequisite, an appropriate combination of
   those two profiles (an "SAVPF") is being specified [21].  Note that,
   when employing group authentication (as opposed to source
   authentication), the aforementioned attacks may be carried out by
   malicious or malfunctioning group members in possession of the right
   keying material.
"
So I don't think this statement 3) conflicts with statement 1) and 2). Also=
 I must emphasize countermeasures we proposed here in the statement 3) shou=
ld apply to any Feedback messages including NACK, TPLR.
Hope this clarifies.

>Magnus, from your statement below, I take it that you propose a receiver b=
ehaviour different from the one defined in RFC 4585 (so SHOULD suppress fee=
dback instead of MUST suppress feedback in >RFC 4585).

>If you do this , it requires some explicit reasoning that explains this di=
fference , and explicit indication that this behaviour is different from fe=
edback suppression rule defined in RFC 4585.
>Tom


>-----Original Message-----
>From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of=20
>Magnus Westerlund
>Sent: zaterdag 10 maart 2012 11:38
>To: IETF AVTCore WG
>Subject: [AVTCORE] Regarding=20
>draft-ietf-avtcore-feedback-supression-rtp-15

>Hi,

>Qin Wu has been very diligent in addressing raised comments. I want to sta=
te that I believe that this latest version do address the ADs comments in a=
 reasonable way. I do want to point out to the WG that >the authors choice =
of how to resolve one issue was to remove the whole problematic sentence. I=
 personally believe this is right, but if any in the WG thinks it is proble=
matic then speak up during the IETF >last call.

>   In other words, receivers MAY ignore RTCP TPLR messages, but SHOULD
>   react to them unless they have good reason to still send
 >  feedback messages despite having been requested to suppress them.

>Cheers

>Magnus Westerlund
>AVTCORE WG chair

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

>_______________________________________________
>Audio/Video Transport Core Maintenance
>avt@ietf.org
>https://www.ietf.org/mailman/listinfo/avt
_______________________________________________
>Audio/Video Transport Core Maintenance
>avt@ietf.org
>https://www.ietf.org/mailman/listinfo/avt=

From ron.even.tlv@gmail.com  Wed Mar 14 01:13:15 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1732221F86D7 for ; Wed, 14 Mar 2012 01:13:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.625
X-Spam-Level: 
X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, 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 c0mAaZWzqojH for ; Wed, 14 Mar 2012 01:13:13 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D072D21F86D9 for ; Wed, 14 Mar 2012 01:13:09 -0700 (PDT)
Received: by werb10 with SMTP id b10so1691340wer.31 for ; Wed, 14 Mar 2012 01:13:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=K9xeY7KtV+ZKvhQ3a4JejEqnJNLpMZYusG7J+e1Dxe8=; b=FiJPZuyccvPsYvcKinDvWnRGS2FhEkEHlwbMpYKbsSXCR2I0Bbim6M29+fzMLQ/BGv FUNzr/lsQF8wS3i8F+4f+ACZGSCw4knBmvDksvBDNSRdRaDHcpXthjp6cmNxziSzoHoy HU3g+vIt9UHnmzy8RZfVCXHuquYX1ie9Y/yM+k98itjbbUiGG3yEbSWHg+TvDD6JAohZ FDkYsPWyXAwzfrv7t3COmZq7U625oeMgDfHc0/KNYYJzkXsZ5eB2bYVFs334qM+04U/P 7SiMHaOF/eAMIxatS2OfGtnam7uBckgt5QO1fZE0GPXIzHTk85YLJwC4QuZxGvVnEQKX QOQQ==
Received: by 10.216.136.13 with SMTP id v13mr991380wei.32.1331712788981; Wed, 14 Mar 2012 01:13:08 -0700 (PDT)
Received: from windows8d787f9 (bzq-79-179-219-130.red.bezeqint.net. [79.179.219.130]) by mx.google.com with ESMTPS id j3sm13675884wiw.1.2012.03.14.01.13.06 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Mar 2012 01:13:08 -0700 (PDT)
From: "Roni Even" 
To: "'IETF AVTCore WG'" 
Date: Wed, 14 Mar 2012 10:12:15 +0200
Message-ID: <4f605314.634cb40a.759a.ffff9c50@mx.google.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0042_01CD01CA.F02D13C0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac0BuipXL86K29YNRVyAx/RlKCzX/w==
Content-Language: en-us
Subject: [AVTCORE] Updated agenda for AVTcore session in IETF83
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 08:13:15 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0042_01CD01CA.F02D13C0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0043_01CD01CA.F02D13C0"


------=_NextPart_001_0043_01CD01CA.F02D13C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

Switched the order between Clock Source signaling and IDMS and update the
presenter name.

 

Roni

 

 

Audio/Video Transport Core Maintenance  (AVTCore) Working Group

===============================================================

 

CHAIRS:  Magnus Westerlund       

         Roni Even         

 

AGENDA

 

Monday, 26 March 2012 at 13:00-16:10 (252B)

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

13:00   AVTCore Status Update                               (Chairs, 15)

 

13:15   Why RTP Sessions Should Be Content Neutral(Harald Alvestrand , 15)

        draft-alvestrand-rtp-sess-neutral-00

 

13:30   RTP Multiplexing Architecture           (Magnus Westerlund , 20)

        draft-westerlund-avtcore-multiplex-architecture-01

 

13:50   Multiple RTP Session on a Single Lower-Layer Transport(Magnus
Westerlund , 35)

        draft-westerlund-avtcore-transport-multiplexing-02

 

14:25   RTP Congestion Control: Circuit Breakers for Unicast Sessions(Colin
Perkins , 15)

        draft-perkins-avtcore-rtp-circuit-breakers-00

 

14:40   RTP Topology Considerations for Offer/Answer-Initiated
Sessions(Jonathan Lennox, 20)

        draft-lennox-avtcore-rtp-topo-offer-answer-00

 

15:00   Break (if needed)                                         (, 10)

 

15:10   RTP Clock Source Signalling                 (Aidan Williams, 10)

        draft-williams-avtcore-clksrc-00

 

15:20   RTCP for inter-destination media synchronization(Ray van
Brandenburg, 10)

        draft-ietf-avtcore-idms-03

 

15:30   Duplicating RTP Streams                              (Begen, 10)

        draft-begen-avtcore-rtp-duplication-01

 

15:40   Multipath RTP                                  (Varun Singh, 10)

        draft-singh-avt-mprtp-04

 

15:50   End


------=_NextPart_001_0043_01CD01CA.F02D13C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi,
Switched the =
order between Clock Source signaling and IDMS and update the presenter =
name.
 
Roni
 
 
Audio/Video =
Transport Core Maintenance  (AVTCore) Working =
Group
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
<=
p class=3DMsoNormal> 
CHAIRS:  Magnus =
Westerlund       =
<magnus.westerlund@ericsson.com>
         Roni =
Even         =
<even.roni@huawei.com>
 
AGENDA
 
Monday, 26 =
March 2012 at 13:00-16:10 (252B)
-------------------------------------------<=
/p>
13:00   AVTCore Status =
Update           &=
nbsp;           &n=
bsp;       (Chairs, 15)
 
13:15   Why RTP Sessions Should Be Content =
Neutral(Harald Alvestrand , 15)
        =
draft-alvestrand-rtp-sess-neutral-00
 
13:30   RTP Multiplexing =
Architecture           =
(Magnus Westerlund , 20)
        =
draft-westerlund-avtcore-multiplex-architecture-01
 
13:50   Multiple RTP Session on a Single =
Lower-Layer Transport(Magnus Westerlund , 35)
        =
draft-westerlund-avtcore-transport-multiplexing-02
 
14:25   RTP Congestion Control: Circuit =
Breakers for Unicast Sessions(Colin Perkins , 15)
        =
draft-perkins-avtcore-rtp-circuit-breakers-00
 
14:40   RTP Topology Considerations for =
Offer/Answer-Initiated Sessions(Jonathan Lennox, 20)
        =
draft-lennox-avtcore-rtp-topo-offer-answer-00
 
15:00   Break (if =
needed)           =
            &=
nbsp;           &n=
bsp;     (, 10)
 
15:10   RTP Clock Source =
Signalling          &nb=
sp;      (Aidan Williams, 10)
        =
draft-williams-avtcore-clksrc-00
 
15:20   RTCP for inter-destination media =
synchronization(Ray van Brandenburg, 10)
        =
draft-ietf-avtcore-idms-03
 
15:30   Duplicating RTP =
Streams           =
            &=
nbsp;      (Begen, 10)
        =
draft-begen-avtcore-rtp-duplication-01
 
15:40   Multipath =
RTP           &nbs=
p;            =
;          (Varun Singh, =
10)
        =
draft-singh-avt-mprtp-04
 
15:50   =
End

------=_NextPart_001_0043_01CD01CA.F02D13C0--

------=_NextPart_000_0042_01CD01CA.F02D13C0
Content-Type: text/html;
	name="agenda.html"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="agenda.html"



Audio/Video Transport Core Maintenance  (AVTCore) Working Group =
Agenda


Audio/Video Transport Core Maintenance  =
(AVTCore) Working Group Agenda







Chairs: Magnus Westerlund       , Roni =
Even         





Monday, 26 March 2012 at 13:00-16:10 (252B)







13:00
AVTCore Status UpdateChairs


13:15
Why RTP Sessions Should Be Content NeutralHarald Alvestrand=20



dr=
aft-alvestrand-rtp-sess-neutral-00


13:30
RTP Multiplexing ArchitectureMagnus Westerlund=20



draft-westerlund-avtcore-multiplex-architecture-01


13:50
Multiple RTP Session on a Single Lower-Layer =
TransportMagnus Westerlund=20



draft-westerlund-avtcore-transport-multiplexing-02


14:25
RTP Congestion Control: Circuit Breakers for Unicast =
SessionsColin Perkins=20



draft-perkins-avtcore-rtp-circuit-breakers-00


14:40
RTP Topology Considerations for =
Offer/Answer-Initiated SessionsJonathan Lennox



draft-lennox-avtcore-rtp-topo-offer-answer-00


15:00
Break (if needed)


15:10
RTP Clock Source SignallingAidan =
Williams



draft-=
williams-avtcore-clksrc-00


15:20
RTCP for inter-destination media synchronizationRay van Brandenburg



draft-ietf-a=
vtcore-idms-03


15:30
Duplicating RTP StreamsBegen



=
draft-begen-avtcore-rtp-duplication-01


15:40
Multipath RTP Varun Singh



draft-singh-av=
t-mprtp-04


15:50
End


------=_NextPart_000_0042_01CD01CA.F02D13C0--


From ron.even.tlv@gmail.com  Wed Mar 14 01:30:29 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D38E21F8528 for ; Wed, 14 Mar 2012 01:30:29 -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.242, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, 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 6o8iPEsTxLEE for ; Wed, 14 Mar 2012 01:30:28 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC2621F869C for ; Wed, 14 Mar 2012 01:30:28 -0700 (PDT)
Received: by wibhq7 with SMTP id hq7so1737469wib.13 for ; Wed, 14 Mar 2012 01:30:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=zna00cOmvRDTZawc7c/leD5wUVSsbmpWr6yPjM4ZQ+M=; b=k2RWR3mHTf4IBGBOlCzjLMEVcy5gEoLkDEpT94lPyT16kZYW03Jr6GSxFNvwyl7c+x pQAw84LcbzUJlb46GZywI9+M7ufzRxLQVt4G0a1QCVSXHTjg/K4dwxMDifcNdQhk/Ook HiXFwaxnZ41uVrW7I0wSy701E91kV9ftokJmX5WCL9/CI/vqMvouXKLypzmYuh7hn+ZO EAmc3x43cFiw2oOxhztBXlr0szq6Xu1hSJx/1LUse5QCmaNXZwRPa/ibPSktRRqopueV SdnFQ5LsA3CFmzEao/iKNi504OKDRYHHOoJPrNuJEkYr8LaJBLJ9OHonCBUgeYVrvoij akJQ==
Received: by 10.180.24.4 with SMTP id q4mr14729465wif.7.1331713827400; Wed, 14 Mar 2012 01:30:27 -0700 (PDT)
Received: from windows8d787f9 (bzq-79-179-219-130.red.bezeqint.net. [79.179.219.130]) by mx.google.com with ESMTPS id e6sm47049056wix.8.2012.03.14.01.30.25 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Mar 2012 01:30:26 -0700 (PDT)
From: "Roni Even" 
To: "'IETF AVTCore WG'" 
Date: Wed, 14 Mar 2012 10:29:35 +0200
Message-ID: <4f605722.e64eb40a.68e9.46a0@mx.google.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_004B_01CD01CD.5B39F1E0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac0BuipXL86K29YNRVyAx/RlKCzX/w==
Content-Language: en-us
Subject: [AVTCORE] Updated agenda for AVTcore session in IETF83 - wrong link
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 08:30:29 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_004B_01CD01CD.5B39F1E0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_004C_01CD01CD.5B39F1E0"


------=_NextPart_001_004C_01CD01CD.5B39F1E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

Fixed a wrong link for multipath RTP

 

Roni

 

 

Audio/Video Transport Core Maintenance  (AVTCore) Working Group

===============================================================

 

CHAIRS:  Magnus Westerlund       

         Roni Even         

 

AGENDA

 

Monday, 26 March 2012 at 13:00-16:10 (252B)

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

13:00   AVTCore Status Update                               (Chairs, 15)

 

13:15   Why RTP Sessions Should Be Content Neutral(Harald Alvestrand , 15)

        draft-alvestrand-rtp-sess-neutral-00

 

13:30   RTP Multiplexing Architecture           (Magnus Westerlund , 20)

        draft-westerlund-avtcore-multiplex-architecture-01

 

13:50   Multiple RTP Session on a Single Lower-Layer Transport(Magnus
Westerlund , 35)

        draft-westerlund-avtcore-transport-multiplexing-02

 

14:25   RTP Congestion Control: Circuit Breakers for Unicast Sessions(Colin
Perkins , 15)

        draft-perkins-avtcore-rtp-circuit-breakers-00

 

14:40   RTP Topology Considerations for Offer/Answer-Initiated
Sessions(Jonathan Lennox, 20)

        draft-lennox-avtcore-rtp-topo-offer-answer-00

 

15:00   Break (if needed)                                         (, 10)

 

15:10   RTP Clock Source Signalling                 (Aidan Williams, 10)

        draft-williams-avtcore-clksrc-00

 

15:20   RTCP for inter-destination media synchronization(Ray van
Brandenburg, 10)

        draft-ietf-avtcore-idms-03

 

15:30   Duplicating RTP Streams                              (Begen, 10)

        draft-begen-avtcore-rtp-duplication-01

 

15:40   Multipath RTP                                  (Varun Singh, 10)

        draft-singh-avtcore-mprtp-04

 

15:50   End


------=_NextPart_001_004C_01CD01CD.5B39F1E0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi,
Fixed a wrong =
link for multipath RTP
 
Roni
 
 
Audio/Video =
Transport Core Maintenance  (AVTCore) Working =
Group
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
<=
p class=3DMsoNormal> 
CHAIRS:  Magnus =
Westerlund       =
<magnus.westerlund@ericsson.com>
         Roni =
Even         =
<even.roni@huawei.com>
 
AGENDA
 
Monday, 26 =
March 2012 at 13:00-16:10 (252B)
-------------------------------------------<=
/p>
13:00   AVTCore Status =
Update           &=
nbsp;  =
            &=
nbsp;    (Chairs, 15)
 
13:15   Why RTP Sessions Should Be Content =
Neutral(Harald Alvestrand , 15)
        =
draft-alvestrand-rtp-sess-neutral-00
 
13:30   RTP Multiplexing =
Architecture           =
(Magnus Westerlund , 20)
        =
draft-westerlund-avtcore-multiplex-architecture-01
 
13:50   Multiple RTP Session on a Single =
Lower-Layer Transport(Magnus Westerlund , 35)
        =
draft-westerlund-avtcore-transport-multiplexing-02
 
14:25   RTP Congestion Control: Circuit =
Breakers for Unicast Sessions(Colin Perkins , 15)
        =
draft-perkins-avtcore-rtp-circuit-breakers-00
 
14:40   RTP Topology Considerations for =
Offer/Answer-Initiated Sessions(Jonathan Lennox, 20)
        =
draft-lennox-avtcore-rtp-topo-offer-answer-00
 
15:00   Break (if =
needed)           =
       =
            &=
nbsp;          (, =
10)
 
15:10   RTP Clock Source =
Signalling          &nb=
sp;      (Aidan Williams, 10)
        =
draft-williams-avtcore-clksrc-00
 
15:20   RTCP for inter-destination media =
synchronization(Ray van Brandenburg, 10)
        =
draft-ietf-avtcore-idms-03
 
15:30   Duplicating RTP =
Streams           =
            &=
nbsp;      (Begen, 10)
        =
draft-begen-avtcore-rtp-duplication-01
 
15:40   Multipath =
RTP           &nbs=
p;            =
;          (Varun Singh, =
10)
        =
draft-singh-avtcore-mprtp-04
 
15:50   =
End

------=_NextPart_001_004C_01CD01CD.5B39F1E0--

------=_NextPart_000_004B_01CD01CD.5B39F1E0
Content-Type: text/html;
	name="agenda.html"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="agenda.html"



Audio/Video Transport Core Maintenance  (AVTCore) Working Group =
Agenda


Audio/Video Transport Core Maintenance  =
(AVTCore) Working Group Agenda







Chairs: Magnus Westerlund       , Roni =
Even         





Monday, 26 March 2012 at 13:00-16:10 (252B)







13:00
AVTCore Status UpdateChairs


13:15
Why RTP Sessions Should Be Content NeutralHarald Alvestrand=20



dr=
aft-alvestrand-rtp-sess-neutral-00


13:30
RTP Multiplexing ArchitectureMagnus Westerlund=20



draft-westerlund-avtcore-multiplex-architecture-01


13:50
Multiple RTP Session on a Single Lower-Layer =
TransportMagnus Westerlund=20



draft-westerlund-avtcore-transport-multiplexing-02


14:25
RTP Congestion Control: Circuit Breakers for Unicast =
SessionsColin Perkins=20



draft-perkins-avtcore-rtp-circuit-breakers-00


14:40
RTP Topology Considerations for =
Offer/Answer-Initiated SessionsJonathan Lennox



draft-lennox-avtcore-rtp-topo-offer-answer-00


15:00
Break (if needed)


15:10
RTP Clock Source SignallingAidan =
Williams



draft-=
williams-avtcore-clksrc-00


15:20
RTCP for inter-destination media synchronizationRay van Brandenburg



draft-ietf-a=
vtcore-idms-03


15:30
Duplicating RTP StreamsBegen



=
draft-begen-avtcore-rtp-duplication-01


15:40
Multipath RTP Varun Singh



draft-sing=
h-avtcore-mprtp-04


15:50
End


------=_NextPart_000_004B_01CD01CD.5B39F1E0--


From magnus.westerlund@ericsson.com  Wed Mar 14 02:54:58 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BEE21F8679 for ; Wed, 14 Mar 2012 02:54:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.362
X-Spam-Level: 
X-Spam-Status: No, score=-110.362 tagged_above=-999 required=5 tests=[AWL=0.237, 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 lRyfbW51vVSS for ; Wed, 14 Mar 2012 02:54:57 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4951321F867A for ; Wed, 14 Mar 2012 02:54:57 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c6fae0000045c0-c3-4f606af026db
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9F.F3.17856.0FA606F4; Wed, 14 Mar 2012 10:54:56 +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.213.0; Wed, 14 Mar 2012 10:54:54 +0100
Message-ID: <4F606AED.6070804@ericsson.com>
Date: Wed, 14 Mar 2012 10:54:53 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: IETF AVTCore WG 
X-Enigmail-Version: 1.3.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Subject: [AVTCORE] Creating a milestone for the specification of how to use ARIA with SRTP
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 09:54:58 -0000

WG,

Cryptographic algorithms that someone desires to use with SRTP needs to
be specified and their identifiers registered with the key-management
protocol. IETF currently has three different key-management protocols.
The Security Descriptions registry requires standards action to define
additional registry entries for crypto suits. ARIA is a South Korean
crypto standard and also published as informational RFC 5794. I think
there needs to be strong motivations why we would not go ahead and
specify this usage. We WG chairs propose the following milestone.

Dec 2012  Submit SRTP Cryptographic Transform(s) based on the ARIA
algorithm and corresponding key-management profiles for Security
Descriptions, MIKEY and DTLS-SRTP for publication as proposed standard

WG, please provide input on this milestone no later than the 26th 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 eckelcu@cisco.com  Wed Mar 14 15:46:35 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D886411E8081 for ; Wed, 14 Mar 2012 15:46:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.26
X-Spam-Level: 
X-Spam-Status: No, score=-9.26 tagged_above=-999 required=5 tests=[AWL=1.339,  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 bLRljgQ8W4yQ for ; Wed, 14 Mar 2012 15:46:35 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id E137A11E8075 for ; Wed, 14 Mar 2012 15:46:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=4734; q=dns/txt; s=iport; t=1331765194; x=1332974794; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=38x112VxR7TTI5bjAiFjWXPg0DnSH5mNwaueBkKOx4k=; b=iD+LDE8e+08n7yfcBSUf8tbpwB3wTN6RcMtVfJ8Vz2lTVGmm71rV8GMS EDMoCUpCtP0N5j08LBittJpW6bB6THgQojA2+mY62AnN4fdvUxnwKuoWo NJZo42Fq98iwpjohkj0f/Yg7k+kQifja9iRd+AX2Qa6ygbGC6yN70mHGg o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAG0eYU+rRDoG/2dsb2JhbABDti2BB4IJAQEBBAEBAQkGAR1VAgICAQgRAQMBAQsGFwEGARoMHwMGCAEBBAESCBqHZwELmxWfJwQEkBhjBIgkM5s/gWiDBg
X-IronPort-AV: E=Sophos;i="4.73,586,1325462400"; d="scan'208";a="33593693"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 14 Mar 2012 22:46:34 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2EMkYC6009658; Wed, 14 Mar 2012 22:46:34 GMT
Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 14 Mar 2012 15:46:34 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 14 Mar 2012 15:46:33 -0700
Message-ID: 
In-Reply-To: <4F546EDF.10203@ericsson.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [AVTCORE] WG last call on Monitoring Architecture for RTP(draft-ietf-avtcore-monarch-11)
Thread-Index: Acz6o9KdvRPwk6BwR+utSJqPWZZFfAHiYHRw
References: <4F546EDF.10203@ericsson.com>
From: "Charles Eckel (eckelcu)" 
To: "Magnus Westerlund" , "IETF AVTCore WG" 
X-OriginalArrivalTime: 14 Mar 2012 22:46:34.0327 (UTC) FILETIME=[4E90A670:01CD0234]
Subject: Re: [AVTCORE] WG last call on Monitoring Architecture for RTP(draft-ietf-avtcore-monarch-11)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Mar 2012 22:46:36 -0000

I have read this draft and think it is in good shape.
I have the following editorial recommendations.

1) Section 1, reads as follows:
   However the proliferation of RTP/RTCP specific metrics for transport
   and application quality monitoring has been identified as a potential
   problem for RTP/RTCP interoperability, which attempt to provide full
   coverage of all those parameters of concern to a specific
   application.
I suggest rewording this as follows:
   The proliferation of RTP/RTCP specific metrics for transport
   and application quality monitoring has been identified as a potential
   problem for interoperability when using RTP/RTCP to communicate all=20
   the parameters of concern to a specific application.

2) Section 2, Application level metric definition
r/the service level and is/the service level and are

3) Section 2, Direct metrics definition
r/other metric/other metrics

4) Section 2, Composed metrics definition, reads as follows:
      Metrics that are not directly measured and derived from other
      metrics.  One example of such metrics is the ones calculated based
      on Direct metric that have been measured.
I suggest rewording as follows:
      Metrics that are not measured directly but rather are derived from =
one or=20
      more other metrics. An example is a metric calculated based on =
derived metrics
      that have been measured.

5) Section 2, Sampled metrics definition
r/measured or calculated that/measure or calculated metric that

6) Section 3, last word
r/mechanism/mechanisms

7) Section 3.1
r/RTP is used/RTP may be used,
Also, expand ASM and SSM.

8) Section 4, first bullet
r/Design compound/Designing compound

9) Section 4, second bullet, reads as follows:
   o  Correlating RTCP XR with the non-RTP data.  Canonical End-Point
      Identifier SDES Item (CNAME) defined in the RTP Protocol [RFC3550]
      is an example of existing tool that allows to bind an
      Synchronization source (SSRC) that may change to a fixed source
      name in one RTP session.  It may be also fixed across multiple RTP
      sessions from the same source.
I suggest rewording as follows:
   o  Correlating RTCP XR with the non-RTP data.  Canonical End-Point
      Identifier SDES Item (CNAME), defined in the RTP Protocol =
[RFC3550],
      is an example of an existing tool that allows binding a
      Synchronization source (SSRC) that may change to a name that is
      fixed within one RTP session.  CNAME may be also fixed across =
multiple RTP
      sessions from the same source.
Also
r/should be concerned/should be provided

10) Section 4, third bullet
r/"metric interval. In such case"/"metric intervals. In such cases"

11) Section 5.1, second paragraph
r/this memo proposes the use of single metrics block each =
containing/this memo recommends the definition of metrics blocks =
containing

12) Section 5.2,
r/There may be situation/There may be situations
r/one media transport protocols are used/one media transport protocol is =
used
r/"in a VOIP session one"/"in a VOIP session. One"

13) Section 5.3,
r/even if though/even though

Cheers,
Charles
=20
> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of
> Magnus Westerlund
> Sent: Sunday, March 04, 2012 11:45 PM
> To: IETF AVTCore WG
> Subject: [AVTCORE] WG last call on Monitoring Architecture for
> RTP(draft-ietf-avtcore-monarch-11)
>=20
> WG,
>=20
> This initiates the Working group last call on Monitoring Architecture
> for RTP (draft-ietf-avtcore-monarch-11) to be published as
> Informational
> RFC. The WG last call will run for three weeks and end Monday the =
26th.
>=20
> The draft can be retrieved from here:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-monarch/
>=20
> Please provide feedback if you have read it, even if you have no
> comments or think it is good enough, this is important information in
> judging the support and readiness for publication.
>=20
> Thanks
>=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
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

From ron.even.tlv@gmail.com  Thu Mar 15 04:47:45 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143B621F8692 for ; Thu, 15 Mar 2012 04:47:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.227
X-Spam-Level: 
X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=0.371,  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 HbnaAr3TSd0k for ; Thu, 15 Mar 2012 04:47:44 -0700 (PDT)
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1444A21F867F for ; Thu, 15 Mar 2012 04:47:43 -0700 (PDT)
Received: by wibhr17 with SMTP id hr17so7519643wib.1 for ; Thu, 15 Mar 2012 04:47:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=K6u3tBlwVCCIwv3ZnsNoseJFsTjwTPL4InX/Zo00ah8=; b=DVX6kMo6ZiepduTcPcQHSW6OrQqJnuNjK8fcNoS/GhTnJhRTn+ZI2q52bFrVd88Jih dAiaWimXDDtbcfh9kPutNVXyW6vW+vXoSJDiC0IEHAls01K9u8TOPtmA13dDZA1LTd6A Om6Ub9li8NslkSjMPLlsSOfpo3yydZywD6VtEPXmdbf9upskk5FWwCANyszaKX3wSg3q e2HXgc7m6LQOWPq7k4N+7sI4RU8SlhkkVaIxEL6rYHMV05z+ymOUVrrp65cyJ+F4i+8t SianzW3vRNN/igtP9DH0JFIaQU29QVF7tQmihY66iaJYB2b2U28utkh175sqHS3HzfSo qdJw==
Received: by 10.180.83.97 with SMTP id p1mr14847290wiy.19.1331812062985; Thu, 15 Mar 2012 04:47:42 -0700 (PDT)
Received: from windows8d787f9 (bzq-79-179-219-130.red.bezeqint.net. [79.179.219.130]) by mx.google.com with ESMTPS id o2sm7361309wiv.11.2012.03.15.04.47.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Mar 2012 04:47:42 -0700 (PDT)
From: "Roni Even" 
To: "'IETF AVTCore WG'" 
Date: Thu, 15 Mar 2012 13:46:46 +0200
Message-ID: <4f61d6de.e249b40a.33a4.ffffe28f@mx.google.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01CD02B2.11D8AF60"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac0CoUwtdhWmyOivRTS6jm5dSPeaLw==
Content-Language: en-us
Subject: [AVTCORE] Input on draft-alvestrand-rtp-sess-neutral-00
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 11:47:45 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0030_01CD02B2.11D8AF60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

I am sending this review to the AVTcore list since it will be on the AVTcore
agenda for Paris.

 

My input is as an individual.

 

I think the review given in the document provides a good discussion point on
the multiplexing issue with regards to RTP sessions.

 

Section 5 discuss section 5.2 of RFC 3550 which lists 5 problems why not to
multiplex different RTP media types in one RTP session.

 

Problems 1-3 are addressed by using different SSRCs while for point 5 my
understanding is that the draft  suggests using BUNDLE to signal the
different priority partitions. 

 

This leaves problem 4 (the mixer). Section 7 of RFC  3550 does not mandate
any specific mixing, I assume that it was meant that since an RTP session is
composed of the same media type it will allow the mixer to combine all input
RTP streams using his own (Single?) SSRC. This is probably already broken
for the examples listed in the draft (FEC,  T140) if the RTP mixer does not
know how it can mix the subtypes only based on the RTP header information
(for dynamic payload type numbers) without having the SDP information.

I think that the issue of the RTP mixer behavior should also be discussed
and some text is needed to explain what is needed for it to work. I think
this is the motivation for signaling the RTP session as part of the RTP
information or we can say that RTP mixer will not work for different media
type or even for the cases in the examples (FEC, T140). This can be an
update to the topology draft (RFC5117).

 

Roni Even


------=_NextPart_000_0030_01CD02B2.11D8AF60
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi,
I am sending =
this review to the AVTcore list since it will be on the AVTcore agenda =
for Paris.
 
My input is as an individual.
 
I think the =
review given in the document provides a good discussion point on the =
multiplexing issue with regards to RTP sessions.
 
Section 5 =
discuss section 5.2 of RFC 3550 which lists 5 problems why not to =
multiplex different RTP media types in one RTP session.
 
Problems 1-3 =
are addressed by using different SSRCs while for point 5 my =
understanding is that the draft  suggests using BUNDLE to signal =
the different priority partitions. 
 
This leaves =
problem 4 (the mixer). Section 7 of RFC  3550 does not mandate any =
specific mixing, I assume that it was meant that since an RTP session is =
composed of the same media type it will allow the mixer to combine all =
input RTP streams using his own (Single?) SSRC. This is probably already =
broken for the examples listed in the draft (FEC,  T140) if the RTP =
mixer does not know how it can mix the subtypes only based on the RTP =
header information (for dynamic payload type numbers) without having the =
SDP information.
I think that the =
issue of the RTP mixer behavior should also be discussed and some text =
is needed to explain what is needed for it to work. I think this is the =
motivation for signaling the RTP session as part of the RTP information =
or we can say that RTP mixer will not work for different media type or =
even for the cases in the examples (FEC, T140). This can be an update to =
the topology draft (RFC5117).
 
Roni =
Even

------=_NextPart_000_0030_01CD02B2.11D8AF60--


From ron.even.tlv@gmail.com  Thu Mar 15 10:19:25 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9029421F86E0 for ; Thu, 15 Mar 2012 10:19:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.268
X-Spam-Level: 
X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[AWL=0.330,  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 wFgjpNxsZHTn for ; Thu, 15 Mar 2012 10:19:25 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id D0B0721F86D8 for ; Thu, 15 Mar 2012 10:19:24 -0700 (PDT)
Received: by wibhq7 with SMTP id hq7so3815564wib.13 for ; Thu, 15 Mar 2012 10:19:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=vRQRwF/Hu5jV9G7Pg4C/wkSPzOKTWYcJ2rRWA7gVTIc=; b=Dr4UBE7yNLq4W/sLBB1SsFhPDF6omCZcw70iHlewVT4XdObIGIGoxegIKBxx3rGme5 24eKlqzNbaeB8HCbwfa7BO1WK7mxvNTGHHrTCTcwiVttX7ASoiJvvu8t9b+P6/ZGdY1j ogN4AjjelIivQK+vplIbDuPNgkqR8skVTexFsQjk1WRX52+eykn8jCukG5LDBIDEG5FF ML2sx179m7R/soX4yCuPL1B0Wj0WtlmbF4JcM125v6Ur1Pr5NXbU05ymw3IZulERp4F3 ndjVkzIZwpC3M9fWNs1TVM/jHSwnYnlRocTq044agWpSclUjW8ruyQ0uAxKXQdoUXl8U G/2A==
Received: by 10.180.107.162 with SMTP id hd2mr28136472wib.8.1331831963973; Thu, 15 Mar 2012 10:19:23 -0700 (PDT)
Received: from windows8d787f9 (bzq-79-179-219-130.red.bezeqint.net. [79.179.219.130]) by mx.google.com with ESMTPS id p10sm6619173wic.0.2012.03.15.10.19.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Mar 2012 10:19:23 -0700 (PDT)
From: "Roni Even" 
To: "'IETF AVTCore WG'" 
Date: Thu, 15 Mar 2012 19:18:26 +0200
Message-ID: <4f62249b.8a0eb40a.628f.6e47@mx.google.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01CD02E0.6788C980"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac0Cz6ISeBtb9qvsR3utYezOVc6Y6A==
Content-Language: en-us
Subject: [AVTCORE] draft-westerlund-avtcore-multiplex-architecture-01 - same SSRC
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Mar 2012 17:19:25 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0054_01CD02E0.6788C980
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

I saw in section 3.2 a reference to RFC6190 about using same SSRC in
different RTP sessions. Can you point out where it is in RFC6190, I did not
see it.

 

Thanks

Roni Even


------=_NextPart_000_0054_01CD02E0.6788C980
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi,
I saw in =
section 3.2 a reference to RFC6190 about using same SSRC in different =
RTP sessions. Can you point out where it is in RFC6190, I did not see =
it.
 
Thanks
Roni =
Even

------=_NextPart_000_0054_01CD02E0.6788C980--


From bill.wu@huawei.com  Fri Mar 16 00:19:18 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A13C21E8035 for ; Fri, 16 Mar 2012 00:19:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.648
X-Spam-Level: 
X-Spam-Status: No, score=-4.648 tagged_above=-999 required=5 tests=[AWL=0.198,  BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 qTtr1Dn0DQNH for ; Fri, 16 Mar 2012 00:19:17 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id DAF4021E8020 for ; Fri, 16 Mar 2012 00:19:16 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0Y00LCPV040Z@szxga04-in.huawei.com> for avt@ietf.org; Fri, 16 Mar 2012 15:19:16 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0Y00B9RV0332@szxga04-in.huawei.com> for avt@ietf.org; Fri, 16 Mar 2012 15:19:16 +0800 (CST)
Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AHM41279; Fri, 16 Mar 2012 15:19:15 +0800
Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Mar 2012 15:18:18 +0800
Received: from w53375 (10.138.41.149) by szxeml405-hub.china.huawei.com (10.82.67.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Mar 2012 15:19:08 +0800
Date: Fri, 16 Mar 2012 15:19:07 +0800
From: Qin Wu 
X-Originating-IP: [10.138.41.149]
To: "Charles Eckel (eckelcu)" , Magnus Westerlund , IETF AVTCore WG 
Message-id: <819F88273E5D420FBDEEE792010E185D@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: base64
X-Priority: 3
X-MSMail-priority: Normal
X-CFilter-Loop: Reflected
References: <4F546EDF.10203@ericsson.com> 
Subject: Re: [AVTCORE] WG last call on Monitoring Architecture forRTP(draft-ietf-avtcore-monarch-11)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Mar 2012 07:19:18 -0000

SGksIENoYXJsZXM6DQpJIGFjY2VwdCBhbGwgeW91ciBjb21tZW50cyBhbmQgd2lsbCBpc3N1ZSBu
ZXcgdmVyc2lvbiB0byBhZGRyZXNzIHVwb24gTEMgaXMgZG9uZS4NClRoYW5rcyBmb3IgeW91ciB2
YWx1YWJsZSByZXZpZXcuIA0KDQpSZWdhcmRzIQ0KLVFpbg0KLS0tLS0gT3JpZ2luYWwgTWVzc2Fn
ZSAtLS0tLSANCj5Gcm9tOiAiQ2hhcmxlcyBFY2tlbCAoZWNrZWxjdSkiIDxlY2tlbGN1QGNpc2Nv
LmNvbT4NCj5UbzogIk1hZ251cyBXZXN0ZXJsdW5kIiA8bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nz
b24uY29tPjsgIklFVEYgQVZUQ29yZSBXRyIgPGF2dEBpZXRmLm9yZz4NCj5TZW50OiBUaHVyc2Rh
eSwgTWFyY2ggMTUsIDIwMTIgNjo0NiBBTQ0KPlN1YmplY3Q6IFJlOiBbQVZUQ09SRV0gV0cgbGFz
dCBjYWxsIG9uIE1vbml0b3JpbmcgQXJjaGl0ZWN0dXJlIGZvclJUUChkcmFmdC1pZXRmLWF2dGNv
cmUtbW9uYXJjaC0xMSkNCg0KDQo+SSBoYXZlIHJlYWQgdGhpcyBkcmFmdCBhbmQgdGhpbmsgaXQg
aXMgaW4gZ29vZCBzaGFwZS4NCj5JIGhhdmUgdGhlIGZvbGxvd2luZyBlZGl0b3JpYWwgcmVjb21t
ZW5kYXRpb25zLg0KDQo+MSkgU2VjdGlvbiAxLCByZWFkcyBhcyBmb2xsb3dzOg0KPiAgIEhvd2V2
ZXIgdGhlIHByb2xpZmVyYXRpb24gb2YgUlRQL1JUQ1Agc3BlY2lmaWMgbWV0cmljcyBmb3IgdHJh
bnNwb3J0DQo+ICAgYW5kIGFwcGxpY2F0aW9uIHF1YWxpdHkgbW9uaXRvcmluZyBoYXMgYmVlbiBp
ZGVudGlmaWVkIGFzIGEgcG90ZW50aWFsDQo+ICAgcHJvYmxlbSBmb3IgUlRQL1JUQ1AgaW50ZXJv
cGVyYWJpbGl0eSwgd2hpY2ggYXR0ZW1wdCB0byBwcm92aWRlIGZ1bGwNCj4gICBjb3ZlcmFnZSBv
ZiBhbGwgdGhvc2UgcGFyYW1ldGVycyBvZiBjb25jZXJuIHRvIGEgc3BlY2lmaWMNCj4gICBhcHBs
aWNhdGlvbi4NCj5JIHN1Z2dlc3QgcmV3b3JkaW5nIHRoaXMgYXMgZm9sbG93czoNCj4gICBUaGUg
cHJvbGlmZXJhdGlvbiBvZiBSVFAvUlRDUCBzcGVjaWZpYyBtZXRyaWNzIGZvciB0cmFuc3BvcnQN
Cj4gICBhbmQgYXBwbGljYXRpb24gcXVhbGl0eSBtb25pdG9yaW5nIGhhcyBiZWVuIGlkZW50aWZp
ZWQgYXMgYSBwb3RlbnRpYWwNCj4gICBwcm9ibGVtIGZvciBpbnRlcm9wZXJhYmlsaXR5IHdoZW4g
dXNpbmcgUlRQL1JUQ1AgdG8gY29tbXVuaWNhdGUgYWxsIA0KPiAgIHRoZSBwYXJhbWV0ZXJzIG9m
IGNvbmNlcm4gdG8gYSBzcGVjaWZpYyBhcHBsaWNhdGlvbi4NCg0KW1Fpbl06IFRoZSBuZXcgd29y
ZGluZyBsb29rcyBiZXR0ZXIgdG8gbWUuIFRoYW5rcy4gDQoNCj4yKSBTZWN0aW9uIDIsIEFwcGxp
Y2F0aW9uIGxldmVsIG1ldHJpYyBkZWZpbml0aW9uDQo+ci90aGUgc2VydmljZSBsZXZlbCBhbmQg
aXMvdGhlIHNlcnZpY2UgbGV2ZWwgYW5kIGFyZQ0KDQpbUWluXTogT2theS4NCg0KPjMpIFNlY3Rp
b24gMiwgRGlyZWN0IG1ldHJpY3MgZGVmaW5pdGlvbg0KPnIvb3RoZXIgbWV0cmljL290aGVyIG1l
dHJpY3MNCg0KW1Fpbl06IE9rYXkuDQoNCj40KSBTZWN0aW9uIDIsIENvbXBvc2VkIG1ldHJpY3Mg
ZGVmaW5pdGlvbiwgcmVhZHMgYXMgZm9sbG93czoNCj4gICAgICBNZXRyaWNzIHRoYXQgYXJlIG5v
dCBkaXJlY3RseSBtZWFzdXJlZCBhbmQgZGVyaXZlZCBmcm9tIG90aGVyDQo+ICAgICAgbWV0cmlj
cy4gIE9uZSBleGFtcGxlIG9mIHN1Y2ggbWV0cmljcyBpcyB0aGUgb25lcyBjYWxjdWxhdGVkIGJh
c2VkDQo+ICAgICAgb24gRGlyZWN0IG1ldHJpYyB0aGF0IGhhdmUgYmVlbiBtZWFzdXJlZC4NCj5J
IHN1Z2dlc3QgcmV3b3JkaW5nIGFzIGZvbGxvd3M6DQo+ICAgICAgTWV0cmljcyB0aGF0IGFyZSBu
b3QgbWVhc3VyZWQgZGlyZWN0bHkgYnV0IHJhdGhlciBhcmUgZGVyaXZlZCBmcm9tIG9uZSBvciAN
Cj4gICAgICBtb3JlIG90aGVyIG1ldHJpY3MuIEFuIGV4YW1wbGUgaXMgYSBtZXRyaWMgY2FsY3Vs
YXRlZCBiYXNlZCBvbiBkZXJpdmVkIG1ldHJpY3MNCj4gICAgICB0aGF0IGhhdmUgYmVlbiBtZWFz
dXJlZC4NCg0KW1Fpbl06IEdvb2Qgd29yZGluZywgdGhhbmtzLg0KDQo+NSkgU2VjdGlvbiAyLCBT
YW1wbGVkIG1ldHJpY3MgZGVmaW5pdGlvbg0KPnIvbWVhc3VyZWQgb3IgY2FsY3VsYXRlZCB0aGF0
L21lYXN1cmUgb3IgY2FsY3VsYXRlZCBtZXRyaWMgdGhhdA0KDQoNCltRaW5dOiBPa2F5Lg0KDQo+
NikgU2VjdGlvbiAzLCBsYXN0IHdvcmQNCj5yL21lY2hhbmlzbS9tZWNoYW5pc21zDQoNCltRaW5d
OiBPa2F5Lg0KDQo+NykgU2VjdGlvbiAzLjENCj5yL1JUUCBpcyB1c2VkL1JUUCBtYXkgYmUgdXNl
ZCwNCj5BbHNvLCBleHBhbmQgQVNNIGFuZCBTU00uDQoNCg0KW1Fpbl06IE9rYXkuDQoNCj44KSBT
ZWN0aW9uIDQsIGZpcnN0IGJ1bGxldA0KPnIvRGVzaWduIGNvbXBvdW5kL0Rlc2lnbmluZyBjb21w
b3VuZA0KDQpbUWluXTogT2theS4NCg0KPjkpIFNlY3Rpb24gNCwgc2Vjb25kIGJ1bGxldCwgcmVh
ZHMgYXMgZm9sbG93czoNCj4gICBvICBDb3JyZWxhdGluZyBSVENQIFhSIHdpdGggdGhlIG5vbi1S
VFAgZGF0YS4gIENhbm9uaWNhbCBFbmQtUG9pbnQNCj4gICAgICBJZGVudGlmaWVyIFNERVMgSXRl
bSAoQ05BTUUpIGRlZmluZWQgaW4gdGhlIFJUUCBQcm90b2NvbCBbUkZDMzU1MF0NCj4gICAgICBp
cyBhbiBleGFtcGxlIG9mIGV4aXN0aW5nIHRvb2wgdGhhdCBhbGxvd3MgdG8gYmluZCBhbg0KPiAg
ICAgIFN5bmNocm9uaXphdGlvbiBzb3VyY2UgKFNTUkMpIHRoYXQgbWF5IGNoYW5nZSB0byBhIGZp
eGVkIHNvdXJjZQ0KPiAgICAgIG5hbWUgaW4gb25lIFJUUCBzZXNzaW9uLiAgSXQgbWF5IGJlIGFs
c28gZml4ZWQgYWNyb3NzIG11bHRpcGxlIFJUUA0KPiAgICAgIHNlc3Npb25zIGZyb20gdGhlIHNh
bWUgc291cmNlLg0KPkkgc3VnZ2VzdCByZXdvcmRpbmcgYXMgZm9sbG93czoNCj4gICBvICBDb3Jy
ZWxhdGluZyBSVENQIFhSIHdpdGggdGhlIG5vbi1SVFAgZGF0YS4gIENhbm9uaWNhbCBFbmQtUG9p
bnQNCj4gICAgICBJZGVudGlmaWVyIFNERVMgSXRlbSAoQ05BTUUpLCBkZWZpbmVkIGluIHRoZSBS
VFAgUHJvdG9jb2wgW1JGQzM1NTBdLA0KPiAgICAgIGlzIGFuIGV4YW1wbGUgb2YgYW4gZXhpc3Rp
bmcgdG9vbCB0aGF0IGFsbG93cyBiaW5kaW5nIGENCj4gICAgICBTeW5jaHJvbml6YXRpb24gc291
cmNlIChTU1JDKSB0aGF0IG1heSBjaGFuZ2UgdG8gYSBuYW1lIHRoYXQgaXMNCj4gICAgICBmaXhl
ZCB3aXRoaW4gb25lIFJUUCBzZXNzaW9uLiAgQ05BTUUgbWF5IGJlIGFsc28gZml4ZWQgYWNyb3Nz
IG11bHRpcGxlIFJUUA0KPiAgICAgIHNlc3Npb25zIGZyb20gdGhlIHNhbWUgc291cmNlLg0KPkFs
c28NCj5yL3Nob3VsZCBiZSBjb25jZXJuZWQvc2hvdWxkIGJlIHByb3ZpZGVkDQoNCltRaW5dOiBP
a2F5Lg0KDQo+MTApIFNlY3Rpb24gNCwgdGhpcmQgYnVsbGV0DQo+ci8ibWV0cmljIGludGVydmFs
LiBJbiBzdWNoIGNhc2UiLyJtZXRyaWMgaW50ZXJ2YWxzLiBJbiBzdWNoIGNhc2VzIg0KDQpbUWlu
XTogT2theS4NCg0KPjExKSBTZWN0aW9uIDUuMSwgc2Vjb25kIHBhcmFncmFwaA0KPnIvdGhpcyBt
ZW1vIHByb3Bvc2VzIHRoZSB1c2Ugb2Ygc2luZ2xlIG1ldHJpY3MgYmxvY2sgZWFjaCBjb250YWlu
aW5nL3RoaXMgbWVtbyByZWNvbW1lbmRzIHRoZSBkZWZpbml0aW9uIG9mIG1ldHJpY3MgYmxvY2tz
IGNvbnRhaW5pbmcNCg0KW1Fpbl06IE9rYXkuDQoNCj4xMikgU2VjdGlvbiA1LjIsDQo+ci9UaGVy
ZSBtYXkgYmUgc2l0dWF0aW9uL1RoZXJlIG1heSBiZSBzaXR1YXRpb25zDQo+ci9vbmUgbWVkaWEg
dHJhbnNwb3J0IHByb3RvY29scyBhcmUgdXNlZC9vbmUgbWVkaWEgdHJhbnNwb3J0IHByb3RvY29s
IGlzIHVzZWQNCj5yLyJpbiBhIFZPSVAgc2Vzc2lvbiBvbmUiLyJpbiBhIFZPSVAgc2Vzc2lvbi4g
T25lIg0KDQpbUWluXTogT2theS4NCg0KPjEzKSBTZWN0aW9uIDUuMywNCj5yL2V2ZW4gaWYgdGhv
dWdoL2V2ZW4gdGhvdWdoDQoNCltRaW5dOiBPa2F5Lg0KDQo+Q2hlZXJzLA0KPkNoYXJsZXMNCiAN
Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogYXZ0LWJvdW5jZXNAaWV0Zi5v
cmcgW21haWx0bzphdnQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IE1hZ251cyBX
ZXN0ZXJsdW5kDQo+IFNlbnQ6IFN1bmRheSwgTWFyY2ggMDQsIDIwMTIgMTE6NDUgUE0NCj4gVG86
IElFVEYgQVZUQ29yZSBXRw0KPiBTdWJqZWN0OiBbQVZUQ09SRV0gV0cgbGFzdCBjYWxsIG9uIE1v
bml0b3JpbmcgQXJjaGl0ZWN0dXJlIGZvcg0KPiBSVFAoZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFy
Y2gtMTEpDQo+IA0KPiBXRywNCj4gDQo+IFRoaXMgaW5pdGlhdGVzIHRoZSBXb3JraW5nIGdyb3Vw
IGxhc3QgY2FsbCBvbiBNb25pdG9yaW5nIEFyY2hpdGVjdHVyZQ0KPiBmb3IgUlRQIChkcmFmdC1p
ZXRmLWF2dGNvcmUtbW9uYXJjaC0xMSkgdG8gYmUgcHVibGlzaGVkIGFzDQo+IEluZm9ybWF0aW9u
YWwNCj4gUkZDLiBUaGUgV0cgbGFzdCBjYWxsIHdpbGwgcnVuIGZvciB0aHJlZSB3ZWVrcyBhbmQg
ZW5kIE1vbmRheSB0aGUgMjZ0aC4NCj4gDQo+IFRoZSBkcmFmdCBjYW4gYmUgcmV0cmlldmVkIGZy
b20gaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1h
dnRjb3JlLW1vbmFyY2gvDQo+IA0KPiBQbGVhc2UgcHJvdmlkZSBmZWVkYmFjayBpZiB5b3UgaGF2
ZSByZWFkIGl0LCBldmVuIGlmIHlvdSBoYXZlIG5vDQo+IGNvbW1lbnRzIG9yIHRoaW5rIGl0IGlz
IGdvb2QgZW5vdWdoLCB0aGlzIGlzIGltcG9ydGFudCBpbmZvcm1hdGlvbiBpbg0KPiBqdWRnaW5n
IHRoZSBzdXBwb3J0IGFuZCByZWFkaW5lc3MgZm9yIHB1YmxpY2F0aW9uLg0KPiANCj4gVGhhbmtz
DQo+IA0KPiBNYWdudXMgV2VzdGVybHVuZA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBNdWx0aW1l
ZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RWTQ0KPiAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tDQo+IEVyaWNzc29uIEFCICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3
DQo+IEbkcvZnYXRhbiA2ICAgICAgICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5DQo+
IFNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbnwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBl
cmljc3Nvbi5jb20NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUg
TWFpbnRlbmFuY2UNCj4gYXZ0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vYXZ0DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KPkF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQo+YXZ0QGll
dGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnQNCj4=


From magnus.westerlund@ericsson.com  Fri Mar 16 00:41:22 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F0621F8657 for ; Fri, 16 Mar 2012 00:41:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.365
X-Spam-Level: 
X-Spam-Status: No, score=-110.365 tagged_above=-999 required=5 tests=[AWL=0.234, 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 iCj3e9nU+poM for ; Fri, 16 Mar 2012 00:41:21 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 455D921F8638 for ; Fri, 16 Mar 2012 00:41:20 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c6fae0000045c0-37-4f62ee9fde6b
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6F.09.17856.F9EE26F4; Fri, 16 Mar 2012 08:41:19 +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.213.0; Fri, 16 Mar 2012 08:41:19 +0100
Message-ID: <4F62EE9F.8080204@ericsson.com>
Date: Fri, 16 Mar 2012 08:41:19 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Roni Even 
References: <4f62249b.8a0eb40a.628f.6e47@mx.google.com>
In-Reply-To: <4f62249b.8a0eb40a.628f.6e47@mx.google.com>
X-Enigmail-Version: 1.3.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: 'IETF AVTCore WG' 
Subject: Re: [AVTCORE] draft-westerlund-avtcore-multiplex-architecture-01 - same SSRC
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Mar 2012 07:41:22 -0000

On 2012-03-15 18:18, Roni Even wrote:
> Hi,
> 
> I saw in section 3.2 a reference to RFC6190 about using same SSRC in
> different RTP sessions. Can you point out where it is in RFC6190, I did
> not see it.

No, it is not present in the RFC. In fact the RFC fails to to discuss
how to bind together the media streams between the different RTP
sessions when using MST mode. However, my analysis is that using the
same SSRC is the only feasible approach as CNAME is insufficient if you
would have more than two media sources from the same end-point present
in the same RTP session.

Section 5.2 of
https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtcp-sdes-srcname/
do have some more argumentation around this problem and proposing the
srcname as fix that takes us away from that requirement.

I talked to Jonathan Lennox about this and he agreed that this is the
logical interpretation.

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 bill.wu@huawei.com  Fri Mar 16 01:35:37 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4B021F85C3 for ; Fri, 16 Mar 2012 01:35: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]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWKqpu2szm+R for ; Fri, 16 Mar 2012 01:35:36 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [58.251.152.66]) by ietfa.amsl.com (Postfix) with ESMTP id A18B121F85C0 for ; Fri, 16 Mar 2012 01:35:36 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0Y009KAW673L@szxga03-in.huawei.com> for avt@ietf.org; Fri, 16 Mar 2012 15:44:31 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0Y00BKQW5ELK@szxga03-in.huawei.com> for avt@ietf.org; Fri, 16 Mar 2012 15:44:31 +0800 (CST)
Received: from szxeml211-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AHX39717; Fri, 16 Mar 2012 15:44:30 +0800
Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Mar 2012 15:43:33 +0800
Received: from w53375 (10.138.41.149) by szxeml422-hub.china.huawei.com (10.82.67.161) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Mar 2012 15:44:28 +0800
Date: Fri, 16 Mar 2012 15:44:27 +0800
From: Qin Wu 
X-Originating-IP: [10.138.41.149]
To: IETF AVTCore WG 
Message-id: <0FDFA5AD37E04C878E9027BE8DE0E860@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
X-CFilter-Loop: Reflected
References: <4F5B2F09.2090704@ericsson.com>  <10EE199408404E20922B52A3D8B367CD@china.huawei.com> 
Subject: Re: [AVTCORE] Regarding draft-ietf-avtcore-feedback-supression-rtp-15
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Mar 2012 08:35:37 -0000

[sorry, if you receive multiple copies of this message]

Hi, Tom:
Sorry for late. Statement 3 is just an advice.
I agree unauthenticated feedback is not equivalent to suspicious feedback. RFC4585 allow ignore suspicious feedback but does not say we MUST ignore any unauthenticated feedback.
Your proposal looks good to me. How about revise the last paragraph, section 7 as:
"
   Also note that endpoints that receive a Third Party Loss Report would
   be well-advised to minimize the risk of false TPLR messages from
   a malicious source (which results in unneeded suppression feedback
   at the target victim receiver(s). Suggested measure is to authenticate 
   the sender of the Third Party Loss Report. Accepting Third Party Loss Report 
   from un-authenticated sender can lead to a denial of service attack, where 
   the endpoint accepts poor quality media that could be repaired.
"
Hope this addresses your comment.

Regards!
-Qin

>----- Original Message ----- 
>From: "Van Caenegem, Tom (Tom)" 
>To: "Qin Wu" ; "Magnus Westerlund" ; "IETF AVTCore WG" 
>Sent: Tuesday, March 13, 2012 9:59 PM
>Subject: RE: [AVTCORE] Regarding draft-ietf-avtcore-feedback-supression-rtp-15


>Hi Qin,

>The issue on statement 2 : OK

>IMO your statement 3 ("Also note that endpoints that receive a Third Party Loss Report would 
>be well-advised to ignore it, unless the security is in place to authenticate the sender of the Third Party Loss Report") is an advice (/requirement?) that goes well beyond the recommendations in the security >section 8 of RFC 4585. 

>The latter indicates that senders/receivers should behave conservatively when observing strange reporting behaviour. 

>The section also states that false RTCP packets can be avoided by authenticating RTCP messages.  

>(see below the exact phrasing that I copied for your convenience)

>In line with these RFC 4585 recommendation, you seem to interprete "unauthenticated" RTCP messages as an example of "strange" reporting behavior, which I do not think was the intention from RFC >4585.

>My proposal would be to just indicate in your security section that a solution to minimise the risk on false TPLR messages from a malicious source (which results in unneeded suppression feedback at the >target victim receiver(s), is to make use of an authentication framework (in line with RFC 4585). 

>Regards
>Tom


>RFC 4585, section 8 (Security):

>(..)

>Senders as well as receivers SHOULD behave conservatively when
>   observing strange reporting behavior.  For excessive failure
>   reporting from one or a few receivers, the sender MAY decide to no
>   longer consider this feedback when adapting its transmission behavior
>   for the media stream.  In any case, senders and receivers SHOULD
>   still adhere to the maximum RTCP bandwidth but make sure that they
>   are capable of transmitting at least regularly scheduled RTCP
>   packets.  Senders SHOULD carefully consider how to adjust their
>   transmission bandwidth when encountering strange reporting behavior;
>   they MUST NOT increase their transmission bandwidth even if ignoring
>   suspicious feedback.

>   Attacks using false RTCP packets (Regular as well as Early ones) can
>   be avoided by authenticating all RTCP messages.  This can be achieved
>   by using the AVPF profile together with the Secure RTP profile as
>   defined in [22]; as a prerequisite, an appropriate combination of
>   those two profiles (an "SAVPF") is being specified [21].  Note that,
>   when employing group authentication (as opposed to source
>   authentication), the aforementioned attacks may be carried out by
>   malicious or malfunctioning group members in possession of the right
>   keying material.

From ron.even.tlv@gmail.com  Fri Mar 16 06:42:36 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809E221F86A7 for ; Fri, 16 Mar 2012 06:42:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.301
X-Spam-Level: 
X-Spam-Status: No, score=-3.301 tagged_above=-999 required=5 tests=[AWL=0.298,  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 MGklImp3cxio for ; Fri, 16 Mar 2012 06:42:35 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7A15621F8621 for ; Fri, 16 Mar 2012 06:42:35 -0700 (PDT)
Received: by wibhj6 with SMTP id hj6so659982wib.13 for ; Fri, 16 Mar 2012 06:42:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=wPK4c/PZfCg6iYOYl9xCFXAXtSudKeE8UXhX9GR0zxs=; b=oHXNtMz6OJrV9/SJzIlFCIubvimiRSLFH8s1+biYOfe0QjwCkQV2sGxS5xmRscntJq iNGqgG3TLKpRVpjDhnnG5rABnVCsfbkFWLQn32jzdj8GK+SvlKqaOSwX0bkoGqHh42gs 6gvRqzhCCWcSaG144bXKfYaPXgmrDmNPbMCQzt+Dyc0sw3gSZ/U+Q2xndlhqzCozDd5Z GBSV1Wsa0IP6zNBnlNWrxlBcUKdf1FoSjcLCUqGplO/us+27c8jOg0Hp6dxH+vtiygnw 3J1try0yi6cRLW1FXFq58jMgwsGi+FZlPooVqOz5q1I3RjX+5mM/uskZcpeRZPZ49ahn RRnQ==
Received: by 10.180.101.231 with SMTP id fj7mr6501070wib.15.1331905354651; Fri, 16 Mar 2012 06:42:34 -0700 (PDT)
Received: from windows8d787f9 (bzq-79-179-219-130.red.bezeqint.net. [79.179.219.130]) by mx.google.com with ESMTPS id k6sm13828275wie.9.2012.03.16.06.42.29 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Mar 2012 06:42:31 -0700 (PDT)
From: "Roni Even" 
To: "'Magnus Westerlund'" 
References: <4f62249b.8a0eb40a.628f.6e47@mx.google.com> <4F62EE9F.8080204@ericsson.com>
In-Reply-To: <4F62EE9F.8080204@ericsson.com>
Date: Fri, 16 Mar 2012 15:41:32 +0200
Message-ID: <4f634347.2614b40a.036d.fffff329@mx.google.com>
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: Ac0DSC64pfAz2xQLRviVv3r/sqzHGQAMdooA
Content-Language: en-us
Cc: 'IETF AVTCore WG' 
Subject: Re: [AVTCORE] draft-westerlund-avtcore-multiplex-architecture-01 - same SSRC
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Mar 2012 13:42:36 -0000

Hi Magnus,
I thought that RFC5583 is used to signal the media decoding dependency
between the different sessions as mentioned in section 7.2.3 of RFC =
6190.
I also think that this allows you to provide also the SSRC value of the
different RTP streams.

Roni Even

> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> Sent: Friday, March 16, 2012 9:41 AM
> To: Roni Even
> Cc: 'IETF AVTCore WG'
> Subject: Re: [AVTCORE] =
draft-westerlund-avtcore-multiplex-architecture-
> 01 - same SSRC
>=20
> On 2012-03-15 18:18, Roni Even wrote:
> > Hi,
> >
> > I saw in section 3.2 a reference to RFC6190 about using same SSRC in
> > different RTP sessions. Can you point out where it is in RFC6190, I
> > did not see it.
>=20
> No, it is not present in the RFC. In fact the RFC fails to to discuss
> how to bind together the media streams between the different RTP
> sessions when using MST mode. However, my analysis is that using the
> same SSRC is the only feasible approach as CNAME is insufficient if =
you
> would have more than two media sources from the same end-point present
> in the same RTP session.
>=20
> Section 5.2 of
> https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtcp-sdes-
> srcname/
> do have some more argumentation around this problem and proposing the
> srcname as fix that takes us away from that requirement.
>=20
> I talked to Jonathan Lennox about this and he agreed that this is the
> logical interpretation.
>=20
> Cheers
>=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
> ----------------------------------------------------------------------


From magnus.westerlund@ericsson.com  Fri Mar 16 08:06:50 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5B921F863D for ; Fri, 16 Mar 2012 08:06:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.069
X-Spam-Level: 
X-Spam-Status: No, score=-110.069 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, 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 94Yjq-YTYOvY for ; Fri, 16 Mar 2012 08:06:49 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id F0B5D21F8637 for ; Fri, 16 Mar 2012 08:06:41 -0700 (PDT)
X-AuditID: c1b4fb39-b7bf2ae0000069a1-4c-4f63570035ba
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 4D.B1.27041.007536F4; Fri, 16 Mar 2012 16:06:41 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Fri, 16 Mar 2012 16:06:40 +0100
Message-ID: <4F635700.8050505@ericsson.com>
Date: Fri, 16 Mar 2012 16:06:40 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Roni Even 
References: <4f62249b.8a0eb40a.628f.6e47@mx.google.com> <4F62EE9F.8080204@ericsson.com> <4f634347.2614b40a.036d.fffff329@mx.google.com>
In-Reply-To: <4f634347.2614b40a.036d.fffff329@mx.google.com>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: 'IETF AVTCore WG' 
Subject: Re: [AVTCORE] draft-westerlund-avtcore-multiplex-architecture-01 - same SSRC
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Mar 2012 15:06:51 -0000

On 2012-03-16 14:41, Roni Even wrote:
> Hi Magnus,
> I thought that RFC5583 is used to signal the media decoding dependency
> between the different sessions as mentioned in section 7.2.3 of RFC 6190.
> I also think that this allows you to provide also the SSRC value of the
> different RTP streams.

No, to my understanding RFC 5583 only defines how the media description
grouping to indicate which m= lines that contains dependent media. And
the a=depend SDP attribute links which RTP payload types in the
respective media descriptions. There is no linking of the SSRCs. So when
there is more than one SSRC with a given CNAME you have no other defined
method than to use the same SSRC value across sessions.

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 magnus.westerlund@ericsson.com  Fri Mar 16 08:45:05 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAE321F86B5 for ; Fri, 16 Mar 2012 08:45:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.371
X-Spam-Level: 
X-Spam-Status: No, score=-110.371 tagged_above=-999 required=5 tests=[AWL=0.228, 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 22cfcSE6ezWq for ; Fri, 16 Mar 2012 08:45:04 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id E08AD21F866C for ; Fri, 16 Mar 2012 08:45:03 -0700 (PDT)
X-AuditID: c1b4fb39-b7bf2ae0000069a1-82-4f635ffe6449
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D9.57.27041.EFF536F4; Fri, 16 Mar 2012 16:45:02 +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.213.0; Fri, 16 Mar 2012 16:45:02 +0100
Message-ID: <4F635FFE.2040703@ericsson.com>
Date: Fri, 16 Mar 2012 16:45:02 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: IETF AVTCore WG 
References: <4F635D10.3040607@ericsson.com>
In-Reply-To: <4F635D10.3040607@ericsson.com>
X-Enigmail-Version: 1.4
X-Forwarded-Message-Id: <4F635D10.3040607@ericsson.com>
Content-Type: multipart/mixed; boundary="------------040005070906010801040507"
X-Brightmail-Tracker: AAAAAA==
Subject: [AVTCORE] Fwd: [dispatch] Media Stream Related Signaling
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: DISPATCH list 
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Mar 2012 15:45:05 -0000

--------------040005070906010801040507
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

AVTCORE WG,
(As Individual)

A reminder to you that this discussion will happen in Paris in the
Dispatch WG session, currently scheduled for Tuesday (27th of March) at
1300-1500.

If you already now have input in the discussion please send email to the
Dispatch WG mailing list.

Cheers

Magnus

--------------040005070906010801040507
Content-Type: message/rfc822;
	name="[dispatch] Media Stream Related Signaling.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="[dispatch] Media Stream Related Signaling.eml"

X-Mozilla-Keys: 
Received: from sesbmg10.ericsson.net (153.88.115.8) by
 esessmw0197.eemea.ericsson.se (153.88.115.89) with Microsoft SMTP Server
 (TLS) id 8.3.213.0; Fri, 16 Mar 2012 16:32:40 +0100
Received: from mail.ietf.org (mail.ietf.org [12.22.58.30])	by
 sesbmg10.ericsson.net (Symantec Mail Security) with SMTP id
 A3.ED.03823.81D536F4; Fri, 16 Mar 2012 16:32:40 +0100 (CET)
Received: from ietfa.amsl.com (localhost [127.0.0.1])	by ietfa.amsl.com
 (Postfix) with ESMTP id B86EB21F8711;	Fri, 16 Mar 2012 08:32:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])	by ietfa.amsl.com (Postfix)
 with ESMTP id 4405C21F8709	for ; Fri, 16 Mar 2012
 08:32:35 -0700 (PDT)
Received: from mail.ietf.org ([12.22.58.30])	by localhost (ietfa.amsl.com
 [127.0.0.1]) (amavisd-new, port 10024)	with ESMTP id 5KcNVfIl1OhU for
 ;	Fri, 16 Mar 2012 08:32:34 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net
	[193.180.251.61])	by ietfa.amsl.com (Postfix) with ESMTP id 5F7C621F86D5	for
 ; Fri, 16 Mar 2012 08:32:34 -0700 (PDT)
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124])
	by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id
	C4.11.17856.11D536F4; Fri, 16 Mar 2012 16:32:33 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se
	(153.88.115.82) with Microsoft SMTP Server id 8.3.213.0;	Fri, 16 Mar 2012
 16:32:32 +0100
From: Magnus Westerlund 
To: DISPATCH list 
Sender: "dispatch-bounces@ietf.org" 
Date: Fri, 16 Mar 2012 16:32:32 +0100
Subject: [dispatch] Media Stream Related Signaling
Thread-Topic: [dispatch] Media Stream Related Signaling
Thread-Index: Ac0DigZOdrBIp9HVQ6m5uCDvQ8b40Q==
Message-ID: <4F635D10.3040607@ericsson.com>
References: <4F635AF9.9020605@ericsson.com>
List-Help: 
List-Subscribe: ,
	
List-Unsubscribe: ,
	
In-Reply-To: <4F635AF9.9020605@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-AuthSource: esessmw0197.eemea.ericsson.se
X-MS-Has-Attach: 
X-Auto-Response-Suppress: All
X-MS-TNEF-Correlator: 
x-auditid: c1b4fb3c-b7f126d000000eef-25-4f635d171dd7
x-brightmail-tracker: AAAAAA==
dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1;
	t=1331911958; bh=InyQ1CufGR9qkZDp9pnRK+DMwxIXvg5eclqpB6XDScQ=;
	h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:
	 Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:
	 List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender;
	b=h5Q1xvKpRAVpgVLge5pdbt5xmqCZRVoNRo2Xb0EiC5eP9mkkMxWhR3CtMzttMTGvK
	 sh5FxZy/w+QEJAKSpfpH2uz8GzKe61DEGI3cdXyCOIcA1j0iN9V1qUVXrMscJAmk85
	 fBjrbqCZd0ypCAlFdW11JrpvEg2dQiABoc+rxvfk=
user-agent: Mozilla/5.0 (Windows NT 6.1;	rv:10.0.2) Gecko/20120216
 Thunderbird/10.0.2
errors-to: dispatch-bounces@ietf.org
x-virus-scanned: amavisd-new at amsl.com
x-mailman-version: 2.1.12
list-post: 
list-archive: 
list-id: DISPATCH Working Group Mail List 
x-beenthere: dispatch@ietf.org
x-spam-level: 
x-spam-status: No, score=-110.368 tagged_above=-999 required=5
	tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8,
	USER_IN_WHITELIST=-100]
x-spam-score: -110.368
x-spam-flag: NO
delivered-to: dispatch@ietfa.amsl.com
x-original-to: dispatch@ietfa.amsl.com
x-enigmail-version: 1.4
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Dispatch,

With 10 days until the meeting I would like to provide a reminder on the
upcoming discussion and some clarification on what we believe to be the
high level question that Dispatch needs to resolve for us to be able to
make progress.

First of all we have not updated our drafts. They are still relevant
background material for this discussion:

Media Stream Selection:
https://datatracker.ietf.org/doc/draft-westerlund-dispatch-stream-selection=
/

Pause and Resume:
https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtp-stream-pause/

The above drafts propose the need for two functionalities:

Choose What Content to Receive - A media receiver wants to dynamically
choose which media stream to receive, out of many possible, from a
certain media sender, out of many possible

Request to Pause Sending of a Content - A media receiver wants to ask
the media sender to temporarily stop sending a specific media stream,
and to resume it with short notice

>From our perspective there exist three different high level methods for
realizing this functionality:

- Using a media control protocol, like BFCP or Media Control Framework
- Using the media plane, like RTCP
- Using the signaling plane, like SIP/SDP or other SIP carried data

What we want out of the Dispatch session is clear indications on what
are the most suitable method or methods (as we have two different
functionalities) that should be worked out. That indication can then
hopefully be turned into a decision pretty quickly to take the work to
one or more WG. We want to be able to continue working on this and
making progress.

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


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


--------------040005070906010801040507--

From magnus.westerlund@ericsson.com  Fri Mar 16 08:57:54 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACA221F8685 for ; Fri, 16 Mar 2012 08:57:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.383
X-Spam-Level: 
X-Spam-Status: No, score=-110.383 tagged_above=-999 required=5 tests=[AWL=0.216, 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 RrUygNJOVVMZ for ; Fri, 16 Mar 2012 08:57:54 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9D68921F85D8 for ; Fri, 16 Mar 2012 08:57:53 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c6fae0000045c0-05-4f6363008f11
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 91.64.17856.003636F4; Fri, 16 Mar 2012 16:57:52 +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.213.0; Fri, 16 Mar 2012 16:57:52 +0100
Message-ID: <4F6362FF.20501@ericsson.com>
Date: Fri, 16 Mar 2012 16:57:51 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: IETF AVTCore WG 
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Subject: [AVTCORE] Regarding the discussion of single transport flow with one or more RTP session
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Mar 2012 15:57:54 -0000

WG,
(As Individual)

In Paris we will once more have some discussion around what work to do
when it comes to using a single transport flow for one or more RTP
sessions and where an RTP sessions could contain multiple media types.

There are a lot of details to consider in this discussion. I therefore
would strongly encourage anyone who intended to participate in this
discussion to actual prepare and review the available material. I think
the following drafts are all relevant to this discussion and should be
considered:

https://datatracker.ietf.org/doc/draft-westerlund-avtcore-multiplex-architecture/

https://datatracker.ietf.org/doc/draft-westerlund-avtcore-transport-multiplexing/

https://datatracker.ietf.org/doc/draft-alvestrand-rtp-sess-neutral/

https://datatracker.ietf.org/doc/draft-lennox-rtcweb-rtp-media-type-mux/

After quite some consideration I personally will argue for working on
both single RTP session with multiple media types and a mechanism for
multiplexing multiple RTP sessions over a single transport.

The main reasons is that I believe that multiple media types in one RTP
session will be used by some for which the limitations documented in
Section 6.7 of draft-westerlund-avtcore-multiplex-architecture is not an
issue. And unless we document these limitations more than one RTP
application implementor may become very unhappy when they realize them.
So I rather ensure that they are written up. If we are not developing a
mechanism that allows multiple RTP sessions over a single lower layer
transport the WG is blocking the usage of a tool in the RTP toolbox that
we ourself in the past quite frequently have used to accomplish
extensions or functions when it is desirable to have only one transport
flow. That appears short sighted and also provides an implicit
recommendations for multiple media types in a single RTP session despite
its limitations.

Hoping for a fruitful discussion in Paris

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 ron.even.tlv@gmail.com  Sat Mar 17 02:11:31 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6017121F8652 for ; Sat, 17 Mar 2012 02:11:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.029
X-Spam-Level: 
X-Spam-Status: No, score=-3.029 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, J_CHICKENPOX_16=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 l5CaoKmWTScs for ; Sat, 17 Mar 2012 02:11:30 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1A221F8646 for ; Sat, 17 Mar 2012 02:11:07 -0700 (PDT)
Received: by wibhj6 with SMTP id hj6so1445225wib.13 for ; Sat, 17 Mar 2012 02:11:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=k3S2AZcqgCwH1tjUIWQPPgTzUgqHxpW/xRg+2WzE2Z0=; b=lWmNmCYNnQ92UVJa2M1EkDPpLBNYOhGw7tGNv7PEjwkqlXdkxy4IdcrDUTylaWkqal btV7Gnqwe4oHJDXxexC40RdmvPKJEoXf7eHg6mqyw+yBY3A+faJmNDFnWwPmnwaMcvEu hG08pyhhcmJE+y+sSohWAyscs15YQWrvlVpgDvhKq9xhxounwK6QylJC9VgF3UaouTim PbqgACaYUzNuqbX22eeSiAr1KWooEgKAS4LgGdv/M+M4bOOni5mU8UJqVMi/Fd8mpwgh tOcwMvX+CTLYxOBV/iKA+nP8z0XT9jiadatPSAPgR8Ovl4z5jjOG6OjIIvRhwDyMr4pU p6vg==
Received: by 10.180.78.233 with SMTP id e9mr5103927wix.0.1331975466795; Sat, 17 Mar 2012 02:11:06 -0700 (PDT)
Received: from windows8d787f9 (bzq-79-179-219-130.red.bezeqint.net. [79.179.219.130]) by mx.google.com with ESMTPS id fl2sm9789551wib.4.2012.03.17.02.11.04 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 17 Mar 2012 02:11:05 -0700 (PDT)
From: "Roni Even" 
To: "'Magnus Westerlund'" 
References: <4f62249b.8a0eb40a.628f.6e47@mx.google.com> <4F62EE9F.8080204@ericsson.com> <4f634347.2614b40a.036d.fffff329@mx.google.com> <4F635700.8050505@ericsson.com>
In-Reply-To: <4F635700.8050505@ericsson.com>
Date: Sat, 17 Mar 2012 11:10:06 +0200
Message-ID: <4f645529.2266b40a.193a.fffff25e@mx.google.com>
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: Ac0DhmUVMz8kwP7vQmKnctJhrnkAxQAlIh2Q
Content-Language: en-us
Cc: 'IETF AVTCore WG' 
Subject: Re: [AVTCORE] draft-westerlund-avtcore-multiplex-architecture-01 - same SSRC for SVC
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Mar 2012 09:11:31 -0000

Hi,
I will just address the SVC multiplexing issue and start a different =
thread
on the session and ssrc multiplexing and the relation between RTP =
session
and the transport infrastructure used which is also discussed in
draft-alvestrand-rtp-sess-neutral-00.

As for the SVC example in the document, I think that the reason for MST =
mode
is because the idea is to use the session multiplexing based on =
different
UDP ports to divide the streams, for example in multicast allowing the =
users
to join just the relevant multicast groups. IF you want SSRC =
multiplexing in
SVC you can use SST (Single Session Transmission) mode and I think this =
is
the reason there is no need to address SSRC multiplexing using multiple
sessions to a single UDP receive port is not discussed.

What I am saying is that the example in 3.2 is not correct since it was =
not
addressed on purpose being non relevant use for MST.
Roni Even

> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> Sent: Friday, March 16, 2012 5:07 PM
> To: Roni Even
> Cc: 'IETF AVTCore WG'
> Subject: Re: [AVTCORE] =
draft-westerlund-avtcore-multiplex-architecture-
> 01 - same SSRC
>=20
> On 2012-03-16 14:41, Roni Even wrote:
> > Hi Magnus,
> > I thought that RFC5583 is used to signal the media decoding
> dependency
> > between the different sessions as mentioned in section 7.2.3 of RFC
> 6190.
> > I also think that this allows you to provide also the SSRC value of
> > the different RTP streams.
>=20
> No, to my understanding RFC 5583 only defines how the media =
description
> grouping to indicate which m=3D lines that contains dependent media. =
And
> the a=3Ddepend SDP attribute links which RTP payload types in the
> respective media descriptions. There is no linking of the SSRCs. So
> when there is more than one SSRC with a given CNAME you have no other
> defined method than to use the same SSRC value across sessions.
>=20
> Cheers
>=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
> ----------------------------------------------------------------------


From ron.even.tlv@gmail.com  Sun Mar 18 09:34:59 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB5A21F8692; Sun, 18 Mar 2012 09:34:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.445
X-Spam-Level: 
X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=-0.609, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, 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 zntuRD14Lhu4; Sun, 18 Mar 2012 09:34:58 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E00F321F8691; Sun, 18 Mar 2012 09:34:57 -0700 (PDT)
Received: by werb10 with SMTP id b10so6451507wer.31 for ; Sun, 18 Mar 2012 09:34:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=81D9B9PeMZ2cnywBaACdBByRNS3yaS97Y//+cQcDBBs=; b=D65PbNn7VBxZv8LIVM5J/oAVPJTUjCEwF5Iej/VSCKQyoTT352zS/SpPnrPjiIaDTi ilJARBWQvr3D0nbq5lc7NEipZv2qnAQ95gM7ALLBs17L/rqQp+ygrchsRnS2oXTPP7FO 94CNRya/tfy08OlYumR3+2NUYwLtvNJ9Ai8x7kHH7ZHZS3YFdW3lBzHyRADpH2X+DFWO pahoWgr1utPU6EN1h/u6caa45EtVu6Rx/CSNrxCrXlxdhc3LeDNfL/vxLXQs/IyUUmSO rzzpI2gezUysYPulZQWWfSsPbAsnISP13TWqCjwSCL22WE4ssGy2vjZEm91VXqld0cbA 0KoQ==
Received: by 10.180.19.37 with SMTP id b5mr13396043wie.9.1332088497093; Sun, 18 Mar 2012 09:34:57 -0700 (PDT)
Received: from windows8d787f9 (bzq-79-179-219-130.red.bezeqint.net. [79.179.219.130]) by mx.google.com with ESMTPS id gg2sm28987438wib.7.2012.03.18.09.34.53 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 18 Mar 2012 09:34:54 -0700 (PDT)
From: "Roni Even" 
To: "'IETF AVTCore WG'" , 
Date: Sun, 18 Mar 2012 18:33:53 +0200
Message-ID: <4f660eae.c268b40a.715b.144d@mx.google.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0032_01CD0535.AD9DADD0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac0FJOf8d1X5yg9QTUyRIpxgxIHRlQ==
Content-Language: en-us
Cc: 'Magnus Westerlund' 
Subject: [AVTCORE] (no subject)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Mar 2012 16:34:59 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0032_01CD0535.AD9DADD0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,
 
The document write-up template for sending documents to publication has
changed.  In particular, we need to poll authors on their compliance with
IETF IPR rules prior to moving a document to the publication in the WG
process. See http://www.ietf.org/iesg/template/doc-writeup.html question 7.
 
We plan to send the following email when a WG document goes to WG last call.
 
 
 
Please let us know if you have any comments on this plan.
 
Roni Even
AVTCore and Payload co-chair
 
-----------------------------------------------------------------
 
To: 
Cc: AD; AVTcore/Payload WG
 
Subject: Regarding IPR on 
 
Are you aware of any IPR that applies to ? If so,
has this IPR been disclosed in compliance with IETF IPR rules (see RFCs
3979, 4879, 3669 and 5378 for more details)?
 
If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR.  This document will not advance to the next
stage until a response has been received from each author and listed
contributor.
 
If you are on the AVTcore/payload WG email list but are not listed as an
author or contributor, we remind you of your obligations under the IETF IPR
rules which encourages you to notify the IETF if you are aware of IPR of
others on an IETF contribution, or to refrain from participating in any
contribution or discussion related to your undisclosed IPR.  For more
information, please see the RFCs listed above and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
 

 


------=_NextPart_000_0032_01CD0535.AD9DADD0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi,
 
The document write-up template for sending documents to =
publication has changed.  In particular, we need to poll authors on =
their compliance with IETF IPR rules prior to moving a document to the =
publication in the WG process. See http://www.ie=
tf.org/iesg/template/doc-writeup.html question =
7.
 
We plan to send the =
following email when a WG document goes to WG last =
call.
 
 <=
/pre>
 
Please let us know if you have any =
comments on this =
plan.
 
Roni =
Even
AVTCore and Payload =
co-chair
 
---------------=
--------------------------------------------------
<=
o:p> 
To: <list all authors and =
contributors>
Cc: AD; AVTcore/Payload =
WG
 
Subject: Regarding =
IPR on <insert document =
name>
 
Are you aware =
of any IPR that applies to <insert document name>? If =
so,
has this IPR been disclosed in compliance with =
IETF IPR rules (see RFCs
3979, 4879, 3669 and 5378 =
for more details)?
 
If =
you are listed as a document author or contributor please answer =
the
above by responding to this email regardless of =
whether or not you are
aware of any relevant =
IPR.  This document will not advance to the =
next
stage until a response has been received from =
each author and =
listed
contributor.
 =

If you are on the AVTcore/payload WG email list but are =
not listed as an author or contributor, we remind you of your =
obligations under the IETF IPR rules which encourages you to notify the =
IETF if you are aware of IPR of others on an IETF contribution, or to =
refrain from participating in any contribution or discussion related to =
your undisclosed IPR.  For more information, please see the RFCs =
listed above and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty=
.
 
 

------=_NextPart_000_0032_01CD0535.AD9DADD0--


From stewe@stewe.org  Sun Mar 18 10:03:22 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487C021F8674; Sun, 18 Mar 2012 10:03:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.765
X-Spam-Level: 
X-Spam-Status: No, score=-3.765 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 tJniC3satWZH; Sun, 18 Mar 2012 10:03:21 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2E321F865E; Sun, 18 Mar 2012 10:03:21 -0700 (PDT)
Received: from mail197-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Sun, 18 Mar 2012 17:03:17 +0000
Received: from mail197-va3 (localhost [127.0.0.1])	by mail197-va3-R.bigfish.com (Postfix) with ESMTP id 872FB3A0373; Sun, 18 Mar 2012 17:03:16 +0000 (UTC)
X-SpamScore: -14
X-BigFish: PS-14(zzc85fhzz1202h1082kzz1033IL8275bh8275dhz2fh2a8h668h839hbe3k)
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
Received-SPF: pass (mail197-va3: 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 mail197-va3 (localhost.localdomain [127.0.0.1]) by mail197-va3 (MessageSwitch) id 1332090193489214_8926; Sun, 18 Mar 2012 17:03:13 +0000 (UTC)
Received: from VA3EHSMHS026.bigfish.com (unknown [10.7.14.254])	by mail197-va3.bigfish.com (Postfix) with ESMTP id 70E01C0065; Sun, 18 Mar 2012 17:03:13 +0000 (UTC)
Received: from BL2PRD0710HT005.namprd07.prod.outlook.com (157.56.240.133) by VA3EHSMHS026.bigfish.com (10.7.99.36) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 18 Mar 2012 17:03:13 +0000
Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.131]) by BL2PRD0710HT005.namprd07.prod.outlook.com ([10.255.102.40]) with mapi id 14.16.0123.000; Sun, 18 Mar 2012 17:03:09 +0000
From: Stephan Wenger 
To: Roni Even , 'IETF AVTCore WG' , "payload@ietf.org" 
Thread-Topic: [AVTCORE] (no subject)
Thread-Index: Ac0FJOf8d1X5yg9QTUyRIpxgxIHRlQADHcSA
Date: Sun, 18 Mar 2012 17:03:09 +0000
Message-ID: 
In-Reply-To: <4f660eae.c268b40a.715b.144d@mx.google.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_CB8BD29E848D4stewesteweorg_"
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Cc: 'Magnus Westerlund' 
Subject: Re: [AVTCORE] (no subject)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Mar 2012 17:03:22 -0000

--_000_CB8BD29E848D4stewesteweorg_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
There are many cases, where the answer to the first question is Yes, the an=
swer to the second question is No, and people would still be in compliance =
with the assorted policy RFCs.  The reason is that disclosure is not requir=
ed in many cases; for example, when the IPR in question is not owned by the=
m or their employers.

Suggest that the second question should be something like:
"

If so,

has this IPR been disclosed when so required for in compliance with IETF IP=
R rules (see RFCs

3979, 4879, 3669 and 5378 for more details)?

"

Stephan

From: Roni Even >
Date: Sun, 18 Mar 2012 18:33:53 +0200
To: 'IETF AVTCore WG' >, >
Cc: 'Magnus Westerlund' >
Subject: [AVTCORE] (no subject)


Hi,



The document write-up template for sending documents to publication has cha=
nged.  In particular, we need to poll authors on their compliance with IETF=
 IPR rules prior to moving a document to the publication in the WG process.=
 See http://www.ietf.org/iesg/template/doc-writeup.html question 7.



We plan to send the following email when a WG document goes to WG last call=
.







Please let us know if you have any comments on this plan.



Roni Even

AVTCore and Payload co-chair



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



To: 

Cc: AD; AVTcore/Payload WG



Subject: Regarding IPR on 



Are you aware of any IPR that applies to ? If so,

has this IPR been disclosed in compliance with IETF IPR rules (see RFCs

3979, 4879, 3669 and 5378 for more details)?



If you are listed as a document author or contributor please answer the

above by responding to this email regardless of whether or not you are

aware of any relevant IPR.  This document will not advance to the next

stage until a response has been received from each author and listed

contributor.



If you are on the AVTcore/payload WG email list but are not listed as an au=
thor or contributor, we remind you of your obligations under the IETF IPR r=
ules which encourages you to notify the IETF if you are aware of IPR of oth=
ers on an IETF contribution, or to refrain from participating in any contri=
bution or discussion related to your undisclosed IPR.  For more information=
, please see the RFCs listed above and

http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.



_______________________________________________ Audio/Video Transport Core =
Maintenance avt@ietf.org https://www.ietf.org/mailman/=
listinfo/avt

--_000_CB8BD29E848D4stewesteweorg_
Content-Type: text/html; charset="us-ascii"
Content-ID: <85DBCABF6445EF43BBDE035D934DC527@namprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable







Hi,


There are many cases, where the answer to the first question is Yes, t=
he answer to the second question is No, and people would still be in compli=
ance with the assorted policy RFCs.  The reason is that disclosure is =
not required in many cases; for example,
 when the IPR in question is not owned by them or their employers.  






Suggest that the second question should be something like:


"




If so,
has this IPR been disclosed when so re=
quired for in compliance with IETF IPR rules (see RFCs=

3979, 4879, 3669 and 5378 for more details)?




"







Stephan









From: Roni Even <ron.even.tlv@gmail.com>

Date: Sun, 18 Mar 2012 18:33:53 =
3;0200

To: 'IETF AVTCore WG' <avt@ietf.org>, <payload@ietf.org>

Cc: 'Magnus Westerlund' <magnus.westerlund@ericsson.com>

Subject: [AVTCORE] (no subject)

















Hi,


 


The document write-up template for sending documents to publication ha=
s changed.  In particular, we need to poll authors on their compliance=
 with IETF IPR rules prior to moving a document to the publication in the W=
G process. See http://www.ietf.org/iesg/template/doc-writeup.html question 7.<=
/o:p>


 


We plan to send the following email when a WG document goes to WG last=
 call.


 


 


 


Please let us know if you have any comments on this plan.

 


Roni Even


AVTCore and Payload co-chair


 


-----------------------------------------------------------------=



 


To: <list all authors and contributors>


Cc: AD; AVTcore/Payload WG


 


Subject: Regarding IPR on <insert document name>

 


Are you aware of any IPR that applies to <insert document name>?=
 If so,


has this IPR been disclosed in compliance with IETF IPR rules (see RFC=
s


3979, 4879, 3669 and 5378 for more details)?


 


If you are listed as a document author or contributor please answer th=
e


above by responding to this email regardless of whether or not you are=



aware of any relevant IPR.  This document will not advance to the=
 next


stage until a response has been received from each author and listed


contributor.


 


If you are on the AVTcore/payload WG email list but are not listed as =
an author or contributor, we remind you of your obligations under the IETF =
IPR rules which encourages you to notify the IETF if you are aware of IPR o=
f others on an IETF contribution, or to refrain from participating in any c=
ontribution or discussion related to your undisclosed IPR.  For more i=
nformation, please see the RFCs listed above and


http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProp=
erty.


 


 







_______________________________________________ Audio/Video Transport Core =
Maintenance
avt@ietf.org 
https://www.ietf.org/mailman/listinfo/avt 



--_000_CB8BD29E848D4stewesteweorg_--

From ron.even.tlv@gmail.com  Sun Mar 18 15:53:50 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4D321F8498; Sun, 18 Mar 2012 15:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.279
X-Spam-Level: 
X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[AWL=0.319,  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 7zSUHdVHslwy; Sun, 18 Mar 2012 15:53:49 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id C114A21F849B; Sun, 18 Mar 2012 15:53:48 -0700 (PDT)
Received: by wibhq7 with SMTP id hq7so2456301wib.13 for ; Sun, 18 Mar 2012 15:53:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=7qbs8yQBpHnxKYL4f3V95kAPlIr2RO16u2ldcQbOD1U=; b=Ttq0qV312GpyEjeFKwoDRFlnPT1aSqFnIOr4YctwwNUSIbF3Q6TlSVHGytGtk4GSH8 02Tjqq+o0dpZr5S29RMqnp/k5gPFhNrr4oJ91hepoyeMVwPqD5AkxVjUZa1ltR0+CFgy VCSv9LSO3vNopJNtRhfVg10CvwbyIQ66NOLYA/y9UpMTDCpCbdf7k/BKY9Sski6xx3sy 4gqQbFUbQ6p4bNQQHCar9vU0aG0GaJXkfR1z3+AC1VZwCVR19h8bJW9qjc2N1si5+x2Z l4VcTFS0AcWhu/X54i51o+mULBn27p5ClVcyyFe2GjIrpAIodOufCvZgHpDMiC4TOEU1 GtVQ==
Received: by 10.180.78.225 with SMTP id e1mr14916732wix.0.1332111227870; Sun, 18 Mar 2012 15:53:47 -0700 (PDT)
Received: from windows8d787f9 (bzq-79-179-219-130.red.bezeqint.net. [79.179.219.130]) by mx.google.com with ESMTPS id ff2sm33011850wib.9.2012.03.18.15.53.45 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 18 Mar 2012 15:53:47 -0700 (PDT)
From: "Roni Even" 
To: "'Stephan Wenger'" , "'IETF AVTCore WG'" , 
References: <4f660eae.c268b40a.715b.144d@mx.google.com> 
In-Reply-To: 
Date: Mon, 19 Mar 2012 00:52:45 +0200
Message-ID: <4f66677b.6265b40a.5afc.ffff8f1b@mx.google.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0046_01CD056A.9ADE8900"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac0FJOf8d1X5yg9QTUyRIpxgxIHRlQADHcSAAAn/RCA=
Content-Language: en-us
Cc: 'Magnus Westerlund' 
Subject: Re: [AVTCORE] IPR requirements in document write-up
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Mar 2012 22:53:50 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0046_01CD056A.9ADE8900
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Stephan,

Thanks for the text, I will use it.

Roni

 

From: Stephan Wenger [mailto:stewe@stewe.org] 
Sent: Sunday, March 18, 2012 7:03 PM
To: Roni Even; 'IETF AVTCore WG'; payload@ietf.org
Cc: 'Magnus Westerlund'
Subject: Re: [AVTCORE] (no subject)

 

Hi,

There are many cases, where the answer to the first question is Yes, the
answer to the second question is No, and people would still be in compliance
with the assorted policy RFCs.  The reason is that disclosure is not
required in many cases; for example, when the IPR in question is not owned
by them or their employers.  

 

Suggest that the second question should be something like:

"

If so,
has this IPR been disclosed when so required for in compliance with IETF IPR
rules (see RFCs
3979, 4879, 3669 and 5378 for more details)?

"

 

Stephan

 

From: Roni Even 
Date: Sun, 18 Mar 2012 18:33:53 +0200
To: 'IETF AVTCore WG' , 
Cc: 'Magnus Westerlund' 
Subject: [AVTCORE] (no subject)

 

Hi,
 
The document write-up template for sending documents to publication has
changed.  In particular, we need to poll authors on their compliance with
IETF IPR rules prior to moving a document to the publication in the WG
process. See http://www.ietf.org/iesg/template/doc-writeup.html question 7.
 
We plan to send the following email when a WG document goes to WG last call.
 
 
 
Please let us know if you have any comments on this plan.
 
Roni Even
AVTCore and Payload co-chair
 
-----------------------------------------------------------------
 
To: 
Cc: AD; AVTcore/Payload WG
 
Subject: Regarding IPR on 
 
Are you aware of any IPR that applies to ? If so,
has this IPR been disclosed in compliance with IETF IPR rules (see RFCs
3979, 4879, 3669 and 5378 for more details)?
 
If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR.  This document will not advance to the next
stage until a response has been received from each author and listed
contributor.
 
If you are on the AVTcore/payload WG email list but are not listed as an
author or contributor, we remind you of your obligations under the IETF IPR
rules which encourages you to notify the IETF if you are aware of IPR of
others on an IETF contribution, or to refrain from participating in any
contribution or discussion related to your undisclosed IPR.  For more
information, please see the RFCs listed above and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
 

 

_______________________________________________ Audio/Video Transport Core
Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt 


------=_NextPart_000_0046_01CD056A.9ADE8900
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi Stephan,
Thanks for the text, I =
will use it.
Roni
 
From:=
 =
Stephan Wenger [mailto:stewe@stewe.org] 
Sent: Sunday, March =
18, 2012 7:03 PM
To: Roni Even; 'IETF AVTCore WG'; =
payload@ietf.org
Cc: 'Magnus Westerlund'
Subject: =
Re: [AVTCORE] (no subject)
 
Hi,
There are many cases, where the =
answer to the first question is Yes, the answer to the second question =
is No, and people would still be in compliance with the assorted policy =
RFCs.  The reason is that disclosure is not required in many cases; =
for example, when the IPR in question is not owned by them or their =
employers.  
 
=

Suggest that the second question =
should be something like:
"
=

If =
so,
has this IPR =
been disclosed when so required for in compliance with =
IETF IPR rules (see RFCs
3979, 4879, 3669 and 5378 for more =
details)?
"
=

 
=

Stephan
 
=

From: =
Roni Even <ron.even.tlv@gmail.com>
=
Date: Sun, 18 Mar 2012 18:33:53 +0200
To: 'IETF AVTCore =
WG' <avt@ietf.org>, <payload@ietf.org>
Cc: =
'Magnus Westerlund' <magnus.westerlund@ericsson=
.com>
Subject: [AVTCORE] (no =
subject)
 
=

Hi,
 
The document write-up template for sending =
documents to publication has changed.  In particular, we need to =
poll authors on their compliance with IETF IPR rules prior to moving a =
document to the publication in the WG process. See http://www.ie=
tf.org/iesg/template/doc-writeup.html question =
7.
 
We plan to send the following email when a WG =
document goes to WG last call.
 
 
 
Please let us know if you have any comments on =
this plan.
 
Roni Even
AVTCore and Payload =
co-chair
 
---------------------------------------------------=
--------------
 
To: <list all authors and =
contributors>
Cc: AD; AVTcore/Payload =
WG
 
Subject: Regarding IPR on <insert document =
name>
 
Are you aware of any IPR that applies to =
<insert document name>? If so,
has this IPR been disclosed in compliance with =
IETF IPR rules (see RFCs
3979, 4879, 3669 and 5378 for more =
details)?
 
If you are listed as a document author or =
contributor please answer the
above by responding to this email regardless of =
whether or not you are
aware of any relevant IPR.  This document =
will not advance to the next
stage until a response has been received from each =
author and listed
contributor.
 
If you are on the AVTcore/payload WG email list =
but are not listed as an author or contributor, we remind you of your =
obligations under the IETF IPR rules which encourages you to notify the =
IETF if you are aware of IPR of others on an IETF contribution, or to =
refrain from participating in any contribution or discussion related to =
your undisclosed IPR.  For more information, please see the RFCs =
listed above and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty=
.
 
 
__________________________________=
_____________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/m=
ailman/listinfo/avt 

------=_NextPart_000_0046_01CD056A.9ADE8900--


From tom.van_caenegem@alcatel-lucent.com  Mon Mar 19 07:08:16 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D8B21F86A1 for ; Mon, 19 Mar 2012 07:08:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.241
X-Spam-Level: 
X-Spam-Status: No, score=-9.241 tagged_above=-999 required=5 tests=[AWL=1.008,  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 zRq4W4LyAYzY for ; Mon, 19 Mar 2012 07:08:15 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFA921F849B for ; Mon, 19 Mar 2012 07:08:15 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2JE0g1b019719 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 19 Mar 2012 15:07:46 +0100
Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.40]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 19 Mar 2012 15:07:39 +0100
From: "Van Caenegem, Tom (Tom)" 
To: Qin Wu , IETF AVTCore WG 
Date: Mon, 19 Mar 2012 15:07:38 +0100
Thread-Topic: [AVTCORE] Regarding draft-ietf-avtcore-feedback-supression-rtp-15
Thread-Index: Ac0DT8iCjwu/6QFCS5y5EMDoz64k7QChpZSw
Message-ID: 
References: <4F5B2F09.2090704@ericsson.com>  <10EE199408404E20922B52A3D8B367CD@china.huawei.com>  <0FDFA5AD37E04C878E9027BE8DE0E860@china.huawei.com>
In-Reply-To: <0FDFA5AD37E04C878E9027BE8DE0E860@china.huawei.com>
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: nl-NL, en-US
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.83
Subject: Re: [AVTCORE] Regarding	draft-ietf-avtcore-feedback-supression-rtp-15
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Mar 2012 14:08:16 -0000

Qin,

I scanned through the security section, and my proposal would be to make it=
 more compact. The whole section could be written as per below. Let me know=
 what you think and whether I missed some important statements in the curre=
nt "security" section.

Regards
Tom


Proposal:


"The security considerations documented in RFC 4585 are also applicable for=
 the TPLR messages defined in this document.

More specifically, spoofed or maliciously created TPLR feedback messages gi=
ve rise to (undesired) feedback supression at RTCP receivers that accept su=
ch TPLR messages. Any packet loss detected by a receiver and where this RTP=
 receiver also receives a TPLR message for the same missing packet(s), will=
 negatively impact the application that relies on the (timely) RTP retransm=
ission capabilities.=20

A solution to prevent such attack with maliciously sent TPLR messages, is t=
o apply an authentication and integrity protection framework for the feedba=
ck messages.  This can be accomplished using the RTP profile that combines =
Secure RTP [RFC3711] and AVPF into SAVPF [RFC5124].

Note that intermediaries that are not visible at the RTP layer that
   wish to send the Third Party Loss Reports on behalf of the media
   source can only do so if they spoof the SSRC of the media source.
   This is difficult in case SRTP is in use.  If the intermediary is
   visible at the RTP layer, this is not an issue, provided the
   intermediary is part of the security context for the session."




-----Original Message-----
From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Qin W=
u
Sent: vrijdag 16 maart 2012 8:44
To: IETF AVTCore WG
Subject: Re: [AVTCORE] Regarding draft-ietf-avtcore-feedback-supression-rtp=
-15

[sorry, if you receive multiple copies of this message]

Hi, Tom:
Sorry for late. Statement 3 is just an advice.
I agree unauthenticated feedback is not equivalent to suspicious feedback. =
RFC4585 allow ignore suspicious feedback but does not say we MUST ignore an=
y unauthenticated feedback.
Your proposal looks good to me. How about revise the last paragraph, sectio=
n 7 as:
"
   Also note that endpoints that receive a Third Party Loss Report would
   be well-advised to minimize the risk of false TPLR messages from
   a malicious source (which results in unneeded suppression feedback
   at the target victim receiver(s). Suggested measure is to authenticate=20
   the sender of the Third Party Loss Report. Accepting Third Party Loss Re=
port=20
   from un-authenticated sender can lead to a denial of service attack, whe=
re=20
   the endpoint accepts poor quality media that could be repaired.
"
Hope this addresses your comment.

Regards!
-Qin

>----- Original Message -----
>From: "Van Caenegem, Tom (Tom)" 
>To: "Qin Wu" ; "Magnus Westerlund"=20
>; "IETF AVTCore WG" 
>Sent: Tuesday, March 13, 2012 9:59 PM
>Subject: RE: [AVTCORE] Regarding=20
>draft-ietf-avtcore-feedback-supression-rtp-15


>Hi Qin,

>The issue on statement 2 : OK

>IMO your statement 3 ("Also note that endpoints that receive a Third=20
>Party Loss Report would be well-advised to ignore it, unless the security =
is in place to authenticate the sender of the Third Party Loss Report") is =
an advice (/requirement?) that goes well beyond the recommendations in the =
security >section 8 of RFC 4585.

>The latter indicates that senders/receivers should behave conservatively w=
hen observing strange reporting behaviour.=20

>The section also states that false RTCP packets can be avoided by authenti=
cating RTCP messages. =20

>(see below the exact phrasing that I copied for your convenience)

>In line with these RFC 4585 recommendation, you seem to interprete "unauth=
enticated" RTCP messages as an example of "strange" reporting behavior, whi=
ch I do not think was the intention from RFC >4585.

>My proposal would be to just indicate in your security section that a solu=
tion to minimise the risk on false TPLR messages from a malicious source (w=
hich results in unneeded suppression feedback at the >target victim receive=
r(s), is to make use of an authentication framework (in line with RFC 4585)=
.=20

>Regards
>Tom


>RFC 4585, section 8 (Security):

>(..)

>Senders as well as receivers SHOULD behave conservatively when
>   observing strange reporting behavior.  For excessive failure
>   reporting from one or a few receivers, the sender MAY decide to no
>   longer consider this feedback when adapting its transmission behavior
>   for the media stream.  In any case, senders and receivers SHOULD
>   still adhere to the maximum RTCP bandwidth but make sure that they
>   are capable of transmitting at least regularly scheduled RTCP
>   packets.  Senders SHOULD carefully consider how to adjust their
>   transmission bandwidth when encountering strange reporting behavior;
>   they MUST NOT increase their transmission bandwidth even if ignoring
>   suspicious feedback.

>   Attacks using false RTCP packets (Regular as well as Early ones) can
>   be avoided by authenticating all RTCP messages.  This can be achieved
>   by using the AVPF profile together with the Secure RTP profile as
>   defined in [22]; as a prerequisite, an appropriate combination of
>   those two profiles (an "SAVPF") is being specified [21].  Note that,
>   when employing group authentication (as opposed to source
>   authentication), the aforementioned attacks may be carried out by
>   malicious or malfunctioning group members in possession of the right
>   keying material.
_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt

From magnus.westerlund@ericsson.com  Mon Mar 19 15:03:54 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3FD21E8012 for ; Mon, 19 Mar 2012 15:03:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.386
X-Spam-Level: 
X-Spam-Status: No, score=-110.386 tagged_above=-999 required=5 tests=[AWL=0.213, 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 yz6wMEwbNBo9 for ; Mon, 19 Mar 2012 15:03:53 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 293C021F8535 for ; Mon, 19 Mar 2012 15:03:52 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c6fae0000045c0-4f-4f67ad470b71
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 56.88.17856.74DA76F4; Mon, 19 Mar 2012 23:03:52 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Mon, 19 Mar 2012 23:03:51 +0100
Message-ID: <4F67AD46.1010404@ericsson.com>
Date: Mon, 19 Mar 2012 23:03:50 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Roni Even 
References: <4f62249b.8a0eb40a.628f.6e47@mx.google.com> <4F62EE9F.8080204@ericsson.com> <4f634347.2614b40a.036d.fffff329@mx.google.com> <4F635700.8050505@ericsson.com> <4f645529.2266b40a.193a.fffff25e@mx.google.com>
In-Reply-To: <4f645529.2266b40a.193a.fffff25e@mx.google.com>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: 'IETF AVTCore WG' 
Subject: Re: [AVTCORE] draft-westerlund-avtcore-multiplex-architecture-01 - same SSRC for SVC
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Mar 2012 22:03:54 -0000

On 2012-03-17 10:10, Roni Even wrote:
> Hi,
> I will just address the SVC multiplexing issue and start a different thread
> on the session and ssrc multiplexing and the relation between RTP session
> and the transport infrastructure used which is also discussed in
> draft-alvestrand-rtp-sess-neutral-00.
> 
> As for the SVC example in the document, I think that the reason for MST mode
> is because the idea is to use the session multiplexing based on different
> UDP ports to divide the streams, for example in multicast allowing the users
> to join just the relevant multicast groups. IF you want SSRC multiplexing in
> SVC you can use SST (Single Session Transmission) mode and I think this is
> the reason there is no need to address SSRC multiplexing using multiple
> sessions to a single UDP receive port is not discussed.

Yes, I agree that MST exist so that sets of scalability layers can be
distributed over multiple multicast groups so that each receivers can
join the appropriate number of multicast groups for them.

And the discussion in section 3.2 is in this context.

> 
> What I am saying is that the example in 3.2 is not correct since it was not
> addressed on purpose being non relevant use for MST.

Sorry,

I don't understand how you come to this conclusion. What section 3.2
says around SVC is:

      Inter-relation:  SSRC belonging to the same synchronization
         context (originating from the same end-point), within or
         between RTP Sessions, are indicated through use of identical
         SDES CNAME items in RTCP compound packets with those SSRC as
         originating source.  SDP signalling can provide explicit SSRC
         grouping [RFC5576].  When CNAME is inappropriate or
         insufficient, there exist a few other methods to relate
         different SSRC.  One such case is session-based RTP
         retransmission [RFC4588].  In some cases, the same SSRC
         Identifier value is used to relate streams in two different RTP
         Sessions, such as in Multi-Session Transmission of scalable
         video [RFC6190].


What is says is that in MST there exist cases where CNAME clearly isn't
enough to make the binding between the SSRC in the different RTP session
on the differnet multicast groups. CNAME is not sufficient if multiple
video sources are sent from the same synchronization context.

Thus something additional mechanism is required. My claim is that RFC
6190 is relying on using the same SSRC value in the different RTP
Session being used to transmit the different scalability layers. However
this is not documented in the RFC.

Please don't mix SST into this case as it is not what we are talking about.

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 bill.wu@huawei.com  Mon Mar 19 19:16:40 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251B921E8059 for ; Mon, 19 Mar 2012 19:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.278
X-Spam-Level: *
X-Spam-Status: No, score=1.278 tagged_above=-999 required=5 tests=[AWL=2.124,  BAYES_00=-2.599, MIME_BASE64_TEXT=1.753]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72rgg7M6N3Sc for ; Mon, 19 Mar 2012 19:16:39 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8D01321E8054 for ; Mon, 19 Mar 2012 19:16:33 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEF43171; Mon, 19 Mar 2012 22:16:33 -0400 (EDT)
Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Mar 2012 19:15:45 -0700
Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Mar 2012 19:15:44 -0700
Received: from w53375 (10.138.41.149) by szxeml424-hub.china.huawei.com (10.82.67.163) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Mar 2012 10:15:37 +0800
Message-ID: <5072026449B54C15AF507676E0C8EC01@china.huawei.com>
From: Qin Wu 
To: "Van Caenegem, Tom (Tom)" , IETF AVTCore WG 
References: <4F5B2F09.2090704@ericsson.com><10EE199408404E20922B52A3D8B367CD@china.huawei.com> <0FDFA5AD37E04C878E9027BE8DE0E860@china.huawei.com> 
Date: Tue, 20 Mar 2012 10:15:36 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Originating-IP: [10.138.41.149]
X-CFilter-Loop: Reflected
Subject: Re: [AVTCORE] Regardingdraft-ietf-avtcore-feedback-supression-rtp-15
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Mar 2012 02:16:40 -0000

SGksIFRvbToNClRoYW5rIGZvciB5b3VyIHByb3Bvc2VkIHRleHQuIEkgYWdyZWUgdGhhdCByZW9y
Z25pemluZyBzZWN1cml0eSBzZWN0aW9uIGluIHRoZSBjb21wYWN0IG1hbm5lciBtYWtlcyBzZW5z
ZSB0byBtZSBzaW5jZSBSRkM0NTg1IHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gYWxzbyBhcHBsaWVz
IHRvIHRoaXMgZG9jdW1lbnQuDQpJIGxpa2UgdG8gY2hhbmdlIHRoZSBzZWNvbmQgcGFyYWdyYXBo
IGluIHRoZSBzZWN1cml0eSBzZWN0aW9uIHlvdXIgcHJvcG9zZWQgYSBsaXR0bGUgYml0Lg0KWW91
ciBwcm9wb3NlZCB0ZXh0DQoiDQpNb3JlIHNwZWNpZmljYWxseSwgc3Bvb2ZlZCBvciBtYWxpY2lv
dXNseSBjcmVhdGVkIFRQTFIgZmVlZGJhY2sgbWVzc2FnZXMgZ2l2ZSByaXNlIHRvICh1bmRlc2ly
ZWQpIGZlZWRiYWNrIHN1cHJlc3Npb24gYXQgUlRDUCByZWNlaXZlcnMgdGhhdCBhY2NlcHQgc3Vj
aCBUUExSIG1lc3NhZ2VzLiBBbnkgcGFja2V0IGxvc3MgZGV0ZWN0ZWQgYnkgYSByZWNlaXZlciBh
bmQgd2hlcmUgdGhpcyBSVFAgcmVjZWl2ZXIgYWxzbyByZWNlaXZlcyBhIFRQTFIgbWVzc2FnZSBm
b3IgdGhlIHNhbWUgbWlzc2luZyBwYWNrZXQocyksIHdpbGwgbmVnYXRpdmVseSBpbXBhY3QgdGhl
IGFwcGxpY2F0aW9uIHRoYXQgcmVsaWVzIG9uIHRoZSAodGltZWx5KSBSVFAgcmV0cmFuc21pc3Np
b24gY2FwYWJpbGl0aWVzLiANCg0KIg0KTmV3IFRleHQ6DQoiDQpNb3JlIHNwZWNpZmljYWxseSwg
c3Bvb2ZlZCBvciBtYWxpY2lvdXNseSBjcmVhdGVkIFRQTFIgZmVlZGJhY2sgbWVzc2FnZXMgY2F1
c2UgbWlzc2luZyBSVFAgcGFja2V0cyB0byBub3QgYmUgcmVwYWlyZWQgaW4gYSB0aW1lbHkgZmFz
aGlvbiBhbmQgYWRkIHJpc2sgb2YgKHVuZGVzaXJlZCkgZmVlZGJhY2sgc3VwcmVzc2lvbiBhdCBS
VENQIHJlY2VpdmVycyB0aGF0IGFjY2VwdCBzdWNoIFRQTFIgbWVzc2FnZXMuIEFueSBwYWNrZXQg
bG9zcyBkZXRlY3RlZCBieSBhIHJlY2VpdmVyIGFuZCB3aGVyZSB0aGlzIFJUUCByZWNlaXZlciBh
bHNvIHJlY2VpdmVzIGEgVFBMUiBtZXNzYWdlIGZvciB0aGUgc2FtZSBtaXNzaW5nIHBhY2tldChz
KSwgd2lsbCBuZWdhdGl2ZWx5IGltcGFjdCB0aGUgYXBwbGljYXRpb24gdGhhdCByZWxpZXMgb24g
dGhlICh0aW1lbHkpIFJUUCByZXRyYW5zbWlzc2lvbiBjYXBhYmlsaXRpZXMuIA0KIg0KSG9wZSB0
aGlzIG1ha2Ugc2Vuc2UuDQoNClJlZ2FyZHMhDQotUWluDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdl
IC0tLS0tIA0KRnJvbTogIlZhbiBDYWVuZWdlbSwgVG9tIChUb20pIiA8dG9tLnZhbl9jYWVuZWdl
bUBhbGNhdGVsLWx1Y2VudC5jb20+DQpUbzogIlFpbiBXdSIgPGJpbGwud3VAaHVhd2VpLmNvbT47
ICJJRVRGIEFWVENvcmUgV0ciIDxhdnRAaWV0Zi5vcmc+DQpTZW50OiBNb25kYXksIE1hcmNoIDE5
LCAyMDEyIDEwOjA3IFBNDQpTdWJqZWN0OiBSRTogW0FWVENPUkVdIFJlZ2FyZGluZ2RyYWZ0LWll
dGYtYXZ0Y29yZS1mZWVkYmFjay1zdXByZXNzaW9uLXJ0cC0xNQ0KDQoNCg0KUWluLA0KDQpJIHNj
YW5uZWQgdGhyb3VnaCB0aGUgc2VjdXJpdHkgc2VjdGlvbiwgYW5kIG15IHByb3Bvc2FsIHdvdWxk
IGJlIHRvIG1ha2UgaXQgbW9yZSBjb21wYWN0LiBUaGUgd2hvbGUgc2VjdGlvbiBjb3VsZCBiZSB3
cml0dGVuIGFzIHBlciBiZWxvdy4gTGV0IG1lIGtub3cgd2hhdCB5b3UgdGhpbmsgYW5kIHdoZXRo
ZXIgSSBtaXNzZWQgc29tZSBpbXBvcnRhbnQgc3RhdGVtZW50cyBpbiB0aGUgY3VycmVudCAic2Vj
dXJpdHkiIHNlY3Rpb24uDQoNClJlZ2FyZHMNClRvbQ0KDQoNClByb3Bvc2FsOg0KDQoNCiJUaGUg
c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZG9jdW1lbnRlZCBpbiBSRkMgNDU4NSBhcmUgYWxzbyBh
cHBsaWNhYmxlIGZvciB0aGUgVFBMUiBtZXNzYWdlcyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQu
DQoNCk1vcmUgc3BlY2lmaWNhbGx5LCBzcG9vZmVkIG9yIG1hbGljaW91c2x5IGNyZWF0ZWQgVFBM
UiBmZWVkYmFjayBtZXNzYWdlcyBnaXZlIHJpc2UgdG8gKHVuZGVzaXJlZCkgZmVlZGJhY2sgc3Vw
cmVzc2lvbiBhdCBSVENQIHJlY2VpdmVycyB0aGF0IGFjY2VwdCBzdWNoIFRQTFIgbWVzc2FnZXMu
IEFueSBwYWNrZXQgbG9zcyBkZXRlY3RlZCBieSBhIHJlY2VpdmVyIGFuZCB3aGVyZSB0aGlzIFJU
UCByZWNlaXZlciBhbHNvIHJlY2VpdmVzIGEgVFBMUiBtZXNzYWdlIGZvciB0aGUgc2FtZSBtaXNz
aW5nIHBhY2tldChzKSwgd2lsbCBuZWdhdGl2ZWx5IGltcGFjdCB0aGUgYXBwbGljYXRpb24gdGhh
dCByZWxpZXMgb24gdGhlICh0aW1lbHkpIFJUUCByZXRyYW5zbWlzc2lvbiBjYXBhYmlsaXRpZXMu
IA0KDQpBIHNvbHV0aW9uIHRvIHByZXZlbnQgc3VjaCBhdHRhY2sgd2l0aCBtYWxpY2lvdXNseSBz
ZW50IFRQTFIgbWVzc2FnZXMsIGlzIHRvIGFwcGx5IGFuIGF1dGhlbnRpY2F0aW9uIGFuZCBpbnRl
Z3JpdHkgcHJvdGVjdGlvbiBmcmFtZXdvcmsgZm9yIHRoZSBmZWVkYmFjayBtZXNzYWdlcy4gIFRo
aXMgY2FuIGJlIGFjY29tcGxpc2hlZCB1c2luZyB0aGUgUlRQIHByb2ZpbGUgdGhhdCBjb21iaW5l
cyBTZWN1cmUgUlRQIFtSRkMzNzExXSBhbmQgQVZQRiBpbnRvIFNBVlBGIFtSRkM1MTI0XS4NCg0K
Tm90ZSB0aGF0IGludGVybWVkaWFyaWVzIHRoYXQgYXJlIG5vdCB2aXNpYmxlIGF0IHRoZSBSVFAg
bGF5ZXIgdGhhdA0KICAgd2lzaCB0byBzZW5kIHRoZSBUaGlyZCBQYXJ0eSBMb3NzIFJlcG9ydHMg
b24gYmVoYWxmIG9mIHRoZSBtZWRpYQ0KICAgc291cmNlIGNhbiBvbmx5IGRvIHNvIGlmIHRoZXkg
c3Bvb2YgdGhlIFNTUkMgb2YgdGhlIG1lZGlhIHNvdXJjZS4NCiAgIFRoaXMgaXMgZGlmZmljdWx0
IGluIGNhc2UgU1JUUCBpcyBpbiB1c2UuICBJZiB0aGUgaW50ZXJtZWRpYXJ5IGlzDQogICB2aXNp
YmxlIGF0IHRoZSBSVFAgbGF5ZXIsIHRoaXMgaXMgbm90IGFuIGlzc3VlLCBwcm92aWRlZCB0aGUN
CiAgIGludGVybWVkaWFyeSBpcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBjb250ZXh0IGZvciB0aGUg
c2Vzc2lvbi4iDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBhdnQt
Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmF2dC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg
T2YgUWluIFd1DQpTZW50OiB2cmlqZGFnIDE2IG1hYXJ0IDIwMTIgODo0NA0KVG86IElFVEYgQVZU
Q29yZSBXRw0KU3ViamVjdDogUmU6IFtBVlRDT1JFXSBSZWdhcmRpbmcgZHJhZnQtaWV0Zi1hdnRj
b3JlLWZlZWRiYWNrLXN1cHJlc3Npb24tcnRwLTE1DQoNCltzb3JyeSwgaWYgeW91IHJlY2VpdmUg
bXVsdGlwbGUgY29waWVzIG9mIHRoaXMgbWVzc2FnZV0NCg0KSGksIFRvbToNClNvcnJ5IGZvciBs
YXRlLiBTdGF0ZW1lbnQgMyBpcyBqdXN0IGFuIGFkdmljZS4NCkkgYWdyZWUgdW5hdXRoZW50aWNh
dGVkIGZlZWRiYWNrIGlzIG5vdCBlcXVpdmFsZW50IHRvIHN1c3BpY2lvdXMgZmVlZGJhY2suIFJG
QzQ1ODUgYWxsb3cgaWdub3JlIHN1c3BpY2lvdXMgZmVlZGJhY2sgYnV0IGRvZXMgbm90IHNheSB3
ZSBNVVNUIGlnbm9yZSBhbnkgdW5hdXRoZW50aWNhdGVkIGZlZWRiYWNrLg0KWW91ciBwcm9wb3Nh
bCBsb29rcyBnb29kIHRvIG1lLiBIb3cgYWJvdXQgcmV2aXNlIHRoZSBsYXN0IHBhcmFncmFwaCwg
c2VjdGlvbiA3IGFzOg0KIg0KICAgQWxzbyBub3RlIHRoYXQgZW5kcG9pbnRzIHRoYXQgcmVjZWl2
ZSBhIFRoaXJkIFBhcnR5IExvc3MgUmVwb3J0IHdvdWxkDQogICBiZSB3ZWxsLWFkdmlzZWQgdG8g
bWluaW1pemUgdGhlIHJpc2sgb2YgZmFsc2UgVFBMUiBtZXNzYWdlcyBmcm9tDQogICBhIG1hbGlj
aW91cyBzb3VyY2UgKHdoaWNoIHJlc3VsdHMgaW4gdW5uZWVkZWQgc3VwcHJlc3Npb24gZmVlZGJh
Y2sNCiAgIGF0IHRoZSB0YXJnZXQgdmljdGltIHJlY2VpdmVyKHMpLiBTdWdnZXN0ZWQgbWVhc3Vy
ZSBpcyB0byBhdXRoZW50aWNhdGUgDQogICB0aGUgc2VuZGVyIG9mIHRoZSBUaGlyZCBQYXJ0eSBM
b3NzIFJlcG9ydC4gQWNjZXB0aW5nIFRoaXJkIFBhcnR5IExvc3MgUmVwb3J0IA0KICAgZnJvbSB1
bi1hdXRoZW50aWNhdGVkIHNlbmRlciBjYW4gbGVhZCB0byBhIGRlbmlhbCBvZiBzZXJ2aWNlIGF0
dGFjaywgd2hlcmUgDQogICB0aGUgZW5kcG9pbnQgYWNjZXB0cyBwb29yIHF1YWxpdHkgbWVkaWEg
dGhhdCBjb3VsZCBiZSByZXBhaXJlZC4NCiINCkhvcGUgdGhpcyBhZGRyZXNzZXMgeW91ciBjb21t
ZW50Lg0KDQpSZWdhcmRzIQ0KLVFpbg0KDQo+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0K
PkZyb206ICJWYW4gQ2FlbmVnZW0sIFRvbSAoVG9tKSIgPHRvbS52YW5fY2FlbmVnZW1AYWxjYXRl
bC1sdWNlbnQuY29tPg0KPlRvOiAiUWluIFd1IiA8YmlsbC53dUBodWF3ZWkuY29tPjsgIk1hZ251
cyBXZXN0ZXJsdW5kIiANCj48bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPjsgIklFVEYg
QVZUQ29yZSBXRyIgPGF2dEBpZXRmLm9yZz4NCj5TZW50OiBUdWVzZGF5LCBNYXJjaCAxMywgMjAx
MiA5OjU5IFBNDQo+U3ViamVjdDogUkU6IFtBVlRDT1JFXSBSZWdhcmRpbmcgDQo+ZHJhZnQtaWV0
Zi1hdnRjb3JlLWZlZWRiYWNrLXN1cHJlc3Npb24tcnRwLTE1DQoNCg0KPkhpIFFpbiwNCg0KPlRo
ZSBpc3N1ZSBvbiBzdGF0ZW1lbnQgMiA6IE9LDQoNCj5JTU8geW91ciBzdGF0ZW1lbnQgMyAoIkFs
c28gbm90ZSB0aGF0IGVuZHBvaW50cyB0aGF0IHJlY2VpdmUgYSBUaGlyZCANCj5QYXJ0eSBMb3Nz
IFJlcG9ydCB3b3VsZCBiZSB3ZWxsLWFkdmlzZWQgdG8gaWdub3JlIGl0LCB1bmxlc3MgdGhlIHNl
Y3VyaXR5IGlzIGluIHBsYWNlIHRvIGF1dGhlbnRpY2F0ZSB0aGUgc2VuZGVyIG9mIHRoZSBUaGly
ZCBQYXJ0eSBMb3NzIFJlcG9ydCIpIGlzIGFuIGFkdmljZSAoL3JlcXVpcmVtZW50PykgdGhhdCBn
b2VzIHdlbGwgYmV5b25kIHRoZSByZWNvbW1lbmRhdGlvbnMgaW4gdGhlIHNlY3VyaXR5ID5zZWN0
aW9uIDggb2YgUkZDIDQ1ODUuDQoNCj5UaGUgbGF0dGVyIGluZGljYXRlcyB0aGF0IHNlbmRlcnMv
cmVjZWl2ZXJzIHNob3VsZCBiZWhhdmUgY29uc2VydmF0aXZlbHkgd2hlbiBvYnNlcnZpbmcgc3Ry
YW5nZSByZXBvcnRpbmcgYmVoYXZpb3VyLiANCg0KPlRoZSBzZWN0aW9uIGFsc28gc3RhdGVzIHRo
YXQgZmFsc2UgUlRDUCBwYWNrZXRzIGNhbiBiZSBhdm9pZGVkIGJ5IGF1dGhlbnRpY2F0aW5nIFJU
Q1AgbWVzc2FnZXMuICANCg0KPihzZWUgYmVsb3cgdGhlIGV4YWN0IHBocmFzaW5nIHRoYXQgSSBj
b3BpZWQgZm9yIHlvdXIgY29udmVuaWVuY2UpDQoNCj5JbiBsaW5lIHdpdGggdGhlc2UgUkZDIDQ1
ODUgcmVjb21tZW5kYXRpb24sIHlvdSBzZWVtIHRvIGludGVycHJldGUgInVuYXV0aGVudGljYXRl
ZCIgUlRDUCBtZXNzYWdlcyBhcyBhbiBleGFtcGxlIG9mICJzdHJhbmdlIiByZXBvcnRpbmcgYmVo
YXZpb3IsIHdoaWNoIEkgZG8gbm90IHRoaW5rIHdhcyB0aGUgaW50ZW50aW9uIGZyb20gUkZDID40
NTg1Lg0KDQo+TXkgcHJvcG9zYWwgd291bGQgYmUgdG8ganVzdCBpbmRpY2F0ZSBpbiB5b3VyIHNl
Y3VyaXR5IHNlY3Rpb24gdGhhdCBhIHNvbHV0aW9uIHRvIG1pbmltaXNlIHRoZSByaXNrIG9uIGZh
bHNlIFRQTFIgbWVzc2FnZXMgZnJvbSBhIG1hbGljaW91cyBzb3VyY2UgKHdoaWNoIHJlc3VsdHMg
aW4gdW5uZWVkZWQgc3VwcHJlc3Npb24gZmVlZGJhY2sgYXQgdGhlID50YXJnZXQgdmljdGltIHJl
Y2VpdmVyKHMpLCBpcyB0byBtYWtlIHVzZSBvZiBhbiBhdXRoZW50aWNhdGlvbiBmcmFtZXdvcmsg
KGluIGxpbmUgd2l0aCBSRkMgNDU4NSkuIA0KDQo+UmVnYXJkcw0KPlRvbQ0KDQoNCj5SRkMgNDU4
NSwgc2VjdGlvbiA4IChTZWN1cml0eSk6DQoNCj4oLi4pDQoNCj5TZW5kZXJzIGFzIHdlbGwgYXMg
cmVjZWl2ZXJzIFNIT1VMRCBiZWhhdmUgY29uc2VydmF0aXZlbHkgd2hlbg0KPiAgIG9ic2Vydmlu
ZyBzdHJhbmdlIHJlcG9ydGluZyBiZWhhdmlvci4gIEZvciBleGNlc3NpdmUgZmFpbHVyZQ0KPiAg
IHJlcG9ydGluZyBmcm9tIG9uZSBvciBhIGZldyByZWNlaXZlcnMsIHRoZSBzZW5kZXIgTUFZIGRl
Y2lkZSB0byBubw0KPiAgIGxvbmdlciBjb25zaWRlciB0aGlzIGZlZWRiYWNrIHdoZW4gYWRhcHRp
bmcgaXRzIHRyYW5zbWlzc2lvbiBiZWhhdmlvcg0KPiAgIGZvciB0aGUgbWVkaWEgc3RyZWFtLiAg
SW4gYW55IGNhc2UsIHNlbmRlcnMgYW5kIHJlY2VpdmVycyBTSE9VTEQNCj4gICBzdGlsbCBhZGhl
cmUgdG8gdGhlIG1heGltdW0gUlRDUCBiYW5kd2lkdGggYnV0IG1ha2Ugc3VyZSB0aGF0IHRoZXkN
Cj4gICBhcmUgY2FwYWJsZSBvZiB0cmFuc21pdHRpbmcgYXQgbGVhc3QgcmVndWxhcmx5IHNjaGVk
dWxlZCBSVENQDQo+ICAgcGFja2V0cy4gIFNlbmRlcnMgU0hPVUxEIGNhcmVmdWxseSBjb25zaWRl
ciBob3cgdG8gYWRqdXN0IHRoZWlyDQo+ICAgdHJhbnNtaXNzaW9uIGJhbmR3aWR0aCB3aGVuIGVu
Y291bnRlcmluZyBzdHJhbmdlIHJlcG9ydGluZyBiZWhhdmlvcjsNCj4gICB0aGV5IE1VU1QgTk9U
IGluY3JlYXNlIHRoZWlyIHRyYW5zbWlzc2lvbiBiYW5kd2lkdGggZXZlbiBpZiBpZ25vcmluZw0K
PiAgIHN1c3BpY2lvdXMgZmVlZGJhY2suDQoNCj4gICBBdHRhY2tzIHVzaW5nIGZhbHNlIFJUQ1Ag
cGFja2V0cyAoUmVndWxhciBhcyB3ZWxsIGFzIEVhcmx5IG9uZXMpIGNhbg0KPiAgIGJlIGF2b2lk
ZWQgYnkgYXV0aGVudGljYXRpbmcgYWxsIFJUQ1AgbWVzc2FnZXMuICBUaGlzIGNhbiBiZSBhY2hp
ZXZlZA0KPiAgIGJ5IHVzaW5nIHRoZSBBVlBGIHByb2ZpbGUgdG9nZXRoZXIgd2l0aCB0aGUgU2Vj
dXJlIFJUUCBwcm9maWxlIGFzDQo+ICAgZGVmaW5lZCBpbiBbMjJdOyBhcyBhIHByZXJlcXVpc2l0
ZSwgYW4gYXBwcm9wcmlhdGUgY29tYmluYXRpb24gb2YNCj4gICB0aG9zZSB0d28gcHJvZmlsZXMg
KGFuICJTQVZQRiIpIGlzIGJlaW5nIHNwZWNpZmllZCBbMjFdLiAgTm90ZSB0aGF0LA0KPiAgIHdo
ZW4gZW1wbG95aW5nIGdyb3VwIGF1dGhlbnRpY2F0aW9uIChhcyBvcHBvc2VkIHRvIHNvdXJjZQ0K
PiAgIGF1dGhlbnRpY2F0aW9uKSwgdGhlIGFmb3JlbWVudGlvbmVkIGF0dGFja3MgbWF5IGJlIGNh
cnJpZWQgb3V0IGJ5DQo+ICAgbWFsaWNpb3VzIG9yIG1hbGZ1bmN0aW9uaW5nIGdyb3VwIG1lbWJl
cnMgaW4gcG9zc2Vzc2lvbiBvZiB0aGUgcmlnaHQNCj4gICBrZXlpbmcgbWF0ZXJpYWwuDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQXVkaW8vVmlkZW8g
VHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UNCmF2dEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnQ=


From ron.even.tlv@gmail.com  Tue Mar 20 00:31:34 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BB621F8806 for ; Tue, 20 Mar 2012 00:31:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.302
X-Spam-Level: 
X-Spam-Status: No, score=-3.302 tagged_above=-999 required=5 tests=[AWL=0.297,  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 IkE4FXmE610D for ; Tue, 20 Mar 2012 00:31:29 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id CAEEE21F8807 for ; Tue, 20 Mar 2012 00:31:28 -0700 (PDT)
Received: by werb10 with SMTP id b10so8008340wer.31 for ; Tue, 20 Mar 2012 00:31:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=hGSV5gIyibkwsRiKlXALHBDhy5HiK0Jed05tMXoXpdA=; b=jzBmQGGOjcppRfk1obTQCzL8bptLRDOgDKiffNuFAu9aLymn5HV42wEfNqzwY/MEIy LskRsnK6jAgGuir//swkS+ldPC2E32je8DM49BEyCCUVGXQvKcAvXd6hu+P+mE3Xo/bY spg1PgqyHN4bJeTCYItHY/QKX1pp60ocrpuRzTtbfACGFQd3B+EwFLz+1g9iXjn3KAro gaV/pFBMdLpY0IraDaGLXi5flWytnLAcPXwMMA65kscnR+e05uuTSlF9jrsoVTgaq1Q8 VpFYv0TwU4qwR/42cAdgv8d6W8AXMxjlzKB3VDQ7dRY2JEUSURYvfBhcHF0UhQnvOwxO uP2A==
Received: by 10.180.92.34 with SMTP id cj2mr26185775wib.8.1332228687786; Tue, 20 Mar 2012 00:31:27 -0700 (PDT)
Received: from windows8d787f9 (bzq-79-179-219-130.red.bezeqint.net. [79.179.219.130]) by mx.google.com with ESMTPS id df3sm31986692wib.1.2012.03.20.00.31.25 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Mar 2012 00:31:26 -0700 (PDT)
From: "Roni Even" 
To: "'Magnus Westerlund'" 
References: <4f62249b.8a0eb40a.628f.6e47@mx.google.com> <4F62EE9F.8080204@ericsson.com> <4f634347.2614b40a.036d.fffff329@mx.google.com> <4F635700.8050505@ericsson.com> <4f645529.2266b40a.193a.fffff25e@mx.google.com> <4F67AD46.1010404@ericsson.com>
In-Reply-To: <4F67AD46.1010404@ericsson.com>
Date: Tue, 20 Mar 2012 09:30:26 +0200
Message-ID: <4f68324e.e35eb40a.4673.ffffc572@mx.google.com>
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: Ac0GHCv1RcO842NARvuV0bWeQ57FSwATivFw
Content-Language: en-us
Cc: 'IETF AVTCore WG' 
Subject: Re: [AVTCORE] draft-westerlund-avtcore-multiplex-architecture-01 - same SSRC for SVC
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Mar 2012 07:31:34 -0000

Hi Magnus,
I understand now the case you were relating to as a case where at least =
two
MST SVC payloads are multiplexed.
Still RFC 6190 does not discussed this case and does not suggest using =
same
SSRC in the different session. My view is that RFC 6190 leaves it to
signaling since section 7.2.3 of RFC 6190 talks about using signaling =
for
media decoding dependency. I agree that the current signaling does not
address this case but claim that SSRC dependencies should be done in the
signaling.

I also think that in term of application usage I would not recommend =
mixing
SVC layers from different sources in MST since the major reason for =
using
MST was to handle BW better allowing receivers to join or receive only =
the
subset they need. This was the reason for mentioning SST since if there =
is
no application requirement for MST why use it.

Roni Even

> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> Sent: Tuesday, March 20, 2012 12:04 AM
> To: Roni Even
> Cc: 'IETF AVTCore WG'
> Subject: Re: [AVTCORE] =
draft-westerlund-avtcore-multiplex-architecture-
> 01 - same SSRC for SVC
>=20
> On 2012-03-17 10:10, Roni Even wrote:
> > Hi,
> > I will just address the SVC multiplexing issue and start a different
> > thread on the session and ssrc multiplexing and the relation between
> > RTP session and the transport infrastructure used which is also
> > discussed in draft-alvestrand-rtp-sess-neutral-00.
> >
> > As for the SVC example in the document, I think that the reason for
> > MST mode is because the idea is to use the session multiplexing =
based
> > on different UDP ports to divide the streams, for example in
> multicast
> > allowing the users to join just the relevant multicast groups. IF =
you
> > want SSRC multiplexing in SVC you can use SST (Single Session
> > Transmission) mode and I think this is the reason there is no need =
to
> > address SSRC multiplexing using multiple sessions to a single UDP
> receive port is not discussed.
>=20
> Yes, I agree that MST exist so that sets of scalability layers can be
> distributed over multiple multicast groups so that each receivers can
> join the appropriate number of multicast groups for them.
>=20
> And the discussion in section 3.2 is in this context.
>=20
> >
> > What I am saying is that the example in 3.2 is not correct since it
> > was not addressed on purpose being non relevant use for MST.
>=20
> Sorry,
>=20
> I don't understand how you come to this conclusion. What section 3.2
> says around SVC is:
>=20
>       Inter-relation:  SSRC belonging to the same synchronization
>          context (originating from the same end-point), within or
>          between RTP Sessions, are indicated through use of identical
>          SDES CNAME items in RTCP compound packets with those SSRC as
>          originating source.  SDP signalling can provide explicit SSRC
>          grouping [RFC5576].  When CNAME is inappropriate or
>          insufficient, there exist a few other methods to relate
>          different SSRC.  One such case is session-based RTP
>          retransmission [RFC4588].  In some cases, the same SSRC
>          Identifier value is used to relate streams in two different
> RTP
>          Sessions, such as in Multi-Session Transmission of scalable
>          video [RFC6190].
>=20
>=20
> What is says is that in MST there exist cases where CNAME clearly =
isn't
> enough to make the binding between the SSRC in the different RTP
> session on the differnet multicast groups. CNAME is not sufficient if
> multiple video sources are sent from the same synchronization context.
>=20
> Thus something additional mechanism is required. My claim is that RFC
> 6190 is relying on using the same SSRC value in the different RTP
> Session being used to transmit the different scalability layers.
> However this is not documented in the RFC.
>=20
> Please don't mix SST into this case as it is not what we are talking
> about.
>=20
> Cheers
>=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
> ----------------------------------------------------------------------


From tom.van_caenegem@alcatel-lucent.com  Tue Mar 20 02:16:25 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C3221F8881 for ; Tue, 20 Mar 2012 02:16:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.385
X-Spam-Level: 
X-Spam-Status: No, score=-9.385 tagged_above=-999 required=5 tests=[AWL=0.864,  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 ZfuT6kg0iTSa for ; Tue, 20 Mar 2012 02:16:24 -0700 (PDT)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id C0C7721F887D for ; Tue, 20 Mar 2012 02:16:23 -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 q2K9DQ38005854 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 20 Mar 2012 10:16:18 +0100
Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.40]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 20 Mar 2012 10:16:05 +0100
From: "Van Caenegem, Tom (Tom)" 
To: Qin Wu , IETF AVTCore WG 
Date: Tue, 20 Mar 2012 10:16:04 +0100
Thread-Topic: [AVTCORE] Regardingdraft-ietf-avtcore-feedback-supression-rtp-15
Thread-Index: Ac0GP1ze5EMbuctfRRG4baEt8rZTzQAOptlw
Message-ID: 
References: <4F5B2F09.2090704@ericsson.com>  <10EE199408404E20922B52A3D8B367CD@china.huawei.com>  <0FDFA5AD37E04C878E9027BE8DE0E860@china.huawei.com>  <5072026449B54C15AF507676E0C8EC01@china.huawei.com>
In-Reply-To: <5072026449B54C15AF507676E0C8EC01@china.huawei.com>
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: nl-NL, en-US
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
Subject: Re: [AVTCORE] Regardingdraft-ietf-avtcore-feedback-supression-rtp-15
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Mar 2012 09:16:25 -0000

Looks fine too!
Tom=20

-----Original Message-----
From: Qin Wu [mailto:bill.wu@huawei.com]=20
Sent: dinsdag 20 maart 2012 3:16
To: Van Caenegem, Tom (Tom); IETF AVTCore WG
Subject: Re: [AVTCORE] Regardingdraft-ietf-avtcore-feedback-supression-rtp-=
15

Hi, Tom:
Thank for your proposed text. I agree that reorgnizing security section in =
the compact manner makes sense to me since RFC4585 security consideration a=
lso applies to this document.
I like to change the second paragraph in the security section your proposed=
 a little bit.
Your proposed text
"
More specifically, spoofed or maliciously created TPLR feedback messages gi=
ve rise to (undesired) feedback supression at RTCP receivers that accept su=
ch TPLR messages. Any packet loss detected by a receiver and where this RTP=
 receiver also receives a TPLR message for the same missing packet(s), will=
 negatively impact the application that relies on the (timely) RTP retransm=
ission capabilities.=20

"
New Text:
"
More specifically, spoofed or maliciously created TPLR feedback messages ca=
use missing RTP packets to not be repaired in a timely fashion and add risk=
 of (undesired) feedback supression at RTCP receivers that accept such TPLR=
 messages. Any packet loss detected by a receiver and where this RTP receiv=
er also receives a TPLR message for the same missing packet(s), will negati=
vely impact the application that relies on the (timely) RTP retransmission =
capabilities.=20
"
Hope this make sense.

Regards!
-Qin
----- Original Message -----
From: "Van Caenegem, Tom (Tom)" 
To: "Qin Wu" ; "IETF AVTCore WG" 
Sent: Monday, March 19, 2012 10:07 PM
Subject: RE: [AVTCORE] Regardingdraft-ietf-avtcore-feedback-supression-rtp-=
15



Qin,

I scanned through the security section, and my proposal would be to make it=
 more compact. The whole section could be written as per below. Let me know=
 what you think and whether I missed some important statements in the curre=
nt "security" section.

Regards
Tom


Proposal:


"The security considerations documented in RFC 4585 are also applicable for=
 the TPLR messages defined in this document.

More specifically, spoofed or maliciously created TPLR feedback messages gi=
ve rise to (undesired) feedback supression at RTCP receivers that accept su=
ch TPLR messages. Any packet loss detected by a receiver and where this RTP=
 receiver also receives a TPLR message for the same missing packet(s), will=
 negatively impact the application that relies on the (timely) RTP retransm=
ission capabilities.=20

A solution to prevent such attack with maliciously sent TPLR messages, is t=
o apply an authentication and integrity protection framework for the feedba=
ck messages.  This can be accomplished using the RTP profile that combines =
Secure RTP [RFC3711] and AVPF into SAVPF [RFC5124].

Note that intermediaries that are not visible at the RTP layer that
   wish to send the Third Party Loss Reports on behalf of the media
   source can only do so if they spoof the SSRC of the media source.
   This is difficult in case SRTP is in use.  If the intermediary is
   visible at the RTP layer, this is not an issue, provided the
   intermediary is part of the security context for the session."




-----Original Message-----
From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Qin W=
u
Sent: vrijdag 16 maart 2012 8:44
To: IETF AVTCore WG
Subject: Re: [AVTCORE] Regarding draft-ietf-avtcore-feedback-supression-rtp=
-15

[sorry, if you receive multiple copies of this message]

Hi, Tom:
Sorry for late. Statement 3 is just an advice.
I agree unauthenticated feedback is not equivalent to suspicious feedback. =
RFC4585 allow ignore suspicious feedback but does not say we MUST ignore an=
y unauthenticated feedback.
Your proposal looks good to me. How about revise the last paragraph, sectio=
n 7 as:
"
   Also note that endpoints that receive a Third Party Loss Report would
   be well-advised to minimize the risk of false TPLR messages from
   a malicious source (which results in unneeded suppression feedback
   at the target victim receiver(s). Suggested measure is to authenticate=20
   the sender of the Third Party Loss Report. Accepting Third Party Loss Re=
port=20
   from un-authenticated sender can lead to a denial of service attack, whe=
re=20
   the endpoint accepts poor quality media that could be repaired.
"
Hope this addresses your comment.

Regards!
-Qin

>----- Original Message -----
>From: "Van Caenegem, Tom (Tom)" 
>To: "Qin Wu" ; "Magnus Westerlund"=20
>; "IETF AVTCore WG" 
>Sent: Tuesday, March 13, 2012 9:59 PM
>Subject: RE: [AVTCORE] Regarding=20
>draft-ietf-avtcore-feedback-supression-rtp-15


>Hi Qin,

>The issue on statement 2 : OK

>IMO your statement 3 ("Also note that endpoints that receive a Third=20
>Party Loss Report would be well-advised to ignore it, unless the security =
is in place to authenticate the sender of the Third Party Loss Report") is =
an advice (/requirement?) that goes well beyond the recommendations in the =
security >section 8 of RFC 4585.

>The latter indicates that senders/receivers should behave conservatively w=
hen observing strange reporting behaviour.=20

>The section also states that false RTCP packets can be avoided by authenti=
cating RTCP messages. =20

>(see below the exact phrasing that I copied for your convenience)

>In line with these RFC 4585 recommendation, you seem to interprete "unauth=
enticated" RTCP messages as an example of "strange" reporting behavior, whi=
ch I do not think was the intention from RFC >4585.

>My proposal would be to just indicate in your security section that a solu=
tion to minimise the risk on false TPLR messages from a malicious source (w=
hich results in unneeded suppression feedback at the >target victim receive=
r(s), is to make use of an authentication framework (in line with RFC 4585)=
.=20

>Regards
>Tom


>RFC 4585, section 8 (Security):

>(..)

>Senders as well as receivers SHOULD behave conservatively when
>   observing strange reporting behavior.  For excessive failure
>   reporting from one or a few receivers, the sender MAY decide to no
>   longer consider this feedback when adapting its transmission behavior
>   for the media stream.  In any case, senders and receivers SHOULD
>   still adhere to the maximum RTCP bandwidth but make sure that they
>   are capable of transmitting at least regularly scheduled RTCP
>   packets.  Senders SHOULD carefully consider how to adjust their
>   transmission bandwidth when encountering strange reporting behavior;
>   they MUST NOT increase their transmission bandwidth even if ignoring
>   suspicious feedback.

>   Attacks using false RTCP packets (Regular as well as Early ones) can
>   be avoided by authenticating all RTCP messages.  This can be achieved
>   by using the AVPF profile together with the Secure RTP profile as
>   defined in [22]; as a prerequisite, an appropriate combination of
>   those two profiles (an "SAVPF") is being specified [21].  Note that,
>   when employing group authentication (as opposed to source
>   authentication), the aforementioned attacks may be carried out by
>   malicious or malfunctioning group members in possession of the right
>   keying material.
_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt

From mcgrew@cisco.com  Wed Mar 21 11:00:52 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046D121E8063 for ; Wed, 21 Mar 2012 11:00:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.17
X-Spam-Level: 
X-Spam-Status: No, score=-109.17 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_44=0.6, 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 dShyO77yAOin for ; Wed, 21 Mar 2012 11:00:50 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7746321E8091 for ; Wed, 21 Mar 2012 11:00:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=18563; q=dns/txt; s=iport; t=1332352850; x=1333562450; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=FoNvGQV6KGdnTwtG3WMZ+OeNJL77egRS2JDJmJARrH8=; b=mkTXk0Vhgcfd/Qkx1RJLU02BAqlGRidLg0WuzGuYGeSSn57NdFP31aRZ UIqFS9lwELa9YFrOdrYQ3NEi8COk7gl3idwNLkZOpMRQ/Cqwlc26nz5eT 6xhqsNnMHesPydcN8q0ZmQDm1h7Wr9MkoyaGiEqnsF7R49R55n+OKMXP1 M=;
X-Files: ekt-rt.txt : 8960
X-IronPort-AV: E=Sophos;i="4.73,623,1325462400";  d="txt'?scan'208";a="37096155"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 21 Mar 2012 18:00:50 +0000
Received: from stealth-10-32-254-213.cisco.com (stealth-10-32-254-213.cisco.com [10.32.254.213]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2LI0n9B026939; Wed, 21 Mar 2012 18:00:49 GMT
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/mixed; boundary="Apple-Mail=_C02993E1-8F4F-4058-A324-782D0123B952"
From: David McGrew 
In-Reply-To: 
Date: Wed, 21 Mar 2012 14:00:48 -0400
Message-Id: <7A5A3B36-FEAF-43D0-B66F-690468902622@cisco.com>
References: <4F3E1F27.6020108@ericsson.com> 
To: Magnus Westerlund , IETF AVTCore WG , Roni Even 
X-Mailer: Apple Mail (2.1257)
Cc: Flemming Andreasen , Dan Wing 
Subject: [AVTCORE] EKT with removable tags [Was: Re: Questions regarding EKT (draft-ietf-avt-srtp-ekt-03)]
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Mar 2012 18:00:52 -0000

--Apple-Mail=_C02993E1-8F4F-4058-A324-782D0123B952
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Hi AVTCore,

here is the follow-up to the questions on EKT.  =20

The original EKT design used the SRTP authentication function to protect =
the authenticity of the EKT data, which allowed the design to make the =
size of the EKT data somewaht smaller.  However, this design requires a =
tight binding between EKT and SRTP, and this tight binding makes it =
impossible for the original design to be used in some new use cases, =
such as interoperability between EKT and non-EKT endpoints.  Attached is =
a short note that describes a new loose-binding approach to EKT, which =
retains EKT's current capabilities while allowing it to accomodate some =
use cases that were unanticipated when it was first designed.=20

Comments welcome.  Apologies for the length of the note, but we wanted =
to be clear. =20

David


--Apple-Mail=_C02993E1-8F4F-4058-A324-782D0123B952
Content-Disposition: attachment;
	filename=ekt-rt.txt
Content-Type: text/plain;
	name="ekt-rt.txt"
Content-Transfer-Encoding: 7bit

Removate Encrypted Key Transport (EKT) Tags: a design alternative
using a loose binding approach

David and Dan (with input from Magnus)

0.  Introduction

The original EKT design used the SRTP authentication function to
protect the authenticity of the EKT data, which allowed the design to
make the size of the EKT data somewaht smaller.  However, this design
requires a tight binding between EKT and SRTP, and this tight binding
makes it impossible for the original design to be used in some new use
cases, such as interoperability between EKT and non-EKT endpoints.
This note introduces a new loose-binding approach to EKT, which
retains EKT's current capabilities while allowing it to accomodate
some use cases that were unanticipated when it was first designed.
Loose-binding requires somewhat larger EKT data, but this fact is
mitigated somewhat by the fact that the sender can choose when to
include EKT data in SRTP/SRTCP packets at its own discretion.


1.  The interoperabiltiy use case

Appendix A of draft-ietf-avt-srtp-ekt-0 descries how EKT can be used
to optimize interworking between DTLS-SRTP and SRTP with SDP Security
Descriptions.  Consider the case in which a WEBRTC endpoint Alice
(using DTLS-SRTP + EKT) uses a media gateway (MGW) (with DTLS+SRTP and
EKT support) to connect to a SDESC keyed SRTP legacy end-point Bob.
The goal here is that the MGW should not need to perform any SRTP or
SRTCP operations beyond injecting Bob's key using EKT to Alice. 

Unfortunately, this case does not work with EKT as currently defined,
because the MGW will have to modify all RTP and RTCP packets as they
pass the MGW.  This is because current definition of EKT has an SRTP
base authentication tag that depends on the EKT data, and thus the
removal of any EKT data requires one to recalculate the base
authentication tag.  Note that this is true even in the abbreviated
form, where the reserved and "0" abbreviated form indication bit is
covered. Thus it is impossible for the MGW to perform a packet
transformation by simply stripping away the extra byte in the
abbreviated form in the Alice to Bob direction, to accomodate the fact
that Bob is "legacy" and does not understand EKT.

Also in the other direction, in which the MGW needs to include EKT
information in the SRTP/SRTCP packets in order to indicate Bob's key to
Alice, the MGW needs to recompute all SRTP and SRTCP packets to ensure
that the authentication tag changes from the base SRTP authentication
to include either the full or abbreviated EKT authentication tag.

In the rest of this note we propose some changes to EKT that would
allow all of the EKT fields to be removed by an intermediary device
such as a media gateway.


2.  Removable EKT tags

Removable EKT tags can be used with non-EKT SRTP implementations, and
it allows a media gateway to do basic insertion or stripping
operations of the packets to convert them between SRTP-EKT and regular
SRTP packets, even without the EKT key in most scenarios.  More
specifically, our goal is that the removal of an EKT tag from an
SRTP-EKT packet results in a valid SRTP packet for the same SRTP
session, with the same SRTP master key.  In addition, an intermediary
device that knows the SRTP master key and the EKT key can create a
valid EKT tag for an SRTP packet.  The logical model here is that
there is an SRTP session in which some, but not all, members are using
EKT.

Recall that that EKT has two formats: a full EKT tag, that contains
all of the data of interest, and a short form, which conveys no
information other than the absence of the full tag.  The sender
periodically uses the full tag, but otherwise uses the short
tag to save bandwidth.  

We consider two cases: an intermediary device that participates in the
SRTP-EKT session, and thus knows the EKT key, and one that does not.
With removable tags, here are the transformations that would be
possible to execute by an intermediary device that does not have any
secret key information:

  1.  SRTP-EKT with full EKT tag -> SRTP-EKT with short EKT tag 

  2.  SRTP-EKT with short EKT tag -> Regular SRTP 

  3.  SRTP-EKT with full EKT tag -> Regular SRTP (this just combines 1 and 2)

  4.  Regular SRTP  -> SRTP-EKT with short EKT tag 

(This assumes that the short tag does not depend on the EKT keys, as
in the current EKT.)  An intermediary device that doesn't know any of
the SRTP keys could still do this transition as well:

  5.  SRTP-EKT with short EKT tag  -> SRTP-EKT with full EKT tag 

  6.  Regular SRTP -> SRTP-EKT with full EKT tag (this just combines 1 and 5)

... if it knows the full EKT tag, but it can't create the full EKT tag
itself without those SRTP keys.  (Note the architectural question of
how the intermediary gets the current full EKT tag.  This is a
solvable problem, of course, but one that should be kept in mind.)

If the intermediary has the SRTP keys and other information, as in the
case in which it is a gateway between Regular SRTP and SRTP-EKT, then
it has all of the information needed for transformations #5 and #6.


3.  Changes to EKT to allow removable tags

The main change is that EKT needs to provide its own authentication.
The AES-ECB cipher does not provide this security service, but the AES
Key Wrap (AES-KW) cipher does.  AES-KW is currently the
mandatory-to-implement EKT cipher, so the only change needed to the
EKT ciphers is the removal of the AES-ECB option.

The EKT processing is changed so that all of the EKT-specific packet
processing steps take place before the normal SRTP packet processing
steps.  For instance, the provisional keys used in current
inbound processing are not needed.

The new EKT data fields are as follows:

      EKT_Plaintext = SRTP_Master_Key || SSRC || ROC || ISN

     EKT_Ciphertext = EKT_Encrypt(EKT_Key, EKT_Plaintext)

       Full_EKT_Tag = Ciphertext || SPI || '1'

      Short_EKT_Tag = Reserved || '0'

Here || denotes concatenation, and '1' and '0' denote single one and
zero bits, respectively.  The fields are 

   EKT_Plaintext is an input to the EKT encryption operation.  This
   data never appears on the wire, and is only used in computations
   internal to EKT.

   EKT_Ciphertext is the output of the EKT encryption operation.  This
   field is included in SRTP-EKT packets.  

   The SPI and Reserved fields are as currently defined.  

   SSRC is the RTP Synchronization Source identifier of the 
   current RTP stream.

   ROC is the SRTP Rollover Counter of the current SRTP stream.

   ISN is the initial sequence number, as currently defined in EKT.

Note that if P = SRTP || EKT is a valid SRTP-EKT packet with full tag,
then P' = SRTP is a valid SRTP packet, and SRTP || Reserved || '0'
is a valid SRTP-EKT packet with a short tag.

A receiver processes an EKT_Ciphertext by decrypting it, verifying
that the SSRC field in the resulting EKT_plaintext matches the SSRC in
the session, and accepting the other fields of the SSRC values match.

The new packet formats are simple: the Full_EKT_Tag or the
Short_EKT_Tag are appended at the tail end of the SRTP packet.  


4.  Using removable tags for interoperability

A MGW can provide interoperability between an SRTP-EKT endpoint and a
non-EKT SRTP endpoint, and for the most part, the MGW can use the
non-cryptographic transformations on packets outlined above.  However,
there are some uses of cryptography that will be required for that
gateway.

If a new SRTP master key is communicated to the MGW (via EKT from the
EKT leg, or via Security Descriptions from the Security Descriptions
leg), the MGW needs to convert that information for the other leg, and
that process will incur some cryptographic operations.  Specifically,
if the new key arrived via EKT, that must be decrypted and then sent
in Security Descriptions; likewise, if a new key arrives via Security
Descriptions that must be encrypted via EKT and sent in SRTP/SRTCP.


5.  Security 

The presence of the SSRC in the EKT_Plaintext ensures that an attacker
cannot substitute an EKT_Ciphertext from one SRTP stream into another
SRTP stream, even if those two streams are using the same SRTP master
key.  This is important because some applications may use the same
master key for multiple streams.

An attacker who strips a Full_EKT_Tag from an SRTP packet may prevent
the intended receiver of that packet from being able to decrypt it.
This is a minor denail of service vulnerability.   Similarly, an
attacker who adds a Full_EKT_Tag can disrupt service.  

An attacker learns from EKT when SRTP Master Keys change.  

The EKT Cipher MUST be at least as strong as the encryption and
authentication operations used in SRTP.  

Part of the EKT_Plaintext is known, or easily guessable to an
attacker.  Thus, the EKT Cipher MUST resist known plaintext attacks.
In practice, this requirement does not impose any restrictions 
on our choices, since the ciphers in use provide high security
even when much plaintext is known.












--Apple-Mail=_C02993E1-8F4F-4058-A324-782D0123B952
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1



On Feb 22, 2012, at 10:20 AM, David McGrew wrote:

> Many thanks for your review, Magnus.   I'll follow up with the thread =
that doesn't copy the list, then let's bring the conversation back to =
the list.
>=20
> David
>=20
> On Feb 17, 2012, at 4:34 AM, Magnus Westerlund wrote:
>=20
>> Authors, WG,
>>=20
>> I have reviewed the EKT draft and have a number of high level =
comments
>> and questions about this draft. Please consider this as individual
>> input, not as WG chair.
>>=20
>> I have done this review from the perspective of checking if two
>> different use cases are possible to realize using EKT. The two use =
cases
>> are:
>>=20
>> A) Centralized conferencing using a RTP transport translator. Example
>> would be 4 end-points establishing unicast traffic session to the
>> translator. On each of these DTLS-SRTP would be used for keying and =
all
>> nodes support EKT. The goal is that the transport translator should =
be
>> able to forward all RTP and RTCP packets from one participant to all =
the
>> other without any processing related to security (SRTP). I assume the
>> translator supports DTLS-SRTP and the signalling helps ensure that =
the
>> conference participants agree on a single KEK and SPI set.
>>=20
>> B) A WEBRTC endpoint Alice (using DTLS-SRTP + EKT in this case) uses =
a
>> media gateway (MGW) (DTLS+SRTP and EKT support) to connect to a SDESC
>> keyed SRTP legacy end-point Bob. The goal is that the MGW should not
>> need to perform any SRTP or SRTCP operations beyond injecting Bob's =
key
>> using EKT to Alice. This is basically the use case described in =
Appendix
>> A in the draft.
>>=20
>> =46rom my review I have the following issues with the current =
definition
>> of EKT or at least the description. I do not rule out that I have =
missed
>> something in the description.
>>=20
>> 1) It appears that use case B above is not functional with EKT as
>> currently defined. My understanding is that the MGW will have to =
modify
>> all RTP and RTCP packets as they pass the MGW. This as the presence =
of
>> the EKT authentication tag, in either form requires one to =
recalculate
>> the base authentication tag. This as it covers the keys and fields of
>> the EKT authentication tag, even in the abbreviated form where the
>> reserved and "0" abbreviated form indication bit is covered. Thus it =
is
>> impossible for the MGW to perform a packet transformation by simply
>> stripping away the extra byte in the abbreviated form in the Alice to
>> Bob direction, remember that Bob is legacy and wants no EKT
>> authentication tags as it doesn't understand them.
>>=20
>> Also in the other direction where the MGW needs to include EKT
>> information in the RTP/RTCP packets where it would like to indicate
>> Bob's key to Alice it needs to recompute all RTP and RTCP packets to
>> ensure that the authentication tag changes from the regular 80 bit =
SHA-1
>> HMAC to either the full or abbreviated EKT authentication tag =
including
>> a different 80-bit SHA-1 HMAC tag.
>>=20
>> This appears to be a design flaw. I think it is important that EKT =
can
>> be used with legacy and the MGW only needs to do basic insertion or
>> stripping operations of the packets to convert them between EKT and
>> regular SRTP versions of the authentication tag.
>>=20
>> 2) If I understand correctly there are in fact three ways of EKT
>> operation in regards how to use the KEK and EKT where of 2 I think =
are
>> intentional. This is focused on use case A above.
>>=20
>> i) Use a single KEK+SPI over all session participants, having the
>> signaling and the central conference server force the participants to
>> agree on the servers decided KEK and SPI information
>>=20
>> ii) Have each participant agree with the server on a different =
KEK+SPI,
>> then distribute each KEK and SPI to all the participants so that EKT
>> SRTP/SRTCP packets can go end-to-end between all participants.
>>=20
>> iii) Have each participant agree with the server on a different =
KEK+SPI,
>> then have the central node to modify the EKT messages to match the =
KEK
>> that particular participant has. This last one is only practical if =
only
>> the SRTP/SRTCP messages that has a master key in them needs to be =
modified.
>>=20
>> I assume iii) is not intentional to use as it is sub-optimal. ii) =
seems
>> to have one issue that is clearly insufficiently discussed in the =
draft.
>> That is how the system ensures that all participants agree on =
different
>> SPI values so that none is overlapping within the RTP session. For =
both
>> i) and ii) I am missing discussion in the negotiation sections on the
>> details how the SPI value is negotiated and can be changed by the =
party
>> representing the centralized conference to arrive at a set that are
>> unique. I also think this can result in some "clipping" cases as
>> somewhat discussed.
>>=20
>> In addition the fact that one has two different modes of operation it =
is
>> unclear which should be used by an end-point in a given session and
>> there is no signaling for this. In worst case the conference server
>> assumes that each participant will generate a KEK and use different
>> ones, while a participants implementation assumes that a single one =
will
>> be used. So clarification of both implementation requirements of =
these
>> operation modes and the signaling necessary to agree on what is being =
used.
>>=20
>> 3) The draft discusses that one can use EKT authentication tags in =
RTCP
>> only, RTP only or both. However, it appears there is no signaling to
>> negotiate which should be used. Is the goal that one uses the EKT
>> authentication tag always in both RTP and RTCP independent if one
>> actually is sending full EKT authentication tag only in RTCP? If that =
is
>> not the intention I think the aspect of how one negotiates what
>> authentication format for RTP and RTCP needs to be clarified.
>>=20
>> 4) Section 2.2.2: I am a bit confused over the process when using =
ISN.
>> The first one has to do with that one uses ISN in the replay =
protection
>> part. That would mean that multiple SRTCP packets containing the same
>> EKT transported master key would be considered duplicates, despite =
the
>> actual RTCP information in it is not a duplicate. Why isn't the =
regular
>> RTCP packet index or RTP sequence number used in the replay =
protection?
>>=20
>> Secondly, if I understand correctly in a SRTP packet that contains a
>> full EKT auth tag that has a RTP sequence number that is lower than =
the
>> ISN (when re-keying) will still use the new key that is included in =
the
>> KEK protected part for the packet protection (encryption and =
integrity).
>> I find this strange behavior to use the new key prior to the ISN. It
>> also appears to have the effect that if one uses different EKT SPI to
>> protect the new key compared to the old key in use by this end-point =
the
>> receivers that hasn't gotten this SPI+KEK can't decode this RTP/RTCP
>> packet despite this is prior to the rekeying point. That can't be the
>> intention as it creates an unclean key-change.
>>=20
>>=20
>> I do have more detailed comments but I will save those until I have
>> received answer on these to determine if they are worth writing up or
>> may become irrelevant due to changes.
>>=20
>> Cheers
>>=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
>=20


--Apple-Mail=_C02993E1-8F4F-4058-A324-782D0123B952--

From stewe@stewe.org  Wed Mar 21 11:09:27 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92EE021F847F; Wed, 21 Mar 2012 11:09:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.735
X-Spam-Level: 
X-Spam-Status: No, score=-3.735 tagged_above=-999 required=5 tests=[AWL=-0.136, 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 aj1hdzaxc4Qr; Wed, 21 Mar 2012 11:09:26 -0700 (PDT)
Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1C16121F847E; Wed, 21 Mar 2012 11:09:25 -0700 (PDT)
Received: from mail101-db3-R.bigfish.com (10.3.81.238) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Wed, 21 Mar 2012 18:09:18 +0000
Received: from mail101-db3 (localhost [127.0.0.1])	by mail101-db3-R.bigfish.com (Postfix) with ESMTP id 91DC54A0357; Wed, 21 Mar 2012 18:09:17 +0000 (UTC)
X-SpamScore: -43
X-BigFish: PS-43(zz9371I1503M542M1432N98dK4015I1447Mzz1202h1082kzz1033IL8275bh8275dhz2fh2a8h668h839h944h)
X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT004.namprd07.prod.outlook.com; RD:none; EFVD:NLI
Received-SPF: pass (mail101-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=BL2PRD0710HT004.namprd07.prod.outlook.com ; .outlook.com ; 
Received: from mail101-db3 (localhost.localdomain [127.0.0.1]) by mail101-db3 (MessageSwitch) id 1332353355317821_29063; Wed, 21 Mar 2012 18:09:15 +0000 (UTC)
Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.238])	by mail101-db3.bigfish.com (Postfix) with ESMTP id 46568100049; Wed, 21 Mar 2012 18:09:15 +0000 (UTC)
Received: from BL2PRD0710HT004.namprd07.prod.outlook.com (157.56.240.133) by DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 21 Mar 2012 18:09:14 +0000
Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.100]) by BL2PRD0710HT004.namprd07.prod.outlook.com ([10.255.102.39]) with mapi id 14.16.0135.002; Wed, 21 Mar 2012 18:09:09 +0000
From: Stephan Wenger 
To: Barry Leiba 
Thread-Topic: [AVTCORE] IPR requirements in document write-up
Thread-Index: AQHNB4223QfN1LwTdkiObOrmg6aoSw==
Date: Wed, 21 Mar 2012 18:09:09 +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: "ipr@ietf.org" , IETF , "avt@ietf.org" , "payload@ietf.org" , "iesg@ietf.org" 
Subject: Re: [AVTCORE] IPR requirements in document write-up
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Mar 2012 18:09:27 -0000

Hi Barry,

Adding the IPRWG and ietf@ietf.

For the benefit if "new" readers: This is about an updated proto shepherd
writeup template, asking two questions about IPR that, IMO may not be in
compliance with the IETF's IPR policy.

I was not aware that the proto template had IESG blessing.  Still, I
believe that the template text does not ask the right question, or, more
specifically, is a suggestive question in that it appears (at least to me)
to interpret the IETF's patent policy in a considerably more strict way
than it is set out in the policy RFCs.
I believe the IESG should reconsider the proto writeup.
A few more comments inline

On 3.21.2012 17:03 , "Barry Leiba"  wrote:

>> Thanks for the text, I will use it.
>>
>> Roni
>
>I recommend you do not, for a few reasons:
>
>1. You may not rewrite the PROTO template; that belongs to the IESG.

Agreed (now that I'm aware of that this is an IESG-sanctioned template).

>2. The question was worded as it is for a reason, and it should be
>left that way.  The IESG wants to know whether there are any known IPR
>claims, whether declarations have been made to and considered by the
>working group, and whether formal IPR statements have been filed in
>the system.  The middle one is as important as the last.

Also agreed (with caveats, see below).

>
>3. Stephan is incorrect when he says this:
>> The reason is that disclosure is not
>> required in many cases; for example, when the IPR in question is not
>>owned
>> by them or their employers.
>
>If you are aware of IPR that you do not own, you may and you should
>make a third-party disclosure.

Barry, please read my language carefully.  Perhaps I should have
capitalized REQUIRED, but the text is clear and inline with yours.  It's
MAY and SHOULD for third party disclosures.  But you are NOT *required* to
do so by policy; there is no MUST.  There are many good and valid reasons
why there is no MUST (beyond that it's not in the policy docs).  And,
third party disclosures are not even a widely used current practice.  Just
look at the (comparatively low) number of third party disclosures.

Look, I do patent work as my day job.  I also do standards work  In my
current and previous job roles, I have looked at hundreds of patents of my
current or previous employers, as well as occasionally at third party
patents.  Now, with this background, let's look at the template text again
(numerals by me):

   (1) Are you aware of any IPR that applies to ?
(2) If so,
   has this IPR been disclosed in compliance with IETF IPR rules (see RFCs
3979,=20
   4879, 3669 and 5378 for more details)?


For the majority of the documents I am working on, the answer to question
(1) would be yes.  The answer to question (2) would be quite often no.

Based on my interpretation of the policy RFCs, I am in full compliance
with language and spirit of the policy.  I'm not doing anything fishy.  I
just don't talk about third party IPR, which is my right under the IETF's
IPR policy.  However, by providing answers to questions (1) and (2), the
IESG would receive a signal that it is not entitled to receive (more
precisely: that I'm not required to send, and not willing to send
voluntarily, as it could get me personally into trouble), namely that
there may be patents related to a document which the discloser is not
willing, AND not obligated, to talk about.

This is a policy change through the backdoor.  Policy changes through the
backdoor are bad.

My suggestion was aimed to bring the template in compliance with what I
believe is language and spirit of the policy.

Thanks,
Stephan



>
>You may, of course, ask the question of your working group in any way
>you like.  But I suggest you ask it in a way that allows you to
>accurately answer the question asked in the PROTO template.
>
>Barry, incoming Applications AD
>
>> -------- Original Message --------
>> From: Stephan Wenger [mailto:stewe@stewe.org]
>> Sent: Sunday, March 18, 2012 7:03 PM
>> To: Roni Even; 'IETF AVTCore WG'; payload@ietf.org
>> Cc: 'Magnus Westerlund'
>> Subject: Re: [AVTCORE] (no subject)
>>
>> Hi,
>>
>> There are many cases, where the answer to the first question is Yes, the
>> answer to the second question is No, and people would still be in
>>compliance
>> with the assorted policy RFCs.  The reason is that disclosure is not
>> required in many cases; for example, when the IPR in question is not
>>owned
>> by them or their employers.
>>
>>
>>
>> Suggest that the second question should be something like:
>>
>> "
>>
>> If so,
>>
>> has this IPR been disclosed when so required for in compliance with IETF
>> IPR rules (see RFCs
>>
>> 3979, 4879, 3669 and 5378 for more details)?
>>
>> "
>>
>>
>>
>> Stephan
>>
>>
>>
>> From: Roni Even 
>> Date: Sun, 18 Mar 2012 18:33:53 +0200
>> To: 'IETF AVTCore WG' , 
>> Cc: 'Magnus Westerlund' 
>> Subject: [AVTCORE] (no subject)
>>
>>
>>
>> Hi,
>>
>>
>>
>> The document write-up template for sending documents to publication has
>> changed.  In particular, we need to poll authors on their compliance
>>with
>> IETF IPR rules prior to moving a document to the publication in the WG
>> process. See http://www.ietf.org/iesg/template/doc-writeup.html
>>question 7.
>>
>>
>>
>> We plan to send the following email when a WG document goes to WG last
>> call.
>>
>>
>>
>>
>>
>>
>>
>> Please let us know if you have any comments on this plan.
>>
>>
>>
>> Roni Even
>>
>> AVTCore and Payload co-chair
>>
>>
>>
>> -----------------------------------------------------------------
>>
>>
>>
>> To: 
>>
>> Cc: AD; AVTcore/Payload WG
>>
>>
>>
>> Subject: Regarding IPR on 
>>
>>
>>
>> Are you aware of any IPR that applies to ? If so,
>>
>> has this IPR been disclosed in compliance with IETF IPR rules (see RFCs
>>
>> 3979, 4879, 3669 and 5378 for more details)?
>>
>>
>>
>> If you are listed as a document author or contributor please answer the
>>
>> above by responding to this email regardless of whether or not you are
>>
>> aware of any relevant IPR.  This document will not advance to the next
>>
>> stage until a response has been received from each author and listed
>>
>> contributor.
>>
>>
>>
>> If you are on the AVTcore/payload WG email list but are not listed as an
>> author or contributor, we remind you of your obligations under the IETF
>>IPR
>> rules which encourages you to notify the IETF if you are aware of IPR of
>> others on an IETF contribution, or to refrain from participating in any
>> contribution or discussion related to your undisclosed IPR.  For more
>> information, please see the RFCs listed above and
>>
>> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
>>
>>
>>
>>
>>
>> _______________________________________________ Audio/Video Transport
>>Core
>> Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt
>



From barryleiba@gmail.com  Wed Mar 21 09:03:08 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64E121E801A; Wed, 21 Mar 2012 09:03:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.99
X-Spam-Level: 
X-Spam-Status: No, score=-102.99 tagged_above=-999 required=5 tests=[AWL=-0.013, 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 fposVTJssx7O; Wed, 21 Mar 2012 09:03:05 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C6C0A21F85CF; Wed, 21 Mar 2012 09:03:04 -0700 (PDT)
Received: by ggmi1 with SMTP id i1so1193053ggm.31 for ; Wed, 21 Mar 2012 09:03:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ne/2CVIMcy4X9ovMfAf/9Y+Z3GBbdCCRG5aRC4d7XkU=; b=ex3q8lc19TevoW41zvwktVbkpnbKI+mluAg+Jx9HY6uOAhvPSyj/hHtCA25WtadJmB 4id62BhDzrNtBqgq7qDPaH4bqVRs5aJQ299oPsI1nwkDCJ7+fXlQck3ZJI3yEYKxiSkl W91e9ZN9x67dV01BrUKkOmCVAzYPk17Yrz5vzCNE+dMX2uRyBW5zO+q/TDSsgzK589Wa RAeWYr1YJcsi8aNBQgLvYW2ejd7P/DeL8xZb9Tqb83TaA/TkS5kwrJoQFHMZHKoewDLP 3P0kOiEsUKw4ycd8epAFAn3LoJZIhFizi5Dt8/INUjNi3rmyyea4Fgy5+J1nifTDrP8m UqXw==
MIME-Version: 1.0
Received: by 10.182.12.6 with SMTP id u6mr5531823obb.12.1332345784345; Wed, 21 Mar 2012 09:03:04 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.60.165.72 with HTTP; Wed, 21 Mar 2012 09:03:04 -0700 (PDT)
In-Reply-To: <4F68E88F.70009@nostrum.com>
References: <4f66677b.6265b40a.5afc.ffff8f1b@mx.google.com> <4F68E88F.70009@nostrum.com>
Date: Wed, 21 Mar 2012 12:03:04 -0400
X-Google-Sender-Auth: ywdnc-rUABhz9fGTTqT_yHEQ9D8
Message-ID: 
From: Barry Leiba 
To: Roni Even , Stephan Wenger 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 22 Mar 2012 12:58:09 -0700
Cc: Magnus Westerlund , avt@ietf.org, payload@ietf.org, iesg@ietf.org
Subject: Re: [AVTCORE] IPR requirements in document write-up
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Mar 2012 16:03:09 -0000

> Thanks for the text, I will use it.
>
> Roni

I recommend you do not, for a few reasons:

1. You may not rewrite the PROTO template; that belongs to the IESG.

2. The question was worded as it is for a reason, and it should be
left that way.  The IESG wants to know whether there are any known IPR
claims, whether declarations have been made to and considered by the
working group, and whether formal IPR statements have been filed in
the system.  The middle one is as important as the last.

3. Stephan is incorrect when he says this:
> The reason is that disclosure is not
> required in many cases; for example, when the IPR in question is not owne=
d
> by them or their employers.

If you are aware of IPR that you do not own, you may and you should
make a third-party disclosure.

You may, of course, ask the question of your working group in any way
you like.  But I suggest you ask it in a way that allows you to
accurately answer the question asked in the PROTO template.

Barry, incoming Applications AD

> -------- Original Message --------
> From: Stephan Wenger [mailto:stewe@stewe.org]
> Sent: Sunday, March 18, 2012 7:03 PM
> To: Roni Even; 'IETF AVTCore WG'; payload@ietf.org
> Cc: 'Magnus Westerlund'
> Subject: Re: [AVTCORE] (no subject)
>
> Hi,
>
> There are many cases, where the answer to the first question is Yes, the
> answer to the second question is No, and people would still be in complia=
nce
> with the assorted policy RFCs. =A0The reason is that disclosure is not
> required in many cases; for example, when the IPR in question is not owne=
d
> by them or their employers.
>
>
>
> Suggest that the second question should be something like:
>
> "
>
> If so,
>
> has this IPR been disclosed when so required for in compliance with IETF
> IPR rules (see RFCs
>
> 3979, 4879, 3669 and 5378 for more details)?
>
> "
>
>
>
> Stephan
>
>
>
> From: Roni Even 
> Date: Sun, 18 Mar 2012 18:33:53 +0200
> To: 'IETF AVTCore WG' , 
> Cc: 'Magnus Westerlund' 
> Subject: [AVTCORE] (no subject)
>
>
>
> Hi,
>
>
>
> The document write-up template for sending documents to publication has
> changed.=A0 In particular, we need to poll authors on their compliance wi=
th
> IETF IPR rules prior to moving a document to the publication in the WG
> process. See http://www.ietf.org/iesg/template/doc-writeup.html question =
7.
>
>
>
> We plan to send the following email when a WG document goes to WG last
> call.
>
>
>
>
>
>
>
> Please let us know if you have any comments on this plan.
>
>
>
> Roni Even
>
> AVTCore and Payload co-chair
>
>
>
> -----------------------------------------------------------------
>
>
>
> To: 
>
> Cc: AD; AVTcore/Payload WG
>
>
>
> Subject: Regarding IPR on 
>
>
>
> Are you aware of any IPR that applies to ? If so,
>
> has this IPR been disclosed in compliance with IETF IPR rules (see RFCs
>
> 3979, 4879, 3669 and 5378 for more details)?
>
>
>
> If you are listed as a document author or contributor please answer the
>
> above by responding to this email regardless of whether or not you are
>
> aware of any relevant IPR.=A0 This document will not advance to the next
>
> stage until a response has been received from each author and listed
>
> contributor.
>
>
>
> If you are on the AVTcore/payload WG email list but are not listed as an
> author or contributor, we remind you of your obligations under the IETF I=
PR
> rules which encourages you to notify the IETF if you are aware of IPR of
> others on an IETF contribution, or to refrain from participating in any
> contribution or discussion related to your undisclosed IPR.=A0 For more
> information, please see the RFCs listed above and
>
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
>
>
>
>
>
> _______________________________________________ Audio/Video Transport Cor=
e
> Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt

From simon@josefsson.org  Wed Mar 21 11:59:59 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B190821F8564; Wed, 21 Mar 2012 11:59:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.9
X-Spam-Level: 
X-Spam-Status: No, score=-102.9 tagged_above=-999 required=5 tests=[AWL=-0.991, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, 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 On8Y+BGwvQxg; Wed, 21 Mar 2012 11:59:59 -0700 (PDT)
Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id D34DD21F8555; Wed, 21 Mar 2012 11:59:57 -0700 (PDT)
Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q2LIxDpc006028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 21 Mar 2012 19:59:14 +0100
From: Simon Josefsson 
To: Stephan Wenger 
References:  
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:120321:stewe@stewe.org::Vzbh9oFczpoonGjO:JlV
X-Hashcash: 1:22:120321:iesg@ietf.org::1t4rL2u8gTq2lgYm:2+Gr
X-Hashcash: 1:22:120321:ipr@ietf.org::25ffxsWrf5VX2wtv:A4+6
X-Hashcash: 1:22:120321:barryleiba@computer.org::1OqKn1j+wkJ0m70i:G+/I
X-Hashcash: 1:22:120321:payload@ietf.org::e5Jf6SPh3OYwi0qT:ZhLs
X-Hashcash: 1:22:120321:avt@ietf.org::xxWzSK0ZStnqfbZt:qVwu
X-Hashcash: 1:22:120321:ietf@ietf.org::wz6szIOpPs/uFY/j:sE4R
Date: Wed, 21 Mar 2012 19:59:13 +0100
In-Reply-To:  (Stephan Wenger's message of "Wed, 21 Mar 2012 18:09:09 +0000")
Message-ID: <87wr6dye4e.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v
X-Virus-Status: Clean
X-Mailman-Approved-At: Thu, 22 Mar 2012 12:58:38 -0700
Cc: "ipr@ietf.org" , "avt@ietf.org" , "payload@ietf.org" , "iesg@ietf.org" , Barry Leiba , IETF 
Subject: Re: [AVTCORE] IPR requirements in document write-up
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Mar 2012 18:59:59 -0000

Stephan Wenger  writes:

>    (1) Are you aware of any IPR that applies to ?
> (2) If so,
>    has this IPR been disclosed in compliance with IETF IPR rules (see RFCs
> 3979, 
>    4879, 3669 and 5378 for more details)?
>
>
> For the majority of the documents I am working on, the answer to question
> (1) would be yes.  The answer to question (2) would be quite often no.
>
> Based on my interpretation of the policy RFCs, I am in full compliance
> with language and spirit of the policy.  I'm not doing anything fishy.  I
> just don't talk about third party IPR, which is my right under the IETF's
> IPR policy.

RFC 3669 section 5.7:

https://tools.ietf.org/html/rfc3669#section-5.7

says for example

   It is good to notify the IETF of relevant IPR claims even when they
   are not one's own, and [6] says to do so "as soon as possible".

My interpretation has always been that partcipants are strongly
encouraged to notify about third party patents.  Withholding such
information seems contrary to the spirit even if not the letter of the
guidelines.

There are additional advice given here:

https://tools.ietf.org/html/rfc3669#section-5.7.1

/Simon

From ron.even.tlv@gmail.com  Fri Mar 23 03:19:49 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5CB21F853A for ; Fri, 23 Mar 2012 03:19:49 -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 eHVsjf+XqI+W for ; Fri, 23 Mar 2012 03:19:47 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF8921F852D for ; Fri, 23 Mar 2012 03:19:46 -0700 (PDT)
Received: by werb10 with SMTP id b10so3030435wer.31 for ; Fri, 23 Mar 2012 03:19:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=WjZbhYRK5uXk7IcwcMAhmHEkYpxnSozuhq4Twpc9xhY=; b=ts1/qOEAhWYvIPJiVoFfaYmh3dZbnEHyOti4EtnMXAOyHUcG7Eszi5f3tgWFp5m78X d5Scv5xrPXjkXuLQgS1vMcU5pbRSXvriaOYmtXBQDn2XDvwaY3IKLzpJcaZ8AuLhCZZS nTWum7N5ZPzSTJ2vPBOkTlMRdcJcZm6S6s3AJ8lbKtsd4Iu4E3kEUamW6r2Lm2m8aGVX X+d/Vbl6AQcbHkPSpjsLRTCiD2t9yZlFky51F9Cp2AgOtHLvWhcVI9Pp8YD6NXNThJZi ytdZJb7vrcAF1k4JXUmIMe3KRzEAf+hd1TqpZAv2RomhGaNEbliCWgCYdloBexYpQu5R mKFg==
Received: by 10.216.132.222 with SMTP id o72mr6314334wei.95.1332497985512; Fri, 23 Mar 2012 03:19:45 -0700 (PDT)
Received: from windows8d787f9 (bzq-79-182-234-108.red.bezeqint.net. [79.182.234.108]) by mx.google.com with ESMTPS id n15sm12689382wiw.6.2012.03.23.03.19.43 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Mar 2012 03:19:44 -0700 (PDT)
From: "Roni Even" 
To: "'IETF AVTCore WG'" 
Date: Fri, 23 Mar 2012 12:18:38 +0200
Message-ID: <4f6c4e40.ef4cb40a.10f1.ffff96a3@mx.google.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_03FA_01CD08EF.15A14970"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac0I3k/xbPr+NhR+SLqfOw1tcyqNoA==
Content-Language: en-us
Subject: [AVTCORE] multi session and avtcore-multiplex-architecture
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Mar 2012 10:19:49 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_03FA_01CD08EF.15A14970
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

After reading draft-westerlund-avtcore-multiplex-architecture-01.txt and
draft-alvestrand-rtp-sess-neutral-00.txt and looking at RFC3550 my view is
that what we can say in terms of RFC3550 is that we have support for two
modes: 

1.	RTP multisession where each session has a unique SSRC space with no
defined support for SSRC multiplexing across RTP sessions. 
2.	RTP single session that can support SSRC multiplexing in the single
session.

RTP session multiplexing is only defined based on transport multiplexing
(UDP ports).

The SDP support is based on the above description defining the transport
address for RTP session and SSRC per RTP media inside the session.

Section 5.2 of RFC 3550 does not forbid SSRC multiplexing of different media
types but lists some problems.

I would like to concentrate on problems 4 and 5.

Problem 4 talks about the difficulty an RTP mixer will have when
encountering multiple media types in the same RTP session. I think that this
problem is also relevant when having same media types in the same session if
they do not have the same usage (for example video of the room and of a
presentation but each can have its own RTP session). 

 

Problem 5 talks about supporting different QoS or different bandwidth usage
and again I think that this is true also for same media type like different
SVC layers or different video content.

 

So my understanding of the current state (RFC 3550) is that both SSRC
multiplexing using a single session can be used for different media types
and multisession using the transport layer (UDP) as the multiplex to make it
simpler for mixers and for specific network topologies should be the
recommended solutions. We will need to document all the issues discussed in
the multiplex architecture draft in order to help implementers choose the
right solution and add the required SDP to support it.

As for multiplexing multiple sessions using one transport connection (One
UDP port), I am not sure what is the value with regards to problem 4 and 5
considering the current RTP and network infrastructure that will not benefit
from this mode. I can see some value in having this mode providing a better
RTP layer structure for RTP session and RTP SSRC multiplexing that is not
based on the transport but defined in the RTP level, but I am not sure if
this is a good enough reason unless people have a strong requirement to use
a single port in all cases without considering the whole solution aspects.
For example if you want to supply different SVC layers in different sessions
(MST mode) in order to address bandwidth issues it does not make sense to
multiplex them to a single UDP port considering the current infrastructure
will not handle it per flow or if you want the presentation video and room
video to be handles differently use the transport based session
multiplexing.

Roni Even


------=_NextPart_000_03FA_01CD08EF.15A14970
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi,
After reading =
draft-westerlund-avtcore-multiplex-architecture-01.txt and =
draft-alvestrand-rtp-sess-neutral-00.txt and looking at RFC3550 my view =
is that what we can say in terms of RFC3550 is that we have support for =
two modes: 
  1. RTP =
multisession where each session has a unique SSRC space with no defined =
support for SSRC multiplexing across RTP sessions. 
  2. RTP single session =
that can support SSRC multiplexing in the single =
session.
RTP session =
multiplexing is only defined based on transport multiplexing (UDP =
ports).
The SDP support is based on =
the above description defining the transport address for RTP session and =
SSRC per RTP media inside the session.
Section 5.2 of RFC 3550 does not forbid SSRC =
multiplexing of different media types but lists some =
problems.
I would like to concentrate =
on problems 4 and 5.
Problem 4 talks =
about the difficulty an RTP mixer will have when encountering multiple =
media types in the same RTP session. I think that this problem is also =
relevant when having same media types in the same session if they do not =
have the same usage (for example video of the room and of a presentation =
but each can have its own RTP session). 
 
Problem 5 =
talks about supporting different QoS or different bandwidth usage and =
again I think that this is true also for same media type like different =
SVC layers or different video content.
 
So my =
understanding of the current state (RFC 3550) is that both SSRC =
multiplexing using a single session can be used for different media =
types and multisession using the transport layer (UDP) as the multiplex =
to make it simpler for mixers and for specific network topologies should =
be the recommended solutions. We will need to document all the issues =
discussed in the multiplex architecture draft in order to help =
implementers choose the right solution and add the required SDP to =
support it.
As for multiplexing =
multiple sessions using one transport connection (One UDP port), I am =
not sure what is the value with regards to problem 4 and 5 considering =
the current RTP and network infrastructure that will not benefit from =
this mode. I can see some value in having this mode providing a better =
RTP layer structure for RTP session and RTP SSRC multiplexing that is =
not based on the transport but defined in the RTP level, but I am not =
sure if this is a good enough reason unless people have a strong =
requirement to use a single port in all cases without considering the =
whole solution aspects. For example if you want to supply different SVC =
layers in different sessions (MST mode) in order to address bandwidth =
issues it does not make sense to multiplex them to a single UDP port =
considering the current infrastructure will not handle it per flow or if =
you want the presentation video and room video to be handles differently =
use the transport based session multiplexing.
Roni Even

------=_NextPart_000_03FA_01CD08EF.15A14970--


From ron.even.tlv@gmail.com  Fri Mar 23 04:23:12 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B3521F856F for ; Fri, 23 Mar 2012 04:23:11 -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 bssaNYFAM5JD for ; Fri, 23 Mar 2012 04:23:10 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C52E921F852B for ; Fri, 23 Mar 2012 04:23:09 -0700 (PDT)
Received: by werb10 with SMTP id b10so3081651wer.31 for ; Fri, 23 Mar 2012 04:23:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=tQPgo8q4tclpywcZowY7atPCd3Tr4t0bx6NfsYuHk+I=; b=RXTSCxfF8LtuUIQ4IBKPr3OWyW+5ThabtNRr17Fnynls0G6LTRxOsYmy3ZAqzcui25 0iz+jJZubFiCKGNi5hdjTyowwhE9t3JuM/z/MbjcYjJ7mjwaAVerSP+ev2n5nVqBhRiO pKZQbVhKMyN6HTmuwaW7GTTk+jSEC0So/Gv1gn48K42F7PbD9wpjjjRzBXN9Ko3tJWAu 9yDaieZkyrxcXpmboDOLLBjb9Gilu+0DhX1M6RLg/nJU/5e+wDpom7XC9QwbfhSk2ncr 6GX9u+hh6Y4rqRU8fPYuu2/Hsk8i+vFF1AKlDHa1kjphimiS3rSHVXbOp1Woeegf5gWj ZYwg==
Received: by 10.180.83.72 with SMTP id o8mr5709044wiy.5.1332501788828; Fri, 23 Mar 2012 04:23:08 -0700 (PDT)
Received: from windows8d787f9 (bzq-79-182-234-108.red.bezeqint.net. [79.182.234.108]) by mx.google.com with ESMTPS id b3sm13086289wib.4.2012.03.23.04.23.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Mar 2012 04:23:08 -0700 (PDT)
From: "Roni Even" 
To: "'IETF AVTCore WG'" 
Date: Fri, 23 Mar 2012 13:22:01 +0200
Message-ID: <4f6c5d1c.6303b40a.047e.ffffa9b1@mx.google.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_040B_01CD08F7.F088E4A0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac0I5ynci2Oo3RVyRNecyXAvSZPCgw==
Content-Language: en-us
Subject: [AVTCORE] review of draft-westerlund-avtcore-transport-multiplexing-02
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Mar 2012 11:23:12 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_040B_01CD08F7.F088E4A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

I think that if we are going to have a multiplex multi session solution I
will support using the shim based solution.  On open issue 3 I think that
the fallback when bundled is supported and the application fails to support
the shim it should fall back to multi session (multiple ports) since if the
offerer wanted a single session he could have offered one and probably had
application reason for asking for multi session.

I have some comments and questions on the document

1.       In section 4.3 "Lacking different RTP sessions to demultiplex
incoming packets, a receiver will have to dig deeper into the packet before
determining what to do with it. " I am not sure what you mean here, the
receiver will need only to look at the SSRC which is simpler than looking at
the Shim based session ID.

2.       In section 4.3 when discussion the multi party case my view is that
most implementations use the RTP mixer model and have separate SSRC space to
each party so there is no problem from going from multi session to
multiplexed single session in this case in terms of extra overhead.

3.       In section 5.8 when you fail the single session for vanilla RTP
sessions, I am not sure what you mean by Vanilla RTP session but if it means
that multiplexing/translation is done without knowing the signaling than the
shim solution will also fail. I believe that you are talking about the case
where all parties use the same SSRC space in unicast based multi party with
centralized server in which case you are right that the server will need to
re-negotiate the SSRCs but for the Shim case it may also need to do it if
the session-id received from one of the parties is not the common one.

Roni Even

As individual

 


------=_NextPart_000_040B_01CD08F7.F088E4A0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi,
I think that if =
we are going to have a multiplex multi session solution I will support =
using the shim based solution.  On open issue 3 I think that the =
fallback when bundled is supported and the application fails to support =
the shim it should fall back to multi session (multiple ports) since if =
the offerer wanted a single session he could have offered one and =
probably had application reason for asking for multi =
session.
I have some comments and =
questions on the document
1.       =
In section =
4.3 “Lacking =
different RTP sessions to demultiplex incoming packets, a receiver will =
have to dig deeper into the packet before determining what to do with =
it. “ I am not sure what you mean here, the receiver will need =
only to look at the SSRC which is simpler than looking at the Shim based =
session ID.
2.       =
In section =
4.3 when discussion the multi party case my view is that most =
implementations use the RTP mixer model and have separate SSRC space to =
each party so there is no problem from going from multi session to =
multiplexed single session in this case in terms of extra =
overhead.
3.       =
In section =
5.8 when you fail the single session for vanilla RTP sessions, I am not =
sure what you mean by Vanilla RTP session but if it means that =
multiplexing/translation is done without knowing the signaling than the =
shim solution will also fail. I believe that you are talking about the =
case where all parties use the same SSRC space in unicast based multi =
party with centralized server in which case you are right that the =
server will need to re-negotiate the SSRCs but for the Shim case it may =
also need to do it if the session-id received from one of the parties is =
not the common one.
Roni =
Even
As =
individual
 

------=_NextPart_000_040B_01CD08F7.F088E4A0--


From dwing@cisco.com  Fri Mar 23 07:35:24 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E66221F8555 for ; Fri, 23 Mar 2012 07:35:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.395
X-Spam-Level: 
X-Spam-Status: No, score=-109.395 tagged_above=-999 required=5 tests=[AWL=1.204, 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 fenjq4k+dZoR for ; Fri, 23 Mar 2012 07:35:20 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3192821F8518 for ; Fri, 23 Mar 2012 07:35:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1643; q=dns/txt; s=iport; t=1332513320; x=1333722920; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=qdpiCpjR4D9Xy4Vm2yVCuBYdigWq7u7cv/fdOT/bkps=; b=AwY+D0T69HK94VqgdZXIC/3MfCbWpYC7QNWNtCjTpBiDsa5OZsZjXYkO 1I+ER3YrNcTGHnSUrfoi8OR8lDq7d5trajezfCtlUyxFxl9cyZhXjXA09 oAGUQTZJPUuXhEUbv2mbOWU4ZqkZR/P5xwQ+J/oQTqVfWu/6yJ+WUNkt3 k=;
X-IronPort-AV: E=Sophos;i="4.73,636,1325462400"; d="scan'208";a="37290917"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 23 Mar 2012 14:35:20 +0000
Received: from dwingWS ([10.32.240.196]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2NEZJ2A021994; Fri, 23 Mar 2012 14:35:19 GMT
From: "Dan Wing" 
To: "'IETF AVTCore WG'" 
References: <4F3E1F27.6020108@ericsson.com>  <7A5A3B36-FEAF-43D0-B66F-690468902622@cisco.com>
In-Reply-To: <7A5A3B36-FEAF-43D0-B66F-690468902622@cisco.com>
Date: Fri, 23 Mar 2012 07:35:19 -0700
Message-ID: <05ee01cd0902$2bfd2f50$83f78df0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac0HjI8GvFxwoVuyQ6ydwYchcWt4HABdCvbg
Content-Language: en-us
Cc: 'Flemming Andreasen' , 'Magnus Westerlund' 
Subject: Re: [AVTCORE] EKT with removable tags [Was: Re: Questions regarding EKT (draft-ietf-avt-srtp-ekt-03)]
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Mar 2012 14:35:24 -0000

AVTCORE,

I will summarize these EKT changes during my RTCWEB presentation at IETF83.


>From an RTCWEB perspective, this change to EKT means a media gateway can
provide interworking between DTLS-SRTP-EKT (on the RTCWEB leg) with Security
Descriptions (on the other leg), and the interworking involves no per-packet
cryptographic operations of the SRTP packets in either direction.

This change to EKT eliminates one of RTCWEB's barriers to adoption of
DTLS-SRTP.

-d


> -----Original Message-----
> From: David McGrew [mailto:mcgrew@cisco.com]
> Sent: Wednesday, March 21, 2012 11:01 AM
> To: Magnus Westerlund; IETF AVTCore WG; Roni Even
> Cc: Dan Wing; Flemming Andreasen
> Subject: EKT with removable tags [Was: Re: Questions regarding EKT
> (draft-ietf-avt-srtp-ekt-03)]
> 
> Hi AVTCore,
> 
> here is the follow-up to the questions on EKT.
> 
> The original EKT design used the SRTP authentication function to
> protect the authenticity of the EKT data, which allowed the design to
> make the size of the EKT data somewaht smaller.  However, this design
> requires a tight binding between EKT and SRTP, and this tight binding
> makes it impossible for the original design to be used in some new use
> cases, such as interoperability between EKT and non-EKT endpoints.
> Attached is a short note that describes a new loose-binding approach to
> EKT, which retains EKT's current capabilities while allowing it to
> accomodate some use cases that were unanticipated when it was first
> designed.
> 
> Comments welcome.  Apologies for the length of the note, but we wanted
> to be clear.
> 
> David



From magnus.westerlund@ericsson.com  Sat Mar 24 00:00:33 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA9221F8674 for ; Sat, 24 Mar 2012 00:00:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.388
X-Spam-Level: 
X-Spam-Status: No, score=-110.388 tagged_above=-999 required=5 tests=[AWL=0.211, 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 atfU5NgLSjlx for ; Sat, 24 Mar 2012 00:00:32 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2E34721F8673 for ; Sat, 24 Mar 2012 00:00:31 -0700 (PDT)
X-AuditID: c1b4fb39-b7bf2ae0000069a1-b4-4f6d710ed2a2
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 94.F8.27041.E017D6F4; Sat, 24 Mar 2012 08:00:30 +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.213.0; Sat, 24 Mar 2012 08:00:30 +0100
Message-ID: <4F6D710D.5070409@ericsson.com>
Date: Sat, 24 Mar 2012 08:00:29 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: Roni Even 
References: <4f6c4e40.ef4cb40a.10f1.ffff96a3@mx.google.com>
In-Reply-To: <4f6c4e40.ef4cb40a.10f1.ffff96a3@mx.google.com>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: 'IETF AVTCore WG' 
Subject: Re: [AVTCORE] multi session and avtcore-multiplex-architecture
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Mar 2012 07:00:33 -0000

Hi,
(as individual)

No significant disagreement about your first part of the message. The
arguments in RFC 3550 are not really applicable for certain set of
applications. The list of limitations in Section 6.7 of
draft-westerlund-avtcore-multiplex-architecture-01 does not contain a
big smoking gun. They do need to be considered by an application
implementor so they can consider if they matter. We also forgot to list
in 6.7 one of the biggest issues in my mind, namely interworking as
discussed in section 6.3.1.

The issue there is that if one has an RTP session that is common across
multiple end-points using a central node, like an RTP translator, or a
media gateway then connecting an end-point that uses two RTP sessions
for audio and video with one that has a single session for both medias
can force that gateway/translator to perform SSRC translation. Which if
we uses SRTP forces an decrypt and encrypt cycle at that node in
addition to performing that translation. This would for example be the
case for the WebRTC legacy interop.

Thus you need the possibility to fallback to using multiple RTP sessions
to handle such situations. If you can support multiple RTP sessions over
a single flow you can still have a single transport flow and support
multiple RTP sessions.

On 2012-03-23 11:18, Roni Even wrote:
> 
> As for multiplexing multiple sessions using one transport connection
> (One UDP port), I am not sure what is the value with regards to problem
> 4 and 5 considering the current RTP and network infrastructure that will
> not benefit from this mode. I can see some value in having this mode
> providing a better RTP layer structure for RTP session and RTP SSRC
> multiplexing that is not based on the transport but defined in the RTP
> level, but I am not sure if this is a good enough reason unless people
> have a strong requirement to use a single port in all cases without
> considering the whole solution aspects. For example if you want to
> supply different SVC layers in different sessions (MST mode) in order to
> address bandwidth issues it does not make sense to multiplex them to a
> single UDP port considering the current infrastructure will not handle
> it per flow or if you want the presentation video and room video to be
> handles differently use the transport based session multiplexing.

I agree that one needs to understand what ones limitations are. But
there are reasons for using multiple RTP sessions that aren't connected
to the need for transport level separation. For example our proposal for
how to simulcast with RTP and utilizing existing signaling we put
different quality tiers in different RTP sessions. Also as discussed
above if one want to avoid a forklift upgrade of clients in a
multi-party applications that already uses multiple RTP session like for
audio and video then implementing a multiplexing shim based solution in
the new version of the client and the central node lets you use only a
single transport flow for all upgraded clients without changing any of
the logic and processing in clients and central node.

What I think is important to remember in this discussion is to not only
think about the applications oneself has. RTP is widely used and just
because oneself doesn't need a feature, there can be others that do need
it.

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 eckelcu@cisco.com  Sat Mar 24 02:21:28 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CA821F86F7 for ; Sat, 24 Mar 2012 02:21:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.391
X-Spam-Level: 
X-Spam-Status: No, score=-9.391 tagged_above=-999 required=5 tests=[AWL=1.208,  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 IAcLr8p5SG9r for ; Sat, 24 Mar 2012 02:21:28 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3793821F86EB for ; Sat, 24 Mar 2012 02:21:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=4996; q=dns/txt; s=iport; t=1332580888; x=1333790488; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ODlynPUhdr4NsMa1S6kowJOGnoydQyE60mjv8JYh0Ac=; b=OvpZIHqa5M8+RRDeCU2+Nr0wBLgCeaAWRBqcyA7g/1vI7rwadEJbSHH+ hWzmyqutAADrOiIBDiQyl2/Sq8dLcJKNg+6s0igdE/2vizrrFJDo1zEUw XJVYAVPOIgjonGosI3dsxoG7q2iQ8Z+N35vIohBzm0/8w5PpGu9TUu3Zm k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAOeRbU+rRDoJ/2dsb2JhbABEuCCBB4IJAQEBAwEBAQEJBgEdSQwCAgIBCBEBAwEBAQoGFwEGARoMHwMGCAEBBAESCBMHh2MEAQuZSp5iBASKboVTYwSIJDObToFogweBNg
X-IronPort-AV: E=Sophos;i="4.73,640,1325462400"; d="scan'208";a="37402695"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 24 Mar 2012 09:21:25 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2O9LO6O009869; Sat, 24 Mar 2012 09:21:24 GMT
Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Sat, 24 Mar 2012 02:21:24 -0700
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 24 Mar 2012 02:21:22 -0700
Message-ID: 
In-Reply-To: <4F6D710D.5070409@ericsson.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [AVTCORE] multi session and avtcore-multiplex-architecture
Thread-Index: Ac0Ji9JorSQfznyRT3W7EUIUQO4N0wAEff4A
References: <4f6c4e40.ef4cb40a.10f1.ffff96a3@mx.google.com> <4F6D710D.5070409@ericsson.com>
From: "Charles Eckel (eckelcu)" 
To: "Magnus Westerlund" , "Roni Even" 
X-OriginalArrivalTime: 24 Mar 2012 09:21:24.0873 (UTC) FILETIME=[7C047790:01CD099F]
Cc: IETF AVTCore WG 
Subject: Re: [AVTCORE] multi session and avtcore-multiplex-architecture
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Mar 2012 09:21:29 -0000

Hi Magnus,

Please see question inline.

> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of
> Magnus Westerlund
> Sent: Saturday, March 24, 2012 8:00 AM
> To: Roni Even
> Cc: 'IETF AVTCore WG'
> Subject: Re: [AVTCORE] multi session and =
avtcore-multiplex-architecture
>=20
> Hi,
> (as individual)
>=20
> No significant disagreement about your first part of the message. The
> arguments in RFC 3550 are not really applicable for certain set of
> applications. The list of limitations in Section 6.7 of
> draft-westerlund-avtcore-multiplex-architecture-01 does not contain a
> big smoking gun. They do need to be considered by an application
> implementor so they can consider if they matter. We also forgot to =
list
> in 6.7 one of the biggest issues in my mind, namely interworking as
> discussed in section 6.3.1.
>=20
> The issue there is that if one has an RTP session that is common =
across
> multiple end-points using a central node, like an RTP translator, or a
> media gateway then connecting an end-point that uses two RTP sessions
> for audio and video with one that has a single session for both medias
> can force that gateway/translator to perform SSRC translation. Which =
if
> we uses SRTP forces an decrypt and encrypt cycle at that node in
> addition to performing that translation. This would for example be the
> case for the WebRTC legacy interop.
>=20
> Thus you need the possibility to fallback to using multiple RTP
> sessions
> to handle such situations. If you can support multiple RTP sessions
> over
> a single flow you can still have a single transport flow and support
> multiple RTP sessions.

Instead, could you not have the RTP translator indicate that there is an =
SSRC collision toward the endpoint that is using two RTP sessions? =
Perhaps the problem is that the endpoint might be implemented such that =
it always wants to use the same SSRC across both RTP sessions, and thus =
it handles the "collision" by changing the SSRC for both RTP sessions to =
be a new problematically shared value.

Cheers,
Charles

>=20
> On 2012-03-23 11:18, Roni Even wrote:
> >
> > As for multiplexing multiple sessions using one transport connection
> > (One UDP port), I am not sure what is the value with regards to
> problem
> > 4 and 5 considering the current RTP and network infrastructure that
> will
> > not benefit from this mode. I can see some value in having this mode
> > providing a better RTP layer structure for RTP session and RTP SSRC
> > multiplexing that is not based on the transport but defined in the
> RTP
> > level, but I am not sure if this is a good enough reason unless
> people
> > have a strong requirement to use a single port in all cases without
> > considering the whole solution aspects. For example if you want to
> > supply different SVC layers in different sessions (MST mode) in =
order
> to
> > address bandwidth issues it does not make sense to multiplex them to
> a
> > single UDP port considering the current infrastructure will not
> handle
> > it per flow or if you want the presentation video and room video to
> be
> > handles differently use the transport based session multiplexing.
>=20
> I agree that one needs to understand what ones limitations are. But
> there are reasons for using multiple RTP sessions that aren't =
connected
> to the need for transport level separation. For example our proposal
> for
> how to simulcast with RTP and utilizing existing signaling we put
> different quality tiers in different RTP sessions. Also as discussed
> above if one want to avoid a forklift upgrade of clients in a
> multi-party applications that already uses multiple RTP session like
> for
> audio and video then implementing a multiplexing shim based solution =
in
> the new version of the client and the central node lets you use only a
> single transport flow for all upgraded clients without changing any of
> the logic and processing in clients and central node.
>=20
> What I think is important to remember in this discussion is to not =
only
> think about the applications oneself has. RTP is widely used and just
> because oneself doesn't need a feature, there can be others that do
> need
> it.
>=20
> Cheers
>=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
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

From ron.even.tlv@gmail.com  Sat Mar 24 13:38:39 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB6B21F8484 for ; Sat, 24 Mar 2012 13:38:39 -0700 (PDT)
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 Ypmhw2RccUP5 for ; Sat, 24 Mar 2012 13:38:38 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8F33721F8483 for ; Sat, 24 Mar 2012 13:38:38 -0700 (PDT)
Received: by pbbrq13 with SMTP id rq13so4118610pbb.31 for ; Sat, 24 Mar 2012 13:38:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :content-language:thread-index; bh=ANFGJ0kZWccWAVa5uCiShTHQyKfbjiJdtzSfUHUtAr8=; b=KZaqR6b78yN20S08araOuTLImm1g7IyPmIX340/mr1Ept8NZQ1CoR93RueO7SSRXCx yarK2iZWxLtrZ4Z5MUd35t65SUwBkFYSrQy1iBwr1y+fzbLp8lTh6KzXW7KnBYEsHf/E zK7JQGoAlt701mjNPXA5A6iwgPmPFw7XQsTyvTn91+TGZulv+UKp6PksFhj5UwaVkBOX Yw2hjup6+JnbGd0MH9YDVg2bxVrPgwL9yFA14SkKWdJ2N0arQ4YuHvpHC9NuAjRaPy2h KKoTYINtTg8PECEg4tRsXpQfBXMQa+RVETEgQLFFNwfyKgdlXg5B1/yi9qVF8RYrR0aj W2Mg==
Received: by 10.68.229.73 with SMTP id so9mr39781868pbc.163.1332621518289; Sat, 24 Mar 2012 13:38:38 -0700 (PDT)
Received: from windows8d787f9 (dhcp-4432.meeting.ietf.org. [130.129.68.50]) by mx.google.com with ESMTPS id o2sm8732252pbd.6.2012.03.24.13.38.22 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 24 Mar 2012 13:38:36 -0700 (PDT)
From: "Roni Even" 
To: "'Magnus Westerlund'" 
References: <4f6c4e40.ef4cb40a.10f1.ffff96a3@mx.google.com> <4F6D710D.5070409@ericsson.com>
In-Reply-To: <4F6D710D.5070409@ericsson.com>
Date: Sat, 24 Mar 2012 22:37:18 +0200
Message-ID: <4f6e30cc.8211440a.047c.5748@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Content-language: en-us
Thread-Index: Ac0Ji822DD6sFoZuR0uqtOrnuEhsqAAcSuXw
Cc: 'IETF AVTCore WG' 
Subject: Re: [AVTCORE] multi session and avtcore-multiplex-architecture
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Mar 2012 20:38:39 -0000

Hi Magnus,
I agree that for a signaling + media gateway it will be simpler to =
handle
the data for the Shim if it is out of the security context.
You need the signaling gateway to translate the SDP if multiple RTP =
session
using multiple source to multiple RTP sessions using one port.=20

Roni

> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> Sent: Saturday, March 24, 2012 9:00 AM
> To: Roni Even
> Cc: 'IETF AVTCore WG'
> Subject: Re: [AVTCORE] multi session and =
avtcore-multiplex-architecture
>=20
> Hi,
> (as individual)
>=20
> No significant disagreement about your first part of the message. The
> arguments in RFC 3550 are not really applicable for certain set of
> applications. The list of limitations in Section 6.7 of
> draft-westerlund-avtcore-multiplex-architecture-01 does not contain a
> big smoking gun. They do need to be considered by an application
> implementor so they can consider if they matter. We also forgot to =
list
> in 6.7 one of the biggest issues in my mind, namely interworking as
> discussed in section 6.3.1.
>=20
> The issue there is that if one has an RTP session that is common =
across
> multiple end-points using a central node, like an RTP translator, or a
> media gateway then connecting an end-point that uses two RTP sessions
> for audio and video with one that has a single session for both medias
> can force that gateway/translator to perform SSRC translation. Which =
if
> we uses SRTP forces an decrypt and encrypt cycle at that node in
> addition to performing that translation. This would for example be the
> case for the WebRTC legacy interop.
>=20
> Thus you need the possibility to fallback to using multiple RTP
> sessions to handle such situations. If you can support multiple RTP
> sessions over a single flow you can still have a single transport flow
> and support multiple RTP sessions.
>=20
> On 2012-03-23 11:18, Roni Even wrote:
> >
> > As for multiplexing multiple sessions using one transport connection
> > (One UDP port), I am not sure what is the value with regards to
> > problem
> > 4 and 5 considering the current RTP and network infrastructure that
> > will not benefit from this mode. I can see some value in having this
> > mode providing a better RTP layer structure for RTP session and RTP
> > SSRC multiplexing that is not based on the transport but defined in
> > the RTP level, but I am not sure if this is a good enough reason
> > unless people have a strong requirement to use a single port in all
> > cases without considering the whole solution aspects. For example if
> > you want to supply different SVC layers in different sessions (MST
> > mode) in order to address bandwidth issues it does not make sense to
> > multiplex them to a single UDP port considering the current
> > infrastructure will not handle it per flow or if you want the
> > presentation video and room video to be handles differently use the
> transport based session multiplexing.
>=20
> I agree that one needs to understand what ones limitations are. But
> there are reasons for using multiple RTP sessions that aren't =
connected
> to the need for transport level separation. For example our proposal
> for how to simulcast with RTP and utilizing existing signaling we put
> different quality tiers in different RTP sessions. Also as discussed
> above if one want to avoid a forklift upgrade of clients in a multi-
> party applications that already uses multiple RTP session like for
> audio and video then implementing a multiplexing shim based solution =
in
> the new version of the client and the central node lets you use only a
> single transport flow for all upgraded clients without changing any of
> the logic and processing in clients and central node.
>=20
> What I think is important to remember in this discussion is to not =
only
> think about the applications oneself has. RTP is widely used and just
> because oneself doesn't need a feature, there can be others that do
> need it.
>=20
> Cheers
>=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
> ----------------------------------------------------------------------


From ron.even.tlv@gmail.com  Mon Mar 26 01:51:45 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C2021F85CE for ; Mon, 26 Mar 2012 01:51:45 -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 Z2vTIYO98vbf for ; Mon, 26 Mar 2012 01:51:44 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id F0B9C21F85CD for ; Mon, 26 Mar 2012 01:51:43 -0700 (PDT)
Received: by ggmi1 with SMTP id i1so4003098ggm.31 for ; Mon, 26 Mar 2012 01:51:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=jqPnxm+cZbMUBRF5/OdKRdWf5REu1SHp4JAmR4BTGOg=; b=Fsj3YXhPVWqkTqUhGo6tO5YvoK5qCgYrVWJ0QrifQcp0sLSFA8f0JO2F0HDRI0hqB6 s5DaMsnuLKSAJH7CJS+82A0B5DEQ4AwhB+gTcL2gBH/tiqCgna8VDWAGm8gwuWruE327 uD5utSB56xm5qQsP7gu66ZA7a+8jQZrbQB1m8zq3gdZThWK/3CLQftci2/eUKfwEv5FY m/VsuvH3ngK5OR6RNyMFbDOCrf3C1oQ9rpDRHE8DWFHj1twaMhi01r51v4Jq/igxojhp cUxkuTwx2dd1Wu8wgX869H9+82jj6rqFayNTKHJDlVhtMtVZZ4TBPOwqxlz7r9t9sm5Y BUqw==
Received: by 10.68.130.163 with SMTP id of3mr51189290pbb.85.1332751902962; Mon, 26 Mar 2012 01:51:42 -0700 (PDT)
Received: from windows8d787f9 (dhcp-17b3.meeting.ietf.org. [130.129.23.179]) by mx.google.com with ESMTPS id u10sm12059939pbf.37.2012.03.26.01.51.40 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Mar 2012 01:51:42 -0700 (PDT)
From: "Roni Even" 
To: "'IETF AVTCore WG'" 
Date: Mon, 26 Mar 2012 10:50:35 +0200
Message-ID: <4f702e1e.8a18440a.6431.1976@mx.google.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0064_01CD0B3E.48B12820"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac0LLYKk2+KDjvUmRfWZwrR/vlKjgw==
Content-Language: en-us
Subject: [AVTCORE] Agenda change for today session
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Mar 2012 08:51:45 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0064_01CD0B3E.48B12820
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

We did a small change moving the mprtp presentation after the break. This is
since this document was not discussed in the previous meeting due to time
constrains.

We still think that we will be able to finish the whole agenda this time
since we still have some slack time.

 

This is the updated agenda

 

 

Monday, 26 March 2012 at 13:00-16:10 (252B)

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

13:00   AVTCore Status Update                               (Chairs, 15)

 

13:15   Why RTP Sessions Should Be Content Neutral(Harald Alvestrand , 15)

        draft-alvestrand-rtp-sess-neutral-00

 

13:30   RTP Multiplexing Architecture           (Magnus Westerlund , 20)

        draft-westerlund-avtcore-multiplex-architecture-01

 

13:50   Multiple RTP Session on a Single Lower-Layer Transport(Magnus
Westerlund , 35)

        draft-westerlund-avtcore-transport-multiplexing-02

 

14:25   RTP Congestion Control: Circuit Breakers for Unicast Sessions(Colin
Perkins , 15)

        draft-perkins-avtcore-rtp-circuit-breakers-00

 

14:40   RTP Topology Considerations for Offer/Answer-Initiated
Sessions(Jonathan Lennox, 20)

        draft-lennox-avtcore-rtp-topo-offer-answer-00

 

15:00   Break (if needed)                                         (, 10)

 

15:10   Multipath RTP                                  (Varun Singh, 10)

        draft-singh-avtcore-mprtp-04

 

15:20   RTP Clock Source Signalling                 (Aidan Williams, 10)

        draft-williams-avtcore-clksrc-00

 

15:30   RTCP for inter-destination media synchronization(Ray van
Brandenburg, 10)

        draft-ietf-avtcore-idms-03

 

15:40   Duplicating RTP Streams                              (Begen, 10)

        draft-begen-avtcore-rtp-duplication-01

 

15:50   End

 

 

 

 

 

Roni Even

AVTcore co-chair


------=_NextPart_000_0064_01CD0B3E.48B12820
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi,
We did a small =
change moving the mprtp presentation after the break. This is since this =
document was not discussed in the previous meeting due to time =
constrains.
We still think that we =
will be able to finish the whole agenda this time since we still have =
some slack time.
 
This is the =
updated agenda
 
 
Monday, 26 =
March 2012 at 13:00-16:10 (252B)
-------------------------------------------<=
/p>
13:00   AVTCore Status =
Update           &=
nbsp;           &n=
bsp;       (Chairs, 15)
 
13:15   Why RTP Sessions Should Be Content =
Neutral(Harald Alvestrand , 15)
        =
draft-alvestrand-rtp-sess-neutral-00
 
13:30   RTP Multiplexing =
Architecture           =
(Magnus Westerlund , 20)
        =
draft-westerlund-avtcore-multiplex-architecture-01
 
13:50   Multiple RTP Session on a Single =
Lower-Layer Transport(Magnus Westerlund , 35)
        =
draft-westerlund-avtcore-transport-multiplexing-02
 
14:25   RTP Congestion Control: Circuit =
Breakers for Unicast Sessions(Colin Perkins , 15)
        =
draft-perkins-avtcore-rtp-circuit-breakers-00
 
14:40   RTP Topology Considerations for =
Offer/Answer-Initiated Sessions(Jonathan Lennox, 20)
        =
draft-lennox-avtcore-rtp-topo-offer-answer-00
 
15:00   Break (if =
needed)           =
            &=
nbsp;           &n=
bsp;     (, 10)
 
15:10   Multipath =
RTP           &nbs=
p;            =
;          (Varun Singh, =
10)
        =
draft-singh-avtcore-mprtp-04
 
15:20   RTP Clock Source =
Signalling          &nb=
sp;      (Aidan Williams, 10)
        =
draft-williams-avtcore-clksrc-00
 
15:30   RTCP for inter-destination media =
synchronization(Ray van Brandenburg, 10)
        =
draft-ietf-avtcore-idms-03
 
15:40   Duplicating RTP =
Streams           =
            &=
nbsp;      (Begen, 10)
        =
draft-begen-avtcore-rtp-duplication-01
 
15:50   End
 
 
 
 
 
Roni =
Even
AVTcore =
co-chair

------=_NextPart_000_0064_01CD0B3E.48B12820--


From thomas.schierl@hhi.fraunhofer.de  Tue Mar 27 01:26:52 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C2121F88A9 for ; Tue, 27 Mar 2012 01:26:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.8
X-Spam-Level: 
X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 g6NE10ojffEx for ; Tue, 27 Mar 2012 01:26:45 -0700 (PDT)
Received: from mailgw.hhi.fraunhofer.de (mail.HHI.FRAUNHOFER.DE [193.174.67.45]) by ietfa.amsl.com (Postfix) with ESMTP id E800C21F88A6 for ; Tue, 27 Mar 2012 01:26:44 -0700 (PDT)
X-IMSS-DKIM-Authentication-Result: mailgw.hhi.fraunhofer.de; sigcount=0
Received: from [130.129.21.86] (dhcp-1556.meeting.ietf.org [130.129.21.86]) by mailgw.hhi.fraunhofer.de (Postfix) with ESMTP id DF85B1868015; Tue, 27 Mar 2012 10:26:42 +0200 (CEST)
Message-ID: <4F7179C3.70302@hhi.fraunhofer.de>
Date: Tue, 27 Mar 2012 10:26:43 +0200
From: Thomas Schierl 
Organization: Fraunhofer-Institut fuer Nachrichtentechnik Heinrich-Hertz-Institut
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: avt@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060406010407090704010902"
X-alterMIME: Yes
Subject: Re: [AVTCORE] New Version Notification for draft-singh-avtcore-mprtp-04.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Mar 2012 08:26:52 -0000

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

Dear all,

I support this draft to become a working group document. I think it is 
definitely of interest having today's availability of multiple 
interfaces in mind. Therefore it makes sense to start exploring the 
field of using multiple RTP connections in an experimental document.

Thomas
--
Fraunhofer HHI


On 27.02.2012 11:37, Varun Singh wrote:
> Hi,
>
> We have submitted an updated draft for Multipath RTP (MPRTP) and would
> like the WG to review the draft and provide feedback.
> The exact changes are:
> https://tools.ietf.org/rfcdiff?url2=draft-singh-avtcore-mprtp-04.txt
>
> The main changes are:
> 1. Advertising MPRTP interfaces can be done in RTCP or using SDP. Both
> extensions are in the draft.
> 2. MPRTP multiplexes RTP and RTCP on a single port.
> 3. If an endpoint wants to do NAT traversal then it should use ICE
> procedures and the Section 11 covers how it could be done. However,
> using ICE is optional. So session can be setup using ICE and without
> ICE (Examples for session setup are in Section 11.6).
> 4. Using MPRTP with RTSP 2.0
>
> There are still some open issues, mainly related to advertising
> interfaces in RTCP (in-band) and in SDP (out-of-band). In some
> situations advertising in RTCP is less complex, especially, if the
> interfaces were already offered as ICE candidates and connectivity
> checks were successful.
>
> Security considerations for sending interface advertisements in RTCP
> (without ICE) are still pending and will be covered in the coming
> iterations.
>
> Cheers,
> Varun
>
>
> Begin forwarded message:
>> A new version of I-D, draft-singh-avtcore-mprtp-04.txt has been successfully submitted by Varun Singh and posted to the IETF repository.
>>
>> Filename:      draft-singh-avtcore-mprtp
>> Revision:      04
>> Title:                 Multipath RTP (MPRTP)
>> Creation date:         2012-02-27
>> WG ID:                 Individual Submission
>> Number of pages: 49
>>
>> Abstract:
>>    The Real-time Transport Protocol (RTP) is used to deliver real-time
>>    content and, along with the RTP Control Protocol (RTCP), forms the
>>    control channel between the sender and receiver.  However, RTP and
>>    RTCP assume a single delivery path between the sender and receiver
>>    and make decisions based on the measured characteristics of this
>>    single path.  Increasingly, endpoints are becoming multi-homed, which
>>    means that they are connected via multiple Internet paths.  Network
>>    utilization can be improved when endpoints use multiple parallel
>>    paths for communication.  The resulting increase in reliability and
>>    throughput can also enhance the user experience.  This document
>>    extends the Real-time Transport Protocol (RTP) so that a single
>>    session can take advantage of the availability of multiple paths
>>    between two endpoints.
>>
>>
>>
>>
>> The IETF Secretariat
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>

--------------------
visit us at

FOE 2012
April 11-13 / Tokyo Big Sight, Japan / German Pavilion Booth No. 26-31 

NAB Show 2012
April 16-19 / Las Vegas, USA / Booth C8444

www.hhi.fraunhofer.de/events
--------------060406010407090704010902
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Dear all,

      

      I support this draft to become a working group document. I think
      it is definitely of interest having today's availability of
      multiple interfaces in mind. Therefore it makes sense to start
      exploring the field of using multiple RTP connections in an
      experimental document.

      

      Thomas

      --

      Fraunhofer HHI

    
    

      
      


      

    

    

    On 27.02.2012 11:37, Varun Singh wrote:
    

      
Hi,

We have submitted an updated draft for Multipath RTP (MPRTP) and would
like the WG to review the draft and provide feedback.
The exact changes are:
https://tools.ietf.org/rfcdiff?url2=draft-singh-avtcore-mprtp-04.txt

The main changes are:
1. Advertising MPRTP interfaces can be done in RTCP or using SDP. Both
extensions are in the draft.
2. MPRTP multiplexes RTP and RTCP on a single port.
3. If an endpoint wants to do NAT traversal then it should use ICE
procedures and the Section 11 covers how it could be done. However,
using ICE is optional. So session can be setup using ICE and without
ICE (Examples for session setup are in Section 11.6).
4. Using MPRTP with RTSP 2.0

There are still some open issues, mainly related to advertising
interfaces in RTCP (in-band) and in SDP (out-of-band). In some
situations advertising in RTCP is less complex, especially, if the
interfaces were already offered as ICE candidates and connectivity
checks were successful.

Security considerations for sending interface advertisements in RTCP
(without ICE) are still pending and will be covered in the coming
iterations.

Cheers,
Varun


Begin forwarded message:


      

        
A new version of I-D, draft-singh-avtcore-mprtp-04.txt has been successfully submitted by Varun Singh and posted to the IETF repository.

Filename:      draft-singh-avtcore-mprtp
Revision:      04
Title:                 Multipath RTP (MPRTP)
Creation date:         2012-02-27
WG ID:                 Individual Submission
Number of pages: 49

Abstract:
  The Real-time Transport Protocol (RTP) is used to deliver real-time
  content and, along with the RTP Control Protocol (RTCP), forms the
  control channel between the sender and receiver.  However, RTP and
  RTCP assume a single delivery path between the sender and receiver
  and make decisions based on the measured characteristics of this
  single path.  Increasingly, endpoints are becoming multi-homed, which
  means that they are connected via multiple Internet paths.  Network
  utilization can be improved when endpoints use multiple parallel
  paths for communication.  The resulting increase in reliability and
  throughput can also enhance the user experience.  This document
  extends the Real-time Transport Protocol (RTP) so that a single
  session can take advantage of the availability of multiple paths
  between two endpoints.




The IETF Secretariat


      

      
_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt



    

  



-----
visit us at

FOE 2012
April 11-13 / Tokyo Big Sight, Japan / German Pavilion Booth No. 26-31


NAB Show 2012
April 16-19 / Las Vegas, USA / Booth C8444

www.hhi.fraunhofer.de/events







--------------060406010407090704010902--


From abegen@cisco.com  Tue Mar 27 01:44:34 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD5521F88C6 for ; Tue, 27 Mar 2012 01:44:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.455
X-Spam-Level: 
X-Spam-Status: No, score=-10.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 fiyG6TDdqKUk for ; Tue, 27 Mar 2012 01:44:33 -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 8F00B21F87EF for ; Tue, 27 Mar 2012 01:44:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=3782; q=dns/txt; s=iport; t=1332837873; x=1334047473; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=P2WfP/NQfeSmgIrZTZhS15grpujI21E1w3ymyF2C//s=; b=grgvIdtbKvX6n0JzVgG99Ff7tLviyyEepajg5VaIsbV76dgbE/1c8MmN IjGNzhix66ta3IyQpO1NFHizQjDolonTRqbpRLnuRphUtMZwbMqlMzH9z bCCHw3Un2cGNF1czus02SSwiV9TlNRSDK/bVPkvReFz+rv3aQCyYZyQGg U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAId9cU+tJV2Z/2dsb2JhbABFuEiBB4IJAQEBBAEBAQ8BNi4OBAIBCBEEAQEBCh0HJwsUCQgCBAESCBqHaAuaNZ8VkCxjBKQmgWiCZw
X-IronPort-AV: E=Sophos;i="4.73,656,1325462400"; d="scan'208";a="69679641"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 27 Mar 2012 08:44:33 +0000
Received: from xht-rcd-x02-p.cisco.com (xht-rcd-x02-p.cisco.com [173.37.178.213]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2R8iXXW011497;  Tue, 27 Mar 2012 08:44:33 GMT
Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.120]) by xht-rcd-x02-p.cisco.com ([173.37.178.213]) with mapi id 14.02.0283.003; Tue, 27 Mar 2012 01:44:32 -0700
From: "Ali C. Begen (abegen)" 
To: Thomas Schierl , "avt@ietf.org" 
Thread-Topic: [AVTCORE] New Version Notification for draft-singh-avtcore-mprtp-04.txt
Thread-Index: AQHM9TvUkyyUSQq4G0qs1bPQytrLSpZ+cY+A//+Pm1A=
Date: Tue, 27 Mar 2012 08:44:32 +0000
Message-ID: 
References:  <4F7179C3.70302@hhi.fraunhofer.de>
In-Reply-To: <4F7179C3.70302@hhi.fraunhofer.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [173.37.178.200]
x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18800.005
x-tm-as-result: No--43.131400-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [AVTCORE] New Version Notification for	draft-singh-avtcore-mprtp-04.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Mar 2012 08:44:34 -0000

+1

> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Tho=
mas Schierl
> Sent: Tuesday, March 27, 2012 10:27 AM
> To: avt@ietf.org
> Subject: Re: [AVTCORE] New Version Notification for draft-singh-avtcore-m=
prtp-04.txt
>=20
> Dear all,
>=20
> I support this draft to become a working group document. I think it is de=
finitely of interest having today's availability of
> multiple interfaces in mind. Therefore it makes sense to start exploring =
the field of using multiple RTP connections in an
> experimental document.
>=20
> Thomas
> --
> Fraunhofer HHI
>=20
>=20
>=20
> On 27.02.2012 11:37, Varun Singh wrote:
>=20
> 	Hi,
>=20
> 	We have submitted an updated draft for Multipath RTP (MPRTP) and would
> 	like the WG to review the draft and provide feedback.
> 	The exact changes are:
> 	https://tools.ietf.org/rfcdiff?url2=3Ddraft-singh-avtcore-mprtp-04.txt
>=20
> 	The main changes are:
> 	1. Advertising MPRTP interfaces can be done in RTCP or using SDP. Both
> 	extensions are in the draft.
> 	2. MPRTP multiplexes RTP and RTCP on a single port.
> 	3. If an endpoint wants to do NAT traversal then it should use ICE
> 	procedures and the Section 11 covers how it could be done. However,
> 	using ICE is optional. So session can be setup using ICE and without
> 	ICE (Examples for session setup are in Section 11.6).
> 	4. Using MPRTP with RTSP 2.0
>=20
> 	There are still some open issues, mainly related to advertising
> 	interfaces in RTCP (in-band) and in SDP (out-of-band). In some
> 	situations advertising in RTCP is less complex, especially, if the
> 	interfaces were already offered as ICE candidates and connectivity
> 	checks were successful.
>=20
> 	Security considerations for sending interface advertisements in RTCP
> 	(without ICE) are still pending and will be covered in the coming
> 	iterations.
>=20
> 	Cheers,
> 	Varun
>=20
>=20
> 	Begin forwarded message:
>=20
> 		A new version of I-D, draft-singh-avtcore-mprtp-04.txt has been success=
fully submitted by Varun Singh and
> posted to the IETF repository.
>=20
> 		Filename:      draft-singh-avtcore-mprtp
> 		Revision:      04
> 		Title:                 Multipath RTP (MPRTP)
> 		Creation date:         2012-02-27
> 		WG ID:                 Individual Submission
> 		Number of pages: 49
>=20
> 		Abstract:
> 		  The Real-time Transport Protocol (RTP) is used to deliver real-time
> 		  content and, along with the RTP Control Protocol (RTCP), forms the
> 		  control channel between the sender and receiver.  However, RTP and
> 		  RTCP assume a single delivery path between the sender and receiver
> 		  and make decisions based on the measured characteristics of this
> 		  single path.  Increasingly, endpoints are becoming multi-homed, which
> 		  means that they are connected via multiple Internet paths.  Network
> 		  utilization can be improved when endpoints use multiple parallel
> 		  paths for communication.  The resulting increase in reliability and
> 		  throughput can also enhance the user experience.  This document
> 		  extends the Real-time Transport Protocol (RTP) so that a single
> 		  session can take advantage of the availability of multiple paths
> 		  between two endpoints.
>=20
>=20
>=20
>=20
> 		The IETF Secretariat
>=20
> 	_______________________________________________
> 	Audio/Video Transport Core Maintenance
> 	avt@ietf.org
> 	https://www.ietf.org/mailman/listinfo/avt
>=20
>=20
>=20
> -----
> visit us at
>=20
> FOE 2012
> April 11-13 / Tokyo Big Sight, Japan / German Pavilion Booth No. 26-31
>=20
>=20
> NAB Show 2012
> April 16-19 / Las Vegas, USA / Booth C8444
>=20
> www.hhi.fraunhofer.de/events


From ron.even.tlv@gmail.com  Tue Mar 27 09:47:22 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C0F21F85EF for ; Tue, 27 Mar 2012 09:47: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=[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 LWR4l3WfYJCV for ; Tue, 27 Mar 2012 09:47:21 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1916121F85A8 for ; Tue, 27 Mar 2012 09:47:20 -0700 (PDT)
Received: by werb10 with SMTP id b10so76790wer.31 for ; Tue, 27 Mar 2012 09:47:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=Y5a5GDNNvIKIRbyLfGFzz0pU/MypF0fNTDVYfEIp14k=; b=DKJvfgJluDgLd4T9NN6FnNB9Rl6eO/oZf9HumBKbLy0VvbKEBTLRtAj+OxLJ17SHNI KBQh4qu+mhTWDpZja4dc4pOg/gcLPB7/Dt3iMeh0dPUSZSGRvHpG1uMaWMsFtLaPpUAB H0ADEZSj8KE9eM2iumUHieYC1j/3QN0B5d7OfZFNvA/fV+knlvYwjFOATkHevm/kMDk1 O5ILYWuxDhk5dHVvKsIwhMv+nnpSvFtBKQJ6BPbk4gNvE6VOMcxQdGYXkLsBbnODLWb2 iFH5aCs4d/UqbJMeRzBHy3xqFceFvRH1fezPkXVwUfIaBPv5o5Chng5F1tjUTV0097a6 MZ6w==
Received: by 10.180.78.225 with SMTP id e1mr29079405wix.0.1332866840310; Tue, 27 Mar 2012 09:47:20 -0700 (PDT)
Received: from windows8d787f9 (dhcp-4733.meeting.ietf.org. [130.129.71.51]) by mx.google.com with ESMTPS id l5sm50662819wia.11.2012.03.27.09.47.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 09:47:19 -0700 (PDT)
From: "Roni Even" 
To: "'IETF AVTCore WG'" 
Date: Tue, 27 Mar 2012 18:46:14 +0200
Message-ID: <4f71ef17.c507b40a.6cb0.ffff8c94@mx.google.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01CD0C49.E3B33190"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac0MOR8krdK/Q9DGTqSjn5mhiZT5AQ==
Content-Language: en-us
Subject: [AVTCORE] Summary of RTP multiplexing discussion in AVTcore
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Mar 2012 16:47:22 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_001D_01CD0C49.E3B33190
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

As the WG co-chair I would like to try to summarize what I consider as the
consensus to go forward.

 

My understanding from the meeting was that we had a rough consensus that
addresses what is required to do in AVTcore. The decision had two parts:

 

1.  Have a document that will update RFC 3550 with regards to multiplexing
different media types (section 5.2) explaining when it can be used and what
are the issues.

2.  In parallel, we will continue with the individual submission of
multiplexing multiple RTP sessions over a single transport flow (The Shim
approach is looking like the preferred method).

 

My understanding as the WG co-chair of the discussion is that there is  no
issue with having more than one way to multiplex RTP streams/sessions since
we currently have more than one mode. (Session multiplexing and SSRC
multiplexing; there were some people who preferred one solution but this
approach is following previous WG decision).

 

The issue of how to negotiate an agreed mode between the single session and
multisession over a single transport flow is discussed in MMUSIC in the
Bundle draft and in  draft-westerlund-avtcore-transport-multiplexing in the
signaling section. This interoperability topic should be discussed in MMUSIC
and maybe added to the bundle draft which leaves this option open (see
section 1 of bundle).

The WG chairs are asking for additional views from the people not present in
the meeting and people who did not have a chance to provide their view. (we
are not barring others to respond)


Roni Even

AVTcore co-chair

 


------=_NextPart_000_001D_01CD0C49.E3B33190
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi,
As the WG =
co-chair I would like to try to summarize what I consider as the =
consensus to go forward.
 
My =
understanding from the meeting was that we had a rough consensus that =
addresses what is required to do in AVTcore. The decision had two =
parts:
 
1.  Have a document that will update RFC 3550 =
with regards to multiplexing different media types (section 5.2) =
explaining when it can be used and what are the issues.
2.  In parallel, we will continue with the =
individual submission of multiplexing multiple RTP sessions over a =
single transport flow (The Shim approach is looking like the preferred =
method).
 
My understanding as the WG co-chair of the discussion =
is that there is  no issue with having more than one way to =
multiplex RTP streams/sessions since we currently have more than one =
mode. (Session multiplexing and SSRC multiplexing; there were some =
people who preferred one solution but this approach is following =
previous WG decision).
 
The issue of how to negotiate an agreed =
mode between the single session and multisession over a single transport =
flow is discussed in MMUSIC in the Bundle draft and in  =
draft-westerlund-avtcore-transport-multiplexing in the signaling =
section. This interoperability topic should be discussed in MMUSIC and =
maybe added to the bundle draft which leaves this option open (see =
section 1 of bundle).
The WG =
chairs are asking for =
additional views from the people not present in the meeting and people =
who did not have a chance to provide their view. (we are not barring =
others to respond)

Roni =
Even
AVTcore =
co-chair
 

------=_NextPart_000_001D_01CD0C49.E3B33190--


From magnus.westerlund@ericsson.com  Thu Mar 29 04:25:49 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342B721F8812 for ; Thu, 29 Mar 2012 04:25:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.132
X-Spam-Level: 
X-Spam-Status: No, score=-108.132 tagged_above=-999 required=5 tests=[AWL=-1.883, 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 0WGth--pXg0Q for ; Thu, 29 Mar 2012 04:25:47 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 913E121F880C for ; Thu, 29 Mar 2012 04:25:47 -0700 (PDT)
X-AuditID: c1b4fb2d-b7b76ae0000063d8-bc-4f7446bab9d6
Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0184"; auth=fail (cipher=AES128-SHA)
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0184", Issuer "esessmw0184" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id DC.52.25560.AB6447F4; Thu, 29 Mar 2012 13:25:46 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Thu, 29 Mar 2012 13:25:45 +0200
Message-ID: <4F7446B8.4060509@ericsson.com>
Date: Thu, 29 Mar 2012 13:25:44 +0200
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: IETF AVTCore WG 
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Subject: [AVTCORE] Adopting new work on RTP Congestion Circuit Breakers
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Mar 2012 11:25:49 -0000

WG,

At the IETF 83 there was a presentation in the AVTCORE and also in the
ICCRG of "RTP Congestion Control: Circuit Breakers for Unicast Sessions"

https://datatracker.ietf.org/doc/draft-perkins-avtcore-rtp-circuit-breakers/

This was well received and there was support for adopting this as WG
item. Thus I would like to confirm on the mailing list that we should
adopt a WG item that works on providing RTP congestion control circuit
breakers for unicast transport flows.

WG, please comment if you support or disagree of such adaptation. The WG
chairs will call a consensus after Friday the 13th.

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 magnus.westerlund@ericsson.com  Thu Mar 29 04:30:55 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D4C21F886E for ; Thu, 29 Mar 2012 04:30:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.284
X-Spam-Level: 
X-Spam-Status: No, score=-110.284 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=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 SkB3ozPAP0k6 for ; Thu, 29 Mar 2012 04:30:54 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1825921F882D for ; Thu, 29 Mar 2012 04:30:53 -0700 (PDT)
X-AuditID: c1b4fb3d-b7b5aae000002dcb-aa-4f7447ed0d6a
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 45.13.11723.DE7447F4; Thu, 29 Mar 2012 13:30:53 +0200 (CEST)
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.213.0; Thu, 29 Mar 2012 13:30:52 +0200
Message-ID: <4F7447EB.4000304@ericsson.com>
Date: Thu, 29 Mar 2012 13:30:51 +0200
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: IETF AVTCore WG 
X-Enigmail-Version: 1.4
Content-Type: multipart/alternative; boundary="------------020005070905010703020807"
X-Brightmail-Tracker: AAAAAA==
Subject: [AVTCORE] Milestone update for AVTCORE WG
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Mar 2012 11:30:55 -0000

--------------020005070905010703020807
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit

WG,

There are updated milestone dates for our still open  WG Items and we
have also created three new milestones. These will shortly be published
on our charter page.

•          Current milestones:

–        Apr 2012 - Submit Monitoring Architecture for RTP for
Informational 

–        Apr 2012 - Submit Encryption of Header Extensions in the Secure
Real-Time Transport Protocol (SRTP) for Proposed Standard

–        Oct 2012 - Submit in band keying mechanism for SRTP draft for
Proposed Standard

–        Nov 2012 - Submit Specification for Inter-destination Media
Playout Synchronization in RTP to IESG for publication as Proposed Standard

–        Dec 2012 - Submit Real-Time Transport Control Protocol (RTCP)
in Overlay Multicast for Proposed Standard

•          New Milestones:

–        Oct 2012 Submit an Overview of RTP Security Solutions as
Informational.

–        Nov 2012 Submit RTP Clock Source Signaling as Proposed Standard

–        Dec 2012 – Submit SRTP Cryptographic Transform(s) on the ARIA
algorithm and corresponding key-management profiles for Security
Descriptions, MIKEY and DTLS-SRTP for publication as proposed standard

 
Cheers

Magnus Westerlund


--------------020005070905010703020807
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit


  
    
    
    
  
  
    
WG,

          

          There are updated milestone dates for our still open  WG Items
          and we have also created three new milestones. These will
          shortly be published on our charter page. 

          

         •          Current milestones:
      
–        Apr 2012 - Submit Monitoring Architecture for
        RTP for Informational  

      
–        Apr 2012 - Submit Encryption of Header
        Extensions in the Secure Real-Time Transport Protocol (SRTP) for
        Proposed Standard 

      
–        Oct 2012 - Submit in band keying mechanism
        for SRTP draft for Proposed Standard

      
–        Nov 2012 - Submit Specification for
        Inter-destination Media Playout Synchronization in RTP to IESG
        for publication as Proposed Standard

      
–        Dec 2012 - Submit Real-Time Transport Control
        Protocol (RTCP) in Overlay Multicast for Proposed Standard 

      
•          New Milestones:

      
–        Oct 2012 Submit an Overview of RTP Security
        Solutions as Informational.

      
–        Nov 2012 Submit RTP Clock Source Signaling as
        Proposed Standard

      
–        Dec 2012 – Submit SRTP Cryptographic
        Transform(s) on the ARIA algorithm and corresponding
        key-management profiles for Security Descriptions, MIKEY and
        DTLS-SRTP for publication as proposed standard

      
 

          Cheers

        

      
Magnus Westerlund

        

    

  


--------------020005070905010703020807--

From abegen@cisco.com  Thu Mar 29 04:31:22 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A77621F882D for ; Thu, 29 Mar 2012 04:31:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.464
X-Spam-Level: 
X-Spam-Status: No, score=-10.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 9q0g2nz9m+VB for ; Thu, 29 Mar 2012 04:31:21 -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 57EAA21F886E for ; Thu, 29 Mar 2012 04:31:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=1628; q=dns/txt; s=iport; t=1333020681; x=1334230281; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=iikaMtV3p4+sUC8MjE7rvDxgTcjcPkBFL3h9WHDpggk=; b=Qry1dt0EqxhxJ9srpODcQdwwBLaZx4loW4sRmYtk7fIO8Wc9+EILI70d Uo0r6HElhlcbNXC4Hn/PSiD6uoIEW7JUPywD7KqH30cvKoKeguaQD/SEt 0zGtlPljFnrG4+kxvwNrnyPIo22WbcrRtfyec5wOXamlK6R4vmP8pkGrh o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EABpHdE+tJXG9/2dsb2JhbABEuQ+BB4IJAQEBBAEBAQkGAVsXAgICAQgRBAEBCx0HGwwLFAkIAgQBEggah2gLm1+fHQQEkDhjBKQmgWiCZw
X-IronPort-AV: E=Sophos;i="4.73,667,1325462400"; d="scan'208";a="70410707"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 29 Mar 2012 11:31:20 +0000
Received: from xht-rcd-x02-p.cisco.com (xht-rcd-x02-p.cisco.com [173.37.178.213]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2TBVJwA017078;  Thu, 29 Mar 2012 11:31:19 GMT
Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.120]) by xht-rcd-x02-p.cisco.com ([173.37.178.213]) with mapi id 14.02.0283.003; Thu, 29 Mar 2012 04:31:19 -0700
From: "Ali C. Begen (abegen)" 
To: Magnus Westerlund , IETF AVTCore WG 
Thread-Topic: [AVTCORE] Adopting new work on RTP Congestion Circuit Breakers
Thread-Index: AQHNDZ61Pjjr/LFNsEuz/poqCOo4jZaBI3nA
Date: Thu, 29 Mar 2012 11:31:19 +0000
Message-ID: 
References: <4F7446B8.4060509@ericsson.com>
In-Reply-To: <4F7446B8.4060509@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [173.37.178.200]
x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18804.006
x-tm-as-result: No--35.013900-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [AVTCORE] Adopting new work on RTP Congestion Circuit Breakers
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Mar 2012 11:31:22 -0000

I support adoption.

-acbegen

> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Mag=
nus Westerlund
> Sent: Thursday, March 29, 2012 1:26 PM
> To: IETF AVTCore WG
> Subject: [AVTCORE] Adopting new work on RTP Congestion Circuit Breakers
>=20
> WG,
>=20
> At the IETF 83 there was a presentation in the AVTCORE and also in the
> ICCRG of "RTP Congestion Control: Circuit Breakers for Unicast Sessions"
>=20
> https://datatracker.ietf.org/doc/draft-perkins-avtcore-rtp-circuit-breake=
rs/
>=20
> This was well received and there was support for adopting this as WG
> item. Thus I would like to confirm on the mailing list that we should
> adopt a WG item that works on providing RTP congestion control circuit
> breakers for unicast transport flows.
>=20
> WG, please comment if you support or disagree of such adaptation. The WG
> chairs will call a consensus after Friday the 13th.
>=20
> Cheers
>=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
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

From jmpolk@cisco.com  Thu Mar 29 17:53:27 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68B321F866D for ; Thu, 29 Mar 2012 17:53:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.431
X-Spam-Level: 
X-Spam-Status: No, score=-109.431 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 X4DxpWdiNgEC for ; Thu, 29 Mar 2012 17:53:26 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id D9FC621F8668 for ; Thu, 29 Mar 2012 17:53:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1598; q=dns/txt; s=iport; t=1333068806; x=1334278406; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version:content-transfer-encoding; bh=V4giVBsQmUVZ0XP9YmhkScSHYv+UiPihgfj+ZKQ12O4=; b=LxqFyRtNBXB+jhupZsxwACDb6XJc3rVg9dmvIhbfTWYmUorKRk6RXJme zCPlYA6zBYzJVb4T0G+sPqDsER1DL48Ldiu/ZNJ/51xQ1MiDtkKgH3ht2 rNmzYnbdJasoQr5ei+4gEHkIUI59NSKpXiWmcmC6pP7Z2RWQdlC+Ffs7e I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EANwCdU+rRDoI/2dsb2JhbABEuRqBB4IJAQEBBAEBAQkGASU2Cw4CBwQYJwcZAgwfEQYTIodnDJt7nyEEBJAmYwSIJTObT4FogwU
X-IronPort-AV: E=Sophos;i="4.75,339,1330905600"; d="scan'208";a="35184789"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 30 Mar 2012 00:53:26 +0000
Received: from jmpolk-wxp01.cisco.com (tky-vpn-client-230-184.cisco.com [10.70.230.184]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2U0rDLD005261; Fri, 30 Mar 2012 00:53:15 GMT
Message-Id: <201203300053.q2U0rDLD005261@mtv-core-3.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 29 Mar 2012 19:53:09 -0500
To: Magnus Westerlund 
From: "James M. Polk" 
In-Reply-To: <4F7446B8.4060509@ericsson.com>
References: <4F7446B8.4060509@ericsson.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: IETF AVTCore WG 
Subject: Re: [AVTCORE] Adopting new work on RTP Congestion Circuit Breakers
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Mar 2012 00:53:27 -0000

While I generally think this draft is=20
interesting, even the author admits it's awfully=20
drafty at this point (both in AVTCORE and=20
TSV-Dir). And I think perhaps too much so in this=20
version. In other words, I'd like to see more meat on them bones.

James

At 06:25 AM 3/29/2012, Magnus Westerlund wrote:
>WG,
>
>At the IETF 83 there was a presentation in the AVTCORE and also in the
>ICCRG of "RTP Congestion Control: Circuit Breakers for Unicast Sessions"
>
>https://datatracker.ietf.org/doc/draft-perkins-avtcore-rtp-circuit-breakers=
/
>
>This was well received and there was support for adopting this as WG
>item. Thus I would like to confirm on the mailing list that we should
>adopt a WG item that works on providing RTP congestion control circuit
>breakers for unicast transport flows.
>
>WG, please comment if you support or disagree of such adaptation. The WG
>chairs will call a consensus after Friday the 13th.
>
>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
>----------------------------------------------------------------------
>
>_______________________________________________
>Audio/Video Transport Core Maintenance
>avt@ietf.org
>https://www.ietf.org/mailman/listinfo/avt


From bill.wu@huawei.com  Thu Mar 29 22:59:52 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5801321F86D5 for ; Thu, 29 Mar 2012 22:59:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.537
X-Spam-Level: 
X-Spam-Status: No, score=0.537 tagged_above=-999 required=5 tests=[AWL=2.684,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 LCL-Eq6h5pr9 for ; Thu, 29 Mar 2012 22:59:51 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C26FE21F85E3 for ; Thu, 29 Mar 2012 22:59:51 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEU84487; Fri, 30 Mar 2012 01:59:51 -0400 (EDT)
Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 22:56:52 -0700
Received: from SZXEML432-HUB.china.huawei.com (10.72.61.60) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 22:56:12 -0700
Received: from SZXEML523-MBS.china.huawei.com ([169.254.6.188]) by SZXEML432-HUB.china.huawei.com ([10.72.61.60]) with mapi id 14.01.0323.003; Fri, 30 Mar 2012 13:56:55 +0800
From: Qin Wu 
To: Magnus Westerlund , IETF AVTCore WG 
Thread-Topic: [AVTCORE] Adopting new work on RTP Congestion Circuit Breakers
Thread-Index: AQHNDZ9ogcLy0ZiYeEuAY8N7TybbHpaCVu2Q
Date: Fri, 30 Mar 2012 05:56:55 +0000
Message-ID: 
References: <4F7446B8.4060509@ericsson.com>
In-Reply-To: <4F7446B8.4060509@ericsson.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.139.29]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [AVTCORE] =?utf-8?b?562U5aSNOiAgQWRvcHRpbmcgbmV3IHdvcmsgb24gUlRQ?= =?utf-8?q?_Congestion_Circuit_Breakers?=
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Mar 2012 05:59:52 -0000

SSBoYXZlIHJlYWQgZHJhZnQgYW5kIGFtIGluIGZhdm9yIG9mIGdldHRpbmcgdGhpcyBkcmFmdCBh
ZG9wdGlvbi4NCg0KUmVnYXJkcyENCi1RaW4NCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7
tuS6ujogYXZ0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzphdnQtYm91bmNlc0BpZXRmLm9yZ10g
5Luj6KGoIE1hZ251cyBXZXN0ZXJsdW5kDQrlj5HpgIHml7bpl7Q6IDIwMTLlubQz5pyIMjnml6Ug
MTM6MjYNCuaUtuS7tuS6ujogSUVURiBBVlRDb3JlIFdHDQrkuLvpopg6IFtBVlRDT1JFXSBBZG9w
dGluZyBuZXcgd29yayBvbiBSVFAgQ29uZ2VzdGlvbiBDaXJjdWl0IEJyZWFrZXJzDQoNCldHLA0K
DQpBdCB0aGUgSUVURiA4MyB0aGVyZSB3YXMgYSBwcmVzZW50YXRpb24gaW4gdGhlIEFWVENPUkUg
YW5kIGFsc28gaW4gdGhlDQpJQ0NSRyBvZiAiUlRQIENvbmdlc3Rpb24gQ29udHJvbDogQ2lyY3Vp
dCBCcmVha2VycyBmb3IgVW5pY2FzdCBTZXNzaW9ucyINCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5p
ZXRmLm9yZy9kb2MvZHJhZnQtcGVya2lucy1hdnRjb3JlLXJ0cC1jaXJjdWl0LWJyZWFrZXJzLw0K
DQpUaGlzIHdhcyB3ZWxsIHJlY2VpdmVkIGFuZCB0aGVyZSB3YXMgc3VwcG9ydCBmb3IgYWRvcHRp
bmcgdGhpcyBhcyBXRw0KaXRlbS4gVGh1cyBJIHdvdWxkIGxpa2UgdG8gY29uZmlybSBvbiB0aGUg
bWFpbGluZyBsaXN0IHRoYXQgd2Ugc2hvdWxkDQphZG9wdCBhIFdHIGl0ZW0gdGhhdCB3b3JrcyBv
biBwcm92aWRpbmcgUlRQIGNvbmdlc3Rpb24gY29udHJvbCBjaXJjdWl0DQpicmVha2VycyBmb3Ig
dW5pY2FzdCB0cmFuc3BvcnQgZmxvd3MuDQoNCldHLCBwbGVhc2UgY29tbWVudCBpZiB5b3Ugc3Vw
cG9ydCBvciBkaXNhZ3JlZSBvZiBzdWNoIGFkYXB0YXRpb24uIFRoZSBXRw0KY2hhaXJzIHdpbGwg
Y2FsbCBhIGNvbnNlbnN1cyBhZnRlciBGcmlkYXkgdGhlIDEzdGguDQoNCkNoZWVycw0KDQpNYWdu
dXMgV2VzdGVybHVuZA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpNdWx0aW1lZGlhIFRlY2hub2xvZ2llcywg
RXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RWTQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRXJpY3Nzb24gQUIgICAg
ICAgICAgICAgICAgfCBQaG9uZSAgKzQ2IDEwIDcxNDgyODcNCkbDpHLDtmdhdGFuIDYgICAgICAg
ICAgICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5NDkwNzkNClNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3
ZWRlbnwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCi0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkF1
ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQphdnRAaWV0Zi5vcmcNCmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQo=

From internet-drafts@ietf.org  Fri Mar 30 02:29:03 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB3321F88AE; Fri, 30 Mar 2012 02:29:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.378
X-Spam-Level: 
X-Spam-Status: No, score=-102.378 tagged_above=-999 required=5 tests=[AWL=0.221, 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 guN8i08vBRsC; Fri, 30 Mar 2012 02:29:02 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD1121F879E; Fri, 30 Mar 2012 02:29:02 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120330092902.25081.99206.idtracker@ietfa.amsl.com>
Date: Fri, 30 Mar 2012 02:29:02 -0700
Cc: avt@ietf.org
Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-feedback-supression-rtp-16.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Mar 2012 09:29:03 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Audio/Video Transport Core Maintenanc=
e Working Group of the IETF.

	Title           : RTCP Extension for Third-party Loss Report
	Author(s)       : Qin Wu
                          Frank Xia
                          Roni Even
	Filename        : draft-ietf-avtcore-feedback-supression-rtp-16.txt
	Pages           : 19
	Date            : 2012-03-30

   In a large RTP session using the RTCP feedback mechanism defined in
   RFC 4585, a feedback target may experience transient overload if some
   event causes a large number of receivers to send feedback at once.
   This overload is usually avoided by ensuring that feedback reports
   are forwarded to all receivers, allowing them to avoid sending
   duplicate feedback reports.  However, there are cases where it is not
   recommended to forward feedback reports, and this may allow feedback
   implosion.  This memo discusses these cases and defines a new RTCP
   third-party loss report that can be used to inform receivers that the
   feedback target is aware of some loss event, allowing them to
   suppress feedback.  Associated SDP signalling is also defined.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-=
rtp-16.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-r=
tp-16.txt


From internet-drafts@ietf.org  Fri Mar 30 02:40:38 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D84A21F8934; Fri, 30 Mar 2012 02:40:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.336
X-Spam-Level: 
X-Spam-Status: No, score=-102.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 QwLejvuJkVQ4; Fri, 30 Mar 2012 02:40:37 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8198F21F88A8; Fri, 30 Mar 2012 02:40:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120330094037.29163.45542.idtracker@ietfa.amsl.com>
Date: Fri, 30 Mar 2012 02:40:37 -0700
Cc: avt@ietf.org
Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-ecn-for-rtp-07.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Mar 2012 09:40:38 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Audio/Video Transport Core Maintenanc=
e Working Group of the IETF.

	Title           : Explicit Congestion Notification (ECN) for RTP over UDP
	Author(s)       : Magnus Westerlund
                          Ingemar Johansson
                          Colin Perkins
                          Piers O'Hanlon
                          Ken Carlberg
	Filename        : draft-ietf-avtcore-ecn-for-rtp-07.txt
	Pages           : 56
	Date            : 2012-03-30

   This memo specifies how Explicit Congestion Notification (ECN) can be
   used with the Real-time Transport Protocol (RTP) running over UDP,
   using RTP Control Protocol (RTCP) as a feedback mechanism.  It
   defines a new RTCP Extended Report (XR) block for periodic ECN
   feedback, a new RTCP transport feedback message for timely reporting
   of congestion events, and a Session Traversal Utilities for NAT
   (STUN) extension used in the optional initialization method using
   Interactive Connectivity Establishment (ICE).  Signalling and
   procedures for negotiation of capabilities and initialization methods
   are also defined.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avtcore-ecn-for-rtp-07.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-ecn-for-rtp-07.txt


From csp@csperkins.org  Fri Mar 30 02:43:36 2012
Return-Path: 
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A1D21F8874 for ; Fri, 30 Mar 2012 02:43:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.901
X-Spam-Level: 
X-Spam-Status: No, score=-102.901 tagged_above=-999 required=5 tests=[AWL=0.698, 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 bUkhUAkDAi9R for ; Fri, 30 Mar 2012 02:43:36 -0700 (PDT)
Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by ietfa.amsl.com (Postfix) with ESMTP id 23D5621F8873 for ; Fri, 30 Mar 2012 02:43:36 -0700 (PDT)
Received: from dhcp-20d9.meeting.ietf.org ([130.129.32.217]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1SDYMo-0002m3-ZP for avt@ietf.org; Fri, 30 Mar 2012 09:43:35 +0000
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1257)
From: Colin Perkins 
In-Reply-To: <20120330094037.29163.45542.idtracker@ietfa.amsl.com>
Date: Fri, 30 Mar 2012 11:43:34 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1A1DABE6-9A8F-4CC5-8B49-8A7C1DDE07BB@csperkins.org>
References: <20120330094037.29163.45542.idtracker@ietfa.amsl.com>
To: "avt@ietf.org WG" 
X-Mailer: Apple Mail (2.1257)
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-ecn-for-rtp-07.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Mar 2012 09:43:37 -0000

On 30 Mar 2012, at 11:40, 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 Audio/Video Transport Core =
Maintenance Working Group of the IETF.
>=20
> 	Title           : Explicit Congestion Notification (ECN) for RTP =
over UDP
> 	Author(s)       : Magnus Westerlund
>                          Ingemar Johansson
>                          Colin Perkins
>                          Piers O'Hanlon
>                          Ken Carlberg
> 	Filename        : draft-ietf-avtcore-ecn-for-rtp-07.txt
> 	Pages           : 56
> 	Date            : 2012-03-30
>=20
>   This memo specifies how Explicit Congestion Notification (ECN) can =
be
>   used with the Real-time Transport Protocol (RTP) running over UDP,
>   using RTP Control Protocol (RTCP) as a feedback mechanism.  It
>   defines a new RTCP Extended Report (XR) block for periodic ECN
>   feedback, a new RTCP transport feedback message for timely reporting
>   of congestion events, and a Session Traversal Utilities for NAT
>   (STUN) extension used in the optional initialization method using
>   Interactive Connectivity Establishment (ICE).  Signalling and
>   procedures for negotiation of capabilities and initialization =
methods
>   are also defined.
>=20
>=20
> A URL for this Internet-Draft is:
> =
http://www.ietf.org/internet-drafts/draft-ietf-avtcore-ecn-for-rtp-07.txt


This version addresses comments from the AD and IANA reviews:

- Clarify the name of the STUN attribute (ECN-CHECK) per IANA comments
- Remove reference to RTP no-op
- Fix Block Length in Section 5.2
- Clarify handling of counter wraps in Section 5.1
- Clarify "other reactions" in Section 7.3.3
- Make reference to RFC4566 normative
- Fix editorial nits

--=20
Colin Perkins
http://csperkins.org/