From Simo.Veikkolainen@nokia.com Tue Nov 1 00:16:26 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC9A11E80DB for ; Tue, 1 Nov 2011 00:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 fby8SvQuPEfV for ; Tue, 1 Nov 2011 00:16:24 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8B111E8103 for ; Tue, 1 Nov 2011 00:16:15 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pA17FtW0018485; Tue, 1 Nov 2011 09:16:00 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Nov 2011 09:15:40 +0200 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 1 Nov 2011 08:15:39 +0100 Received: from 008-AM1MPN1-025.mgdnok.nokia.com ([169.254.5.38]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0339.002; Tue, 1 Nov 2011 08:15:38 +0100 From: To: , Thread-Topic: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt Thread-Index: AQHMl8UhGeJlmRQ8r02tioerLlQmapWWWu/ggABr1oCAANONoA== Date: Tue, 1 Nov 2011 07:15:38 +0000 Message-ID: References: <20111031120308.18508.69135.idtracker@ietfa.amsl.com> <4EAEF751.6000205@alum.mit.edu> In-Reply-To: <4EAEF751.6000205@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [88.114.28.45] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 01 Nov 2011 07:15:40.0173 (UTC) FILETIME=[0F8A9BD0:01CC9866] X-Nokia-AV: Clean Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 07:16:26 -0000 SGkgUGF1bCwgDQpTZWUgYmVsb3cuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogbW11c2ljLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRm Lm9yZ10gT24NCj4gQmVoYWxmIE9mIGV4dCBQYXVsIEt5eml2YXQNCj4gU2VudDogMzEgT2N0b2Jl ciwgMjAxMSAyMTozMA0KPiBUbzogbW11c2ljQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbTU1V U0lDXSBGVzogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLWNzLTA5LnR4dA0KPiAN Cj4gVGhhbmtzLiBUaGlzIGNsZWFycyB1cCBhIGxvdC4NCj4gSW4gbG9va2luZyBvdmVyIHRoZSBj aGFuZ2VzLCBJIG5vdGVkIHRoZSBmb2xsb3dpbmcgb3RoZXIgdGhpbmdzOg0KPiANCj4gU3ludGF4 IChpbiA1LjIuMy4xIGFuZCA1LjYpOg0KPiANCj4gQXMgd3JpdHRlbiwgdGhpcyB3aWxsIGFsbG93 IGluZGl2aWR1YWwgY29ycmVsYXRpb24gbWVjaGFuaXNtcyB0byBiZSByZXBlYXRlZCwNCj4gcG9z c2libHkgd2l0aCBkaWZmZXJpbmcgdmFsdWVzLiBFLmcuDQo+IA0KPiBhPWNzLWNvcnJlbGF0aW9u OiBkdG1mOjEyMyBkdG1mOjQ1Ng0KPiANCj4gSSdtIG5vdCBzdXJlLCBidXQgSSAqZG91YnQqIHlv dSBpbnRlbmQgdG8gYWxsb3cgdGhhdC4NCj4gVG8gYWRkcmVzcyBpdCwgeW91IGhhdmUgYSBjb3Vw bGUgb2YgY2hvaWNlczoNCj4gDQo+IC0gZmlkZGxlIHRoZSBzeW50YXggdG8gZGlzYWxsb3cgaXQu DQo+IC0gcHV0IGluIHRleHR1YWwgcnVsZXMgdG8gZm9yYmlkIGl0Lg0KDQpJdCBzZWVtcyBJJ20g bm90IHJlYWxseSBmbHVlbnQgd2l0aCB0aGUgc3ludGF4Li4uIFdlIGRvbid0IHdhbnQgdG8gYWxs b3cgcmVwZWF0aW5nIGluZGl2aWR1YWwgbWVjaGFuaXNtcy4gV2UnbGwgdGFrZSBhIGxvb2sgYXQg dGhlIHN5bnRheCBhZ2Fpbi4NCiANCj4gSW4gc2VjdGlvbiA1LjIuMy4yLCB5b3UgaGF2ZToNCj4g DQo+ICAgICBGb3IgZXhhbXBsZSwgdGhlIG51bWJlcnMgKzM1OC05LTEyMy00NTY3IGFuZCAwOS0x MjMtNDU2Nw0KPiAgICAgY291bGQgYmUgY29uc2lkZXJlZCBhcyB0aGUgc2FtZSBudW1iZXIuDQo+ IA0KPiBUaGlzIGNvdWxkIGJlIGludGVycHJldGVkIGFzIGluZGljYXRpbmcgdGhhdCB0aGUgaW50 ZXJuYXRpb25hbCBFLjE2NCBudW1iZXINCj4gbWlnaHQgY29udGFpbiBzZXBhcmF0b3IgY2hhcmFj dGVycy4gQmFzZWQgb24geW91ciBzeW50YXgsIHRoZSBvbmUgaW4gdGhlIGNzLQ0KPiBjb3JyZWxh dGlvbiBhdHRyaWJ1dGUgY2FuJ3QgaGF2ZSB0aGVtLiBJJ20gbm90IHN1cmUgaWYgdGhlIG9uZSBy ZWNlaXZlZCBhcw0KPiBjYWxsZXJpZCBpbmZvIGZyb20gdGhlIFBTVE4gY2FuIGhhdmUgdGhlbSBv ciBub3QuDQoNCldlIHNob3VsZCB3cml0ZSArMzU4OTEyMzQ1NjcgYW5kIDA5MTIzNDU2Ny4NCiAN Cj4gSW4gc2VjdGlvbiA1LjIuMy4zOg0KPiANCj4gVGhlIHByb3RvY29sIGRpc2NyaW1pbmF0b3Ig bXVzdCBiZSBzcGVjaWZpZWQgKnNvbWV3aGVyZSouDQo+IEVpdGhlciB5b3UgY2FuIHNwZWNpZnkg YSBmaXhlZCBvbmUgYXMgcGFydCBvZiB0aGlzIG1lY2hhbmlzbSwgb3IgZWxzZSB5b3UgbXVzdA0K PiBhbGxvdyBpdCB0byBiZSBzcGVjaWZpZWQgYXMgcGFydCBvZiB0aGUgdmFsdWUuDQoNCkkgd2Fz IHRoaW5raW5nIHRoZSBwcm90b2NvbCBkaXNjcmltaW5hdG9yIGlzIHBpY2tlZCB1cCBieSB0aGUg Q1Mgc2lnbmFsaW5nIHN0YWNrLCBhcyBpdCB3b3VsZCBmb3Igbm9ybWFsIENTIGNhbGxzLCBhbmQg anVzdCBjb21wYXJpbmcgb2N0ZXRzIDQuLi5uICBvZiB0aGUgcmVjZWl2ZWQgVVVJRSB0byB0aGUg dmFsdWUgZXhjaGFuZ2VkIGluIE8vQSB3b3VsZCBiZSBzdWZmaWNpZW50LiBJZiB3ZSBuZWVkIHRv IGRlZmluZSB0aGUgdmFsdWUgZm9yIHRoZSBwcm90b2NvbCBkaXNjcmltaW5hdG9yLCBvbmUgb3B0 aW9uIEkgZ3Vlc3MgY291bGQgYmUgdmFsdWUgMCwgd2hpY2ggaW5kaWNhdGVzIFVzZXItc3BlY2lm aWMgcHJvdG9jb2wgYWNjb3JkaW5nIHRvIFEuOTMxLiANCg0KPiBJbiBzZWN0aW9uIDUuNS40Og0K PiANCj4gIklmIGVpdGhlciBwYXJ0eSB3aXNoZXMgdG8gZHJvcCBhbmQgcmVlc3RhYmxpc2ggYW4g ZXhpc3RpbmcgY2FsbC4uLiINCj4gDQo+IFRoaXMgaW1wbGllcyB0aGF0IG9uZSBtdXN0IHVzZSBv bmUgby9hIGV4Y2hhbmdlIHRvIGRyb3AgdGhlIGV4aXN0aW5nIGNhbGwgYW5kDQo+IGFub3RoZXIg b25lIHRvIGVzdGFibGlzaCBpdCBhZ2Fpbi4gVGhhdCBzaG91bGRuJ3QgYmUgbmVjZXNzYXJ5Lg0K PiBTZW5kaW5nIHRoZSBzYW1lIHNvcnQgb2Ygb2ZmZXIgb25lIHdvdWxkIGRvIHRvIGVzdGFibGlz aCB0aGUgaW5pdGlhbCBzZXNzaW9uDQo+IChpbmNsdWRpbmcgYT1jb25uZWN0aW9uOm5ldykgc2hv dWxkIGJlIGZpbmUuDQoNCk9rLCB3ZSdsbCBjbGFyaWZ5IHRoYXQuDQoNClRoYW5rcw0KU2ltbw0K IA0KPiAJVGhhbmtzLA0KPiAJUGF1bA0KPiANCj4gDQo+IE9uIDEwLzMxLzExIDg6MDYgQU0sIFNp bW8uVmVpa2tvbGFpbmVuQG5va2lhLmNvbSB3cm90ZToNCj4gPiBIaSwNCj4gPiBXZSBoYXZlIHN1 Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBzZHAtY3MgZHJhZnQNCj4gKGh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1jcy0wOS50eHQp LA0KPiBhZGRyZXNzaW5nIFBhdWwncyBjb21tZW50cy4NCj4gPg0KPiA+IEJlbG93IGlzIGEgbGlz dCBvZiBjaGFuZ2VzIGluIHRoZSAtMDkgdmVyc2lvbjoNCj4gPg0KPiA+IE51bWJlciBmb3JtYXQN Cj4gPiAtCVVzZSB0aGUgdGVybSDigJxpbnRlcm5hdGlvbmFsIEUuMTY0IG51bWJlcuKAnSB0aHJv dWdob3V0IHRoZQ0KPiBkb2N1bWVudA0KPiA+IC0JUmVxdWlyZSBhIOKAnCvigJ0gc2lnbiBpbiBh bGwgaW50ZXJuYXRpb25hbCBFLjE2NCBudW1iZXJzDQo+ID4NCj4gPiBBZGRlZCB0aGUgZm9sbG93 aW5nIGxpbmVzIHRvIGFkZHJlc3N0eXBlIHNwZWNpZmljYXRpb24gaW4gNS4yLjE6DQo+ID4g4oCc DQo+ID4gICAgICBXaGVuIHRoZTxhZGRydHlwZT4gIGlzIFBTVE4sIHRoZSBjb25uZWN0aW9uIGFk ZHJlc3MgaXMgZGVmaW5lZA0KPiA+ICAgICAgYXMgZm9sbG93czoNCj4gPg0KPiA+ICAgICAgbyAg YW4gZTE2NC1hZGRyZXNzDQo+ID4NCj4gPiAgICAgIFdoZW4gdGhlPGFkZHJ0eXBlPiAgaXMgIi0i LCB0aGUgY29ubmVjdGlvbiBhZGRyZXNzIGlzIGRlZmluZWQNCj4gPiAgICAgIGFzIGZvbGxvd3M6 DQo+ID4NCj4gPiAgICAgIG8gIHRoZSB2YWx1ZSAiLSIsIHNpZ25pZnlpbmcgdGhhdCB0aGUgYWRk cmVzcyBpcyB1bmtub3duLg0KPiA+IE9SDQo+ID4gICAgICBvICBhbnkgc3ludGFjdGljYWxseSB2 YWxpZCB2YWx1ZSwgd2hpY2ggaXMgdG8gYmUgaWdub3JlZC4uDQo+ID4g4oCcDQo+ID4NCj4gPiBT eW50YXggb2YgY3MtY29ycmVsYXRpb24gY2hhbmdlZCBpbiA1LjIuMy4xDQo+ID4NCj4gPiBVVUlF IHByb3RvY29sIGRpc2NyaW1pbmF0b3INCj4gPiAtCUNsYXJpZmllZCB0aGF0IG9ubHkgdGhlIOKA nFVzZXIgaW5mb3JtYXRpb27igJ0gcGFydCBvZiBVVUlFIGlzIHRvIGJlDQo+IGluY2x1ZGVkIGFz IHRoZSB2YWx1ZSBvZiB1dWllLW1lY2gsIGFuZCB1c2VkIGZvciBjb21wYXJpbmcgdGhlIGluY29t aW5nDQo+IFVVSUUNCj4gPiAtCUFkZGVkIGFuIE9QRU4gSVNTVUUgc3RpbGwgaGVyZQ0KPiA+DQo+ ID4gTW92ZWQgdGhlIHVzYWdlIG9mIOKAnGE9Y29ubmVjdGlvbjpleGlzdGluZ+KAnSB0byA1LjUu NCBNb2RpZnlpbmcgdGhlDQo+IHNlc3Npb24uDQo+ID4NCj4gPiBBZGRlZCB0ZXh0IGluIDUuNS40 IG9uIGhvdyBjb25uZWN0aW9uIHJldXNlIHdvcmtzLg0KPiA+DQo+ID4gRS4xNjQgc3ludGF4IGlu IDUuNg0KPiA+IC0gd2UgZGlkbuKAmXQgaW5jbHVkZSBhIHJlZmVyZW5jZSB0byBSRkMzOTY2IHNp bmNlIHdlIGRvbuKAmXQgd2FudCB0bw0KPiA+IGluY2x1ZGUgdGhlIHZpc3VhbCBzZXBhcmF0b3Is IGFuZCBvdGhlcndpc2UgdGhlIGJlbmVmaXQgb2YgaGF2aW5nIHRoZQ0KPiA+IFJGQyBhcyByZWZl cmVuY2Ugd291bGQgYmUgc21hbGwNCj4gPg0KPiA+IENoYW5nZWQgdGhlIG51bWJlciBpbiB0aGUg ZXhhbXBsZXMuICsxNTU1MTIzNCAtPiAgKzM1ODkxMjM0NTY3IChJIGtub3cNCj4gPiB0aGlzIGF0 IGxlYXN0IGlzIGEgc3ludGFjdGljYWxseSBjb3JyZWN0IHJlcHJlc2VudGF0aW9uIEoNCj4gPg0K PiA+IFRoaW5ncyB3aGljaCBkaWQgbm90IG1ha2UgdGhpcyB2ZXJzaW9uOg0KPiA+DQo+ID4gVE9E TzogQWRkIGV4YW1wbGUgd2l0aCBDUyBhdWRpby92aWRlbyBzdHJlYW0uDQo+ID4gVE9ETzogU2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMgbmVlZHMgbW9yZSB3b3JrIGJhc2VkIG9uIEZsZW1taW5nJ3MN Cj4gZWFybGllciBjb21tZW50cyAoaW5jbHVkaW5nIGNhbGxlcidzIEUxNjQgbnVtYmVyIGluIFNE UCkuDQo+ID4gVE9ETzogQ2xhcmlmaWNhdGlvbiBvbiB0aGUgbWVjaGFuaXNtIHdvcmtzIHdpdGgg M1BDQy4NCj4gPg0KPiA+DQo+ID4gVGhhbmtzDQo+ID4gU2ltbw0KPiA+DQo+ID4NCj4gPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IGktZC1hbm5vdW5jZS1ib3VuY2VzQGll dGYub3JnDQo+ID4gW21haWx0bzppLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIGV4dA0KPiA+IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPiA+IFNlbnQ6IDMxIE9j dG9iZXIsIDIwMTEgMTQ6MDMNCj4gPiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+ID4gQ2M6 IG1tdXNpY0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbW11 c2ljLXNkcC1jcy0wOS50eHQNCj4gPg0KPiA+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWls YWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPiBkaXJlY3Rvcmllcy4gVGhp cyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTXVsdGlwYXJ0eSBNdWx0aW1lZGlhIFNlc3Np b24NCj4gQ29udHJvbCBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KPiA+DQo+ID4gCVRpdGxl ICAgICAgICAgICA6IFNlc3Npb24gRGVzY3JpcHRpb24gUHJvdG9jb2wgKFNEUCkgRXh0ZW5zaW9u IEZvciBTZXR0aW5nDQo+IFVwIEF1ZGlvIGFuZCBWaWRlbyBNZWRpYSBTdHJlYW1zIE92ZXIgQ2ly Y3VpdC1Td2l0Y2hlZCBCZWFyZXJzIEluIFRoZQ0KPiBQdWJsaWMgU3dpdGNoZWQgVGVsZXBob25l IE5ldHdvcmsgKFBTVE4pDQo+ID4gCUF1dGhvcihzKSAgICAgICA6IE1pZ3VlbCBBLiBHYXJjaWEt TWFydGluDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgU2ltbyBWZWlra29sYWluZW4N Cj4gPiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLWNzLTA5LnR4dA0K PiA+IAlQYWdlcyAgICAgICAgICAgOiAzMA0KPiA+IAlEYXRlICAgICAgICAgICAgOiAyMDExLTEw LTMxDQo+ID4NCj4gPiAgICAgVGhpcyBtZW1vIGRlc2NyaWJlcyB1c2UgY2FzZXMsIHJlcXVpcmVt ZW50cywgYW5kIHByb3RvY29sIGV4dGVuc2lvbnMNCj4gPiAgICAgZm9yIHVzaW5nIHRoZSBTZXNz aW9uIERlc2NyaXB0aW9uIFByb3RvY29sIChTRFApIE9mZmVyL0Fuc3dlciBtb2RlbA0KPiA+ICAg ICBmb3IgZXN0YWJsaXNoaW5nIGF1ZGlvIGFuZCB2aWRlbyBtZWRpYSBzdHJlYW1zIG92ZXIgY2ly Y3VpdC1zd2l0Y2hlZA0KPiA+ICAgICBiZWFyZXJzIGluIHRoZSBQdWJsaWMgU3dpdGNoZWQgVGVs ZXBob25lIE5ldHdvcmsgKFBTVE4pLg0KPiA+DQo+ID4NCj4gPiBBIFVSTCBmb3IgdGhpcyBJbnRl cm5ldC1EcmFmdCBpczoNCj4gPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1pZXRmLW1tdXNpYy1zZHAtY3MtMDkudHh0DQo+ID4NCj4gPiBJbnRlcm5ldC1EcmFmdHMg YXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ID4gZnRwOi8vZnRwLmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gPg0KPiA+IFRoaXMgSW50ZXJuZXQtRHJhZnQgY2Fu IGJlIHJldHJpZXZlZCBhdDoNCj4gPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWlldGYtbW11c2ljLXNkcC1jcy0wOS50eHQNCj4gPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEktRC1Bbm5vdW5jZSBtYWlsaW5nIGxp c3QNCj4gPiBJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KPiA+IEludGVybmV0LURyYWZ0IGRpcmVjdG9y aWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIG9yDQo+ID4gZnRwOi8vZnRwLmll dGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCj4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG1tdXNpYyBtYWlsaW5nIGxpc3QNCj4gPiBt bXVzaWNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21tdXNpYw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gbW11c2ljIG1haWxpbmcgbGlzdA0KPiBtbXVzaWNAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg== From fandreas@cisco.com Wed Nov 2 08:50:01 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B972311E8083 for ; Wed, 2 Nov 2011 08:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONILbICZi4me for ; Wed, 2 Nov 2011 08:50:00 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id C493721F8DB8 for ; Wed, 2 Nov 2011 08:49:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=40519; q=dns/txt; s=iport; t=1320248999; x=1321458599; h=message-id:date:from:mime-version:to:subject; bh=Ijr974MCDd6FMnqqgL7r6aGXRUsc30Y1Llej37J3YTc=; b=guJ7HqEq4nL87eFAQGpaVO8DLabA67PXu/3rchJKNaTvlre8jkPwDd18 QrGq6qxQrIDhf41I5TK+UDoNO+H0Wxne8VKJAb2p+3Yl+yULHC+dNYxpY cxnlKRawYTKp6A7cvVkfRUHkg81WszG/F/As4byryYy+L+VhZWV4I9WPi 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtcAAAtmsU6tJV2b/2dsb2JhbABCgk2XI45dgR+BBYILAWU9FgEBBhADAgECATQXDQYCAQEFGYdolRaBJgGeaokQBJQUkgE X-IronPort-AV: E=Sophos;i="4.69,444,1315180800"; d="scan'208,217";a="32831693" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 02 Nov 2011 15:49:58 +0000 Received: from rtp-fandreas-8716.cisco.com (rtp-fandreas-8716.cisco.com [10.117.7.87]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA2Fo5EH018409 for ; Wed, 2 Nov 2011 15:50:06 GMT Message-ID: <4EB166A5.8030600@cisco.com> Date: Wed, 02 Nov 2011 11:49:57 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: mmusic Content-Type: multipart/alternative; boundary="------------020005060706080507020807" Subject: [MMUSIC] Draft MMUSIC Agenda for Taipei X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 15:50:01 -0000 This is a multi-part message in MIME format. --------------020005060706080507020807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Greetings We have just uploaded the draft MMUSIC agenda for IETF-82 in Taipei, which you can see at http://www.ietf.org/proceedings/82/agenda/mmusic.htm as well as below. Please take a look and let us know if you have any questions or comments. Please note that we have only 2 hours this time, and a fairly full agenda. Agenda items are listed in priority order with WG items and actively discussed drafts taking precedence with a goal of discussing and closing open issues rather than just giving general status updates. The remaining drafts will be discussed as time permits. Thanks Flemming & Miguel IETF-82, Taipei Multiparty Multimedia Session Control (MMUSIC) WG ================================================== *** AGENDA *** Chairs: Miguel Garcia (miguel.a.garcia@ericsson.com ) Flemming Andreasen (fandreas@cisco.com ) FRIDAY, November 18, 2011, 9:00--11:00 (101C) ----------------------------------------------------- 09:00--09:15 Introduction and Status Update (Chairs, 15) 09:15-09:30 Discussion on latching mechanisms as an alternative to ICE (Discussion facilitated by chairs) 09:30-09:40 Real Time Streaming Protocol 2.0 (Martin, 15) draft-ietf-mmusic-rfc2326bis-28.txt 09:40-09:50 SDP Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The PSTN (Simo Veikkolainen, 10) draft-ietf-mmusic-sdp-cs-09.txt 10:00-10:10Miscellaneous Capabilities Negotiation in SDP (Simo Veikkolainen, 10) draft-garcia-mmusic-sdp-miscellaneous-caps-00.txt 10:10-10:20 SDP Media Capabilities (Flemming Andreasen, 10) draft-ietf-mmusic-sdp-media-capabilities-12.txt 10:20-10:30 Multiplexing Negotiation Using SDP Port Numbers (Christer Holmberg, 10) draft-holmberg-mmusic-sdp-bundle-negotiation-00.txt 10:30-10:40 Signal 3D format in SDP (Bert Greevenbosh, 10) draft-greevenbosch-mmusic-signal-3d-format-02 10:40-10:50 Extensible Bandwidth Attribute for SDP (Magnus Westerlund, 10) draft-westerlund-mmusic-sdp-bw-attribute-00.txt 10:50-10:55 RTSP Extension for Substream Control (Peiyu Yue, 10) draft-yue-mmusic-rtsp-substream-control-extension-00.txt 10:55-11:00 Wrap-up --------------020005060706080507020807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Greetings

We have just uploaded the draft MMUSIC agenda for IETF-82 in Taipei, which you can see at

    http://www.ietf.org/proceedings/82/agenda/mmusic.htm

as well as below. Please take a look and let us know if you have any questions or comments.

Please note that we have only 2 hours this time, and a fairly full agenda. Agenda items are listed in priority order with WG items and actively discussed drafts taking precedence with a goal of discussing and closing open issues rather than just giving general status updates. The remaining drafts will be discussed as time permits.

Thanks

        Flemming & Miguel   


IETF-82, Taipei

 

Multiparty Multimedia Session Control (MMUSIC) WG

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

** AGENDA **

 

Chairs: Miguel Garcia (miguel.a.garcia@ericsson.com)

        Flemming Andreasen (fandreas@cisco.com)          

 

 

FRIDAY, November 18, 2011, 9:00–11:00 (101C)

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

 

09:00–09:15  Introduction and Status Update (Chairs, 15)

 

 

09:15-09:30 Discussion on latching mechanisms as an alternative

            to ICE (Discussion facilitated by chairs)

 

 

09:30-09:40 Real Time Streaming Protocol 2.0 (Martin, 15)

           

            draft-ietf-mmusic-rfc2326bis-28.txt

 

 

09:40-09:50 SDP Extension For Setting Up Audio and Video

            Media Streams Over Circuit-Switched Bearers In The

            PSTN (Simo Veikkolainen, 10)

 

            draft-ietf-mmusic-sdp-cs-09.txt

 

 
10:00-10:10 Miscellaneous Capabilities Negotiation in SDP
            (Simo Veikkolainen, 10)
 
            draft-garcia-mmusic-sdp-miscellaneous-caps-00.txt
 

 

10:10-10:20 SDP Media Capabilities (Flemming Andreasen, 10)

                 

            draft-ietf-mmusic-sdp-media-capabilities-12.txt

 

 

10:20-10:30 Multiplexing Negotiation Using SDP Port

            Numbers (Christer Holmberg, 10)

 

            draft-holmberg-mmusic-sdp-bundle-negotiation-00.txt

 

 

10:30-10:40 Signal 3D format in SDP (Bert Greevenbosh, 10)

 

            draft-greevenbosch-mmusic-signal-3d-format-02

 

 

10:40-10:50 Extensible Bandwidth Attribute for SDP (Magnus

            Westerlund, 10)

 

            draft-westerlund-mmusic-sdp-bw-attribute-00.txt

 

 

10:50-10:55 RTSP Extension for Substream Control (Peiyu Yue, 10)

 

            draft-yue-mmusic-rtsp-substream-control-extension-00.txt

 

 

10:55-11:00 Wrap-up



--------------020005060706080507020807-- From pkyzivat@alum.mit.edu Wed Nov 2 10:57:13 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E26C1F0CA0 for ; Wed, 2 Nov 2011 10:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=0.197, 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 BWf7SbVW3wNn for ; Wed, 2 Nov 2011 10:57:12 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7D91F0CAC for ; Wed, 2 Nov 2011 10:57:12 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta05.westchester.pa.mail.comcast.net with comcast id sHwk1h0030QuhwU55HxBVl; Wed, 02 Nov 2011 17:57:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta02.westchester.pa.mail.comcast.net with comcast id sHxA1h0050tdiYw3NHxBTX; Wed, 02 Nov 2011 17:57:11 +0000 Message-ID: <4EB18474.40701@alum.mit.edu> Date: Wed, 02 Nov 2011 13:57:08 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Simo.Veikkolainen@nokia.com References: <20111031120308.18508.69135.idtracker@ietfa.amsl.com> <4EAEF751.6000205@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Keith Drage , mmusic@ietf.org Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 17:57:13 -0000 Inline. (Keith Drage - there is a question for you below.) On 11/1/11 3:15 AM, Simo.Veikkolainen@nokia.com wrote: > Hi Paul, > See below. > >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf Of ext Paul Kyzivat >> Sent: 31 October, 2011 21:30 >> To: mmusic@ietf.org >> Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt >> >> Thanks. This clears up a lot. >> In looking over the changes, I noted the following other things: >> >> Syntax (in 5.2.3.1 and 5.6): >> >> As written, this will allow individual correlation mechanisms to be repeated, >> possibly with differing values. E.g. >> >> a=cs-correlation: dtmf:123 dtmf:456 >> >> I'm not sure, but I *doubt* you intend to allow that. >> To address it, you have a couple of choices: >> >> - fiddle the syntax to disallow it. >> - put in textual rules to forbid it. > > It seems I'm not really fluent with the syntax... We don't want to allow repeating individual mechanisms. We'll take a look at the syntax again. Its fairly easy to write the ABNF to allow each kind at most once if you fix the order in which they may appear. cs-correlation-attr= "cs-correlation:" corr-mechanisms corr-mechanisms = [SP caller-id-mech] [SP uuie-mech] [SP dtmf-mech] [SP ext-mech] (This has the limitation that there must be a space before the first mechanism.) To allow them in any order is *possible* but unreasonably complex. If you want that, then best to just do it with words. >> In section 5.2.3.2, you have: >> >> For example, the numbers +358-9-123-4567 and 09-123-4567 >> could be considered as the same number. >> >> This could be interpreted as indicating that the international E.164 number >> might contain separator characters. Based on your syntax, the one in the cs- >> correlation attribute can't have them. I'm not sure if the one received as >> callerid info from the PSTN can have them or not. > > We should write +35891234567 and 091234567. WFM >> In section 5.2.3.3: >> >> The protocol discriminator must be specified *somewhere*. >> Either you can specify a fixed one as part of this mechanism, or else you must >> allow it to be specified as part of the value. > > I was thinking the protocol discriminator is picked up by the CS signaling stack, as it would for normal CS calls, and just comparing octets 4...n of the received UUIE to the value exchanged in O/A would be sufficient. If we need to define the value for the protocol discriminator, one option I guess could be value 0, which indicates User-specific protocol according to Q.931. So the recipient would ignore the protocol discriminator? That seems pretty odd to me. But I will defer to someone who is more familiar with use of these mechanisms in the PSTN. (Keith?) Thanks, Paul >> In section 5.5.4: >> >> "If either party wishes to drop and reestablish an existing call..." >> >> This implies that one must use one o/a exchange to drop the existing call and >> another one to establish it again. That shouldn't be necessary. >> Sending the same sort of offer one would do to establish the initial session >> (including a=connection:new) should be fine. > > Ok, we'll clarify that. > > Thanks > Simo > >> Thanks, >> Paul >> >> >> On 10/31/11 8:06 AM, Simo.Veikkolainen@nokia.com wrote: >>> Hi, >>> We have submitted a new version of the sdp-cs draft >> (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-09.txt), >> addressing Paul's comments. >>> >>> Below is a list of changes in the -09 version: >>> >>> Number format >>> - Use the term “international E.164 number” throughout the >> document >>> - Require a “+” sign in all international E.164 numbers >>> >>> Added the following lines to addresstype specification in 5.2.1: >>> “ >>> When the is PSTN, the connection address is defined >>> as follows: >>> >>> o an e164-address >>> >>> When the is "-", the connection address is defined >>> as follows: >>> >>> o the value "-", signifying that the address is unknown. >>> OR >>> o any syntactically valid value, which is to be ignored.. >>> “ >>> >>> Syntax of cs-correlation changed in 5.2.3.1 >>> >>> UUIE protocol discriminator >>> - Clarified that only the “User information” part of UUIE is to be >> included as the value of uuie-mech, and used for comparing the incoming >> UUIE >>> - Added an OPEN ISSUE still here >>> >>> Moved the usage of “a=connection:existing” to 5.5.4 Modifying the >> session. >>> >>> Added text in 5.5.4 on how connection reuse works. >>> >>> E.164 syntax in 5.6 >>> - we didn’t include a reference to RFC3966 since we don’t want to >>> include the visual separator, and otherwise the benefit of having the >>> RFC as reference would be small >>> >>> Changed the number in the examples. +15551234 -> +35891234567 (I know >>> this at least is a syntactically correct representation J >>> >>> Things which did not make this version: >>> >>> TODO: Add example with CS audio/video stream. >>> TODO: Security considerations needs more work based on Flemming's >> earlier comments (including caller's E164 number in SDP). >>> TODO: Clarification on the mechanism works with 3PCC. >>> >>> >>> Thanks >>> Simo >>> >>> >>> -----Original Message----- >>> From: i-d-announce-bounces@ietf.org >>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext >>> internet-drafts@ietf.org >>> Sent: 31 October, 2011 14:03 >>> To: i-d-announce@ietf.org >>> Cc: mmusic@ietf.org >>> Subject: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Multiparty Multimedia Session >> Control Working Group of the IETF. >>> >>> Title : Session Description Protocol (SDP) Extension For Setting >> Up Audio and Video Media Streams Over Circuit-Switched Bearers In The >> Public Switched Telephone Network (PSTN) >>> Author(s) : Miguel A. Garcia-Martin >>> Simo Veikkolainen >>> Filename : draft-ietf-mmusic-sdp-cs-09.txt >>> Pages : 30 >>> Date : 2011-10-31 >>> >>> This memo describes use cases, requirements, and protocol extensions >>> for using the Session Description Protocol (SDP) Offer/Answer model >>> for establishing audio and video media streams over circuit-switched >>> bearers in the Public Switched Telephone Network (PSTN). >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-09.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-mmusic-sdp-cs-09.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 >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic From fandreas@cisco.com Wed Nov 2 13:54:24 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F3C11E811F for ; Wed, 2 Nov 2011 13:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVV8uFgTJRt0 for ; Wed, 2 Nov 2011 13:54:23 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 66F7B21F852E for ; Wed, 2 Nov 2011 13:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=6152; q=dns/txt; s=iport; t=1320267263; x=1321476863; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Ih9ZGkBk4q7sloVJh5L8imiIzaU6OCWnvRmw8wqIGO0=; b=kLtfmAJEQA2l84byI1YW8TSbvqtYui5o9OrRfQMHntKTSrLPBBKb5d8l Ggr073EksgzSS3Ailc/t/kYU3M3U72y0NL72B97dJgzomLndJY/njXFJX 0vVtLwNQQEWmNRalZen1DQuVv07emG9dIYEMO7Ll8pvGqOdhLuwIKR+id A=; X-IronPort-AV: E=Sophos;i="4.69,445,1315180800"; d="scan'208";a="32922566" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 02 Nov 2011 20:54:23 +0000 Received: from rtp-fandreas-8716.cisco.com (rtp-fandreas-8716.cisco.com [10.117.7.87]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id pA2KsM2j016568; Wed, 2 Nov 2011 20:54:22 GMT Message-ID: <4EB1ADFD.4030501@cisco.com> Date: Wed, 02 Nov 2011 16:54:21 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= References: <4E8C6114.4000402@ericsson.com> <03191512-00C7-45A5-AF8C-AEEEBA10AC5D@acmepacket.com> <4E9047F7.9000204@cisco.com> <0B8A3FEC-4C92-467D-871F-FE67F98F0E26@acmepacket.com> <4E9CDD35.6020304@cisco.com> <2B5668C4-72EB-4DFD-909C-847FF5AE2491@acmepacket.com> <4EA825D2.6090405@cisco.com> <78010146-3AD8-44DA-824E-10335528B03C@acmepacket.com> <7F97F7F5-86F0-4684-B2C4-F4B9372C6E26@acmepacket.com> <4EAA080D.8070801@cisco.com> <945EE41C-0068-4CBE-8797-1DF8C7F2BDC0@acmepacket.com> <4EAEF66D.3030007@cisco.com> <4EAF8E01.4010807@omnitor.se> In-Reply-To: <4EAF8E01.4010807@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "Elwell, John" , Dan Wing , "" , "mmusic \(E-mail\)" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 20:54:24 -0000 That might be another option (multiplex RTP and RTCP with RTCP as the keep-alive mechanism), however I think you still have the issue of sending the intial packets to punch a hole. -- Flemming On 11/1/11 2:13 AM, Gunnar Hellstrm wrote: > Can rfc6263 RTP Keep-alive be referenced for the non-ICE case? > > /Gunnar > > > Flemming Andreasen skrev 2011-10-31 20:26: >> >> >> On 10/27/11 11:36 PM, Hadriel Kaplan wrote: >>> On Oct 27, 2011, at 9:40 PM, Flemming Andreasen wrote: >>> >>>>> As I understand it, your concern is we (1) don't have an RFC >>>>> defining how NAT traversal works if not with ICE, (2) don't want >>>>> to define a "primer" thingy just for this one loopback draft, and >>>>> (3) are dizzy from of going around in circles. :) >>>>> >>>> Right, and >>>> (4) If we are not happy with ICE as our IETF NAT traversal >>>> mechanism, for whatever reason, then we as WG need to be explicit >>>> about that and figure out a way of addressing it in general - not >>>> just in the form of and as part of some loopback specific >>>> discussion (or we'll have another one of these threads when the >>>> next draft comes along that needs to work behind NATs, but doesn't >>>> really want to do ICE). >>> While I and some others have noted on multiple occasions that ICE >>> isn't the utopian solution it's cracked up to be, it appears so far >>> we're still in the minority in the WG. >>> >>> I did put in text in: >>> http://tools.ietf.org/html/draft-boucadair-mmusic-ccap-00 >>> in Appendix A.2, of an example why ICE can't be used for some people >>> - but that's sort of an obscure reference because the point of the >>> draft is about IPv4/v6 not NATs. >> Would it make sense to include this as part of John Elwells ICE draft ? >> >>> There're other ICE-problem examples too, like in the Enterprise >>> market where the IT guys want to force the media to go through their >>> VPNs or stay inside and never reach the public Internet. >>> >>> But essentially media-loopback is the only case I've seen where >>> there's a NAT problem to solve that isn't auto-handled by just >>> normal RTP behavior and latching. The IPv4/v6 case isn't a NAT >>> traversal problem per se, nor a latching one, but more of a need to >>> indicate multiple address families in SDP, competing with the desire >>> by some others in the WG that a connectivity check type thing >>> happens because IPv6 isn't stable. >>> >>> >>>>> My point in all this is to propose the following high-level >>>>> straw-man: >>>>> >>>>> 1) We use the STUN Binding Indications as our primer packet >>>>> format, by referencing STUN RFC. >>>>> >>>> Any reason we can't reference the ICE RFC and make it a "SHOULD" >>>> implement ? >>> How about this: "A UAC compliant with this document SHOULD implement >>> [RFC5245], but MAY only implement section 10 of [RFC5245] with the >>> additional rules noted in section X of this document if it does not >>> use ICE for normal media sessions." >>> >>> And section X would have something like this: >>> When a UAS loopback mirror receives an SDP Offer with >>> media-loopback, if the UAS implements [RFC5245] then it follows ICE >>> procedures, including fallback to just sending STUN Binding >>> Indications per Section 10 of ICE if the received Offer did not >>> indicate ICE or there is an ICE mismatch condition. If the UAS does >>> not implement [RFC5245], then it MUST at least follow the procedures >>> of Section 10 of [RFC5245] and send STUN Binding Indications. In >>> all cases, even if ICE is not actively used, the existence of the >>> media-loopback indication in SDP indicates the far-end is capable of >>> receiving and ignoring STUN Binding Indications, and the local UAS >>> MUST send such as per Section 10 of [RFC5245] as if the SDP >>> contained a candidate line. This is to ensure some initial packets >>> gets sent to the loopback source, to create NAT bindings or open >>> Firewall pinholes along the path, since RTP is not generated by the >>> loopback mirror until RTP is received. >>> >> >> I'd like to hear more people commenting on this. My understanding of >> ICE Section 5.1/10 in this case is that it's for keep-alives and >> hence you wouldn't send these messages initially (which is not to say >> that couldn't be changed when used with loopback - the question is >> how it differs from "real" ICE then). >> >>>>> 3) We specify that the media-loopback indication in SDP means the >>>>> loopback-source supports receiving and ignoring STUN Binding >>>>> Indications, so that following Section 10 of RFC 5245 the mirror >>>>> MUST send STUN not no-op or comfort noise. >>>>> 4) We put some text in the loopback-source about sources MUST >>>>> support ignoring received STUN Binding Indications, not depend on >>>>> getting them, etc. >>>>> >>>> This seems like a way forward that would keep us consistent with >>>> current ICE procedures. We probably need to explore it in more >>>> detail (and I'd welcome more comments on this as well), but it >>>> seems promising. One question is the frequency with which these >>>> STUN Binding Requests would be sent ? >>> The frequency is in section 10, but I assume you mean when >>> "inactive" mode is used in media-loopback? That's a tough one. In >>> a normal call there would be no RTP in that mode, and since the >>> tester may want to test that mode to see if it is causing problems >>> then I think the mirror shouldn't send STUN even then. :( >> I believe Section 10 would only apply to keep-alives in the scenario >> being considered here (and hence inactive mode is fine). The issue, I >> believe, is that you need these STUN binding packets sent initially >> to punch a hole through the NAT, and I don't believe the current RFC >> 5245 by itself will give you that. >> >> -- Flemming >> >> >>> -hadriel >>> >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > From gunnar.hellstrom@omnitor.se Wed Nov 2 14:52:34 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49DD11F0C63 for ; Wed, 2 Nov 2011 14:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_52=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXC8l3Xo+bCf for ; Wed, 2 Nov 2011 14:52:33 -0700 (PDT) Received: from vsp-outgoing3.binero.net (vsp-outgoing3.binero.net [193.17.218.162]) by ietfa.amsl.com (Postfix) with SMTP id E0ECB1F0C5D for ; Wed, 2 Nov 2011 14:52:32 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.39.229]) by vsp-outgoing3.binero.net (Halon Mail Gateway) with ESMTP for ; Wed, 2 Nov 2011 22:52:19 +0100 (CET) Received: from [192.168.50.31] (h225n1fls32o933.telia.com [213.67.165.225]) by smtp-02-01.atm.binero.net (Postfix) with ESMTPA id AC5E43A11B; Wed, 2 Nov 2011 22:52:18 +0100 (CET) Message-ID: <4EB1BB97.9080205@omnitor.se> Date: Wed, 02 Nov 2011 22:52:23 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Flemming Andreasen , "mmusic (E-mail)" References: <4E8C6114.4000402@ericsson.com> <03191512-00C7-45A5-AF8C-AEEEBA10AC5D@acmepacket.com> <4E9047F7.9000204@cisco.com> <0B8A3FEC-4C92-467D-871F-FE67F98F0E26@acmepacket.com> <4E9CDD35.6020304@cisco.com> <2B5668C4-72EB-4DFD-909C-847FF5AE2491@acmepacket.com> <4EA825D2.6090405@cisco.com> <78010146-3AD8-44DA-824E-10335528B03C@acmepacket.com> <7F97F7F5-86F0-4684-B2C4-F4B9372C6E26@acmepacket.com> <4EAA080D.8070801@cisco.com> <945EE41C-0068-4CBE-8797-1DF8C7F2BDC0@acmepacket.com> <4EAEF66D.3030007@cisco.com> <4EAF8E01.4010807@omnitor.se> <4EB1ADFD.4030501@cisco.com> In-Reply-To: <4EB1ADFD.4030501@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "Elwell, John" , Dan Wing Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-media-loopback-16 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 21:52:34 -0000 With the reasoning about why the keep-alive according to RFC6263 is needed, I would expect that it would transmit first keep-alive immediately, so that the hole is punched. RFC6263 is intended for example for payloads that may have long pauses between transmissions. The "pause" may be from the beginning. For such payloads, an initial priming through NAT is needed, and RFC6263 can provide that. But that might be up for interpretation... Gunnar Flemming Andreasen skrev 2011-11-02 21:54: > That might be another option (multiplex RTP and RTCP with RTCP as the > keep-alive mechanism), however I think you still have the issue of > sending the intial packets to punch a hole. > > -- Flemming > > On 11/1/11 2:13 AM, Gunnar Hellstrm wrote: >> Can rfc6263 RTP Keep-alive be referenced for the non-ICE case? >> >> /Gunnar >> >> >> Flemming Andreasen skrev 2011-10-31 20:26: >>> >>> >>> On 10/27/11 11:36 PM, Hadriel Kaplan wrote: >>>> On Oct 27, 2011, at 9:40 PM, Flemming Andreasen wrote: >>>> >>>>>> As I understand it, your concern is we (1) don't have an RFC >>>>>> defining how NAT traversal works if not with ICE, (2) don't want >>>>>> to define a "primer" thingy just for this one loopback draft, and >>>>>> (3) are dizzy from of going around in circles. :) >>>>>> >>>>> Right, and >>>>> (4) If we are not happy with ICE as our IETF NAT traversal >>>>> mechanism, for whatever reason, then we as WG need to be explicit >>>>> about that and figure out a way of addressing it in general - not >>>>> just in the form of and as part of some loopback specific >>>>> discussion (or we'll have another one of these threads when the >>>>> next draft comes along that needs to work behind NATs, but doesn't >>>>> really want to do ICE). >>>> While I and some others have noted on multiple occasions that ICE >>>> isn't the utopian solution it's cracked up to be, it appears so far >>>> we're still in the minority in the WG. >>>> >>>> I did put in text in: >>>> http://tools.ietf.org/html/draft-boucadair-mmusic-ccap-00 >>>> in Appendix A.2, of an example why ICE can't be used for some >>>> people - but that's sort of an obscure reference because the point >>>> of the draft is about IPv4/v6 not NATs. >>> Would it make sense to include this as part of John Elwells ICE draft ? >>> >>>> There're other ICE-problem examples too, like in the Enterprise >>>> market where the IT guys want to force the media to go through >>>> their VPNs or stay inside and never reach the public Internet. >>>> >>>> But essentially media-loopback is the only case I've seen where >>>> there's a NAT problem to solve that isn't auto-handled by just >>>> normal RTP behavior and latching. The IPv4/v6 case isn't a NAT >>>> traversal problem per se, nor a latching one, but more of a need to >>>> indicate multiple address families in SDP, competing with the >>>> desire by some others in the WG that a connectivity check type >>>> thing happens because IPv6 isn't stable. >>>> >>>> >>>>>> My point in all this is to propose the following high-level >>>>>> straw-man: >>>>>> >>>>>> 1) We use the STUN Binding Indications as our primer packet >>>>>> format, by referencing STUN RFC. >>>>>> >>>>> Any reason we can't reference the ICE RFC and make it a "SHOULD" >>>>> implement ? >>>> How about this: "A UAC compliant with this document SHOULD >>>> implement [RFC5245], but MAY only implement section 10 of [RFC5245] >>>> with the additional rules noted in section X of this document if it >>>> does not use ICE for normal media sessions." >>>> >>>> And section X would have something like this: >>>> When a UAS loopback mirror receives an SDP Offer with >>>> media-loopback, if the UAS implements [RFC5245] then it follows ICE >>>> procedures, including fallback to just sending STUN Binding >>>> Indications per Section 10 of ICE if the received Offer did not >>>> indicate ICE or there is an ICE mismatch condition. If the UAS >>>> does not implement [RFC5245], then it MUST at least follow the >>>> procedures of Section 10 of [RFC5245] and send STUN Binding >>>> Indications. In all cases, even if ICE is not actively used, the >>>> existence of the media-loopback indication in SDP indicates the >>>> far-end is capable of receiving and ignoring STUN Binding >>>> Indications, and the local UAS MUST send such as per Section 10 of >>>> [RFC5245] as if the SDP contained a candidate line. This is to >>>> ensure some initial packets gets sent to the loopback source, to >>>> create NAT bindings or open Firewall pinholes along the path, since >>>> RTP is not generated by the loopback mirror until RTP is received. >>>> >>> >>> I'd like to hear more people commenting on this. My understanding of >>> ICE Section 5.1/10 in this case is that it's for keep-alives and >>> hence you wouldn't send these messages initially (which is not to >>> say that couldn't be changed when used with loopback - the question >>> is how it differs from "real" ICE then). >>> >>>>>> 3) We specify that the media-loopback indication in SDP means the >>>>>> loopback-source supports receiving and ignoring STUN Binding >>>>>> Indications, so that following Section 10 of RFC 5245 the mirror >>>>>> MUST send STUN not no-op or comfort noise. >>>>>> 4) We put some text in the loopback-source about sources MUST >>>>>> support ignoring received STUN Binding Indications, not depend on >>>>>> getting them, etc. >>>>>> >>>>> This seems like a way forward that would keep us consistent with >>>>> current ICE procedures. We probably need to explore it in more >>>>> detail (and I'd welcome more comments on this as well), but it >>>>> seems promising. One question is the frequency with which these >>>>> STUN Binding Requests would be sent ? >>>> The frequency is in section 10, but I assume you mean when >>>> "inactive" mode is used in media-loopback? That's a tough one. In >>>> a normal call there would be no RTP in that mode, and since the >>>> tester may want to test that mode to see if it is causing problems >>>> then I think the mirror shouldn't send STUN even then. :( >>> I believe Section 10 would only apply to keep-alives in the scenario >>> being considered here (and hence inactive mode is fine). The issue, >>> I believe, is that you need these STUN binding packets sent >>> initially to punch a hole through the NAT, and I don't believe the >>> current RFC 5245 by itself will give you that. >>> >>> -- Flemming >>> >>> >>>> -hadriel >>>> >>>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From capelastegui@dit.upm.es Thu Nov 3 09:27:22 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD3B11E8129 for ; Thu, 3 Nov 2011 09:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5NzhGQgGeas for ; Thu, 3 Nov 2011 09:27:21 -0700 (PDT) Received: from mail.dit.upm.es (mail.dit.upm.es [IPv6:2001:720:1500:42:215:c5ff:fef6:86e4]) by ietfa.amsl.com (Postfix) with ESMTP id 8836911E8123 for ; Thu, 3 Nov 2011 09:27:21 -0700 (PDT) Received: from correo.dit.upm.es (correo.dit.upm.es [IPv6:2001:720:1500:42:250:56ff:fea2:1a03]) by mail.dit.upm.es (8.14.2/8.14.2) with ESMTP id pA3GQwAt018178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Nov 2011 17:26:58 +0100 Received: from delta (delta.dit.upm.es [138.4.7.204]) (authenticated bits=0) by correo.dit.upm.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pA3GQm7X008330 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 3 Nov 2011 17:26:48 +0100 From: "Pedro Capelastegui" To: "IETF - MMUSIC" , Date: Thu, 3 Nov 2011 17:27:00 +0100 Message-ID: <002801cc9a45$69afeda0$3d0fc8e0$@dit.upm.es> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcyaRS2Ds7CxkogiRQaA1geKYfHAxg== Content-Language: es Subject: [MMUSIC] 3D format negotiation in draft-greevenbosch-mmusic-signal-3d-format X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 16:27:22 -0000 Hi, Here are some further comments on draft-greevenbosch-mmusic-signal-3d-format. These are focused on the 3d format negotiation process, and specifically how the extension behaves when multiple 3d configuration options are offered. My main concern is that, in order to offer alternate 3d format configurations, the offerer has to include additional 'm=' lines in the SDP. Currently, each media descriptor can have a single 3d format, and each 3d format is associated to 1 or 2 media descriptors. This is not an issue in offers with a single 3d format (see examples 9.1, 9.2 and 9.3), but when several 3d formats are offered, the number of media descriptors multiplies. This can be observed in example 9.4, where 4 media descriptors are used in the offer, though the answerer is expected to reject all but two. In general, in order to provide N 3D format options for a 3D video stream,between N and 2N media descriptors will be required in the offered SDP, of which only one or two will be used. I think this proliferation of media descriptions has several drawbacks. For one, it goes against the general philosophy of SDP negotiation. Normally, when different possible configurations exist for a media stream, they are shown as different media formats within a single media descriptor. Using multiple media descriptors that actually refer to the same media stream (the 3D video stream, or a subset of it), and having the answerer reject all but the ones with the desired configuration breaks this model. In addition, this excess of 'm=' lines may have a negative effect when combined with techniques such as ICE, and could be confusing for 3d-unaware nodes. On the other hand, this is only a problem if user agents are expected to select between many 3d formats on an average session. Unfortunately, I think this will be the case. At the very least, a UA starting a 3D session should provide a single 3D format and the option not to use 3D. Apart from that, a 3D user agent intended to be interoperable with other UAs should support several 3D formats, including video+depth and transmission of 2 views. The solution, in my opinion, would be to shift away from the current model and instead associate each 3D format with a payload type within a media description. I will discuss how this can be done in a separate mail. Regards, Pedro From capelastegui@dit.upm.es Thu Nov 3 09:34:36 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D977011E8132 for ; Thu, 3 Nov 2011 09:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=-2.650, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46r-SKUrFGSX for ; Thu, 3 Nov 2011 09:34:36 -0700 (PDT) Received: from mail.dit.upm.es (mail.dit.upm.es [IPv6:2001:720:1500:42:215:c5ff:fef6:86e4]) by ietfa.amsl.com (Postfix) with ESMTP id AC64211E8110 for ; Thu, 3 Nov 2011 09:34:35 -0700 (PDT) Received: from correo.dit.upm.es (correo.dit.upm.es [IPv6:2001:720:1500:42:250:56ff:fea2:1a03]) by mail.dit.upm.es (8.14.2/8.14.2) with ESMTP id pA3GYU5o018335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Nov 2011 17:34:30 +0100 Received: from delta (delta.dit.upm.es [138.4.7.204]) (authenticated bits=0) by correo.dit.upm.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pA3GYIbu008726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 3 Nov 2011 17:34:19 +0100 From: "Pedro Capelastegui" To: "'IETF - MMUSIC'" , References: <002801cc9a45$69afeda0$3d0fc8e0$@dit.upm.es> In-Reply-To: <002801cc9a45$69afeda0$3d0fc8e0$@dit.upm.es> Date: Thu, 3 Nov 2011 17:34:31 +0100 Message-ID: <002901cc9a46$771e6290$655b27b0$@dit.upm.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKXCGBtb1yACvM5goToMvn0QrotsJQGewXg Content-Language: es Subject: Re: [MMUSIC] 3D format negotiation in draft-greevenbosch-mmusic-signal-3d-format X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 16:34:37 -0000 Hi, In the previous post, I argued against the 3D format negotiation = mechanism currently used in draft-greevenbosch-mmusic-signal-3d-format, and = suggested associating 3D formats with payload types instead. Here I explain how = this could be achieved. The process could be summarized as follows: 3d format configuration parameters are described in media level attributes (like in the current draft), but these attributes have a payload type as an additional = parameter: a=3D3dformat: <3dformat parameters> Each 3D media stream will be composed of one or two media descriptions, = each with one or more 3d format attributes. For each media description, an answerer would select one of the available media formats, with the = preferred combination of codec and 3d format. In order to keep complexity = manageable, the answerer would only be allowed to choose a single media format when = 3d is enabled. This still leaves us with the problem of declaring dependencies between media descriptions within a 3D media stream (e.g. stream B is the depth = map of stream A, or stream B is the right view and stream A is the left = one). This could be signaled with the =91a=3Ddepend=92 attribute (see RFC = 5583). As an example, here is how this system would work in the scenario shown = in section 9.4 of draft-greevenbosch-mmusic-signal-3d-format. The offerer = is trying to initiate a session with a 3D video stream which can have 2 possible configurations:=20 (1) 1 stream for video and one stream for a parallax map (2) 1 stream for the left view and one for the right view. This is what the offer SDP would look like v=3D0 o=3DAlice 2890844526 2890842807 IN IP4 131.163.72.4 s=3DThe technology of 3D-TV c=3DIN IP4 131.164.74.2 t=3D0 0 a=3Dgroup:3DS 1 2 m=3Dvideo 49170 RTP/AVP 99 100 a=3Drtpmap:99 H264/90000 a=3D3dFormat:99 2DA C a=3Drtpmap:100 H264/90000 a=3D3dFormat:100 SC L a=3Dmid:1 m=3Dvideo 49172 RTP/AVP 99 100 a=3Drtpmap:99 H264/90000 a=3D3dFormat:99 2DA P a=3Drtpmap:100 H264/90000 a=3D3dFormat:100 SC R a=3Dmid:2 a=3Ddepend 99 3dv 1:99; 100 3dv 1:100 m=3Daudio 52890 RTP/AVP 10 a=3Drtpmap:10 L16/16000/2 =913dv=92 would be a new dependency-type defined for use with 3d format. = The =91depend=92 attribute is tipically used in combination with =93DDP=94 = (decoding dependency) groups, though I think using it with =933DS=94 groups in = this scenario wouldn=92t go against the specification. This offer SDP has 2 video streams in a 3DS group, each with 2 possible configurations. The first one can be configured as a =91center=92 view = in a video+auxiliary map scheme, or as a left view in a simulcast scheme. The second media stream can be configured as a parallax map in a video+aux configuration, or as a right view in a simulcast configuration. Only = certain payload type combinations are viable, which is signaled in the = =91a=3Ddepend=92 line: video stream 2 can only be configured as a parallax map if video stream 1 is the center view, and it can only be configured as a right = view if stream 1 is the left view. The SDP answer would look like this, if the answerer chooses the "center view plus parallax map" option:=20 v=3D0 o=3DBob 2890844528 2890842809 IN IP4 131.163.72.5 s=3DThe technology of 3D-TV c=3DIN IP4 131.164.74.3 t=3D0 0 a=3Dgroup:3DS 1 2 m=3Dvideo 48170 RTP/AVP 99 a=3Drtpmap:99 H264/90000 a=3D3dFormat:99 2DA C a=3Dmid:1 m=3Dvideo 48172 RTP/AVP 99=20 a=3Drtpmap:99 H264/90000 a=3D3dFormat:99 2DA P a=3Dmid:2 a=3Ddepend 99 3dv 1:99; 100 3dv 1:100 m=3Daudio 52890 RTP/AVP 10 a=3Drtpmap:10 L16/16000/2 Compared to the SDPs used in draft-greevenbosch-mmusic-signal-3d-format, this offer/answer exchange only uses 3 media descriptions instead of 5. Also, including additional 3D formats would be more simple using this mechanism. Regards, Pedro -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Pedro Capelastegui Sent: Thursday, November 03, 2011 5:27 PM To: IETF - MMUSIC; Bert.Greevenbosch@huawei.com Subject: [MMUSIC] 3D format negotiation in draft-greevenbosch-mmusic-signal-3d-format Hi, Here are some further comments on draft-greevenbosch-mmusic-signal-3d-format. These are focused on the 3d format negotiation process, and specifically how the extension behaves = when multiple 3d configuration options are offered. My main concern is that, in order to offer alternate 3d format configurations, the offerer has to include additional 'm=3D' lines in = the SDP. Currently, each media descriptor can have a single 3d format, and each = 3d format is associated to 1 or 2 media descriptors. This is not an issue = in offers with a single 3d format (see examples 9.1, 9.2 and 9.3), but when several 3d formats are offered, the number of media descriptors = multiplies. This can be observed in example 9.4, where 4 media descriptors are used = in the offer, though the answerer is expected to reject all but two. In general, in order to provide N 3D format options for a 3D video stream,between N and 2N media descriptors will be required in the = offered SDP, of which only one or two will be used. I think this proliferation of media descriptions has several drawbacks. = For one, it goes against the general philosophy of SDP negotiation. = Normally, when different possible configurations exist for a media stream, they = are shown as different media formats within a single media descriptor. Using multiple media descriptors that actually refer to the same media stream = (the 3D video stream, or a subset of it), and having the answerer reject all = but the ones with the desired configuration breaks this model. In addition, = this excess of 'm=3D' lines may have a negative effect when combined with techniques such as ICE, and could be confusing for 3d-unaware nodes. On the other hand, this is only a problem if user agents are expected to select between many 3d formats on an average session. Unfortunately, I = think this will be the case. At the very least, a UA starting a 3D session = should provide a single 3D format and the option not to use 3D. Apart from = that, a 3D user agent intended to be interoperable with other UAs should support several 3D formats, including video+depth and transmission of 2 views.=20 The solution, in my opinion, would be to shift away from the current = model and instead associate each 3D format with a payload type within a media description. I will discuss how this can be done in a separate mail. Regards, Pedro _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic ----- No se encontraron virus en este mensaje. Comprobado por AVG - www.avg.com Versi=F3n: 10.0.1411 / Base de datos de virus: 2092/3992 - Fecha de publicaci=F3n: 11/02/11 From keith.drage@alcatel-lucent.com Thu Nov 3 18:02:19 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDE51F0C4C for ; Thu, 3 Nov 2011 18:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.161 X-Spam-Level: X-Spam-Status: No, score=-106.161 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_FR=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 ze2AEAyVglt8 for ; Thu, 3 Nov 2011 18:02:18 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 070F51F0C3D for ; Thu, 3 Nov 2011 18:02:17 -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 pA412CX5009224 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 Nov 2011 02:02:13 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 4 Nov 2011 02:02:12 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "Simo.Veikkolainen@nokia.com" Date: Fri, 4 Nov 2011 02:02:09 +0100 Thread-Topic: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt Thread-Index: AcyZiNzPvF88zF/4RzOlobdWyxj0eQBAkFRA Message-ID: References: <20111031120308.18508.69135.idtracker@ietfa.amsl.com> <4EAEF751.6000205@alum.mit.edu> <4EB18474.40701@alum.mit.edu> In-Reply-To: <4EB18474.40701@alum.mit.edu> 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-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 01:02:19 -0000 In regard to your question about the protocol discriminator, I don't see th= e text as saying ignore it, it is just saying it is outside the scope of th= is document. This document is saying how you take the delivered user data and correlate = it with something that is in the SDP. The protocol discriminator can form p= art of the checks of whether I am delivering the user data to the right app= lication in the first place along with what message I've received it in and= probably one or two other things, none of which have anything to do with t= his document. However I must admit I don't like specification by negatives (MUST NOT) whi= ch is what this is.=20 Maybe change the text as: The first three octets of the User-user information element specified in ITU-T Q.931 [ITU.Q931.1998] are the user-user information element ide= ntifier, length of user-user contents, and a protocol discriminator, follow= ed by the user information. An entity performing correlation MUST only com= pare the octets carrying the user information to the "cs-correlation:uuie" attribute (the user-user information element identifier, length of user-= user contents, and protocol discriminator are not used for this purpose). I've corrected some capitalization and a typo as well. Keith > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 02 November 2011 17:57 > To: Simo.Veikkolainen@nokia.com > Cc: mmusic@ietf.org; DRAGE, Keith (Keith) > Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt >=20 > Inline. >=20 > (Keith Drage - there is a question for you below.) >=20 > On 11/1/11 3:15 AM, Simo.Veikkolainen@nokia.com wrote: > > Hi Paul, > > See below. > > > >> -----Original Message----- > >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > >> Behalf Of ext Paul Kyzivat > >> Sent: 31 October, 2011 21:30 > >> To: mmusic@ietf.org > >> Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt > >> > >> Thanks. This clears up a lot. > >> In looking over the changes, I noted the following other things: > >> > >> Syntax (in 5.2.3.1 and 5.6): > >> > >> As written, this will allow individual correlation mechanisms to be > repeated, > >> possibly with differing values. E.g. > >> > >> a=3Dcs-correlation: dtmf:123 dtmf:456 > >> > >> I'm not sure, but I *doubt* you intend to allow that. > >> To address it, you have a couple of choices: > >> > >> - fiddle the syntax to disallow it. > >> - put in textual rules to forbid it. > > > > It seems I'm not really fluent with the syntax... We don't want to allo= w > repeating individual mechanisms. We'll take a look at the syntax again. >=20 > Its fairly easy to write the ABNF to allow each kind at most once if you > fix the order in which they may appear. >=20 > cs-correlation-attr=3D "cs-correlation:" corr-mechanisms > corr-mechanisms =3D [SP caller-id-mech] [SP uuie-mech] > [SP dtmf-mech] [SP ext-mech] >=20 > (This has the limitation that there must be a space before the first > mechanism.) >=20 > To allow them in any order is *possible* but unreasonably complex. If > you want that, then best to just do it with words. >=20 > >> In section 5.2.3.2, you have: > >> > >> For example, the numbers +358-9-123-4567 and 09-123-4567 > >> could be considered as the same number. > >> > >> This could be interpreted as indicating that the international E.164 > number > >> might contain separator characters. Based on your syntax, the one in > the cs- > >> correlation attribute can't have them. I'm not sure if the one receive= d > as > >> callerid info from the PSTN can have them or not. > > > > We should write +35891234567 and 091234567. >=20 > WFM >=20 > >> In section 5.2.3.3: > >> > >> The protocol discriminator must be specified *somewhere*. > >> Either you can specify a fixed one as part of this mechanism, or else > you must > >> allow it to be specified as part of the value. > > > > I was thinking the protocol discriminator is picked up by the CS > signaling stack, as it would for normal CS calls, and just comparing > octets 4...n of the received UUIE to the value exchanged in O/A would be > sufficient. If we need to define the value for the protocol discriminator= , > one option I guess could be value 0, which indicates User-specific > protocol according to Q.931. >=20 > So the recipient would ignore the protocol discriminator? > That seems pretty odd to me. But I will defer to someone who is more > familiar with use of these mechanisms in the PSTN. (Keith?) >=20 > Thanks, > Paul >=20 > >> In section 5.5.4: > >> > >> "If either party wishes to drop and reestablish an existing call..." > >> > >> This implies that one must use one o/a exchange to drop the existing > call and > >> another one to establish it again. That shouldn't be necessary. > >> Sending the same sort of offer one would do to establish the initial > session > >> (including a=3Dconnection:new) should be fine. > > > > Ok, we'll clarify that. > > > > Thanks > > Simo > > > >> Thanks, > >> Paul > >> > >> > >> On 10/31/11 8:06 AM, Simo.Veikkolainen@nokia.com wrote: > >>> Hi, > >>> We have submitted a new version of the sdp-cs draft > >> (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-09.txt), > >> addressing Paul's comments. > >>> > >>> Below is a list of changes in the -09 version: > >>> > >>> Number format > >>> - Use the term "international E.164 number" throughout the > >> document > >>> - Require a "+" sign in all international E.164 numbers > >>> > >>> Added the following lines to addresstype specification in 5.2.1: > >>> " > >>> When the is PSTN, the connection address is defined > >>> as follows: > >>> > >>> o an e164-address > >>> > >>> When the is "-", the connection address is defined > >>> as follows: > >>> > >>> o the value "-", signifying that the address is unknown. > >>> OR > >>> o any syntactically valid value, which is to be ignored.. > >>> " > >>> > >>> Syntax of cs-correlation changed in 5.2.3.1 > >>> > >>> UUIE protocol discriminator > >>> - Clarified that only the "User information" part of UUIE is to be > >> included as the value of uuie-mech, and used for comparing the incomin= g > >> UUIE > >>> - Added an OPEN ISSUE still here > >>> > >>> Moved the usage of "a=3Dconnection:existing" to 5.5.4 Modifying the > >> session. > >>> > >>> Added text in 5.5.4 on how connection reuse works. > >>> > >>> E.164 syntax in 5.6 > >>> - we didn't include a reference to RFC3966 since we don't want to > >>> include the visual separator, and otherwise the benefit of having the > >>> RFC as reference would be small > >>> > >>> Changed the number in the examples. +15551234 -> +35891234567 (I > know > >>> this at least is a syntactically correct representation J > >>> > >>> Things which did not make this version: > >>> > >>> TODO: Add example with CS audio/video stream. > >>> TODO: Security considerations needs more work based on Flemming's > >> earlier comments (including caller's E164 number in SDP). > >>> TODO: Clarification on the mechanism works with 3PCC. > >>> > >>> > >>> Thanks > >>> Simo > >>> > >>> > >>> -----Original Message----- > >>> From: i-d-announce-bounces@ietf.org > >>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext > >>> internet-drafts@ietf.org > >>> Sent: 31 October, 2011 14:03 > >>> To: i-d-announce@ietf.org > >>> Cc: mmusic@ietf.org > >>> Subject: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. This draft is a work item of the Multiparty Multimedia > Session > >> Control Working Group of the IETF. > >>> > >>> Title : Session Description Protocol (SDP) Extension For > Setting > >> Up Audio and Video Media Streams Over Circuit-Switched Bearers In The > >> Public Switched Telephone Network (PSTN) > >>> Author(s) : Miguel A. Garcia-Martin > >>> Simo Veikkolainen > >>> Filename : draft-ietf-mmusic-sdp-cs-09.txt > >>> Pages : 30 > >>> Date : 2011-10-31 > >>> > >>> This memo describes use cases, requirements, and protocol > extensions > >>> for using the Session Description Protocol (SDP) Offer/Answer > model > >>> for establishing audio and video media streams over circuit- > switched > >>> bearers in the Public Switched Telephone Network (PSTN). > >>> > >>> > >>> A URL for this Internet-Draft is: > >>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-09.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-mmusic-sdp-cs-09.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 > >>> _______________________________________________ > >>> mmusic mailing list > >>> mmusic@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mmusic > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic From Simo.Veikkolainen@nokia.com Fri Nov 4 02:22:58 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98C021F8BF6 for ; Fri, 4 Nov 2011 02:22:58 -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 ruxaKQpa-fbq for ; Fri, 4 Nov 2011 02:22:57 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7186C21F8B8C for ; Fri, 4 Nov 2011 02:22:57 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pA49Mka9001049; Fri, 4 Nov 2011 11:22:47 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Nov 2011 11:22:45 +0200 Received: from 008-AM1MPN1-025.mgdnok.nokia.com ([169.254.5.38]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.01.0339.002; Fri, 4 Nov 2011 10:22:45 +0100 From: To: , Thread-Topic: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt Thread-Index: AQHMl8UhGeJlmRQ8r02tioerLlQmapWWWu/ggABr1oCAANONoIACNw0AgAIJFICAAJx00A== Date: Fri, 4 Nov 2011 09:22:44 +0000 Message-ID: References: <20111031120308.18508.69135.idtracker@ietfa.amsl.com> <4EAEF751.6000205@alum.mit.edu> <4EB18474.40701@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.3.8.1 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IoNHS33Y/HxWJ1oQk11TrsiK7l56UaLot01u8oq9o1arzL3aohyu3SsnBstmm3TK2AgeuSSi9avT6Y4bpMG/0DMn4O/JO1EsgJOY4nb97cYA9R7pPmTV9nZ7Wd/8U2FfHBn1ryXoTkFmpfxTEI9gsiqyKQgJp5uFjsJ3u0edAPJ5a1F1Gxpoh7Bw+Dqpwv9qnP/m13CMssaaCW39ziLCeh+zvRpWzX6KvsvI+Qfva4MYkyz5Cnq9iDLzDbolk7/nbg== x-originating-ip: [85.156.80.209] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Nov 2011 09:22:45.0780 (UTC) FILETIME=[4FFF2540:01CC9AD3] X-Nokia-AV: Clean Cc: mmusic@ietf.org Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 09:22:58 -0000 > -----Original Message----- > From: ext DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > Sent: 04 November, 2011 03:02 > To: Paul Kyzivat; Veikkolainen Simo (Nokia-CTO/Helsinki) > Cc: mmusic@ietf.org > Subject: RE: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt >=20 > In regard to your question about the protocol discriminator, I don't see = the > text as saying ignore it, it is just saying it is outside the scope of th= is > document. Right. =20 > This document is saying how you take the delivered user data and correlat= e it > with something that is in the SDP. The protocol discriminator can form pa= rt of > the checks of whether I am delivering the user data to the right applicat= ion in > the first place along with what message I've received it in and probably = one > or two other things, none of which have anything to do with this document= . >=20 > However I must admit I don't like specification by negatives (MUST NOT) > which is what this is. >=20 > Maybe change the text as: >=20 > The first three octets of the User-user information element specified > in ITU-T Q.931 [ITU.Q931.1998] are the user-user information element > identifier, length of user-user contents, and a protocol discriminator, > followed by the user information. An entity performing correlation MUST > only compare > the octets carrying the user information to the "cs-correlation:uuie" > attribute (the user-user information element identifier, length of use= r-user > contents, and protocol discriminator are not used for this purpose). >=20 > I've corrected some capitalization and a typo as well. This proposal would work for me. Thanks, Simo =20 > Keith >=20 >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > Sent: 02 November 2011 17:57 > > To: Simo.Veikkolainen@nokia.com > > Cc: mmusic@ietf.org; DRAGE, Keith (Keith) > > Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt > > > > Inline. > > > > (Keith Drage - there is a question for you below.) > > > > On 11/1/11 3:15 AM, Simo.Veikkolainen@nokia.com wrote: > > > Hi Paul, > > > See below. > > > > > >> -----Original Message----- > > >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > >> Behalf Of ext Paul Kyzivat > > >> Sent: 31 October, 2011 21:30 > > >> To: mmusic@ietf.org > > >> Subject: Re: [MMUSIC] FW: I-D Action: > > >> draft-ietf-mmusic-sdp-cs-09.txt > > >> > > >> Thanks. This clears up a lot. > > >> In looking over the changes, I noted the following other things: > > >> > > >> Syntax (in 5.2.3.1 and 5.6): > > >> > > >> As written, this will allow individual correlation mechanisms to be > > repeated, > > >> possibly with differing values. E.g. > > >> > > >> a=3Dcs-correlation: dtmf:123 dtmf:456 > > >> > > >> I'm not sure, but I *doubt* you intend to allow that. > > >> To address it, you have a couple of choices: > > >> > > >> - fiddle the syntax to disallow it. > > >> - put in textual rules to forbid it. > > > > > > It seems I'm not really fluent with the syntax... We don't want to > > > allow > > repeating individual mechanisms. We'll take a look at the syntax again. > > > > Its fairly easy to write the ABNF to allow each kind at most once if > > you fix the order in which they may appear. > > > > cs-correlation-attr=3D "cs-correlation:" corr-mechanisms > > corr-mechanisms =3D [SP caller-id-mech] [SP uuie-mech] > > [SP dtmf-mech] [SP ext-mech] > > > > (This has the limitation that there must be a space before the first > > mechanism.) > > > > To allow them in any order is *possible* but unreasonably complex. If > > you want that, then best to just do it with words. > > > > >> In section 5.2.3.2, you have: > > >> > > >> For example, the numbers +358-9-123-4567 and 09-123-4567 > > >> could be considered as the same number. > > >> > > >> This could be interpreted as indicating that the international > > >> E.164 > > number > > >> might contain separator characters. Based on your syntax, the one > > >> in > > the cs- > > >> correlation attribute can't have them. I'm not sure if the one > > >> received > > as > > >> callerid info from the PSTN can have them or not. > > > > > > We should write +35891234567 and 091234567. > > > > WFM > > > > >> In section 5.2.3.3: > > >> > > >> The protocol discriminator must be specified *somewhere*. > > >> Either you can specify a fixed one as part of this mechanism, or > > >> else > > you must > > >> allow it to be specified as part of the value. > > > > > > I was thinking the protocol discriminator is picked up by the CS > > signaling stack, as it would for normal CS calls, and just comparing > > octets 4...n of the received UUIE to the value exchanged in O/A would > > be sufficient. If we need to define the value for the protocol > > discriminator, one option I guess could be value 0, which indicates > > User-specific protocol according to Q.931. > > > > So the recipient would ignore the protocol discriminator? > > That seems pretty odd to me. But I will defer to someone who is more > > familiar with use of these mechanisms in the PSTN. (Keith?) > > > > Thanks, > > Paul > > > > >> In section 5.5.4: > > >> > > >> "If either party wishes to drop and reestablish an existing call..." > > >> > > >> This implies that one must use one o/a exchange to drop the > > >> existing > > call and > > >> another one to establish it again. That shouldn't be necessary. > > >> Sending the same sort of offer one would do to establish the > > >> initial > > session > > >> (including a=3Dconnection:new) should be fine. > > > > > > Ok, we'll clarify that. > > > > > > Thanks > > > Simo > > > > > >> Thanks, > > >> Paul > > >> > > >> > > >> On 10/31/11 8:06 AM, Simo.Veikkolainen@nokia.com wrote: > > >>> Hi, > > >>> We have submitted a new version of the sdp-cs draft > > >> (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-09.tx > > >> t), > > >> addressing Paul's comments. > > >>> > > >>> Below is a list of changes in the -09 version: > > >>> > > >>> Number format > > >>> - Use the term "international E.164 number" throughout the > > >> document > > >>> - Require a "+" sign in all international E.164 numbers > > >>> > > >>> Added the following lines to addresstype specification in 5.2.1: > > >>> " > > >>> When the is PSTN, the connection address is defin= ed > > >>> as follows: > > >>> > > >>> o an e164-address > > >>> > > >>> When the is "-", the connection address is define= d > > >>> as follows: > > >>> > > >>> o the value "-", signifying that the address is unknown. > > >>> OR > > >>> o any syntactically valid value, which is to be ignored.. > > >>> " > > >>> > > >>> Syntax of cs-correlation changed in 5.2.3.1 > > >>> > > >>> UUIE protocol discriminator > > >>> - Clarified that only the "User information" part of UUIE is to be > > >> included as the value of uuie-mech, and used for comparing the > > >> incoming UUIE > > >>> - Added an OPEN ISSUE still here > > >>> > > >>> Moved the usage of "a=3Dconnection:existing" to 5.5.4 Modifying the > > >> session. > > >>> > > >>> Added text in 5.5.4 on how connection reuse works. > > >>> > > >>> E.164 syntax in 5.6 > > >>> - we didn't include a reference to RFC3966 since we don't want to > > >>> include the visual separator, and otherwise the benefit of having > > >>> the RFC as reference would be small > > >>> > > >>> Changed the number in the examples. +15551234 -> +35891234567 (I > > know > > >>> this at least is a syntactically correct representation J > > >>> > > >>> Things which did not make this version: > > >>> > > >>> TODO: Add example with CS audio/video stream. > > >>> TODO: Security considerations needs more work based on Flemming's > > >> earlier comments (including caller's E164 number in SDP). > > >>> TODO: Clarification on the mechanism works with 3PCC. > > >>> > > >>> > > >>> Thanks > > >>> Simo > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: i-d-announce-bounces@ietf.org > > >>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext > > >>> internet-drafts@ietf.org > > >>> Sent: 31 October, 2011 14:03 > > >>> To: i-d-announce@ietf.org > > >>> Cc: mmusic@ietf.org > > >>> Subject: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt > > >>> > > >>> A New Internet-Draft is available from the on-line Internet-Drafts > > >> directories. This draft is a work item of the Multiparty Multimedia > > Session > > >> Control Working Group of the IETF. > > >>> > > >>> Title : Session Description Protocol (SDP) Extension For > > Setting > > >> Up Audio and Video Media Streams Over Circuit-Switched Bearers In > > >> The Public Switched Telephone Network (PSTN) > > >>> Author(s) : Miguel A. Garcia-Martin > > >>> Simo Veikkolainen > > >>> Filename : draft-ietf-mmusic-sdp-cs-09.txt > > >>> Pages : 30 > > >>> Date : 2011-10-31 > > >>> > > >>> This memo describes use cases, requirements, and protocol > > extensions > > >>> for using the Session Description Protocol (SDP) Offer/Answer > > model > > >>> for establishing audio and video media streams over circuit- > > switched > > >>> bearers in the Public Switched Telephone Network (PSTN). > > >>> > > >>> > > >>> A URL for this Internet-Draft is: > > >>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-09.tx > > >>> t > > >>> > > >>> 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-mmusic-sdp-cs-09.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 > > >>> _______________________________________________ > > >>> mmusic mailing list > > >>> mmusic@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mmusic > > >> > > >> _______________________________________________ > > >> mmusic mailing list > > >> mmusic@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mmusic From Simo.Veikkolainen@nokia.com Fri Nov 4 02:24:17 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940C021F8B8C for ; Fri, 4 Nov 2011 02:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 okAI4mU+t3IJ for ; Fri, 4 Nov 2011 02:24:16 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5142B21F8BF6 for ; Fri, 4 Nov 2011 02:24:15 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pA49OBLL008263; Fri, 4 Nov 2011 11:24:12 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Nov 2011 11:24:10 +0200 Received: from 008-AM1MPN1-025.mgdnok.nokia.com ([169.254.5.38]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.01.0339.002; Fri, 4 Nov 2011 10:24:10 +0100 From: To: Thread-Topic: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt Thread-Index: AQHMl8UhGeJlmRQ8r02tioerLlQmapWWWu/ggABr1oCAANONoIACNw0AgAKlxYA= Date: Fri, 4 Nov 2011 09:24:09 +0000 Message-ID: References: <20111031120308.18508.69135.idtracker@ietfa.amsl.com> <4EAEF751.6000205@alum.mit.edu> <4EB18474.40701@alum.mit.edu> In-Reply-To: <4EB18474.40701@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.3.8.1 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IoNHS33Y/HxWJ1oQk11TrsiK7l56UaLot01u8oq9o1arzL3aohyu3SsnBstmm3TK2AgeuSSi9avT6Y4bpMG/0DMn4O/JO1EsgJOY4nb97cYA9R7pPmTV9nZ7Wd/8U2FfHBn1ryXoTkFmpfxTEI9gsiqyKQgJp5uFjsJ3u0edAPJ5a1F1Gxpoh7Bw+Dqpwv9qnP/m13CMssaaCW39ziLCeh+zvRpWzX6KvsvI+Qfva4MYkyz5Cnq9iDLzDbolk7/nbg== x-originating-ip: [85.156.80.209] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 04 Nov 2011 09:24:11.0091 (UTC) FILETIME=[82D89230:01CC9AD3] X-Nokia-AV: Clean Cc: drage@lucent.com, mmusic@ietf.org Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 09:24:17 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZXh0IFBhdWwgS3l6aXZh dCBbbWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdV0NCj4gU2VudDogMDIgTm92ZW1iZXIsIDIw MTEgMTk6NTcNCj4gVG86IFZlaWtrb2xhaW5lbiBTaW1vIChOb2tpYS1DVE8vSGVsc2lua2kpDQo+ IENjOiBtbXVzaWNAaWV0Zi5vcmc7IEtlaXRoIERyYWdlDQo+IFN1YmplY3Q6IFJlOiBbTU1VU0lD XSBGVzogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLWNzLTA5LnR4dA0KPiANCj4g SW5saW5lLg0KPiANCj4gKEtlaXRoIERyYWdlIC0gdGhlcmUgaXMgYSBxdWVzdGlvbiBmb3IgeW91 IGJlbG93LikNCj4gDQo+IE9uIDExLzEvMTEgMzoxNSBBTSwgU2ltby5WZWlra29sYWluZW5Abm9r aWEuY29tIHdyb3RlOg0KPiA+IEhpIFBhdWwsDQo+ID4gU2VlIGJlbG93Lg0KPiA+DQo+ID4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IG1tdXNpYy1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4+IEJlaGFsZiBPZiBl eHQgUGF1bCBLeXppdmF0DQo+ID4+IFNlbnQ6IDMxIE9jdG9iZXIsIDIwMTEgMjE6MzANCj4gPj4g VG86IG1tdXNpY0BpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW01NVVNJQ10gRlc6IEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtbW11c2ljLXNkcC1jcy0wOS50eHQNCj4gPj4NCj4gPj4gVGhhbmtz LiBUaGlzIGNsZWFycyB1cCBhIGxvdC4NCj4gPj4gSW4gbG9va2luZyBvdmVyIHRoZSBjaGFuZ2Vz LCBJIG5vdGVkIHRoZSBmb2xsb3dpbmcgb3RoZXIgdGhpbmdzOg0KPiA+Pg0KPiA+PiBTeW50YXgg KGluIDUuMi4zLjEgYW5kIDUuNik6DQo+ID4+DQo+ID4+IEFzIHdyaXR0ZW4sIHRoaXMgd2lsbCBh bGxvdyBpbmRpdmlkdWFsIGNvcnJlbGF0aW9uIG1lY2hhbmlzbXMgdG8gYmUNCj4gPj4gcmVwZWF0 ZWQsIHBvc3NpYmx5IHdpdGggZGlmZmVyaW5nIHZhbHVlcy4gRS5nLg0KPiA+Pg0KPiA+PiBhPWNz LWNvcnJlbGF0aW9uOiBkdG1mOjEyMyBkdG1mOjQ1Ng0KPiA+Pg0KPiA+PiBJJ20gbm90IHN1cmUs IGJ1dCBJICpkb3VidCogeW91IGludGVuZCB0byBhbGxvdyB0aGF0Lg0KPiA+PiBUbyBhZGRyZXNz IGl0LCB5b3UgaGF2ZSBhIGNvdXBsZSBvZiBjaG9pY2VzOg0KPiA+Pg0KPiA+PiAtIGZpZGRsZSB0 aGUgc3ludGF4IHRvIGRpc2FsbG93IGl0Lg0KPiA+PiAtIHB1dCBpbiB0ZXh0dWFsIHJ1bGVzIHRv IGZvcmJpZCBpdC4NCj4gPg0KPiA+IEl0IHNlZW1zIEknbSBub3QgcmVhbGx5IGZsdWVudCB3aXRo IHRoZSBzeW50YXguLi4gV2UgZG9uJ3Qgd2FudCB0byBhbGxvdw0KPiByZXBlYXRpbmcgaW5kaXZp ZHVhbCBtZWNoYW5pc21zLiBXZSdsbCB0YWtlIGEgbG9vayBhdCB0aGUgc3ludGF4IGFnYWluLg0K PiANCj4gSXRzIGZhaXJseSBlYXN5IHRvIHdyaXRlIHRoZSBBQk5GIHRvIGFsbG93IGVhY2gga2lu ZCBhdCBtb3N0IG9uY2UgaWYgeW91IGZpeCB0aGUNCj4gb3JkZXIgaW4gd2hpY2ggdGhleSBtYXkg YXBwZWFyLg0KPiANCj4gICAgICAgICAgY3MtY29ycmVsYXRpb24tYXR0cj0gImNzLWNvcnJlbGF0 aW9uOiIgY29yci1tZWNoYW5pc21zDQo+ICAgICAgICAgIGNvcnItbWVjaGFuaXNtcyAgICA9IFtT UCBjYWxsZXItaWQtbWVjaF0gW1NQIHV1aWUtbWVjaF0NCj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgW1NQIGR0bWYtbWVjaF0gW1NQIGV4dC1tZWNoXQ0KPiANCj4gKFRoaXMgaGFzIHRo ZSBsaW1pdGF0aW9uIHRoYXQgdGhlcmUgbXVzdCBiZSBhIHNwYWNlIGJlZm9yZSB0aGUgZmlyc3QN Cj4gbWVjaGFuaXNtLikNCj4gDQo+IFRvIGFsbG93IHRoZW0gaW4gYW55IG9yZGVyIGlzICpwb3Nz aWJsZSogYnV0IHVucmVhc29uYWJseSBjb21wbGV4LiBJZiB5b3UNCj4gd2FudCB0aGF0LCB0aGVu IGJlc3QgdG8ganVzdCBkbyBpdCB3aXRoIHdvcmRzLg0KDQpGaXhlZCBvcmRlciBpcyBmaW5lLiBJ J2xsIGZpeCB0aGUgc3ludGF4IGFjY29yZGluZyB0byB0aGlzLg0KDQpUaGFua3MNClNpbW8NCiAN Cj4gPj4gSW4gc2VjdGlvbiA1LjIuMy4yLCB5b3UgaGF2ZToNCj4gPj4NCj4gPj4gICAgICBGb3Ig ZXhhbXBsZSwgdGhlIG51bWJlcnMgKzM1OC05LTEyMy00NTY3IGFuZCAwOS0xMjMtNDU2Nw0KPiA+ PiAgICAgIGNvdWxkIGJlIGNvbnNpZGVyZWQgYXMgdGhlIHNhbWUgbnVtYmVyLg0KPiA+Pg0KPiA+ PiBUaGlzIGNvdWxkIGJlIGludGVycHJldGVkIGFzIGluZGljYXRpbmcgdGhhdCB0aGUgaW50ZXJu YXRpb25hbCBFLjE2NA0KPiA+PiBudW1iZXIgbWlnaHQgY29udGFpbiBzZXBhcmF0b3IgY2hhcmFj dGVycy4gQmFzZWQgb24geW91ciBzeW50YXgsIHRoZQ0KPiA+PiBvbmUgaW4gdGhlIGNzLSBjb3Jy ZWxhdGlvbiBhdHRyaWJ1dGUgY2FuJ3QgaGF2ZSB0aGVtLiBJJ20gbm90IHN1cmUgaWYNCj4gPj4g dGhlIG9uZSByZWNlaXZlZCBhcyBjYWxsZXJpZCBpbmZvIGZyb20gdGhlIFBTVE4gY2FuIGhhdmUg dGhlbSBvciBub3QuDQo+ID4NCj4gPiBXZSBzaG91bGQgd3JpdGUgKzM1ODkxMjM0NTY3IGFuZCAw OTEyMzQ1NjcuDQo+IA0KPiBXRk0NCj4gDQo+ID4+IEluIHNlY3Rpb24gNS4yLjMuMzoNCj4gPj4N Cj4gPj4gVGhlIHByb3RvY29sIGRpc2NyaW1pbmF0b3IgbXVzdCBiZSBzcGVjaWZpZWQgKnNvbWV3 aGVyZSouDQo+ID4+IEVpdGhlciB5b3UgY2FuIHNwZWNpZnkgYSBmaXhlZCBvbmUgYXMgcGFydCBv ZiB0aGlzIG1lY2hhbmlzbSwgb3IgZWxzZQ0KPiA+PiB5b3UgbXVzdCBhbGxvdyBpdCB0byBiZSBz cGVjaWZpZWQgYXMgcGFydCBvZiB0aGUgdmFsdWUuDQo+ID4NCj4gPiBJIHdhcyB0aGlua2luZyB0 aGUgcHJvdG9jb2wgZGlzY3JpbWluYXRvciBpcyBwaWNrZWQgdXAgYnkgdGhlIENTIHNpZ25hbGlu Zw0KPiBzdGFjaywgYXMgaXQgd291bGQgZm9yIG5vcm1hbCBDUyBjYWxscywgYW5kIGp1c3QgY29t cGFyaW5nIG9jdGV0cyA0Li4ubiAgb2YgdGhlDQo+IHJlY2VpdmVkIFVVSUUgdG8gdGhlIHZhbHVl IGV4Y2hhbmdlZCBpbiBPL0Egd291bGQgYmUgc3VmZmljaWVudC4gSWYgd2UgbmVlZA0KPiB0byBk ZWZpbmUgdGhlIHZhbHVlIGZvciB0aGUgcHJvdG9jb2wgZGlzY3JpbWluYXRvciwgb25lIG9wdGlv biBJIGd1ZXNzIGNvdWxkDQo+IGJlIHZhbHVlIDAsIHdoaWNoIGluZGljYXRlcyBVc2VyLXNwZWNp ZmljIHByb3RvY29sIGFjY29yZGluZyB0byBRLjkzMS4NCj4gDQo+IFNvIHRoZSByZWNpcGllbnQg d291bGQgaWdub3JlIHRoZSBwcm90b2NvbCBkaXNjcmltaW5hdG9yPw0KPiBUaGF0IHNlZW1zIHBy ZXR0eSBvZGQgdG8gbWUuIEJ1dCBJIHdpbGwgZGVmZXIgdG8gc29tZW9uZSB3aG8gaXMgbW9yZQ0K PiBmYW1pbGlhciB3aXRoIHVzZSBvZiB0aGVzZSBtZWNoYW5pc21zIGluIHRoZSBQU1ROLiAoS2Vp dGg/KQ0KPiANCj4gCVRoYW5rcywNCj4gCVBhdWwNCj4gDQo+ID4+IEluIHNlY3Rpb24gNS41LjQ6 DQo+ID4+DQo+ID4+ICJJZiBlaXRoZXIgcGFydHkgd2lzaGVzIHRvIGRyb3AgYW5kIHJlZXN0YWJs aXNoIGFuIGV4aXN0aW5nIGNhbGwuLi4iDQo+ID4+DQo+ID4+IFRoaXMgaW1wbGllcyB0aGF0IG9u ZSBtdXN0IHVzZSBvbmUgby9hIGV4Y2hhbmdlIHRvIGRyb3AgdGhlIGV4aXN0aW5nDQo+ID4+IGNh bGwgYW5kIGFub3RoZXIgb25lIHRvIGVzdGFibGlzaCBpdCBhZ2Fpbi4gVGhhdCBzaG91bGRuJ3Qg YmUgbmVjZXNzYXJ5Lg0KPiA+PiBTZW5kaW5nIHRoZSBzYW1lIHNvcnQgb2Ygb2ZmZXIgb25lIHdv dWxkIGRvIHRvIGVzdGFibGlzaCB0aGUgaW5pdGlhbA0KPiA+PiBzZXNzaW9uIChpbmNsdWRpbmcg YT1jb25uZWN0aW9uOm5ldykgc2hvdWxkIGJlIGZpbmUuDQo+ID4NCj4gPiBPaywgd2UnbGwgY2xh cmlmeSB0aGF0Lg0KPiA+DQo+ID4gVGhhbmtzDQo+ID4gU2ltbw0KPiA+DQo+ID4+IAlUaGFua3Ms DQo+ID4+IAlQYXVsDQo+ID4+DQo+ID4+DQo+ID4+IE9uIDEwLzMxLzExIDg6MDYgQU0sIFNpbW8u VmVpa2tvbGFpbmVuQG5va2lhLmNvbSB3cm90ZToNCj4gPj4+IEhpLA0KPiA+Pj4gV2UgaGF2ZSBz dWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUgc2RwLWNzIGRyYWZ0DQo+ID4+IChodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtY3MtMDku dHh0KQ0KPiA+PiAsDQo+ID4+IGFkZHJlc3NpbmcgUGF1bCdzIGNvbW1lbnRzLg0KPiA+Pj4NCj4g Pj4+IEJlbG93IGlzIGEgbGlzdCBvZiBjaGFuZ2VzIGluIHRoZSAtMDkgdmVyc2lvbjoNCj4gPj4+ DQo+ID4+PiBOdW1iZXIgZm9ybWF0DQo+ID4+PiAtCVVzZSB0aGUgdGVybSDigJxpbnRlcm5hdGlv bmFsIEUuMTY0IG51bWJlcuKAnSB0aHJvdWdob3V0IHRoZQ0KPiA+PiBkb2N1bWVudA0KPiA+Pj4g LQlSZXF1aXJlIGEg4oCcK+KAnSBzaWduIGluIGFsbCBpbnRlcm5hdGlvbmFsIEUuMTY0IG51bWJl cnMNCj4gPj4+DQo+ID4+PiBBZGRlZCB0aGUgZm9sbG93aW5nIGxpbmVzIHRvIGFkZHJlc3N0eXBl IHNwZWNpZmljYXRpb24gaW4gNS4yLjE6DQo+ID4+PiDigJwNCj4gPj4+ICAgICAgIFdoZW4gdGhl PGFkZHJ0eXBlPiAgIGlzIFBTVE4sIHRoZSBjb25uZWN0aW9uIGFkZHJlc3MgaXMgZGVmaW5lZA0K PiA+Pj4gICAgICAgYXMgZm9sbG93czoNCj4gPj4+DQo+ID4+PiAgICAgICBvICBhbiBlMTY0LWFk ZHJlc3MNCj4gPj4+DQo+ID4+PiAgICAgICBXaGVuIHRoZTxhZGRydHlwZT4gICBpcyAiLSIsIHRo ZSBjb25uZWN0aW9uIGFkZHJlc3MgaXMgZGVmaW5lZA0KPiA+Pj4gICAgICAgYXMgZm9sbG93czoN Cj4gPj4+DQo+ID4+PiAgICAgICBvICB0aGUgdmFsdWUgIi0iLCBzaWduaWZ5aW5nIHRoYXQgdGhl IGFkZHJlc3MgaXMgdW5rbm93bi4NCj4gPj4+IE9SDQo+ID4+PiAgICAgICBvICBhbnkgc3ludGFj dGljYWxseSB2YWxpZCB2YWx1ZSwgd2hpY2ggaXMgdG8gYmUgaWdub3JlZC4uDQo+ID4+PiDigJwN Cj4gPj4+DQo+ID4+PiBTeW50YXggb2YgY3MtY29ycmVsYXRpb24gY2hhbmdlZCBpbiA1LjIuMy4x DQo+ID4+Pg0KPiA+Pj4gVVVJRSBwcm90b2NvbCBkaXNjcmltaW5hdG9yDQo+ID4+PiAtCUNsYXJp ZmllZCB0aGF0IG9ubHkgdGhlIOKAnFVzZXIgaW5mb3JtYXRpb27igJ0gcGFydCBvZiBVVUlFIGlz IHRvIGJlDQo+ID4+IGluY2x1ZGVkIGFzIHRoZSB2YWx1ZSBvZiB1dWllLW1lY2gsIGFuZCB1c2Vk IGZvciBjb21wYXJpbmcgdGhlDQo+ID4+IGluY29taW5nIFVVSUUNCj4gPj4+IC0JQWRkZWQgYW4g T1BFTiBJU1NVRSBzdGlsbCBoZXJlDQo+ID4+Pg0KPiA+Pj4gTW92ZWQgdGhlIHVzYWdlIG9mIOKA nGE9Y29ubmVjdGlvbjpleGlzdGluZ+KAnSB0byA1LjUuNCBNb2RpZnlpbmcgdGhlDQo+ID4+IHNl c3Npb24uDQo+ID4+Pg0KPiA+Pj4gQWRkZWQgdGV4dCBpbiA1LjUuNCBvbiBob3cgY29ubmVjdGlv biByZXVzZSB3b3Jrcy4NCj4gPj4+DQo+ID4+PiBFLjE2NCBzeW50YXggaW4gNS42DQo+ID4+PiAt IHdlIGRpZG7igJl0IGluY2x1ZGUgYSByZWZlcmVuY2UgdG8gUkZDMzk2NiBzaW5jZSB3ZSBkb27i gJl0IHdhbnQgdG8NCj4gPj4+IGluY2x1ZGUgdGhlIHZpc3VhbCBzZXBhcmF0b3IsIGFuZCBvdGhl cndpc2UgdGhlIGJlbmVmaXQgb2YgaGF2aW5nDQo+ID4+PiB0aGUgUkZDIGFzIHJlZmVyZW5jZSB3 b3VsZCBiZSBzbWFsbA0KPiA+Pj4NCj4gPj4+IENoYW5nZWQgdGhlIG51bWJlciBpbiB0aGUgZXhh bXBsZXMuICsxNTU1MTIzNCAtPiAgICszNTg5MTIzNDU2NyAoSQ0KPiBrbm93DQo+ID4+PiB0aGlz IGF0IGxlYXN0IGlzIGEgc3ludGFjdGljYWxseSBjb3JyZWN0IHJlcHJlc2VudGF0aW9uIEoNCj4g Pj4+DQo+ID4+PiBUaGluZ3Mgd2hpY2ggZGlkIG5vdCBtYWtlIHRoaXMgdmVyc2lvbjoNCj4gPj4+ DQo+ID4+PiBUT0RPOiBBZGQgZXhhbXBsZSB3aXRoIENTIGF1ZGlvL3ZpZGVvIHN0cmVhbS4NCj4g Pj4+IFRPRE86IFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIG5lZWRzIG1vcmUgd29yayBiYXNlZCBv biBGbGVtbWluZydzDQo+ID4+IGVhcmxpZXIgY29tbWVudHMgKGluY2x1ZGluZyBjYWxsZXIncyBF MTY0IG51bWJlciBpbiBTRFApLg0KPiA+Pj4gVE9ETzogQ2xhcmlmaWNhdGlvbiBvbiB0aGUgbWVj aGFuaXNtIHdvcmtzIHdpdGggM1BDQy4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gVGhhbmtzDQo+ID4+ PiBTaW1vDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4+PiBGcm9tOiBpLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZw0KPiA+Pj4gW21haWx0bzpp LWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dA0KPiA+Pj4gaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+ID4+PiBTZW50OiAzMSBPY3RvYmVyLCAyMDExIDE0OjAz DQo+ID4+PiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+ID4+PiBDYzogbW11c2ljQGlldGYu b3JnDQo+ID4+PiBTdWJqZWN0OiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW1tdXNpYy1zZHAtY3Mt MDkudHh0DQo+ID4+Pg0KPiA+Pj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZy b20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+ID4+IGRpcmVjdG9yaWVzLiBUaGlzIGRy YWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBNdWx0aXBhcnR5IE11bHRpbWVkaWENCj4gPj4gU2Vz c2lvbiBDb250cm9sIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+ID4+Pg0KPiA+Pj4gCVRp dGxlICAgICAgICAgICA6IFNlc3Npb24gRGVzY3JpcHRpb24gUHJvdG9jb2wgKFNEUCkgRXh0ZW5z aW9uIEZvciBTZXR0aW5nDQo+ID4+IFVwIEF1ZGlvIGFuZCBWaWRlbyBNZWRpYSBTdHJlYW1zIE92 ZXIgQ2lyY3VpdC1Td2l0Y2hlZCBCZWFyZXJzIEluIFRoZQ0KPiA+PiBQdWJsaWMgU3dpdGNoZWQg VGVsZXBob25lIE5ldHdvcmsgKFBTVE4pDQo+ID4+PiAJQXV0aG9yKHMpICAgICAgIDogTWlndWVs IEEuIEdhcmNpYS1NYXJ0aW4NCj4gPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTaW1v IFZlaWtrb2xhaW5lbg0KPiA+Pj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtbW11c2lj LXNkcC1jcy0wOS50eHQNCj4gPj4+IAlQYWdlcyAgICAgICAgICAgOiAzMA0KPiA+Pj4gCURhdGUg ICAgICAgICAgICA6IDIwMTEtMTAtMzENCj4gPj4+DQo+ID4+PiAgICAgIFRoaXMgbWVtbyBkZXNj cmliZXMgdXNlIGNhc2VzLCByZXF1aXJlbWVudHMsIGFuZCBwcm90b2NvbA0KPiBleHRlbnNpb25z DQo+ID4+PiAgICAgIGZvciB1c2luZyB0aGUgU2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCAo U0RQKSBPZmZlci9BbnN3ZXIgbW9kZWwNCj4gPj4+ICAgICAgZm9yIGVzdGFibGlzaGluZyBhdWRp byBhbmQgdmlkZW8gbWVkaWEgc3RyZWFtcyBvdmVyIGNpcmN1aXQtc3dpdGNoZWQNCj4gPj4+ICAg ICAgYmVhcmVycyBpbiB0aGUgUHVibGljIFN3aXRjaGVkIFRlbGVwaG9uZSBOZXR3b3JrIChQU1RO KS4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6 DQo+ID4+PiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1t dXNpYy1zZHAtY3MtMDkudHh0DQo+ID4+Pg0KPiA+Pj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNv IGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiA+Pj4gZnRwOi8vZnRwLmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy8NCj4gPj4+DQo+ID4+PiBUaGlzIEludGVybmV0LURyYWZ0IGNhbiBi ZSByZXRyaWV2ZWQgYXQ6DQo+ID4+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWlldGYtbW11c2ljLXNkcC1jcy0wOS50eHQNCj4gPj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+PiBJLUQtQW5ub3VuY2UgbWFpbGlu ZyBsaXN0DQo+ID4+PiBJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCj4gPj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo+ID4+PiBJbnRlcm5ldC1EcmFm dCBkaXJlY3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCBvcg0KPiA+Pj4g ZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCj4gPj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+PiBtbXVzaWMgbWFp bGluZyBsaXN0DQo+ID4+PiBtbXVzaWNAaWV0Zi5vcmcNCj4gPj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IG1tdXNpYyBtYWlsaW5nIGxpc3QN Cj4gPj4gbW11c2ljQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbW11c2ljDQoNCg== From pkyzivat@alum.mit.edu Fri Nov 4 10:21:21 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D5511E8086 for ; Fri, 4 Nov 2011 10:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, 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 xTfDvAmEPCzZ for ; Fri, 4 Nov 2011 10:21:20 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1C72511E8082 for ; Fri, 4 Nov 2011 10:21:18 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta05.westchester.pa.mail.comcast.net with comcast id t2Cb1h0071c6gX8555MKVb; Fri, 04 Nov 2011 17:21:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta23.westchester.pa.mail.comcast.net with comcast id t5MJ1h01M0tdiYw3j5MKVb; Fri, 04 Nov 2011 17:21:19 +0000 Message-ID: <4EB41F0D.4050001@alum.mit.edu> Date: Fri, 04 Nov 2011 13:21:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <20111031120308.18508.69135.idtracker@ietfa.amsl.com> <4EAEF751.6000205@alum.mit.edu> <4EB18474.40701@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 17:21:21 -0000 On 11/3/11 9:02 PM, DRAGE, Keith (Keith) wrote: > In regard to your question about the protocol discriminator, I don't see the text as saying ignore it, it is just saying it is outside the scope of this document. > > This document is saying how you take the delivered user data and correlate it with something that is in the SDP. The protocol discriminator can form part of the checks of whether I am delivering the user data to the right application in the first place along with what message I've received it in and probably one or two other things, none of which have anything to do with this document. > > However I must admit I don't like specification by negatives (MUST NOT) which is what this is. > > Maybe change the text as: > > The first three octets of the User-user information element specified > in ITU-T Q.931 [ITU.Q931.1998] are the user-user information element identifier, length of user-user contents, and a protocol discriminator, followed by the user information. An entity performing correlation MUST only compare > the octets carrying the user information to the "cs-correlation:uuie" > attribute (the user-user information element identifier, length of user-user contents, and protocol discriminator are not used for this purpose). > > I've corrected some capitalization and a typo as well. This still seems problematic to me. The UUIE is sent by one endpoint and received by the other. If the protocol discriminator is not signaled in the SDP, and its also not fixed by the spec, then it must be chosen by the endpoint initiating the cs, and won't be known to the recipient. If the recipient puts *any* limitations on what it is, then it will fail if the sender chooses something else. In my book that means the recipient must ignore the protocol discriminator for this to work. Does it matter what discriminator is used, or cause any harm to ignore it? I don't know. I suppose it depends on how these things are used in the PSTN. Does anything enforce consistency between the discriminator and the content? Does anything restrict what discriminators may be used? If the discriminator is so unimportant that it can be ignored, then why is it present at all? Just to be safe, why not either: - include the discriminator in the string; OR - just pick a discriminator and wire it into this document Thanks, Paul From keith.drage@alcatel-lucent.com Fri Nov 4 11:02:39 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A7A11E8085 for ; Fri, 4 Nov 2011 11:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.165 X-Spam-Level: X-Spam-Status: No, score=-106.165 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_EQ_FR=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 gZwyopuSuLsw for ; Fri, 4 Nov 2011 11:02:37 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4E72611E807F for ; Fri, 4 Nov 2011 11:02:37 -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 pA4I2WxM031910 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 Nov 2011 19:02:32 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 4 Nov 2011 19:02:32 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat Date: Fri, 4 Nov 2011 19:02:29 +0100 Thread-Topic: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt Thread-Index: AcybFi7ABLFnfg6lQn624M1wWPNQVQAA02QA Message-ID: References: <20111031120308.18508.69135.idtracker@ietfa.amsl.com> <4EAEF751.6000205@alum.mit.edu> <4EB18474.40701@alum.mit.edu> <4EB41F0D.4050001@alum.mit.edu> In-Reply-To: <4EB41F0D.4050001@alum.mit.edu> 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-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 18:02:39 -0000 The protocol discriminator is only one of the variables. Essentially there are a number of things that can vary such as: - what purpose am I doing this correlation for in the first place. Section = 1 of the document mentions a number of use cases but none of this document = describes how I actually use this mechanism within that use case (and that = needs to be agreed between both ends before it can occur) - which correlation transport mechanism am I using (the document provides a= t least three in 5.2.3.2, 5.2.3.3 and 5.2.3.4), and the one you choose depe= nds on what is available end to end within that overall use case (and again= that needs to be agreed between both ends before it can occur). So I very much see this document as providing part of a toolkit which I plu= g into a much wider usage. It is not the part of this document to specify t= hat wider usage.=20 I believe 3GPP has one document that specifies how these get pulled togethe= r for one specific use case. Other groups and even IETF may have other use = cases that need a similar tool. I don't think it is part of this document to specify those use cases, and I= think it is just sufficient to know they exist, and that standards can be = applied elsewhere to deal with the options available in using this document= . Keith > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 > Sent: 04 November 2011 17:21 > To: DRAGE, Keith (Keith) > Cc: Simo.Veikkolainen@nokia.com; mmusic@ietf.org > Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt >=20 > On 11/3/11 9:02 PM, DRAGE, Keith (Keith) wrote: > > In regard to your question about the protocol=20 > discriminator, I don't see the text as saying ignore it, it=20 > is just saying it is outside the scope of this document. > > > > This document is saying how you take the delivered user=20 > data and correlate it with something that is in the SDP. The=20 > protocol discriminator can form part of the checks of whether=20 > I am delivering the user data to the right application in the=20 > first place along with what message I've received it in and=20 > probably one or two other things, none of which have anything=20 > to do with this document. > > > > However I must admit I don't like specification by=20 > negatives (MUST NOT) which is what this is. > > > > Maybe change the text as: > > > > The first three octets of the User-user information=20 > element specified > > in ITU-T Q.931 [ITU.Q931.1998] are the user-user=20 > information element identifier, length of user-user contents,=20 > and a protocol discriminator, followed by the user=20 > information. An entity performing correlation MUST only compare > > the octets carrying the user information to the=20 > "cs-correlation:uuie" > > attribute (the user-user information element=20 > identifier, length of user-user contents, and protocol=20 > discriminator are not used for this purpose). > > > > I've corrected some capitalization and a typo as well. >=20 > This still seems problematic to me. > The UUIE is sent by one endpoint and received by the other. > If the protocol discriminator is not signaled in the SDP, and=20 > its also not fixed by the spec, then it must be chosen by the=20 > endpoint initiating the cs, and won't be known to the recipient. >=20 > If the recipient puts *any* limitations on what it is, then=20 > it will fail if the sender chooses something else. In my book=20 > that means the recipient must ignore the protocol=20 > discriminator for this to work. >=20 > Does it matter what discriminator is used, or cause any harm=20 > to ignore it? I don't know. I suppose it depends on how these=20 > things are used in the PSTN. Does anything enforce=20 > consistency between the discriminator and the content? Does=20 > anything restrict what discriminators may be used? >=20 > If the discriminator is so unimportant that it can be=20 > ignored, then why is it present at all? >=20 > Just to be safe, why not either: > - include the discriminator in the string; OR > - just pick a discriminator and wire it into this document >=20 > Thanks, > Paul > = From stewe@stewe.org Sun Nov 6 08:48:23 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D1E21F8532 for ; Sun, 6 Nov 2011 08:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iy71xVZPIOD for ; Sun, 6 Nov 2011 08:48:22 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id A226A21F8515 for ; Sun, 6 Nov 2011 08:48:21 -0800 (PST) Received: from [192.168.1.63] (unverified [71.202.147.60]) by stewe.org (SurgeMail 3.9e) with ESMTP id 56868-1743317 for ; Sun, 06 Nov 2011 17:48:20 +0100 User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Sun, 06 Nov 2011 08:48:13 -0700 From: Stephan Wenger To: Message-ID: Thread-Topic: RFC 5583 bug, fix in errata? Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3403414100_20309180" X-Originating-IP: 71.202.147.60 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (71.202.147.60) was found in the spamhaus database. http://www.spamhaus.net Subject: [MMUSIC] RFC 5583 bug, fix in errata? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2011 16:48:23 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3403414100_20309180 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi, Section 5.1 in RFC 5583 reads > The dependency signaling is only feasible between media descriptions > described with an "m=3D"-line and with an assigned media identification > attribute ("mid"), as defined in [RFC3388 > ]. All media descriptions > grouped according to this specification MUST have the same media > type. Other dependencies relations expressed by SDP grouping have to > be addressed in other specifications. A media description MUST NOT > be part of more than one group of the grouping type defined in this > Specification. The highlighted sentence ("All media descriptions [=8A] MUST have the same media type." for those using plaintext) imposes a restrictions that runs contrary to the authors' intention. Specifically, when writing up the drafts that led to RFC 5583, we (that's Thomas Schierl and myself) had in mind the use of an H.264 base layer (media type H264) and SVC enhancement layer(s) (media type SVC). Replacing "media type" with "media name" would make, to us, perfect sense. There is no point in trying to signal a decoding dependency between a, say, audio base layer and a video enhancement layer. But the restriction of the same media type does not make much sense. So the proposed bug fix is to replace "media type" with "media name". Can this issue be dealt with using the errata process or do we need an RFC5583-bis draft? Stephan =20 --B_3403414100_20309180 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi,
Section 5.1 in= RFC 5583 reads
The highlighted sente=
nce ("All media descriptions […] MUST have the same media type." for t=
hose using plaintext) imposes a restrictions that runs contrary to the autho=
rs' intention.  Specifically, when writing up the drafts that led to RFC 558=
3, we (that's Thomas Schierl and myself) had in mind the use of an H.264 bas=
e layer (media type H264) and SVC enhancement layer(s) (media type SVC). &nb=
sp;

Replacing "media type" wi= th "media name" would make, to us, perfect sense. There is no point in tryi= ng to signal a decoding dependency between a, say, audio base layer and a vi= deo enhancement layer. But the restriction of the same media type does not = make much sense.
=

So the propo=
sed bug fix is to replace "media type" with "media name".

Can this issue be dealt with using the errata p=
rocess or do we need an RFC5583-bis draft?

Stephan



<= /body> --B_3403414100_20309180-- From yuepeiyu@huawei.com Mon Nov 7 00:03:01 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B6B1F0C3F for ; Mon, 7 Nov 2011 00:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.301 X-Spam-Level: X-Spam-Status: No, score=-97.301 tagged_above=-999 required=5 tests=[AWL=1.155, BAYES_50=0.001, CN_BODY_35=0.339, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 UhSqKhzBaN+V for ; Mon, 7 Nov 2011 00:02:59 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id B73671F0C35 for ; Mon, 7 Nov 2011 00:02:58 -0800 (PST) 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 <0LUA00KNW6ANIA@szxga04-in.huawei.com> for mmusic@ietf.org; Mon, 07 Nov 2011 16:01:35 +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 <0LUA00HQG6A7LV@szxga04-in.huawei.com> for mmusic@ietf.org; Mon, 07 Nov 2011 16:01:35 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEU44306; Mon, 07 Nov 2011 16:01:35 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 07 Nov 2011 16:01:28 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.102]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0270.001; Mon, 07 Nov 2011 16:01:22 +0800 Date: Mon, 07 Nov 2011 08:01:22 +0000 From: "Roy Yue(PeiYu)" In-reply-to: X-Originating-IP: [10.138.73.89] To: "mmusic@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/related; boundary="Boundary_(ID_QBlETJ12QneLPa7wam07fw)"; type="multipart/alternative" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: RFC 5583 bug, fix in errata? Thread-index: AQHMnKPsTxx8oDp7yU+HsRPo0XgrSZWhBnEA X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: Re: [MMUSIC] RFC 5583 bug, fix in errata? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 08:03:01 -0000 --Boundary_(ID_QBlETJ12QneLPa7wam07fw) Content-type: multipart/alternative; boundary="Boundary_(ID_IhzhtKog8N9S76ehTZWVpw)" --Boundary_(ID_IhzhtKog8N9S76ehTZWVpw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGksDQoNCk5vdCBmYW1pbGlhciB3aXRoIHRoZSBwcm9jZXNzIG9mIElFVEYuICBIb3dldmVyIHRo ZSBwcm9wb3NlZCB0ZXJtIKGwbWVkaWEgbmFtZaGxIGxvb2tzIHRvbyB2YWd1ZSB0byB1bmRlcnN0 YW5kLg0KQW5vdGhlciB0ZXJtIKGwdG9wLWxldmVsIG1lZGlhIHR5cGWhsSBkZWZpbmVkIGJ5IFJG QzIwNDYgY2FuIGNvcGUgd2l0aCB5b3VyIGV4YW1wbGVzIHZlcnkgd2VsbC4gV2hhdCBhYm91dCB1 c2luZyChsHRvcC1sZXZlbCBtZWRpYSB0eXBlobEgaW5zdGVhZD8NCg0KQWN0dWFsbHksIGluIElB TkEoZS5nLiBodHRwOi8vd3d3LmlhbmEub3JnL2NnaS1iaW4vbWVkaWF0eXBlcy5wbCkgYW5kIHNv bWUgUkZDcyAoZS5nLiBSRkM0ODU1KSwgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0ZXJtIKGwbWVk aWEgdHlwZaGxIGFuZCB0ZXJtIKGwdG9wLWxldmVsIG1lZGlhIHR5cGWhsSBpcyBub3QgZGlzdGlu Y3QuDQpTb21ldGltZSChsG1lZGlhIHR5cGWhsSBtZWFucyB0aGUgdG9wIGxldmVsIG1lZGlhIHR5 cGUgd2hpbGUgc29tZXRpbWVzIGl0IG1lYW5zIHRoZSB3aG9sZSBtZWRpYSB0eXBlLg0KU28gdGhl IHNlbnRlbmNlIGluIFJGQyA1NTgzIGlzIGV2ZW4gY29ycmVjdCB0byBzb21lIGV4dGVudC4gQnV0 IEkgYWdyZWUgaXQgaXMgYmV0dGVyIHRvIHVwZGF0ZSBpdCBmb3IgYmV0dGVyIHVuZGVyc3RhbmRp bmcuDQoNCkJlc3QgcmVnYXJkLA0KUm95KMDWxeDT8SkNCkh1YXdlaSBTb2Z0d2FyZSBUZWNobm9s b2dpZXMgQ28uLCBMdGQgW2h1YXdlaV9sb2dvXQ0KDQpONSwgTk8uIDEwMSwgSHVhd2VpIEJhc2UN ClJ1YW5qaWFuIEF2LCBZdUh1YSBEaXN0DQpOYW5qaW5nLCAyMTAwMTIsIFAuUi5DDQpUZWw6ICs4 Ni0yNS01NjYyMjA1OA0KRmF4OiArODYtMjUtNTY2MjQwODENCk1vYmlsZTogKzg2LTEzODA5MDMw NDAxDQpFbWFpbDogeXVlcGVpeXVAaHVhd2VpLmNvbQ0KaHR0cDovL3d3dy5odWF3ZWkuY29tDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQqxvtPKvP68sMbkuL28/rqs09C7qs6quavLvrXEsaPD3NDFz6Kj rL32z97T2reiy824+MnPw+a12Na31tDB0LP2tcS49sjLu/LIutfpoaO9+w0K1rnIzrrOxuTL+8jL 0tTIzrrO0M7Kvcq508OjqLD8wKi1q7K7z97T2sirsr+78rK/t9a12NC5wrahori01sahorvyyaK3 oqOpsb7Tyrz+1tANCrXE0MXPoqGjyOe5+8T6tO3K1cHLsb7Tyrz+o6zH68T6waK8tLXnu7C78tPK vP7NqNaqt6K8/sjLsqLJvrP9sb7Tyrz+o6ENClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVu dHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoDQpp cyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlz IGxpc3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUNCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJl aW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBh cnRpYWwNCmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVy c29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQu IElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYnkNCnBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhDQq3orz+ yMs6IG1tdXNpYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5v cmddILT6se0gU3RlcGhhbiBXZW5nZXINCreiy83KsbzkOiAyMDExxOoxMdTCNsjVIDIzOjQ4DQrK 1bz+yMs6IG1tdXNpY0BpZXRmLm9yZw0K1vfM4jogW01NVVNJQ10gUkZDIDU1ODMgYnVnLCBmaXgg aW4gZXJyYXRhPw0KDQpIaSwNClNlY3Rpb24gNS4xIGluIFJGQyA1NTgzIHJlYWRzDQoNCiAgIFRo ZSBkZXBlbmRlbmN5IHNpZ25hbGluZyBpcyBvbmx5IGZlYXNpYmxlIGJldHdlZW4gbWVkaWEgZGVz Y3JpcHRpb25zDQoNCiAgIGRlc2NyaWJlZCB3aXRoIGFuICJtPSItbGluZSBhbmQgd2l0aCBhbiBh c3NpZ25lZCBtZWRpYSBpZGVudGlmaWNhdGlvbg0KDQogICBhdHRyaWJ1dGUgKCJtaWQiKSwgYXMg ZGVmaW5lZCBpbiBbUkZDMzM4ODxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzMzg4Pl0u ICBBbGwgbWVkaWEgZGVzY3JpcHRpb25zDQoNCiAgIGdyb3VwZWQgYWNjb3JkaW5nIHRvIHRoaXMg c3BlY2lmaWNhdGlvbiBNVVNUIGhhdmUgdGhlIHNhbWUgbWVkaWENCg0KICAgdHlwZS4gIE90aGVy IGRlcGVuZGVuY2llcyByZWxhdGlvbnMgZXhwcmVzc2VkIGJ5IFNEUCBncm91cGluZyBoYXZlIHRv DQoNCiAgIGJlIGFkZHJlc3NlZCBpbiBvdGhlciBzcGVjaWZpY2F0aW9ucy4gIEEgbWVkaWEgZGVz Y3JpcHRpb24gTVVTVCBOT1QNCg0KICAgYmUgcGFydCBvZiBtb3JlIHRoYW4gb25lIGdyb3VwIG9m IHRoZSBncm91cGluZyB0eXBlIGRlZmluZWQgaW4gdGhpcw0KDQogICBTcGVjaWZpY2F0aW9uLg0K DQpUaGUgaGlnaGxpZ2h0ZWQgc2VudGVuY2UgKCJBbGwgbWVkaWEgZGVzY3JpcHRpb25zIFuhrV0g TVVTVCBoYXZlIHRoZSBzYW1lIG1lZGlhIHR5cGUuIiBmb3IgdGhvc2UgdXNpbmcgcGxhaW50ZXh0 KSBpbXBvc2VzIGEgcmVzdHJpY3Rpb25zIHRoYXQgcnVucyBjb250cmFyeSB0byB0aGUgYXV0aG9y cycgaW50ZW50aW9uLiAgU3BlY2lmaWNhbGx5LCB3aGVuIHdyaXRpbmcgdXAgdGhlIGRyYWZ0cyB0 aGF0IGxlZCB0byBSRkMgNTU4Mywgd2UgKHRoYXQncyBUaG9tYXMgU2NoaWVybCBhbmQgbXlzZWxm KSBoYWQgaW4gbWluZCB0aGUgdXNlIG9mIGFuIEguMjY0IGJhc2UgbGF5ZXIgKG1lZGlhIHR5cGUg SDI2NCkgYW5kIFNWQyBlbmhhbmNlbWVudCBsYXllcihzKSAobWVkaWEgdHlwZSBTVkMpLg0KDQoN ClJlcGxhY2luZyAibWVkaWEgdHlwZSIgd2l0aCAibWVkaWEgbmFtZSIgd291bGQgbWFrZSwgdG8g dXMsIHBlcmZlY3Qgc2Vuc2UuICBUaGVyZSBpcyBubyBwb2ludCBpbiB0cnlpbmcgdG8gc2lnbmFs IGEgZGVjb2RpbmcgZGVwZW5kZW5jeSBiZXR3ZWVuIGEsIHNheSwgYXVkaW8gYmFzZSBsYXllciBh bmQgYSB2aWRlbyBlbmhhbmNlbWVudCBsYXllci4gIEJ1dCB0aGUgcmVzdHJpY3Rpb24gb2YgdGhl IHNhbWUgbWVkaWEgdHlwZSBkb2VzIG5vdCBtYWtlIG11Y2ggc2Vuc2UuDQoNCg0KU28gdGhlIHBy b3Bvc2VkIGJ1ZyBmaXggaXMgdG8gcmVwbGFjZSAibWVkaWEgdHlwZSIgd2l0aCAibWVkaWEgbmFt ZSIuDQoNCg0KQ2FuIHRoaXMgaXNzdWUgYmUgZGVhbHQgd2l0aCB1c2luZyB0aGUgZXJyYXRhIHBy b2Nlc3Mgb3IgZG8gd2UgbmVlZCBhbiBSRkM1NTgzLWJpcyBkcmFmdD8NCg0KDQpTdGVwaGFuDQoN Cg0KDQoNCg0K --Boundary_(ID_IhzhtKog8N9S76ehTZWVpw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi,

 = ;

Not famili= ar with the process of IETF.  However the proposed term =A1=B0media na= me=A1=B1 looks too vague to understand.

Another te= rm =A1=B0top-level media type=A1=B1 defined by RFC2046 can cope with your e= xamples very well. What about using =A1=B0top-level media type=A1=B1 instea= d?

 = ;

Actually, = in IANA(e.g. http://www.iana.org/cgi-bin/mediatypes.pl) and some RFCs (e.g.= RFC4855), the difference between term =A1=B0media type=A1=B1 and term =A1=B0top-level media type=A1=B1 is not distinct.

Sometime = =A1=B0media type=A1=B1 means the top level media type while sometimes it me= ans the whole media type.

So the sen= tence in RFC 5583 is even correct to some extent. But I agree it is better = to update it for better understanding.

 = ;

Best regar= d,

Roy(=C0=D6=C5=E0= =D3=F1)
Huawei Software Technologies Co., Ltd 3D"huawei_logo"


N5, NO. 101, Huawei Base
Ruanjian Av, YuHua Dist
Nanjing, 210012, P.R.C
Tel: +86-25-56622058
Fax: +86-25-56624081
Mobile: +86-13809030401
Email: yuepeiyu@huawei.com
http://www.huawei.com
---------------------------------------------------------------------------= ----------------------------------------------------------
=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE= =AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2= =CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB= =F2=C8=BA=D7=E9=A1=A3=BD=FB
=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD= =CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2= =BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9= =B1=BE=D3=CA=BC=FE=D6=D0
=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE= =D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD= =A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
This e-mail and its attac= hments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!

=B7=A2=BC=FE=C8=CB: mmusic-= bounces@ietf.org [mailto:mmusic-bounces@ietf.org] =B4=FA= =B1=ED Stephan Wenger
=B7=A2= =CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C26=C8=D5 23:48
=CA=D5=BC=FE=C8=CB: mmusic@ietf.org
=D6=F7=CC=E2: [MMUSIC] RFC 5583 bug, fix in errata?

 

Hi,

Section 5.1 = in RFC 5583 reads

   The dependency si=
gnaling is only feasible between media descriptions
   described with an=
 "m=3D"-line and with an assigned media identification=

   attribute ("=
mid"), as defined in [RFC3388].  All media descriptions
   grouped according to this specification =
MUST have the same media
   type.  Other dep=
endencies relations expressed by SDP grouping have to

   be addressed in o=
ther specifications.  A media description MUST NOT

   be part of more t=
han one group of the grouping type defined in this


   Specification.


Th=
e highlighted sentence ("All media descriptions [=A1=AD] MUST have the=
 same media type." for those using plaintext) imposes a restrictions t=
hat runs contrary to the authors' intention.  Specifically, when writi=
ng up the drafts that led to RFC 5583, we (that's Thomas Schierl and myself=
) had in mind the use of an H.264 base layer (media type H264) and SVC enha=
ncement layer(s) (media type SVC).  

 
Re=
placing "media type" with "media name" would make, to u=
s, perfect sense.  There is no point in trying to signal a decoding de=
pendency between a, say, audio base layer and a video enhancement layer.&nb=
sp; But the restriction of the same media type does not make much sense.

 
So=
 the proposed bug fix is to replace "media type" with "media=
 name".

 
Ca=
n this issue be dealt with using the errata process or do we need an RFC558=
3-bis draft?

 
St=
ephan
 <=
o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

--Boundary_(ID_IhzhtKog8N9S76ehTZWVpw)-- --Boundary_(ID_QBlETJ12QneLPa7wam07fw) Content-id: Content-type: image/jpeg; name=image001.jpg Content-transfer-encoding: base64 Content-disposition: inline; filename=image001.jpg; size=6737; creation-date="Mon, 07 Nov 2011 08:01:21 GMT"; modification-date="Mon, 07 Nov 2011 08:01:21 GMT" Content-description: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_QBlETJ12QneLPa7wam07fw)-- From magnus.westerlund@ericsson.com Mon Nov 7 06:49:48 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6994121F8B51 for ; Mon, 7 Nov 2011 06:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 SxUxo5LyPHxg for ; Mon, 7 Nov 2011 06:49:44 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3F97321F8B48 for ; Mon, 7 Nov 2011 06:49:44 -0800 (PST) X-AuditID: c1b4fb3d-b7c26ae0000035b9-aa-4eb7f007b3b8 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F3.92.13753.700F7BE4; Mon, 7 Nov 2011 15:49:43 +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.137.0; Mon, 7 Nov 2011 15:49:42 +0100 Message-ID: <4EB7F005.5060907@ericsson.com> Date: Mon, 7 Nov 2011 15:49:41 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] RFC 5583 bug, fix in errata? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 14:49:48 -0000 On 2011-11-06 16:48, Stephan Wenger wrote: > Hi, Section 5.1 in RFC 5583 reads >> The dependency signaling is only feasible between media >> descriptions described with an "m="-line and with an assigned media >> identification attribute ("mid"), as defined in [RFC3388 >> ]. All media descriptions >> grouped according to this specification MUST have the same media >> type. Other dependencies relations expressed by SDP grouping have >> to be addressed in other specifications. A media description MUST >> NOT be part of more than one group of the grouping type defined in >> this Specification. > > The highlighted sentence ("All media descriptions [] MUST have the > same media type." for those using plaintext) imposes a restrictions > that runs contrary to the authors' intention. Specifically, when > writing up the drafts that led to RFC 5583, we (that's Thomas Schierl > and myself) had in mind the use of an H.264 base layer (media type > H264) and SVC enhancement layer(s) (media type SVC). > I think you are overreacting, Media Type is any audio or any video format. The limiation does not apply on payload type level, like your example with combing H.264 and SVC would be. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From pkyzivat@alum.mit.edu Mon Nov 7 11:16:22 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BFB21F8AFF for ; Mon, 7 Nov 2011 11:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, 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 SxkbnWuPMZBg for ; Mon, 7 Nov 2011 11:16:21 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 2913821F8B66 for ; Mon, 7 Nov 2011 11:16:21 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta09.westchester.pa.mail.comcast.net with comcast id uENU1h0041wpRvQ59KGMVf; Mon, 07 Nov 2011 19:16:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta18.westchester.pa.mail.comcast.net with comcast id uKGL1h03X07duvL3eKGMMG; Mon, 07 Nov 2011 19:16:21 +0000 Message-ID: <4EB82E83.5070701@alum.mit.edu> Date: Mon, 07 Nov 2011 14:16:19 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <20111031120308.18508.69135.idtracker@ietfa.amsl.com> <4EAEF751.6000205@alum.mit.edu> <4EB18474.40701@alum.mit.edu> <4EB41F0D.4050001@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 19:16:22 -0000 On 11/4/11 2:02 PM, DRAGE, Keith (Keith) wrote: > The protocol discriminator is only one of the variables. > > Essentially there are a number of things that can vary such as: > > - what purpose am I doing this correlation for in the first place. Section 1 of the document mentions a number of use cases but none of this document describes how I actually use this mechanism within that use case (and that needs to be agreed between both ends before it can occur) I don't understand your point here. The offerer has decided to offer a circuit switched stream. The answerer doesn't have to know why this decision was made. It need only decide whether to accept it or not. In this regard it is like many other things negotiated via o/a. > - which correlation transport mechanism am I using (the document provides at least three in 5.2.3.2, 5.2.3.3 and 5.2.3.4), and the one you choose depends on what is available end to end within that overall use case (and again that needs to be agreed between both ends before it can occur). Again, the offerer provides info for the correlation mechanisms it is willing to use. They aren't mutually exclusive - they can be used in tandem. So the answerer can answer with the full subset that it is able to use. There need not be any external pre-agreement. > So I very much see this document as providing part of a toolkit which I plug into a much wider usage. It is not the part of this document to specify that wider usage. ISTM that the protocol discriminator choice is of an entirely different character than the others. As it stands, there must either be a separate agreement about this, or else the recipient must ignore it. > I believe 3GPP has one document that specifies how these get pulled together for one specific use case. Other groups and even IETF may have other use cases that need a similar tool. This mechanism could be used in non-IMS enviroments, without major pre-agreements (other than to support the mechanism at all), *if* the mechanism for determining the protocol discriminator is specified. I'll repeat my earlier question - what is the harm in specifying this? CUSS is defining use of UUI, and it is including the protocol discriminator along with the value. Is there a reason not to follow the same representation here? > I don't think it is part of this document to specify those use cases, and I think it is just sufficient to know they exist, and that standards can be applied elsewhere to deal with the options available in using this document. I don't think this doc need specify those cases. But it ought to specify a complete mechanism. Thanks, Paul > Keith > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 04 November 2011 17:21 >> To: DRAGE, Keith (Keith) >> Cc: Simo.Veikkolainen@nokia.com; mmusic@ietf.org >> Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt >> >> On 11/3/11 9:02 PM, DRAGE, Keith (Keith) wrote: >>> In regard to your question about the protocol >> discriminator, I don't see the text as saying ignore it, it >> is just saying it is outside the scope of this document. >>> >>> This document is saying how you take the delivered user >> data and correlate it with something that is in the SDP. The >> protocol discriminator can form part of the checks of whether >> I am delivering the user data to the right application in the >> first place along with what message I've received it in and >> probably one or two other things, none of which have anything >> to do with this document. >>> >>> However I must admit I don't like specification by >> negatives (MUST NOT) which is what this is. >>> >>> Maybe change the text as: >>> >>> The first three octets of the User-user information >> element specified >>> in ITU-T Q.931 [ITU.Q931.1998] are the user-user >> information element identifier, length of user-user contents, >> and a protocol discriminator, followed by the user >> information. An entity performing correlation MUST only compare >>> the octets carrying the user information to the >> "cs-correlation:uuie" >>> attribute (the user-user information element >> identifier, length of user-user contents, and protocol >> discriminator are not used for this purpose). >>> >>> I've corrected some capitalization and a typo as well. >> >> This still seems problematic to me. >> The UUIE is sent by one endpoint and received by the other. >> If the protocol discriminator is not signaled in the SDP, and >> its also not fixed by the spec, then it must be chosen by the >> endpoint initiating the cs, and won't be known to the recipient. >> >> If the recipient puts *any* limitations on what it is, then >> it will fail if the sender chooses something else. In my book >> that means the recipient must ignore the protocol >> discriminator for this to work. >> >> Does it matter what discriminator is used, or cause any harm >> to ignore it? I don't know. I suppose it depends on how these >> things are used in the PSTN. Does anything enforce >> consistency between the discriminator and the content? Does >> anything restrict what discriminators may be used? >> >> If the discriminator is so unimportant that it can be >> ignored, then why is it present at all? >> >> Just to be safe, why not either: >> - include the discriminator in the string; OR >> - just pick a discriminator and wire it into this document >> >> Thanks, >> Paul >> From wuym2000cn@gmail.com Mon Nov 7 16:59:08 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18F81F0C52 for ; Mon, 7 Nov 2011 16:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.713 X-Spam-Level: X-Spam-Status: No, score=-2.713 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=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 pzRxBUop0JaI for ; Mon, 7 Nov 2011 16:59:08 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3D28D11E80CA for ; Mon, 7 Nov 2011 16:59:08 -0800 (PST) Received: by qadc10 with SMTP id c10so5079960qad.31 for ; Mon, 07 Nov 2011 16:59:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=im9JJE/QLlqicCMrITIwteSExrs+vt9v7/n2p6wBiOo=; b=FGcjoVen+GKQBlOD6CzBN7DhFPT+LPqJsOp0M++LnHAxFCMby6fFXsLptOcBaSveXy ZlZLe79Dom862YyHXcaX3yfMSadnOdPVCPcNcgOqdhgjpMOlbrbPPDE85ZfUMIXlzugL IH4U4CPWJTxzsyso/4x+leFSx5wMfnO+K+cvg= MIME-Version: 1.0 Received: by 10.229.61.169 with SMTP id t41mr3412243qch.249.1320713947545; Mon, 07 Nov 2011 16:59:07 -0800 (PST) Received: by 10.229.84.143 with HTTP; Mon, 7 Nov 2011 16:59:07 -0800 (PST) Date: Tue, 8 Nov 2011 08:59:07 +0800 Message-ID: From: woo johnman To: mmusic@ietf.org Content-Type: multipart/alternative; boundary=0016e64fd32cb1807704b12eaded Subject: [MMUSIC] Question about ICE: Checks Schedule X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 01:00:31 -0000 --0016e64fd32cb1807704b12eaded Content-Type: text/plain; charset=ISO-8859-1 Hi,Experts: I got such a question when i read the ICE standard. At 5.7.4, It says: " 2. The agent examines the check list for the first media stream (a media stream is the first media stream when it is described by the first m line in the SDP offer and answer). For that media stream: * For all pairs with the same foundation, it sets the state of the pair with the lowest component ID to Waiting. If there is more than one such pair, the one with the highest priority is used. " At 5.8. it says: " o Find the highest-priority pair in that check list that is in the Waiting state. o If there is such a pair: * Send a STUN check from the local candidate of that pair to the remote candidate of that pair. The procedures for forming the STUN request for this purpose are described in Section 7.1.2. * Set the state of the candidate pair to In-Progress. o If there is no such pair: * Find the highest-priority pair in that check list that is in the Frozen state. * If there is such a pair: + Unfreeze the pair. + Perform a check for that pair, causing its state to transition to In-Progress. " As my understanding, clause 5.7.4 can be considered as the initialization stage of the ICE check procedure expressed at clause 5.8. The question is why the criterion of waiting pair selection is a little different at the two stage. At initliazation, it uses 'foundation' and 'component ID' to deduce the waiting pair,But at runtime it mainly uses 'priority' . I think the later is simple and nice. Can the same criterion be used at two stage? Thanks in advance! --0016e64fd32cb1807704b12eaded Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,Experts:

I got such a question when i read the ICE standard.

At 5.7.4, It says:

"

=A02.=A0 The agent examines the c= heck list for the first media stream (a
=A0=A0=A0=A0=A0=A0 media stream = is the first media stream when it is described by
=A0=A0=A0=A0=A0=A0 the first m line in the SDP offer and answer).=A0 For th= at media
=A0=A0=A0=A0=A0=A0 stream:

=A0=A0=A0=A0=A0=A0 *=A0 For al= l pairs with the same foundation, it sets the state of
=A0=A0=A0=A0=A0= =A0=A0=A0=A0 the pair with the lowest component ID to Waiting.=A0 If there = is
=A0=A0=A0=A0=A0=A0=A0=A0=A0 more than one such pair, the one with the highe= st priority is
=A0=A0=A0=A0=A0=A0=A0=A0=A0 used.
=A0"

At 5= .8. it says:

"

=A0=A0 o=A0 Find the highest-priority pair = in that check list that is in the
=A0=A0=A0=A0=A0 Waiting state.

=A0=A0 o=A0 If there is such a pair:

=A0=A0=A0=A0=A0 *=A0 Send a S= TUN check from the local candidate of that pair to the
=A0=A0=A0=A0=A0= =A0=A0=A0 remote candidate of that pair.=A0 The procedures for forming the<= br>=A0=A0=A0=A0=A0=A0=A0=A0 STUN request for this purpose are described in = Section 7.1.2.

=A0=A0=A0=A0=A0 *=A0 Set the state of the candidate pair to In-Progress.=

=A0=A0 o=A0 If there is no such pair:

=A0=A0=A0=A0=A0 *=A0 Fin= d the highest-priority pair in that check list that is in
=A0=A0=A0=A0= =A0=A0=A0=A0 the Frozen state.

=A0=A0=A0=A0=A0 *=A0 If there is such = a pair:

=A0=A0=A0=A0=A0=A0=A0=A0 +=A0 Unfreeze the pair.

=A0=A0=A0=A0=A0= =A0=A0=A0 +=A0 Perform a check for that pair, causing its state to
=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 transition to In-Progress.

"

<= p>As my understanding, clause 5.7.4 can be considered as the initialization= stage of the ICE check procedure expressed at clause 5.8.

The question is why the criterion of waiting pair selection is a little = different at the two stage.

At initliazation, it uses=A0 'foundat= ion' and 'component ID' to deduce the waiting pair,But at runti= me=A0 it mainly uses 'priority' .

=A0

I think the later is simple and nice. Can the same criterion b= e used at two stage?

=A0

Thanks in advance!

--0016e64fd32cb1807704b12eaded-- From wuym2000cn@gmail.com Mon Nov 7 17:06:45 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9094811E80B6 for ; Mon, 7 Nov 2011 17:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.837 X-Spam-Level: X-Spam-Status: No, score=-2.837 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=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 mNJYDI9WzlvW for ; Mon, 7 Nov 2011 17:06:44 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A697411E8082 for ; Mon, 7 Nov 2011 17:06:44 -0800 (PST) Received: by qyl16 with SMTP id 16so3029755qyl.10 for ; Mon, 07 Nov 2011 17:06:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=0vJvXDelkBqhSh/PljvDzex69U1Q3Snpj0ebEzEGV40=; b=HvLmQMokOsJ4wkyRpxLJOmYWj0zCBJ1ge9AHq7xi+jvR7RMEbSX6L/+0d/PeLRCwnR zv2e0d9QXMq3HsEwTSfeLyj3quYFN5l9T86l/edVmqMnBrz4gXaPL9NiR2DSChmOkfKo gQh1SBP/UBMWgEAaN6QZULJMgEvCrUh7/trRM= MIME-Version: 1.0 Received: by 10.229.213.3 with SMTP id gu3mr3510172qcb.211.1320714404198; Mon, 07 Nov 2011 17:06:44 -0800 (PST) Received: by 10.229.84.143 with HTTP; Mon, 7 Nov 2011 17:06:44 -0800 (PST) In-Reply-To: References: Date: Tue, 8 Nov 2011 09:06:44 +0800 Message-ID: From: woo johnman To: mmusic@ietf.org Content-Type: multipart/alternative; boundary=0016e6407dbae97a3004b12ec82c Subject: [MMUSIC] Question about ICE: Checks Schedule X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 01:06:45 -0000 --0016e6407dbae97a3004b12ec82c Content-Type: text/plain; charset=ISO-8859-1 Hi,Experts: I got such a question when i read the ICE standard. At 5.7.4, It says: " 2. The agent examines the check list for the first media stream (a media stream is the first media stream when it is described by the first m line in the SDP offer and answer). For that media stream: * For all pairs with the same foundation, it sets the state of the pair with the lowest component ID to Waiting. If there is more than one such pair, the one with the highest priority is used. " At 5.8. it says: " o Find the highest-priority pair in that check list that is in the Waiting state. o If there is such a pair: * Send a STUN check from the local candidate of that pair to the remote candidate of that pair. The procedures for forming the STUN request for this purpose are described in Section 7.1.2. * Set the state of the candidate pair to In-Progress. o If there is no such pair: * Find the highest-priority pair in that check list that is in the Frozen state. * If there is such a pair: + Unfreeze the pair. + Perform a check for that pair, causing its state to transition to In-Progress. " As my understanding, clause 5.7.4 can be considered as the initialization step of the ICE check procedure expressed at clause 5.8. The question is why the criterion of waiting pair selection is a little different at the two steps. At initliazation, it uses 'foundation' and 'component ID' to deduce the waiting pair,But at runtime it mainly uses 'priority' . I think the later is simple and nice. Can the same criterion be used at two steps? Thanks in advance! Woo --0016e6407dbae97a3004b12ec82c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,Experts:
I got such a question= when i read the ICE standard.
At 5.7.4, It says:
"= ;
=A02.=A0 The agent examines the check list for the first media = stream (a
=A0=A0=A0=A0=A0=A0 media stream is the first media stream when it is descri= bed by
=A0=A0=A0=A0=A0=A0 the first m line in the SDP offer and answer).=A0 For th= at media
=A0=A0=A0=A0=A0=A0 stream:
=A0=A0=A0=A0=A0=A0 *=A0 Fo= r all pairs with the same foundation, it sets the state of
=A0=A0=A0=A0= =A0=A0=A0=A0=A0 the pair with the lowest component ID to Waiting.=A0 If the= re is
=A0=A0=A0=A0=A0=A0=A0=A0=A0 more than one such pair, the one with the highe= st priority is
=A0=A0=A0=A0=A0=A0=A0=A0=A0 used.
=A0"
= At 5.8. it says:
"
=A0=A0 o=A0 Find the highest-pr= iority pair in that check list that is in the
=A0=A0=A0=A0=A0 Waiting state.
=A0=A0 o=A0 If there is such a pai= r:
=A0=A0=A0=A0=A0 *=A0 Send a STUN check from the local candidat= e of that pair to the
=A0=A0=A0=A0=A0=A0=A0=A0 remote candidate of that = pair.=A0 The procedures for forming the
=A0=A0=A0=A0=A0=A0=A0=A0 STUN request for this purpose are described in Sec= tion 7.1.2.
=A0=A0=A0=A0=A0 *=A0 Set the state of the candidate p= air to In-Progress.
=A0=A0 o=A0 If there is no such pair:
=A0=A0=A0=A0=A0 *=A0 Find the highest-priority pair in that check list t= hat is in
=A0=A0=A0=A0=A0=A0=A0=A0 the Frozen state.
=A0=A0=A0=A0=A0 *=A0 I= f there is such a pair:
=A0=A0=A0=A0=A0=A0=A0=A0 +=A0 Unfreeze th= e pair.
=A0=A0=A0=A0=A0=A0=A0=A0 +=A0 Perform a check for that pa= ir, causing its state to
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 transition to= In-Progress.
"
As my understanding, clause 5.7.4 can be considered a= s the=A0initialization=A0step=A0of the ICE check procedure expressed at cla= use 5.8.
The question is why the criterion of waiting pair selec= tion is a little different at the two steps.
At initliazation, it uses=A0 'foundation' and 'component I= D' to deduce the waiting pair,But at runtime =A0it mainly uses 'pri= ority' .
=A0
I think the later is simple and nice. = Can the same criterion be used at two steps?
=A0
Thanks in advance!
Woo

--0016e6407dbae97a3004b12ec82c-- From wuym2000cn@gmail.com Mon Nov 7 17:48:59 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237DE11E8073 for ; Mon, 7 Nov 2011 17:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.86 X-Spam-Level: X-Spam-Status: No, score=-2.86 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=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 USL4bTztnlgW for ; Mon, 7 Nov 2011 17:48:58 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6631F0C4D for ; Mon, 7 Nov 2011 17:48:58 -0800 (PST) Received: by qyl16 with SMTP id 16so3066607qyl.10 for ; Mon, 07 Nov 2011 17:48:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=vB1VAXo/NBP6vTk/DrktnSBmzAxHYuLhg0L7y41LN6o=; b=Uc9XBXl9s3pRd7gnnISYWH6MC6apmQBPim1hBDtoZ3/04NS0yOIWsf6k6YLWbxEb+a U4zzyGqJ0sch3VggA02D7OsJXKzgQmyAs9znPktJl3ld4O08N74Sdo14lsSyGo434TTa IQsBe8mn9iZFIvTSx14sjxAglCYeoQZNJNntU= MIME-Version: 1.0 Received: by 10.229.221.11 with SMTP id ia11mr2572821qcb.97.1320716936895; Mon, 07 Nov 2011 17:48:56 -0800 (PST) Received: by 10.229.84.143 with HTTP; Mon, 7 Nov 2011 17:48:56 -0800 (PST) In-Reply-To: References: Date: Tue, 8 Nov 2011 09:48:56 +0800 Message-ID: From: woo johnman To: mmusic@ietf.org Content-Type: multipart/alternative; boundary=0016e686ccd4df5b7304b12f5fe8 Subject: [MMUSIC] Question about ICE: Checks Schedule X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 01:48:59 -0000 --0016e686ccd4df5b7304b12f5fe8 Content-Type: text/plain; charset=ISO-8859-1 Hi,Experts: I got such a question when i read the ICE standard. At 5.7.4, It says: " 2. The agent examines the check list for the first media stream (a media stream is the first media stream when it is described by the first m line in the SDP offer and answer). For that media stream: * For all pairs with the same foundation, it sets the state of the pair with the lowest component ID to Waiting. If there is more than one such pair, the one with the highest priority is used. " At 5.8. it says: " o Find the highest-priority pair in that check list that is in the Waiting state. o If there is such a pair: * Send a STUN check from the local candidate of that pair to the remote candidate of that pair. The procedures for forming the STUN request for this purpose are described in Section 7.1.2. * Set the state of the candidate pair to In-Progress. o If there is no such pair: * Find the highest-priority pair in that check list that is in the Frozen state. * If there is such a pair: + Unfreeze the pair. + Perform a check for that pair, causing its state to transition to In-Progress. " As my understanding, clause 5.7.4 can be considered as the initialization stage of the ICE check procedure expressed at clause 5.8. The question is why the criterion of waiting pair selection is a little different at the two stage. At initliazation, it uses 'foundation' and 'component ID' to deduce the waiting pair,But at runtime it mainly uses 'priority' . I think the later is simple and nice. Can the same criterion be used at two stage? Thanks in advance! --0016e686ccd4df5b7304b12f5fe8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,Experts:

I got such a question when = i read the ICE standard.

At 5.7.4, It says:

"

=A02.= =A0 The agent examines the check list for the first media stream (a
=A0= =A0=A0=A0=A0=A0 media stream is the first media stream when it is described= by
=A0=A0=A0=A0=A0=A0 the first m line in the SDP offer and answer).=A0 For th= at media
=A0=A0=A0=A0=A0=A0 stream:

=A0=A0=A0=A0=A0=A0 *=A0 For al= l pairs with the same foundation, it sets the state of
=A0=A0=A0=A0=A0= =A0=A0=A0=A0 the pair with the lowest component ID to Waiting.=A0 If there = is
=A0=A0=A0=A0=A0=A0=A0=A0=A0 more than one such pair, the one with the highe= st priority is
=A0=A0=A0=A0=A0=A0=A0=A0=A0 used.
=A0"

At 5= .8. it says:

"

=A0=A0 o=A0 Find the highest-priority pair = in that check list that is in the
=A0=A0=A0=A0=A0 Waiting state.

=A0=A0 o=A0 If there is such a pair:

=A0=A0=A0=A0=A0 *=A0 Send a S= TUN check from the local candidate of that pair to the
=A0=A0=A0=A0=A0= =A0=A0=A0 remote candidate of that pair.=A0 The procedures for forming the<= br>=A0=A0=A0=A0=A0=A0=A0=A0 STUN request for this purpose are described in = Section 7.1.2.

=A0=A0=A0=A0=A0 *=A0 Set the state of the candidate pair to In-Progress.=

=A0=A0 o=A0 If there is no such pair:

=A0=A0=A0=A0=A0 *=A0 Fin= d the highest-priority pair in that check list that is in
=A0=A0=A0=A0= =A0=A0=A0=A0 the Frozen state.

=A0=A0=A0=A0=A0 *=A0 If there is such = a pair:

=A0=A0=A0=A0=A0=A0=A0=A0 +=A0 Unfreeze the pair.

=A0=A0=A0=A0=A0= =A0=A0=A0 +=A0 Perform a check for that pair, causing its state to
=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 transition to In-Progress.

"

<= p>As my understanding, clause 5.7.4 can be considered as the initialization= stage of the ICE check procedure expressed at clause 5.8.

The question is why the criterion of waiting pair selection is a little = different at the two stage.

At initliazation, it uses=A0 'foundat= ion' and 'component ID' to deduce the waiting pair,But at runti= me=A0 it mainly uses 'priority' .

=A0

I think the later is simple and nice. Can the same criterion b= e used at two stage?

=A0

Thanks in advance!


--0016e686ccd4df5b7304b12f5fe8-- From vsingh.ietf@gmail.com Sun Nov 13 02:41:41 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D2121F8B6E for ; Sun, 13 Nov 2011 02:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.775 X-Spam-Level: X-Spam-Status: No, score=-1.775 tagged_above=-999 required=5 tests=[AWL=1.824, 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 PRMGL3uy4dpl for ; Sun, 13 Nov 2011 02:41:40 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2CD21F8B6D for ; Sun, 13 Nov 2011 02:41:31 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so5933573bkb.31 for ; Sun, 13 Nov 2011 02:41:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=A56Mp/2OyKnW0QTdL97GNfnNnxwYZtDqlMqUIyDYI1c=; b=mVY7E6fL00gtljrz/thp3ZPXDvBQAG0d5pUc8mFtZ3btEITavTeDU50J5cKqCFXVF0 QKF78JgopdpnE/t6GbE/Zpi4u02ERILHctDxyTkA8s0hFJp/ydAlOY1SI79mOZHVmNev h4D8fQU4JFdiWnzygwnx9QYJVSbu2s9/lP5AY= Received: by 10.204.129.88 with SMTP id n24mr8144521bks.19.1321180890757; Sun, 13 Nov 2011 02:41:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.62.17 with HTTP; Sun, 13 Nov 2011 02:41:09 -0800 (PST) In-Reply-To: <4E4D0DC8.5030903@ericsson.com> References: <7F2072F1E0DE894DA4B517B93C6A05851DB6558B6D@ESESSCMS0356.eemea.ericsson.se> <4E4D0DC8.5030903@ericsson.com> From: Varun Singh Date: Sun, 13 Nov 2011 18:41:09 +0800 Message-ID: To: "Miguel A. Garcia" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmusic , Christer Holmberg Subject: Re: [MMUSIC] SDP comments on draft-singh-avtcore-mprtp-02: General - Connectivity checks X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 10:41:41 -0000 Hi, Apologies for the late reply. I have incorporated most of the changes suggested by Christer and Miguel and added some clarifications in some places. However, some comments are still work in progress. You can find the changes in the -03 draft (http://tools.ietf.org/rfcdiff?url2=3Ddraft-singh-avtcore-mprtp-0= 3.txt) 1. About using STUN instead of RTCP for interface advertisementsThis is still under consideration but we don't have an answer for this yet. Our implementation uses RTCP (possibly because of the ease of implementation) 2. In-band and Out-of-band interface advertisementWe have tried to clarify this in the new revision but it probably requires some more work (See http://tools.ietf.org/html/draft-singh-avtcore-mprtp-03#section-7= .1.3) - In case an endpoint receives an MPRTP interface advertisement (in RTCP or in SDP), then it should respond using the same mechanism.- In case of conflict between RTCP-based and SDP-based interface advertisement, then at this instance the endpoints MUST advertise using SDP.(if the endpoints send their interfaces independently at roughly the same time, one in RTCP and the other in SDP then in this particular instance they both should advertise using SDP.) 3. MPRTP in SDP There are two ways of doing this:- MPRTP without ICE: directly advertise the MPRTP interfaces (no need for connectivity checks)- MPRTP with ICE: first advertise ICE candidates and after the connectivity checks succeed, then advertise the MPRTP interfaces. If an endpoint gets an interface advertisement without ICE then it responds without ICE, else it responds with ICE. We have included some basic examples in http://tools.ietf.org/html/draft-singh-avtcore-mprtp-03#section-11.6 - TODO: More complex scenarios (when interfaces appear and disappear mid-session). Regards, Varun On Thu, Aug 18, 2011 at 21:04, Miguel A. Garcia wrote: > As an individual... > > Some comments to the connectivity checks of this draft. > > I basically agree with Christer. I find confusing several concepts that a= re > highly mixed in the draft, namely: > > a) Whether ICE is mandatory or not > > b) The presence of two mechanisms for doing connectivity checks: ICE and = the > RTP built-in > > c) It seems to be mandated to do connectivity checks prior to using the > MPRTP. This is something that currently is not mandated (unless you > implement ICE). But if you implement vanilla RTP, you don't need to test = the > connectivity before you send or receive data. > > So, the recommendation to the authors is to avoid mandating connectivity > tests, but having as an option. > > Use clear terminology: "STUN connectivity tests" versus "built-in RTP > connectivity tests". > > This, of course, assuming that you still want to support both types of > connectivity test, something that is arguable. > > /Miguel > > > On 03/08/2011 22:54, Christer Holmberg wrote: >> >> Hi, >> >> Below are some general comments on the connectivity checks. More specifi= c >> comments will be found in my e-mails commending the individual sections. >> >> Regards, >> >> Christer >> >> >> Connectivity checks: >> >> =A0 =A0 =A0 =A0FU_GEN-1: The document defines a new type of connectivity= check. We >> should have a >> =A0 =A0 =A0 =A0discussion whether that's a good thing to do or not, but = assuming >> it will be done, >> =A0 =A0 =A0 =A0as I also indicate in my editorial comments, you need to = more >> clearly define the "RTCP >> =A0 =A0 =A0 =A0connectivity checks" somewhere in the document, and then = refer to >> it. >> >> =A0 =A0 =A0 =A0I think you also need to describe the characteristic diff= erences >> (security etc) >> =A0 =A0 =A0 =A0compared to STUN connectivity checks, and I think you sho= uld have >> some text on why >> =A0 =A0 =A0 =A0you define a new type of connectivity check in the first = place >> (rather than relying on >> =A0 =A0 =A0 =A0STUN). >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > --=20 http://www.netlab.tkk.fi/~varun/ From Bert.Greevenbosch@huawei.com Tue Nov 15 00:01:34 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD101F0C3E for ; Tue, 15 Nov 2011 00:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[AWL=-1.799, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_55=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 tmmlNQlc4Zoa for ; Tue, 15 Nov 2011 00:01:33 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id E78601F0C45 for ; Tue, 15 Nov 2011 00:01:32 -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 <0LUO00LEEZK50G@szxga03-in.huawei.com> for mmusic@ietf.org; Tue, 15 Nov 2011 16:00:05 +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 <0LUO00E4PZK2LD@szxga03-in.huawei.com> for mmusic@ietf.org; Tue, 15 Nov 2011 16:00:05 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFB22321; Tue, 15 Nov 2011 15:59:58 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 15 Nov 2011 15:59:54 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.220]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0323.003; Tue, 15 Nov 2011 15:59:50 +0800 Date: Tue, 15 Nov 2011 07:59:50 +0000 From: Bert Greevenbosch In-reply-to: <002901cc9a46$771e6290$655b27b0$@dit.upm.es> X-Originating-IP: [172.24.2.41] To: Pedro Capelastegui , 'IETF - MMUSIC' Message-id: <46A1DF3F04371240B504290A071B4DB6231D5D12@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-GB Content-transfer-encoding: quoted-printable Accept-Language: en-GB, zh-CN, en-US Thread-topic: [MMUSIC] 3D format negotiation in draft-greevenbosch-mmusic-signal-3d-format Thread-index: AQHMmkZ8AmjgMGjWwkSMesWVKCSrNpWtjCH/ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <002801cc9a45$69afeda0$3d0fc8e0$@dit.upm.es> <002901cc9a46$771e6290$655b27b0$@dit.upm.es> Subject: Re: [MMUSIC] 3D format negotiation in draft-greevenbosch-mmusic-signal-3d-format X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 08:01:34 -0000 Hi Pedro,=0A= =0A= Sorry for my late response; I have been quite busy lately.=0A= =0A= Thanks for your e-mail, and for thinking with us about how to move forward = with the 3D drafts.=0A= =0A= To summarise your proposal:=0A= (1) Point at multiple possible video streams in a single media "m=3D" line = (i.e. a group of video streams per one media line; I'll call that a "media = group").=0A= (2) Stipulate that per media group, only one video stream can be chosen.=0A= (3) In one of the media groups, use the "depend" attribute to indicate whic= h video streams are associated with which video streams from the other medi= a group(s).=0A= (4) Use "3DS" grouping + "mid" attribute to label the media groups; needed = for the "depend" attribute.=0A= (5) Use the payload type to differentiate the streams within a media group.= =0A= =0A= I have thought about your proposal, and the following issues arose:=0A= (A) The usage of the payload type requires a different payload type for eac= h video stream. This is OK for streams that use a dynamic payload type. How= ever, certain RTP streams have fixed payload types. For example, MPEG-2 vid= eo over MPEG Transport Stream over RTP has fixed payload type 33. With your= proposal, it is not possible to do 3D simulcast of L- and R-streams in MPE= G-2.=0A= (B) It is true, that the number of "m=3D" lines in your proposal is less th= an in the current draft. But this is only a virtual reduction, as now multi= ple video streams are advertised in a single media line. In principle, the = same number of video streams is advertised.=0A= (C) With your proposal, in addition to the "3DS" grouping and the "3dFormat= " attribute, the "depend" attribute needs also be supported, with the parti= cular meaning as you have defined it.=0A= (D) Does having less "m=3D" lines justify the additional complexity of usin= g the "depend" attribute?=0A= (E) What if different video streams in the same media group require differe= nt SDP attributes?=0A= =0A= What do you think?=0A= =0A= Best regards,=0A= Bert=0A= =0A= =0A= ________________________________________=0A= From: Pedro Capelastegui [capelastegui@dit.upm.es]=0A= Sent: 04 November 2011 00:34=0A= To: 'IETF - MMUSIC'; Bert Greevenbosch=0A= Subject: RE: [MMUSIC] 3D format negotiation in draft-greevenbosch-mmusic-s= ignal-3d-format=0A= =0A= Hi,=0A= =0A= In the previous post, I argued against the 3D format negotiation mechanism= =0A= currently used in draft-greevenbosch-mmusic-signal-3d-format, and suggested= =0A= associating 3D formats with payload types instead. Here I explain how this= =0A= could be achieved.=0A= =0A= The process could be summarized as follows: 3d format configuration=0A= parameters are described in media level attributes (like in the current=0A= draft), but these attributes have a payload type as an additional parameter= :=0A= =0A= a=3D3dformat: <3dformat parameters>=0A= =0A= Each 3D media stream will be composed of one or two media descriptions, eac= h=0A= with one or more 3d format attributes. For each media description, an=0A= answerer would select one of the available media formats, with the preferre= d=0A= combination of codec and 3d format. In order to keep complexity manageable,= =0A= the answerer would only be allowed to choose a single media format when 3d= =0A= is enabled.=0A= =0A= This still leaves us with the problem of declaring dependencies between=0A= media descriptions within a 3D media stream (e.g. stream B is the depth map= =0A= of stream A, or stream B is the right view and stream A is the left one).= =0A= This could be signaled with the =91a=3Ddepend=92 attribute (see RFC 5583).= =0A= =0A= As an example, here is how this system would work in the scenario shown in= =0A= section 9.4 of draft-greevenbosch-mmusic-signal-3d-format. The offerer is= =0A= trying to initiate a session with a 3D video stream which can have 2=0A= possible configurations:=0A= =0A= (1) 1 stream for video and one stream for a parallax map=0A= (2) 1 stream for the left view and one for the right view.=0A= =0A= This is what the offer SDP would look like=0A= v=3D0=0A= o=3DAlice 2890844526 2890842807 IN IP4 131.163.72.4=0A= s=3DThe technology of 3D-TV=0A= c=3DIN IP4 131.164.74.2=0A= t=3D0 0=0A= a=3Dgroup:3DS 1 2=0A= m=3Dvideo 49170 RTP/AVP 99 100=0A= a=3Drtpmap:99 H264/90000=0A= a=3D3dFormat:99 2DA C=0A= a=3Drtpmap:100 H264/90000=0A= a=3D3dFormat:100 SC L=0A= a=3Dmid:1=0A= m=3Dvideo 49172 RTP/AVP 99 100=0A= a=3Drtpmap:99 H264/90000=0A= a=3D3dFormat:99 2DA P=0A= a=3Drtpmap:100 H264/90000=0A= a=3D3dFormat:100 SC R=0A= a=3Dmid:2=0A= a=3Ddepend 99 3dv 1:99; 100 3dv 1:100=0A= m=3Daudio 52890 RTP/AVP 10=0A= a=3Drtpmap:10 L16/16000/2=0A= =0A= =913dv=92 would be a new dependency-type defined for use with 3d format. Th= e=0A= =91depend=92 attribute is tipically used in combination with =93DDP=94 (dec= oding=0A= dependency) groups, though I think using it with =933DS=94 groups in this= =0A= scenario wouldn=92t go against the specification.=0A= =0A= This offer SDP has 2 video streams in a 3DS group, each with 2 possible=0A= configurations. The first one can be configured as a =91center=92 view in a= =0A= video+auxiliary map scheme, or as a left view in a simulcast scheme. The=0A= second media stream can be configured as a parallax map in a video+aux=0A= configuration, or as a right view in a simulcast configuration. Only certai= n=0A= payload type combinations are viable, which is signaled in the =91a=3Ddepen= d=92=0A= line: video stream 2 can only be configured as a parallax map if video=0A= stream 1 is the center view, and it can only be configured as a right view= =0A= if stream 1 is the left view.=0A= =0A= The SDP answer would look like this, if the answerer chooses the "center=0A= view plus parallax map" option:=0A= =0A= v=3D0=0A= o=3DBob 2890844528 2890842809 IN IP4 131.163.72.5=0A= s=3DThe technology of 3D-TV=0A= c=3DIN IP4 131.164.74.3=0A= t=3D0 0=0A= a=3Dgroup:3DS 1 2=0A= m=3Dvideo 48170 RTP/AVP 99=0A= a=3Drtpmap:99 H264/90000=0A= a=3D3dFormat:99 2DA C=0A= a=3Dmid:1=0A= m=3Dvideo 48172 RTP/AVP 99=0A= a=3Drtpmap:99 H264/90000=0A= a=3D3dFormat:99 2DA P=0A= a=3Dmid:2=0A= a=3Ddepend 99 3dv 1:99; 100 3dv 1:100=0A= m=3Daudio 52890 RTP/AVP 10=0A= a=3Drtpmap:10 L16/16000/2=0A= =0A= Compared to the SDPs used in draft-greevenbosch-mmusic-signal-3d-format,=0A= this offer/answer exchange only uses 3 media descriptions instead of 5.=0A= Also, including additional 3D formats would be more simple using this=0A= mechanism.=0A= =0A= Regards,=0A= Pedro=0A= =0A= -----Original Message-----=0A= From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= =0A= Pedro Capelastegui=0A= Sent: Thursday, November 03, 2011 5:27 PM=0A= To: IETF - MMUSIC; Bert.Greevenbosch@huawei.com=0A= Subject: [MMUSIC] 3D format negotiation in=0A= draft-greevenbosch-mmusic-signal-3d-format=0A= =0A= Hi,=0A= =0A= Here are some further comments on=0A= draft-greevenbosch-mmusic-signal-3d-format. These are focused on the 3d=0A= format negotiation process, and specifically how the extension behaves when= =0A= multiple 3d configuration options are offered.=0A= =0A= My main concern is that, in order to offer alternate 3d format=0A= configurations, the offerer has to include additional 'm=3D' lines in the S= DP.=0A= Currently, each media descriptor can have a single 3d format, and each 3d= =0A= format is associated to 1 or 2 media descriptors. This is not an issue in= =0A= offers with a single 3d format (see examples 9.1, 9.2 and 9.3), but when=0A= several 3d formats are offered, the number of media descriptors multiplies.= =0A= This can be observed in example 9.4, where 4 media descriptors are used in= =0A= the offer, though the answerer is expected to reject all but two. In=0A= general, in order to provide N 3D format options for a 3D video=0A= stream,between N and 2N media descriptors will be required in the offered= =0A= SDP, of which only one or two will be used.=0A= =0A= I think this proliferation of media descriptions has several drawbacks. For= =0A= one, it goes against the general philosophy of SDP negotiation. Normally,= =0A= when different possible configurations exist for a media stream, they are= =0A= shown as different media formats within a single media descriptor. Using=0A= multiple media descriptors that actually refer to the same media stream (th= e=0A= 3D video stream, or a subset of it), and having the answerer reject all but= =0A= the ones with the desired configuration breaks this model. In addition, thi= s=0A= excess of 'm=3D' lines may have a negative effect when combined with=0A= techniques such as ICE, and could be confusing for 3d-unaware nodes.=0A= =0A= On the other hand, this is only a problem if user agents are expected to=0A= select between many 3d formats on an average session. Unfortunately, I thin= k=0A= this will be the case. At the very least, a UA starting a 3D session should= =0A= provide a single 3D format and the option not to use 3D. Apart from that, a= =0A= 3D user agent intended to be interoperable with other UAs should support=0A= several 3D formats, including video+depth and transmission of 2 views.=0A= =0A= The solution, in my opinion, would be to shift away from the current model= =0A= and instead associate each 3D format with a payload type within a media=0A= description. I will discuss how this can be done in a separate mail.=0A= =0A= Regards,=0A= =0A= Pedro=0A= =0A= _______________________________________________=0A= mmusic mailing list=0A= mmusic@ietf.org=0A= https://www.ietf.org/mailman/listinfo/mmusic=0A= -----=0A= No se encontraron virus en este mensaje.=0A= Comprobado por AVG - www.avg.com=0A= Versi=F3n: 10.0.1411 / Base de datos de virus: 2092/3992 - Fecha de=0A= publicaci=F3n: 11/02/11=0A= =0A= From fandreas@cisco.com Tue Nov 15 04:49:08 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFBF21F8D73 for ; Tue, 15 Nov 2011 04:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNMgHzT7U3lA for ; Tue, 15 Nov 2011 04:49:08 -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 1A5F021F8D72 for ; Tue, 15 Nov 2011 04:49:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=2571; q=dns/txt; s=iport; t=1321361348; x=1322570948; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=pk+D7KV7A7jeS2BD6YvXf4KDEw0j3zDq0gdFTCzj0pU=; b=gsNfEbp0WIQhCpPqiBVAx5EL9pDU5AURh7a75WPqAwHAxMWWy4vzKkWJ eadoWmSHP1VqBVqDU7hfK/uUkY9c0FUAyY1OPuD13n1RarVk3uAdhZ7dg 2Xg9nw/en5l7aTFOum1Ipu7sCbOz7Fx5CxuOmMb7d3YD7CnH1sTG+nVKS w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAF5fwk6rRDoH/2dsb2JhbABDqW2BBYILASVAPRYYAwIBAgFLDQgBAQUSB4domU+BJgGfB4oRBIgTjB+SGA X-IronPort-AV: E=Sophos;i="4.69,515,1315180800"; d="scan'208";a="12612483" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 15 Nov 2011 12:49:07 +0000 Received: from dhcp-454f.meeting.ietf.org ([10.21.76.128]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAFCn6m2010419 for ; Tue, 15 Nov 2011 12:49:06 GMT Message-ID: <4EC25FCC.6030702@cisco.com> Date: Tue, 15 Nov 2011 07:49:16 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Do We Need an ICE Alternative ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 12:49:08 -0000 Greetings Over the past several years, the MMUSIC WG has developed and standardized ICE (RFC 5245) as the mechanism to enable NAT traversal and IPv4/IPv6 transition for Offer/Answer based protocols (such as SIP). Alternative NAT traversal mechanisms exist, and others have been proposed, however they have either been limited to specific deployment topologies (e.g. symmetric RTP or STUN by itself) or required some level of network support (e.g. an ALG of some sort). Similarly, for IPv4/IPv6 transition, RFC 4091/4092 (ANAT) defined an alternative solution that was deprecated following MMUSIC and SIPPING WG discssion and consensus at IETF68 (in 2007): http://www.ietf.org/proceedings/68/minutes/mmusic.txt http://www.ietf.org/proceedings/68/minutes/sipping.txt Several years have passed and we have been getting more implementation and deployment experience with ICE. However, we have also seen suggestions for alternative solutions, with recent examples including the ALTC draft for IPv4/IPv6 transition and the latching mechanism for NAT traversal: Link to ALTC draft: https://datatracker.ietf.org/doc/draft-boucadair-mmusic-altc/ Link to latching mechanism (Section 5.7 in old version of loopback draft): http://tools.ietf.org/id/draft-ietf-mmusic-media-loopback-15.txt Alternatives, that generally have a more limited scope than ICE, keep popping up every now and then, and it seems that at least some set of people are not happy with the current ICE solution. So, we would like to understand from the working group if there are issues with ICE and if we need to explore alternative solutions for NAT traversal and/or for IPv4/IPv6 transition. Our goal as a standards organization is to enable interoperable products, and having multiple different standards for the same problem or multiple different standards for specific instances of a general problem is not conducive to that. If we have to revisit one of the standards for a given problem space, we ought to be careful and understand what are the issues that we have with that standard. Furthermore, if we are to come with alternative solutions for that problem space, we have to ensure a clear understanding of what has changed since the last time we created the standard, what are the new set of requirements to satisfy, and which of the old requirements no longer apply. So, we would like to sense the WG for opinions in this matter Thanks Flemming and Miguel (MMUSIC chairs) From internet-drafts@ietf.org Tue Nov 15 07:32:17 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433BB21F8B68; Tue, 15 Nov 2011 07:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 Y6VsEVRLSynh; Tue, 15 Nov 2011 07:32:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F6C21F8B1F; Tue, 15 Nov 2011 07:32:16 -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: 3.63 Message-ID: <20111115153216.16491.16948.idtracker@ietfa.amsl.com> Date: Tue, 15 Nov 2011 07:32:16 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-tcp-16.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 15:32:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : TCP Candidates with Interactive Connectivity Establishme= nt (ICE) Author(s) : Jonathan Rosenberg Ari Keranen Bruce B. Lowekamp Adam Roach Filename : draft-ietf-mmusic-ice-tcp-16.txt Pages : 30 Date : 2011-11-15 Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN). ICE provides a general framework for describing candidates, but only defines UDP-based media streams. This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-tcp-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-mmusic-ice-tcp-16.txt From ari.keranen@nomadiclab.com Tue Nov 15 07:51:33 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A6C11E808C for ; Tue, 15 Nov 2011 07:51:33 -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 4m208jBy2bZM for ; Tue, 15 Nov 2011 07:51:29 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0D54F11E8097 for ; Tue, 15 Nov 2011 07:51:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id A20304E701 for ; Tue, 15 Nov 2011 17:51:27 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7jwz54EjgRU for ; Tue, 15 Nov 2011 17:51:23 +0200 (EET) Received: from As-MacBook-Air.local (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 3BFDB4E6E1 for ; Tue, 15 Nov 2011 17:51:21 +0200 (EET) Message-ID: <4EC28A76.1080203@nomadiclab.com> Date: Tue, 15 Nov 2011 23:51:18 +0800 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <20111115153216.16491.16948.idtracker@ietfa.amsl.com> In-Reply-To: <20111115153216.16491.16948.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-tcp-16.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 15:51:33 -0000 Folks, This new revision addresses the IESG and Gen-ART review comments. There are lots of editorial fixes but also two technical changes, as requested by ADs, worth noting: - The "tcptype" parameter's value in the SDP is now "active" or "passive" instead of "act" or "pass". This was due to comment that the "pass" can be misinterpreted as "passing" and it's not really worth saving a few bytes here. Also, this is now better in line with RFC4145 terminology. - The RTP over TLS is no longer "MUST NOT" but "SHOULD be avoided". It was not really clear why it was "MUST NOT" in the first place (some new rationale is now given in the draft) and there could be cases when someone really wants to do that and we didn't find any compelling reason why to forbid that. Cheers, Ari On 11/15/11 11:32 PM, 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 Multiparty Multimedia Session Control Working Group of the IETF. > > Title : TCP Candidates with Interactive Connectivity Establishment (ICE) > Author(s) : Jonathan Rosenberg > Ari Keranen > Bruce B. Lowekamp > Adam Roach > Filename : draft-ietf-mmusic-ice-tcp-16.txt > Pages : 30 > Date : 2011-11-15 > > Interactive Connectivity Establishment (ICE) defines a mechanism for > NAT traversal for multimedia communication protocols based on the > offer/answer model of session negotiation. ICE works by providing a > set of candidate transport addresses for each media stream, which are > then validated with peer-to-peer connectivity checks based on Session > Traversal Utilities for NAT (STUN). ICE provides a general framework > for describing candidates, but only defines UDP-based media streams. > This specification extends ICE to TCP-based media, including the > ability to offer a mix of TCP and UDP-based candidates for a single > stream. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-tcp-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-mmusic-ice-tcp-16.txt > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From miguel.a.garcia@ericsson.com Tue Nov 15 18:03:34 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC82A11E818F for ; Tue, 15 Nov 2011 18:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.373 X-Spam-Level: X-Spam-Status: No, score=-6.373 tagged_above=-999 required=5 tests=[AWL=0.226, 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 ErO6esgRGLff for ; Tue, 15 Nov 2011 18:03:27 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 71BE811E8189 for ; Tue, 15 Nov 2011 18:03:27 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-7b-4ec319eef99f Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 89.26.09514.EE913CE4; Wed, 16 Nov 2011 03:03:26 +0100 (CET) Received: from [159.107.48.180] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Wed, 16 Nov 2011 03:03:25 +0100 Message-ID: <4EC319EA.20802@ericsson.com> Date: Wed, 16 Nov 2011 03:03:22 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen Subject: [MMUSIC] Updated agenda. MMUSIC meeting at IETF 82 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 02:03:34 -0000 We have updated the agenda of our meeting on Friday. It has been uploaded to the meeting's material site: http://www.ietf.org/proceedings/82/agenda/mmusic.htm /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From fandreas@cisco.com Tue Nov 15 18:30:18 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9570C11E81C7 for ; Tue, 15 Nov 2011 18:30:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZ7lUFRPVoR6 for ; Tue, 15 Nov 2011 18:30:14 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0965E11E81B8 for ; Tue, 15 Nov 2011 18:30:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=8293; q=dns/txt; s=iport; t=1321410614; x=1322620214; h=message-id:date:from:mime-version:to:subject; bh=xQydCsVYWxv9+FYRANHC65TwBd8zkpK29adAGpjB1PQ=; b=kjBz5bsamFQUdGq1Ct9Vu4iLmaEvkQ3ECS3zqtHk8xFsa2OhNvHBOam7 5H6z301drUdsJEHcTqYIltsaiSgasko63r8Dc9olJt6xA4+8WV2VSDez2 zhVxfuywBlhsc81fwlj6rcrhxv0lbe1vn6xI/7WKJLq0w9vWRJz0P/EDk Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABYfw06rRDoI/2dsb2JhbABDqXKBBYFyAQEBBQEBDwFbCg0gAwECChYYAwIBAgEVJgIODQYCAQEFGYdomTuBJgGeVIoXBIgUjCCSGg X-IronPort-AV: E=Sophos;i="4.69,518,1315180800"; d="scan'208,217";a="14465298" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 16 Nov 2011 02:30:12 +0000 Received: from dhcp-1345.meeting.ietf.org (sjc-vpn2-1148.cisco.com [10.21.116.124]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAG2UBck015947 for ; Wed, 16 Nov 2011 02:30:12 GMT Message-ID: <4EC32040.3080509@cisco.com> Date: Tue, 15 Nov 2011 21:30:24 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: mmusic Content-Type: multipart/alternative; boundary="------------090106080506030508010309" Subject: [MMUSIC] Fwd: I-D Action: draft-ietf-mmusic-sdp-media-capabilities-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 02:30:18 -0000 This is a multi-part message in MIME format. --------------090106080506030508010309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The major change in this version of the media capabilities draft is around media format capabilites ("mcap"). Previous versions of the draft effectively limited media format capabilities to being RTP-based media formats, which was noted as problematic by the circuit-switched bearer authors (draft-ietf-mmusic-sdp-cs). There were two different ways of addressing this: 1) Redefine syntax and semantics of the existing "a=mcap" attribute to cover both RTP-based and non-RTP based media formats 2) Split "mcap" in two different attributes; one for RTP-based and one for non-RTP based. The media capabilities authors went for the second option in order to avoid semantically different operations based on the type of media format a given media format capability has. Furthermore, for consistency and to avoid any confusion with earlier "mcap" definitions, the authors used two new names for these attributes ("rmcap" and "omcap"). Various other nit fixes and editorial changes have been made throughout as well (http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-mmusic-sdp-media-capabilities-12.txt) If anybody has any concerns with the above, please let us know. The draft still needs updated offer/answer considerations and security considerations. The plan is to have those done before the next IETF and hopefully be ready for WGLC shortly thereafter. Thanks -- Flemming (as individual) -------- Original Message -------- Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-media-capabilities-12.txt Date: Mon, 31 Oct 2011 10:04:03 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: mmusic@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : SDP Media Mapabilities Negotiation Author(s) : Robert R Gilman Roni Even Flemming Andreasen Filename : draft-ietf-mmusic-sdp-media-capabilities-12.txt Pages : 50 Date : 2011-10-31 Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. In this document, we extend the framework by defining media capabilities that can be used to negotiate media types and their associated parameters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-media-capabilities-12.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-mmusic-sdp-media-capabilities-12.txt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --------------090106080506030508010309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The major change in this version of the media capabilities draft is around media format capabilites ("mcap"). Previous versions of the draft effectively limited media format capabilities to being RTP-based media formats, which was noted as problematic by the circuit-switched bearer authors (draft-ietf-mmusic-sdp-cs). There were two different ways of addressing this:
1) Redefine syntax and semantics of the existing "a=mcap" attribute to cover both RTP-based and non-RTP based media formats
2) Split "mcap" in two different attributes; one for RTP-based and one for non-RTP based.

The media capabilities authors went for the second option in order to avoid semantically different operations based on the type of media format a given media format capability has. Furthermore, for consistency and to avoid any confusion with earlier "mcap" definitions, the authors used two new names for these attributes ("rmcap" and "omcap").

Various other nit fixes and editorial changes have been made throughout as well (http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-mmusic-sdp-media-capabilities-12.txt)

If anybody has any concerns with the above, please let us know.

The draft still needs updated offer/answer considerations and security considerations. The plan is to have those done before the next IETF and hopefully be ready for WGLC shortly thereafter.

Thanks

-- Flemming (as individual)

-------- Original Message --------
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-media-capabilities-12.txt
Date: Mon, 31 Oct 2011 10:04:03 -0700
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
CC: mmusic@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title           : SDP Media Mapabilities Negotiation
	Author(s)       : Robert R Gilman
                          Roni Even
                          Flemming Andreasen
	Filename        : draft-ietf-mmusic-sdp-media-capabilities-12.txt
	Pages           : 50
	Date            : 2011-10-31

   Session Description Protocol (SDP) capability negotiation provides a
   general framework for indicating and negotiating capabilities in SDP.
   The base framework defines only capabilities for negotiating
   transport protocols and attributes.  In this document, we extend the
   framework by defining media capabilities that can be used to
   negotiate media types and their associated parameters.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-media-capabilities-12.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-mmusic-sdp-media-capabilities-12.txt
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
--------------090106080506030508010309-- From andrew.hutton@siemens-enterprise.com Tue Nov 15 18:57:33 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5C411E81DD for ; Tue, 15 Nov 2011 18:57:33 -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 pnEWfESqVwZK for ; Tue, 15 Nov 2011 18:57:29 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 30E4411E81DB for ; Tue, 15 Nov 2011 18:57:29 -0800 (PST) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id A54BE23F04ED; Wed, 16 Nov 2011 03:57:25 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 16 Nov 2011 03:57:25 +0100 From: "Hutton, Andrew" To: Flemming Andreasen , mmusic Date: Wed, 16 Nov 2011 03:57:21 +0100 Thread-Topic: [MMUSIC] Do We Need an ICE Alternative ? Thread-Index: AcyjlP2mrTgfFTODS7ucr4aiUU4Y/wAbq1Jw Message-ID: <101C6067BEC68246B0C3F6843BCCC1E311FAB66360@MCHP058A.global-ad.net> References: <4EC25FCC.6030702@cisco.com> In-Reply-To: <4EC25FCC.6030702@cisco.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: Re: [MMUSIC] Do We Need an ICE Alternative ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 02:57:33 -0000 Hi, My understanding of previous discussion. During IETF77 we discussed both the altc draft (http://tools.ietf.org/html/= draft-boucadair-mmusic-altc-03) and the alternative ICE-microlite draft (ht= tp://tools.ietf.org/html/draft-hutton-mmusic-icemicrolite-02).=20 The conclusion of this discussion was that there was no way forward for eit= her of these drafts as stated in the minutes of this meeting (http://www.ie= tf.org/proceedings/77/minutes/mmusic.html). However I notice that draft-boucadair-mmusic-altc continues to be updated a= lthough there has been no discussion or even notification of updates on the= MMUSIC list.=20 Therefore I would like to know what is the current status and intention reg= arding the altc draft? During IETF80 draft http://tools.ietf.org/html/draft-elwell-mmusic-ice-upda= ted-offer-01 was presented with the intention of starting a discussion on s= ome of the barriers to deploying ICE. The feedback we obtained was that the= requirement for an updated offer in ICE was not really that strict, even t= hough it is mandatory in the draft, and implementations are not always impl= ementing this anyway. The conclusion I understood was to continue to docum= ent and discuss the problems and if necessary if there are enough issues ra= ised update ICE. Regards Andy > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Flemming Andreasen > Sent: 15 November 2011 20:49 > To: mmusic > Subject: [MMUSIC] Do We Need an ICE Alternative ? >=20 > Greetings >=20 > Over the past several years, the MMUSIC WG has developed and > standardized ICE (RFC 5245) as the mechanism to enable NAT traversal > and > IPv4/IPv6 transition for Offer/Answer based protocols (such as SIP). > Alternative NAT traversal mechanisms exist, and others have been > proposed, however they have either been limited to specific deployment > topologies (e.g. symmetric RTP or STUN by itself) or required some > level > of network support (e.g. an ALG of some sort). Similarly, for IPv4/IPv6 > transition, RFC 4091/4092 (ANAT) defined an alternative solution that > was deprecated following MMUSIC and SIPPING WG discssion and consensus > at IETF68 (in 2007): >=20 > http://www.ietf.org/proceedings/68/minutes/mmusic.txt > http://www.ietf.org/proceedings/68/minutes/sipping.txt >=20 > Several years have passed and we have been getting more implementation > and deployment experience with ICE. However, we have also seen > suggestions for alternative solutions, with recent examples including > the ALTC draft for IPv4/IPv6 transition and the latching mechanism for > NAT traversal: >=20 > Link to ALTC draft: > https://datatracker.ietf.org/doc/draft-boucadair-mmusic-altc/ >=20 > Link to latching mechanism (Section 5.7 in old version of loopback > draft): > http://tools.ietf.org/id/draft-ietf-mmusic-media-loopback-15.txt >=20 >=20 > Alternatives, that generally have a more limited scope than ICE, keep > popping up every now and then, and it seems that at least some set of > people are not happy with the current ICE solution. So, we would like > to > understand from the working group if there are issues with ICE and if > we > need to explore alternative solutions for NAT traversal and/or for > IPv4/IPv6 transition. >=20 > Our goal as a standards organization is to enable interoperable > products, and having multiple different standards for the same problem > or multiple different standards for specific instances of a general > problem is not conducive to that. If we have to revisit one of the > standards for a given problem space, we ought to be careful and > understand what are the issues that we have with that standard. > Furthermore, if we are to come with alternative solutions for that > problem space, we have to ensure a clear understanding of what has > changed since the last time we created the standard, what are the new > set of requirements to satisfy, and which of the old requirements no > longer apply. >=20 > So, we would like to sense the WG for opinions in this matter >=20 > Thanks >=20 > Flemming and Miguel (MMUSIC chairs) > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From HKaplan@acmepacket.com Tue Nov 15 22:26:09 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508AC21F92AA for ; Tue, 15 Nov 2011 22:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 CadiPhRJ04kd for ; Tue, 15 Nov 2011 22:26:05 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 388CE21F92AE for ; Tue, 15 Nov 2011 22:26:05 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 16 Nov 2011 01:26:03 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 16 Nov 2011 01:26:02 -0500 From: Hadriel Kaplan To: "Hutton, Andrew" Thread-Topic: [MMUSIC] Do We Need an ICE Alternative ? Thread-Index: AQHMpCicY4fxjr42VE+QGSGIFekSoQ== Date: Wed, 16 Nov 2011 06:26:02 +0000 Message-ID: References: <4EC25FCC.6030702@cisco.com> <101C6067BEC68246B0C3F6843BCCC1E311FAB66360@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E311FAB66360@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] Do We Need an ICE Alternative ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 06:26:09 -0000 On Nov 15, 2011, at 9:57 PM, Hutton, Andrew wrote: > Hi, >=20 > My understanding of previous discussion. > During IETF77 we discussed both the altc draft (http://tools.ietf.org/htm= l/draft-boucadair-mmusic-altc-03) and the alternative ICE-microlite draft (= http://tools.ietf.org/html/draft-hutton-mmusic-icemicrolite-02).=20 > The conclusion of this discussion was that there was no way forward for e= ither of these drafts as stated in the minutes of this meeting (http://www.= ietf.org/proceedings/77/minutes/mmusic.html). > However I notice that draft-boucadair-mmusic-altc continues to be updated= although there has been no discussion or even notification of updates on t= he MMUSIC list.=20 >=20 > Therefore I would like to know what is the current status and intention r= egarding the altc draft? It's now an independent submission to the RFC editor, outside of IETF. It = was updated based on comments back from the assigned reviewer. If you have comments/edits/changes/concerns you'd like to make on the altc = draft, please email the authors - we'd love to hear them and address them. -hadriel From andrew.hutton@siemens-enterprise.com Tue Nov 15 22:47:22 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AFD21F9328 for ; Tue, 15 Nov 2011 22:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 cZhTp3Le8LYs for ; Tue, 15 Nov 2011 22:47:18 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFEA21F9324 for ; Tue, 15 Nov 2011 22:47:18 -0800 (PST) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 82C8423F04D4; Wed, 16 Nov 2011 07:47:17 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 16 Nov 2011 07:47:17 +0100 From: "Hutton, Andrew" To: Hadriel Kaplan Date: Wed, 16 Nov 2011 07:47:15 +0100 Thread-Topic: [MMUSIC] Do We Need an ICE Alternative ? Thread-Index: AQHMpCicY4fxjr42VE+QGSGIFekSoZWvDmdQ Message-ID: <101C6067BEC68246B0C3F6843BCCC1E311FAB66395@MCHP058A.global-ad.net> References: <4EC25FCC.6030702@cisco.com> <101C6067BEC68246B0C3F6843BCCC1E311FAB66360@MCHP058A.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] Do We Need an ICE Alternative ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 06:47:22 -0000 I assume then that the draft should no longer indicate that it is "Standard= s Track". Regards Andy > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: 16 November 2011 14:26 > To: Hutton, Andrew > Cc: Flemming Andreasen; mmusic > Subject: Re: [MMUSIC] Do We Need an ICE Alternative ? >=20 >=20 > On Nov 15, 2011, at 9:57 PM, Hutton, Andrew wrote: >=20 > > Hi, > > > > My understanding of previous discussion. > > During IETF77 we discussed both the altc draft > (http://tools.ietf.org/html/draft-boucadair-mmusic-altc-03) and the > alternative ICE-microlite draft (http://tools.ietf.org/html/draft- > hutton-mmusic-icemicrolite-02). > > The conclusion of this discussion was that there was no way forward > for either of these drafts as stated in the minutes of this meeting > (http://www.ietf.org/proceedings/77/minutes/mmusic.html). > > However I notice that draft-boucadair-mmusic-altc continues to be > updated although there has been no discussion or even notification of > updates on the MMUSIC list. > > > > Therefore I would like to know what is the current status and > intention regarding the altc draft? >=20 > It's now an independent submission to the RFC editor, outside of IETF. > It was updated based on comments back from the assigned reviewer. >=20 > If you have comments/edits/changes/concerns you'd like to make on the > altc draft, please email the authors - we'd love to hear them and > address them. >=20 > -hadriel From HKaplan@acmepacket.com Tue Nov 15 23:56:06 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B258C11E816D for ; Tue, 15 Nov 2011 23:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 6Kjy67rPJ3v5 for ; Tue, 15 Nov 2011 23:56:02 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB9711E8138 for ; Tue, 15 Nov 2011 23:56:02 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 16 Nov 2011 02:56:01 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 16 Nov 2011 02:56:00 -0500 From: Hadriel Kaplan To: Andrew Hutton Thread-Topic: [MMUSIC] Do We Need an ICE Alternative ? Thread-Index: AQHMpDUtuWsTsHpkKk6Q9IG8V2rckg== Date: Wed, 16 Nov 2011 07:55:59 +0000 Message-ID: <2DA899DD-4BA2-464F-B8D6-FC99A051EF1D@acmepacket.com> References: <4EC25FCC.6030702@cisco.com> <101C6067BEC68246B0C3F6843BCCC1E311FAB66360@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E311FAB66395@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E311FAB66395@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <5480292549D65844ABCE3CD1893244BA@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: Flemming Andreasen , "mmusic \(E-mail\)" , "draft-boucadair-mmusic-altc@tools.ietf.org" Subject: Re: [MMUSIC] Do We Need an ICE Alternative ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 07:56:06 -0000 I think (hope) the RFC Editor actually fixes that stuff, but you're right w= e should change the draft to correct it now. I'll ask Mohamed to rev the doc or explicitly point this out to the RFC Edi= tor. (publication was already requested) -hadriel On Nov 16, 2011, at 1:47 AM, Hutton, Andrew wrote: > I assume then that the draft should no longer indicate that it is "Standa= rds Track". >=20 >=20 > Regards > Andy >=20 >> -----Original Message----- >> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >> Sent: 16 November 2011 14:26 >> To: Hutton, Andrew >> Cc: Flemming Andreasen; mmusic >> Subject: Re: [MMUSIC] Do We Need an ICE Alternative ? >>=20 >>=20 >> On Nov 15, 2011, at 9:57 PM, Hutton, Andrew wrote: >>=20 >>> Hi, >>>=20 >>> My understanding of previous discussion. >>> During IETF77 we discussed both the altc draft >> (http://tools.ietf.org/html/draft-boucadair-mmusic-altc-03) and the >> alternative ICE-microlite draft (http://tools.ietf.org/html/draft- >> hutton-mmusic-icemicrolite-02). >>> The conclusion of this discussion was that there was no way forward >> for either of these drafts as stated in the minutes of this meeting >> (http://www.ietf.org/proceedings/77/minutes/mmusic.html). >>> However I notice that draft-boucadair-mmusic-altc continues to be >> updated although there has been no discussion or even notification of >> updates on the MMUSIC list. >>>=20 >>> Therefore I would like to know what is the current status and >> intention regarding the altc draft? >>=20 >> It's now an independent submission to the RFC editor, outside of IETF. >> It was updated based on comments back from the assigned reviewer. >>=20 >> If you have comments/edits/changes/concerns you'd like to make on the >> altc draft, please email the authors - we'd love to hear them and >> address them. >>=20 >> -hadriel >=20 From andrew.hutton@siemens-enterprise.com Wed Nov 16 00:23:08 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC30B21F93D1 for ; Wed, 16 Nov 2011 00:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 cAS18yRBHiK2 for ; Wed, 16 Nov 2011 00:23:08 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id B637621F91E1 for ; Wed, 16 Nov 2011 00:23:07 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 6A0621EB8471; Wed, 16 Nov 2011 09:23:06 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 16 Nov 2011 09:23:06 +0100 From: "Hutton, Andrew" To: Hadriel Kaplan Date: Wed, 16 Nov 2011 09:23:01 +0100 Thread-Topic: [MMUSIC] Do We Need an ICE Alternative ? Thread-Index: AQHMpDUtuWsTsHpkKk6Q9IG8V2rckpWvKCNg Message-ID: <101C6067BEC68246B0C3F6843BCCC1E311FAB663E8@MCHP058A.global-ad.net> References: <4EC25FCC.6030702@cisco.com> <101C6067BEC68246B0C3F6843BCCC1E311FAB66360@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E311FAB66395@MCHP058A.global-ad.net> <2DA899DD-4BA2-464F-B8D6-FC99A051EF1D@acmepacket.com> In-Reply-To: <2DA899DD-4BA2-464F-B8D6-FC99A051EF1D@acmepacket.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 Cc: Flemming Andreasen , "mmusic \(E-mail\)" , "draft-boucadair-mmusic-altc@tools.ietf.org" Subject: Re: [MMUSIC] Do We Need an ICE Alternative ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 08:23:09 -0000 Thanks and I would appreciate a quick update to correct the intended status= of the draft. If I remember correctly the draft has some limitations in the way it handle= s RTCP ports and would for example be incompatible with RFC 3605 because th= ere is no way to indicate a different port for each address type. If you ag= ree would it be possible to state these limitations in the draft. Regards Andy > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: 16 November 2011 15:56 > To: Hutton, Andrew > Cc: Flemming Andreasen; mmusic (E-mail); draft-boucadair-mmusic- > altc@tools.ietf.org > Subject: Re: [MMUSIC] Do We Need an ICE Alternative ? >=20 >=20 > I think (hope) the RFC Editor actually fixes that stuff, but you're > right we should change the draft to correct it now. > I'll ask Mohamed to rev the doc or explicitly point this out to the RFC > Editor. (publication was already requested) >=20 > -hadriel >=20 >=20 > On Nov 16, 2011, at 1:47 AM, Hutton, Andrew wrote: >=20 > > I assume then that the draft should no longer indicate that it is > "Standards Track". > > > > > > Regards > > Andy > > > >> -----Original Message----- > >> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > >> Sent: 16 November 2011 14:26 > >> To: Hutton, Andrew > >> Cc: Flemming Andreasen; mmusic > >> Subject: Re: [MMUSIC] Do We Need an ICE Alternative ? > >> > >> > >> On Nov 15, 2011, at 9:57 PM, Hutton, Andrew wrote: > >> > >>> Hi, > >>> > >>> My understanding of previous discussion. > >>> During IETF77 we discussed both the altc draft > >> (http://tools.ietf.org/html/draft-boucadair-mmusic-altc-03) and the > >> alternative ICE-microlite draft (http://tools.ietf.org/html/draft- > >> hutton-mmusic-icemicrolite-02). > >>> The conclusion of this discussion was that there was no way forward > >> for either of these drafts as stated in the minutes of this meeting > >> (http://www.ietf.org/proceedings/77/minutes/mmusic.html). > >>> However I notice that draft-boucadair-mmusic-altc continues to be > >> updated although there has been no discussion or even notification > of > >> updates on the MMUSIC list. > >>> > >>> Therefore I would like to know what is the current status and > >> intention regarding the altc draft? > >> > >> It's now an independent submission to the RFC editor, outside of > IETF. > >> It was updated based on comments back from the assigned reviewer. > >> > >> If you have comments/edits/changes/concerns you'd like to make on > the > >> altc draft, please email the authors - we'd love to hear them and > >> address them. > >> > >> -hadriel > > From capelastegui@dit.upm.es Wed Nov 16 06:03:40 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6EC1F0C55 for ; Wed, 16 Nov 2011 06:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.366 X-Spam-Level: X-Spam-Status: No, score=-1.366 tagged_above=-999 required=5 tests=[AWL=-1.167, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTM2G3D2kAv5 for ; Wed, 16 Nov 2011 06:03:40 -0800 (PST) Received: from mail.dit.upm.es (mail.dit.upm.es [IPv6:2001:720:1500:42:215:c5ff:fef6:86e4]) by ietfa.amsl.com (Postfix) with ESMTP id 933841F0C4B for ; Wed, 16 Nov 2011 06:03:39 -0800 (PST) Received: from correo.dit.upm.es (correo.dit.upm.es [IPv6:2001:720:1500:42:250:56ff:fea2:7367]) by mail.dit.upm.es (8.14.2/8.14.2) with ESMTP id pAGE3O4U010012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Nov 2011 15:03:24 +0100 Received: from delta (delta.dit.upm.es [138.4.7.204]) (authenticated bits=0) by correo.dit.upm.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAGE3DPc026116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 Nov 2011 15:03:14 +0100 From: "Pedro Capelastegui" To: "'Bert Greevenbosch'" , "'IETF - MMUSIC'" References: <002801cc9a45$69afeda0$3d0fc8e0$@dit.upm.es> <002901cc9a46$771e6290$655b27b0$@dit.upm.es> <46A1DF3F04371240B504290A071B4DB6231D5D12@szxeml509-mbs.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB6231D5D12@szxeml509-mbs.china.huawei.com> Date: Wed, 16 Nov 2011 15:03:24 +0100 Message-ID: <001801cca468$81d2ed60$8578c820$@dit.upm.es> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKXCGBtb1yACvM5goToMvn0QrotsAJ5XQo5AY9YFvKT+nd0AA== Content-Language: es Subject: Re: [MMUSIC] 3D format negotiation in draft-greevenbosch-mmusic-signal-3d-format X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 14:03:40 -0000 Hi Bert, Thanks for answering. Answers inline. Regards, Pedro > -----Original Message----- > From: Bert Greevenbosch [mailto:Bert.Greevenbosch@huawei.com] > Sent: Tuesday, November 15, 2011 9:00 AM > To: Pedro Capelastegui; 'IETF - MMUSIC' > Subject: RE: [MMUSIC] 3D format negotiation in draft-greevenbosch- > mmusic-signal-3d-format > > Hi Pedro, > > Sorry for my late response; I have been quite busy lately. > > Thanks for your e-mail, and for thinking with us about how to move forward > with the 3D drafts. > > To summarise your proposal: > (1) Point at multiple possible video streams in a single media "m=" line (i.e. a > group of video streams per one media line; I'll call that a "media group"). > (2) Stipulate that per media group, only one video stream can be chosen. > (3) In one of the media groups, use the "depend" attribute to indicate which > video streams are associated with which video streams from the other media > group(s). > (4) Use "3DS" grouping + "mid" attribute to label the media groups; needed > for the "depend" attribute. > (5) Use the payload type to differentiate the streams within a media group. Your summary is correct. However, I'd like to comment something about the terminology. I think it's best to refer to the "m=" lines as "media descriptions", and to the configurations associated with each payload type number as "media format", since this matches the vocabulary used in other RFCs. Your use of "video streams" and "media groups" could be helpful in drawing parallels between both proposals, but it wouldn't be entirely accurate, for the following reasons: - A media descriptor ("media group") in my proposal is not the equivalent to a "3DS" group of media streams in the current draft. - A media format ("video stream") in my proposal may actually include multiple video streams, either through frame packing, or by using 2D+auxiliary data formats. > I have thought about your proposal, and the following issues arose: > (A) The usage of the payload type requires a different payload type for each > video stream. This is OK for streams that use a dynamic payload type. > However, certain RTP streams have fixed payload types. For example, > MPEG-2 video over MPEG Transport Stream over RTP has fixed payload type > 33. With your proposal, it is not possible to do 3D simulcast of L- and R- > streams in MPEG-2. This is something I hadn't taken into account. However, I'm not sure if it could be a problem. As far as I can tell, all a static payload type implies is that an encoding (such as MPEG-2) is mapped by default to a given number (33, in this case). But I haven't been able to find a rule that prevents the same encoding from being mapped to a dynamic payload type number, after checking several RFCs about SDP and RTP. Is there any such rule that I may have missed? Would this remapping of encodings with static payload types break anything in existing implementations, otherwise? Assuming that I've missed something, and static payload types cannot be remapped, it's an issue that needs to be addressed in my proposal. On the bright side, it doesn't prevent signalling 3D formats while using codecs with static payload types - following your example, it WOULD be possible to do 3D simulcast of L and R streams in MPEG-2, such as in the following SDP: v=0 o=Alice 2890844526 2890842807 IN IP4 131.163.72.4 s=The technology of 3D-TV c=IN IP4 131.164.74.2 t=0 0 a=group:3DS 1 2 m=video 49170 RTP/AVP 33 a=rtpmap: 33 MP2T/90000 a=3dFormat:100 SC L a=mid:1 m=video 49172 RTP/AVP 33 a=rtpmap:33 MP2T/90000 a=3dFormat:33 SC R a=mid:2 a=depend 33 3dv 1:33 m=audio 52890 RTP/AVP 10 a=rtpmap:10 L16/16000/2 Where static payload types would have a negative impact would be in using multiple 3d formats in the offer. In the example above, the offerer could only add another 3d format (say, simulcast 2D+parallax) by adding a new payload type - but we wouldn't be able to use MP2T encoding for the alternative 3d format. > (B) It is true, that the number of "m=" lines in your proposal is less than in the > current draft. But this is only a virtual reduction, as now multiple video > streams are advertised in a single media line. In principle, the same number > of video streams is advertised. This is one case where I think your choice of terminology can be confusing, so I'll refer to what you call "video streams" as "media formats". It is true that the amount of media formats offered would remain the same across proposals, so the overall complexity of the sdp would not change. However, I believe reducing the number of media descriptors (media lines) makes the negotiation process more efficient, for the following reasons: - NAT traversal. The complexity of NAT traversal usually increases with the number of media descriptors in an SDP. As an example, ICE needs to gather candidates for each RTP media stream (i.e. each media descriptor) - it is unaffected by the number of media formats in any descriptor. - Firewalling. Likewise, each media descriptor in the SDP offer usually requires a unique listening port (plus another for RTCP), so adding more descriptors may complicate firewall configuration. - Subsequent offers. Not a huge issue, but under your proposal, if a user agent re-INVITES (e.g. to disable a stream), all discarded media lines from the original offer must still be included, cluttering the SDP (though their attributes may be omitted). > (C) With your proposal, in addition to the "3DS" grouping and the "3dFormat" > attribute, the "depend" attribute needs also be supported, with the > particular meaning as you have defined it. Yes > (D) Does having less "m=" lines justify the additional complexity of using the > "depend" attribute? I think so, but I wouldn't mind some feedback on the matter. Regarding the costs, I think the complexity introduced by "a=depend" is relatively low, though I admit I don't have direct experience using it in implementations. On the other hand, if an implementation was already using "a=depend" for other purposes, this cost would be negated. Current applications requiring the attribute include H.264/SVC coding, for example. Also, H.264/MVC, when it's finished, is highly likely to also use "a=depend" - and I'd expect that format to be widely adopted by 3D-capable UAs. As for the benefits, I've discussed the merits of reducing "m=" lines above. On top of that, a benefit of my overall approach which I had't mentioned yet is that it's better suited for scenarios with multiple 3D streams (e.g. multiple displays, or 3D telepresence).In the current draft, though it is possible for an answerer to accept more than one 3d format at once, there is no clear way for the offerer to indicate whether it actually intends to use more than one. An offer could have multiple 3d formats as alternatives to each other, or as actual 3d streams that could be reproduced simultaneously. By contrast, in my proposal, each "3DS" group would always correspond to a separate 3d stream. Of course, this can be addressed through other kind of update to the current draft, but that may have its own complexity cost. Either way, this may be worth discussing as a separate topic. > (E) What if different video streams in the same media group require > different SDP attributes? Of all media-level attributes, the most likely to change from one 3d media format to the other is "a=fmtp", which is defined for each payload type. That said, there are a few potentially problematic interactions. "a=recvonly", "a=sendonly", "a=sendrecv", "a=inactive": It would be rare, but not impossible, for an offerer to want to specify different stream directions depending on the 3D media format (maybe has display capabilities, but cannot capture, for a certain format). In this specific case, a simple re-invite once the offer/answer process has narrowed down the 3d formats to a sigle option should work. "b=" : clearly, different 3d formats may have different bandwidth requirements, so having many formats under a single media descriptor makes the "b=" attribute less accurate than under your proposal. That said, it is already possible to have a single media descriptor with multiple 2D formats with very different bandwidth requirements, so this is hardly a new problem. I haven't found other media level attributes that could cause trouble. Did you have any in mind? From fandreas@cisco.com Wed Nov 16 18:07:23 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38ECC1F0C55 for ; Wed, 16 Nov 2011 18:07:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wR8tg4mwInzt for ; Wed, 16 Nov 2011 18:07:22 -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 3D7A01F0C51 for ; Wed, 16 Nov 2011 18:07:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=2577; q=dns/txt; s=iport; t=1321495642; x=1322705242; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=7nf03EFFjmXfFPUoQpYzW7TrhyO0UsTWNcVVhDnzZnM=; b=TrgjyYvC4Yru9WL9Pl+Dx5DrO6WkCyybNT1mXpFUHSeU3cS+v6+r/6gD 2E5BgTYtglZGWWs3/ohc7NiCYVV4vhAuBws/s/2BRa0lp+vPRluyYX97d R/o9bOvgskzrYYC99AlAoKkgw1wOEzTXhxb1jTxSkEHNChMaba7dgzJ9H U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKprxE6rRDoH/2dsb2JhbAA4CqoGgQWCCwElQD0WGAMCAQIBSwEMCAEBFwecYgGeZ4ZjgzQEiBSMIJIa X-IronPort-AV: E=Sophos;i="4.69,524,1315180800"; d="scan'208";a="14755246" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 17 Nov 2011 02:07:22 +0000 Received: from dhcp-1345.meeting.ietf.org (sjc-vpn3-1309.cisco.com [10.21.69.29]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAH27Khd006632; Thu, 17 Nov 2011 02:07:21 GMT Message-ID: <4EC46C66.9010305@cisco.com> Date: Wed, 16 Nov 2011 21:07:34 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: mmusic , draft-holmberg-mmusic-sdp-bundle-negotiation@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Comments on draft-holmberg-mmusic-sdp-bundle-negotiation-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 02:07:23 -0000 I have two major comments on the draft: 1) The draft says that it is backwards compatible, however I don't believe it is. As the authors note, sharing tranxport addresses among multiple media descriptions is undefined in RFC 4566, and while the draft suggests some ways around that on the offering side, I don't believe they work. Problems include: - Potential SSRC overlap between the different media streams, which will lead to all kinds of problems - Does not work without symmetric media/RTP (as more or less noted in the draft) - Even when symmetric media/RTP is used, NAT implies that you cannot use the port information from the SDP answer to infer the missing parts of the 5-tuple. - Given that shared transport addresses between different media streams is undefined in RFC 4566, the answerer may not support this to begin with - Shared destination transport addresses without full 5-tuple information implies that you cannot identify each media stream as an independent flow in the network, and the ability to do so may be one reason the answerer did not want to do bundles to begin with. - Fallback is to do another O/A exchange, however at that point, the media streams have already been established, and hence this is not backwards compatible. Fundamentally, we always have this backwards compatibility issue when using grouping to try and negotiate something that has to be supported by the other side to avoid failures, and this is another example of that. I will note that SDP Capability Negotiation is an alternative solution to what you are trying to do and it would not suffer from these backwards compatibility issues (would still need to define a capability negotiation extension for this though). 2) The intent of the draft is to effectively turn multiple media descriptions into a single RTP (or other media) session. We do however have a number of SDP parameters (in RFC 4566 and extensions) that are specified on a per media stream basis and we need some general rules around how to deal with those. Section 7.2 begins to look at it, but we need a lot more here, especially if we need to support backwards compatibility at the same time in a single O/A exchange. Some media description parameters will have to be cumulative among the multiple "m=" lines (rtpmap for example), others will have to pick a single one (e.g. SRTP keying parameters), and yet others will need to be combined (bandwidth for example as noted in the draft). Thanks -- Flemming (as individual) From christer.holmberg@ericsson.com Wed Nov 16 18:35:23 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC60911E8073 for ; Wed, 16 Nov 2011 18:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.358 X-Spam-Level: X-Spam-Status: No, score=-6.358 tagged_above=-999 required=5 tests=[AWL=0.241, 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 Z+h1Wl60b3+2 for ; Wed, 16 Nov 2011 18:35:23 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id CA2831F0C3D for ; Wed, 16 Nov 2011 18:35:22 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-a3-4ec472e9f845 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 21.C7.09514.9E274CE4; Thu, 17 Nov 2011 03:35:21 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.2]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 17 Nov 2011 03:35:21 +0100 From: Christer Holmberg To: 'Flemming Andreasen' , mmusic , "draft-holmberg-mmusic-sdp-bundle-negotiation@tools.ietf.org" Date: Thu, 17 Nov 2011 03:35:21 +0100 Thread-Topic: [MMUSIC] Comments on draft-holmberg-mmusic-sdp-bundle-negotiation-00 Thread-Index: AcykzadeGeui6QkkRWudGZriej9EkwAAQMgg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C39375A05@ESESSCMS0356.eemea.ericsson.se> References: <4EC46C66.9010305@cisco.com> In-Reply-To: <4EC46C66.9010305@cisco.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== Subject: Re: [MMUSIC] Comments on draft-holmberg-mmusic-sdp-bundle-negotiation-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 02:35:23 -0000 Hi,=20 > I have two major comments on the draft: > > 1) The draft says that it is backwards compatible, however I don't believ= e it is. As the authors=20 > note, sharing tranxport addresses among multiple media descriptions is un= defined in RFC 4566, and=20 > while the draft suggests some ways around that on the offering side, I do= n't believe they work. Problems include: > - Potential SSRC overlap between the different media streams, which will = lead to all kinds of problems > - Does not work without symmetric media/RTP (as more or less noted in the= draft) > - Even when symmetric media/RTP is used, NAT implies that you cannot use = the port information from the SDP=20 > answer to infer the missing parts of the 5-tuple. > - Given that shared transport addresses between different media streams i= s undefined in RFC 4566, the answerer may not support this to begin with That may of course be true, and in that case the answerer might reject the = offer. However, I have been informed by a number of companies that their pr= oducts will NOT have a problem with the fact that the remote end uses the s= ame ports. > - Shared destination transport addresses without full 5-tuple information= implies that you cannot identify=20 > each media stream as an independent flow in the network, and the ability = to do so may be one reason the=20 > answerer did not want to do bundles to begin with. > - Fallback is to do another O/A exchange, however at that point, the medi= a streams have already been=20 > established, and hence this is not backwards compatible. > > Fundamentally, we always have this backwards compatibility issue when usi= ng grouping to try and negotiate=20 > something that has to be supported by the other side to avoid failures, a= nd this is another example of that.=20 > I will note that SDP Capability Negotiation is an alternative solution to= what you are trying to do and it=20 > would not suffer from these backwards compatibility issues (would still n= eed to define a capability negotiation=20 > extension for this though). > > 2) The intent of the draft is to effectively turn multiple media descript= ions into a single RTP (or other media) session. It can be a single RTP session, or multiple RTP sessions. The draft suggest= s a default, but it can be extended also for other cases. > We do however have a number of SDP parameters (in RFC 4566 and extensions= ) that are specified on a per media stream=20 > basis and we need some general rules around how to deal with those. Secti= on 7.2 begins to look at it, but we need a=20 > lot more here, especially if we need to support backwards compatibility a= t the same time in a single O/A exchange.=20 > Some media description parameters will have to be cumulative among the mu= ltiple "m=3D" lines (rtpmap for example), others=20 > will have to pick a single one (e.g. SRTP keying parameters), and yet oth= ers will need to be combined (bandwidth for=20 > example as noted in the draft). I agree, and that for sure is something we will have to work with before th= e spec is published as RFC. Section 6.4 (and 7.2) is intended to cover such= text (there is already some text about the b=3D parameter, but more will b= e needed).=20 However, I hope that not having all those details ready available at this p= oint is a show stopper for starting the work. Regards, Christer From fandreas@cisco.com Wed Nov 16 19:32:09 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A798A11E80FE for ; Wed, 16 Nov 2011 19:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txlemsU+xUmG for ; Wed, 16 Nov 2011 19:32:03 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id B54F711E80FC for ; Wed, 16 Nov 2011 19:32:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=4121; q=dns/txt; s=iport; t=1321500723; x=1322710323; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=KsvnItvZoMldJhlmFf5g27uUxoi8e/ETAXwzKAg7u9w=; b=PTNxaPQVqR2+ZqTwBhYDi/D6K8aiXEj6SA67LnJVgaH3lZuLaCGnRHiv jTfewjegungAlbs/ZSIhMzQcXoXyr59T4HZIwmTCrmEJvSl/afIfS0pVj H3eL7sU72VZ79409/tW/vlvtVq4CqocOUwpE16J5j/ySykEOhTaocQfsP w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALZ/xE6rRDoG/2dsb2JhbAA4CqoGgQWBcgEBAQMBEgElQAEQCxgJFg8JAwIBAgFFBg0BBwEBFweHYJUWAZ5phmODNASIFIwgkho X-IronPort-AV: E=Sophos;i="4.69,524,1315180800"; d="scan'208";a="14699510" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 17 Nov 2011 03:32:03 +0000 Received: from dhcp-1345.meeting.ietf.org (sjc-vpn3-1309.cisco.com [10.21.69.29]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAH3W211021682; Thu, 17 Nov 2011 03:32:02 GMT Message-ID: <4EC4803F.6040207@cisco.com> Date: Wed, 16 Nov 2011 22:32:15 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Christer Holmberg References: <4EC46C66.9010305@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C39375A05@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C39375A05@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-holmberg-mmusic-sdp-bundle-negotiation@tools.ietf.org" , mmusic Subject: Re: [MMUSIC] Comments on draft-holmberg-mmusic-sdp-bundle-negotiation-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 03:32:09 -0000 On 11/16/11 9:35 PM, Christer Holmberg wrote: > Hi, > > >> I have two major comments on the draft: >> >> 1) The draft says that it is backwards compatible, however I don't believe it is. As the authors >> note, sharing tranxport addresses among multiple media descriptions is undefined in RFC 4566, and >> while the draft suggests some ways around that on the offering side, I don't believe they work. Problems include: >> - Potential SSRC overlap between the different media streams, which will lead to all kinds of problems >> - Does not work without symmetric media/RTP (as more or less noted in the draft) >> - Even when symmetric media/RTP is used, NAT implies that you cannot use the port information from the SDP >> answer to infer the missing parts of the 5-tuple. >> - Given that shared transport addresses between different media streams is undefined in RFC 4566, the answerer may not support this to begin with >> > That may of course be true, and in that case the answerer might reject the offer. However, I have been informed by a number of companies that their products will NOT have a problem with the fact that the remote end uses the same ports. > > >> - Shared destination transport addresses without full 5-tuple information implies that you cannot identify >> each media stream as an independent flow in the network, and the ability to do so may be one reason the >> answerer did not want to do bundles to begin with. >> - Fallback is to do another O/A exchange, however at that point, the media streams have already been >> established, and hence this is not backwards compatible. >> >> Fundamentally, we always have this backwards compatibility issue when using grouping to try and negotiate >> something that has to be supported by the other side to avoid failures, and this is another example of that. >> I will note that SDP Capability Negotiation is an alternative solution to what you are trying to do and it >> would not suffer from these backwards compatibility issues (would still need to define a capability negotiation >> extension for this though). >> >> 2) The intent of the draft is to effectively turn multiple media descriptions into a single RTP (or other media) session. >> > It can be a single RTP session, or multiple RTP sessions. The draft suggests a default, but it can be extended also for other cases. > > > >> We do however have a number of SDP parameters (in RFC 4566 and extensions) that are specified on a per media stream >> basis and we need some general rules around how to deal with those. Section 7.2 begins to look at it, but we need a >> lot more here, especially if we need to support backwards compatibility at the same time in a single O/A exchange. >> Some media description parameters will have to be cumulative among the multiple "m=" lines (rtpmap for example), others >> will have to pick a single one (e.g. SRTP keying parameters), and yet others will need to be combined (bandwidth for >> example as noted in the draft). >> > I agree, and that for sure is something we will have to work with before the spec is published as RFC. Section 6.4 (and 7.2) is intended to cover such text (there is already some text about the b= parameter, but more will be needed). > > However, I hope that not having all those details ready available at this point is a show stopper for starting the work. > Agreed, however it may affect the nature of the solution and hence it would be good to understand more details around this before deciding which way to go. Taking capability negotiation as an alternative for example, you there have an explicit negotiation framework that could make it very explicit as to what you actually want to do depending on whether you end up doing the bundle or not in a given negotiation. The approach outlined here seems less clear (for the moment at least) and will require a bunch of new rules that may or may not generalize well among existing and future SDP extensions. -- Flemming > > Regards, > > Christer > > > > From christer.holmberg@ericsson.com Thu Nov 17 00:34:32 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380B921F9A03 for ; Thu, 17 Nov 2011 00:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.361 X-Spam-Level: X-Spam-Status: No, score=-6.361 tagged_above=-999 required=5 tests=[AWL=0.238, 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 kXag+b-P8Yoi for ; Thu, 17 Nov 2011 00:34:31 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 568C121F9A01 for ; Thu, 17 Nov 2011 00:34:31 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-b9-4ec4c7157e0b Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C3.0D.09514.517C4CE4; Thu, 17 Nov 2011 09:34:30 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.2]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 17 Nov 2011 09:34:29 +0100 From: Christer Holmberg To: Flemming Andreasen Date: Thu, 17 Nov 2011 09:34:28 +0100 Thread-Topic: [MMUSIC] Comments on draft-holmberg-mmusic-sdp-bundle-negotiation-00 Thread-Index: Acyk2XteQcrVi6lGQpiTI6zWoemcEAAKQeCb Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3925E7C9@ESESSCMS0356.eemea.ericsson.se> References: <4EC46C66.9010305@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C39375A05@ESESSCMS0356.eemea.ericsson.se>, <4EC4803F.6040207@cisco.com> In-Reply-To: <4EC4803F.6040207@cisco.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: "draft-holmberg-mmusic-sdp-bundle-negotiation@tools.ietf.org" , mmusic Subject: Re: [MMUSIC] Comments on draft-holmberg-mmusic-sdp-bundle-negotiation-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 08:34:32 -0000 Hi, >>>> We do however have a number of SDP parameters (in RFC 4566 and extensi= ons) that are specified on a per media stream >>>> basis and we need some general rules around how to deal with those. Se= ction 7.2 begins to look at it, but we need a >>>> lot more here, especially if we need to support backwards compatibilit= y at the same time in a single O/A exchange. >>>> Some media description parameters will have to be cumulative among the= multiple "m=3D" lines (rtpmap for example), others >>>> will have to pick a single one (e.g. SRTP keying parameters), and yet = others will need to be combined (bandwidth for >>>> example as noted in the draft). >>>> >>> I agree, and that for sure is something we will have to work with befor= e the spec is published as RFC. Section 6.4 (and 7.2) is intended to=20 >>> cover such text (there is already some text about the b=3D parameter, b= ut more will be needed). >> >> However, I hope that not having all those details ready available at thi= s point is a show stopper for starting the work. > > Agreed, however it may affect the nature of the solution and hence it > would be good to understand more details around this before deciding > which way to go. Taking capability negotiation as an alternative for > example, you there have an explicit negotiation framework that could > make it very explicit as to what you actually want to do depending on > whether you end up doing the bundle or not in a given negotiation.=20 > The approach outlined here seems less clear (for the moment at least) and= will=20 > require a bunch of new rules that may or may not generalize well > among existing and future SDP extensions. In my personal opinion (but, the WG of course decides :) I think it is quit= e clear and straight forward, and I don't see any major issues - eventhough= I do agree that there are a number of things we need to specify.=20 I do realize that there might be cases where an answerer, that does not sup= port BUNDLE, will not accept an offer with identical port numbers. But, I h= ave never seen such entity, and nobody has informed about such entities. Th= at of course doesn't mean they don't exist, but my view is that it's not a = big real-life problem. Also, could you explain to me how all this would look using CapNeg, and how= you would avoid the issues you've raised with BUNDLE? Regards, Christer= From harald@alvestrand.no Thu Nov 17 00:44:01 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B63B21F9A36 for ; Thu, 17 Nov 2011 00:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.969 X-Spam-Level: X-Spam-Status: No, score=-109.969 tagged_above=-999 required=5 tests=[AWL=-0.570, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=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 4V49Vg3EN5Vv for ; Thu, 17 Nov 2011 00:44:00 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 559C721F9A35 for ; Thu, 17 Nov 2011 00:44:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5200239E04C; Thu, 17 Nov 2011 09:43: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 SsDHWPNdOxCw; Thu, 17 Nov 2011 09:43:58 +0100 (CET) Received: from [130.129.67.10] (dhcp-430a.meeting.ietf.org [130.129.67.10]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 9550739E176; Thu, 17 Nov 2011 09:43:56 +0100 (CET) Message-ID: <4EC4C947.8060807@alvestrand.no> Date: Thu, 17 Nov 2011 16:43:51 +0800 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Flemming Andreasen References: <4EC46C66.9010305@cisco.com> In-Reply-To: <4EC46C66.9010305@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-holmberg-mmusic-sdp-bundle-negotiation@tools.ietf.org, mmusic Subject: Re: [MMUSIC] Comments on draft-holmberg-mmusic-sdp-bundle-negotiation-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 08:44:01 -0000 Thanks for the review! I may want to be a little more undiplomatic than Holmberg, however... On 11/17/2011 10:07 AM, Flemming Andreasen wrote: > I have two major comments on the draft: > > 1) The draft says that it is backwards compatible, however I don't > believe it is. As the authors note, sharing tranxport addresses among > multiple media descriptions is undefined in RFC 4566, and while the > draft suggests some ways around that on the offering side, I don't > believe they work. Problems include: > - Potential SSRC overlap between the different media streams, which > will lead to all kinds of problems The result of successfully negotiating the extension will be one RTP session (or one RTP session per bundle). If the RTP implementation is incompetent enough to put more than one media flow onto one SSRC inside one RTP session, then it has much bigger problems than supporting the bundle. > - Does not work without symmetric media/RTP (as more or less noted in > the draft) I believe this is true. It should be made even more explicit than it already is. Being a precondition for using it means that we don't have to deal with the non-symmetric-media situation; we simply can't use the extension under those conditions. (This also means that the extension is useless for multicast. Not a problem.) > - Even when symmetric media/RTP is used, NAT implies that you cannot > use the port information from the SDP answer to infer the missing > parts of the 5-tuple. When NAT is used, ICE is required to get media flowing. This is something that is true for all SDP session negotiations; I do not believe it is in any way unique to this draft. > > - Given that shared transport addresses between different media > streams is undefined in RFC 4566, the answerer may not support this to > begin with You mean transport addresses on flows from the answerer to the offerer? This is the piece that bothers me, and which was the main difference between draft-holmberg and draft-alvestrand-one-rtp-stream. However, most commenters when they were both presented seemed to indicate that draft-holmberg's solution did not present a problem. > - Shared destination transport addresses without full 5-tuple > information implies that you cannot identify each media stream as an > independent flow in the network, and the ability to do so may be one > reason the answerer did not want to do bundles to begin with. I do not parse this sentence. Given that symmetric SDP is a requirement, the full 5-tuple is known by both sender and receiver. Most equipment that cares about flows works on 5-tuples rather than 3-tuples; are you suggesting that there exists flow-identifying equpment we care about where unique 3-tuples is a requirement for correct operation? > - Fallback is to do another O/A exchange, however at that point, the > media streams have already been established, and hence this is not > backwards compatible. Do you mean that doing two O/A exchanges is not backwards compatible, or that having some short period of media flow before the new O/A exchange can be performed is an issue? > > Fundamentally, we always have this backwards compatibility issue when > using grouping to try and negotiate something that has to be supported > by the other side to avoid failures, and this is another example of > that. I will note that SDP Capability Negotiation is an alternative > solution to what you are trying to do and it would not suffer from > these backwards compatibility issues (would still need to define a > capability negotiation extension for this though). I did not see anything in RFC 5939 that would be helpful; I might not have read it closely enough. > > > 2) The intent of the draft is to effectively turn multiple media > descriptions into a single RTP (or other media) session. We do however > have a number of SDP parameters (in RFC 4566 and extensions) that are > specified on a per media stream basis and we need some general rules > around how to deal with those. Section 7.2 begins to look at it, but > we need a lot more here, especially if we need to support backwards > compatibility at the same time in a single O/A exchange. Some media > description parameters will have to be cumulative among the multiple > "m=" lines (rtpmap for example), others will have to pick a single one > (e.g. SRTP keying parameters), and yet others will need to be combined > (bandwidth for example as noted in the draft). This was also addressed a bit more explicitly in draft-alvestrand-one-rtp, but I have not yet seen a description of a parameter where the required rule is not obvious; payload types (a=rtpmap) values have to be unique across all the description pieces of the RTP session, which naturally solves the problem for a=fmtp parameters; bandwidth has already been discussed; a=label and SDES keying parameters only makes sense once for the session. Which other parameters are there where the answer is not obvious? From fandreas@cisco.com Thu Nov 17 01:56:07 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DBB21F9B49 for ; Thu, 17 Nov 2011 01:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jkgiz6yYcrXb for ; Thu, 17 Nov 2011 01:56:06 -0800 (PST) Received: from hkhkgsmtp.docomointertouch.com (unknown [116.214.122.25]) by ietfa.amsl.com (Postfix) with ESMTP id 477D421F9A4D for ; Thu, 17 Nov 2011 01:56:06 -0800 (PST) Received: from fandreas-mac.local (203-69-99-17.HINET-IP.hinet.net [203.69.99.17] (may be forged)) by hkhkgsmtp.docomointertouch.com with ESMTP id pAH9trli005031-pAH9trlj005031; Thu, 17 Nov 2011 17:55:53 +0800 Message-ID: <4EC4DA36.3020608@cisco.com> Date: Thu, 17 Nov 2011 04:56:06 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Christer Holmberg References: <4EC46C66.9010305@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C39375A05@ESESSCMS0356.eemea.ericsson.se>, <4EC4803F.6040207@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3925E7C9@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3925E7C9@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-holmberg-mmusic-sdp-bundle-negotiation@tools.ietf.org" , mmusic Subject: Re: [MMUSIC] Comments on draft-holmberg-mmusic-sdp-bundle-negotiation-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 09:56:07 -0000 On 11/17/11 3:34 AM, Christer Holmberg wrote: > Hi, > > >>>>> We do however have a number of SDP parameters (in RFC 4566 and extensions) that are specified on a per media stream >>>>> basis and we need some general rules around how to deal with those. Section 7.2 begins to look at it, but we need a >>>>> lot more here, especially if we need to support backwards compatibility at the same time in a single O/A exchange. >>>>> Some media description parameters will have to be cumulative among the multiple "m=" lines (rtpmap for example), others >>>>> will have to pick a single one (e.g. SRTP keying parameters), and yet others will need to be combined (bandwidth for >>>>> example as noted in the draft). >>>>> >>>>> >>>> I agree, and that for sure is something we will have to work with before the spec is published as RFC. Section 6.4 (and 7.2) is intended to >>>> cover such text (there is already some text about the b= parameter, but more will be needed). >>>> >>> However, I hope that not having all those details ready available at this point is a show stopper for starting the work. >>> >> Agreed, however it may affect the nature of the solution and hence it >> would be good to understand more details around this before deciding >> which way to go. Taking capability negotiation as an alternative for >> example, you there have an explicit negotiation framework that could >> make it very explicit as to what you actually want to do depending on >> whether you end up doing the bundle or not in a given negotiation. >> The approach outlined here seems less clear (for the moment at least) and will >> require a bunch of new rules that may or may not generalize well >> among existing and future SDP extensions. >> > In my personal opinion (but, the WG of course decides :) I think it is quite clear and straight forward, and I don't see any major issues - eventhough I do agree that there are a number of things we need to specify. > Ok - if it's clear and straight forward then it should be easy to write them up in the next version of the draft so we can see that. > I do realize that there might be cases where an answerer, that does not support BUNDLE, will not accept an offer with identical port numbers. But, I have never seen such entity, and nobody has informed about such entities. That of course doesn't mean they don't exist, but my view is that it's not a big real-life problem. > > Also, could you explain to me how all this would look using CapNeg, and how you would avoid the issues you've raised with BUNDLE? > The backwards compatibility issue would be addressed by having the standard (non-bundle) configuration provided as the actual configuration (i.e. standard SDP) whereas the bundle configuration would be provided as a set of capabilities with a potential configuration for them. You may need to supplement that with one or more new attributes to specify bundle semantics, but those attributes could simply be provided as attribute capabilities that would be part of the potential (bundle) configuration. As for rules around how to deal with various media-level parameters that you may or may not want depending on whether you end up doing the bundle or not, the potential configuration allows you to specify the exact set you want used for each configuration. It gets verbose quickly, but it's unambigious and well-defined at least. Thanks -- Flemming > Regards, > > Christer > From fandreas@cisco.com Thu Nov 17 02:19:54 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D718721F9BAF for ; Thu, 17 Nov 2011 02:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.105 X-Spam-Level: X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7c4Ps2W3M3X for ; Thu, 17 Nov 2011 02:19:49 -0800 (PST) Received: from hkhkgsmtp.docomointertouch.com (unknown [116.214.122.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0847921F9A07 for ; Thu, 17 Nov 2011 02:19:47 -0800 (PST) Received: from fandreas-mac.local (203-69-99-17.HINET-IP.hinet.net [203.69.99.17] (may be forged)) by hkhkgsmtp.docomointertouch.com with ESMTP id pAHAJah5005738-pAHAJah6005738; Thu, 17 Nov 2011 18:19:36 +0800 Message-ID: <4EC4DFC4.5040108@cisco.com> Date: Thu, 17 Nov 2011 05:19:48 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Harald Alvestrand References: <4EC46C66.9010305@cisco.com> <4EC4C947.8060807@alvestrand.no> In-Reply-To: <4EC4C947.8060807@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-holmberg-mmusic-sdp-bundle-negotiation@tools.ietf.org, mmusic Subject: Re: [MMUSIC] Comments on draft-holmberg-mmusic-sdp-bundle-negotiation-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 10:19:54 -0000 On 11/17/11 3:43 AM, Harald Alvestrand wrote: > Thanks for the review! > > I may want to be a little more undiplomatic than Holmberg, however... > > On 11/17/2011 10:07 AM, Flemming Andreasen wrote: >> I have two major comments on the draft: >> >> 1) The draft says that it is backwards compatible, however I don't >> believe it is. As the authors note, sharing tranxport addresses among >> multiple media descriptions is undefined in RFC 4566, and while the >> draft suggests some ways around that on the offering side, I don't >> believe they work. Problems include: >> - Potential SSRC overlap between the different media streams, which >> will lead to all kinds of problems > The result of successfully negotiating the extension will be one RTP > session (or one RTP session per bundle). If the RTP implementation is > incompetent enough to put more than one media flow onto one SSRC > inside one RTP session, then it has much bigger problems than > supporting the bundle. The issue here is when the answerer does not support the extension. The answerer now believes there are multiple different RTP sessions and hence may end up using the same SSRC, however this will not work on the offering side. >> - Does not work without symmetric media/RTP (as more or less noted in >> the draft) > I believe this is true. It should be made even more explicit than it > already is. > Being a precondition for using it means that we don't have to deal > with the non-symmetric-media situation; we simply can't use the > extension under those conditions. Indeed, and hence it is not backwards compatible for those implementations. > (This also means that the extension is useless for multicast. Not a > problem.) > >> - Even when symmetric media/RTP is used, NAT implies that you cannot >> use the port information from the SDP answer to infer the missing >> parts of the 5-tuple. > > When NAT is used, ICE is required to get media flowing. This is > something that is true for all SDP session negotiations; I do not > believe it is in any way unique to this draft. > The draft says that "the SDP offerer can use the port information from the SDP answer in order to create the 5-tuple mapping for each media". I'm simply saying this doesn't work in the presence of NATs (whether ICE is used or not). >> >> - Given that shared transport addresses between different media >> streams is undefined in RFC 4566, the answerer may not support this >> to begin with > > You mean transport addresses on flows from the answerer to the offerer? Effectively yes (theoretically, there could be an issue on the answerer processing such an offer in the first place). > > This is the piece that bothers me, and which was the main difference > between draft-holmberg and draft-alvestrand-one-rtp-stream. However, > most commenters when they were both presented seemed to indicate that > draft-holmberg's solution did not present a problem. > >> - Shared destination transport addresses without full 5-tuple >> information implies that you cannot identify each media stream as an >> independent flow in the network, and the ability to do so may be one >> reason the answerer did not want to do bundles to begin with. > I do not parse this sentence. Given that symmetric SDP is a > requirement, the full 5-tuple is known by both sender and receiver. > Most equipment that cares about flows works on 5-tuples rather than > 3-tuples; are you suggesting that there exists flow-identifying > equpment we care about where unique 3-tuples is a requirement for > correct operation? > The full 5-tuple that the sender and receiver knows may not be the same as the network sees due to NATs. There exists equipment and standards that classify flows based on destination transport address alone (e.g. for QoS operation). >> - Fallback is to do another O/A exchange, however at that point, the >> media streams have already been established, and hence this is not >> backwards compatible. > Do you mean that doing two O/A exchanges is not backwards compatible, > or that having some short period of media flow before the new O/A > exchange can be performed is an issue? Both, however the issue is that the first O/A exchange may establish media streams that do not function correctly. Furthermore, you cannot always immediately start a second O/A exchange to rectify this (think early media). >> >> Fundamentally, we always have this backwards compatibility issue when >> using grouping to try and negotiate something that has to be >> supported by the other side to avoid failures, and this is another >> example of that. I will note that SDP Capability Negotiation is an >> alternative solution to what you are trying to do and it would not >> suffer from these backwards compatibility issues (would still need to >> define a capability negotiation extension for this though). > > I did not see anything in RFC 5939 that would be helpful; I might not > have read it closely enough. > The issue is that RFC 4566 (SDP) has a rule that says to simply ignore unknown attributes. If correct processing of those unknown attributes is a prerequisite for correct operation you have a problem. The way grouping is used here you run into that per the above. >> >> >> 2) The intent of the draft is to effectively turn multiple media >> descriptions into a single RTP (or other media) session. We do >> however have a number of SDP parameters (in RFC 4566 and extensions) >> that are specified on a per media stream basis and we need some >> general rules around how to deal with those. Section 7.2 begins to >> look at it, but we need a lot more here, especially if we need to >> support backwards compatibility at the same time in a single O/A >> exchange. Some media description parameters will have to be >> cumulative among the multiple "m=" lines (rtpmap for example), others >> will have to pick a single one (e.g. SRTP keying parameters), and yet >> others will need to be combined (bandwidth for example as noted in >> the draft). > > This was also addressed a bit more explicitly in > draft-alvestrand-one-rtp, but I have not yet seen a description of a > parameter where the required rule is not obvious; payload types > (a=rtpmap) values have to be unique across all the description pieces > of the RTP session, which naturally solves the problem for a=fmtp > parameters; bandwidth has already been discussed; a=label and SDES > keying parameters only makes sense once for the session. > > Which other parameters are there where the answer is not obvious? Even reasonable people tend to differ on what is obvious, especially once they start implementing things. While we could go through the entire list of SDP parameters defined to date and specify for each how to handle it, how do you handle future SDP parameters ? It would be a shame if this mechanism didn't work for any SDP extensions defined after it and hence we need a general and interoperable solution to this issue. Thanks -- Flemming > > From harald@alvestrand.no Thu Nov 17 02:46:15 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A8721F9BAC for ; Thu, 17 Nov 2011 02:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.93 X-Spam-Level: X-Spam-Status: No, score=-109.93 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=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 kT9ICO09kPML for ; Thu, 17 Nov 2011 02:46:14 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8647421F95AA for ; Thu, 17 Nov 2011 02:46:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BCFB739E0D4; Thu, 17 Nov 2011 11:46:13 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvh4sLc7IdCp; Thu, 17 Nov 2011 11:46:11 +0100 (CET) Received: from [130.129.22.244] (dhcp-16f4.meeting.ietf.org [130.129.22.244]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 8B88939E04C; Thu, 17 Nov 2011 11:46:09 +0100 (CET) Message-ID: <4EC4E5ED.6000908@alvestrand.no> Date: Thu, 17 Nov 2011 18:46:05 +0800 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Flemming Andreasen References: <4EC46C66.9010305@cisco.com> <4EC4C947.8060807@alvestrand.no> <4EC4DFC4.5040108@cisco.com> In-Reply-To: <4EC4DFC4.5040108@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-holmberg-mmusic-sdp-bundle-negotiation@tools.ietf.org, mmusic Subject: Re: [MMUSIC] Comments on draft-holmberg-mmusic-sdp-bundle-negotiation-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 10:46:15 -0000 On 11/17/2011 06:19 PM, Flemming Andreasen wrote: > > > On 11/17/11 3:43 AM, Harald Alvestrand wrote: >> Thanks for the review! >> >> I may want to be a little more undiplomatic than Holmberg, however... >> >> On 11/17/2011 10:07 AM, Flemming Andreasen wrote: >>> I have two major comments on the draft: >>> >>> 1) The draft says that it is backwards compatible, however I don't >>> believe it is. As the authors note, sharing tranxport addresses >>> among multiple media descriptions is undefined in RFC 4566, and >>> while the draft suggests some ways around that on the offering side, >>> I don't believe they work. Problems include: >>> - Potential SSRC overlap between the different media streams, which >>> will lead to all kinds of problems >> The result of successfully negotiating the extension will be one RTP >> session (or one RTP session per bundle). If the RTP implementation is >> incompetent enough to put more than one media flow onto one SSRC >> inside one RTP session, then it has much bigger problems than >> supporting the bundle. > The issue here is when the answerer does not support the extension. > The answerer now believes there are multiple different RTP sessions > and hence may end up using the same SSRC, however this will not work > on the offering side. It will work if the offerer is able to distinguish the two 5-tuples; since the answer came back without the BUNDLE extension, the offerer knows that there are multiple different RTP sessions. > >>> - Does not work without symmetric media/RTP (as more or less noted >>> in the draft) >> I believe this is true. It should be made even more explicit than it >> already is. >> Being a precondition for using it means that we don't have to deal >> with the non-symmetric-media situation; we simply can't use the >> extension under those conditions. > Indeed, and hence it is not backwards compatible for those > implementations. > >> (This also means that the extension is useless for multicast. Not a >> problem.) >> >>> - Even when symmetric media/RTP is used, NAT implies that you cannot >>> use the port information from the SDP answer to infer the missing >>> parts of the 5-tuple. >> >> When NAT is used, ICE is required to get media flowing. This is >> something that is true for all SDP session negotiations; I do not >> believe it is in any way unique to this draft. >> > The draft says that "the SDP offerer can use the port information from > the SDP answer in order to create the 5-tuple mapping for each media". > I'm simply saying this doesn't work in the presence of NATs (whether > ICE is used or not). Yes, this language needs to be changed to clarify that "port information from the SDP answer" may refer to port information gathered via the ICE exchange rather than the (useless) information from the SDP m= line. The language in question is in section 6.2: NOTE: Assuming symmetric media is used, the SDP Offerer can use the port information from the SDP Answer in order to create the 5-tuple mapping for each media. > > >>> >>> - Given that shared transport addresses between different media >>> streams is undefined in RFC 4566, the answerer may not support this >>> to begin with >> >> You mean transport addresses on flows from the answerer to the offerer? > > Effectively yes (theoretically, there could be an issue on the > answerer processing such an offer in the first place). > >> >> This is the piece that bothers me, and which was the main difference >> between draft-holmberg and draft-alvestrand-one-rtp-stream. However, >> most commenters when they were both presented seemed to indicate that >> draft-holmberg's solution did not present a problem. >> >>> - Shared destination transport addresses without full 5-tuple >>> information implies that you cannot identify each media stream as an >>> independent flow in the network, and the ability to do so may be one >>> reason the answerer did not want to do bundles to begin with. >> I do not parse this sentence. Given that symmetric SDP is a >> requirement, the full 5-tuple is known by both sender and receiver. >> Most equipment that cares about flows works on 5-tuples rather than >> 3-tuples; are you suggesting that there exists flow-identifying >> equpment we care about where unique 3-tuples is a requirement for >> correct operation? >> > The full 5-tuple that the sender and receiver knows may not be the > same as the network sees due to NATs. There exists equipment and > standards that classify flows based on destination transport address > alone (e.g. for QoS operation). References? I'm quite aware of equipment that does classification on destination port numbers, but that's obviously not what you're thinking about. > >>> - Fallback is to do another O/A exchange, however at that point, the >>> media streams have already been established, and hence this is not >>> backwards compatible. >> Do you mean that doing two O/A exchanges is not backwards compatible, >> or that having some short period of media flow before the new O/A >> exchange can be performed is an issue? > Both, however the issue is that the first O/A exchange may establish > media streams that do not function correctly. Furthermore, you cannot > always immediately start a second O/A exchange to rectify this (think > early media). > > >>> >>> Fundamentally, we always have this backwards compatibility issue >>> when using grouping to try and negotiate something that has to be >>> supported by the other side to avoid failures, and this is another >>> example of that. I will note that SDP Capability Negotiation is an >>> alternative solution to what you are trying to do and it would not >>> suffer from these backwards compatibility issues (would still need >>> to define a capability negotiation extension for this though). >> >> I did not see anything in RFC 5939 that would be helpful; I might not >> have read it closely enough. >> > The issue is that RFC 4566 (SDP) has a rule that says to simply ignore > unknown attributes. If correct processing of those unknown attributes > is a prerequisite for correct operation you have a problem. The way > grouping is used here you run into that per the above. In this case, we're dependent on a particular behaviour (5-tuple stream ID and symmetric RTP) that I believe is widely used outside of this standard, but that behaviour is not specified by any attribute I know of (RFC 4961 did not specify an SDP attribute). The alternate from draft-alvestrand, different source ports, would present other problems (must spin up ports that are thrown away if not used). Would you see that as less problematic? > > > >>> >>> >>> 2) The intent of the draft is to effectively turn multiple media >>> descriptions into a single RTP (or other media) session. We do >>> however have a number of SDP parameters (in RFC 4566 and extensions) >>> that are specified on a per media stream basis and we need some >>> general rules around how to deal with those. Section 7.2 begins to >>> look at it, but we need a lot more here, especially if we need to >>> support backwards compatibility at the same time in a single O/A >>> exchange. Some media description parameters will have to be >>> cumulative among the multiple "m=" lines (rtpmap for example), >>> others will have to pick a single one (e.g. SRTP keying parameters), >>> and yet others will need to be combined (bandwidth for example as >>> noted in the draft). >> >> This was also addressed a bit more explicitly in >> draft-alvestrand-one-rtp, but I have not yet seen a description of a >> parameter where the required rule is not obvious; payload types >> (a=rtpmap) values have to be unique across all the description pieces >> of the RTP session, which naturally solves the problem for a=fmtp >> parameters; bandwidth has already been discussed; a=label and SDES >> keying parameters only makes sense once for the session. >> >> Which other parameters are there where the answer is not obvious? > Even reasonable people tend to differ on what is obvious, especially > once they start implementing things. While we could go through the > entire list of SDP parameters defined to date and specify for each how > to handle it, how do you handle future SDP parameters ? It would be a > shame if this mechanism didn't work for any SDP extensions defined > after it and hence we need a general and interoperable solution to > this issue. Going through the list (or parts of it) might result in us concluding that there are only a few categories of handling possible, and that it's reasonable to require future extensions to fit within the categories. Or it might not. Suggestions? From christer.holmberg@ericsson.com Thu Nov 17 03:29:01 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBA621F9BEA for ; Thu, 17 Nov 2011 03:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.363 X-Spam-Level: X-Spam-Status: No, score=-6.363 tagged_above=-999 required=5 tests=[AWL=0.236, 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 jIUk7f-QMJLk for ; Thu, 17 Nov 2011 03:29:01 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id B0DE921F9A4C for ; Thu, 17 Nov 2011 03:29:00 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-9b-4ec4effb9e2a Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id BB.60.09514.BFFE4CE4; Thu, 17 Nov 2011 12:28:59 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.2]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 17 Nov 2011 12:28:59 +0100 From: Christer Holmberg To: Flemming Andreasen Date: Thu, 17 Nov 2011 12:28:58 +0100 Thread-Topic: [MMUSIC] Comments on draft-holmberg-mmusic-sdp-bundle-negotiation-00 Thread-Index: AcylDx0QNokxGBVYRVik7p8T+aKQqwACn7TO Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3925E7CB@ESESSCMS0356.eemea.ericsson.se> References: <4EC46C66.9010305@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C39375A05@ESESSCMS0356.eemea.ericsson.se>, <4EC4803F.6040207@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3925E7C9@ESESSCMS0356.eemea.ericsson.se>, <4EC4DA36.3020608@cisco.com> In-Reply-To: <4EC4DA36.3020608@cisco.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: "draft-holmberg-mmusic-sdp-bundle-negotiation@tools.ietf.org" , mmusic Subject: Re: [MMUSIC] Comments on draft-holmberg-mmusic-sdp-bundle-negotiation-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 11:29:01 -0000 Hi, >>> Agreed, however it may affect the nature of the solution and hence it >>> would be good to understand more details around this before deciding >>> which way to go. Taking capability negotiation as an alternative for >>> example, you there have an explicit negotiation framework that could >>> make it very explicit as to what you actually want to do depending on >>> whether you end up doing the bundle or not in a given negotiation. >>> The approach outlined here seems less clear (for the moment at least) a= nd will >>> require a bunch of new rules that may or may not generalize well >>> among existing and future SDP extensions. >>> >> In my personal opinion (but, the WG of course decides :) I think it is q= uite clear and straight forward, and I=20 >> don't see any major issues - eventhough I do agree that there are a numb= er of things we need to specify. > > Ok - if it's clear and straight forward then it should be easy to write t= hem up in the next version of the draft so we can see that. I didn't mean that I have all the details in my head :) What I meant was that it is clear WHAT we need to do, and we should do that= as a community. >> Also, could you explain to me how all this would look using CapNeg, and = how you would avoid the issues you've raised with BUNDLE? > > The backwards compatibility issue would be addressed by having the > standard (non-bundle) configuration provided as the actual configuration > (i.e. standard SDP) whereas the bundle configuration would be provided > as a set of capabilities with a potential configuration for them. You > may need to supplement that with one or more new attributes to specify > bundle semantics, but those attributes could simply be provided as > attribute capabilities that would be part of the potential (bundle) > configuration. > > As for rules around how to deal with various media-level parameters that > you may or may not want depending on whether you end up doing the bundle > or not, the potential configuration allows you to specify the exact set > you want used for each configuration. It gets verbose quickly, but it's > unambigious and well-defined at least. You still need to specify how the media level parameters will "interact" in= a bundle - no matter whether you use CapNeg or not to negotiate the bundle= . In my opinion, the usage of CapNeg is "overkill" for this, as we're only ta= lking about the port. And, as you said, we would still need to define new p= arameters for the bundle semantics.=20 And, does the base CapNeg spec support providing alternative port numbers? And, even if the answerer doesn't support bundle, maybe the offerer still w= ants to use the same local port. Regards, Christer= From fandreas@cisco.com Thu Nov 17 03:37:30 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BAC11E80D9 for ; Thu, 17 Nov 2011 03:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=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 p2dZgGkAv+UL for ; Thu, 17 Nov 2011 03:37:24 -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 82AB811E80D7 for ; Thu, 17 Nov 2011 03:37:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=9750; q=dns/txt; s=iport; t=1321529844; x=1322739444; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=sbdUEtOC3vAip0cCBOcWbzL5aK5Zy0/QWvYzZf7VDi0=; b=m6NzgQQG6FobGPYUaSwpoiRdRLFn1WFmaB6pyss/BGUvjn06mVTWt36e OqPOLgOM4VgcK++CjKYtq4VFZS8K/T6zTOOLWl9/1LAo1HdgB7nZ3xVbd eIAaG82TXAcQdpXZaEQ5OaDLjPHYM89ds9feEXIIcvbmXY3F0R+dzjZOM c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtEFAJ7xxE6rRDoH/2dsb2JhbAA4CqdbgiOBBYFyAQEBAwESASVAARALGAkWDwkDAgECAUUGDQEHAQEXB4dglhMBnkKGY4M0BIgVjCCSGg X-IronPort-AV: E=Sophos;i="4.69,526,1315180800"; d="scan'208";a="14823426" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 17 Nov 2011 11:37:24 +0000 Received: from fandreas-mac.local (sjc-vpn5-1899.cisco.com [10.21.95.107]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAHBbMv1029705; Thu, 17 Nov 2011 11:37:23 GMT Message-ID: <4EC4F1FF.9080606@cisco.com> Date: Thu, 17 Nov 2011 06:37:35 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Harald Alvestrand References: <4EC46C66.9010305@cisco.com> <4EC4C947.8060807@alvestrand.no> <4EC4DFC4.5040108@cisco.com> <4EC4E5ED.6000908@alvestrand.no> In-Reply-To: <4EC4E5ED.6000908@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-holmberg-mmusic-sdp-bundle-negotiation@tools.ietf.org, mmusic Subject: Re: [MMUSIC] Comments on draft-holmberg-mmusic-sdp-bundle-negotiation-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 11:37:30 -0000 On 11/17/11 5:46 AM, Harald Alvestrand wrote: > On 11/17/2011 06:19 PM, Flemming Andreasen wrote: >> >> >> On 11/17/11 3:43 AM, Harald Alvestrand wrote: >>> Thanks for the review! >>> >>> I may want to be a little more undiplomatic than Holmberg, however... >>> >>> On 11/17/2011 10:07 AM, Flemming Andreasen wrote: >>>> I have two major comments on the draft: >>>> >>>> 1) The draft says that it is backwards compatible, however I don't >>>> believe it is. As the authors note, sharing tranxport addresses >>>> among multiple media descriptions is undefined in RFC 4566, and >>>> while the draft suggests some ways around that on the offering >>>> side, I don't believe they work. Problems include: >>>> - Potential SSRC overlap between the different media streams, which >>>> will lead to all kinds of problems >>> The result of successfully negotiating the extension will be one RTP >>> session (or one RTP session per bundle). If the RTP implementation >>> is incompetent enough to put more than one media flow onto one SSRC >>> inside one RTP session, then it has much bigger problems than >>> supporting the bundle. >> The issue here is when the answerer does not support the extension. >> The answerer now believes there are multiple different RTP sessions >> and hence may end up using the same SSRC, however this will not work >> on the offering side. > It will work if the offerer is able to distinguish the two 5-tuples; > since the answer came back without the BUNDLE extension, the offerer > knows that there are multiple different RTP sessions. Maybe so, but when those two RTP sessions have different payload type mappings for the same payload type numbers (as they most likely will) it gets ugly. >> >>>> - Does not work without symmetric media/RTP (as more or less noted >>>> in the draft) >>> I believe this is true. It should be made even more explicit than it >>> already is. >>> Being a precondition for using it means that we don't have to deal >>> with the non-symmetric-media situation; we simply can't use the >>> extension under those conditions. >> Indeed, and hence it is not backwards compatible for those >> implementations. >> >>> (This also means that the extension is useless for multicast. Not a >>> problem.) >>> >>>> - Even when symmetric media/RTP is used, NAT implies that you >>>> cannot use the port information from the SDP answer to infer the >>>> missing parts of the 5-tuple. >>> >>> When NAT is used, ICE is required to get media flowing. This is >>> something that is true for all SDP session negotiations; I do not >>> believe it is in any way unique to this draft. >>> >> The draft says that "the SDP offerer can use the port information >> from the SDP answer in order to create the 5-tuple mapping for each >> media". I'm simply saying this doesn't work in the presence of NATs >> (whether ICE is used or not). > Yes, this language needs to be changed to clarify that "port > information from the SDP answer" may refer to port information > gathered via the ICE exchange rather than the (useless) information > from the SDP m= line. > > The language in question is in section 6.2: > > NOTE: Assuming symmetric media is used, the SDP Offerer can use the > port information from the SDP Answer in order to create the 5-tuple > mapping for each media. > > >> >> >>>> >>>> - Given that shared transport addresses between different media >>>> streams is undefined in RFC 4566, the answerer may not support this >>>> to begin with >>> >>> You mean transport addresses on flows from the answerer to the offerer? >> >> Effectively yes (theoretically, there could be an issue on the >> answerer processing such an offer in the first place). >> >>> >>> This is the piece that bothers me, and which was the main difference >>> between draft-holmberg and draft-alvestrand-one-rtp-stream. However, >>> most commenters when they were both presented seemed to indicate >>> that draft-holmberg's solution did not present a problem. >>> >>>> - Shared destination transport addresses without full 5-tuple >>>> information implies that you cannot identify each media stream as >>>> an independent flow in the network, and the ability to do so may be >>>> one reason the answerer did not want to do bundles to begin with. >>> I do not parse this sentence. Given that symmetric SDP is a >>> requirement, the full 5-tuple is known by both sender and receiver. >>> Most equipment that cares about flows works on 5-tuples rather than >>> 3-tuples; are you suggesting that there exists flow-identifying >>> equpment we care about where unique 3-tuples is a requirement for >>> correct operation? >>> >> The full 5-tuple that the sender and receiver knows may not be the >> same as the network sees due to NATs. There exists equipment and >> standards that classify flows based on destination transport address >> alone (e.g. for QoS operation). > References? I'm quite aware of equipment that does classification on > destination port numbers, but that's obviously not what you're > thinking about. 3GPP and PacketCable policy control. >> >>>> - Fallback is to do another O/A exchange, however at that point, >>>> the media streams have already been established, and hence this is >>>> not backwards compatible. >>> Do you mean that doing two O/A exchanges is not backwards >>> compatible, or that having some short period of media flow before >>> the new O/A exchange can be performed is an issue? >> Both, however the issue is that the first O/A exchange may establish >> media streams that do not function correctly. Furthermore, you cannot >> always immediately start a second O/A exchange to rectify this (think >> early media). >> >> >>>> >>>> Fundamentally, we always have this backwards compatibility issue >>>> when using grouping to try and negotiate something that has to be >>>> supported by the other side to avoid failures, and this is another >>>> example of that. I will note that SDP Capability Negotiation is an >>>> alternative solution to what you are trying to do and it would not >>>> suffer from these backwards compatibility issues (would still need >>>> to define a capability negotiation extension for this though). >>> >>> I did not see anything in RFC 5939 that would be helpful; I might >>> not have read it closely enough. >>> >> The issue is that RFC 4566 (SDP) has a rule that says to simply >> ignore unknown attributes. If correct processing of those unknown >> attributes is a prerequisite for correct operation you have a >> problem. The way grouping is used here you run into that per the above. > In this case, we're dependent on a particular behaviour (5-tuple > stream ID and symmetric RTP) that I believe is widely used outside of > this standard, but that behaviour is not specified by any attribute I > know of (RFC 4961 did not specify an SDP attribute). > > The alternate from draft-alvestrand, different source ports, would > present other problems (must spin up ports that are thrown away if not > used). Would you see that as less problematic? >> Yes - I believe it would resolve the backwards compatibility issues discussed so far. >> >> >>>> >>>> >>>> 2) The intent of the draft is to effectively turn multiple media >>>> descriptions into a single RTP (or other media) session. We do >>>> however have a number of SDP parameters (in RFC 4566 and >>>> extensions) that are specified on a per media stream basis and we >>>> need some general rules around how to deal with those. Section 7.2 >>>> begins to look at it, but we need a lot more here, especially if we >>>> need to support backwards compatibility at the same time in a >>>> single O/A exchange. Some media description parameters will have to >>>> be cumulative among the multiple "m=" lines (rtpmap for example), >>>> others will have to pick a single one (e.g. SRTP keying >>>> parameters), and yet others will need to be combined (bandwidth for >>>> example as noted in the draft). >>> >>> This was also addressed a bit more explicitly in >>> draft-alvestrand-one-rtp, but I have not yet seen a description of a >>> parameter where the required rule is not obvious; payload types >>> (a=rtpmap) values have to be unique across all the description >>> pieces of the RTP session, which naturally solves the problem for >>> a=fmtp parameters; bandwidth has already been discussed; a=label and >>> SDES keying parameters only makes sense once for the session. >>> >>> Which other parameters are there where the answer is not obvious? >> Even reasonable people tend to differ on what is obvious, especially >> once they start implementing things. While we could go through the >> entire list of SDP parameters defined to date and specify for each >> how to handle it, how do you handle future SDP parameters ? It would >> be a shame if this mechanism didn't work for any SDP extensions >> defined after it and hence we need a general and interoperable >> solution to this issue. > Going through the list (or parts of it) might result in us concluding > that there are only a few categories of handling possible, and that > it's reasonable to require future extensions to fit within the > categories. Or it might not. > > Suggestions? It can't hurt to take a look at that, although I prefer that each new extension is self-contained and hence doesn't require other (especially future) extensions to define how they work together (classic feature interaction issue). Thanks -- Flemming > > From christer.holmberg@ericsson.com Thu Nov 17 04:00:49 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8656421F9AC2 for ; Thu, 17 Nov 2011 04:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.766 X-Spam-Level: X-Spam-Status: No, score=-5.766 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=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 UxqwX8GorP9h for ; Thu, 17 Nov 2011 04:00:48 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB9C11E80AD for ; Thu, 17 Nov 2011 04:00:48 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-27-4ec4f76f8241 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A8.95.09514.F67F4CE4; Thu, 17 Nov 2011 13:00:47 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.2]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 17 Nov 2011 13:00:46 +0100 From: Christer Holmberg To: Flemming Andreasen , Harald Alvestrand Date: Thu, 17 Nov 2011 13:00:45 +0100 Thread-Topic: [MMUSIC] Comments on draft-holmberg-mmusic-sdp-bundle-negotiation-00 Thread-Index: AcylEnV0DKRrHeoESK6OJhxOqhG6YgACcsVH Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3925E7CC@ESESSCMS0356.eemea.ericsson.se> References: <4EC46C66.9010305@cisco.com> <4EC4C947.8060807@alvestrand.no>,<4EC4DFC4.5040108@cisco.com> In-Reply-To: <4EC4DFC4.5040108@cisco.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: "draft-holmberg-mmusic-sdp-bundle-negotiation@tools.ietf.org" , mmusic Subject: Re: [MMUSIC] Comments on draft-holmberg-mmusic-sdp-bundle-negotiation-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 12:00:49 -0000 Hi, >>> - Does not work without symmetric media/RTP (as more or less noted in >>> the draft) >> I believe this is true. It should be made even more explicit than it alr= eady is. >> Being a precondition for using it means that we don't have to deal >> with the non-symmetric-media situation; we simply can't use the >> extension under those conditions. > Indeed, and hence it is not backwards compatible for those implementation= s. Are you saying that it would be TOO restrictive to assume symmetric RTP? I think there are a number of other features that also assume symmetric RTP= . >>> - Even when symmetric media/RTP is used, NAT implies that you cannot >>> use the port information from the SDP answer to infer the missing >>> parts of the 5-tuple. >> >> When NAT is used, ICE is required to get media flowing. This is >> something that is true for all SDP session negotiations; I do not >> believe it is in any way unique to this draft. >> > The draft says that "the SDP offerer can use the port information from > the SDP answer in order to create the 5-tuple mapping for each media". > I'm simply saying this doesn't work in the presence of NATs (whether ICE > is used or not). Maybe we need to fix the wording, and talk about the source address of the = RTP packages. >>> - Given that shared transport addresses between different media >>> streams is undefined in RFC 4566, the answerer may not support this >>> to begin with >> >> You mean transport addresses on flows from the answerer to the offerer? > > Effectively yes (theoretically, there could be an issue on the answerer > processing such an offer in the first place). >>> - Shared destination transport addresses without full 5-tuple >>> information implies that you cannot identify each media stream as an >>> independent flow in the network, and the ability to do so may be one >>> reason the answerer did not want to do bundles to begin with. >> I do not parse this sentence. Given that symmetric SDP is a >> requirement, the full 5-tuple is known by both sender and receiver. >> Most equipment that cares about flows works on 5-tuples rather than >> 3-tuples; are you suggesting that there exists flow-identifying >> equpment we care about where unique 3-tuples is a requirement for >> correct operation? >> > The full 5-tuple that the sender and receiver knows may not be the same > as the network sees due to NATs. There exists equipment and standards > that classify flows based on destination transport address alone (e.g. > for QoS operation). If you have such procedures, won't that always cause issues when you have N= ATs? How is that specific to BUNDLE? >>> - Fallback is to do another O/A exchange, however at that point, the >>> media streams have already been established, and hence this is not >>> backwards compatible. >> Do you mean that doing two O/A exchanges is not backwards compatible, >> or that having some short period of media flow before the new O/A >> exchange can be performed is an issue? > Both, however the issue is that the first O/A exchange may establish > media streams that do not function correctly. Furthermore, you cannot > always immediately start a second O/A exchange to rectify this (think > early media). >> Fundamentally, we always have this backwards compatibility issue when >> using grouping to try and negotiate something that has to be >> supported by the other side to avoid failures, and this is another >> example of that. I will note that SDP Capability Negotiation is an >> alternative solution to what you are trying to do and it would not >> suffer from these backwards compatibility issues (would still need to >> define a capability negotiation extension for this though). > > I did not see anything in RFC 5939 that would be helpful; I might not > have read it closely enough. > > The issue is that RFC 4566 (SDP) has a rule that says to simply ignore > unknown attributes. If correct processing of those unknown attributes is > a prerequisite for correct operation you have a problem. The way > grouping is used here you run into that per the above. Sure, maybe there are entities that will reject the offer, but then I will = claim that it is as likely (or, even more liekly) that there will be interm= ediaries that will have problems with CapNeg :) >> 2) The intent of the draft is to effectively turn multiple media >> descriptions into a single RTP (or other media) session. We do >> however have a number of SDP parameters (in RFC 4566 and extensions) >> that are specified on a per media stream basis and we need some >> general rules around how to deal with those. Section 7.2 begins to >> look at it, but we need a lot more here, especially if we need to >> support backwards compatibility at the same time in a single O/A >> exchange. Some media description parameters will have to be >> cumulative among the multiple "m=3D" lines (rtpmap for example), others >> will have to pick a single one (e.g. SRTP keying parameters), and yet >> others will need to be combined (bandwidth for example as noted in >> the draft). > > This was also addressed a bit more explicitly in > draft-alvestrand-one-rtp, but I have not yet seen a description of a > parameter where the required rule is not obvious; payload types > (a=3Drtpmap) values have to be unique across all the description pieces > of the RTP session, which naturally solves the problem for a=3Dfmtp > parameters; bandwidth has already been discussed; a=3Dlabel and SDES > keying parameters only makes sense once for the session. > > Which other parameters are there where the answer is not obvious? > Even reasonable people tend to differ on what is obvious, especially > once they start implementing things. While we could go through the > entire list of SDP parameters defined to date and specify for each how > to handle it, how do you handle future SDP parameters ? It would be a > shame if this mechanism didn't work for any SDP extensions defined after > it and hence we need a general and interoperable solution to this issue. I still don't understand how you would avoid having to do that with CapNeg. Regards, Christer= From ietf@meetecho.com Thu Nov 17 10:35:49 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1722D21F9605 for ; Thu, 17 Nov 2011 10:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oV9Sxqz51cNc for ; Thu, 17 Nov 2011 10:35:48 -0800 (PST) Received: from smtplq03.aruba.it (smtplq-out18.aruba.it [62.149.158.38]) by ietfa.amsl.com (Postfix) with SMTP id BE03C21F95CC for ; Thu, 17 Nov 2011 10:35:47 -0800 (PST) Received: (qmail 4861 invoked by uid 89); 17 Nov 2011 18:35:42 -0000 Received: from unknown (HELO smtp3.aruba.it) (62.149.158.223) by smtplq03.aruba.it with SMTP; 17 Nov 2011 18:35:42 -0000 Received: (qmail 13974 invoked by uid 89); 17 Nov 2011 18:35:42 -0000 Received: from unknown (HELO ?192.168.15.115?) (ietf@meetecho.com@114.24.8.77) by smtp3.ad.aruba.it with SMTP; 17 Nov 2011 18:35:42 -0000 Message-ID: <4EC553F4.9070007@meetecho.com> Date: Thu, 17 Nov 2011 19:35:32 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp3.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq03.aruba.it 1.6.2 0/1000/N Subject: [MMUSIC] Meetecho support for MMUSIC WG meeting session X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 18:35:49 -0000 Hi all, a virtual room has been reserved on the Meetecho system for Friday's MMUSIC WG meeting session. Access to the on-line session (including audio and video streams) will be available from 9:00am at: http://www.meetecho.com/ietf82/mmusic The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf82/tutorials For further information you can contact us at ietf-support@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From ietf@meetecho.com Mon Nov 21 06:40:50 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D499321F8B43 for ; Mon, 21 Nov 2011 06:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.422 X-Spam-Level: X-Spam-Status: No, score=-0.422 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGJVl-0c+Q79 for ; Mon, 21 Nov 2011 06:40:46 -0800 (PST) Received: from smtplq04.aruba.it (smtplq-out19.aruba.it [62.149.158.39]) by ietfa.amsl.com (Postfix) with SMTP id F351521F8B34 for ; Mon, 21 Nov 2011 06:40:45 -0800 (PST) Received: (qmail 6332 invoked by uid 89); 21 Nov 2011 14:40:44 -0000 Received: from unknown (HELO smtp1.aruba.it) (62.149.158.221) by smtplq04.aruba.it with SMTP; 21 Nov 2011 14:40:44 -0000 Received: (qmail 18538 invoked by uid 89); 21 Nov 2011 14:40:44 -0000 Received: from unknown (HELO ?143.225.229.189?) (ietf@meetecho.com@143.225.229.189) by smtp1.ad.aruba.it with SMTP; 21 Nov 2011 14:40:44 -0000 Message-ID: <4ECA62DE.6000704@meetecho.com> Date: Mon, 21 Nov 2011 15:40:30 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp1.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N Subject: [MMUSIC] MMUSIC session recording available X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 14:40:50 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of MMUSIC session at IETF-82 is available. You can watch it by either clicking the proper link on the remote participation page (http://www.ietf.org/meeting/82/remote-participation.html#Meetecho), or by directly accessing the following URL: http://www.meetecho.com/ietf82/recordings#MMUSIC For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From HKaplan@acmepacket.com Mon Nov 21 09:59:59 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D6A21F8B18; Mon, 21 Nov 2011 09:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 k+dFJMloF-vH; Mon, 21 Nov 2011 09:59:59 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 038F421F8AAA; Mon, 21 Nov 2011 09:59:58 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 21 Nov 2011 12:59:55 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 21 Nov 2011 12:59:55 -0500 From: Hadriel Kaplan To: "mmusic (E-mail)" Thread-Topic: [MMUSIC] Comments on draft-ietf-mmusic-media-loopback-16 Thread-Index: AQHMqHdfBqooEIMwnkm5vxPqfuyS4w== Date: Mon, 21 Nov 2011 17:59:55 +0000 Message-ID: <4E297805-F75E-4728-855B-A0F78BE86D9B@acmepacket.com> References: <4EA13A85.2060506@ericsson.com> In-Reply-To: <4EA13A85.2060506@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5F4082E497E5B84AB72325A719DD93B7@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: Magnus Westerlund , "payload@ietf.org" Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-media-loopback-16 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 17:59:59 -0000 Howdy, Magnus sent back a big list of comments against media-loopback for the WGLC= . I plan to propose changes to address some of his points in separate emails,= notably for the technical ones. The following points copied below I consider editorial in nature and wish t= o resolve directly as the editor. Does anyone object to this? On Oct 21, 2011, at 5:25 AM, Magnus Westerlund wrote: > 5. Abstract: "maintaining voice/real-time Text/video quality, > reliability, and overall performance." The "voice/real-time" > construction appears to indicate that voice isn't real-time. I guess > something like: maintaining real-time voice/Text/video quality, > reliability, and overall performance. would be easier and clearer. >=20 > 6. Section 3. > No reference to SDP offer answer. And the "Offering entity" is called > agent in SDP O/A terminology. >=20 > 7. Section 3: > "it MAY do so as defined in section 5.4.1 of > this specification." >=20 > Considering what is written in 5.4.1 I think that section can be moved > to section 3. >=20 > 8. Section 4: > An answering entity that is not compliant to this specification and > which receives an offer with the "loopback" media attributes MAY > ignore the attribute and treat the incoming offer as a normal > request. >=20 > I would suggest reformulate this. I expect this text to say what is > expected to happen when the answering agent doesn't know what this > attribute is. Which is ignore the attribute, attempt to establish the > session without loopback and send back the answer without the attribute. >=20 > I would suggest to clarify that the offering agent should consider > terminating the establishment at this point as loopback was not > available, unless it might actual "ring" if this is an end-point at a use= r. >=20 ... > 10. What is really the purpose of the sections 3 and 4. They seem to be > teasers for a very small part of the issue that is covered in detail in > section 5. Why not move the appropriate text in to the relevant subsectio= ns? >=20 ... >=20 > 12. Section 5.3: > I think one could clarify that the loopback source needs to include the > encapsulation or direct loopback payload formats when suggesting pckt > type loopback. >=20 > ... > 14. Section 5.1: > loopback-type =3D loopback-choice [1*SP loopback-choice] > loopback-choice =3D loopback-type-pkt / loopback-type-media > loopback-type-pkt =3D "rtp-pkt-loopback" > loopback-type-media =3D "rtp-media-loopback" >=20 > The ABNF appears broken as it doesn't define the whole attribute. I > would suggest to add a line: >=20 > loopback-attr =3D "a=3Dloopback:" loopback-type >=20 > 15. Section 5.2 is missing ABNF. > I think it should make clear the attributes definition completely. >=20 > 16. Section 5 > Two new media attributes are defined: one indicates the type of > loopback and the other indicates the mode of the loopback. >=20 > I would claim that this spec defines 3 attributes. >=20 > 17. Section 5.4: >=20 > The loopback-mode attributes (loopbackThe > port number and the address in the answer (m=3D line) indicate where > the answerer would like to receive the media stream. >=20 > Strange sentence! >=20 ... > 21. Section 6. > "An answering entity that is compliant to this specification and > accepting a media with the loopback type rtp-media-loopback MUST > transmit all received media back to the sender. " >=20 > I think this MUST, MUST have an exception for that the path from the > mirror to the source actually can support the bit-rate required. >=20 ... > 36. Section 10.1 > Either of the o=3D lines are in error. Because they can't be the same whe= n > it comes to the ID and version fields. >=20 ... -hadriel From HKaplan@acmepacket.com Mon Nov 21 10:57:56 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8316211E80E7; Mon, 21 Nov 2011 10:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 gAqxTUeACsMI; Mon, 21 Nov 2011 10:57:56 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id F2B4511E80E5; Mon, 21 Nov 2011 10:57:55 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 21 Nov 2011 13:57:54 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 21 Nov 2011 13:57:54 -0500 From: Hadriel Kaplan To: "mmusic (E-mail)" , "payload@ietf.org" Thread-Topic: Issue #4 from Magnus on draft-ietf-mmusic-media-loopback-16 Thread-Index: AQHMqH95nHVY2W5eEU6uQXRGDD1AsA== Date: Mon, 21 Nov 2011 18:57:53 +0000 Message-ID: References: <4EA13A85.2060506@ericsson.com> In-Reply-To: <4EA13A85.2060506@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1847384CF048EF4EA80807AE67A67EBC@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: Magnus Westerlund , "" Subject: [MMUSIC] Issue #4 from Magnus on draft-ietf-mmusic-media-loopback-16 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 18:57:56 -0000 On Oct 21, 2011, at 5:25 AM, Magnus Westerlund wrote: > 4. Title: I think the title is indicating that this is only an SDP > solution, but it clearly contains the considerations needed for the > RTP/RTCP part also. I think it should reflect that it is a solution for > RTP transported media loopback including SDP signalling. I propose the following title: "A Media Loopback Mechanism for Real-time Transport Protocol (RTP)" Does anyone object? -hadriel From HKaplan@acmepacket.com Mon Nov 21 11:06:35 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15CF1F0C7E; Mon, 21 Nov 2011 11:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 v1DUiwrJAC7O; Mon, 21 Nov 2011 11:06:34 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 754201F0C79; Mon, 21 Nov 2011 11:05:57 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 21 Nov 2011 14:05:56 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 21 Nov 2011 14:05:56 -0500 From: Hadriel Kaplan To: "mmusic (E-mail)" , "payload@ietf.org" Thread-Topic: Issue #11 from Magnus on draft-ietf-mmusic-media-loopback-16 Thread-Index: AQHMqICYahoClbm3JkeqXgL1uiWwxw== Date: Mon, 21 Nov 2011 19:05:56 +0000 Message-ID: References: <4EA13A85.2060506@ericsson.com> In-Reply-To: <4EA13A85.2060506@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: draft-ietf-mmusic-media-loopback Subject: [MMUSIC] Issue #11 from Magnus on draft-ietf-mmusic-media-loopback-16 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 19:06:35 -0000 With regards to issue #11 on the media-loopback draft, the consensus on the= mailing list so far appears to be ok with the following text: "Since media loopback requires bidirectional RTP, its normal direction mode= is "sendrecv"; the "sendrecv" direction attribute MAY be encoded in SDP or= not, as per section 5.1 of [RFC3264], since it is implied by default. If e= ither the loopback source or mirror wish to disable loopback use during a s= ession, the direction attribute "inactive" MUST be used as per [RFC3264]. = The direction mode attributes "recvonly" and "sendonly" are incompatible wi= th the loopback mechanism and MUST NOT be indicated when generating an SDP = Offer or Answer." Does anyone object to the above text? -hadriel On Oct 21, 2011, at 5:25 AM, Magnus Westerlund wrote: > 11. Section 5.3 > " Note: A loopback offer in a given media description MUST NOT > contain the standard mode attributes sendonly, recvonly, sendrecv, > or inactive. The loopback-mode attributes (loopback-source and > loopback-mirror) replace the standard attributes." >=20 > This appears to be a strange MUST NOT which I think might encounter > issues. Considering that SIP proxies that looks into this SDP requires > the direction attribute to be present and adds it, what happens now. > And why isn't sendrecv and inactive possible values? sendrecv appears to > be requried for loopback to work, and inactive would put media transport > in an established session on hold. Isn't that reasonable? From nathan@robotics.net Mon Nov 21 11:26:57 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACCD1F0C8B; Mon, 21 Nov 2011 11:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuXGW47ymbGa; Mon, 21 Nov 2011 11:26:56 -0800 (PST) Received: from bart.robotics.net (bart.robotics.net [75.148.206.242]) by ietfa.amsl.com (Postfix) with ESMTP id B42C01F0C5A; Mon, 21 Nov 2011 11:26:56 -0800 (PST) Received: from [10.13.0.114] (75-148-206-241-Houston.hfc.comcastbusiness.net [75.148.206.241]) by bart.robotics.net (Postfix) with ESMTPA id 0BBDD22020E; Mon, 21 Nov 2011 13:26:39 -0600 (CST) References: <4EA13A85.2060506@ericsson.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9A405) From: Nathan Stratton Date: Mon, 21 Nov 2011 13:26:37 -0600 To: Hadriel Kaplan Cc: draft-ietf-mmusic-media-loopback , "mmusic \(E-mail\)" , "payload@ietf.org" Subject: Re: [MMUSIC] Issue #11 from Magnus on draft-ietf-mmusic-media-loopback-16 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 19:26:57 -0000 Looks good. Sent from my iPhone On Nov 21, 2011, at 1:05 PM, Hadriel Kaplan wrote: >=20 > With regards to issue #11 on the media-loopback draft, the consensus on th= e mailing list so far appears to be ok with the following text: >=20 > "Since media loopback requires bidirectional RTP, its normal direction mod= e is "sendrecv"; the "sendrecv" direction attribute MAY be encoded in SDP or= not, as per section 5.1 of [RFC3264], since it is implied by default. If ei= ther the loopback source or mirror wish to disable loopback use during a ses= sion, the direction attribute "inactive" MUST be used as per [RFC3264]. The= direction mode attributes "recvonly" and "sendonly" are incompatible with t= he loopback mechanism and MUST NOT be indicated when generating an SDP Offer= or Answer." >=20 > Does anyone object to the above text? >=20 > -hadriel >=20 >=20 > On Oct 21, 2011, at 5:25 AM, Magnus Westerlund wrote: >=20 >> 11. Section 5.3 >> " Note: A loopback offer in a given media description MUST NOT >> contain the standard mode attributes sendonly, recvonly, sendrecv, >> or inactive. The loopback-mode attributes (loopback-source and >> loopback-mirror) replace the standard attributes." >>=20 >> This appears to be a strange MUST NOT which I think might encounter >> issues. Considering that SIP proxies that looks into this SDP requires >> the direction attribute to be present and adds it, what happens now. >> And why isn't sendrecv and inactive possible values? sendrecv appears to >> be requried for loopback to work, and inactive would put media transport >> in an established session on hold. Isn't that reasonable? From miguel.a.garcia@ericsson.com Mon Nov 21 22:43:25 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53ED811E816A; Mon, 21 Nov 2011 22:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.384 X-Spam-Level: X-Spam-Status: No, score=-6.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 jAPppBtEU60T; Mon, 21 Nov 2011 22:43:24 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2F40511E8165; Mon, 21 Nov 2011 22:43:24 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-92-4ecb4488d26b Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 22.02.09514.8844BCE4; Tue, 22 Nov 2011 07:43:20 +0100 (CET) Received: from [159.107.24.191] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Tue, 22 Nov 2011 07:43:20 +0100 Message-ID: <4ECB4487.9000801@ericsson.com> Date: Tue, 22 Nov 2011 07:43:19 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Hadriel Kaplan References: <4EA13A85.2060506@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Magnus Westerlund , "" , "mmusic \(E-mail\)" , "payload@ietf.org" Subject: Re: [MMUSIC] Issue #4 from Magnus on draft-ietf-mmusic-media-loopback-16 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 06:43:25 -0000 Hi: In my comments posted in this mail: http://www.ietf.org/mail-archive/web/mmusic/current/msg08958.html I suggested to rename the draft to: "An extension to SDP and RTP for media loopback". While I don't care much of the exact words, I think the terms "SDP", "RTP" and "media loopback" need all be in the title of the document. Your proposal misses "SDP", so, if you add it, I will agree. BR, Miguel On 21/11/2011 19:57, Hadriel Kaplan wrote: > > > > On Oct 21, 2011, at 5:25 AM, Magnus Westerlund wrote: > >> 4. Title: I think the title is indicating that this is only an SDP >> solution, but it clearly contains the considerations needed for the >> RTP/RTCP part also. I think it should reflect that it is a solution for >> RTP transported media loopback including SDP signalling. > > I propose the following title: > "A Media Loopback Mechanism for Real-time Transport Protocol (RTP)" > > Does anyone object? > > -hadriel > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From HKaplan@acmepacket.com Tue Nov 22 00:11:33 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA0211E8083; Tue, 22 Nov 2011 00:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 bHuo3BmPBor9; Tue, 22 Nov 2011 00:11:32 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 60D1A21F8557; Tue, 22 Nov 2011 00:11:28 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 22 Nov 2011 03:11:24 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Tue, 22 Nov 2011 03:11:24 -0500 From: Hadriel Kaplan To: "Miguel A. Garcia" Thread-Topic: [MMUSIC] Issue #4 from Magnus on draft-ietf-mmusic-media-loopback-16 Thread-Index: AQHMqO5T57XIgns6CUqTjH7PUFazsg== Date: Tue, 22 Nov 2011 08:11:24 +0000 Message-ID: <5960030E-C594-4751-84CB-46E30275232C@acmepacket.com> References: <4EA13A85.2060506@ericsson.com> <4ECB4487.9000801@ericsson.com> In-Reply-To: <4ECB4487.9000801@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <98ED0D38328506468E4FAB6780579EA0@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: Magnus Westerlund , "" , "mmusic \(E-mail\)" , "payload@ietf.org" Subject: Re: [MMUSIC] Issue #4 from Magnus on draft-ietf-mmusic-media-loopback-16 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 08:11:33 -0000 Hi Miguel, I knew you had also posted comments but I was planning to address Magnus' f= irst and then your's, but I see now there is some overlap. With regard to title, would this be ok: "A Media Loopback Mechanism for Real-time Transport Protocol (RTP) and Exte= nsion for SDP" -hadriel On Nov 22, 2011, at 1:43 AM, Miguel A. Garcia wrote: > Hi: >=20 > In my comments posted in this mail: > http://www.ietf.org/mail-archive/web/mmusic/current/msg08958.html >=20 > I suggested to rename the draft to: "An extension to SDP and RTP for medi= a loopback". >=20 > While I don't care much of the exact words, I think the terms "SDP", "RTP= " and "media loopback" need all be in the title of the document. Your propo= sal misses "SDP", so, if you add it, I will agree. >=20 > BR, >=20 > Miguel >=20 > On 21/11/2011 19:57, Hadriel Kaplan wrote: >>=20 >>=20 >>=20 >> On Oct 21, 2011, at 5:25 AM, Magnus Westerlund wrote: >>=20 >>> 4. Title: I think the title is indicating that this is only an SDP >>> solution, but it clearly contains the considerations needed for the >>> RTP/RTCP part also. I think it should reflect that it is a solution for >>> RTP transported media loopback including SDP signalling. >>=20 >> I propose the following title: >> "A Media Loopback Mechanism for Real-time Transport Protocol (RTP)" >>=20 >> Does anyone object? >>=20 >> -hadriel >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >=20 > --=20 > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain From miguel.a.garcia@ericsson.com Tue Nov 22 00:12:27 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C85D11E8164; Tue, 22 Nov 2011 00:12:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.394 X-Spam-Level: X-Spam-Status: No, score=-6.394 tagged_above=-999 required=5 tests=[AWL=0.205, 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 VcpUXhEYyADP; Tue, 22 Nov 2011 00:12:26 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id D675C21F858D; Tue, 22 Nov 2011 00:12:25 -0800 (PST) X-AuditID: c1b4fb3d-b7c26ae0000035b9-4c-4ecb5961b667 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 48.FA.13753.1695BCE4; Tue, 22 Nov 2011 09:12:17 +0100 (CET) Received: from [159.107.24.191] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Tue, 22 Nov 2011 09:12:17 +0100 Message-ID: <4ECB5960.4090305@ericsson.com> Date: Tue, 22 Nov 2011 09:12:16 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Hadriel Kaplan References: <4EA13A85.2060506@ericsson.com> <4ECB4487.9000801@ericsson.com> <5960030E-C594-4751-84CB-46E30275232C@acmepacket.com> In-Reply-To: <5960030E-C594-4751-84CB-46E30275232C@acmepacket.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Magnus Westerlund , "" , "mmusic \(E-mail\)" , "payload@ietf.org" Subject: Re: [MMUSIC] Issue #4 from Magnus on draft-ietf-mmusic-media-loopback-16 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 08:12:27 -0000 Works for me. /Miguel On 22/11/2011 9:11, Hadriel Kaplan wrote: > > Hi Miguel, > I knew you had also posted comments but I was planning to address Magnus' first and then your's, but I see now there is some overlap. > > With regard to title, would this be ok: > > "A Media Loopback Mechanism for Real-time Transport Protocol (RTP) and Extension for SDP" > > -hadriel > > > On Nov 22, 2011, at 1:43 AM, Miguel A. Garcia wrote: > >> Hi: >> >> In my comments posted in this mail: >> http://www.ietf.org/mail-archive/web/mmusic/current/msg08958.html >> >> I suggested to rename the draft to: "An extension to SDP and RTP for media loopback". >> >> While I don't care much of the exact words, I think the terms "SDP", "RTP" and "media loopback" need all be in the title of the document. Your proposal misses "SDP", so, if you add it, I will agree. >> >> BR, >> >> Miguel >> >> On 21/11/2011 19:57, Hadriel Kaplan wrote: >>> >>> >>> >>> On Oct 21, 2011, at 5:25 AM, Magnus Westerlund wrote: >>> >>>> 4. Title: I think the title is indicating that this is only an SDP >>>> solution, but it clearly contains the considerations needed for the >>>> RTP/RTCP part also. I think it should reflect that it is a solution for >>>> RTP transported media loopback including SDP signalling. >>> >>> I propose the following title: >>> "A Media Loopback Mechanism for Real-time Transport Protocol (RTP)" >>> >>> Does anyone object? >>> >>> -hadriel >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> -- >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From internet-drafts@ietf.org Tue Nov 22 00:14:35 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952FD11E816D; Tue, 22 Nov 2011 00:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 rvPlX23ql6IZ; Tue, 22 Nov 2011 00:14:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40FC11E8161; Tue, 22 Nov 2011 00:14:34 -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: 3.64 Message-ID: <20111122081434.7987.5487.idtracker@ietfa.amsl.com> Date: Tue, 22 Nov 2011 00:14:34 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-parallax-attribute-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 08:14:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : SDP attribute to signal parallax Author(s) : Bert Greevenbosch Hui Yu Filename : draft-ietf-mmusic-parallax-attribute-00.txt Pages : 15 Date : 2011-11-21 This document introduces a "ParallaxInfo" attribute in SDP. This attribute can be used in stereoscopic applications, to signal the depth positioning of 2D media data within the 3D space. Note Discussion and suggestions for improvement are requested, and should be sent to mmusic@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-parallax-attribute-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-ietf-mmusic-parallax-attribute-00.= txt From internet-drafts@ietf.org Tue Nov 22 00:17:40 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA0411E8174; Tue, 22 Nov 2011 00:17:40 -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 VpLywvBZ39Vd; Tue, 22 Nov 2011 00:17:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1BA611E8156; Tue, 22 Nov 2011 00:17:38 -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: 3.64 Message-ID: <20111122081720.8054.11148.idtracker@ietfa.amsl.com> Date: Tue, 22 Nov 2011 00:17:20 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-signal-3d-format-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 08:17:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : Signal 3D format Author(s) : Bert Greevenbosch Hui Yu Filename : draft-ietf-mmusic-signal-3d-format-00.txt Pages : 27 Date : 2011-11-21 This document introduces the SDP attribute "3dFormat", which provides format description of stereoscopic 3D video. In addition, the grouping mechanism for SDP is extended to cater for stereoscopic 3D video. Note Discussion and suggestions for improvement are requested, and should be sent to mmusic@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-signal-3d-format-00.t= xt 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-mmusic-signal-3d-format-00.txt From HKaplan@acmepacket.com Tue Nov 22 00:25:40 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E4B21F8B74; Tue, 22 Nov 2011 00:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 MI4WqgC2uuzn; Tue, 22 Nov 2011 00:25:40 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id B0A6D21F8B73; Tue, 22 Nov 2011 00:25:39 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 22 Nov 2011 03:25:38 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Tue, 22 Nov 2011 03:25:38 -0500 From: Hadriel Kaplan To: "mmusic (E-mail)" , "payload@ietf.org" Thread-Topic: [MMUSIC] Comments to draft-ietf-mmusic-media-loopback-16 Thread-Index: AQHMqPBPLmwVIdu6wEilEi4+tI/ZTQ== Date: Tue, 22 Nov 2011 08:25:37 +0000 Message-ID: References: <4E9B41B6.9070506@ericsson.com> In-Reply-To: <4E9B41B6.9070506@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <84B500DA7A4DDB4C8D240F057B73DC21@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [MMUSIC] Comments to draft-ietf-mmusic-media-loopback-16 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 08:25:40 -0000 Howdy, Miguel sent back a list of comments against media-loopback for the WGLC. I plan to propose changes to address some of his points in separate emails,= for the technical comments. The following points copied below I consider editorial in nature and wish t= o resolve directly as the editor.=20 Does anyone object to this course of action? On Oct 16, 2011, at 4:42 PM, Miguel A. Garcia wrote: > - Terminology. I don't find any justification for this draft to depend on= RFC 3261 and for making references to SIP INVITEs and alike. Instead, the = draft should be based on the SDP offer/answer model (RFC 3264). As part of = this, I will add a paragraph in Section 2 saying that ... "The following te= rms are borrowed from RFC 3264: offer, offerer, answer, answerer". I will r= ename section 3 to "SDP offerer behavior", Section 4 to "SDP answerer behav= ior". An in general, I will not talk of the "offering entity" (section 3), = but the "offerer", or the "answering entity" (section 4), but the "answerer= ". >=20 > - I will add a new paragraph at the end of Section 3 indicating where the= "loopback" attribute is defined. >=20 > - Section 4, the last paragraph is not correct, because it puts a normati= ve requirement (MAY) for answerers that are not compliant with this specifi= cation. So, if an answerer is not compliant with this specification, how ca= n it comply with the normative MAY? >=20 > I suggest to replace the "MAY" with "is expected". >=20 > - I would rename Section 5 to "New SDP attributes" >=20 > - I would start Section 5.1 with a sentence that says: "This specificatio= n defines a new 'loopback' attribute which indicates the type of loopback t= hat the entity is able to do". >=20 ... > - The last two paragraphs in Section 5.1 describe the packet loopback and= the media loopback. However, in Section 1.1, there are three modes defined= . I would like to have a matching between the two values and the three mode= s. For example, you could add a sentence indicating in each of these two va= lues "this value is used when the loopback is of type xxx (see Section 1.X)= ." >=20 >=20 ... > - Section 5.3, after the example. There is a note that contains a normati= ve statement (MUST NOT). In principle, notes should be informative by natur= e, so just remove the word "Note:" from the beginning of the paragraph. >=20 > - Section 5.3, the paragraph after the Note refers to the "m=3D line" whe= n the draft says "The port number and the address in the offer (m=3D line).= .." However, the address in SDP goes in the c=3D line, therefore, whenever = you refer to port number and address, you should refer to the "m/c=3D lines= ". >=20 >=20 ... > - Examples at the end of Section 5.3 It would be nice to elaborate these = examples, describing what they are showing. Also, at this point in the draf= t, the "encaprtp" and "rtploopback" tokens have not been introduced, so it = would be nice to point to the sections where it will later be defined. >=20 > - Section 5.4, first paragraph, first sentence, replace "a loopback answe= r" with "an SDP answer". Later in this same paragraph replace "offerere" wi= th "offerer". >=20 > - There is some missing words in the second sentence of the first paragra= ph in Section 5.4. The sentence is incomplete. >=20 > - Section 5.4, second paragraph, write "attributes" in plural in the firs= t sentence. >=20 > - Section 5.5, first and second sentences, read: >=20 > The answer to a loopback-source MUST be loopback-mirror. The > answer to a loopback-mirror MUST be loopback-source. >=20 > First, the sentences should be expressed in terms of "SDP offer" and "SDP= answer" "containing a loopback-source" or "loopback-mirror". For example: >=20 > An offer containing a "loopback-source" attribute must be answered wit= h an SDP answer containing a "loopback-mirror attribute in the same media d= escription. An offer containing... >=20 > But, having said that... I wonder whether the above sentence makes sense = in this section. This section is titled "Offerer processing of the answer".= Therefore, I expect to find there what the offerer should do when it recei= ves an SDP answer, not what the answerer should do to process the offer and= generate the answer. So, move these two sentences to the Section 5.4. >=20 > - The third and fourth sentences in Section 5.5 read: >=20 > The > loopback-mode line MUST contain at least one codec the answerer is > willing to send or receive depending on whether it is the loopback- > source or the loopback-mirror. In addition, the "m=3D" line MUST > contain at least one codec that the answerer is willing to send or > receive depending on whether it is the loopback-mirror or the > loopback-source. >=20 > Well, it seems that these sentencse also describe how the answerer genera= tes the answer, so it should be moved to Section 5.4. >=20 > - Second paragraph in Section 5.5. Replace "target UA" with "answerer". B= ut most important, this paragraph needs to say what happens if the offer re= ceives an answer that does not include the loopback-mirror/loopback-source = attribute. I believe it should say that a session is still established, but= loopback packets are not expected. It is up to the offerer to close down t= he session by regular means (high level protocol such as a SIP BYE or sendi= ng a new offer with the port number set to zero). >=20 > - Section 5.6, I wonder way the "may" in the first sentence is not a MAY. >=20 > - Section 5.6, replace the reference to SIP. You just need the reference = to Section 8 of RFC 3264. >=20 ... > - Section 10. All the examples, replace "client", "server" and "INVITE re= quest", and "response" with: >=20 > An [offerer|answerer] sends an SDP [offer|answer] which looks like: >=20 > - Section 10. In all the examples, replace "s=3DExample" with "s=3D" (sou= rce, RFC 3264). And you can omit the i=3D and e=3D lines as well, they do n= ot really add anything, nor they are mandated. >=20 > - Section 10.3. Re-title this section to "SDP answer rejecting loopback m= edia". >=20 > - The note at the end of Section 10.3 reads: >=20 > NOTE: Loopback request may be rejected by either not including the > loopback mode attribute (for backward compatibility) or setting the > media port number to zero, or both, in the response. >=20 > First, I don't like this note here, because it may induce to double speci= fication, specially since you have Section 5.4 that describes how to reject= a loopback request. >=20 > And actually, here you have double incongruent specification. Section 5.4= .1 only offers one mechanism for rejecting a session: setting the port to z= ero like in regular SDP. Nothing is written about rejecting a session by no= t including the loopback mode attribute. >=20 > Not including a loopback mode attribute in the answer is not a rejection,= it is merely a session with no support for the loopback feature, but the s= ession is established. >=20 > I recommend to delete this note. >=20 > - Section 11. I disagree with the dependency on RFC 3261. Please remove. = Also, I am surprised of not seen any dependency of the security considerati= ons of RTP/RTCP. >=20 -hadriel From trac+mmusic@trac.tools.ietf.org Tue Nov 22 00:43:12 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94C321F8D19 for ; Tue, 22 Nov 2011 00:43:12 -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 67SFxUKRvZ-n for ; Tue, 22 Nov 2011 00:43:11 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 21A7A21F8D1A for ; Tue, 22 Nov 2011 00:43:10 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RSlwJ-0004dW-F2; Tue, 22 Nov 2011 03:42:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mmusic issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mmusic-media-loopback@tools.ietf.org, hkaplan@acmepacket.com X-Trac-Project: mmusic Date: Tue, 22 Nov 2011 08:42:51 -0000 X-URL: http://tools.ietf.org/mmusic/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/1 Message-ID: <063.dd932850aa2e7e04e8bf51bcfe9041ab@trac.tools.ietf.org> X-Trac-Ticket-ID: 1 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-mmusic-media-loopback@tools.ietf.org, hkaplan@acmepacket.com, mmusic@ietf.org X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111122084311.21A7A21F8D1A@ietfa.amsl.com> Resent-Date: Tue, 22 Nov 2011 00:43:10 -0800 (PST) Resent-From: trac+mmusic@trac.tools.ietf.org X-Mailman-Approved-At: Tue, 22 Nov 2011 00:52:42 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] [mmusic] #1: How to reject a loopback offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 08:43:12 -0000 #1: How to reject a loopback offer There is an inconsistency and confusion around how to "reject" a loopback SDP offer. Two comments were received regarding this: ------------------- From Magnus: Section 5.4: If an answerer wishes to accept the loopback request it MUST include both the loopback mode and loopback type attribute in the answer. When a stream is offered with the loopback-source attribute, the corresponding stream in the response MUST be loopback-mirror and vice versa, provided that answerer is capable of supporting the requested loopback-type. This seems to be in partial conflict with 5.4.1. As my impression of the above, is that if you don't want to accept, you don't include the attributes. But 5.4.1 says that it should be included but the port set to 0. ------------------- From Miguel: The note at the end of Section 10.3 reads: NOTE: Loopback request may be rejected by either not including the loopback mode attribute (for backward compatibility) or setting the media port number to zero, or both, in the response. First, I don't like this note here, because it may induce to double specification, specially since you have Section 5.4 that describes how to reject a loopback request. And actually, here you have double incongruent specification. Section 5.4.1 only offers one mechanism for rejecting a session: setting the port to zero like in regular SDP. Nothing is written about rejecting a session by not including the loopback mode attribute. Not including a loopback mode attribute in the answer is not a rejection, it is merely a session with no support for the loopback feature, but the session is established. I recommend to delete this note. -- --------------------------+------------------------------------------------ Reporter: hkaplan@… | Owner: draft-ietf-mmusic-media-loopback@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: media- | Version: 1.0 loopback | Keywords: Severity: In WG Last | Call | --------------------------+------------------------------------------------ Ticket URL: mmusic From trac+mmusic@trac.tools.ietf.org Tue Nov 22 00:47:57 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8821021F8D4D for ; Tue, 22 Nov 2011 00:47:57 -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 qZjZjxjvAzRR for ; Tue, 22 Nov 2011 00:47:55 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6D79321F8D43 for ; Tue, 22 Nov 2011 00:47:55 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RSm1C-0006qT-M4; Tue, 22 Nov 2011 03:47:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mmusic issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: hkaplan@acmepacket.com X-Trac-Project: mmusic Date: Tue, 22 Nov 2011 08:47:54 -0000 X-URL: http://tools.ietf.org/mmusic/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mmusic/trac/ticket/2 Message-ID: <063.2ea57b41e0be5050c487b56fc2e0d848@trac.tools.ietf.org> X-Trac-Ticket-ID: 2 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hkaplan@acmepacket.com, mmusic@ietf.org X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Tue, 22 Nov 2011 00:52:43 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] [mmusic] #2: Rules for Answerer payload type selection X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 08:47:58 -0000 #2: Rules for Answerer payload type selection From Magnus: Section 5.4 I am missing clear rules for the cases when I might exclude payload types from loopback-mode attributes compared to the m= lines. Are this only the loopback payload types? What happens if I exclude a regular media payload format? -- -----------------------------+------------------------ Reporter: hkaplan@… | Owner: hkaplan@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: media-loopback | Version: 1.0 Severity: In WG Last Call | Keywords: -----------------------------+------------------------ Ticket URL: mmusic From trac+mmusic@trac.tools.ietf.org Tue Nov 22 00:49:29 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D4721F8B28 for ; Tue, 22 Nov 2011 00:49:29 -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 vlhKW2OwwIbv for ; Tue, 22 Nov 2011 00:49:28 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC3421F8D53 for ; Tue, 22 Nov 2011 00:49:24 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RSm2d-0001NU-Mr; Tue, 22 Nov 2011 03:49:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mmusic issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: hkaplan@acmepacket.com X-Trac-Project: mmusic Date: Tue, 22 Nov 2011 08:49:23 -0000 X-URL: http://tools.ietf.org/mmusic/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/mmusic/trac/ticket/3 Message-ID: <063.c6ad2ca26b75b2c4a024f9648d322815@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hkaplan@acmepacket.com, mmusic@ietf.org X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Tue, 22 Nov 2011 00:52:43 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] [mmusic] #3: Packet size and fragmentation avoidance X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 08:49:29 -0000 #3: Packet size and fragmentation avoidance From Magnus: Section 7.1: The packet expansion of the encapsulated format I think needs better discussion. I think one needs to first recommend PMTU discovery. Secondly I think it is likely worth discussing when the loopback source should reduce the packet sizes to avoid fragmentation versus the need to measure that size in the forward link and thus causing fragmentation. -- -----------------------------+------------------------ Reporter: hkaplan@… | Owner: hkaplan@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: media-loopback | Version: 1.0 Severity: In WG Last Call | Keywords: -----------------------------+------------------------ Ticket URL: mmusic From finlayson@live555.com Sat Nov 26 11:53:34 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A0921F8B8E for ; Sat, 26 Nov 2011 11:53:34 -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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1vbVjJ3V-Cf for ; Sat, 26 Nov 2011 11:53:33 -0800 (PST) Received: from ns.live555.com (ns.live555.com [4.79.217.242]) by ietfa.amsl.com (Postfix) with ESMTP id EE22321F8B10 for ; Sat, 26 Nov 2011 11:53:33 -0800 (PST) Received: from [127.0.0.1] (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.14.4/8.14.4) with ESMTP id pAQJs1iL000114 for ; Sat, 26 Nov 2011 11:54:01 -0800 (PST) (envelope-from finlayson@live555.com) From: Ross Finlayson Content-Type: multipart/alternative; boundary="Apple-Mail=_DD38F68F-4637-4AF0-BCAB-BE176A9DD284" Date: Sat, 26 Nov 2011 11:53:33 -0800 Message-Id: To: mmusic@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [MMUSIC] Question about the various "range-spec"s defined for RTSP 2.0 (and RTSP 1.0) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 19:53:34 -0000 --Apple-Mail=_DD38F68F-4637-4AF0-BCAB-BE176A9DD284 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In "draft-ietf-mmusic-rfc2326bis-28" (and preceding), a "npt-range-spec" = is defined as npt-range-spec =3D ( npt-time "-" [ npt-time ] ) / ( "-" = npt-time ) (ditto for "smtp-range-spec" and "utc-range-spec"). This suggests that the following are valid: npt =3D -now npt =3D -12.34 What are these supposed to mean (especially given that - in section 4.5 = - you say that "Negative values are not defined")? Ross Finlayson Live Networks, Inc. http://www.live555.com/ --Apple-Mail=_DD38F68F-4637-4AF0-BCAB-BE176A9DD284 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii In = "draft-ietf-mmusic-rfc2326bis-28" (and preceding), a "npt-range-spec" is = defined as
= npt-range-spec =3D ( npt-time "-" [ npt-time ] ) / ( "-" npt-time = )
(ditto for "smtp-range-spec" and = "utc-range-spec").

This suggests that the = following are valid:
npt =3D -now
npt =3D = -12.34

What are these supposed to mean = (especially given that - in section 4.5 - you say that "Negative values = are not defined")?

Ross = Finlayson
Live Networks, Inc.
http://www.live555.com/=

= --Apple-Mail=_DD38F68F-4637-4AF0-BCAB-BE176A9DD284-- From shinji.okumura@softfront.jp Wed Nov 30 01:34:28 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873E721F85AE for ; Wed, 30 Nov 2011 01:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.268 X-Spam-Level: X-Spam-Status: No, score=-99.268 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_64=0.6, RELAY_IS_221=2.222, 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 mTJU5HAcB4A0 for ; Wed, 30 Nov 2011 01:34:28 -0800 (PST) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by ietfa.amsl.com (Postfix) with ESMTP id BA0A621F8610 for ; Wed, 30 Nov 2011 01:34:26 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id B1153428031 for ; Wed, 30 Nov 2011 18:34:24 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2G98aVPqcmtE for ; Wed, 30 Nov 2011 18:34:24 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id C1A5A42802D for ; Wed, 30 Nov 2011 18:34:23 +0900 (JST) From: OKUMURA Shinji To: mmusic@ietf.org Date: Wed, 30 Nov 2011 18:34:27 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.70 (WinNT,502) In-Reply-To: <20111024175730.13367.80904.idtracker@ietfa.amsl.com> References: <20111024175730.13367.80904.idtracker@ietfa.amsl.com> Message-Id: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 09:34:28 -0000 Hi, I have some questions concerning draft-ietf-mmusic-rfc4566bis-04. [Page 25] "If the sub-field is "udp" the sub-fields MUST reference a media type describing the format under the "audio", "video", "text", "application", or "message" top-level media types. The media type registration SHOULD define the packet format for use with UDP transport." Q1. In this document, there are some "media type", "top-level media content types", "top-level content type" and "top-level media types". Which do these mean "MIME media type" or "SDP media type"? Or do the both of two have the same meaning? I think these are ambiguous expressions. Q2. As for the "audio", "video", "text", "application", or "message" top-level media types, where is the definition of the packet format for use with UDP transport? Why is it necessary for new media types? [Page 36] 8.2.3. Media Formats ("fmt") "For the "udp" protocol, new formats SHOULD be registered. Use of an existing media subtype for the format is encouraged. If no media subtype exists, it is RECOMMENDED that a suitable one be registered through the IETF process [RFC4288] by production of, or reference to, a standards-track RFC that defines the transport protocol for the format." Q3. When a new media format(such as t38) is registered, why should we define a new format for "udp" protocol? IMHO all media format don't need the "udp" protocol. Regards, Shinji internet-drafts@ietf.org Mon, 24 Oct 2011 10:57:30 -0700 >A New Internet-Draft is available from the on-line Internet-Drafts >directories. This draft is a work item of the Multiparty Multimedia >Session Control Working Group of the IETF. > > Title : SDP: Session Description Protocol > Author(s) : Mark Handley > Van Jacobson > Colin Perkins > Ali Begen > Filename : draft-ietf-mmusic-rfc4566bis-04.txt > Pages : 49 > Date : 2011-10-24 > > This memo defines the Session Description Protocol (SDP). SDP is > intended for describing multimedia sessions for the purposes of > session announcement, session invitation, and other forms of > multimedia session initiation. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4566bis-04.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-mmusic-rfc4566bis-04.txt From iss@ieee.org Wed Nov 30 07:18:57 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57AE621F8B48; Wed, 30 Nov 2011 07:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, 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 v3hIP4Mun1wg; Wed, 30 Nov 2011 07:18:56 -0800 (PST) Received: from nesono.com (nesono.com [85.214.71.234]) by ietfa.amsl.com (Postfix) with ESMTP id 9299421F87D6; Wed, 30 Nov 2011 07:18:53 -0800 (PST) Received: from faui7rob7.informatik.uni-erlangen.de (faui7rob7.informatik.uni-erlangen.de [131.188.37.137]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: iss@nesono.com) by nesono.com (Postfix) with ESMTPSA id 065102B8008; Wed, 30 Nov 2011 16:18:27 +0100 (CET) From: Jochen Issing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Nov 2011 16:18:26 +0100 Message-Id: <63CCC37C-D80A-46B9-83CB-DB78989F6018@ieee.org> To: payload@ietf.org, mmusic@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 15:18:57 -0000 Dear experts, I need to double-apologize before posting our findings: 1) for cross-posting, as I do not know, where this issue has its exact = home, which is hopefully not a response killer. 2) for the long mail, even though I tried to keep it short. Now, here's the actual request: We are referring to RFC3640 SDP fields only, as this is most often the = stumbling block. Let's use the following example: m=3Daudio 49170 RTP/AVP 96 a=3Drtpmap:96 mpeg4-generic/48000/2 a=3Dfmtp:96 streamtype=3D5; profile-level-id=3D15; mode=3DAAC-hbr; = config=3D1190; sizeLength=3D13; indexLength=3D3; indexDeltaLength=3D3; = constantDuration=3D1024 The fields of interest are in the fmtp line: 'profile-level-id' and = 'config'. In contrast to other codecs, e.g. G.XXX, AAC integrates many different = types of sub codecs, which are identified using the Audio Object Type = (AOT). The AOT and some additional (codec internal) information is = stored in the Audio Specific Config (ASC), which is conveyed in the = 'config' field. The 'profile-level-id' points to a profile with a certain level. The = profile comprises a set of one or more AOTs and the level restricts the = stream to a maximum sample rate and/or number channels. The = profile-level-ids, as specified in ISO 14496-3, are partly hierarchical = and most often ambiguous. Suppose the classic SIP use case that two clients want to exchange their = codec capabilities. The first client specifies some payload types in the SDP part of SIP = INVITE which can differ in their profile-level-id and/or config. For instance, client bob supports AAC-LC, HE-AAC and HE-AACv2. To signal = these codecs/AOTs he could either indicate all formats with the same = profile-level-id (e.g., 48), which includes all these AOTs or he could = specify profile-level-ids, that are most 'narrow' to the actual = specified AOT or he could even mix this principle. On the other hand, the ASC might use implicit signaling, explicit = backwards-compatible, or explicit non-backwards-compatible. Bobs main problem would be to determine, whether the profile-level-id = was chosen to really identify the necessary (and applied) AAC AOTs or if = he could rely on the ASC or if the profile-level-id was just brawling = about the encoders feature. To clean up this mess of opportunities, we would like to specify a = non-ambiguous way to utilize the profile-level-id and config fields = appropriately and provide a guide on how to accomplish clean and easier = signalization and thus improve interoperability. But first of all we would like to make sure, that you agree to this = problem statement or do we miss something here? Comments are as always highly appreciated. Best Regards, --=20 jochen