From zeevvax@microsoft.com Tue Mar 31 10:04:47 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BB063A68BA for ; Tue, 31 Mar 2009 10:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.927 X-Spam-Level: X-Spam-Status: No, score=-7.927 tagged_above=-999 required=5 tests=[AWL=-1.871, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwU9e2ORuEIK for ; Tue, 31 Mar 2009 10:04:45 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id E7E1E3A6894 for ; Tue, 31 Mar 2009 10:04:44 -0700 (PDT) Received: from tk5-exmlt-c102.redmond.corp.microsoft.com (157.54.24.67) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Tue, 31 Mar 2009 10:05:44 -0700 Received: from NA-EXMSG-C111.redmond.corp.microsoft.com ([157.54.61.138]) by tk5-exmlt-c102.redmond.corp.microsoft.com ([157.54.24.67]) with mapi; Tue, 31 Mar 2009 10:05:43 -0700 From: Zeev Vax To: VAN CAENEGEM Tom , Peilin YANG , "Bill Ver Steeg (versteb)" , "Ali C. Begen (abegen)" Date: Tue, 31 Mar 2009 10:05:42 -0700 Thread-Topic: Revised text of the proposal for describing the functionality of Rate Adaptation Thread-Index: AcmxKmkjywEGps37TtKkFV/sR43QLwAGMWpwADa24jA= Message-ID: <5177B2A348E4B64EAD7D589A027892D96A29EAAC65@NA-EXMSG-C111.redmond.corp.microsoft.com> References: <81B9B88E2F9D574AA5328A85547CDE91E0B8A6@xmb-rtp-21d.amer.cisco.com> <238382595265324EA50F6134BB42DCAF03899A2C@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <238382595265324EA50F6134BB42DCAF03899A2C@FRVELSMBS22.ad2.ad.alcatel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5177B2A348E4B64EAD7D589A027892D96A29EAAC65NAEXMSGC111re_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 01 Apr 2009 05:42:19 -0700 Cc: Tom Taylor , "avt@ietf.org" Subject: Re: [AVT] Revised text of the proposal for describing the functionality of Rate Adaptation X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 17:04:47 -0000 --_000_5177B2A348E4B64EAD7D589A027892D96A29EAAC65NAEXMSGC111re_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 UGxlYXNlIHNlZSBpbmxpbmUuDQoNCg0KDQpaZWV2DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogVkFOIENBRU5FR0VNIFRvbSBbbWFpbHRvOlRvbS5WYW5fQ2FlbmVnZW1A YWxjYXRlbC1sdWNlbnQuYmVdDQpTZW50OiBNb25kYXksIE1hcmNoIDMwLCAyMDA5IDc6MjggQU0N ClRvOiBQZWlsaW4gWUFORzsgQmlsbCBWZXIgU3RlZWcgKHZlcnN0ZWIpOyBBbGkgQy4gQmVnZW4g KGFiZWdlbik7IFplZXYgVmF4DQpDYzogUm9uaSBFdmVuOyBUb20gVGF5bG9yOyBZZS1LdWkgV2Fu ZzsgYXZ0QGlldGYub3JnDQpTdWJqZWN0OiBSRTogUmV2aXNlZCB0ZXh0IG9mIHRoZSBwcm9wb3Nh bCBmb3IgZGVzY3JpYmluZyB0aGUgZnVuY3Rpb25hbGl0eSBvZiBSYXRlIEFkYXB0YXRpb24NCg0K DQoNCkhpIFBlaWxpbiwNCg0KDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gRm9yIHRob3Nl IHRoYXQgY29uY2VybiBlZGl0b3JpYWwgc3R1ZmYsIEkgaGF2ZSBubyBjb21tZW50cyBiYWNrLg0K DQpJIGhhdmUgY29tbWVudHMgb24gdGhyZWUgb2YgeW91ciBzdWdnZXN0ZWQgbW9kaWZpY2F0aW9u IGl0ZW1zLCBhcyBleHBsYWluZWQgYmVsb3cuDQoNCktpbmQgcmVnYXJkcw0KDQpUb20NCg0KDQoN Cg0KDQpJdGVtIDEpIFJNUy1JIG1lc3NhZ2UNCg0KDQoNCllvdSB3cm90ZToNCg0KIkluIHRoZSBS TVMtSSBtZXNzYWdlLCB0aGUgcHJlc2VudCB2YWx1ZXMgb2YgUmVzcG9uc2UgaW5jbHVkZSAwLDEg YW5kIDIuIFRoZSB2YWx1ZSBvZiAwIGluZGljYXRlcyB0aGF0IHRoZSByYXBpZCBzeW5jaHJvbml6 YXRpb24gcmVxdWVzdCBoYXMgYmVlbiByZWplY3RlZC4gTmV2ZXJ0aGVsZXNzLCBpbiB0aGUgUk1T LUkgbWVzc2FnZSB0aGVyZSBpcyBub3QgYSBmaWVsZCB0byBpbmRpY2F0ZSBhIHJlamVjdGVkIHJl YXNvbi4gSW4gbXkgcG9pbnQgb2YgdmlldywgdHQgaXMgZWFzaWVyIGZvciBSUiB0byB1bmRlcnN0 YW5kIHRoZSByZWplY3RlZCByZWFzb24gaWYgdGhlcmUgaXMgYSBmaWVsZCBvZiByZWFzb24uIFdo YXQncyBtb3JlLCBpdCBpcyBjb252ZW5pZW50IHRvIG1ha2Ugc3RhdGlzdGljcyByZXBvcnQuDQoN Cg0KDQpUaGUgZm9sbG93aW5nIEZpZ3VyZSBpcyBteSBwcm9wb3NhbC4gICguLikgIg0KDQoNCg0K VE9NIDogaW4gYW55IGNhc2UgdGhlIG1lc3NhZ2UgZm9ybWF0cyB3aWxsIGJlIHJldmlzZWQgdG8g ZGVzY3JpYmUgcGFyYW1ldGVycyBhcyBtdWNoIGFzIHBvc3NpYmxlIGFuZC9vciB1c2VmdWwgYnkg bWVhbnMgb2Yob3B0aW9uYWwpIFRMViBmaWVsZHMuIEkgYmVsaWV2ZSBCaWxsIHdpbGwgbWFrZSBh IHByb3Bvc2FsIHNvb24uDQoNCkkgdGhpbmsgdGhlICJjYXVzZSBvZiByZWplY3Rpb24iIG1heSBi ZSBzdWNoIGEgVExWIGZpZWxkLCB3aGVuIHRoZSBSUyBpbmRlZWQgcmVqZWN0cyB0aGUgQnVyc3Qg UmVxdWVzdC4gSG93ZXZlciwgSSB0aGluayB0aGF0IG1heSB3ZWxsIGJlIGEgdmVuZG9yLXNwZWNp ZmljIGZpZWxkIChmb3Igd2hpY2ggd2UgbmVlZCBhICJ0eXBlIiBjbGFzc2lmaWVyKSwgYXMgdGhl cmUgYXJlIG1hbnkgcmVhc29ucyB3aHkgYSByZXF1ZXN0IGlzIG5vdCBob25vcmVkLCBidXQgdG8g bGlzdCB0aGVtIHdvdWxkIElNTyBiZSBvdXQgb2Ygc2NvcGUgb2YgdGhpcyBkcmFmdC4gU28sIHRo ZSBxdWVzdGlvbiBpczogZG8gd2UgZGVmaW5lIGEgVHlwZSBmb3IgYSBUTFYgZXh0ZW5zaW9uIHRo YXQgd2UgY2FsbCBlLmcuICJyZWFzb24gb2YgcmVqZWN0aW9uIiBvciBkbyB3ZSBqdXN0IHN0aWNr IHRvIGEgVHlwZSB0aGF0IG9ubHkgbWVhbnMgIiB2ZW5kb3Igc3BlY2lmaWMiLiBJIHRoaW5rIGlu IGJvdGggY2FzZXMsIGFuIFJSIGFuZCBhIFJTIG9mIGEgZGlmZmVyZW50IHZlbmRvciB3aWxsIG5v dCB1bmRlcnN0YW5kIGVhY2gtb3RoZXIsIHNvIHdlIG1heSB3ZWxsIG1ha2UgaXQgdmVyeSBnZW5l cmljIGFuZCBvbmx5IGRlZmluZSBhIFRMViAidHlwZSIgdGhhdCBtZWFucyAiIHZlbmRvciBzcGVj aWZpYyINCg0KDQoNCltaZWV2IFZheF0gV2Ugc3RpbGwgbmVlZCB0byBkaXNjdXNzIHRoZSBleGFj dCBiYWxhbmNlIGJldHdlZW4gVExWIGFuZCBmaXhlZCBmaWVsZHMuDQoNCg0KDQoNCg0KDQoNCkl0 ZW0gMikgU2VjdGlvbiA2LjI6IE1lc3NhZ2UgZmxvd3MNCg0KDQoNCiAgIDMuICBVcGRhdGVkIFJl cXVlc3Q6IFRoZSBSUiBNQVkgc2VuZCBhIG5ldyBSTVMtUiBtZXNzYWdlIHdpdGggYSBkaWZmZXJl bnQNCg0KICAgICAgIHZhbHVsZSBvZiB0aGUgZmllbGQgTWF4IFJlY2VpdmUgQml0cmF0ZS4gVGhl IFJTIE1BWSB1c2UgdGhpcyB1cGRhdGVkDQoNCiAgICAgICBiaXRyYXRlIGZvciBzZW5kaW5nIHRo ZSBidXJzdCwgb3IgcmVmaW5lIHRoZSB2YWx1ZSBhbmQgdXNlIHRoZSByZWZpbmVkDQoNCiAgICAg ICB2YWx1ZSBmb3Igc2VuZGluZyB0aGUgYnVyc3QuIEluIGFueSBvZiB0aGUgY2FzZXMsIHRoZSBS UyBNQVkgc2VuZCBhbg0KDQogICAgICAgUk1TLUkgdG8gaW5kaWNhdGUgdGhlIGJpdHJhdGUgYmVp bmcgdXNlZC4gSW4gY2FzZSB0aGUgUlMgcmVjZWl2ZXMNCg0KICAgICAgIG11bHRpcGxlIFJNUy1S IG1lc3NhZ2VzIGF0IHRoZSBzYW1lIHRpbWUsIHRoZSBsYXRlc3QgUk1TLVIgbWVzc2FnZSwNCg0K ICAgICAgIGFzIGluZGljYXRlZCBieSB0aGUgdmFsdWUgb2YgdGhlIE1TTiBmaWVsZCBpbiB0aGUg Uk1TLVIgbWVzc2FnZSwgTVVTVA0KDQogICAgICAgYmUgdXNlZCwgYW5kIG90aGVyIFJNUy1SIG1l c3NhZ2VzIFNIT1VMRCBiZSBkaXNjYXJkZWQuDQoNCg0KDQpUT006IEkgc3VnZ2VzdCB0byBkZWxl dGUgIiBJbiBjYXNlIHRoZSBSUyByZWNlaXZlcw0KDQogICAgICAgbXVsdGlwbGUgUk1TLVIgbWVz c2FnZXMgYXQgdGhlIHNhbWUgdGltZSwgdGhlIGxhdGVzdCBSTVMtUiBtZXNzYWdlLA0KDQogICAg ICAgYXMgaW5kaWNhdGVkIGJ5IHRoZSB2YWx1ZSBvZiB0aGUgTVNOIGZpZWxkIGluIHRoZSBSTVMt UiBtZXNzYWdlLCBNVVNUDQoNCiAgICAgICBiZSB1c2VkLCBhbmQgb3RoZXIgUk1TLVIgbWVzc2Fn ZXMgU0hPVUxEIGJlIGRpc2NhcmRlZC4iDQoNCltaZWV2IFZheF0gSSBhZ3JlZSB3aXRoIFRvbSwg YW5kIGhpcyBjb21tZW50IGlzIGFsaWduIHdpdGggd2hhdCB3ZSBhZ3JlZWQgaW4gdGhlIGxhc3Qg bWVldGluZy4gQW55IGZvbGxvd2luZyBSTVMtUiBtZXNzYWdlIG1pZ2h0IGJlIHVzZWQgYnkgdGhl IFJTLCBidXQgaXQgaXMgb25seSByZWNvbW1lbmRhdGlvbi4NCg0KDQoNClRoaXMgaXMgYmVjYXVz ZSBhbiBSUyBtYXkgbm90IHN1cHBvcnQgdGhlIGZlYXR1cmUgb2YgZmxleGlibGUgYnVyc3QgcmF0 ZSBhZGFwdGF0aW9uIHVuZGVyIGNvbnRyb2wgb2YgdGhlIFJSLiBIZW5jZSBpbiB0aGF0IGNhc2Ug aXRzIGltcGxlbWVudGF0aW9uIG1heSBiZSBzdWNoIHRoYXQgaXQgY2xhc3NpZmllcyBpbmNvbWlu ZyBSTVMtUiBiYXNlZCBvbiB2ZXJzaW9uIG51bWJlciBhbmQgaW50ZXJuYWwgc3RhdGUuIFdoZW4g dGhlIFJTICBoYXMgYWxyZWFkeSBhbiBhY3RpdmUgdGhyZWFkIGZvciBhIGNlcnRhaW4gUlIgYW5k IGNlcnRhaW4gU1NNIChhIHBlbmRpbmcgb3IgYWN0aXZlIGJ1cnN0IHJlcXVlc3QpICwgdGhlIFJT IGNhbiBzaW1wbHkgZHJvcCBhbnkgbmV3IFJNUy1SICh3aXRoIGEgaGlnaGVyIG1lc3NhZ2Ugc2Vx dWVuY2UgbnVtYmVyKSB0cmFuc21pdHRlZCBieSB0aGF0IHNwZWNpZmljIFJSIGZvciB0aGF0IHNw ZWNpZmljIHNzbS4NCg0KDQoNCg0KDQoNCg0KDQoNCkl0ZW0gMykgU2VjdGlvbiBvbiBSTVMtUiBt ZXNzYWdlIChzZWN0aW9uIDcuMSkNCg0KDQoNCiAgICAgIE1lc3NhZ2UgU2VxdWVuY2UgTnVtYmVy ICg4IGJpdHMpIDogIER1cmluZyByYXBpZCBzeW5jaHJvbml6YXRpb24sDQoNCiAgICAgIHRoZSBS TVMtUiBtZXNzYWdlKHMpIG1heSBiZSBzZW50IG1vcmUgdGhhbiBvbmNlLiAgVGhlIGZpcnN0IFJN Uy1SDQoNCiAgICAgIG1lc3NhZ2UgU0hBTEwgaGF2ZSBhbiBNU04gdmFsdWUgb2YgMC4gSWYgYSBu ZXcgaW5mb3JtYXRpb24gaXMgY29udmV5ZWQNCg0KICAgICAgaW4gYSBuZXcgUk1TLVIgbWVzc2Fn ZSwgdGhlIE1TTiB2YWx1ZSBTSEFMTCBiZSBpbmNyZW1lbnRlZCBieSBvbmUuDQoNCg0KDQpUT006 IGFuIFJNUy1SIG1lc3NhZ2UgbWF5IGFsc28gYmUgc2VudCBtdWx0aXBsZSB0aW1lcyB3aXRoIHRo ZSBzYW1lIGluZm9ybWF0aW9uIGZvciByZWR1bmRhbmN5IHB1cnBvc2VzLiBGb3IgdGhhdCByZWFz b24sIEkgc3VnZ2VzdCB3ZSBoYXZlIGluc3RlYWQgb2YgIiBJZiBhIG5ldyBpbmZvcm1hdGlvbiBp cyBjb252ZXllZCBpbiBhIG5ldyBSTVMtUiBtZXNzYWdlLCB0aGUgTVNOIHZhbHVlIFNIQUxMIGJl IGluY3JlbWVudGVkIGJ5IG9uZSAiLCB3ZSBhcmUgbW9yZSBzcGVjaWZpYyBhbmQgYWxpZ24gd2l0 aCB0aGUgcGhyYXNpbmcgYXMgdXNlZCBmb3IgdGhlIFJNUy1JIG1lc3NhZ2U6DQoNCiJUaGlzIHZh bHVlIFNIQUxMIE5PVCBiZSBjaGFuZ2VkIGlmIHRoZSBzYW1lIFJNUy1SIG1lc3NhZ2UgaXMgc2Vu dCB0byB0aGUgc2FtZSBSUyBtdWx0aXBsZSB0aW1lcyBmb3IgcmVkdW5kYW5jeSBwdXJwb3Nlcy4g SWYgYSBuZXcgaW5mb3JtYXRpb24gaXMgY29udmV5ZWQgaW4gYSBuZXcgUk1TLVIgbWVzc2FnZSwg dGhlIE1TTiB2YWx1ZSBTSEFMTCBiZSBpbmNyZW1lbnRlZCBieSBvbmUiDQoNCg0KDQpbWmVldiBW YXhdIEJvdGggc291bmQgcmVhc29uYWJsZSB0byBtZQ0KDQoNCg0KDQoNCg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBQZWlsaW4gWUFORyBbbWFpbHRvOnlhbmdwZWlsaW5A aHVhd2VpLmNvbV0NCg0KU2VudDogbWFhbmRhZyAzMCBtYWFydCAyMDA5IDEzOjIwDQoNClRvOiBC aWxsIFZlciBTdGVlZyAodmVyc3RlYik7IEFsaSBDLiBCZWdlbiAoYWJlZ2VuKTsgVkFOIENBRU5F R0VNIFRvbTsgemVldnZheEBtaWNyb3NvZnQuY29tDQoNCkNjOiBSb25pIEV2ZW47IFRvbSBUYXls b3I7IFllLUt1aSBXYW5nDQoNClN1YmplY3Q6IFJldmlzZWQgdGV4dCBvZiB0aGUgcHJvcG9zYWwg Zm9yIGRlc2NyaWJpbmcgdGhlIGZ1bmN0aW9uYWxpdHkgb2YgUmF0ZSBBZGFwdGF0aW9uDQoNCg0K DQpEZWFyIEJpbGwsIEFsaSwgVG9tIGFuZCBaZWV2LA0KDQoNCg0KSSBhZGRlZCBzb21lIHJldmlz ZWQgdGV4dCBvZiB0aGUgcHJvcG9zYWwgZm9yIGRlc2NyaWJpbmcgdGhlIGZ1bmN0aW9uYWxpdHkg b2YgUmF0ZSBBZGFwdGF0aW9uIGZvciB0aGUgQnVyc3QuIFBsZWFzZSBzZWUgdGhlIGF0dGFjaGVk IGZpbGUuIFRoZSByZXZpc2VkIHRleHQgbWFpbmx5IGludm9sdmVzIGluIGEgbmV3IHN0ZXAgMywg cGFydCBvZiBzdGVwIDEsICI3LjEuIFJNUyBSZXF1ZXN0IiBhbmQgRmlndXJlIDMgZGVwaWN0cyBh biBleGFtcGxlIG9mIG1lc3NhZ2luZyBmbG93Lg0KDQpJIGFtIHZlcnkgZ2xhZCB0byBkaXN1Y3Nz IGl0IHdpdGggeW91LiBJbiB0aGUgYXR0YWNobWVudCBmaWxlIGl0IGFsc28gaW5jbHVkZXMgYSBs aXR0bGUgcmV2aXNpb24uIFBsZWFzZSBzZWUgaWYgbm90IHN1aXRhYmxlIGZvciByZXZpc29uLg0K DQoNCg0KSW4gYWRkaXRpb24sIEkgdGhpbmssIHRoZSBmb2xsb3dpbmcgc3VnZ2VzdGlvbnMgYWxz byBuZWVkIHRvIGJlIGRpc2N1c3NlZC4NCg0KDQoNCjEpIElHTVANCg0KDQoNCkluIHRoZSBkcmFm dCBsaWtlIHRoZSBmb2xsb3dpbmcgdGV4dCBpdCBvbmx5IGRlc2NyaWJlcyB0aGUgSUdNUCBiYXNl ZCBvbiBJUHY0Lg0KDQoNCg0KIldoZW4gYSByZWNlaXZlciB3aXNoZXMgdG8gam9pbiB0aGUgc2Ft ZSBtdWx0aWNhc3Qgc2Vzc2lvbiwgaW5zdGVhZCBvZiBzaW1wbHkgaXNzdWluZyAgIGFuIEludGVy bmV0IEdyb3VwIE1hbmFnZW1lbnQgUHJvdG9jb2wgKElHTVApIFtSRkMzMzc2XSBKb2luIG1lc3Nh Z2UsIGl0IHNlbmRzIGEgcmVxdWVzdCB0byB0aGUgZmVlZGJhY2sgdGFyZ2V0IGFkZHJlc3MgZm9y IHRoZSBzZXNzaW9uIGFza2luZyBmb3IgdGhlIFJlZmVyZW5jZSBJbmZvcm1hdGlvbi4gIg0KDQoN Cg0KRG8geW91IHRoaW5rIGl0IGlzIG5lY2Vzc2FyeSB0byBjb25zaWRlciBNTEQgcHJvdG9jb2wg YmFzZWQgb24gSVB2NiBpbiB0aGUgZG9jdW1lbnQgYXMgZm9sbG93cz8NCg0KDQoNCiJXaGVuIGEg cmVjZWl2ZXIgd2lzaGVzIHRvIGpvaW4gdGhlIHNhbWUgbXVsdGljYXN0IHNlc3Npb24sIGluc3Rl YWQgb2Ygc2ltcGx5IGlzc3VpbmcgICBhbiBJbnRlcm5ldCBHcm91cCBNYW5hZ2VtZW50IFByb3Rv Y29sIChJR01QKSBbUkZDMzM3Nl0gb3IgTXVsdGljYXN0IExpc3RlbmVyIERpc2NvdmVyeSAoTUxE KSBbUkZDIDM4MTBdIEpvaW4gbWVzc2FnZSwgaXQgc2VuZHMgYSByZXF1ZXN0IHRvIHRoZSBmZWVk YmFjayB0YXJnZXQgYWRkcmVzcyBmb3IgdGhlIHNlc3Npb24gYXNraW5nIGZvciB0aGUgUmVmZXJl bmNlIEluZm9ybWF0aW9uLiAiDQoNCg0KDQoyKSBSTVMtSSBtZXNzYWdlDQoNCg0KDQpJbiB0aGUg Uk1TLUkgbWVzc2FnZSwgdGhlIHByZXNlbnQgdmFsdWVzIG9mIFJlc3BvbnNlIGluY2x1ZGUgMCwx IGFuZCAyLiBUaGUgdmFsdWUgb2YgMCBpbmRpY2F0ZXMgdGhhdCB0aGUgcmFwaWQgc3luY2hyb25p emF0aW9uIHJlcXVlc3QgaGFzIGJlZW4gcmVqZWN0ZWQuIE5ldmVydGhlbGVzcywgaW4gdGhlIFJN Uy1JIG1lc3NhZ2UgdGhlcmUgaXMgbm90IGEgZmllbGQgdG8gaW5kaWNhdGUgYSByZWplY3RlZCBy ZWFzb24uIEluIG15IHBvaW50IG9mIHZpZXcsIHR0IGlzIGVhc2llciBmb3IgUlIgdG8gdW5kZXJz dGFuZCB0aGUgcmVqZWN0ZWQgcmVhc29uIGlmIHRoZXJlIGlzIGEgZmllbGQgb2YgcmVhc29uLiBX aGF0J3MgbW9yZSwgaXQgaXMgY29udmVuaWVudCB0byBtYWtlIHN0YXRpc3RpY3MgcmVwb3J0Lg0K DQoNCg0KVGhlIGZvbGxvd2luZyBGaWd1cmUgaXMgbXkgcHJvcG9zYWwuDQoNCg0KDQogICAgICAw ICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAg ICAzDQoNCiAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMQ0KDQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCiAgICAgfCAgICAgIE1TTiAg ICAgIHwgICBSZXNwb25zZSAgICB8ICAgICAgUmVhc29uICAgfCAgICAgUnN2ZC4gICAgIHwNCg0K ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KDQogICAgIHwgICAgICAgIEV4dGVuZGVkIFJUUCBTZXFudW0gb2YgdGhl IEZpcnN0IEJ1cnN0IFBhY2tldCAgICAgICAgICB8DQoNCiAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KICAgICB8 ICAgICAgICAgICAgICAgICAgIEVhcmxpZXN0IElHTVAgSm9pbiBUaW1lICAgICAgICAgICAgICAg ICAgICAgfA0KDQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCiAgICAgfCAgICAgICAgICAgICAgIFJhcGlkIFN5 bmNocm9uaXphdGlvbiBEdXJhdGlvbiAgICAgICAgICAgICAgICAgIHwNCg0KICAgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KDQogICAgIHwgICAgICAgICAgICAgICAgICAgICAgIE1heCBCdXJzdCBCaXRyYXRlICAgICAg ICAgICAgICAgICAgICAgICB8DQoNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KDQoNCiAgICAgICAgRmlndXJl IDU6IEZDSSBmaWVsZCBzeW50YXggZm9yIHRoZSBSTVMgSW5mb3JtYXRpb24gbWVzc2FnZQ0KDQoN Cg0KMykgImFuL3RoZSBSVFAgUmVjZWl2ZXIiIGFuZCAiYS90aGUgUmVjZWl2ZXIiDQoNCkluIHRo ZSBkb2N1bWVudCB0aGVyZSBhcmUgbWFueSAiYW4vdGhlIFJUUCBSZWNlaXZlciIgYW5kICJhL3Ro ZSBSZWNlaXZlciIuIERvIHlvdSB0aGluayBpdCBpcyBuZWNlc3NhcnkgdG8ga2VlcCB0aGVzZSB0 ZXJtcyB0byBiZSBjb25zaXN0ZW50IHRocm91Z2hvdXQgdGhlIGRvY3VtZW50PyAgSSByZXZpc2Vk IHRoZW0gYXMgImFuL3RoZSBSVFAgUmVjZWl2ZXIiIGluIHRoZSByZXZpc2VkIHByb3Bvc2FsIHRl eHQuDQoNCg0KDQo0KSAidGhlIGJ1cnN0IiwgImEvdGhlIHVuaWNhc3QgYnVyc3QiLCAiYW4vdGhl IFJUUCBidXJzdCIgYW5kICJ0aGUgUlRQIHVuaWNhc3QgYnVyc3QiDQoNCkluIHRoZSBkb2N1bWVu dCB0aGVyZSBhcmUgbWFueSAidGhlIGJ1cnN0IiwgImEvdGhlIHVuaWNhc3QgYnVyc3QiLCAiYW4v dGhlIFJUUCBidXJzdCIgYW5kICJ0aGUgUlRQIHVuaWNhc3QgYnVyc3QiLiBEbyB5b3UgdGhpbmsg aXQgaXMgbmVjZXNzYXJ5IHRvIGtlZXAgdGhlc2UgdGVybXMgdG8gYmUgY29uc2lzdGVudCB0aHJv dWdob3V0IHRoZSBkb2N1bWVudD8gIEkgcmV2aXNlZCB0aGVtIGFzICJhL3RoZSB1bmljYXN0IGJ1 cnN0IiBpbiB0aGUgcmV2aXNlZCBwcm9wb3NhbCB0ZXh0Lg0KDQoNCg0KNSkgImpvaW5pbmcgdGhl IG11bHRpY2FzdCBzZXNzaW9uIiBhbmQgImpvaW5pbmcgdGhlIG11bHRpY2FzdCBncm91cCINCg0K SW4gdGhlIGRvY3VtZW50IHRoZXJlIGlzIG9ubHkgb25lICJqb2luaW5nIHRoZSBtdWx0aWNhc3Qg Z3JvdXAiLiBJIG1vZGlmaWVkICJqb2luaW5nIHRoZSBtdWx0aWNhc3QgZ3JvdXAiIHRvICJqb2lu aW5nIHRoZSBtdWx0aWNhc3Qgc2Vzc2lvbiINCg0KDQoNCjYpIFRoZSBkZXNjcmlwdGlvbiBvZiAi VXBkYXRlZCBSZXNwb25zZXMiIG9mIHN0ZXAgMyBJbiB0aGUgZG9jdW1lbnQgdGhlcmUgaXMgYSBn ZW5lcmFsIGRlc2NyaXB0aW9uIGZvciAiVXBkYXRlZCBSZXNwb25zZXMiIGFzIGZvbGxvd3MuIFdo ZW4gSSBkaXNjdXNzZWQgd2l0aCBvdXIgZGV2ZWxvcG1lbnQgZW5naW5lcnJzLCBhcyBvbi1uYXRp dmUgZW5nbGlzaCBzcGVha2VycyB0aGV5IHNhaWQgaXQgaXMgbm90IGNvbXBsZXRlbHkgY2xlYXIg dG8gaG93IHRvIGltcGxlbWVudCBpdC4NCg0KDQoNCiAgIjMuICBVcGRhdGVkIFJlc3BvbnNlczog IFJTIG1heSBzZW5kIG1vcmUgdGhhbiBvbmUgUk1TLUkgbWVzc2FnZXMsDQoNCiAgICAgICBlLmcu LCB0byB1cGRhdGUgdGhlIGJ1cnN0IGJpdHJhdGUgaW5mb3JtYXRpb24gd2hlbiB0aGUgYml0cmF0 ZSBpcw0KDQogICAgICAgYWRhcHRlZCBhbmQvb3IgdG8gc2lnbmFsIFJSIGluIHJlYWwgdGltZSB0 byBqb2luIHRoZSBTU00gc2Vzc2lvbi4iDQoNCg0KDQpUaGV5IHNhaWQgdGhlIG9yaWdpbmFsIHRl eHQgZnJvbSB0aGUgZHJhZnQgLSBkcmFmdC1sZXZpbi1hdnQtcnRjcC1idXJzdC0wMCBpcyBlYXNp ZXIgdG8gdW5kZXJzdGFuZC4NCg0KU28gSSBzdWdnZXN0IHRvIGFkZCBhIGxpdHRsZSBkZXNjcmlw dGlvbiBleGFtcGxlIGF0IHRoZSBlbmQgb2YgdGhlIHNlbnNlbmNlLg0KDQoNCg0KVGhlIGZvbGxv d2luZyB0ZXh0IGlzIG15IHByb3Bvc2FsLiBUaGUgbGFzdCBzZW5zZW5jZSBpcyBsYXJnZWx5IGV4 dHJhY3RlZCBmcm9tIHRoZSBkcmFmdCAtIGRyYWZ0LWxldmluLWF2dC1ydGNwLWJ1cnN0LTAwDQoN Cg0KDQogICIzLiAgVXBkYXRlZCBSZXNwb25zZXM6ICBSUyBtYXkgc2VuZCBtb3JlIHRoYW4gb25l IFJNUy1JIG1lc3NhZ2VzLA0KDQogICAgICAgZS5nLiwgdG8gdXBkYXRlIHRoZSB1bmljYXN0IGJ1 cnN0IGJpdHJhdGUgaW5mb3JtYXRpb24gd2hlbiB0aGUgYml0cmF0ZSBpcw0KDQogICAgICAgYWRh cHRlZCBhbmQvb3IgdG8gc2lnbmFsIFJSIGluIHJlYWwgdGltZSB0byBqb2luIHRoZSBTU00gc2Vz c2lvbjsgdG8gbm90aWZ5DQoNCiAgICAgICBSUiB0byBqb2luIHRoZSBtdWx0aWNhc3Qgc2Vzc2lv biB3aGVuIHRoZSB1bmljYXN0IGJ1cnN0IGNhdGNoZXMgdXAgd2l0aA0KDQogICAgICAgdGhlIG9y aWdpbmFsIG11bHRpY2FzdCBzZXNzaW9uLiINCg0KDQoNClJlZ2FyZHMsDQoNClBlaWxpbg0KDQoN Cg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCiBUaGlzIGVtYWlsIGFuZCBp dHMgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFX RUksIHdoaWNoIGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3Nl IGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaGVyZSBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90 YWwgb3IgcGFydGlhbCBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24p IGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpIGlzIHByb2hp Yml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBieSBwaG9uZSBvciBlbWFpbCAgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCEN Cg0KICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCg0KDQotLS0tLSDUrdPKvP4g LS0tLS0NCg0Kt6K8/sjLOiAiQmlsbCBWZXIgU3RlZWcgKHZlcnN0ZWIpIiA8dmVyc3RlYkBjaXNj by5jb20+DQoNCsjVxto6INDHxtrO5SwgyP3UwiAyN8jVLCAyMDA5IMnPzuczOjQzDQoNCtb3zOI6 IFJFOiBIaSBCaWxsIGFuZCBhbGwsDQoNCsrVvP7IyzogUGVpbGluIFlBTkcgPHlhbmdwZWlsaW5A aHVhd2VpLmNvbT4sICJBbGkgQy4gQmVnZW4gKGFiZWdlbikiIDxhYmVnZW5AY2lzY28uY29tPiwg VG9tLlZhbl9DYWVuZWdlbUBhbGNhdGVsLWx1Y2VudC5iZSwgemVldnZheEBtaWNyb3NvZnQuY29t LCBZZS1LdWkgV2FuZyA8eWVrdWl3YW5nQGh1YXdlaS5jb20+DQoNCrOty806IFJvbmkgRXZlbiA8 cm9uLmV2ZW4udGx2QGdtYWlsLmNvbT4sIFRvbSBUYXlsb3IgPHRvbS50YXlsb3JAcm9nZXJzLmNv bT4sICJEYXZlIE9yYW4gKG9yYW4pIiA8b3JhbkBjaXNjby5jb20+LCBhdnRAaWV0Zi5vcmcNCg0K DQoNCj4gUGVpbGluLQ0KDQo+DQoNCj4gSSB0aGluayB3ZSBtYWRlIGdvb2QgcHJvZ3Jlc3Mgb24g dGhlIGRyYWZ0LiBXZSBhbHNvIGhhdmUgc29tZSBvdGhlcg0KDQo+IGZvbGtzIGxvb2tpbmcgYXQg aG93IHRoZSByYXRlIGFkYXB0YXRpb24gaW50ZXJhY3RzIHdpdGggdGhlIHJlc3Qgb2YNCg0KPiB0 aGUgc2lnbmFsaW5nLiBIb3BlZnVsbHkgd2Ugd2lsbCBiZSBhYmxlIHRvIGNsZWFubHkgaW5jb3Jw b3JhdGUgcmF0ZQ0KDQo+IGFkYXB0YXRpb24gaW50byB0aGUgcHJvdG9jb2wuIElmIHlvdSBoYXZl IHNvbWUgc3VnZ2VzdGVkIHRleHQgaW4gdGhhdA0KDQo+IGFyZWEsIHRoYXQgd291bGQgYmUgZ3Jl YXQuDQoNCj4NCg0KPiBCaWxsIFZlclN0ZWVnDQoNCj4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KDQo+IEZyb206IFBlaWxpbiBZQU5HIFttYWlsdG86eWFuZ3BlaWxpbkBodWF3ZWku Y29tXQ0KDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMjUsIDIwMDkgODowNyBQTQ0KDQo+IFRv OiBCaWxsIFZlciBTdGVlZyAodmVyc3RlYik7IEFsaSBDLiBCZWdlbiAoYWJlZ2VuKTsNCg0KPiBU b20uVmFuX0NhZW5lZ2VtQGFsY2F0ZWwtbHVjZW50LmJlOyB6ZWV2dmF4QG1pY3Jvc29mdC5jb207 IFllLUt1aSBXYW5nDQoNCj4gQ2M6IFJvbmkgRXZlbjsgVG9tIFRheWxvcjsgRGF2ZSBPcmFuIChv cmFuKTsgYXZ0QGlldGYub3JnDQoNCj4gU3ViamVjdDogSGkgQmlsbCBhbmQgYWxsLA0KDQo+DQoN Cj4gSGkgQmlsbCBhbmQgYWxsLA0KDQo+DQoNCj4gVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgY29u Y2VybmluZyBIdWF3ZWkncyBkcmFmdC4NCg0KPiBJIGFtIHNvcnJ5IEkgaGF2ZW4ndCBwYXJ0aWNp cGF0ZWQgdGhlIFNGIG1lZXRpbmcgYmVjYXVzZSBJIGhhdmVuJ3QgZ290DQoNCj4gYW4gQW1lcmlj YW4gVmlzYSB0aGlzIHRpbWUuDQoNCj4NCg0KPiBZSyB0b2xkIG1lIGFuIGluZm9ybWFsIHJlc3Vs dCBvZiBicmVhayBzZXNzaW9uIHllc3RlcmRheS4NCg0KPiBOb3cgSSBhbSBjb25zaWRlcmluZyB0 aGUgcmV2aXNlZCB0ZXh0IGZvciBkZXNjcmliaW5nIHRoZSBmdW5jdGlvbmFsaXR5DQoNCj4gb2Yg UmF0ZSBBZGFwdGF0aW9uIGZvciB0aGUgQnVyc3QgdG8gdGhlIGNvbW1vbiBjb252ZXJnaW5nIHNv bHV0aW9uIGFuZA0KDQo+IG90aGVyIHBvc3NpYmxlIGNvbnRyaWJ1dGluZyB0ZXh0Lg0KDQo+DQoN Cj4gUmVnYXJkcywNCg0KPg0KDQo+IFBlaWxpbg0KDQo+DQoNCj4gKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQo+ ICoqDQoNCj4gKioqKioqKioqKioqKioqKioqDQoNCj4gVGhpcyBlbWFpbCBhbmQgaXRzIGF0dGFj aG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZyb20NCg0KPiBIVUFXRUks IHdoaWNoIGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFk ZHJlc3MNCg0KPiBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNv bnRhaW5lZCBoZXJlIGluIGFueSB3YXkNCg0KPiAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQg dG8sIHRvdGFsIG9yIHBhcnRpYWwgZGlzY2xvc3VyZSwNCg0KPiByZXByb2R1Y3Rpb24sIG9yIGRp c3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQNCg0KPiByZWNp cGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlbWFpbCBpbiBlcnJv ciwgcGxlYXNlDQoNCj4gbm90aWZ5IHRoZSBzZW5kZXIgYnkgcGhvbmUgb3IgZW1haWwgIGltbWVk aWF0ZWx5IGFuZCBkZWxldGUgaXQhDQoNCj4NCg0KPiAqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCj4gKioNCg0K PiAqKioqKioqKioqKioqKioqKg0KDQo+DQoNCg0K --_000_5177B2A348E4B64EAD7D589A027892D96A29EAAC65NAEXMSGC111re_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Please see inline.

 

Zeev

 

-----Original Message-----
From: VAN CAENEGEM Tom [mailto:Tom.Van_Caenegem@alcatel-lucent.be]
Sent: Monday, March 30, 2009 7:28 AM
To: Peilin YANG; Bill Ver Steeg (versteb); Ali C. Begen (abegen); Zeev Vax<= br> Cc: Roni Even; Tom Taylor; Ye-Kui Wang; avt@ietf.org
Subject: RE: Revised text of the proposal for describing the functionality = of Rate Adaptation

 

Hi Peilin,

 

Thanks for your comments. For those that concern editorial stuff, I have no comments back.

I have comments on three of your suggested modifica= tion items, as explained below.

Kind regards

Tom

 

 

Item 1) RMS-I message

 

You wrote:

"In the RMS-I message, the present values of Response include 0,1 and 2. The value of 0 indicates that the rapid synchro= nization request has been rejected. Nevertheless, in the RMS-I message there is not = a field to indicate a rejected reason. In my point of view, tt is easier for = RR to understand the rejected reason if there is a field of reason. What's mor= e, it is convenient to make statistics report.

 

The following Figure is my proposal.  (..) &qu= ot;

 

TOM : in any case the message formats will be revis= ed to describe parameters as much as possible and/or useful by means of(optional)= TLV fields. I believe Bill will make a proposal soon.

I think the "cause of rejection" may be s= uch a TLV field, when the RS indeed rejects the Burst Request. However, I think t= hat may well be a vendor-specific field (for which we need a "type" classifier), as there are many reasons why a request is not honored, but to list them would IMO be out of scope of this draft. So, the question is: do = we define a Type for a TLV extension that we call e.g. "reason of rejection" or do we just stick to a Type that only means " vendor specific". I think in both cases, an RR and a RS of a different vendor will not understand each-other, so we may well make it very generic and onl= y define a TLV "type" that means " vendor specific"<= /o:p>

 

[Zeev Vax] We still need to discuss the exact balance between = TLV and fixed fields.

 

 

 

Item 2) Section 6.2: Message flows

 

   3.  Updated Request: The RR MAY s= end a new RMS-R message with a different

       valule of the = field Max Receive Bitrate. The RS MAY use this updated

       bitrate for se= nding the burst, or refine the value and use the refined

       value for send= ing the burst. In any of the cases, the RS MAY send an

       RMS-I to indic= ate the bitrate being used. In case the RS receives

       multiple RMS-R messages at the same time, the latest RMS-R message,

       as indicated b= y the value of the MSN field in the RMS-R message, MUST

       be used, and o= ther RMS-R messages SHOULD be discarded.

 

TOM: I suggest to delete " In case the RS rece= ives

       multiple RMS-R messages at the same time, the latest RMS-R message,

       as indicated b= y the value of the MSN field in the RMS-R message, MUST

       be used, and o= ther RMS-R messages SHOULD be discarded."

[Zeev Vax] I ag= ree with Tom, and his comment is align with what we agreed in the last meeting. Any = following RMS-R message might be used by the RS, but it is only recommendation.

 

This is because an RS may not support the feature o= f flexible burst rate adaptation under control of the RR. Hence in that case = its implementation may be such that it classifies incoming RMS-R based on versi= on number and internal state. When the RS  has already an active thread f= or a certain RR and certain SSM (a pending or active burst request) , the RS can simply drop any new RMS-R (with a higher message sequence number) transmitt= ed by that specific RR for that specific ssm.

 

 

 

 

Item 3) Section on RMS-R message (section 7.1)=

 

      Message Sequence Num= ber (8 bits) :  During rapid synchronization,

      the RMS-R message(s)= may be sent more than once.  The first RMS-R

      message SHALL have a= n MSN value of 0. If a new information is conveyed

      in a new RMS-R messa= ge, the MSN value SHALL be incremented by one.

 

TOM: an RMS-R message may also be sent multiple tim= es with the same information for redundancy purposes. For that reason, I sugge= st we have instead of " If a new information is conveyed in a new RMS-R message, the MSN value SHALL be incremented by one ", we are more spec= ific and align with the phrasing as used for the RMS-I message:

"This value SHALL NOT be changed if the same R= MS-R message is sent to the same RS multiple times for redundancy purposes. If a= new information is conveyed in a new RMS-R message, the MSN value SHALL be incremented by one"

 

[Zeev Vax] Both sound= reasonable to me

 

 

 

-----Original Message-----

From: Peilin YANG [mailto:yangpeilin@huawei.com]

Sent: maandag 30 maart 2009 13:20

To: Bill Ver Steeg (versteb); Ali C. Begen (abegen)= ; VAN CAENEGEM Tom; zeevvax@microsoft.com

Cc: Roni Even; Tom Taylor; Ye-Kui Wang

Subject: Revised text of the proposal for describin= g the functionality of Rate Adaptation

 

Dear Bill, Ali, Tom and Zeev,

 

I added some revised text of the proposal for descr= ibing the functionality of Rate Adaptation for the Burst. Please see the attached= file. The revised text mainly involves in a new step 3, part of step 1, "7.1= . RMS Request" and Figure 3 depicts an example of messaging flow.

I am very glad to disucss it with you. In the attac= hment file it also includes a little revision. Please see if not suitable for revison.

 

In addition, I think, the following suggestions als= o need to be discussed. 

 

1) IGMP

 

In the draft like the following text it only descri= bes the IGMP based on IPv4.

 

"When a receiver wishes to join the same multi= cast session, instead of simply issuing   an Internet Group Management Protocol (IGMP) [RFC3376] Join message, it sends a request to the feedback target address for the session asking for the Reference Information. "=

 

Do you think it is necessary to consider MLD protoc= ol based on IPv6 in the document as follows?

 

"When a receiver wishes to join the same multi= cast session, instead of simply issuing   an Internet Group Management Protocol (IGMP) [RFC3376] or Multicast Listener Discovery (MLD) [RFC 3810] = Join message, it sends a request to the feedback target address for the session asking for the Reference Information. "

 

2) RMS-I message

 

In the RMS-I message, the present values of Respons= e include 0,1 and 2. The value of 0 indicates that the rapid synchronization request has been rejected. Nevertheless, in the RMS-I message there is not = a field to indicate a rejected reason. In my point of view, tt is easier for = RR to understand the rejected reason if there is a field of reason. What's mor= e, it is convenient to make statistics report.

 

The following Figure is my proposal. 

 

      0            &n= bsp;      1            &n= bsp;      2            &n= bsp;      3

      0 1 2 3 4 5 6 7 8 9 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |    &= nbsp; MSN      |   Response    |      Reason   |    = ; Rsvd.     |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |        Extended RTP Seqnum of the Firs= t Burst Packet          |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |            &n= bsp;      Earliest IGMP Join Time            = ;         |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |             &= nbsp; Rapid Synchronization Duration           &= nbsp;      |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |            &n= bsp;          Max Burst Bitrate           &n= bsp;           |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

        Figure 5= : FCI field syntax for the RMS Information message

 

3) "an/the RTP Receiver" and "a/the Receiver"

In the document there are many "an/the RTP Receiver" and "a/the Receiver". Do you think it is necessary= to keep these terms to be consistent throughout the document?  I revised = them as "an/the RTP Receiver" in the revised proposal text.

 

4) "the burst", "a/the unicast burst", "an/the RTP burst" and "the RTP unicast burst&q= uot;

In the document there are many "the burst"= ;, "a/the unicast burst", "an/the RTP burst" and "the= RTP unicast burst". Do you think it is necessary to keep these terms to be consistent throughout the document?  I revised them as "a/the uni= cast burst" in the revised proposal text.

 

5) "joining the multicast session" and "joining the multicast group"

In the document there is only one "joining the multicast group". I modified "joining the multicast group" t= o "joining the multicast session"

 

6) The description of "Updated Responses"= of step 3 In the document there is a general description for "Updated Responses" as follows. When I discussed with our development enginerrs= , as on-native english speakers they said it is not completely clear to how to implement it.

 

  "3.  Updated Responses:  RS m= ay send more than one RMS-I messages,

       e.g., to updat= e the burst bitrate information when the bitrate is

       adapted and/or= to signal RR in real time to join the SSM session."

 

They said the original text from the draft - draft-levin-avt-rtcp-burst-00 is easier to understand.

So I suggest to add a little description example at= the end of the sensence.

 

The following text is my proposal. The last sensenc= e is largely extracted from the draft - draft-levin-avt-rtcp-burst-00 

 

  "3.  Updated Responses:  RS m= ay send more than one RMS-I messages,

       e.g., to updat= e the unicast burst bitrate information when the bitrate is

       adapted and/or= to signal RR in real time to join the SSM session; to notify

       RR to join the multicast session when the unicast burst catches up with

       the original multicast session."

 

Regards,

Peilin

 

***************************************************= ***************************************

 This email and its attachments contain confid= ential information from HUAWEI, which is intended only for the person or entity wh= ose address is listed above. Any use of the information contained here in any w= ay (including, but not limited to, total or partial disclosure, reproduction, = or dissemination) by persons other than the intended recipient(s) is prohibite= d. If you receive this email in error, please notify the sender by phone or email  immediately and delete it!

 *********************************************= ********************************************

 

----- =D4= =AD=D3=CA=BC=FE -----=

= =B7=A2=BC=FE=C8=CB: "Bill Ver Steeg (versteb)" <versteb@cisco.com>

=C8=D5=C6= =DA: =D0=C7=C6=DA=CE=E5, =C8=FD=D4=C2 27=C8=D5, 2009 =C9=CF=CE=E73:43

=D6=F7=CC=E2: RE: Hi Bill and= all,

=CA=D5=BC= =FE=C8=CB: Peilin YANG <yangpeilin@huawei.com>, "Ali C. Begen (abegen)" <abegen@cisco.com>, Tom.Van_Caenegem@alcatel-lucent.be, zeevvax@microsoft.com, Ye-Kui Wang <yekuiwang@huawei.com><= /p>

=B3=AD=CB= =CD: Roni Even <ron.even.tlv@gmail.com>, Tom Taylor <tom.taylor@rogers.com&g= t;, "Dave Oran (oran)" <oran@cisco.com>, avt@ietf.org

 

> Peilin-

>

> I think we made good progress on the draft. We= also have some other

> folks looking at how the rate adaptation inter= acts with the rest of

> the signaling. Hopefully we will be able to cl= eanly incorporate rate

> adaptation into the protocol. If you have some suggested text in that

> area, that would be great.

>

> Bill VerSteeg

>

> -----Original Message-----

> From: Peilin YANG [mailto:yangpeilin@huawei.co= m]

> Sent: Wednesday, March 25, 2009 8:07 PM

> To: Bill Ver Steeg (versteb); Ali C. Begen (ab= egen);

> Tom.Van_Caenegem@alcatel-lucent.be; zeevvax@microsoft.com; Ye-Kui Wang

> Cc: Roni Even; Tom Taylor; Dave Oran (oran); avt@ietf.org

> Subject: Hi Bill and all,

>

> Hi Bill and all,

>

> Thank you very much for concerning Huawei's dr= aft.

> I am sorry I haven't participated the SF meeti= ng because I haven't got

> an American Visa this time.

>

> YK told me an informal result of break session yesterday.

> Now I am considering the revised text for desc= ribing the functionality

> of Rate Adaptation for the Burst to the common converging solution and

> other possible contributing text.

>

> Regards,

>

> Peilin

>

> **********************************************************************=

> **

> ******************

> This email and its attachments contain confide= ntial information from

> HUAWEI, which is intended only for the person = or entity whose address

> is listed above. Any use of the information contained here in any way

> (including, but not limited to, total or parti= al disclosure,

> reproduction, or dissemination) by persons oth= er than the intended

> recipient(s) is prohibited. If you receive thi= s email in error, please

> notify the sender by phone or email  immediately and delete it!

>

> **********************************************************************=

> **

> *****************

>

 

--_000_5177B2A348E4B64EAD7D589A027892D96A29EAAC65NAEXMSGC111re_-- From yangpeilin@huawei.com Wed Apr 1 06:34:12 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF37228C14E for ; Wed, 1 Apr 2009 06:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_72=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFF6CXBicqyj for ; Wed, 1 Apr 2009 06:34:11 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 398B23A6B75 for ; Wed, 1 Apr 2009 06:34:11 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHF00MTGCEKQF@szxga04-in.huawei.com> for avt@ietf.org; Wed, 01 Apr 2009 21:35:09 +0800 (CST) Received: from huawei.com ([172.17.1.31]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHF00EHTCEK0T@szxga04-in.huawei.com> for avt@ietf.org; Wed, 01 Apr 2009 21:35:08 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [117.89.74.213]) by szxmc03-in.huawei.com (mshttpd); Wed, 01 Apr 2009 21:35:08 +0800 Date: Wed, 01 Apr 2009 21:35:08 +0800 From: Peilin YANG In-reply-to: <81B9B88E2F9D574AA5328A85547CDE91EC162E@xmb-rtp-21d.amer.cisco.com> To: "Bill Ver Steeg (versteb)" , zeevvax@microsoft.com, Tom.Van_Caenegem@alcatel-lucent.be, "Ali C. Begen (abegen)" Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <81B9B88E2F9D574AA5328A85547CDE91EC162E@xmb-rtp-21d.amer.cisco.com> Cc: avt@ietf.org Subject: Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - Fixed and TLV fields X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 13:34:12 -0000 Please see inline comments=2C *************************************************************************= ***************** This email and its attachments contain confidential information from HUA= WEI=2C which is intended only for the person or entity whose address is l= isted above=2E Any use of the information contained here in any way (incl= uding=2C but not limited to=2C total or partial disclosure=2C reproductio= n=2C or dissemination) by persons other than the intended recipient(s) is= prohibited=2E If you receive this email in error=2C please notify the se= nder by phone or email immediately and delete it! ************************************************************************= ***************** ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A =22Bill Ver Steeg (versteb)=22 =3Cversteb=40cisco=2E= com=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=C8=FD=2C =CB=C4=D4=C2 1=C8=D5=2C 2009 =C9=CF= =CE=E72=3A46 =D6=F7=CC=E2=3A =5BAVT=5D Rapid Acquisition of Multicast Streams (RAMS) -= Fixed and TLV fields =CA=D5=BC=FE=C8=CB=3A avt=40ietf=2Eorg=2C zeevvax=40microsoft=2Ecom=2C To= m=2EVan=5FCaenegem=40alcatel-lucent=2Ebe=2C =22Ali C=2E Begen (abegen)=22= =3Cabegen=40cisco=2Ecom=3E =3E = =3E One of the primary action items arising from the review of the Rapid =3E Acquisition of Multicast Streams draft is to identify which = =3E fields are =3E mandatory (and thus fixed format) and which fields are optional (and =3E thus TLV format)=2E Here is my take on the matter=2E Once we reach =3E consensus=2C I will update the draft=2E =3E = =3E I have also included a description of the requested =22motivating tex= t=22 =3E for the fields that do not already have such text in the document=2E =3E Please let me know if I am on the right track=2E =3E = =3E There is currently no version number in the messages=2E Ali and I do = not =3E think that this is a problem because we can add new TLVs as = =3E needed=2E I =3E want to be sure we intentionally decide on this point rather than bac= k =3E into it accidently=2E Any comments=3F =3E = =3E We have 3 messages - = =3E = =3E RAMS-Request =3E Max Receive BitRate - mandatory =3E Min Buffer Fill Requirement - optional ( Add wording - The = =3E receiver may =3E have knowledge of it=27s buffering requirements=2E These requirements= = =3E may be =3E application or device specific=2E For instance=2C the receiver may = =3E need to =3E have a certain amount of data in it=27s application buffer to handle =3E interdependency within the data=2E If the RS knows the buffering abil= ity =3E of the receiver=2C it may more precisely tailor the burst to the clie= nt=2E =3E The methods used by the receiver to determine this value is = =3E applicationspecific=2C and thus out of scope=2E This mechanism can be= = =3E used by the =3E receiver to signal the sender=2C if the receiver has such knowledge )= =3E Max Buffer Fill Requirement - optional ( Add wording - The = =3E receiver may =3E have knowledge of it=27s buffering requirements=2E These requirements= = =3E may be =3E application or device specific=2E For instance=2C one receiver may = =3E have more =3E physical memory than another receiver=2C and thus can buffer more = =3E data=2E If =3E the RS knows the buffering ability of the receiver=2C it may more =3E precisely tailor the burst to the client=2E The methods used by the =3E receiver to determine this value is application specific=2C and thus = out =3E of scope=2E This mechanism can be used by the receiver to signal the =3E sender=2C if the receiver has such knowledge ) =3E = Peilin=3A Like Mr=2E Tom Taylor comment=2C these two optional parameters = are quite clear to me=2E It is easier to understand and implement if ther= e is an instance to explain it=2E = =3E RAMS- Inform =3E message Sequence Number - mandatory =3E Response - mandatory=2C will include an enumerated list of response = =3E codes- 0 is succeed=2C non zero is an error code=2E We will enumerate= = =3E a list of =3E error codes=2C and note that additional error codes are possible usin= g =3E vendor-specific TLV fields=2E The enumerated errors will include =5BN= o =3E server resources=2C No network resources=2C bad RMS-R request=2C WHAT= =3E ELSE=3F=3F=3F=3F=5D = Peilin=3A no buffered content=2E For example=2C when RR requests a channe= l=2CRS hasn=27t buffered this channel=2CRS will reject this request=2E Th= at is to say=2C RR is the first receiver to request to this channel becau= se it is impossible for RS to buffer all channels=2E so I think =22no buf= fered content=22 is a kind of error code=2E Note - we have removed the =22join now semantic=2C as that is =3E captured in the =22earliest join time=22 field=2E = =3E Reserved - mandatory - must be all 0s =3E Max Burst Bitrate - mandatory = =3E Rapid Acquisition Duration - mandatory - 0 means =22join now=22 (Add =3E wording to reflect that this is the server=27s current value=2C and = =3E can be =3E changed by subsequent RMS-I=2E Add wording to reflect that the RS can= =27t =3E consume resources forever and needs to deterministically stop the = =3E flow=2EThe RS MUST terminate the flow at this time=2C even if does no= t = =3E get RMS-T =3E from the RR=2E ) = =3E Extended RTP Sequence Number of First Burst Packet - mandatory =3E Earliest IGMP Join Time - optional (we should consider making this =3E mandatory in at least one RMS-I=2C as the client needs to eventually = =3E join) = =3E Rams -Terminate - = =3E Extended RTP seqnum of First Multicast packet - optional (intent = =3E is to =3E tell the RS the seqnum at which to stop the burst=2C but leave the = =3E sessionopen=2E If the field is not present=2C it means =22stop now=22= ) =3E = =3E = =3E = =3E Bill VerSteeg =3E From yangpeilin@huawei.com Wed Apr 1 06:38:15 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 404EB3A684A for ; Wed, 1 Apr 2009 06:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.842 X-Spam-Level: * X-Spam-Status: No, score=1.842 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_42=0.6, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qS2JRVF+szS2 for ; Wed, 1 Apr 2009 06:38:13 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 7B2D43A688F for ; Wed, 1 Apr 2009 06:37:52 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHF0012LCKH5L@szxga03-in.huawei.com> for avt@ietf.org; Wed, 01 Apr 2009 21:38:41 +0800 (CST) Received: from huawei.com ([172.17.1.31]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHF0088DCKG69@szxga03-in.huawei.com> for avt@ietf.org; Wed, 01 Apr 2009 21:38:41 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [117.89.74.213]) by szxmc03-in.huawei.com (mshttpd); Wed, 01 Apr 2009 21:38:40 +0800 Date: Wed, 01 Apr 2009 21:38:40 +0800 From: Peilin YANG In-reply-to: <81B9B88E2F9D574AA5328A85547CDE91EC1548@xmb-rtp-21d.amer.cisco.com> To: "Bill Ver Steeg (versteb)" , "Ali C. Begen (abegen)" , Tom.Van_Caenegem@alcatel-lucent.be, zeevvax@microsoft.com Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <81B9B88E2F9D574AA5328A85547CDE91E0B8A6@xmb-rtp-21d.amer.cisco.com> <81B9B88E2F9D574AA5328A85547CDE91EC1548@xmb-rtp-21d.amer.cisco.com> Cc: avt@ietf.org Subject: Re: [AVT] Revised text of the proposal for describing the functionality of Rate Adaptation X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 13:38:15 -0000 Hi Bill=2C Ali=2C Tom and Zeev=2C Thank you very much for reply and comments=2C and thank Bill for going th= rough the document with my suggestion=2E I also support Ali=27s advice that we should focus on issue at this time=2E= Once we slove the major issues=2C we can make quick progress on the conve= rging draft=2E The most important issue is the proposal of =22fixed vs TLV fields=22 tha= t Bill suggested to discuss in the mailing list=2E Obviously both fixed vs TLV fields have their advantage and disadvantage=2E= For TLV fields=2C it is easier to allow vendor-specific extensions=2E Bu= t I have no idea if TLV format will influence the maximum number of concu= rrent of RS=2E It should be better if there is a small influence=2E Another issue is the Sequence Number of RMS-R=2Cas Bill said=2Cit is not = good that two message of the 3 have a seqnum type=2E I also think so=2E N= evertheless=2C for RS perhaps it is more clear if there is a seqnum of RM= S-R=2E I have no idea if there is another replaceable way for this=2E Regards=2C Peilin *************************************************************************= ***************** This email and its attachments contain confidential information from HUA= WEI=2C which is intended only for the person or entity whose address is l= isted above=2E Any use of the information contained here in any way (incl= uding=2C but not limited to=2C total or partial disclosure=2C reproductio= n=2C or dissemination) by persons other than the intended recipient(s) is= prohibited=2E If you receive this email in error=2C please notify the se= nder by phone or email immediately and delete it! ************************************************************************= ***************** ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A =22Bill Ver Steeg (versteb)=22 =3Cversteb=40cisco=2E= com=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=C8=FD=2C =CB=C4=D4=C2 1=C8=D5=2C 2009 =C9=CF= =CE=E71=3A10 =D6=F7=CC=E2=3A RE=3A Revised text of the proposal for describing the fun= ctionality of Rate Adaptation =CA=D5=BC=FE=C8=CB=3A Peilin YANG =3Cyangpeilin=40huawei=2Ecom=3E=2C =22A= li C=2E Begen (abegen)=22 =3Cabegen=40cisco=2Ecom=3E=2C Tom=2EVan=5FCaene= gem=40alcatel-lucent=2Ebe=2C zeevvax=40microsoft=2Ecom =B3=AD=CB=CD=3A Roni Even =3Cron=2Eeven=2Etlv=40gmail=2Ecom=3E=2C Tom Tay= lor =3Ctom=2Etaylor=40rogers=2Ecom=3E=2C Ye-Kui Wang =3Cyekuiwang=40huawe= i=2Ecom=3E =3E Peilin/Zeev =3E = =3E Thanks for the detailed suggestions=2E =3E = =3E I am still considering whether the RMS-I and RMS-T messages need a = =3E sequence number=2E It sounds like we want a sequence number on the = =3E RMS-I=2C but do not want one on the RMS-T=2E If we have a seqnum on 2= = =3E of the 3 messages=2C I am inclined to put one on all of them=2E Does = =3E anybody else have an opinion=3F =3E = =3E I should have a straw man proposal for fixed vs TLV fields in the = =3E next few hours (worst case tomorrow)=2E We can discuss in detail via = =3E email or on a call=2E =3E = =3E I am going through the document with Peilin=27s suggested word- =3E smithing changes (as modified by Zeev and Tom)=2E I am incorporating = =3E many of the suggested changes=2C with exceptions noted below- =3E = =3E 1- Regarding =22receiver=22 and =22RTP receiver=22 - I have changed m= any = =3E instances of =22receiver=22 to =22RTP receiver=22=2C but left some of= the = =3E references as =22receiver=22 for readability=2E I tried to use =22RTP= = =3E receiver=22 when referencing protocol specific actions=2C but use = =3E =22receiver=22 when discussing a generic device=2E This is not large = =3E point=2C so some areas could go either way without a loss of clarity=2E= =3E = =3E 2- Same comments regarding =22burst=22 and =22unicast burst=22=2E I d= id = =3E eliminate all instances of =22RTP burst=22 =3E = =3E = =3E = =3E I should have a document out this evening or tomorrow afternoon = =3E (depending on how many interrupts the =22real job=22 gives me today=2E= =3E = =3E Bvs =3E = =3E = =3E -----Original Message----- =3E From=3A Peilin YANG =5Bmailto=3Ayangpeilin=40huawei=2Ecom=5D = =3E Sent=3A Monday=2C March 30=2C 2009 7=3A20 AM =3E To=3A Bill Ver Steeg (versteb)=3B Ali C=2E Begen (abegen)=3B = =3E Tom=2EVan=5FCaenegem=40alcatel-lucent=2Ebe=3B zeevvax=40microsoft=2Ec= om =3E Cc=3A Roni Even=3B Tom Taylor=3B Ye-Kui Wang =3E Subject=3A Revised text of the proposal for describing the = =3E functionality of Rate Adaptation =3E = =3E Dear Bill=2C Ali=2C Tom and Zeev=2C =3E = =3E I added some revised text of the proposal for describing the = =3E functionality of Rate Adaptation for the Burst=2E Please see the = =3E attached file=2E The revised text mainly involves in a new step 3=2C = =3E part of step 1=2C =227=2E1=2E RMS Request=22 and Figure 3 depicts an = example = =3E of messaging flow=2E =3E I am very glad to disucss it with you=2E In the attachment file it = =3E also includes a little revision=2E Please see if not suitable for = =3E revison=2E =3E In addition=2C I think=2C the following suggestions also need to be = =3E discussed=2E = =3E = =3E 1) IGMP = =3E = =3E In the draft like the following text it only describes the IGMP = =3E based on IPv4=2E =3E = =3E =22When a receiver wishes to join the same multicast session=2C = =3E instead of simply issuing an Internet Group Management Protocol = =3E (IGMP) =5BRFC3376=5D Join message=2C it sends a request to the feedba= ck = =3E target address for the session asking for the Reference = =3E Information=2E =22 =3E = =3E Do you think it is necessary to consider MLD protocol based on = =3E IPv6 in the document as follows=3F = =3E = =3E =22When a receiver wishes to join the same multicast session=2C = =3E instead of simply issuing an Internet Group Management Protocol = =3E (IGMP) =5BRFC3376=5D or Multicast Listener Discovery (MLD) =5BRFC 381= 0=5D = =3E Join message=2C it sends a request to the feedback target address = =3E for the session asking for the Reference Information=2E =22 =3E = =3E 2) RMS-I message =3E = =3E In the RMS-I message=2C the present values of Response include 0=2C1 = =3E and 2=2E The value of 0 indicates that the rapid synchronization = =3E request has been rejected=2E Nevertheless=2C in the RMS-I message = =3E there is not a field to indicate a rejected reason=2E In my point of = =3E view=2C tt is easier for RR to understand the rejected reason if = =3E there is a field of reason=2E What=27s more=2C it is convenient to ma= ke = =3E statistics report=2E = =3E = =3E The following Figure is my proposal=2E = =3E = =3E 0 1 2 3 =3E 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 = =3E 0 1 =3E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- =3E +-+ =3E =7C MSN =7C Response =7C Reason =7C Rsv= d=2E = =3E =7C =3E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- =3E +-+ =3E =7C Extended RTP Seqnum of the First Burst Packet = =3E =7C =3E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- =3E +-+ =3E =7C Earliest IGMP Join Time = =3E =7C =3E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- =3E +-+ =3E =7C Rapid Synchronization Duration = =3E =7C =3E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- =3E +-+ =3E =7C Max Burst Bitrate = =3E =7C =3E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- =3E +-+ =3E = =3E Figure 5=3A FCI field syntax for the RMS Information message =3E = =3E 3) =22an/the RTP Receiver=22 and =22a/the Receiver=22 =3E In the document there are many =22an/the RTP Receiver=22 and =22a/the= = =3E Receiver=22=2E Do you think it is necessary to keep these terms to be= = =3E consistent throughout the document=3F I revised them as =22an/the RT= P = =3E Receiver=22 in the revised proposal text=2E = =3E = =3E 4) =22the burst=22=2C =22a/the unicast burst=22=2C =22an/the RTP burs= t=22 and =22the = =3E RTP unicast burst=22 =3E In the document there are many =22the burst=22=2C =22a/the unicast bu= rst=22=2C = =3E =22an/the RTP burst=22 and =22the RTP unicast burst=22=2E Do you thin= k it is = =3E necessary to keep these terms to be consistent throughout the = =3E document=3F I revised them as =22a/the unicast burst=22 in the revis= ed = =3E proposal text=2E =3E = =3E 5) =22joining the multicast session=22 and =22joining the multicast g= roup=22 =3E In the document there is only one =22joining the multicast group=22=2E= I = =3E modified =22joining the multicast group=22 to =22joining the multicas= t = =3E session=22 =3E 6) The description of =22Updated Responses=22 of step 3 In the = =3E document there is a general description for =22Updated Responses=22 a= s = =3E follows=2E When I discussed with our development enginerrs=2C as on- =3E native english speakers they said it is not completely clear to = =3E how to implement it=2E =3E = =3E =223=2E Updated Responses=3A RS may send more than one RMS-I messa= ges=2C =3E e=2Eg=2E=2C to update the burst bitrate information when the = =3E bitrate is =3E adapted and/or to signal RR in real time to join the SSM = =3E session=2E=22 =3E They said the original text from the draft - draft-levin-avt-rtcp- =3E burst-00 is easier to understand=2E =3E So I suggest to add a little description example at the end of the = =3E sensence=2E =3E The following text is my proposal=2E The last sensence is largely = =3E extracted from the draft - draft-levin-avt-rtcp-burst-00 = =3E = =3E =223=2E Updated Responses=3A RS may send more than one RMS-I messa= ges=2C =3E e=2Eg=2E=2C to update the unicast burst bitrate information whe= n = =3E the bitrate is =3E adapted and/or to signal RR in real time to join the SSM = =3E session=3B to notify = =3E RR to join the multicast session when the unicast burst = =3E catches up with = =3E the original multicast session=2E=22 = =3E = =3E Regards=2C =3E Peilin =3E = =3E *********************************************************************= ********************* =3E This email and its attachments contain confidential information = =3E from HUAWEI=2C which is intended only for the person or entity whose = =3E address is listed above=2E Any use of the information contained here = =3E in any way (including=2C but not limited to=2C total or partial = =3E disclosure=2C reproduction=2C or dissemination) by persons other than= = =3E the intended recipient(s) is prohibited=2E If you receive this email = =3E in error=2C please notify the sender by phone or email immediately = =3E and delete it! =3E = =3E *********************************************************************= ******************** =3E ----- =D4=AD=D3=CA=BC=FE ----- =3E =B7=A2=BC=FE=C8=CB=3A =22Bill Ver Steeg (versteb)=22 =3Cversteb=40cis= co=2Ecom=3E =3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CE=E5=2C =C8=FD=D4=C2 27=C8=D5=2C 2009 =C9= =CF=CE=E73=3A43 =3E =D6=F7=CC=E2=3A RE=3A Hi Bill and all=2C =3E =CA=D5=BC=FE=C8=CB=3A Peilin YANG =3Cyangpeilin=40huawei=2Ecom=3E=2C = =22Ali C=2E Begen (abegen)=22 = =3E =3Cabegen=40cisco=2Ecom=3E=2C Tom=2EVan=5FCaenegem=40alcatel-lucent=2E= be=2C = =3E zeevvax=40microsoft=2Ecom=2C Ye-Kui Wang =3Cyekuiwang=40huawei=2Ecom=3E= =3E =B3=AD=CB=CD=3A Roni Even =3Cron=2Eeven=2Etlv=40gmail=2Ecom=3E=2C Tom= Taylor = =3E =3Ctom=2Etaylor=40rogers=2Ecom=3E=2C =22Dave Oran (oran)=22 =3Coran=40= cisco=2Ecom=3E=2C = =3E avt=40ietf=2Eorg =3E =3E Peilin- =3E =3E = =3E =3E I think we made good progress on the draft=2E We also have some = =3E other = =3E =3E folks looking at how the rate adaptation interacts with the rest = =3E of = =3E =3E the signaling=2E Hopefully we will be able to cleanly incorporate= = =3E rate = =3E =3E adaptation into the protocol=2E If you have some suggested text i= n = =3E that = =3E =3E area=2C that would be great=2E =3E =3E = =3E =3E Bill VerSteeg =3E =3E = =3E =3E -----Original Message----- =3E =3E From=3A Peilin YANG =5Bmailto=3Ayangpeilin=40huawei=2Ecom=5D =3E =3E Sent=3A Wednesday=2C March 25=2C 2009 8=3A07 PM =3E =3E To=3A Bill Ver Steeg (versteb)=3B Ali C=2E Begen (abegen)=3B = =3E =3E Tom=2EVan=5FCaenegem=40alcatel-lucent=2Ebe=3B zeevvax=40microsoft= =2Ecom=3B Ye- =3E Kui Wang =3E =3E Cc=3A Roni Even=3B Tom Taylor=3B Dave Oran (oran)=3B avt=40ietf=2E= org =3E =3E Subject=3A Hi Bill and all=2C =3E =3E = =3E =3E Hi Bill and all=2C =3E =3E = =3E =3E Thank you very much for concerning Huawei=27s draft=2E =3E =3E I am sorry I haven=27t participated the SF meeting because I = =3E haven=27t got = =3E =3E an American Visa this time=2E =3E =3E = =3E =3E YK told me an informal result of break session yesterday=2E =3E =3E Now I am considering the revised text for describing the = =3E functionality = =3E =3E of Rate Adaptation for the Burst to the common converging = =3E solution and = =3E =3E other possible contributing text=2E =3E =3E = =3E =3E Regards=2C =3E =3E = =3E =3E Peilin =3E =3E = =3E =3E = =3E *********************************************************************= *=3E ** =3E =3E ****************** =3E =3E This email and its attachments contain confidential information = =3E from = =3E =3E HUAWEI=2C which is intended only for the person or entity whose = =3E address = =3E =3E is listed above=2E Any use of the information contained here in = =3E any way = =3E =3E (including=2C but not limited to=2C total or partial disclosure=2C= = =3E =3E reproduction=2C or dissemination) by persons other than the inten= ded =3E =3E recipient(s) is prohibited=2E If you receive this email in error=2C= = =3E please = =3E =3E notify the sender by phone or email immediately and delete it! =3E =3E = =3E =3E = =3E *********************************************************************= *=3E ** =3E =3E ***************** =3E =3E = =3E From versteb@cisco.com Wed Apr 1 14:36:17 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1CDB3A6863 for ; Wed, 1 Apr 2009 14:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pb1UYVCwgY-Y for ; Wed, 1 Apr 2009 14:36:16 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 7103E3A68C8 for ; Wed, 1 Apr 2009 14:36:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,308,1235952000"; d="scan'208,217";a="165209784" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-1.cisco.com with ESMTP; 01 Apr 2009 21:37:16 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n31LbGP6018727; Wed, 1 Apr 2009 17:37:16 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n31LbGf5022806; Wed, 1 Apr 2009 21:37:16 GMT Received: from xmb-rtp-21d.amer.cisco.com ([64.102.31.116]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 17:37:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B312.06AC6017" Date: Wed, 1 Apr 2009 17:37:15 -0400 Message-ID: <81B9B88E2F9D574AA5328A85547CDE91EC1C34@xmb-rtp-21d.amer.cisco.com> In-Reply-To: <5177B2A348E4B64EAD7D589A027892D96A29EAB21D@NA-EXMSG-C111.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Rapid Acquisition of Multicast Streams (RAMS) - Fixed and TLV fields Thread-Index: AcmyMO1Vf+4hrMHmQjCLzeIX0fZkSAAt6jegAApONVA= References: <81B9B88E2F9D574AA5328A85547CDE91EC162E@xmb-rtp-21d.amer.cisco.com> <5177B2A348E4B64EAD7D589A027892D96A29EAB21D@NA-EXMSG-C111.redmond.corp.microsoft.com> From: "Bill Ver Steeg (versteb)" To: "Zeev Vax" , , "Ali C. Begen (abegen)" X-OriginalArrivalTime: 01 Apr 2009 21:37:16.0416 (UTC) FILETIME=[06F34800:01C9B312] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=17834; t=1238621836; x=1239485836; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=versteb@cisco.com; z=From:=20=22Bill=20Ver=20Steeg=20(versteb)=22=20 |Subject:=20RE=3A=20Rapid=20Acquisition=20of=20Multicast=20 Streams=20(RAMS)=20-=20Fixed=20and=20TLV=20fields |Sender:=20 |To:=20=22Zeev=20Vax=22=20,=20,=0A=20=20=20=20=20=20=20=20=2 2Ali=20C.=20Begen=20(abegen)=22=20; bh=L2wNtkxUUA/UhT5PSlbv/wmOjkfYA28t4uFBTBoHf6g=; b=S+sl3PZ6rBO1LBp0QgZ1PD64uMO86EyZTecrZa/CMnjwsFfoAiu7ZoWrz5 PlWZWd95PGnMCBwxSmMjafGOywib7G7IiVERn6xVQb4NTOhnN6BBaMkvTG2U wmwbUnHBbV; Authentication-Results: rtp-dkim-1; header.From=versteb@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: avt@ietf.org Subject: Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - Fixed and TLV fields X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 21:36:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B312.06AC6017 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sure - hopefully this evening. Tomorrow at the latest =20 I have gotten some feedback on the included note. Once I get this text updated and rolled into the document I will send it to you for your updates. =20 bvs =20 ________________________________ From: Zeev Vax [mailto:zeevvax@microsoft.com]=20 Sent: Wednesday, April 01, 2009 1:09 PM To: Bill Ver Steeg (versteb); Tom.Van_Caenegem@alcatel-lucent.be; Ali C. Begen (abegen) Cc: avt@ietf.org Subject: RE: Rapid Acquisition of Multicast Streams (RAMS) - Fixed and TLV fields Bill, =20 Please send me the draft for review once you are done with your editorial path, before we send it out for review I would like to add my changes to the draft. =20 =20 Zeev =20 From: Bill Ver Steeg (versteb) [mailto:versteb@cisco.com]=20 Sent: Tuesday, March 31, 2009 11:46 AM To: avt@ietf.org; Zeev Vax; Tom.Van_Caenegem@alcatel-lucent.be; Ali C. Begen (abegen) Subject: Rapid Acquisition of Multicast Streams (RAMS) - Fixed and TLV fields =20 =20 One of the primary action items arising from the review of the Rapid Acquisition of Multicast Streams draft is to identify which fields are mandatory (and thus fixed format) and which fields are optional (and thus TLV format). Here is my take on the matter. Once we reach consensus, I will update the draft. =20 I have also included a description of the requested "motivating text" for the fields that do not already have such text in the document. Please let me know if I am on the right track. =20 There is currently no version number in the messages. Ali and I do not think that this is a problem because we can add new TLVs as needed. I want to be sure we intentionally decide on this point rather than back into it accidently. Any comments? =20 We have 3 messages -=20 =20 RAMS-Request Max Receive BitRate - mandatory Min Buffer Fill Requirement - optional ( Add wording - The receiver may have knowledge of it's buffering requirements. These requirements may be application or device specific. For instance, the receiver may need to have a certain amount of data in it's application buffer to handle interdependency within the data. If the RS knows the buffering ability of the receiver, it may more precisely tailor the burst to the client. The methods used by the receiver to determine this value is application specific, and thus out of scope. This mechanism can be used by the receiver to signal the sender, if the receiver has such knowledge ) Max Buffer Fill Requirement - optional ( Add wording - The receiver may have knowledge of it's buffering requirements. These requirements may be application or device specific. For instance, one receiver may have more physical memory than another receiver, and thus can buffer more data. If the RS knows the buffering ability of the receiver, it may more precisely tailor the burst to the client. The methods used by the receiver to determine this value is application specific, and thus out of scope. This mechanism can be used by the receiver to signal the sender, if the receiver has such knowledge ) =20 RAMS- Inform message Sequence Number - mandatory Response - mandatory, will include an enumerated list of response codes - 0 is succeed, non zero is an error code. We will enumerate a list of error codes, and note that additional error codes are possible using vendor-specific TLV fields. The enumerated errors will include [No server resources, No network resources, bad RMS-R request, WHAT ELSE????] Note - we have removed the "join now semantic, as that is captured in the "earliest join time" field.=20 Reserved - mandatory - must be all 0s Max Burst Bitrate - mandatory=20 Rapid Acquisition Duration - mandatory - 0 means "join now" (Add wording to reflect that this is the server's current value, and can be changed by subsequent RMS-I. Add wording to reflect that the RS can't consume resources forever and needs to deterministically stop the flow. The RS MUST terminate the flow at this time, even if does not get RMS-T from the RR. )=20 Extended RTP Sequence Number of First Burst Packet - mandatory Earliest IGMP Join Time - optional (we should consider making this mandatory in at least one RMS-I, as the client needs to eventually join) =20 Rams -Terminate -=20 Extended RTP seqnum of First Multicast packet - optional (intent is to tell the RS the seqnum at which to stop the burst, but leave the session open. If the field is not present, it means "stop now") =20 =20 =20 Bill VerSteeg ------_=_NextPart_001_01C9B312.06AC6017 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Sure - hopefully this evening. Tomorrow at the=20 latest
 
I have gotten some feedback on the = included note. Once=20 I get this text updated and rolled into the document I will send it to = you for=20 your updates.
 
bvs
 

From: Zeev Vax = [mailto:zeevvax@microsoft.com]=20
Sent: Wednesday, April 01, 2009 1:09 PM
To: Bill = Ver Steeg=20 (versteb); Tom.Van_Caenegem@alcatel-lucent.be; Ali C. Begen=20 (abegen)
Cc: avt@ietf.org
Subject: RE: Rapid = Acquisition of=20 Multicast Streams (RAMS) - Fixed and TLV fields

Bill,

 

Please send me = the draft for=20 review once you are done with your editorial path, before we send it out = for=20 review I would like to add my changes to the draft. =  

 

Zeev

 

From: Bill Ver = Steeg=20 (versteb) [mailto:versteb@cisco.com]
Sent: Tuesday, March 31, = 2009=20 11:46 AM
To: avt@ietf.org; Zeev Vax;=20 Tom.Van_Caenegem@alcatel-lucent.be; Ali C. Begen = (abegen)
Subject:=20 Rapid Acquisition of Multicast Streams (RAMS) - Fixed and TLV=20 fields

 

 

One of the = primary=20 action items arising from the review of the Rapid Acquisition of = Multicast=20 Streams  draft is to identify which fields are mandatory (and thus = fixed=20 format) and which fields are optional (and thus TLV format). Here = is my=20 take on the matter. Once we reach consensus, I will update the=20 draft.

 

I have also = included=20 a description of the requested "motivating text" for the fields that do = not=20 already have such text in the document. Please let me know if I am on = the right=20 track.

 

There is = currently no=20 version number in the messages. Ali and I do not think that = this is a=20 problem because we can add new TLVs as needed. I want to be sure we = intentionally decide on this point rather than back into it accidently. = Any=20 comments?

 

We have 3 = messages -=20

 

RAMS-Request

 Max = Receive=20 BitRate - mandatory

 Min = Buffer Fill=20 Requirement - optional ( Add wording - The receiver may have = knowledge of=20 it's buffering requirements. These requirements may be application or=20 device specific. For instance, the receiver may need to have a = certain=20 amount of data in it's application buffer to handle interdependency = within the=20 data. If the RS knows the buffering ability of the receiver, it may more = precisely tailor the burst to the client. The methods used by = the=20 receiver to determine this value is application specific, and thus out = of scope.=20 This mechanism can be used by the receiver to signal the sender, if=20 the receiver has such knowledge )

 Max = Buffer Fill=20 Requirement - optional ( Add wording - The receiver may have knowledge = of it's=20 buffering requirements. These requirements may be application or=20 device specific. For instance, one receiver may have more = physical=20 memory than another receiver, and thus can buffer more data. If the RS = knows the=20 buffering ability of the receiver, it may more precisely tailor the = burst to the=20 client. The methods used by the receiver to determine = this value=20 is application specific, and thus out of scope. This mechanism can be = used by=20 the receiver to signal the sender, if the receiver has such=20 knowledge )

 

RAMS-=20 Inform

 message=20 Sequence Number - mandatory

 Response -=20 mandatory, will include an enumerated list of response codes - 0 is = succeed, non=20 zero is an error code. We will enumerate a list of error codes, = and note=20 that additional error codes are possible using vendor-specific TLV = fields.=20 The enumerated errors will include [No server resources, No network = resources,=20 bad RMS-R request, WHAT ELSE????] Note - we have removed the "join now = semantic,=20 as that is captured in the "earliest join time"=20 field. 

 Reserved -=20 mandatory - must be all 0s

 Max = Burst=20 Bitrate - mandatory

 Rapid = Acquisition Duration - mandatory - 0 means "join now" (Add wording = to=20 reflect that this is the server's current value, and can be = changed by=20 subsequent RMS-I. Add wording to reflect that the RS can't consume = resources=20 forever and needs to deterministically stop the flow. The RS = MUST=20 terminate the flow at this time, even if does not get RMS-T from the RR. =  )

 Extended RTP=20 Sequence Number of First Burst Packet -=20 mandatory

 Earliest = IGMP Join=20 Time - optional (we should consider making this mandatory in at least = one RMS-I,=20 as the client needs to eventually join)

 

Rams = -Terminate -=20

  Extended=20 RTP seqnum of First Multicast packet - optional (intent is to tell the = RS the=20 seqnum at which to stop the burst, but leave the session open. If the = field is=20 not present, it means "stop now")

 

 

 

Bill=20 VerSteeg

------_=_NextPart_001_01C9B312.06AC6017-- From versteb@cisco.com Wed Apr 1 16:51:18 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63A3E3A6B8F for ; Wed, 1 Apr 2009 16:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CL+faYiR7YH3 for ; Wed, 1 Apr 2009 16:51:17 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E8C203A69A9 for ; Wed, 1 Apr 2009 16:51:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,309,1235952000"; d="scan'208,217";a="40778917" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 01 Apr 2009 23:52:17 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n31NqHFf003785; Wed, 1 Apr 2009 19:52:17 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n31NqHBi028702; Wed, 1 Apr 2009 23:52:17 GMT Received: from xmb-rtp-21d.amer.cisco.com ([64.102.31.116]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 19:52:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B324.E3051D80" Date: Wed, 1 Apr 2009 19:52:15 -0400 Message-ID: <81B9B88E2F9D574AA5328A85547CDE91EC1CAA@xmb-rtp-21d.amer.cisco.com> In-Reply-To: <81B9B88E2F9D574AA5328A85547CDE91EC1C34@xmb-rtp-21d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Rapid Acquisition of Multicast Streams (RAMS) - multiple RAMS-R messages for the same unicast flow Thread-Index: AcmyMO1Vf+4hrMHmQjCLzeIX0fZkSAAt6jegAApONVAABEpf4A== References: <81B9B88E2F9D574AA5328A85547CDE91EC162E@xmb-rtp-21d.amer.cisco.com><5177B2A348E4B64EAD7D589A027892D96A29EAB21D@NA-EXMSG-C111.redmond.corp.microsoft.com> <81B9B88E2F9D574AA5328A85547CDE91EC1C34@xmb-rtp-21d.amer.cisco.com> From: "Bill Ver Steeg (versteb)" To: "Bill Ver Steeg (versteb)" , "Zeev Vax" , , "Ali C. Begen (abegen)" X-OriginalArrivalTime: 01 Apr 2009 23:52:16.0963 (UTC) FILETIME=[E340A930:01C9B324] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7509; t=1238629937; x=1239493937; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=versteb@cisco.com; z=From:=20=22Bill=20Ver=20Steeg=20(versteb)=22=20 |Subject:=20=20Rapid=20Acquisition=20of=20Multicast=20Strea ms=20(RAMS)=20-=20multiple=20RAMS-R=20messages=20for=20the=2 0same=20unicast=20flow |Sender:=20 |To:=20=22Bill=20Ver=20Steeg=20(versteb)=22=20,=0A=20=20=20=20=20=20=20=20=22Zeev=20Vax=22=20,=0A=20=20=20=20=20=20=20=20,=0A=20=20=20=20=20=20=20=20=22Ali=20C.= 20Begen=20(abegen)=22=20; bh=85OC4LAmZ7CooyecAGijFEA9CgOJFzEHUGJ3aJJ09j0=; b=NxxQA88YlxaXSj+C/C7RIc8rdXBE5aM054NbZX8FFfwJ479mViTKAFBRWh C1ydcknB54Hej2tjmcFNgur0ZzLWVL4yL8oCuYpcoaxtthFkN1fQFvCL3n9X zPGfmv2rv/; Authentication-Results: rtp-dkim-1; header.From=versteb@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: avt@ietf.org Subject: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multiple RAMS-R messages for the same unicast flow X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 23:51:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B324.E3051D80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 When we added the ability to send more than one RAMS-R message, we opened up a few design points that we now need to consider. We need to have some nomenclature for describing the "initial RMS-R" and "subsequent RMS-R", so I will start with using those words. Better words would be appreciated. The first design point I would like to address is what the RS is required to do when it receives an RAMS-R for a burst that is already in flow (aka "subsequent RMS-R"). We stated that the least it could do was "ignore it". Does this imply that there is no requirement to send an RMS-I in response to RMS-R messages referencing an in-progress flow? If so, we should add clarifying text in the document that cautions the RR not to assume the RAMS-R was dropped. I briefly considered requiring the RS to send a RAMS-I for each received RAMS-R. Unfortunately, this then leads to another set of corner cases, and may result in a chatty exchange of messages. We also need to consider how to deterministically differentiate between the initial RMS-R message and subsequent RMS-R messages, particularly in the event of packet loss or (unlikely) re-ordering. This probably leads us to including a monotonically increasing sequence number on the RMS-R. Dropped RMS-R messages should not be a protocol problem, as the first one received will trigger the burst. Subsequent RMS-R messages either change the burst shape or they do not, and they do not trigger additional messages. Similarly, if the initial RMS-I is dropped it will probably trigger an additional RMS-R message. Subsequent RMS-I messages will either be received by the RR or they will not, and they will not trigger additional messages. So, has anybody considered these design points in detail? I have started to go down this path, but it gets complicated quickly. In order to limit the complexity, I suggest that we state that the first received RMS-R triggers a RMS-I. Further RMS-R messages may flow. Further RMS-I messages may also flow, but there is no explicit requirement to send an RMS-I in response to a subsequent RMS-R. =20 Bill VerSteeg ------_=_NextPart_001_01C9B324.E3051D80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

When we added the ability to send more than one RAMS-R message, we = opened up=20 a few design points that we now need to consider.

We need to have some nomenclature for describing the "initial RMS-R" = and=20 "subsequent RMS-R", so I will start with using those words. Better words = would=20 be appreciated.

The first design point I would like to address is what the RS is = required to=20 do when it receives an RAMS-R for a burst that is already in flow (aka=20 "subsequent RMS-R"). We stated that the least it could do was "ignore = it". Does=20 this imply that there is no requirement to send an RMS-I in response to = RMS-R=20 messages referencing an in-progress flow? If so, we should add = clarifying text=20 in the document that cautions the RR not to assume the RAMS-R was = dropped. I=20 briefly considered requiring the RS to send a RAMS-I for each received = RAMS-R.=20 Unfortunately, this then leads to another set of corner cases, and may = result in=20 a chatty exchange of messages.

We also need to consider how to deterministically differentiate = between the=20 initial RMS-R message and subsequent RMS-R messages, particularly in the = event=20 of packet loss or (unlikely) re-ordering. This probably leads us to = including a=20 monotonically increasing sequence number on the RMS-R. Dropped RMS-R messages should not be a = protocol=20 problem, as the first one received will trigger the burst. Subsequent = RMS-R=20 messages either change the burst shape or they do not, and they do not = trigger=20 additional messages. Similarly, if the initial RMS-I is dropped it will = probably=20 trigger an additional RMS-R message. Subsequent RMS-I messages will = either be=20 received by the RR or they will not, and they will not trigger = additional=20 messages.

So, has anybody considered these design points in detail? I have = started to=20 go down this path, but it gets complicated quickly.

In order to limit the complexity, I suggest that we state that the=20 first received RMS-R = triggers a=20 RMS-I. Further RMS-R messages may flow. Further RMS-I messages may also = flow,=20 but there is no explicit requirement to send an RMS-I in response to a=20 subsequent RMS-R.

 

Bill VerSteeg

------_=_NextPart_001_01C9B324.E3051D80-- From yekuiwang@huawei.com Wed Apr 1 17:52:17 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F17D3A687D for ; Wed, 1 Apr 2009 17:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.707 X-Spam-Level: X-Spam-Status: No, score=-1.707 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0Edv0iCR2Ko for ; Wed, 1 Apr 2009 17:52:16 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 1DEF53A681A for ; Wed, 1 Apr 2009 17:52:16 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHG00AJN7SSE8@usaga04-in.huawei.com> for avt@ietf.org; Wed, 01 Apr 2009 19:53:16 -0500 (CDT) Received: from W90946 ([10.51.0.20]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KHG00KTM7SNLX@usaga04-in.huawei.com> for avt@ietf.org; Wed, 01 Apr 2009 19:53:16 -0500 (CDT) Date: Wed, 01 Apr 2009 20:53:10 -0400 From: Ye-Kui Wang In-reply-to: <81B9B88E2F9D574AA5328A85547CDE91EC1CAA@xmb-rtp-21d.amer.cisco.com> To: "'Bill Ver Steeg (versteb)'" , 'Zeev Vax' , Tom.Van_Caenegem@alcatel-lucent.be, "'Ali C. Begen (abegen)'" Message-id: <9FBAA863185D42098EB4FA0C7D117E25@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_jiY/hiJsyT5x6TNeI5lJIg)" Thread-index: AcmyMO1Vf+4hrMHmQjCLzeIX0fZkSAAt6jegAApONVAABEpf4AACVnxA References: <81B9B88E2F9D574AA5328A85547CDE91EC162E@xmb-rtp-21d.amer.cisco.com> <5177B2A348E4B64EAD7D589A027892D96A29EAB21D@NA-EXMSG-C111.redmond.corp.microsoft.com> <81B9B88E2F9D574AA5328A85547CDE91EC1C34@xmb-rtp-21d.amer.cisco.com> <81B9B88E2F9D574AA5328A85547CDE91EC1CAA@xmb-rtp-21d.amer.cisco.com> Cc: avt@ietf.org Subject: Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multiple RAMS-R messages for the same unicast flow X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 00:52:17 -0000 This is a multi-part message in MIME format. --Boundary_(ID_jiY/hiJsyT5x6TNeI5lJIg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Sending of subsequent RAMS-I messages by the RS is not trigged by reception of RAMS-R messages, but by that the server has decided to change information contained in RAMS-I messages, including burst bitrate. Only in the case when the RS decided to change the burst bitrate according to a subsequent RAMS-R message received, the subsequent RAMS-R message indirectly triggers a RAMS-I message. The process to me seems rather simple. BR, YK _____ From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Bill Ver Steeg (versteb) Sent: Wednesday, April 01, 2009 7:52 PM To: Bill Ver Steeg (versteb); Zeev Vax; Tom.Van_Caenegem@alcatel-lucent.be; Ali C. Begen (abegen) Cc: avt@ietf.org Subject: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multiple RAMS-R messages for the same unicast flow When we added the ability to send more than one RAMS-R message, we opened up a few design points that we now need to consider. We need to have some nomenclature for describing the "initial RMS-R" and "subsequent RMS-R", so I will start with using those words. Better words would be appreciated. The first design point I would like to address is what the RS is required to do when it receives an RAMS-R for a burst that is already in flow (aka "subsequent RMS-R"). We stated that the least it could do was "ignore it". Does this imply that there is no requirement to send an RMS-I in response to RMS-R messages referencing an in-progress flow? If so, we should add clarifying text in the document that cautions the RR not to assume the RAMS-R was dropped. I briefly considered requiring the RS to send a RAMS-I for each received RAMS-R. Unfortunately, this then leads to another set of corner cases, and may result in a chatty exchange of messages. We also need to consider how to deterministically differentiate between the initial RMS-R message and subsequent RMS-R messages, particularly in the event of packet loss or (unlikely) re-ordering. This probably leads us to including a monotonically increasing sequence number on the RMS-R. Dropped RMS-R messages should not be a protocol problem, as the first one received will trigger the burst. Subsequent RMS-R messages either change the burst shape or they do not, and they do not trigger additional messages. Similarly, if the initial RMS-I is dropped it will probably trigger an additional RMS-R message. Subsequent RMS-I messages will either be received by the RR or they will not, and they will not trigger additional messages. So, has anybody considered these design points in detail? I have started to go down this path, but it gets complicated quickly. In order to limit the complexity, I suggest that we state that the first received RMS-R triggers a RMS-I. Further RMS-R messages may flow. Further RMS-I messages may also flow, but there is no explicit requirement to send an RMS-I in response to a subsequent RMS-R. Bill VerSteeg --Boundary_(ID_jiY/hiJsyT5x6TNeI5lJIg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Sending of subsequent RAMS-I messages by the RS is not trigged by reception of RAMS-R messages, but by that the server has decided to change information contained in RAMS-I messages, including burst bitrate. Only in the case when the RS decided to change the burst bitrate according to a subsequent RAMS-R message received, the subsequent RAMS-R message indirectly triggers a RAMS-I message. The process to me seems rather simple.
 
BR, YK

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Bill Ver Steeg (versteb)
Sent: Wednesday, April 01, 2009 7:52 PM
To: Bill Ver Steeg (versteb); Zeev Vax; Tom.Van_Caenegem@alcatel-lucent.be; Ali C. Begen (abegen)
Cc: avt@ietf.org
Subject: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multiple RAMS-R messages for the same unicast flow

 

When we added the ability to send more than one RAMS-R message, we opened up a few design points that we now need to consider.

We need to have some nomenclature for describing the "initial RMS-R" and "subsequent RMS-R", so I will start with using those words. Better words would be appreciated.

The first design point I would like to address is what the RS is required to do when it receives an RAMS-R for a burst that is already in flow (aka "subsequent RMS-R"). We stated that the least it could do was "ignore it". Does this imply that there is no requirement to send an RMS-I in response to RMS-R messages referencing an in-progress flow? If so, we should add clarifying text in the document that cautions the RR not to assume the RAMS-R was dropped. I briefly considered requiring the RS to send a RAMS-I for each received RAMS-R. Unfortunately, this then leads to another set of corner cases, and may result in a chatty exchange of messages.

We also need to consider how to deterministically differentiate between the initial RMS-R message and subsequent RMS-R messages, particularly in the event of packet loss or (unlikely) re-ordering. This probably leads us to including a monotonically increasing sequence number on the RMS-R. Dropped RMS-R messages should not be a protocol problem, as the first one received will trigger the burst. Subsequent RMS-R messages either change the burst shape or they do not, and they do not trigger additional messages. Similarly, if the initial RMS-I is dropped it will probably trigger an additional RMS-R message. Subsequent RMS-I messages will either be received by the RR or they will not, and they will not trigger additional messages.

So, has anybody considered these design points in detail? I have started to go down this path, but it gets complicated quickly.

In order to limit the complexity, I suggest that we state that the first received RMS-R triggers a RMS-I. Further RMS-R messages may flow. Further RMS-I messages may also flow, but there is no explicit requirement to send an RMS-I in response to a subsequent RMS-R.

 

Bill VerSteeg

--Boundary_(ID_jiY/hiJsyT5x6TNeI5lJIg)-- From oran@cisco.com Wed Apr 1 18:00:50 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CBB23A6821 for ; Wed, 1 Apr 2009 18:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.616 X-Spam-Level: X-Spam-Status: No, score=-6.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TL-mBI3JC7k8 for ; Wed, 1 Apr 2009 18:00:48 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id DC6A53A67CC for ; Wed, 1 Apr 2009 18:00:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,309,1235952000"; d="scan'208";a="165302534" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-1.cisco.com with ESMTP; 02 Apr 2009 01:01:49 +0000 Received: from stealth-10-32-245-156.cisco.com ([10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id n3212pNm021328; Wed, 1 Apr 2009 17:02:52 -0800 Message-Id: <99D207F9-2F80-48E8-95B0-DCE28D43B469@cisco.com> From: David R Oran To: "Bill Ver Steeg (versteb)" In-Reply-To: <81B9B88E2F9D574AA5328A85547CDE91EC1CAA@xmb-rtp-21d.amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 1 Apr 2009 21:01:46 -0400 References: <81B9B88E2F9D574AA5328A85547CDE91EC162E@xmb-rtp-21d.amer.cisco.com><5177B2A348E4B64EAD7D589A027892D96A29EAB21D@NA-EXMSG-C111.redmond.corp.microsoft.com> <81B9B88E2F9D574AA5328A85547CDE91EC1C34@xmb-rtp-21d.amer.cisco.com> <81B9B88E2F9D574AA5328A85547CDE91EC1CAA@xmb-rtp-21d.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5588; t=1238634173; x=1239498173; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[AVT]=20Rapid=20Acquisition=20of=20Mult icast=20Streams=20(RAMS)=20-=20multiple=20RAMS-R=20messages= 20for=20the=20same=20unicast=20flow |Sender:=20 |To:=20=22Bill=20Ver=20Steeg=20(versteb)=22=20; bh=WFjcwXrohb+Zsag3o9ACLzzHeXpWbCHn3avT/0axTMY=; b=imza1edfjmap83ACglkbZS533JH9JVm7KGhjFPF7hvKKQcnklKc/55uk3+ bsRkJxL3N8H9jca0YtgEf/+5z4YHIQRKfF7jtBWzUcDwgWzwrVYl+9I9Ua20 c9sqR0egin; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: Tom.Van_Caenegem@alcatel-lucent.be, avt@ietf.org, Zeev Vax Subject: Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multiple RAMS-R messages for the same unicast flow X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 01:00:50 -0000 On Apr 1, 2009, at 7:52 PM, Bill Ver Steeg (versteb) wrote: > > When we added the ability to send more than one RAMS-R message, we > opened up a few design points that we now need to consider. > > We need to have some nomenclature for describing the "initial RMS-R" > and "subsequent RMS-R", so I will start with using those words. > Better words would be appreciated. > > The first design point I would like to address is what the RS is > required to do when it receives an RAMS-R for a burst that is > already in flow (aka "subsequent RMS-R"). We stated that the least > it could do was "ignore it". Does this imply that there is no > requirement to send an RMS-I in response to RMS-R messages > referencing an in-progress flow? > No. In order to have rational state machines the RS MUST reply to each RAMS-R with a RAMS-I. Whether there is a "Reference to the in-progress flow" is a secondary issue. The key point is that semantically the RAMS-I returned in response to a RAMS-R can be (from a state machine point of view) no different from the first, because either the RS may never have received the first RAMS-R, or conversely the RAMS-I sent in response to te earlier RAMS-R might have been lost. This is how protocols utilizing idempotency semantics have to operate. > If so, we should add clarifying text in the document that cautions > the RR not to assume the RAMS-R was dropped. > Well, "caution" is not the term I would use. Just show the state machines and the whole thins should be obvious (at least it would be to me). > I briefly considered requiring the RS to send a RAMS-I for each > received RAMS-R. Unfortunately, this then leads to another set of > corner cases, and may result in a chatty exchange of messages. > Uh, I don't think so. The only time a message other than the two needed to initiate a burst is sent is if a message is lost. Worst case this is one extra message - if the sequence is RAMS-R->RAMS- I(lost)...RAMS-R(retry)->RAMS-I. As long as none of the fields in the messages have themselves non- idempotent semantics (e.g. by being deltas rather than absolute values) I fail to see what corner cases arise. > We also need to consider how to deterministically differentiate > between the initial RMS-R message and subsequent RMS-R messages, > particularly in the event of packet loss or (unlikely) re-ordering. > I would argue that we in fact don't need to do this as long as we wait long enough for retransmission to avoid delayed duplicates or messages crossing on the wire. If that is that is the case I would much prefer that we use transaction ids instead of or in addition to sequence numbers. But I think neither is in fact necessary In low-probability case the RAMS-R messages permute, the client can always recover by sending another RAMS-R with the burst rate it wants. What this does point out however, is that we should have either DIFFERENT fields for the values in the RAMS-I that are meant to echo/ confirm values requested by the RAMS-R, versus those set unilaterally by the server, or use a DIFFERENT message type for a unilateral RAMs- (something other than -I) generate by the RS that was not triggered by receipt of a RAMS-R. Either would work. > This probably leads us to including a monotonically increasing > sequence number on the RMS-R. > This begs the question of who throws away state when. For example, if I try to do a RAMS on multicast group 1, give up, try to do a RAMS on multicast group 2, give up, and then try to do a RAMS on group 1 again. What sequence number does the last of these RAMS-R message have? Why would it be different than if I never had done the RAMS-R on flow 2? How can the RS possibly know which case obtains? I think we're actually making the protocol much more complicated and with more error states by introducing sequencing to avoid the problems that would arise from permuted messages on a retransmission time-out. It's just so much easier to ensure all the protocol semantics are idempotent. > Dropped RMS-R messages should not be a protocol problem, as the > first one received will trigger the burst. Subsequent RMS-R messages > either change the burst shape or they do not, and they do not > trigger additional messages. > Really? Not if they have sequence numbers and the RS failed to forget the state of an earlier burst. > Similarly, if the initial RMS-I is dropped it will probably trigger > an additional RMS-R message. Subsequent RMS-I messages will either > be received by the RR or they will not, and they will not trigger > additional messages. > > So, has anybody considered these design points in detail? > Yes. Not for RAMS, but for numerous other request/response protocols that operate idempotently. > I have started to go down this path, but it gets complicated quickly. > So you're discovering :-) > In order to limit the complexity, I suggest that we state that the > first received RMS-R triggers a RMS-I. Further RMS-R messages may > flow. Further RMS-I messages may also flow, but there is no explicit > requirement to send an RMS-I in response to a subsequent RMS-R. > No, this is a bug. It never allows the client to ascertain the state of the server. DaveO. > > Bill VerSteeg > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From versteb@cisco.com Wed Apr 1 18:01:06 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E4E63A67F2 for ; Wed, 1 Apr 2009 18:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.136 X-Spam-Level: X-Spam-Status: No, score=-6.136 tagged_above=-999 required=5 tests=[AWL=-0.422, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcMd4NZTSpvg for ; Wed, 1 Apr 2009 18:01:04 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CA7B03A67CC for ; Wed, 1 Apr 2009 18:01:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,309,1235952000"; d="scan'208,217";a="278500103" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-6.cisco.com with ESMTP; 02 Apr 2009 01:02:05 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n321256J029924; Wed, 1 Apr 2009 21:02:05 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n32124DH016767; Thu, 2 Apr 2009 01:02:05 GMT Received: from xmb-rtp-21d.amer.cisco.com ([64.102.31.116]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 21:01:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B32E.8E5F0E24" Date: Wed, 1 Apr 2009 21:01:28 -0400 Message-ID: <81B9B88E2F9D574AA5328A85547CDE91EC1CDA@xmb-rtp-21d.amer.cisco.com> In-Reply-To: <9FBAA863185D42098EB4FA0C7D117E25@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multipleRAMS-R messages for the same unicast flow Thread-Index: AcmyMO1Vf+4hrMHmQjCLzeIX0fZkSAAt6jegAApONVAABEpf4AACVnxAAAB3z7A= References: <81B9B88E2F9D574AA5328A85547CDE91EC162E@xmb-rtp-21d.amer.cisco.com> <5177B2A348E4B64EAD7D589A027892D96A29EAB21D@NA-EXMSG-C111.redmond.corp.microsoft.com> <81B9B88E2F9D574AA5328A85547CDE91EC1C34@xmb-rtp-21d.amer.cisco.com> <81B9B88E2F9D574AA5328A85547CDE91EC1CAA@xmb-rtp-21d.amer.cisco.com> <9FBAA863185D42098EB4FA0C7D117E25@china.huawei.com> From: "Bill Ver Steeg (versteb)" To: "Ye-Kui Wang" , "Zeev Vax" , , "Ali C. Begen (abegen)" X-OriginalArrivalTime: 02 Apr 2009 01:01:30.0100 (UTC) FILETIME=[8EB71340:01C9B32E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12471; t=1238634125; x=1239498125; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=versteb@cisco.com; z=From:=20=22Bill=20Ver=20Steeg=20(versteb)=22=20 |Subject:=20RE=3A=20[AVT]=20Rapid=20Acquisition=20of=20Mult icast=20Streams=20(RAMS)=20-=20multipleRAMS-R=20messages=20f or=20the=20same=20unicast=20flow |Sender:=20 |To:=20=22Ye-Kui=20Wang=22=20,=20=22Z eev=20Vax=22=20,=0A=20=20=20=20=20=20 =20=20,=0A=20=20=20=20=2 0=20=20=20=22Ali=20C.=20Begen=20(abegen)=22=20; bh=pInv4mKxwLJ0xfMEYCX6/6Yxzzygbrfzvw8smvjFqGs=; b=p3jo4/LVC9Mmyo29mTmyIoV6T0joWxfPj8GCjDOI6JSgIJtQOVleVsiQbL 35H7OTnQm5w4CA4ngbExweojbTlXDPRM6MG5imNrVJPwDe4or40fpgT+9/yo Q8GP9uzxIN; Authentication-Results: rtp-dkim-1; header.From=versteb@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: avt@ietf.org Subject: Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multipleRAMS-R messages for the same unicast flow X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 01:01:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B32E.8E5F0E24 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks YK- =20 This is also where I ended up. Simple is good. =20 I will be sure that the text is clear in this regard. =20 bvs =20 ________________________________ From: Ye-Kui Wang [mailto:yekuiwang@huawei.com]=20 Sent: Wednesday, April 01, 2009 8:53 PM To: Bill Ver Steeg (versteb); 'Zeev Vax'; Tom.Van_Caenegem@alcatel-lucent.be; Ali C. Begen (abegen) Cc: avt@ietf.org Subject: RE: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multipleRAMS-R messages for the same unicast flow Sending of subsequent RAMS-I messages by the RS is not trigged by reception of RAMS-R messages, but by that the server has decided to change information contained in RAMS-I messages, including burst bitrate. Only in the case when the RS decided to change the burst bitrate according to a subsequent RAMS-R message received, the subsequent RAMS-R message indirectly triggers a RAMS-I message. The process to me seems rather simple.=20 =20 BR, YK ________________________________ From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Bill Ver Steeg (versteb) Sent: Wednesday, April 01, 2009 7:52 PM To: Bill Ver Steeg (versteb); Zeev Vax; Tom.Van_Caenegem@alcatel-lucent.be; Ali C. Begen (abegen) Cc: avt@ietf.org Subject: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multiple RAMS-R messages for the same unicast flow =09 =09 =20 When we added the ability to send more than one RAMS-R message, we opened up a few design points that we now need to consider. We need to have some nomenclature for describing the "initial RMS-R" and "subsequent RMS-R", so I will start with using those words. Better words would be appreciated. The first design point I would like to address is what the RS is required to do when it receives an RAMS-R for a burst that is already in flow (aka "subsequent RMS-R"). We stated that the least it could do was "ignore it". Does this imply that there is no requirement to send an RMS-I in response to RMS-R messages referencing an in-progress flow? If so, we should add clarifying text in the document that cautions the RR not to assume the RAMS-R was dropped. I briefly considered requiring the RS to send a RAMS-I for each received RAMS-R. Unfortunately, this then leads to another set of corner cases, and may result in a chatty exchange of messages. We also need to consider how to deterministically differentiate between the initial RMS-R message and subsequent RMS-R messages, particularly in the event of packet loss or (unlikely) re-ordering. This probably leads us to including a monotonically increasing sequence number on the RMS-R. Dropped RMS-R messages should not be a protocol problem, as the first one received will trigger the burst. Subsequent RMS-R messages either change the burst shape or they do not, and they do not trigger additional messages. Similarly, if the initial RMS-I is dropped it will probably trigger an additional RMS-R message. Subsequent RMS-I messages will either be received by the RR or they will not, and they will not trigger additional messages. So, has anybody considered these design points in detail? I have started to go down this path, but it gets complicated quickly. In order to limit the complexity, I suggest that we state that the first received RMS-R triggers a RMS-I. Further RMS-R messages may flow. Further RMS-I messages may also flow, but there is no explicit requirement to send an RMS-I in response to a subsequent RMS-R. =20 Bill VerSteeg ------_=_NextPart_001_01C9B32E.8E5F0E24 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks YK-
 
This is also where I ended up. Simple is=20 good.
 
I will be sure that the text is clear in this=20 regard.
 
bvs
 

From: Ye-Kui Wang = [mailto:yekuiwang@huawei.com]=20
Sent: Wednesday, April 01, 2009 8:53 PM
To: Bill = Ver Steeg=20 (versteb); 'Zeev Vax'; Tom.Van_Caenegem@alcatel-lucent.be; Ali C. Begen=20 (abegen)
Cc: avt@ietf.org
Subject: RE: [AVT] Rapid=20 Acquisition of Multicast Streams (RAMS) - multipleRAMS-R messages for = the same=20 unicast flow

Sending of subsequent RAMS-I messages by the RS = is not trigged by reception of RAMS-R messages, but by that = the server=20 has decided to change information contained in RAMS-I messages, = including burst=20 bitrate. Only in the case when the RS decided to change the burst = bitrate=20 according to a subsequent RAMS-R message received, the=20 subsequent RAMS-R message indirectly triggers a RAMS-I message. The = process=20 to me seems rather simple.
 
BR, YK

From: avt-bounces@ietf.org=20 [mailto:avt-bounces@ietf.org] On Behalf Of Bill Ver Steeg=20 (versteb)
Sent: Wednesday, April 01, 2009 7:52 = PM
To: Bill=20 Ver Steeg (versteb); Zeev Vax; Tom.Van_Caenegem@alcatel-lucent.be; Ali = C.=20 Begen (abegen)
Cc: avt@ietf.org
Subject: [AVT] = Rapid=20 Acquisition of Multicast Streams (RAMS) - multiple RAMS-R messages for = the=20 same unicast flow

 

When we added the ability to send more than one RAMS-R message, we = opened=20 up a few design points that we now need to consider.

We need to have some nomenclature for describing the "initial = RMS-R" and=20 "subsequent RMS-R", so I will start with using those words. Better = words would=20 be appreciated.

The first design point I would like to address is what the RS is = required=20 to do when it receives an RAMS-R for a burst that is already in flow = (aka=20 "subsequent RMS-R"). We stated that the least it could do was "ignore = it".=20 Does this imply that there is no requirement to send an RMS-I in = response to=20 RMS-R messages referencing an in-progress flow? If so, we should add=20 clarifying text in the document that cautions the RR not to assume the = RAMS-R=20 was dropped. I briefly considered requiring the RS to send a RAMS-I = for each=20 received RAMS-R. Unfortunately, this then leads to another set of = corner=20 cases, and may result in a chatty exchange of messages.

We also need to consider how to deterministically differentiate = between the=20 initial RMS-R message and subsequent RMS-R messages, particularly in = the event=20 of packet loss or (unlikely) re-ordering. This probably leads us to = including=20 a monotonically increasing sequence number on the RMS-R. Dropped RMS-R messages should not be a = protocol=20 problem, as the first one received will trigger the burst. Subsequent = RMS-R=20 messages either change the burst shape or they do not, and they do not = trigger=20 additional messages. Similarly, if the initial RMS-I is dropped it = will=20 probably trigger an additional RMS-R message. Subsequent RMS-I = messages will=20 either be received by the RR or they will not, and they will not = trigger=20 additional messages.

So, has anybody considered these design points in detail? I have = started to=20 go down this path, but it gets complicated quickly.

In order to limit the complexity, I suggest that we state that the=20 first received RMS-R = triggers a=20 RMS-I. Further RMS-R messages may flow. Further RMS-I messages may = also flow,=20 but there is no explicit requirement to send an RMS-I in response to a = subsequent RMS-R.

 

Bill VerSteeg

------_=_NextPart_001_01C9B32E.8E5F0E24-- From versteb@cisco.com Wed Apr 1 18:03:32 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E08E3A6C49 for ; Wed, 1 Apr 2009 18:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.11 X-Spam-Level: X-Spam-Status: No, score=-6.11 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id katLu4Be9ViT for ; Wed, 1 Apr 2009 18:03:30 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 985133A6BAF for ; Wed, 1 Apr 2009 18:03:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,309,1235952000"; d="scan'208,217";a="278501136" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-6.cisco.com with ESMTP; 02 Apr 2009 01:04:31 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3214UUv026713; Wed, 1 Apr 2009 21:04:30 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3214UGP017555; Thu, 2 Apr 2009 01:04:30 GMT Received: from xmb-rtp-21d.amer.cisco.com ([64.102.31.116]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 21:04:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B32E.FA2CE38D" Date: Wed, 1 Apr 2009 21:04:29 -0400 Message-ID: <81B9B88E2F9D574AA5328A85547CDE91EC1CDC@xmb-rtp-21d.amer.cisco.com> In-Reply-To: <81B9B88E2F9D574AA5328A85547CDE91EC1CDA@xmb-rtp-21d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Rapid Acquisition of Multicast Streams (RAMS) -multipleRAMS-R messages for the same unicast flow Thread-Index: AcmyMO1Vf+4hrMHmQjCLzeIX0fZkSAAt6jegAApONVAABEpf4AACVnxAAAB3z7AAACdp0A== References: <81B9B88E2F9D574AA5328A85547CDE91EC162E@xmb-rtp-21d.amer.cisco.com><5177B2A348E4B64EAD7D589A027892D96A29EAB21D@NA-EXMSG-C111.redmond.corp.microsoft.com><81B9B88E2F9D574AA5328A85547CDE91EC1C34@xmb-rtp-21d.amer.cisco.com><81B9B88E2F9D574AA5328A85547CDE91EC1CAA@xmb-rtp-21d.amer.cisco.com><9FBAA863185D42098EB4FA0C7D117E25@china.huawei.com> <81B9B88E2F9D574AA5328A85547CDE91EC1CDA@xmb-rtp-21d.amer.cisco.com> From: "Bill Ver Steeg (versteb)" To: "Bill Ver Steeg (versteb)" , "Ye-Kui Wang" , "Zeev Vax" , , "Ali C. Begen (abegen)" X-OriginalArrivalTime: 02 Apr 2009 01:04:30.0666 (UTC) FILETIME=[FA5742A0:01C9B32E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14477; t=1238634270; x=1239498270; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=versteb@cisco.com; z=From:=20=22Bill=20Ver=20Steeg=20(versteb)=22=20 |Subject:=20RE=3A=20[AVT]=20Rapid=20Acquisition=20of=20Mult icast=20Streams=20(RAMS)=20-multipleRAMS-R=20messages=20for= 20the=20same=20unicast=20flow |Sender:=20 |To:=20=22Bill=20Ver=20Steeg=20(versteb)=22=20,=0A=20=20=20=20=20=20=20=20=22Ye-Kui=20Wang=22=20,=0A=20=20=20=20=20=20=20=20=22Zeev=20Vax= 22=20,=0A=20=20=20=20=20=20=20=20,=0A=20=20=20=20=20=20=20=20 =22Ali=20C.=20Begen=20(abegen)=22=20; bh=+1HHgaJv5XX63539D1vHSX/KgAmm02ICtwEKwW0HHV0=; b=P2nsBfGyKmtqWcWalyKhiiD+q7V0YRict5U1AwlNPX2GqZ7TyM9BiIlfkE 2upjMYiqsEPml6zFEctBPI7ouNp4p2c7Y8PkJimu7anJWwD5hLSOORXrQSRJ +/np9oEtXc; Authentication-Results: rtp-dkim-2; header.From=versteb@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: avt@ietf.org Subject: Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) -multipleRAMS-R messages for the same unicast flow X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 01:03:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B32E.FA2CE38D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Based on further responses, the jury is still out. =20 I will mark this section of the text with an editor's note and we will continue the discussion. =20 bvs ________________________________ From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Bill Ver Steeg (versteb) Sent: Wednesday, April 01, 2009 9:01 PM To: Ye-Kui Wang; Zeev Vax; Tom.Van_Caenegem@alcatel-lucent.be; Ali C. Begen (abegen) Cc: avt@ietf.org Subject: Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) -multipleRAMS-R messages for the same unicast flow Thanks YK- =20 This is also where I ended up. Simple is good. =20 I will be sure that the text is clear in this regard. =20 bvs =20 ________________________________ From: Ye-Kui Wang [mailto:yekuiwang@huawei.com]=20 Sent: Wednesday, April 01, 2009 8:53 PM To: Bill Ver Steeg (versteb); 'Zeev Vax'; Tom.Van_Caenegem@alcatel-lucent.be; Ali C. Begen (abegen) Cc: avt@ietf.org Subject: RE: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multipleRAMS-R messages for the same unicast flow Sending of subsequent RAMS-I messages by the RS is not trigged by reception of RAMS-R messages, but by that the server has decided to change information contained in RAMS-I messages, including burst bitrate. Only in the case when the RS decided to change the burst bitrate according to a subsequent RAMS-R message received, the subsequent RAMS-R message indirectly triggers a RAMS-I message. The process to me seems rather simple.=20 =20 BR, YK ________________________________ From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Bill Ver Steeg (versteb) Sent: Wednesday, April 01, 2009 7:52 PM To: Bill Ver Steeg (versteb); Zeev Vax; Tom.Van_Caenegem@alcatel-lucent.be; Ali C. Begen (abegen) Cc: avt@ietf.org Subject: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multiple RAMS-R messages for the same unicast flow =09 =09 =20 When we added the ability to send more than one RAMS-R message, we opened up a few design points that we now need to consider. We need to have some nomenclature for describing the "initial RMS-R" and "subsequent RMS-R", so I will start with using those words. Better words would be appreciated. The first design point I would like to address is what the RS is required to do when it receives an RAMS-R for a burst that is already in flow (aka "subsequent RMS-R"). We stated that the least it could do was "ignore it". Does this imply that there is no requirement to send an RMS-I in response to RMS-R messages referencing an in-progress flow? If so, we should add clarifying text in the document that cautions the RR not to assume the RAMS-R was dropped. I briefly considered requiring the RS to send a RAMS-I for each received RAMS-R. Unfortunately, this then leads to another set of corner cases, and may result in a chatty exchange of messages. We also need to consider how to deterministically differentiate between the initial RMS-R message and subsequent RMS-R messages, particularly in the event of packet loss or (unlikely) re-ordering. This probably leads us to including a monotonically increasing sequence number on the RMS-R. Dropped RMS-R messages should not be a protocol problem, as the first one received will trigger the burst. Subsequent RMS-R messages either change the burst shape or they do not, and they do not trigger additional messages. Similarly, if the initial RMS-I is dropped it will probably trigger an additional RMS-R message. Subsequent RMS-I messages will either be received by the RR or they will not, and they will not trigger additional messages. So, has anybody considered these design points in detail? I have started to go down this path, but it gets complicated quickly. In order to limit the complexity, I suggest that we state that the first received RMS-R triggers a RMS-I. Further RMS-R messages may flow. Further RMS-I messages may also flow, but there is no explicit requirement to send an RMS-I in response to a subsequent RMS-R. =20 Bill VerSteeg ------_=_NextPart_001_01C9B32E.FA2CE38D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Based on further responses, the jury is still=20 out.
 
I will mark this section of the text with an = editor's note=20 and we will continue the discussion.
 
bvs

From: avt-bounces@ietf.org=20 [mailto:avt-bounces@ietf.org] On Behalf Of Bill Ver Steeg=20 (versteb)
Sent: Wednesday, April 01, 2009 9:01 = PM
To: Ye-Kui=20 Wang; Zeev Vax; Tom.Van_Caenegem@alcatel-lucent.be; Ali C. Begen=20 (abegen)
Cc: avt@ietf.org
Subject: Re: [AVT] Rapid=20 Acquisition of Multicast Streams (RAMS) -multipleRAMS-R messages for the = same=20 unicast flow

Thanks YK-
 
This is also where I ended up. Simple is=20 good.
 
I will be sure that the text is clear in this=20 regard.
 
bvs
 

From: Ye-Kui Wang = [mailto:yekuiwang@huawei.com]=20
Sent: Wednesday, April 01, 2009 8:53 PM
To: Bill = Ver Steeg=20 (versteb); 'Zeev Vax'; Tom.Van_Caenegem@alcatel-lucent.be; Ali C. Begen=20 (abegen)
Cc: avt@ietf.org
Subject: RE: [AVT] Rapid=20 Acquisition of Multicast Streams (RAMS) - multipleRAMS-R messages for = the same=20 unicast flow

Sending of subsequent RAMS-I messages by the RS = is not trigged by reception of RAMS-R messages, but by that = the server=20 has decided to change information contained in RAMS-I messages, = including burst=20 bitrate. Only in the case when the RS decided to change the burst = bitrate=20 according to a subsequent RAMS-R message received, the=20 subsequent RAMS-R message indirectly triggers a RAMS-I message. The = process=20 to me seems rather simple.
 
BR, YK

From: avt-bounces@ietf.org=20 [mailto:avt-bounces@ietf.org] On Behalf Of Bill Ver Steeg=20 (versteb)
Sent: Wednesday, April 01, 2009 7:52 = PM
To: Bill=20 Ver Steeg (versteb); Zeev Vax; Tom.Van_Caenegem@alcatel-lucent.be; Ali = C.=20 Begen (abegen)
Cc: avt@ietf.org
Subject: [AVT] = Rapid=20 Acquisition of Multicast Streams (RAMS) - multiple RAMS-R messages for = the=20 same unicast flow

 

When we added the ability to send more than one RAMS-R message, we = opened=20 up a few design points that we now need to consider.

We need to have some nomenclature for describing the "initial = RMS-R" and=20 "subsequent RMS-R", so I will start with using those words. Better = words would=20 be appreciated.

The first design point I would like to address is what the RS is = required=20 to do when it receives an RAMS-R for a burst that is already in flow = (aka=20 "subsequent RMS-R"). We stated that the least it could do was "ignore = it".=20 Does this imply that there is no requirement to send an RMS-I in = response to=20 RMS-R messages referencing an in-progress flow? If so, we should add=20 clarifying text in the document that cautions the RR not to assume the = RAMS-R=20 was dropped. I briefly considered requiring the RS to send a RAMS-I = for each=20 received RAMS-R. Unfortunately, this then leads to another set of = corner=20 cases, and may result in a chatty exchange of messages.

We also need to consider how to deterministically differentiate = between the=20 initial RMS-R message and subsequent RMS-R messages, particularly in = the event=20 of packet loss or (unlikely) re-ordering. This probably leads us to = including=20 a monotonically increasing sequence number on the RMS-R. Dropped RMS-R messages should not be a = protocol=20 problem, as the first one received will trigger the burst. Subsequent = RMS-R=20 messages either change the burst shape or they do not, and they do not = trigger=20 additional messages. Similarly, if the initial RMS-I is dropped it = will=20 probably trigger an additional RMS-R message. Subsequent RMS-I = messages will=20 either be received by the RR or they will not, and they will not = trigger=20 additional messages.

So, has anybody considered these design points in detail? I have = started to=20 go down this path, but it gets complicated quickly.

In order to limit the complexity, I suggest that we state that the=20 first received RMS-R = triggers a=20 RMS-I. Further RMS-R messages may flow. Further RMS-I messages may = also flow,=20 but there is no explicit requirement to send an RMS-I in response to a = subsequent RMS-R.

 

Bill VerSteeg

------_=_NextPart_001_01C9B32E.FA2CE38D-- From yekuiwang@huawei.com Wed Apr 1 19:32:21 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E84D3A67DA for ; Wed, 1 Apr 2009 19:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rLnURUuVAyH for ; Wed, 1 Apr 2009 19:32:20 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 516F03A6957 for ; Wed, 1 Apr 2009 19:32:20 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHG00AB8CFKE8@usaga04-in.huawei.com> for avt@ietf.org; Wed, 01 Apr 2009 21:33:21 -0500 (CDT) Received: from W90946 ([10.51.0.20]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KHG007JJCFGZB@usaga04-in.huawei.com> for avt@ietf.org; Wed, 01 Apr 2009 21:33:20 -0500 (CDT) Date: Wed, 01 Apr 2009 22:33:15 -0400 From: Ye-Kui Wang In-reply-to: <99D207F9-2F80-48E8-95B0-DCE28D43B469@cisco.com> To: 'David R Oran' , "'Bill Ver Steeg (versteb)'" Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcmzLqoS720oUMdWTz2E9nK2pjE+swACy6lg References: <81B9B88E2F9D574AA5328A85547CDE91EC162E@xmb-rtp-21d.amer.cisco.com> <5177B2A348E4B64EAD7D589A027892D96A29EAB21D@NA-EXMSG-C111.redmond.corp.microsoft.com> <81B9B88E2F9D574AA5328A85547CDE91EC1C34@xmb-rtp-21d.amer.cisco.com> <81B9B88E2F9D574AA5328A85547CDE91EC1CAA@xmb-rtp-21d.amer.cisco.com> <99D207F9-2F80-48E8-95B0-DCE28D43B469@cisco.com> Cc: Tom.Van_Caenegem@alcatel-lucent.be, avt@ietf.org, 'Zeev Vax' Subject: Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multipleRAMS-R messages for the same unicast flow X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 02:32:21 -0000 I am leaving all but the last comment from Dave for Bill. > > In order to limit the complexity, I suggest that we state that the > > first received RMS-R triggers a RMS-I. Further RMS-R messages may > > flow. Further RMS-I messages may also flow, but there is no > explicit > > requirement to send an RMS-I in response to a subsequent RMS-R. > > > No, this is a bug. It never allows the client to ascertain the state > of the server. This relates to the discussion about loss of RMS-I message during Bill's presentation in San Francisco. My understanding then and also now is as follows. If during the burst, the burst bitrate is changed by the RS due to whatever reason, and the RS has not sent an RMS-I or the sent RMS-I was lost, it should not be a disater to the client as it knows the its buffer status, and it can also know the change of the burst bitrate and even the value of the changed burst bitrate if it wants. So why there is a problem here? BR, YK > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of David R Oran > Sent: Wednesday, April 01, 2009 9:02 PM > To: Bill Ver Steeg (versteb) > Cc: Tom.Van_Caenegem@alcatel-lucent.be; avt@ietf.org; Zeev Vax > Subject: Re: [AVT] Rapid Acquisition of Multicast Streams > (RAMS) - multipleRAMS-R messages for the same unicast flow > > > On Apr 1, 2009, at 7:52 PM, Bill Ver Steeg (versteb) wrote: > > > > > When we added the ability to send more than one RAMS-R message, we > > opened up a few design points that we now need to consider. > > > > We need to have some nomenclature for describing the > "initial RMS-R" > > and "subsequent RMS-R", so I will start with using those words. > > Better words would be appreciated. > > > > The first design point I would like to address is what the RS is > > required to do when it receives an RAMS-R for a burst that > is already > > in flow (aka "subsequent RMS-R"). We stated that the least > it could do > > was "ignore it". Does this imply that there is no > requirement to send > > an RMS-I in response to RMS-R messages referencing an in-progress > > flow? > > > No. In order to have rational state machines the RS MUST > reply to each RAMS-R with a RAMS-I. Whether there is a > "Reference to the in-progress flow" is a secondary issue. The > key point is that semantically the RAMS-I returned in > response to a RAMS-R can be (from a state machine point of > view) no different from the first, because either the RS may > never have received the first RAMS-R, or conversely the > RAMS-I sent in response to te earlier RAMS-R might have been lost. > > This is how protocols utilizing idempotency semantics have to operate. > > If so, we should add clarifying text in the document that > cautions the > > RR not to assume the RAMS-R was dropped. > > > Well, "caution" is not the term I would use. Just show the > state machines and the whole thins should be obvious (at > least it would be to me). > > I briefly considered requiring the RS to send a RAMS-I for each > > received RAMS-R. Unfortunately, this then leads to another set of > > corner cases, and may result in a chatty exchange of messages. > > > Uh, I don't think so. The only time a message other than the > two needed to initiate a burst is sent is if a message is > lost. Worst case this is one extra message - if the sequence > is RAMS-R->RAMS- I(lost)...RAMS-R(retry)->RAMS-I. > As long as none of the fields in the messages have themselves > non- idempotent semantics (e.g. by being deltas rather than absolute > values) I fail to see what corner cases arise. > > We also need to consider how to deterministically differentiate > > between the initial RMS-R message and subsequent RMS-R messages, > > particularly in the event of packet loss or (unlikely) re-ordering. > > > I would argue that we in fact don't need to do this as long > as we wait long enough for retransmission to avoid delayed > duplicates or messages crossing on the wire. If that is that > is the case I would much prefer that we use transaction ids > instead of or in addition to sequence numbers. But I think > neither is in fact necessary > > In low-probability case the RAMS-R messages permute, the > client can always recover by sending another RAMS-R with the > burst rate it wants. > > What this does point out however, is that we should have > either DIFFERENT fields for the values in the RAMS-I that are > meant to echo/ confirm values requested by the RAMS-R, versus > those set unilaterally by the server, or use a DIFFERENT > message type for a unilateral RAMs- (something other than -I) > generate by the RS that was not triggered by receipt of a RAMS-R. > > Either would work. > > > > This probably leads us to including a monotonically increasing > > sequence number on the RMS-R. > > > This begs the question of who throws away state when. For > example, if I try to do a RAMS on multicast group 1, give up, > try to do a RAMS on multicast group 2, give up, and then try > to do a RAMS on group 1 again. What sequence number does the > last of these RAMS-R message have? Why would it be different > than if I never had done the RAMS-R on flow 2? How can the RS > possibly know which case obtains? > > I think we're actually making the protocol much more > complicated and with more error states by introducing > sequencing to avoid the problems that would arise from > permuted messages on a retransmission time-out. > It's just so much easier to ensure all the protocol semantics > are idempotent. > > Dropped RMS-R messages should not be a protocol problem, > as the first > > one received will trigger the burst. Subsequent RMS-R > messages either > > change the burst shape or they do not, and they do not trigger > > additional messages. > > > Really? Not if they have sequence numbers and the RS failed > to forget the state of an earlier burst. > > Similarly, if the initial RMS-I is dropped it will probably > trigger an > > additional RMS-R message. Subsequent RMS-I messages will either be > > received by the RR or they will not, and they will not trigger > > additional messages. > > > > So, has anybody considered these design points in detail? > > > Yes. Not for RAMS, but for numerous other request/response > protocols that operate idempotently. > > I have started to go down this path, but it gets > complicated quickly. > > > So you're discovering :-) > > In order to limit the complexity, I suggest that we state that the > > first received RMS-R triggers a RMS-I. Further RMS-R messages may > > flow. Further RMS-I messages may also flow, but there is no > explicit > > requirement to send an RMS-I in response to a subsequent RMS-R. > > > No, this is a bug. It never allows the client to ascertain the state > of the server. > > DaveO. > > > > > Bill VerSteeg > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From oran@cisco.com Wed Apr 1 19:37:57 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E558C3A6872 for ; Wed, 1 Apr 2009 19:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.616 X-Spam-Level: X-Spam-Status: No, score=-6.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EAtMXrUr+yE for ; Wed, 1 Apr 2009 19:37:56 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B3D8F3A67DA for ; Wed, 1 Apr 2009 19:37:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,310,1235952000"; d="scan'208";a="149739632" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-2.cisco.com with ESMTP; 02 Apr 2009 02:38:55 +0000 Received: from stealth-10-32-245-156.cisco.com ([10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id n322dvQE025167; Wed, 1 Apr 2009 18:39:58 -0800 Message-Id: <23E5CE61-6429-48D7-AF3F-89726BCC2583@cisco.com> From: David R Oran To: Ye-Kui Wang In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 1 Apr 2009 22:38:52 -0400 References: <81B9B88E2F9D574AA5328A85547CDE91EC162E@xmb-rtp-21d.amer.cisco.com> <5177B2A348E4B64EAD7D589A027892D96A29EAB21D@NA-EXMSG-C111.redmond.corp.microsoft.com> <81B9B88E2F9D574AA5328A85547CDE91EC1C34@xmb-rtp-21d.amer.cisco.com> <81B9B88E2F9D574AA5328A85547CDE91EC1CAA@xmb-rtp-21d.amer.cisco.com> <99D207F9-2F80-48E8-95B0-DCE28D43B469@cisco.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7891; t=1238639999; x=1239503999; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[AVT]=20Rapid=20Acquisition=20of=20Mult icast=20Streams=20(RAMS)=20-=20multipleRAMS-R=20messages=20f or=20the=20same=20unicast=20flow |Sender:=20 |To:=20Ye-Kui=20Wang=20; bh=tEedpumZghoRB0AG/5mGFaHMaB3+jPgt46BFzlb6gMI=; b=iz1z0RDtthLyY2yG0wnIE2WAdlpMBmSBmkEeVqWp0CP67TOePjX4MD4JdF nxQy+4LkvA6VFeZOmu+Nydyu9RRiKLVhuQvbt1EgftFa220W1r2Qvh1wPpKG Ii/5fcd4/P; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: Tom.Van_Caenegem@alcatel-lucent.be, avt@ietf.org, "'Bill Ver Steeg \(versteb\)'" , 'Zeev Vax' Subject: Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multipleRAMS-R messages for the same unicast flow X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 02:37:58 -0000 On Apr 1, 2009, at 10:33 PM, Ye-Kui Wang wrote: > > I am leaving all but the last comment from Dave for Bill. > >>> In order to limit the complexity, I suggest that we state that the >>> first received RMS-R triggers a RMS-I. Further RMS-R messages may >>> flow. Further RMS-I messages may also flow, but there is no >> explicit >>> requirement to send an RMS-I in response to a subsequent RMS-R. >>> >> No, this is a bug. It never allows the client to ascertain the state >> of the server. > > This relates to the discussion about loss of RMS-I message during > Bill's > presentation in San Francisco. My understanding then and also now is > as > follows. If during the burst, the burst bitrate is changed by the RS > due to > whatever reason, and the RS has not sent an RMS-I or the sent RMS-I > was > lost, it should not be a disater to the client as it knows the its > buffer > status, and it can also know the change of the burst bitrate and > even the > value of the changed burst bitrate if it wants. So why there is a > problem > here? > The client doesn't know if the burst is going to start or not, or if the RS aborted the burst, or finished it. The client can't tell whether the RS failed to send an RAMS-I because it lost the RAMS-R or because it thought it was redundant - in a client/server protocol each request needs to be replied to with a response for the state machines to clean up correctly. > BR, YK > > >> -----Original Message----- >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On >> Behalf Of David R Oran >> Sent: Wednesday, April 01, 2009 9:02 PM >> To: Bill Ver Steeg (versteb) >> Cc: Tom.Van_Caenegem@alcatel-lucent.be; avt@ietf.org; Zeev Vax >> Subject: Re: [AVT] Rapid Acquisition of Multicast Streams >> (RAMS) - multipleRAMS-R messages for the same unicast flow >> >> >> On Apr 1, 2009, at 7:52 PM, Bill Ver Steeg (versteb) wrote: >> >>> >>> When we added the ability to send more than one RAMS-R message, we >>> opened up a few design points that we now need to consider. >>> >>> We need to have some nomenclature for describing the >> "initial RMS-R" >>> and "subsequent RMS-R", so I will start with using those words. >>> Better words would be appreciated. >>> >>> The first design point I would like to address is what the RS is >>> required to do when it receives an RAMS-R for a burst that >> is already >>> in flow (aka "subsequent RMS-R"). We stated that the least >> it could do >>> was "ignore it". Does this imply that there is no >> requirement to send >>> an RMS-I in response to RMS-R messages referencing an in-progress >>> flow? >>> >> No. In order to have rational state machines the RS MUST >> reply to each RAMS-R with a RAMS-I. Whether there is a >> "Reference to the in-progress flow" is a secondary issue. The >> key point is that semantically the RAMS-I returned in >> response to a RAMS-R can be (from a state machine point of >> view) no different from the first, because either the RS may >> never have received the first RAMS-R, or conversely the >> RAMS-I sent in response to te earlier RAMS-R might have been lost. >> >> This is how protocols utilizing idempotency semantics have to >> operate. >>> If so, we should add clarifying text in the document that >> cautions the >>> RR not to assume the RAMS-R was dropped. >>> >> Well, "caution" is not the term I would use. Just show the >> state machines and the whole thins should be obvious (at >> least it would be to me). >>> I briefly considered requiring the RS to send a RAMS-I for each >>> received RAMS-R. Unfortunately, this then leads to another set of >>> corner cases, and may result in a chatty exchange of messages. >>> >> Uh, I don't think so. The only time a message other than the >> two needed to initiate a burst is sent is if a message is >> lost. Worst case this is one extra message - if the sequence >> is RAMS-R->RAMS- I(lost)...RAMS-R(retry)->RAMS-I. >> As long as none of the fields in the messages have themselves >> non- idempotent semantics (e.g. by being deltas rather than absolute >> values) I fail to see what corner cases arise. >>> We also need to consider how to deterministically differentiate >>> between the initial RMS-R message and subsequent RMS-R messages, >>> particularly in the event of packet loss or (unlikely) re-ordering. >>> >> I would argue that we in fact don't need to do this as long >> as we wait long enough for retransmission to avoid delayed >> duplicates or messages crossing on the wire. If that is that >> is the case I would much prefer that we use transaction ids >> instead of or in addition to sequence numbers. But I think >> neither is in fact necessary >> >> In low-probability case the RAMS-R messages permute, the >> client can always recover by sending another RAMS-R with the >> burst rate it wants. >> >> What this does point out however, is that we should have >> either DIFFERENT fields for the values in the RAMS-I that are >> meant to echo/ confirm values requested by the RAMS-R, versus >> those set unilaterally by the server, or use a DIFFERENT >> message type for a unilateral RAMs- (something other than -I) >> generate by the RS that was not triggered by receipt of a RAMS-R. >> >> Either would work. >> >> >>> This probably leads us to including a monotonically increasing >>> sequence number on the RMS-R. >>> >> This begs the question of who throws away state when. For >> example, if I try to do a RAMS on multicast group 1, give up, >> try to do a RAMS on multicast group 2, give up, and then try >> to do a RAMS on group 1 again. What sequence number does the >> last of these RAMS-R message have? Why would it be different >> than if I never had done the RAMS-R on flow 2? How can the RS >> possibly know which case obtains? >> >> I think we're actually making the protocol much more >> complicated and with more error states by introducing >> sequencing to avoid the problems that would arise from >> permuted messages on a retransmission time-out. >> It's just so much easier to ensure all the protocol semantics >> are idempotent. >>> Dropped RMS-R messages should not be a protocol problem, >> as the first >>> one received will trigger the burst. Subsequent RMS-R >> messages either >>> change the burst shape or they do not, and they do not trigger >>> additional messages. >>> >> Really? Not if they have sequence numbers and the RS failed >> to forget the state of an earlier burst. >>> Similarly, if the initial RMS-I is dropped it will probably >> trigger an >>> additional RMS-R message. Subsequent RMS-I messages will either be >>> received by the RR or they will not, and they will not trigger >>> additional messages. >>> >>> So, has anybody considered these design points in detail? >>> >> Yes. Not for RAMS, but for numerous other request/response >> protocols that operate idempotently. >>> I have started to go down this path, but it gets >> complicated quickly. >>> >> So you're discovering :-) >>> In order to limit the complexity, I suggest that we state that the >>> first received RMS-R triggers a RMS-I. Further RMS-R messages may >>> flow. Further RMS-I messages may also flow, but there is no >> explicit >>> requirement to send an RMS-I in response to a subsequent RMS-R. >>> >> No, this is a bug. It never allows the client to ascertain the state >> of the server. >> >> DaveO. >> >>> >>> Bill VerSteeg >>> >>> _______________________________________________ >>> Audio/Video Transport Working Group >>> avt@ietf.org >>> https://www.ietf.org/mailman/listinfo/avt >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> > > From yekuiwang@huawei.com Wed Apr 1 19:56:30 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E79A33A67F2 for ; Wed, 1 Apr 2009 19:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIoFs08+cX8T for ; Wed, 1 Apr 2009 19:56:30 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 5D0353A685A for ; Wed, 1 Apr 2009 19:56:28 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHG00ALNDJSE8@usaga04-in.huawei.com> for avt@ietf.org; Wed, 01 Apr 2009 21:57:29 -0500 (CDT) Received: from W90946 ([10.51.0.20]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KHG007S0DJNZB@usaga04-in.huawei.com> for avt@ietf.org; Wed, 01 Apr 2009 21:57:28 -0500 (CDT) Date: Wed, 01 Apr 2009 22:57:23 -0400 From: Ye-Kui Wang In-reply-to: <23E5CE61-6429-48D7-AF3F-89726BCC2583@cisco.com> To: 'David R Oran' Message-id: <8B8E843FAC7A4A5F9F2C36A7DB8D13FE@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcmzPC9QbUC6gJCIQCWr+ISY4COhsAAARN9w References: <81B9B88E2F9D574AA5328A85547CDE91EC162E@xmb-rtp-21d.amer.cisco.com> <5177B2A348E4B64EAD7D589A027892D96A29EAB21D@NA-EXMSG-C111.redmond.corp.microsoft.com> <81B9B88E2F9D574AA5328A85547CDE91EC1C34@xmb-rtp-21d.amer.cisco.com> <81B9B88E2F9D574AA5328A85547CDE91EC1CAA@xmb-rtp-21d.amer.cisco.com> <99D207F9-2F80-48E8-95B0-DCE28D43B469@cisco.com> <23E5CE61-6429-48D7-AF3F-89726BCC2583@cisco.com> Cc: Tom.Van_Caenegem@alcatel-lucent.be, avt@ietf.org, "'Bill Ver Steeg \(versteb\)'" , 'Zeev Vax' Subject: Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multipleRAMS-R messages for the same unicast flow X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 02:56:31 -0000 > > This relates to the discussion about loss of RMS-I message during > > Bill's presentation in San Francisco. My understanding then > and also > > now is as follows. If during the burst, the burst bitrate > is changed > > by the RS due to whatever reason, and the RS has not sent > an RMS-I or > > the sent RMS-I was lost, it should not be a disater to the > client as > > it knows the its buffer status, and it can also know the > change of the > > burst bitrate and even the value of the changed burst bitrate if it > > wants. So why there is a problem here? > > > The client doesn't know if the burst is going to start or not, The client knows that the burst started if burst packets are coming. Of course the first RMS-I message is still important. > or if the RS aborted the burst, or finished it. The Isn't that the RS only aborts the burst after receiving RMS-T or BYE message? And no draft has mentioned using a message from RS to tell that it will abort or finish the burst anyway. > client can't tell whether the RS failed to send an RAMS-I > because it lost the RAMS-R or because it thought it was > redundant - in a client/server protocol each request needs to > be replied to with a response for the state machines to clean > up correctly. Agreed. BR, YK From yangpeilin@huawei.com Thu Apr 2 01:41:57 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FEAE3A6A3A for ; Thu, 2 Apr 2009 01:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.505 X-Spam-Level: * X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[AWL=1.315, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fg80RIGpEe5l for ; Thu, 2 Apr 2009 01:41:56 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id AAEB03A6953 for ; Thu, 2 Apr 2009 01:41:55 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHG00I9MTE6QR@szxga04-in.huawei.com> for avt@ietf.org; Thu, 02 Apr 2009 16:39:42 +0800 (CST) Received: from huawei.com ([172.17.1.31]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHG00HGPTE67M@szxga04-in.huawei.com> for avt@ietf.org; Thu, 02 Apr 2009 16:39:42 +0800 (CST) Received: from [172.24.1.24] (Forwarded-For: [10.164.12.60]) by szxmc03-in.huawei.com (mshttpd); Thu, 02 Apr 2009 16:39:42 +0800 Date: Thu, 02 Apr 2009 16:39:42 +0800 From: Peilin YANG In-reply-to: <99D207F9-2F80-48E8-95B0-DCE28D43B469@cisco.com> To: David R Oran , "Bill Ver Steeg (versteb)" , Tom.Van_Caenegem@alcatel-lucent.be, Zeev Vax Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <81B9B88E2F9D574AA5328A85547CDE91EC162E@xmb-rtp-21d.amer.cisco.com> <5177B2A348E4B64EAD7D589A027892D96A29EAB21D@NA-EXMSG-C111.redmond.corp.microsoft.com> <81B9B88E2F9D574AA5328A85547CDE91EC1C34@xmb-rtp-21d.amer.cisco.com> <81B9B88E2F9D574AA5328A85547CDE91EC1CAA@xmb-rtp-21d.amer.cisco.com> <99D207F9-2F80-48E8-95B0-DCE28D43B469@cisco.com> Cc: avt@ietf.org Subject: Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multiple RAMS-R messages for the same unicast flow X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 08:41:57 -0000 The RS shall reply to each RAMS-R fom the viewpoint of state machine=2ENe= vertheless=2C = subsequent RAMS-I messages is not trigged by reception of RAMS-R messages= =2C = so I also think that adding a DIFFERENT field for the values in the RAMS-= I should be a good choice=2E = In the meantime this can avoid having a seqnum on 2 of the 3 messages=2E Regards=2C Peilin *************************************************************************= ***************** This email and its attachments contain confidential information from HUA= WEI=2C which is intended only for the person or entity whose address is l= isted above=2E Any use of the information contained here in any way (incl= uding=2C but not limited to=2C total or partial disclosure=2C reproductio= n=2C or dissemination) by persons other than the intended recipient(s) is= prohibited=2E If you receive this email in error=2C please notify the se= nder by phone or email immediately and delete it! ************************************************************************= ***************** ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A David R Oran =3Coran=40cisco=2Ecom=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CB=C4=2C =CB=C4=D4=C2 2=C8=D5=2C 2009 =C9=CF= =CE=E79=3A02 =D6=F7=CC=E2=3A Re=3A =5BAVT=5D Rapid Acquisition of Multicast Streams (R= AMS) - multiple RAMS-R messages for the same unicast flow =CA=D5=BC=FE=C8=CB=3A =22Bill Ver Steeg (versteb)=22 =3Cversteb=40cisco=2E= com=3E =B3=AD=CB=CD=3A Tom=2EVan=5FCaenegem=40alcatel-lucent=2Ebe=2C avt=40ietf=2E= org=2C Zeev Vax =3Czeevvax=40microsoft=2Ecom=3E =3E = =3E On Apr 1=2C 2009=2C at 7=3A52 PM=2C Bill Ver Steeg (versteb) wrote=3A= =3E = =3E =3E =3E =3E When we added the ability to send more than one RAMS-R message=2C= = =3E we = =3E =3E opened up a few design points that we now need to consider=2E =3E =3E =3E =3E We need to have some nomenclature for describing the =22initial = =3E RMS-R=22 = =3E =3E and =22subsequent RMS-R=22=2C so I will start with using those wo= rds=2E = =3E =3E Better words would be appreciated=2E =3E =3E =3E =3E The first design point I would like to address is what the RS is = =3E = =3E =3E required to do when it receives an RAMS-R for a burst that is = =3E =3E already in flow (aka =22subsequent RMS-R=22)=2E We stated that th= e = =3E least = =3E =3E it could do was =22ignore it=22=2E Does this imply that there is = no = =3E =3E requirement to send an RMS-I in response to RMS-R messages = =3E =3E referencing an in-progress flow=3F =3E =3E =3E No=2E In order to have rational state machines the RS MUST reply to = =3E each = =3E RAMS-R with a RAMS-I=2E Whether there is a =22Reference to the in- =3E progress = =3E flow=22 is a secondary issue=2E The key point is that semantically th= e = =3E = =3E RAMS-I returned in response to a RAMS-R can be (from a state = =3E machine = =3E point of view) no different from the first=2C because either the RS = =3E may = =3E never have received the first RAMS-R=2C or conversely the RAMS-I = =3E sent in = =3E response to te earlier RAMS-R might have been lost=2E =3E = =3E This is how protocols utilizing idempotency semantics have to operate= =2E =3E =3E If so=2C we should add clarifying text in the document that = =3E cautions = =3E =3E the RR not to assume the RAMS-R was dropped=2E =3E =3E =3E Well=2C =22caution=22 is not the term I would use=2E Just show the st= ate = =3E machines and the whole thins should be obvious (at least it would = =3E be = =3E to me)=2E =3E =3E I briefly considered requiring the RS to send a RAMS-I for each = =3E =3E received RAMS-R=2E Unfortunately=2C this then leads to another se= t = =3E of = =3E =3E corner cases=2C and may result in a chatty exchange of messages=2E= =3E =3E =3E Uh=2C I don=27t think so=2E The only time a message other than the tw= o = =3E needed to initiate a burst is sent is if a message is lost=2E Worst = =3E case = =3E this is one extra message - if the sequence is RAMS-R-=3ERAMS- = =3E I(lost)=2E=2E=2ERAMS-R(retry)-=3ERAMS-I=2E =3E As long as none of the fields in the messages have themselves non- = =3E idempotent semantics (e=2Eg=2E by being deltas rather than absolute = =3E values) I fail to see what corner cases arise=2E =3E =3E We also need to consider how to deterministically differentiate = =3E =3E between the initial RMS-R message and subsequent RMS-R messages=2C= = =3E = =3E =3E particularly in the event of packet loss or (unlikely) re-orderin= g=2E =3E =3E =3E I would argue that we in fact don=27t need to do this as long as we = =3E wait = =3E long enough for retransmission to avoid delayed duplicates or = =3E messages = =3E crossing on the wire=2E If that is that is the case I would much = =3E prefer = =3E that we use transaction ids instead of or in addition to sequence = =3E numbers=2E But I think neither is in fact necessary =3E = =3E In low-probability case the RAMS-R messages permute=2C the client = =3E can = =3E always recover by sending another RAMS-R with the burst rate it wants= =2E =3E = =3E What this does point out however=2C is that we should have either = =3E DIFFERENT fields for the values in the RAMS-I that are meant to = =3E echo/ = =3E confirm values requested by the RAMS-R=2C versus those set = =3E unilaterally = =3E by the server=2C or use a DIFFERENT message type for a unilateral = =3E RAMs- = =3E (something other than -I) generate by the RS that was not = =3E triggered by = =3E receipt of a RAMS-R=2E =3E = =3E Either would work=2E =3E = =3E = =3E =3E This probably leads us to including a monotonically increasing = =3E =3E sequence number on the RMS-R=2E =3E =3E =3E This begs the question of who throws away state when=2E For example=2C= = =3E if = =3E I try to do a RAMS on multicast group 1=2C give up=2C try to do a RAM= S = =3E on = =3E multicast group 2=2C give up=2C and then try to do a RAMS on group 1 = = =3E again=2E What sequence number does the last of these RAMS-R message = =3E have=3F Why would it be different than if I never had done the RAMS- =3E R on = =3E flow 2=3F How can the RS possibly know which case obtains=3F =3E = =3E I think we=27re actually making the protocol much more complicated = =3E and = =3E with more error states by introducing sequencing to avoid the = =3E problems = =3E that would arise from permuted messages on a retransmission time- =3E out=2E = =3E It=27s just so much easier to ensure all the protocol semantics are = =3E idempotent=2E =3E =3E Dropped RMS-R messages should not be a protocol problem=2C as th= e = =3E = =3E =3E first one received will trigger the burst=2E Subsequent RMS-R = =3E messages = =3E =3E either change the burst shape or they do not=2C and they do not = =3E =3E trigger additional messages=2E =3E =3E =3E Really=3F Not if they have sequence numbers and the RS failed to = =3E forget = =3E the state of an earlier burst=2E =3E =3E Similarly=2C if the initial RMS-I is dropped it will probably = =3E trigger = =3E =3E an additional RMS-R message=2E Subsequent RMS-I messages will = =3E either = =3E =3E be received by the RR or they will not=2C and they will not = =3E trigger = =3E =3E additional messages=2E =3E =3E =3E =3E So=2C has anybody considered these design points in detail=3F =3E =3E =3E Yes=2E Not for RAMS=2C but for numerous other request/response = =3E protocols = =3E that operate idempotently=2E =3E =3E I have started to go down this path=2C but it gets complicated = =3E quickly=2E=3E =3E So you=27re discovering =3A-) =3E =3E In order to limit the complexity=2C I suggest that we state that = =3E the = =3E =3E first received RMS-R triggers a RMS-I=2E Further RMS-R messages = =3E may = =3E =3E flow=2E Further RMS-I messages may also flow=2C but there is no = =3E explicit = =3E =3E requirement to send an RMS-I in response to a subsequent RMS-R=2E= =3E =3E =3E No=2C this is a bug=2E It never allows the client to ascertain the = =3E state = =3E of the server=2E =3E = =3E DaveO=2E =3E = =3E =3E =3E =3E Bill VerSteeg =3E =3E =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =3E =3E Audio/Video Transport Working Group =3E =3E avt=40ietf=2Eorg =3E =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/avt =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E Audio/Video Transport Working Group =3E avt=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/avt =3E From tendyntu@huawei.com Thu Apr 2 04:52:33 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 384933A67D0 for ; Thu, 2 Apr 2009 04:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.637 X-Spam-Level: * X-Spam-Status: No, score=1.637 tagged_above=-999 required=5 tests=[AWL=-0.657, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIlp8I3y5Vo2 for ; Thu, 2 Apr 2009 04:52:32 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 911153A67FA for ; Thu, 2 Apr 2009 04:52:31 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHH00MTI2CWFB@szxga03-in.huawei.com> for avt@ietf.org; Thu, 02 Apr 2009 19:53:20 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHH008D32CWDS@szxga03-in.huawei.com> for avt@ietf.org; Thu, 02 Apr 2009 19:53:20 +0800 (CST) Received: from z61302 ([10.85.208.250]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KHH00J6H2CVNX@szxml04-in.huawei.com> for avt@ietf.org; Thu, 02 Apr 2009 19:53:19 +0800 (CST) Date: Thu, 02 Apr 2009 19:53:19 +0800 From: Zou ZiXuan In-reply-to: To: 'Peilin YANG' , 'David R Oran' , "'Bill Ver Steeg (versteb)'" , Tom.Van_Caenegem@alcatel-lucent.be, 'Zeev Vax' Message-id: <006001c9b389$9de17620$d9a46260$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=gb2312 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: AcmzbxwL0h+SGVAZQH2KCGnhWeyDrwAF/0RQ References: <81B9B88E2F9D574AA5328A85547CDE91EC162E@xmb-rtp-21d.amer.cisco.com> <5177B2A348E4B64EAD7D589A027892D96A29EAB21D@NA-EXMSG-C111.redmond.corp.microsoft.com> <81B9B88E2F9D574AA5328A85547CDE91EC1C34@xmb-rtp-21d.amer.cisco.com> <81B9B88E2F9D574AA5328A85547CDE91EC1CAA@xmb-rtp-21d.amer.cisco.com> <99D207F9-2F80-48E8-95B0-DCE28D43B469@cisco.com> Cc: avt@ietf.org Subject: Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multiple RAMS-R messages for the same unicast flow X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 11:52:33 -0000 > The RS shall reply to each RAMS-R fom the viewpoint of state > machine.Nevertheless, > subsequent RAMS-I messages is not trigged by reception of RAMS-R > messages, [ZiXuan] If subsequent RAM-I message is not triggered by reception of RAMS-R, then why do we need a DIFFERENT field in the RAMS-I message? I guess you meant those RAMS-I messages generated unilaterally by RS, is my understanding correct? > so I also think that adding a DIFFERENT field for the values in the RAMS-I > should be a good choice. > In the meantime this can avoid having a seqnum on 2 of the 3 messages. >=20 > Regards, >=20 > Peilin >=20 > ************************************************************************ ************ > ****** > This email and its attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address is > listed above. Any use of the information contained here in any way (including, > but not limited to, total or partial disclosure, reproduction, or dissemination) > by persons other than the intended recipient(s) is prohibited. If you receive > this email in error, please notify the sender by phone or email > immediately and delete it! >=20 > ************************************************************************ ************ > ***** >=20 > ----- =D4=AD=D3=CA=BC=FE ----- > =B7=A2=BC=FE=C8=CB: David R Oran > =C8=D5=C6=DA: =D0=C7=C6=DA=CB=C4, =CB=C4=D4=C2 2=C8=D5, 2009 = =C9=CF=CE=E79:02 > =D6=F7=CC=E2: Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) = - multiple > RAMS-R messages for the same unicast flow > =CA=D5=BC=FE=C8=CB: "Bill Ver Steeg (versteb)" > =B3=AD=CB=CD: Tom.Van_Caenegem@alcatel-lucent.be, avt@ietf.org, Zeev = Vax > >=20 > > > > On Apr 1, 2009, at 7:52 PM, Bill Ver Steeg (versteb) wrote: > > > > > > > > When we added the ability to send more than one RAMS-R message, > > we > > > opened up a few design points that we now need to consider. > > > > > > We need to have some nomenclature for describing the "initial > > RMS-R" > > > and "subsequent RMS-R", so I will start with using those words. > > > Better words would be appreciated. > > > > > > The first design point I would like to address is what the RS is > > > > > required to do when it receives an RAMS-R for a burst that is > > > already in flow (aka "subsequent RMS-R"). We stated that the > > least > > > it could do was "ignore it". Does this imply that there is no > > > requirement to send an RMS-I in response to RMS-R messages > > > referencing an in-progress flow? > > > > > No. In order to have rational state machines the RS MUST reply to > > each > > RAMS-R with a RAMS-I. Whether there is a "Reference to the in- > > progress > > flow" is a secondary issue. The key point is that semantically the > > > > RAMS-I returned in response to a RAMS-R can be (from a state > > machine > > point of view) no different from the first, because either the RS > > may > > never have received the first RAMS-R, or conversely the RAMS-I > > sent in > > response to te earlier RAMS-R might have been lost. > > > > This is how protocols utilizing idempotency semantics have to operate. > > > If so, we should add clarifying text in the document that > > cautions > > > the RR not to assume the RAMS-R was dropped. > > > > > Well, "caution" is not the term I would use. Just show the state > > machines and the whole thins should be obvious (at least it would > > be > > to me). > > > I briefly considered requiring the RS to send a RAMS-I for each > > > received RAMS-R. Unfortunately, this then leads to another set > > of > > > corner cases, and may result in a chatty exchange of messages. > > > > > Uh, I don't think so. The only time a message other than the two > > needed to initiate a burst is sent is if a message is lost. Worst > > case > > this is one extra message - if the sequence is RAMS-R->RAMS- > > I(lost)...RAMS-R(retry)->RAMS-I. > > As long as none of the fields in the messages have themselves non- > > idempotent semantics (e.g. by being deltas rather than absolute > > values) I fail to see what corner cases arise. > > > We also need to consider how to deterministically differentiate > > > between the initial RMS-R message and subsequent RMS-R messages, > > > > > particularly in the event of packet loss or (unlikely) re-ordering. > > > > > I would argue that we in fact don't need to do this as long as we > > wait > > long enough for retransmission to avoid delayed duplicates or > > messages > > crossing on the wire. If that is that is the case I would much > > prefer > > that we use transaction ids instead of or in addition to sequence > > numbers. But I think neither is in fact necessary > > > > In low-probability case the RAMS-R messages permute, the client > > can > > always recover by sending another RAMS-R with the burst rate it wants. > > > > What this does point out however, is that we should have either > > DIFFERENT fields for the values in the RAMS-I that are meant to > > echo/ > > confirm values requested by the RAMS-R, versus those set > > unilaterally > > by the server, or use a DIFFERENT message type for a unilateral > > RAMs- > > (something other than -I) generate by the RS that was not > > triggered by > > receipt of a RAMS-R. > > > > Either would work. > > > > > > > This probably leads us to including a monotonically increasing > > > sequence number on the RMS-R. > > > > > This begs the question of who throws away state when. For example, > > if > > I try to do a RAMS on multicast group 1, give up, try to do a RAMS > > on > > multicast group 2, give up, and then try to do a RAMS on group 1 > > again. What sequence number does the last of these RAMS-R message > > have? Why would it be different than if I never had done the RAMS- > > R on > > flow 2? How can the RS possibly know which case obtains? > > > > I think we're actually making the protocol much more complicated > > and > > with more error states by introducing sequencing to avoid the > > problems > > that would arise from permuted messages on a retransmission time- > > out. > > It's just so much easier to ensure all the protocol semantics are > > idempotent. > > > Dropped RMS-R messages should not be a protocol problem, as the > > > > > first one received will trigger the burst. Subsequent RMS-R > > messages > > > either change the burst shape or they do not, and they do not > > > trigger additional messages. > > > > > Really? Not if they have sequence numbers and the RS failed to > > forget > > the state of an earlier burst. > > > Similarly, if the initial RMS-I is dropped it will probably > > trigger > > > an additional RMS-R message. Subsequent RMS-I messages will > > either > > > be received by the RR or they will not, and they will not > > trigger > > > additional messages. > > > > > > So, has anybody considered these design points in detail? > > > > > Yes. Not for RAMS, but for numerous other request/response > > protocols > > that operate idempotently. > > > I have started to go down this path, but it gets complicated > > quickly.> > > So you're discovering :-) > > > In order to limit the complexity, I suggest that we state that > > the > > > first received RMS-R triggers a RMS-I. Further RMS-R messages > > may > > > flow. Further RMS-I messages may also flow, but there is no > > explicit > > > requirement to send an RMS-I in response to a subsequent RMS-R. > > > > > No, this is a bug. It never allows the client to ascertain the > > state > > of the server. > > > > DaveO. > > > > > > > > Bill VerSteeg > > > > > > _______________________________________________ > > > Audio/Video Transport Working Group > > > avt@ietf.org > > > https://www.ietf.org/mailman/listinfo/avt > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From yangpeilin@huawei.com Thu Apr 2 05:03:37 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A7703A69C5 for ; Thu, 2 Apr 2009 05:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.317 X-Spam-Level: * X-Spam-Status: No, score=1.317 tagged_above=-999 required=5 tests=[AWL=1.127, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8z7HcBIzMt1D for ; Thu, 2 Apr 2009 05:03:36 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 73AF03A6CC0 for ; Thu, 2 Apr 2009 05:02:57 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHH001GD2UHP2@szxga04-in.huawei.com> for avt@ietf.org; Thu, 02 Apr 2009 20:03:53 +0800 (CST) Received: from huawei.com ([172.17.1.31]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHH00EJ22UG64@szxga04-in.huawei.com> for avt@ietf.org; Thu, 02 Apr 2009 20:03:53 +0800 (CST) Received: from [172.24.1.24] (Forwarded-For: [10.164.12.60]) by szxmc03-in.huawei.com (mshttpd); Thu, 02 Apr 2009 20:03:52 +0800 Date: Thu, 02 Apr 2009 20:03:52 +0800 From: Peilin YANG In-reply-to: <006001c9b389$9de17620$d9a46260$@com> To: Zou ZiXuan Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <81B9B88E2F9D574AA5328A85547CDE91EC162E@xmb-rtp-21d.amer.cisco.com> <5177B2A348E4B64EAD7D589A027892D96A29EAB21D@NA-EXMSG-C111.redmond.corp.microsoft.com> <81B9B88E2F9D574AA5328A85547CDE91EC1C34@xmb-rtp-21d.amer.cisco.com> <81B9B88E2F9D574AA5328A85547CDE91EC1CAA@xmb-rtp-21d.amer.cisco.com> <99D207F9-2F80-48E8-95B0-DCE28D43B469@cisco.com> <006001c9b389$9de17620$d9a46260$@com> Cc: Tom.Van_Caenegem@alcatel-lucent.be, 'David R Oran' , avt@ietf.org, "'Bill Ver Steeg \(versteb\)'" , 'Zeev Vax' Subject: Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multiple RAMS-R messages for the same unicast flow X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 12:03:37 -0000 Yes=2C your understanding is corrrect=2E That is my meaning=2E Peilin *************************************************************************= ***************** This email and its attachments contain confidential information from HUA= WEI=2C which is intended only for the person or entity whose address is l= isted above=2E Any use of the information contained here in any way (incl= uding=2C but not limited to=2C total or partial disclosure=2C reproductio= n=2C or dissemination) by persons other than the intended recipient(s) is= prohibited=2E If you receive this email in error=2C please notify the se= nder by phone or email immediately and delete it! ************************************************************************= ***************** ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A Zou ZiXuan =3Ctendyntu=40huawei=2Ecom=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CB=C4=2C =CB=C4=D4=C2 2=C8=D5=2C 2009 =CF=C2= =CE=E77=3A55 =D6=F7=CC=E2=3A RE=3A =5BAVT=5D Rapid Acquisition of Multicast Streams (R= AMS) - multiple RAMS-R messages for the same unicast flow =CA=D5=BC=FE=C8=CB=3A =27Peilin YANG=27 =3Cyangpeilin=40huawei=2Ecom=3E=2C= =27David R Oran=27 =3Coran=40cisco=2Ecom=3E=2C =22=27Bill Ver Steeg (ver= steb)=27=22 =3Cversteb=40cisco=2Ecom=3E=2C Tom=2EVan=5FCaenegem=40alcatel= -lucent=2Ebe=2C =27Zeev Vax=27 =3Czeevvax=40microsoft=2Ecom=3E =B3=AD=CB=CD=3A avt=40ietf=2Eorg =3E =3E The RS shall reply to each RAMS-R fom the viewpoint of state =3E =3E machine=2ENevertheless=2C =3E =3E subsequent RAMS-I messages is not trigged by reception of RAMS-R =3E =3E messages=2C =3E =5BZiXuan=5D If subsequent RAM-I message is not triggered by receptio= n of =3E RAMS-R=2C then why do we need a DIFFERENT field in the RAMS-I = =3E message=3F I =3E guess you meant those RAMS-I messages generated unilaterally by = =3E RS=2C is =3E my understanding correct=3F =3E =3E so I also think that adding a DIFFERENT field for the values in t= he =3E RAMS-I =3E =3E should be a good choice=2E =3E =3E In the meantime this can avoid having a seqnum on 2 of the 3 = =3E messages=2E=3E = =3E =3E Regards=2C =3E =3E = =3E =3E Peilin =3E =3E = =3E =3E =3E *********************************************************************= *** =3E ************ =3E =3E ****** =3E =3E This email and its attachments contain confidential information = =3E from=3E HUAWEI=2C which is intended only for the person or entity = =3E whose address =3E is =3E =3E listed above=2E Any use of the information contained here in any = way =3E (including=2C =3E =3E but not limited to=2C total or partial disclosure=2C reproduction= =2C or =3E dissemination) =3E =3E by persons other than the intended recipient(s) is prohibited=2E = =3E If you =3E receive =3E =3E this email in error=2C please notify the sender by phone or email= =3E =3E immediately and delete it! =3E =3E = =3E =3E =3E *********************************************************************= *** =3E ************ =3E =3E ***** =3E =3E = =3E =3E ----- =D4=AD=D3=CA=BC=FE ----- =3E =3E =B7=A2=BC=FE=C8=CB=3A David R Oran =3Coran=40cisco=2Ecom=3E =3E =3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CB=C4=2C =CB=C4=D4=C2 2=C8=D5=2C 200= 9 =C9=CF=CE=E79=3A02 =3E =3E =D6=F7=CC=E2=3A Re=3A =5BAVT=5D Rapid Acquisition of Multicast St= reams (RAMS) - =3E multiple =3E =3E RAMS-R messages for the same unicast flow =3E =3E =CA=D5=BC=FE=C8=CB=3A =22Bill Ver Steeg (versteb)=22 =3Cversteb=40= cisco=2Ecom=3E =3E =3E =B3=AD=CB=CD=3A Tom=2EVan=5FCaenegem=40alcatel-lucent=2Ebe=2C avt= =40ietf=2Eorg=2C Zeev Vax =3E =3E =3Czeevvax=40microsoft=2Ecom=3E =3E =3E = =3E =3E =3E =3E =3E =3E On Apr 1=2C 2009=2C at 7=3A52 PM=2C Bill Ver Steeg (versteb) = wrote=3A =3E =3E =3E =3E =3E =3E =3E =3E =3E =3E =3E When we added the ability to send more than one RAMS-R me= ssage=2C =3E =3E =3E we =3E =3E =3E =3E opened up a few design points that we now need to conside= r=2E =3E =3E =3E =3E =3E =3E =3E =3E We need to have some nomenclature for describing the =22i= nitial =3E =3E =3E RMS-R=22 =3E =3E =3E =3E and =22subsequent RMS-R=22=2C so I will start with using = those words=2E =3E =3E =3E =3E Better words would be appreciated=2E =3E =3E =3E =3E =3E =3E =3E =3E The first design point I would like to address is what th= e = =3E RS is =3E =3E =3E =3E =3E =3E =3E required to do when it receives an RAMS-R for a burst tha= t is =3E =3E =3E =3E already in flow (aka =22subsequent RMS-R=22)=2E We stated= that the =3E =3E =3E least =3E =3E =3E =3E it could do was =22ignore it=22=2E Does this imply that t= here is no =3E =3E =3E =3E requirement to send an RMS-I in response to RMS-R message= s =3E =3E =3E =3E referencing an in-progress flow=3F =3E =3E =3E =3E =3E =3E =3E No=2E In order to have rational state machines the RS MUST re= ply to =3E =3E =3E each =3E =3E =3E RAMS-R with a RAMS-I=2E Whether there is a =22Reference to th= e in- =3E =3E =3E progress =3E =3E =3E flow=22 is a secondary issue=2E The key point is that semanti= cally the =3E =3E =3E =3E =3E =3E RAMS-I returned in response to a RAMS-R can be (from a state =3E =3E =3E machine =3E =3E =3E point of view) no different from the first=2C because either = the RS =3E =3E =3E may =3E =3E =3E never have received the first RAMS-R=2C or conversely the RAM= S-I =3E =3E =3E sent in =3E =3E =3E response to te earlier RAMS-R might have been lost=2E =3E =3E =3E =3E =3E =3E This is how protocols utilizing idempotency semantics have to= =3E operate=2E =3E =3E =3E =3E If so=2C we should add clarifying text in the document th= at =3E =3E =3E cautions =3E =3E =3E =3E the RR not to assume the RAMS-R was dropped=2E =3E =3E =3E =3E =3E =3E =3E Well=2C =22caution=22 is not the term I would use=2E Just sho= w the state =3E =3E =3E machines and the whole thins should be obvious (at least it w= ould =3E =3E =3E be =3E =3E =3E to me)=2E =3E =3E =3E =3E I briefly considered requiring the RS to send a RAMS-I fo= r each =3E =3E =3E =3E received RAMS-R=2E Unfortunately=2C this then leads to an= other set =3E =3E =3E of =3E =3E =3E =3E corner cases=2C and may result in a chatty exchange of me= ssages=2E =3E =3E =3E =3E =3E =3E =3E Uh=2C I don=27t think so=2E The only time a message other tha= n the two =3E =3E =3E needed to initiate a burst is sent is if a message is lost=2E= Worst =3E =3E =3E case =3E =3E =3E this is one extra message - if the sequence is RAMS-R-=3ERAMS= - =3E =3E =3E I(lost)=2E=2E=2ERAMS-R(retry)-=3ERAMS-I=2E =3E =3E =3E As long as none of the fields in the messages have themselves= = =3E non- =3E =3E =3E idempotent semantics (e=2Eg=2E by being deltas rather than ab= solute =3E =3E =3E values) I fail to see what corner cases arise=2E =3E =3E =3E =3E We also need to consider how to deterministically differe= ntiate =3E =3E =3E =3E between the initial RMS-R message and subsequent RMS-R me= ssages=2C =3E =3E =3E =3E =3E =3E =3E particularly in the event of packet loss or (unlikely) =3E re-ordering=2E =3E =3E =3E =3E =3E =3E =3E I would argue that we in fact don=27t need to do this as long= as we =3E =3E =3E wait =3E =3E =3E long enough for retransmission to avoid delayed duplicates or= =3E =3E =3E messages =3E =3E =3E crossing on the wire=2E If that is that is the case I would m= uch =3E =3E =3E prefer =3E =3E =3E that we use transaction ids instead of or in addition to sequ= ence =3E =3E =3E numbers=2E But I think neither is in fact necessary =3E =3E =3E =3E =3E =3E In low-probability case the RAMS-R messages permute=2C the cl= ient =3E =3E =3E can =3E =3E =3E always recover by sending another RAMS-R with the burst rate = it =3E wants=2E =3E =3E =3E =3E =3E =3E What this does point out however=2C is that we should have ei= ther =3E =3E =3E DIFFERENT fields for the values in the RAMS-I that are meant = to =3E =3E =3E echo/ =3E =3E =3E confirm values requested by the RAMS-R=2C versus those set =3E =3E =3E unilaterally =3E =3E =3E by the server=2C or use a DIFFERENT message type for a unilat= eral =3E =3E =3E RAMs- =3E =3E =3E (something other than -I) generate by the RS that was not =3E =3E =3E triggered by =3E =3E =3E receipt of a RAMS-R=2E =3E =3E =3E =3E =3E =3E Either would work=2E =3E =3E =3E =3E =3E =3E =3E =3E =3E =3E This probably leads us to including a monotonically incre= asing =3E =3E =3E =3E sequence number on the RMS-R=2E =3E =3E =3E =3E =3E =3E =3E This begs the question of who throws away state when=2E For e= xample=2C =3E =3E =3E if =3E =3E =3E I try to do a RAMS on multicast group 1=2C give up=2C try to = do a RAMS =3E =3E =3E on =3E =3E =3E multicast group 2=2C give up=2C and then try to do a RAMS on = group 1 =3E =3E =3E again=2E What sequence number does the last of these RAMS-R m= essage =3E =3E =3E have=3F Why would it be different than if I never had done th= e = =3E RAMS- =3E =3E =3E R on =3E =3E =3E flow 2=3F How can the RS possibly know which case obtains=3F =3E =3E =3E =3E =3E =3E I think we=27re actually making the protocol much more compli= cated =3E =3E =3E and =3E =3E =3E with more error states by introducing sequencing to avoid the= =3E =3E =3E problems =3E =3E =3E that would arise from permuted messages on a retransmission = =3E time- =3E =3E =3E out=2E =3E =3E =3E It=27s just so much easier to ensure all the protocol semanti= cs are =3E =3E =3E idempotent=2E =3E =3E =3E =3E Dropped RMS-R messages should not be a protocol problem=2C= as the =3E =3E =3E =3E =3E =3E =3E first one received will trigger the burst=2E Subsequent R= MS-R =3E =3E =3E messages =3E =3E =3E =3E either change the burst shape or they do not=2C and they = do not =3E =3E =3E =3E trigger additional messages=2E =3E =3E =3E =3E =3E =3E =3E Really=3F Not if they have sequence numbers and the RS failed= to =3E =3E =3E forget =3E =3E =3E the state of an earlier burst=2E =3E =3E =3E =3E Similarly=2C if the initial RMS-I is dropped it will prob= ably =3E =3E =3E trigger =3E =3E =3E =3E an additional RMS-R message=2E Subsequent RMS-I messages = will =3E =3E =3E either =3E =3E =3E =3E be received by the RR or they will not=2C and they will n= ot =3E =3E =3E trigger =3E =3E =3E =3E additional messages=2E =3E =3E =3E =3E =3E =3E =3E =3E So=2C has anybody considered these design points in detai= l=3F =3E =3E =3E =3E =3E =3E =3E Yes=2E Not for RAMS=2C but for numerous other request/respons= e =3E =3E =3E protocols =3E =3E =3E that operate idempotently=2E =3E =3E =3E =3E I have started to go down this path=2C but it gets compli= cated =3E =3E =3E quickly=2E=3E =3E =3E =3E So you=27re discovering =3A-) =3E =3E =3E =3E In order to limit the complexity=2C I suggest that we sta= te that =3E =3E =3E the =3E =3E =3E =3E first received RMS-R triggers a RMS-I=2E Further RMS-R me= ssages =3E =3E =3E may =3E =3E =3E =3E flow=2E Further RMS-I messages may also flow=2C but there= is no =3E =3E =3E explicit =3E =3E =3E =3E requirement to send an RMS-I in response to a subsequent = RMS-R=2E =3E =3E =3E =3E =3E =3E =3E No=2C this is a bug=2E It never allows the client to ascertai= n the =3E =3E =3E state =3E =3E =3E of the server=2E =3E =3E =3E =3E =3E =3E DaveO=2E =3E =3E =3E =3E =3E =3E =3E =3E =3E =3E =3E Bill VerSteeg =3E =3E =3E =3E =3E =3E =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F =3E =3E =3E =3E Audio/Video Transport Working Group =3E =3E =3E =3E avt=40ietf=2Eorg =3E =3E =3E =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/avt =3E =3E =3E =3E =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F =3E =3E =3E Audio/Video Transport Working Group =3E =3E =3E avt=40ietf=2Eorg =3E =3E =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/avt =3E =3E =3E =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =3E =3E Audio/Video Transport Working Group =3E =3E avt=40ietf=2Eorg =3E =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/avt =3E = =3E From Thomas.Schierl@hhi.fraunhofer.de Thu Apr 2 05:24:05 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCC9A3A6827 for ; Thu, 2 Apr 2009 05:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.844 X-Spam-Level: X-Spam-Status: No, score=-3.844 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIOzFAitegFt for ; Thu, 2 Apr 2009 05:24:04 -0700 (PDT) Received: from mail.hhi.fraunhofer.de (mail.HHI.FRAUNHOFER.DE [193.174.67.45]) by core3.amsl.com (Postfix) with ESMTP id 2BC073A67FA for ; Thu, 2 Apr 2009 05:24:03 -0700 (PDT) Received: by mail.hhi.fraunhofer.de (Postfix, from userid 65534) id 5EB3D1D88FF3; Thu, 2 Apr 2009 14:24:43 +0200 (CEST) Received: from [172.19.40.6] (ipamfw.iphhi.de [212.202.149.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Thomas Schierl", Issuer "Fraunhofer-Gesellschaft Root-CA v2" (not verified)) by mail.hhi.fraunhofer.de (Postfix) with ESMTP id EA9FF1D88F5F; Thu, 2 Apr 2009 14:24:42 +0200 (CEST) Message-ID: <49D4AE9D.8060905@hhi.fraunhofer.de> Date: Thu, 02 Apr 2009 14:25:01 +0200 From: Thomas.Schierl@hhi.fraunhofer.de Organization: Fraunhofer HHI User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Michael A Dolan References: <20090309171502.518513A6359@core3.amsl.com> <4A6ACB13-0CBB-4DA7-84AD-28CDE56DB4C3@csperkins.org> <0MKpCa-1LoLs525qX-000cvA@mrelay.perfora.net> <49D1C793.9050409@hhi.fraunhofer.de> <0MKp8S-1Lof8c1LTC-000fjs@mrelay.perfora.net> In-Reply-To: <0MKp8S-1Lof8c1LTC-000fjs@mrelay.perfora.net> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-alterMIME: Yes Cc: avt@ietf.org Subject: Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid-rtp-sync-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 12:24:05 -0000 Hi Michael,

What I can see from the ATSC M/H Transport spec is that there are requirements on encoder and decoder clock precisions, which for sure give a complete different environment than assumed by RFC3550 with respect to the clock precision. If we could assure such clocks for all devices which may potentially encode and stream layered media via multi session transmission, the problem would have been solved anyway. But that is not the case, as I tried to show by pointing to some of the relevant discussions on the mailing list.

About your second point: RTP does not require NTP to be used as wallclock. In RTP, there is much more freedom in selecting the source for this clock. RTP uses the NTP timestamp format just for indicating the wallclock in the RTCP sender reports. Furthermore draft-perkins-avt-rapid-rtp-sync-03 does only require to use the same wallclock as used for the SRs also for the wallclock timestamps in the header extensions.

Another interesting point is that the ATSC Transport spec is not mentioning SVC while mentioning AVC and AAC. If looking at the ATSC Video Systems spec. (S4-136r7-A153-Part-7-Video-System), there is a solution which requires RTP timestamp synchronization for "SVC Transport in Two RTP Sessions". This for sure solves the clock skew problem, but as discussed in AVT, this is not a general solution and has different implications if applied to all use cases of RTP multi session transmission as, e.g. conversational services. Therefore we now have a solution which seems to be agreeable by the group, which solves the problem and is more in line with RFC 3550, i.e. using the wallclock for the data alignment between the session.

Best regards,
Thomas


Michael A Dolan wrote:
Hi Thomas-

Thanks.  Yes, I am familiar with the discussion.

I'm not necessarily pushing the ATSC solution, but offering some points to consider, which apply equally to the problem at hand here, I think.

Also, it is important to note some more things about the ATSC text:

1. The language in the specification very carefully recommends the clock precision without requiring it.  It is expected to work over routers with jitter and delays and with media components from outside the broadcast facility. The difference is that the client is expected to be able to perform tight sync when the servers are able to provide the recommended timing model (encoding one hop away, etc).  It gracefully degrades to "Internet" timing model quality.

2. The clock, although "NTP" syntax, is not time of day (e.g. reference_ID= "GPS"), but "PPS", thus allowing the components to be encoded and decoded without concern for end-to-end delivery delay.  This only works when NTP is explicitly signaled as part of the encoding and both components share a clock (same or closely coupled encoders). So it will not work in the general case.  But there are many systems where it will and perhaps consideration should be given to permitting non-"wall clock" timebases.

The NTP hdr ext here is an encoding optimization that indeed has some other good properties.  Although the draft ties the NTP timestamp back to the RTCP SR records, the timebase is not explicitly defined (which is also true of RTCP SR).  Some reference_ID value must be assumed and there is enough delta between, for example, GPS and UTC, timebases to cause things to break if the entire system is not implicitly assumed to be only one timebase. For example, without an explicit reference_ID, how could one use other timebases defined in NTPv4?  This is a broader issue than the hdr ext syntax, but since we're discussing NTP, I thought I'd bring it up.

I think the above and the other points below are relevant here and not inconsistent with the RTCP SR methods. The fact that the ATSC design *can* be more precise is not alone cause to discard the techniques developed there.

Regards,

         Mike

At 09:34 AM 3/31/2009 +0200, Thomas.Schierl@hhi.fraunhofer.de wrote:
Dear Michael,

Thanks for the comments and the reference to the ATSC M/H.

I guess, what we are looking for in AVT is a solution which also works for encoders having non-perfect clocks. There was a long discussion on the list, here are two pointers:

http://www.ietf.org/mail-archive/web/avt/current/msg09144.html
http://www.ietf.org/mail-archive/web/avt/current/msg10491.html

ATSC surely can assume to have a perfect clock in the NTP streams, which will not be the case on PC systems that may be used as an encoder for multi session transmission of a layered codec. This is one major problem we intended to solve with the header extension while keeping the whole approach as close as possible in line with the existing RTCP SR method.


Best regards,
Thomas



______________________________________________
Thomas Schierl, Dipl.-Ing.
Fraunhofer HHI
Senior Research Engineer
Image Processing Dept. / Multimedia Transport
Einsteinufer 37, 10587 Berlin, Germany
PHONE: +49 30 31002 227 , FAX: +49 30 392 7200
WEB: http://ip.hhi.de , SKYPE: thomas.schierl
EMAIL: thomas.schierl@hhi.fraunhofer.de



Michael A Dolan wrote:
Those interested in this topic may also find this interesting:

http://www.atsc.org/standards/cs_documents/a153-2009-03-13/S4-132r13-A153-Part-3-Transport.pdf

Section 10.3.

Some differences are:

1. There is one NTP packet stream per service, rather than the encoding optimization in the hdr ext;
2. RTCP SR records are emitted "near" video random access points, rather than on a prescribed time schedule; and
3. The above works in multicast-only, UDLR networks (e.g. television broadcast), rather than requiring a 2-way link.

#2 is interesting since in order to begin a *synchronized* decode (video + audio properly correlated), a client must have acquired all of:
a. NTP
b. RTCP SR for each component
c. video reference frame and decoding metadata (i.e. a random access point)
d. audio frame

So, the relative timing of the RTCP SR records to the RTP stream content is perhaps more important than the emission period.  Having the RTCP SR records arrive faster than the video reference frames doesn't help of course.  And even if they are "fast enough", having them arrive out of sync with the reference frames delays the service acquisition by half the period on average.

Bandwidth utilization (how many bits to devote to RTCP and NTP) can arguably be more efficiently managed by the server in most cases, not individual client requests for faster RTCP SR packets. And, the client would have no knowledge of the intended (video) reference frame periods being used by the server, so it would not, in general, know what to ask for.

In practice, won't a server that wants to enable faster acquisition and sync do things like the above?  I'm concerned that detailed requests from clients beyond "please use more bandwidth and enable fast sync" won't be as valuable as they seem since in the general case the client doesn't know what to ask for exactly.

FYI, the above ATSC document is in a "candidate" state where public comments are solicited.  Independent of this thread, if anyone has comments on it, I could convey them back to the ATSC.

Regards,

        Mike

At 07:43 PM 3/9/2009 +0000, Colin Perkins wrote:
The changes in this version are primarily editorial; we're aware that
not all the open issues have been addressed yet. Any further comments
are welcomed.

Chairs: we'd like this to be considered as an AVT working group
draft, as indicated privately.

Cheers,
Colin




Begin forwarded message:
From: Internet-Drafts@ietf.org
Date: 9 March 2009 17:15:02 GMT
To: i-d-announce@ietf.org
Subject: I-D Action:draft-perkins-avt-rapid-rtp-sync-03.txt
Reply-To: internet-drafts@ietf.org

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

        Title           : Rapid Synchronisation of RTP Flows
        Author(s)       : C. Perkins, T. Schierl
        Filename        : draft-perkins-avt-rapid-rtp-sync-03.txt
        Pages           : 17
        Date            : 2009-03-09

This memo outlines how RTP multimedia sessions are synchronised, and
discusses how rapidly such synchronisation can occur.  We show that
most RTP sessions can be synchronised immediately, but that the use
of video switching multipoint conference units (MCUs) or large source
specific multicast (SSM) groups can greatly increase the initial
synchronisation delay.  This increase in delay can be unacceptable to
some applications that use layered and/or multi-description codecs.

This memo updates the RTP Control Protocol (RTCP) timing rules to
reduce the initial synchronisation delay for SSM sessions.  A new
feedback packet is defined for use with the Extended RTP Profile for
RTCP-based Feedback (RTP/AVPF), allowing video switching MCUs to
rapidly request resynchronisation.  Two new RTP header extensions are
defined to allow rapid synchronisation of late joiners, and guarantee
correct timestamp based decoding order recovery for layered codecs in
the presence of clock skew.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-perkins-avt-rapid-rtp- sync-03.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID: <2009-03-09100610.I-D@ietf.org>

_______________________________________________
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

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt

---
Visit us at

Web 2.0 Expo / March 31 - April 03 / San Francisco, California / Booth 415
http://www.web2expo.com/webexsf2009

NAB SHOW 2009 / April 18-23 / Las Vegas, Nevada USA / South Hall (Upper), Booth SU9624F
http://www.nabshow.com/

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt


----
Visit us at

Web 2.0 Expo / March 31 - April 03 / San Francisco, California / Booth 415
http://www.web2expo.com/webexsf2009

NAB SHOW 2009 / April 18-23 / Las Vegas, Nevada USA / South Hall (Upper), Booth SU9624F
http://www.nabshow.com/
From john.mattsson@ericsson.com Thu Apr 2 06:22:43 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB9B43A6A5F for ; Thu, 2 Apr 2009 06:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXe+oLw0qTHI for ; Thu, 2 Apr 2009 06:22:42 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 8DE6D3A6A19 for ; Thu, 2 Apr 2009 06:22:42 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D603020E60; Thu, 2 Apr 2009 15:23:42 +0200 (CEST) X-AuditID: c1b4fb3c-ae798bb0000004b9-3c-49d4bc5ea24e Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9CEFC20415; Thu, 2 Apr 2009 15:23:42 +0200 (CEST) Received: from esealmw121.eemea.ericsson.se ([153.88.200.80]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 15:23:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Apr 2009 15:23:41 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] SRTP store-and-forward Thread-Index: AcmyFtwddoa4DdtHTvuOdbiK1SGRFwBfu1dw References: <49D0E097.3000902@ericsson.com> From: "John Mattsson" To: "Randell Jesup" X-OriginalArrivalTime: 02 Apr 2009 13:23:42.0579 (UTC) FILETIME=[3E241C30:01C9B396] X-Brightmail-Tracker: AAAAAA== Cc: AVT Subject: Re: [AVT] SRTP store-and-forward X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 13:22:43 -0000 >Rolf Blom writes: >>To be able to handle an audio and a video stream using one security=20 >>context it is necessary to introduce a mechanism to give them separate >>protection. We did that with the introduction of the SSS, the SRTP SaF >>Source. It s also necessary to be able to indicate which e2e security=20 >>context that the media is using and thus a CCI, Crypto Context=20 >>Identifier is needed. So we believe that what we have presented is=20 >>general enough but still is a very thin design providing not more than what is really needed. >> >>Cullen gave an example in which it was essential that what is=20 >>forwarded is the complete message that was received by the SaF=20 >>middlebox (do not launch the missile!). Even if I believe that such a=20 >>message wouldn't be left on an answering machine - it probably should=20 >>be delivered directly to eliminate the risk for mistakes - it points at a possible threat. >>This threat might perhaps be countered by some RTCP signaling messages >>e2e. However, in the current draft-naslund-saf-00 we do not provide=20 >>e2e integrity protected RTCP. Is this a problem? Should it be added?=20 >>Or are there other application layer mechanisms that should be=20 >>applied? Note that with an e2e integrity transform and letting PUV be=20 >>a counter, it is possible to detect replays and re-orderings at the=20 >>application layer. However, it will not guarantee that all packets are forwarded. >>Note that the threat discussed is outside the trust model assumed for=20 >>SRTP store-and-forward, which assumes a honest but curious SaF middlebox. Randell Jesup writes: >You need to at least include RTCP as well, or synchronization between=20 >streams (audio and video) cannot be done. Protecting it would be smart, >though probably not strictly necessary. (If not protected, someone=20 >could mess with the stream sync, possibly tickling bugs in the player=20 >or causing one stream or the other to never play, to jump around, or to >be unintelligible.) Our intention have always been that the middlebox saves the relevant parts of RTCP (e.g. SR, APP) and retransmits them to the final receiver. As RTCP is protected hop-by-hop, the only one that could mess with the synchronization is the middlebox, which according to our trust model is trusted not to do so. Most of what can be achieved by messing with the synchronization could be done by not forwarding chosen packets. We thought about protecting RTCP e2e but felt that it creates more problems than it solves. Parts of RTCP should be sent e2e and other parts only hbh, for RTCP APP, this distinction is application dependant. If there is a need to protect against a synchronization messing middlebox, the audio and video should encoded in a format that can be sent in a single stream. /John From zeevvax@microsoft.com Wed Apr 1 10:08:15 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 555A73A659B for ; Wed, 1 Apr 2009 10:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.574 X-Spam-Level: X-Spam-Status: No, score=-9.574 tagged_above=-999 required=5 tests=[AWL=1.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UW-MMZjJK3o8 for ; Wed, 1 Apr 2009 10:08:14 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 385F028C122 for ; Wed, 1 Apr 2009 10:07:48 -0700 (PDT) Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Wed, 1 Apr 2009 10:08:48 -0700 Received: from NA-EXMSG-C111.redmond.corp.microsoft.com ([157.54.61.138]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.88.97]) with mapi; Wed, 1 Apr 2009 10:08:48 -0700 From: Zeev Vax To: "Bill Ver Steeg (versteb)" , "Tom.Van_Caenegem@alcatel-lucent.be" , "Ali C. Begen (abegen)" Date: Wed, 1 Apr 2009 10:08:43 -0700 Thread-Topic: Rapid Acquisition of Multicast Streams (RAMS) - Fixed and TLV fields Thread-Index: AcmyMO1Vf+4hrMHmQjCLzeIX0fZkSAAt6jeg Message-ID: <5177B2A348E4B64EAD7D589A027892D96A29EAB21D@NA-EXMSG-C111.redmond.corp.microsoft.com> References: <81B9B88E2F9D574AA5328A85547CDE91EC162E@xmb-rtp-21d.amer.cisco.com> In-Reply-To: <81B9B88E2F9D574AA5328A85547CDE91EC162E@xmb-rtp-21d.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5177B2A348E4B64EAD7D589A027892D96A29EAB21DNAEXMSGC111re_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 02 Apr 2009 08:43:39 -0700 Cc: "avt@ietf.org" Subject: Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - Fixed and TLV fields X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 17:08:15 -0000 --_000_5177B2A348E4B64EAD7D589A027892D96A29EAB21DNAEXMSGC111re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bill, Please send me the draft for review once you are done with your editorial p= ath, before we send it out for review I would like to add my changes to the= draft. Zeev From: Bill Ver Steeg (versteb) [mailto:versteb@cisco.com] Sent: Tuesday, March 31, 2009 11:46 AM To: avt@ietf.org; Zeev Vax; Tom.Van_Caenegem@alcatel-lucent.be; Ali C. Bege= n (abegen) Subject: Rapid Acquisition of Multicast Streams (RAMS) - Fixed and TLV fiel= ds One of the primary action items arising from the review of the Rapid Acquis= ition of Multicast Streams draft is to identify which fields are mandatory= (and thus fixed format) and which fields are optional (and thus TLV format= ). Here is my take on the matter. Once we reach consensus, I will update th= e draft. I have also included a description of the requested "motivating text" for t= he fields that do not already have such text in the document. Please let me= know if I am on the right track. There is currently no version number in the messages. Ali and I do not thin= k that this is a problem because we can add new TLVs as needed. I want to b= e sure we intentionally decide on this point rather than back into it accid= ently. Any comments? We have 3 messages - RAMS-Request Max Receive BitRate - mandatory Min Buffer Fill Requirement - optional ( Add wording - The receiver may ha= ve knowledge of it's buffering requirements. These requirements may be appl= ication or device specific. For instance, the receiver may need to have a c= ertain amount of data in it's application buffer to handle interdependency = within the data. If the RS knows the buffering ability of the receiver, it = may more precisely tailor the burst to the client. The methods used by the = receiver to determine this value is application specific, and thus out of s= cope. This mechanism can be used by the receiver to signal the sender, if t= he receiver has such knowledge ) Max Buffer Fill Requirement - optional ( Add wording - The receiver may ha= ve knowledge of it's buffering requirements. These requirements may be appl= ication or device specific. For instance, one receiver may have more physic= al memory than another receiver, and thus can buffer more data. If the RS k= nows the buffering ability of the receiver, it may more precisely tailor th= e burst to the client. The methods used by the receiver to determine this v= alue is application specific, and thus out of scope. This mechanism can be = used by the receiver to signal the sender, if the receiver has such knowled= ge ) RAMS- Inform message Sequence Number - mandatory Response - mandatory, will include an enumerated list of response codes - = 0 is succeed, non zero is an error code. We will enumerate a list of error = codes, and note that additional error codes are possible using vendor-speci= fic TLV fields. The enumerated errors will include [No server resources, No= network resources, bad RMS-R request, WHAT ELSE????] Note - we have remove= d the "join now semantic, as that is captured in the "earliest join time" f= ield. Reserved - mandatory - must be all 0s Max Burst Bitrate - mandatory Rapid Acquisition Duration - mandatory - 0 means "join now" (Add wording t= o reflect that this is the server's current value, and can be changed by su= bsequent RMS-I. Add wording to reflect that the RS can't consume resources = forever and needs to deterministically stop the flow. The RS MUST terminate= the flow at this time, even if does not get RMS-T from the RR. ) Extended RTP Sequence Number of First Burst Packet - mandatory Earliest IGMP Join Time - optional (we should consider making this mandato= ry in at least one RMS-I, as the client needs to eventually join) Rams -Terminate - Extended RTP seqnum of First Multicast packet - optional (intent is to te= ll the RS the seqnum at which to stop the burst, but leave the session open= . If the field is not present, it means "stop now") Bill VerSteeg --_000_5177B2A348E4B64EAD7D589A027892D96A29EAB21DNAEXMSGC111re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bill,

 

Please send me the dr= aft for review once you are done with your editorial path, before we send it out fo= r review I would like to add my changes to the draft.  

 

Zeev

 <= /a>

From: Bill Ver Stee= g (versteb) [mailto:versteb@cisco.com]
Sent: Tuesday, March 31, 2009 11:46 AM
To: avt@ietf.org; Zeev Vax; Tom.Van_Caenegem@alcatel-lucent.be; Ali = C. Begen (abegen)
Subject: Rapid Acquisition of Multicast Streams (RAMS) - Fixed and T= LV fields

 

 

One of the primary action items arising from the review of the Rapid Acquisitio= n of Multicast Streams  draft is to identify which fields are mandatory (an= d thus fixed format) and which fields are optional (and thus TLV format).&nbs= p;Here is my take on the matter. Once we reach consensus, I will update the draft.=

 

I have also included a description of the requested "motivating text&quo= t; for the fields that do not already have such text in the document. Please l= et me know if I am on the right track.

 

There is currently no version number in the messages. Ali and I do not think that this is a problem because we can add new TLVs as needed. I = want to be sure we intentionally decide on this point rather than back into it accidently. Any comments?

 

We have 3 messages -

 

RAMS-Request

 Max Receive BitRate - mandatory

 Min Buffer Fill Requirement - optional ( Add wording - The receiver may ha= ve knowledge of it's buffering requirements. These requirements may be applica= tion or device specific. For instance, the receiver may need to have a cert= ain amount of data in it's application buffer to handle interdependency within = the data. If the RS knows the buffering ability of the receiver, it may more precisely tailor the burst to the client. The methods used by the receiver to determine this value is application specific, and thus out of scope. This mechanism can be used by the receiver to signal the sender, if the receiver has such knowledge )

 Max Buffer Fill Requirement - optional ( Add wording - The receiver may have knowledge of it's buffering requirements. These requirements may be applica= tion or device specific. For instance, one receiver may have more phys= ical memory than another receiver, and thus can buffer more data. If the RS know= s the buffering ability of the receiver, it may more precisely tailor the bur= st to the client. The methods used by the receiver to determine this value is application specific, and thus out of scope. This mechanism c= an be used by the receiver to signal the sender, if the receiver has such knowledge )

 

RAMS- Inform

 message Sequence Number - mandatory

 Response - mandatory, will include an enumerated list of response codes - 0 is succe= ed, non zero is an error code. We will enumerate a list of error codes, and note that additional error codes are possible using vendor-specific TLV fields. The enumerated errors will include [No server resources, No network resources, bad RMS-R request, WHAT ELSE????] Note - w= e have removed the "join now semantic, as that is captured in the "earliest join time" field. 

 Reserved - mandatory - must be all 0s

 Max Burst Bitrate - mandatory

 Rapid Acquisition Duration - mandatory - 0 means "join now" (Add wording to reflect that this is the server's current value, and can be changed by subsequent RMS-I. Add wording to reflect that the RS can't consume resources forever and needs to deterministically stop the flow= . The RS MUST terminate the flow at this time, even if does not get RMS-= T from the RR.  )

 Extended RTP Sequence Number of First Burst Packet - mandatory

 Earliest IGMP Join Time - optional (we should consider making this mandatory in at l= east one RMS-I, as the client needs to eventually join)

 

Rams -Terminate -

  Extended RTP seqnum of First Multicast packet - optional (intent is to tell the RS t= he seqnum at which to stop the burst, but leave the session open. If the field= is not present, it means "stop now")

 

 

 

Bill VerSteeg

--_000_5177B2A348E4B64EAD7D589A027892D96A29EAB21DNAEXMSGC111re_-- From zeevvax@microsoft.com Wed Apr 1 19:50:40 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 437C83A6A0E for ; Wed, 1 Apr 2009 19:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.83 X-Spam-Level: X-Spam-Status: No, score=-9.83 tagged_above=-999 required=5 tests=[AWL=0.768, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pf6CQ0afonaR for ; Wed, 1 Apr 2009 19:50:34 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 0985C3A6957 for ; Wed, 1 Apr 2009 19:50:33 -0700 (PDT) Received: from tk5-expfs-c104.redmond.corp.microsoft.com (157.54.88.62) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Wed, 1 Apr 2009 19:51:34 -0700 Received: from NA-EXMSG-C111.redmond.corp.microsoft.com ([157.54.61.138]) by tk5-expfs-c104.redmond.corp.microsoft.com ([157.54.88.62]) with mapi; Wed, 1 Apr 2009 19:51:34 -0700 From: Zeev Vax To: "Bill Ver Steeg (versteb)" , "Tom.Van_Caenegem@alcatel-lucent.be" , "Ali C. Begen (abegen)" Date: Wed, 1 Apr 2009 19:51:34 -0700 Thread-Topic: Rapid Acquisition of Multicast Streams (RAMS) - multiple RAMS-R messages for the same unicast flow Thread-Index: AcmyMO1Vf+4hrMHmQjCLzeIX0fZkSAAt6jegAApONVAABEpf4AACaGjg Message-ID: <5177B2A348E4B64EAD7D589A027892D96A29EAB64F@NA-EXMSG-C111.redmond.corp.microsoft.com> References: <81B9B88E2F9D574AA5328A85547CDE91EC162E@xmb-rtp-21d.amer.cisco.com><5177B2A348E4B64EAD7D589A027892D96A29EAB21D@NA-EXMSG-C111.redmond.corp.microsoft.com> <81B9B88E2F9D574AA5328A85547CDE91EC1C34@xmb-rtp-21d.amer.cisco.com> <81B9B88E2F9D574AA5328A85547CDE91EC1CAA@xmb-rtp-21d.amer.cisco.com> In-Reply-To: <81B9B88E2F9D574AA5328A85547CDE91EC1CAA@xmb-rtp-21d.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5177B2A348E4B64EAD7D589A027892D96A29EAB64FNAEXMSGC111re_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 02 Apr 2009 08:43:39 -0700 Cc: "avt@ietf.org" Subject: Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multiple RAMS-R messages for the same unicast flow X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 02:50:40 -0000 --_000_5177B2A348E4B64EAD7D589A027892D96A29EAB64FNAEXMSGC111re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with your conclusions, giving possible packet lose and the fact the= RS is not required to act on subsequent RMS-R, this would be the best way = to keep it simple. The statement I'm referring to is "In order to limit the complexity, I suggest that we state that the first r= eceived RMS-R triggers a RMS-I. Further RMS-R messages may flow. Further RM= S-I messages may also flow, but there is no explicit requirement to send an= RMS-I in response to a subsequent RMS-R." I don't think we need and monotonically increased sequence number, relayin= g on that will only complicate the RS decision making and error handling. Zeev From: Bill Ver Steeg (versteb) [mailto:versteb@cisco.com] Sent: Wednesday, April 01, 2009 4:52 PM To: Bill Ver Steeg (versteb); Zeev Vax; Tom.Van_Caenegem@alcatel-lucent.be;= Ali C. Begen (abegen) Cc: avt@ietf.org Subject: Rapid Acquisition of Multicast Streams (RAMS) - multiple RAMS-R me= ssages for the same unicast flow When we added the ability to send more than one RAMS-R message, we opened u= p a few design points that we now need to consider. We need to have some nomenclature for describing the "initial RMS-R" and "s= ubsequent RMS-R", so I will start with using those words. Better words woul= d be appreciated. The first design point I would like to address is what the RS is required t= o do when it receives an RAMS-R for a burst that is already in flow (aka "s= ubsequent RMS-R"). We stated that the least it could do was "ignore it". Do= es this imply that there is no requirement to send an RMS-I in response to = RMS-R messages referencing an in-progress flow? If so, we should add clarif= ying text in the document that cautions the RR not to assume the RAMS-R was= dropped. I briefly considered requiring the RS to send a RAMS-I for each r= eceived RAMS-R. Unfortunately, this then leads to another set of corner cas= es, and may result in a chatty exchange of messages. We also need to consider how to deterministically differentiate between the= initial RMS-R message and subsequent RMS-R messages, particularly in the e= vent of packet loss or (unlikely) re-ordering. This probably leads us to in= cluding a monotonically increasing sequence number on the RMS-R. Dropped RM= S-R messages should not be a protocol problem, as the first one received wi= ll trigger the burst. Subsequent RMS-R messages either change the burst sha= pe or they do not, and they do not trigger additional messages. Similarly, = if the initial RMS-I is dropped it will probably trigger an additional RMS-= R message. Subsequent RMS-I messages will either be received by the RR or t= hey will not, and they will not trigger additional messages. So, has anybody considered these design points in detail? I have started to= go down this path, but it gets complicated quickly. In order to limit the complexity, I suggest that we state that the first re= ceived RMS-R triggers a RMS-I. Further RMS-R messages may flow. Further RMS= -I messages may also flow, but there is no explicit requirement to send an = RMS-I in response to a subsequent RMS-R. Bill VerSteeg --_000_5177B2A348E4B64EAD7D589A027892D96A29EAB64FNAEXMSGC111re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with your conclusions, giving possible packet lose a= nd the fact the RS is not required to act on subsequent RMS-R, this would be t= he best way to keep it simple.

The statement I’m referring to is

“In order to limit the complexity, I suggest that we state that th= e first received RMS-R triggers a RMS-I. Further RMS-R messages may flow= . Further RMS-I messages may also flow, but there is no explicit requirement = to send an RMS-I in response to a subsequent RMS-R.”

I don’t think we need and monotonically increased &nbs= p;sequence number, relaying on that will only complicate the RS decision making and er= ror handling.

 

Zeev

   

 <= /a>

From: Bill Ver Stee= g (versteb) [mailto:versteb@cisco.com]
Sent: Wednesday, April 01, 2009 4:52 PM
To: Bill Ver Steeg (versteb); Zeev Vax; Tom.Van_Caenegem@alcatel-lucent.be; Ali C. Begen (abegen)
Cc: avt@ietf.org
Subject: Rapid Acquisition of Multicast Streams (RAMS) - multiple RA= MS-R messages for the same unicast flow

 

 

When we added the ability to send more than one RAMS-R message, we opened up a few design points that we now need to consider.

We need to have some nomenclature for describing the "initial RMS-R" and "subsequent RMS-R", so I will start with using those words. Better words would be appreciated.

The first design point I would like to address is what t= he RS is required to do when it receives an RAMS-R for a burst that is already in flow (aka "subsequent RMS-R"). We stated that the least it could = do was "ignore it". Does this imply that there is no requirement to = send an RMS-I in response to RMS-R messages referencing an in-progress flow? If = so, we should add clarifying text in the document that cautions the RR not to assume the RAMS-R was dropped. I briefly considered requiring the RS to sen= d a RAMS-I for each received RAMS-R. Unfortunately, this then leads to another = set of corner cases, and may result in a chatty exchange of messages.

We also need to consider how to deterministically differentiate between the initial RMS-R message and subsequent RMS-R messag= es, particularly in the event of packet loss or (unlikely) re-ordering. This probably leads us to including a monotonically increasing sequence number o= n the RMS-R. Dropped RMS-R messages should not be a protocol problem, as the first one received will trigger the burst. Subsequent RMS-R messages either change the burst shape or they do not, and they do not trigger additional messages. Similarly, if the initial RMS-I is dropped it will probably trigg= er an additional RMS-R message. Subsequent RMS-I messages will either be recei= ved by the RR or they will not, and they will not trigger additional messages.<= o:p>

So, has anybody considered these design points in detail= ? I have started to go down this path, but it gets complicated quickly.

In order to limit the complexity, I suggest that we stat= e that the first received RMS-R triggers a RMS-I. Further RMS-R messages may flow. Further RMS-I messages may also flow, but there is no explicit requirement to send an RMS-I in response to a subsequent RMS-R.<= /span>

 

Bill VerSteeg

--_000_5177B2A348E4B64EAD7D589A027892D96A29EAB64FNAEXMSGC111re_-- From oran@cisco.com Thu Apr 2 10:09:55 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A29C428C234 for ; Thu, 2 Apr 2009 10:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rNCkTgLpJe6 for ; Thu, 2 Apr 2009 10:09:55 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id BB50328C259 for ; Thu, 2 Apr 2009 10:09:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,315,1235952000"; d="scan'208";a="165735560" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-1.cisco.com with ESMTP; 02 Apr 2009 17:10:31 +0000 Received: from dhcp-161-44-173-104.cisco.com (dhcp-161-44-173-104.cisco.com [161.44.173.104]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id n32HBVfi027583; Thu, 2 Apr 2009 09:11:31 -0800 Message-Id: From: David R Oran To: Zou ZiXuan In-Reply-To: <006001c9b389$9de17620$d9a46260$@com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 13:10:27 -0400 References: <81B9B88E2F9D574AA5328A85547CDE91EC162E@xmb-rtp-21d.amer.cisco.com> <5177B2A348E4B64EAD7D589A027892D96A29EAB21D@NA-EXMSG-C111.redmond.corp.microsoft.com> <81B9B88E2F9D574AA5328A85547CDE91EC1C34@xmb-rtp-21d.amer.cisco.com> <81B9B88E2F9D574AA5328A85547CDE91EC1CAA@xmb-rtp-21d.amer.cisco.com> <99D207F9-2F80-48E8-95B0-DCE28D43B469@cisco.com> <006001c9b389$9de17620$d9a46260$@com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=751; t=1238692292; x=1239556292; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[AVT]=20Rapid=20Acquisition=20of=20Mult icast=20Streams=20(RAMS)=20-=20multiple=20RAMS-R=20messages= 20for=20the=20same=20unicast=20flow |Sender:=20 |To:=20Zou=20ZiXuan=20; bh=ecphpnc8slDE3mIbqBGsBbLiCR9Lj0sEi86hvxuwTtU=; b=jIIBdxXJiP+9rSkF8QNNmMH/t9wTzNRzVL6zr/DGIzhfVvJbLJ/q8iY0/x 0jQf5jxWvddZe3tCylOZDi3ZVBLvOIpudVky720ekdDhA8c8I5wuY0pu+XH3 fgkP9904J+; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: Tom.Van_Caenegem@alcatel-lucent.be, avt@ietf.org, "'Bill Ver Steeg \(versteb\)'" , 'Zeev Vax' Subject: Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multiple RAMS-R messages for the same unicast flow X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 17:09:55 -0000 On Apr 2, 2009, at 7:53 AM, Zou ZiXuan wrote: >> The RS shall reply to each RAMS-R fom the viewpoint of state >> machine.Nevertheless, >> subsequent RAMS-I messages is not trigged by reception of RAMS-R >> messages, > [ZiXuan] If subsequent RAM-I message is not triggered by reception of > RAMS-R, then why do we need a DIFFERENT field in the RAMS-I message? I > guess you meant those RAMS-I messages generated unilaterally by RS, is > my understanding correct? Yes, sorry if that wasn't clear. DaveO >> so I also think that adding a DIFFERENT field for the values in the > RAMS-I >> should be a good choice. >> In the meantime this can avoid having a seqnum on 2 of the 3 >> messages. >> >> Regards, >> >> Peilin >> >> > From rjesup@wgate.com Thu Apr 2 12:38:14 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FB353A6C62 for ; Thu, 2 Apr 2009 12:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.426 X-Spam-Level: X-Spam-Status: No, score=-1.426 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZlMp4xGAEBp for ; Thu, 2 Apr 2009 12:38:13 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id 362873A6D49 for ; Thu, 2 Apr 2009 12:38:13 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 15:39:14 -0400 To: "John Mattsson" References: <49D0E097.3000902@ericsson.com> From: Randell Jesup Date: Thu, 02 Apr 2009 15:39:41 -0400 In-Reply-To: (John Mattsson's message of "Thu, 2 Apr 2009 15:23:41 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 02 Apr 2009 19:39:14.0291 (UTC) FILETIME=[B4168430:01C9B3CA] Cc: AVT Subject: Re: [AVT] SRTP store-and-forward X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 19:38:14 -0000 "John Mattsson" writes: >>Rolf Blom writes: >>>To be able to handle an audio and a video stream using one security >>>context it is necessary to introduce a mechanism to give them separate >>>protection. We did that with the introduction of the SSS, the SRTP SaF >>>Source. It s also necessary to be able to indicate which e2e security >>>context that the media is using and thus a CCI, Crypto Context >>>Identifier is needed. So we believe that what we have presented is >>>general enough but still is a very thin design providing not more than >>>what is really needed. >>> >>>Cullen gave an example in which it was essential that what is forwarded >>>is the complete message that was received by the SaF middlebox (do not >>>launch the missile!). Even if I believe that such a message wouldn't be >>>left on an answering machine - it probably should be delivered directly >>>to eliminate the risk for mistakes - it points at a possible threat. >>>This threat might perhaps be countered by some RTCP signaling messages >>>e2e. However, in the current draft-naslund-saf-00 we do not provide e2e >>>integrity protected RTCP. Is this a problem? Should it be added? Or are >>>there other application layer mechanisms that should be applied? Note >>>that with an e2e integrity transform and letting PUV be a counter, it is >>>possible to detect replays and re-orderings at the application >>>layer. However, it will not guarantee that all packets are forwarded. >>>Note that the threat discussed is outside the trust model assumed for >>>SRTP store-and-forward, which assumes a honest but curious SaF >>>middlebox. > >Randell Jesup writes: >>You need to at least include RTCP as well, or synchronization between >>streams (audio and video) cannot be done. Protecting it would be smart, >>though probably not strictly necessary. (If not protected, someone >>could mess with the stream sync, possibly tickling bugs in the player >>or causing one stream or the other to never play, to jump around, or to >>be unintelligible.) > >Our intention have always been that the middlebox saves the relevant >parts of RTCP (e.g. SR, APP) and retransmits them to the final receiver. Ok, though I don't know how the midbox would know what RTCP packets are relevant in all cases, especially if they're RTCP sub-packets that are defined after the midbox is written/updated. >As RTCP is protected hop-by-hop, the only one that could mess with the >synchronization is the middlebox, which according to our trust model is >trusted not to do so. RTCP is protected end-to-end normally, not hop-to-hop (excluding B2BUAs - perhaps you're assuming a B2BUA, but then RTP isn't end-to-end protected either). And I'm confused (probably by not reading the recent versions of this): why are you assuming that the midbox is trusted? And if it's trusted, why are you not decrypting the message, then re-encrypting for playback, avoiding the entirety (or most of it) of the need for this draft? I'd assumed SRTP Store-and-forward was supposed to assume a lack of trust in the box doing the storing, beyond that it would do the forwarding when asked. I.e. allow a message to be stored on an insecure server in a secure manner; avoiding the possibility that the contents could be snooped or modified. (Obviously they could be deleted or truncated.) >Most of what can be achieved by messing with the synchronization could be >done by not forwarding chosen packets. Simple refutation: set the current NTP time via RTCP for the one stream to be 20 years in the future. The user will probably hear the audio and see no video (or a still image); or the other way around, depending on how the client works. (Some very dumb clients might ignore this.) Alternate refutation: cause the NTP time to jump around (forward and backwards); this could cause all sorts of nasty effects depending on the client. >We thought about protecting RTCP e2e but felt that it creates more >problems than it solves. Parts of RTCP should be sent e2e and other parts >only hbh, for RTCP APP, this distinction is application dependant. If >there is a need to protect against a synchronization messing middlebox, >the audio and video should encoded in a format that can be sent in a >single stream. You can do that, but then you lose the ability to leverage all the tools that understand audio/video streams; it no longer is an extension to existing abilities, but a new, separate tool for messages. The question is: what is the reason(s) for SRTP usage, and how does that map to the usecase you're trying to handle here (storing messages)? Who are you protecting against; what level of interference needs to be overcome? -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From tom.taylor@rogers.com Thu Apr 2 19:14:57 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F49428C0FA for ; Thu, 2 Apr 2009 19:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.258 X-Spam-Level: X-Spam-Status: No, score=-1.258 tagged_above=-999 required=5 tests=[AWL=-0.518, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxp6rAQADC7t for ; Thu, 2 Apr 2009 19:14:57 -0700 (PDT) Received: from smtp120.rog.mail.re2.yahoo.com (smtp120.rog.mail.re2.yahoo.com [68.142.224.75]) by core3.amsl.com (Postfix) with SMTP id BD66A3A685E for ; Thu, 2 Apr 2009 19:14:56 -0700 (PDT) Received: (qmail 51173 invoked from network); 3 Apr 2009 02:15:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=Ap51sBLf3QaCyR/GlJF+rhAFQSJ4uP1sdgLBBcN2h3vCWlrYhiAg7cXZ1gHa6uGCUs31TudggwXymMq0DangoltBozLfdjc70ntcCdMvqZaXurMCaRIw/fyyJsmGIbG12d2aJeYdJUewABC5ohwMl0rTkeae5T8kxhH6yEINGJw= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@72.140.46.24 with plain) by smtp120.rog.mail.re2.yahoo.com with SMTP; 3 Apr 2009 02:15:58 -0000 X-YMail-OSG: vMKrlt4VM1n8237L6ICsmyqtg.MXyKV9aY2QBJlhB0o7ATcnSlHDPtmSEiDInw.X8Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D5715E.3080805@rogers.com> Date: Thu, 02 Apr 2009 22:15:58 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: IETF AVT WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [AVT] Inconsistent attribute name in RFC 3611 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 02:14:57 -0000 RFC 3611 defines the attribute rcvr-rtt in the SDP section, but uses recv-rtt in the text and the IANA Considerations section. Alan Clark suggests that the SDP section should prevail, but it seems like a good idea to check on what has been implemented first. Do people have views one way or the other? Tom Taylor From yangpeilin@huawei.com Thu Apr 2 19:53:46 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E163D3A6962 for ; Thu, 2 Apr 2009 19:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.541 X-Spam-Level: **** X-Spam-Status: No, score=4.541 tagged_above=-999 required=5 tests=[AWL=-2.598, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVrD-UummZdy for ; Thu, 2 Apr 2009 19:53:46 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CB1013A685E for ; Thu, 2 Apr 2009 19:53:45 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHI00JZD831FE@szxga04-in.huawei.com> for avt@ietf.org; Fri, 03 Apr 2009 10:54:37 +0800 (CST) Received: from huawei.com ([172.17.1.31]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHI0059G830DU@szxga04-in.huawei.com> for avt@ietf.org; Fri, 03 Apr 2009 10:54:37 +0800 (CST) Received: from [172.24.1.24] (Forwarded-For: [10.164.12.60]) by szxmc03-in.huawei.com (mshttpd); Fri, 03 Apr 2009 10:54:36 +0800 Date: Fri, 03 Apr 2009 10:54:36 +0800 From: Peilin YANG In-reply-to: <81B9B88E2F9D574AA5328A85547CDE91F26279@xmb-rtp-21d.amer.cisco.com> To: "Bill Ver Steeg (versteb)" Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <49c91f64.20038e0a.7d29.fffff161@mx.google.com> <81B9B88E2F9D574AA5328A85547CDE91F26279@xmb-rtp-21d.amer.cisco.com> Cc: Jonathan Lennox , Xavier Marjou , sean.sheedy@arrisi.com, "Dave Oran \(oran\)" , avt@ietf.org, Ingemar Johansson S Subject: [AVT] =?gb2312?b?u9i4tCA6VXBkYXRlIHRvIFJhcGlkIEFjcXVpc2l0aW9uIG9m?= =?gb2312?b?IE11bHRpY2FzdCBTZXNzaW9ucyAoUkFNUykgZG9jdW1lbnQgZnJvbSBvdXRw?= =?gb2312?b?dXQgb2YgSUVURiBicmVhayBvdXQgc2Vzc2lvbg==?= X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 02:53:47 -0000 Hi Bill=2C I will review the draft and send comments later=2E Peilin *************************************************************************= ***************** This email and its attachments contain confidential information from HUA= WEI=2C which is intended only for the person or entity whose address is l= isted above=2E Any use of the information contained here in any way (incl= uding=2C but not limited to=2C total or partial disclosure=2C reproductio= n=2C or dissemination) by persons other than the intended recipient(s) is= prohibited=2E If you receive this email in error=2C please notify the se= nder by phone or email immediately and delete it! ************************************************************************= ***************** ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A =22Bill Ver Steeg (versteb)=22 =3Cversteb=40cisco=2E= com=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CE=E5=2C =CB=C4=D4=C2 3=C8=D5=2C 2009 =C9=CF= =CE=E73=3A47 =D6=F7=CC=E2=3A Update to Rapid Acquisition of Multicast Sessions (RAMS) = document from output of IETF break out session =CA=D5=BC=FE=C8=CB=3A Roni Even =3Cron=2Eeven=2Etlv=40gmail=2Ecom=3E=2C I= ngemar Johansson S =3Cingemar=2Es=2Ejohansson=40ericsson=2Ecom=3E=2C zeev= vax=40microsoft=2Ecom=2C Xavier Marjou =3Cxavier=2Emarjou=40orange-ftgrou= p=2Ecom=3E=2C =22Dave Oran (oran)=22 =3Coran=40cisco=2Ecom=3E=2C Orit Lev= in =3Coritl=40microsoft=2Ecom=3E=2C Peilin YANG =3Cyangpeilin=40huawei=2E= com=3E=2C Tom Taylor =3Ctom=2Etaylor=40rogers=2Ecom=3E =B3=AD=CB=CD=3A =22Ali C=2E Begen (abegen)=22 =3Cabegen=40cisco=2Ecom=3E=2C= Ye-Kui Wang =3Cyekuiwang=40huawei=2Ecom=3E=2C Tom=2EVan=5FCaenegem=40alc= atel-lucent=2Ebe=2C Haibin Song =3Cmelodysong=40huawei=2Ecom=3E=2C zongni= ng 63316 =3Czongning=40huawei=2Ecom=3E=2C Jonathan Lennox =3Cjonathan=40v= idyo=2Ecom=3E=2C sean=2Esheedy=40arrisi=2Ecom =3E The following preliminary document captures the recommended = =3E changes to =3E the =22Rapid Acquisition of Multicast Sessions (RAMS)=22 draft from t= he =3E technical break out session in San Francisco last week=2E I think = =3E that I =3E captured the major points from the session=2C as well as the recent =3E clarifications on the AVT list=2E There are still a few editor=27s no= tes =3E that need to be resolved=2C and the embedded ascii art needs = =3E cleanup=2C but =3E I think we made good progress=2E =3E = =3E Zeev is currently making some additional editorial changes=2C but we =3E wanted to give the attendees plus the folks who have made suggestions= =3E the opportunity to verify the major points in a timely fashion=2E =3E = =3E If you feel that the document is missing significant changes=2C = =3E please let =3E us know=2E If you have minor editorial comments=2C please hold them u= ntil =3E next week=2E We will be better able to word-smith once Zeev = =3E completes his =3E pass through the document=2E =3E = =3E = =3E Bill VerSteeg =3E From magnus.westerlund@ericsson.com Fri Apr 3 02:38:50 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBEF63A6D8E for ; Fri, 3 Apr 2009 02:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.171 X-Spam-Level: X-Spam-Status: No, score=-6.171 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxEztzjnaQM7 for ; Fri, 3 Apr 2009 02:38:49 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9EFC328C27E for ; Fri, 3 Apr 2009 02:38:23 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D226821264; Fri, 3 Apr 2009 11:39:24 +0200 (CEST) X-AuditID: c1b4fb3e-ac820bb0000024d5-98-49d5d94cccad Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B02A7211EB; Fri, 3 Apr 2009 11:39:24 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 11:39:22 +0200 Received: from [147.214.183.173] ([147.214.183.173]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 11:39:22 +0200 Message-ID: <49D5D94A.7030707@ericsson.com> Date: Fri, 03 Apr 2009 11:39:22 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: RFC Errata System References: <200904030934.n339Yqs6006876@boreas.isi.edu> In-Reply-To: <200904030934.n339Yqs6006876@boreas.isi.edu> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 03 Apr 2009 09:39:22.0326 (UTC) FILETIME=[119E3F60:01C9B440] X-Brightmail-Tracker: AAAAAA== Cc: fluffy@cisco.com, jon.peterson@neustar.biz, tom.taylor@rogers.com, avt@ietf.org, ingemar.s.johansson@ericsson.com Subject: Re: [AVT] [Editorial Errata Reported] RFC5404 (1754) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 09:38:50 -0000 Hi, I reported this errata to keep track of the fact that the reference is not correct. I don't think there is any issue with anyone not finding G.719 due to this. I would recommend a state of "Hold for document update". Cheers Magnus RFC Errata System skrev: > The following errata report has been submitted for RFC5404, > "RTP Payload Format for G.719". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5404&eid=1754 > > -------------------------------------- > Type: Editorial > Reported by: Magnus Westerlund > > Section: 12.1 > > Original Text > ------------- > [ITU-T-G719] ITU-T, "Specification : ITU-T G.719 extension for 20 > kHz fullband audio", April 2008. > > > Corrected Text > -------------- > [ITU-T-G719] ITU-T, "Specification: ITU-T G.719 Low-complexity, full-band audio coding for high-quality, conversational applications", June 2008. > > Notes > ----- > Steven Botzko informed me that the Reference title is not correct, nor is the publication date for the G.719 reference. However, there should be little issues with finding the correct reference based on Recommendation number. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5404 (draft-ietf-avt-rtp-g719-04) > -------------------------------------- > Title : RTP Payload Format for G.719 > Publication Date : January 2009 > Author(s) : M. Westerlund, I. Johansson > Category : PROPOSED STANDARD > Source : Audio/Video Transport > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ron.even.tlv@gmail.com Fri Apr 3 05:08:42 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C683B3A6B59 for ; Fri, 3 Apr 2009 05:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fapui+z-kZmF for ; Fri, 3 Apr 2009 05:08:41 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 475F83A6946 for ; Fri, 3 Apr 2009 05:08:41 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 22so857691fge.18 for ; Fri, 03 Apr 2009 05:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=mDi3ZBHix5CEMDLD0cQrCtLvZKmIdvkhR2gikm4T/II=; b=pDiSmnnM94wTqGmbaAapM6bcm9ymyZ1/mePqC6HQTnZKhmmAqZrN+IM6pgybhxIM3j 66FY8VON7wfWzNdmjvHF3rFQcCf6EzOK4O7C7nSFp+87SBI5EdzJkfSF6E8R1koFHNAz zWrrYkn64TGzZr4wVzfS6gUBpfnz4LvEKjY/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=vcn/kmAAu7VD+kBYIpQMEiqALFX2FQ5dB6tkPo/HA83zJeMYAUq2MwzcyJyV+YlDJo Qtb3za/dNZzC2GQ99q4bwu04VYR8MiOfEgqPf9ADa9Y1krE1cldCToAe9GFBP6SdrM0e IKVe0rICJonWm967EF05MdVRT8Vx8AemTA1Ns= Received: by 10.86.3.4 with SMTP id 4mr928402fgc.41.1238760582876; Fri, 03 Apr 2009 05:09:42 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-112-250.red.bezeqint.net [79.179.112.250]) by mx.google.com with ESMTPS id 3sm3816900fge.9.2009.04.03.05.09.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 03 Apr 2009 05:09:42 -0700 (PDT) From: "Roni Even" To: "'Magnus Westerlund'" , "'RFC Errata System'" References: <200904030934.n339Yqs6006876@boreas.isi.edu> <49D5D94A.7030707@ericsson.com> In-Reply-To: <49D5D94A.7030707@ericsson.com> Date: Fri, 3 Apr 2009 15:08:17 +0300 Message-ID: <49d5fc86.0305560a.0a37.ffffd8f5@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm0QBM2K2hPgpBmTWSCpWyuGu6fbQAFLDtw Content-Language: en-us Cc: fluffy@cisco.com, jon.peterson@neustar.biz, avt@ietf.org, tom.taylor@rogers.com, ingemar.s.johansson@ericsson.com Subject: Re: [AVT] [Editorial Errata Reported] RFC5404 (1754) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 12:08:42 -0000 Hi, I support Magnus on this. Roni Even -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Friday, April 03, 2009 12:39 PM To: RFC Errata System Cc: ingemar.s.johansson@ericsson.com; rjsparks@nostrum.com; jon.peterson@neustar.biz; fluffy@cisco.com; ron.even.tlv@gmail.com; tom.taylor@rogers.com; avt@ietf.org Subject: Re: [Editorial Errata Reported] RFC5404 (1754) Hi, I reported this errata to keep track of the fact that the reference is not correct. I don't think there is any issue with anyone not finding G.719 due to this. I would recommend a state of "Hold for document update". Cheers Magnus RFC Errata System skrev: > The following errata report has been submitted for RFC5404, > "RTP Payload Format for G.719". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5404&eid=3D1754 >=20 > -------------------------------------- > Type: Editorial > Reported by: Magnus Westerlund >=20 > Section: 12.1 >=20 > Original Text > ------------- > [ITU-T-G719] ITU-T, "Specification : ITU-T G.719 extension for 20 > kHz fullband audio", April 2008. >=20 >=20 > Corrected Text > -------------- > [ITU-T-G719] ITU-T, "Specification: ITU-T G.719 Low-complexity, = full-band audio coding for high-quality, conversational applications", June 2008. >=20 > Notes > ----- > Steven Botzko informed me that the Reference title is not correct, nor = is the publication date for the G.719 reference. However, there should be little issues with finding the correct reference based on Recommendation number. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5404 (draft-ietf-avt-rtp-g719-04) > -------------------------------------- > Title : RTP Payload Format for G.719 > Publication Date : January 2009 > Author(s) : M. Westerlund, I. Johansson > Category : PROPOSED STANDARD > Source : Audio/Video Transport > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG >=20 --=20 Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From oran@cisco.com Fri Apr 3 05:51:25 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E1CF3A6B23 for ; Fri, 3 Apr 2009 05:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.609 X-Spam-Level: X-Spam-Status: No, score=-6.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ar8JnKJ+wnr for ; Fri, 3 Apr 2009 05:51:24 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CDB073A6AC4 for ; Fri, 3 Apr 2009 05:51:19 -0700 (PDT) Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 03 Apr 2009 12:52:22 +0000 Received: from stealth-10-32-245-156.cisco.com ([10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id n33CrJTF010303; Fri, 3 Apr 2009 04:53:20 -0800 Message-Id: From: David R Oran To: IETF AVT WG In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 3 Apr 2009 08:52:20 -0400 References: <04CAD96D4C5A3D48B1919248A8FE0D540902ABA8@xmb-sjc-215.amer.cisco.com> <04735F6A-72A6-47B1-AFAE-D3FB855847CD@cisco.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1233; t=1238763200; x=1239627200; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[AVT]=20Inconsistent=20attribute=20name =20in=20RFC=203611 |Sender:=20 |To:=20IETF=20AVT=20WG=20; bh=vKnB+KI7uPa2zWpqL2jXCcj27T3KmPR6vCUWENWgvOE=; b=SiI43juzDtgPq89QiFl/cQg0Ux9iax4RwEhrKSGUCd5GwN1IEBa1+rA/Ke z3O+Y/z60XZyjOx/dh5LmmocOYcHwLPI//HGH2aoIV5DAzp1VVRVXqAtST8x JcrVGsy1lH; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Subject: Re: [AVT] Inconsistent attribute name in RFC 3611 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 12:51:25 -0000 I just checked and the Cisco IPTV code uses rcvr-rtt. Just goes to show that for implementers they copy stuff from the examples rather than the spec! So, we'd obviously prefer that the errata change the IANA registration and the spec text rather than the example, but if given some time to switch (it takes 2 release to make such a change since this is a red/ green style packet problem) we can deal with either. DaveO. >>> -----Original Message----- >>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On >> Behalf Of >>> Tom Taylor >>> Sent: Thursday, April 02, 2009 7:16 PM >>> To: IETF AVT WG >>> Subject: [AVT] Inconsistent attribute name in RFC 3611 >>> >>> RFC 3611 defines the attribute rcvr-rtt in the SDP section, >> but uses >>> recv-rtt in the text and the IANA Considerations section. >> Alan Clark >>> suggests that the SDP section should prevail, but it seems >> like a good >>> idea to check on what has been implemented first. Do people >> have views >>> one way or the other? >>> >>> Tom Taylor >>> _______________________________________________ >>> Audio/Video Transport Working Group >>> avt@ietf.org >>> https://www.ietf.org/mailman/listinfo/avt >> >> From magnus.westerlund@ericsson.com Fri Apr 3 06:07:28 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 712B53A6D12 for ; Fri, 3 Apr 2009 06:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.175 X-Spam-Level: X-Spam-Status: No, score=-6.175 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhVDAtj6+nWb for ; Fri, 3 Apr 2009 06:07:27 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2E9E83A6AF5 for ; Fri, 3 Apr 2009 06:07:27 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 113DF20D3A; Fri, 3 Apr 2009 15:08:25 +0200 (CEST) X-AuditID: c1b4fb3c-a9ee5bb000003b08-1c-49d60a4873af Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 73CAF20FA6; Fri, 3 Apr 2009 15:08:24 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 15:07:36 +0200 Received: from [147.214.183.173] ([147.214.183.173]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 15:07:36 +0200 Message-ID: <49D60A18.1090400@ericsson.com> Date: Fri, 03 Apr 2009 15:07:36 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: IETF AVT WG , Cullen Jennings X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 03 Apr 2009 13:07:36.0704 (UTC) FILETIME=[28D90800:01C9B45D] X-Brightmail-Tracker: AAAAAA== Subject: [AVT] erratas on RFC 5117 (RTP Topologies) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 13:07:28 -0000 Hi, I am looking on the filed Erratas for the RTP topologies (RFC 5117). I think all fall into the category of "Hold for document update". I would recommend that Cullen verify them into this state. Cheers Magnus RFC5117, "RTP Topologies", January 2008 Source of RFC: avt (rai) Errata ID: 1312 Status: Reported Type: Editorial Reported By: Alfred Hoenes Date Reported: 2008-02-13 Section 3.3, 5th par says: Stand-alone Media Translators are rare. Most commonly, a combination | of Transport and Media Translators are used to translate both the media stream and the transport aspects of a stream between two transport domains (or clouds). It should say: Stand-alone Media Translators are rare. Most commonly, a combination | of Transport and Media Translators is used to translate both the media stream and the transport aspects of a stream between two transport domains (or clouds). Notes: "A combination ... *is* used ..." ! Errata ID: 1313 Status: Reported Type: Editorial Reported By: Alfred Hoenes Date Reported: 2008-02-13 Section 3.3,pg.7 says: [...]. Therefore, if the Receiver Reports were forwarded without changes, the extended highest sequence number would indicate that B were substantially behind in reception, while it most | likely it would not be. [...] ^^^^ It should say: [...]. Therefore, if the Receiver Reports were forwarded without changes, the extended highest sequence number would indicate that B were substantially behind in reception, while it most | likely would not be. [...] ^ Notes: Spurious word replication; location is 4th-to-last line on page 7. Errata ID: 1314 Status: Reported Type: Editorial Reported By: Alfred Hoenes Date Reported: 2008-02-13 Section 3.4, pg.9 says: [...]. The CSRC Count (CC) and CSRC fields in the RTP header | are used to indicate the contributors of to the newly generated stream. The SSRCs of the to-be-mixed streams on the Mixer input appear as the CSRCs at the Mixer output. That output stream uses a | unique SSRC that identifies the Mixer's stream. The CSRC are forwarded between the two domains to allow for loop detection and identification of sources that are part of the global session. [...] It should say: [...]. The CSRC Count (CC) and CSRC fields in the RTP header | are used to indicate the contributors to the newly generated stream. The SSRCs of the to-be-mixed streams on the Mixer input appear as the CSRCs at the Mixer output. That output stream uses a | unique SSRC that identifies the Mixer's stream. The CSRCs are forwarded between the two domains to allow for loop detection and identification of sources that are part of the global session. [...] Notes: Near the bottom of page 9: a) s/of to/to/ ^^^ b) s/The CSRC are/The CSRCs are/ ^ Errata ID: 1315 Status: Reported Type: Editorial Reported By: Alfred Hoenes Date Reported: 2008-02-13 Section 3.4, pg.10 says: A Mixer is responsible for receiving RTCP feedback messages and handling them appropriately. The definition of "appropriate" depends on the message itself and the context. In some cases, the reception of a codec-control message may result in the generation and transmission of RTCP feedback messages by the Mixer to the | participants in the other domain. In other cases, a message is handled by the Mixer itself and therefore not forwarded to any other domain. It should say: A Mixer is responsible for receiving RTCP feedback messages and handling them appropriately. The definition of "appropriate" depends on the message itself and the context. In some cases, the reception of a codec-control message may result in the generation and transmission of RTCP feedback messages by the Mixer to the | participants in the other domain(s). In other cases, a message is handled by the Mixer itself and therefore not forwarded to any other domain. Notes: Location is 4th paragraph on page 10. Rationale: There may be more than one "other" domain; in particular, this *is* the case in the example discussed in the text (cf. Figure 5 on page 9). Errata ID: 1316 Status: Reported Type: Editorial Reported By: Alfred Hoenes Date Reported: 2008-02-13 Section 4.1.5, p.16 says: ... handled correctly in domain bridging function. [...] It should say: Either: ... handled correctly in domain bridging functions. [...] Or (less preferable): ... handled correctly in a domain bridging function. [...] -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From web-usrn@ISI.EDU Fri Apr 3 02:34:33 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 138F33A6D72 for ; Fri, 3 Apr 2009 02:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.247 X-Spam-Level: X-Spam-Status: No, score=-17.247 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scFy60mWtIG9 for ; Fri, 3 Apr 2009 02:34:32 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 46BB73A6D6F for ; Fri, 3 Apr 2009 02:34:32 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n339YqMf006878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Apr 2009 02:34:53 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n339Yqs6006876; Fri, 3 Apr 2009 02:34:52 -0700 (PDT) Date: Fri, 3 Apr 2009 02:34:52 -0700 (PDT) Message-Id: <200904030934.n339Yqs6006876@boreas.isi.edu> To: magnus.westerlund@ericsson.com, ingemar.s.johansson@ericsson.com, rjsparks@nostrum.com, jon.peterson@neustar.biz, fluffy@cisco.com, ron.even.tlv@gmail.com, tom.taylor@rogers.com From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu X-Mailman-Approved-At: Fri, 03 Apr 2009 08:04:26 -0700 Cc: magnus.westerlund@ericsson.com, avt@ietf.org, rfc-editor@rfc-editor.org Subject: [AVT] [Editorial Errata Reported] RFC5404 (1754) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 09:34:33 -0000 The following errata report has been submitted for RFC5404, "RTP Payload Format for G.719". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5404&eid=1754 -------------------------------------- Type: Editorial Reported by: Magnus Westerlund Section: 12.1 Original Text ------------- [ITU-T-G719] ITU-T, "Specification : ITU-T G.719 extension for 20 kHz fullband audio", April 2008. Corrected Text -------------- [ITU-T-G719] ITU-T, "Specification: ITU-T G.719 Low-complexity, full-band audio coding for high-quality, conversational applications", June 2008. Notes ----- Steven Botzko informed me that the Reference title is not correct, nor is the publication date for the G.719 reference. However, there should be little issues with finding the correct reference based on Recommendation number. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5404 (draft-ietf-avt-rtp-g719-04) -------------------------------------- Title : RTP Payload Format for G.719 Publication Date : January 2009 Author(s) : M. Westerlund, I. Johansson Category : PROPOSED STANDARD Source : Audio/Video Transport Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From john.mattsson@ericsson.com Fri Apr 3 09:41:09 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DD8328C1E1 for ; Fri, 3 Apr 2009 09:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCJO2h+WOotR for ; Fri, 3 Apr 2009 09:41:08 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C372B28C121 for ; Fri, 3 Apr 2009 09:41:07 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2821521E93; Fri, 3 Apr 2009 18:42:09 +0200 (CEST) X-AuditID: c1b4fb3c-a7ee1bb000003b08-96-49d63c6008d7 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D7C6321E86; Fri, 3 Apr 2009 18:42:08 +0200 (CEST) Received: from esealmw121.eemea.ericsson.se ([153.88.200.80]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 18:41:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Apr 2009 18:41:18 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] SRTP store-and-forward Thread-Index: AcmyFtwddoa4DdtHTvuOdbiK1SGRFwBfu1dwADkF2WA= References: <49D0E097.3000902@ericsson.com> From: "John Mattsson" To: "Randell Jesup" X-OriginalArrivalTime: 03 Apr 2009 16:41:19.0574 (UTC) FILETIME=[03DFB760:01C9B47B] X-Brightmail-Tracker: AAAAAA== Cc: AVT Subject: Re: [AVT] SRTP store-and-forward X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 16:41:09 -0000 Randell Jesup writes: >>>You need to at least include RTCP as well, or synchronization between >>>streams (audio and video) cannot be done. Protecting it would be=20 >>>smart, though probably not strictly necessary. (If not protected,=20 >>>someone could mess with the stream sync, possibly tickling bugs in the=20 >>>player or causing one stream or the other to never play, to jump=20 >>>around, or to be unintelligible.) =20 >>Our intention have always been that the middlebox saves the relevant=20 >>parts of RTCP (e.g. SR, APP) and retransmits them to the final receiver. =20 >Ok, though I don't know how the midbox would know what RTCP packets are >relevant in all cases, especially if they're RTCP sub-packets that are >defined after the midbox is written/updated. =20 This is a general problem for store-and-forward of RTP and not specific to SRTP SaF. You are right in that the middlebox cannot know which RTCP packets are relevant in all future cases and might need to be updated. I think that a simple policy were the middlebox forwards the information it knows should be forwarded e2e (e.g. synch info) and the information it does not recognize (e.g. RTCP APP) goes a long way. =20 >>As RTCP is protected hop-by-hop, the only one that could mess with the >>synchronization is the middlebox, which according to our trust model is=20 >>trusted not to do so. =20 >RTCP is protected end-to-end normally, not hop-to-hop (excluding B2BUAs - >perhaps you're assuming a B2BUA, but then RTP isn't end-to-end protected >either). And I'm confused (probably by not reading the recent versions of >this): why are you assuming that the midbox is trusted? And if it's >trusted, why are you not decrypting the message, then re-encrypting for >playback, avoiding the entirety (or most of it) of the need for this >draft? =20 >I'd assumed SRTP Store-and-forward was supposed to assume a lack of trust >in the box doing the storing, beyond that it would do the forwarding when >asked. I.e. allow a message to be stored on an insecure server in a >secure manner; avoiding the possibility that the contents could be >snooped or modified. (Obviously they could be deleted or truncated.) =20 The middlebox is exactly as you say only trusted to do the forwarding when asked (including unmodified synchronization info). We call this semi-trusted in the draft. If the middlebox is totally untrusted it would be meaningless to use for anything. We do not trust the middlebox with cleartext data. =20 >>Most of what can be achieved by messing with the synchronization could >>be done by not forwarding chosen packets. =20 >Simple refutation: set the current NTP time via RTCP for the one stream >to be 20 years in the future. The user will probably hear the audio and >see no video (or a still image); or the other way around, depending on >how the client works. (Some very dumb clients might ignore this.) =20 >Alternate refutation: cause the NTP time to jump around (forward and >backwards); this could cause all sorts of nasty effects depending on >the client. =20 I agree, the middlebox could cause the the NTP time to jump around. The semi-trusted middlebox is however trusted to forward the packets without modifing them. =20 >>We thought about protecting RTCP e2e but felt that it creates more=20 >>problems than it solves. Parts of RTCP should be sent e2e and other=20 >>parts only hbh, for RTCP APP, this distinction is application=20 >>dependant. If there is a need to protect against a synchronization=20 >>messing middlebox, the audio and video should encoded in a format that >>can be sent in a single stream. =20 >You can do that, but then you lose the ability to leverage all the tools >that understand audio/video streams; it no longer is an extension to >existing abilities, but a new, separate tool for messages. =20 >The question is: what is the reason(s) for SRTP usage, and how does that >map to the usecase you're trying to handle here (storing messages)? Who >are you protecting against; what level of interference needs to be overcome? =20 The main thing that we are protecting is the confidentiality of the data. If you look at the use cases described in the drafts, I think you will agree that in these use cases it is reasonable to assume that the middleboxes are what we call semi-trusted. If one absolutely needs to use a middlebox which is not trusted to not modify the synchronization info and if modification of the synchronization info is seen as an unacceptable risk, one might be limited to a smaller set of formats and tools. / John Mattsson From tom.taylor@rogers.com Fri Apr 3 15:54:56 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D99AE3A6944 for ; Fri, 3 Apr 2009 15:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qj8cWc8KSsoe for ; Fri, 3 Apr 2009 15:54:56 -0700 (PDT) Received: from smtp105.rog.mail.re2.yahoo.com (smtp105.rog.mail.re2.yahoo.com [206.190.36.83]) by core3.amsl.com (Postfix) with SMTP id DA2893A691B for ; Fri, 3 Apr 2009 15:54:55 -0700 (PDT) Received: (qmail 50045 invoked from network); 3 Apr 2009 22:55:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=P/DgrmtXf6jamYCVpJZq4FzmsawYC5aOVVkhpon87XAogxKRXI0+clO5zP3dzrETFICWWmaoueUmU6D0dfImjC64QD93MdZnGGKe4WNOB1cs2O57YElw4CbnbBrYT0ihEsD7sCLeV1cNLSYk59x+pmFyW0RPyZSHsUwDiC3jHIU= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@72.140.46.24 with plain) by smtp105.rog.mail.re2.yahoo.com with SMTP; 3 Apr 2009 22:55:58 -0000 X-YMail-OSG: tJwHztIVM1kWGK99Oafkz06DKrJqsR635qD.drDpWXSD1uXNCc.HRysWRvTLChZjZw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D693FE.2000506@rogers.com> Date: Fri, 03 Apr 2009 18:55:58 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David R Oran References: <04CAD96D4C5A3D48B1919248A8FE0D540902ABA8@xmb-sjc-215.amer.cisco.com> <04735F6A-72A6-47B1-AFAE-D3FB855847CD@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF AVT WG Subject: Re: [AVT] Inconsistent attribute name in RFC 3611 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 22:54:56 -0000 Maybe I'm being hasty, but the general opinion seems to be to go with rcvr-rtt. David R Oran wrote: > I just checked and the Cisco IPTV code uses rcvr-rtt. > > Just goes to show that for implementers they copy stuff from the > examples rather than the spec! > > So, we'd obviously prefer that the errata change the IANA registration > and the spec text rather than the example, but if given some time to > switch (it takes 2 release to make such a change since this is a > red/green style packet problem) we can deal with either. > > DaveO. > > >>>> -----Original Message----- >>>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On >>> Behalf Of >>>> Tom Taylor >>>> Sent: Thursday, April 02, 2009 7:16 PM >>>> To: IETF AVT WG >>>> Subject: [AVT] Inconsistent attribute name in RFC 3611 >>>> >>>> RFC 3611 defines the attribute rcvr-rtt in the SDP section, >>> but uses >>>> recv-rtt in the text and the IANA Considerations section. >>> Alan Clark >>>> suggests that the SDP section should prevail, but it seems >>> like a good >>>> idea to check on what has been implemented first. Do people >>> have views >>>> one way or the other? >>>> >>>> Tom Taylor >>>> _______________________________________________ >>>> Audio/Video Transport Working Group >>>> avt@ietf.org >>>> https://www.ietf.org/mailman/listinfo/avt >>> >>> > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > From fluffy@cisco.com Sat Apr 4 04:45:53 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B0F63A67F6 for ; Sat, 4 Apr 2009 04:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.581 X-Spam-Level: X-Spam-Status: No, score=-106.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-OILF-yoWi6 for ; Sat, 4 Apr 2009 04:45:52 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6A1FA3A6818 for ; Sat, 4 Apr 2009 04:45:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,323,1235952000"; d="scan'208";a="280181768" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 04 Apr 2009 11:46:56 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n34BkuNw013044; Sat, 4 Apr 2009 04:46:56 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n34Bktlc011336; Sat, 4 Apr 2009 11:46:55 GMT From: Cullen Jennings To: Magnus Westerlund In-Reply-To: <49D60A18.1090400@ericsson.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <49D60A18.1090400@ericsson.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 4 Apr 2009 05:46:54 -0600 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=356; t=1238845616; x=1239709616; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20erratas=20on=20RFC=205117=20(RTP=20Topo logies) |Sender:=20; bh=Nix0Q4Xn0U2movS3P8Gk+bDgbR7OYnZITa3963vp5pQ=; b=pKgommK0O3eh5IERalbr5RhRX4Oy8pBHd3yC7neOs1wE28taubnrpihXrr iiC0zJm6xyh+vM3IkkSYJZiTcv4jbu9uwvn16NhCR3RiF2uKe2EolkhB/hke RkrBKco4TX; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: IETF AVT WG Subject: Re: [AVT] erratas on RFC 5117 (RTP Topologies) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 11:45:53 -0000 On Apr 3, 2009, at 7:07 AM, Magnus Westerlund wrote: > Hi, > > I am looking on the filed Erratas for the RTP topologies (RFC 5117). > > I think all fall into the category of "Hold for document update". I > would recommend that Cullen verify them into this state. > > Cheers > > Magnus Seemed clear for these so I did as Magnus suggested. From ron.even.tlv@gmail.com Mon Apr 6 10:10:21 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C05E228C22D for ; Mon, 6 Apr 2009 10:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUzLXLfEcJat for ; Mon, 6 Apr 2009 10:10:17 -0700 (PDT) Received: from mail-bw0-f169.google.com (mail-bw0-f169.google.com [209.85.218.169]) by core3.amsl.com (Postfix) with ESMTP id 5ECB928C20E for ; Mon, 6 Apr 2009 10:10:16 -0700 (PDT) Received: by bwz17 with SMTP id 17so1969043bwz.37 for ; Mon, 06 Apr 2009 10:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=HBnxvfN71uqtOC3LuMnRvezPzyRyXoH+wvDezmPjO28=; b=cJ6Qlz64L6mtM9oghLAIbiAamk4Lr+gmKyT4gs22AV6th94JvpYKEqotIcWUsJaUNc xfbr/7zzNyzFiKOPpaeEQPJuqq2A40aw199s6BX+j8/P0KTEUC5i8yuVlI5wAHHsLG8w ZBcgnFTeeqqjdemFNhRZ3pHE3cOuk69T3KVeY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; b=GI5UMNooEadrJqcaK+0tWjznPD82WC6WQFtTt/0doDjx446QbjIu1N3Pz5RMQVu3Jm 56kNTLFBEVd59/xNeo7aFIGs0RIfECask1X6PyEZDFNYMHkN4durEc9rfTVLVdSZQdzN i8Ibs+Z1Yt6xyDFiljrrHcDEFw5jtlP7I6ZNc= Received: by 10.204.31.196 with SMTP id z4mr1845365bkc.73.1239037881290; Mon, 06 Apr 2009 10:11:21 -0700 (PDT) Received: from windows8d787f9 (bzq-79-176-115-125.red.bezeqint.net [79.176.115.125]) by mx.google.com with ESMTPS id y15sm1722674fkd.12.2009.04.06.10.11.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 06 Apr 2009 10:11:20 -0700 (PDT) From: "Roni Even" To: Date: Mon, 6 Apr 2009 20:09:49 +0300 Message-ID: <49da37b8.0f975e0a.45f6.4199@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01C9B6F3.AAF79430" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm22n45s6DFO0XpSM2zvl8AyXjFIA== Content-Language: en-us Subject: [AVT] comments on draft-schmidt-avt-rfc3016bis-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 17:10:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0031_01C9B6F3.AAF79430 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I reviewed the draft and have some comments. It looks to me that the draft has all the text from RFC 3016 and I suggest that it would obsolete RFC 3016 and not update it. Others 1. We are using media subtype for RTP payload instead of MIME type, this need to be updated in the whole draft 2. You are using the term VOP starting in section 1.1, please define what is this abbreviation of. 3. In section 1.2 you discuss scalable stream. In the second line of the 4 paragraph you are referring to RTP packets but from the rest of the paragraph it looks like you meant RTP streams (with different PT) 4. For the scalable audio and video you are using the PT values to define the dependency. I assume that you need it for backward compatibility but why not also suggest using the SDP decoding dependency draft. 5. In section 3 you mention RFC 4629 and 4628. Please add references. 6. The media subtype registration should be updated to be inline with RFC485 7. For mpeg4 -video you mention in Applications which use this media type IM and email yet there is no file format specified or referenced here. 8. To the SDP usage add offer/answer consideration including also the negotiation for profile-level, what is considered an interoperability mode, do both sides need to have the same profile and level or the offer is rejected and so on. 9. The security section can you the security consideration from draft-ieft-avt-srtp-not-mandatory 10. The IANA consideration should say that it updates the media type registration from 3016 and point at the media subtype definition sections in the current draft. Regards Roni Even ------=_NextPart_000_0031_01C9B6F3.AAF79430 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I reviewed the draft and have some = comments.

 

It looks to me that the draft has all the text from = RFC 3016 and I suggest that it would obsolete RFC 3016 and not update = it.

 

Others

 

1.       We are using media = subtype for RTP payload instead of MIME type, this need to be updated in the whole = draft

2.       You are using the term = VOP starting in section 1.1, please define what is this abbreviation = of.

3.       In section 1.2 you = discuss scalable stream. In the second line of the 4 paragraph you are referring to RTP = packets but from the rest of the paragraph it looks like you meant RTP streams = (with different PT)

4.       For the scalable audio = and video you are using the PT values to define the dependency. I assume that you = need it for backward compatibility but why not also suggest using the SDP = decoding dependency draft.

5.       In section 3 you mention = RFC 4629 and 4628. Please add references.

6.       The media subtype = registration should be updated to be inline with RFC485

7.       For mpeg4 –video = you mention in Applications which use this media type IM and email yet there is no = file format specified or referenced here.

8.       To the SDP usage add = offer/answer consideration including also the negotiation for profile-level, what is considered an interoperability mode,  do both sides need to have = the same profile and level or the offer is rejected and so on.

9.       The security section can = you the security consideration from = draft-ieft-avt-srtp-not-mandatory

10.   The IANA consideration = should say that it updates the media type registration from 3016 and point at the = media subtype definition sections in the current draft.

 

 

Regards

Roni Even

 

------=_NextPart_000_0031_01C9B6F3.AAF79430-- From ekr@networkresonance.com Mon Apr 6 16:37:10 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55E103A6CBD for ; Mon, 6 Apr 2009 16:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.479 X-Spam-Level: X-Spam-Status: No, score=-1.479 tagged_above=-999 required=5 tests=[AWL=-0.984, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HDv3KpAIiAE for ; Mon, 6 Apr 2009 16:37:09 -0700 (PDT) Received: from kilo.networkresonance.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 6ACAC3A6C88 for ; Mon, 6 Apr 2009 16:37:09 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 3B4B81244B7; Mon, 6 Apr 2009 16:39:06 -0700 (PDT) Date: Mon, 06 Apr 2009 16:39:05 -0700 From: Eric Rescorla To: avt@ietf.org, draft-mattsson-srtp-store-and-forward@tools.ietf.org User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090406233906.3B4B81244B7@kilo.networkresonance.com> Subject: [AVT] Review of store and forward drafts X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 23:37:10 -0000 $Id: draft-mattson-srtp-store-and-forward-02-rev.txt,v 1.1 2009/04/06 22:43:10 ekr Exp $ Also draft-naslund-srtp-saf-00.txt These documents describe a set of use cases and a protocol for a modification to SRTP to do "store and forward". I have several concerns: - Are these use cases actually compelling? - Do these use cases all need the same set of mechanisms? - How is key management really going to be done for these. - How realistic is the threat model? The use cases here fall into two major categories: - media distribution - recording media on answering machines/voicemail servers - untrusted conference bridges It's not clear to me that these are really that similar problems. In particular, the media distribution cases mostly seem to me to be cases in which what's needed is to temporally decouple message integrity from confidentiality so that you can avoid storing bogus data which is only determined to be bogus when you go to replay it. This is particularly noticeable in the "Recording Encrypted Media at Home" example (S 4.2.4) where there's no real need to treat the DVR as untrusted--you just want to be sure that the media is correct at the time you record it even though you don't have a license for the media yet. I agree that the voice mail case requires something more substantial, however it's also much less compelling. First, it's not clear to me that people really don't trust their voice mail servers. Second, voice mail servers do a fair amount of mixing (for instance, prompts) with the media. As I said on the call, I'm skeptical that existing phones will handle this well. Third, it requires a key management scheme we don't have: in order for this use case to work, you need a way for the sender of the voice mail to do offline key exchange with the ultimate receiver. If this worked well, we wouldn't have had any need for RTPSEC to solve the special case of online key exchange! The untrusted conference bridge case seems even less compelling, because real bridges do a lot of fancy audio stuff. Another concern I have is that the threat model seems fairly unrealistic. Why is it safe to assume that the middlebox which is not allowed to see the media is nevertheless allowed to retime it and mount generic cut-and-paste attacks? I appreciate you have a countermeasure for that, but that countermeasure relies on a separate integrity check and basically precludes much of the point of this work, it seems to me. At the end of the day, I wonder whether there is a simpler scheme in which we simply partition the authentication and encryption transforms so that disconnected keys can be used for each. ISTM that this would allow the most interesting set of use cases (those concerned with media distribution) with significantly less effort. Yes, I realize that it wouldn't provide quite the same level of integrity protection, but it's not clear that that's really necessary. To the extent to which you *do* want to double-wrap the data, it's not clear to me that doing it again in SRTP is really that useful: a lot of the point of SRTP is that it leverages existing headers for maximum data compactness. Once you're doublewrapping and adding new headers like e2e PUV, maybe you could just get away with an outer DTLS wrapper without any SRTP extensions From ekr@networkresonance.com Mon Apr 6 16:37:47 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0B3B3A6CBD for ; Mon, 6 Apr 2009 16:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.479 X-Spam-Level: X-Spam-Status: No, score=-1.479 tagged_above=-999 required=5 tests=[AWL=-0.984, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNXjQvyVcxsK for ; Mon, 6 Apr 2009 16:37:47 -0700 (PDT) Received: from kilo.networkresonance.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 8FB7B3A6C88 for ; Mon, 6 Apr 2009 16:37:47 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id D66671244BB; Mon, 6 Apr 2009 16:39:44 -0700 (PDT) Date: Mon, 06 Apr 2009 16:39:44 -0700 From: Eric Rescorla To: avt@ietf.org, draft-mattsson-srtp-store-and-forward@tools.ietf.org User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090406233944.D66671244BB@kilo.networkresonance.com> Subject: [AVT] Review of store and forward drafts X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 23:37:47 -0000 $Id: draft-mattson-srtp-store-and-forward-02-rev.txt,v 1.1 2009/04/06 22:43:10 ekr Exp $ Also draft-naslund-srtp-saf-00.txt These documents describe a set of use cases and a protocol for a modification to SRTP to do "store and forward". I have several concerns: - Are these use cases actually compelling? - Do these use cases all need the same set of mechanisms? - How is key management really going to be done for these. - How realistic is the threat model? The use cases here fall into two major categories: - media distribution - recording media on answering machines/voicemail servers - untrusted conference bridges It's not clear to me that these are really that similar problems. In particular, the media distribution cases mostly seem to me to be cases in which what's needed is to temporally decouple message integrity from confidentiality so that you can avoid storing bogus data which is only determined to be bogus when you go to replay it. This is particularly noticeable in the "Recording Encrypted Media at Home" example (S 4.2.4) where there's no real need to treat the DVR as untrusted--you just want to be sure that the media is correct at the time you record it even though you don't have a license for the media yet. I agree that the voice mail case requires something more substantial, however it's also much less compelling. First, it's not clear to me that people really don't trust their voice mail servers. Second, voice mail servers do a fair amount of mixing (for instance, prompts) with the media. As I said on the call, I'm skeptical that existing phones will handle this well. Third, it requires a key management scheme we don't have: in order for this use case to work, you need a way for the sender of the voice mail to do offline key exchange with the ultimate receiver. If this worked well, we wouldn't have had any need for RTPSEC to solve the special case of online key exchange! The untrusted conference bridge case seems even less compelling, because real bridges do a lot of fancy audio stuff. Another concern I have is that the threat model seems fairly unrealistic. Why is it safe to assume that the middlebox which is not allowed to see the media is nevertheless allowed to retime it and mount generic cut-and-paste attacks? I appreciate you have a countermeasure for that, but that countermeasure relies on a separate integrity check and basically precludes much of the point of this work, it seems to me. At the end of the day, I wonder whether there is a simpler scheme in which we simply partition the authentication and encryption transforms so that disconnected keys can be used for each. ISTM that this would allow the most interesting set of use cases (those concerned with media distribution) with significantly less effort. Yes, I realize that it wouldn't provide quite the same level of integrity protection, but it's not clear that that's really necessary. To the extent to which you *do* want to double-wrap the data, it's not clear to me that doing it again in SRTP is really that useful: a lot of the point of SRTP is that it leverages existing headers for maximum data compactness. Once you're doublewrapping and adding new headers like e2e PUV, maybe you could just get away with an outer DTLS wrapper without any SRTP extensions From ekr@networkresonance.com Mon Apr 6 16:48:04 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B4523A6880 for ; Mon, 6 Apr 2009 16:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.461 X-Spam-Level: X-Spam-Status: No, score=-1.461 tagged_above=-999 required=5 tests=[AWL=-0.966, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tK7x3V+V57BO for ; Mon, 6 Apr 2009 16:47:59 -0700 (PDT) Received: from kilo.networkresonance.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 62E3F3A6452 for ; Mon, 6 Apr 2009 16:47:59 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 9616E1244C6; Mon, 6 Apr 2009 16:49:56 -0700 (PDT) Date: Mon, 06 Apr 2009 16:49:56 -0700 From: Eric Rescorla To: Rolf Blom In-Reply-To: <49D30ECC.8090604@ericsson.com> References: <49D0E097.3000902@ericsson.com> <02f801c9b179$5aed9a90$c4f0200a@cisco.com> <49D30ECC.8090604@ericsson.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090406234956.9616E1244C6@kilo.networkresonance.com> Cc: AVT Subject: Re: [AVT] SRTP store-and-forward X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 23:48:04 -0000 > When you refer to MIKEY-RSA having some mechanism to acquire such > information (shared key / certificate) I believe you refer to > MIKEY-RSA-R. In MIKEY-RSA-R the initiator attaches his certificate in > the first message and the responder uses it to return the key to be > used. This works well when there is an on-line connection between the > two but  wouldn't work for SRTP  Store-and-Forward applications. Here > we must rely on either predistributed keys or certificates or that keys > or certificates can be acquired from an online third party. As I said > before this situation is exactly as for secure email. And secure email > is used! I would say extraordinarily rarely. Indeed, this is precisely one of the challenges that led to RTPSEC. -Ekr From rolf.j.blom@ericsson.com Tue Apr 7 06:47:08 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0C233A69A3 for ; Tue, 7 Apr 2009 06:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.104 X-Spam-Level: X-Spam-Status: No, score=-4.104 tagged_above=-999 required=5 tests=[AWL=-1.173, BAYES_20=-0.74, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33SXPGCVVKSr for ; Tue, 7 Apr 2009 06:47:08 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 5ED443A69CD for ; Tue, 7 Apr 2009 06:46:43 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6230020BC6; Tue, 7 Apr 2009 15:47:48 +0200 (CEST) X-AuditID: c1b4fb3c-aaee7bb000003b08-0e-49db5984f5c0 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3BEC320C01; Tue, 7 Apr 2009 15:47:48 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Apr 2009 15:47:48 +0200 Received: from [127.0.0.1] ([147.214.131.229]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Apr 2009 15:47:48 +0200 Message-ID: <49DB5982.1040509@ericsson.com> Date: Tue, 07 Apr 2009 15:47:46 +0200 From: Rolf Blom User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Eric Rescorla References: <49D0E097.3000902@ericsson.com> <02f801c9b179$5aed9a90$c4f0200a@cisco.com> <49D30ECC.8090604@ericsson.com> <20090406234956.9616E1244C6@kilo.networkresonance.com> In-Reply-To: <20090406234956.9616E1244C6@kilo.networkresonance.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Apr 2009 13:47:48.0271 (UTC) FILETIME=[6FE7F3F0:01C9B787] X-Brightmail-Tracker: AAAAAA== Cc: AVT Subject: Re: [AVT] SRTP store-and-forward X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 13:47:08 -0000 Hi Eric,

My experience is that secure email becomes of more and more interest for enterprises and government authorities. Such organizations already now invest in the needed infrastructure to enable handling of user certificates and other types of user credentials for secure access and communication. I also expect that in the future, secure email will be used more and more by the general public for privacy reasons. Look e.g. at the success for PGP.

/Rolf



Eric Rescorla wrote: 
When you refer to MIKEY-RSA having some mechanism to acquire such
information (shared key / certificate) I believe you refer to
MIKEY-RSA-R. In MIKEY-RSA-R the initiator attaches his certificate in
the first message and the responder uses it to return the key to be
used. This works well when there is an on-line connection between the
two but&nbsp; wouldn't work for SRTP&nbsp; Store-and-Forward applications. Here
we must rely on either predistributed keys or certificates or that keys
or certificates can be acquired from an online third party. As I said
before this situation is exactly as for secure email. And secure email
is used!
    

I would say extraordinarily rarely. Indeed, this is precisely one
of the challenges that led to RTPSEC.

-Ekr


  

-- 
Rolf Blom, Ph.D. Expert, Mobile Communications Security, Ericsson Research
Postal address: Ericsson AB, SE-164 80 STOCKHOLM, Sweden
Tel: +46 10 713 17 07,  GSM: +46 70 757 2092,  Fax: +46 8 757 01 35


This communication is confidential and intended solely for the
addressee(s). Any unauthorized review, use, disclosure or distribution
is prohibited. If you believe this message has been sent to you 
in error, please notify the sender by replying to this transmission 
and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to datacorruption, 
interruption, unauthorized amendment, tampering and viruses, and 
we only send and receive e-mails on the basis that we are not 
liable for any such corruption, interception, amendment, tampering
or viruses or any consequences thereof.
From ekr@networkresonance.com Tue Apr 7 08:46:47 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5B343A6DB4 for ; Tue, 7 Apr 2009 08:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.427 X-Spam-Level: X-Spam-Status: No, score=-1.427 tagged_above=-999 required=5 tests=[AWL=-0.932, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ahuo0aMQY-ED for ; Tue, 7 Apr 2009 08:46:47 -0700 (PDT) Received: from kilo.networkresonance.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id C43A23A6D64 for ; Tue, 7 Apr 2009 08:46:35 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 9F15E124C27; Tue, 7 Apr 2009 08:48:38 -0700 (PDT) Date: Tue, 07 Apr 2009 08:48:38 -0700 From: Eric Rescorla To: Rolf Blom In-Reply-To: <49DB5982.1040509@ericsson.com> References: <49D0E097.3000902@ericsson.com> <02f801c9b179$5aed9a90$c4f0200a@cisco.com> <49D30ECC.8090604@ericsson.com> <20090406234956.9616E1244C6@kilo.networkresonance.com> <49DB5982.1040509@ericsson.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090407154838.9F15E124C27@kilo.networkresonance.com> Cc: AVT Subject: Re: [AVT] SRTP store-and-forward X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 15:46:47 -0000 At Tue, 07 Apr 2009 15:47:46 +0200, Rolf Blom wrote: > My experience is that secure email becomes of more and more interest > for enterprises and government authorities. Such organizations already > now invest in the needed infrastructure to enable handling of user > certificates and other types of user credentials for secure access and > communication. My experience is the contrary. Some organizations try and they're almost universally miserable. > I also expect that in the future, secure email will be > used more and more by the general public for privacy reasons. Look e.g. > at the success for PGP.
If that's a success, I'd hate to see failure. Compare the deployment of TLS to the deployment of PGP. -Ekr From ron.even.tlv@gmail.com Wed Apr 8 07:00:13 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 566413A69C4 for ; Wed, 8 Apr 2009 07:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmFiXTVMRC4r for ; Wed, 8 Apr 2009 07:00:12 -0700 (PDT) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.190]) by core3.amsl.com (Postfix) with ESMTP id 133913A6952 for ; Wed, 8 Apr 2009 07:00:11 -0700 (PDT) Received: by mu-out-0910.google.com with SMTP id w9so56151mue.9 for ; Wed, 08 Apr 2009 07:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=SW5/ovzcsxMBrA6fTMBTaoWBc5D6tJUghVH0XPdX9q4=; b=c3GlSMFjkFht021CsQCFRA2+XYu5WyJ5XxF7sDnW5iT1YDJbRCqk/UuP0JBABM1icz Ff7zZY7rFAmc7C062fGjLN6lyBkddqveiOnsVHMOX+XSCQjqxE/da/Joa3vFcvjj6nYh Lbkgdg6PHAfr84KMxzrEEevylizEfQBnk+Vow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; b=OWg28pVJNaPQce1kLGSUswbkx46AQldjrB6tm3IX6eea0Kbxx/japVqveYtKCAOSUE 7khl9TM1IGmOVHDLIdZBL+C/7T18VCkHaNlRwlDewTjaUQbOyBEGit4KMZ5b7DOyn3OW vPtbnp3NpCYlbLd8NeN6uVfIRdsOCaJa6DeGw= Received: by 10.103.223.2 with SMTP id a2mr570737mur.88.1239199278505; Wed, 08 Apr 2009 07:01:18 -0700 (PDT) Received: from windows8d787f9 (bzq-79-176-30-237.red.bezeqint.net [79.176.30.237]) by mx.google.com with ESMTPS id i7sm12575187mue.14.2009.04.08.06.59.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 08 Apr 2009 07:01:18 -0700 (PDT) From: "Roni Even" To: "'Colin Perkins'" , References: In-Reply-To: Date: Wed, 8 Apr 2009 16:56:55 +0300 Message-ID: <49dcae2e.07a0660a.1700.0daf@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C5_01C9B86B.6D5B9620" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acmwqu/4KtCBMjDFQn+pdbiPbW1QKAHpn7kQ Content-Language: en-us Cc: 'Tom Taylor' , avt@ietf.org Subject: Re: [AVT] making draft-perkins-avt-rapid-rtp-sync-03 a WG item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 14:00:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C5_01C9B86B.6D5B9620 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, There was support for having this work as a working group item, so AVT will start working on this topic. Colin or Thomas please submit the draft as an AVT draft. Roni Even From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Sunday, March 29, 2009 11:14 PM To: 'avt@ietf.org' Cc: 'Tom Taylor' Subject: making draft-perkins-avt-rapid-rtp-sync-03 a WG item Hi, I would like to ask if there is interest in making Rapid Synchronisation of RTP Flows, draft-perkins-avt-rapid-rtp-sync-03.txt a working group meeting. The draft was presented in San Francisco and is offering a solutions to synchronize multiple RTP streams. It is a suggested solution to DVB TM-AVC who would like to have by June. This work is not in the AVT charter and the chairs intend to submit an updated charter. Please send your respond to the mailing list till April 8th . If there will be no objections we will accept this topic and have the above draft as the initial document Roni Even ------=_NextPart_000_00C5_01C9B86B.6D5B9620 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

There was support for = having this work as a working group item, so AVT will start working on this = topic.

Colin or Thomas = please submit the draft as an AVT draft.

Roni = Even

 

From:= Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: Sunday, March 29, 2009 11:14 PM
To: 'avt@ietf.org'
Cc: 'Tom Taylor'
Subject: making draft-perkins-avt-rapid-rtp-sync-03 a WG = item

 

Hi,

I would like to =
ask if there is interest in making Rapid Synchronisation of RTP Flows, =
draft-perkins-avt-rapid-rtp-sync-03.txt  a working group meeting. =
The draft was presented in San Francisco and is offering a solutions to =
synchronize multiple RTP streams. It is a suggested solution to DVB =
TM-AVC who would like to have by June.
This work is not in the AVT =
charter and the chairs intend to submit an updated =
charter.
Please send your respond to =
the mailing list till April 8th . If there will be no =
objections we will accept this topic and have the above draft as the =
initial document
 
Roni =
Even
 =
------=_NextPart_000_00C5_01C9B86B.6D5B9620-- From web-usrn@ISI.EDU Tue Apr 7 11:00:28 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FCB33A69A3 for ; Tue, 7 Apr 2009 11:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.23 X-Spam-Level: X-Spam-Status: No, score=-17.23 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeLM2oiDpa38 for ; Tue, 7 Apr 2009 11:00:27 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 9F45A3A68EB for ; Tue, 7 Apr 2009 11:00:27 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n37I0Gdt011612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Apr 2009 11:00:17 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n37I0DCK011592; Tue, 7 Apr 2009 11:00:13 -0700 (PDT) Date: Tue, 7 Apr 2009 11:00:13 -0700 (PDT) Message-Id: <200904071800.n37I0DCK011592@boreas.isi.edu> To: almeroth@cs.ucsb.edu, caceres@watson.ibm.com, alan@telchemy.com, robert.cole@jhuapl.edu, duffield@research.att.com, timur.friedman@lip6.fr, khedayat@brixnet.com, ksarac@utdallas.edu, magnus.westerlund@ericsson.com, rjsparks@nostrum.com, jon.peterson@neustar.biz, fluffy@cisco.com, ron.even.tlv@gmail.com, tom.taylor@rogers.com From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu X-Mailman-Approved-At: Wed, 08 Apr 2009 08:26:40 -0700 Cc: timur.friedman@lip6.fr, avt@ietf.org, rfc-editor@rfc-editor.org Subject: [AVT] [Technical Errata Reported] RFC3611 (1759) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 18:00:28 -0000 The following errata report has been submitted for RFC3611, "RTP Control Protocol Extended Reports (RTCP XR)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3611&eid=1759 -------------------------------------- Type: Technical Reported by: Timur Friedman Section: 6.3 Original Text ------------- "recv-rtt" Corrected Text -------------- "rcvr-rtt" Notes ----- Sec. 6.3 describes the SDP attribute in Sec. 5.1, but erroneously calls it "recv-rtt" whereas it is in fact "rcvr-rtt". The IANA, following Sec. 6.3, had recorded "recv-rtt" but has corrected this and now records "rcvr-rtt". I am one of the editors of this RFC, and I apologize for not having caught this error before publication. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3611 (draft-ietf-avt-rtcp-report-extns-06) -------------------------------------- Title : RTP Control Protocol Extended Reports (RTCP XR) Publication Date : November 2003 Author(s) : T. Friedman, Ed., R. Caceres, Ed., A. Clark, Ed. Category : PROPOSED STANDARD Source : Audio/Video Transport Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From ingemar.s.johansson@ericsson.com Wed Apr 8 13:49:54 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A77513A6E92 for ; Wed, 8 Apr 2009 13:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.986 X-Spam-Level: X-Spam-Status: No, score=-5.986 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svhGzCKBVHt7 for ; Wed, 8 Apr 2009 13:49:54 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id CDE893A69EB for ; Wed, 8 Apr 2009 13:49:53 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 798FB20A81 for ; Wed, 8 Apr 2009 22:50:37 +0200 (CEST) X-AuditID: c1b4fb3c-aa6e6bb000003b08-e4-49dd0e1d0e7f Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5E61F20240 for ; Wed, 8 Apr 2009 22:50:37 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Apr 2009 22:50:36 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Apr 2009 22:50:36 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8CD081DF@esealmw109.eemea.ericsson.se> In-Reply-To: <20090408185305.D7D6D3A6E7D@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multicast-Based Rapid Acquisition of Multicast RTP Sessions Thread-Index: Acm4e2nRHEPRtSc5SXuOSBKQLYj0XgAD0ZHg References: <20090408185305.D7D6D3A6E7D@core3.amsl.com> From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 08 Apr 2009 20:50:36.0723 (UTC) FILETIME=[AB184830:01C9B88B] X-Brightmail-Tracker: AAAAAA== Subject: [AVT] Multicast-Based Rapid Acquisition of Multicast RTP Sessions X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 20:49:54 -0000 Hi A new draft that addresses the work on Rapid Acquisition for Multicast based Streaming has been submitted=20 http://tools.ietf.org/id/draft-johansson-avt-mcast-based-rams-00.txt Comments are welcome=20 Regards Ingemar Johansson =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Abstract: This document proposes an improvement to the unicast based=20 Rapid Acquisition for Multicast based Streaming discussed in=20 [ID-Versteeg]. The outline of the improvement is to gather up Rapid=20 Acquisition requests for many users and transmit them in=20 dedicated multicast streams. With this technique the peak=20 load on the retransmission server and on the outgoing link=20 from the retransmission server can be reduced. For a problem=20 description of the channel change problem in multicast based=20 IPTV the reader is encouraged to read [ID-Versteeg]. [ID-Versteeg] =3D http://tools.ietf.org/id/draft-versteeg-avt-rapid-synchronization-for-rt p-02.txt From root@core3.amsl.com Wed Apr 8 14:15:02 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 158CA28C1E7; Wed, 8 Apr 2009 14:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090408211502.158CA28C1E7@core3.amsl.com> Date: Wed, 8 Apr 2009 14:15:02 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-seed-srtp-10.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 21:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : The SEED Cipher Algorithm and Its Use with the Secure Real-time Transport Protocol (SRTP Author(s) : S. Yoon, H. Park, J. Kim, H. Jeong, Y. Won Filename : draft-ietf-avt-seed-srtp-10.txt Pages : 12 Date : 2009-4-8 This document describes the use of the SEED block cipher algorithm in the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for the Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-seed-srtp-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-seed-srtp-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-4-8140627.I-D@ietf.org> --NextPart-- From csp@csperkins.org Wed Apr 8 14:41:11 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC58F3A6B36 for ; Wed, 8 Apr 2009 14:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHsMUo6EWdxl for ; Wed, 8 Apr 2009 14:41:11 -0700 (PDT) Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by core3.amsl.com (Postfix) with ESMTP id EED0F3A6B2A for ; Wed, 8 Apr 2009 14:41:10 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=mangole.lan) by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1LrfXF-0001NS-j7; Wed, 08 Apr 2009 21:42:18 +0000 Message-Id: From: Colin Perkins To: Roni Even In-Reply-To: <49dcae2e.07a0660a.1700.0daf@mx.google.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 8 Apr 2009 22:42:09 +0100 References: <49dcae2e.07a0660a.1700.0daf@mx.google.com> X-Mailer: Apple Mail (2.930.3) Cc: Thomas.Schierl@hhi.fraunhofer.de, 'Tom Taylor' , avt@ietf.org Subject: Re: [AVT] making draft-perkins-avt-rapid-rtp-sync-03 a WG item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 21:41:11 -0000 On 8 Apr 2009, at 14:56, Roni Even wrote: > There was support for having this work as a working group item, so > AVT will start working on this topic. > Colin or Thomas please submit the draft as an AVT draft. I submitted draft-ietf-avt-rapid-rtp-sync-00.txt - just waiting for WG chair approval. This is identical to draft-perkins-avt-rapid-rtp- sync-03.txt apart from the filename and date. -- Colin Perkins http://csperkins.org/ From root@core3.amsl.com Wed Apr 8 15:00:01 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6DB573A6E87; Wed, 8 Apr 2009 15:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090408220001.6DB573A6E87@core3.amsl.com> Date: Wed, 8 Apr 2009 15:00:01 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rapid-rtp-sync-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 22:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Rapid Synchronisation of RTP Flows Author(s) : C. Perkins, T. Schierl Filename : draft-ietf-avt-rapid-rtp-sync-00.txt Pages : 17 Date : 2009-04-08 This memo outlines how RTP multimedia sessions are synchronised, and discusses how rapidly such synchronisation can occur. We show that most RTP sessions can be synchronised immediately, but that the use of video switching multipoint conference units (MCUs) or large source specific multicast (SSM) groups can greatly increase the initial synchronisation delay. This increase in delay can be unacceptable to some applications that use layered and/or multi-description codecs. This memo updates the RTP Control Protocol (RTCP) timing rules to reduce the initial synchronisation delay for SSM sessions. A new feedback packet is defined for use with the Extended RTP Profile for RTCP-based Feedback (RTP/AVPF), allowing video switching MCUs to rapidly request resynchronisation. Two new RTP header extensions are defined to allow rapid synchronisation of late joiners, and guarantee correct timestamp based decoding order recovery for layered codecs in the presence of clock skew. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rapid-rtp-sync-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-rapid-rtp-sync-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-08145125.I-D@ietf.org> --NextPart-- From john.mattsson@ericsson.com Wed Apr 8 15:39:45 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1C213A6B46 for ; Wed, 8 Apr 2009 15:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nq1413iKqybp for ; Wed, 8 Apr 2009 15:39:44 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id F1CEC3A6B36 for ; Wed, 8 Apr 2009 15:39:43 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4F3182027A; Thu, 9 Apr 2009 00:40:50 +0200 (CEST) X-AuditID: c1b4fb3e-ae023bb0000024d5-4c-49dd27f25fd4 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 25BAA20063; Thu, 9 Apr 2009 00:40:50 +0200 (CEST) Received: from esealmw121.eemea.ericsson.se ([153.88.200.80]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 00:40:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Apr 2009 00:40:49 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Review of store and forward drafts Thread-Index: Acm4mxCHh9lgELLeTruH6M0HNt/Kew== From: "John Mattsson" To: X-OriginalArrivalTime: 08 Apr 2009 22:40:50.0154 (UTC) FILETIME=[1101C4A0:01C9B89B] X-Brightmail-Tracker: AAAAAA== Cc: avt@ietf.org Subject: Re: [AVT] Review of store and forward drafts X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 22:39:45 -0000 Hi Eric, =20 Thanks very much for providing these comments; it is much appreciated to = have this analysis of the problems and solutions in the draft. =20 > These documents describe a set of use cases and a protocol for a=20 > modification to SRTP to do "store and forward". I have several > concerns: =20 > - Are these use cases actually compelling? =20 The use cases are motivated by applications used and needed by the = intended primary users and their major concern is data confidentiality. = Given that, the use cases are real and compelling. In media distribution = use cases, the confidentiality requirement is asymmetric; it (mainly) = comes from the content owner. In the other use cases the requirement is = symmetric and comes from both sender and receiver. Typical users in the = answering machine and conferencing use cases are as stated in the draft = organizations such as public safety and enterprises. Or for that matter = anyone that uses transport protection and wants a similar level of = protection in the store-and-forward case. =20 > - Do these use cases all need the same set of mechanisms? =20 Maybe not, but the draft proposes a common solution. And if all use = cases can be easily solved with a single set of mechanisms, there seems = to be no need for several solutions. =20 > - How is key management really going to be done for these. > - How realistic is the threat model? =20 These questions are answered below. =20 > The use cases here fall into two major categories: =20 > - media distribution > - recording media on answering machines/voicemail servers > - untrusted conference bridges =20 > It's not clear to me that these are really that similar problems. In=20 > particular, the media distribution cases mostly seem to me to be cases > in which what's needed is to temporally decouple message integrity > from confidentiality so that you can avoid storing bogus data which is > only determined to be bogus when you go to replay it. This is=20 > particularly noticeable in the "Recording Encrypted Media at Home" > example (S 4.2.4) where there's no real need to treat the DVR as=20 > untrusted--you just want to be sure that the media is correct at the=20 > time you record it even though you don't have a license for the media > yet. =20 You are right in that the problems are a bit different. In this use case = it might be sufficient to separate the keys. However, the solution then = becomes severely limited in that the media cannot be pre-encrypted and = the stored media cannot be forwarded. To get away from such limitations, = a more important requirement in the media distribution use cases is to = decouple the encryption from the RTP header to make the protection = transport independent (See Section 5 in draft-mattsson). When it comes = to trusting the DVR in the use case you mention we agree that the owner = of the DVR would as you write probably trust it. However, the major = security requirement in all use cases is to protect the confidentiality = of the data and a content owner would have (very) limited trust in an = arbitrary DVR. =20 While we initially say that the trust model does not need to be = symmetric in that both sender and receiver needs to have the same level = of trust in the middlebox, we have probably been sloppy in pointing out = this difference in a few places (like here, for instance). Thanks for = identifying this issue. =20 > I agree that the voice mail case requires something more substantial,=20 > however it's also much less compelling. First, it's not clear to me=20 > that people really don't trust their voice mail servers. Second, voice > mail servers do a fair amount of mixing (for instance, prompts) with=20 > the media. As I said on the call, I'm skeptical that existing phones=20 > will handle this well. Third, it requires a key management scheme we=20 > don't have: in order for this use case to work, you need a way for the > sender of the voice mail to do offline key exchange with the ultimate=20 > receiver. If this worked well, we wouldn't have had any need for=20 > RTPSEC to solve the special case of online key exchange! =20 Well, in the general case with two random peers without any relation, = the key management has no general solution today, and it is probably = such peers that you think of when you write that the use case is not = compelling. The typical users we have in mind, public-safety and = enterprise users, would normally have key management systems already. = Note that the de-coupling of the key management and SRTP SaF was a = deliberate choice to allow use of different existing and/or future key = management solutions. The fact that a general key management scheme does = not exist is to me not an argument to stop looking at the use case, it = is rather an argument to start looking also at the key management = problem. In Appendix B in draft-mattsson we illustrate how the key = management can be achieved with small changes to DTLS-SRTP or MIKEY, but = some work surely needs to be done. Finally, you can of course not mix = encrypted data, but the needed functionality for prompting etc can be = achieved by switching of security contexts within one stream or simply = sending the prompts in a separate stream. =20 > The untrusted conference bridge case seems even less compelling,=20 > because real bridges do a lot of fancy audio stuff. =20 One example where no mixing is done is Push-to-talk, which is a major = use case for the expected users such as public safety and enterprises. = Ordinary conference bridges would need some type of floor control. =20 > Another concern I have is that the threat model seems fairly=20 > unrealistic. Why is it safe to assume that the middlebox which is not=20 > allowed to see the media is nevertheless allowed to retime it and=20 > mount generic cut-and-paste attacks? I appreciate you have a=20 > countermeasure for that, but that countermeasure relies on a separate=20 > integrity check and basically precludes much of the point of this=20 > work, it seems to me. =20 The trust in the middlebox may sometimes be very high (as you yourself = point out above, e.g. the end user likely has strong trust in his own = PVR). In other cases, it may be weak(er). We looked for a single trust = model that is reasonable (neither too strong nor too weak) to apply to = all our use cases. The main concern (from end-user's point of view) in = all our uses cases is the confidentiality of sensitive/valuable data. We = claim that from this (confidentiality) point of view it _is_ safe to use = the proposed solution in the defined trust model. The middlebox is = trusted to deliver media as requested, nothing else, and to this end we = used the well-known "honest-by-curious" model. But this does not imply = that the middlebox is "allowed" to do the copy-paste attacks and similar = things. The deliberately malicious middlebox threat is in fact not = realistic in the intended operational environment. Nevertheless, we = always leave control of data confidentiality to the endpoints. =20 In summary: * In the media distribution use cases, the main concern of the content = creator is probably not what a DVR does with the media as long as it = cannot access cleartext data. In the same case, the owner of the DVR = would trust it. * In the answering machine and conferencing use cases, there is no = realistic case were the owner of the service (e.g. an operator) would = have something to gain by launching such copy-paste attacks in general. = (Note that such attacks would anyhow be much harder to do in a = controlled way, when the data is e2e encrypted.) The privacy of the data = is the fundamental requirement for public safety and enterprise users. * The trust model has been chosen to be simple but at the same time it = also "allows" some attacks which are not realistic (but they are still = detectable). =20 When we update the draft, we will include a section about copy-and-paste = attacks in the security considerations. =20 > At the end of the day, I wonder whether there is a simpler scheme in=20 > which we simply partition the authentication and encryption transforms > so that disconnected keys can be used for each. ISTM that this would=20 > allow the most interesting set of use cases (those concerned with=20 > media distribution) with significantly less effort. Yes, I realize=20 > that it wouldn't provide quite the same level of integrity protection, > but it's not clear that that's really necessary. To the extent to=20 > which you *do* want to double-wrap the data, it's not clear to me that > doing it again in SRTP is really that useful: a lot of the point of=20 > SRTP is that it leverages existing headers for maximum data=20 > compactness. Once you're doublewrapping and adding new headers like=20 > e2e PUV, maybe you could just get away with an outer DTLS wrapper=20 > without any SRTP extensions =20 Key separation is a very nice and simple alternative that would work in = some of the uses cases. Unfortunately, it has several shortcomings. It = does not work well in the media distribution use cases as rewind and = random seek functionality would be impossible. For that functionality to = be possible, the protection has to be transport independent. To solve = this, we introduced the PUV. To identify the SA we needed the CCI, and = to protect several streams with a single SA, we added the SSS. We did = consider alternatives, but the requirements in the identified use cases = cannot be solved with any "simpler" changes to SRTP. =20 /John From rfc-editor@rfc-editor.org Thu Apr 9 14:23:04 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 921213A691A; Thu, 9 Apr 2009 14:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.928 X-Spam-Level: X-Spam-Status: No, score=-16.928 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGYxJX5JH+uj; Thu, 9 Apr 2009 14:23:03 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id C4E903A6843; Thu, 9 Apr 2009 14:23:03 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 7E78827AA52; Thu, 9 Apr 2009 14:22:55 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090409212255.7E78827AA52@bosco.isi.edu> Date: Thu, 9 Apr 2009 14:22:55 -0700 (PDT) Cc: avt@ietf.org, rfc-editor@rfc-editor.org Subject: [AVT] RFC 5506 on Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 21:23:04 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5506 Title: Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences Author: I. Johansson, M. Westerlund Status: Standards Track Date: April 2009 Mailbox: ingemar.s.johansson@ericsson.com, magnus.westerlund@ericsson.com Pages: 17 Characters: 41011 Updates: RFC3550, RFC3711, RFC4585 I-D Tag: draft-ietf-avt-rtcp-non-compound-09.txt URL: http://www.rfc-editor.org/rfc/rfc5506.txt This memo discusses benefits and issues that arise when allowing Real-time Transport Protocol (RTCP) packets to be transmitted with reduced size. The size can be reduced if the rules on how to create compound packets outlined in RFC 3550 are removed or changed. Based on that analysis, this memo defines certain changes to the rules to allow feedback messages to be sent as Reduced-Size RTCP packets under certain conditions when using the RTP/AVPF (Real-time Transport Protocol / Audio-Visual Profile with Feedback) profile (RFC 4585). This document updates RFC 3550, RFC 3711, and RFC 4585. [STANDARDS TRACK] This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From root@core3.amsl.com Sat Apr 11 08:00:02 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F37913A6ADE; Sat, 11 Apr 2009 08:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090411150001.F37913A6ADE@core3.amsl.com> Date: Sat, 11 Apr 2009 08:00:01 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rfc3047-bis-09.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 15:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for ITU-T Recommendation G.722.1 Author(s) : P. Luthi, R. Even Filename : draft-ietf-avt-rfc3047-bis-09.txt Pages : 17 Date : 2009-04-11 International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec. This document describes the payload format for including G.722.1 generated bit streams within an RTP packet. The document also describes the syntax and semantics of the SDP parameters needed to support G.722.1 audio codec. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc3047-bis-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-rfc3047-bis-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-11075922.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Apr 13 14:00:01 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4305D3A6B17; Mon, 13 Apr 2009 14:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090413210001.4305D3A6B17@core3.amsl.com> Date: Mon, 13 Apr 2009 14:00:01 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtp-speex-06.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 21:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for the Speex Codec Author(s) : G. Herlein, et al. Filename : draft-ietf-avt-rtp-speex-06.txt Pages : 23 Date : 2009-04-13 Speex is an open-source voice codec suitable for use in Voice over IP (VoIP) type applications. This document describes the payload format for Speex generated bit streams within an RTP packet. Also included here are the necessary details for the use of Speex with the Session Description Protocol (SDP).Editors Note All references to RFC XXXX are to be replaced by references to the RFC number of this memo, when published. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-speex-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-rtp-speex-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-13134810.I-D@ietf.org> --NextPart-- From ron.even.tlv@gmail.com Tue Apr 14 03:06:44 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E1103A6AF8 for ; Tue, 14 Apr 2009 03:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9joCLZH96p9Y for ; Tue, 14 Apr 2009 03:06:43 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 3B07A3A6840 for ; Tue, 14 Apr 2009 03:06:43 -0700 (PDT) Received: by fxm2 with SMTP id 2so2345633fxm.37 for ; Tue, 14 Apr 2009 03:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:date :message-id:mime-version:content-type:x-mailer:content-language :thread-index; bh=/0miQwbLUjF6TWI+5WpzRXTD7BrQD3fUjzJsn4ALXc0=; b=KexOHvDn6NOes1tQ3/p+FdMxRpgFFjTzhTEZ2nQ1EgF1xQdh/y5r6r5b+zAM+Dt2sW wEfHsPyTnEL7NjTkJop+CMmdiHlHdu6rvxCNs/ECVpPMPDZYY+mmywNxkVxAt49RjAVi P5xqu7p66yqsBPPUkr14mKGzdHWsKtvql5QSs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:content-language:thread-index; b=qawKJXtcBM2clCNx/pRxJ8+CIOCCDJr6/r7V5R29hXJZq9JYesEsXOqvtA69tmZCyX tFzGk0Yjcp/g/xpoDw0mBpZjLY2vAWJGIE652ESBiFHquhEywYqAcCunHteQ4hhCKMcD mWk+8uyZ9cDTcbwS0il+xqsDjhShyZrUDH8HY= Received: by 10.103.134.8 with SMTP id l8mr3860964mun.116.1239703674004; Tue, 14 Apr 2009 03:07:54 -0700 (PDT) Received: from windows8d787f9 (bzq-79-176-110-183.red.bezeqint.net [79.176.110.183]) by mx.google.com with ESMTPS id y37sm12291885mug.53.2009.04.14.03.07.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Apr 2009 03:07:53 -0700 (PDT) From: "Roni Even" To: "'Colin Perkins'" , Date: Tue, 14 Apr 2009 13:06:20 +0300 Message-ID: <49e46079.25e2660a.30b0.ffffb5f3@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0086_01C9BD01.D0454F70" X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-Index: Acm86KhO5PCvxUgOR4G5k0DORs/2HQ== Cc: avt@ietf.org, avt-chairs@tools.ietf.org Subject: [AVT] going forward with draft-ietf-avt-rapid-rtp-sync-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 10:06:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0086_01C9BD01.D0454F70 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi guys, I think Thomas had a request to move this draft forward. I suggest that you do another revision finishing the missing parts like the IANA consideration section. Please use fmt=5 for the message since this is the next available one in the IANA registry and the other work an rapid acquisition will use the following numbers when if and when it becomes a working group document. I noticed that there was a lot of support for this work, so all those who support the work please help by reviewing the work so we can start WGLC ASAP Roni Even ------=_NextPart_000_0086_01C9BD01.D0454F70 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi guys,

I think Thomas had a request to move this draft = forward.

I suggest that you do another revision finishing = the missing parts like the IANA consideration section.

Please use fmt=3D5 for the message since this is = the next available one in the IANA registry and the other work an rapid = acquisition will use the following numbers when if and when it becomes a working group = document.

 

I noticed that there was a lot of support for this = work, so all those who support the work please help by reviewing the work so we = can start WGLC ASAP

 

Roni Even

 

 

 

------=_NextPart_000_0086_01C9BD01.D0454F70-- From ron.even.tlv@gmail.com Tue Apr 14 03:09:43 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 498BC3A677C for ; Tue, 14 Apr 2009 03:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WFgZeZ+RO7P for ; Tue, 14 Apr 2009 03:09:42 -0700 (PDT) Received: from mail-bw0-f169.google.com (mail-bw0-f169.google.com [209.85.218.169]) by core3.amsl.com (Postfix) with ESMTP id 1D2073A6893 for ; Tue, 14 Apr 2009 03:09:41 -0700 (PDT) Received: by bwz17 with SMTP id 17so2350662bwz.37 for ; Tue, 14 Apr 2009 03:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:date :message-id:mime-version:content-type:x-mailer:content-language :thread-index; bh=PZctdEUPFguuRYPXB1EoDlK+bExuaA3PTRK9FDo/5C0=; b=dQG++bpl17hlLZV17hK6l4VyIMUZzzk7ABVZY05mW5u29SRnlTq+EbtU9M/Wct0Box 0p1l7Z3h3e9h1Gbq2htYYyHt2l+xXag3MsOHLoiDW4t5CxC55sMI3Byls6xhsO8UzVEH O/ZzAXAhiOo7QeotG+a0FPwtVCS7Nk/hWFtis= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:content-language:thread-index; b=ZA06eomhOw6YFAZC1oma00HP+M6BMa5dXuaYz7CG+rbtpZwhofufTwQrZzAhoOqwN6 /m0wtFuM7zOTamajrjFpeLYQhEV6Vqkjv59p3YgRcNNoWUE40SsIXud4pTPuU9KgcbzA HtcL0wc1JgFo8l+ta1YJRanEDgib2dqxEI9n0= Received: by 10.103.248.17 with SMTP id a17mr3862186mus.97.1239703852530; Tue, 14 Apr 2009 03:10:52 -0700 (PDT) Received: from windows8d787f9 (bzq-79-176-110-183.red.bezeqint.net [79.176.110.183]) by mx.google.com with ESMTPS id s11sm12365564mue.47.2009.04.14.03.10.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Apr 2009 03:10:51 -0700 (PDT) From: "Roni Even" To: "'Zeev Vax'" , "'Ali C. Begen \(abegen\)'" , "'Bill Ver Steeg \(versteb\)'" , "'Peilin YANG'" Date: Tue, 14 Apr 2009 13:09:20 +0300 Message-ID: <49e4612b.0baa660a.6a22.fffff47f@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008B_01C9BD02.3A737840" X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-Index: Acm86RQAR4ChqXKlR0S5th9mdckQzA== Cc: avt@ietf.org, 'Tom Taylor' Subject: [AVT] FMT numbers in your draft X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 10:09:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_008B_01C9BD02.3A737840 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi guys, Since we have the RTP rapid synchronization as a WG item I suggest they use the fmt=5 and that for new RTPFB that will be specified in any new work will use the following numbers when it is a WG item Regards Roni Even AVT co-chair ------=_NextPart_000_008B_01C9BD02.3A737840 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi guys,

Since we have the RTP rapid synchronization as a WG = item I suggest they use the fmt=3D5 and that for new RTPFB that will be = specified in any new work will use the following numbers when it is a WG = item

 

Regards

Roni Even

AVT co-chair

------=_NextPart_000_008B_01C9BD02.3A737840-- From abegen@cisco.com Tue Apr 14 05:56:58 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9367B3A6DFC for ; Tue, 14 Apr 2009 05:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.453 X-Spam-Level: X-Spam-Status: No, score=-6.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yc+2lxYNHIMM for ; Tue, 14 Apr 2009 05:56:57 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id A0F583A67F9 for ; Tue, 14 Apr 2009 05:56:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,185,1238976000"; d="scan'208";a="154417264" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 14 Apr 2009 12:58:09 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3ECw9qS007611; Tue, 14 Apr 2009 05:58:09 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3ECw9VI003299; Tue, 14 Apr 2009 12:58:09 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Apr 2009 05:58:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Apr 2009 05:58:06 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540913E023@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49e4612b.0baa660a.6a22.fffff47f@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FMT numbers in your draft Thread-Index: Acm86RQAR4ChqXKlR0S5th9mdckQzAAF0IxQ References: <49e4612b.0baa660a.6a22.fffff47f@mx.google.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , "Zeev Vax" , "Bill Ver Steeg (versteb)" , "Peilin YANG" X-OriginalArrivalTime: 14 Apr 2009 12:58:09.0137 (UTC) FILETIME=[A9186E10:01C9BD00] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=926; t=1239713889; x=1240577889; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20FMT=20numbers=20in=20your=20draft |Sender:=20; bh=Wf2ZjI4gNhd5K0M+DJLC0fb5FjOn9n6dO+0vnZB/2JA=; b=DT2nW25C3YJfzdrqPfVNInDMDkO098Afq8WTS3BOw/2aRWjQBxQNpHpjNU ETYIzZj8l/Dj20CHftSb9HH4iBF2/aDcBVCkR2XM2sRTQJuGMC43dFJPzdyM /uSfyvkfWk; Authentication-Results: sj-dkim-3; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: avt@ietf.org, Tom Taylor Subject: Re: [AVT] FMT numbers in your draft X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 12:56:58 -0000 Sure, we will make the necessary changes in the revision. We are also = working on a format that will need only one FMT number for the protocol, = and then we will use a field something like "sub fmt" to further specify = which specific message we are using. Thanks for the heads-up. -acbegen=20 > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > Sent: Tuesday, April 14, 2009 3:09 AM > To: 'Zeev Vax'; Ali C. Begen (abegen); Bill Ver Steeg=20 > (versteb); 'Peilin YANG' > Cc: avt@ietf.org; 'Tom Taylor' > Subject: FMT numbers in your draft >=20 > Hi guys, >=20 > Since we have the RTP rapid synchronization as a WG item I=20 > suggest they use the fmt=3D5 and that for new RTPFB that will=20 > be specified in any new work will use the following numbers=20 > when it is a WG item >=20 > =20 >=20 > Regards >=20 > Roni Even >=20 > AVT co-chair=20 >=20 >=20 From Thomas.Schierl@hhi.fraunhofer.de Tue Apr 14 06:20:00 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0D893A6E0F for ; Tue, 14 Apr 2009 06:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=-1.755, BAYES_50=0.001, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKvQvvlCAnJ4 for ; Tue, 14 Apr 2009 06:19:59 -0700 (PDT) Received: from mail.hhi.fraunhofer.de (mail.HHI.FRAUNHOFER.DE [193.174.67.45]) by core3.amsl.com (Postfix) with ESMTP id 9248E3A6DB7 for ; Tue, 14 Apr 2009 06:19:59 -0700 (PDT) Received: by mail.hhi.fraunhofer.de (Postfix, from userid 65534) id 93AF31D88FDF; Tue, 14 Apr 2009 15:20:38 +0200 (CEST) Received: from imsva.hhi.de (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 736FF150036; Tue, 14 Apr 2009 15:20:38 +0200 (CEST) Received: from [172.19.40.6] (ipamfw.iphhi.de [212.202.149.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.hhi.fraunhofer.de (Postfix) with ESMTP id 190E71D88FB1; Tue, 14 Apr 2009 15:20:38 +0200 (CEST) Message-ID: <49E48DC3.6070609@hhi.fraunhofer.de> Date: Tue, 14 Apr 2009 15:21:07 +0200 From: Thomas.Schierl@hhi.fraunhofer.de Organization: Fraunhofer HHI User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Roni Even References: <49e46079.25e2660a.30b0.ffffb5f3@mx.google.com> In-Reply-To: <49e46079.25e2660a.30b0.ffffb5f3@mx.google.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-alterMIME: Yes Cc: 'Colin Perkins' , avt-chairs@tools.ietf.org, avt@ietf.org Subject: Re: [AVT] going forward with draft-ietf-avt-rapid-rtp-sync-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 13:20:01 -0000 Hi Roni, all,

We will do so soon. I hope we can submit a new version of the draft early next week.

Thanks,
Thomas
______________________________________________
Thomas Schierl, Dipl.-Ing.
Fraunhofer HHI
Senior Research Engineer
Image Processing Dept. / Multimedia Transport
Einsteinufer 37, 10587 Berlin, Germany
PHONE: +49 30 31002 227 , FAX: +49 30 392 7200
WEB: http://ip.hhi.de , SKYPE: thomas.schierl
EMAIL: thomas.schierl@hhi.fraunhofer.de


Roni Even wrote:

Hi guys,

I think Thomas had a request to move this draft forward.

I suggest that you do another revision finishing the missing parts like the IANA consideration section.

Please use fmt=5 for the message since this is the next available one in the IANA registry and the other work an rapid acquisition will use the following numbers when if and when it becomes a working group document.

 

I noticed that there was a lot of support for this work, so all those who support the work please help by reviewing the work so we can start WGLC ASAP

 

Roni Even

 

 

 



----
Visit us at

NAB SHOW 2009 / April 18-23 / Las Vegas, Nevada USA / South Hall (Upper), Booth SU9624F
http://www.nabshow.com/


From yekuiwang@huawei.com Tue Apr 14 07:09:14 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC92F3A6CB5 for ; Tue, 14 Apr 2009 07:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQK9UQwodCP9 for ; Tue, 14 Apr 2009 07:09:13 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id C98BF3A6C69 for ; Tue, 14 Apr 2009 07:09:13 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KI3001A4GP7M5@usaga02-in.huawei.com> for avt@ietf.org; Tue, 14 Apr 2009 07:10:20 -0700 (PDT) Received: from W90946 ([10.51.0.19]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KI3006T5G4X7C@usaga02-in.huawei.com> for avt@ietf.org; Tue, 14 Apr 2009 06:58:20 -0700 (PDT) Date: Tue, 14 Apr 2009 09:58:06 -0400 From: Ye-Kui Wang In-reply-to: <49e46079.25e2660a.30b0.ffffb5f3@mx.google.com> To: 'Roni Even' , 'Colin Perkins' , Thomas.Schierl@hhi.fraunhofer.de Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_AvkNhrlZzusEIbd4s3IwLw)" Thread-index: Acm86KhO5PCvxUgOR4G5k0DORs/2HQAH9tlQ References: <49e46079.25e2660a.30b0.ffffb5f3@mx.google.com> Cc: avt@ietf.org, avt-chairs@tools.ietf.org Subject: Re: [AVT] going forward with draft-ietf-avt-rapid-rtp-sync-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 14:09:14 -0000 This is a multi-part message in MIME format. --Boundary_(ID_AvkNhrlZzusEIbd4s3IwLw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Colin said the following a few days ago, "I submitted draft-ietf-avt-rapid-rtp-sync-00.txt - just waiting for WG chair approval. This is identical to draft-perkins-avt-rapid-rtp- sync-03.txt apart from the filename and date." Therefore, it seems that all the comments sent to the list before the San Francisco meeting should be addressed first (and there were requests that these should be addressed in the first WG version), before the "supporters" draft to do another round of review. BR, YK _____ From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even Sent: Tuesday, April 14, 2009 6:06 AM To: 'Colin Perkins'; Thomas.Schierl@hhi.fraunhofer.de Cc: avt@ietf.org; avt-chairs@tools.ietf.org Subject: [AVT] going forward with draft-ietf-avt-rapid-rtp-sync-00 Hi guys, I think Thomas had a request to move this draft forward. I suggest that you do another revision finishing the missing parts like the IANA consideration section. Please use fmt=5 for the message since this is the next available one in the IANA registry and the other work an rapid acquisition will use the following numbers when if and when it becomes a working group document. I noticed that there was a lot of support for this work, so all those who support the work please help by reviewing the work so we can start WGLC ASAP Roni Even --Boundary_(ID_AvkNhrlZzusEIbd4s3IwLw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Colin said the following a few days ago, 
 
"I submitted draft-ietf-avt-rapid-rtp-sync-00.txt - just waiting for WG chair approval. This is identical to draft-perkins-avt-rapid-rtp- sync-03.txt apart from the filename and date."
 
Therefore, it seems that all the comments sent to the list before the San Francisco meeting should be addressed first (and there were requests that these should be addressed in the first WG version), before the "supporters" draft to do another round of review.  
 
BR, YK

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even
Sent: Tuesday, April 14, 2009 6:06 AM
To: 'Colin Perkins'; Thomas.Schierl@hhi.fraunhofer.de
Cc: avt@ietf.org; avt-chairs@tools.ietf.org
Subject: [AVT] going forward with draft-ietf-avt-rapid-rtp-sync-00

Hi guys,

I think Thomas had a request to move this draft forward.

I suggest that you do another revision finishing the missing parts like the IANA consideration section.

Please use fmt=5 for the message since this is the next available one in the IANA registry and the other work an rapid acquisition will use the following numbers when if and when it becomes a working group document.

 

I noticed that there was a lot of support for this work, so all those who support the work please help by reviewing the work so we can start WGLC ASAP

 

Roni Even

 

 

 

--Boundary_(ID_AvkNhrlZzusEIbd4s3IwLw)-- From Thomas.Schierl@hhi.fraunhofer.de Tue Apr 14 07:19:09 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A21DA28C13C for ; Tue, 14 Apr 2009 07:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8NNBujKQaJH for ; Tue, 14 Apr 2009 07:19:08 -0700 (PDT) Received: from mail.hhi.fraunhofer.de (mail.HHI.FRAUNHOFER.DE [193.174.67.45]) by core3.amsl.com (Postfix) with ESMTP id 817793A6D9F for ; Tue, 14 Apr 2009 07:19:05 -0700 (PDT) Received: by mail.hhi.fraunhofer.de (Postfix, from userid 65534) id C49D71D88F98; Tue, 14 Apr 2009 16:19:44 +0200 (CEST) Received: from imsva.hhi.de (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id A55DC150036; Tue, 14 Apr 2009 16:19:44 +0200 (CEST) Received: from [10.8.0.150] (unknown [10.8.0.150]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.hhi.fraunhofer.de (Postfix) with ESMTP id C55051D88F8C; Tue, 14 Apr 2009 16:19:43 +0200 (CEST) Message-ID: <49E49B9C.2090500@hhi.fraunhofer.de> Date: Tue, 14 Apr 2009 16:20:12 +0200 From: Thomas.Schierl@hhi.fraunhofer.de Organization: Fraunhofer HHI User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ye-Kui Wang References: <49e46079.25e2660a.30b0.ffffb5f3@mx.google.com> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-alterMIME: Yes Cc: 'Colin Perkins' , avt-chairs@tools.ietf.org, avt@ietf.org Subject: Re: [AVT] going forward with draft-ietf-avt-rapid-rtp-sync-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 14:19:09 -0000 Ye-Kui,

This is the plan for the new version to be submitted early next week.

Thanks,
Thomas
______________________________________________
Thomas Schierl, Dipl.-Ing.
Fraunhofer HHI
Senior Research Engineer
Image Processing Dept. / Multimedia Transport
Einsteinufer 37, 10587 Berlin, Germany
PHONE: +49 30 31002 227 , FAX: +49 30 392 7200
WEB: http://ip.hhi.de , SKYPE: thomas.schierl
EMAIL: thomas.schierl@hhi.fraunhofer.de


Ye-Kui Wang wrote:
Colin said the following a few days ago, 
 
"I submitted draft-ietf-avt-rapid-rtp-sync-00.txt - just waiting for WG chair approval. This is identical to draft-perkins-avt-rapid-rtp- sync-03.txt apart from the filename and date."
 
Therefore, it seems that all the comments sent to the list before the San Francisco meeting should be addressed first (and there were requests that these should be addressed in the first WG version), before the "supporters" draft to do another round of review.  
 
BR, YK

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even
Sent: Tuesday, April 14, 2009 6:06 AM
To: 'Colin Perkins'; Thomas.Schierl@hhi.fraunhofer.de
Cc: avt@ietf.org; avt-chairs@tools.ietf.org
Subject: [AVT] going forward with draft-ietf-avt-rapid-rtp-sync-00

Hi guys,

I think Thomas had a request to move this draft forward.

I suggest that you do another revision finishing the missing parts like the IANA consideration section.

Please use fmt=5 for the message since this is the next available one in the IANA registry and the other work an rapid acquisition will use the following numbers when if and when it becomes a working group document.

 

I noticed that there was a lot of support for this work, so all those who support the work please help by reviewing the work so we can start WGLC ASAP

 

Roni Even

 

 

 



----
Visit us at

NAB SHOW 2009 / April 18-23 / Las Vegas, Nevada USA / South Hall (Upper), Booth SU9624F
http://www.nabshow.com/


From petithug@acm.org Tue Apr 14 08:42:55 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 970083A6E12 for ; Tue, 14 Apr 2009 08:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.147 X-Spam-Level: X-Spam-Status: No, score=-102.147 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYkyvpnN0-Nm for ; Tue, 14 Apr 2009 08:42:54 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id EB3C23A6936 for ; Tue, 14 Apr 2009 08:42:54 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id BD2BBB60408E; Tue, 14 Apr 2009 15:44:05 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 69522B60408C for ; Tue, 14 Apr 2009 15:44:03 +0000 (UTC) Message-ID: <49E4AF42.6060400@acm.org> Date: Tue, 14 Apr 2009 08:44:02 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [AVT] RFC 4103 - RTP Payload for Text Conversation X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 15:42:55 -0000 I hope that this is the right place for questions on RFC 4103. - Section 5.2, 3rd paragraph: "The last packet before an idle period will contain only one non-empty T140block as redundant data..." I am not sure how to reconcile this with the first paragraph in the same section that states that the beginning of an idle period is when the empty T140block is sent. Does it means that the idle period starts with the empty T140block when no redundancy is used, but with the last retransmitted packet when redundancy is used? This also does not fit well with the next sentence; "Any empty T140block sent as primary data MUST be included as redundant T140block in subsequent packets, just as normal text." If it was the case, wouldn't the last redundant packet sent entirely be composed of empty T140block? - Section 7.1: "As a follow-on to the previous example, the example belows shows the next RTP packet in the sequence..." The example that follow does not seems to be correct. The previous packet contains an empty primary block and data in the secondary block. The next packet contains 3 blocks so I understand that the third block in the previous packet was removed because it contained an empty block that has a too old timestamp. So the previous packet contains (older first): {empty, data, empty}, but the next packet contains {empty, data, data}, which does not make sense. If I understand correctly the protocol, it should be {data, empty, data}. Is my understanding correct? - T-140 says that the byte order mark should be inserted at the beginning of the session, which I understand as the first packet sent (as RFC 4103 does not say anything about it). But the byte order mark is useless after been converted to UTF-8 so why a sender should send it? Thanks. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From md.1@newtbt.com Tue Apr 14 09:02:16 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B21B3A6E57 for ; Tue, 14 Apr 2009 09:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYbQz+IpLyrX for ; Tue, 14 Apr 2009 09:02:15 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 387E63A6E4E for ; Tue, 14 Apr 2009 09:02:12 -0700 (PDT) Received: from TBT-Laptop.newtbt.com (ppp-71-129-250-70.dsl.sndg02.pacbell.net [71.129.250.70]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1Ltl6X2vXl-000flf; Tue, 14 Apr 2009 12:03:23 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 14 Apr 2009 09:03:18 -0700 To: avt@ietf.org From: Michael A Dolan In-Reply-To: <49e46079.25e2660a.30b0.ffffb5f3@mx.google.com> References: <49e46079.25e2660a.30b0.ffffb5f3@mx.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <0MKp8S-1Ltl6X2vXl-000flf@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX18JLE53MYve4iHVlPA8CCRaVUs6UIftC9EQ1YK p3kvNnhXUe5Y/cqjz4qMDGv/tyRdzmVqWB520mRX6SSgdr8mbU 0GPHHGovHc+SrlLlwO/rA== Subject: Re: [AVT] going forward with draft-ietf-avt-rapid-rtp-sync-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 16:02:16 -0000 Roni- My comments from the earlier draft have not been addressed, but I see the authors are preparing another revision. But before I continued the thread with the authors, I had asked you your intentions for modifying the charter. The new ID is now listed, but there is no discussion. It would be helpful to understand the scope of this work and if this is intended to be a general and complete guidance for rapid sync between RTP sessions, or just one way to improve sync in some cases? Thanks, Mike At 01:06 PM 4/14/2009 +0300, Roni Even wrote: >Content-Type: multipart/alternative; > boundary="----=_NextPart_000_0086_01C9BD01.D0454F70" >Content-language: en-us > >Hi guys, >I think Thomas had a request to move this draft forward. >I suggest that you do another revision finishing the missing parts >like the IANA consideration section. >Please use fmt=5 for the message since this is the next available >one in the IANA registry and the other work an rapid acquisition >will use the following numbers when if and when it becomes a working >group document. > >I noticed that there was a lot of support for this work, so all >those who support the work please help by reviewing the work so we >can start WGLC ASAP > >Roni Even > > > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www.ietf.org/mailman/listinfo/avt From gunnar.hellstrom@omnitor.se Tue Apr 14 10:44:13 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97DC328C19F for ; Tue, 14 Apr 2009 10:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1LZQ1NJIshm for ; Tue, 14 Apr 2009 10:44:12 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 2B5473A6B6F for ; Tue, 14 Apr 2009 10:44:11 -0700 (PDT) Received: (qmail 54860 invoked from network); 14 Apr 2009 17:45:28 -0000 Received: from s34.loopia.se (HELO s128.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 14 Apr 2009 17:45:28 -0000 Received: (qmail 97754 invoked from network); 14 Apr 2009 17:45:20 -0000 Received: from h16n1fls34o265.telia.com (HELO GunnarH) (gunnar.hellstrom@omnitor.se@[213.64.232.16]) (envelope-sender ) by s128.loopia.se (qmail-ldap-1.03) with SMTP for ; 14 Apr 2009 17:45:20 -0000 From: "Gunnar Hellstrom" To: "'Marc Petit-Huguenin'" , References: <49E4AF42.6060400@acm.org> Date: Tue, 14 Apr 2009 19:45:20 +0200 Message-ID: <01c501c9bd28$c8139d80$211ea8c0@GunnarH> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acm9F+DJsNpXMDA/RL6T32/pHfvrsQACsdWw In-Reply-To: <49E4AF42.6060400@acm.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Subject: Re: [AVT] RFC 4103 - RTP Payload for Text Conversation X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 17:44:13 -0000 Marc, I will start answering your questions in the AVT list. In parallell, we can have a side discussion about details if you want.=20 I have guided some implementors through implementations and interop = tests. Until then, take a look at www.realtimetext.org and sourceforge.net search for tipcon1=20 Regards Gunnar=20 ------------------------------------------------------------------- Gunnar Hellstr=F6m Omnitor gunnar.hellstrom@omnitor.se Tel: +46708204288 www.omnitor.se -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Marc Petit-Huguenin Sent: Tuesday, April 14, 2009 5:44 PM To: avt@ietf.org Subject: [AVT] RFC 4103 - RTP Payload for Text Conversation I hope that this is the right place for questions on RFC 4103. - Section 5.2, 3rd paragraph: "The last packet before an idle period = will contain only one non-empty T140block as redundant data..." I am not sure how to reconcile this with the first paragraph in the same section that states that the beginning of an idle period is when the = empty T140block is sent. Does it means that the idle period starts with the = empty T140block when no redundancy is used, but with the last retransmitted = packet when redundancy is used? This also does not fit well with the next sentence; "Any empty T140block sent as primary data MUST be included as redundant T140block in = subsequent packets, just as normal text." If it was the case, wouldn't the last redundant packet sent entirely be composed of empty T140block? - Section 7.1: "As a follow-on to the previous example, the example = belows shows the next RTP packet in the sequence..." The example that follow does not seems to be correct. The previous = packet contains an empty primary block and data in the secondary block. The = next packet contains 3 blocks so I understand that the third block in the previous packet was removed because it contained an empty block that has = a too old timestamp. So the previous packet contains (older first): = {empty, data, empty}, but the next packet contains {empty, data, data}, which = does not make sense. If I understand correctly the protocol, it should be = {data, empty, data}. Is my understanding correct? - T-140 says that the byte order mark should be inserted at the = beginning of the session, which I understand as the first packet sent (as RFC 4103 = does not say anything about it). But the byte order mark is useless after = been converted to UTF-8 so why a sender should send it? Thanks. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt __________ NOD32 4006 (20090414) Information __________ Detta meddelande dr genomsvkt av NOD32 Antivirus. http://www.nod32.com From gunnar.hellstrom@omnitor.se Tue Apr 14 13:52:27 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E97C3A695B for ; Tue, 14 Apr 2009 13:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sd3+trAj8sql for ; Tue, 14 Apr 2009 13:52:26 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id EA0C73A659C for ; Tue, 14 Apr 2009 13:52:25 -0700 (PDT) Received: (qmail 30042 invoked from network); 14 Apr 2009 20:53:43 -0000 Received: from s34.loopia.se (HELO s128.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 14 Apr 2009 20:53:43 -0000 Received: (qmail 162 invoked from network); 14 Apr 2009 20:53:34 -0000 Received: from h16n1fls34o265.telia.com (HELO GunnarH) (gunnar.hellstrom@omnitor.se@[213.64.232.16]) (envelope-sender ) by s128.loopia.se (qmail-ldap-1.03) with SMTP for ; 14 Apr 2009 20:53:34 -0000 From: "Gunnar Hellstrom" To: "'Marc Petit-Huguenin'" , References: <49E4AF42.6060400@acm.org> Date: Tue, 14 Apr 2009 22:53:34 +0200 Message-ID: <01ea01c9bd43$13f96620$211ea8c0@GunnarH> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acm9F+DJsNpXMDA/RL6T32/pHfvrsQAIM9jg In-Reply-To: <49E4AF42.6060400@acm.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Subject: Re: [AVT] RFC 4103 - RTP Payload for Text Conversation X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 20:52:27 -0000 Marc, See answers inline. -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Marc Petit-Huguenin Sent: Tuesday, April 14, 2009 5:44 PM To: avt@ietf.org Subject: [AVT] RFC 4103 - RTP Payload for Text Conversation I hope that this is the right place for questions on RFC 4103. - Section 5.2, 3rd paragraph: "The last packet before an idle period will contain only one non-empty T140block as redundant data..." I am not sure how to reconcile this with the first paragraph in the same section that states that the beginning of an idle period is when the empty T140block is sent. Does it means that the idle period starts with the empty T140block when no redundancy is used, but with the last retransmitted packet when redundancy is used? This also does not fit well with the next sentence; "Any empty T140block sent as primary data MUST be included as redundant T140block in subsequent packets, just as normal text." If it was the case, wouldn't the last redundant packet sent entirely be composed of empty T140block? - Section 7.1: "As a follow-on to the previous example, the example belows shows the next RTP packet in the sequence..." The example that follow does not seems to be correct. The previous packet contains an empty primary block and data in the secondary block. The next packet contains 3 blocks so I understand that the third block in the previous packet was removed because it contained an empty block that has a too old timestamp. So the previous packet contains (older first): {empty, data, empty}, but the next packet contains {empty, data, data}, which does not make sense. If I understand correctly the protocol, it should be {data, empty, data}. Is my understanding correct? Thanks Gunnar Hellstrom. -------------------- Thanks. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt __________ NOD32 4006 (20090414) Information __________ Detta meddelande dr genomsvkt av NOD32 Antivirus. http://www.nod32.com From petithug@acm.org Tue Apr 14 15:39:21 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6D7E3A67D0 for ; Tue, 14 Apr 2009 15:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EFuHCKZpK2z for ; Tue, 14 Apr 2009 15:39:21 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 228793A677D for ; Tue, 14 Apr 2009 15:39:21 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 808B96C98428; Tue, 14 Apr 2009 22:40:32 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id A96146C9842A; Tue, 14 Apr 2009 22:39:58 +0000 (UTC) Message-ID: <49E510BC.7090708@acm.org> Date: Tue, 14 Apr 2009 15:39:56 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Gunnar Hellstrom References: <49E4AF42.6060400@acm.org> <01ea01c9bd43$13f96620$211ea8c0@GunnarH> In-Reply-To: <01ea01c9bd43$13f96620$211ea8c0@GunnarH> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: avt@ietf.org Subject: Re: [AVT] RFC 4103 - RTP Payload for Text Conversation X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 22:39:21 -0000 Gunnar Hellstrom wrote: > Marc, > See answers inline. > > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Marc > Petit-Huguenin > Sent: Tuesday, April 14, 2009 5:44 PM > To: avt@ietf.org > Subject: [AVT] RFC 4103 - RTP Payload for Text Conversation > > I hope that this is the right place for questions on RFC 4103. > > - Section 5.2, 3rd paragraph: "The last packet before an idle period will > contain only one non-empty T140block as redundant data..." > > I am not sure how to reconcile this with the first paragraph in the same > section that states that the beginning of an idle period is when the empty > T140block is sent. Does it means that the idle period starts with the empty > T140block when no redundancy is used, but with the last retransmitted packet > when redundancy is used? > > that case you transmit one packet with an empty T140 block at the sample > time after the last valid data. Then there will be an equal opportunity to > detect if valid data is missing regardless of if the data is within a text > burst or at the end of it. The idle period starts after transmission of that > packet. > Next multi-line paragraph is for the redundancy case. Then you send in this > pattern: > data1, data2, data3. > > data2, data3, empty. > > data3, empty, empty > > ----- idle period ---- > > empty, empty, data4 > > This matches your assumption, and the text in the RFC.> So if I understand correctly the idle period starts 300 ms after sending the last text when there is no redundancy, and 600 ms after sending the last text in the primary block when using redundancy. > > > This also does not fit well with the next sentence; "Any empty T140block > sent as primary data MUST be included as redundant T140block in subsequent > packets, just as normal text." If it was the case, wouldn't the last > redundant packet sent entirely be composed of empty T140block? > T140 block that has not been transmitted the full number of redundant > generations, will be transmitted again, stepped up in redundancy > generations, and followed by the new primary data. But if the idle period > was longer, the old empty blocks will be dropped. > OK. > > - T-140 says that the byte order mark should be inserted at the beginning of > the session, which I understand as the first packet sent (as RFC 4103 does > not say anything about it). But the byte order mark is useless after been > converted to UTF-8 so why a sender should send it? > outgoing packets in order to be able to receive incoming packets. So, one > reason for this transmission is to "prime the channel". Right. NATs. Thanks. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From root@core3.amsl.com Wed Apr 15 05:45:01 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EFAF13A6AF5; Wed, 15 Apr 2009 05:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090415124501.EFAF13A6AF5@core3.amsl.com> Date: Wed, 15 Apr 2009 05:45:01 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtp-gsm-hr-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 12:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload format for GSM-HR Author(s) : X. Duan, et al. Filename : draft-ietf-avt-rtp-gsm-hr-00.txt Pages : 18 Date : 2009-04-15 This document specifies the RTP payload format for packetization of the GSM Half-Rate speech codec. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-gsm-hr-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-rtp-gsm-hr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-15053148.I-D@ietf.org> --NextPart-- From csp@csperkins.org Wed Apr 15 08:58:41 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52F483A69E7 for ; Wed, 15 Apr 2009 08:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HttzL-yCkaIh for ; Wed, 15 Apr 2009 08:58:40 -0700 (PDT) Received: from lon1-msapost-3.mail.demon.net (lon1-msapost-3.mail.demon.net [195.173.77.182]) by core3.amsl.com (Postfix) with ESMTP id 5E4793A694A for ; Wed, 15 Apr 2009 08:58:40 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1Lu7Wi-0001Rg-dq; Wed, 15 Apr 2009 15:59:52 +0000 Message-Id: <6948A2B0-C5F3-4934-BBE4-2D53FEDE1454@csperkins.org> From: Colin Perkins To: IETF AVT WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 15 Apr 2009 16:59:51 +0100 References: X-Mailer: Apple Mail (2.930.3) Cc: Marshall Eubanks Subject: [AVT] Fwd: [Fecframe] WGLC on draft-ietf-fecframe-interleaved-fec-scheme X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 15:58:41 -0000 Forwarding to AVT, since this is an RTP payload format. Colin Begin forwarded message: > From: Marshall Eubanks > Date: 1 April 2009 13:36:50 BST > To: fecframe@ietf.org > Subject: [Fecframe] WGLC on draft-ietf-fecframe-interleaved-fec-scheme > > As was discussed in the meeting last week, I would like to start a > Working Group Last Call on > > draft-ietf-fecframe-interleaved-fec-scheme . This draft can be found > at > > http://tools.ietf.org/html/draft-ietf-fecframe-interleaved-fec-scheme-02 > > This WGLC will run until midnight, UTC, on April 16th. Please read > this draft and send your comments and questions to the list. > > Regards > Marshall > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe -- Colin Perkins http://csperkins.org/ From root@core3.amsl.com Wed Apr 15 13:30:02 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1899B28C245; Wed, 15 Apr 2009 13:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090415203002.1899B28C245@core3.amsl.com> Date: Wed, 15 Apr 2009 13:30:02 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-ipmr-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 20:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for SPIRIT IP-MR Speech Codec Author(s) : A. Setsko Filename : draft-ietf-avt-rtp-ipmr-03.txt Pages : 13 Date : 2009-4-15 This document specifies the payload format for packetization of SPIRIT IP-MR encoded speech signals into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per payload and introduced redundancy for robustness against packet loss. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-ipmr-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-rtp-ipmr-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-4-15132754.I-D@ietf.org> --NextPart-- From versteb@cisco.com Thu Apr 16 09:37:45 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46DD03A6EA3 for ; Thu, 16 Apr 2009 09:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 852P5xSkXWX2 for ; Thu, 16 Apr 2009 09:37:44 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4245D3A69E6 for ; Thu, 16 Apr 2009 09:37:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,198,1238976000"; d="scan'208,217";a="287473179" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-6.cisco.com with ESMTP; 16 Apr 2009 16:38:57 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3GGcuZQ025365 for ; Thu, 16 Apr 2009 12:38:56 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3GGcu0L009225 for ; Thu, 16 Apr 2009 16:38:56 GMT Received: from xmb-rtp-21d.amer.cisco.com ([64.102.31.116]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 12:38:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BEB1.D623BD7E" Date: Thu, 16 Apr 2009 12:38:56 -0400 Message-ID: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available Thread-Index: Acm+sdXPh1GGTWXYSFG97HplRMX73Q== From: "Bill Ver Steeg (versteb)" To: X-OriginalArrivalTime: 16 Apr 2009 16:38:56.0921 (UTC) FILETIME=[D6375890:01C9BEB1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4102; t=1239899937; x=1240763937; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=versteb@cisco.com; z=From:=20=22Bill=20Ver=20Steeg=20(versteb)=22=20 |Subject:=20New=20draft=20of=20=22Rapid=20Acquisition=20of= 20Multicast=20RTP=20Sessions=20(RAMS)=22=20available |Sender:=20 |To:=20; bh=9R9VrFZMMxjyuvZ7/2zgGiUX9TIhuo98maTsuYzasWc=; b=W1LYNLQIV3HfWYvbr8jFerqEb9uu0iyE/qRFuFTnsXchb6U5HVoO4nD//8 nsqCznXuQCYDTMZ8H1mQLto3Pgheb4tE1P78g8jGEXjs3I2HLFSh1BHTr6rC QSbnKbZvdh; Authentication-Results: rtp-dkim-2; header.From=versteb@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 16:37:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BEB1.D623BD7E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is a new draft of the "Rapid Acquisition of Multicast RTP Sessions (RAMS)" draft available at http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-synchroniza tion-for-rtp-03.txt =20 =20 We have incorporated the changes from the technical breakout session in San Francisco. The major changes in this version of the draft include=20 1- Changing the document title to avoid confusion with other ongoing "synchronization" drafts 2- changing the message names to reflect the title change 3- clarification of the RTCP message semantics, including changes to the "Request" and "Inform" messages 4- additional description/motivation for the various message flows has been added 5- RTP/RTCP muxing has been added =20 =20 We hope to make this a Working Group item, and will change the name of the draft to avoid conflicts with other "synchronization" drafts at that time. =20 Bill VerSteeg =20 =20 ------_=_NextPart_001_01C9BEB1.D623BD7E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
There = is a new draft=20 of the "Rapid Acquisition of Multicast RTP Sessions (RAMS)" draft = available at=20 http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-syn= chronization-for-rtp-03.txt
 
We=20 have incorporated the changes from the technical breakout session = in San=20 Francisco. The major changes in this version of the draft include=20
1- = Changing the=20 document title to avoid confusion with other ongoing "synchronization"=20 drafts
2- = changing the=20 message names to reflect the title change
3- = clarification of=20 the RTCP message semantics, including changes to the "Request" = and=20 "Inform" messages
4- = additional=20 description/motivation for the various message flows has been=20 added
5- = RTP/RTCP muxing=20 has been added
 
 
We = hope to make this=20 a Working Group item, and will change the name of the draft to avoid = conflicts=20 with other "synchronization" drafts at that time.
 
Bill=20 VerSteeg
 
 
------_=_NextPart_001_01C9BEB1.D623BD7E-- From wwwrun@core3.amsl.com Thu Apr 16 13:57:40 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 560B33A6B43; Thu, 16 Apr 2009 13:57:39 -0700 (PDT) To: geoff.hunt@bt.com,alan.d.clark@telchemy.com From: IETF Secretariat Message-Id: <20090416205740.560B33A6B43@core3.amsl.com> Date: Thu, 16 Apr 2009 13:57:40 -0700 (PDT) X-Mailman-Approved-At: Fri, 17 Apr 2009 13:13:12 -0700 Cc: fluffy@cisco.com, tom.taylor@rogers.com, avt@ietf.org, ipr-announce@ietf.org Subject: [AVT] Posting of IPR Disclosure related to Cisco System's Statement of IPR related to draft-ietf-avt-rtcp-xr-loss-conceal-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 20:57:40 -0000 Dear Geoff Hunt, Alan Clark: An IPR disclosure that pertains to your Internet-Draft entitled "RTCP XR Report Block for Loss Concealment metric Reporting" (draft-ietf-avt-rtcp-xr-loss-conceal) was submitted to the IETF Secretariat on 2009-04-15 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1131/). The title of the IPR disclosure is "Cisco System's Statement of IPR related to draft-ietf-avt-rtcp-xr-loss-conceal-01." The IETF Secretariat From wwwrun@core3.amsl.com Thu Apr 16 14:00:22 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 597DC3A6E06; Thu, 16 Apr 2009 14:00:21 -0700 (PDT) To: geoff.hunt@bt.com,alan.d.clark@telchemy.com From: IETF Secretariat Message-Id: <20090416210022.597DC3A6E06@core3.amsl.com> Date: Thu, 16 Apr 2009 14:00:22 -0700 (PDT) X-Mailman-Approved-At: Fri, 17 Apr 2009 13:13:12 -0700 Cc: fluffy@cisco.com, tom.taylor@rogers.com, avt@ietf.org, ipr-announce@ietf.org Subject: [AVT] Posting of IPR Disclosure related to Cisco System's Statement of IPR related to draft-ietf-avt-rtcp-xr-concsec-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 21:00:22 -0000 Dear Geoff Hunt, Alan Clark: An IPR disclosure that pertains to your Internet-Draft entitled "RTCP XR Report Block for Concealed Seconds metric Reporting" (draft-ietf-avt-rtcp-xr-concsec) was submitted to the IETF Secretariat on 2009-04-15 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1132/). The title of the IPR disclosure is "Cisco System's Statement of IPR related to draft-ietf-avt-rtcp-xr-concsec-01." The IETF Secretariat From tom.taylor@rogers.com Fri Apr 17 17:48:24 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26D383A6A38 for ; Fri, 17 Apr 2009 17:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHE0tXiUacmU for ; Fri, 17 Apr 2009 17:48:22 -0700 (PDT) Received: from smtp123.rog.mail.re2.yahoo.com (smtp123.rog.mail.re2.yahoo.com [206.190.53.28]) by core3.amsl.com (Postfix) with SMTP id 43C803A6ACA for ; Fri, 17 Apr 2009 17:48:22 -0700 (PDT) Received: (qmail 49314 invoked from network); 18 Apr 2009 00:49:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=0xCA/CQkMutUE1wqDPoM3hcPI6L4+cOv/LpRKOKUDdxq+36HnzjSOkoA7mmialfCcPDpLZT9ABpvVKi33Fn71f8lANsJjWSuvCjKJtGZQGxJCZyLrxUWIu53rH7YZ87FEYgKsj55SlmoHoplebeyIfJYnrx9jOp/Sikc13pzQRI= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@72.140.46.24 with plain) by smtp123.rog.mail.re2.yahoo.com with SMTP; 18 Apr 2009 00:49:35 -0000 X-YMail-OSG: fADcjsMVM1mVOgMXSIhy7r9nPFi2v402jz0Lih8cfGhreXjRow9hNlRZuzEz3l6q.g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E9239F.7000909@rogers.com> Date: Fri, 17 Apr 2009 20:49:35 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: IETF AVT WG , Roni Even Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [AVT] IETF 74 AVT Minutes first cut X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 00:48:24 -0000 I'll improve the minutes for the second session before submitting, but in the meantime, please check everything for accuracy. Tom Taylor AVT Minutes ============ AVT met for two sessions at IETF 74: Monday 1300-1500, and Thursday 1510-1610. Roni Even and Tom Taylor chaired the sessions. Monday 1300-1500 ================ Dave Oran took notes, with some help from Joerg Ott . Jonathan Lennox acted as Jabber scribe. There were 75 attendees at this session. Chair report (Roni Even) ======================== Slides at http://www.ietf.org/proceedings/09mar/slides/avt-0.pdf - Slight change to agenda: moved security issues to Thursday, RTCP-XR moved to today. - NOTE WELL was presented. - Chairs gave document status - see agenda/intro slides for individual document details. Noted that SSM is blocking some key documents. Apparently a production problem -- using Word. In addition to drafts listed, noted that SVC and 3984bis are ready to go to the IESG. - Received a liaison from ITU-T Q18 of WP1/16. Desire is to avoid tandem media processing entities on a bearer path (e.g. echo cancellers). See chair slides for discussion and details. WG is asked to give chairs input (via mailing list) on how to respond. Colin Perkins on Jabber: do we need a joint BoF to discuss requirements? - Need charter update for RTCP extensions. - There is an issue with codec references for media sub-type registration in the standards tree when the codec itself is proprietary but the payload type is defined by an IETF document. Registry rules are unclear. Topic is on agenda for a meeting between the Chairs and ADs Thursday morning. - RFC3016 mainly used by 3GPP, but some misalignments with 3GPP PSS service. draft-schmidt-avt-rfc3016bis-01 provides updates. The authors want it adopted as a WG work item. RTP Payload for IP-MR Speech codec ================================== draft-ietf-avt-rtp-ipmr-02 Roni presented on behalf of the authors Slides at http://www.ietf.org/proceedings/09mar/slides/avt-1.pdf - on-the-fly adaptable wideband speech codec, VBR, etc. - see slides for details of updates from previous version. - Need review to ascertain whether it is ready for last call. No one indicated that they had read the draft. Rapid Synchronization of RTP flows ================================== draft-perkins-avt-rapid-rtp-sync-03 Roni presented on behalf of the authors Slides at http://www.ietf.org/proceedings/09mar/slides/avt-2.pdf - general agreement to change name of the rapid multicast synch work to avoid terminology confusion. This draft will keep the "rapid synch" terminology. - current draft is a merge of draft-perkins... and draft-schierl... - see slides for details on draft technical content and updates since -00. - proposed solution to jitter problem is to use the NTP header extension for all streams in the session - trying to encourage DVB to use this spec instead of rolling their own for TM-AVC. Chairs polled the room as to whether it should be a working group item. Hum agreement it should be - will confirm on mailing list. Ye-Kui Wang noted that "SSM" was spelled out in different ways. It should be "Source-specific multicast". Rapid Synchronization with RTP Multicast Sessions ================================================= (1) draft-versteeg-avt-rapid-synchronization-for-rtp-02 --------------------------------------------------- Presented by Bill Ver Steeg Slides at http://www.ietf.org/proceedings/09mar/slides/avt-3.pdf The drafts presented at IETF 73 were merged into this one. However, there is another draft dealing with this topic (see below). To avoid confusion with the Perkins-Schierl work item it is proposed to rename this draft to "Unicast-based Rapid Acquisition of Multicast RTP Sessions". - See slides for background and enumeration of updates from last version. - Current draft is a merge of -01 and draft=-levin-rtp-burst. They were similar and not a big deal to combine - Went to TLV encoding of the fields. The earlier dependence on MPEG-2 transport stream transport has been removed. Adding capability for vendor-specific fields. Roni Even remarked that there was no text explaining how the TLVs are used and what is the behavior associated with them. Bill Ver Steeg said they would work to clarify the semantics. Dave Oran noted that in most cases these fields are used strictly for optimizations. Roni argued that designers will not implement them if they see no gain from doing so. Authors will continue to consider the matter. - issue around when and whether we can use extended RTP sequence numbers in the control messages. Breakout scheduled for Tuesday 9 am to discuss open issues. Roni: once a it is a WG item we can think about fixing FMT items. Xavier Marjou : was there thought as to whether everything should be in RTP header extensions rather than RTCP messages? He had NAT interference in mind. Dave Oran responded that most of the messaging fits with the AVPF control channel model, but it might be a good idea to piggyback RS->RR control information for burst rate changes. Zeev Vax added that you can derive burst rate from the received data, but the idea of using header extensions is worth considering. Roni observed that we still need to iron out the details of the mechanism. He would try to present the outcome of the breakout session on Thursday so we can get this to be a WG item as soon as possible. (2) draft-peilin-avt-rtp-burst-01 ----------------------------- Ye-Kui Wang presented on behalf of the authors. Slides at http://www.ietf.org/proceedings/09mar/slides/avt-7.pdf. - there may be Huawei IPR on the draft. - General architecture adopts the draft-versteeg... approach - Two new items beyond what is in the other draft -- 1: allows burst rate to be controlled by RR, RS or both together. -- 2: Method to terminate a burst based on initiation of a different burst - See slides and draft for details. Yunfei Zhang [??]: Requirements OK, but (1) not sure how receiver can know what bit rate to provide to the sender, and (2) are these mandatory requirements of the solution? - Roni: clarification of (1) how does the RR know the peak rate it can use? Answer: receiver just tells what it may know. Followup: should IETF be specifying optimal bitrates? YeKui: not looking to optimize. No need for IETF to specify -- situations differ. Roni: look at RFC 3550. Zeev: Burst typically 5-10 seconds. Can't adapt faster than RTT allows. Need stable jitter and loss estimate. Takes longer than time available. Risk of increased overhead without adding value. - Yunfei second question: is it implied that support of rapid channel change is mandatory? No - depends on provider, but question of making system work better. Dave Oran: bear in mind that this is an optimization of an optimization. Second point: if message fails, don't want to worsen subscriber experience. RTCP-XR* Drafts =============== Geoff Hunt presented. Slides at http://www.ietf.org/proceedings/09mar/slides/avt-4.pdf. - There is a large menagerie of these - see slides for a list. Split of drafts due to a "re-architecting" of the XR drafts to separate the individual blocks to be specific rather than packaged together in arbitrary sets. - see slides for changes from prior versions. A Cisco IPR claim affecting -xr-concsec was noted. Al Morton: on PDV block draft, 2 points - (1) would good to reference an RFC on PDV guidance (RFC5481), (2) Naming conventions in this draft no longer correspond to the terms we use in RFC3550 and elsewhere. He would be glad to help nail the names down, particularly before they get put into an IANA registry. There is now general convergence amongst SDOs. Reviews requested. Milestones still have to be firmed up. Cullen understands the logic of creating so many drafts, but suggested we discuss the prioritization of these drafts on the list. RTP payload format for the CELT codec ===================================== draft-valin-celt-rtp-profile-00 Presented by Greg Maxwell Slides at http://www.ietf.org/proceedings/09mar/slides/avt-5.pdf - Presented background of codec characteristics (see slides). On chart 4, Dave Oran what the Y-axis was for the bar chart on the right -- scores from ITU-T methodology. - To solve early media problems - could burn a bunch of payload types (combinatorics kill it) so need to choose some common combinations. - Future work consideration is signaling configuration data, also need to freeze the CELT bit-stream. RTP Payload format for DV (IEC 61834) Video =========================================== draft-ietf-avt-rfc3189bis-02 Roni provided a quick review. Slides at http://www.ietf.org/proceedings/09mar/slides/avt-6.pdf. - Minor changes from last draft (see slides) Need opinions on whether this is ready for WGLC. AVT Thursday Mar 26 =================== Roni and Tom chairing Status ============= Roni Perkins synch In favour of making WG item? No objections Summary from burst breakout session (chart) Revision then go to list to make WG item DTLS-SRTP Key Transport (Dan) ============================= Apologies, material to be uploaded after presentation. Supports interworking with sdescriptions. David McGrew states values to this independently of EKT -- interworking needed ?? can add description of interworking with MIKEY? Yes. Please indicate which variety of MIKEY is of interest. Roni: verify that the call flows work correctly in interworking. Encrypted key transport (EKT) David McGrew ========================================== Master key conveyed to many participants. Layer of indirection separating key management (who should have it?) from conferencing details. Group controller sets up DTLS-SRTP key transport EKT uses 1 to many RTP channel Defined two years ago, premature. Essential for scaling to large groups -- avoids layer violations. Currently ses sdescriptions Eric Rescorla: what alternatives to EKT. A couple of DTLS-SRTP extensions give almost as good results. How would you know it is safe to send EKT messages? SDP. Looks quite useful. Roni: Do more discussion of tradeoffs before merging documents. Think about multi-unicast cast, which scales differently from multicast. ?? need reliability, RTP not reliable. David: can lose some packets. Dan: can send in either RTCP or RTP. In latter case, common fate. Sender can use more replication initially. AES-192 and AES-256 David McGrew ================================ 128 bit keys won't expire for decades, but might want to be ready for larger keys. Possibilities: future advances in cryptanalysis, larger computers. (Competition/compatibility ZRTP). SWEETPEA compliance. Should we make AES-192 optional, make AES-256 the target. Definitely add DTLS-SRTP binding. Agreed, make standard Jonathan: what about SHA-1? Offline discussion. Cullen: make sure SecArea gets involved. AES-GCM and AES-CCM autheticated encryption David McGrew ======================================================== AES-GCM Encryption + authen -- no need for HMAC Arguably efficient, esp. for short packets AES-CCM more compact code. Draft uses interface defined by RFC 5116 Eric: supports making WG doc. But why CCM? Roni: see if existing usage mandates use Dan xx: might consider SIV instead of CCM. SRTP Store and forward Blom =========================== Draft refocussed on use cases and requirements. Cullen only reader. Didn't understand it all yet. Eric: wondered why all the layers. Response: other scenarios. Continuing discussion. To the list. From petithug@acm.org Sat Apr 18 08:29:50 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2D353A6A5C for ; Sat, 18 Apr 2009 08:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.227 X-Spam-Level: X-Spam-Status: No, score=-101.227 tagged_above=-999 required=5 tests=[AWL=-0.821, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmHENHya6inl for ; Sat, 18 Apr 2009 08:29:50 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 493193A692E for ; Sat, 18 Apr 2009 08:29:50 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id B880115BC4030; Sat, 18 Apr 2009 15:31:03 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 96EEC15BC4032 for ; Sat, 18 Apr 2009 15:31:02 +0000 (UTC) Message-ID: <49E9F234.7000400@acm.org> Date: Sat, 18 Apr 2009 08:31:00 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [AVT] Another question on RFC 4103 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 15:29:50 -0000 RFC 4103 does not give any advice on what to do when a t140block to send will create an RTP packet that will exceed the PMTU. Should the PMTU be considered as an implicit maximum character transmission rate, or should multiple RTP packets with the same timestamp be sent? (for the latter there is the additional issue that RFC 2198 does not provide any advice on the same problem). For example let say that the cps is 30 and the PMTU is unknown so 576 bytes is the maximum IPv4 packet size that can be sent. With 30 cps and a language that makes use of three bytes per character, the maximum block size is 900 bytes which is more than the maximum IPv4 packet size without even counting the overhead. In this case the maximum implicit cps would be 17 cps. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From gunnar.hellstrom@omnitor.se Sat Apr 18 12:31:54 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81B553A6BA1 for ; Sat, 18 Apr 2009 12:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[AWL=-0.809, BAYES_20=-0.74, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qc9Ds45+q5s for ; Sat, 18 Apr 2009 12:31:53 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 15CC33A6B7D for ; Sat, 18 Apr 2009 12:31:52 -0700 (PDT) Received: (qmail 77512 invoked from network); 18 Apr 2009 19:33:12 -0000 Received: from s34.loopia.se (HELO s57.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 18 Apr 2009 19:33:12 -0000 Received: (qmail 18454 invoked from network); 18 Apr 2009 19:32:58 -0000 Received: from h16n1fls34o265.telia.com (HELO GunnarH) (gunnar.hellstrom@omnitor.se@[213.64.232.16]) (envelope-sender ) by s57.loopia.se (qmail-ldap-1.03) with SMTP for ; 18 Apr 2009 19:32:58 -0000 From: "Gunnar Hellstrom" To: "'Marc Petit-Huguenin'" , References: <49E9F234.7000400@acm.org> Date: Sat, 18 Apr 2009 21:33:02 +0200 Message-ID: <00ad01c9c05c$82028fe0$211ea8c0@GunnarH> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcnAOre8FTwx+Vg/TIKzlE2/DdsSfwABEZTg In-Reply-To: <49E9F234.7000400@acm.org> Subject: Re: [AVT] Another question on RFC 4103 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 19:31:54 -0000 Marc, My calculations end up a factor 10 lower than yours. You are right that we did not think there was any reason to go deep in a discussion on MTU sizes in RFC 4103. Instead we specify the intended use, that is for human input, and human reading in a real-time conversation. The most rapid input I can imagine is from a speech-to-text application, that maybe can reach 20 characters per second from a rapid speaker. That is why the maximum required rate to support is specified to be 30 characters per second. The recommended sample time is 300 ms, resulting in sending 3.3 packets per second when there is text to send. With an even caracter rate, that results in 9 new characters per packet. With the recommended two generations of redundancy, it will mean that 27 characters are packed in each packet. If they are from a language that make use of three UTF-8 bytes per character, there will be a mean of 81 bytes text per packet. Add the IPv4, UDP, RTP and RFC2198 overhead of -say 70 bytes, the packet size that will be close to maximum is 151 bytes. That is so far from the maximum MTU size This is a maximum. In reality, text is usually entered by typing, resulting in only 1-4 new characters per packet. Even if the reasoning above tells that there is no risk at all for exceeding the maximum MTU-size, the application should follow a reasonable strategy to be sure: The application should check so that the maximum MTU is not exceeded. If there is a risk for that, excess characters should be delayed and transmitted in next regular packet to transmit. Gunnar -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Marc Petit-Huguenin Sent: Saturday, April 18, 2009 5:31 PM To: avt@ietf.org Subject: [AVT] Another question on RFC 4103 RFC 4103 does not give any advice on what to do when a t140block to send will create an RTP packet that will exceed the PMTU. Should the PMTU be considered as an implicit maximum character transmission rate, or should multiple RTP packets with the same timestamp be sent? (for the latter there is the additional issue that RFC 2198 does not provide any advice on the same problem). For example let say that the cps is 30 and the PMTU is unknown so 576 bytes is the maximum IPv4 packet size that can be sent. With 30 cps and a language that makes use of three bytes per character, the maximum block size is 900 bytes which is more than the maximum IPv4 packet size without even counting the overhead. In this case the maximum implicit cps would be 17 cps. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt __________ NOD32 4018 (20090418) Information __________ Detta meddelande dr genomsvkt av NOD32 Antivirus. http://www.nod32.com From petithug@acm.org Sat Apr 18 13:13:48 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 467013A6C46 for ; Sat, 18 Apr 2009 13:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.14 X-Spam-Level: X-Spam-Status: No, score=-102.14 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iX+HQ5XDZik0 for ; Sat, 18 Apr 2009 13:13:47 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 7F11F3A68DE for ; Sat, 18 Apr 2009 13:13:47 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id C661215BC402E; Sat, 18 Apr 2009 20:15:00 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id B84CC15BC402E; Sat, 18 Apr 2009 20:14:55 +0000 (UTC) Message-ID: <49EA34BC.8080600@acm.org> Date: Sat, 18 Apr 2009 13:14:52 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Gunnar Hellstrom References: <49E9F234.7000400@acm.org> <00ad01c9c05c$82028fe0$211ea8c0@GunnarH> In-Reply-To: <00ad01c9c05c$82028fe0$211ea8c0@GunnarH> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: avt@ietf.org Subject: Re: [AVT] Another question on RFC 4103 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 20:13:48 -0000 Gunnar Hellstrom wrote: > Marc, > My calculations end up a factor 10 lower than yours. Section 6 of RFC 4103 states that "The [cps] value shall be used as a mean value over any 10-second internal." So at 30 cps, one can send nothing for 10 seconds then send a block of 300 characters without triggering the rate limiter. This can be the case when a text (e.g a long URL) is copied and pasted in the UI. > > You are right that we did not think there was any reason to go deep in a > discussion on MTU sizes in RFC 4103. > > Instead we specify the intended use, that is for human input, and human > reading in a real-time conversation. > > The most rapid input I can imagine is from a speech-to-text application, > that maybe can reach 20 characters per second from a rapid speaker. > That is why the maximum required rate to support is specified to be 30 > characters per second. RFC 4103 says that the _default_ value is 30, but where is it said that the _maximum_ is 30? > > The recommended sample time is 300 ms, resulting in sending 3.3 packets per > second when there is text to send. With an even caracter rate, that results > in 9 new characters per packet. > > With the recommended two generations of redundancy, it will mean that 27 > characters are packed in each packet. > > If they are from a language that make use of three UTF-8 bytes per > character, there will be a mean of 81 bytes text per packet. > > Add the IPv4, UDP, RTP and RFC2198 overhead of -say 70 bytes, the packet > size that will be close to maximum is 151 bytes. That is so far from the > maximum MTU size > > This is a maximum. In reality, text is usually entered by typing, resulting > in only 1-4 new characters per packet. > > Even if the reasoning above tells that there is no risk at all for exceeding > the maximum MTU-size, the application should follow a reasonable strategy to > be sure: The application should check so that the maximum MTU is not > exceeded. If there is a risk for that, excess characters should be delayed > and transmitted in next regular packet to transmit. OK, so your answer is that the PMTU must be considered as an implicit maximum character transmission rate, and must override the provided cps if it is higher than the value calculated from the PMTU. Thanks. > > Gunnar > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Marc > Petit-Huguenin > Sent: Saturday, April 18, 2009 5:31 PM > To: avt@ietf.org > Subject: [AVT] Another question on RFC 4103 > > RFC 4103 does not give any advice on what to do when a t140block to send > will create an RTP packet that will exceed the PMTU. Should the PMTU be > considered as an implicit maximum character transmission rate, or should > multiple RTP packets with the same timestamp be sent? (for the latter there > is the additional issue that RFC 2198 does not provide any advice on the > same problem). > > For example let say that the cps is 30 and the PMTU is unknown so > 576 bytes is the maximum IPv4 packet size that can be sent. With 30 cps and > a language that makes use of three bytes per character, the maximum block > size is 900 bytes which is more than the maximum IPv4 packet size without > even counting the overhead. In this case the maximum implicit cps would be > 17 cps. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From abegen@cisco.com Sat Apr 18 14:03:24 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30C123A6C5A; Sat, 18 Apr 2009 14:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.457 X-Spam-Level: X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqpZ+NQ1OcnE; Sat, 18 Apr 2009 14:03:23 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 465593A6988; Sat, 18 Apr 2009 14:03:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,210,1238976000"; d="scan'208";a="288701445" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 18 Apr 2009 21:04:38 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3IL4cDJ004000; Sat, 18 Apr 2009 14:04:38 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3IL4cei021300; Sat, 18 Apr 2009 21:04:38 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Apr 2009 14:04:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sat, 18 Apr 2009 14:03:36 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54091BAA88@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 Thread-Index: AcnAaI0k+CHA6Xe+Sfy0BV96KkoCXgAAB9bA From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 18 Apr 2009 21:04:37.0765 (UTC) FILETIME=[48869B50:01C9C069] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2324; t=1240088678; x=1240952678; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20FW=3A=20New=20Version=20Notification=20for=20dr aft-ietf-fecframe-interleaved-fec-scheme-03=20 |Sender:=20; bh=woGjytyxYttCHrOb85Z2AIIet5IphOG9dp8aMD7Kq5k=; b=sToCP6K2C7RxZ8wckFZmjRXXIjXDNkE64OfOJX7N5uGI98m8v+/8jWxINa +rNvzutU5BM46MhOEhX2FxAnAe1xM+8qxVNtYzWQjiZZX6GJsA2AGwGMRWs/ Q3Xsj3lqoa/GHIDuyyabFjFTQ9y8ns0WfvPGLRW/UNYowJl9SONYQ=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: avt@ietf.org Subject: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 21:03:24 -0000 VGhpcyB1cGRhdGUgYWRkcmVzc2VzIGFsbCB0aGUgY29tbWVudHMgcmVjZWl2ZWQgaW4gdGhlIFdH TEMgcGVyaW9kIGluaXRhdGVkIG9uIEFwcmlsIDFzdC4gSWYgdGhlcmUgYXJlIGZ1cnRoZXIgY29t bWVudHMsIHBsZWFzZSBwb3N0IHRoZW0gc29vbiBhcyB3ZSB3b3VsZCBsaWtlIHRvIG1vdmUgZm9y d2FyZCB3aXRoIHRoaXMgZHJhZnQuDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUtMDMudHh0DQoNCkJS LA0KLWFjYmVnZW4gDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJRVRGIEkt RCBTdWJtaXNzaW9uIFRvb2wgW21haWx0bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmddIA0KU2VudDog U2F0dXJkYXksIEFwcmlsIDE4LCAyMDA5IDE6NTggUE0NClRvOiBBbGkgQy4gQmVnZW4gKGFiZWdl bikNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1mZWNm cmFtZS1pbnRlcmxlYXZlZC1mZWMtc2NoZW1lLTAzIA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUtMDMudHh0IGhhcyBi ZWVuIHN1Y2Nlc3NmdWx5IHN1Ym1pdHRlZCBieSBBbGkgQmVnZW4gYW5kIHBvc3RlZCB0byB0aGUg SUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWlldGYtZmVjZnJhbWUtaW50ZXJs ZWF2ZWQtZmVjLXNjaGVtZQ0KUmV2aXNpb246CSAwMw0KVGl0bGU6CQkgUlRQIFBheWxvYWQgRm9y bWF0IGZvciAxLUQgSW50ZXJsZWF2ZWQgUGFyaXR5IEZFQw0KQ3JlYXRpb25fZGF0ZToJIDIwMDkt MDQtMTgNCldHIElEOgkJIGZlY2ZyYW1lDQpOdW1iZXJfb2ZfcGFnZXM6IDMxDQoNCkFic3RyYWN0 Og0KVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IFJUUCBwYXlsb2FkIGZvcm1hdCBmb3IgdGhl IEZvcndhcmQgRXJyb3INCkNvcnJlY3Rpb24gKEZFQykgdGhhdCBpcyBnZW5lcmF0ZWQgYnkgdGhl IDEtRCBpbnRlcmxlYXZlZCBwYXJpdHkgY29kZQ0KZnJvbSBhIHNvdXJjZSBtZWRpYSBlbmNhcHN1 bGF0ZWQgaW4gUlRQLiAgVGhlIDEtRCBpbnRlcmxlYXZlZCBwYXJpdHkNCmNvZGUgaXMgYSBzeXN0 ZW1hdGljIGNvZGUsIHdoZXJlIGEgbnVtYmVyIG9mIHJlcGFpciBzeW1ib2xzIGFyZQ0KZ2VuZXJh dGVkIGZyb20gYSBzZXQgb2Ygc291cmNlIHN5bWJvbHMgYW5kIHNlbnQgaW4gYSByZXBhaXIgZmxv dw0Kc2VwYXJhdGUgZnJvbSB0aGUgc291cmNlIGZsb3cgdGhhdCBjYXJyaWVzIHRoZSBzb3VyY2Ug c3ltYm9scy4gIFRoZQ0KMS1EIGludGVybGVhdmVkIHBhcml0eSBjb2RlIG9mZmVycyBhIGdvb2Qg cHJvdGVjdGlvbiBhZ2FpbnN0IGJ1cnN0eQ0KcGFja2V0IGxvc3NlcyBhdCBhIGNvc3Qgb2YgZGVj ZW50IGNvbXBsZXhpdHkuICBUaGUgbmV3IHBheWxvYWQgZm9ybWF0DQpkZWZpbmVkIGluIHRoaXMg ZG9jdW1lbnQgaXMgdXNlZCAod2l0aCBzb21lIGV4Y2VwdGlvbnMpIGFzIGEgcGFydCBvZg0KdGhl IERWQiBBcHBsaWNhdGlvbi1sYXllciBGRUMgc3BlY2lmaWNhdGlvbi4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdC4NCg0KDQo= From jeedward@yahoo.com Sun Apr 19 11:35:10 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618883A6F69 for ; Sun, 19 Apr 2009 11:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.391 X-Spam-Level: X-Spam-Status: No, score=-0.391 tagged_above=-999 required=5 tests=[AWL=-1.789, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0oEZ6q75MLE for ; Sun, 19 Apr 2009 11:35:09 -0700 (PDT) Received: from n56a.bullet.mail.sp1.yahoo.com (n56a.bullet.mail.sp1.yahoo.com [98.136.45.3]) by core3.amsl.com (Postfix) with SMTP id 6D06D3A6F66 for ; Sun, 19 Apr 2009 11:35:09 -0700 (PDT) Received: from [216.252.122.217] by n56.bullet.mail.sp1.yahoo.com with NNFMP; 19 Apr 2009 18:36:24 -0000 Received: from [69.147.65.158] by t2.bullet.sp1.yahoo.com with NNFMP; 19 Apr 2009 18:36:24 -0000 Received: from [127.0.0.1] by omp406.mail.sp1.yahoo.com with NNFMP; 19 Apr 2009 18:36:24 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 888859.7151.bm@omp406.mail.sp1.yahoo.com Received: (qmail 6628 invoked by uid 60001); 19 Apr 2009 18:36:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240166184; bh=7lkbL+6q29n0B6xBag3xu8zVkeGOYZUhl5n0mDyi1Tw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=obXvsCJHEkKI+S6/0EYD0Q0D7z/SXCUNSlOLIc2SKapfGCDtWb8Lgevd7lWVrf5EUQ2rocc/98aOJPj8RrsZDtMZJeY3by3MU6ixmm22cP6woxIIqFadNeHzSz2rjOfKW0B/rlIIgs0v9LrhrR5yOy0L0DzFmD3y2X/KyDXQ2us= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=PaXgDmz13yaEGW7VOQnvA5abVw2Ttk5syUBvHGwacoQ9hOOsfPF3Dpp5OPe8wBa9DDQmEpX9gmKwXjxW6MXuFhiyvyfvLYrdJ6VqX7ThoTEK3fyiuxlka8mnB8LPBrHtLWtqiN3AXH1lDfHA66OjPauqhiY3fk/qifRsTHFBKaQ=; Message-ID: <705960.5722.qm@web45901.mail.sp1.yahoo.com> X-YMail-OSG: 2Q886ZcVM1mUYr4UxGMqkgTgdKRqLqcsdyJjJzvO5k_m24eOX1PbYGfeFlyYibP.Cn0CXb07wK8DaONeyCTXeGnoT6LVRqWy34M_2Wpgvd__7qe9.UHe_vyOvSjtHQIYQLj.8i6DWuIAvR5QQ8VUsp94KsXllr4diEi4XTqodW8wN8U_bZ34dJQs6OVNwD2RyfPSymyUks3o08.lfqAyLm1338zkgkSKu1S7eWAFxroHcUcVSdImWlF.cqQ0bjW1YAA3XqTCNg.xFWzmpOAnqwc0HdAYZG9tg8M4VxzSX0NwXxpqWngBJmYtyB777JKs Received: from [67.233.191.18] by web45901.mail.sp1.yahoo.com via HTTP; Sun, 19 Apr 2009 11:36:24 PDT X-Mailer: YahooMailClassic/5.2.18 YahooMailWebService/0.7.289.1 Date: Sun, 19 Apr 2009 11:36:24 -0700 (PDT) From: John Edward To: avt@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1221683748-1240166184=:5722" Subject: [AVT] Extended draft paper submission: HPCNCS-09 call for papers X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 18:35:10 -0000 --0-1221683748-1240166184=:5722 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Extended draft paper submission: HPCNCS-09 call for papers =A0 This Extended Call for Papers for the 2009 International Conference on High= Performance Computing, Networking and Communication Systems (HPCNCS-09) (w= ebsite: http://www.PromoteResearch.org ) is for those who didn't get a chan= ce to submit the papers for the earlier call for papers. The papers receive= d and accepted in response to this extended call for papers will be include= d in the final version of the respective conference proceedings. These proc= eedings will be either ready by the time of the conference (i.e., they will= be available during the conference) or soon after the conference (before t= he end of August 2009), based how fast the proceedings can be prepared.=20 Note: If you have already submitted a paper (whether accepted or rejected o= r currently under review) for MULTICONF-09, please DO NOT submit that paper= again to this extended call for papers.=20 IMPORTANT DATES:=20 Draft paper submission date: May 11, 2009=20 Acceptance/rejection decision: May 21, 2009 Camera ready paper and copyright and pre-registration due: May 28, 2009 Conference dates: July 13-16, 2009 =A0 =A0 HPCNCS-09 will be held during July 13-16 2009 in Orlando, FL, USA. We invit= e draft paper submissions. The conference will take place at the same time = and venue where several other international conferences are taking place. T= he other conferences include: =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Artificial Intellig= ence and Pattern Recognition (AIPR-09)=20 =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Automation, Robotic= s and Control Systems (ARCS-09) =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Bioinformatics, Com= putational Biology, Genomics and Chemoinformatics (BCBGC-09)=20 =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Enterprise Informat= ion Systems and Web Technologies (EISWT-09) =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Information Securit= y and Privacy (ISP-09) =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Recent Advances in = Information Technology and Applications (RAITA-09) =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Software Engineerin= g Theory and Practice (SETP-09)=20 =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Theory and Applicat= ions of Computational Science (TACS-09) =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Theoretical and Mat= hematical Foundations of Computer Science (TMFCS-09) =A0 The website http://www.PromoteResearch.org contains more details. =A0 Sincerely John Edward Publicity committee =A0 =A0 =A0=0A=0A=0A --0-1221683748-1240166184=:5722 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Extended draft paper submission: HPCNC= S-09 call for papers

 

This Extended Call for Papers for the 2009 International Conference on High Performance Computing, Networking an= d Communication Systems (HPCNCS-09) (website: <= /SPAN>http://www.PromoteResearch.org= ) is for those who didn't get a chance to sub= mit the papers for the earlier call for papers. The papers received and acc= epted in response to this extended call for papers will be included in the final version of the resp= ective conference proceedings. These proceedings will be either ready by th= e time of the conference (i.e., they will be available during the conferenc= e) or soon after the conference (before the end of August 2009), based how = fast the proceedings can be prepared.

Note: If you have already submitted = a paper (whether accepted or rejected or currently under review) for MULTIC= ONF-09, please DO NOT submit that paper again to this extended call for pap= ers.


IMPORTANT DATES:

Draft paper submission date: May 11, 2009
Acceptance/re= jection decision: May 21, 2009
Camera ready paper and copyright and pre-= registration due: May 28, 2009
Conference dates: July 13-16, 2009=

 

 

HPCNCS-09 will be held during = July 13-16 2009 in Orlando, FL, USA. We invite draft paper submissions. The= conference will take place at the same time and venue where several other = international conferences are taking place. The other conferences include:<= SPAN style=3D"COLOR: black"><= /DIV>

=B7         <= /FONT>

=B7         =B7         =B7         =B7         =B7         =B7         =B7         =B7          

The website h= ttp://www.PromoteResearch.org contains more details.

 

Sincerely

John Edward

Publicity committee

 

 

 


=0A=0A= =0A=0A --0-1221683748-1240166184=:5722-- From gunnar.hellstrom@omnitor.se Sun Apr 19 14:02:18 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FEA83A6DD6 for ; Sun, 19 Apr 2009 14:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[AWL=-1.045, BAYES_50=0.001, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wgj9UJCpU8t for ; Sun, 19 Apr 2009 14:02:17 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id CAF833A6B2F for ; Sun, 19 Apr 2009 14:02:15 -0700 (PDT) Received: (qmail 72116 invoked from network); 19 Apr 2009 21:03:37 -0000 Received: from s34.loopia.se (HELO s19.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 19 Apr 2009 21:03:37 -0000 Received: (qmail 58886 invoked from network); 19 Apr 2009 21:03:28 -0000 Received: from h16n1fls34o265.telia.com (HELO GunnarH) (gunnar.hellstrom@omnitor.se@[213.64.232.16]) (envelope-sender ) by s19.loopia.se (qmail-ldap-1.03) with SMTP for ; 19 Apr 2009 21:03:28 -0000 From: "Gunnar Hellstrom" To: "'Marc Petit-Huguenin'" References: <49E9F234.7000400@acm.org> <00ad01c9c05c$82028fe0$211ea8c0@GunnarH> <49EA34BC.8080600@acm.org> Date: Sun, 19 Apr 2009 23:03:37 +0200 Message-ID: <003c01c9c132$4f4c0f00$211ea8c0@GunnarH> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcnAYlttjtMan0UsTQakQY0ajQdeWgAAoLdA In-Reply-To: <49EA34BC.8080600@acm.org> Cc: avt@ietf.org Subject: Re: [AVT] Another question on RFC 4103 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 21:02:18 -0000 Marc, See answers inline:=20 Gunnar -----Original Message----- From: Marc Petit-Huguenin [mailto:petithug@acm.org]=20 Sent: Saturday, April 18, 2009 10:15 PM To: Gunnar Hellstrom Cc: avt@ietf.org Subject: Re: [AVT] Another question on RFC 4103 Gunnar Hellstrom wrote: > Marc, > My calculations end up a factor 10 lower than yours. Section 6 of RFC 4103 states that "The [cps] value shall be used as a = mean value over any 10-second internal." So at 30 cps, one can send nothing = for 10 seconds then send a block of 300 characters without triggering the = rate limiter. This can be the case when a text (e.g a long URL) is copied = and pasted in the UI. >=20 > You are right that we did not think there was any reason to go deep in = > a discussion on MTU sizes in RFC 4103. >=20 > Instead we specify the intended use, that is for human input, and=20 > human reading in a real-time conversation. >=20 > The most rapid input I can imagine is from a speech-to-text=20 > application, that maybe can reach 20 characters per second from a = rapid speaker. > That is why the maximum required rate to support is specified to be 30 = > characters per second. RFC 4103 says that the _default_ value is 30, but where is it said that = the _maximum_ is 30? >=20 > The recommended sample time is 300 ms, resulting in sending 3.3=20 > packets per second when there is text to send. With an even caracter=20 > rate, that results in 9 new characters per packet. >=20 > With the recommended two generations of redundancy, it will mean that=20 > 27 characters are packed in each packet. >=20 > If they are from a language that make use of three UTF-8 bytes per=20 > character, there will be a mean of 81 bytes text per packet. >=20 > Add the IPv4, UDP, RTP and RFC2198 overhead of -say 70 bytes, the=20 > packet size that will be close to maximum is 151 bytes. That is so far = > from the maximum MTU size >=20 > This is a maximum. In reality, text is usually entered by typing,=20 > resulting in only 1-4 new characters per packet. >=20 > Even if the reasoning above tells that there is no risk at all for=20 > exceeding the maximum MTU-size, the application should follow a=20 > reasonable strategy to be sure: The application should check so that=20 > the maximum MTU is not exceeded. If there is a risk for that, excess=20 > characters should be delayed and transmitted in next regular packet to transmit. OK, so your answer is that the PMTU must be considered as an implicit maximum character transmission rate, and must override the provided cps = if it is higher than the value calculated from the PMTU. =20 Gunnar -------------- Thanks. >=20 > Gunnar >=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of=20 > Marc Petit-Huguenin > Sent: Saturday, April 18, 2009 5:31 PM > To: avt@ietf.org > Subject: [AVT] Another question on RFC 4103 >=20 > RFC 4103 does not give any advice on what to do when a t140block to=20 > send will create an RTP packet that will exceed the PMTU. Should the=20 > PMTU be considered as an implicit maximum character transmission rate, = > or should multiple RTP packets with the same timestamp be sent? (for=20 > the latter there is the additional issue that RFC 2198 does not=20 > provide any advice on the same problem). >=20 > For example let say that the cps is 30 and the PMTU is unknown so > 576 bytes is the maximum IPv4 packet size that can be sent. With 30=20 > cps and a language that makes use of three bytes per character, the=20 > maximum block size is 900 bytes which is more than the maximum IPv4=20 > packet size without even counting the overhead. In this case the=20 > maximum implicit cps would be > 17 cps. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org __________ NOD32 4018 (20090418) Information __________ Detta meddelande =E4r genoms=F6kt av NOD32 Antivirus. http://www.nod32.com From petithug@acm.org Sun Apr 19 14:58:49 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11FF13A6D32 for ; Sun, 19 Apr 2009 14:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.142 X-Spam-Level: X-Spam-Status: No, score=-102.142 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wE46jN8QzOt for ; Sun, 19 Apr 2009 14:58:48 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 691D03A67D8 for ; Sun, 19 Apr 2009 14:58:48 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 9AC7AFBC401A; Sun, 19 Apr 2009 22:00:01 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 0CCB6FBC4018; Sun, 19 Apr 2009 22:00:00 +0000 (UTC) Message-ID: <49EB9EDD.40306@acm.org> Date: Sun, 19 Apr 2009 14:59:57 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Gunnar Hellstrom References: <49E9F234.7000400@acm.org> <00ad01c9c05c$82028fe0$211ea8c0@GunnarH> <49EA34BC.8080600@acm.org> <003c01c9c132$4f4c0f00$211ea8c0@GunnarH> In-Reply-To: <003c01c9c132$4f4c0f00$211ea8c0@GunnarH> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: avt@ietf.org Subject: Re: [AVT] Another question on RFC 4103 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 21:58:49 -0000 Gunnar Hellstrom wrote: > Marc, > See answers inline: > > Gunnar > -----Original Message----- > From: Marc Petit-Huguenin [mailto:petithug@acm.org] > Sent: Saturday, April 18, 2009 10:15 PM > To: Gunnar Hellstrom > Cc: avt@ietf.org > Subject: Re: [AVT] Another question on RFC 4103 > [...] > OK, so your answer is that the PMTU must be considered as an implicit > maximum character transmission rate, and must override the provided cps if > it is higher than the value calculated from the PMTU. > > that you occasionally reduce the packet interval. Not to zero as you > proposed, because that is not allowed in RTP, but just as much shorter than > 300 ms as you need to get your long text transmitted. > Or do you have any other proposal for how to handle your case? > I am not proposing anything, I am just trying to understand how this is supposed to work. My current understanding is that the cps is an average of the 10 last seconds but that text blocks that creates RTP packets exceeding the path MTU must be smoothed off multiple RTP packets. Thanks. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From spoorthi.ka@globaledgesoft.com Tue Apr 21 01:50:24 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D15F63A6817 for ; Tue, 21 Apr 2009 01:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.254 X-Spam-Level: X-Spam-Status: No, score=0.254 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPM76uscwRGP for ; Tue, 21 Apr 2009 01:50:24 -0700 (PDT) Received: from gesmail.globaledgesoft.com (gesmail.globaledgesoft.com [203.76.137.4]) by core3.amsl.com (Postfix) with ESMTP id ECF333A69CC for ; Tue, 21 Apr 2009 01:50:23 -0700 (PDT) Received: from [172.16.8.111] (unknown [172.16.8.111]) by gesmail.globaledgesoft.com (Postfix) with ESMTP id 2DDB517B423 for ; Tue, 21 Apr 2009 14:21:37 +0530 (IST) Message-ID: <49ED88C5.1010802@globaledgesoft.com> Date: Tue, 21 Apr 2009 14:20:13 +0530 From: Spoorthi User-Agent: Thunderbird 2.0.0.17 (X11/20080914) MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [AVT] Three way and Conference calls X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 08:50:24 -0000 Hi, Plz provide info on Role of RTP/RTCP in three way and conference calls. During a conference call, RTP mixing has to be performed by the endpoints or servers. Plz clarify. Thnx and Rgs, spoorthi From ingemar.s.johansson@ericsson.com Tue Apr 21 05:53:56 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BDBA28C23B for ; Tue, 21 Apr 2009 05:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.619 X-Spam-Level: X-Spam-Status: No, score=-5.619 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIT2quNi-ruU for ; Tue, 21 Apr 2009 05:53:55 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 919AB28C232 for ; Tue, 21 Apr 2009 05:53:50 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 16393210A8; Tue, 21 Apr 2009 14:55:06 +0200 (CEST) X-AuditID: c1b4fb3e-ae78abb000005486-40-49edc229f61d Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 31591218EC; Tue, 21 Apr 2009 14:55:05 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Apr 2009 14:55:04 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Apr 2009 14:55:03 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8CE5B090@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available Thread-Index: AcnCgGOAYtLRTTIdQwOCQbmUqfc+Vw== From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 21 Apr 2009 12:55:04.0832 (UTC) FILETIME=[6421F800:01C9C280] X-Brightmail-Tracker: AAAAAA== Cc: Ingemar Johansson S , versteb@cisco.com Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 12:53:56 -0000 Hi I have read through the updated draft and have a few comments and = requests for your consideration. In general (as I hinted before) I would like this draft to not just = discuss the unicast version of RAMS, instead I would like it to also = incorporate the multicast version into the framework.=20 I have looked into this and I would say that support for the multicast = alternative as described in=20 http://tools.ietf.org/id/draft-johansson-avt-mcast-based-rams-00.txt is fairly straightforward to add to the existing framework, I will = describe in brief below the key additions that I see today. The title of the draft would then become "Rapid Acquisition of Multicast = RTP Sessions". I can offer to add the necessary parts in the document = that describes the multicast based version of RAMS. Packet structure: In the draft, three FMT's are defined for the RAMS R,I and T messages. I = wonder if it would be better to use one just one FMT for this "family" = of messages and use a subtype to define R, I, T (or any other message). = This was also brought up during the break-out session in SF.=20 Also I would consider a version field as well as there is a chance that = things need to be changed in the future and TLV extensions may not solve = all backwards compatibility issues in a satisfactory way (changing = version number should not be too easy though, TLV elements should be the = first choice).=20 With this in mind the first 32 bits may look like: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ver |subtype| flags .... |reserved | = =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In this example 3 bits are used for the version number and 5 bits are = used for the subtype but there may be a better distribution here. The = number of bits for the flags and reserved field depends on the subtype The subtypes would be encoded as RAMS-R =3D 0 RAMS-I =3D 1 RAMS-T =3D 2 Figure 2:=20 A flow diagram that describes the multicast version to be added. Figure 3:=20 A description that describes the multicast version to be added. Section 6.4: Failure cases An alternative to RAMS-T in the multicast version of RAMS is the use of = IGMP-Leave (details about this are needed) Section 7.1 RAMS Request Here the 32 bit header is added (with subtype=3D0) and possibly the = preference and or support of the multicast and the unicast version of = RAMS can be defined in the flags field. The latter is likely needed as = the SDP's are likely only declarative. Section 7.2 RAMS Information Here the 32 bit header is added (with subtype=3D1) and the MSN,S and = Response field is put in the flags field. An additional TLV element is added that includes a multicast address and = possibly other information such as expected delay until the multicast = RAMS starts. This field is mandatory if the multicast address for RAMS = is described in this way. Section 7.2 RAMS Termination Here the 32 bit header is added (with subtype=3D2)=20 Note that RAMS-T may not be needed in the multicast version of RAMS = (T.B.D) Comments to my comments are welcome Regards Ingemar *******************************************=20 Ingemar Johansson=20 Senior Research Engineer, IETF "nethead"=20 EAB/TVP - Multimedia Technologies=20 Ericsson Research Ericsson AB=20 Box 920 S-971 28 Lule=E5, Sweden=20 Tel: +46 (0)10 7143042=20 ECN: 852-43042=20 ECC: 852-19042 Mobile: +46 (0)730 783289=20 Visit http://labs.ericsson.com ! *******************************************=20 From abegen@cisco.com Tue Apr 21 11:27:10 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FA663A68C2 for ; Tue, 21 Apr 2009 11:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.162 X-Spam-Level: X-Spam-Status: No, score=-6.162 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZpoQi8eb+bi for ; Tue, 21 Apr 2009 11:27:09 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 25ED43A67D9 for ; Tue, 21 Apr 2009 11:27:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,225,1238976000"; d="scan'208";a="157289438" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 21 Apr 2009 18:28:25 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3LISPN2032656; Tue, 21 Apr 2009 11:28:25 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3LISPKg005633; Tue, 21 Apr 2009 18:28:25 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Apr 2009 11:28:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Apr 2009 11:28:23 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540924FED8@xmb-sjc-215.amer.cisco.com> In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8CE5B090@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions(RAMS)" available Thread-Index: AcnCgGOAYtLRTTIdQwOCQbmUqfc+VwAKXQPw References: <130EBB38279E9847BAAAE0B8F9905F8CE5B090@esealmw109.eemea.ericsson.se> From: "Ali C. Begen (abegen)" To: "Ingemar Johansson S" , X-OriginalArrivalTime: 21 Apr 2009 18:28:25.0307 (UTC) FILETIME=[F55842B0:01C9C2AE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6799; t=1240338505; x=1241202505; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20New=20draft=20of=20=22Rapid=20A cquisition=20of=20Multicast=20RTP=20Sessions(RAMS)=22=20avai lable |Sender:=20; bh=ZRv6uKtrx0mcJrGV3kkWY1irMoHyZVPM674/WBKkhxQ=; b=NxUGrc8vlTo7q1hUkGjUxeHG3OwIAW4yIE1Ftb4rssN2XFAj2i8Vc5tiTe DylEVKZBpGNntz52ZFI1qXjcAKlAo6goN8jaJ8p+0O1RRV1/0BZ7WG83/LMe IHLvIRHgI2OPrvlMbBO38bowBu20s52t+R8UMahr8L9kH50hMqJZM=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "Bill Ver Steeg \(versteb\)" Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions(RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 18:27:10 -0000 Hi Ingemar,=20 > Hi >=20 > I have read through the updated draft and have a few comments=20 > and requests for your consideration. Thanks for the review. =20 > In general (as I hinted before) I would like this draft to=20 > not just discuss the unicast version of RAMS, instead I would=20 > like it to also incorporate the multicast version into the framework.=20 While I see the common goal for these two methods, I believe the one you = proposed is an additional enhancement on the unicast approach. Regarding = whether they need to be combined or not, I have some comments below. > I have looked into this and I would say that support for the=20 > multicast alternative as described in=20 > http://tools.ietf.org/id/draft-johansson-avt-mcast-based-rams-00.txt > is fairly straightforward to add to the existing framework, I=20 > will describe in brief below the key additions that I see today. I would not say it would be "fairly straighforward." To make the = multicast bursting effective, many parameters need to be adjusted = properly and optimized. Ow, it can easily degrade the performance even = at the expense of additional complexity. A concern I have which is not addressed in your document is that to make = the proposal make sense, Td needs to be small enough. But, to ensure = that all receivers join the burst mcast session before the burst starts, = Td cannot be very small and RS should not admit last-minute RAMS = requests for that multicast burst (they need to wait for the next = batch). This is because if some receivers miss the first few packets of = the burst, their acquisition will fail. Also, how many clients can the = retransmission server aggregate in a single burst batch in a practical = scenario? The eligible requests should be received within +/- a few = hundereds of milliseconds. How practical is this, I wonder. The selection of a common burst bitrate is also critical. If everybody = supports a different burst bitrate and there is a large variation, = multicast bursting will perform poorly for the well-connected clients. = One solution could be to include the receivers with an available bw that = is smaller than R1 and larger than R2 in the multicast pool. The very = fast and very slow receivers should be still served via unicast. My personal view is that the multicast bursting proposal will be a nice = solution when the issues above (and possible others) are addressed, = however, I think it should be a separate draft that normatively = references the unicast draft. This way, we can keep the unicast draft = more focused. > The title of the draft would then become "Rapid Acquisition=20 > of Multicast RTP Sessions". I can offer to add the necessary=20 > parts in the document that describes the multicast based=20 > version of RAMS. >=20 > Packet structure: > In the draft, three FMT's are defined for the RAMS R,I and T=20 > messages. I wonder if it would be better to use one just one=20 > FMT for this "family" of messages and use a subtype to define=20 > R, I, T (or any other message). This was also brought up=20 > during the break-out session in SF.=20 This was indeed a good recommendation and we already took that into = account, but we did not want to modify the packet formats too much to = avoid any confusion in this version. If you look at the open items = section, it is already there. > Also I would consider a version field as well as there is a=20 > chance that things need to be changed in the future and TLV=20 > extensions may not solve all backwards compatibility issues=20 > in a satisfactory way (changing version number should not be=20 > too easy though, TLV elements should be the first choice).=20 In a later version, the meanings of the mandatory fields would not = change and TLVs are optional anyway. So, why do you think new TLVs would = not give you what you want? Not that I am against using a version field, = but I would rather see a need for it. > With this in mind the first 32 bits may look like: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ver |subtype| flags .... |reserved =20 > | =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > In this example 3 bits are used for the version number and 5=20 > bits are used for the subtype but there may be a better=20 > distribution here. The number of bits for the flags and=20 > reserved field depends on the subtype > The subtypes would be encoded as > RAMS-R =3D 0 > RAMS-I =3D 1 > RAMS-T =3D 2 >=20 >=20 > Figure 2:=20 > A flow diagram that describes the multicast version to be added. >=20 > Figure 3:=20 > A description that describes the multicast version to be added. >=20 > Section 6.4: Failure cases > An alternative to RAMS-T in the multicast version of RAMS is=20 > the use of IGMP-Leave (details about this are needed) >=20 > Section 7.1 RAMS Request > Here the 32 bit header is added (with subtype=3D0) and possibly=20 > the preference and or support of the multicast and the=20 > unicast version of RAMS can be defined in the flags field.=20 > The latter is likely needed as the SDP's are likely only declarative. > > Section 7.2 RAMS Information > Here the 32 bit header is added (with subtype=3D1) and the=20 > MSN,S and Response field is put in the flags field. > An additional TLV element is added that includes a multicast=20 > address and possibly other information such as expected delay=20 > until the multicast RAMS starts. This field is mandatory if=20 > the multicast address for RAMS is described in this way. >=20 > Section 7.2 RAMS Termination > Here the 32 bit header is added (with subtype=3D2)=20 > Note that RAMS-T may not be needed in the multicast version=20 > of RAMS (T.B.D) These could be all addressed if/when we decide to combine the mcast = bursting support. Thanks again for the detail review. BR, -acbegen =20 > Comments to my comments are welcome > Regards > Ingemar > *******************************************=20 > Ingemar Johansson=20 > Senior Research Engineer, IETF "nethead"=20 > EAB/TVP - Multimedia Technologies=20 > Ericsson Research Ericsson AB=20 > Box 920 S-971 28 Lule=E5, Sweden=20 > Tel: +46 (0)10 7143042=20 > ECN: 852-43042=20 > ECC: 852-19042 > Mobile: +46 (0)730 783289=20 > Visit http://labs.ericsson.com ! > *******************************************=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt >=20 From br@brianrosen.net Tue Apr 21 14:01:52 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 924183A6E59 for ; Tue, 21 Apr 2009 14:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSQXDxHX9h8Y for ; Tue, 21 Apr 2009 14:01:51 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id BC7683A6C61 for ; Tue, 21 Apr 2009 14:01:51 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LwK39-0007yi-5w; Tue, 21 Apr 2009 12:46:27 -0500 From: "Brian Rosen" To: "'Spoorthi'" , References: <49ED88C5.1010802@globaledgesoft.com> In-Reply-To: <49ED88C5.1010802@globaledgesoft.com> Date: Tue, 21 Apr 2009 13:46:34 -0400 Message-ID: <013401c9c2a9$1f1c74f0$5d555ed0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnCXmL5gAO6GUT4RBuNk708aMOqYQASfOoQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [AVT] Three way and Conference calls X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 21:01:52 -0000 RTP and RTPC are always used in a single end to end leg. The mixer has a point to point connection with each leg. The mixer can be in an endpoint or in a server. If a phone, for example, can mix a three way, it may simply have point to point RTP connections with the other two parties. If it can't, it may need an external mixer to do that. That mixer would have 3 point to point RTP connections. B S / \ or / | \ A C A B C -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Spoorthi Sent: Tuesday, April 21, 2009 4:50 AM To: avt@ietf.org Subject: [AVT] Three way and Conference calls Hi, Plz provide info on Role of RTP/RTCP in three way and conference calls. During a conference call, RTP mixing has to be performed by the endpoints or servers. Plz clarify. Thnx and Rgs, spoorthi _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From root@core3.amsl.com Wed Apr 22 17:00:02 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 09F203A69B1; Wed, 22 Apr 2009 17:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090423000002.09F203A69B1@core3.amsl.com> Date: Wed, 22 Apr 2009 17:00:02 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtp-rfc3984bis-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 00:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for H.264 Video Author(s) : Y. Wang, et al. Filename : draft-ietf-avt-rtp-rfc3984bis-05.txt Pages : 97 Date : 2009-04-22 This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec, excluding the Scalable Video Coding (SVC) extension and the Multivew Video Coding extension, for which the RTP payload formats are defined elsewhere. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bit-rate conversational usage, to Internet video streaming with interleaved transmission, to high bit-rate video-on-demand. This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized in section 18. Issues on backward compatibility to RFC 3984 are discussed in section 17. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-rfc3984bis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-rtp-rfc3984bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-22165850.I-D@ietf.org> --NextPart-- From yekuiwang@huawei.com Wed Apr 22 18:04:12 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0A663A6C65 for ; Wed, 22 Apr 2009 18:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPSLHE+Hf0rQ for ; Wed, 22 Apr 2009 18:04:12 -0700 (PDT) Received: from mail.globalsuite.net (mail.globalsuite.net [69.46.103.200]) by core3.amsl.com (Postfix) with SMTP id 0AF463A67AE for ; Wed, 22 Apr 2009 18:04:11 -0700 (PDT) X-AuditID: c0a8013c-a7b79bb000000c10-c2-49efbed7005f Received: from W90946 (rrcs-67-53-223-2.west.biz.rr.com [67.53.223.2]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 3C175558003 for ; Wed, 22 Apr 2009 19:05:27 -0600 (MDT) From: "Ye-Kui Wang" To: References: <20090423000002.09F203A69B1@core3.amsl.com> Date: Wed, 22 Apr 2009 21:05:15 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnDpzhneBOfy3c3Qf6umDGDAsKD5AABnLeg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <20090423000002.09F203A69B1@core3.amsl.com> X-Brightmail-Tracker: AAAAAg6CO1QOgkFm Subject: Re: [AVT] I-D Action:draft-ietf-avt-rtp-rfc3984bis-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 01:04:13 -0000 The changes compared to -04 include the change of SDP reference from RFC 2327 to RFC 4566, as well as some purely editorial changes, all suggested by Tom Taylor. Many thanks to Tom! BR, YK > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Wednesday, April 22, 2009 8:00 PM > To: i-d-announce@ietf.org > Cc: avt@ietf.org > Subject: [AVT] I-D Action:draft-ietf-avt-rtp-rfc3984bis-05.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport > Working Group of the IETF. > > > Title : RTP Payload Format for H.264 Video > Author(s) : Y. Wang, et al. > Filename : draft-ietf-avt-rtp-rfc3984bis-05.txt > Pages : 97 > Date : 2009-04-22 > > This memo describes an RTP Payload format for the ITU-T > Recommendation H.264 video codec and the technically > identical ISO/IEC International Standard 14496-10 video > codec, excluding the Scalable Video Coding (SVC) extension > and the Multivew Video Coding extension, for which the RTP > payload formats are defined elsewhere. > The RTP payload format allows for packetization of one or > more Network Abstraction Layer Units (NALUs), produced by an > H.264 video encoder, in each RTP payload. The payload format > has wide applicability, as it supports applications from > simple low bit-rate conversational usage, to Internet video > streaming with interleaved transmission, to high bit-rate > video-on-demand. > > This memo obsoletes RFC 3984. Changes from RFC 3984 are > summarized in section 18. Issues on backward compatibility > to RFC 3984 are discussed in section 17. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-rfc3984 > bis-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail > reader implementation to automatically retrieve the ASCII > version of the Internet-Draft. > From timur.friedman@gmail.com Wed Apr 22 20:31:14 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 270503A67AE for ; Wed, 22 Apr 2009 20:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3t0u4n7l7h2c for ; Wed, 22 Apr 2009 20:31:13 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id 4FB4D3A6E08 for ; Wed, 22 Apr 2009 20:30:46 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so433747yxb.49 for ; Wed, 22 Apr 2009 20:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=QFU+LJKB3uLU1jSP9jVb8+8sXRz+gmHFsYaDJ2w2u0c=; b=CyHKxyydJzhWR7Ak1JY2LihJnQTGI2IHCKpE37nu7Gb0uZVpCOPwfQ+1gj/3zEPlPj zpQbL0sjHjveZs5HXCzsMUfcg4yITYI5MCcbvuh+ikxqDb+jVAhbg2H3tL1RnQ9EEjsI WoRLtY2lc/3D9FLFhfCsso6A0TuzvQlaUt0dM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; b=umc1cAwX1x3rkhdMPDGm2H/ffZNXIogYrGSpxVaKJr59KaXD0WI3k6NYUSMbU2tuR+ ekFQ413oJCyMZRmp+yG177nld9jtgffUbeMeRx50EeRL4gspmhTE/fSIM9t28dtBBGVA Poz5MMVrW8Zc5ClUrfgtKcxkNce+VEbhdOvpk= MIME-Version: 1.0 Sender: timur.friedman@gmail.com Received: by 10.90.66.14 with SMTP id o14mr579296aga.106.1240457523344; Wed, 22 Apr 2009 20:32:03 -0700 (PDT) From: Timur Friedman Date: Wed, 22 Apr 2009 20:31:48 -0700 X-Google-Sender-Auth: 3d8528e472a2985c Message-ID: <5ef5d7280904222031te6b6570r2760491dafee65f@mail.gmail.com> To: avt@ietf.org Content-Type: multipart/alternative; boundary=001636163c5f09cf0f0468308698 Cc: Ramon Caceres Subject: [AVT] misleading RFC 3611 statement on RTCP packet stacking X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 03:52:27 -0000 --001636163c5f09cf0f0468308698 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Some people are reading RFC 3611 as overriding RFC 3550 on RTCP packet stacking. This is what Sec. 1.1 of RFC 3611 says: "XR packets supplement the existing RTCP packets, and may be stacked with other RTCP packets to form compound RTCP packets [9, Section 6]." Reference 9 is RFC 3550, which says: "all RTCP packets MUST be sent in a compound packet of at least two individual packets" That is, RFC 3550 says that RTCP packets MUST be stacked into a compound packet, and some people are reading RFC 3611 as weakening that mandate to say only that RTCP packets MAY be stacked into a compound packet (but also MAY NOT, at least in the case of the XR packet). As one of the authors of RFC 3611, I can say that it was not my intention t= o override RFC 3550. Nor was it the intention of the two of my eight co-authors who I have discussed this with. Rather, the purpose of this sentence was to remind the reader that XR packets, like any RTCP packets, are designed to be stacked, and to helpfully point the reader to the RFC 3550 section that deals with RTCP packet stacking for further details. To the best of my recollection, no discussion in AVT leading up to approval of RFC 3611 indicates that any group participants at the time believed that RFC 3611 would override RFC 3550 on RTCP packet stacking. Still, I understand how people are reading RFC 3611 in this way. It does sa= y "may be stacked", and though "may" is not capitalized, it is nonetheless an RFC 2119 keyword, meaning that the item is truly optional. Co-authors Nick Duffield, Ramon Caceres, and myself would like to open discussion on how to address this situation. We start by suggesting that we file an RFC Errata report, indicating that the sentence should read instead= : =93XR packets supplement the existing RTCP packets, and stack with other RT= CP packets to form compound RTCP packets, as described in Sec. 6 of RFC 3550 [9].=94 By dropping the "may", we drop any hint that this RFC overrides the RFC 355= 0 stacking mandate. And by adding "as described in Sec. 6 of RFC 3550" we mak= e clear the informational nature of this sentence. Timur Friedman --001636163c5f09cf0f0468308698 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Some people are reading RFC 3611 as overriding RFC 3550 on RTCP packet stac= king.

This is what Sec. 1.1 of RFC 3611 says:

"XR packet= s supplement the existing RTCP packets, and may be stacked with other RTCP packets to form compound RTCP packets [9, Section 6]."=

Reference 9 is RFC 3550, which says:

"all RTCP packets = MUST be sent in a compound packet of at least two individual packets"<= br>
That is, RFC 3550 says that RTCP packets MUST be stacked into a compoun= d packet, and some people are reading RFC 3611 as weakening that mandate to= say only that RTCP packets MAY be stacked into a compound packet (but also= MAY NOT, at least in the case of the XR packet).

As one of the authors of RFC 3611, I can say that it was not my intenti= on to override RFC 3550. Nor was it the intention of the two of my eight co= -authors who I have discussed this with. Rather, the purpose of this senten= ce was to remind the reader that XR packets, like any RTCP packets, are des= igned to be stacked, and to helpfully point the reader to the RFC 3550 sect= ion that deals with RTCP packet stacking for further details.

To the best of my recollection, no discussion in AVT leading up to appr= oval of RFC 3611 indicates that any group participants at the time believed= that RFC 3611 would override RFC 3550 on RTCP packet stacking.

Still, I understand how people are reading RFC 3611 in this way. It does sa= y "may be stacked", and though "may" is not capitalized= , it is nonetheless an RFC 2119 keyword, meaning that the item is truly opt= ional.

Co-authors Nick Duffield, Ramon Caceres, and myself would like to open = discussion on how to address this situation. We start by suggesting that we= file an RFC Errata report, indicating that the sentence should read instea= d:

=93XR packets supplement the existing RTCP packets, and stack with other RTCP packets to form compound RTCP packets, as described in Sec. 6 of RFC 3550 [9].=94

By dropping the "may", we drop any hint that = this RFC overrides the RFC 3550 stacking mandate. And by adding "as de= scribed in Sec. 6 of RFC 3550" we make clear the informational nature = of this sentence.

Timur Friedman

--001636163c5f09cf0f0468308698-- From rjesup@wgate.com Thu Apr 23 08:42:44 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDF8928C687 for ; Thu, 23 Apr 2009 08:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aohLXRsseJCb for ; Thu, 23 Apr 2009 08:42:44 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id 15CDA28C682 for ; Thu, 23 Apr 2009 08:42:44 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Apr 2009 11:44:01 -0400 To: "Brian Rosen" References: <49ED88C5.1010802@globaledgesoft.com> <013401c9c2a9$1f1c74f0$5d555ed0$@net> From: Randell Jesup Date: Thu, 23 Apr 2009 11:45:18 -0400 In-Reply-To: <013401c9c2a9$1f1c74f0$5d555ed0$@net> (Brian Rosen's message of "Tue\, 21 Apr 2009 13\:46\:34 -0400") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 23 Apr 2009 15:44:01.0839 (UTC) FILETIME=[5315FBF0:01C9C42A] Cc: avt@ietf.org Subject: Re: [AVT] Three way and Conference calls X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 15:42:45 -0000 "Brian Rosen" writes: >RTP and RTPC are always used in a single end to end leg. The mixer has a >point to point connection with each leg. The mixer can be in an endpoint or >in a server. If a phone, for example, can mix a three way, it may simply >have point to point RTP connections with the other two parties. If it >can't, it may need an external mixer to do that. That mixer would have 3 >point to point RTP connections. > > > B S > / \ or / | \ > A C A B C There's one other configuration for 3-way and conference calls: B / \ A --- C I.e. a no-central-mixer solution, or an "all to all media" topology as defined in RFC 5117. Each endpoint would be responsible for doing it's own mixing as needed, and the upstream and downstream bandwidth of A and C (for the first diagram above) and A, B and C (for the second diagram) would be roughly doubled compared to a mixer solution. A & C (or A, B and C) also probably need to be capable enough to decode two incoming streams, though they could implement a hard switch behavior (instead of mixing) and only decode one stream at a time. This configuration isn't often used in the unicast world, I believe; it fits better in a multicast world where the upstream bandwidth of A & C (or A, B & C) wouldn't have to increase. Also, as you add more participants, the bandwidth and processing multiplication effect quickly will cause problems. >-----Original Message----- >Plz provide info on Role of RTP/RTCP in three way and conference calls. >During a conference call, RTP mixing has to be performed by the >endpoints or servers. Plz clarify. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From root@core3.amsl.com Thu Apr 23 15:45:01 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 67BED3A6E7F; Thu, 23 Apr 2009 15:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090423224501.67BED3A6E7F@core3.amsl.com> Date: Thu, 23 Apr 2009 15:45:01 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-seed-srtp-11.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 22:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : The SEED Cipher Algorithm and Its Use with the Secure Real-time Transport Protocol (SRTP Author(s) : S. Yoon, H. Park, J. Kim, H. Jeong, Y. Won Filename : draft-ietf-avt-seed-srtp-11.txt Pages : 12 Date : 2009-4-23 This document describes the use of the SEED block cipher algorithm in the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for the Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-seed-srtp-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-seed-srtp-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-4-23153042.I-D@ietf.org> --NextPart-- From ron.even.tlv@gmail.com Fri Apr 24 00:04:23 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FDC328C729 for ; Fri, 24 Apr 2009 00:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gE0ZDLJDhdT4 for ; Fri, 24 Apr 2009 00:04:22 -0700 (PDT) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.189]) by core3.amsl.com (Postfix) with ESMTP id 4E12A28C725 for ; Fri, 24 Apr 2009 00:04:22 -0700 (PDT) Received: by mu-out-0910.google.com with SMTP id w1so165842mue.9 for ; Fri, 24 Apr 2009 00:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=fOoB/VzbVQuX44VWDWr8peAEVdnoktqYyMpbXC4SEpo=; b=OMTUiMwXoO0zwaxy9UGTCxyCSvjYN1vSYY4sNyotdBZZy8Mvb98Gx4DNybAcf6KT2a mNau1WJDym4sdpbIfmzKBIUrq5P6tN3ITHH7wEM/XTvG/BfxIjXP7FFt0LIgbx+UVbVo Nt/aKfHXpIilFSSd06maM4k8zKjyPvXoFuJp0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=led1pR+0YXAeP0dlr/0xS4pb2YH75+zQ2pGYdbUYy+N0NuYEueuJ4NxETuQztLDYfb iTLK7MQmJG74wBT1r1I5TS07owOtClaADIpj8vEDIyPchv24JCdywaXQ0AW/rF/DBcuL tNozkbM0MXHpJFQ+GsdWPYXILTr1KQicd5Qu8= Received: by 10.103.193.12 with SMTP id v12mr1104717mup.23.1240556740159; Fri, 24 Apr 2009 00:05:40 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-121-32.red.bezeqint.net [79.179.121.32]) by mx.google.com with ESMTPS id j6sm2165251mue.1.2009.04.24.00.05.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 24 Apr 2009 00:05:39 -0700 (PDT) From: "Roni Even" To: "'Spoorthi'" , References: <49ED88C5.1010802@globaledgesoft.com> In-Reply-To: <49ED88C5.1010802@globaledgesoft.com> Date: Fri, 24 Apr 2009 10:03:52 +0300 Message-ID: <49f164c3.06a1660a.2f06.6870@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnCXmq5vGmWuAP7RLWEjAAxXsRyJwCTDe/A Content-Language: en-us Subject: Re: [AVT] Three way and Conference calls X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 07:04:23 -0000 Hi, You should look at http://tools.ietf.org/html/rfc5117 that discuss the different RTP topologies. Still you can always do a full mesh and let every endpoint mix the streams. Roni Even -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Spoorthi Sent: Tuesday, April 21, 2009 11:50 AM To: avt@ietf.org Subject: [AVT] Three way and Conference calls Hi, Plz provide info on Role of RTP/RTCP in three way and conference calls. During a conference call, RTP mixing has to be performed by the endpoints or servers. Plz clarify. Thnx and Rgs, spoorthi _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From spoorthi.ka@globaledgesoft.com Fri Apr 24 02:54:07 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E81B93A72D1 for ; Fri, 24 Apr 2009 02:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.676 X-Spam-Level: X-Spam-Status: No, score=-0.676 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuCMvcXvKKSr for ; Fri, 24 Apr 2009 02:54:07 -0700 (PDT) Received: from gesmail.globaledgesoft.com (gesmail.globaledgesoft.com [203.76.137.4]) by core3.amsl.com (Postfix) with ESMTP id 09A413A67CF for ; Fri, 24 Apr 2009 02:54:07 -0700 (PDT) Received: from [172.16.8.111] (unknown [172.16.8.111]) by gesmail.globaledgesoft.com (Postfix) with ESMTP id B1FCF17B425; Fri, 24 Apr 2009 15:25:22 +0530 (IST) Message-ID: <49F18C32.9050601@globaledgesoft.com> Date: Fri, 24 Apr 2009 15:23:54 +0530 From: Spoorthi User-Agent: Thunderbird 2.0.0.17 (X11/20080914) MIME-Version: 1.0 To: Brian Rosen References: <49ED88C5.1010802@globaledgesoft.com> <013401c9c2a9$1f1c74f0$5d555ed0$@net> In-Reply-To: <013401c9c2a9$1f1c74f0$5d555ed0$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: avt@ietf.org Subject: Re: [AVT] Three way and Conference calls X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 09:54:08 -0000 A endpoint involved a three way call will have point to point RTP connections with the other two parties as shown below * B / \ A C * Now, the endpoint the 'B' has to mix the audio received from the endpoint 'A' and transmit the same to endpoint 'C'. The endpoint 'B' has to mix the audio received from the endpoint 'C' and transmit the same to endpoint 'A'. To perform the mixing should the endpoint B deployed with a mixer or endpoint B has to do the audio mixing??? Plz clarify... Thnx and Rgs, spoorthi Brian Rosen wrote: > RTP and RTPC are always used in a single end to end leg. The mixer has a > point to point connection with each leg. The mixer can be in an endpoint or > in a server. If a phone, for example, can mix a three way, it may simply > have point to point RTP connections with the other two parties. If it > can't, it may need an external mixer to do that. That mixer would have 3 > point to point RTP connections. > > > B S > / \ or / | \ > A C A B C > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Spoorthi > Sent: Tuesday, April 21, 2009 4:50 AM > To: avt@ietf.org > Subject: [AVT] Three way and Conference calls > > Hi, > > Plz provide info on Role of RTP/RTCP in three way and conference calls. > During a conference call, RTP mixing has to be performed by the > endpoints or servers. Plz clarify. > > Thnx and Rgs, > spoorthi > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > From tendyntu@huawei.com Fri Apr 24 03:03:42 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1554A3A73AB for ; Fri, 24 Apr 2009 03:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.055 X-Spam-Level: X-Spam-Status: No, score=0.055 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KptIXjvtjaeo for ; Fri, 24 Apr 2009 03:03:41 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 5EE2628C72B for ; Fri, 24 Apr 2009 03:01:48 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIL00BQHNWWDN@szxga03-in.huawei.com> for avt@ietf.org; Fri, 24 Apr 2009 18:02:56 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIL002UFNWWQ3@szxga03-in.huawei.com> for avt@ietf.org; Fri, 24 Apr 2009 18:02:56 +0800 (CST) Received: from z61302 ([10.85.208.250]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIL001GCNWV0Q@szxml04-in.huawei.com> for avt@ietf.org; Fri, 24 Apr 2009 18:02:56 +0800 (CST) Date: Fri, 24 Apr 2009 18:02:54 +0800 From: Zou ZiXuan In-reply-to: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> To: "'Bill Ver Steeg (versteb)'" , avt@ietf.org Message-id: <014601c9c4c3$d6c56fa0$84504ee0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_+q1C1BhzvFLn4e5+OZXtnw)" Content-language: zh-cn Thread-index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGCYQgQ References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 10:03:42 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à²¿·ÖÓʼþ¡£ --Boundary_(ID_+q1C1BhzvFLn4e5+OZXtnw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, The burst duration (8 octets) in RAMS-I message is in a single RTP ticks. And I note that from draft-01 on, the solution is payload-independent (is my understanding correct?). So, for non-MEPG2-TS payload, for example, H.264-NAL where audio and video content are encapsulated separately in two RTP streams with different ticks, does the duration indicated by this single ticks still work? Which stream does this tick belong to? From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Bill Ver Steeg (versteb) Sent: Friday, April 17, 2009 12:39 AM To: avt@ietf.org Subject: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available There is a new draft of the "Rapid Acquisition of Multicast RTP Sessions (RAMS)" draft available at http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-synchroniza tion-for-rtp-03.txt We have incorporated the changes from the technical breakout session in San Francisco. The major changes in this version of the draft include 1- Changing the document title to avoid confusion with other ongoing "synchronization" drafts 2- changing the message names to reflect the title change 3- clarification of the RTCP message semantics, including changes to the "Request" and "Inform" messages 4- additional description/motivation for the various message flows has been added 5- RTP/RTCP muxing has been added We hope to make this a Working Group item, and will change the name of the draft to avoid conflicts with other "synchronization" drafts at that time. Bill VerSteeg --Boundary_(ID_+q1C1BhzvFLn4e5+OZXtnw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

         The burst duration (8 octets) in RAMS-I message is in a single RTP ticks. And I note that from draft-01 on, the solution is payload-independent (is my understanding correct?). So, for non-MEPG2-TS payload, for example, H.264-NAL where audio and video content are encapsulated separately in two RTP streams with different ticks, does the duration indicated by this single ticks still work? Which stream does this tick belong to?

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Bill Ver Steeg (versteb)
Sent: Friday, April 17, 2009 12:39 AM
To: avt@ietf.org
Subject: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available

 

There is a new draft of the "Rapid Acquisition of Multicast RTP Sessions (RAMS)" draft available at http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt

 

We have incorporated the changes from the technical breakout session in San Francisco. The major changes in this version of the draft include

1- Changing the document title to avoid confusion with other ongoing "synchronization" drafts

2- changing the message names to reflect the title change

3- clarification of the RTCP message semantics, including changes to the "Request" and "Inform" messages

4- additional description/motivation for the various message flows has been added

5- RTP/RTCP muxing has been added

 

 

We hope to make this a Working Group item, and will change the name of the draft to avoid conflicts with other "synchronization" drafts at that time.

 

Bill VerSteeg

 

 

--Boundary_(ID_+q1C1BhzvFLn4e5+OZXtnw)-- From Tom.Van_Caenegem@alcatel-lucent.be Fri Apr 24 03:35:19 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84F5B3A68AD for ; Fri, 24 Apr 2009 03:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.373 X-Spam-Level: X-Spam-Status: No, score=-5.373 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9eZVEoectKW for ; Fri, 24 Apr 2009 03:35:11 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 468E33A6EC0 for ; Fri, 24 Apr 2009 03:35:11 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3OAaRNw008645 for ; Fri, 24 Apr 2009 12:36:27 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Apr 2009 12:36:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C4C8.85DD0C88" Date: Fri, 24 Apr 2009 12:36:26 +0200 Message-ID: <238382595265324EA50F6134BB42DCAF03B18B96@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multiple Feedback Targets in " http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18" Thread-Index: AcnEyIV3JVxE1pVAQlWyD4mzx47lUg== From: "VAN CAENEGEM Tom" To: X-OriginalArrivalTime: 24 Apr 2009 10:36:27.0750 (UTC) FILETIME=[86013860:01C9C4C8] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: [AVT] Multiple Feedback Targets in " http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18" X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 10:35:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C4C8.85DD0C88 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have two questions/comments mostly regarding the RTCP-SSM draft (http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18). The background of my questions is the use case of "broadcast channels" in an IPTV context, where the channels are distributed over IP multicast (SSM). In this context, the concept of feedback target(s) is obviously very useful, and actually necessary given today's restrictions with multicast in upstream in the "WAN".=20 For the IPTV use case, it also makes sense to have multiple feedback targets, each responsible for a subset of RTP receivers, because of the large number of RTP receivers involved (100.000s is possible). The way to signal this by means of SDP is that each local subset of RTP receivers sees a different IP address in the "a=3Drtcp: "portnumber" IN IP4 "IP address" line. So, multiple "localised" FT is covered by the draft IMO. However, in that case, the maximum bandwidth that can be used for RTCP reporting by RTP receivers only needs to be determined by the size of the local group of RTP receivers (sending RTCP to the same localised Feedback Target), especially in the summary FB model. But in my interpretation of the architecture, the actual RTCP bandwith limit information can only be retrieved by the RTP receivers from the information sent by the distribution source in the ssm session. Either by refected RTCP reports from RTP receivers (not a feasible solution for the given use case) or from a RSI message -in the summary FB model- indicating the session size or explicitly the RTCP reporting bandwidth limit. The fact is that this information is sent to ALL RTP receivers, which may be reporting to different Feedback targets where each Feedback target is collecting RTCP messages from a different number of RTP receivers, and hence may have different "requirements" for total RTCP reporting bandwidth limit. My question is whether local Feedback targets have been considered with respect to this issue? My second question again has to do with multiple feedback targets for the same use case.=20 In the IPTV use case for rtcpssm, Feedback Targets can also be used as retransmission sources (RFC 4588) and in http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for- rtp-03, the feedback target architecture is used to allow fast acquisition of SSM RTP sessions. The draft proposes that a "burst source" is co-located with the FT which transmits unicast data (starting with a random access point of the video channel) from a cache that holds the most recent data distributed over the RTP SSM. It does transmit the RTP packets at an accelerated speed, allowing the RTP receiver to join the SSM after some time. The idea I would like to bring forward is to allow separate Feedback Targets for the same RTP receiver (population): one Feedback target acts as RTP retransmission server (see http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for- rtp-03) and collects RTCP FB messages, while the other Feedback Target is solely "responsible" for the non RTCP-FB messages, such as RTCP XR messages. I realise this idea is not necessarily linked with the rtcp-ssm draft, but IMO only for a massive scale application that makes use of RTP and leverages rtcp ssm such a separation is justified. The possibility for separation of the monitoring service -associated with a server function basically responsible for collecting RTCP receiver reports for the purpose of monitoring- and the retransmission service requiring a server function that is responsible for processing and responding to RTCP FB messages, is driven from the point of view of server function optimisation (different requirements on the server platform).=20 In terms of signaling two Feedback Targets, we could make use of the following lines: a=3Drtcp:40001 IN IP4 192.0.2.1 (This is for retransmission) a=3Drtcp-fb:96 nack a=3Drtcp:40001 IN IP4 192.0.2.2 (This is for XR collection) However, that is probably quite ambiguous..? Furthermore I also realise such a solution introduces other questions than just signaling syntax including the fact that we may need guiding rules on how RTCP reports are issued by the RTP receiver with two RTCP targets in place, as in the example above. The new RFC 5506 is certainly helpful here, but this is probably not sufficient.=20 Comments appreciated on this idea. Kind regards, Tom Van Caenegem =20 ------_=_NextPart_001_01C9C4C8.85DD0C88 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Multiple Feedback Targets in " = http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18"

Hi,

I have two = questions/comments mostly regarding the RTCP-SSM draft (http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18). = The background of my questions is the use case of "broadcast = channels" in an IPTV context, where the channels are distributed = over IP multicast (SSM). In this context, the concept of feedback = target(s) is obviously very useful, and actually necessary given today's = restrictions with multicast in upstream in the "WAN". =

For the IPTV use = case, it also makes sense to have multiple feedback targets, each = responsible for a subset of RTP receivers, because of the large number = of RTP receivers involved (100.000s is possible). The way to signal this = by means of SDP is that each local subset of RTP receivers sees a = different IP address in the "a=3Drtcp: = "portnumber" IN IP4 "IP = address"  line.  So, multiple "localised" FT  = is covered by the draft IMO.

However, in that = case, the maximum bandwidth that can be used for RTCP reporting by RTP = receivers only needs to be determined by the size of the local group of = RTP receivers (sending RTCP to the same localised Feedback Target), = especially in the summary FB model. But in my interpretation of the = architecture, the actual RTCP bandwith limit information can only be = retrieved by the RTP receivers from the information sent by the = distribution source in the ssm session. Either by refected RTCP reports = from RTP receivers (not a feasible solution for the given use case) or = from a RSI message -in the summary FB model- indicating the session size = or explicitly the RTCP reporting bandwidth limit. The fact is that this = information is sent to ALL RTP receivers, which may be reporting to = different Feedback targets where each Feedback target is collecting RTCP = messages from a different number of RTP receivers, and hence may have = different "requirements" for total RTCP reporting bandwidth = limit.  My question is whether local Feedback targets have been = considered with respect to this issue?

My second question = again has to do with multiple feedback targets for the same use case. =

In the IPTV use = case for rtcpssm, Feedback Targets can also be used as retransmission = sources (RFC 4588) and in http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchr= onization-for-rtp-03, the feedback target architecture is used to = allow fast acquisition of SSM RTP sessions. The draft proposes = that  a "burst source" is co-located with the FT which = transmits unicast data (starting with a random access point of the video = channel) from a cache that holds the most recent data distributed over = the RTP SSM. It does transmit the RTP packets at an accelerated speed, = allowing the RTP receiver to join the SSM after some = time.

The idea I would = like to bring forward is to allow separate Feedback Targets  for = the same RTP receiver (population): one Feedback target acts as RTP = retransmission server (see http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchr= onization-for-rtp-03) and collects RTCP FB messages, while the other = Feedback Target is solely "responsible" for the non RTCP-FB = messages, such as RTCP XR messages. = I realise this idea is not necessarily linked with  the rtcp-ssm = draft, but IMO only for a massive scale application that makes use of = RTP and leverages rtcp ssm such a separation is justified. The = possibility for separation of the monitoring service –associated with a server function basically responsible = for collecting RTCP receiver reports for the purpose of monitoring- and = the retransmission service requiring a server function that is = responsible for processing and responding to RTCP FB messages, is driven = from the point of view of server function optimisation (different = requirements on the server platform).

In terms of = signaling two Feedback Targets, we could make use of the following = lines:

a=3Drtcp:40001 IN IP4 192.0.2.1 (This is for = retransmission)
a=3Drtcp-fb:96 nack
a=3Drtcp:40001 IN IP4 192.0.2.2 (This is for XR = collection)


However, that is = probably quite ambiguous..?
Furthermore I = also realise such a solution introduces other questions than just = signaling syntax including the fact that we may need guiding rules on = how RTCP reports are issued by the RTP receiver with two RTCP targets in = place, as in the example above. The new RFC 5506 is certainly helpful = here, but this is probably not sufficient.

Comments = appreciated on this idea.

Kind = regards,
Tom Van = Caenegem



 

------_=_NextPart_001_01C9C4C8.85DD0C88-- From ron.even.tlv@gmail.com Fri Apr 24 04:24:59 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BF0A3A67F1 for ; Fri, 24 Apr 2009 04:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKVJf7UsHN+g for ; Fri, 24 Apr 2009 04:24:58 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 7C7B43A68AF for ; Fri, 24 Apr 2009 04:24:57 -0700 (PDT) Received: by bwz7 with SMTP id 7so1036223bwz.37 for ; Fri, 24 Apr 2009 04:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=7ODYI12UpZDnSdK94GorOMzzdpI5nKEYH87TNczF11s=; b=lkZnGgsGiHZ8jo8uqILRQwsRzySpuop+3FvvTRrG5ZlsYqfmJQ+YWjQiVF2FUcbsFd OqtDjojBhqX5VM3FO7x67TIimieHhqnkC+p/7oIelFe/Llu2BxFfu8wvdQw8WE6yiiBO nJUHwiraQdsLUEXhMfE6aPi+Ol0ujylFrOv4I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; b=dhrQf0bu6SIm2YpVX0HqdwSpnzYc7CpFRZl6j2U4hOjOejaJnRXmAr2ZQcPIAckI6q IHLogFS17WmQoF20t8RWDQGKsmjlB/BYw3mCkOhjmFGIfqhQW9XdqbW0bcJ2NWQh1W3R 9PGLLv3HL9vZqaBcWnsUK/VzlMnYjjp7NkisY= Received: by 10.103.223.2 with SMTP id a2mr1219683mur.4.1240572375226; Fri, 24 Apr 2009 04:26:15 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-121-32.red.bezeqint.net [79.179.121.32]) by mx.google.com with ESMTPS id 25sm2695226mul.27.2009.04.24.04.26.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 24 Apr 2009 04:26:14 -0700 (PDT) From: "Roni Even" To: References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> In-Reply-To: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> Date: Fri, 24 Apr 2009 14:24:16 +0300 Message-ID: <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AE_01C9C4E8.60B3C260" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGHOeBQ Content-Language: en-us Cc: "'Bill Ver Steeg \(versteb\)'" Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 11:24:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00AE_01C9C4E8.60B3C260 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I think that the current draft does not give a description of a system that works since there is no text explaining how the RS knows the unicast transport address on the RR to where to send the stream. If you mandate the use of RTP/RTCP mux it should say so otherwise the RAMS-R should have an optional parameter that supplies this information and a flag for using RTP/RTCP mux. Thanks Roni Even From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Bill Ver Steeg (versteb) Sent: Thursday, April 16, 2009 7:39 PM To: avt@ietf.org Subject: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available There is a new draft of the "Rapid Acquisition of Multicast RTP Sessions (RAMS)" draft available at http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-synchronization -for-rtp-03.txt We have incorporated the changes from the technical breakout session in San Francisco. The major changes in this version of the draft include 1- Changing the document title to avoid confusion with other ongoing "synchronization" drafts 2- changing the message names to reflect the title change 3- clarification of the RTCP message semantics, including changes to the "Request" and "Inform" messages 4- additional description/motivation for the various message flows has been added 5- RTP/RTCP muxing has been added We hope to make this a Working Group item, and will change the name of the draft to avoid conflicts with other "synchronization" drafts at that time. Bill VerSteeg ------=_NextPart_000_00AE_01C9C4E8.60B3C260 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I think that the current draft does not give a = description of a system that works since there is no text explaining how the RS knows the unicast transport address on the RR to where to send the stream. =

If you mandate the use of RTP/RTCP mux it should say so = otherwise the RAMS-R should have an optional parameter that supplies this = information and a flag for using RTP/RTCP mux.

Thanks

Roni Even

 

From:= avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Bill Ver Steeg (versteb)
Sent: Thursday, April 16, 2009 7:39 PM
To: avt@ietf.org
Subject: [AVT] New draft of "Rapid Acquisition of Multicast = RTP Sessions (RAMS)" available

 

There is a new draft of the "Rapid Acquisition of Multicast RTP Sessions (RAMS)" draft available at http://www.ietf.org/internet-drafts/draft-versteeg-avt-ra= pid-synchronization-for-rtp-03.txt

 

We have incorporated the changes from the technical breakout session = in San Francisco. The major changes in this version of the draft include =

1- Changing the document title to avoid confusion with other ongoing "synchronization" drafts

2- changing the message names to reflect the title = change

3- clarification of the RTCP message semantics, including changes to the "Request" and "Inform" = messages

4- additional description/motivation for the various message flows has been = added

5- RTP/RTCP muxing has been added

 

 

We hope to make this a Working Group item, and will change the name of the = draft to avoid conflicts with other "synchronization" drafts at that = time.

 

Bill VerSteeg

 

 

------=_NextPart_000_00AE_01C9C4E8.60B3C260-- From ron.even.tlv@gmail.com Fri Apr 24 07:31:18 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 832913A6B0A; Fri, 24 Apr 2009 07:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+kYam3XxBSo; Fri, 24 Apr 2009 07:31:17 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id F13CB3A69CA; Fri, 24 Apr 2009 07:31:16 -0700 (PDT) Received: by bwz7 with SMTP id 7so1127715bwz.37 for ; Fri, 24 Apr 2009 07:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=cEECRJu9dwFzaRz91b/RMZfe4NJGa6lqgYD07UXRP6A=; b=V2blGunYFkmmnz9HphxGEcr5/HQ/wEIqw9mPG14CVFgTY+5gufdhJX0Oj5S8TFKv6D Nrs42EB0dIJQ7YgH4N96/Q4aDz4sCBi96mmAHfTrcd4JTt40Df/ASMxUc9qvrMho5ENa RLkWrZKrzi6Yc2yqfIKeiJfarZVcHjBA0do4w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=dfjvtqGHCoH290vZI4fvWPiIBGb3hirDJYyFqR4MRN+v19pRVH/qREm13jccJjoAk5 6OwOymjG3KddnoFC5E9lWhXKlaMWpubqF9pyXIeRhV1lD4dqkWp1ytmQWy8gIFWStJyD ESKJVnTq+MQg5/R4UwwRqP8hCYpiHePTTXP7g= Received: by 10.204.68.73 with SMTP id u9mr2097323bki.192.1240583554987; Fri, 24 Apr 2009 07:32:34 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-121-32.red.bezeqint.net [79.179.121.32]) by mx.google.com with ESMTPS id 21sm316675fkx.36.2009.04.24.07.32.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 24 Apr 2009 07:32:34 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , References: <04CAD96D4C5A3D48B1919248A8FE0D54091BAA88@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54091BAA88@xmb-sjc-215.amer.cisco.com> Date: Fri, 24 Apr 2009 17:30:29 +0300 Message-ID: <49f1cd82.15185e0a.0fc3.ffffb9e7@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnAaI0k+CHA6Xe+Sfy0BV96KkoCXgAAB9bAAR8Fr7A= Content-Language: en-us Cc: avt@ietf.org Subject: Re: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 14:31:18 -0000 Hi, I am sorry that I did not review the draft before since I am not subscribed to fecframe and AVT was not cc'ed on the WGLC. I have some editorial comments: 1. In section 1 you reference RFC2733, I think it was obsolete by RFC 5109 , do you need this downref? 2. In the registration section 5.1, the comments applies to all subtypes: 2.1 You have for security considerations and published specification "this document" it is better to write RFC xxxx and have a note to the RFC editor to replace it with the RFC number allocated, this will show in the IANA registry with the write pointer. 2.2 In the restriction on usage I assume that the document is using RTP framing and is not specified for other types, if this is the case it should say so. E.g. " This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time" 2.3 You need to add the "additional information" that is in the template probably saying none 3. In section 5.2.1 it looks like you require symmetry between the send and received stream. Is this your requirement. 4. In section 5.2.1 can the answerer send a response with no FEC at all even if not offered. 5. In section 5.2.2 Can the receiver just ignore the fec stream, the text has a MUST use the configuration that is offered which can hint that it MUST use FEC. 6. In section 7 you discuss an exchange using grouping. Is it also allowed to use FEC withoutout grouping using the video or audio media types like section 14 in RFC 5109 Thanks Roni Even -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ali C. Begen (abegen) Sent: Sunday, April 19, 2009 12:04 AM To: fecframe@ietf.org Cc: avt@ietf.org Subject: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 This update addresses all the comments received in the WGLC period initated on April 1st. If there are further comments, please post them soon as we would like to move forward with this draft. http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interleaved-fec-sche me-03.txt BR, -acbegen -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Saturday, April 18, 2009 1:58 PM To: Ali C. Begen (abegen) Subject: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 A new version of I-D, draft-ietf-fecframe-interleaved-fec-scheme-03.txt has been successfuly submitted by Ali Begen and posted to the IETF repository. Filename: draft-ietf-fecframe-interleaved-fec-scheme Revision: 03 Title: RTP Payload Format for 1-D Interleaved Parity FEC Creation_date: 2009-04-18 WG ID: fecframe Number_of_pages: 31 Abstract: This document defines a new RTP payload format for the Forward Error Correction (FEC) that is generated by the 1-D interleaved parity code from a source media encapsulated in RTP. The 1-D interleaved parity code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The 1-D interleaved parity code offers a good protection against bursty packet losses at a cost of decent complexity. The new payload format defined in this document is used (with some exceptions) as a part of the DVB Application-layer FEC specification. The IETF Secretariat. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From abegen@cisco.com Fri Apr 24 08:11:33 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8D353A6B80 for ; Fri, 24 Apr 2009 08:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9IhIPLq4T-g for ; Fri, 24 Apr 2009 08:11:32 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id D627E3A6B46 for ; Fri, 24 Apr 2009 08:11:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,242,1238976000"; d="scan'208";a="34329880" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 24 Apr 2009 15:12:51 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3OFCm8l003759; Fri, 24 Apr 2009 08:12:48 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3OFCmhD010107; Fri, 24 Apr 2009 15:12:48 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 08:12:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Apr 2009 08:12:46 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C8066@xmb-sjc-215.amer.cisco.com> In-Reply-To: <014601c9c4c3$d6c56fa0$84504ee0$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available Thread-Index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGCYQgQAAvXoiA= References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <014601c9c4c3$d6c56fa0$84504ee0$@com> From: "Ali C. Begen (abegen)" To: "Zou ZiXuan" , "Bill Ver Steeg (versteb)" , X-OriginalArrivalTime: 24 Apr 2009 15:12:48.0594 (UTC) FILETIME=[20F53B20:01C9C4EF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3955; t=1240585971; x=1241449971; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20New=20draft=20of=20=22Rapid=20A cquisition=20of=20Multicast=20RTP=20Sessions=09(RAMS)=22=20a vailable |Sender:=20; bh=I2vCSm8CrNgin8I2hwU3JcL4I0oGhifDCQZl5d30ipU=; b=FbNhM7+VkWLQHdgJ/vOH2ae2/7SYruk8qToZ81Uzg4PY6cyCRdKd4jPZcj poIQX0RkcgFzCD+v7K7Txe/0COY6y4aobPIHYKORkIPuMJW7NeBvOk7St+h0 xs1kj78grz; Authentication-Results: sj-dkim-4; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 15:11:33 -0000 Hi Zou, This is a very good question. Let me take a stab here. Per RFC 3550, each SSRC space has its own clock rate and seq numbering. = We include the SSRC in the RAMS request messages. There are different flavors of your scneario. Lets assume that we have = two RTP streams (audio and video). Case 1: Different RTP sessions are transmitted over different mcast = groups. Here, we run a different independent RAMS session for each RTP stream = that we want to rapidly acquire (they can run in parallel). Here one = needs to pay attention to how to use the shared bandwidth among = different bursts, though. Case 2: Different RTP sessions are transmitted over the same mcast group = (with different dest ports). Again, we run a different independent RAMS for each RTP stream = (different request for each, etc). But, one should keep in mind that the = join times for the all RAMS sessions need to be common as there is only = one multicast. Case 3: One RTP session (same mcast group, same dest port) carrying both = audio and video (this is SSRC multiplexing). Similar to case 2, join time needs to be coordinated among different = RAMS sessions running for each RTP stream. Since we signal SSRC in the = request message and we have independent RAMS sessions, using different = clock rates is not an issue. Case 4: One RTP session, one SSRC with payload type multiplexing. This = is not recommended for many reasons. On top of that, different payloads = with different clock rates cannot be multiplexed in this fashion. So, I = don't think this will apply to our problem. HTH, -acbegen > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of Zou ZiXuan > Sent: Friday, April 24, 2009 3:03 AM > To: Bill Ver Steeg (versteb); avt@ietf.org > Subject: Re: [AVT] New draft of "Rapid Acquisition of=20 > Multicast RTP Sessions (RAMS)" available >=20 > Hi, >=20 > The burst duration (8 octets) in RAMS-I message is=20 > in a single RTP ticks. And I note that from draft-01 on, the=20 > solution is payload-independent (is my understanding=20 > correct?). So, for non-MEPG2-TS payload, for example,=20 > H.264-NAL where audio and video content are encapsulated=20 > separately in two RTP streams with different ticks, does the=20 > duration indicated by this single ticks still work? Which=20 > stream does this tick belong to? >=20 > =20 >=20 > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of Bill Ver Steeg (versteb) > Sent: Friday, April 17, 2009 12:39 AM > To: avt@ietf.org > Subject: [AVT] New draft of "Rapid Acquisition of Multicast=20 > RTP Sessions (RAMS)" available >=20 > =20 >=20 > There is a new draft of the "Rapid Acquisition of Multicast=20 > RTP Sessions (RAMS)" draft available at=20 > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s ynchronization-for-rtp-03.txt = drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt>=20 >=20 > =20 >=20 > We have incorporated the changes from the technical breakout=20 > session in San Francisco. The major changes in this version=20 > of the draft include=20 >=20 > 1- Changing the document title to avoid confusion with other=20 > ongoing "synchronization" drafts >=20 > 2- changing the message names to reflect the title change >=20 > 3- clarification of the RTCP message semantics, including=20 > changes to the "Request" and "Inform" messages >=20 > 4- additional description/motivation for the various message=20 > flows has been added >=20 > 5- RTP/RTCP muxing has been added >=20 > =20 >=20 > =20 >=20 > We hope to make this a Working Group item, and will change=20 > the name of the draft to avoid conflicts with other=20 > "synchronization" drafts at that time. >=20 > =20 >=20 > Bill VerSteeg >=20 > =20 >=20 > =20 >=20 >=20 From marshall.eubanks@gmail.com Fri Apr 24 08:45:18 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9AAD3A6D53 for ; Fri, 24 Apr 2009 08:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qf-qpB9PkzEL for ; Fri, 24 Apr 2009 08:45:14 -0700 (PDT) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.191]) by core3.amsl.com (Postfix) with ESMTP id 8EC693A6A37 for ; Fri, 24 Apr 2009 08:45:13 -0700 (PDT) Received: by mu-out-0910.google.com with SMTP id w1so271663mue.9 for ; Fri, 24 Apr 2009 08:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=6/zNeS8voJhAf/U8Ewy57UlporyCVAFxQNIveiCZgo0=; b=wSQxQrBBtFoLPitF/sbTzEDVD7YtpIL9ox6zunVEj8xWz3VvSNDf/gpt/1ACNXVqP8 aa7TyKsX2rpcGHRDcPnrIEx6yR+pa7conX3aM1nB17hsDGCJ02jJzrybwda3DwGeeaKP 6jPujXjBHIbIqXPaKLX6KB5lVvFcvoiZVjxlw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=ZW8tvuni3CZ7GXLiEoWbofnHLhMWOItTe7pher1GRku5LSbS/h6KkmoKrI5dp5AfdY PMY1XWiIdsSSxrGKWV6nP09a5mw5/Mc23Oe0QMVpCjChmgI47y9fQ4LCzHqcwEfg6yNM YRfkCwBnyCVsnbfh+ZC4nHu9ETgjyTjGZD8Yw= MIME-Version: 1.0 Received: by 10.239.142.201 with SMTP id h9mr114622hba.44.1240587991285; Fri, 24 Apr 2009 08:46:31 -0700 (PDT) In-Reply-To: <7703FB86-C193-4843-8FAD-4C02C8313D21@americafree.tv> References: <387DA3D4-8B91-48C8-BB08-3C0725D112F8@multicasttech.com> <7703FB86-C193-4843-8FAD-4C02C8313D21@americafree.tv> Date: Fri, 24 Apr 2009 11:46:31 -0400 Message-ID: From: Marshall Eubanks To: IETF AVT WG Content-Type: multipart/alternative; boundary=001485f90f44887fa904684ee66b Subject: [AVT] Fwd: [Fecframe] Working Group Last Call on draft-ietf-fecframe-config-signaling X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 15:45:18 -0000 --001485f90f44887fa904684ee66b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I apologize for not forwarding this to AVT, but I think it may be of interest here. Regards Marshall ---------- Forwarded message ---------- From: Marshall Eubanks Date: Fri, Apr 24, 2009 at 11:44 AM Subject: Fwd: [Fecframe] Working Group Last Call on draft-ietf-fecframe-config-signaling To: "marshall.eubanks@gmail.com Eubanks" Begin forwarded message: From: Marshall Eubanks > Date: April 18, 2009 2:04:14 PM EDT > To: fecframe@ietf.org > Subject: [Fecframe] Working Group Last Call on > draft-ietf-fecframe-config-signaling > > I think that this document is also ready, so I would like to issue > a working group last call on draft-ietf-fecframe-config-signaling-01. This > document can be > found at > > http://tools.ietf.org/id/draft-ietf-fecframe-config-signaling-01.txt > > I encourage everyone to read this document and comment during the last call > period. > > This last call will end on Monday, May 4th, 2009. > > Regards > Marshall Eubanks > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > > Regards Marshall Eubanks CEO / AmericaFree.TV --001485f90f44887fa904684ee66b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I apologize for not forwarding this to AVT, but I think it may be of intere= st here.=A0

Regards
Marshall

---------- Forwarded message ----------
From: Marshall Eubanks <tme@americafree.tv>
Date: Fri, Apr 24, 2009 at 11:44 AM
Subject: Fwd: [Fecframe] Working Gro= up Last Call on draft-ietf-fecframe-config-signaling
To: "marshall.eubanks@gmail.com Euban= ks" <marshall.eubanks= @gmail.com>




Begin forwarded message:

From: Marshall Eubanks <tme@multicasttech.com>
Date: April 18, 2009 2:04:14 PM EDT
To: fecframe@ietf.or= g
Subject: [Fecframe] Working Group Last Call on draft-ietf-fecframe-config-s= ignaling

I think that this document is also ready, so I would like to issue
a working group last call on draft-ietf-fecframe-config-signaling-01. This = document can be
found at

http://tools.ietf.org/id/draft-ietf-fecframe-config= -signaling-01.txt

I encourage everyone to read this document and comment during the last call= period.

This last call will end on Monday, May 4th, 2009.

Regards
Marshall Eubanks
_______________________________________________
Fecframe mailing list
Fecframe@ietf.org
https://www.ietf.org/mailman/listinfo/fecframe


Regards
Marshall Eubanks
CEO / AmericaFree.TV


--001485f90f44887fa904684ee66b-- From marshall.eubanks@gmail.com Fri Apr 24 08:46:05 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A35D3A6A9C for ; Fri, 24 Apr 2009 08:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59EljInDdOth for ; Fri, 24 Apr 2009 08:46:04 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 391123A6A37 for ; Fri, 24 Apr 2009 08:46:03 -0700 (PDT) Received: by bwz7 with SMTP id 7so1166672bwz.37 for ; Fri, 24 Apr 2009 08:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=cLFxubcAZHr/+QZqP3bOn8mQ1xRWdLQ2wfI1mAz/Og4=; b=LoH29DoOgF+Qq1xGJXU9WNakJBIc3AfJFDhSL2Q1L66Xqvd0kgR2pPEwyX7xbwyJIr d/5ZEcxr0utIjepPyLNPv7WcJTSwD6r+4vPYoFGJezsy+4FVlHH3YQwv33NRIUrLh2Na S47657w9wQ/gwNpArq3jkdtXvAik/PtbZzxok= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=kc7pgBJ0n74PdQeCxrbms4qZHpXJ4oHCDONKAmfBZBJ9xDTo+P0E9lPT1xtYZpaKol Q+PieInmkKRlbl3g9ZHBZWiLA670wmuW5G1OtVeNe8Z4Js4+z8yyb/a2Oc93T4tcEQ3o 0zplizpLaVX+pGSlEUkCMJspkGLDm6+SdAsz4= MIME-Version: 1.0 Received: by 10.239.133.74 with SMTP id 10mr118264hbu.29.1240588040971; Fri, 24 Apr 2009 08:47:20 -0700 (PDT) In-Reply-To: <8380A340-D38C-425C-9784-770232426BFB@americafree.tv> References: <14F76614-5B0C-4296-8CF5-6FA3B100EEF1@multicasttech.com> <8380A340-D38C-425C-9784-770232426BFB@americafree.tv> Date: Fri, 24 Apr 2009 11:47:20 -0400 Message-ID: From: Marshall Eubanks To: IETF AVT WG Content-Type: multipart/alternative; boundary=001485f7c5a07ea52d04684ee992 Subject: [AVT] Fwd: [Fecframe] Working Group Last Call on draft-ietf-fecframe-framework X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 15:46:05 -0000 --001485f7c5a07ea52d04684ee992 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This should certainly be of interest here and I apologize for not forwarding it previously. Regards Marshall ---------- Forwarded message ---------- From: Marshall Eubanks Date: Fri, Apr 24, 2009 at 11:43 AM Subject: Fwd: [Fecframe] Working Group Last Call on draft-ietf-fecframe-framework To: "marshall.eubanks@gmail.com Eubanks" Begin forwarded message: From: Marshall Eubanks > Date: April 18, 2009 1:58:27 PM EDT > To: fecframe@ietf.org > Subject: [Fecframe] Working Group Last Call on > draft-ietf-fecframe-framework > > Based on the discussion at the FECFRAME meeting in San Francisco, I would > like to > issue a working group last call on draft-ietf-fecframe-framework-03. This > document can be > found at > > http://www.ietf.org/internet-drafts/draft-ietf-fecframe-framework-03.txt > > This is an essential document for the Fecframe work, so I would like to > encourage everyone to > read it again and comment. > > This last call will end on Monday, May 4th, 2009. > > Regards > Marshall Eubanks > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > > Regards Marshall Eubanks CEO / AmericaFree.TV --001485f7c5a07ea52d04684ee992 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This should certainly be of interest here and I apologize for not forwardin= g it previously.

Regards
Marshall

---------- Forwarded message ----------
From: Marshall Eubanks <tme@americafree.tv>
Date: Fri, Apr 24, 2009 at 11:43 AM
Subject: Fwd: [Fecframe] Working Gro= up Last Call on draft-ietf-fecframe-framework
To: "marshall.eubanks@gmail.com Eubanks" = <marshall.eubanks@gmail.co= m>




Begin forwarded message:

From: Marshall Eubanks <tme@multicasttech.com>
Date: April 18, 2009 1:58:27 PM EDT
To: fecframe@ietf.or= g
Subject: [Fecframe] Working Group Last Call on draft-ietf-fecframe-framewor= k

Based on the discussion at the FECFRAME meeting in San Francisco, I would l= ike to
issue a working group last call on draft-ietf-fecframe-framework-03. This d= ocument can be
found at

http://www.ietf.org/internet-drafts/draft-ietf-= fecframe-framework-03.txt

This is an essential document for the Fecframe work, so I would like to enc= ourage everyone to
read it again and comment.

This last call will end on Monday, May 4th, 2009.

Regards
Marshall Eubanks
_______________________________________________
Fecframe mailing list
Fecframe@ietf.org
https://www.ietf.org/mailman/listinfo/fecframe


Regards
Marshall Eubanks
CEO / AmericaFree.TV


--001485f7c5a07ea52d04684ee992-- From abegen@cisco.com Fri Apr 24 09:37:17 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C24AF3A7027 for ; Fri, 24 Apr 2009 09:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5BvartLPRKk for ; Fri, 24 Apr 2009 09:37:15 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 828B028C246 for ; Fri, 24 Apr 2009 09:36:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,242,1238976000"; d="scan'208";a="292365906" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 24 Apr 2009 16:37:45 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3OGbjee017437; Fri, 24 Apr 2009 09:37:45 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3OGbjZD019273; Fri, 24 Apr 2009 16:37:45 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 09:37:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Apr 2009 09:37:42 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available Thread-Index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGHOeBQAAroqxA= References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , X-OriginalArrivalTime: 24 Apr 2009 16:37:45.0248 (UTC) FILETIME=[FECCEA00:01C9C4FA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2775; t=1240591065; x=1241455065; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20New=20draft=20of=20=22Rapid=20A cquisition=20of=20Multicast=20RTPSessions=09(RAMS)=22=20avai lable |Sender:=20; bh=/62qb536pq5WCx/lBQ1bTXuu4TOCahVkWMR8BIcn2+8=; b=s0ndQZedYliqnmwG4vlMbnscQY0EI9ncEKttG4MJ87FuZuHje6/6BZm+lU S/zQ616gfBoLCAbCRF6Y7uyq58dmIhUKr//0OGOTfq6L51Ei0qLdlWgD1S9L dujHQfIupoiQd8Wynny3ko3XbrpFuLiPwx4X67TA2iND+Gxpxe1e4=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "Bill Ver Steeg \(versteb\)" Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 16:37:17 -0000 Hi Roni,=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of Roni Even > Sent: Friday, April 24, 2009 4:24 AM > To: avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: Re: [AVT] New draft of "Rapid Acquisition of=20 > Multicast RTPSessions (RAMS)" available >=20 > Hi, >=20 > I think that the current draft does not give a description of=20 > a system that works since there is no text explaining how the=20 What do you mean by "a system that works"?=20 > RS knows the unicast transport address on the RR to where to=20 > send the stream.=20 Once RS receives the request packet from an RR, RS knows its address. = Ports are defined in the SDP. If you are asking about "NAT" issues, we = have a section for it, and we plan to complete it as we move forward. It = is not as critical as the other parts for now. =20 > If you mandate the use of RTP/RTCP mux it should say so=20 > otherwise the RAMS-R should have an optional parameter that=20 > supplies this information and a flag for using RTP/RTCP mux. IMO, we cannot mandate muxing as it is not required to make RAMS work. = If muxing is supported, the SDP should reflect it. BR, -acbegen =20 > Thanks >=20 > Roni Even >=20 > =20 >=20 > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of Bill Ver Steeg (versteb) > Sent: Thursday, April 16, 2009 7:39 PM > To: avt@ietf.org > Subject: [AVT] New draft of "Rapid Acquisition of Multicast=20 > RTP Sessions (RAMS)" available >=20 > =20 >=20 > There is a new draft of the "Rapid Acquisition of Multicast=20 > RTP Sessions (RAMS)" draft available at=20 > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s ynchronization-for-rtp-03.txt = drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt>=20 >=20 > =20 >=20 > We have incorporated the changes from the technical breakout=20 > session in San Francisco. The major changes in this version=20 > of the draft include=20 >=20 > 1- Changing the document title to avoid confusion with other=20 > ongoing "synchronization" drafts >=20 > 2- changing the message names to reflect the title change >=20 > 3- clarification of the RTCP message semantics, including=20 > changes to the "Request" and "Inform" messages >=20 > 4- additional description/motivation for the various message=20 > flows has been added >=20 > 5- RTP/RTCP muxing has been added >=20 > =20 >=20 > =20 >=20 > We hope to make this a Working Group item, and will change=20 > the name of the draft to avoid conflicts with other=20 > "synchronization" drafts at that time. >=20 > =20 >=20 > Bill VerSteeg >=20 > =20 >=20 > =20 >=20 >=20 From abegen@cisco.com Fri Apr 24 09:51:14 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F8DD3A6B8F; Fri, 24 Apr 2009 09:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.476 X-Spam-Level: X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zm3Xm3KB2HD2; Fri, 24 Apr 2009 09:51:08 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id DDD2E3A6986; Fri, 24 Apr 2009 09:50:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,242,1238976000"; d="scan'208";a="292374100" Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-6.cisco.com with ESMTP; 24 Apr 2009 16:52:07 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id n3OGq7ta020483; Fri, 24 Apr 2009 09:52:07 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3OGq71O002512; Fri, 24 Apr 2009 16:52:07 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 09:52:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Apr 2009 09:52:02 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C80EF@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49f1cd82.15185e0a.0fc3.ffffb9e7@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 Thread-Index: AcnAaI0k+CHA6Xe+Sfy0BV96KkoCXgAAB9bAAR8Fr7AABY9UAA== References: <04CAD96D4C5A3D48B1919248A8FE0D54091BAA88@xmb-sjc-215.amer.cisco.com> <49f1cd82.15185e0a.0fc3.ffffb9e7@mx.google.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , X-OriginalArrivalTime: 24 Apr 2009 16:52:07.0736 (UTC) FILETIME=[00E22380:01C9C4FD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4864; t=1240591927; x=1241455927; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20FW=3A=20New=20Version=20Notific ation=20for=09draft-ietf-fecframe-interleaved-fec-scheme-03 |Sender:=20; bh=CBq8kALL90ZF9JNoMziOxZb4YtqCnP5CDzCW0fjqwjU=; b=FYNBhc4gRRZySpseLMHgXulGeOESYJ9oJp1Blp3w/hDo/Y7ZAhlS1a/paI KAPdFvLJe6a8c8KDr/v+dCqcNrxbIwl1LEf9F0Pjt2tES8BsAF2E4PzJKIOp cQaH6zmtXw; Authentication-Results: sj-dkim-8; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); Cc: avt@ietf.org Subject: Re: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 16:51:14 -0000 Thanks for the review. See inline.=20 > 1. In section 1 you reference RFC2733, I think it was=20 > obsolete by RFC 5109 , > do you need this downref? Yes, this has been already discussed within fecframe and with Magnus. We = give an informative reference as we are using an extension of the header = RFC 2733 had. =20 > 2. In the registration section 5.1, the comments applies to=20 > all subtypes: =20 > 2.1 You have for security considerations and published=20 > specification > "this document" it is better to write RFC xxxx and have a=20 > note to the > RFC editor to replace it with the RFC number allocated, this=20 > will show in > the IANA registry with the write pointer. Will do. =20 > 2.2 In the restriction on usage I assume that the document=20 > is using RTP > framing and is not specified for other types, if this is the case it > should say so. E.g. " This media type depends on RTP=20 > framing, and hence is > only defined for transfer via RTP [RFC3550]. =09 > Transport within other > framing protocols is not defined at this time" Will do. > 2.3 You need to add the "additional information" that is in=20 > the template > probably saying none I believe I already have "additional information: none" for each = subtype. > 3. In section 5.2.1 it looks like you require symmetry=20 > between the send and > received stream. Is this your requirement.=20 I am not sure what "symmetry" means here. Could you explain? =20 > 4. In section 5.2.1 can the answerer send a response with no=20 > FEC at all even > if not offered. If the answerer does not want FEC, yes, it can drop FEC from the offer. = Let me make that clear in the text. =20 > 5. In section 5.2.2 Can the receiver just ignore the fec=20 > stream, the text > has a MUST use the configuration that is offered which can=20 > hint that it MUST > use FEC. The receiver may decide to receive or not receive the FEC stream. If it = decides to receive, it MUST use the configuration that is provided for = the session. I guess the text is clear about this point. =20 > 6. In section 7 you discuss an exchange using grouping. Is it=20 > also allowed > to use FEC withoutout grouping using the video or audio media=20 > types like > section 14 in RFC 5109 Per FEC framework, we require the FEC to be in a separate flow, which = requires the source and FEC streams to be on different RTP sessions. = Thus, we require grouping (RFC 4756 or 4756bis) BR, -acbegen =20 >=20 > Thanks > Roni Even > =20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of Ali C. > Begen (abegen) > Sent: Sunday, April 19, 2009 12:04 AM > To: fecframe@ietf.org > Cc: avt@ietf.org > Subject: [AVT] FW: New Version Notification for > draft-ietf-fecframe-interleaved-fec-scheme-03 >=20 > This update addresses all the comments received in the WGLC=20 > period initated > on April 1st. If there are further comments, please post them=20 > soon as we > would like to move forward with this draft. > http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interl eaved-fec-sche > me-03.txt >=20 > BR, > -acbegen=20 >=20 > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 > Sent: Saturday, April 18, 2009 1:58 PM > To: Ali C. Begen (abegen) > Subject: New Version Notification for > draft-ietf-fecframe-interleaved-fec-scheme-03=20 >=20 >=20 > A new version of I-D,=20 > draft-ietf-fecframe-interleaved-fec-scheme-03.txt has > been successfuly submitted by Ali Begen and posted to the=20 > IETF repository. >=20 > Filename: draft-ietf-fecframe-interleaved-fec-scheme > Revision: 03 > Title: RTP Payload Format for 1-D Interleaved=20 > Parity FEC > Creation_date: 2009-04-18 > WG ID: fecframe > Number_of_pages: 31 >=20 > Abstract: > This document defines a new RTP payload format for the Forward Error > Correction (FEC) that is generated by the 1-D interleaved parity code > from a source media encapsulated in RTP. The 1-D interleaved parity > code is a systematic code, where a number of repair symbols are > generated from a set of source symbols and sent in a repair flow > separate from the source flow that carries the source symbols. The > 1-D interleaved parity code offers a good protection against bursty > packet losses at a cost of decent complexity. The new payload format > defined in this document is used (with some exceptions) as a part of > the DVB Application-layer FEC specification. > =20 >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt >=20 >=20 From ron.even.tlv@gmail.com Fri Apr 24 11:44:44 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAE723A6C83 for ; Fri, 24 Apr 2009 11:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIO9cSiHnRFO for ; Fri, 24 Apr 2009 11:44:43 -0700 (PDT) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.189]) by core3.amsl.com (Postfix) with ESMTP id 5CDF23A69C6 for ; Fri, 24 Apr 2009 11:44:43 -0700 (PDT) Received: by mu-out-0910.google.com with SMTP id w1so308350mue.9 for ; Fri, 24 Apr 2009 11:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=TkR1e2SMj4FaweTwpP8qoqBmwXdyI4N4cZBLPmqcw0w=; b=AFyIltKWWWMscuEGgVm5qYcQkMrGDaNRbimk+PdEfHpzsNNCC388P2iujpsT6mQVpg byffzOT08C7PQzIaf+9uaBP9cffqaeYflBIeb4hpv1Dd7e7ALzzd6pePx2qnOylV9CNN TZlK9uXD18LTKAJHYAdu8+Nby/liNVEk8JJJU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=GCjwkAgiC+rKURAe36IgEdYXYqjo5SlpXrF60OzWeCH1weNFoQMeL0uTx+prZ/4KyS XALijmQP0fL+0mkCRFcOsZC+DrAlMiPULAxT4ZgqgpWkYNAXIZN42D7k225pW9NCEHqR 3wwDKn0J+OA6RIlWp6bYyArtHxbpg5K8hZ3T8= Received: by 10.103.214.8 with SMTP id r8mr1481020muq.6.1240598761351; Fri, 24 Apr 2009 11:46:01 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-121-32.red.bezeqint.net [79.179.121.32]) by mx.google.com with ESMTPS id i5sm4069112mue.25.2009.04.24.11.45.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 24 Apr 2009 11:46:00 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> Date: Fri, 24 Apr 2009 21:44:01 +0300 Message-ID: <49f208e8.05a0660a.5bd2.6764@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGHOeBQAAroqxAABGe0AA== Content-Language: en-us Cc: "'Bill Ver Steeg \(versteb\)'" Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 18:44:44 -0000 Ali, I will try to explain in simple way When the RS receives the RAMS-R it need to start sending an RTP stream to the RR. In order to send a unicast packet, the RS needs to know a transport address on the RR to where the RTP stream will be sent. The current draft does not say how the RS knows this address. There is no SDP from RR to RS like you mention in your response. This is why I say that the current draft does not specify a solution that can be implemented as a working solution Roni -----Original Message----- From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] Sent: Friday, April 24, 2009 7:38 PM To: Roni Even; avt@ietf.org Cc: Bill Ver Steeg (versteb) Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available Hi Roni, > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Roni Even > Sent: Friday, April 24, 2009 4:24 AM > To: avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: Re: [AVT] New draft of "Rapid Acquisition of > Multicast RTPSessions (RAMS)" available > > Hi, > > I think that the current draft does not give a description of > a system that works since there is no text explaining how the What do you mean by "a system that works"? > RS knows the unicast transport address on the RR to where to > send the stream. Once RS receives the request packet from an RR, RS knows its address. Ports are defined in the SDP. If you are asking about "NAT" issues, we have a section for it, and we plan to complete it as we move forward. It is not as critical as the other parts for now. > If you mandate the use of RTP/RTCP mux it should say so > otherwise the RAMS-R should have an optional parameter that > supplies this information and a flag for using RTP/RTCP mux. IMO, we cannot mandate muxing as it is not required to make RAMS work. If muxing is supported, the SDP should reflect it. BR, -acbegen > Thanks > > Roni Even > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Bill Ver Steeg (versteb) > Sent: Thursday, April 16, 2009 7:39 PM > To: avt@ietf.org > Subject: [AVT] New draft of "Rapid Acquisition of Multicast > RTP Sessions (RAMS)" available > > > > There is a new draft of the "Rapid Acquisition of Multicast > RTP Sessions (RAMS)" draft available at > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s ynchronization-for-rtp-03.txt drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt> > > > > We have incorporated the changes from the technical breakout > session in San Francisco. The major changes in this version > of the draft include > > 1- Changing the document title to avoid confusion with other > ongoing "synchronization" drafts > > 2- changing the message names to reflect the title change > > 3- clarification of the RTCP message semantics, including > changes to the "Request" and "Inform" messages > > 4- additional description/motivation for the various message > flows has been added > > 5- RTP/RTCP muxing has been added > > > > > > We hope to make this a Working Group item, and will change > the name of the draft to avoid conflicts with other > "synchronization" drafts at that time. > > > > Bill VerSteeg > > > > > > From versteb@cisco.com Fri Apr 24 11:49:15 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E30A28C1A9 for ; Fri, 24 Apr 2009 11:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaZ-WmeaZdaI for ; Fri, 24 Apr 2009 11:49:14 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 7EE1E3A69C6 for ; Fri, 24 Apr 2009 11:49:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,243,1238976000"; d="scan'208,217";a="34377591" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 24 Apr 2009 18:50:32 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3OIoXEU007140; Fri, 24 Apr 2009 11:50:33 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3OIo6eB016664; Fri, 24 Apr 2009 18:50:33 GMT Received: from xmb-rtp-21d.amer.cisco.com ([64.102.31.116]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 14:50:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C50D.87FA4A67" Date: Fri, 24 Apr 2009 14:50:25 -0400 Message-ID: <81B9B88E2F9D574AA5328A85547CDE9101153491@xmb-rtp-21d.amer.cisco.com> In-Reply-To: <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available Thread-Index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGHOeBQAA3KHOA= References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> From: "Bill Ver Steeg (versteb)" To: "Roni Even" , X-OriginalArrivalTime: 24 Apr 2009 18:50:26.0588 (UTC) FILETIME=[8820FDC0:01C9C50D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13088; t=1240599033; x=1241463033; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=versteb@cisco.com; z=From:=20=22Bill=20Ver=20Steeg=20(versteb)=22=20 |Subject:=20RE=3A=20[AVT]=20New=20draft=20of=20=22Rapid=20A cquisition=20of=20Multicast=20RTP=20Sessions=09(RAMS)=22=20a vailable |Sender:=20; bh=x1VYo8t76G5KFkZ/qhy2WQtM/mWj1HeV2JZ1jef/Dzs=; b=tWViZA+2DM8LuQMHGJW1QRVLAIl5NqjZ6jeQIpfyrfQqh6mAS1T6FmmIyD dCr2B5I5GTNI1mQHpG4ATff89hlqfNmLMeD/MTCKF9Wr+OoAUCx8UIhFA9LE ca9oVOCUeK; Authentication-Results: sj-dkim-3; header.From=versteb@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 18:49:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C50D.87FA4A67 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Roni- =20 Yes, the document needs updating in this respect. We have two broad options which need to be described in detail. =20 The method that I have been assuming does use muxing. The RS sends the unicast burst back to the UDP port number on the RR that sent the RAMS-R. This allows transparent operation through NAT. There is a single UDP port, and the transaction is initiated by the "client", so it is NAT friendly. =20 There are quite a few ways we could handle the case in which muxing is not used. We could add a parameter to the RAMS-R, use another RTCP packet in the same compound packet, define the port numbers as a relationship to the opened port (not attractive), or define something in the SDP (also not attractive). I personally like the "RAMS-R optional field" approach, but I think this should be a topic that we consider in detail once we have a WG item. =20 =20 =20 =20 bvs =20 ________________________________ From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 Sent: Friday, April 24, 2009 7:24 AM To: avt@ietf.org Cc: Bill Ver Steeg (versteb) Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available Hi, I think that the current draft does not give a description of a system that works since there is no text explaining how the RS knows the unicast transport address on the RR to where to send the stream.=20 If you mandate the use of RTP/RTCP mux it should say so otherwise the RAMS-R should have an optional parameter that supplies this information and a flag for using RTP/RTCP mux. Thanks Roni Even =20 From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Bill Ver Steeg (versteb) Sent: Thursday, April 16, 2009 7:39 PM To: avt@ietf.org Subject: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available =20 There is a new draft of the "Rapid Acquisition of Multicast RTP Sessions (RAMS)" draft available at http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-synchroniza tion-for-rtp-03.txt =20 =20 We have incorporated the changes from the technical breakout session in San Francisco. The major changes in this version of the draft include=20 1- Changing the document title to avoid confusion with other ongoing "synchronization" drafts 2- changing the message names to reflect the title change 3- clarification of the RTCP message semantics, including changes to the "Request" and "Inform" messages 4- additional description/motivation for the various message flows has been added 5- RTP/RTCP muxing has been added =20 =20 We hope to make this a Working Group item, and will change the name of the draft to avoid conflicts with other "synchronization" drafts at that time. =20 Bill VerSteeg =20 =20 ------_=_NextPart_001_01C9C50D.87FA4A67 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Roni-
 
Yes, the document needs updating in this = respect. We have=20 two broad options which need to be described in = detail.
 
The method that I have been assuming does use = muxing.=20 The RS sends the unicast burst back to the UDP port number on the = RR that=20 sent the RAMS-R. This allows transparent operation through NAT. There is = a=20 single UDP port, and the transaction is initiated by the "client", so it = is NAT=20 friendly.
 
There are quite a few ways we could handle the = case in=20 which muxing is not used. We could add a parameter to the RAMS-R, use = another=20 RTCP packet in the same compound packet, define the port numbers as a=20 relationship to the opened port (not attractive), or define something in = the SDP=20 (also not attractive). I personally like the "RAMS-R optional field" = approach,=20 but I think this should be a topic that we consider in detail once we = have a WG=20 item.
 
 
 
 
bvs
 

From: Roni Even = [mailto:ron.even.tlv@gmail.com]=20
Sent: Friday, April 24, 2009 7:24 AM
To:=20 avt@ietf.org
Cc: Bill Ver Steeg (versteb)
Subject: = RE: [AVT]=20 New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)"=20 available

Hi,

I=20 think that the current draft does not give a description of a system = that works=20 since there is no text explaining how the RS knows the unicast transport = address=20 on the RR to where to send the stream.

If=20 you mandate the use of RTP/RTCP mux it should say so otherwise the = RAMS-R should=20 have an optional parameter that supplies this information and a flag for = using=20 RTP/RTCP mux.

Thanks

Roni=20 Even

 

From:=20 avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Bill Ver=20 Steeg (versteb)
Sent: Thursday, April 16, 2009 7:39 = PM
To:=20 avt@ietf.org
Subject: [AVT] New draft of "Rapid Acquisition of = Multicast RTP Sessions (RAMS)" = available

 

There is a = new draft=20 of the "Rapid Acquisition of Multicast RTP Sessions (RAMS)" draft = available at=20 http://www.ietf.org/internet-drafts/draft-versteeg-avt-ra= pid-synchronization-for-rtp-03.txt

=

 

We=20 have incorporated the changes from the technical breakout session = in San=20 Francisco. The major changes in this version of the draft include=20

1- Changing = the=20 document title to avoid confusion with other ongoing "synchronization"=20 drafts

2- changing = the=20 message names to reflect the title change

3- = clarification of=20 the RTCP message semantics, including changes to the "Request" = and=20 "Inform" messages

4- = additional=20 description/motivation for the various message flows has been=20 added

5- RTP/RTCP = muxing=20 has been added

 

 

We hope to = make this=20 a Working Group item, and will change the name of the draft to avoid = conflicts=20 with other "synchronization" drafts at that = time.

 

Bill=20 VerSteeg

 

 

------_=_NextPart_001_01C9C50D.87FA4A67-- From abegen@cisco.com Fri Apr 24 11:59:37 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDA303A6A02 for ; Fri, 24 Apr 2009 11:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.285 X-Spam-Level: X-Spam-Status: No, score=-5.285 tagged_above=-999 required=5 tests=[AWL=-1.086, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7o263rEEZgVO for ; Fri, 24 Apr 2009 11:59:36 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CB3C23A688F for ; Fri, 24 Apr 2009 11:59:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,243,1238976000"; d="scan'208";a="292443597" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 24 Apr 2009 19:00:55 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3OJ0tbm013917; Fri, 24 Apr 2009 12:00:55 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3OJ0txu025606; Fri, 24 Apr 2009 19:00:55 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 12:00:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Apr 2009 12:00:51 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49f208e8.05a0660a.5bd2.6764@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available Thread-Index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGHOeBQAAroqxAABGe0AAAAUgbQ References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , X-OriginalArrivalTime: 24 Apr 2009 19:00:55.0790 (UTC) FILETIME=[FF2998E0:01C9C50E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5166; t=1240599655; x=1241463655; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20New=20draft=20of=20=22Rapid=20A cquisition=20of=20Multicast=20RTPSessions=09(RAMS)=22=20avai lable |Sender:=20; bh=D6Cb6/NRajYBfO6EYF8t4wlLD+ro0ygwg2KN2v6dmYg=; b=Cb7c+6Q54bDwmbTIypGl+Cef9u159IYuNVkgAntHplkXBuSBTh0k5uxEf6 SJ9BkEk2QR2SqAmxVxRDuiHCgnlxVjQw/9FewqQ3jCKj5wLAyzwtblf1v71X 8j2ArWQn+k; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "Bill Ver Steeg \(versteb\)" Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 18:59:38 -0000 Oh, I see. The burst goes to the port that we would normally send the = retransmissions. For example, consider the SDP from the draft: m=3Dvideo 41000 RTP/AVPF 98 i=3DPrimary Multicast Stream #2 c=3DIN IP4 224.1.1.2/255 a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 a=3Drtpmap:98 MP2T/90000 a=3Drtcp:41001 IN IP4 192.0.2.1 a=3Drtcp-fb:98 nack a=3Drtcp-fb:98 nack ssli a=3Dssrc:123321 cname:iptv-ch32@rams.example.com a=3Dmid:3 m=3Dvideo 41002 RTP/AVPF 99 i=3DUnicast Retransmission Stream #2 (Ret. and Rapid Acq. = Support) c=3DIN IP4 192.0.2.1 a=3Drecvonly a=3Drtpmap:99 rtx/90000 a=3Drtcp:41003 a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 a=3Dmid:4 In this case, the burst will go to port 41002 on the RR. The RAMS-I = message(s), which is an RTCP feedback message, will go to port 41003. HTH, -acbegen > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > Sent: Friday, April 24, 2009 11:44 AM > To: Ali C. Begen (abegen); avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > Multicast RTPSessions (RAMS)" available >=20 > Ali, > I will try to explain in simple way >=20 > When the RS receives the RAMS-R it need to start sending an=20 > RTP stream to > the RR.=20 > In order to send a unicast packet, the RS needs to know a=20 > transport address > on the RR to where the RTP stream will be sent. The current=20 > draft does not > say how the RS knows this address. There is no SDP from RR to=20 > RS like you > mention in your response. > This is why I say that the current draft does not specify a=20 > solution that > can be implemented as a working solution > Roni >=20 > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > Sent: Friday, April 24, 2009 7:38 PM > To: Roni Even; avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > Multicast RTPSessions > (RAMS)" available >=20 > Hi Roni,=20 >=20 > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > > Behalf Of Roni Even > > Sent: Friday, April 24, 2009 4:24 AM > > To: avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: Re: [AVT] New draft of "Rapid Acquisition of=20 > > Multicast RTPSessions (RAMS)" available > >=20 > > Hi, > >=20 > > I think that the current draft does not give a description of=20 > > a system that works since there is no text explaining how the=20 >=20 > What do you mean by "a system that works"?=20 >=20 > > RS knows the unicast transport address on the RR to where to=20 > > send the stream.=20 >=20 > Once RS receives the request packet from an RR, RS knows its=20 > address. Ports > are defined in the SDP. If you are asking about "NAT" issues,=20 > we have a > section for it, and we plan to complete it as we move=20 > forward. It is not as > critical as the other parts for now. > =20 > > If you mandate the use of RTP/RTCP mux it should say so=20 > > otherwise the RAMS-R should have an optional parameter that=20 > > supplies this information and a flag for using RTP/RTCP mux. >=20 > IMO, we cannot mandate muxing as it is not required to make=20 > RAMS work. If > muxing is supported, the SDP should reflect it. >=20 > BR, > -acbegen > =20 > > Thanks > >=20 > > Roni Even > >=20 > > =20 > >=20 > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > > Behalf Of Bill Ver Steeg (versteb) > > Sent: Thursday, April 16, 2009 7:39 PM > > To: avt@ietf.org > > Subject: [AVT] New draft of "Rapid Acquisition of Multicast=20 > > RTP Sessions (RAMS)" available > >=20 > > =20 > >=20 > > There is a new draft of the "Rapid Acquisition of Multicast=20 > > RTP Sessions (RAMS)" draft available at=20 > > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s > ynchronization-for-rtp-03.txt > drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt>=20 > >=20 > > =20 > >=20 > > We have incorporated the changes from the technical breakout=20 > > session in San Francisco. The major changes in this version=20 > > of the draft include=20 > >=20 > > 1- Changing the document title to avoid confusion with other=20 > > ongoing "synchronization" drafts > >=20 > > 2- changing the message names to reflect the title change > >=20 > > 3- clarification of the RTCP message semantics, including=20 > > changes to the "Request" and "Inform" messages > >=20 > > 4- additional description/motivation for the various message=20 > > flows has been added > >=20 > > 5- RTP/RTCP muxing has been added > >=20 > > =20 > >=20 > > =20 > >=20 > > We hope to make this a Working Group item, and will change=20 > > the name of the draft to avoid conflicts with other=20 > > "synchronization" drafts at that time. > >=20 > > =20 > >=20 > > Bill VerSteeg > >=20 > > =20 > >=20 > > =20 > >=20 > >=20 >=20 >=20 From ron.even.tlv@gmail.com Fri Apr 24 12:05:24 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DE4F28C710; Fri, 24 Apr 2009 12:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YX-WIFJ+nbXb; Fri, 24 Apr 2009 12:05:23 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 3CE9928C763; Fri, 24 Apr 2009 12:03:44 -0700 (PDT) Received: by bwz7 with SMTP id 7so1254738bwz.37 for ; Fri, 24 Apr 2009 12:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=IVjVdbVLHOQanoBZLg4HlZLgRtnsuDo3+X7TOsxESvg=; b=OkvCc0FOLlgDxm/Ep1fjFAlmk3PIjU9lWJyupRNvAMSkT1B3TsArbaX5cg3glrfa8s ZZZSwCp1jqXu88s8LazzS83LT5NcfTsfJp0Orp5DVhZDDs7dqA+6aE+UGqdxJ7u4Ziog AXVx6Ok1c4Rn9yCQ/Grh4FaCinpAOAWN8Z2zg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=tADi3zxRF7LN/Ce1W0kSdUKmRxjhOcG/TbvO+lzNkWhH9IeCezM20ezIT7aq7Kkow8 hlH7GJB0HFT2LKlbkhTwCQQWNzNPP+gxfdnSAw7Gxx2EFVFv6Xn9VPDvZ0sKDdINc/wt NtYFl1yE8vuZ2DzZCwtLFVUqRvvzoZz/mbkVI= Received: by 10.204.118.138 with SMTP id v10mr2334042bkq.182.1240599902190; Fri, 24 Apr 2009 12:05:02 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-121-32.red.bezeqint.net [79.179.121.32]) by mx.google.com with ESMTPS id f31sm2842049fkf.12.2009.04.24.12.04.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 24 Apr 2009 12:05:01 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , References: <04CAD96D4C5A3D48B1919248A8FE0D54091BAA88@xmb-sjc-215.amer.cisco.com> <49f1cd82.15185e0a.0fc3.ffffb9e7@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80EF@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C80EF@xmb-sjc-215.amer.cisco.com> Date: Fri, 24 Apr 2009 22:03:13 +0300 Message-ID: <49f20d5d.1f205e0a.2719.fffffab1@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnAaI0k+CHA6Xe+Sfy0BV96KkoCXgAAB9bAAR8Fr7AABY9UAAAE5sqQ Content-Language: en-us Cc: avt@ietf.org Subject: Re: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 19:05:24 -0000 Ali, Inline Roni > 2.3 You need to add the "additional information" that is in > the template > probably saying none I believe I already have "additional information: none" for each subtype. RE- The order was different so I missed it > 3. In section 5.2.1 it looks like you require symmetry > between the send and > received stream. Is this your requirement. I am not sure what "symmetry" means here. Could you explain? RE - Symmetry means that the offerer and answerer MUST use the same mode since this exchange results in a two streams, one from each direction. > 5. In section 5.2.2 Can the receiver just ignore the fec > stream, the text > has a MUST use the configuration that is offered which can > hint that it MUST > use FEC. The receiver may decide to receive or not receive the FEC stream. If it decides to receive, it MUST use the configuration that is provided for the session. I guess the text is clear about this point. RE- I think it has to do with my assumption that you can multiplex the streams like RFC 5109 > 6. In section 7 you discuss an exchange using grouping. Is it > also allowed > to use FEC withoutout grouping using the video or audio media > types like > section 14 in RFC 5109 Per FEC framework, we require the FEC to be in a separate flow, which requires the source and FEC streams to be on different RTP sessions. Thus, we require grouping (RFC 4756 or 4756bis) RE- I will have to look at that draft, this is different from RFC 5109 and RFC 2733 BR, -acbegen > > Thanks > Roni Even > > > > > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Ali C. > Begen (abegen) > Sent: Sunday, April 19, 2009 12:04 AM > To: fecframe@ietf.org > Cc: avt@ietf.org > Subject: [AVT] FW: New Version Notification for > draft-ietf-fecframe-interleaved-fec-scheme-03 > > This update addresses all the comments received in the WGLC > period initated > on April 1st. If there are further comments, please post them > soon as we > would like to move forward with this draft. > http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interl eaved-fec-sche > me-03.txt > > BR, > -acbegen > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Saturday, April 18, 2009 1:58 PM > To: Ali C. Begen (abegen) > Subject: New Version Notification for > draft-ietf-fecframe-interleaved-fec-scheme-03 > > > A new version of I-D, > draft-ietf-fecframe-interleaved-fec-scheme-03.txt has > been successfuly submitted by Ali Begen and posted to the > IETF repository. > > Filename: draft-ietf-fecframe-interleaved-fec-scheme > Revision: 03 > Title: RTP Payload Format for 1-D Interleaved > Parity FEC > Creation_date: 2009-04-18 > WG ID: fecframe > Number_of_pages: 31 > > Abstract: > This document defines a new RTP payload format for the Forward Error > Correction (FEC) that is generated by the 1-D interleaved parity code > from a source media encapsulated in RTP. The 1-D interleaved parity > code is a systematic code, where a number of repair symbols are > generated from a set of source symbols and sent in a repair flow > separate from the source flow that carries the source symbols. The > 1-D interleaved parity code offers a good protection against bursty > packet losses at a cost of decent complexity. The new payload format > defined in this document is used (with some exceptions) as a part of > the DVB Application-layer FEC specification. > > > > > The IETF Secretariat. > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > From ron.even.tlv@gmail.com Fri Apr 24 12:19:48 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8679F3A6A67 for ; Fri, 24 Apr 2009 12:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjzwYkA-6Nos for ; Fri, 24 Apr 2009 12:19:47 -0700 (PDT) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.187]) by core3.amsl.com (Postfix) with ESMTP id 682DA3A7048 for ; Fri, 24 Apr 2009 12:19:46 -0700 (PDT) Received: by mu-out-0910.google.com with SMTP id w1so314888mue.9 for ; Fri, 24 Apr 2009 12:21:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=WCE/aXfsyJ9dedKP3w1kz8QIBujSK/QQJjfnjEg23nQ=; b=fEZTO0oFoZgmX4azWeeGDtkyQBj8EiKENUZrcUS1le/7NTl0lwSbmFwzEvPdqFsgoG K/VQZZ2omneh/0Xne5b27pgamG2pky4HUz+udwU4FUjggcrFPwhV3cZEd0HEQZpJ5M8K mQZDyN7CuajeaO9ns1MCfIe1sctX/cVA0Hm94= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; b=EJKUcK2KpaNd8V3HE5yCywbSImvaZijVWBswOX30dMF8xaKOXSGahDQQ1RwmFIoqtE lrrPk/NlkqzVjOyAysCxYer3HBhKcLQq7xA2jrItDTtqIpnPf9Lf/L7MYCjfEJogz9v/ ebaHepbJqXl8JPukb6tQEscZbz5tsDWrdWGec= Received: by 10.103.102.18 with SMTP id e18mr1506988mum.44.1240600864290; Fri, 24 Apr 2009 12:21:04 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-121-32.red.bezeqint.net [79.179.121.32]) by mx.google.com with ESMTPS id j2sm4176218mue.11.2009.04.24.12.20.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 24 Apr 2009 12:21:03 -0700 (PDT) From: "Roni Even" To: "'Bill Ver Steeg \(versteb\)'" , References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <81B9B88E2F9D574AA5328A85547CDE9101153491@xmb-rtp-21d.amer.cisco.com> In-Reply-To: <81B9B88E2F9D574AA5328A85547CDE9101153491@xmb-rtp-21d.amer.cisco.com> Date: Fri, 24 Apr 2009 22:19:04 +0300 Message-ID: <49f2111f.02a1660a.2722.ffff9354@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E4_01C9C52A.B5D2D000" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGHOeBQAA3KHOAAAoZt4A== Content-Language: en-us Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 19:19:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00E4_01C9C52A.B5D2D000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bill, Since I have two hats here then as a WG chair, my intention is to ask the list to start this topic as a WG item Taking my WG chair off, my expectation is that a WG document will describe a solution that can be implemented while the current text does not specify how to make it work. I do not care if you write that RTP/RTCP mux MUST be used by the RS and supported by the RR and update the SDP in the example to specify that this is case. My personal preference is to have the RS indicate in the SDP that it wants to use multiplexing and to add a flag to RAMS-R that will indicate if RTP/RTCP mux is supported by RR and can be used. Only if the RR cannot support the multiplexing it should indicate it using the flag and add to the RAMS-R the transport address to be used (Note that it can be v4 or v6). SDP cannot be used since there is no SDP from RR to RS. Roni Even From: Bill Ver Steeg (versteb) [mailto:versteb@cisco.com] Sent: Friday, April 24, 2009 9:50 PM To: Roni Even; avt@ietf.org Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available Roni- Yes, the document needs updating in this respect. We have two broad options which need to be described in detail. The method that I have been assuming does use muxing. The RS sends the unicast burst back to the UDP port number on the RR that sent the RAMS-R. This allows transparent operation through NAT. There is a single UDP port, and the transaction is initiated by the "client", so it is NAT friendly. There are quite a few ways we could handle the case in which muxing is not used. We could add a parameter to the RAMS-R, use another RTCP packet in the same compound packet, define the port numbers as a relationship to the opened port (not attractive), or define something in the SDP (also not attractive). I personally like the "RAMS-R optional field" approach, but I think this should be a topic that we consider in detail once we have a WG item. bvs _____ From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Friday, April 24, 2009 7:24 AM To: avt@ietf.org Cc: Bill Ver Steeg (versteb) Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available Hi, I think that the current draft does not give a description of a system that works since there is no text explaining how the RS knows the unicast transport address on the RR to where to send the stream. If you mandate the use of RTP/RTCP mux it should say so otherwise the RAMS-R should have an optional parameter that supplies this information and a flag for using RTP/RTCP mux. Thanks Roni Even From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Bill Ver Steeg (versteb) Sent: Thursday, April 16, 2009 7:39 PM To: avt@ietf.org Subject: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available There is a new draft of the "Rapid Acquisition of Multicast RTP Sessions (RAMS)" draft available at http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-synchronization -for-rtp-03.txt We have incorporated the changes from the technical breakout session in San Francisco. The major changes in this version of the draft include 1- Changing the document title to avoid confusion with other ongoing "synchronization" drafts 2- changing the message names to reflect the title change 3- clarification of the RTCP message semantics, including changes to the "Request" and "Inform" messages 4- additional description/motivation for the various message flows has been added 5- RTP/RTCP muxing has been added We hope to make this a Working Group item, and will change the name of the draft to avoid conflicts with other "synchronization" drafts at that time. Bill VerSteeg ------=_NextPart_000_00E4_01C9C52A.B5D2D000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bill,

 

Since I have two hats here then as a WG chair, my = intention is to ask the list to start this topic as a WG item

 

Taking my WG chair off, my expectation is that a WG = document will describe a solution that can be implemented while the current text does = not specify how to make it work. I do not care if you write that RTP/RTCP mux MUST = be used by the RS and supported by the RR and update the SDP in the example to = specify that this is case.  

 

My personal preference is to have the RS indicate in the = SDP that it wants to use multiplexing and to add a flag to RAMS-R that will indicate if RTP/RTCP mux is supported by RR and can be used. Only if the = RR cannot support the multiplexing it should indicate it using the flag and add to = the RAMS-R the transport address to be used (Note that it can be v4 or = v6).

SDP cannot be used since there is no SDP from RR to = RS.

 

Roni Even

 

From:= Bill Ver = Steeg (versteb) [mailto:versteb@cisco.com]
Sent: Friday, April 24, 2009 9:50 PM
To: Roni Even; avt@ietf.org
Subject: RE: [AVT] New draft of "Rapid Acquisition of = Multicast RTP Sessions (RAMS)" available

 

Roni-

 

Yes, the document needs updating in this respect. We have = two broad options which need to be described in detail.

 

The method that I have been assuming does use muxing. = The RS sends the unicast burst back to the UDP port number on the RR that sent = the RAMS-R. This allows transparent operation through NAT. There is a single = UDP port, and the transaction is initiated by the "client", so it = is NAT friendly.

 

There are quite a few ways we could handle the case in which = muxing is not used. We could add a parameter to the RAMS-R, use another RTCP = packet in the same compound packet, define the port numbers as a relationship to = the opened port (not attractive), or define something in the SDP (also not attractive). I personally like the "RAMS-R optional field" = approach, but I think this should be a topic that we consider in detail once we = have a WG item.

 

 

 

 

bvs

 

 

From: Roni Even = [mailto:ron.even.tlv@gmail.com]
Sent: Friday, April 24, 2009 7:24 AM
To: avt@ietf.org
Cc: Bill Ver Steeg (versteb)
Subject: RE: [AVT] New draft of "Rapid Acquisition of = Multicast RTP Sessions (RAMS)" available

Hi,

I think that the current draft does not give a = description of a system that works since there is no text explaining how the RS knows the unicast transport address on the RR to where to send the stream. =

If you mandate the use of RTP/RTCP mux it should say so otherwise the RAMS-R should have an optional parameter that supplies = this information and a flag for using RTP/RTCP mux.

Thanks

Roni Even

 

From:= avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Bill Ver Steeg (versteb)
Sent: Thursday, April 16, 2009 7:39 PM
To: avt@ietf.org
Subject: [AVT] New draft of "Rapid Acquisition of Multicast = RTP Sessions (RAMS)" available

 

There is a new draft of the "Rapid Acquisition of Multicast RTP Sessions (RAMS)" draft available at http://www.ietf.org/internet-drafts/draft-versteeg-avt-ra= pid-synchronization-for-rtp-03.txt

 

We have incorporated the changes from the technical breakout session = in San Francisco. The major changes in this version of the draft include =

1- Changing the document title to avoid confusion with other ongoing "synchronization" drafts

2- changing the message names to reflect the title = change

3- clarification of the RTCP message semantics, including changes to the "Request" and "Inform" = messages

4- additional description/motivation for the various message flows has been = added

5- RTP/RTCP muxing has been added

 

 

We hope to make this a Working Group item, and will change the name of the = draft to avoid conflicts with other "synchronization" drafts at that = time.

 

Bill VerSteeg

 

 

------=_NextPart_000_00E4_01C9C52A.B5D2D000-- From ron.even.tlv@gmail.com Fri Apr 24 12:23:28 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 523563A6C2C for ; Fri, 24 Apr 2009 12:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.257 X-Spam-Level: X-Spam-Status: No, score=-1.257 tagged_above=-999 required=5 tests=[AWL=-1.058, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdFjbhYujMFQ for ; Fri, 24 Apr 2009 12:23:27 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by core3.amsl.com (Postfix) with ESMTP id C9A983A6966 for ; Fri, 24 Apr 2009 12:23:26 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 18so570840fkq.5 for ; Fri, 24 Apr 2009 12:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=10tJmQABZAAKedI50p3HCSETwOdAStVieCRtX/kEmn8=; b=wMi4oJz2Z5y7YzPcG7X8c4q8HizNjlk3AwBJCAhKWjqf650WLmCXs3hz3vdi+LShs+ 3ASnqYrssKc3apbyTk7YjGuAFPseQg24L/fxoOU6u63SpabozHe/NOEXJ079K6BjmCdw NkNEx8iNe+svsAzUQjJfRADoLKKJEyEOWFvFk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=t/OujTbpXiQhT+1ioLnhfZ1fgwzwCP/iYFtjQxLIK2wjJLhTZk2J5ZG3q9leO4e/aF dgrCU9ibYgW9+iW2u8XXMh+fZjRncw70Ws5XZaoBW6Y9BCEK17YaGdH+oWVe5MvwuiNa tWaTRX0AE4BISI0G3YasdoKms/1Yp8dY4nkR8= Received: by 10.103.222.1 with SMTP id z1mr1469418muq.121.1240601084816; Fri, 24 Apr 2009 12:24:44 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-121-32.red.bezeqint.net [79.179.121.32]) by mx.google.com with ESMTPS id n7sm4148287mue.42.2009.04.24.12.24.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 24 Apr 2009 12:24:44 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> Date: Fri, 24 Apr 2009 22:22:37 +0300 Message-ID: <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGHOeBQAAroqxAABGe0AAAAUgbQAAEZLVA= Content-Language: en-us Cc: "'Bill Ver Steeg \(versteb\)'" Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 19:23:28 -0000 Ali, I think you get it wrong, this SDP is from the RS and not the RR so the RS cannot specify to which address it will send it can only specify to which address it can receive RTP stream. In this SDP the relevant information is that the request for retransmission will be sent by the RR to port 41003 Roni -----Original Message----- From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] Sent: Friday, April 24, 2009 10:01 PM To: Roni Even; avt@ietf.org Cc: Bill Ver Steeg (versteb) Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available Oh, I see. The burst goes to the port that we would normally send the retransmissions. For example, consider the SDP from the draft: m=video 41000 RTP/AVPF 98 i=Primary Multicast Stream #2 c=IN IP4 224.1.1.2/255 a=source-filter: incl IN IP4 224.1.1.2 192.0.2.2 a=rtpmap:98 MP2T/90000 a=rtcp:41001 IN IP4 192.0.2.1 a=rtcp-fb:98 nack a=rtcp-fb:98 nack ssli a=ssrc:123321 cname:iptv-ch32@rams.example.com a=mid:3 m=video 41002 RTP/AVPF 99 i=Unicast Retransmission Stream #2 (Ret. and Rapid Acq. Support) c=IN IP4 192.0.2.1 a=recvonly a=rtpmap:99 rtx/90000 a=rtcp:41003 a=fmtp:99 apt=98; rtx-time=5000 a=mid:4 In this case, the burst will go to port 41002 on the RR. The RAMS-I message(s), which is an RTCP feedback message, will go to port 41003. HTH, -acbegen > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Friday, April 24, 2009 11:44 AM > To: Ali C. Begen (abegen); avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of > Multicast RTPSessions (RAMS)" available > > Ali, > I will try to explain in simple way > > When the RS receives the RAMS-R it need to start sending an > RTP stream to > the RR. > In order to send a unicast packet, the RS needs to know a > transport address > on the RR to where the RTP stream will be sent. The current > draft does not > say how the RS knows this address. There is no SDP from RR to > RS like you > mention in your response. > This is why I say that the current draft does not specify a > solution that > can be implemented as a working solution > Roni > > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Friday, April 24, 2009 7:38 PM > To: Roni Even; avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of > Multicast RTPSessions > (RAMS)" available > > Hi Roni, > > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > Behalf Of Roni Even > > Sent: Friday, April 24, 2009 4:24 AM > > To: avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: Re: [AVT] New draft of "Rapid Acquisition of > > Multicast RTPSessions (RAMS)" available > > > > Hi, > > > > I think that the current draft does not give a description of > > a system that works since there is no text explaining how the > > What do you mean by "a system that works"? > > > RS knows the unicast transport address on the RR to where to > > send the stream. > > Once RS receives the request packet from an RR, RS knows its > address. Ports > are defined in the SDP. If you are asking about "NAT" issues, > we have a > section for it, and we plan to complete it as we move > forward. It is not as > critical as the other parts for now. > > > If you mandate the use of RTP/RTCP mux it should say so > > otherwise the RAMS-R should have an optional parameter that > > supplies this information and a flag for using RTP/RTCP mux. > > IMO, we cannot mandate muxing as it is not required to make > RAMS work. If > muxing is supported, the SDP should reflect it. > > BR, > -acbegen > > > Thanks > > > > Roni Even > > > > > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > Behalf Of Bill Ver Steeg (versteb) > > Sent: Thursday, April 16, 2009 7:39 PM > > To: avt@ietf.org > > Subject: [AVT] New draft of "Rapid Acquisition of Multicast > > RTP Sessions (RAMS)" available > > > > > > > > There is a new draft of the "Rapid Acquisition of Multicast > > RTP Sessions (RAMS)" draft available at > > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s > ynchronization-for-rtp-03.txt > drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt> > > > > > > > > We have incorporated the changes from the technical breakout > > session in San Francisco. The major changes in this version > > of the draft include > > > > 1- Changing the document title to avoid confusion with other > > ongoing "synchronization" drafts > > > > 2- changing the message names to reflect the title change > > > > 3- clarification of the RTCP message semantics, including > > changes to the "Request" and "Inform" messages > > > > 4- additional description/motivation for the various message > > flows has been added > > > > 5- RTP/RTCP muxing has been added > > > > > > > > > > > > We hope to make this a Working Group item, and will change > > the name of the draft to avoid conflicts with other > > "synchronization" drafts at that time. > > > > > > > > Bill VerSteeg > > > > > > > > > > > > > > From ron.even.tlv@gmail.com Fri Apr 24 12:32:23 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D8953A697F; Fri, 24 Apr 2009 12:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FA9QJ4A5DG3m; Fri, 24 Apr 2009 12:32:22 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 1E7563A688F; Fri, 24 Apr 2009 12:32:21 -0700 (PDT) Received: by bwz7 with SMTP id 7so1266370bwz.37 for ; Fri, 24 Apr 2009 12:33:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=cGju+VpuBmCHQU/5qsmxPBPNF2QsKu8pYJ7gWw+a8jk=; b=v6BtwB9st/u/Sp95qq1S0jxAJzgqgM4WXDifwoRGCsgI2E4rDNMVPo5WWbqRhGUMxv Y2rHBljpUtsCFtS4Z/Mn6zSXqeCkxJh5YTQJuSft4RS29PBgWG9t8tcpM6F6RndMMs/d /vOfqm6A5YO+dJhBiK9zVMfGAYe0n6GjGtFDk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=br7STxkN0VB0OkSqYWFFl82lFlo30hVfgfD6CRsjaim1oOS0fUtdzw8XmiuJNF1xrZ x4G8Ijy2Krc682i97GFNcKvwmrJwMbHJLnZOC3T6QK4lO1FLQAZ5oHZHDmH8lDWMqtH3 5kmqMvcbN7FAhlonGpqCSSc6ZhanvyHCHU53I= Received: by 10.103.160.9 with SMTP id m9mr1470399muo.96.1240601619925; Fri, 24 Apr 2009 12:33:39 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-121-32.red.bezeqint.net [79.179.121.32]) by mx.google.com with ESMTPS id n7sm4175456mue.42.2009.04.24.12.33.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 24 Apr 2009 12:33:39 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , References: <04CAD96D4C5A3D48B1919248A8FE0D54091BAA88@xmb-sjc-215.amer.cisco.com> <49f1cd82.15185e0a.0fc3.ffffb9e7@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80EF@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C80EF@xmb-sjc-215.amer.cisco.com> Date: Fri, 24 Apr 2009 22:31:39 +0300 Message-ID: <49f21413.07a5660a.3f7f.ffff99e5@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnAaI0k+CHA6Xe+Sfy0BV96KkoCXgAAB9bAAR8Fr7AABY9UAAAF8PqA Content-Language: en-us Cc: avt@ietf.org Subject: Re: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 19:32:23 -0000 Ali, I am a bit confused about your answer, I assume that FEC framework you refer to draft-ietf-fecframe-framework-03, at least I cold not see any reference in the draft to a document. In section 4 of the above draft it says " In the case that RTP is used for the repair flows, the source and repair data may be multiplexed using RTP onto a single UDP flow and must consequently be demultiplexed at the receiver." Roni > 6. In section 7 you discuss an exchange using grouping. Is it > also allowed > to use FEC withoutout grouping using the video or audio media > types like > section 14 in RFC 5109 Per FEC framework, we require the FEC to be in a separate flow, which requires the source and FEC streams to be on different RTP sessions. Thus, we require grouping (RFC 4756 or 4756bis) In the case that RTP is used for the repair flows, the source and repair data may be multiplexed using RTP onto a single UDP flow and must consequently be demultiplexed at the receiver. From abegen@cisco.com Fri Apr 24 12:37:38 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE0B73A68C1 for ; Fri, 24 Apr 2009 12:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.259 X-Spam-Level: X-Spam-Status: No, score=-5.259 tagged_above=-999 required=5 tests=[AWL=-1.060, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptiNdBE7Th1n for ; Fri, 24 Apr 2009 12:37:37 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 414133A6E7C for ; Fri, 24 Apr 2009 12:35:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,243,1238976000"; d="scan'208";a="73243067" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 24 Apr 2009 19:37:07 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3OJb7Gn014412; Fri, 24 Apr 2009 12:37:07 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3OJb7IG014236; Fri, 24 Apr 2009 19:37:07 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 12:37:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Apr 2009 12:37:06 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available Thread-Index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGHOeBQAAroqxAABGe0AAAAUgbQAAEZLVAAAGk5sA== References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , X-OriginalArrivalTime: 24 Apr 2009 19:37:07.0074 (UTC) FILETIME=[0D593E20:01C9C514] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6844; t=1240601827; x=1241465827; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20New=20draft=20of=20=22Rapid=20A cquisition=20of=20Multicast=20RTPSessions=09(RAMS)=22=20avai lable |Sender:=20; bh=+T80GWONKLcMPTH56dhaM/DEahStYJPLKLGqCCGpfJw=; b=tZg7LKYKaLxkTmabJpqYMz6poia9tNA3y3AfCc2uhEf9LBSWjpjR+LHWD0 DP9rUC/WHAIVWTtE6/TxLVVjaeVmBE08HvHKx7qWcS7kb8cHxr0JnMGV08w9 ucyGdIO43lykGlK5EhYUEFFI6+5NSPlgdvXb398vhJ41kNah7v2tc=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "Bill Ver Steeg \(versteb\)" Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 19:37:38 -0000 This is a part of an example SDP sent to RS and RR in a SAP = announcement, for example. So, the SDP describes what both parties = should do (RR cannot say that he wants to receive this multicast on its = favorite port). The individual SDPs sent to RR or RS may include other = portions of descriptions that will contain specific information.=20 -acbegen > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > Sent: Friday, April 24, 2009 12:23 PM > To: Ali C. Begen (abegen); avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > Multicast RTPSessions (RAMS)" available >=20 > Ali, > I think you get it wrong, this SDP is from the RS and not the=20 > RR so the RS > cannot specify to which address it will send it can only=20 > specify to which > address it can receive RTP stream. In this SDP the relevant=20 > information is > that the request for retransmission will be sent by the RR to=20 > port 41003 > Roni >=20 > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > Sent: Friday, April 24, 2009 10:01 PM > To: Roni Even; avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > Multicast RTPSessions > (RAMS)" available >=20 > Oh, I see. The burst goes to the port that we would normally send the > retransmissions. For example, consider the SDP from the draft: >=20 > m=3Dvideo 41000 RTP/AVPF 98 > i=3DPrimary Multicast Stream #2 > c=3DIN IP4 224.1.1.2/255 > a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 > a=3Drtpmap:98 MP2T/90000 > a=3Drtcp:41001 IN IP4 192.0.2.1 > a=3Drtcp-fb:98 nack > a=3Drtcp-fb:98 nack ssli > a=3Dssrc:123321 cname:iptv-ch32@rams.example.com > a=3Dmid:3 > m=3Dvideo 41002 RTP/AVPF 99 > i=3DUnicast Retransmission Stream #2 (Ret. and Rapid=20 > Acq. Support) > c=3DIN IP4 192.0.2.1 > a=3Drecvonly > a=3Drtpmap:99 rtx/90000 > a=3Drtcp:41003 > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > a=3Dmid:4 >=20 > In this case, the burst will go to port 41002 on the RR. The RAMS-I > message(s), which is an RTCP feedback message, will go to port 41003. >=20 > HTH, > -acbegen >=20 > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > > Sent: Friday, April 24, 2009 11:44 AM > > To: Ali C. Begen (abegen); avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > Multicast RTPSessions (RAMS)" available > >=20 > > Ali, > > I will try to explain in simple way > >=20 > > When the RS receives the RAMS-R it need to start sending an=20 > > RTP stream to > > the RR.=20 > > In order to send a unicast packet, the RS needs to know a=20 > > transport address > > on the RR to where the RTP stream will be sent. The current=20 > > draft does not > > say how the RS knows this address. There is no SDP from RR to=20 > > RS like you > > mention in your response. > > This is why I say that the current draft does not specify a=20 > > solution that > > can be implemented as a working solution > > Roni > >=20 > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > > Sent: Friday, April 24, 2009 7:38 PM > > To: Roni Even; avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > Multicast RTPSessions > > (RAMS)" available > >=20 > > Hi Roni,=20 > >=20 > > > -----Original Message----- > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > > > Behalf Of Roni Even > > > Sent: Friday, April 24, 2009 4:24 AM > > > To: avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: Re: [AVT] New draft of "Rapid Acquisition of=20 > > > Multicast RTPSessions (RAMS)" available > > >=20 > > > Hi, > > >=20 > > > I think that the current draft does not give a description of=20 > > > a system that works since there is no text explaining how the=20 > >=20 > > What do you mean by "a system that works"?=20 > >=20 > > > RS knows the unicast transport address on the RR to where to=20 > > > send the stream.=20 > >=20 > > Once RS receives the request packet from an RR, RS knows its=20 > > address. Ports > > are defined in the SDP. If you are asking about "NAT" issues,=20 > > we have a > > section for it, and we plan to complete it as we move=20 > > forward. It is not as > > critical as the other parts for now. > > =20 > > > If you mandate the use of RTP/RTCP mux it should say so=20 > > > otherwise the RAMS-R should have an optional parameter that=20 > > > supplies this information and a flag for using RTP/RTCP mux. > >=20 > > IMO, we cannot mandate muxing as it is not required to make=20 > > RAMS work. If > > muxing is supported, the SDP should reflect it. > >=20 > > BR, > > -acbegen > > =20 > > > Thanks > > >=20 > > > Roni Even > > >=20 > > > =20 > > >=20 > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > > > Behalf Of Bill Ver Steeg (versteb) > > > Sent: Thursday, April 16, 2009 7:39 PM > > > To: avt@ietf.org > > > Subject: [AVT] New draft of "Rapid Acquisition of Multicast=20 > > > RTP Sessions (RAMS)" available > > >=20 > > > =20 > > >=20 > > > There is a new draft of the "Rapid Acquisition of Multicast=20 > > > RTP Sessions (RAMS)" draft available at=20 > > > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s > > ynchronization-for-rtp-03.txt > > drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt>=20 > > >=20 > > > =20 > > >=20 > > > We have incorporated the changes from the technical breakout=20 > > > session in San Francisco. The major changes in this version=20 > > > of the draft include=20 > > >=20 > > > 1- Changing the document title to avoid confusion with other=20 > > > ongoing "synchronization" drafts > > >=20 > > > 2- changing the message names to reflect the title change > > >=20 > > > 3- clarification of the RTCP message semantics, including=20 > > > changes to the "Request" and "Inform" messages > > >=20 > > > 4- additional description/motivation for the various message=20 > > > flows has been added > > >=20 > > > 5- RTP/RTCP muxing has been added > > >=20 > > > =20 > > >=20 > > > =20 > > >=20 > > > We hope to make this a Working Group item, and will change=20 > > > the name of the draft to avoid conflicts with other=20 > > > "synchronization" drafts at that time. > > >=20 > > > =20 > > >=20 > > > Bill VerSteeg > > >=20 > > > =20 > > >=20 > > > =20 > > >=20 > > >=20 > >=20 > >=20 >=20 >=20 From versteb@cisco.com Fri Apr 24 12:37:39 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B87D03A6E14 for ; Fri, 24 Apr 2009 12:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFaty-bYPtbR for ; Fri, 24 Apr 2009 12:37:38 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 539E33A697F for ; Fri, 24 Apr 2009 12:35:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,243,1238976000"; d="scan'208,217";a="42599123" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 24 Apr 2009 19:37:12 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3OJbCak026625; Fri, 24 Apr 2009 15:37:12 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3OJbCLQ017286; Fri, 24 Apr 2009 19:37:12 GMT Received: from xmb-rtp-21d.amer.cisco.com ([64.102.31.116]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 15:37:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C514.107473A7" Date: Fri, 24 Apr 2009 15:37:11 -0400 Message-ID: <81B9B88E2F9D574AA5328A85547CDE91011534E2@xmb-rtp-21d.amer.cisco.com> In-Reply-To: <49f2111f.02a1660a.2722.ffff9354@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available Thread-Index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGHOeBQAA3KHOAAAoZt4AAA3/cQ References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com><49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com><81B9B88E2F9D574AA5328A85547CDE9101153491@xmb-rtp-21d.amer.cisco.com> <49f2111f.02a1660a.2722.ffff9354@mx.google.com> From: "Bill Ver Steeg (versteb)" To: "Roni Even" , X-OriginalArrivalTime: 24 Apr 2009 19:37:12.0544 (UTC) FILETIME=[109BE600:01C9C514] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=20260; t=1240601832; x=1241465832; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=versteb@cisco.com; z=From:=20=22Bill=20Ver=20Steeg=20(versteb)=22=20 |Subject:=20RE=3A=20[AVT]=20New=20draft=20of=20=22Rapid=20A cquisition=20of=20Multicast=20RTPSessions=09(RAMS)=22=20avai lable |Sender:=20 |To:=20=22Roni=20Even=22=20,=20; bh=r23kn8W+gfEna//0x1bubop9OWEb+NGMraGkcyxCit8=; b=XdxzHJ6ptID8eKbR3xov50zaCqp+OOntuK72pCGTyFh1KhH3OhyPZ/hbT3 faqc+2Q01r76iR1Yg9ZxIyVY4Rt1f4ACqOjpCd9OmfVoXC79sitiiUwxiDeH CBCtNNpqw5; Authentication-Results: rtp-dkim-1; header.From=versteb@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 19:37:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C514.107473A7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Roni- =20 These are reasonable approaches, which I need to consider in detail. I have (mostly) been thinking about NAT-friendly solutions, which leads me back to muxing. I need to consider the ramifications of NAT on the methods that signal IP addresses and port numbers as part of the run-time for acceleration. The intent is to make acquisition faster, and additional complexity at session instantiation should be avoided (IMHO). =20 More to come, once I get my head around the various options. =20 bvs =20 ________________________________ From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even Sent: Friday, April 24, 2009 3:19 PM To: Bill Ver Steeg (versteb); avt@ietf.org Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available Bill, =20 Since I have two hats here then as a WG chair, my intention is to ask the list to start this topic as a WG item =20 Taking my WG chair off, my expectation is that a WG document will describe a solution that can be implemented while the current text does not specify how to make it work. I do not care if you write that RTP/RTCP mux MUST be used by the RS and supported by the RR and update the SDP in the example to specify that this is case. =20 =20 My personal preference is to have the RS indicate in the SDP that it wants to use multiplexing and to add a flag to RAMS-R that will indicate if RTP/RTCP mux is supported by RR and can be used. Only if the RR cannot support the multiplexing it should indicate it using the flag and add to the RAMS-R the transport address to be used (Note that it can be v4 or v6). SDP cannot be used since there is no SDP from RR to RS. =20 Roni Even =20 From: Bill Ver Steeg (versteb) [mailto:versteb@cisco.com]=20 Sent: Friday, April 24, 2009 9:50 PM To: Roni Even; avt@ietf.org Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available =20 Roni- =20 Yes, the document needs updating in this respect. We have two broad options which need to be described in detail. =20 The method that I have been assuming does use muxing. The RS sends the unicast burst back to the UDP port number on the RR that sent the RAMS-R. This allows transparent operation through NAT. There is a single UDP port, and the transaction is initiated by the "client", so it is NAT friendly. =20 There are quite a few ways we could handle the case in which muxing is not used. We could add a parameter to the RAMS-R, use another RTCP packet in the same compound packet, define the port numbers as a relationship to the opened port (not attractive), or define something in the SDP (also not attractive). I personally like the "RAMS-R optional field" approach, but I think this should be a topic that we consider in detail once we have a WG item. =20 =20 =20 =20 bvs =20 =20 ________________________________ From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 Sent: Friday, April 24, 2009 7:24 AM To: avt@ietf.org Cc: Bill Ver Steeg (versteb) Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available Hi, I think that the current draft does not give a description of a system that works since there is no text explaining how the RS knows the unicast transport address on the RR to where to send the stream.=20 If you mandate the use of RTP/RTCP mux it should say so otherwise the RAMS-R should have an optional parameter that supplies this information and a flag for using RTP/RTCP mux. Thanks Roni Even =20 From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Bill Ver Steeg (versteb) Sent: Thursday, April 16, 2009 7:39 PM To: avt@ietf.org Subject: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available =20 There is a new draft of the "Rapid Acquisition of Multicast RTP Sessions (RAMS)" draft available at http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-synchroniza tion-for-rtp-03.txt =20 =20 We have incorporated the changes from the technical breakout session in San Francisco. The major changes in this version of the draft include=20 1- Changing the document title to avoid confusion with other ongoing "synchronization" drafts 2- changing the message names to reflect the title change 3- clarification of the RTCP message semantics, including changes to the "Request" and "Inform" messages 4- additional description/motivation for the various message flows has been added 5- RTP/RTCP muxing has been added =20 =20 We hope to make this a Working Group item, and will change the name of the draft to avoid conflicts with other "synchronization" drafts at that time. =20 Bill VerSteeg =20 =20 ------_=_NextPart_001_01C9C514.107473A7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Roni-
 
These are reasonable approaches, which I need = to consider=20 in detail. I have (mostly) been thinking about NAT-friendly solutions, = which=20 leads me back to muxing. I need to consider the ramifications of NAT on = the=20 methods that signal IP addresses and port numbers as part of the = run-time for=20 acceleration. The intent is to make acquisition faster, and additional=20 complexity at session instantiation should be avoided=20 (IMHO).
 
More to come, once I get my head around the = various=20 options.
 
bvs
 

From: avt-bounces@ietf.org=20 [mailto:avt-bounces@ietf.org] On Behalf Of Roni = Even
Sent:=20 Friday, April 24, 2009 3:19 PM
To: Bill Ver Steeg (versteb);=20 avt@ietf.org
Subject: Re: [AVT] New draft of "Rapid = Acquisition of=20 Multicast RTPSessions (RAMS)" available

Bill,

 

Since=20 I have two hats here then as a WG chair, my intention is to ask the list = to=20 start this topic as a WG item

 

Taking=20 my WG chair off, my expectation is that a WG document will describe a = solution=20 that can be implemented while the current text does not specify how to = make it=20 work. I do not care if you write that RTP/RTCP mux MUST be used by the = RS and=20 supported by the RR and update the SDP in the example to specify that = this is=20 case.  

 

My=20 personal preference is to have the RS indicate in the SDP that it wants = to use=20 multiplexing and to add a flag to RAMS-R that will indicate if RTP/RTCP = mux is=20 supported by RR and can be used. Only if the RR cannot support the = multiplexing=20 it should indicate it using the flag and add to the RAMS-R the transport = address=20 to be used (Note that it can be v4 or v6).

SDP=20 cannot be used since there is no SDP from RR to = RS.

 

Roni=20 Even

 

From: Bill Ver = Steeg=20 (versteb) [mailto:versteb@cisco.com]
Sent: Friday, April 24, = 2009=20 9:50 PM
To: Roni Even; avt@ietf.org
Subject: RE: = [AVT] New=20 draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)"=20 available

 

Roni-

 

Yes, the=20 document needs updating in this respect. We have two broad options which = need to=20 be described in detail.

 

The=20 method that I have been assuming does use muxing. The RS sends the = unicast=20 burst back to the UDP port number on the RR that sent the RAMS-R. This = allows=20 transparent operation through NAT. There is a single UDP port, and the=20 transaction is initiated by the "client", so it is NAT=20 friendly.

 

There=20 are quite a few ways we could handle the case in which muxing is not = used. We=20 could add a parameter to the RAMS-R, use another RTCP packet in the same = compound packet, define the port numbers as a relationship to the opened = port=20 (not attractive), or define something in the SDP (also not attractive). = I=20 personally like the "RAMS-R optional field" approach, but I think this = should be=20 a topic that we consider in detail once we have a WG = item.

 

 

 

 

bvs

 

 

From: Roni Even = [mailto:ron.even.tlv@gmail.com]
Sent: Friday, April 24, 2009 = 7:24=20 AM
To: avt@ietf.org
Cc: Bill Ver Steeg=20 (versteb)
Subject: RE: [AVT] New draft of "Rapid Acquisition = of=20 Multicast RTP Sessions (RAMS)" available

Hi,

I=20 think that the current draft does not give a description of a system = that works=20 since there is no text explaining how the RS knows the unicast transport = address=20 on the RR to where to send the stream.

If=20 you mandate the use of RTP/RTCP mux it should say so otherwise the = RAMS-R should=20 have an optional parameter that supplies this information and a flag for = using=20 RTP/RTCP mux.

Thanks

Roni=20 Even

 

From:=20 avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Bill Ver=20 Steeg (versteb)
Sent: Thursday, April 16, 2009 7:39 = PM
To:=20 avt@ietf.org
Subject: [AVT] New draft of "Rapid Acquisition of = Multicast RTP Sessions (RAMS)" = available

 

There is a = new draft=20 of the "Rapid Acquisition of Multicast RTP Sessions (RAMS)" draft = available at=20 http://www.ietf.org/internet-drafts/draft-versteeg-avt-ra= pid-synchronization-for-rtp-03.txt

=

 

We=20 have incorporated the changes from the technical breakout session = in San=20 Francisco. The major changes in this version of the draft include=20

1- Changing = the=20 document title to avoid confusion with other ongoing "synchronization"=20 drafts

2- changing = the=20 message names to reflect the title change

3- = clarification of=20 the RTCP message semantics, including changes to the "Request" = and=20 "Inform" messages

4- = additional=20 description/motivation for the various message flows has been=20 added

5- RTP/RTCP = muxing=20 has been added

 

 

We hope to = make this=20 a Working Group item, and will change the name of the draft to avoid = conflicts=20 with other "synchronization" drafts at that = time.

 

Bill=20 VerSteeg

 

 

------_=_NextPart_001_01C9C514.107473A7-- From abegen@cisco.com Fri Apr 24 12:37:40 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A718C3A6F95; Fri, 24 Apr 2009 12:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.434 X-Spam-Level: X-Spam-Status: No, score=-6.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHVNp+TW3bCO; Fri, 24 Apr 2009 12:37:39 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D012E3A68AB; Fri, 24 Apr 2009 12:37:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,243,1238976000"; d="scan'208";a="292462426" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 24 Apr 2009 19:38:36 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3OJcaYM014489; Fri, 24 Apr 2009 12:38:36 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3OJcaWL017061; Fri, 24 Apr 2009 19:38:36 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 12:38:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Apr 2009 12:38:34 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C8204@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49f20d5d.1f205e0a.2719.fffffab1@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 Thread-Index: AcnAaI0k+CHA6Xe+Sfy0BV96KkoCXgAAB9bAAR8Fr7AABY9UAAAE5sqQAABiiFA= References: <04CAD96D4C5A3D48B1919248A8FE0D54091BAA88@xmb-sjc-215.amer.cisco.com> <49f1cd82.15185e0a.0fc3.ffffb9e7@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80EF@xmb-sjc-215.amer.cisco.com> <49f20d5d.1f205e0a.2719.fffffab1@mx.google.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , X-OriginalArrivalTime: 24 Apr 2009 19:38:36.0761 (UTC) FILETIME=[42CE6490:01C9C514] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=949; t=1240601916; x=1241465916; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20FW=3A=20New=20Version=20Notific ation=20for=09draft-ietf-fecframe-interleaved-fec-scheme-03 |Sender:=20; bh=pSdmVm6WLoeK5WekIXjVjkc3Q+D7Q+p+2m2pE8wPY7U=; b=n/jf5xPZUJYiwb0urc9IBebDDDkBWucTELQsg5TyXfzZvETjYeMoGupQdB AZT90eT+7aURvNg3aeXV0n/wfPTTo+CkQzvij3u2qO+T/YDAgFKWVNzoQb9i hdpkrR+gX7; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: avt@ietf.org Subject: Re: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 19:37:40 -0000 > > 6. In section 7 you discuss an exchange using grouping. Is it=20 > > also allowed > > to use FEC withoutout grouping using the video or audio media=20 > > types like > > section 14 in RFC 5109 >=20 > Per FEC framework, we require the FEC to be in a separate flow, which > requires the source and FEC streams to be on different RTP=20 > sessions. Thus, > we require grouping (RFC 4756 or 4756bis) >=20 > RE- I will have to look at that draft, this is different from=20 > RFC 5109 and > RFC 2733 Actually, we might be supporting SSRC multiplexing in the fec framework = (see my email sent today to fecframe/mmusic about this topic), since = there are some use cases for it. It does bring up other issues, though. = I would be glad to hear your comments. There are also some issues with RFC 5109 regarding SSRC multiplexing as = you mentioned in one of your earlier emails that may need to be = addressed. BR, -acbegen From abegen@cisco.com Fri Apr 24 12:45:25 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57D2A3A6B42; Fri, 24 Apr 2009 12:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.438 X-Spam-Level: X-Spam-Status: No, score=-6.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXiTqmPVDeiI; Fri, 24 Apr 2009 12:45:24 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 518FF3A68C1; Fri, 24 Apr 2009 12:45:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,243,1238976000"; d="scan'208";a="73246472" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 24 Apr 2009 19:46:43 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3OJkheN031881; Fri, 24 Apr 2009 12:46:43 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3OJkhjj021348; Fri, 24 Apr 2009 19:46:43 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 12:46:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Apr 2009 12:46:40 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C820A@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49f21413.07a5660a.3f7f.ffff99e5@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 Thread-Index: AcnAaI0k+CHA6Xe+Sfy0BV96KkoCXgAAB9bAAR8Fr7AABY9UAAAF8PqAAABmxsA= References: <04CAD96D4C5A3D48B1919248A8FE0D54091BAA88@xmb-sjc-215.amer.cisco.com> <49f1cd82.15185e0a.0fc3.ffffb9e7@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80EF@xmb-sjc-215.amer.cisco.com> <49f21413.07a5660a.3f7f.ffff99e5@mx.google.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , X-OriginalArrivalTime: 24 Apr 2009 19:46:43.0227 (UTC) FILETIME=[64C336B0:01C9C515] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1695; t=1240602403; x=1241466403; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20FW=3A=20New=20Version=20Notific ation=20for=09draft-ietf-fecframe-interleaved-fec-scheme-03 |Sender:=20; bh=Hb0If4wtetRF/51WMkhtrk6uBaGQkQKyIlVi7ATZHDI=; b=LP+Y9UHzLzcrPU4EfNdu1wY09Zvknjp5uXaRbfjxmmLGCUrE1pbQWIdk4P JaIwq3Mft1R8otSE4saCoPG0xJumCk9WGmLe1o/KBeI2epf2dp3a5Z2iRIsw zGbV6rgjVhCom9W/60rPSHUVWxJFMoDKNhayP9v8V5RL5H7yM14n0=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: avt@ietf.org Subject: Re: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 19:45:25 -0000 Yes, that is the fecframework draft, and I raised exactly the same point = this morning in the fecframe/mmusic list when I noticed that text in the = draft. Please use that thread for that discussion.=20 -acbegen > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > Sent: Friday, April 24, 2009 12:32 PM > To: Ali C. Begen (abegen); fecframe@ietf.org > Cc: avt@ietf.org > Subject: RE: [AVT] FW: New Version Notification for=20 > draft-ietf-fecframe-interleaved-fec-scheme-03 >=20 > Ali, > I am a bit confused about your answer, I assume that FEC=20 > framework you refer > to draft-ietf-fecframe-framework-03, at least I cold not see=20 > any reference > in the draft to a document.=20 > In section 4 of the above draft it says=20 >=20 > " > In the case that RTP is used for the repair flows, the source=20 > and repair > data may be multiplexed using RTP onto a single UDP flow and must > consequently be demultiplexed at the receiver." >=20 >=20 > Roni >=20 >=20 > > 6. In section 7 you discuss an exchange using grouping. Is it=20 > > also allowed > > to use FEC withoutout grouping using the video or audio media=20 > > types like > > section 14 in RFC 5109 >=20 > Per FEC framework, we require the FEC to be in a separate flow, which > requires the source and FEC streams to be on different RTP=20 > sessions. Thus, > we require grouping (RFC 4756 or 4756bis) >=20 >=20 >=20 >=20 >=20 > In the case that RTP is used for the repair flows, the source=20 > and repair > data may be multiplexed using RTP onto a single UDP flow and must > consequently be demultiplexed at the receiver. >=20 >=20 From root@core3.amsl.com Fri Apr 24 14:00:01 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 46F333A6E0E; Fri, 24 Apr 2009 14:00:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090424210001.46F333A6E0E@core3.amsl.com> Date: Fri, 24 Apr 2009 14:00:01 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-atrac-family-22.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 21:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for Adaptive TRansform Acoustic Coding (ATRAC) Family Author(s) : J. Matsumoto, M. Hatanaka Filename : draft-ietf-avt-rtp-atrac-family-22.txt Pages : 35 Date : 2009-4-24 This document describes an RTP payload format for efficient and flexible transporting of audio data encoded with the Adaptive TRansform Audio Coding (ATRAC) family of codecs. Recent enhancements to the ATRAC family of codecs support high quality audio coding with multiple channels. The RTP payload format as presented in this document also includes support for data fragmentation, elementary redundancy measures, and a variation on scalable streaming. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-atrac-family-22.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-rtp-atrac-family-22.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-4-24135120.I-D@ietf.org> --NextPart-- From petithug@acm.org Fri Apr 24 16:30:06 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BC943A6B97 for ; Fri, 24 Apr 2009 16:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.967 X-Spam-Level: X-Spam-Status: No, score=-101.967 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_6CONS_WORD=0.356, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgeWW6-qLXb0 for ; Fri, 24 Apr 2009 16:30:05 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 7C55E3A6B42 for ; Fri, 24 Apr 2009 16:30:05 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 5313E6C98430; Fri, 24 Apr 2009 23:31:21 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 95AD06C9841E for ; Fri, 24 Apr 2009 23:31:18 +0000 (UTC) Message-ID: <49F24BC1.8080107@acm.org> Date: Fri, 24 Apr 2009 16:31:13 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [AVT] SDP attribute in rtcpssm-18 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 23:30:06 -0000 Section 10.1 of draft-ietf-avt-rtcpssm-18 states that '[a] new session level attribute MUST be used [...]: "rtcp-unicast"' but the IANA considerations section registers a media level only att-field named "unicast-rtcp". So which one should be used, and is it a media or a session level attribute? Thanks. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From tendyntu@huawei.com Fri Apr 24 18:32:51 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D283E3A67A6 for ; Fri, 24 Apr 2009 18:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.024 X-Spam-Level: X-Spam-Status: No, score=-0.024 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRt4Rk+ZSloH for ; Fri, 24 Apr 2009 18:32:51 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 791B63A63EC for ; Fri, 24 Apr 2009 18:32:50 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIM00CP4UJJCA@szxga03-in.huawei.com> for avt@ietf.org; Sat, 25 Apr 2009 09:23:43 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIM006VXUJJAR@szxga03-in.huawei.com> for avt@ietf.org; Sat, 25 Apr 2009 09:23:43 +0800 (CST) Received: from z61302 ([10.85.208.250]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIM00BBOUJH8M@szxml04-in.huawei.com> for avt@ietf.org; Sat, 25 Apr 2009 09:23:42 +0800 (CST) Date: Sat, 25 Apr 2009 09:23:41 +0800 From: Zou ZiXuan In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D54092C8066@xmb-sjc-215.amer.cisco.com> To: "'Ali C. Begen (abegen)'" , "'Bill Ver Steeg (versteb)'" , avt@ietf.org Message-id: <018d01c9c544$789b6e30$69d24a90$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGCYQgQAAvXoiAAFEyMYA== References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <014601c9c4c3$d6c56fa0$84504ee0$@com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8066@xmb-sjc-215.amer.cisco.com> Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 01:32:51 -0000 Hi, Ali, Thanks for your explanation. > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Friday, April 24, 2009 11:13 PM > To: Zou ZiXuan; Bill Ver Steeg (versteb); avt@ietf.org > Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions > (RAMS)" available > > Hi Zou, > > This is a very good question. Let me take a stab here. > > Per RFC 3550, each SSRC space has its own clock rate and seq numbering. > We include the SSRC in the RAMS request messages. > > There are different flavors of your scneario. Lets assume that we have two > RTP streams (audio and video). > > > Case 1: Different RTP sessions are transmitted over different mcast groups. > > Here, we run a different independent RAMS session for each RTP stream > that we want to rapidly acquire (they can run in parallel). Here one needs to > pay attention to how to use the shared bandwidth among different bursts, > though. > > Case 2: Different RTP sessions are transmitted over the same mcast group > (with different dest ports). > > Again, we run a different independent RAMS for each RTP stream (different > request for each, etc). But, one should keep in mind that the join times for the > all RAMS sessions need to be common as there is only one multicast. > > Case 3: One RTP session (same mcast group, same dest port) carrying both > audio and video (this is SSRC multiplexing). > > Similar to case 2, join time needs to be coordinated among different RAMS > sessions running for each RTP stream. Since we signal SSRC in the request > message and we have independent RAMS sessions, using different clock > rates is not an issue. > > Case 4: One RTP session, one SSRC with payload type multiplexing. This is > not recommended for many reasons. On top of that, different payloads with > different clock rates cannot be multiplexed in this fashion. So, I don't think this > will apply to our problem. > > HTH, > -acbegen > > > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > Behalf Of Zou ZiXuan > > Sent: Friday, April 24, 2009 3:03 AM > > To: Bill Ver Steeg (versteb); avt@ietf.org > > Subject: Re: [AVT] New draft of "Rapid Acquisition of > > Multicast RTP Sessions (RAMS)" available > > > > Hi, > > > > The burst duration (8 octets) in RAMS-I message is > > in a single RTP ticks. And I note that from draft-01 on, the > > solution is payload-independent (is my understanding > > correct?). So, for non-MEPG2-TS payload, for example, > > H.264-NAL where audio and video content are encapsulated > > separately in two RTP streams with different ticks, does the > > duration indicated by this single ticks still work? Which > > stream does this tick belong to? > > > > > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > Behalf Of Bill Ver Steeg (versteb) > > Sent: Friday, April 17, 2009 12:39 AM > > To: avt@ietf.org > > Subject: [AVT] New draft of "Rapid Acquisition of Multicast > > RTP Sessions (RAMS)" available > > > > > > > > There is a new draft of the "Rapid Acquisition of Multicast > > RTP Sessions (RAMS)" draft available at > > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s > ynchronization-for-rtp-03.txt > drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt> > > > > > > > > We have incorporated the changes from the technical breakout > > session in San Francisco. The major changes in this version > > of the draft include > > > > 1- Changing the document title to avoid confusion with other > > ongoing "synchronization" drafts > > > > 2- changing the message names to reflect the title change > > > > 3- clarification of the RTCP message semantics, including > > changes to the "Request" and "Inform" messages > > > > 4- additional description/motivation for the various message > > flows has been added > > > > 5- RTP/RTCP muxing has been added > > > > > > > > > > > > We hope to make this a Working Group item, and will change > > the name of the draft to avoid conflicts with other > > "synchronization" drafts at that time. > > > > > > > > Bill VerSteeg > > > > > > > > > > > > From ron.even.tlv@gmail.com Sat Apr 25 04:09:09 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7CDB3A68B0 for ; Sat, 25 Apr 2009 04:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.227 X-Spam-Level: X-Spam-Status: No, score=-1.227 tagged_above=-999 required=5 tests=[AWL=-1.028, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbH6Ly072fuP for ; Sat, 25 Apr 2009 04:09:08 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 573183A684E for ; Sat, 25 Apr 2009 04:09:08 -0700 (PDT) Received: by bwz7 with SMTP id 7so1481321bwz.37 for ; Sat, 25 Apr 2009 04:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=zpqU6QPbiwZkCTxJqTWJYrpmVRFb0AX2Jde2B3mjhPQ=; b=sGy2JMea3NaQH2hx9/Vd35ECkSFV02p70LANqE+XkKLYNQKwqNRAUgtxAPq7nmxYWX nXYQtF1c7n5UtuC9mrmsNQ5ew/awpSiLavQFZyUgzLGPQ5o0uL9rap1xvPeR4pJapTiB Wu4Tcw0IUcl8oRPupgpwiEdegjX33d/qSvGUQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=QzR+vqRiuZ+SHVG+as1IXgX6SVGvRO2XwQTa6vkc9SsahbkvDr/uS5S4QNDA5j3DFF 8SfBScWGxaZ6hLCxl5zajiizVGGPGtDw1rR+TDA+L2B0KQKFD3fo8iqjhbWoimMdensI mYjV86MG+11PMK4vhV8qMLylDDGeTRUhVuRro= Received: by 10.204.118.66 with SMTP id u2mr3021741bkq.132.1240657826796; Sat, 25 Apr 2009 04:10:26 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-121-32.red.bezeqint.net [79.179.121.32]) by mx.google.com with ESMTPS id g28sm4198533fkg.5.2009.04.25.04.10.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 25 Apr 2009 04:10:26 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> Date: Sat, 25 Apr 2009 14:08:27 +0300 Message-ID: <49f2efa2.1c215e0a.4454.ffffaf91@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGHOeBQAAroqxAABGe0AAAAUgbQAAEZLVAAAGk5sAAgqbUw Content-Language: en-us Cc: "'Bill Ver Steeg \(versteb\)'" Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 11:09:09 -0000 Ali, The example SDP is syntactically correct but it does not say that the rtp/rtcp mux will be used and it does not give the information to where the unicast stream will be sent when the RR sends a RAMS-R. I am not sure why the unicast stream m-line has a port number with an attribute of recvonly. What is the use case for that. The only information that the RR will need is the RTCP port on the RS to where to send the RAMS-R message. Roni -----Original Message----- From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] Sent: Friday, April 24, 2009 10:37 PM To: Roni Even; avt@ietf.org Cc: Bill Ver Steeg (versteb) Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available This is a part of an example SDP sent to RS and RR in a SAP announcement, for example. So, the SDP describes what both parties should do (RR cannot say that he wants to receive this multicast on its favorite port). The individual SDPs sent to RR or RS may include other portions of descriptions that will contain specific information. -acbegen > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Friday, April 24, 2009 12:23 PM > To: Ali C. Begen (abegen); avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of > Multicast RTPSessions (RAMS)" available > > Ali, > I think you get it wrong, this SDP is from the RS and not the > RR so the RS > cannot specify to which address it will send it can only > specify to which > address it can receive RTP stream. In this SDP the relevant > information is > that the request for retransmission will be sent by the RR to > port 41003 > Roni > > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Friday, April 24, 2009 10:01 PM > To: Roni Even; avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of > Multicast RTPSessions > (RAMS)" available > > Oh, I see. The burst goes to the port that we would normally send the > retransmissions. For example, consider the SDP from the draft: > > m=video 41000 RTP/AVPF 98 > i=Primary Multicast Stream #2 > c=IN IP4 224.1.1.2/255 > a=source-filter: incl IN IP4 224.1.1.2 192.0.2.2 > a=rtpmap:98 MP2T/90000 > a=rtcp:41001 IN IP4 192.0.2.1 > a=rtcp-fb:98 nack > a=rtcp-fb:98 nack ssli > a=ssrc:123321 cname:iptv-ch32@rams.example.com > a=mid:3 > m=video 41002 RTP/AVPF 99 > i=Unicast Retransmission Stream #2 (Ret. and Rapid > Acq. Support) > c=IN IP4 192.0.2.1 > a=recvonly > a=rtpmap:99 rtx/90000 > a=rtcp:41003 > a=fmtp:99 apt=98; rtx-time=5000 > a=mid:4 > > In this case, the burst will go to port 41002 on the RR. The RAMS-I > message(s), which is an RTCP feedback message, will go to port 41003. > > HTH, > -acbegen > > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > Sent: Friday, April 24, 2009 11:44 AM > > To: Ali C. Begen (abegen); avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > Multicast RTPSessions (RAMS)" available > > > > Ali, > > I will try to explain in simple way > > > > When the RS receives the RAMS-R it need to start sending an > > RTP stream to > > the RR. > > In order to send a unicast packet, the RS needs to know a > > transport address > > on the RR to where the RTP stream will be sent. The current > > draft does not > > say how the RS knows this address. There is no SDP from RR to > > RS like you > > mention in your response. > > This is why I say that the current draft does not specify a > > solution that > > can be implemented as a working solution > > Roni > > > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > Sent: Friday, April 24, 2009 7:38 PM > > To: Roni Even; avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > Multicast RTPSessions > > (RAMS)" available > > > > Hi Roni, > > > > > -----Original Message----- > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > > Behalf Of Roni Even > > > Sent: Friday, April 24, 2009 4:24 AM > > > To: avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: Re: [AVT] New draft of "Rapid Acquisition of > > > Multicast RTPSessions (RAMS)" available > > > > > > Hi, > > > > > > I think that the current draft does not give a description of > > > a system that works since there is no text explaining how the > > > > What do you mean by "a system that works"? > > > > > RS knows the unicast transport address on the RR to where to > > > send the stream. > > > > Once RS receives the request packet from an RR, RS knows its > > address. Ports > > are defined in the SDP. If you are asking about "NAT" issues, > > we have a > > section for it, and we plan to complete it as we move > > forward. It is not as > > critical as the other parts for now. > > > > > If you mandate the use of RTP/RTCP mux it should say so > > > otherwise the RAMS-R should have an optional parameter that > > > supplies this information and a flag for using RTP/RTCP mux. > > > > IMO, we cannot mandate muxing as it is not required to make > > RAMS work. If > > muxing is supported, the SDP should reflect it. > > > > BR, > > -acbegen > > > > > Thanks > > > > > > Roni Even > > > > > > > > > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > > Behalf Of Bill Ver Steeg (versteb) > > > Sent: Thursday, April 16, 2009 7:39 PM > > > To: avt@ietf.org > > > Subject: [AVT] New draft of "Rapid Acquisition of Multicast > > > RTP Sessions (RAMS)" available > > > > > > > > > > > > There is a new draft of the "Rapid Acquisition of Multicast > > > RTP Sessions (RAMS)" draft available at > > > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s > > ynchronization-for-rtp-03.txt > > drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt> > > > > > > > > > > > > We have incorporated the changes from the technical breakout > > > session in San Francisco. The major changes in this version > > > of the draft include > > > > > > 1- Changing the document title to avoid confusion with other > > > ongoing "synchronization" drafts > > > > > > 2- changing the message names to reflect the title change > > > > > > 3- clarification of the RTCP message semantics, including > > > changes to the "Request" and "Inform" messages > > > > > > 4- additional description/motivation for the various message > > > flows has been added > > > > > > 5- RTP/RTCP muxing has been added > > > > > > > > > > > > > > > > > > We hope to make this a Working Group item, and will change > > > the name of the draft to avoid conflicts with other > > > "synchronization" drafts at that time. > > > > > > > > > > > > Bill VerSteeg > > > > > > > > > > > > > > > > > > > > > > > > From ingemar.s.johansson@ericsson.com Sat Apr 25 05:24:32 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E01EB3A6845 for ; Sat, 25 Apr 2009 05:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.586 X-Spam-Level: X-Spam-Status: No, score=-5.586 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8n5QyoxeQgJD for ; Sat, 25 Apr 2009 05:24:31 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 56B603A6B89 for ; Sat, 25 Apr 2009 05:24:30 -0700 (PDT) X-AuditID: c1b4fb3e-b7b0dae000000c6c-b1-49f3014cc962 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 80.27.03180.C4103F94; Sat, 25 Apr 2009 14:25:48 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Apr 2009 14:25:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 25 Apr 2009 14:25:45 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8CF06BD5@esealmw109.eemea.ericsson.se> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540924FED8@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions(RAMS)" available Thread-Index: AcnCgGOAYtLRTTIdQwOCQbmUqfc+VwAKXQPwALciuUA= References: <130EBB38279E9847BAAAE0B8F9905F8CE5B090@esealmw109.eemea.ericsson.se> <04CAD96D4C5A3D48B1919248A8FE0D540924FED8@xmb-sjc-215.amer.cisco.com> From: "Ingemar Johansson S" To: "Ali C. Begen (abegen)" , X-OriginalArrivalTime: 25 Apr 2009 12:25:48.0088 (UTC) FILETIME=[F6AF1B80:01C9C5A0] X-Brightmail-Tracker: AAAAAA== Cc: Ingemar Johansson S , "Bill Ver Steeg \(versteb\)" Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions(RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 12:24:33 -0000 Hi Sorry for the delay, see my comments inline Regards Ingemar=20 > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > Sent: den 21 april 2009 20:28 > To: Ingemar Johansson S; avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > Multicast RTP Sessions(RAMS)" available >=20 > Hi Ingemar,=20 >=20 > > Hi > >=20 > > I have read through the updated draft and have a few comments and=20 > > requests for your consideration. >=20 > Thanks for the review. > =20 > > In general (as I hinted before) I would like this draft to not just=20 > > discuss the unicast version of RAMS, instead I would like=20 > it to also=20 > > incorporate the multicast version into the framework. >=20 > While I see the common goal for these two methods, I believe=20 > the one you proposed is an additional enhancement on the=20 > unicast approach. Regarding whether they need to be combined=20 > or not, I have some comments below. >=20 > > I have looked into this and I would say that support for=20 > the multicast=20 > > alternative as described in=20 > > http://tools.ietf.org/id/draft-johansson-avt-mcast-based-rams-00.txt > > is fairly straightforward to add to the existing framework, I will=20 > > describe in brief below the key additions that I see today. >=20 > I would not say it would be "fairly straighforward." To make=20 > the multicast bursting effective, many parameters need to be=20 > adjusted properly and optimized. Ow, it can easily degrade=20 > the performance even at the expense of additional complexity. >=20 > A concern I have which is not addressed in your document is=20 > that to make the proposal make sense, Td needs to be small=20 > enough. But, to ensure that all receivers join the burst=20 > mcast session before the burst starts, Td cannot be very=20 > small and RS should not admit last-minute RAMS requests for=20 > that multicast burst (they need to wait for the next batch).=20 > This is because if some receivers miss the first few packets=20 > of the burst, their acquisition will fail. Also, how many=20 > clients can the retransmission server aggregate in a single=20 > burst batch in a practical scenario? The eligible requests=20 > should be received within +/- a few hundereds of=20 > milliseconds. How practical is this, I wonder. The neat thing is that during low load conditions Td can be made very = low such that in practice only one user is served by each request. This = can be implemented with either unicast or multicast bursts that only = serve one STB. As he load increases Td increases and more users that = send a requests will be served by one multicast channel. As Td is = limited some requests will be too late but they can too be collected and = served by additional multicast feeds. Then depending on the distribuion = the tail may be handled with unicast bursts. This is more or less an = optimization issue on the servers. The idea is not that the unicast and multicast alternatives should = compete with one another, rather they should complement each other, due = to the highly dynamic nature of channel switching behavior in a = population both alternatives are useful. I do believe that the multicast = solution can help to reduce deplyment cost.=20 I have tried to look for statistics on channel switching behavior and of = what I have seen sofar the "peak-to-average" ratio of channel swithing = density can be more than 5. This is seen in a master thesis with the = title "TPTV traffic measuring & modeling" by Geng Yu (have not found it = published anywhere yet).=20 > The selection of a common burst bitrate is also critical. If=20 > everybody supports a different burst bitrate and there is a=20 > large variation, multicast bursting will perform poorly for=20 > the well-connected clients. One solution could be to include=20 > the receivers with an available bw that is smaller than R1=20 > and larger than R2 in the multicast pool. The very fast and=20 > very slow receivers should be still served via unicast. Sounds reasonable. >=20 > My personal view is that the multicast bursting proposal will=20 > be a nice solution when the issues above (and possible=20 > others) are addressed, however, I think it should be a=20 > separate draft that normatively references the unicast draft.=20 > This way, we can keep the unicast draft more focused. Not sure that I agree here, it all depends on how the signaling is = standardized. For instance an STB likely needs to declare its = unicast/multicast preference or capability in the RAMS-R as the SDP's = are likely only declarative.=20 >=20 > > The title of the draft would then become "Rapid Acquisition of=20 > > Multicast RTP Sessions". I can offer to add the necessary=20 > parts in the=20 > > document that describes the multicast based version of RAMS. > >=20 > > Packet structure: > > In the draft, three FMT's are defined for the RAMS R,I and=20 > T messages.=20 > > I wonder if it would be better to use one just one FMT for this=20 > > "family" of messages and use a subtype to define R, I, T=20 > (or any other=20 > > message). This was also brought up during the break-out=20 > session in SF. >=20 > This was indeed a good recommendation and we already took=20 > that into account, but we did not want to modify the packet=20 > formats too much to avoid any confusion in this version. If=20 > you look at the open items section, it is already there. Hmm... Sorry, did not see it. >=20 > > Also I would consider a version field as well as there is a chance=20 > > that things need to be changed in the future and TLV extensions may=20 > > not solve all backwards compatibility issues in a satisfactory way=20 > > (changing version number should not be too easy though, TLV=20 > elements=20 > > should be the first choice). >=20 > In a later version, the meanings of the mandatory fields=20 > would not change and TLVs are optional anyway. So, why do you=20 > think new TLVs would not give you what you want? Not that I=20 > am against using a version field, but I would rather see a=20 > need for it. I would appreciate the comments from others here, my argument sofar is = that the cost is quite small but I agree that there are ways to solve = future issues like using a completely new FMT. Problem here is maybe = that it is difficult to foresee the future need. >=20 > > With this in mind the first 32 bits may look like: > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | ver |subtype| flags .... |reserved =20 > > | =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > In this example 3 bits are used for the version number and=20 > 5 bits are=20 > > used for the subtype but there may be a better distribution=20 > here. The=20 > > number of bits for the flags and reserved field depends on=20 > the subtype=20 > > The subtypes would be encoded as RAMS-R =3D 0 RAMS-I =3D 1 RAMS-T = =3D 2 > >=20 > >=20 > > Figure 2:=20 > > A flow diagram that describes the multicast version to be added. > >=20 > > Figure 3:=20 > > A description that describes the multicast version to be added. > >=20 > > Section 6.4: Failure cases > > An alternative to RAMS-T in the multicast version of RAMS=20 > is the use=20 > > of IGMP-Leave (details about this are needed) > >=20 > > Section 7.1 RAMS Request > > Here the 32 bit header is added (with subtype=3D0) and possibly the=20 > > preference and or support of the multicast and the unicast=20 > version of=20 > > RAMS can be defined in the flags field. > > The latter is likely needed as the SDP's are likely only=20 > declarative. > > > > Section 7.2 RAMS Information > > Here the 32 bit header is added (with subtype=3D1) and the MSN,S and = > > Response field is put in the flags field. > > An additional TLV element is added that includes a=20 > multicast address=20 > > and possibly other information such as expected delay until the=20 > > multicast RAMS starts. This field is mandatory if the multicast=20 > > address for RAMS is described in this way. > >=20 > > Section 7.2 RAMS Termination > > Here the 32 bit header is added (with subtype=3D2) Note that=20 > RAMS-T may=20 > > not be needed in the multicast version of RAMS (T.B.D) >=20 > These could be all addressed if/when we decide to combine the=20 > mcast bursting support. OK >=20 > Thanks again for the detail review. >=20 > BR, > -acbegen > =20 > > Comments to my comments are welcome > > Regards > > Ingemar > > ******************************************* > > Ingemar Johansson > > Senior Research Engineer, IETF "nethead"=20 > > EAB/TVP - Multimedia Technologies > > Ericsson Research Ericsson AB > > Box 920 S-971 28 Lule=E5, Sweden > > Tel: +46 (0)10 7143042 > > ECN: 852-43042 > > ECC: 852-19042 > > Mobile: +46 (0)730 783289 > > Visit http://labs.ericsson.com ! > > ******************************************* > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > >=20 >=20 From abegen@cisco.com Sat Apr 25 13:01:39 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F104C3A6CF1 for ; Sat, 25 Apr 2009 13:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.245 X-Spam-Level: X-Spam-Status: No, score=-5.245 tagged_above=-999 required=5 tests=[AWL=-1.046, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46slhAq-Tc05 for ; Sat, 25 Apr 2009 13:01:38 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 92C4E3A67EF for ; Sat, 25 Apr 2009 13:01:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,247,1238976000"; d="scan'208";a="176879677" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 25 Apr 2009 20:02:24 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3PK2O3P026753; Sat, 25 Apr 2009 13:02:24 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3PK2OhH001902; Sat, 25 Apr 2009 20:02:24 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Apr 2009 13:02:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 25 Apr 2009 13:02:13 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C8403@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49f2efa2.1c215e0a.4454.ffffaf91@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available Thread-Index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGHOeBQAAroqxAABGe0AAAAUgbQAAEZLVAAAGk5sAAgqbUwABJxCtA= References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> <49f2efa2.1c215e0a.4454.ffffaf91@mx.google.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , X-OriginalArrivalTime: 25 Apr 2009 20:02:24.0131 (UTC) FILETIME=[BFFF8530:01C9C5E0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8885; t=1240689744; x=1241553744; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20New=20draft=20of=20=22Rapid=20A cquisition=20of=20Multicast=20RTPSessions=09(RAMS)=22=20avai lable |Sender:=20; bh=7TdP1wPGRd6CesIaUCierW9EROVSCrCXxqWS/HjRoXc=; b=DTjeIO3MXxgYbIZdOx5OyoNQ9m7y+iS9ha0BnUQdzhYCzkKtqA/i9Mu5wG xRnAQ3ty9d0liyhuY84/OdAu5C53fyH/qdZsEe2spI4ppH0Reh9GudphJMo0 dicAZmU/q1uWa68tN+3zA/vxeXmL9YxVu3UYegpYVivai14vcjrls=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "Bill Ver Steeg \(versteb\)" Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 20:01:40 -0000 > Ali, > The example SDP is syntactically correct but it does not say that the > rtp/rtcp mux will be used and it does not give the=20 > information to where the > unicast stream will be sent when the RR sends a RAMS-R.=20 To my knowledge, the first line in the following SDP tells the RRs on = which port they will receive the retransmission/burst packets. m=3Dvideo 41002 RTP/AVPF 99 i=3DUnicast Retransmission Stream #2 (Ret. and Rapid Acq. = Support) c=3DIN IP4 192.0.2.1 a=3Drtpmap:99 rtx/90000 a=3Drtcp:41003 a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 a=3Dmid:4 There is a typo, you are right. That "a=3Drecvonly" line should only = exist in the SDP sent to RRs. In the SDP sent to RS, we should rather = have "a=3Dsendonly". I will make this correction in the next version. The feedback target for the SSM session and the RTCP port for the = retransmission session are also defined in the SDP. Hope this clarifies. BR, -acbegen =20 >=20 > I am not sure why the unicast stream m-line has a port number with an > attribute of recvonly. What is the use case for that. The=20 > only information > that the RR will need is the RTCP port on the RS to where to=20 > send the RAMS-R > message. > Roni > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > Sent: Friday, April 24, 2009 10:37 PM > To: Roni Even; avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > Multicast RTPSessions > (RAMS)" available >=20 > This is a part of an example SDP sent to RS and RR in a SAP=20 > announcement, > for example. So, the SDP describes what both parties should=20 > do (RR cannot > say that he wants to receive this multicast on its favorite port). The > individual SDPs sent to RR or RS may include other portions=20 > of descriptions > that will contain specific information.=20 >=20 > -acbegen >=20 > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > > Sent: Friday, April 24, 2009 12:23 PM > > To: Ali C. Begen (abegen); avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > Multicast RTPSessions (RAMS)" available > >=20 > > Ali, > > I think you get it wrong, this SDP is from the RS and not the=20 > > RR so the RS > > cannot specify to which address it will send it can only=20 > > specify to which > > address it can receive RTP stream. In this SDP the relevant=20 > > information is > > that the request for retransmission will be sent by the RR to=20 > > port 41003 > > Roni > >=20 > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > > Sent: Friday, April 24, 2009 10:01 PM > > To: Roni Even; avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > Multicast RTPSessions > > (RAMS)" available > >=20 > > Oh, I see. The burst goes to the port that we would=20 > normally send the > > retransmissions. For example, consider the SDP from the draft: > >=20 > > m=3Dvideo 41000 RTP/AVPF 98 > > i=3DPrimary Multicast Stream #2 > > c=3DIN IP4 224.1.1.2/255 > > a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 > > a=3Drtpmap:98 MP2T/90000 > > a=3Drtcp:41001 IN IP4 192.0.2.1 > > a=3Drtcp-fb:98 nack > > a=3Drtcp-fb:98 nack ssli > > a=3Dssrc:123321 cname:iptv-ch32@rams.example.com > > a=3Dmid:3 > > m=3Dvideo 41002 RTP/AVPF 99 > > i=3DUnicast Retransmission Stream #2 (Ret. and Rapid=20 > > Acq. Support) > > c=3DIN IP4 192.0.2.1 > > a=3Drecvonly > > a=3Drtpmap:99 rtx/90000 > > a=3Drtcp:41003 > > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > > a=3Dmid:4 > >=20 > > In this case, the burst will go to port 41002 on the RR. The RAMS-I > > message(s), which is an RTCP feedback message, will go to=20 > port 41003. > >=20 > > HTH, > > -acbegen > >=20 > > > -----Original Message----- > > > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > > > Sent: Friday, April 24, 2009 11:44 AM > > > To: Ali C. Begen (abegen); avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > Multicast RTPSessions (RAMS)" available > > >=20 > > > Ali, > > > I will try to explain in simple way > > >=20 > > > When the RS receives the RAMS-R it need to start sending an=20 > > > RTP stream to > > > the RR.=20 > > > In order to send a unicast packet, the RS needs to know a=20 > > > transport address > > > on the RR to where the RTP stream will be sent. The current=20 > > > draft does not > > > say how the RS knows this address. There is no SDP from RR to=20 > > > RS like you > > > mention in your response. > > > This is why I say that the current draft does not specify a=20 > > > solution that > > > can be implemented as a working solution > > > Roni > > >=20 > > > -----Original Message----- > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > > > Sent: Friday, April 24, 2009 7:38 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > Multicast RTPSessions > > > (RAMS)" available > > >=20 > > > Hi Roni,=20 > > >=20 > > > > -----Original Message----- > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > > > > Behalf Of Roni Even > > > > Sent: Friday, April 24, 2009 4:24 AM > > > > To: avt@ietf.org > > > > Cc: Bill Ver Steeg (versteb) > > > > Subject: Re: [AVT] New draft of "Rapid Acquisition of=20 > > > > Multicast RTPSessions (RAMS)" available > > > >=20 > > > > Hi, > > > >=20 > > > > I think that the current draft does not give a description of=20 > > > > a system that works since there is no text explaining how the=20 > > >=20 > > > What do you mean by "a system that works"?=20 > > >=20 > > > > RS knows the unicast transport address on the RR to where to=20 > > > > send the stream.=20 > > >=20 > > > Once RS receives the request packet from an RR, RS knows its=20 > > > address. Ports > > > are defined in the SDP. If you are asking about "NAT" issues,=20 > > > we have a > > > section for it, and we plan to complete it as we move=20 > > > forward. It is not as > > > critical as the other parts for now. > > > =20 > > > > If you mandate the use of RTP/RTCP mux it should say so=20 > > > > otherwise the RAMS-R should have an optional parameter that=20 > > > > supplies this information and a flag for using RTP/RTCP mux. > > >=20 > > > IMO, we cannot mandate muxing as it is not required to make=20 > > > RAMS work. If > > > muxing is supported, the SDP should reflect it. > > >=20 > > > BR, > > > -acbegen > > > =20 > > > > Thanks > > > >=20 > > > > Roni Even > > > >=20 > > > > =20 > > > >=20 > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > > > > Behalf Of Bill Ver Steeg (versteb) > > > > Sent: Thursday, April 16, 2009 7:39 PM > > > > To: avt@ietf.org > > > > Subject: [AVT] New draft of "Rapid Acquisition of Multicast=20 > > > > RTP Sessions (RAMS)" available > > > >=20 > > > > =20 > > > >=20 > > > > There is a new draft of the "Rapid Acquisition of Multicast=20 > > > > RTP Sessions (RAMS)" draft available at=20 > > > > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s > > > ynchronization-for-rtp-03.txt > > > drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt>=20 > > > >=20 > > > > =20 > > > >=20 > > > > We have incorporated the changes from the technical breakout=20 > > > > session in San Francisco. The major changes in this version=20 > > > > of the draft include=20 > > > >=20 > > > > 1- Changing the document title to avoid confusion with other=20 > > > > ongoing "synchronization" drafts > > > >=20 > > > > 2- changing the message names to reflect the title change > > > >=20 > > > > 3- clarification of the RTCP message semantics, including=20 > > > > changes to the "Request" and "Inform" messages > > > >=20 > > > > 4- additional description/motivation for the various message=20 > > > > flows has been added > > > >=20 > > > > 5- RTP/RTCP muxing has been added > > > >=20 > > > > =20 > > > >=20 > > > > =20 > > > >=20 > > > > We hope to make this a Working Group item, and will change=20 > > > > the name of the draft to avoid conflicts with other=20 > > > > "synchronization" drafts at that time. > > > >=20 > > > > =20 > > > >=20 > > > > Bill VerSteeg > > > >=20 > > > > =20 > > > >=20 > > > > =20 > > > >=20 > > > >=20 > > >=20 > > >=20 > >=20 > >=20 >=20 >=20 From ron.even.tlv@gmail.com Sat Apr 25 13:12:06 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A90E3A6A94 for ; Sat, 25 Apr 2009 13:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.195 X-Spam-Level: X-Spam-Status: No, score=-1.195 tagged_above=-999 required=5 tests=[AWL=-0.996, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9Pr5Yvhg+cd for ; Sat, 25 Apr 2009 13:12:05 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 6B7933A6407 for ; Sat, 25 Apr 2009 13:12:04 -0700 (PDT) Received: by fxm2 with SMTP id 2so1639923fxm.37 for ; Sat, 25 Apr 2009 13:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=RLU5Ou5uNdrV26rFl7kknDJTSno/z3qegjOnt2USxOY=; b=pzTY3JLWz6QTUMpyEllKs84jdFnnFpSSImUlMIW8SXBq+eG4X12/nxzrmK5KyvYkaG FrTF3V5zhrqAagy2QBAfrT+n9EgSTlcfMrqt2Qw6DOfQJ74EPRPKBZ3rxXAjnrETfLP8 qzskoNdsyahg5vC/pBt6QmPc53EESNz0h/r98= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=jrBunl1apUyLl4lcnHtZs8Bm5w5erpnStp69UINbfkq0etbJ4jBZhKKrTUusSDOJYU x+gglRSPjjWwfbT8F+JPuaJDnGOB2jwnhtEvJUqxc1q9YhS1uUVERP5LNEK9J7Xv/6RN +h7pSuxMCW8+XRQaK/f/Ox74F1Ej01scA31Ts= Received: by 10.86.74.4 with SMTP id w4mr1854684fga.60.1240690403202; Sat, 25 Apr 2009 13:13:23 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-121-32.red.bezeqint.net [79.179.121.32]) by mx.google.com with ESMTPS id d4sm3165748fga.4.2009.04.25.13.13.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 25 Apr 2009 13:13:22 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> <49f2efa2.1c215e0a.4454.ffffaf91@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8403@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C8403@xmb-sjc-215.amer.cisco.com> Date: Sat, 25 Apr 2009 23:11:28 +0300 Message-ID: <49f36ee2.0437560a.11df.1eef@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGHOeBQAAroqxAABGe0AAAAUgbQAAEZLVAAAGk5sAAgqbUwABJxCtAAAIRzIA== Content-Language: en-us Cc: "'Bill Ver Steeg \(versteb\)'" Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 20:12:06 -0000 Ali, Can you please write three addresses from this strange SDP. 1. The address and port of multicast 2. The address and port of the RS where the RTCP FB should go to 3. The address and port on the RR where the unicast stream should be sent to Roni -----Original Message----- From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] Sent: Saturday, April 25, 2009 11:02 PM To: Roni Even; avt@ietf.org Cc: Bill Ver Steeg (versteb) Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available > Ali, > The example SDP is syntactically correct but it does not say that the > rtp/rtcp mux will be used and it does not give the > information to where the > unicast stream will be sent when the RR sends a RAMS-R. To my knowledge, the first line in the following SDP tells the RRs on which port they will receive the retransmission/burst packets. m=video 41002 RTP/AVPF 99 i=Unicast Retransmission Stream #2 (Ret. and Rapid Acq. Support) c=IN IP4 192.0.2.1 a=rtpmap:99 rtx/90000 a=rtcp:41003 a=fmtp:99 apt=98; rtx-time=5000 a=mid:4 There is a typo, you are right. That "a=recvonly" line should only exist in the SDP sent to RRs. In the SDP sent to RS, we should rather have "a=sendonly". I will make this correction in the next version. The feedback target for the SSM session and the RTCP port for the retransmission session are also defined in the SDP. Hope this clarifies. BR, -acbegen > > I am not sure why the unicast stream m-line has a port number with an > attribute of recvonly. What is the use case for that. The > only information > that the RR will need is the RTCP port on the RS to where to > send the RAMS-R > message. > Roni > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Friday, April 24, 2009 10:37 PM > To: Roni Even; avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of > Multicast RTPSessions > (RAMS)" available > > This is a part of an example SDP sent to RS and RR in a SAP > announcement, > for example. So, the SDP describes what both parties should > do (RR cannot > say that he wants to receive this multicast on its favorite port). The > individual SDPs sent to RR or RS may include other portions > of descriptions > that will contain specific information. > > -acbegen > > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > Sent: Friday, April 24, 2009 12:23 PM > > To: Ali C. Begen (abegen); avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > Multicast RTPSessions (RAMS)" available > > > > Ali, > > I think you get it wrong, this SDP is from the RS and not the > > RR so the RS > > cannot specify to which address it will send it can only > > specify to which > > address it can receive RTP stream. In this SDP the relevant > > information is > > that the request for retransmission will be sent by the RR to > > port 41003 > > Roni > > > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > Sent: Friday, April 24, 2009 10:01 PM > > To: Roni Even; avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > Multicast RTPSessions > > (RAMS)" available > > > > Oh, I see. The burst goes to the port that we would > normally send the > > retransmissions. For example, consider the SDP from the draft: > > > > m=video 41000 RTP/AVPF 98 > > i=Primary Multicast Stream #2 > > c=IN IP4 224.1.1.2/255 > > a=source-filter: incl IN IP4 224.1.1.2 192.0.2.2 > > a=rtpmap:98 MP2T/90000 > > a=rtcp:41001 IN IP4 192.0.2.1 > > a=rtcp-fb:98 nack > > a=rtcp-fb:98 nack ssli > > a=ssrc:123321 cname:iptv-ch32@rams.example.com > > a=mid:3 > > m=video 41002 RTP/AVPF 99 > > i=Unicast Retransmission Stream #2 (Ret. and Rapid > > Acq. Support) > > c=IN IP4 192.0.2.1 > > a=recvonly > > a=rtpmap:99 rtx/90000 > > a=rtcp:41003 > > a=fmtp:99 apt=98; rtx-time=5000 > > a=mid:4 > > > > In this case, the burst will go to port 41002 on the RR. The RAMS-I > > message(s), which is an RTCP feedback message, will go to > port 41003. > > > > HTH, > > -acbegen > > > > > -----Original Message----- > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > Sent: Friday, April 24, 2009 11:44 AM > > > To: Ali C. Begen (abegen); avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > Multicast RTPSessions (RAMS)" available > > > > > > Ali, > > > I will try to explain in simple way > > > > > > When the RS receives the RAMS-R it need to start sending an > > > RTP stream to > > > the RR. > > > In order to send a unicast packet, the RS needs to know a > > > transport address > > > on the RR to where the RTP stream will be sent. The current > > > draft does not > > > say how the RS knows this address. There is no SDP from RR to > > > RS like you > > > mention in your response. > > > This is why I say that the current draft does not specify a > > > solution that > > > can be implemented as a working solution > > > Roni > > > > > > -----Original Message----- > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > Sent: Friday, April 24, 2009 7:38 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > Hi Roni, > > > > > > > -----Original Message----- > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > > > Behalf Of Roni Even > > > > Sent: Friday, April 24, 2009 4:24 AM > > > > To: avt@ietf.org > > > > Cc: Bill Ver Steeg (versteb) > > > > Subject: Re: [AVT] New draft of "Rapid Acquisition of > > > > Multicast RTPSessions (RAMS)" available > > > > > > > > Hi, > > > > > > > > I think that the current draft does not give a description of > > > > a system that works since there is no text explaining how the > > > > > > What do you mean by "a system that works"? > > > > > > > RS knows the unicast transport address on the RR to where to > > > > send the stream. > > > > > > Once RS receives the request packet from an RR, RS knows its > > > address. Ports > > > are defined in the SDP. If you are asking about "NAT" issues, > > > we have a > > > section for it, and we plan to complete it as we move > > > forward. It is not as > > > critical as the other parts for now. > > > > > > > If you mandate the use of RTP/RTCP mux it should say so > > > > otherwise the RAMS-R should have an optional parameter that > > > > supplies this information and a flag for using RTP/RTCP mux. > > > > > > IMO, we cannot mandate muxing as it is not required to make > > > RAMS work. If > > > muxing is supported, the SDP should reflect it. > > > > > > BR, > > > -acbegen > > > > > > > Thanks > > > > > > > > Roni Even > > > > > > > > > > > > > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > > > Behalf Of Bill Ver Steeg (versteb) > > > > Sent: Thursday, April 16, 2009 7:39 PM > > > > To: avt@ietf.org > > > > Subject: [AVT] New draft of "Rapid Acquisition of Multicast > > > > RTP Sessions (RAMS)" available > > > > > > > > > > > > > > > > There is a new draft of the "Rapid Acquisition of Multicast > > > > RTP Sessions (RAMS)" draft available at > > > > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s > > > ynchronization-for-rtp-03.txt > > > drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt> > > > > > > > > > > > > > > > > We have incorporated the changes from the technical breakout > > > > session in San Francisco. The major changes in this version > > > > of the draft include > > > > > > > > 1- Changing the document title to avoid confusion with other > > > > ongoing "synchronization" drafts > > > > > > > > 2- changing the message names to reflect the title change > > > > > > > > 3- clarification of the RTCP message semantics, including > > > > changes to the "Request" and "Inform" messages > > > > > > > > 4- additional description/motivation for the various message > > > > flows has been added > > > > > > > > 5- RTP/RTCP muxing has been added > > > > > > > > > > > > > > > > > > > > > > > > We hope to make this a Working Group item, and will change > > > > the name of the draft to avoid conflicts with other > > > > "synchronization" drafts at that time. > > > > > > > > > > > > > > > > Bill VerSteeg > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From abegen@cisco.com Sat Apr 25 13:29:04 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B61CB3A6A77 for ; Sat, 25 Apr 2009 13:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.223 X-Spam-Level: X-Spam-Status: No, score=-5.223 tagged_above=-999 required=5 tests=[AWL=-1.024, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkC6soCV5c8b for ; Sat, 25 Apr 2009 13:29:03 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2B4013A693D for ; Sat, 25 Apr 2009 13:29:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,247,1238976000"; d="scan'208";a="176883674" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 25 Apr 2009 20:30:23 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3PKUMLp017894; Sat, 25 Apr 2009 13:30:22 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3PKUME9011258; Sat, 25 Apr 2009 20:30:22 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Apr 2009 13:30:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 25 Apr 2009 13:30:19 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C8405@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49f36ee2.0437560a.11df.1eef@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available Thread-Index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGHOeBQAAroqxAABGe0AAAAUgbQAAEZLVAAAGk5sAAgqbUwABJxCtAAAIRzIAAAQcKg References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> <49f2efa2.1c215e0a.4454.ffffaf91@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8403@xmb-sjc-215.amer.cisco.com> <49f36ee2.0437560a.11df.1eef@mx.google.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , X-OriginalArrivalTime: 25 Apr 2009 20:30:22.0624 (UTC) FILETIME=[A8753A00:01C9C5E4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11743; t=1240691423; x=1241555423; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20New=20draft=20of=20=22Rapid=20A cquisition=20of=20Multicast=20RTPSessions=09(RAMS)=22=20avai lable |Sender:=20; bh=vX7hGtJiLsbchCjMigN2hTnZz4q1RZC3dHSVAWbZzQo=; b=W14rdSbv5/fQZUhRUfAA8wTsDme6aU8u662DBIL5SWnO7iivLfQfmXLRBr SPnNdNqd9I8YKQANWIMyLVPlU7dXuUbuGW81dUk42rCsLna/3PnGYiBtHyIV gkfNNG3PQA; Authentication-Results: sj-dkim-3; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: "Bill Ver Steeg \(versteb\)" Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 20:29:04 -0000 Here is the SDP. m=3Dvideo 41000 RTP/AVPF 98 i=3DPrimary Multicast Stream #2 c=3DIN IP4 224.1.1.2/255 a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 Source (192.0.2.2) sends the rtp packets to the multicast group = (224.1.1.2) with a dest port 41000. a=3Drtpmap:98 MP2T/90000 a=3Drtcp:41001 IN IP4 192.0.2.1 The feedback target (RS) address for this SSM session is 192.0.2.1 and = its port is 41001. This is the address/port where RR sends the RAMS-R, = or receiver reports for the SSM session. a=3Drtcp-fb:98 nack a=3Drtcp-fb:98 nack ssli a=3Dssrc:123321 cname:iptv-ch32@rams.example.com a=3Dmid:3 m=3Dvideo 41002 RTP/AVPF 99 The retransmission packets go to port 41002. This is the port RRs listen = to for retransmission and RAMS. i=3DUnicast Retransmission Stream #2 (Ret. and Rapid Acq. = Support) c=3DIN IP4 192.0.2.1 This is where the retransmission packets come from, same as the feedback = target (in this example). a=3Drtpmap:99 rtx/90000 a=3Drtcp:41003 This is where the RTCP packets for the retransmission session go. For = example, RAMS-I goes to this port on RRs. RAMS-T goes to this port on = RS. a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 a=3Dmid:4 -acbegen =20 > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > Sent: Saturday, April 25, 2009 1:11 PM > To: Ali C. Begen (abegen); avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > Multicast RTPSessions (RAMS)" available >=20 > Ali, > Can you please write three addresses from this strange SDP. >=20 > 1. The address and port of multicast >=20 > 2. The address and port of the RS where the RTCP FB should go to >=20 > 3. The address and port on the RR where the unicast stream=20 > should be sent to >=20 > Roni >=20 > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > Sent: Saturday, April 25, 2009 11:02 PM > To: Roni Even; avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > Multicast RTPSessions > (RAMS)" available >=20 > > Ali, > > The example SDP is syntactically correct but it does not=20 > say that the > > rtp/rtcp mux will be used and it does not give the=20 > > information to where the > > unicast stream will be sent when the RR sends a RAMS-R.=20 >=20 > To my knowledge, the first line in the following SDP tells=20 > the RRs on which > port they will receive the retransmission/burst packets. >=20 > m=3Dvideo 41002 RTP/AVPF 99 > i=3DUnicast Retransmission Stream #2 (Ret. and Rapid=20 > Acq. Support) > c=3DIN IP4 192.0.2.1 > a=3Drtpmap:99 rtx/90000 > a=3Drtcp:41003 > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > a=3Dmid:4 >=20 > There is a typo, you are right. That "a=3Drecvonly" line should=20 > only exist in > the SDP sent to RRs. In the SDP sent to RS, we should rather have > "a=3Dsendonly". I will make this correction in the next version. >=20 > The feedback target for the SSM session and the RTCP port for the > retransmission session are also defined in the SDP. >=20 > Hope this clarifies. >=20 > BR, > -acbegen > =20 > >=20 > > I am not sure why the unicast stream m-line has a port=20 > number with an > > attribute of recvonly. What is the use case for that. The=20 > > only information > > that the RR will need is the RTCP port on the RS to where to=20 > > send the RAMS-R > > message. > > Roni > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > > Sent: Friday, April 24, 2009 10:37 PM > > To: Roni Even; avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > Multicast RTPSessions > > (RAMS)" available > >=20 > > This is a part of an example SDP sent to RS and RR in a SAP=20 > > announcement, > > for example. So, the SDP describes what both parties should=20 > > do (RR cannot > > say that he wants to receive this multicast on its favorite=20 > port). The > > individual SDPs sent to RR or RS may include other portions=20 > > of descriptions > > that will contain specific information.=20 > >=20 > > -acbegen > >=20 > > > -----Original Message----- > > > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > > > Sent: Friday, April 24, 2009 12:23 PM > > > To: Ali C. Begen (abegen); avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > Multicast RTPSessions (RAMS)" available > > >=20 > > > Ali, > > > I think you get it wrong, this SDP is from the RS and not the=20 > > > RR so the RS > > > cannot specify to which address it will send it can only=20 > > > specify to which > > > address it can receive RTP stream. In this SDP the relevant=20 > > > information is > > > that the request for retransmission will be sent by the RR to=20 > > > port 41003 > > > Roni > > >=20 > > > -----Original Message----- > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > > > Sent: Friday, April 24, 2009 10:01 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > Multicast RTPSessions > > > (RAMS)" available > > >=20 > > > Oh, I see. The burst goes to the port that we would=20 > > normally send the > > > retransmissions. For example, consider the SDP from the draft: > > >=20 > > > m=3Dvideo 41000 RTP/AVPF 98 > > > i=3DPrimary Multicast Stream #2 > > > c=3DIN IP4 224.1.1.2/255 > > > a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 > > > a=3Drtpmap:98 MP2T/90000 > > > a=3Drtcp:41001 IN IP4 192.0.2.1 > > > a=3Drtcp-fb:98 nack > > > a=3Drtcp-fb:98 nack ssli > > > a=3Dssrc:123321 cname:iptv-ch32@rams.example.com > > > a=3Dmid:3 > > > m=3Dvideo 41002 RTP/AVPF 99 > > > i=3DUnicast Retransmission Stream #2 (Ret. and Rapid=20 > > > Acq. Support) > > > c=3DIN IP4 192.0.2.1 > > > a=3Drecvonly > > > a=3Drtpmap:99 rtx/90000 > > > a=3Drtcp:41003 > > > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > > > a=3Dmid:4 > > >=20 > > > In this case, the burst will go to port 41002 on the RR.=20 > The RAMS-I > > > message(s), which is an RTCP feedback message, will go to=20 > > port 41003. > > >=20 > > > HTH, > > > -acbegen > > >=20 > > > > -----Original Message----- > > > > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > > > > Sent: Friday, April 24, 2009 11:44 AM > > > > To: Ali C. Begen (abegen); avt@ietf.org > > > > Cc: Bill Ver Steeg (versteb) > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > > Multicast RTPSessions (RAMS)" available > > > >=20 > > > > Ali, > > > > I will try to explain in simple way > > > >=20 > > > > When the RS receives the RAMS-R it need to start sending an=20 > > > > RTP stream to > > > > the RR.=20 > > > > In order to send a unicast packet, the RS needs to know a=20 > > > > transport address > > > > on the RR to where the RTP stream will be sent. The current=20 > > > > draft does not > > > > say how the RS knows this address. There is no SDP from RR to=20 > > > > RS like you > > > > mention in your response. > > > > This is why I say that the current draft does not specify a=20 > > > > solution that > > > > can be implemented as a working solution > > > > Roni > > > >=20 > > > > -----Original Message----- > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > > > > Sent: Friday, April 24, 2009 7:38 PM > > > > To: Roni Even; avt@ietf.org > > > > Cc: Bill Ver Steeg (versteb) > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > > Multicast RTPSessions > > > > (RAMS)" available > > > >=20 > > > > Hi Roni,=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > > > > > Behalf Of Roni Even > > > > > Sent: Friday, April 24, 2009 4:24 AM > > > > > To: avt@ietf.org > > > > > Cc: Bill Ver Steeg (versteb) > > > > > Subject: Re: [AVT] New draft of "Rapid Acquisition of=20 > > > > > Multicast RTPSessions (RAMS)" available > > > > >=20 > > > > > Hi, > > > > >=20 > > > > > I think that the current draft does not give a description of=20 > > > > > a system that works since there is no text explaining how the=20 > > > >=20 > > > > What do you mean by "a system that works"?=20 > > > >=20 > > > > > RS knows the unicast transport address on the RR to where to=20 > > > > > send the stream.=20 > > > >=20 > > > > Once RS receives the request packet from an RR, RS knows its=20 > > > > address. Ports > > > > are defined in the SDP. If you are asking about "NAT" issues,=20 > > > > we have a > > > > section for it, and we plan to complete it as we move=20 > > > > forward. It is not as > > > > critical as the other parts for now. > > > > =20 > > > > > If you mandate the use of RTP/RTCP mux it should say so=20 > > > > > otherwise the RAMS-R should have an optional parameter that=20 > > > > > supplies this information and a flag for using RTP/RTCP mux. > > > >=20 > > > > IMO, we cannot mandate muxing as it is not required to make=20 > > > > RAMS work. If > > > > muxing is supported, the SDP should reflect it. > > > >=20 > > > > BR, > > > > -acbegen > > > > =20 > > > > > Thanks > > > > >=20 > > > > > Roni Even > > > > >=20 > > > > > =20 > > > > >=20 > > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > > > > > Behalf Of Bill Ver Steeg (versteb) > > > > > Sent: Thursday, April 16, 2009 7:39 PM > > > > > To: avt@ietf.org > > > > > Subject: [AVT] New draft of "Rapid Acquisition of Multicast=20 > > > > > RTP Sessions (RAMS)" available > > > > >=20 > > > > > =20 > > > > >=20 > > > > > There is a new draft of the "Rapid Acquisition of Multicast=20 > > > > > RTP Sessions (RAMS)" draft available at=20 > > > > > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s > > > > ynchronization-for-rtp-03.txt > > > > drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt>=20 > > > > >=20 > > > > > =20 > > > > >=20 > > > > > We have incorporated the changes from the technical breakout=20 > > > > > session in San Francisco. The major changes in this version=20 > > > > > of the draft include=20 > > > > >=20 > > > > > 1- Changing the document title to avoid confusion with other=20 > > > > > ongoing "synchronization" drafts > > > > >=20 > > > > > 2- changing the message names to reflect the title change > > > > >=20 > > > > > 3- clarification of the RTCP message semantics, including=20 > > > > > changes to the "Request" and "Inform" messages > > > > >=20 > > > > > 4- additional description/motivation for the various message=20 > > > > > flows has been added > > > > >=20 > > > > > 5- RTP/RTCP muxing has been added > > > > >=20 > > > > > =20 > > > > >=20 > > > > > =20 > > > > >=20 > > > > > We hope to make this a Working Group item, and will change=20 > > > > > the name of the draft to avoid conflicts with other=20 > > > > > "synchronization" drafts at that time. > > > > >=20 > > > > > =20 > > > > >=20 > > > > > Bill VerSteeg > > > > >=20 > > > > > =20 > > > > >=20 > > > > > =20 > > > > >=20 > > > > >=20 > > > >=20 > > > >=20 > > >=20 > > >=20 > >=20 > >=20 >=20 >=20 From abegen@cisco.com Sat Apr 25 13:49:20 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BEC33A6D90 for ; Sat, 25 Apr 2009 13:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.401 X-Spam-Level: X-Spam-Status: No, score=-6.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Df4wL33y4jYR for ; Sat, 25 Apr 2009 13:49:19 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0C14E3A6822 for ; Sat, 25 Apr 2009 13:49:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,247,1238976000"; d="scan'208";a="176887523" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 25 Apr 2009 20:50:38 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3PKoctN018195; Sat, 25 Apr 2009 13:50:38 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3PKoc47017205; Sat, 25 Apr 2009 20:50:38 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Apr 2009 13:50:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 25 Apr 2009 13:50:33 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C8406@xmb-sjc-215.amer.cisco.com> In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8CF06BD5@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions(RAMS)" available Thread-Index: AcnCgGOAYtLRTTIdQwOCQbmUqfc+VwAKXQPwALciuUAAF5U9oA== References: <130EBB38279E9847BAAAE0B8F9905F8CE5B090@esealmw109.eemea.ericsson.se> <04CAD96D4C5A3D48B1919248A8FE0D540924FED8@xmb-sjc-215.amer.cisco.com> <130EBB38279E9847BAAAE0B8F9905F8CF06BD5@esealmw109.eemea.ericsson.se> From: "Ali C. Begen (abegen)" To: "Ingemar Johansson S" , X-OriginalArrivalTime: 25 Apr 2009 20:50:38.0685 (UTC) FILETIME=[7D4968D0:01C9C5E7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5147; t=1240692638; x=1241556638; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20New=20draft=20of=20=22Rapid=20A cquisition=20of=20Multicast=20RTP=20Sessions(RAMS)=22=20avai lable |Sender:=20; bh=Mu/GY18xV3Lfy7bVGiicgzFigfOb0Lzxml3RTx3x9r4=; b=w4SXn6R2P57VjWL/6ediThHwEmsCurv72xSKYNmiW3Mmxz5FqzI+Xtp/L/ EpOSE0/Dqv8QFzXIfq3GMgVkJA8rrKwi+I5yGzgKsDTWk/gRgnhg6zszd37w h1i5LoQIKd; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "Bill Ver Steeg \(versteb\)" Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions(RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 20:49:20 -0000 > > I would not say it would be "fairly straighforward." To make=20 > > the multicast bursting effective, many parameters need to be=20 > > adjusted properly and optimized. Ow, it can easily degrade=20 > > the performance even at the expense of additional complexity. > >=20 > > A concern I have which is not addressed in your document is=20 > > that to make the proposal make sense, Td needs to be small=20 > > enough. But, to ensure that all receivers join the burst=20 > > mcast session before the burst starts, Td cannot be very=20 > > small and RS should not admit last-minute RAMS requests for=20 > > that multicast burst (they need to wait for the next batch).=20 > > This is because if some receivers miss the first few packets=20 > > of the burst, their acquisition will fail. Also, how many=20 > > clients can the retransmission server aggregate in a single=20 > > burst batch in a practical scenario? The eligible requests=20 > > should be received within +/- a few hundereds of=20 > > milliseconds. How practical is this, I wonder. > The neat thing is that during low load conditions Td can be=20 > made very low such that in practice only one user is served=20 > by each request. This can be implemented with either unicast=20 > or multicast bursts that only serve one STB. As he load=20 > increases Td increases and more users that send a requests=20 > will be served by one multicast channel. As Td is limited=20 > some requests will be too late but they can too be collected=20 > and served by additional multicast feeds. Then depending on=20 > the distribuion the tail may be handled with unicast bursts.=20 > This is more or less an optimization issue on the servers. Agree. > The idea is not that the unicast and multicast alternatives=20 > should compete with one another, rather they should=20 > complement each other, due to the highly dynamic nature of=20 > channel switching behavior in a population both alternatives=20 > are useful. I do believe that the multicast solution can help=20 > to reduce deplyment cost.=20 It can. However, remember that in a highly-loaded environment, if RS = cannot provide (unicast) acceleration, it can deny the request. For the = sake of doing multicast bursting (to save bandwidth), if RRs experience = a slower acquisition (due to a large Td, for example) compared to a = simple join, that is not good. > I have tried to look for statistics on channel switching=20 > behavior and of what I have seen sofar the "peak-to-average"=20 > ratio of channel swithing density can be more than 5. This is=20 > seen in a master thesis with the title "TPTV traffic=20 > measuring & modeling" by Geng Yu (have not found it published=20 > anywhere yet).=20 I don't think I have that study, either. But, there is a recent study in = IMC 2008. Here is the link. http://portal.acm.org/ft_gateway.cfm?id=3D1452529&type=3Dpdf&coll=3Dporta= l&dl=3DACM The results are in general more or less similar to what we found in one = of our own studies. The figure you will find interesting is Figure 14.=20 For the most popular channel, the entire data set shows that on average = 14 viewers tune into that channel per second (Figure 14a). Of course, = there are occasions where a lot more viewers may tune at approximately = the same time (within the same second), but this is for the top-ranked = channel and the number 14 includes all viewers in the data set, which is = about 250K (This is what I got from the text). If we consider only a = subset of these viewers will be served by the same RS, the concurrency = we will get in a single server will be far smaller, impying that = multicast burst will not be needed most of the time. Different studies may suggest different numbers based on the regional = characteristics. So, I don't think we should read too much into this = study. If there are other studies, please post them here. So, we can = make a better judgment. > > The selection of a common burst bitrate is also critical. If=20 > > everybody supports a different burst bitrate and there is a=20 > > large variation, multicast bursting will perform poorly for=20 > > the well-connected clients. One solution could be to include=20 > > the receivers with an available bw that is smaller than R1=20 > > and larger than R2 in the multicast pool. The very fast and=20 > > very slow receivers should be still served via unicast. > Sounds reasonable. >=20 > >=20 > > My personal view is that the multicast bursting proposal will=20 > > be a nice solution when the issues above (and possible=20 > > others) are addressed, however, I think it should be a=20 > > separate draft that normatively references the unicast draft.=20 > > This way, we can keep the unicast draft more focused. > Not sure that I agree here, it all depends on how the=20 > signaling is standardized. For instance an STB likely needs=20 > to declare its unicast/multicast preference or capability in=20 > the RAMS-R as the SDP's are likely only declarative.=20 There can be a TLV in the request to do this, no?=20 BR, -acbegen From ron.even.tlv@gmail.com Sat Apr 25 14:24:34 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 193B33A6BDD for ; Sat, 25 Apr 2009 14:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.165 X-Spam-Level: X-Spam-Status: No, score=-1.165 tagged_above=-999 required=5 tests=[AWL=-0.966, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5hvgc389z2j for ; Sat, 25 Apr 2009 14:24:32 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 196433A67E1 for ; Sat, 25 Apr 2009 14:24:31 -0700 (PDT) Received: by fxm2 with SMTP id 2so1658085fxm.37 for ; Sat, 25 Apr 2009 14:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=+9fI+r1QHfW5oLvSFEQ7FMHz9t/UPVBkDsEeKYzLLOo=; b=uKGn3c3iBotBQWxB5gX+udCYRKYgtwxm3uCCuWU9FLIaLRfUDRU6cj/FBlpMOsPR5s UKL4MC2EZJ7vkIfIoKLrBzlINGq3J3+qMywN8pi2E/IH96Wv6xphkR0IYdYfZoGw+0RG 9Je9de28FxLoqXcHVMjqYr1wmGnJRgFqY5/88= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=NyvVYZ5k1iiaDQZ4VttYHKvANknDaduxYZ8eTmrsRBzqfqFt9ggVvx9sNx7jRw+bfh Lu+zQkrGyqjEqUMBzh/2v8R3uVu2lQ8ZVcbYuRVsLizgV3IMEOaC1T8Hmfll/xriUwl9 NBqcEsTo9wijweGJ3Ou+fgrx9dRT9fjVOciac= Received: by 10.102.218.8 with SMTP id q8mr2196543mug.45.1240694750837; Sat, 25 Apr 2009 14:25:50 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-121-32.red.bezeqint.net [79.179.121.32]) by mx.google.com with ESMTPS id j9sm7732699mue.17.2009.04.25.14.25.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 25 Apr 2009 14:25:50 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> <49f2efa2.1c215e0a.4454.ffffaf91@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8403@xmb-sjc-215.amer.cisco.com> <49f36ee2.0437560a.11df.1eef@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8405@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C8405@xmb-sjc-215.amer.cisco.com> Date: Sun, 26 Apr 2009 00:24:00 +0300 Message-ID: <49f37fde.09a1660a.2b46.ffffb694@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGHOeBQAAroqxAABGe0AAAAUgbQAAEZLVAAAGk5sAAgqbUwABJxCtAAAIRzIAAAQcKgAADfs5A= Content-Language: en-us Cc: "'Bill Ver Steeg \(versteb\)'" Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 21:24:34 -0000 Ali, See inline Roni -----Original Message----- From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] Sent: Saturday, April 25, 2009 11:30 PM To: Roni Even; avt@ietf.org Cc: Bill Ver Steeg (versteb) Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available Here is the SDP. m=video 41000 RTP/AVPF 98 i=Primary Multicast Stream #2 c=IN IP4 224.1.1.2/255 a=source-filter: incl IN IP4 224.1.1.2 192.0.2.2 Source (192.0.2.2) sends the rtp packets to the multicast group (224.1.1.2) with a dest port 41000. a=rtpmap:98 MP2T/90000 a=rtcp:41001 IN IP4 192.0.2.1 The feedback target (RS) address for this SSM session is 192.0.2.1 and its port is 41001. This is the address/port where RR sends the RAMS-R, or receiver reports for the SSM session. a=rtcp-fb:98 nack a=rtcp-fb:98 nack ssli a=ssrc:123321 cname:iptv-ch32@rams.example.com a=mid:3 m=video 41002 RTP/AVPF 99 The retransmission packets go to port 41002. This is the port RRs listen to for retransmission and RAMS. Roni E: This implies that the multicast source defines the port that all clients MUST use to receive the unicast information from the Burst source. i=Unicast Retransmission Stream #2 (Ret. and Rapid Acq. Support) c=IN IP4 192.0.2.1 This is where the retransmission packets come from, same as the feedback target (in this example). Roni E: If this is the address of the feedback target it belongs to the above m-line (m=video 41002 RTP/AVPF 99) that according to you gives the port on the RR and not on the RS. The problem is that according to SDP the combination of the c= and port on the m-line provides the transport address to where a stream will be sent so according to SDP this m-line specify an address and port on the Feedback Target and not on the RR and only to this address RTP payload type 99 will be sent. I am positive that this is not what you want. a=rtpmap:99 rtx/90000 a=rtcp:41003 This is where the RTCP packets for the retransmission session go. For example, RAMS-I goes to this port on RRs. RAMS-T goes to this port on RS. Roni E: So now you assume that the RR must use the same port as the FT for this communication. I could not find any place that one m-line gives the address for both sides. This RTCP port is on 192.0.2.1 so it will be used for RAMS-R but not for RAMS-I. a=fmtp:99 apt=98; rtx-time=5000 a=mid:4 -acbegen > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Saturday, April 25, 2009 1:11 PM > To: Ali C. Begen (abegen); avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of > Multicast RTPSessions (RAMS)" available > > Ali, > Can you please write three addresses from this strange SDP. > > 1. The address and port of multicast > > 2. The address and port of the RS where the RTCP FB should go to > > 3. The address and port on the RR where the unicast stream > should be sent to > > Roni > > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Saturday, April 25, 2009 11:02 PM > To: Roni Even; avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of > Multicast RTPSessions > (RAMS)" available > > > Ali, > > The example SDP is syntactically correct but it does not > say that the > > rtp/rtcp mux will be used and it does not give the > > information to where the > > unicast stream will be sent when the RR sends a RAMS-R. > > To my knowledge, the first line in the following SDP tells > the RRs on which > port they will receive the retransmission/burst packets. > > m=video 41002 RTP/AVPF 99 > i=Unicast Retransmission Stream #2 (Ret. and Rapid > Acq. Support) > c=IN IP4 192.0.2.1 > a=rtpmap:99 rtx/90000 > a=rtcp:41003 > a=fmtp:99 apt=98; rtx-time=5000 > a=mid:4 > > There is a typo, you are right. That "a=recvonly" line should > only exist in > the SDP sent to RRs. In the SDP sent to RS, we should rather have > "a=sendonly". I will make this correction in the next version. > > The feedback target for the SSM session and the RTCP port for the > retransmission session are also defined in the SDP. > > Hope this clarifies. > > BR, > -acbegen > > > > > I am not sure why the unicast stream m-line has a port > number with an > > attribute of recvonly. What is the use case for that. The > > only information > > that the RR will need is the RTCP port on the RS to where to > > send the RAMS-R > > message. > > Roni > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > Sent: Friday, April 24, 2009 10:37 PM > > To: Roni Even; avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > Multicast RTPSessions > > (RAMS)" available > > > > This is a part of an example SDP sent to RS and RR in a SAP > > announcement, > > for example. So, the SDP describes what both parties should > > do (RR cannot > > say that he wants to receive this multicast on its favorite > port). The > > individual SDPs sent to RR or RS may include other portions > > of descriptions > > that will contain specific information. > > > > -acbegen > > > > > -----Original Message----- > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > Sent: Friday, April 24, 2009 12:23 PM > > > To: Ali C. Begen (abegen); avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > Multicast RTPSessions (RAMS)" available > > > > > > Ali, > > > I think you get it wrong, this SDP is from the RS and not the > > > RR so the RS > > > cannot specify to which address it will send it can only > > > specify to which > > > address it can receive RTP stream. In this SDP the relevant > > > information is > > > that the request for retransmission will be sent by the RR to > > > port 41003 > > > Roni > > > > > > -----Original Message----- > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > Sent: Friday, April 24, 2009 10:01 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > Oh, I see. The burst goes to the port that we would > > normally send the > > > retransmissions. For example, consider the SDP from the draft: > > > > > > m=video 41000 RTP/AVPF 98 > > > i=Primary Multicast Stream #2 > > > c=IN IP4 224.1.1.2/255 > > > a=source-filter: incl IN IP4 224.1.1.2 192.0.2.2 > > > a=rtpmap:98 MP2T/90000 > > > a=rtcp:41001 IN IP4 192.0.2.1 > > > a=rtcp-fb:98 nack > > > a=rtcp-fb:98 nack ssli > > > a=ssrc:123321 cname:iptv-ch32@rams.example.com > > > a=mid:3 > > > m=video 41002 RTP/AVPF 99 > > > i=Unicast Retransmission Stream #2 (Ret. and Rapid > > > Acq. Support) > > > c=IN IP4 192.0.2.1 > > > a=recvonly > > > a=rtpmap:99 rtx/90000 > > > a=rtcp:41003 > > > a=fmtp:99 apt=98; rtx-time=5000 > > > a=mid:4 > > > > > > In this case, the burst will go to port 41002 on the RR. > The RAMS-I > > > message(s), which is an RTCP feedback message, will go to > > port 41003. > > > > > > HTH, > > > -acbegen > > > > > > > -----Original Message----- > > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > > Sent: Friday, April 24, 2009 11:44 AM > > > > To: Ali C. Begen (abegen); avt@ietf.org > > > > Cc: Bill Ver Steeg (versteb) > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > > Multicast RTPSessions (RAMS)" available > > > > > > > > Ali, > > > > I will try to explain in simple way > > > > > > > > When the RS receives the RAMS-R it need to start sending an > > > > RTP stream to > > > > the RR. > > > > In order to send a unicast packet, the RS needs to know a > > > > transport address > > > > on the RR to where the RTP stream will be sent. The current > > > > draft does not > > > > say how the RS knows this address. There is no SDP from RR to > > > > RS like you > > > > mention in your response. > > > > This is why I say that the current draft does not specify a > > > > solution that > > > > can be implemented as a working solution > > > > Roni > > > > > > > > -----Original Message----- > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > > Sent: Friday, April 24, 2009 7:38 PM > > > > To: Roni Even; avt@ietf.org > > > > Cc: Bill Ver Steeg (versteb) > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > > Multicast RTPSessions > > > > (RAMS)" available > > > > > > > > Hi Roni, > > > > > > > > > -----Original Message----- > > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > > > > Behalf Of Roni Even > > > > > Sent: Friday, April 24, 2009 4:24 AM > > > > > To: avt@ietf.org > > > > > Cc: Bill Ver Steeg (versteb) > > > > > Subject: Re: [AVT] New draft of "Rapid Acquisition of > > > > > Multicast RTPSessions (RAMS)" available > > > > > > > > > > Hi, > > > > > > > > > > I think that the current draft does not give a description of > > > > > a system that works since there is no text explaining how the > > > > > > > > What do you mean by "a system that works"? > > > > > > > > > RS knows the unicast transport address on the RR to where to > > > > > send the stream. > > > > > > > > Once RS receives the request packet from an RR, RS knows its > > > > address. Ports > > > > are defined in the SDP. If you are asking about "NAT" issues, > > > > we have a > > > > section for it, and we plan to complete it as we move > > > > forward. It is not as > > > > critical as the other parts for now. > > > > > > > > > If you mandate the use of RTP/RTCP mux it should say so > > > > > otherwise the RAMS-R should have an optional parameter that > > > > > supplies this information and a flag for using RTP/RTCP mux. > > > > > > > > IMO, we cannot mandate muxing as it is not required to make > > > > RAMS work. If > > > > muxing is supported, the SDP should reflect it. > > > > > > > > BR, > > > > -acbegen > > > > > > > > > Thanks > > > > > > > > > > Roni Even > > > > > > > > > > > > > > > > > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > > > > Behalf Of Bill Ver Steeg (versteb) > > > > > Sent: Thursday, April 16, 2009 7:39 PM > > > > > To: avt@ietf.org > > > > > Subject: [AVT] New draft of "Rapid Acquisition of Multicast > > > > > RTP Sessions (RAMS)" available > > > > > > > > > > > > > > > > > > > > There is a new draft of the "Rapid Acquisition of Multicast > > > > > RTP Sessions (RAMS)" draft available at > > > > > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s > > > > ynchronization-for-rtp-03.txt > > > > drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt> > > > > > > > > > > > > > > > > > > > > We have incorporated the changes from the technical breakout > > > > > session in San Francisco. The major changes in this version > > > > > of the draft include > > > > > > > > > > 1- Changing the document title to avoid confusion with other > > > > > ongoing "synchronization" drafts > > > > > > > > > > 2- changing the message names to reflect the title change > > > > > > > > > > 3- clarification of the RTCP message semantics, including > > > > > changes to the "Request" and "Inform" messages > > > > > > > > > > 4- additional description/motivation for the various message > > > > > flows has been added > > > > > > > > > > 5- RTP/RTCP muxing has been added > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We hope to make this a Working Group item, and will change > > > > > the name of the draft to avoid conflicts with other > > > > > "synchronization" drafts at that time. > > > > > > > > > > > > > > > > > > > > Bill VerSteeg > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From ron.even.tlv@gmail.com Sat Apr 25 14:35:28 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D02E3A693D for ; Sat, 25 Apr 2009 14:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[AWL=-0.938, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+tsIov04HcB for ; Sat, 25 Apr 2009 14:35:26 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 3BF043A6A14 for ; Sat, 25 Apr 2009 14:35:26 -0700 (PDT) Received: by bwz7 with SMTP id 7so1648265bwz.37 for ; Sat, 25 Apr 2009 14:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=167piDHfnA6jQWWWb+JVIiQhRGFF4niJwCwuGtzW0Q8=; b=gZCRCMrlArZ9Yu3xWF1lvBrbAW9l1+ITFow9D/PnfZksZ4DyRLWfsvgTlBMOKK8aYb jZCZzou5abiQhiyTAhgtay6fbG+E5B5jcrFkZVIWElPUxcw3ap9iDmxCN9Ej3XUhvMWg pwwIsU72uV9WleMyi3KcZWMqcm/d9cmIBH4JE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=cFxsVQ3gH7SXqiFRH2DTzTuxcHaFxS8CxRAUK1WcAuDs+Kzj/sZbQMsRTWkrSI03Nz QpL4irUvlnGfQOgEOb11kfdy4XBrBC3iFnnihpm9NwWIOwrjkuP/MmURkBL6CBQ/SEeL EYT0fR/wxnleMCqGc9ZKDo4rSsgZEz85nno7o= Received: by 10.103.226.20 with SMTP id d20mr2253713mur.8.1240695404860; Sat, 25 Apr 2009 14:36:44 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-121-32.red.bezeqint.net [79.179.121.32]) by mx.google.com with ESMTPS id y37sm6401326mug.19.2009.04.25.14.36.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 25 Apr 2009 14:36:44 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> <49f2efa2.1c215e0a.4454.ffffaf91@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8403@xmb-sjc-215.amer.cisco.com> <49f36ee2.0437560a.11df.1eef@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8405@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C8405@xmb-sjc-215.amer.cisco.com> Date: Sun, 26 Apr 2009 00:34:51 +0300 Message-ID: <49f3826c.25e2660a.7ce0.7689@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGHOeBQAAroqxAABGe0AAAAUgbQAAEZLVAAAGk5sAAgqbUwABJxCtAAAIRzIAAAQcKgAAKkM+A= Content-Language: en-us Cc: "'Bill Ver Steeg \(versteb\)'" Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 21:35:28 -0000 Ali, Another comment I thought that RAMS-R and RAMS-T go to the same port but in the example you say that RAMS-R go to port 41001 and RAMS-T go to port 41003 Roni -----Original Message----- From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] Sent: Saturday, April 25, 2009 11:30 PM To: Roni Even; avt@ietf.org Cc: Bill Ver Steeg (versteb) Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available Here is the SDP. m=video 41000 RTP/AVPF 98 i=Primary Multicast Stream #2 c=IN IP4 224.1.1.2/255 a=source-filter: incl IN IP4 224.1.1.2 192.0.2.2 Source (192.0.2.2) sends the rtp packets to the multicast group (224.1.1.2) with a dest port 41000. a=rtpmap:98 MP2T/90000 a=rtcp:41001 IN IP4 192.0.2.1 The feedback target (RS) address for this SSM session is 192.0.2.1 and its port is 41001. This is the address/port where RR sends the RAMS-R, or receiver reports for the SSM session. a=rtcp-fb:98 nack a=rtcp-fb:98 nack ssli a=ssrc:123321 cname:iptv-ch32@rams.example.com a=mid:3 m=video 41002 RTP/AVPF 99 The retransmission packets go to port 41002. This is the port RRs listen to for retransmission and RAMS. i=Unicast Retransmission Stream #2 (Ret. and Rapid Acq. Support) c=IN IP4 192.0.2.1 This is where the retransmission packets come from, same as the feedback target (in this example). a=rtpmap:99 rtx/90000 a=rtcp:41003 This is where the RTCP packets for the retransmission session go. For example, RAMS-I goes to this port on RRs. RAMS-T goes to this port on RS. a=fmtp:99 apt=98; rtx-time=5000 a=mid:4 -acbegen > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Saturday, April 25, 2009 1:11 PM > To: Ali C. Begen (abegen); avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of > Multicast RTPSessions (RAMS)" available > > Ali, > Can you please write three addresses from this strange SDP. > > 1. The address and port of multicast > > 2. The address and port of the RS where the RTCP FB should go to > > 3. The address and port on the RR where the unicast stream > should be sent to > > Roni > > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Saturday, April 25, 2009 11:02 PM > To: Roni Even; avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of > Multicast RTPSessions > (RAMS)" available > > > Ali, > > The example SDP is syntactically correct but it does not > say that the > > rtp/rtcp mux will be used and it does not give the > > information to where the > > unicast stream will be sent when the RR sends a RAMS-R. > > To my knowledge, the first line in the following SDP tells > the RRs on which > port they will receive the retransmission/burst packets. > > m=video 41002 RTP/AVPF 99 > i=Unicast Retransmission Stream #2 (Ret. and Rapid > Acq. Support) > c=IN IP4 192.0.2.1 > a=rtpmap:99 rtx/90000 > a=rtcp:41003 > a=fmtp:99 apt=98; rtx-time=5000 > a=mid:4 > > There is a typo, you are right. That "a=recvonly" line should > only exist in > the SDP sent to RRs. In the SDP sent to RS, we should rather have > "a=sendonly". I will make this correction in the next version. > > The feedback target for the SSM session and the RTCP port for the > retransmission session are also defined in the SDP. > > Hope this clarifies. > > BR, > -acbegen > > > > > I am not sure why the unicast stream m-line has a port > number with an > > attribute of recvonly. What is the use case for that. The > > only information > > that the RR will need is the RTCP port on the RS to where to > > send the RAMS-R > > message. > > Roni > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > Sent: Friday, April 24, 2009 10:37 PM > > To: Roni Even; avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > Multicast RTPSessions > > (RAMS)" available > > > > This is a part of an example SDP sent to RS and RR in a SAP > > announcement, > > for example. So, the SDP describes what both parties should > > do (RR cannot > > say that he wants to receive this multicast on its favorite > port). The > > individual SDPs sent to RR or RS may include other portions > > of descriptions > > that will contain specific information. > > > > -acbegen > > > > > -----Original Message----- > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > Sent: Friday, April 24, 2009 12:23 PM > > > To: Ali C. Begen (abegen); avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > Multicast RTPSessions (RAMS)" available > > > > > > Ali, > > > I think you get it wrong, this SDP is from the RS and not the > > > RR so the RS > > > cannot specify to which address it will send it can only > > > specify to which > > > address it can receive RTP stream. In this SDP the relevant > > > information is > > > that the request for retransmission will be sent by the RR to > > > port 41003 > > > Roni > > > > > > -----Original Message----- > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > Sent: Friday, April 24, 2009 10:01 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > Oh, I see. The burst goes to the port that we would > > normally send the > > > retransmissions. For example, consider the SDP from the draft: > > > > > > m=video 41000 RTP/AVPF 98 > > > i=Primary Multicast Stream #2 > > > c=IN IP4 224.1.1.2/255 > > > a=source-filter: incl IN IP4 224.1.1.2 192.0.2.2 > > > a=rtpmap:98 MP2T/90000 > > > a=rtcp:41001 IN IP4 192.0.2.1 > > > a=rtcp-fb:98 nack > > > a=rtcp-fb:98 nack ssli > > > a=ssrc:123321 cname:iptv-ch32@rams.example.com > > > a=mid:3 > > > m=video 41002 RTP/AVPF 99 > > > i=Unicast Retransmission Stream #2 (Ret. and Rapid > > > Acq. Support) > > > c=IN IP4 192.0.2.1 > > > a=recvonly > > > a=rtpmap:99 rtx/90000 > > > a=rtcp:41003 > > > a=fmtp:99 apt=98; rtx-time=5000 > > > a=mid:4 > > > > > > In this case, the burst will go to port 41002 on the RR. > The RAMS-I > > > message(s), which is an RTCP feedback message, will go to > > port 41003. > > > > > > HTH, > > > -acbegen > > > > > > > -----Original Message----- > > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > > Sent: Friday, April 24, 2009 11:44 AM > > > > To: Ali C. Begen (abegen); avt@ietf.org > > > > Cc: Bill Ver Steeg (versteb) > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > > Multicast RTPSessions (RAMS)" available > > > > > > > > Ali, > > > > I will try to explain in simple way > > > > > > > > When the RS receives the RAMS-R it need to start sending an > > > > RTP stream to > > > > the RR. > > > > In order to send a unicast packet, the RS needs to know a > > > > transport address > > > > on the RR to where the RTP stream will be sent. The current > > > > draft does not > > > > say how the RS knows this address. There is no SDP from RR to > > > > RS like you > > > > mention in your response. > > > > This is why I say that the current draft does not specify a > > > > solution that > > > > can be implemented as a working solution > > > > Roni > > > > > > > > -----Original Message----- > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > > Sent: Friday, April 24, 2009 7:38 PM > > > > To: Roni Even; avt@ietf.org > > > > Cc: Bill Ver Steeg (versteb) > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > > Multicast RTPSessions > > > > (RAMS)" available > > > > > > > > Hi Roni, > > > > > > > > > -----Original Message----- > > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > > > > Behalf Of Roni Even > > > > > Sent: Friday, April 24, 2009 4:24 AM > > > > > To: avt@ietf.org > > > > > Cc: Bill Ver Steeg (versteb) > > > > > Subject: Re: [AVT] New draft of "Rapid Acquisition of > > > > > Multicast RTPSessions (RAMS)" available > > > > > > > > > > Hi, > > > > > > > > > > I think that the current draft does not give a description of > > > > > a system that works since there is no text explaining how the > > > > > > > > What do you mean by "a system that works"? > > > > > > > > > RS knows the unicast transport address on the RR to where to > > > > > send the stream. > > > > > > > > Once RS receives the request packet from an RR, RS knows its > > > > address. Ports > > > > are defined in the SDP. If you are asking about "NAT" issues, > > > > we have a > > > > section for it, and we plan to complete it as we move > > > > forward. It is not as > > > > critical as the other parts for now. > > > > > > > > > If you mandate the use of RTP/RTCP mux it should say so > > > > > otherwise the RAMS-R should have an optional parameter that > > > > > supplies this information and a flag for using RTP/RTCP mux. > > > > > > > > IMO, we cannot mandate muxing as it is not required to make > > > > RAMS work. If > > > > muxing is supported, the SDP should reflect it. > > > > > > > > BR, > > > > -acbegen > > > > > > > > > Thanks > > > > > > > > > > Roni Even > > > > > > > > > > > > > > > > > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > > > > Behalf Of Bill Ver Steeg (versteb) > > > > > Sent: Thursday, April 16, 2009 7:39 PM > > > > > To: avt@ietf.org > > > > > Subject: [AVT] New draft of "Rapid Acquisition of Multicast > > > > > RTP Sessions (RAMS)" available > > > > > > > > > > > > > > > > > > > > There is a new draft of the "Rapid Acquisition of Multicast > > > > > RTP Sessions (RAMS)" draft available at > > > > > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s > > > > ynchronization-for-rtp-03.txt > > > > drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt> > > > > > > > > > > > > > > > > > > > > We have incorporated the changes from the technical breakout > > > > > session in San Francisco. The major changes in this version > > > > > of the draft include > > > > > > > > > > 1- Changing the document title to avoid confusion with other > > > > > ongoing "synchronization" drafts > > > > > > > > > > 2- changing the message names to reflect the title change > > > > > > > > > > 3- clarification of the RTCP message semantics, including > > > > > changes to the "Request" and "Inform" messages > > > > > > > > > > 4- additional description/motivation for the various message > > > > > flows has been added > > > > > > > > > > 5- RTP/RTCP muxing has been added > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We hope to make this a Working Group item, and will change > > > > > the name of the draft to avoid conflicts with other > > > > > "synchronization" drafts at that time. > > > > > > > > > > > > > > > > > > > > Bill VerSteeg > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From ron.even.tlv@gmail.com Sat Apr 25 14:58:22 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FA023A6A62 for ; Sat, 25 Apr 2009 14:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[AWL=-0.911, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGaQHWaOTcdu for ; Sat, 25 Apr 2009 14:58:21 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id B3B5F3A693D for ; Sat, 25 Apr 2009 14:58:19 -0700 (PDT) Received: by fxm2 with SMTP id 2so1665416fxm.37 for ; Sat, 25 Apr 2009 14:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=8nbpgg3Z9q1Fm/bAIEM9d1mm4zKGkVknblcJQcGHG3w=; b=BSl70uxzvbiWst+Qnu5JlsgKbMAuKPwB+Vvfn7Ip4HW2jK864D4e9PYiMO6IYiWEgs dlze0diTffaZFZ3GbcKiYigoe0IsVCwQ54Oy/EkMKd21hrSRj16UgE9VXionzY4/DPhL pFfiqHw1I31sk1zxoOaq7H6gw3sLxeiX4K5r0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=KpWUqQz4wVrjLwDk2qn7pT7FJa9igvIGjUwwmDRU2yqgIDuWGgxTWo60C4MoUOs5wt 2TvOHSxBIqUyAGcgOqNoSNUb0qUZhs+MmDNmmPWGGbgtO8+gvRuKQi9SEBEMzQeMn+uy I7kfm7mN5QO4aq5amvc2DOFY2y0IoqDXhf+xs= Received: by 10.86.49.13 with SMTP id w13mr1935094fgw.38.1240696778621; Sat, 25 Apr 2009 14:59:38 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-121-32.red.bezeqint.net [79.179.121.32]) by mx.google.com with ESMTPS id 3sm3260809fge.10.2009.04.25.14.59.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 25 Apr 2009 14:59:38 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> <49f2efa2.1c215e0a.4454.ffffaf91@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8403@xmb-sjc-215.amer.cisco.com> <49f36ee2.0437560a.11df.1eef@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8405@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C8405@xmb-sjc-215.amer.cisco.com> Date: Sun, 26 Apr 2009 00:57:46 +0300 Message-ID: <49f387ca.0305560a.6657.4be7@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGHOeBQAAroqxAABGe0AAAAUgbQAAEZLVAAAGk5sAAgqbUwABJxCtAAAIRzIAAAQcKgAANiJ+A= Content-Language: en-us Cc: "'Bill Ver Steeg \(versteb\)'" Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 21:58:22 -0000 Ali, I looked at RFC 4570 and I assume that port 41001 is the port for the unicast RTCP reports from the receivers and according to section 3.2.1 of that RFC you also should have a RTCP-unicast specification. This is for the multicast receiver reports. Roni -----Original Message----- From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] Sent: Saturday, April 25, 2009 11:30 PM To: Roni Even; avt@ietf.org Cc: Bill Ver Steeg (versteb) Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available Here is the SDP. m=video 41000 RTP/AVPF 98 i=Primary Multicast Stream #2 c=IN IP4 224.1.1.2/255 a=source-filter: incl IN IP4 224.1.1.2 192.0.2.2 Source (192.0.2.2) sends the rtp packets to the multicast group (224.1.1.2) with a dest port 41000. a=rtpmap:98 MP2T/90000 a=rtcp:41001 IN IP4 192.0.2.1 The feedback target (RS) address for this SSM session is 192.0.2.1 and its port is 41001. This is the address/port where RR sends the RAMS-R, or receiver reports for the SSM session. a=rtcp-fb:98 nack a=rtcp-fb:98 nack ssli a=ssrc:123321 cname:iptv-ch32@rams.example.com a=mid:3 m=video 41002 RTP/AVPF 99 The retransmission packets go to port 41002. This is the port RRs listen to for retransmission and RAMS. i=Unicast Retransmission Stream #2 (Ret. and Rapid Acq. Support) c=IN IP4 192.0.2.1 This is where the retransmission packets come from, same as the feedback target (in this example). a=rtpmap:99 rtx/90000 a=rtcp:41003 This is where the RTCP packets for the retransmission session go. For example, RAMS-I goes to this port on RRs. RAMS-T goes to this port on RS. a=fmtp:99 apt=98; rtx-time=5000 a=mid:4 -acbegen > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Saturday, April 25, 2009 1:11 PM > To: Ali C. Begen (abegen); avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of > Multicast RTPSessions (RAMS)" available > > Ali, > Can you please write three addresses from this strange SDP. > > 1. The address and port of multicast > > 2. The address and port of the RS where the RTCP FB should go to > > 3. The address and port on the RR where the unicast stream > should be sent to > > Roni > > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Saturday, April 25, 2009 11:02 PM > To: Roni Even; avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of > Multicast RTPSessions > (RAMS)" available > > > Ali, > > The example SDP is syntactically correct but it does not > say that the > > rtp/rtcp mux will be used and it does not give the > > information to where the > > unicast stream will be sent when the RR sends a RAMS-R. > > To my knowledge, the first line in the following SDP tells > the RRs on which > port they will receive the retransmission/burst packets. > > m=video 41002 RTP/AVPF 99 > i=Unicast Retransmission Stream #2 (Ret. and Rapid > Acq. Support) > c=IN IP4 192.0.2.1 > a=rtpmap:99 rtx/90000 > a=rtcp:41003 > a=fmtp:99 apt=98; rtx-time=5000 > a=mid:4 > > There is a typo, you are right. That "a=recvonly" line should > only exist in > the SDP sent to RRs. In the SDP sent to RS, we should rather have > "a=sendonly". I will make this correction in the next version. > > The feedback target for the SSM session and the RTCP port for the > retransmission session are also defined in the SDP. > > Hope this clarifies. > > BR, > -acbegen > > > > > I am not sure why the unicast stream m-line has a port > number with an > > attribute of recvonly. What is the use case for that. The > > only information > > that the RR will need is the RTCP port on the RS to where to > > send the RAMS-R > > message. > > Roni > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > Sent: Friday, April 24, 2009 10:37 PM > > To: Roni Even; avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > Multicast RTPSessions > > (RAMS)" available > > > > This is a part of an example SDP sent to RS and RR in a SAP > > announcement, > > for example. So, the SDP describes what both parties should > > do (RR cannot > > say that he wants to receive this multicast on its favorite > port). The > > individual SDPs sent to RR or RS may include other portions > > of descriptions > > that will contain specific information. > > > > -acbegen > > > > > -----Original Message----- > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > Sent: Friday, April 24, 2009 12:23 PM > > > To: Ali C. Begen (abegen); avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > Multicast RTPSessions (RAMS)" available > > > > > > Ali, > > > I think you get it wrong, this SDP is from the RS and not the > > > RR so the RS > > > cannot specify to which address it will send it can only > > > specify to which > > > address it can receive RTP stream. In this SDP the relevant > > > information is > > > that the request for retransmission will be sent by the RR to > > > port 41003 > > > Roni > > > > > > -----Original Message----- > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > Sent: Friday, April 24, 2009 10:01 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > Oh, I see. The burst goes to the port that we would > > normally send the > > > retransmissions. For example, consider the SDP from the draft: > > > > > > m=video 41000 RTP/AVPF 98 > > > i=Primary Multicast Stream #2 > > > c=IN IP4 224.1.1.2/255 > > > a=source-filter: incl IN IP4 224.1.1.2 192.0.2.2 > > > a=rtpmap:98 MP2T/90000 > > > a=rtcp:41001 IN IP4 192.0.2.1 > > > a=rtcp-fb:98 nack > > > a=rtcp-fb:98 nack ssli > > > a=ssrc:123321 cname:iptv-ch32@rams.example.com > > > a=mid:3 > > > m=video 41002 RTP/AVPF 99 > > > i=Unicast Retransmission Stream #2 (Ret. and Rapid > > > Acq. Support) > > > c=IN IP4 192.0.2.1 > > > a=recvonly > > > a=rtpmap:99 rtx/90000 > > > a=rtcp:41003 > > > a=fmtp:99 apt=98; rtx-time=5000 > > > a=mid:4 > > > > > > In this case, the burst will go to port 41002 on the RR. > The RAMS-I > > > message(s), which is an RTCP feedback message, will go to > > port 41003. > > > > > > HTH, > > > -acbegen > > > > > > > -----Original Message----- > > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > > Sent: Friday, April 24, 2009 11:44 AM > > > > To: Ali C. Begen (abegen); avt@ietf.org > > > > Cc: Bill Ver Steeg (versteb) > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > > Multicast RTPSessions (RAMS)" available > > > > > > > > Ali, > > > > I will try to explain in simple way > > > > > > > > When the RS receives the RAMS-R it need to start sending an > > > > RTP stream to > > > > the RR. > > > > In order to send a unicast packet, the RS needs to know a > > > > transport address > > > > on the RR to where the RTP stream will be sent. The current > > > > draft does not > > > > say how the RS knows this address. There is no SDP from RR to > > > > RS like you > > > > mention in your response. > > > > This is why I say that the current draft does not specify a > > > > solution that > > > > can be implemented as a working solution > > > > Roni > > > > > > > > -----Original Message----- > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > > Sent: Friday, April 24, 2009 7:38 PM > > > > To: Roni Even; avt@ietf.org > > > > Cc: Bill Ver Steeg (versteb) > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > > Multicast RTPSessions > > > > (RAMS)" available > > > > > > > > Hi Roni, > > > > > > > > > -----Original Message----- > > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > > > > Behalf Of Roni Even > > > > > Sent: Friday, April 24, 2009 4:24 AM > > > > > To: avt@ietf.org > > > > > Cc: Bill Ver Steeg (versteb) > > > > > Subject: Re: [AVT] New draft of "Rapid Acquisition of > > > > > Multicast RTPSessions (RAMS)" available > > > > > > > > > > Hi, > > > > > > > > > > I think that the current draft does not give a description of > > > > > a system that works since there is no text explaining how the > > > > > > > > What do you mean by "a system that works"? > > > > > > > > > RS knows the unicast transport address on the RR to where to > > > > > send the stream. > > > > > > > > Once RS receives the request packet from an RR, RS knows its > > > > address. Ports > > > > are defined in the SDP. If you are asking about "NAT" issues, > > > > we have a > > > > section for it, and we plan to complete it as we move > > > > forward. It is not as > > > > critical as the other parts for now. > > > > > > > > > If you mandate the use of RTP/RTCP mux it should say so > > > > > otherwise the RAMS-R should have an optional parameter that > > > > > supplies this information and a flag for using RTP/RTCP mux. > > > > > > > > IMO, we cannot mandate muxing as it is not required to make > > > > RAMS work. If > > > > muxing is supported, the SDP should reflect it. > > > > > > > > BR, > > > > -acbegen > > > > > > > > > Thanks > > > > > > > > > > Roni Even > > > > > > > > > > > > > > > > > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > > > > Behalf Of Bill Ver Steeg (versteb) > > > > > Sent: Thursday, April 16, 2009 7:39 PM > > > > > To: avt@ietf.org > > > > > Subject: [AVT] New draft of "Rapid Acquisition of Multicast > > > > > RTP Sessions (RAMS)" available > > > > > > > > > > > > > > > > > > > > There is a new draft of the "Rapid Acquisition of Multicast > > > > > RTP Sessions (RAMS)" draft available at > > > > > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s > > > > ynchronization-for-rtp-03.txt > > > > drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt> > > > > > > > > > > > > > > > > > > > > We have incorporated the changes from the technical breakout > > > > > session in San Francisco. The major changes in this version > > > > > of the draft include > > > > > > > > > > 1- Changing the document title to avoid confusion with other > > > > > ongoing "synchronization" drafts > > > > > > > > > > 2- changing the message names to reflect the title change > > > > > > > > > > 3- clarification of the RTCP message semantics, including > > > > > changes to the "Request" and "Inform" messages > > > > > > > > > > 4- additional description/motivation for the various message > > > > > flows has been added > > > > > > > > > > 5- RTP/RTCP muxing has been added > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We hope to make this a Working Group item, and will change > > > > > the name of the draft to avoid conflicts with other > > > > > "synchronization" drafts at that time. > > > > > > > > > > > > > > > > > > > > Bill VerSteeg > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From abegen@cisco.com Sat Apr 25 15:24:56 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEE623A6D38 for ; Sat, 25 Apr 2009 15:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.205 X-Spam-Level: X-Spam-Status: No, score=-5.205 tagged_above=-999 required=5 tests=[AWL=-1.006, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t03eLc2dCcmX for ; Sat, 25 Apr 2009 15:24:55 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0C1583A6BA6 for ; Sat, 25 Apr 2009 15:24:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,247,1238976000"; d="scan'208";a="292953722" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 25 Apr 2009 22:25:22 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3PMPMbr030002; Sat, 25 Apr 2009 15:25:22 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n3PMPMuE029306; Sat, 25 Apr 2009 22:25:22 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Apr 2009 15:25:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 25 Apr 2009 15:23:17 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C8408@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49f37fde.09a1660a.2b46.ffffb694@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available Thread-Index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGHOeBQAAroqxAABGe0AAAAUgbQAAEZLVAAAGk5sAAgqbUwABJxCtAAAIRzIAAAQcKgAADfs5AAAik1MA== References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> <49f2efa2.1c215e0a.4454.ffffaf91@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8403@xmb-sjc-215.amer.cisco.com> <49f36ee2.0437560a.11df.1eef@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8405@xmb-sjc-215.amer.cisco.com> <49f37fde.09a1660a.2b46.ffffb694@mx.google.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , X-OriginalArrivalTime: 25 Apr 2009 22:25:22.0654 (UTC) FILETIME=[B9323FE0:01C9C5F4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15126; t=1240698322; x=1241562322; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20New=20draft=20of=20=22Rapid=20A cquisition=20of=20Multicast=20RTPSessions=09(RAMS)=22=20avai lable |Sender:=20; bh=ZYpKG5KURU519R0nUGZoE1OOp7/CxMgkW3V9+w1PcmQ=; b=0bm4yu3cIgmlw30TEByCUehBICEZKHW2SiS2DwVd1SFBye0nE3+ZC04Py/ ajFI4LKFzmeYqcv6w1CaQgvbtIBPcWdRsBhgtfxrWnqqbfnNNpSjryjd2EeT lWH8zAvF7F; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "Bill Ver Steeg \(versteb\)" Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 22:24:56 -0000 Inline. > m=3Dvideo 41000 RTP/AVPF 98 > i=3DPrimary Multicast Stream #2 > c=3DIN IP4 224.1.1.2/255 > a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 >=20 > Source (192.0.2.2) sends the rtp packets to the multicast=20 > group (224.1.1.2) > with a dest port 41000. >=20 > a=3Drtpmap:98 MP2T/90000 > a=3Drtcp:41001 IN IP4 192.0.2.1 >=20 > The feedback target (RS) address for this SSM session is=20 > 192.0.2.1 and its > port is 41001. This is the address/port where RR sends the RAMS-R, or > receiver reports for the SSM session. >=20 > a=3Drtcp-fb:98 nack > a=3Drtcp-fb:98 nack ssli > a=3Dssrc:123321 cname:iptv-ch32@rams.example.com > a=3Dmid:3 > m=3Dvideo 41002 RTP/AVPF 99 >=20 > The retransmission packets go to port 41002. This is the port=20 > RRs listen to > for retransmission and RAMS. >=20 > Roni E: This implies that the multicast source defines the=20 > port that all > clients MUST use to receive the unicast information from the=20 > Burst source. =20 Yes, that is what it implies (One nit is that I would call it unicast = RTP packets rather than information since we may use another port for = RTCP packets). =20 > i=3DUnicast Retransmission Stream #2 (Ret. and Rapid=20 > Acq. Support) > c=3DIN IP4 192.0.2.1 >=20 > This is where the retransmission packets come from, same as=20 > the feedback > target (in this example). >=20 > Roni E: If this is the address of the feedback target it=20 > belongs to the > above m-line (m=3Dvideo 41002 RTP/AVPF 99) that according to=20 > you gives the > port on the RR and not on the RS. The problem is that=20 This line actually specifies the sender for the unicast retransmission = session. In our case, it just happens to be the feedback target for the = primary SSM session, too. I recall some discussion about using a = retransmission source which is different than the feedback target for = the SSM. In that case, the address would be different, I guess. > according to SDP the > combination of the c=3D and port on the m-line provides the=20 > transport address > to where a stream will be sent so according to SDP this=20 The port on the m line is the port where the retranmission packets are = sent. However, c line denotes the source for these packets. RFC 4566 = page 13 says that "... If the session is not multicast, then the = connection address contains the unicast IP address of the expected data = source or data relay or data sink as determined by additional attribute = fields..." Am I missing something? > m-line specify an > address and port on the Feedback Target and not on the RR and=20 > only to this > address RTP payload type 99 will be sent. I am positive that=20 > this is not > what you want. There can be other payload types we might need to send on this = retransmission session in the future. In that case, we will add them. =20 > a=3Drtpmap:99 rtx/90000 > a=3Drtcp:41003 >=20 > This is where the RTCP packets for the retransmission session go. For > example, RAMS-I goes to this port on RRs. RAMS-T goes to this=20 > port on RS. >=20 > Roni E: So now you assume that the RR must use the same port=20 > as the FT for > this communication. I could not find any place that one=20 > m-line gives the Not the m line, but the "a=3Drtcp" line. Is this wrong? > address for both sides. This RTCP port is on 192.0.2.1 so it=20 > will be used > for RAMS-R but not for RAMS-I. RAMS-R should go to the feedback target address and port for the primary = SSM session since it is a feedback message for the SSM session. But, = RAMS-T is a feedback message for the retransmission session, thus, it = should go to the RTCP port of the retransmission session (41003). I hope = this also clarifies your question in the next email. If you think I got = the ports wrong, let me know. -acbegen =20 > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > a=3Dmid:4 >=20 >=20 > -acbegen > =20 >=20 > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > > Sent: Saturday, April 25, 2009 1:11 PM > > To: Ali C. Begen (abegen); avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > Multicast RTPSessions (RAMS)" available > >=20 > > Ali, > > Can you please write three addresses from this strange SDP. > >=20 > > 1. The address and port of multicast > >=20 > > 2. The address and port of the RS where the RTCP FB should go to > >=20 > > 3. The address and port on the RR where the unicast stream=20 > > should be sent to > >=20 > > Roni > >=20 > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > > Sent: Saturday, April 25, 2009 11:02 PM > > To: Roni Even; avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > Multicast RTPSessions > > (RAMS)" available > >=20 > > > Ali, > > > The example SDP is syntactically correct but it does not=20 > > say that the > > > rtp/rtcp mux will be used and it does not give the=20 > > > information to where the > > > unicast stream will be sent when the RR sends a RAMS-R.=20 > >=20 > > To my knowledge, the first line in the following SDP tells=20 > > the RRs on which > > port they will receive the retransmission/burst packets. > >=20 > > m=3Dvideo 41002 RTP/AVPF 99 > > i=3DUnicast Retransmission Stream #2 (Ret. and Rapid=20 > > Acq. Support) > > c=3DIN IP4 192.0.2.1 > > a=3Drtpmap:99 rtx/90000 > > a=3Drtcp:41003 > > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > > a=3Dmid:4 > >=20 > > There is a typo, you are right. That "a=3Drecvonly" line should=20 > > only exist in > > the SDP sent to RRs. In the SDP sent to RS, we should rather have > > "a=3Dsendonly". I will make this correction in the next version. > >=20 > > The feedback target for the SSM session and the RTCP port for the > > retransmission session are also defined in the SDP. > >=20 > > Hope this clarifies. > >=20 > > BR, > > -acbegen > > =20 > > >=20 > > > I am not sure why the unicast stream m-line has a port=20 > > number with an > > > attribute of recvonly. What is the use case for that. The=20 > > > only information > > > that the RR will need is the RTCP port on the RS to where to=20 > > > send the RAMS-R > > > message. > > > Roni > > > -----Original Message----- > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > > > Sent: Friday, April 24, 2009 10:37 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > Multicast RTPSessions > > > (RAMS)" available > > >=20 > > > This is a part of an example SDP sent to RS and RR in a SAP=20 > > > announcement, > > > for example. So, the SDP describes what both parties should=20 > > > do (RR cannot > > > say that he wants to receive this multicast on its favorite=20 > > port). The > > > individual SDPs sent to RR or RS may include other portions=20 > > > of descriptions > > > that will contain specific information.=20 > > >=20 > > > -acbegen > > >=20 > > > > -----Original Message----- > > > > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > > > > Sent: Friday, April 24, 2009 12:23 PM > > > > To: Ali C. Begen (abegen); avt@ietf.org > > > > Cc: Bill Ver Steeg (versteb) > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > > Multicast RTPSessions (RAMS)" available > > > >=20 > > > > Ali, > > > > I think you get it wrong, this SDP is from the RS and not the=20 > > > > RR so the RS > > > > cannot specify to which address it will send it can only=20 > > > > specify to which > > > > address it can receive RTP stream. In this SDP the relevant=20 > > > > information is > > > > that the request for retransmission will be sent by the RR to=20 > > > > port 41003 > > > > Roni > > > >=20 > > > > -----Original Message----- > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > > > > Sent: Friday, April 24, 2009 10:01 PM > > > > To: Roni Even; avt@ietf.org > > > > Cc: Bill Ver Steeg (versteb) > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > > Multicast RTPSessions > > > > (RAMS)" available > > > >=20 > > > > Oh, I see. The burst goes to the port that we would=20 > > > normally send the > > > > retransmissions. For example, consider the SDP from the draft: > > > >=20 > > > > m=3Dvideo 41000 RTP/AVPF 98 > > > > i=3DPrimary Multicast Stream #2 > > > > c=3DIN IP4 224.1.1.2/255 > > > > a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 > > > > a=3Drtpmap:98 MP2T/90000 > > > > a=3Drtcp:41001 IN IP4 192.0.2.1 > > > > a=3Drtcp-fb:98 nack > > > > a=3Drtcp-fb:98 nack ssli > > > > a=3Dssrc:123321 cname:iptv-ch32@rams.example.com > > > > a=3Dmid:3 > > > > m=3Dvideo 41002 RTP/AVPF 99 > > > > i=3DUnicast Retransmission Stream #2 (Ret. and Rapid=20 > > > > Acq. Support) > > > > c=3DIN IP4 192.0.2.1 > > > > a=3Drecvonly > > > > a=3Drtpmap:99 rtx/90000 > > > > a=3Drtcp:41003 > > > > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > > > > a=3Dmid:4 > > > >=20 > > > > In this case, the burst will go to port 41002 on the RR.=20 > > The RAMS-I > > > > message(s), which is an RTCP feedback message, will go to=20 > > > port 41003. > > > >=20 > > > > HTH, > > > > -acbegen > > > >=20 > > > > > -----Original Message----- > > > > > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > > > > > Sent: Friday, April 24, 2009 11:44 AM > > > > > To: Ali C. Begen (abegen); avt@ietf.org > > > > > Cc: Bill Ver Steeg (versteb) > > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > > > Multicast RTPSessions (RAMS)" available > > > > >=20 > > > > > Ali, > > > > > I will try to explain in simple way > > > > >=20 > > > > > When the RS receives the RAMS-R it need to start sending an=20 > > > > > RTP stream to > > > > > the RR.=20 > > > > > In order to send a unicast packet, the RS needs to know a=20 > > > > > transport address > > > > > on the RR to where the RTP stream will be sent. The current=20 > > > > > draft does not > > > > > say how the RS knows this address. There is no SDP from RR to=20 > > > > > RS like you > > > > > mention in your response. > > > > > This is why I say that the current draft does not specify a=20 > > > > > solution that > > > > > can be implemented as a working solution > > > > > Roni > > > > >=20 > > > > > -----Original Message----- > > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > > > > > Sent: Friday, April 24, 2009 7:38 PM > > > > > To: Roni Even; avt@ietf.org > > > > > Cc: Bill Ver Steeg (versteb) > > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > > > Multicast RTPSessions > > > > > (RAMS)" available > > > > >=20 > > > > > Hi Roni,=20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > > > > > > Behalf Of Roni Even > > > > > > Sent: Friday, April 24, 2009 4:24 AM > > > > > > To: avt@ietf.org > > > > > > Cc: Bill Ver Steeg (versteb) > > > > > > Subject: Re: [AVT] New draft of "Rapid Acquisition of=20 > > > > > > Multicast RTPSessions (RAMS)" available > > > > > >=20 > > > > > > Hi, > > > > > >=20 > > > > > > I think that the current draft does not give a=20 > description of=20 > > > > > > a system that works since there is no text=20 > explaining how the=20 > > > > >=20 > > > > > What do you mean by "a system that works"?=20 > > > > >=20 > > > > > > RS knows the unicast transport address on the RR to=20 > where to=20 > > > > > > send the stream.=20 > > > > >=20 > > > > > Once RS receives the request packet from an RR, RS knows its=20 > > > > > address. Ports > > > > > are defined in the SDP. If you are asking about "NAT" issues,=20 > > > > > we have a > > > > > section for it, and we plan to complete it as we move=20 > > > > > forward. It is not as > > > > > critical as the other parts for now. > > > > > =20 > > > > > > If you mandate the use of RTP/RTCP mux it should say so=20 > > > > > > otherwise the RAMS-R should have an optional parameter that=20 > > > > > > supplies this information and a flag for using RTP/RTCP mux. > > > > >=20 > > > > > IMO, we cannot mandate muxing as it is not required to make=20 > > > > > RAMS work. If > > > > > muxing is supported, the SDP should reflect it. > > > > >=20 > > > > > BR, > > > > > -acbegen > > > > > =20 > > > > > > Thanks > > > > > >=20 > > > > > > Roni Even > > > > > >=20 > > > > > > =20 > > > > > >=20 > > > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > > > > > > Behalf Of Bill Ver Steeg (versteb) > > > > > > Sent: Thursday, April 16, 2009 7:39 PM > > > > > > To: avt@ietf.org > > > > > > Subject: [AVT] New draft of "Rapid Acquisition of Multicast=20 > > > > > > RTP Sessions (RAMS)" available > > > > > >=20 > > > > > > =20 > > > > > >=20 > > > > > > There is a new draft of the "Rapid Acquisition of Multicast=20 > > > > > > RTP Sessions (RAMS)" draft available at=20 > > > > > >=20 > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s > > > > > ynchronization-for-rtp-03.txt > > > > >=20 > drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt>=20 > > > > > >=20 > > > > > > =20 > > > > > >=20 > > > > > > We have incorporated the changes from the technical=20 > breakout=20 > > > > > > session in San Francisco. The major changes in this version=20 > > > > > > of the draft include=20 > > > > > >=20 > > > > > > 1- Changing the document title to avoid confusion=20 > with other=20 > > > > > > ongoing "synchronization" drafts > > > > > >=20 > > > > > > 2- changing the message names to reflect the title change > > > > > >=20 > > > > > > 3- clarification of the RTCP message semantics, including=20 > > > > > > changes to the "Request" and "Inform" messages > > > > > >=20 > > > > > > 4- additional description/motivation for the=20 > various message=20 > > > > > > flows has been added > > > > > >=20 > > > > > > 5- RTP/RTCP muxing has been added > > > > > >=20 > > > > > > =20 > > > > > >=20 > > > > > > =20 > > > > > >=20 > > > > > > We hope to make this a Working Group item, and will change=20 > > > > > > the name of the draft to avoid conflicts with other=20 > > > > > > "synchronization" drafts at that time. > > > > > >=20 > > > > > > =20 > > > > > >=20 > > > > > > Bill VerSteeg > > > > > >=20 > > > > > > =20 > > > > > >=20 > > > > > > =20 > > > > > >=20 > > > > > >=20 > > > > >=20 > > > > >=20 > > > >=20 > > > >=20 > > >=20 > > >=20 > >=20 > >=20 >=20 >=20 From abegen@cisco.com Sat Apr 25 15:26:39 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 806BB3A6C4C for ; Sat, 25 Apr 2009 15:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.185 X-Spam-Level: X-Spam-Status: No, score=-5.185 tagged_above=-999 required=5 tests=[AWL=-0.986, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSO82nQDCTIa for ; Sat, 25 Apr 2009 15:26:38 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 737793A6DDE for ; Sat, 25 Apr 2009 15:26:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,247,1238976000"; d="scan'208";a="292954072" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 25 Apr 2009 22:26:49 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3PMQndf032035; Sat, 25 Apr 2009 15:26:49 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n3PMQm6H029610; Sat, 25 Apr 2009 22:26:49 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Apr 2009 15:26:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 25 Apr 2009 15:26:44 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C840A@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49f387ca.0305560a.6657.4be7@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available Thread-Index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGHOeBQAAroqxAABGe0AAAAUgbQAAEZLVAAAGk5sAAgqbUwABJxCtAAAIRzIAAAQcKgAANiJ+AAAQT/QA== References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> <49f2efa2.1c215e0a.4454.ffffaf91@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8403@xmb-sjc-215.amer.cisco.com> <49f36ee2.0437560a.11df.1eef@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8405@xmb-sjc-215.amer.cisco.com> <49f387ca.0305560a.6657.4be7@mx.google.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , X-OriginalArrivalTime: 25 Apr 2009 22:26:48.0840 (UTC) FILETIME=[EC913080:01C9C5F4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13599; t=1240698409; x=1241562409; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20New=20draft=20of=20=22Rapid=20A cquisition=20of=20Multicast=20RTPSessions=09(RAMS)=22=20avai lable |Sender:=20; bh=pmoE51/NuPub791EjoX4KLGjZIUtG4S0ByXSZSumgCM=; b=tUcev15dsLYL3OYR3yB2n8z9zNRrtt/pP6GbtQUO1YQdITvpW7rZusWo8o dQf+yWbQr5ZwyxglzZ9kqzym0bWbJJzBmXp3E+P0MVkfkkPbHI6jLqkEs3da 3rtVP7ebEB; Authentication-Results: sj-dkim-4; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: "Bill Ver Steeg \(versteb\)" Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 22:26:39 -0000 =20 > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > Sent: Saturday, April 25, 2009 2:58 PM > To: Ali C. Begen (abegen); avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > Multicast RTPSessions (RAMS)" available >=20 > Ali, > I looked at RFC 4570 and I assume that port 41001 is the port for the > unicast RTCP reports from the receivers and according to Yes, indeed. =20 > section 3.2.1 of > that RFC you also should have a RTCP-unicast specification.=20 > This is for the > multicast receiver reports. Correct. We do have that line in our draft at the top right after the = grouping lines: a=3Drtcp-unicast:rsi BR, -acbegen =20 > Roni >=20 > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > Sent: Saturday, April 25, 2009 11:30 PM > To: Roni Even; avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > Multicast RTPSessions > (RAMS)" available >=20 > Here is the SDP. >=20 > m=3Dvideo 41000 RTP/AVPF 98 > i=3DPrimary Multicast Stream #2 > c=3DIN IP4 224.1.1.2/255 > a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 >=20 > Source (192.0.2.2) sends the rtp packets to the multicast=20 > group (224.1.1.2) > with a dest port 41000. >=20 > a=3Drtpmap:98 MP2T/90000 > a=3Drtcp:41001 IN IP4 192.0.2.1 >=20 > The feedback target (RS) address for this SSM session is=20 > 192.0.2.1 and its > port is 41001. This is the address/port where RR sends the RAMS-R, or > receiver reports for the SSM session. >=20 > a=3Drtcp-fb:98 nack > a=3Drtcp-fb:98 nack ssli > a=3Dssrc:123321 cname:iptv-ch32@rams.example.com > a=3Dmid:3 > m=3Dvideo 41002 RTP/AVPF 99 >=20 > The retransmission packets go to port 41002. This is the port=20 > RRs listen to > for retransmission and RAMS. >=20 > i=3DUnicast Retransmission Stream #2 (Ret. and Rapid=20 > Acq. Support) > c=3DIN IP4 192.0.2.1 >=20 > This is where the retransmission packets come from, same as=20 > the feedback > target (in this example). >=20 > a=3Drtpmap:99 rtx/90000 > a=3Drtcp:41003 >=20 > This is where the RTCP packets for the retransmission session go. For > example, RAMS-I goes to this port on RRs. RAMS-T goes to this=20 > port on RS. >=20 > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > a=3Dmid:4 >=20 >=20 > -acbegen > =20 >=20 > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > > Sent: Saturday, April 25, 2009 1:11 PM > > To: Ali C. Begen (abegen); avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > Multicast RTPSessions (RAMS)" available > >=20 > > Ali, > > Can you please write three addresses from this strange SDP. > >=20 > > 1. The address and port of multicast > >=20 > > 2. The address and port of the RS where the RTCP FB should go to > >=20 > > 3. The address and port on the RR where the unicast stream=20 > > should be sent to > >=20 > > Roni > >=20 > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > > Sent: Saturday, April 25, 2009 11:02 PM > > To: Roni Even; avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > Multicast RTPSessions > > (RAMS)" available > >=20 > > > Ali, > > > The example SDP is syntactically correct but it does not=20 > > say that the > > > rtp/rtcp mux will be used and it does not give the=20 > > > information to where the > > > unicast stream will be sent when the RR sends a RAMS-R.=20 > >=20 > > To my knowledge, the first line in the following SDP tells=20 > > the RRs on which > > port they will receive the retransmission/burst packets. > >=20 > > m=3Dvideo 41002 RTP/AVPF 99 > > i=3DUnicast Retransmission Stream #2 (Ret. and Rapid=20 > > Acq. Support) > > c=3DIN IP4 192.0.2.1 > > a=3Drtpmap:99 rtx/90000 > > a=3Drtcp:41003 > > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > > a=3Dmid:4 > >=20 > > There is a typo, you are right. That "a=3Drecvonly" line should=20 > > only exist in > > the SDP sent to RRs. In the SDP sent to RS, we should rather have > > "a=3Dsendonly". I will make this correction in the next version. > >=20 > > The feedback target for the SSM session and the RTCP port for the > > retransmission session are also defined in the SDP. > >=20 > > Hope this clarifies. > >=20 > > BR, > > -acbegen > > =20 > > >=20 > > > I am not sure why the unicast stream m-line has a port=20 > > number with an > > > attribute of recvonly. What is the use case for that. The=20 > > > only information > > > that the RR will need is the RTCP port on the RS to where to=20 > > > send the RAMS-R > > > message. > > > Roni > > > -----Original Message----- > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > > > Sent: Friday, April 24, 2009 10:37 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > Multicast RTPSessions > > > (RAMS)" available > > >=20 > > > This is a part of an example SDP sent to RS and RR in a SAP=20 > > > announcement, > > > for example. So, the SDP describes what both parties should=20 > > > do (RR cannot > > > say that he wants to receive this multicast on its favorite=20 > > port). The > > > individual SDPs sent to RR or RS may include other portions=20 > > > of descriptions > > > that will contain specific information.=20 > > >=20 > > > -acbegen > > >=20 > > > > -----Original Message----- > > > > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > > > > Sent: Friday, April 24, 2009 12:23 PM > > > > To: Ali C. Begen (abegen); avt@ietf.org > > > > Cc: Bill Ver Steeg (versteb) > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > > Multicast RTPSessions (RAMS)" available > > > >=20 > > > > Ali, > > > > I think you get it wrong, this SDP is from the RS and not the=20 > > > > RR so the RS > > > > cannot specify to which address it will send it can only=20 > > > > specify to which > > > > address it can receive RTP stream. In this SDP the relevant=20 > > > > information is > > > > that the request for retransmission will be sent by the RR to=20 > > > > port 41003 > > > > Roni > > > >=20 > > > > -----Original Message----- > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > > > > Sent: Friday, April 24, 2009 10:01 PM > > > > To: Roni Even; avt@ietf.org > > > > Cc: Bill Ver Steeg (versteb) > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > > Multicast RTPSessions > > > > (RAMS)" available > > > >=20 > > > > Oh, I see. The burst goes to the port that we would=20 > > > normally send the > > > > retransmissions. For example, consider the SDP from the draft: > > > >=20 > > > > m=3Dvideo 41000 RTP/AVPF 98 > > > > i=3DPrimary Multicast Stream #2 > > > > c=3DIN IP4 224.1.1.2/255 > > > > a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 > > > > a=3Drtpmap:98 MP2T/90000 > > > > a=3Drtcp:41001 IN IP4 192.0.2.1 > > > > a=3Drtcp-fb:98 nack > > > > a=3Drtcp-fb:98 nack ssli > > > > a=3Dssrc:123321 cname:iptv-ch32@rams.example.com > > > > a=3Dmid:3 > > > > m=3Dvideo 41002 RTP/AVPF 99 > > > > i=3DUnicast Retransmission Stream #2 (Ret. and Rapid=20 > > > > Acq. Support) > > > > c=3DIN IP4 192.0.2.1 > > > > a=3Drecvonly > > > > a=3Drtpmap:99 rtx/90000 > > > > a=3Drtcp:41003 > > > > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > > > > a=3Dmid:4 > > > >=20 > > > > In this case, the burst will go to port 41002 on the RR.=20 > > The RAMS-I > > > > message(s), which is an RTCP feedback message, will go to=20 > > > port 41003. > > > >=20 > > > > HTH, > > > > -acbegen > > > >=20 > > > > > -----Original Message----- > > > > > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > > > > > Sent: Friday, April 24, 2009 11:44 AM > > > > > To: Ali C. Begen (abegen); avt@ietf.org > > > > > Cc: Bill Ver Steeg (versteb) > > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > > > Multicast RTPSessions (RAMS)" available > > > > >=20 > > > > > Ali, > > > > > I will try to explain in simple way > > > > >=20 > > > > > When the RS receives the RAMS-R it need to start sending an=20 > > > > > RTP stream to > > > > > the RR.=20 > > > > > In order to send a unicast packet, the RS needs to know a=20 > > > > > transport address > > > > > on the RR to where the RTP stream will be sent. The current=20 > > > > > draft does not > > > > > say how the RS knows this address. There is no SDP from RR to=20 > > > > > RS like you > > > > > mention in your response. > > > > > This is why I say that the current draft does not specify a=20 > > > > > solution that > > > > > can be implemented as a working solution > > > > > Roni > > > > >=20 > > > > > -----Original Message----- > > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > > > > > Sent: Friday, April 24, 2009 7:38 PM > > > > > To: Roni Even; avt@ietf.org > > > > > Cc: Bill Ver Steeg (versteb) > > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > > > Multicast RTPSessions > > > > > (RAMS)" available > > > > >=20 > > > > > Hi Roni,=20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > > > > > > Behalf Of Roni Even > > > > > > Sent: Friday, April 24, 2009 4:24 AM > > > > > > To: avt@ietf.org > > > > > > Cc: Bill Ver Steeg (versteb) > > > > > > Subject: Re: [AVT] New draft of "Rapid Acquisition of=20 > > > > > > Multicast RTPSessions (RAMS)" available > > > > > >=20 > > > > > > Hi, > > > > > >=20 > > > > > > I think that the current draft does not give a=20 > description of=20 > > > > > > a system that works since there is no text=20 > explaining how the=20 > > > > >=20 > > > > > What do you mean by "a system that works"?=20 > > > > >=20 > > > > > > RS knows the unicast transport address on the RR to=20 > where to=20 > > > > > > send the stream.=20 > > > > >=20 > > > > > Once RS receives the request packet from an RR, RS knows its=20 > > > > > address. Ports > > > > > are defined in the SDP. If you are asking about "NAT" issues,=20 > > > > > we have a > > > > > section for it, and we plan to complete it as we move=20 > > > > > forward. It is not as > > > > > critical as the other parts for now. > > > > > =20 > > > > > > If you mandate the use of RTP/RTCP mux it should say so=20 > > > > > > otherwise the RAMS-R should have an optional parameter that=20 > > > > > > supplies this information and a flag for using RTP/RTCP mux. > > > > >=20 > > > > > IMO, we cannot mandate muxing as it is not required to make=20 > > > > > RAMS work. If > > > > > muxing is supported, the SDP should reflect it. > > > > >=20 > > > > > BR, > > > > > -acbegen > > > > > =20 > > > > > > Thanks > > > > > >=20 > > > > > > Roni Even > > > > > >=20 > > > > > > =20 > > > > > >=20 > > > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > > > > > > Behalf Of Bill Ver Steeg (versteb) > > > > > > Sent: Thursday, April 16, 2009 7:39 PM > > > > > > To: avt@ietf.org > > > > > > Subject: [AVT] New draft of "Rapid Acquisition of Multicast=20 > > > > > > RTP Sessions (RAMS)" available > > > > > >=20 > > > > > > =20 > > > > > >=20 > > > > > > There is a new draft of the "Rapid Acquisition of Multicast=20 > > > > > > RTP Sessions (RAMS)" draft available at=20 > > > > > >=20 > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s > > > > > ynchronization-for-rtp-03.txt > > > > >=20 > drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt>=20 > > > > > >=20 > > > > > > =20 > > > > > >=20 > > > > > > We have incorporated the changes from the technical=20 > breakout=20 > > > > > > session in San Francisco. The major changes in this version=20 > > > > > > of the draft include=20 > > > > > >=20 > > > > > > 1- Changing the document title to avoid confusion=20 > with other=20 > > > > > > ongoing "synchronization" drafts > > > > > >=20 > > > > > > 2- changing the message names to reflect the title change > > > > > >=20 > > > > > > 3- clarification of the RTCP message semantics, including=20 > > > > > > changes to the "Request" and "Inform" messages > > > > > >=20 > > > > > > 4- additional description/motivation for the=20 > various message=20 > > > > > > flows has been added > > > > > >=20 > > > > > > 5- RTP/RTCP muxing has been added > > > > > >=20 > > > > > > =20 > > > > > >=20 > > > > > > =20 > > > > > >=20 > > > > > > We hope to make this a Working Group item, and will change=20 > > > > > > the name of the draft to avoid conflicts with other=20 > > > > > > "synchronization" drafts at that time. > > > > > >=20 > > > > > > =20 > > > > > >=20 > > > > > > Bill VerSteeg > > > > > >=20 > > > > > > =20 > > > > > >=20 > > > > > > =20 > > > > > >=20 > > > > > >=20 > > > > >=20 > > > > >=20 > > > >=20 > > > >=20 > > >=20 > > >=20 > >=20 > >=20 >=20 >=20 From ron.even.tlv@gmail.com Sun Apr 26 01:14:27 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A72F3A68E0 for ; Sun, 26 Apr 2009 01:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.085 X-Spam-Level: X-Spam-Status: No, score=-1.085 tagged_above=-999 required=5 tests=[AWL=-0.886, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1oaMq5PLWEe for ; Sun, 26 Apr 2009 01:14:25 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 1A59A3A67B7 for ; Sun, 26 Apr 2009 01:14:24 -0700 (PDT) Received: by fxm2 with SMTP id 2so1765968fxm.37 for ; Sun, 26 Apr 2009 01:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=fhgeOqDajhdMbwDsl7UA1bdRq9ZWqL3T+RUnlmhxHsY=; b=sS0AuhR03PP/mekft4a20mJwY5J61kwnGq8MOiiEGZLbX2u3285rVyJP7LopCXo/Ov kQIXJv4SBBdos19QnVYugNboKcrxpbeXuOxfQUEP8xBszFNrzVOoH9X02z1M5fgv/ck4 q3M/Llt2jg0x4B4K+CzDb8t4LzZV/v4GV6Jns= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=u260jOLDktTMs6t8ZuWPSAbn61Em7vMTWZRF9cCdZt0eu6vvD3lMzrg2MjCsOL5t63 tHJwZMZQZnrknWEddb6aO0r/rxiLPOBgLcTAlx2dS+PaWfL0GOxraPsbORDQI62AUULu XldZMStWqHM7zIh5/A2cjx3Y4rToVNelqwTrU= Received: by 10.103.160.3 with SMTP id m3mr2450109muo.25.1240733743994; Sun, 26 Apr 2009 01:15:43 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-121-32.red.bezeqint.net [79.179.121.32]) by mx.google.com with ESMTPS id n7sm8790622mue.42.2009.04.26.01.15.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 26 Apr 2009 01:15:43 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> <49f2efa2.1c215e0a.4454.ffffaf91@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8403@xmb-sjc-215.amer.cisco.com> <49f36ee2.0437560a.11df.1eef@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8405@xmb-sjc-215.amer.cisco.com> <49f37fde.09a1660a.2b46.ffffb694@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8408@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C8408@xmb-sjc-215.amer.cisco.com> Date: Sun, 26 Apr 2009 11:14:07 +0300 Message-ID: <49f4182f.07a5660a.3f7f.ffffe36a@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGHOeBQAAroqxAABGe0AAAAUgbQAAEZLVAAAGk5sAAgqbUwABJxCtAAAIRzIAAAQcKgAADfs5AAAik1MAAVaJ8A Content-Language: en-us Cc: "'Bill Ver Steeg \(versteb\)'" Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 08:14:27 -0000 Ali, I looked at RTSP http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-20#appendix-D D.1.2. Media Streams The "m=" field is used to enumerate the streams. It is expected that all the specified streams will be rendered with appropriate synchronization. If the session is over multicast, the port number indicated SHOULD be used for reception. The client MAY try to override the destination port, through the Transport header. The servers MAY allow this, the response will indicate if allowed or not. If the session is unicast, the port numbers are the ones RECOMMENDED by the server to the client, about which receiver ports to use; the client MUST still include its receiver ports in its SETUP request. The client MAY ignore this recommendation. If the server has no preference, it SHOULD set the port number value to zero. Note that the client has the choice on which port to receive the unicast stream, this is why there should be such a parameter in RAMS-R Also " D.1.8. Connection Information In SDP, the "c=" field contains the destination address for the media stream. For on-demand unicast streams and some multicast streams, the destination address MAY be specified by the client via the SETUP request, thus overriding any specified address. To identify streams without a fixed destination address, where the client is required to specify a destination address, the "c=" field SHOULD be set to a null value. For addresses of type "IP4", this value MUST be "0.0.0.0", and for type "IP6", this value MUST be "0:0:0:0:0:0:0:0" (can also be written as "::"), i.e. the unspecified address according to RFC 4291 [RFC4291]." As for the c-line in the unicast stream the whole section you quoted " If the session is multicast, the connection address will be an IP multicast group address. If the session is not multicast, then the connection address contains the unicast IP address of the expected data source or data relay or data sink as determined by additional attribute fields. It is not expected that unicast addresses will be given in a session description that is communicated by a multicast announcement, though this is not prohibited." Now the expectation here is for the address of the stream described by the port in the m-line, I do not see any other attribute. Also look at the above text from RTSP. The RS does not know the IP address on the RR to where to send the RTP unicast repair stream. If you assume it is to the IP address from where the RTCP RAMS-R came from this is not mandated that the client will have such implementation. Furthermore the address that the RS will see in the received RTCP RAMS-R packet may have been change by a NAT or SBC. Roni -----Original Message----- From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] Sent: Sunday, April 26, 2009 1:23 AM To: Roni Even; avt@ietf.org Cc: Bill Ver Steeg (versteb) Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available Inline. > m=video 41000 RTP/AVPF 98 > i=Primary Multicast Stream #2 > c=IN IP4 224.1.1.2/255 > a=source-filter: incl IN IP4 224.1.1.2 192.0.2.2 > > Source (192.0.2.2) sends the rtp packets to the multicast > group (224.1.1.2) > with a dest port 41000. > > a=rtpmap:98 MP2T/90000 > a=rtcp:41001 IN IP4 192.0.2.1 > > The feedback target (RS) address for this SSM session is > 192.0.2.1 and its > port is 41001. This is the address/port where RR sends the RAMS-R, or > receiver reports for the SSM session. > > a=rtcp-fb:98 nack > a=rtcp-fb:98 nack ssli > a=ssrc:123321 cname:iptv-ch32@rams.example.com > a=mid:3 > m=video 41002 RTP/AVPF 99 > > The retransmission packets go to port 41002. This is the port > RRs listen to > for retransmission and RAMS. > > Roni E: This implies that the multicast source defines the > port that all > clients MUST use to receive the unicast information from the > Burst source. Yes, that is what it implies (One nit is that I would call it unicast RTP packets rather than information since we may use another port for RTCP packets). > i=Unicast Retransmission Stream #2 (Ret. and Rapid > Acq. Support) > c=IN IP4 192.0.2.1 > > This is where the retransmission packets come from, same as > the feedback > target (in this example). > > Roni E: If this is the address of the feedback target it > belongs to the > above m-line (m=video 41002 RTP/AVPF 99) that according to > you gives the > port on the RR and not on the RS. The problem is that This line actually specifies the sender for the unicast retransmission session. In our case, it just happens to be the feedback target for the primary SSM session, too. I recall some discussion about using a retransmission source which is different than the feedback target for the SSM. In that case, the address would be different, I guess. > according to SDP the > combination of the c= and port on the m-line provides the > transport address > to where a stream will be sent so according to SDP this The port on the m line is the port where the retranmission packets are sent. However, c line denotes the source for these packets. RFC 4566 page 13 says that "... If the session is not multicast, then the connection address contains the unicast IP address of the expected data source or data relay or data sink as determined by additional attribute fields..." Am I missing something? > m-line specify an > address and port on the Feedback Target and not on the RR and > only to this > address RTP payload type 99 will be sent. I am positive that > this is not > what you want. There can be other payload types we might need to send on this retransmission session in the future. In that case, we will add them. > a=rtpmap:99 rtx/90000 > a=rtcp:41003 > > This is where the RTCP packets for the retransmission session go. For > example, RAMS-I goes to this port on RRs. RAMS-T goes to this > port on RS. > > Roni E: So now you assume that the RR must use the same port > as the FT for > this communication. I could not find any place that one > m-line gives the Not the m line, but the "a=rtcp" line. Is this wrong? > address for both sides. This RTCP port is on 192.0.2.1 so it > will be used > for RAMS-R but not for RAMS-I. RAMS-R should go to the feedback target address and port for the primary SSM session since it is a feedback message for the SSM session. But, RAMS-T is a feedback message for the retransmission session, thus, it should go to the RTCP port of the retransmission session (41003). I hope this also clarifies your question in the next email. If you think I got the ports wrong, let me know. -acbegen > a=fmtp:99 apt=98; rtx-time=5000 > a=mid:4 > > > -acbegen > > > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > Sent: Saturday, April 25, 2009 1:11 PM > > To: Ali C. Begen (abegen); avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > Multicast RTPSessions (RAMS)" available > > > > Ali, > > Can you please write three addresses from this strange SDP. > > > > 1. The address and port of multicast > > > > 2. The address and port of the RS where the RTCP FB should go to > > > > 3. The address and port on the RR where the unicast stream > > should be sent to > > > > Roni > > > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > Sent: Saturday, April 25, 2009 11:02 PM > > To: Roni Even; avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > Multicast RTPSessions > > (RAMS)" available > > > > > Ali, > > > The example SDP is syntactically correct but it does not > > say that the > > > rtp/rtcp mux will be used and it does not give the > > > information to where the > > > unicast stream will be sent when the RR sends a RAMS-R. > > > > To my knowledge, the first line in the following SDP tells > > the RRs on which > > port they will receive the retransmission/burst packets. > > > > m=video 41002 RTP/AVPF 99 > > i=Unicast Retransmission Stream #2 (Ret. and Rapid > > Acq. Support) > > c=IN IP4 192.0.2.1 > > a=rtpmap:99 rtx/90000 > > a=rtcp:41003 > > a=fmtp:99 apt=98; rtx-time=5000 > > a=mid:4 > > > > There is a typo, you are right. That "a=recvonly" line should > > only exist in > > the SDP sent to RRs. In the SDP sent to RS, we should rather have > > "a=sendonly". I will make this correction in the next version. > > > > The feedback target for the SSM session and the RTCP port for the > > retransmission session are also defined in the SDP. > > > > Hope this clarifies. > > > > BR, > > -acbegen > > > > > > > > I am not sure why the unicast stream m-line has a port > > number with an > > > attribute of recvonly. What is the use case for that. The > > > only information > > > that the RR will need is the RTCP port on the RS to where to > > > send the RAMS-R > > > message. > > > Roni > > > -----Original Message----- > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > Sent: Friday, April 24, 2009 10:37 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > This is a part of an example SDP sent to RS and RR in a SAP > > > announcement, > > > for example. So, the SDP describes what both parties should > > > do (RR cannot > > > say that he wants to receive this multicast on its favorite > > port). The > > > individual SDPs sent to RR or RS may include other portions > > > of descriptions > > > that will contain specific information. > > > > > > -acbegen > > > > > > > -----Original Message----- > > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > > Sent: Friday, April 24, 2009 12:23 PM > > > > To: Ali C. Begen (abegen); avt@ietf.org > > > > Cc: Bill Ver Steeg (versteb) > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > > Multicast RTPSessions (RAMS)" available > > > > > > > > Ali, > > > > I think you get it wrong, this SDP is from the RS and not the > > > > RR so the RS > > > > cannot specify to which address it will send it can only > > > > specify to which > > > > address it can receive RTP stream. In this SDP the relevant > > > > information is > > > > that the request for retransmission will be sent by the RR to > > > > port 41003 > > > > Roni > > > > > > > > -----Original Message----- > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > > Sent: Friday, April 24, 2009 10:01 PM > > > > To: Roni Even; avt@ietf.org > > > > Cc: Bill Ver Steeg (versteb) > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > > Multicast RTPSessions > > > > (RAMS)" available > > > > > > > > Oh, I see. The burst goes to the port that we would > > > normally send the > > > > retransmissions. For example, consider the SDP from the draft: > > > > > > > > m=video 41000 RTP/AVPF 98 > > > > i=Primary Multicast Stream #2 > > > > c=IN IP4 224.1.1.2/255 > > > > a=source-filter: incl IN IP4 224.1.1.2 192.0.2.2 > > > > a=rtpmap:98 MP2T/90000 > > > > a=rtcp:41001 IN IP4 192.0.2.1 > > > > a=rtcp-fb:98 nack > > > > a=rtcp-fb:98 nack ssli > > > > a=ssrc:123321 cname:iptv-ch32@rams.example.com > > > > a=mid:3 > > > > m=video 41002 RTP/AVPF 99 > > > > i=Unicast Retransmission Stream #2 (Ret. and Rapid > > > > Acq. Support) > > > > c=IN IP4 192.0.2.1 > > > > a=recvonly > > > > a=rtpmap:99 rtx/90000 > > > > a=rtcp:41003 > > > > a=fmtp:99 apt=98; rtx-time=5000 > > > > a=mid:4 > > > > > > > > In this case, the burst will go to port 41002 on the RR. > > The RAMS-I > > > > message(s), which is an RTCP feedback message, will go to > > > port 41003. > > > > > > > > HTH, > > > > -acbegen > > > > > > > > > -----Original Message----- > > > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > > > Sent: Friday, April 24, 2009 11:44 AM > > > > > To: Ali C. Begen (abegen); avt@ietf.org > > > > > Cc: Bill Ver Steeg (versteb) > > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > > > Multicast RTPSessions (RAMS)" available > > > > > > > > > > Ali, > > > > > I will try to explain in simple way > > > > > > > > > > When the RS receives the RAMS-R it need to start sending an > > > > > RTP stream to > > > > > the RR. > > > > > In order to send a unicast packet, the RS needs to know a > > > > > transport address > > > > > on the RR to where the RTP stream will be sent. The current > > > > > draft does not > > > > > say how the RS knows this address. There is no SDP from RR to > > > > > RS like you > > > > > mention in your response. > > > > > This is why I say that the current draft does not specify a > > > > > solution that > > > > > can be implemented as a working solution > > > > > Roni > > > > > > > > > > -----Original Message----- > > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > > > Sent: Friday, April 24, 2009 7:38 PM > > > > > To: Roni Even; avt@ietf.org > > > > > Cc: Bill Ver Steeg (versteb) > > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > > > Multicast RTPSessions > > > > > (RAMS)" available > > > > > > > > > > Hi Roni, > > > > > > > > > > > -----Original Message----- > > > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > > > > > Behalf Of Roni Even > > > > > > Sent: Friday, April 24, 2009 4:24 AM > > > > > > To: avt@ietf.org > > > > > > Cc: Bill Ver Steeg (versteb) > > > > > > Subject: Re: [AVT] New draft of "Rapid Acquisition of > > > > > > Multicast RTPSessions (RAMS)" available > > > > > > > > > > > > Hi, > > > > > > > > > > > > I think that the current draft does not give a > description of > > > > > > a system that works since there is no text > explaining how the > > > > > > > > > > What do you mean by "a system that works"? > > > > > > > > > > > RS knows the unicast transport address on the RR to > where to > > > > > > send the stream. > > > > > > > > > > Once RS receives the request packet from an RR, RS knows its > > > > > address. Ports > > > > > are defined in the SDP. If you are asking about "NAT" issues, > > > > > we have a > > > > > section for it, and we plan to complete it as we move > > > > > forward. It is not as > > > > > critical as the other parts for now. > > > > > > > > > > > If you mandate the use of RTP/RTCP mux it should say so > > > > > > otherwise the RAMS-R should have an optional parameter that > > > > > > supplies this information and a flag for using RTP/RTCP mux. > > > > > > > > > > IMO, we cannot mandate muxing as it is not required to make > > > > > RAMS work. If > > > > > muxing is supported, the SDP should reflect it. > > > > > > > > > > BR, > > > > > -acbegen > > > > > > > > > > > Thanks > > > > > > > > > > > > Roni Even > > > > > > > > > > > > > > > > > > > > > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > > > > > Behalf Of Bill Ver Steeg (versteb) > > > > > > Sent: Thursday, April 16, 2009 7:39 PM > > > > > > To: avt@ietf.org > > > > > > Subject: [AVT] New draft of "Rapid Acquisition of Multicast > > > > > > RTP Sessions (RAMS)" available > > > > > > > > > > > > > > > > > > > > > > > > There is a new draft of the "Rapid Acquisition of Multicast > > > > > > RTP Sessions (RAMS)" draft available at > > > > > > > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s > > > > > ynchronization-for-rtp-03.txt > > > > > > drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt> > > > > > > > > > > > > > > > > > > > > > > > > We have incorporated the changes from the technical > breakout > > > > > > session in San Francisco. The major changes in this version > > > > > > of the draft include > > > > > > > > > > > > 1- Changing the document title to avoid confusion > with other > > > > > > ongoing "synchronization" drafts > > > > > > > > > > > > 2- changing the message names to reflect the title change > > > > > > > > > > > > 3- clarification of the RTCP message semantics, including > > > > > > changes to the "Request" and "Inform" messages > > > > > > > > > > > > 4- additional description/motivation for the > various message > > > > > > flows has been added > > > > > > > > > > > > 5- RTP/RTCP muxing has been added > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We hope to make this a Working Group item, and will change > > > > > > the name of the draft to avoid conflicts with other > > > > > > "synchronization" drafts at that time. > > > > > > > > > > > > > > > > > > > > > > > > Bill VerSteeg > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From abegen@cisco.com Sun Apr 26 10:01:12 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BD093A67F8 for ; Sun, 26 Apr 2009 10:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.166 X-Spam-Level: X-Spam-Status: No, score=-5.166 tagged_above=-999 required=5 tests=[AWL=-0.967, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsZiSEEld1zw for ; Sun, 26 Apr 2009 10:01:09 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C505F3A6405 for ; Sun, 26 Apr 2009 10:01:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,249,1238976000"; d="scan'208";a="177018948" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 26 Apr 2009 17:02:30 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3QH2UpU031562; Sun, 26 Apr 2009 10:02:30 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3QH2U26009592; Sun, 26 Apr 2009 17:02:30 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 26 Apr 2009 10:02:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 26 Apr 2009 10:02:24 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C841F@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49f4182f.07a5660a.3f7f.ffffe36a@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available Thread-Index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGHOeBQAAroqxAABGe0AAAAUgbQAAEZLVAAAGk5sAAgqbUwABJxCtAAAIRzIAAAQcKgAADfs5AAAik1MAAVaJ8AABHrLfA= References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> <49f2efa2.1c215e0a.4454.ffffaf91@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8403@xmb-sjc-215.amer.cisco.com> <49f36ee2.0437560a.11df.1eef@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8405@xmb-sjc-215.amer.cisco.com> <49f37fde.09a1660a.2b46.ffffb694@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8408@xmb-sjc-215.amer.cisco.com> <49f4182f.07a5660a.3f7f.ffffe36a@mx.google.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , X-OriginalArrivalTime: 26 Apr 2009 17:02:30.0069 (UTC) FILETIME=[C8A61E50:01C9C690] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=21429; t=1240765350; x=1241629350; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20New=20draft=20of=20=22Rapid=20A cquisition=20of=20Multicast=20RTPSessions=09(RAMS)=22=20avai lable |Sender:=20; bh=StxJ6NHGFYyxNvRumAUfaipNHQ74vq4Z1D1rSwlsdPE=; b=TeXu5xC6VLKxseYXwSq/m7CfbCTeCsROL4KLobwess9J2NwG/Z2NfhZFcO 1AeGvXfOv5UDI2T325S8DdANEvC88aIrSs7nltKtoEMJcYiID/dczlxPjI8G gS4hJUWE3v; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "Bill Ver Steeg \(versteb\)" Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 17:01:12 -0000 Hi Roni, Thanks for the detailed answer. Admittedly, I don't know much about RTSP = beyond its basics. However, I doubt how much it applies in our case. = "Unicast" in RTSP context mostly refers to video-on-demand kind of = applications where the primary distribution is over unicast. In = contrast, our primary distribution is over multicast, and we use unicast = as a repair stream. Thus, I still believe the SDP we have should work = fine. RS gathers the IP address of the RR when it receives the RAMS = request. The samething happens when RR sends a NACK for requesting = retransmissions. That is not to say that this SDP is the only SDP that will work in this = system. There may be others. But, I still don't agree with you when you = say that this SDP won't work. My expectation is that we will include = other SDP examples as we move forward. On your last point, NAT is a different issue and there has to be a way = to deal with it. Muxing sounds reasonable, and we may or may not mandate = it, I am not sure at this point. An alternative could be that RR opens = ports on its NAT device and includes them in the request message it = sends. These could be in RAMS-R TLV extensions, or could be a separate = RTCP packet solely for this purpose within the same RTCP compound packet = that carries the RAMS-R. I believe Bill mentioned these briefly in his = earlier email. We are open to suggestions at this point and the NAT = section will cover these issues once we have a WG item. -acbegen =20 > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > Sent: Sunday, April 26, 2009 1:14 AM > To: Ali C. Begen (abegen); avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > Multicast RTPSessions (RAMS)" available >=20 > Ali, > I looked at RTSP > http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-20#appendix-D=20 >=20 >=20 >=20 > D.1.2. Media Streams >=20 > The "m=3D" field is used to enumerate the streams. It is=20 > expected that > all the specified streams will be rendered with appropriate > synchronization. If the session is over multicast, the port number > indicated SHOULD be used for reception. The client MAY try to > override the destination port, through the Transport header. The > servers MAY allow this, the response will indicate if=20 > allowed or not. > If the session is unicast, the port numbers are the ones=20 > RECOMMENDED > by the server to the client, about which receiver ports to use; the > client MUST still include its receiver ports in its SETUP request. > The client MAY ignore this recommendation. If the server has no > preference, it SHOULD set the port number value to zero. >=20 >=20 > Note that the client has the choice on which port to receive=20 > the unicast > stream, this is why there should be such a parameter in RAMS-R >=20 >=20 > Also >=20 > " D.1.8. Connection Information >=20 > In SDP, the "c=3D" field contains the destination address=20 > for the media > stream. For on-demand unicast streams and some multicast streams, > the destination address MAY be specified by the client via=20 > the SETUP > request, thus overriding any specified address. To=20 > identify streams > without a fixed destination address, where the client is=20 > required to > specify a destination address, the "c=3D" field SHOULD be=20 > set to a null > value. For addresses of type "IP4", this value MUST be "0.0.0.0", > and for type "IP6", this value MUST be "0:0:0:0:0:0:0:0"=20 > (can also be > written as "::"), i.e. the unspecified address according=20 > to RFC 4291 > [RFC4291]." >=20 >=20 > As for the c-line in the unicast stream the whole section you quoted >=20 > " If the session is multicast, the connection address will be an IP > multicast group address. If the session is not multicast, then > the connection address contains the unicast IP address of the > expected data source or data relay or data sink as determined by > additional attribute fields. It is not expected that unicast > addresses will be given in a session description that is > communicated by a multicast announcement, though this is not > prohibited." >=20 > Now the expectation here is for the address of the stream=20 > described by the > port in the m-line, I do not see any other attribute. Also=20 > look at the above > text from RTSP. The RS does not know the IP address on the RR=20 > to where to > send the RTP unicast repair stream. If you assume it is to=20 > the IP address > from where the RTCP RAMS-R came from this is not mandated=20 > that the client > will have such implementation. Furthermore the address that=20 > the RS will see > in the received RTCP RAMS-R packet may have been change by a=20 > NAT or SBC. >=20 >=20 > Roni >=20 >=20 >=20 > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > Sent: Sunday, April 26, 2009 1:23 AM > To: Roni Even; avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > Multicast RTPSessions > (RAMS)" available >=20 > Inline. >=20 > > m=3Dvideo 41000 RTP/AVPF 98 > > i=3DPrimary Multicast Stream #2 > > c=3DIN IP4 224.1.1.2/255 > > a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 > >=20 > > Source (192.0.2.2) sends the rtp packets to the multicast=20 > > group (224.1.1.2) > > with a dest port 41000. > >=20 > > a=3Drtpmap:98 MP2T/90000 > > a=3Drtcp:41001 IN IP4 192.0.2.1 > >=20 > > The feedback target (RS) address for this SSM session is=20 > > 192.0.2.1 and its > > port is 41001. This is the address/port where RR sends the=20 > RAMS-R, or > > receiver reports for the SSM session. > >=20 > > a=3Drtcp-fb:98 nack > > a=3Drtcp-fb:98 nack ssli > > a=3Dssrc:123321 cname:iptv-ch32@rams.example.com > > a=3Dmid:3 > > m=3Dvideo 41002 RTP/AVPF 99 > >=20 > > The retransmission packets go to port 41002. This is the port=20 > > RRs listen to > > for retransmission and RAMS. > >=20 > > Roni E: This implies that the multicast source defines the=20 > > port that all > > clients MUST use to receive the unicast information from the=20 > > Burst source. =20 >=20 > Yes, that is what it implies (One nit is that I would call it=20 > unicast RTP > packets rather than information since we may use another port for RTCP > packets). > =20 > > i=3DUnicast Retransmission Stream #2 (Ret. and Rapid=20 > > Acq. Support) > > c=3DIN IP4 192.0.2.1 > >=20 > > This is where the retransmission packets come from, same as=20 > > the feedback > > target (in this example). > >=20 > > Roni E: If this is the address of the feedback target it=20 > > belongs to the > > above m-line (m=3Dvideo 41002 RTP/AVPF 99) that according to=20 > > you gives the > > port on the RR and not on the RS. The problem is that=20 >=20 > This line actually specifies the sender for the unicast retransmission > session. In our case, it just happens to be the feedback=20 > target for the > primary SSM session, too. I recall some discussion about using a > retransmission source which is different than the feedback=20 > target for the > SSM. In that case, the address would be different, I guess. >=20 > > according to SDP the > > combination of the c=3D and port on the m-line provides the=20 > > transport address > > to where a stream will be sent so according to SDP this=20 >=20 > The port on the m line is the port where the retranmission=20 > packets are sent. > However, c line denotes the source for these packets. RFC=20 > 4566 page 13 says > that "... If the session is not multicast, then the connection address > contains the unicast IP address of the expected data source=20 > or data relay or > data sink as determined by additional attribute fields..." >=20 > Am I missing something? >=20 > > m-line specify an > > address and port on the Feedback Target and not on the RR and=20 > > only to this > > address RTP payload type 99 will be sent. I am positive that=20 > > this is not > > what you want. >=20 > There can be other payload types we might need to send on this > retransmission session in the future. In that case, we will add them. > =20 > > a=3Drtpmap:99 rtx/90000 > > a=3Drtcp:41003 > >=20 > > This is where the RTCP packets for the retransmission=20 > session go. For > > example, RAMS-I goes to this port on RRs. RAMS-T goes to this=20 > > port on RS. > >=20 > > Roni E: So now you assume that the RR must use the same port=20 > > as the FT for > > this communication. I could not find any place that one=20 > > m-line gives the >=20 > Not the m line, but the "a=3Drtcp" line. Is this wrong? >=20 > > address for both sides. This RTCP port is on 192.0.2.1 so it=20 > > will be used > > for RAMS-R but not for RAMS-I. >=20 > RAMS-R should go to the feedback target address and port for=20 > the primary SSM > session since it is a feedback message for the SSM session.=20 > But, RAMS-T is a > feedback message for the retransmission session, thus, it=20 > should go to the > RTCP port of the retransmission session (41003). I hope this=20 > also clarifies > your question in the next email. If you think I got the ports=20 > wrong, let me > know. >=20 > -acbegen > =20 > > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > > a=3Dmid:4 > >=20 > >=20 > > -acbegen > > =20 > >=20 > > > -----Original Message----- > > > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > > > Sent: Saturday, April 25, 2009 1:11 PM > > > To: Ali C. Begen (abegen); avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > Multicast RTPSessions (RAMS)" available > > >=20 > > > Ali, > > > Can you please write three addresses from this strange SDP. > > >=20 > > > 1. The address and port of multicast > > >=20 > > > 2. The address and port of the RS where the RTCP FB should go to > > >=20 > > > 3. The address and port on the RR where the unicast stream=20 > > > should be sent to > > >=20 > > > Roni > > >=20 > > > -----Original Message----- > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > > > Sent: Saturday, April 25, 2009 11:02 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > Multicast RTPSessions > > > (RAMS)" available > > >=20 > > > > Ali, > > > > The example SDP is syntactically correct but it does not=20 > > > say that the > > > > rtp/rtcp mux will be used and it does not give the=20 > > > > information to where the > > > > unicast stream will be sent when the RR sends a RAMS-R.=20 > > >=20 > > > To my knowledge, the first line in the following SDP tells=20 > > > the RRs on which > > > port they will receive the retransmission/burst packets. > > >=20 > > > m=3Dvideo 41002 RTP/AVPF 99 > > > i=3DUnicast Retransmission Stream #2 (Ret. and Rapid=20 > > > Acq. Support) > > > c=3DIN IP4 192.0.2.1 > > > a=3Drtpmap:99 rtx/90000 > > > a=3Drtcp:41003 > > > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > > > a=3Dmid:4 > > >=20 > > > There is a typo, you are right. That "a=3Drecvonly" line should=20 > > > only exist in > > > the SDP sent to RRs. In the SDP sent to RS, we should rather have > > > "a=3Dsendonly". I will make this correction in the next version. > > >=20 > > > The feedback target for the SSM session and the RTCP port for the > > > retransmission session are also defined in the SDP. > > >=20 > > > Hope this clarifies. > > >=20 > > > BR, > > > -acbegen > > > =20 > > > >=20 > > > > I am not sure why the unicast stream m-line has a port=20 > > > number with an > > > > attribute of recvonly. What is the use case for that. The=20 > > > > only information > > > > that the RR will need is the RTCP port on the RS to where to=20 > > > > send the RAMS-R > > > > message. > > > > Roni > > > > -----Original Message----- > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > > > > Sent: Friday, April 24, 2009 10:37 PM > > > > To: Roni Even; avt@ietf.org > > > > Cc: Bill Ver Steeg (versteb) > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > > Multicast RTPSessions > > > > (RAMS)" available > > > >=20 > > > > This is a part of an example SDP sent to RS and RR in a SAP=20 > > > > announcement, > > > > for example. So, the SDP describes what both parties should=20 > > > > do (RR cannot > > > > say that he wants to receive this multicast on its favorite=20 > > > port). The > > > > individual SDPs sent to RR or RS may include other portions=20 > > > > of descriptions > > > > that will contain specific information.=20 > > > >=20 > > > > -acbegen > > > >=20 > > > > > -----Original Message----- > > > > > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > > > > > Sent: Friday, April 24, 2009 12:23 PM > > > > > To: Ali C. Begen (abegen); avt@ietf.org > > > > > Cc: Bill Ver Steeg (versteb) > > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > > > Multicast RTPSessions (RAMS)" available > > > > >=20 > > > > > Ali, > > > > > I think you get it wrong, this SDP is from the RS and not the=20 > > > > > RR so the RS > > > > > cannot specify to which address it will send it can only=20 > > > > > specify to which > > > > > address it can receive RTP stream. In this SDP the relevant=20 > > > > > information is > > > > > that the request for retransmission will be sent by the RR to=20 > > > > > port 41003 > > > > > Roni > > > > >=20 > > > > > -----Original Message----- > > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > > > > > Sent: Friday, April 24, 2009 10:01 PM > > > > > To: Roni Even; avt@ietf.org > > > > > Cc: Bill Ver Steeg (versteb) > > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > > > Multicast RTPSessions > > > > > (RAMS)" available > > > > >=20 > > > > > Oh, I see. The burst goes to the port that we would=20 > > > > normally send the > > > > > retransmissions. For example, consider the SDP from the draft: > > > > >=20 > > > > > m=3Dvideo 41000 RTP/AVPF 98 > > > > > i=3DPrimary Multicast Stream #2 > > > > > c=3DIN IP4 224.1.1.2/255 > > > > > a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 > > > > > a=3Drtpmap:98 MP2T/90000 > > > > > a=3Drtcp:41001 IN IP4 192.0.2.1 > > > > > a=3Drtcp-fb:98 nack > > > > > a=3Drtcp-fb:98 nack ssli > > > > > a=3Dssrc:123321 cname:iptv-ch32@rams.example.com > > > > > a=3Dmid:3 > > > > > m=3Dvideo 41002 RTP/AVPF 99 > > > > > i=3DUnicast Retransmission Stream #2 (Ret. and Rapid=20 > > > > > Acq. Support) > > > > > c=3DIN IP4 192.0.2.1 > > > > > a=3Drecvonly > > > > > a=3Drtpmap:99 rtx/90000 > > > > > a=3Drtcp:41003 > > > > > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > > > > > a=3Dmid:4 > > > > >=20 > > > > > In this case, the burst will go to port 41002 on the RR.=20 > > > The RAMS-I > > > > > message(s), which is an RTCP feedback message, will go to=20 > > > > port 41003. > > > > >=20 > > > > > HTH, > > > > > -acbegen > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > > > > > > Sent: Friday, April 24, 2009 11:44 AM > > > > > > To: Ali C. Begen (abegen); avt@ietf.org > > > > > > Cc: Bill Ver Steeg (versteb) > > > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > > > > Multicast RTPSessions (RAMS)" available > > > > > >=20 > > > > > > Ali, > > > > > > I will try to explain in simple way > > > > > >=20 > > > > > > When the RS receives the RAMS-R it need to start sending an=20 > > > > > > RTP stream to > > > > > > the RR.=20 > > > > > > In order to send a unicast packet, the RS needs to know a=20 > > > > > > transport address > > > > > > on the RR to where the RTP stream will be sent. The current=20 > > > > > > draft does not > > > > > > say how the RS knows this address. There is no SDP=20 > from RR to=20 > > > > > > RS like you > > > > > > mention in your response. > > > > > > This is why I say that the current draft does not specify a=20 > > > > > > solution that > > > > > > can be implemented as a working solution > > > > > > Roni > > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > > > > > > Sent: Friday, April 24, 2009 7:38 PM > > > > > > To: Roni Even; avt@ietf.org > > > > > > Cc: Bill Ver Steeg (versteb) > > > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > > > > Multicast RTPSessions > > > > > > (RAMS)" available > > > > > >=20 > > > > > > Hi Roni,=20 > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: avt-bounces@ietf.org=20 > [mailto:avt-bounces@ietf.org] On=20 > > > > > > > Behalf Of Roni Even > > > > > > > Sent: Friday, April 24, 2009 4:24 AM > > > > > > > To: avt@ietf.org > > > > > > > Cc: Bill Ver Steeg (versteb) > > > > > > > Subject: Re: [AVT] New draft of "Rapid Acquisition of=20 > > > > > > > Multicast RTPSessions (RAMS)" available > > > > > > >=20 > > > > > > > Hi, > > > > > > >=20 > > > > > > > I think that the current draft does not give a=20 > > description of=20 > > > > > > > a system that works since there is no text=20 > > explaining how the=20 > > > > > >=20 > > > > > > What do you mean by "a system that works"?=20 > > > > > >=20 > > > > > > > RS knows the unicast transport address on the RR to=20 > > where to=20 > > > > > > > send the stream.=20 > > > > > >=20 > > > > > > Once RS receives the request packet from an RR, RS=20 > knows its=20 > > > > > > address. Ports > > > > > > are defined in the SDP. If you are asking about=20 > "NAT" issues,=20 > > > > > > we have a > > > > > > section for it, and we plan to complete it as we move=20 > > > > > > forward. It is not as > > > > > > critical as the other parts for now. > > > > > > =20 > > > > > > > If you mandate the use of RTP/RTCP mux it should say so=20 > > > > > > > otherwise the RAMS-R should have an optional=20 > parameter that=20 > > > > > > > supplies this information and a flag for using=20 > RTP/RTCP mux. > > > > > >=20 > > > > > > IMO, we cannot mandate muxing as it is not required to make=20 > > > > > > RAMS work. If > > > > > > muxing is supported, the SDP should reflect it. > > > > > >=20 > > > > > > BR, > > > > > > -acbegen > > > > > > =20 > > > > > > > Thanks > > > > > > >=20 > > > > > > > Roni Even > > > > > > >=20 > > > > > > > =20 > > > > > > >=20 > > > > > > > From: avt-bounces@ietf.org=20 > [mailto:avt-bounces@ietf.org] On=20 > > > > > > > Behalf Of Bill Ver Steeg (versteb) > > > > > > > Sent: Thursday, April 16, 2009 7:39 PM > > > > > > > To: avt@ietf.org > > > > > > > Subject: [AVT] New draft of "Rapid Acquisition of=20 > Multicast=20 > > > > > > > RTP Sessions (RAMS)" available > > > > > > >=20 > > > > > > > =20 > > > > > > >=20 > > > > > > > There is a new draft of the "Rapid Acquisition of=20 > Multicast=20 > > > > > > > RTP Sessions (RAMS)" draft available at=20 > > > > > > >=20 > > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s > > > > > > ynchronization-for-rtp-03.txt=20 > > > > > > >=20 > > drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt>=20 > > > > > > >=20 > > > > > > > =20 > > > > > > >=20 > > > > > > > We have incorporated the changes from the technical=20 > > breakout=20 > > > > > > > session in San Francisco. The major changes in=20 > this version=20 > > > > > > > of the draft include=20 > > > > > > >=20 > > > > > > > 1- Changing the document title to avoid confusion=20 > > with other=20 > > > > > > > ongoing "synchronization" drafts > > > > > > >=20 > > > > > > > 2- changing the message names to reflect the title change > > > > > > >=20 > > > > > > > 3- clarification of the RTCP message semantics, including=20 > > > > > > > changes to the "Request" and "Inform" messages > > > > > > >=20 > > > > > > > 4- additional description/motivation for the=20 > > various message=20 > > > > > > > flows has been added > > > > > > >=20 > > > > > > > 5- RTP/RTCP muxing has been added > > > > > > >=20 > > > > > > > =20 > > > > > > >=20 > > > > > > > =20 > > > > > > >=20 > > > > > > > We hope to make this a Working Group item, and=20 > will change=20 > > > > > > > the name of the draft to avoid conflicts with other=20 > > > > > > > "synchronization" drafts at that time. > > > > > > >=20 > > > > > > > =20 > > > > > > >=20 > > > > > > > Bill VerSteeg > > > > > > >=20 > > > > > > > =20 > > > > > > >=20 > > > > > > > =20 > > > > > > >=20 > > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > >=20 > > > > >=20 > > > >=20 > > > >=20 > > >=20 > > >=20 > >=20 > >=20 >=20 >=20 From ron.even.tlv@gmail.com Sun Apr 26 11:48:38 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02DE93A6821 for ; Sun, 26 Apr 2009 11:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[AWL=-1.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoWMQSBzO6GA for ; Sun, 26 Apr 2009 11:48:37 -0700 (PDT) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.189]) by core3.amsl.com (Postfix) with ESMTP id 9FA7F3A67EC for ; Sun, 26 Apr 2009 11:48:36 -0700 (PDT) Received: by mu-out-0910.google.com with SMTP id w1so657348mue.9 for ; Sun, 26 Apr 2009 11:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=LquJLNJgAWLqhwjtmfQdR5IJX8EG5h6cay9kC5crDBU=; b=VDvn4qL5WQSH0vizdE9La10fyrjIjrqk9JReACz2UYi97+kkY3+61xMc6pffK/4vcf dFvq6op3w07HcHuUpY30qNlBSDiiTYw5HZbN2vZSeNqov9Kj/oZtydvOXegnQrg7k6TH 4uqRRGibdlNf0XUFfe0B6euC1lM90FxJvfYWI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; b=ELjA4J2k+QKqkG9KfZ1lCw9GPIMOhAMe541z6HxBOVVukqoLqjokASG5/boacccoJy dQ/a5Rh9Pk7P5ZBPACZDV0CteqI9v8WS6hejrId1b2rNgGWCHy6fzqDFewt/qCBCUepg 2cAkk65Eb1y7OfuuP5NO32tel1epnhB6iRdbw= Received: by 10.103.160.10 with SMTP id m10mr2651811muo.50.1240771795035; Sun, 26 Apr 2009 11:49:55 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-121-32.red.bezeqint.net [79.179.121.32]) by mx.google.com with ESMTPS id 12sm1151894muq.29.2009.04.26.11.49.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 26 Apr 2009 11:49:54 -0700 (PDT) From: "Roni Even" To: Date: Sun, 26 Apr 2009 21:48:12 +0300 Message-ID: <49f4acd2.0c11660a.6549.ffffb32b@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0182_01C9C6B8.B8AD0A40" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnGn2ZppMXSeI8kR4uCrP7ReGKWgQ== Content-Language: en-us Subject: [AVT] SDP example in draft-versteeg-avt-rapid-synchronization-for-rtp-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 18:48:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0182_01C9C6B8.B8AD0A40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I am looking for more feedback on the following topic (not by Roni or Ali). The example in the draft is coming from a distribution source using for example SAP (multicast distribution). There are three entities in the communication. The multicast distribution source, the unicast retransmission which also serves as a feedback target and a client that wants to receive the multicast stream and will ask for unicast resynchronization or retransmission. This SDP is coming from the distribution source and according to the authors specify the multicast address, the unicast transport address for the RTCP receiver reports for the multicast (SSM), the uincast transport address on the feedback target/retransmission server that will be used by the clients to ask for retransmission streams using RTCP-FB and the transport address on the client that will be used by the feedback target to send the unicast RTP stream to. Does this SDP look like it supplies all this information enabling interoperable applications. v=0 o=ali 1122334455 1122334466 IN IP4 rams.example.com s=Rapid Acquisition Examples t=0 0 a=group:FID 1 2 a=group:FID 3 4 a=rtcp-unicast:rsi m=video 40000 RTP/AVPF 96 i=Primary Multicast Stream #1 c=IN IP4 224.1.1.1/255 a=source-filter: incl IN IP4 224.1.1.1 192.0.2.2 a=recvonly a=rtpmap:96 MP2T/90000 a=rtcp:40001 IN IP4 192.0.2.1 a=rtcp-fb:96 nack a=mid:1 m=video 40002 RTP/AVPF 97 i=Unicast Retransmission Stream #1 (Ret. Support Only) c=IN IP4 192.0.2.1 a=recvonly a=rtpmap:97 rtx/90000 a=rtcp:40003 a=fmtp:97 apt=96 a=fmtp:97 rtx-time=3000 a=mid:2 Thanks Roni Even ------=_NextPart_000_0182_01C9C6B8.B8AD0A40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi,

 

I am looking for more feedback on the following = topic (not by Roni or Ali).

The example in the draft is coming from a = distribution source using for example SAP (multicast distribution).

There are three entities in the communication. The = multicast distribution source, the unicast retransmission which also serves as a = feedback target and a client that wants to receive the multicast stream and will = ask for unicast  resynchronization or retransmission.

 

This SDP is coming from the distribution source and according to the authors specify the multicast address, the unicast = transport address for the RTCP receiver reports for the multicast (SSM), the = uincast transport address on the feedback target/retransmission server that will =  be used by the clients to ask for retransmission streams using RTCP-FB and = the transport address on the client that will be used by the feedback target = to send the unicast RTP stream to.

 

Does this SDP look like it supplies all this = information enabling interoperable applications.

 

         = v=3D0

        o=3Dali = 1122334455 1122334466 IN IP4 rams.example.com

        = s=3DRapid Acquisition Examples

        t=3D0 = 0

        = a=3Dgroup:FID 1 2

        = a=3Dgroup:FID 3 4

        a=3Drtcp-unicast:rsi

        = m=3Dvideo 40000 RTP/AVPF 96

        = i=3DPrimary Multicast Stream #1

        c=3DIN = IP4 224.1.1.1/255

        = a=3Dsource-filter: incl IN IP4 224.1.1.1 192.0.2.2

        = a=3Drecvonly

        = a=3Drtpmap:96 MP2T/90000

        = a=3Drtcp:40001 IN IP4 192.0.2.1

        = a=3Drtcp-fb:96 nack

        = a=3Dmid:1

        = m=3Dvideo 40002 RTP/AVPF 97

        = i=3DUnicast Retransmission Stream #1 (Ret. Support Only)

        c=3DIN = IP4 192.0.2.1

        = a=3Drecvonly

        = a=3Drtpmap:97 rtx/90000

        = a=3Drtcp:40003

        = a=3Dfmtp:97 apt=3D96

        = a=3Dfmtp:97 rtx-time=3D3000

        = a=3Dmid:2

 

 

Thanks

Roni Even

------=_NextPart_000_0182_01C9C6B8.B8AD0A40-- From ron.even.tlv@gmail.com Sun Apr 26 11:48:43 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1A373A6DE8 for ; Sun, 26 Apr 2009 11:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.03 X-Spam-Level: X-Spam-Status: No, score=-1.03 tagged_above=-999 required=5 tests=[AWL=-0.831, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzSBvVEKuIOQ for ; Sun, 26 Apr 2009 11:48:42 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 088FF3A6C90 for ; Sun, 26 Apr 2009 11:48:39 -0700 (PDT) Received: by bwz7 with SMTP id 7so1916534bwz.37 for ; Sun, 26 Apr 2009 11:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=N1ft5IO0CkQVYnNi302AFzFo3YdcNrCtjNCvJg22GAk=; b=QTjS9wXpNWbk0RN1LsMYBoW6t5KHI31BavVDTZ8j2xALZismQwtdAGZCacd5pMIEb4 AjcDHfM6O5iUvN15QncGQnP0S8crQzmEu2omA621jTF6xgVdIl4pdntAU6hlm2KZj2Zf OV1Li6MgLJKBtJxdFtcmv4MGpQ8NBldbAzagc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=x4Scqyu1CURZ8ma88dMJsZfLcnV5vG326saCLKv0Qooe6uyl0DAVbwPrPd08gQiK/c g35UP3kJFuaPEkhyFyNZggvrMChsssmXnLu77k7d/cuTg8ZlbZUTGUEUnl0EgFwdu45m yP5aXliwUjhAxMVD+XJ9EJo4UPsGV8UtVbZ7U= Received: by 10.103.169.18 with SMTP id w18mr2648892muo.101.1240771799247; Sun, 26 Apr 2009 11:49:59 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-121-32.red.bezeqint.net [79.179.121.32]) by mx.google.com with ESMTPS id 12sm1151894muq.29.2009.04.26.11.49.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 26 Apr 2009 11:49:58 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> <49f2efa2.1c215e0a.4454.ffffaf91@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8403@xmb-sjc-215.amer.cisco.com> <49f36ee2.0437560a.11df.1eef@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8405@xmb-sjc-215.amer.cisco.com> <49f37fde.09a1660a.2b46.ffffb694@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8408@xmb-sjc-215.amer.cisco.com> <49f4182f.07a5660a.3f7f.ffffe36a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C841F@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C841F@xmb-sjc-215.amer.cisco.com> Date: Sun, 26 Apr 2009 21:48:12 +0300 Message-ID: <49f4acd6.0c11660a.6549.ffffb339@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGHOeBQAAroqxAABGe0AAAAUgbQAAEZLVAAAGk5sAAgqbUwABJxCtAAAIRzIAAAQcKgAADfs5AAAik1MAAVaJ8AABHrLfAAA4ZboA== Content-Language: en-us Cc: "'Bill Ver Steeg \(versteb\)'" Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 18:48:44 -0000 Ali, Your SDP example will not help anyone who will try to develop interop application, the c-line in the unicast stream and the port should refer to the same device since there is no other attribute in the example that points to a different semantics to anyone who will look at it. The semantics that you are using where the c-line is for the RS and the port is for the RR and the RS assuming that the RS somehow knows the IP address of the RR based on the RAMS-R request may work in some cases but should not be the one shown as the primary example and should not be the recommended way, The recommended way should be to convey the address of the RR in the RAMS-R and this is the reason I pointed to RTSP. The semantics of the SDP in the example is not documented in your text and is not obvious to anyone who will just look at it. I also strongly object to mandating that the client MUST use a port defined by the server to receive the unicast stream. The RS can recommend a port but it is the client (RR) decision to decide which port to use. Roni Even -----Original Message----- From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] Sent: Sunday, April 26, 2009 8:02 PM To: Roni Even; avt@ietf.org Cc: Bill Ver Steeg (versteb) Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available Hi Roni, Thanks for the detailed answer. Admittedly, I don't know much about RTSP beyond its basics. However, I doubt how much it applies in our case. "Unicast" in RTSP context mostly refers to video-on-demand kind of applications where the primary distribution is over unicast. In contrast, our primary distribution is over multicast, and we use unicast as a repair stream. Thus, I still believe the SDP we have should work fine. RS gathers the IP address of the RR when it receives the RAMS request. The samething happens when RR sends a NACK for requesting retransmissions. That is not to say that this SDP is the only SDP that will work in this system. There may be others. But, I still don't agree with you when you say that this SDP won't work. My expectation is that we will include other SDP examples as we move forward. On your last point, NAT is a different issue and there has to be a way to deal with it. Muxing sounds reasonable, and we may or may not mandate it, I am not sure at this point. An alternative could be that RR opens ports on its NAT device and includes them in the request message it sends. These could be in RAMS-R TLV extensions, or could be a separate RTCP packet solely for this purpose within the same RTCP compound packet that carries the RAMS-R. I believe Bill mentioned these briefly in his earlier email. We are open to suggestions at this point and the NAT section will cover these issues once we have a WG item. -acbegen > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Sunday, April 26, 2009 1:14 AM > To: Ali C. Begen (abegen); avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of > Multicast RTPSessions (RAMS)" available > > Ali, > I looked at RTSP > http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-20#appendix-D > > > > D.1.2. Media Streams > > The "m=" field is used to enumerate the streams. It is > expected that > all the specified streams will be rendered with appropriate > synchronization. If the session is over multicast, the port number > indicated SHOULD be used for reception. The client MAY try to > override the destination port, through the Transport header. The > servers MAY allow this, the response will indicate if > allowed or not. > If the session is unicast, the port numbers are the ones > RECOMMENDED > by the server to the client, about which receiver ports to use; the > client MUST still include its receiver ports in its SETUP request. > The client MAY ignore this recommendation. If the server has no > preference, it SHOULD set the port number value to zero. > > > Note that the client has the choice on which port to receive > the unicast > stream, this is why there should be such a parameter in RAMS-R > > > Also > > " D.1.8. Connection Information > > In SDP, the "c=" field contains the destination address > for the media > stream. For on-demand unicast streams and some multicast streams, > the destination address MAY be specified by the client via > the SETUP > request, thus overriding any specified address. To > identify streams > without a fixed destination address, where the client is > required to > specify a destination address, the "c=" field SHOULD be > set to a null > value. For addresses of type "IP4", this value MUST be "0.0.0.0", > and for type "IP6", this value MUST be "0:0:0:0:0:0:0:0" > (can also be > written as "::"), i.e. the unspecified address according > to RFC 4291 > [RFC4291]." > > > As for the c-line in the unicast stream the whole section you quoted > > " If the session is multicast, the connection address will be an IP > multicast group address. If the session is not multicast, then > the connection address contains the unicast IP address of the > expected data source or data relay or data sink as determined by > additional attribute fields. It is not expected that unicast > addresses will be given in a session description that is > communicated by a multicast announcement, though this is not > prohibited." > > Now the expectation here is for the address of the stream > described by the > port in the m-line, I do not see any other attribute. Also > look at the above > text from RTSP. The RS does not know the IP address on the RR > to where to > send the RTP unicast repair stream. If you assume it is to > the IP address > from where the RTCP RAMS-R came from this is not mandated > that the client > will have such implementation. Furthermore the address that > the RS will see > in the received RTCP RAMS-R packet may have been change by a > NAT or SBC. > > > Roni > > > > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Sunday, April 26, 2009 1:23 AM > To: Roni Even; avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of > Multicast RTPSessions > (RAMS)" available > > Inline. > > > m=video 41000 RTP/AVPF 98 > > i=Primary Multicast Stream #2 > > c=IN IP4 224.1.1.2/255 > > a=source-filter: incl IN IP4 224.1.1.2 192.0.2.2 > > > > Source (192.0.2.2) sends the rtp packets to the multicast > > group (224.1.1.2) > > with a dest port 41000. > > > > a=rtpmap:98 MP2T/90000 > > a=rtcp:41001 IN IP4 192.0.2.1 > > > > The feedback target (RS) address for this SSM session is > > 192.0.2.1 and its > > port is 41001. This is the address/port where RR sends the > RAMS-R, or > > receiver reports for the SSM session. > > > > a=rtcp-fb:98 nack > > a=rtcp-fb:98 nack ssli > > a=ssrc:123321 cname:iptv-ch32@rams.example.com > > a=mid:3 > > m=video 41002 RTP/AVPF 99 > > > > The retransmission packets go to port 41002. This is the port > > RRs listen to > > for retransmission and RAMS. > > > > Roni E: This implies that the multicast source defines the > > port that all > > clients MUST use to receive the unicast information from the > > Burst source. > > Yes, that is what it implies (One nit is that I would call it > unicast RTP > packets rather than information since we may use another port for RTCP > packets). > > > i=Unicast Retransmission Stream #2 (Ret. and Rapid > > Acq. Support) > > c=IN IP4 192.0.2.1 > > > > This is where the retransmission packets come from, same as > > the feedback > > target (in this example). > > > > Roni E: If this is the address of the feedback target it > > belongs to the > > above m-line (m=video 41002 RTP/AVPF 99) that according to > > you gives the > > port on the RR and not on the RS. The problem is that > > This line actually specifies the sender for the unicast retransmission > session. In our case, it just happens to be the feedback > target for the > primary SSM session, too. I recall some discussion about using a > retransmission source which is different than the feedback > target for the > SSM. In that case, the address would be different, I guess. > > > according to SDP the > > combination of the c= and port on the m-line provides the > > transport address > > to where a stream will be sent so according to SDP this > > The port on the m line is the port where the retranmission > packets are sent. > However, c line denotes the source for these packets. RFC > 4566 page 13 says > that "... If the session is not multicast, then the connection address > contains the unicast IP address of the expected data source > or data relay or > data sink as determined by additional attribute fields..." > > Am I missing something? > > > m-line specify an > > address and port on the Feedback Target and not on the RR and > > only to this > > address RTP payload type 99 will be sent. I am positive that > > this is not > > what you want. > > There can be other payload types we might need to send on this > retransmission session in the future. In that case, we will add them. > > > a=rtpmap:99 rtx/90000 > > a=rtcp:41003 > > > > This is where the RTCP packets for the retransmission > session go. For > > example, RAMS-I goes to this port on RRs. RAMS-T goes to this > > port on RS. > > > > Roni E: So now you assume that the RR must use the same port > > as the FT for > > this communication. I could not find any place that one > > m-line gives the > > Not the m line, but the "a=rtcp" line. Is this wrong? > > > address for both sides. This RTCP port is on 192.0.2.1 so it > > will be used > > for RAMS-R but not for RAMS-I. > > RAMS-R should go to the feedback target address and port for > the primary SSM > session since it is a feedback message for the SSM session. > But, RAMS-T is a > feedback message for the retransmission session, thus, it > should go to the > RTCP port of the retransmission session (41003). I hope this > also clarifies > your question in the next email. If you think I got the ports > wrong, let me > know. > > -acbegen > > > a=fmtp:99 apt=98; rtx-time=5000 > > a=mid:4 > > > > > > -acbegen > > > > > > > -----Original Message----- > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > Sent: Saturday, April 25, 2009 1:11 PM > > > To: Ali C. Begen (abegen); avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > Multicast RTPSessions (RAMS)" available > > > > > > Ali, > > > Can you please write three addresses from this strange SDP. > > > > > > 1. The address and port of multicast > > > > > > 2. The address and port of the RS where the RTCP FB should go to > > > > > > 3. The address and port on the RR where the unicast stream > > > should be sent to > > > > > > Roni > > > > > > -----Original Message----- > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > Sent: Saturday, April 25, 2009 11:02 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > > Ali, > > > > The example SDP is syntactically correct but it does not > > > say that the > > > > rtp/rtcp mux will be used and it does not give the > > > > information to where the > > > > unicast stream will be sent when the RR sends a RAMS-R. > > > > > > To my knowledge, the first line in the following SDP tells > > > the RRs on which > > > port they will receive the retransmission/burst packets. > > > > > > m=video 41002 RTP/AVPF 99 > > > i=Unicast Retransmission Stream #2 (Ret. and Rapid > > > Acq. Support) > > > c=IN IP4 192.0.2.1 > > > a=rtpmap:99 rtx/90000 > > > a=rtcp:41003 > > > a=fmtp:99 apt=98; rtx-time=5000 > > > a=mid:4 > > > > > > There is a typo, you are right. That "a=recvonly" line should > > > only exist in > > > the SDP sent to RRs. In the SDP sent to RS, we should rather have > > > "a=sendonly". I will make this correction in the next version. > > > > > > The feedback target for the SSM session and the RTCP port for the > > > retransmission session are also defined in the SDP. > > > > > > Hope this clarifies. > > > > > > BR, > > > -acbegen > > > > > > > > > > > I am not sure why the unicast stream m-line has a port > > > number with an > > > > attribute of recvonly. What is the use case for that. The > > > > only information > > > > that the RR will need is the RTCP port on the RS to where to > > > > send the RAMS-R > > > > message. > > > > Roni > > > > -----Original Message----- > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > > Sent: Friday, April 24, 2009 10:37 PM > > > > To: Roni Even; avt@ietf.org > > > > Cc: Bill Ver Steeg (versteb) > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > > Multicast RTPSessions > > > > (RAMS)" available > > > > > > > > This is a part of an example SDP sent to RS and RR in a SAP > > > > announcement, > > > > for example. So, the SDP describes what both parties should > > > > do (RR cannot > > > > say that he wants to receive this multicast on its favorite > > > port). The > > > > individual SDPs sent to RR or RS may include other portions > > > > of descriptions > > > > that will contain specific information. > > > > > > > > -acbegen > > > > > > > > > -----Original Message----- > > > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > > > Sent: Friday, April 24, 2009 12:23 PM > > > > > To: Ali C. Begen (abegen); avt@ietf.org > > > > > Cc: Bill Ver Steeg (versteb) > > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > > > Multicast RTPSessions (RAMS)" available > > > > > > > > > > Ali, > > > > > I think you get it wrong, this SDP is from the RS and not the > > > > > RR so the RS > > > > > cannot specify to which address it will send it can only > > > > > specify to which > > > > > address it can receive RTP stream. In this SDP the relevant > > > > > information is > > > > > that the request for retransmission will be sent by the RR to > > > > > port 41003 > > > > > Roni > > > > > > > > > > -----Original Message----- > > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > > > Sent: Friday, April 24, 2009 10:01 PM > > > > > To: Roni Even; avt@ietf.org > > > > > Cc: Bill Ver Steeg (versteb) > > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > > > Multicast RTPSessions > > > > > (RAMS)" available > > > > > > > > > > Oh, I see. The burst goes to the port that we would > > > > normally send the > > > > > retransmissions. For example, consider the SDP from the draft: > > > > > > > > > > m=video 41000 RTP/AVPF 98 > > > > > i=Primary Multicast Stream #2 > > > > > c=IN IP4 224.1.1.2/255 > > > > > a=source-filter: incl IN IP4 224.1.1.2 192.0.2.2 > > > > > a=rtpmap:98 MP2T/90000 > > > > > a=rtcp:41001 IN IP4 192.0.2.1 > > > > > a=rtcp-fb:98 nack > > > > > a=rtcp-fb:98 nack ssli > > > > > a=ssrc:123321 cname:iptv-ch32@rams.example.com > > > > > a=mid:3 > > > > > m=video 41002 RTP/AVPF 99 > > > > > i=Unicast Retransmission Stream #2 (Ret. and Rapid > > > > > Acq. Support) > > > > > c=IN IP4 192.0.2.1 > > > > > a=recvonly > > > > > a=rtpmap:99 rtx/90000 > > > > > a=rtcp:41003 > > > > > a=fmtp:99 apt=98; rtx-time=5000 > > > > > a=mid:4 > > > > > > > > > > In this case, the burst will go to port 41002 on the RR. > > > The RAMS-I > > > > > message(s), which is an RTCP feedback message, will go to > > > > port 41003. > > > > > > > > > > HTH, > > > > > -acbegen > > > > > > > > > > > -----Original Message----- > > > > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > > > > Sent: Friday, April 24, 2009 11:44 AM > > > > > > To: Ali C. Begen (abegen); avt@ietf.org > > > > > > Cc: Bill Ver Steeg (versteb) > > > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > > > > Multicast RTPSessions (RAMS)" available > > > > > > > > > > > > Ali, > > > > > > I will try to explain in simple way > > > > > > > > > > > > When the RS receives the RAMS-R it need to start sending an > > > > > > RTP stream to > > > > > > the RR. > > > > > > In order to send a unicast packet, the RS needs to know a > > > > > > transport address > > > > > > on the RR to where the RTP stream will be sent. The current > > > > > > draft does not > > > > > > say how the RS knows this address. There is no SDP > from RR to > > > > > > RS like you > > > > > > mention in your response. > > > > > > This is why I say that the current draft does not specify a > > > > > > solution that > > > > > > can be implemented as a working solution > > > > > > Roni > > > > > > > > > > > > -----Original Message----- > > > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > > > > Sent: Friday, April 24, 2009 7:38 PM > > > > > > To: Roni Even; avt@ietf.org > > > > > > Cc: Bill Ver Steeg (versteb) > > > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > > > > Multicast RTPSessions > > > > > > (RAMS)" available > > > > > > > > > > > > Hi Roni, > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: avt-bounces@ietf.org > [mailto:avt-bounces@ietf.org] On > > > > > > > Behalf Of Roni Even > > > > > > > Sent: Friday, April 24, 2009 4:24 AM > > > > > > > To: avt@ietf.org > > > > > > > Cc: Bill Ver Steeg (versteb) > > > > > > > Subject: Re: [AVT] New draft of "Rapid Acquisition of > > > > > > > Multicast RTPSessions (RAMS)" available > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I think that the current draft does not give a > > description of > > > > > > > a system that works since there is no text > > explaining how the > > > > > > > > > > > > What do you mean by "a system that works"? > > > > > > > > > > > > > RS knows the unicast transport address on the RR to > > where to > > > > > > > send the stream. > > > > > > > > > > > > Once RS receives the request packet from an RR, RS > knows its > > > > > > address. Ports > > > > > > are defined in the SDP. If you are asking about > "NAT" issues, > > > > > > we have a > > > > > > section for it, and we plan to complete it as we move > > > > > > forward. It is not as > > > > > > critical as the other parts for now. > > > > > > > > > > > > > If you mandate the use of RTP/RTCP mux it should say so > > > > > > > otherwise the RAMS-R should have an optional > parameter that > > > > > > > supplies this information and a flag for using > RTP/RTCP mux. > > > > > > > > > > > > IMO, we cannot mandate muxing as it is not required to make > > > > > > RAMS work. If > > > > > > muxing is supported, the SDP should reflect it. > > > > > > > > > > > > BR, > > > > > > -acbegen > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > Roni Even > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: avt-bounces@ietf.org > [mailto:avt-bounces@ietf.org] On > > > > > > > Behalf Of Bill Ver Steeg (versteb) > > > > > > > Sent: Thursday, April 16, 2009 7:39 PM > > > > > > > To: avt@ietf.org > > > > > > > Subject: [AVT] New draft of "Rapid Acquisition of > Multicast > > > > > > > RTP Sessions (RAMS)" available > > > > > > > > > > > > > > > > > > > > > > > > > > > > There is a new draft of the "Rapid Acquisition of > Multicast > > > > > > > RTP Sessions (RAMS)" draft available at > > > > > > > > > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s > > > > > > ynchronization-for-rtp-03.txt > > > > > > > > > drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt> > > > > > > > > > > > > > > > > > > > > > > > > > > > > We have incorporated the changes from the technical > > breakout > > > > > > > session in San Francisco. The major changes in > this version > > > > > > > of the draft include > > > > > > > > > > > > > > 1- Changing the document title to avoid confusion > > with other > > > > > > > ongoing "synchronization" drafts > > > > > > > > > > > > > > 2- changing the message names to reflect the title change > > > > > > > > > > > > > > 3- clarification of the RTCP message semantics, including > > > > > > > changes to the "Request" and "Inform" messages > > > > > > > > > > > > > > 4- additional description/motivation for the > > various message > > > > > > > flows has been added > > > > > > > > > > > > > > 5- RTP/RTCP muxing has been added > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We hope to make this a Working Group item, and > will change > > > > > > > the name of the draft to avoid conflicts with other > > > > > > > "synchronization" drafts at that time. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Bill VerSteeg > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From abegen@cisco.com Sun Apr 26 18:53:11 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84373A6A9D for ; Sun, 26 Apr 2009 18:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.147 X-Spam-Level: X-Spam-Status: No, score=-5.147 tagged_above=-999 required=5 tests=[AWL=-0.948, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOmdEjRULhVn for ; Sun, 26 Apr 2009 18:53:09 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 80CE53A6A90 for ; Sun, 26 Apr 2009 18:53:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,251,1238976000"; d="scan'208";a="159047647" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 27 Apr 2009 01:54:18 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3R1sHtw010820; Sun, 26 Apr 2009 18:54:17 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3R1sHIE013069; Mon, 27 Apr 2009 01:54:17 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 26 Apr 2009 18:54:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 26 Apr 2009 18:54:14 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C844F@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49f4acd6.0c11660a.6549.ffffb339@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available Thread-Index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGHOeBQAAroqxAABGe0AAAAUgbQAAEZLVAAAGk5sAAgqbUwABJxCtAAAIRzIAAAQcKgAADfs5AAAik1MAAVaJ8AABHrLfAAA4ZboAAPnPFw References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> <49f2efa2.1c215e0a.4454.ffffaf91@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8403@xmb-sjc-215.amer.cisco.com> <49f36ee2.0437560a.11df.1eef@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8405@xmb-sjc-215.amer.cisco.com> <49f37fde.09a1660a.2b46.ffffb694@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8408@xmb-sjc-215.amer.cisco.com> <49f4182f.07a5660a.3f7f.ffffe36a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C841F@xmb-sjc-215.amer.cisco.com> <49f4acd6.0c11660a.6549.ffffb339@mx.google.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , X-OriginalArrivalTime: 27 Apr 2009 01:54:17.0742 (UTC) FILETIME=[131AA2E0:01C9C6DB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=25330; t=1240797257; x=1241661257; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20New=20draft=20of=20=22Rapid=20A cquisition=20of=20Multicast=20RTPSessions=09(RAMS)=22=20avai lable |Sender:=20; bh=1gAQNnM/0Oa37DdGnTsG4YJ16Lr414P4eixYhZBgkTY=; b=ihulOqfiaxlb176/dJ2dBf9bEy5aKSMHTBvy0cbjI4v8mNY4/O19J88WTp MDIHbqTzPvw4aIB30j+1YdHAn7TjvhEBRY/KZOROqc0z7kIp/r7GqoZJbNoh fAaa6IPwqPZdYYpxA5nacF9OlJgmC8BH2Fl5XO2gI3Owufx027gAU=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "Bill Ver Steeg \(versteb\)" Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 01:53:12 -0000 Roni, > Ali, > Your SDP example will not help anyone who will try to develop interop > application, the c-line in the unicast stream and the port=20 I believe this is rather a strong claim, considering that I already = mentioned that we would add more SDP examples as we moved forward. > should refer to > the same device since there is no other attribute in the=20 > example that points > to a different semantics to anyone who will look at it. The=20 > semantics that > you are using where the c-line is for the RS and the port is=20 > for the RR and > the RS assuming that the RS somehow knows the IP address of=20 > the RR based on > the RAMS-R request may work in some cases but should not be=20 > the one shown as > the primary example and should not be the recommended way,=20 Again, you are missing the point that we will add more SDP examples as = well as discussion for NAT issues. The current SDP is just one example = that we came up with, and which, I believe, still works and has been = there since version -00. It may be modified, removed or replaced. > The recommended > way should be to convey the address of the RR in the RAMS-R=20 > and this is the > reason I pointed to RTSP. The semantics of the SDP in the=20 This is reasonable, rtp/rtcp muxing is also reseanoable and it is indeed = very neat, too.=20 > example is not > documented in your text and is not obvious to anyone who will=20 > just look at > it. We can certainly add more detailed explanation to the SDP section. But, = let's focus more on the draft rather than a single SDP example that it = currently has. =20 > I also strongly object to mandating that the client MUST use=20 > a port defined > by the server to receive the unicast stream. The RS can=20 > recommend a port but > it is the client (RR) decision to decide which port to use. We are not mandating anything yet as I mentioned several times before. I = suggest we drop this discussion and move forward with the draft. Based = on the comments/suggestions that may be sent to your email about the SDP = example, we will be more than happy to incorporate what AVT decides to = do. -acbegen =20 >=20 >=20 > Roni Even >=20 > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > Sent: Sunday, April 26, 2009 8:02 PM > To: Roni Even; avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > Multicast RTPSessions > (RAMS)" available >=20 > Hi Roni, >=20 > Thanks for the detailed answer. Admittedly, I don't know much=20 > about RTSP > beyond its basics. However, I doubt how much it applies in our case. > "Unicast" in RTSP context mostly refers to video-on-demand kind of > applications where the primary distribution is over unicast.=20 > In contrast, > our primary distribution is over multicast, and we use=20 > unicast as a repair > stream. Thus, I still believe the SDP we have should work=20 > fine. RS gathers > the IP address of the RR when it receives the RAMS request.=20 > The samething > happens when RR sends a NACK for requesting retransmissions. >=20 > That is not to say that this SDP is the only SDP that will=20 > work in this > system. There may be others. But, I still don't agree with=20 > you when you say > that this SDP won't work. My expectation is that we will=20 > include other SDP > examples as we move forward. >=20 > On your last point, NAT is a different issue and there has to=20 > be a way to > deal with it. Muxing sounds reasonable, and we may or may not=20 > mandate it, I > am not sure at this point. An alternative could be that RR=20 > opens ports on > its NAT device and includes them in the request message it=20 > sends. These > could be in RAMS-R TLV extensions, or could be a separate=20 > RTCP packet solely > for this purpose within the same RTCP compound packet that carries the > RAMS-R. I believe Bill mentioned these briefly in his earlier=20 > email. We are > open to suggestions at this point and the NAT section will cover these > issues once we have a WG item. >=20 > -acbegen >=20 > =20 >=20 > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > > Sent: Sunday, April 26, 2009 1:14 AM > > To: Ali C. Begen (abegen); avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > Multicast RTPSessions (RAMS)" available > >=20 > > Ali, > > I looked at RTSP > >=20 > http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-20#appendix-D=20 > >=20 > >=20 > >=20 > > D.1.2. Media Streams > >=20 > > The "m=3D" field is used to enumerate the streams. It is=20 > > expected that > > all the specified streams will be rendered with appropriate > > synchronization. If the session is over multicast, the=20 > port number > > indicated SHOULD be used for reception. The client MAY try to > > override the destination port, through the Transport header. The > > servers MAY allow this, the response will indicate if=20 > > allowed or not. > > If the session is unicast, the port numbers are the ones=20 > > RECOMMENDED > > by the server to the client, about which receiver ports=20 > to use; the > > client MUST still include its receiver ports in its=20 > SETUP request. > > The client MAY ignore this recommendation. If the server has no > > preference, it SHOULD set the port number value to zero. > >=20 > >=20 > > Note that the client has the choice on which port to receive=20 > > the unicast > > stream, this is why there should be such a parameter in RAMS-R > >=20 > >=20 > > Also > >=20 > > " D.1.8. Connection Information > >=20 > > In SDP, the "c=3D" field contains the destination address=20 > > for the media > > stream. For on-demand unicast streams and some=20 > multicast streams, > > the destination address MAY be specified by the client via=20 > > the SETUP > > request, thus overriding any specified address. To=20 > > identify streams > > without a fixed destination address, where the client is=20 > > required to > > specify a destination address, the "c=3D" field SHOULD be=20 > > set to a null > > value. For addresses of type "IP4", this value MUST be=20 > "0.0.0.0", > > and for type "IP6", this value MUST be "0:0:0:0:0:0:0:0"=20 > > (can also be > > written as "::"), i.e. the unspecified address according=20 > > to RFC 4291 > > [RFC4291]." > >=20 > >=20 > > As for the c-line in the unicast stream the whole section you quoted > >=20 > > " If the session is multicast, the connection address will be an IP > > multicast group address. If the session is not=20 > multicast, then > > the connection address contains the unicast IP address of the > > expected data source or data relay or data sink as=20 > determined by > > additional attribute fields. It is not expected that unicast > > addresses will be given in a session description that is > > communicated by a multicast announcement, though this is not > > prohibited." > >=20 > > Now the expectation here is for the address of the stream=20 > > described by the > > port in the m-line, I do not see any other attribute. Also=20 > > look at the above > > text from RTSP. The RS does not know the IP address on the RR=20 > > to where to > > send the RTP unicast repair stream. If you assume it is to=20 > > the IP address > > from where the RTCP RAMS-R came from this is not mandated=20 > > that the client > > will have such implementation. Furthermore the address that=20 > > the RS will see > > in the received RTCP RAMS-R packet may have been change by a=20 > > NAT or SBC. > >=20 > >=20 > > Roni > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > > Sent: Sunday, April 26, 2009 1:23 AM > > To: Roni Even; avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > Multicast RTPSessions > > (RAMS)" available > >=20 > > Inline. > >=20 > > > m=3Dvideo 41000 RTP/AVPF 98 > > > i=3DPrimary Multicast Stream #2 > > > c=3DIN IP4 224.1.1.2/255 > > > a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 > > >=20 > > > Source (192.0.2.2) sends the rtp packets to the multicast=20 > > > group (224.1.1.2) > > > with a dest port 41000. > > >=20 > > > a=3Drtpmap:98 MP2T/90000 > > > a=3Drtcp:41001 IN IP4 192.0.2.1 > > >=20 > > > The feedback target (RS) address for this SSM session is=20 > > > 192.0.2.1 and its > > > port is 41001. This is the address/port where RR sends the=20 > > RAMS-R, or > > > receiver reports for the SSM session. > > >=20 > > > a=3Drtcp-fb:98 nack > > > a=3Drtcp-fb:98 nack ssli > > > a=3Dssrc:123321 cname:iptv-ch32@rams.example.com > > > a=3Dmid:3 > > > m=3Dvideo 41002 RTP/AVPF 99 > > >=20 > > > The retransmission packets go to port 41002. This is the port=20 > > > RRs listen to > > > for retransmission and RAMS. > > >=20 > > > Roni E: This implies that the multicast source defines the=20 > > > port that all > > > clients MUST use to receive the unicast information from the=20 > > > Burst source. =20 > >=20 > > Yes, that is what it implies (One nit is that I would call it=20 > > unicast RTP > > packets rather than information since we may use another=20 > port for RTCP > > packets). > > =20 > > > i=3DUnicast Retransmission Stream #2 (Ret. and Rapid=20 > > > Acq. Support) > > > c=3DIN IP4 192.0.2.1 > > >=20 > > > This is where the retransmission packets come from, same as=20 > > > the feedback > > > target (in this example). > > >=20 > > > Roni E: If this is the address of the feedback target it=20 > > > belongs to the > > > above m-line (m=3Dvideo 41002 RTP/AVPF 99) that according to=20 > > > you gives the > > > port on the RR and not on the RS. The problem is that=20 > >=20 > > This line actually specifies the sender for the unicast=20 > retransmission > > session. In our case, it just happens to be the feedback=20 > > target for the > > primary SSM session, too. I recall some discussion about using a > > retransmission source which is different than the feedback=20 > > target for the > > SSM. In that case, the address would be different, I guess. > >=20 > > > according to SDP the > > > combination of the c=3D and port on the m-line provides the=20 > > > transport address > > > to where a stream will be sent so according to SDP this=20 > >=20 > > The port on the m line is the port where the retranmission=20 > > packets are sent. > > However, c line denotes the source for these packets. RFC=20 > > 4566 page 13 says > > that "... If the session is not multicast, then the=20 > connection address > > contains the unicast IP address of the expected data source=20 > > or data relay or > > data sink as determined by additional attribute fields..." > >=20 > > Am I missing something? > >=20 > > > m-line specify an > > > address and port on the Feedback Target and not on the RR and=20 > > > only to this > > > address RTP payload type 99 will be sent. I am positive that=20 > > > this is not > > > what you want. > >=20 > > There can be other payload types we might need to send on this > > retransmission session in the future. In that case, we will=20 > add them. > > =20 > > > a=3Drtpmap:99 rtx/90000 > > > a=3Drtcp:41003 > > >=20 > > > This is where the RTCP packets for the retransmission=20 > > session go. For > > > example, RAMS-I goes to this port on RRs. RAMS-T goes to this=20 > > > port on RS. > > >=20 > > > Roni E: So now you assume that the RR must use the same port=20 > > > as the FT for > > > this communication. I could not find any place that one=20 > > > m-line gives the > >=20 > > Not the m line, but the "a=3Drtcp" line. Is this wrong? > >=20 > > > address for both sides. This RTCP port is on 192.0.2.1 so it=20 > > > will be used > > > for RAMS-R but not for RAMS-I. > >=20 > > RAMS-R should go to the feedback target address and port for=20 > > the primary SSM > > session since it is a feedback message for the SSM session.=20 > > But, RAMS-T is a > > feedback message for the retransmission session, thus, it=20 > > should go to the > > RTCP port of the retransmission session (41003). I hope this=20 > > also clarifies > > your question in the next email. If you think I got the ports=20 > > wrong, let me > > know. > >=20 > > -acbegen > > =20 > > > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > > > a=3Dmid:4 > > >=20 > > >=20 > > > -acbegen > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > > > > Sent: Saturday, April 25, 2009 1:11 PM > > > > To: Ali C. Begen (abegen); avt@ietf.org > > > > Cc: Bill Ver Steeg (versteb) > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > > Multicast RTPSessions (RAMS)" available > > > >=20 > > > > Ali, > > > > Can you please write three addresses from this strange SDP. > > > >=20 > > > > 1. The address and port of multicast > > > >=20 > > > > 2. The address and port of the RS where the RTCP FB should go to > > > >=20 > > > > 3. The address and port on the RR where the unicast stream=20 > > > > should be sent to > > > >=20 > > > > Roni > > > >=20 > > > > -----Original Message----- > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > > > > Sent: Saturday, April 25, 2009 11:02 PM > > > > To: Roni Even; avt@ietf.org > > > > Cc: Bill Ver Steeg (versteb) > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > > Multicast RTPSessions > > > > (RAMS)" available > > > >=20 > > > > > Ali, > > > > > The example SDP is syntactically correct but it does not=20 > > > > say that the > > > > > rtp/rtcp mux will be used and it does not give the=20 > > > > > information to where the > > > > > unicast stream will be sent when the RR sends a RAMS-R.=20 > > > >=20 > > > > To my knowledge, the first line in the following SDP tells=20 > > > > the RRs on which > > > > port they will receive the retransmission/burst packets. > > > >=20 > > > > m=3Dvideo 41002 RTP/AVPF 99 > > > > i=3DUnicast Retransmission Stream #2 (Ret. and Rapid=20 > > > > Acq. Support) > > > > c=3DIN IP4 192.0.2.1 > > > > a=3Drtpmap:99 rtx/90000 > > > > a=3Drtcp:41003 > > > > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > > > > a=3Dmid:4 > > > >=20 > > > > There is a typo, you are right. That "a=3Drecvonly" line should=20 > > > > only exist in > > > > the SDP sent to RRs. In the SDP sent to RS, we should=20 > rather have > > > > "a=3Dsendonly". I will make this correction in the next version. > > > >=20 > > > > The feedback target for the SSM session and the RTCP=20 > port for the > > > > retransmission session are also defined in the SDP. > > > >=20 > > > > Hope this clarifies. > > > >=20 > > > > BR, > > > > -acbegen > > > > =20 > > > > >=20 > > > > > I am not sure why the unicast stream m-line has a port=20 > > > > number with an > > > > > attribute of recvonly. What is the use case for that. The=20 > > > > > only information > > > > > that the RR will need is the RTCP port on the RS to where to=20 > > > > > send the RAMS-R > > > > > message. > > > > > Roni > > > > > -----Original Message----- > > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > > > > > Sent: Friday, April 24, 2009 10:37 PM > > > > > To: Roni Even; avt@ietf.org > > > > > Cc: Bill Ver Steeg (versteb) > > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > > > Multicast RTPSessions > > > > > (RAMS)" available > > > > >=20 > > > > > This is a part of an example SDP sent to RS and RR in a SAP=20 > > > > > announcement, > > > > > for example. So, the SDP describes what both parties should=20 > > > > > do (RR cannot > > > > > say that he wants to receive this multicast on its favorite=20 > > > > port). The > > > > > individual SDPs sent to RR or RS may include other portions=20 > > > > > of descriptions > > > > > that will contain specific information.=20 > > > > >=20 > > > > > -acbegen > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > > > > > > Sent: Friday, April 24, 2009 12:23 PM > > > > > > To: Ali C. Begen (abegen); avt@ietf.org > > > > > > Cc: Bill Ver Steeg (versteb) > > > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > > > > Multicast RTPSessions (RAMS)" available > > > > > >=20 > > > > > > Ali, > > > > > > I think you get it wrong, this SDP is from the RS=20 > and not the=20 > > > > > > RR so the RS > > > > > > cannot specify to which address it will send it can only=20 > > > > > > specify to which > > > > > > address it can receive RTP stream. In this SDP the relevant=20 > > > > > > information is > > > > > > that the request for retransmission will be sent by=20 > the RR to=20 > > > > > > port 41003 > > > > > > Roni > > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > > > > > > Sent: Friday, April 24, 2009 10:01 PM > > > > > > To: Roni Even; avt@ietf.org > > > > > > Cc: Bill Ver Steeg (versteb) > > > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > > > > Multicast RTPSessions > > > > > > (RAMS)" available > > > > > >=20 > > > > > > Oh, I see. The burst goes to the port that we would=20 > > > > > normally send the > > > > > > retransmissions. For example, consider the SDP from=20 > the draft: > > > > > >=20 > > > > > > m=3Dvideo 41000 RTP/AVPF 98 > > > > > > i=3DPrimary Multicast Stream #2 > > > > > > c=3DIN IP4 224.1.1.2/255 > > > > > > a=3Dsource-filter: incl IN IP4 224.1.1.2 192.0.2.2 > > > > > > a=3Drtpmap:98 MP2T/90000 > > > > > > a=3Drtcp:41001 IN IP4 192.0.2.1 > > > > > > a=3Drtcp-fb:98 nack > > > > > > a=3Drtcp-fb:98 nack ssli > > > > > > a=3Dssrc:123321 cname:iptv-ch32@rams.example.com > > > > > > a=3Dmid:3 > > > > > > m=3Dvideo 41002 RTP/AVPF 99 > > > > > > i=3DUnicast Retransmission Stream #2 (Ret. and Rapid = > > > > > > Acq. Support) > > > > > > c=3DIN IP4 192.0.2.1 > > > > > > a=3Drecvonly > > > > > > a=3Drtpmap:99 rtx/90000 > > > > > > a=3Drtcp:41003 > > > > > > a=3Dfmtp:99 apt=3D98; rtx-time=3D5000 > > > > > > a=3Dmid:4 > > > > > >=20 > > > > > > In this case, the burst will go to port 41002 on the RR.=20 > > > > The RAMS-I > > > > > > message(s), which is an RTCP feedback message, will go to=20 > > > > > port 41003. > > > > > >=20 > > > > > > HTH, > > > > > > -acbegen > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > > > > > > > Sent: Friday, April 24, 2009 11:44 AM > > > > > > > To: Ali C. Begen (abegen); avt@ietf.org > > > > > > > Cc: Bill Ver Steeg (versteb) > > > > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > > > > > Multicast RTPSessions (RAMS)" available > > > > > > >=20 > > > > > > > Ali, > > > > > > > I will try to explain in simple way > > > > > > >=20 > > > > > > > When the RS receives the RAMS-R it need to start=20 > sending an=20 > > > > > > > RTP stream to > > > > > > > the RR.=20 > > > > > > > In order to send a unicast packet, the RS needs to know a=20 > > > > > > > transport address > > > > > > > on the RR to where the RTP stream will be sent.=20 > The current=20 > > > > > > > draft does not > > > > > > > say how the RS knows this address. There is no SDP=20 > > from RR to=20 > > > > > > > RS like you > > > > > > > mention in your response. > > > > > > > This is why I say that the current draft does not=20 > specify a=20 > > > > > > > solution that > > > > > > > can be implemented as a working solution > > > > > > > Roni > > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > > > > > > > Sent: Friday, April 24, 2009 7:38 PM > > > > > > > To: Roni Even; avt@ietf.org > > > > > > > Cc: Bill Ver Steeg (versteb) > > > > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > > > > > > > Multicast RTPSessions > > > > > > > (RAMS)" available > > > > > > >=20 > > > > > > > Hi Roni,=20 > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: avt-bounces@ietf.org=20 > > [mailto:avt-bounces@ietf.org] On=20 > > > > > > > > Behalf Of Roni Even > > > > > > > > Sent: Friday, April 24, 2009 4:24 AM > > > > > > > > To: avt@ietf.org > > > > > > > > Cc: Bill Ver Steeg (versteb) > > > > > > > > Subject: Re: [AVT] New draft of "Rapid Acquisition of=20 > > > > > > > > Multicast RTPSessions (RAMS)" available > > > > > > > >=20 > > > > > > > > Hi, > > > > > > > >=20 > > > > > > > > I think that the current draft does not give a=20 > > > description of=20 > > > > > > > > a system that works since there is no text=20 > > > explaining how the=20 > > > > > > >=20 > > > > > > > What do you mean by "a system that works"?=20 > > > > > > >=20 > > > > > > > > RS knows the unicast transport address on the RR to=20 > > > where to=20 > > > > > > > > send the stream.=20 > > > > > > >=20 > > > > > > > Once RS receives the request packet from an RR, RS=20 > > knows its=20 > > > > > > > address. Ports > > > > > > > are defined in the SDP. If you are asking about=20 > > "NAT" issues,=20 > > > > > > > we have a > > > > > > > section for it, and we plan to complete it as we move=20 > > > > > > > forward. It is not as > > > > > > > critical as the other parts for now. > > > > > > > =20 > > > > > > > > If you mandate the use of RTP/RTCP mux it should say so=20 > > > > > > > > otherwise the RAMS-R should have an optional=20 > > parameter that=20 > > > > > > > > supplies this information and a flag for using=20 > > RTP/RTCP mux. > > > > > > >=20 > > > > > > > IMO, we cannot mandate muxing as it is not=20 > required to make=20 > > > > > > > RAMS work. If > > > > > > > muxing is supported, the SDP should reflect it. > > > > > > >=20 > > > > > > > BR, > > > > > > > -acbegen > > > > > > > =20 > > > > > > > > Thanks > > > > > > > >=20 > > > > > > > > Roni Even > > > > > > > >=20 > > > > > > > > =20 > > > > > > > >=20 > > > > > > > > From: avt-bounces@ietf.org=20 > > [mailto:avt-bounces@ietf.org] On=20 > > > > > > > > Behalf Of Bill Ver Steeg (versteb) > > > > > > > > Sent: Thursday, April 16, 2009 7:39 PM > > > > > > > > To: avt@ietf.org > > > > > > > > Subject: [AVT] New draft of "Rapid Acquisition of=20 > > Multicast=20 > > > > > > > > RTP Sessions (RAMS)" available > > > > > > > >=20 > > > > > > > > =20 > > > > > > > >=20 > > > > > > > > There is a new draft of the "Rapid Acquisition of=20 > > Multicast=20 > > > > > > > > RTP Sessions (RAMS)" draft available at=20 > > > > > > > >=20 > > > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s > > > > > > > ynchronization-for-rtp-03.txt=20 > > > > > > > > >=20 > > > drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt>=20 > > > > > > > >=20 > > > > > > > > =20 > > > > > > > >=20 > > > > > > > > We have incorporated the changes from the technical=20 > > > breakout=20 > > > > > > > > session in San Francisco. The major changes in=20 > > this version=20 > > > > > > > > of the draft include=20 > > > > > > > >=20 > > > > > > > > 1- Changing the document title to avoid confusion=20 > > > with other=20 > > > > > > > > ongoing "synchronization" drafts > > > > > > > >=20 > > > > > > > > 2- changing the message names to reflect the=20 > title change > > > > > > > >=20 > > > > > > > > 3- clarification of the RTCP message semantics,=20 > including=20 > > > > > > > > changes to the "Request" and "Inform" messages > > > > > > > >=20 > > > > > > > > 4- additional description/motivation for the=20 > > > various message=20 > > > > > > > > flows has been added > > > > > > > >=20 > > > > > > > > 5- RTP/RTCP muxing has been added > > > > > > > >=20 > > > > > > > > =20 > > > > > > > >=20 > > > > > > > > =20 > > > > > > > >=20 > > > > > > > > We hope to make this a Working Group item, and=20 > > will change=20 > > > > > > > > the name of the draft to avoid conflicts with other=20 > > > > > > > > "synchronization" drafts at that time. > > > > > > > >=20 > > > > > > > > =20 > > > > > > > >=20 > > > > > > > > Bill VerSteeg > > > > > > > >=20 > > > > > > > > =20 > > > > > > > >=20 > > > > > > > > =20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > >=20 > > > > >=20 > > > >=20 > > > >=20 > > >=20 > > >=20 > >=20 > >=20 >=20 >=20 From ron.even.tlv@gmail.com Mon Apr 27 11:14:09 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 737963A69F0 for ; Mon, 27 Apr 2009 11:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3jzLu47kg9k for ; Mon, 27 Apr 2009 11:14:05 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 1DFD83A6B01 for ; Mon, 27 Apr 2009 11:14:04 -0700 (PDT) Received: by fxm2 with SMTP id 2so73110fxm.37 for ; Mon, 27 Apr 2009 11:15:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=+rWS8t31FXXg7Aq8aca+5N9qY3HsYTjweMIm9mAKNFs=; b=GP5/+9r/JjCa07AdlmVVK1nPDUQN9vflFcMlTDKOSDE25wHz0P42p3roV1ILmzmQlh ySAtxszgq6UaDLC0U3lMlylgKZpwtEa89jzrJzFn5meZDlaHOQCYzQ0uaDcroz/B4Rt0 TdwmmyuWoEF2hodl5M0XF09Wd6TACBjHL9QWY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; b=VWtlBF7p3mZKQOthN8vdmVgwAuwHaYtJq9Wg26kxHbJq2jxRtw6x6WLv5eWe4ZLzeO +4rbr40UFRM5p+d2dGRtZZgoqpGSQ5TCLPTXNPeH6dafbFLGeM8D53rTxNyKcz/O/bf0 00MXw9/kIU96/jxQJv7A75EDhzYC5Tmc38UB0= Received: by 10.103.246.1 with SMTP id y1mr3407486mur.72.1240856125260; Mon, 27 Apr 2009 11:15:25 -0700 (PDT) Received: from windows8d787f9 (bzq-79-182-99-139.red.bezeqint.net [79.182.99.139]) by mx.google.com with ESMTPS id 25sm13249798mul.27.2009.04.27.11.15.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Apr 2009 11:15:24 -0700 (PDT) From: "Roni Even" To: Date: Mon, 27 Apr 2009 21:13:27 +0300 Message-ID: <49f5f63c.190c660a.58fe.2556@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01C9C77D.07A4A580" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnHY9zDr/fCw2IRQrSOnEAtgzkHpw== Content-Language: en-us Subject: [AVT] Comments on draft-ietf-avt-rtp-ipmr-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 18:14:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0063_01C9C77D.07A4A580 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I reviewed the draft and have the following comments most are editorial 1. The draft should have an author name at the top, not just SPIRIT SDP, there is an author name at the end Sergey Ikonin. 2. You describe the payload but it is not clear to me how do you know the size of each speech frame. It may be good to explain it if you can. 3. In section 3 RTP payload format you should start with a section on RTP header usage. See for example RFC 5404. 4. In the security consideration you can use the first two paragraph from RFC 5404 security section. 5. You can add a section on congestion control, this codec can handle congestion so it will be good to mention it. 6. You can add to section 5.2 a subsection on offer answer considerstions Some nits 1. In section 2 "This making the bit stream scalable and allows reduce ." 2. In section 2 " But because of the scalable nature of IP-MR codec there is no need to duplicate the whole previous frame - only the core layer may be retransmitted." 3. In section 3.2 "BR (3 bits): base rate for core layer of frame(s) in this packet using the table for CR. " Thanks Roni Even ------=_NextPart_000_0063_01C9C77D.07A4A580 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I reviewed the draft and have the following = comments most are editorial

 

1.       The draft should have an = author name at the top, not just SPIRIT SDP, there is an author name at the end = Sergey Ikonin.

2.       You describe the payload = but it is not clear to me how do you know the size of each speech frame. It may be = good to explain it if you can.

3.       In section 3 RTP payload = format you should start with a section on RTP header usage. See for example RFC = 5404.

4.       In the security = consideration you can use the first two paragraph from RFC 5404 security = section.

5.       You can add a section on congestion control, this codec can handle congestion so it will be good = to mention it.

6.       You can add to section = 5.2 a subsection on offer answer considerstions

 

Some nits

 

1.       In section 2 =  "This making the bit stream scalable and allows reduce = …"

2.       In section 2 " But = because of the scalable nature of IP-MR codec there is no need to duplicate = the whole previous frame - only the core layer may be = retransmitted."

3.       In section 3.2 "BR = (3 bits): base rate for core layer of frame(s) in this packet using the table = for CR. "

 

 

Thanks

Roni Even

 

 

 

 

 

 

------=_NextPart_000_0063_01C9C77D.07A4A580-- From wwwrun@core3.amsl.com Mon Apr 27 11:42:15 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 7A4A13A6FCD; Mon, 27 Apr 2009 11:42:15 -0700 (PDT) To: csp@csperkins.org,thomas.schierl@hhi.fraunhofer.de From: IETF Secretariat Message-Id: <20090427184215.7A4A13A6FCD@core3.amsl.com> Date: Mon, 27 Apr 2009 11:42:15 -0700 (PDT) Cc: fluffy@cisco.com, tom.taylor@rogers.com, avt@ietf.org, ipr-announce@ietf.org Subject: [AVT] Posting of IPR Disclosure related to ipr-fraunhofer-gesellschaft-draft-ietf-avt-rapid-rtp-sync-00, draft-schierl-avt-rtp-ntp-for-layered-codecs-00 and draft-perkins-avt-rapid-rtp-sync-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 18:42:15 -0000 Dear Colin Perkins, Thomas Schierl: An IPR disclosure that pertains to your Internet-Draft entitled "Rapid Synchronisation of RTP Flows" (draft-ietf-avt-rapid-rtp-sync) was submitted to the IETF Secretariat on 2009-04-22 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1140/). The title of the IPR disclosure is "ipr-fraunhofer-gesellschaft-draft-ietf-avt-rapid-rtp-sync-00, draft-schierl-avt-rtp-ntp-for-layered-codecs-00 and draft-perkins-avt-rapid-rtp-sync-02." The IETF Secretariat From ron.even.tlv@gmail.com Mon Apr 27 14:02:33 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59BCE3A680D; Mon, 27 Apr 2009 14:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QonYcct4vdnV; Mon, 27 Apr 2009 14:02:24 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 128E23A6863; Mon, 27 Apr 2009 14:02:22 -0700 (PDT) Received: by bwz7 with SMTP id 7so164724bwz.37 for ; Mon, 27 Apr 2009 14:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=Dnn2rjdV2CcSj5KfHeahfgAYaVzSSgVjqz0bBO34L/c=; b=PYjUDWrPi4hfXGkgtHSo06PvWrx8colFkyJBNTwMTNGV4Zo2wL+h+N1ql3L2Q9Q4YE KFyGwxry14PNOH44mB5+36ngfLFHG/7TxZvUUs7bPi1zJoDWe5s3mOmRz1YqDFQx5b4c 54v8QxNvqcSRbzPSC+8StEXCyrY8azKbjjJJE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; b=L4TURdzomQ5QhbKYp5lwf89B+7kOBN3V9H3sOVLr1075mmyPjoPNlbg833JCOuSCd7 lvr9+PrvtP6i6sysfdTZ6Dc1hrLJQ0A2REekGjapyH1DUX/c0eBfgz2OES5557mQLCu5 AijyJpbD8NZsFzz1eFf+9JpIPDE4yife1vOaU= Received: by 10.86.74.4 with SMTP id w4mr620578fga.11.1240866223273; Mon, 27 Apr 2009 14:03:43 -0700 (PDT) Received: from windows8d787f9 (bzq-79-182-99-139.red.bezeqint.net [79.182.99.139]) by mx.google.com with ESMTPS id 12sm448281fgg.0.2009.04.27.14.03.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Apr 2009 14:03:42 -0700 (PDT) From: "Roni Even" To: "'VAN CAENEGEM Tom'" , References: <238382595265324EA50F6134BB42DCAF03B18B96@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <238382595265324EA50F6134BB42DCAF03B18B96@FRVELSMBS22.ad2.ad.alcatel.com> Date: Tue, 28 Apr 2009 00:01:48 +0300 Message-ID: <49f61dae.0c07560a.64b2.ffffb27d@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0077_01C9C794.8B94ECD0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnEyIV3JVxE1pVAQlWyD4mzx47lUgCsVa3A Content-Language: en-us Cc: mmusic@ietf.org Subject: Re: [AVT] Multiple Feedback Targets in " http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18" X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 21:02:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0077_01C9C794.8B94ECD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tom, I think this question should go to mmusic. What you are trying to do here is to define semantics for the content of a RTCP flow pointing to different devices. The m-line or the RTCP line in SDP does not address what is the content of the stream that will go in the RTP session. RFC 4796 addresses the media content issue but you are looking for something similar to the RTCP attribute. This may require a new parameter to the rtcp attribute. You will also need to look at backward interoperability where the receiver will not understand this semantics and may change the RTCP message to the wrong address. The example for the content attribute was to specify to video m-lines one with screen capture as a video stream and the other from a camera. SDP does not define the behavior of the receiver if it receives two m-lines of the same media type and can only support one. It is not clear which one he will chose (first or second). The work on capability negotiation tries to address this issue. Roni Even From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of VAN CAENEGEM Tom Sent: Friday, April 24, 2009 1:36 PM To: avt@ietf.org Subject: [AVT] Multiple Feedback Targets in " http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18" Hi, I have two questions/comments mostly regarding the RTCP-SSM draft ( http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18). The background of my questions is the use case of "broadcast channels" in an IPTV context, where the channels are distributed over IP multicast (SSM). In this context, the concept of feedback target(s) is obviously very useful, and actually necessary given today's restrictions with multicast in upstream in the "WAN". For the IPTV use case, it also makes sense to have multiple feedback targets, each responsible for a subset of RTP receivers, because of the large number of RTP receivers involved (100.000s is possible). The way to signal this by means of SDP is that each local subset of RTP receivers sees a different IP address in the "a=rtcp: "portnumber" IN IP4 "IP address" line. So, multiple "localised" FT is covered by the draft IMO. However, in that case, the maximum bandwidth that can be used for RTCP reporting by RTP receivers only needs to be determined by the size of the local group of RTP receivers (sending RTCP to the same localised Feedback Target), especially in the summary FB model. But in my interpretation of the architecture, the actual RTCP bandwith limit information can only be retrieved by the RTP receivers from the information sent by the distribution source in the ssm session. Either by refected RTCP reports from RTP receivers (not a feasible solution for the given use case) or from a RSI message -in the summary FB model- indicating the session size or explicitly the RTCP reporting bandwidth limit. The fact is that this information is sent to ALL RTP receivers, which may be reporting to different Feedback targets where each Feedback target is collecting RTCP messages from a different number of RTP receivers, and hence may have different "requirements" for total RTCP reporting bandwidth limit. My question is whether local Feedback targets have been considered with respect to this issue? My second question again has to do with multiple feedback targets for the same use case. In the IPTV use case for rtcpssm, Feedback Targets can also be used as retransmission sources (RFC 4588) and in http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp- 03, the feedback target architecture is used to allow fast acquisition of SSM RTP sessions. The draft proposes that a "burst source" is co-located with the FT which transmits unicast data (starting with a random access point of the video channel) from a cache that holds the most recent data distributed over the RTP SSM. It does transmit the RTP packets at an accelerated speed, allowing the RTP receiver to join the SSM after some time. The idea I would like to bring forward is to allow separate Feedback Targets for the same RTP receiver (population): one Feedback target acts as RTP retransmission server (see http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp- 03) and collects RTCP FB messages, while the other Feedback Target is solely "responsible" for the non RTCP-FB messages, such as RTCP XR messages. I realise this idea is not necessarily linked with the rtcp-ssm draft, but IMO only for a massive scale application that makes use of RTP and leverages rtcp ssm such a separation is justified. The possibility for separation of the monitoring service -associated with a server function basically responsible for collecting RTCP receiver reports for the purpose of monitoring- and the retransmission service requiring a server function that is responsible for processing and responding to RTCP FB messages, is driven from the point of view of server function optimisation (different requirements on the server platform). In terms of signaling two Feedback Targets, we could make use of the following lines: a=rtcp:40001 IN IP4 192.0.2.1 (This is for retransmission) a=rtcp-fb:96 nack a=rtcp:40001 IN IP4 192.0.2.2 (This is for XR collection) However, that is probably quite ambiguous..? Furthermore I also realise such a solution introduces other questions than just signaling syntax including the fact that we may need guiding rules on how RTCP reports are issued by the RTP receiver with two RTCP targets in place, as in the example above. The new RFC 5506 is certainly helpful here, but this is probably not sufficient. Comments appreciated on this idea. Kind regards, Tom Van Caenegem ------=_NextPart_000_0077_01C9C794.8B94ECD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Multiple Feedback Targets in " http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18"

Tom,

I think this question should go to mmusic. What you are = trying to do here is to define semantics for the content of a RTCP flow = pointing to different devices. The m-line or the RTCP line in SDP does not address = what is the content of the stream that will go in the RTP session.  RFC = 4796 addresses the media content issue but you are looking for something = similar to the RTCP attribute. This may require a new parameter to the rtcp = attribute.

You will also need to look at backward interoperability = where the receiver will not understand this semantics and may change the RTCP = message to the wrong address.

 

The example for the content attribute was to specify to = video m-lines one with screen capture as a video stream and the other from a = camera. SDP does not define the behavior of the receiver if it receives two = m-lines of the same media type and can only support one. It is not clear which one = he will chose (first or second). The work on capability negotiation tries to = address this issue.

 

Roni Even

 

From:= avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = VAN CAENEGEM Tom
Sent: Friday, April 24, 2009 1:36 PM
To: avt@ietf.org
Subject: [AVT] Multiple Feedback Targets in " http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18"

 

 

Hi, =

I = have two questions/comments mostly regarding the RTCP-SSM draft (http://tools.= ietf.org/html/draft-ietf-avt-rtcpssm-18). The = background of my questions is the use case of "broadcast channels" in an = IPTV context, where the channels are distributed over IP multicast (SSM). In = this context, the concept of feedback target(s) is obviously very useful, and actually necessary given today's restrictions with multicast in upstream = in the "WAN".

For = the IPTV use case, it also makes sense to have multiple feedback targets, each responsible for a subset of RTP receivers, because of the large number = of RTP receivers involved (100.000s is possible). The way to signal this by = means of SDP is that each local subset of RTP receivers sees a different IP = address in the "a=3Drtcp: "portnumber" IN IP4 "IP address"  line.  So, multiple "localised" FT  is covered by the draft = IMO.

However, in that case, the maximum bandwidth that can be used for RTCP reporting by = RTP receivers only needs to be determined by the size of the local group of RTP = receivers (sending RTCP to the same localised Feedback Target), especially in the = summary FB model. But in my interpretation of the architecture, the actual RTCP bandwith limit information can only be retrieved by the RTP receivers = from the information sent by the distribution source in the ssm session. Either = by refected RTCP reports from RTP receivers (not a feasible solution for = the given use case) or from a RSI message -in the summary FB model- indicating the session size or explicitly the RTCP reporting bandwidth limit. The fact = is that this information is sent to ALL RTP receivers, which may be reporting to different Feedback targets where each Feedback target is collecting RTCP = messages from a different number of RTP receivers, and hence may have different "requirements" for total RTCP reporting bandwidth limit.  = My question is whether local Feedback targets have been considered with = respect to this issue?

My = second question again has to do with multiple feedback targets for the same use = case.

In = the IPTV use case for rtcpssm, Feedback Targets can also be used as = retransmission sources (RFC 4588) and in http://tools.= ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp-03<= /a>, the = feedback target architecture is used to allow fast acquisition of SSM RTP sessions. The = draft proposes that  a "burst source" is co-located with the FT = which transmits unicast data (starting with a random access point of the video channel) from a cache that holds the most recent data distributed over = the RTP SSM. It does transmit the RTP packets at an accelerated speed, allowing = the RTP receiver to join the SSM after some time.

The = idea I would like to bring forward is to allow separate Feedback Targets  = for the same RTP receiver (population): one Feedback target acts as RTP = retransmission server (see http://tools.= ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp-03<= /a>) and = collects RTCP FB messages, while the other Feedback Target is solely = "responsible" for the non RTCP-FB messages, such as RTCP XR messages. I realise this = idea is not necessarily linked with  the rtcp-ssm draft, but IMO only for a massive scale application that makes use of RTP and leverages rtcp ssm = such a separation is justified. The possibility for separation of the = monitoring service –associ= ated with a server function basically responsible for collecting RTCP = receiver reports for the purpose of monitoring- and the retransmission service = requiring a server function that is responsible for processing and responding to = RTCP FB messages, is driven from the point of view of server function = optimisation (different requirements on the server platform).

In = terms of signaling two Feedback Targets, we could make use of the following = lines:

a=3Drtcp:40001 IN IP4 192.0.2.1 (This is for retransmission)
a=3Drtcp-fb:96 nack
a=3Drtcp:40001 IN IP4 192.0.2.2 (This is for XR collection) =

 

However, that is probably quite ambiguous..?
Furthermore = I also realise such a solution introduces other questions than just = signaling syntax including the fact that we may need guiding rules on how RTCP = reports are issued by the RTP receiver with two RTCP targets in place, as in the example above. The new RFC 5506 is certainly helpful here, but this is = probably not sufficient.

Comments appreciated on this idea.

Kind regards,
Tom = Van Caenegem

 

 =

------=_NextPart_000_0077_01C9C794.8B94ECD0-- From csp@csperkins.org Tue Apr 28 06:43:33 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA65A3A6C29 for ; Tue, 28 Apr 2009 06:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.77 X-Spam-Level: X-Spam-Status: No, score=-3.77 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIKJOgjI12sH for ; Tue, 28 Apr 2009 06:43:33 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by core3.amsl.com (Postfix) with ESMTP id DDFDC3A6A85 for ; Tue, 28 Apr 2009 06:43:32 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1LyncE-0000r5-Zy for avt@ietf.org; Tue, 28 Apr 2009 13:44:54 +0000 Message-Id: From: Colin Perkins To: IETF AVT WG In-Reply-To: <20090225194501.8296628C2D1@core3.amsl.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 28 Apr 2009 14:44:52 +0100 References: <20090225194501.8296628C2D1@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [AVT] I-D Action:draft-ietf-avt-rtcp-xr-meas-identity-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 13:43:33 -0000 On 25 Feb 2009, at 19:45, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Audio/Video Transport Working Group > of the IETF. > > > Title : RTCP XR Report Block for Measurement Identity > Author(s) : G. Hunt, A. Clark > Filename : draft-ietf-avt-rtcp-xr-meas-identity-01.txt > Pages : 13 > Date : 2009-02-25 > > This document defines an RTCP XR Report Block carrying parameters > which identify a measurement, to which one or more other RTCP XR > Report Blocks may refer. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-xr-meas-identity-01.txt The changes look good - thanks! -- Colin Perkins http://csperkins.org/ From csp@csperkins.org Tue Apr 28 06:44:49 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9BDB28C240 for ; Tue, 28 Apr 2009 06:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GacO7r0WlXX for ; Tue, 28 Apr 2009 06:44:49 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by core3.amsl.com (Postfix) with ESMTP id D9D5728C20C for ; Tue, 28 Apr 2009 06:44:48 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1LyndS-0002SK-Wi for avt@ietf.org; Tue, 28 Apr 2009 13:46:10 +0000 Message-Id: <4BA6FE67-0AB5-49B0-857D-7F202641323A@csperkins.org> From: Colin Perkins To: IETF AVT WG In-Reply-To: <20090225194501.7F32928C2D0@core3.amsl.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 28 Apr 2009 14:46:08 +0100 References: <20090225194501.7F32928C2D0@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [AVT] I-D Action:draft-ietf-avt-rtcp-xr-pdv-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 13:44:49 -0000 On 25 Feb 2009, at 19:45, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Audio/Video Transport Working Group > of the IETF. > > > Title : RTCP XR Report Block for Packet Delay Variation > Metric Reporting > Author(s) : G. Hunt, A. Clark > Filename : draft-ietf-avt-rtcp-xr-pdv-01.txt > Pages : 15 > Date : 2009-02-25 > > This document defines an RTCP XR Report Block that allows the > reporting of Packet Delay Variation metrics for a range of RTP > applications. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-xr-pdv-01.txt Changes here look good too, thanks. -- Colin Perkins http://csperkins.org/ From petithug@acm.org Tue Apr 28 07:12:42 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F262D3A6C6B for ; Tue, 28 Apr 2009 07:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.966 X-Spam-Level: X-Spam-Status: No, score=-101.966 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_6CONS_WORD=0.356, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3p6AqwUVbP7D for ; Tue, 28 Apr 2009 07:12:42 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 3745A3A70D1 for ; Tue, 28 Apr 2009 07:12:03 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 62F32DFC4004; Tue, 28 Apr 2009 14:13:24 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 18A96DFC4002 for ; Tue, 28 Apr 2009 14:13:24 +0000 (UTC) Message-ID: <49F70F02.2060304@acm.org> Date: Tue, 28 Apr 2009 07:13:22 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: avt@ietf.org References: <49F24BC1.8080107@acm.org> In-Reply-To: <49F24BC1.8080107@acm.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [AVT] SDP attribute in rtcpssm-18 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 14:12:43 -0000 Marc Petit-Huguenin wrote: > Section 10.1 of draft-ietf-avt-rtcpssm-18 states that '[a] new > session level attribute MUST be used [...]: "rtcp-unicast"' but the > IANA considerations section registers a media level only att-field > named "unicast-rtcp". So which one should be used, and is it a > media or a session level attribute? Has anybody implemented this draft? -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From geoff.hunt@bt.com Tue Apr 28 09:42:44 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EE543A6AE0 for ; Tue, 28 Apr 2009 09:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[AWL=0.508, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9yAU-2xh5gb for ; Tue, 28 Apr 2009 09:42:43 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id A8E7A3A6A2B for ; Tue, 28 Apr 2009 09:42:42 -0700 (PDT) Received: from E03MVY2-UKDY.domain1.systemhost.net ([193.113.30.58]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Apr 2009 17:44:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Apr 2009 17:44:00 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-avt-rtcp-xr-pdv-02 thread-index: AcnIH8DMygSNu7nLTyqBbrbfMpFgCwAABeZA From: To: X-OriginalArrivalTime: 28 Apr 2009 16:44:02.0800 (UTC) FILETIME=[897DC700:01C9C820] Subject: [AVT] FW: New Version Notification for draft-ietf-avt-rtcp-xr-pdv-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 16:42:44 -0000 This revised draft addresses Al Morton's comment at IETF 74, concerning aligning the descriptions of packet delay variation metrics with the terminology used in RFC 5481. Review comments on this and any others of the Clark/Hunt -rtcp-xr-* drafts will be very welcome! Thanks Geoff Geoff Hunt=20 BT Design Tel: 01473 608325 Email: geoff.hunt@bt.com Web: www.bt.com This email contains BT information, which may be privileged or confidential. It is meant only for the individual(s) or entity named above. If you are not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you have received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: 28 April 2009 17:37 To: Hunt,RG,Geoff,DMM R Cc: alan.d.clark@telchemy.com Subject: New Version Notification for draft-ietf-avt-rtcp-xr-pdv-02=20 A new version of I-D, draft-ietf-avt-rtcp-xr-pdv-02.txt has been successfuly submitted by Geoff Hunt and posted to the IETF repository. Filename: draft-ietf-avt-rtcp-xr-pdv Revision: 02 Title: RTCP XR Report Block for Packet Delay Variation Metric Reporting Creation_date: 2009-04-28 WG ID: avt Number_of_pages: 15 Abstract: This document defines an RTCP XR Report Block that allows the reporting of Packet Delay Variation metrics for a range of RTP applications. =20 The IETF Secretariat. From root@core3.amsl.com Tue Apr 28 09:45:01 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BBD073A70BD; Tue, 28 Apr 2009 09:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090428164501.BBD073A70BD@core3.amsl.com> Date: Tue, 28 Apr 2009 09:45:01 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtcp-xr-pdv-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 16:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTCP XR Report Block for Packet Delay Variation Metric Reporting Author(s) : G. Hunt, A. Clark Filename : draft-ietf-avt-rtcp-xr-pdv-02.txt Pages : 15 Date : 2009-04-28 This document defines an RTCP XR Report Block that allows the reporting of Packet Delay Variation metrics for a range of RTP applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-xr-pdv-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-rtcp-xr-pdv-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-28093655.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue Apr 28 09:45:01 2009 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BEB983A70BF; Tue, 28 Apr 2009 09:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090428164501.BEB983A70BF@core3.amsl.com> Date: Tue, 28 Apr 2009 09:45:01 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtp-g718-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 16:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP payload format for G.718 speech/audio Author(s) : A. Lakaniemi, Y. Wang Filename : draft-ietf-avt-rtp-g718-01.txt Pages : 31 Date : 2009-04-28 This document specifies the Real-Time Transport Protocol (RTP) payload format for the Embedded Variable Bit-Rate (EV-VBR) speech/audio codec, specified in ITU-T G.718. A media type registration for this RTP payload format is also included. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-g718-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-rtp-g718-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-28094004.I-D@ietf.org> --NextPart-- From yekuiwang@huawei.com Tue Apr 28 10:10:01 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BB0128C0F6 for ; Tue, 28 Apr 2009 10:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQ9oZ6IZbtB7 for ; Tue, 28 Apr 2009 10:09:57 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 262023A6CB7 for ; Tue, 28 Apr 2009 10:09:57 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIT00MP7MEUME@usaga02-in.huawei.com> for avt@ietf.org; Tue, 28 Apr 2009 10:11:18 -0700 (PDT) Received: from W90946 ([10.51.0.39]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIT00AAAMENKB@usaga02-in.huawei.com> for avt@ietf.org; Tue, 28 Apr 2009 10:11:17 -0700 (PDT) Date: Tue, 28 Apr 2009 13:11:11 -0400 From: Ye-Kui Wang In-reply-to: <20090428164501.BEB983A70BF@core3.amsl.com> To: avt@ietf.org Message-id: <11F22DC0E8574D8C9803360952ED2018@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnIIbCn50AuTRWnQV2X9eLz5qaXPwAAnRew References: <20090428164501.BEB983A70BF@core3.amsl.com> Subject: Re: [AVT] I-D Action:draft-ietf-avt-rtp-g718-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 17:10:01 -0000 This is just a keep-alive submission with only updates to my affiliation/address and the boiler template. BR, YK > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Tuesday, April 28, 2009 12:45 PM > To: i-d-announce@ietf.org > Cc: avt@ietf.org > Subject: [AVT] I-D Action:draft-ietf-avt-rtp-g718-01.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport > Working Group of the IETF. > > > Title : RTP payload format for G.718 speech/audio > Author(s) : A. Lakaniemi, Y. Wang > Filename : draft-ietf-avt-rtp-g718-01.txt > Pages : 31 > Date : 2009-04-28 > > This document specifies the Real-Time Transport Protocol > (RTP) payload format for the Embedded Variable Bit-Rate > (EV-VBR) speech/audio codec, specified in ITU-T G.718. A > media type registration for this RTP payload format is also included. > > Conventions used in this document > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as > described in RFC 2119 [RFC2119]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-g718-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail > reader implementation to automatically retrieve the ASCII > version of the Internet-Draft. > From timur.friedman@gmail.com Tue Apr 28 12:15:32 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D5273A6904 for ; Tue, 28 Apr 2009 12:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.782 X-Spam-Level: X-Spam-Status: No, score=-0.782 tagged_above=-999 required=5 tests=[AWL=-0.664, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZYhVWyLmbHg for ; Tue, 28 Apr 2009 12:15:31 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 2A6043A6B05 for ; Tue, 28 Apr 2009 12:15:31 -0700 (PDT) Received: by fxm2 with SMTP id 2so749010fxm.37 for ; Tue, 28 Apr 2009 12:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to :content-type:content-transfer-encoding; bh=REcDDkOwLWy2+ZZ3eAhgzYURmipr28UkILsXhxCGrEc=; b=bXNHPOlwTFdiEOg45X6Pm+H3fe0Tz/W+wKB+mHsiuQly+trYC2p+gjUkUPqQZztJE+ lebXwcpPl/0B5BXrV/p9zf6+Gtg/Spg2lJc5DQyzPXNnDOJpYMmH/GnrwF+Ps8w/T1/K vvX7PkimvAV8vpvKFeSRzOvq6cEj6wg5UcH/s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; b=QQhxLJAabZkkUrWrWJmJQGGvM5zF/owFAVmJKjosij/XpCNvcv+lvgJrO6llQVCzQA CNcvBgftOJ2DMiFXqHtkOpZxxbeExvaGYuJo/gynPKqGsjYbxAbWuIXPsa878GxRG3CK FvqR9F1PrCYnjt3GEoIeWA32KQgGBOCt/VNm4= MIME-Version: 1.0 Sender: timur.friedman@gmail.com Received: by 10.103.213.19 with SMTP id p19mr4121756muq.9.1240946212063; Tue, 28 Apr 2009 12:16:52 -0700 (PDT) In-Reply-To: <5ef5d7280904222031te6b6570r2760491dafee65f@mail.gmail.com> References: <5ef5d7280904222031te6b6570r2760491dafee65f@mail.gmail.com> From: Timur Friedman Date: Tue, 28 Apr 2009 12:16:32 -0700 X-Google-Sender-Auth: a077045a92194908 Message-ID: <5ef5d7280904281216h68cda0c7p9039db4ffda7209f@mail.gmail.com> To: avt@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [AVT] misleading RFC 3611 statement on RTCP packet stacking X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 19:15:32 -0000 To follow up on our proposal to file an RFC Errata report, here, for more direct comparison, is the RFC 3611 text immediately followed by our suggestion for how it should be read: > "XR packets supplement the existing RTCP packets, and may be stacked with > other RTCP packets to form compound RTCP packets [9, Section 6]." > =93XR packets supplement the existing RTCP packets, and stack with other = RTCP > packets to form compound RTCP packets, as described in Sec. 6 of RFC 3550 > [9].=94 Timur On Wed, Apr 22, 2009 at 8:31 PM, Timur Friedman wr= ote: > Some people are reading RFC 3611 as overriding RFC 3550 on RTCP packet > stacking. > > This is what Sec. 1.1 of RFC 3611 says: > > "XR packets supplement the existing RTCP packets, and may be stacked with > other RTCP packets to form compound RTCP packets [9, Section 6]." > > Reference 9 is RFC 3550, which says: > > "all RTCP packets MUST be sent in a compound packet of at least two > individual packets" > > That is, RFC 3550 says that RTCP packets MUST be stacked into a compound > packet, and some people are reading RFC 3611 as weakening that mandate to > say only that RTCP packets MAY be stacked into a compound packet (but als= o > MAY NOT, at least in the case of the XR packet). > > As one of the authors of RFC 3611, I can say that it was not my intention= to > override RFC 3550. Nor was it the intention of the two of my eight > co-authors who I have discussed this with. Rather, the purpose of this > sentence was to remind the reader that XR packets, like any RTCP packets, > are designed to be stacked, and to helpfully point the reader to the RFC > 3550 section that deals with RTCP packet stacking for further details. > > To the best of my recollection, no discussion in AVT leading up to approv= al > of RFC 3611 indicates that any group participants at the time believed th= at > RFC 3611 would override RFC 3550 on RTCP packet stacking. > > Still, I understand how people are reading RFC 3611 in this way. It does = say > "may be stacked", and though "may" is not capitalized, it is nonetheless = an > RFC 2119 keyword, meaning that the item is truly optional. > > Co-authors Nick Duffield, Ramon Caceres, and myself would like to open > discussion on how to address this situation. We start by suggesting that = we > file an RFC Errata report, indicating that the sentence should read inste= ad: > > =93XR packets supplement the existing RTCP packets, and stack with other = RTCP > packets to form compound RTCP packets, as described in Sec. 6 of RFC 3550 > [9].=94 > > By dropping the "may", we drop any hint that this RFC overrides the RFC 3= 550 > stacking mandate. And by adding "as described in Sec. 6 of RFC 3550" we m= ake > clear the informational nature of this sentence. > > Timur Friedman > > From fluffy@cisco.com Tue Apr 28 13:40:31 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 391053A6CFD for ; Tue, 28 Apr 2009 13:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.593 X-Spam-Level: X-Spam-Status: No, score=-106.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wY+bQP1V-Tcf for ; Tue, 28 Apr 2009 13:40:30 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 611DC3A67EA for ; Tue, 28 Apr 2009 13:40:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,262,1238976000"; d="scan'208";a="157444162" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 28 Apr 2009 20:41:52 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3SKfp8R018607 for ; Tue, 28 Apr 2009 13:41:51 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3SKfoDE018278 for ; Tue, 28 Apr 2009 20:41:51 GMT Message-Id: <85F58CA9-0A5F-441D-8BA1-01CC00DCBFF9@cisco.com> From: Cullen Jennings To: IETF AVT WG Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 28 Apr 2009 14:41:50 -0600 References: <20090428140524.3F32E28C10C@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1375; t=1240951311; x=1241815311; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Fwd=3A=20Last=20Call=3A=20draft-levine-rfb=20(T he=20Remote=20Framebuffer=20Protocol)=20=20to=20Informationa l=20RFC=20 |Sender:=20; bh=AsDfo2OLcZ4Wg5H3D8q6312a925KFUGjuXGVf/YYaCU=; b=EeNX/O+kExA6EIOTr8U0wibd8F8FPGo6qtQMMK2XKIm1QErXyIp2TbeY6L Ay2Ts4Bmqy0g4NEt+qqsGCjfYvA2jgz8+NTrDVbL6LNcEuQwdOR0DAnJ0VFg kxVskk+Sx3; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [AVT] Fwd: Last Call: draft-levine-rfb (The Remote Framebuffer Protocol) to Informational RFC X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 20:40:31 -0000 Just as FYI, this draft is in IETF LC. It specifies the protocol used by VNC to share for desktop sharing. Begin forwarded message: > From: The IESG > Date: April 28, 2009 8:05:24 AM MDT (CA) > To: IETF-Announce > Subject: Last Call: draft-levine-rfb (The Remote Framebuffer > Protocol) to Informational RFC > Reply-To: ietf@ietf.org > > The IESG has received a request from an individual submitter to > consider > the following document: > > - 'The Remote Framebuffer Protocol ' > as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to > the > ietf@ietf.org mailing lists by 2009-05-26. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-levine-rfb-01.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17997&rfc_flag=0 > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From csp@csperkins.org Wed Apr 29 10:41:11 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DC1D3A716B for ; Wed, 29 Apr 2009 10:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=-1.475, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVNoGB4Rqyx1 for ; Wed, 29 Apr 2009 10:41:10 -0700 (PDT) Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by core3.amsl.com (Postfix) with ESMTP id BD8A128C2D5 for ; Wed, 29 Apr 2009 10:40:53 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=mangole.lan) by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1LzDnT-000036-hp; Wed, 29 Apr 2009 17:42:15 +0000 Message-Id: <84F83FF0-B9B8-4FA6-A9F1-364782D91E8D@csperkins.org> From: Colin Perkins To: Roni Even In-Reply-To: <49f4acd2.0c11660a.6549.ffffb32b@mx.google.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 29 Apr 2009 17:33:51 +0100 References: <49f4acd2.0c11660a.6549.ffffb32b@mx.google.com> X-Mailer: Apple Mail (2.930.3) Cc: avt@ietf.org Subject: Re: [AVT] SDP example in draft-versteeg-avt-rapid-synchronization-for-rtp-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 17:41:11 -0000 Roni, It's been a while since I read SDP and its various extensions in great detail, but as far as I can tell, this SDP does provide sufficient information to join the session, on the assumption that symmetric RTP/ RTCP ports can be used. Colin On 26 Apr 2009, at 19:48, Roni Even wrote: > I am looking for more feedback on the following topic (not by Roni > or Ali). > The example in the draft is coming from a distribution source using > for example SAP (multicast distribution). > There are three entities in the communication. The multicast > distribution source, the unicast retransmission which also serves as > a feedback target and a client that wants to receive the multicast > stream and will ask for unicast resynchronization or retransmission. > > This SDP is coming from the distribution source and according to the > authors specify the multicast address, the unicast transport address > for the RTCP receiver reports for the multicast (SSM), the uincast > transport address on the feedback target/retransmission server that > will be used by the clients to ask for retransmission streams using > RTCP-FB and the transport address on the client that will be used by > the feedback target to send the unicast RTP stream to. > > Does this SDP look like it supplies all this information enabling > interoperable applications. > > v=0 > o=ali 1122334455 1122334466 IN IP4 rams.example.com > s=Rapid Acquisition Examples > t=0 0 > a=group:FID 1 2 > a=group:FID 3 4 > a=rtcp-unicast:rsi > m=video 40000 RTP/AVPF 96 > i=Primary Multicast Stream #1 > c=IN IP4 224.1.1.1/255 > a=source-filter: incl IN IP4 224.1.1.1 192.0.2.2 > a=recvonly > a=rtpmap:96 MP2T/90000 > a=rtcp:40001 IN IP4 192.0.2.1 > a=rtcp-fb:96 nack > a=mid:1 > m=video 40002 RTP/AVPF 97 > i=Unicast Retransmission Stream #1 (Ret. Support Only) > c=IN IP4 192.0.2.1 > a=recvonly > a=rtpmap:97 rtx/90000 > a=rtcp:40003 > a=fmtp:97 apt=96 > a=fmtp:97 rtx-time=3000 > a=mid:2 > > > Thanks > Roni Even -- Colin Perkins http://csperkins.org/ From csp@csperkins.org Wed Apr 29 10:44:26 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 404EC28C159; Wed, 29 Apr 2009 10:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=-0.717, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyZ1W4H9XuUr; Wed, 29 Apr 2009 10:44:24 -0700 (PDT) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by core3.amsl.com (Postfix) with ESMTP id 318C13A7187; Wed, 29 Apr 2009 10:44:24 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=mangole.lan) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1LzDqr-0005K4-kQ; Wed, 29 Apr 2009 17:45:46 +0000 Message-Id: From: Colin Perkins To: Roni Even In-Reply-To: <49f61dae.0c07560a.64b2.ffffb27d@mx.google.com> Content-Type: multipart/alternative; boundary=Apple-Mail-6-726930915 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 29 Apr 2009 18:45:35 +0100 References: <238382595265324EA50F6134BB42DCAF03B18B96@FRVELSMBS22.ad2.ad.alcatel.com> <49f61dae.0c07560a.64b2.ffffb27d@mx.google.com> X-Mailer: Apple Mail (2.930.3) Cc: 'VAN CAENEGEM Tom' , avt@ietf.org, mmusic@ietf.org Subject: Re: [AVT] Multiple Feedback Targets in " http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18" X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 17:44:26 -0000 --Apple-Mail-6-726930915 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Roni, The signalling aspects could certainly go to MMUSIC, and are probably =20= not too difficult to address. The proposal also involves some =20 potentially significant changes to the RTCP architecture, which should =20= be considered in AVT (although hopefully as additional documents =20 rather than being folded into the - already long overdue - rtcpssm =20 draft). Cheers, Colin On 27 Apr 2009, at 22:01, Roni Even wrote: > Tom, > I think this question should go to mmusic. What you are trying to do =20= > here is to define semantics for the content of a RTCP flow pointing =20= > to different devices. The m-line or the RTCP line in SDP does not =20 > address what is the content of the stream that will go in the RTP =20 > session. RFC 4796 addresses the media content issue but you are =20 > looking for something similar to the RTCP attribute. This may =20 > require a new parameter to the rtcp attribute. > You will also need to look at backward interoperability where the =20 > receiver will not understand this semantics and may change the RTCP =20= > message to the wrong address. > > The example for the content attribute was to specify to video m-=20 > lines one with screen capture as a video stream and the other from a =20= > camera. SDP does not define the behavior of the receiver if it =20 > receives two m-lines of the same media type and can only support =20 > one. It is not clear which one he will chose (first or second). The =20= > work on capability negotiation tries to address this issue. > > Roni Even > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf =20 > Of VAN CAENEGEM Tom > Sent: Friday, April 24, 2009 1:36 PM > To: avt@ietf.org > Subject: [AVT] Multiple Feedback Targets in " = http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18=20 > " > > > Hi, > > I have two questions/comments mostly regarding the RTCP-SSM draft = (http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18=20 > ). The background of my questions is the use case of "broadcast =20 > channels" in an IPTV context, where the channels are distributed =20 > over IP multicast (SSM). In this context, the concept of feedback =20 > target(s) is obviously very useful, and actually necessary given =20 > today's restrictions with multicast in upstream in the "WAN". > > For the IPTV use case, it also makes sense to have multiple feedback =20= > targets, each responsible for a subset of RTP receivers, because of =20= > the large number of RTP receivers involved (100.000s is possible). =20 > The way to signal this by means of SDP is that each local subset of =20= > RTP receivers sees a different IP address in the "a=3Drtcp: =20 > "portnumber" IN IP4 "IP address" line. So, multiple "localised" =20 > FT is covered by the draft IMO. > > However, in that case, the maximum bandwidth that can be used for =20 > RTCP reporting by RTP receivers only needs to be determined by the =20 > size of the local group of RTP receivers (sending RTCP to the same =20 > localised Feedback Target), especially in the summary FB model. But =20= > in my interpretation of the architecture, the actual RTCP bandwith =20 > limit information can only be retrieved by the RTP receivers from =20 > the information sent by the distribution source in the ssm session. =20= > Either by refected RTCP reports from RTP receivers (not a feasible =20 > solution for the given use case) or from a RSI message -in the =20 > summary FB model- indicating the session size or explicitly the RTCP =20= > reporting bandwidth limit. The fact is that this information is sent =20= > to ALL RTP receivers, which may be reporting to different Feedback =20 > targets where each Feedback target is collecting RTCP messages from =20= > a different number of RTP receivers, and hence may have different =20 > "requirements" for total RTCP reporting bandwidth limit. My =20 > question is whether local Feedback targets have been considered with =20= > respect to this issue? > > My second question again has to do with multiple feedback targets =20 > for the same use case. > > In the IPTV use case for rtcpssm, Feedback Targets can also be used =20= > as retransmission sources (RFC 4588) and in = http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rt= p-03=20 > , the feedback target architecture is used to allow fast acquisition =20= > of SSM RTP sessions. The draft proposes that a "burst source" is co-=20= > located with the FT which transmits unicast data (starting with a =20 > random access point of the video channel) from a cache that holds =20 > the most recent data distributed over the RTP SSM. It does transmit =20= > the RTP packets at an accelerated speed, allowing the RTP receiver =20 > to join the SSM after some time. > > The idea I would like to bring forward is to allow separate Feedback =20= > Targets for the same RTP receiver (population): one Feedback target =20= > acts as RTP retransmission server = (seehttp://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-fo= r-rtp-03)=20 > and collects RTCP FB messages, while the other Feedback Target is =20 > solely "responsible" for the non RTCP-FB messages, such as RTCP XR =20 > messages. I realise this idea is not necessarily linked with the =20 > rtcp-ssm draft, but IMO only for a massive scale application that =20 > makes use of RTP and leverages rtcp ssm such a separation is =20 > justified. The possibility for separation of the monitoring service =96=20= > associated with a server function basically responsible for =20 > collecting RTCP receiver reports for the purpose of monitoring- and =20= > the retransmission service requiring a server function that is =20 > responsible for processing and responding to RTCP FB messages, is =20 > driven from the point of view of server function optimisation =20 > (different requirements on the server platform). > > In terms of signaling two Feedback Targets, we could make use of the =20= > following lines: > > a=3Drtcp:40001 IN IP4 192.0.2.1 (This is for retransmission) > a=3Drtcp-fb:96 nack > a=3Drtcp:40001 IN IP4 192.0.2.2 (This is for XR collection) > > > However, that is probably quite ambiguous..? > Furthermore I also realise such a solution introduces other =20 > questions than just signaling syntax including the fact that we may =20= > need guiding rules on how RTCP reports are issued by the RTP =20 > receiver with two RTCP targets in place, as in the example above. =20 > The new RFC 5506 is certainly helpful here, but this is probably not =20= > sufficient. > > Comments appreciated on this idea. > > Kind regards, > Tom Van Caenegem > > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ --Apple-Mail-6-726930915 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Roni,

The = signalling aspects could certainly go to MMUSIC, and are probably not = too difficult to address. The proposal also involves some potentially = significant changes to the RTCP architecture, which should be considered = in AVT (although hopefully as additional documents rather than being = folded into the - already long overdue - rtcpssm draft). 

Cheers,
Colin



On = 27 Apr 2009, at 22:01, Roni Even wrote:
I = think this question should go to mmusic. What you are trying to do here = is to define semantics for the content of a RTCP flow pointing to = different devices. The m-line or the RTCP line in SDP does not address = what is the content of the stream that will go in the RTP session. =  RFC 4796 addresses the media content issue but you are looking for = something similar to the RTCP attribute. This may require a new = parameter to the rtcp attribute.
You will also need to look at = backward interoperability where the receiver will not understand this = semantics and may change the RTCP message to the wrong = address.
 
The example for the content = attribute was to specify to video m-lines one with screen capture as a = video stream and the other from a camera. SDP does not define the = behavior of the receiver if it receives two m-lines of the same media = type and can only support one. It is not clear which one he will chose = (first or second). The work on capability negotiation tries to address = this issue.
 
Roni = Even
From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of VAN CAENEGEM Tom
Sent: Friday, April 24, 2009 1:36 = PM
To: avt@ietf.org
Subject: [AVT] Multiple Feedback = Targets in " 
 

). The = background of my questions is the use case of "broadcast channels" in an = IPTV context, where the channels are distributed over IP multicast = (SSM). In this context, the concept of feedback target(s) is obviously = very useful, and actually necessary given today's restrictions with = multicast in upstream in the "WAN".

For the IPTV use case, it also = makes sense to have multiple feedback targets, each responsible for a = subset of RTP receivers, because of the large number of RTP receivers = involved (100.000s is possible). The way to signal this by means of SDP = is that each local subset of RTP receivers sees a different IP address = in the "a=3Drtcp: "portnumber" IN IP4 "IP = address"  line.  = So, multiple "localised" FT  is covered by the draft = IMO.

My second question again has to do = with multiple feedback targets for the same use = case.

 , the feedback target architecture is used to allow fast = acquisition of SSM RTP sessions. The draft proposes that  a "burst = source" is co-located with the FT which transmits unicast data (starting = with a random access point of the video channel) from a cache that holds = the most recent data distributed over the RTP SSM. It does transmit the = RTP packets at an accelerated speed, allowing the RTP receiver to join = the SSM after some time.

The idea I would like to bring forward = is to allow separate Feedback Targets  for the same RTP receiver = (population): one Feedback target acts as RTP retransmission server = (see) and collects RTCP FB messages, while the other Feedback = Target is solely "responsible" for the non RTCP-FB messages, such as = RTCP XR messages. I realise this idea is not necessarily linked = with  the rtcp-ssm draft, but IMO only for a massive scale = application that makes use of RTP and leverages rtcp ssm such a = separation is justified. The possibility for separation of the = monitoring service =96associated with a server = function basically responsible for collecting RTCP receiver reports for = the purpose of monitoring- and the retransmission service requiring a = server function that is responsible for processing and responding to = RTCP FB messages, is driven from the point of view of server function = optimisation (different requirements on the server = platform).

In terms of signaling two Feedback = Targets, we could make use of the following = lines:

a=3Drtcp:40001 = IN IP4 192.0.2.1 (This is for retransmission) 
a=3Drtcp-fb:96 nack 
a=3Drtcp:40001 IN IP4 192.0.2.2 (This is for XR = collection)

 

However, that is probably quite = ambiguous..? 
Furthermore I also realise such a solution = introduces other questions than just signaling syntax including the fact = that we may need guiding rules on how RTCP reports are issued by the RTP = receiver with two RTCP targets in place, as in the example above. The = new RFC 5506 is certainly helpful here, but this is probably not = sufficient.

Comments appreciated on this = idea.

 
Tom Van Caenegem

 

Audio/Video Transport Working = Group
avt@ietf.org




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



= --Apple-Mail-6-726930915-- From ron.even.tlv@gmail.com Wed Apr 29 11:59:06 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60FBD3A67ED for ; Wed, 29 Apr 2009 11:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.673 X-Spam-Level: X-Spam-Status: No, score=-0.673 tagged_above=-999 required=5 tests=[AWL=-1.674, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A89vhZpbBZwn for ; Wed, 29 Apr 2009 11:59:05 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id D5FE73A67EC for ; Wed, 29 Apr 2009 11:59:04 -0700 (PDT) Received: by fxm2 with SMTP id 2so1375504fxm.37 for ; Wed, 29 Apr 2009 12:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=uPHMzhgcmJF1bFcYz+eJnbUOnaQGWm0WBzQW4tA7otc=; b=Rx/y+omOMOmTCyByJNYFUqNxQV/tp1/9pLpMlXyjEjEJwQzj+kHEFDczxIHh32Ztrk Vz9XVGB8fXeFMpIE0wni0XG3KLvHfamI+T9xI9xlOodWByLV0SbhHqViCG3ikSEx4qpN 8mNKWtpySrg2BljuEJmn65bmOxFdEmVF9bt/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=VGfiHnfgOuGqPl8QKFCkbUrVUBVre99yZNfDLAcvAfizNj4g2VF6IZk3z5BiGh2Vj4 +94DEJ0ZiwCtjH6OKA5U2PTDq9nZZ2XkWljxBzmIe8kZG8jjpEMFTXQWo1aSjrvVVPbw VfBEtJBNdWI3QRLofTv1oAVZrh6alhyEoilaw= Received: by 10.103.105.1 with SMTP id h1mr446645mum.13.1241031626405; Wed, 29 Apr 2009 12:00:26 -0700 (PDT) Received: from windows8d787f9 (bzq-79-176-57-251.red.bezeqint.net [79.176.57.251]) by mx.google.com with ESMTPS id y37sm3387356mug.49.2009.04.29.12.00.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 29 Apr 2009 12:00:25 -0700 (PDT) From: "Roni Even" To: "'Colin Perkins'" References: <49f4acd2.0c11660a.6549.ffffb32b@mx.google.com> <84F83FF0-B9B8-4FA6-A9F1-364782D91E8D@csperkins.org> In-Reply-To: <84F83FF0-B9B8-4FA6-A9F1-364782D91E8D@csperkins.org> Date: Wed, 29 Apr 2009 21:58:19 +0300 Message-ID: <49f8a3c9.25e2660a.5cb1.fffff25e@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnI8dYD0Ywfs0KwQ2SyoU8YGpXGswACcIyA Content-Language: en-us Cc: avt@ietf.org Subject: Re: [AVT] SDP example in draft-versteeg-avt-rapid-synchronization-for-rtp-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 18:59:06 -0000 Colin, I agree that the assumption is that the client can use this ports but this is why I suggest that the client should be able to override the offer if it cannot use these ports. One example is when the client tries to join two different multicast streams and both offer the same ports. My other concern is that the client IP address is not known from this SDP, so there is another assumption that the IP used in the RTCP RAMS=R from the client is the IP address for the unicast burst. Roni -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org] Sent: Wednesday, April 29, 2009 7:34 PM To: Roni Even Cc: avt@ietf.org Subject: Re: [AVT] SDP example in draft-versteeg-avt-rapid-synchronization-for-rtp-03 Roni, It's been a while since I read SDP and its various extensions in great detail, but as far as I can tell, this SDP does provide sufficient information to join the session, on the assumption that symmetric RTP/ RTCP ports can be used. Colin On 26 Apr 2009, at 19:48, Roni Even wrote: > I am looking for more feedback on the following topic (not by Roni > or Ali). > The example in the draft is coming from a distribution source using > for example SAP (multicast distribution). > There are three entities in the communication. The multicast > distribution source, the unicast retransmission which also serves as > a feedback target and a client that wants to receive the multicast > stream and will ask for unicast resynchronization or retransmission. > > This SDP is coming from the distribution source and according to the > authors specify the multicast address, the unicast transport address > for the RTCP receiver reports for the multicast (SSM), the uincast > transport address on the feedback target/retransmission server that > will be used by the clients to ask for retransmission streams using > RTCP-FB and the transport address on the client that will be used by > the feedback target to send the unicast RTP stream to. > > Does this SDP look like it supplies all this information enabling > interoperable applications. > > v=0 > o=ali 1122334455 1122334466 IN IP4 rams.example.com > s=Rapid Acquisition Examples > t=0 0 > a=group:FID 1 2 > a=group:FID 3 4 > a=rtcp-unicast:rsi > m=video 40000 RTP/AVPF 96 > i=Primary Multicast Stream #1 > c=IN IP4 224.1.1.1/255 > a=source-filter: incl IN IP4 224.1.1.1 192.0.2.2 > a=recvonly > a=rtpmap:96 MP2T/90000 > a=rtcp:40001 IN IP4 192.0.2.1 > a=rtcp-fb:96 nack > a=mid:1 > m=video 40002 RTP/AVPF 97 > i=Unicast Retransmission Stream #1 (Ret. Support Only) > c=IN IP4 192.0.2.1 > a=recvonly > a=rtpmap:97 rtx/90000 > a=rtcp:40003 > a=fmtp:97 apt=96 > a=fmtp:97 rtx-time=3000 > a=mid:2 > > > Thanks > Roni Even -- Colin Perkins http://csperkins.org/ From abegen@cisco.com Wed Apr 29 14:59:20 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1118D3A6E42; Wed, 29 Apr 2009 14:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.356 X-Spam-Level: X-Spam-Status: No, score=-6.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6+6u90DyxvT; Wed, 29 Apr 2009 14:59:19 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 184523A6DFD; Wed, 29 Apr 2009 14:59:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,268,1238976000"; d="scan'208";a="157792158" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 29 Apr 2009 22:00:38 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3TM0cm8023378; Wed, 29 Apr 2009 15:00:38 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3TLxpSK028029; Wed, 29 Apr 2009 22:00:38 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 15:00:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Wed, 29 Apr 2009 15:00:16 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5409348DA0@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 Thread-Index: AcnJFZBSN2BsQsK8Rtu0PIlBx+ZGHQAABYCg From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 29 Apr 2009 22:00:19.0500 (UTC) FILETIME=[E2E626C0:01C9C915] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2246; t=1241042438; x=1241906438; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20FW=3A=20New=20Version=20Notification=20for=20=2 0=20=20=20=20=20=20=20=20draft-ietf-fecframe-interleaved-fec -scheme-04=20 |Sender:=20; bh=ubUrvvjORw5256T5Rfe7C93jCZfjUgRJZt6jBIBfFto=; b=KwvW3Y3nvLPevec+KQhCL8F7h7VoHc9tc0G0rWnbT+0s2TLDD9xTBsuWEt 7921xWgW5o2OOoo0o+KEPGR8WYf54V/OLAYgAwyA4UBcEXQBBCXOx+Qg1VaF C+KslyVoDQ; Authentication-Results: sj-dkim-3; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: avt@ietf.org Subject: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 21:59:20 -0000 VGhpcyB2ZXJzaW9uIGFkZHJlc3NlcyB0aGUgY29tbWVudHMgcmVjZWl2ZWQgZnJvbSBmZWNmcmFt ZSBhbmQgYXZ0IHNvIGZhci4gDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUtMDQudHh0DQoNCg0KRmVj ZnJhbWUgY2hhaXJzLA0KDQpDb3VsZCB3ZSBwcm9jZWVkIGFuZCBmaW5hbGl6ZSBXR0xDPw0KDQot YWNiZWdlbg0KIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSUVURiBJLUQg U3VibWlzc2lvbiBUb29sIFttYWlsdG86aWRzdWJtaXNzaW9uQGlldGYub3JnXSANClNlbnQ6IFdl ZG5lc2RheSwgQXByaWwgMjksIDIwMDkgMjo1NiBQTQ0KVG86IEFsaSBDLiBCZWdlbiAoYWJlZ2Vu KQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWZlY2Zy YW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUtMDQgDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LWlldGYtZmVjZnJhbWUtaW50ZXJsZWF2ZWQtZmVjLXNjaGVtZS0wNC50eHQgaGFzIGJl ZW4gc3VjY2Vzc2Z1bHkgc3VibWl0dGVkIGJ5IEFsaSBCZWdlbiBhbmQgcG9zdGVkIHRvIHRoZSBJ RVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtaWV0Zi1mZWNmcmFtZS1pbnRlcmxl YXZlZC1mZWMtc2NoZW1lDQpSZXZpc2lvbjoJIDA0DQpUaXRsZToJCSBSVFAgUGF5bG9hZCBGb3Jt YXQgZm9yIDEtRCBJbnRlcmxlYXZlZCBQYXJpdHkgRkVDDQpDcmVhdGlvbl9kYXRlOgkgMjAwOS0w NC0yOQ0KV0cgSUQ6CQkgZmVjZnJhbWUNCk51bWJlcl9vZl9wYWdlczogMzENCg0KQWJzdHJhY3Q6 DQpUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgUlRQIHBheWxvYWQgZm9ybWF0IGZvciB0aGUg Rm9yd2FyZCBFcnJvcg0KQ29ycmVjdGlvbiAoRkVDKSB0aGF0IGlzIGdlbmVyYXRlZCBieSB0aGUg MS1EIGludGVybGVhdmVkIHBhcml0eSBjb2RlDQpmcm9tIGEgc291cmNlIG1lZGlhIGVuY2Fwc3Vs YXRlZCBpbiBSVFAuICBUaGUgMS1EIGludGVybGVhdmVkIHBhcml0eQ0KY29kZSBpcyBhIHN5c3Rl bWF0aWMgY29kZSwgd2hlcmUgYSBudW1iZXIgb2YgcmVwYWlyIHN5bWJvbHMgYXJlDQpnZW5lcmF0 ZWQgZnJvbSBhIHNldCBvZiBzb3VyY2Ugc3ltYm9scyBhbmQgc2VudCBpbiBhIHJlcGFpciBmbG93 DQpzZXBhcmF0ZSBmcm9tIHRoZSBzb3VyY2UgZmxvdyB0aGF0IGNhcnJpZXMgdGhlIHNvdXJjZSBz eW1ib2xzLiAgVGhlDQoxLUQgaW50ZXJsZWF2ZWQgcGFyaXR5IGNvZGUgb2ZmZXJzIGEgZ29vZCBw cm90ZWN0aW9uIGFnYWluc3QgYnVyc3R5DQpwYWNrZXQgbG9zc2VzIGF0IGEgY29zdCBvZiBkZWNl bnQgY29tcGxleGl0eS4gIFRoZSBuZXcgcGF5bG9hZCBmb3JtYXQNCmRlZmluZWQgaW4gdGhpcyBk b2N1bWVudCBpcyB1c2VkICh3aXRoIHNvbWUgZXhjZXB0aW9ucykgYXMgYSBwYXJ0IG9mDQp0aGUg RFZCIEFwcGxpY2F0aW9uLWxheWVyIEZFQyBzcGVjaWZpY2F0aW9uLg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0Lg0KDQoNCg== From vincent.roca@inrialpes.fr Thu Apr 30 03:57:15 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E606C3A6ACF; Thu, 30 Apr 2009 03:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.171 X-Spam-Level: X-Spam-Status: No, score=-6.171 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tAaEXQQZ7ir; Thu, 30 Apr 2009 03:57:15 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id 702CE3A68CB; Thu, 30 Apr 2009 03:57:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,272,1238968800"; d="scan'208";a="25420782" Received: from ornon.inrialpes.fr (HELO [194.199.24.115]) ([194.199.24.115]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2009 12:58:35 +0200 Message-ID: <49F9845B.1090704@inrialpes.fr> Date: Thu, 30 Apr 2009 12:58:35 +0200 From: Vincent Roca User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <04CAD96D4C5A3D48B1919248A8FE0D5409348DA0@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5409348DA0@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [AVT] [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 10:57:16 -0000 Hello Ali, I'm not in favor of finalizing the WGLC for this document. IMHO we must, first of all, finalize the framework document itself. For instance, the terminology used by the interleaved-fec-scheme I-D (section 3.1.) is not in line with the terminology used by the fecframe-framework-03 I-D (Section 2): "Source Flow" vs. "Source data flow" "Repair Flow" vs. "Repair data flow" "Source Symbol" vs. nothing "Repair Symbol" vs. nothing "Source Packet" vs. nothing "Repair Packet" vs. nothing And as I said before, IMHO the terminology proposed in the framework I-D should be discussed too. So let's do things in the right order, especially as the framework WGLC finishes soon. Additionally, I may have some comments for the interleaved-fec-scheme-04 I-D. Since I missed the WGLC deadline, you have the right to blame me ;-) and I apologize in advance. Regards, Vincent Ali C. Begen (abegen) wrote: > This version addresses the comments received from fecframe and avt so far. > http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interleaved-fec-scheme-04.txt > > > Fecframe chairs, > > Could we proceed and finalize WGLC? > > -acbegen > > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Wednesday, April 29, 2009 2:56 PM > To: Ali C. Begen (abegen) > Subject: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 > > > A new version of I-D, draft-ietf-fecframe-interleaved-fec-scheme-04.txt has been successfuly submitted by Ali Begen and posted to the IETF repository. > > Filename: draft-ietf-fecframe-interleaved-fec-scheme > Revision: 04 > Title: RTP Payload Format for 1-D Interleaved Parity FEC > Creation_date: 2009-04-29 > WG ID: fecframe > Number_of_pages: 31 > > Abstract: > This document defines a new RTP payload format for the Forward Error > Correction (FEC) that is generated by the 1-D interleaved parity code > from a source media encapsulated in RTP. The 1-D interleaved parity > code is a systematic code, where a number of repair symbols are > generated from a set of source symbols and sent in a repair flow > separate from the source flow that carries the source symbols. The > 1-D interleaved parity code offers a good protection against bursty > packet losses at a cost of decent complexity. The new payload format > defined in this document is used (with some exceptions) as a part of > the DVB Application-layer FEC specification. > > > > The IETF Secretariat. > > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From csp@csperkins.org Thu Apr 30 04:39:24 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54E663A6A5F for ; Thu, 30 Apr 2009 04:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=-1.933, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHkc7Q+OtD8x for ; Thu, 30 Apr 2009 04:39:21 -0700 (PDT) Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by core3.amsl.com (Postfix) with ESMTP id B383E28C0F7 for ; Thu, 30 Apr 2009 04:39:21 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1LzUdA-0005bV-n6; Thu, 30 Apr 2009 11:40:44 +0000 Message-Id: <8AEFABDC-708C-42B6-A596-DC3C6F07E238@csperkins.org> From: Colin Perkins To: Roni Even In-Reply-To: <49f8a3c9.25e2660a.5cb1.fffff25e@mx.google.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 30 Apr 2009 12:40:42 +0100 References: <49f4acd2.0c11660a.6549.ffffb32b@mx.google.com> <84F83FF0-B9B8-4FA6-A9F1-364782D91E8D@csperkins.org> <49f8a3c9.25e2660a.5cb1.fffff25e@mx.google.com> X-Mailer: Apple Mail (2.930.3) Cc: avt@ietf.org Subject: Re: [AVT] SDP example in draft-versteeg-avt-rapid-synchronization-for-rtp-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 11:39:24 -0000 Roni, On 29 Apr 2009, at 19:58, Roni Even wrote: > I agree that the assumption is that the client can use this ports > but this > is why I suggest that the client should be able to override the > offer if it > cannot use these ports. One example is when the client tries to join > two > different multicast streams and both offer the same ports. That's always been an issue with declarative SDP for multicast sessions, I'm not sure there's anything special about this SDP. > My other concern is that the client IP address is not known from > this SDP, > so there is another assumption that the IP used in the RTCP RAMS=R > from the > client is the IP address for the unicast burst. Sure - this gets into NAT traversal issues, of course. Colin > Roni > > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Wednesday, April 29, 2009 7:34 PM > To: Roni Even > Cc: avt@ietf.org > Subject: Re: [AVT] SDP example in > draft-versteeg-avt-rapid-synchronization-for-rtp-03 > > Roni, > > It's been a while since I read SDP and its various extensions in great > detail, but as far as I can tell, this SDP does provide sufficient > information to join the session, on the assumption that symmetric RTP/ > RTCP ports can be used. > > Colin > > > > On 26 Apr 2009, at 19:48, Roni Even wrote: >> I am looking for more feedback on the following topic (not by Roni >> or Ali). >> The example in the draft is coming from a distribution source using >> for example SAP (multicast distribution). >> There are three entities in the communication. The multicast >> distribution source, the unicast retransmission which also serves as >> a feedback target and a client that wants to receive the multicast >> stream and will ask for unicast resynchronization or retransmission. >> >> This SDP is coming from the distribution source and according to the >> authors specify the multicast address, the unicast transport address >> for the RTCP receiver reports for the multicast (SSM), the uincast >> transport address on the feedback target/retransmission server that >> will be used by the clients to ask for retransmission streams using >> RTCP-FB and the transport address on the client that will be used by >> the feedback target to send the unicast RTP stream to. >> >> Does this SDP look like it supplies all this information enabling >> interoperable applications. >> >> v=0 >> o=ali 1122334455 1122334466 IN IP4 rams.example.com >> s=Rapid Acquisition Examples >> t=0 0 >> a=group:FID 1 2 >> a=group:FID 3 4 >> a=rtcp-unicast:rsi >> m=video 40000 RTP/AVPF 96 >> i=Primary Multicast Stream #1 >> c=IN IP4 224.1.1.1/255 >> a=source-filter: incl IN IP4 224.1.1.1 192.0.2.2 >> a=recvonly >> a=rtpmap:96 MP2T/90000 >> a=rtcp:40001 IN IP4 192.0.2.1 >> a=rtcp-fb:96 nack >> a=mid:1 >> m=video 40002 RTP/AVPF 97 >> i=Unicast Retransmission Stream #1 (Ret. Support Only) >> c=IN IP4 192.0.2.1 >> a=recvonly >> a=rtpmap:97 rtx/90000 >> a=rtcp:40003 >> a=fmtp:97 apt=96 >> a=fmtp:97 rtx-time=3000 >> a=mid:2 >> >> >> Thanks >> Roni Even > > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt -- Colin Perkins http://csperkins.org/ From ron.even.tlv@gmail.com Thu Apr 30 05:45:26 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8CA628C112 for ; Thu, 30 Apr 2009 05:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.29 X-Spam-Level: X-Spam-Status: No, score=-0.29 tagged_above=-999 required=5 tests=[AWL=-1.291, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZShTOBh9KHXM for ; Thu, 30 Apr 2009 05:45:25 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 2D6FE3A720B for ; Thu, 30 Apr 2009 05:45:25 -0700 (PDT) Received: by fxm2 with SMTP id 2so1789646fxm.37 for ; Thu, 30 Apr 2009 05:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=ry3dPSOim1zgXD0qe0ansTgKyFr/0NGZcqyfj+u0tFY=; b=XLgNruIKzWRuPRbJzmIbpFFyU+KsIaO2H0FcWjfWOODMoaRk4U/1S5BzVeN7hGlPUj +a9hCsqjKJNUxO5wnBKQOye0g0A23i3YHOVe9P1t+DmAAQnfq99cUWgzLBUFau7M/mko UkrXr9sqFh6/P3VUOHDxxwE6dRfGeuBrC9zu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=Vd7fVK0dFryqnp4fVssXwJpcHQixEWQUa2Ztq8TvOHHdmknSIeYqjgJPwMPCrTc4U7 hSToWm9CTUXh63hVCIBanXgGX4BVxjnBwkWyoimF/snJMEAyoVQVQpzaAWi0GQYX+wl6 GuPumgnDzexJvAfMZnYgjVi0yHKVLz9oj6pCw= Received: by 10.103.119.19 with SMTP id w19mr947813mum.80.1241095607315; Thu, 30 Apr 2009 05:46:47 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-57-219.red.bezeqint.net [79.177.57.219]) by mx.google.com with ESMTPS id 25sm1716462mul.59.2009.04.30.05.46.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Apr 2009 05:46:46 -0700 (PDT) From: "Roni Even" To: "'Colin Perkins'" References: <49f4acd2.0c11660a.6549.ffffb32b@mx.google.com> <84F83FF0-B9B8-4FA6-A9F1-364782D91E8D@csperkins.org> <49f8a3c9.25e2660a.5cb1.fffff25e@mx.google.com> <8AEFABDC-708C-42B6-A596-DC3C6F07E238@csperkins.org> In-Reply-To: <8AEFABDC-708C-42B6-A596-DC3C6F07E238@csperkins.org> Date: Thu, 30 Apr 2009 15:44:41 +0300 Message-ID: <49f99db6.190c660a.12b4.ffff9e55@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnJiH78YiDlC30fRnmkXPHMujrbrwAB09/w Content-Language: en-us Cc: avt@ietf.org Subject: Re: [AVT] SDP example in draft-versteeg-avt-rapid-synchronization-for-rtp-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 12:45:26 -0000 Colin, The special case here is also mentioned in RFC 4566 section 5.7 in the first bullet in the last sentence. "It is not expected that unicast addresses will be given in a session description that is communicated by a multicast announcement, though this is not prohibited." Roni -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org] Sent: Thursday, April 30, 2009 2:41 PM To: Roni Even Cc: avt@ietf.org Subject: Re: [AVT] SDP example in draft-versteeg-avt-rapid-synchronization-for-rtp-03 Roni, On 29 Apr 2009, at 19:58, Roni Even wrote: > I agree that the assumption is that the client can use this ports > but this > is why I suggest that the client should be able to override the > offer if it > cannot use these ports. One example is when the client tries to join > two > different multicast streams and both offer the same ports. That's always been an issue with declarative SDP for multicast sessions, I'm not sure there's anything special about this SDP. > My other concern is that the client IP address is not known from > this SDP, > so there is another assumption that the IP used in the RTCP RAMS=R > from the > client is the IP address for the unicast burst. Sure - this gets into NAT traversal issues, of course. Colin > Roni > > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Wednesday, April 29, 2009 7:34 PM > To: Roni Even > Cc: avt@ietf.org > Subject: Re: [AVT] SDP example in > draft-versteeg-avt-rapid-synchronization-for-rtp-03 > > Roni, > > It's been a while since I read SDP and its various extensions in great > detail, but as far as I can tell, this SDP does provide sufficient > information to join the session, on the assumption that symmetric RTP/ > RTCP ports can be used. > > Colin > > > > On 26 Apr 2009, at 19:48, Roni Even wrote: >> I am looking for more feedback on the following topic (not by Roni >> or Ali). >> The example in the draft is coming from a distribution source using >> for example SAP (multicast distribution). >> There are three entities in the communication. The multicast >> distribution source, the unicast retransmission which also serves as >> a feedback target and a client that wants to receive the multicast >> stream and will ask for unicast resynchronization or retransmission. >> >> This SDP is coming from the distribution source and according to the >> authors specify the multicast address, the unicast transport address >> for the RTCP receiver reports for the multicast (SSM), the uincast >> transport address on the feedback target/retransmission server that >> will be used by the clients to ask for retransmission streams using >> RTCP-FB and the transport address on the client that will be used by >> the feedback target to send the unicast RTP stream to. >> >> Does this SDP look like it supplies all this information enabling >> interoperable applications. >> >> v=0 >> o=ali 1122334455 1122334466 IN IP4 rams.example.com >> s=Rapid Acquisition Examples >> t=0 0 >> a=group:FID 1 2 >> a=group:FID 3 4 >> a=rtcp-unicast:rsi >> m=video 40000 RTP/AVPF 96 >> i=Primary Multicast Stream #1 >> c=IN IP4 224.1.1.1/255 >> a=source-filter: incl IN IP4 224.1.1.1 192.0.2.2 >> a=recvonly >> a=rtpmap:96 MP2T/90000 >> a=rtcp:40001 IN IP4 192.0.2.1 >> a=rtcp-fb:96 nack >> a=mid:1 >> m=video 40002 RTP/AVPF 97 >> i=Unicast Retransmission Stream #1 (Ret. Support Only) >> c=IN IP4 192.0.2.1 >> a=recvonly >> a=rtpmap:97 rtx/90000 >> a=rtcp:40003 >> a=fmtp:97 apt=96 >> a=fmtp:97 rtx-time=3000 >> a=mid:2 >> >> >> Thanks >> Roni Even > > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt -- Colin Perkins http://csperkins.org/ From abegen@cisco.com Thu Apr 30 05:52:17 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A3C73A6848; Thu, 30 Apr 2009 05:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMFWJTbpv46f; Thu, 30 Apr 2009 05:52:16 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 4252F3A6841; Thu, 30 Apr 2009 05:52:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,273,1238976000"; d="scan'208,217";a="157926833" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 30 Apr 2009 12:53:39 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3UCrdwC019392; Thu, 30 Apr 2009 05:53:39 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3UCrdRv003008; Thu, 30 Apr 2009 12:53:39 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 05:53:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C992.AE5F6E58" Date: Thu, 30 Apr 2009 05:53:38 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 Thread-Index: AcnJgq+DQP1j7cRATQa6PC9zcfp8gAAD/6re From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 30 Apr 2009 12:53:39.0251 (UTC) FILETIME=[AED71830:01C9C992] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12695; t=1241096019; x=1241960019; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20Re=3A=20[Fecframe]=20FW=3A=20New=20Version=20No tification=20for=09draft-ietf-fecframe-interleaved-fec-schem e-04 |Sender:=20; bh=I9OYEh3aDGm9iJVQYShMapXmuYpTSJlGqZ9numi8C0A=; b=tTJr6V/B3SEZU+hrYiVtDfS3eF+VAVpEirh98OzmwbBn3JP3YmWP89FBp+ g3MBVcSzMKv1m7OAMQxeL32hzCvN5L3r5MSc2tQxJ+hVpa7fMARy5DQCl5wv E7sY/jJWrf; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [AVT] [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 12:52:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C992.AE5F6E58 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgVmluY2VudA0KDQpUaGlzIGRyYWZ0IGlzIG5vdCBhbiBmZWMgc2NoZW1lIHNvIGl0IGlzIG5v dCByZWxhdGVkIHRvIGZlYyBmcmFtZXdvcmsuIEl0IGlzIGFuIHJ0cCBwYXlsb2FkIGZvcm1hdCBk cmFmdC4gVGhlIHdnbGMgaGFzIGJlZW4gcnVubmluZyBhbG1vc3QgYSBtb250aCBub3cuIElmIHlv dSBoYXZlIGNvbW1lbnRzIGluIHRoaXMgcGVyc3BlY3RpdmUsIHBscyBzdWJtaXQgdGhlbSBzb29u LiANCg0KDQoNCg0KLWFjYmVnZW4NCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJv bTogVmluY2VudCBSb2NhIDx2aW5jZW50LnJvY2FAaW5yaWFscGVzLmZyPg0KVG86IEFsaSBDLiBC ZWdlbiAoYWJlZ2VuKQ0KQ2M6IGZlY2ZyYW1lQGlldGYub3JnIDxmZWNmcmFtZUBpZXRmLm9yZz47 IGF2dEBpZXRmLm9yZyA8YXZ0QGlldGYub3JnPg0KU2VudDogVGh1IEFwciAzMCAwMzo1ODozNSAy MDA5DQpTdWJqZWN0OiBSZTogW0ZlY2ZyYW1lXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvcglkcmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUtMDQNCg0KSGVs bG8gQWxpLA0KDQpJJ20gbm90IGluIGZhdm9yIG9mIGZpbmFsaXppbmcgdGhlIFdHTEMgZm9yIHRo aXMgZG9jdW1lbnQuIElNSE8gd2UgbXVzdCwNCmZpcnN0IG9mIGFsbCwgZmluYWxpemUgdGhlIGZy YW1ld29yayBkb2N1bWVudCBpdHNlbGYuDQoNCkZvciBpbnN0YW5jZSwgdGhlIHRlcm1pbm9sb2d5 IHVzZWQgYnkgdGhlIGludGVybGVhdmVkLWZlYy1zY2hlbWUgSS1EDQooc2VjdGlvbiAzLjEuKSBp cyBub3QgaW4gbGluZSB3aXRoIHRoZSB0ZXJtaW5vbG9neSB1c2VkIGJ5IHRoZQ0KZmVjZnJhbWUt ZnJhbWV3b3JrLTAzIEktRCAoU2VjdGlvbiAyKToNCgkiU291cmNlIEZsb3ciICAgdnMuICJTb3Vy Y2UgZGF0YSBmbG93Ig0KCSJSZXBhaXIgRmxvdyIgICB2cy4gIlJlcGFpciBkYXRhIGZsb3ciDQoJ IlNvdXJjZSBTeW1ib2wiIHZzLiBub3RoaW5nDQoJIlJlcGFpciBTeW1ib2wiIHZzLiBub3RoaW5n DQoJIlNvdXJjZSBQYWNrZXQiIHZzLiBub3RoaW5nDQoJIlJlcGFpciBQYWNrZXQiIHZzLiBub3Ro aW5nDQpBbmQgYXMgSSBzYWlkIGJlZm9yZSwgSU1ITyB0aGUgdGVybWlub2xvZ3kgcHJvcG9zZWQg aW4gdGhlIGZyYW1ld29yaw0KSS1EIHNob3VsZCBiZSBkaXNjdXNzZWQgdG9vLg0KDQpTbyBsZXQn cyBkbyB0aGluZ3MgaW4gdGhlIHJpZ2h0IG9yZGVyLCBlc3BlY2lhbGx5IGFzIHRoZSBmcmFtZXdv cmsNCldHTEMgZmluaXNoZXMgc29vbi4NCg0KQWRkaXRpb25hbGx5LCBJIG1heSBoYXZlIHNvbWUg Y29tbWVudHMgZm9yIHRoZSBpbnRlcmxlYXZlZC1mZWMtc2NoZW1lLTA0DQpJLUQuIFNpbmNlIEkg bWlzc2VkIHRoZSBXR0xDIGRlYWRsaW5lLCB5b3UgaGF2ZSB0aGUgcmlnaHQgdG8gYmxhbWUgbWUg Oy0pDQphbmQgSSBhcG9sb2dpemUgaW4gYWR2YW5jZS4NCg0KUmVnYXJkcywNCg0KICBWaW5jZW50 DQoNCg0KQWxpIEMuIEJlZ2VuIChhYmVnZW4pIHdyb3RlOg0KPiBUaGlzIHZlcnNpb24gYWRkcmVz c2VzIHRoZSBjb21tZW50cyByZWNlaXZlZCBmcm9tIGZlY2ZyYW1lIGFuZCBhdnQgc28gZmFyLiAN Cj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1mZWNmcmFt ZS1pbnRlcmxlYXZlZC1mZWMtc2NoZW1lLTA0LnR4dA0KPiANCj4gDQo+IEZlY2ZyYW1lIGNoYWly cywNCj4gDQo+IENvdWxkIHdlIHByb2NlZWQgYW5kIGZpbmFsaXplIFdHTEM/DQo+IA0KPiAtYWNi ZWdlbg0KPiAgDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJRVRG IEktRCBTdWJtaXNzaW9uIFRvb2wgW21haWx0bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmddIA0KPiBT ZW50OiBXZWRuZXNkYXksIEFwcmlsIDI5LCAyMDA5IDI6NTYgUE0NCj4gVG86IEFsaSBDLiBCZWdl biAoYWJlZ2VuKQ0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWlldGYtZmVjZnJhbWUtaW50ZXJsZWF2ZWQtZmVjLXNjaGVtZS0wNCANCj4gDQo+IA0KPiBBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1mZWNmcmFtZS1pbnRlcmxlYXZlZC1mZWMtc2No ZW1lLTA0LnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVseSBzdWJtaXR0ZWQgYnkgQWxpIEJlZ2VuIGFu ZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IEZpbGVuYW1lOgkgZHJhZnQt aWV0Zi1mZWNmcmFtZS1pbnRlcmxlYXZlZC1mZWMtc2NoZW1lDQo+IFJldmlzaW9uOgkgMDQNCj4g VGl0bGU6CQkgUlRQIFBheWxvYWQgRm9ybWF0IGZvciAxLUQgSW50ZXJsZWF2ZWQgUGFyaXR5IEZF Qw0KPiBDcmVhdGlvbl9kYXRlOgkgMjAwOS0wNC0yOQ0KPiBXRyBJRDoJCSBmZWNmcmFtZQ0KPiBO dW1iZXJfb2ZfcGFnZXM6IDMxDQo+IA0KPiBBYnN0cmFjdDoNCj4gVGhpcyBkb2N1bWVudCBkZWZp bmVzIGEgbmV3IFJUUCBwYXlsb2FkIGZvcm1hdCBmb3IgdGhlIEZvcndhcmQgRXJyb3INCj4gQ29y cmVjdGlvbiAoRkVDKSB0aGF0IGlzIGdlbmVyYXRlZCBieSB0aGUgMS1EIGludGVybGVhdmVkIHBh cml0eSBjb2RlDQo+IGZyb20gYSBzb3VyY2UgbWVkaWEgZW5jYXBzdWxhdGVkIGluIFJUUC4gIFRo ZSAxLUQgaW50ZXJsZWF2ZWQgcGFyaXR5DQo+IGNvZGUgaXMgYSBzeXN0ZW1hdGljIGNvZGUsIHdo ZXJlIGEgbnVtYmVyIG9mIHJlcGFpciBzeW1ib2xzIGFyZQ0KPiBnZW5lcmF0ZWQgZnJvbSBhIHNl dCBvZiBzb3VyY2Ugc3ltYm9scyBhbmQgc2VudCBpbiBhIHJlcGFpciBmbG93DQo+IHNlcGFyYXRl IGZyb20gdGhlIHNvdXJjZSBmbG93IHRoYXQgY2FycmllcyB0aGUgc291cmNlIHN5bWJvbHMuICBU aGUNCj4gMS1EIGludGVybGVhdmVkIHBhcml0eSBjb2RlIG9mZmVycyBhIGdvb2QgcHJvdGVjdGlv biBhZ2FpbnN0IGJ1cnN0eQ0KPiBwYWNrZXQgbG9zc2VzIGF0IGEgY29zdCBvZiBkZWNlbnQgY29t cGxleGl0eS4gIFRoZSBuZXcgcGF5bG9hZCBmb3JtYXQNCj4gZGVmaW5lZCBpbiB0aGlzIGRvY3Vt ZW50IGlzIHVzZWQgKHdpdGggc29tZSBleGNlcHRpb25zKSBhcyBhIHBhcnQgb2YNCj4gdGhlIERW QiBBcHBsaWNhdGlvbi1sYXllciBGRUMgc3BlY2lmaWNhdGlvbi4NCj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KPiANCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0Lg0KPiANCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEZlY2ZyYW1l IG1haWxpbmcgbGlzdA0KPiBGZWNmcmFtZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2ZlY2ZyYW1lDQoNCg== ------_=_NextPart_001_01C9C992.AE5F6E58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2NTQuMTIiPg0KPFRJVExFPlJlOiBbRmVjZnJh bWVdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yCWRyYWZ0LWlldGYtZmVjZnJhbWUt aW50ZXJsZWF2ZWQtZmVjLXNjaGVtZS0wNDwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCjwhLS0g Q29udmVydGVkIGZyb20gdGV4dC9wbGFpbiBmb3JtYXQgLS0+DQoNCjxQPjxGT05UIFNJWkU9Mj5I aSBWaW5jZW50PEJSPg0KPEJSPg0KVGhpcyBkcmFmdCBpcyBub3QgYW4gZmVjIHNjaGVtZSBzbyBp dCBpcyBub3QgcmVsYXRlZCB0byBmZWMgZnJhbWV3b3JrLiBJdCBpcyBhbiBydHAgcGF5bG9hZCBm b3JtYXQgZHJhZnQuIFRoZSB3Z2xjIGhhcyBiZWVuIHJ1bm5pbmcgYWxtb3N0IGEgbW9udGggbm93 LiBJZiB5b3UgaGF2ZSBjb21tZW50cyBpbiB0aGlzIHBlcnNwZWN0aXZlLCBwbHMgc3VibWl0IHRo ZW0gc29vbi48QlI+DQo8QlI+DQo8QlI+DQo8QlI+DQo8QlI+DQotYWNiZWdlbjxCUj4NCjxCUj4N Ci0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS08QlI+DQpGcm9tOiBWaW5jZW50IFJvY2EgJmx0 O3ZpbmNlbnQucm9jYUBpbnJpYWxwZXMuZnImZ3Q7PEJSPg0KVG86IEFsaSBDLiBCZWdlbiAoYWJl Z2VuKTxCUj4NCkNjOiBmZWNmcmFtZUBpZXRmLm9yZyAmbHQ7ZmVjZnJhbWVAaWV0Zi5vcmcmZ3Q7 OyBhdnRAaWV0Zi5vcmcgJmx0O2F2dEBpZXRmLm9yZyZndDs8QlI+DQpTZW50OiBUaHUgQXByIDMw IDAzOjU4OjM1IDIwMDk8QlI+DQpTdWJqZWN0OiBSZTogW0ZlY2ZyYW1lXSBGVzogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBkcmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUtMDQ8QlI+DQo8 QlI+DQpIZWxsbyBBbGksPEJSPg0KPEJSPg0KSSdtIG5vdCBpbiBmYXZvciBvZiBmaW5hbGl6aW5n IHRoZSBXR0xDIGZvciB0aGlzIGRvY3VtZW50LiBJTUhPIHdlIG11c3QsPEJSPg0KZmlyc3Qgb2Yg YWxsLCBmaW5hbGl6ZSB0aGUgZnJhbWV3b3JrIGRvY3VtZW50IGl0c2VsZi48QlI+DQo8QlI+DQpG b3IgaW5zdGFuY2UsIHRoZSB0ZXJtaW5vbG9neSB1c2VkIGJ5IHRoZSBpbnRlcmxlYXZlZC1mZWMt c2NoZW1lIEktRDxCUj4NCihzZWN0aW9uIDMuMS4pIGlzIG5vdCBpbiBsaW5lIHdpdGggdGhlIHRl cm1pbm9sb2d5IHVzZWQgYnkgdGhlPEJSPg0KZmVjZnJhbWUtZnJhbWV3b3JrLTAzIEktRCAoU2Vj dGlvbiAyKTo8QlI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg JnF1b3Q7U291cmNlIEZsb3cmcXVvdDsmbmJzcDsmbmJzcDsgdnMuICZxdW90O1NvdXJjZSBkYXRh IGZsb3cmcXVvdDs8QlI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJnF1b3Q7UmVwYWlyIEZsb3cmcXVvdDsmbmJzcDsmbmJzcDsgdnMuICZxdW90O1JlcGFpciBk YXRhIGZsb3cmcXVvdDs8QlI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJnF1b3Q7U291cmNlIFN5bWJvbCZxdW90OyB2cy4gbm90aGluZzxCUj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtSZXBhaXIgU3ltYm9sJnF1 b3Q7IHZzLiBub3RoaW5nPEJSPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZxdW90O1NvdXJjZSBQYWNrZXQmcXVvdDsgdnMuIG5vdGhpbmc8QlI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7UmVwYWlyIFBhY2tldCZx dW90OyB2cy4gbm90aGluZzxCUj4NCkFuZCBhcyBJIHNhaWQgYmVmb3JlLCBJTUhPIHRoZSB0ZXJt aW5vbG9neSBwcm9wb3NlZCBpbiB0aGUgZnJhbWV3b3JrPEJSPg0KSS1EIHNob3VsZCBiZSBkaXNj dXNzZWQgdG9vLjxCUj4NCjxCUj4NClNvIGxldCdzIGRvIHRoaW5ncyBpbiB0aGUgcmlnaHQgb3Jk ZXIsIGVzcGVjaWFsbHkgYXMgdGhlIGZyYW1ld29yazxCUj4NCldHTEMgZmluaXNoZXMgc29vbi48 QlI+DQo8QlI+DQpBZGRpdGlvbmFsbHksIEkgbWF5IGhhdmUgc29tZSBjb21tZW50cyBmb3IgdGhl IGludGVybGVhdmVkLWZlYy1zY2hlbWUtMDQ8QlI+DQpJLUQuIFNpbmNlIEkgbWlzc2VkIHRoZSBX R0xDIGRlYWRsaW5lLCB5b3UgaGF2ZSB0aGUgcmlnaHQgdG8gYmxhbWUgbWUgOy0pPEJSPg0KYW5k IEkgYXBvbG9naXplIGluIGFkdmFuY2UuPEJSPg0KPEJSPg0KUmVnYXJkcyw8QlI+DQo8QlI+DQom bmJzcDsgVmluY2VudDxCUj4NCjxCUj4NCjxCUj4NCkFsaSBDLiBCZWdlbiAoYWJlZ2VuKSB3cm90 ZTo8QlI+DQomZ3Q7IFRoaXMgdmVyc2lvbiBhZGRyZXNzZXMgdGhlIGNvbW1lbnRzIHJlY2VpdmVk IGZyb20gZmVjZnJhbWUgYW5kIGF2dCBzbyBmYXIuPEJSPg0KJmd0OyA8QSBIUkVGPSJodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybGVh dmVkLWZlYy1zY2hlbWUtMDQudHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUtMDQudHh0PC9BPjxC Uj4NCiZndDs8QlI+DQomZ3Q7PEJSPg0KJmd0OyBGZWNmcmFtZSBjaGFpcnMsPEJSPg0KJmd0OzxC Uj4NCiZndDsgQ291bGQgd2UgcHJvY2VlZCBhbmQgZmluYWxpemUgV0dMQz88QlI+DQomZ3Q7PEJS Pg0KJmd0OyAtYWNiZWdlbjxCUj4NCiZndDsmbmJzcDs8QlI+DQomZ3Q7PEJSPg0KJmd0OyAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj4NCiZndDsgRnJvbTogSUVURiBJLUQgU3VibWlzc2lv biBUb29sIFs8QSBIUkVGPSJtYWlsdG86aWRzdWJtaXNzaW9uQGlldGYub3JnIj5tYWlsdG86aWRz dWJtaXNzaW9uQGlldGYub3JnPC9BPl08QlI+DQomZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwg MjksIDIwMDkgMjo1NiBQTTxCUj4NCiZndDsgVG86IEFsaSBDLiBCZWdlbiAoYWJlZ2VuKTxCUj4N CiZndDsgU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWZl Y2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUtMDQ8QlI+DQomZ3Q7PEJSPg0KJmd0OzxCUj4N CiZndDsgQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtZmVjZnJhbWUtaW50ZXJsZWF2 ZWQtZmVjLXNjaGVtZS0wNC50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bHkgc3VibWl0dGVkIGJ5IEFs aSBCZWdlbiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuPEJSPg0KJmd0OzxCUj4N CiZndDsgRmlsZW5hbWU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LWlldGYt ZmVjZnJhbWUtaW50ZXJsZWF2ZWQtZmVjLXNjaGVtZTxCUj4NCiZndDsgUmV2aXNpb246Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDA0PEJSPg0KJmd0OyBUaXRsZTombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJUUCBQYXlsb2FkIEZvcm1hdCBmb3IgMS1EIEludGVybGVh dmVkIFBhcml0eSBGRUM8QlI+DQomZ3Q7IENyZWF0aW9uX2RhdGU6Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIwMDktMDQtMjk8QlI+DQomZ3Q7IFdHIElE OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZmVjZnJhbWU8QlI+DQomZ3Q7IE51 bWJlcl9vZl9wYWdlczogMzE8QlI+DQomZ3Q7PEJSPg0KJmd0OyBBYnN0cmFjdDo8QlI+DQomZ3Q7 IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBSVFAgcGF5bG9hZCBmb3JtYXQgZm9yIHRoZSBG b3J3YXJkIEVycm9yPEJSPg0KJmd0OyBDb3JyZWN0aW9uIChGRUMpIHRoYXQgaXMgZ2VuZXJhdGVk IGJ5IHRoZSAxLUQgaW50ZXJsZWF2ZWQgcGFyaXR5IGNvZGU8QlI+DQomZ3Q7IGZyb20gYSBzb3Vy Y2UgbWVkaWEgZW5jYXBzdWxhdGVkIGluIFJUUC4mbmJzcDsgVGhlIDEtRCBpbnRlcmxlYXZlZCBw YXJpdHk8QlI+DQomZ3Q7IGNvZGUgaXMgYSBzeXN0ZW1hdGljIGNvZGUsIHdoZXJlIGEgbnVtYmVy IG9mIHJlcGFpciBzeW1ib2xzIGFyZTxCUj4NCiZndDsgZ2VuZXJhdGVkIGZyb20gYSBzZXQgb2Yg c291cmNlIHN5bWJvbHMgYW5kIHNlbnQgaW4gYSByZXBhaXIgZmxvdzxCUj4NCiZndDsgc2VwYXJh dGUgZnJvbSB0aGUgc291cmNlIGZsb3cgdGhhdCBjYXJyaWVzIHRoZSBzb3VyY2Ugc3ltYm9scy4m bmJzcDsgVGhlPEJSPg0KJmd0OyAxLUQgaW50ZXJsZWF2ZWQgcGFyaXR5IGNvZGUgb2ZmZXJzIGEg Z29vZCBwcm90ZWN0aW9uIGFnYWluc3QgYnVyc3R5PEJSPg0KJmd0OyBwYWNrZXQgbG9zc2VzIGF0 IGEgY29zdCBvZiBkZWNlbnQgY29tcGxleGl0eS4mbmJzcDsgVGhlIG5ldyBwYXlsb2FkIGZvcm1h dDxCUj4NCiZndDsgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGlzIHVzZWQgKHdpdGggc29tZSBl eGNlcHRpb25zKSBhcyBhIHBhcnQgb2Y8QlI+DQomZ3Q7IHRoZSBEVkIgQXBwbGljYXRpb24tbGF5 ZXIgRkVDIHNwZWNpZmljYXRpb24uPEJSPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxCUj4NCiZndDs8QlI+DQomZ3Q7PEJSPg0KJmd0OyBUaGUgSUVURiBTZWNyZXRh cmlhdC48QlI+DQomZ3Q7PEJSPg0KJmd0OzxCUj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188QlI+DQomZ3Q7IEZlY2ZyYW1lIG1haWxpbmcgbGlz dDxCUj4NCiZndDsgRmVjZnJhbWVAaWV0Zi5vcmc8QlI+DQomZ3Q7IDxBIEhSRUY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZmVjZnJhbWUiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZmVjZnJhbWU8L0E+PEJSPg0KPEJSPg0KPC9GT05UPg0KPC9Q Pg0KDQo8L0JPRFk+DQo8L0hUTUw+ ------_=_NextPart_001_01C9C992.AE5F6E58-- From ingemar.s.johansson@ericsson.com Thu Apr 30 07:41:40 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 976D83A6D76 for ; Thu, 30 Apr 2009 07:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.89 X-Spam-Level: X-Spam-Status: No, score=-5.89 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIDoXHXXZ4au for ; Thu, 30 Apr 2009 07:41:39 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id ADC043A6827 for ; Thu, 30 Apr 2009 07:41:38 -0700 (PDT) X-AuditID: c1b4fb3e-b7b7aae000004a86-06-49f9aa8f8a2e Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id F9.6A.19078.F8AA9F94; Thu, 30 Apr 2009 15:41:36 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 15:41:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Apr 2009 15:41:33 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8CFA6CC0@esealmw109.eemea.ericsson.se> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C8406@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions(RAMS)" available Thread-Index: AcnCgGOAYtLRTTIdQwOCQbmUqfc+VwAKXQPwALciuUAAF5U9oADstm2w References: <130EBB38279E9847BAAAE0B8F9905F8CE5B090@esealmw109.eemea.ericsson.se> <04CAD96D4C5A3D48B1919248A8FE0D540924FED8@xmb-sjc-215.amer.cisco.com> <130EBB38279E9847BAAAE0B8F9905F8CF06BD5@esealmw109.eemea.ericsson.se> <04CAD96D4C5A3D48B1919248A8FE0D54092C8406@xmb-sjc-215.amer.cisco.com> From: "Ingemar Johansson S" To: "Ali C. Begen (abegen)" , X-OriginalArrivalTime: 30 Apr 2009 13:41:34.0304 (UTC) FILETIME=[60815E00:01C9C999] X-Brightmail-Tracker: AAAAAA== Cc: "Bill Ver Steeg \(versteb\)" Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions(RAMS)" available X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 14:41:40 -0000 Hi Some more comments below Regards /Ingemar=20 > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > Sent: den 25 april 2009 22:51 > To: Ingemar Johansson S; avt@ietf.org > Cc: Bill Ver Steeg (versteb) > Subject: RE: [AVT] New draft of "Rapid Acquisition of=20 > Multicast RTP Sessions(RAMS)" available >=20 > > > I would not say it would be "fairly straighforward." To make the=20 > > > multicast bursting effective, many parameters need to be adjusted=20 > > > properly and optimized. Ow, it can easily degrade the performance=20 > > > even at the expense of additional complexity. > > >=20 > > > A concern I have which is not addressed in your document=20 > is that to=20 > > > make the proposal make sense, Td needs to be small=20 > enough. But, to=20 > > > ensure that all receivers join the burst mcast session before the=20 > > > burst starts, Td cannot be very small and RS should not admit=20 > > > last-minute RAMS requests for that multicast burst (they need to=20 > > > wait for the next batch). > > > This is because if some receivers miss the first few=20 > packets of the=20 > > > burst, their acquisition will fail. Also, how many=20 > clients can the=20 > > > retransmission server aggregate in a single burst batch in a=20 > > > practical scenario? The eligible requests should be=20 > received within=20 > > > +/- a few hundereds of milliseconds. How practical is this, I=20 > > > wonder. > > The neat thing is that during low load conditions Td can be=20 > made very=20 > > low such that in practice only one user is served by each request.=20 > > This can be implemented with either unicast or multicast=20 > bursts that=20 > > only serve one STB. As he load increases Td increases and=20 > more users=20 > > that send a requests will be served by one multicast=20 > channel. As Td is=20 > > limited some requests will be too late but they can too be=20 > collected=20 > > and served by additional multicast feeds. Then depending on the=20 > > distribuion the tail may be handled with unicast bursts. > > This is more or less an optimization issue on the servers. >=20 > Agree. >=20 > > The idea is not that the unicast and multicast alternatives should=20 > > compete with one another, rather they should complement each other,=20 > > due to the highly dynamic nature of channel switching behavior in a=20 > > population both alternatives are useful. I do believe that the=20 > > multicast solution can help to reduce deplyment cost. >=20 > It can. However, remember that in a highly-loaded=20 > environment, if RS cannot provide (unicast) acceleration, it=20 > can deny the request. For the sake of doing multicast=20 > bursting (to save bandwidth), if RRs experience a slower=20 > acquisition (due to a large Td, for example) compared to a=20 > simple join, that is not good. My feeling here is that a multicast solution for RAMS would help to keep the load on a lower level and thus will avoid that a RAMS request is denied. >=20 > > I have tried to look for statistics on channel switching=20 > behavior and=20 > > of what I have seen sofar the "peak-to-average" > > ratio of channel swithing density can be more than 5. This=20 > is seen in=20 > > a master thesis with the title "TPTV traffic measuring &=20 > modeling" by=20 > > Geng Yu (have not found it published anywhere yet). >=20 > I don't think I have that study, either. But, there is a=20 > recent study in IMC 2008. Here is the link. > http://portal.acm.org/ft_gateway.cfm?id=3D1452529&type=3Dpdf&coll=3D portal&dl=3DACM >=20 > The results are in general more or less similar to what we=20 > found in one of our own studies. The figure you will find=20 > interesting is Figure 14.=20 >=20 > For the most popular channel, the entire data set shows that=20 > on average 14 viewers tune into that channel per second=20 > (Figure 14a). Of course, there are occasions where a lot more=20 > viewers may tune at approximately the same time (within the=20 > same second), but this is for the top-ranked channel and the=20 > number 14 includes all viewers in the data set, which is=20 > about 250K (This is what I got from the text). If we consider=20 > only a subset of these viewers will be served by the same RS,=20 > the concurrency we will get in a single server will be far=20 > smaller, impying that multicast burst will not be needed most=20 > of the time. >=20 > Different studies may suggest different numbers based on the=20 > regional characteristics. So, I don't think we should read=20 > too much into this study. If there are other studies, please=20 > post them here. So, we can make a better judgment. I don't have any public links to the other reports (sorry) but I would guess that the results are approximately similar. I see however one risk in trying to compute median and mean from data that may have a very large standard deviation like one can suspect in cases like this where the the behavior is very bursty.=20 >=20 > > > The selection of a common burst bitrate is also critical. If=20 > > > everybody supports a different burst bitrate and there is a large=20 > > > variation, multicast bursting will perform poorly for the=20 > > > well-connected clients. One solution could be to include the=20 > > > receivers with an available bw that is smaller than R1 and larger=20 > > > than R2 in the multicast pool. The very fast and very=20 > slow receivers=20 > > > should be still served via unicast. > > Sounds reasonable. > >=20 > > >=20 > > > My personal view is that the multicast bursting proposal=20 > will be a=20 > > > nice solution when the issues above (and possible > > > others) are addressed, however, I think it should be a separate=20 > > > draft that normatively references the unicast draft. > > > This way, we can keep the unicast draft more focused. > > Not sure that I agree here, it all depends on how the signaling is=20 > > standardized. For instance an STB likely needs to declare its=20 > > unicast/multicast preference or capability in the RAMS-R as=20 > the SDP's=20 > > are likely only declarative. >=20 > There can be a TLV in the request to do this, no?=20 Possible, need to investigate this option closer.=20 >=20 > BR, > -acbegen >=20 From tme@multicasttech.com Thu Apr 30 06:50:40 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A67C3A6E09; Thu, 30 Apr 2009 06:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.939 X-Spam-Level: X-Spam-Status: No, score=-102.939 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVeqJKxHLJ7H; Thu, 30 Apr 2009 06:50:37 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id AFC3C3A6F55; Thu, 30 Apr 2009 06:50:36 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 6DB1F3B38776; Thu, 30 Apr 2009 09:51:59 -0400 (EDT) Message-Id: From: Marshall Eubanks To: "Ali C. Begen (abegen)" In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 30 Apr 2009 09:51:59 -0400 References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Thu, 30 Apr 2009 09:52:40 -0700 Cc: fecframe@ietf.org, avt@ietf.org Subject: Re: [AVT] [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 13:50:40 -0000 On Apr 30, 2009, at 8:53 AM, Ali C. Begen (abegen) wrote: > Hi Vincent > > This draft is not an fec scheme so it is not related to fec > framework. It is an rtp payload format draft. The wglc has been > running almost a month now. If you have comments in this > perspective, pls submit them soon. > > I was about to close this WGLC, but we can wait a short while for new comments. Marshall > > > > -acbegen > > ----- Original Message ----- > From: Vincent Roca > To: Ali C. Begen (abegen) > Cc: fecframe@ietf.org ; avt@ietf.org > Sent: Thu Apr 30 03:58:35 2009 > Subject: Re: [Fecframe] FW: New Version Notification for > draft-ietf-fecframe-interleaved-fec-scheme-04 > > Hello Ali, > > I'm not in favor of finalizing the WGLC for this document. IMHO we > must, > first of all, finalize the framework document itself. > > For instance, the terminology used by the interleaved-fec-scheme I-D > (section 3.1.) is not in line with the terminology used by the > fecframe-framework-03 I-D (Section 2): > "Source Flow" vs. "Source data flow" > "Repair Flow" vs. "Repair data flow" > "Source Symbol" vs. nothing > "Repair Symbol" vs. nothing > "Source Packet" vs. nothing > "Repair Packet" vs. nothing > And as I said before, IMHO the terminology proposed in the framework > I-D should be discussed too. > > So let's do things in the right order, especially as the framework > WGLC finishes soon. > > Additionally, I may have some comments for the interleaved-fec- > scheme-04 > I-D. Since I missed the WGLC deadline, you have the right to blame > me ;-) > and I apologize in advance. > > Regards, > > Vincent > > > Ali C. Begen (abegen) wrote: > > This version addresses the comments received from fecframe and avt > so far. > > http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interleaved-fec-scheme-04.txt > > > > > > Fecframe chairs, > > > > Could we proceed and finalize WGLC? > > > > -acbegen > > > > > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: Wednesday, April 29, 2009 2:56 PM > > To: Ali C. Begen (abegen) > > Subject: New Version Notification for draft-ietf-fecframe- > interleaved-fec-scheme-04 > > > > > > A new version of I-D, draft-ietf-fecframe-interleaved-fec- > scheme-04.txt has been successfuly submitted by Ali Begen and posted > to the IETF repository. > > > > Filename: draft-ietf-fecframe-interleaved-fec-scheme > > Revision: 04 > > Title: RTP Payload Format for 1-D Interleaved > Parity FEC > > Creation_date: 2009-04-29 > > WG ID: fecframe > > Number_of_pages: 31 > > > > Abstract: > > This document defines a new RTP payload format for the Forward Error > > Correction (FEC) that is generated by the 1-D interleaved parity > code > > from a source media encapsulated in RTP. The 1-D interleaved parity > > code is a systematic code, where a number of repair symbols are > > generated from a set of source symbols and sent in a repair flow > > separate from the source flow that carries the source symbols. The > > 1-D interleaved parity code offers a good protection against bursty > > packet losses at a cost of decent complexity. The new payload > format > > defined in this document is used (with some exceptions) as a part of > > the DVB Application-layer FEC specification. > > > > > > > > The IETF Secretariat. > > > > > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe Regards Marshall Eubanks CEO / AmericaFree.TV From ron.even.tlv@gmail.com Thu Apr 30 11:13:08 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F27D13A6FBB; Thu, 30 Apr 2009 11:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.767 X-Spam-Level: X-Spam-Status: No, score=-1.767 tagged_above=-999 required=5 tests=[AWL=0.831, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGZOscjyaU-A; Thu, 30 Apr 2009 11:13:06 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 0D5B23A6DF6; Thu, 30 Apr 2009 11:13:05 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so1935537fgb.18 for ; Thu, 30 Apr 2009 11:14:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=BusdFcJaTU4Yd/j/C0GxMcxo6I+Ij6l7/ZGoTIionTA=; b=RdnXR3Dsfh6h+BaQTu5Mc9LbQURdtjmKK7yuHfOB1DOtzZTjckyoVqDNZRx2+WDsNe Bm3hiNRqjgwEmMSt6Tcf2PILlmQWBQ2XzrcW9s2ESGC9Ttuwp3HMsTiRKKzzdEMIC24a 9ulzDG/duCvctyt2UxTBd3xLWl8dh2eLTtZtQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; b=GcHBZrI6zH2UBIvpqQVJK/BgwKy0bRJiKlX8alZGQ9qcI0JhaE1jCdCJTmO3B1jqOO TRX2gyEW8XjoG06OT7gth3wZfAetd5yVbMPB+hZnQpqmwA8/LXXZMYStxHiVsF7xlbKa XB9O3eDk9uDFXTpJ6naUj5a98ST0TbSo3txEQ= Received: by 10.86.92.9 with SMTP id p9mr2115315fgb.15.1241115267815; Thu, 30 Apr 2009 11:14:27 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-57-219.red.bezeqint.net [79.177.57.219]) by mx.google.com with ESMTPS id d6sm4029458fga.22.2009.04.30.11.14.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Apr 2009 11:14:27 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> Date: Thu, 30 Apr 2009 21:12:21 +0300 Message-ID: <49f9ea83.0637560a.4488.62d2@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B3_01C9C9D8.636879C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnJgq+DQP1j7cRATQa6PC9zcfp8gAAD/6reAAsScqA= Content-Language: en-us Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [AVT] [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 18:13:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B3_01C9C9D8.636879C0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ali, I noticed that the fec framework will allow SSRC multiplexing, are you = going to specify this in this draft in the SDP offer answer section.=20 Maybe you should also discuss when to use application media type and = when to use video or audio =20 Roni =20 From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Ali C. Begen (abegen) Sent: Thursday, April 30, 2009 3:54 PM To: vincent.roca@inrialpes.fr Cc: avt@ietf.org; fecframe@ietf.org Subject: Re: [AVT] [Fecframe] FW: New Version Notification for = draft-ietf-fecframe-interleaved-fec-scheme-04 =20 Hi Vincent This draft is not an fec scheme so it is not related to fec framework. = It is an rtp payload format draft. The wglc has been running almost a = month now. If you have comments in this perspective, pls submit them = soon. -acbegen ----- Original Message ----- From: Vincent Roca To: Ali C. Begen (abegen) Cc: fecframe@ietf.org ; avt@ietf.org Sent: Thu Apr 30 03:58:35 2009 Subject: Re: [Fecframe] FW: New Version Notification for = draft-ietf-fecframe-interleaved-fec-scheme-04 Hello Ali, I'm not in favor of finalizing the WGLC for this document. IMHO we must, first of all, finalize the framework document itself. For instance, the terminology used by the interleaved-fec-scheme I-D (section 3.1.) is not in line with the terminology used by the fecframe-framework-03 I-D (Section 2): "Source Flow" vs. "Source data flow" "Repair Flow" vs. "Repair data flow" "Source Symbol" vs. nothing "Repair Symbol" vs. nothing "Source Packet" vs. nothing "Repair Packet" vs. nothing And as I said before, IMHO the terminology proposed in the framework I-D should be discussed too. So let's do things in the right order, especially as the framework WGLC finishes soon. Additionally, I may have some comments for the interleaved-fec-scheme-04 I-D. Since I missed the WGLC deadline, you have the right to blame me = ;-) and I apologize in advance. Regards, Vincent Ali C. Begen (abegen) wrote: > This version addresses the comments received from fecframe and avt so = far. > = http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interleaved-fec-s= cheme-04.txt > > > Fecframe chairs, > > Could we proceed and finalize WGLC? > > -acbegen >=20 > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Wednesday, April 29, 2009 2:56 PM > To: Ali C. Begen (abegen) > Subject: New Version Notification for = draft-ietf-fecframe-interleaved-fec-scheme-04 > > > A new version of I-D, = draft-ietf-fecframe-interleaved-fec-scheme-04.txt has been successfuly = submitted by Ali Begen and posted to the IETF repository. > > Filename: draft-ietf-fecframe-interleaved-fec-scheme > Revision: 04 > Title: RTP Payload Format for 1-D Interleaved Parity = FEC > Creation_date: 2009-04-29 > WG ID: fecframe > Number_of_pages: 31 > > Abstract: > This document defines a new RTP payload format for the Forward Error > Correction (FEC) that is generated by the 1-D interleaved parity code > from a source media encapsulated in RTP. The 1-D interleaved parity > code is a systematic code, where a number of repair symbols are > generated from a set of source symbols and sent in a repair flow > separate from the source flow that carries the source symbols. The > 1-D interleaved parity code offers a good protection against bursty > packet losses at a cost of decent complexity. The new payload format > defined in this document is used (with some exceptions) as a part of > the DVB Application-layer FEC specification. > = =20 > > > The IETF Secretariat. > > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe ------=_NextPart_000_00B3_01C9C9D8.636879C0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Re: [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04

Ali,

I noticed that the fec framework will allow SSRC = multiplexing, are you going to specify this in this draft in the SDP offer answer = section.

Maybe you should also discuss when to use application = media type and when to use video or audio

 

Roni

 

From:= avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Ali C. Begen (abegen)
Sent: Thursday, April 30, 2009 3:54 PM
To: vincent.roca@inrialpes.fr
Cc: avt@ietf.org; fecframe@ietf.org
Subject: Re: [AVT] [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04

 

Hi = Vincent

This draft is not an fec scheme so it is not related to fec framework. = It is an rtp payload format draft. The wglc has been running almost a month now. = If you have comments in this perspective, pls submit them soon.




-acbegen

----- Original Message -----
From: Vincent Roca <vincent.roca@inrialpes.fr>
To: Ali C. Begen (abegen)
Cc: fecframe@ietf.org <fecframe@ietf.org>; avt@ietf.org <avt@ietf.org>
Sent: Thu Apr 30 03:58:35 2009
Subject: Re: [Fecframe] FW: New Version Notification for        draft-ietf-fecframe-interleaved-fec-scheme-04

Hello Ali,

I'm not in favor of finalizing the WGLC for this document. IMHO we = must,
first of all, finalize the framework document itself.

For instance, the terminology used by the interleaved-fec-scheme I-D
(section 3.1.) is not in line with the terminology used by the
fecframe-framework-03 I-D (Section 2):
        "Source = Flow"   vs. "Source data flow"
        "Repair = Flow"   vs. "Repair data flow"
        "Source Symbol" vs. nothing
        "Repair Symbol" vs. nothing
        "Source Packet" vs. nothing
        "Repair Packet" vs. = nothing
And as I said before, IMHO the terminology proposed in the framework
I-D should be discussed too.

So let's do things in the right order, especially as the framework
WGLC finishes soon.

Additionally, I may have some comments for the = interleaved-fec-scheme-04
I-D. Since I missed the WGLC deadline, you have the right to blame me = ;-)
and I apologize in advance.

Regards,

  Vincent


Ali C. Begen (abegen) wrote:
> This version addresses the comments received from fecframe and avt = so far.
> http://www.ietf.org/internet-drafts/draft-ietf-fecf= rame-interleaved-fec-scheme-04.txt
>
>
> Fecframe chairs,
>
> Could we proceed and finalize WGLC?
>
> -acbegen
> 
>
> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Wednesday, April 29, 2009 2:56 PM
> To: Ali C. Begen (abegen)
> Subject: New Version Notification for = draft-ietf-fecframe-interleaved-fec-scheme-04
>
>
> A new version of I-D, = draft-ietf-fecframe-interleaved-fec-scheme-04.txt has been successfuly submitted by Ali Begen and posted to the IETF = repository.
>
> Filename:      draft-ietf-fecframe-interleaved-fec-scheme
> Revision:      04
> Title:                 RTP Payload Format for = 1-D Interleaved Parity FEC
> Creation_date:         = 2009-04-29
> WG ID:                 fecframe
> Number_of_pages: 31
>
> Abstract:
> This document defines a new RTP payload format for the Forward = Error
> Correction (FEC) that is generated by the 1-D interleaved parity = code
> from a source media encapsulated in RTP.  The 1-D interleaved = parity
> code is a systematic code, where a number of repair symbols are
> generated from a set of source symbols and sent in a repair = flow
> separate from the source flow that carries the source = symbols.  The
> 1-D interleaved parity code offers a good protection against = bursty
> packet losses at a cost of decent complexity.  The new payload = format
> defined in this document is used (with some exceptions) as a part = of
> the DVB Application-layer FEC specification.
>           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;         
>
>
> The IETF Secretariat.
>
>
> _______________________________________________
> Fecframe mailing list
> Fecframe@ietf.org
> https://www.ietf.= org/mailman/listinfo/fecframe

------=_NextPart_000_00B3_01C9C9D8.636879C0-- From Tom.Van_Caenegem@alcatel-lucent.be Thu Apr 30 11:18:17 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E367B3A6941 for ; Thu, 30 Apr 2009 11:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.294 X-Spam-Level: X-Spam-Status: No, score=-3.294 tagged_above=-999 required=5 tests=[AWL=-1.046, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QC9P87f3y14P for ; Thu, 30 Apr 2009 11:18:17 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id CDF513A688A for ; Thu, 30 Apr 2009 11:18:16 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3UIJcV7013024 for ; Thu, 30 Apr 2009 20:19:38 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 20:19:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C9C0.38FD9FAF" Date: Thu, 30 Apr 2009 20:19:37 +0200 Message-ID: <238382595265324EA50F6134BB42DCAF03BAEC6B@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Rapid Acquisition of Multicast RTP Sessions (RAMS)" draft , revision 3 Thread-Index: AcnJwDirwID89CtjSi6xKY0keDSOjw== From: "VAN CAENEGEM Tom" To: X-OriginalArrivalTime: 30 Apr 2009 18:19:38.0643 (UTC) FILETIME=[39257630:01C9C9C0] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: [AVT] Rapid Acquisition of Multicast RTP Sessions (RAMS)" draft , revision 3 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 18:18:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C9C0.38FD9FAF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni and all other IETF AVT WG participants, Considering that the "Rapid Acquisition of Multicast RTP Sessions (RAMS)" draft (revision 3) -has taken into account many of the remarks that came out of the break-out session in the San Francisco meeting -includes the flexible burst rate adaptation capability, the prime differentiator in the "draft-peilin-avt-rtp-burst" from previous versions of the RAMS draft, and as such the RAMS draft has now merged and integrated the solutions proposed in three different originating drafts.=20 -has included adequate flexibility by allowing TLV fields in the signaling messages, allowing other concepts to leverage the solution in the future (including potentially a multicast-based solution as proposed in draft-johansson-avt-mcast-based-rams-00). , I would like to know whether there is still a blocking issue for preventing this draft from becoming a working group item. I followed with great interest in the last weeks the SDP discussions related to the SDP signaling example in the RAMS v 3 draft (I am unfortunately not sufficiently experienced in that domain to contribute), where the latest shared opinions make me think that this is not really a blocking item. Considering that the 1st draft was submitted back in august last year, and the various subsequent revisions and merges since then, can we now proceed with the draft as a working group subject? Kind Regards, Tom Van Caenegem (co-author of the "Rapid Acquisition of Multicast RTPSessions (RAMS)" draft) ------_=_NextPart_001_01C9C9C0.38FD9FAF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rapid Acquisition of Multicast RTP Sessions (RAMS)" draft , = revision 3

Hi Roni and all = other IETF AVT WG participants,

Considering that = the "Rapid Acquisition of Multicast RTP Sessions (RAMS)" draft = (revision 3)

-has taken into = account many of the remarks that came out of the break-out session in = the San Francisco meeting
-includes the = flexible burst rate adaptation capability, the prime differentiator in = the "draft-peilin-avt-rtp-burst" from previous versions of the = RAMS draft, and as such the RAMS draft has now merged and integrated the = solutions proposed in three different originating = drafts.

-has included = adequate flexibility by allowing TLV fields in the signaling messages, = allowing other concepts to leverage the solution in the future = (including potentially a multicast-based solution as proposed = in draft-johansson-avt-mcast-based-rams-00).

, I would like to = know whether there is still a blocking issue for preventing this draft = from becoming a working group item.

I followed with = great interest in the last weeks the SDP discussions related to the SDP = signaling example in the RAMS v 3 draft (I am unfortunately not = sufficiently experienced in that domain to contribute), where the latest = shared opinions make me think that this is not really a blocking = item.

Considering that = the 1st draft was submitted back in august last year, and the various = subsequent revisions and merges since then, can we now proceed with the = draft as a working group subject?

Kind = Regards,
Tom Van Caenegem = (co-author of the "Rapid Acquisition of Multicast RTPSessions = (RAMS)" draft)

------_=_NextPart_001_01C9C9C0.38FD9FAF-- From abegen@cisco.com Thu Apr 30 12:03:59 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFE0C28C326; Thu, 30 Apr 2009 12:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxHGVVFBCQWL; Thu, 30 Apr 2009 12:03:58 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id CDA5F28C35B; Thu, 30 Apr 2009 12:01:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,274,1238976000"; d="scan'208";a="160728761" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 30 Apr 2009 19:03:17 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3UJ3HfN013810; Thu, 30 Apr 2009 12:03:17 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3UJ3HnE017272; Thu, 30 Apr 2009 19:03:17 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 12:03:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 30 Apr 2009 12:01:15 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540934913F@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49f9ea83.0637560a.4488.62d2@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 Thread-Index: AcnJgq+DQP1j7cRATQa6PC9zcfp8gAAD/6reAAsScqAAAXPloA== References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> <49f9ea83.0637560a.4488.62d2@mx.google.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , X-OriginalArrivalTime: 30 Apr 2009 19:03:17.0059 (UTC) FILETIME=[51D80930:01C9C9C6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6586; t=1241118197; x=1241982197; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20[Fecframe]=20FW=3A=20New=20Vers ion=20Notification=09for=09draft-ietf-fecframe-interleaved-f ec-scheme-04 |Sender:=20; bh=CkTuab6xkOGqFObHxHnK70weg2gwV6jYDwtdXk2VMLA=; b=1D5WVGFTbGeUdiKvrCJXyl58cPf5BKoczwu8nYUvoNlgIIbCPLxbV+mkeZ xW6gcDBi6tV1tqd3spFju6QOiMdu5S3oW4e4+6C25jI4E2jvBEBVLzGYG674 O2DQhRaVaN; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [AVT] [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 19:03:59 -0000 SGkgUm9uaSwgDQoNCj4gSSBub3RpY2VkIHRoYXQgdGhlIGZlYyBmcmFtZXdvcmsgd2lsbCBhbGxv dyBTU1JDIA0KDQpZZXMsIGl0IHdpbGwgbm90IGJlIHRoZSByZWNvbW1lbmRlZCB3YXkgb2YgdXNp bmcgRkVDLCBidXQgaXQgd2lsbCBiZSBzdXBwb3J0ZWQuIFRoZSA0NzU2YmlzIGRyYWZ0IGFsc28g c3VwcG9ydHMgaXQgbm93Lg0KDQo+IG11bHRpcGxleGluZywgYXJlIHlvdSBnb2luZyB0byBzcGVj aWZ5IHRoaXMgaW4gdGhpcyBkcmFmdCBpbiANCj4gdGhlIFNEUCBvZmZlciBhbnN3ZXIgc2VjdGlv bi4gDQoNCkkgYW0gbm90IHN1cmUgd2hhdCBJIG5lZWQgdG8gc3BlY2lmeSBhZGRpdGlvbmFsbHkg aW4gdGhpcyBzZWN0aW9uIHJlZ2FyZGluZyBTU1JDIG11bHRpcGxleGluZy4gQ291bGQgeW91IGxl dCBtZSBrbm93IGlmIHRoZXJlIGlzIHN1Y2ggYW4gZXhhbXBsZT8NCiANCj4gTWF5YmUgeW91IHNo b3VsZCBhbHNvIGRpc2N1c3Mgd2hlbiB0byB1c2UgYXBwbGljYXRpb24gbWVkaWEgDQo+IHR5cGUg YW5kIHdoZW4gdG8gdXNlIHZpZGVvIG9yIGF1ZGlvDQoNCkkgYmVsaWV2ZSB0aGUgRkVDIGlzIGFs d2F5cyBhcHBsaWNhdGlvbiB0eXBlLCB3ZSBkaWQgcmVnaXN0cmF0aW9uIGZvciB2aWRlbywgYXVk aW8sIGV0Yy4gc2luY2UgRkVDIGNvdWxkIHJlbGF0ZSB0byBzZXNzaW9ucyBjYXJyeWluZyBzdWNo IHR5cGVzLg0KDQpCUiwNCi1hY2JlZ2VuDQogDQo+ICANCj4gDQo+IFJvbmkNCj4gDQo+ICANCj4g DQo+IEZyb206IGF2dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXZ0LWJvdW5jZXNAaWV0Zi5v cmddIE9uIA0KPiBCZWhhbGYgT2YgQWxpIEMuIEJlZ2VuIChhYmVnZW4pDQo+IFNlbnQ6IFRodXJz ZGF5LCBBcHJpbCAzMCwgMjAwOSAzOjU0IFBNDQo+IFRvOiB2aW5jZW50LnJvY2FAaW5yaWFscGVz LmZyDQo+IENjOiBhdnRAaWV0Zi5vcmc7IGZlY2ZyYW1lQGlldGYub3JnDQo+IFN1YmplY3Q6IFJl OiBbQVZUXSBbRmVjZnJhbWVdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gDQo+IGZvciBk cmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUtMDQNCj4gDQo+ICANCj4g DQo+IEhpIFZpbmNlbnQNCj4gDQo+IFRoaXMgZHJhZnQgaXMgbm90IGFuIGZlYyBzY2hlbWUgc28g aXQgaXMgbm90IHJlbGF0ZWQgdG8gZmVjIA0KPiBmcmFtZXdvcmsuIEl0IGlzIGFuIHJ0cCBwYXls b2FkIGZvcm1hdCBkcmFmdC4gVGhlIHdnbGMgaGFzIA0KPiBiZWVuIHJ1bm5pbmcgYWxtb3N0IGEg bW9udGggbm93LiBJZiB5b3UgaGF2ZSBjb21tZW50cyBpbiB0aGlzIA0KPiBwZXJzcGVjdGl2ZSwg cGxzIHN1Ym1pdCB0aGVtIHNvb24uDQo+IA0KPiANCj4gDQo+IA0KPiAtYWNiZWdlbg0KPiANCj4g LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiBGcm9tOiBWaW5jZW50IFJvY2EgPHZpbmNl bnQucm9jYUBpbnJpYWxwZXMuZnI+DQo+IFRvOiBBbGkgQy4gQmVnZW4gKGFiZWdlbikNCj4gQ2M6 IGZlY2ZyYW1lQGlldGYub3JnIDxmZWNmcmFtZUBpZXRmLm9yZz47IGF2dEBpZXRmLm9yZyA8YXZ0 QGlldGYub3JnPg0KPiBTZW50OiBUaHUgQXByIDMwIDAzOjU4OjM1IDIwMDkNCj4gU3ViamVjdDog UmU6IFtGZWNmcmFtZV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgICAgICANCj4g ICBkcmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUtMDQNCj4gDQo+IEhl bGxvIEFsaSwNCj4gDQo+IEknbSBub3QgaW4gZmF2b3Igb2YgZmluYWxpemluZyB0aGUgV0dMQyBm b3IgdGhpcyBkb2N1bWVudC4gDQo+IElNSE8gd2UgbXVzdCwNCj4gZmlyc3Qgb2YgYWxsLCBmaW5h bGl6ZSB0aGUgZnJhbWV3b3JrIGRvY3VtZW50IGl0c2VsZi4NCj4gDQo+IEZvciBpbnN0YW5jZSwg dGhlIHRlcm1pbm9sb2d5IHVzZWQgYnkgdGhlIGludGVybGVhdmVkLWZlYy1zY2hlbWUgSS1EDQo+ IChzZWN0aW9uIDMuMS4pIGlzIG5vdCBpbiBsaW5lIHdpdGggdGhlIHRlcm1pbm9sb2d5IHVzZWQg YnkgdGhlDQo+IGZlY2ZyYW1lLWZyYW1ld29yay0wMyBJLUQgKFNlY3Rpb24gMik6DQo+ICAgICAg ICAgIlNvdXJjZSBGbG93IiAgIHZzLiAiU291cmNlIGRhdGEgZmxvdyINCj4gICAgICAgICAiUmVw YWlyIEZsb3ciICAgdnMuICJSZXBhaXIgZGF0YSBmbG93Ig0KPiAgICAgICAgICJTb3VyY2UgU3lt Ym9sIiB2cy4gbm90aGluZw0KPiAgICAgICAgICJSZXBhaXIgU3ltYm9sIiB2cy4gbm90aGluZw0K PiAgICAgICAgICJTb3VyY2UgUGFja2V0IiB2cy4gbm90aGluZw0KPiAgICAgICAgICJSZXBhaXIg UGFja2V0IiB2cy4gbm90aGluZw0KPiBBbmQgYXMgSSBzYWlkIGJlZm9yZSwgSU1ITyB0aGUgdGVy bWlub2xvZ3kgcHJvcG9zZWQgaW4gdGhlIGZyYW1ld29yaw0KPiBJLUQgc2hvdWxkIGJlIGRpc2N1 c3NlZCB0b28uDQo+IA0KPiBTbyBsZXQncyBkbyB0aGluZ3MgaW4gdGhlIHJpZ2h0IG9yZGVyLCBl c3BlY2lhbGx5IGFzIHRoZSBmcmFtZXdvcmsNCj4gV0dMQyBmaW5pc2hlcyBzb29uLg0KPiANCj4g QWRkaXRpb25hbGx5LCBJIG1heSBoYXZlIHNvbWUgY29tbWVudHMgZm9yIHRoZSANCj4gaW50ZXJs ZWF2ZWQtZmVjLXNjaGVtZS0wNA0KPiBJLUQuIFNpbmNlIEkgbWlzc2VkIHRoZSBXR0xDIGRlYWRs aW5lLCB5b3UgaGF2ZSB0aGUgcmlnaHQgdG8gDQo+IGJsYW1lIG1lIDstKQ0KPiBhbmQgSSBhcG9s b2dpemUgaW4gYWR2YW5jZS4NCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiAgIFZpbmNlbnQNCj4gDQo+ IA0KPiBBbGkgQy4gQmVnZW4gKGFiZWdlbikgd3JvdGU6DQo+ID4gVGhpcyB2ZXJzaW9uIGFkZHJl c3NlcyB0aGUgY29tbWVudHMgcmVjZWl2ZWQgZnJvbSBmZWNmcmFtZSANCj4gYW5kIGF2dCBzbyBm YXIuDQo+ID4gDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWll dGYtZmVjZnJhbWUtaW50ZXJsDQplYXZlZC1mZWMtc2NoZW1lLTA0LnR4dA0KPiA+DQo+ID4NCj4g PiBGZWNmcmFtZSBjaGFpcnMsDQo+ID4NCj4gPiBDb3VsZCB3ZSBwcm9jZWVkIGFuZCBmaW5hbGl6 ZSBXR0xDPw0KPiA+DQo+ID4gLWFjYmVnZW4NCj4gPiANCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogSUVURiBJLUQgU3VibWlzc2lvbiBUb29sIFttYWlsdG86 aWRzdWJtaXNzaW9uQGlldGYub3JnXQ0KPiA+IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjksIDIw MDkgMjo1NiBQTQ0KPiA+IFRvOiBBbGkgQy4gQmVnZW4gKGFiZWdlbikNCj4gPiBTdWJqZWN0OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIA0KPiBkcmFmdC1pZXRmLWZlY2ZyYW1lLWludGVy bGVhdmVkLWZlYy1zY2hlbWUtMDQNCj4gPg0KPiA+DQo+ID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQs IA0KPiBkcmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUtMDQudHh0IGhh cyBiZWVuIA0KPiBzdWNjZXNzZnVseSBzdWJtaXR0ZWQgYnkgQWxpIEJlZ2VuIGFuZCBwb3N0ZWQg dG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4gPg0KPiA+IEZpbGVuYW1lOiAgICAgIGRyYWZ0LWll dGYtZmVjZnJhbWUtaW50ZXJsZWF2ZWQtZmVjLXNjaGVtZQ0KPiA+IFJldmlzaW9uOiAgICAgIDA0 DQo+ID4gVGl0bGU6ICAgICAgICAgICAgICAgICBSVFAgUGF5bG9hZCBGb3JtYXQgZm9yIDEtRCAN Cj4gSW50ZXJsZWF2ZWQgUGFyaXR5IEZFQw0KPiA+IENyZWF0aW9uX2RhdGU6ICAgICAgICAgMjAw OS0wNC0yOQ0KPiA+IFdHIElEOiAgICAgICAgICAgICAgICAgZmVjZnJhbWUNCj4gPiBOdW1iZXJf b2ZfcGFnZXM6IDMxDQo+ID4NCj4gPiBBYnN0cmFjdDoNCj4gPiBUaGlzIGRvY3VtZW50IGRlZmlu ZXMgYSBuZXcgUlRQIHBheWxvYWQgZm9ybWF0IGZvciB0aGUgRm9yd2FyZCBFcnJvcg0KPiA+IENv cnJlY3Rpb24gKEZFQykgdGhhdCBpcyBnZW5lcmF0ZWQgYnkgdGhlIDEtRCBpbnRlcmxlYXZlZCAN Cj4gcGFyaXR5IGNvZGUNCj4gPiBmcm9tIGEgc291cmNlIG1lZGlhIGVuY2Fwc3VsYXRlZCBpbiBS VFAuICBUaGUgMS1EIGludGVybGVhdmVkIHBhcml0eQ0KPiA+IGNvZGUgaXMgYSBzeXN0ZW1hdGlj IGNvZGUsIHdoZXJlIGEgbnVtYmVyIG9mIHJlcGFpciBzeW1ib2xzIGFyZQ0KPiA+IGdlbmVyYXRl ZCBmcm9tIGEgc2V0IG9mIHNvdXJjZSBzeW1ib2xzIGFuZCBzZW50IGluIGEgcmVwYWlyIGZsb3cN Cj4gPiBzZXBhcmF0ZSBmcm9tIHRoZSBzb3VyY2UgZmxvdyB0aGF0IGNhcnJpZXMgdGhlIHNvdXJj ZSBzeW1ib2xzLiAgVGhlDQo+ID4gMS1EIGludGVybGVhdmVkIHBhcml0eSBjb2RlIG9mZmVycyBh IGdvb2QgcHJvdGVjdGlvbiBhZ2FpbnN0IGJ1cnN0eQ0KPiA+IHBhY2tldCBsb3NzZXMgYXQgYSBj b3N0IG9mIGRlY2VudCBjb21wbGV4aXR5LiAgVGhlIG5ldyANCj4gcGF5bG9hZCBmb3JtYXQNCj4g PiBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgaXMgdXNlZCAod2l0aCBzb21lIGV4Y2VwdGlvbnMp IGFzIGEgcGFydCBvZg0KPiA+IHRoZSBEVkIgQXBwbGljYXRpb24tbGF5ZXIgRkVDIHNwZWNpZmlj YXRpb24uDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQo+ICAgICAgICAgICAgICAgICAgICAgIA0KPiA+DQo+ID4NCj4gPiBU aGUgSUVURiBTZWNyZXRhcmlhdC4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBGZWNmcmFtZSBtYWlsaW5nIGxpc3QNCj4g PiBGZWNmcmFtZUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZmVjZnJhbWUNCj4gDQo+IA0K From ron.even.tlv@gmail.com Thu Apr 30 13:04:24 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 307563A690F; Thu, 30 Apr 2009 13:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFu-k+kCknyw; Thu, 30 Apr 2009 13:04:23 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 92FD73A6ABF; Thu, 30 Apr 2009 13:04:22 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 13so858761fge.18 for ; Thu, 30 Apr 2009 13:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=dGVbuOf5rMSrUoztJo+aNsJOYX5wNnsTRjEawC7paeM=; b=T/P5pXpCTgi0R3aZhtb+yk/PNNwt1/u1OHTeH83I3B8i9oCG/3tsvBou67tHlYXt+K 2Is2eb/WDyFYiw8mPZQ5pq5zi5PQo9t+fH4ofZ1GzmCAALMi7ZRoJ019KgvjTRLiXaEI ZzfniT0Nixd+u0mF4HDNQrQi7TB31okoeVEXo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=ak2KbA8/P+OPckqK0yFeI1IcVPKxGz6+uLIue3DZt2I7EwDBc7cSGg7KiC6jW0Qwq0 wWCFl3ggDxo8m7lSOCxgM3l8KmSsE61SrbJ/okWjYHMq7Sh/9qUmqHa0tGkUcZNcyZ40 xzlraY+8/Nmnw+GKZ02nkJt1G7pNthGsE51F0= Received: by 10.86.65.9 with SMTP id n9mr2206565fga.43.1241121945049; Thu, 30 Apr 2009 13:05:45 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-57-219.red.bezeqint.net [79.177.57.219]) by mx.google.com with ESMTPS id 4sm10946595fge.23.2009.04.30.13.05.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Apr 2009 13:05:44 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> <49f9ea83.0637560a.4488.62d2@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D540934913F@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540934913F@xmb-sjc-215.amer.cisco.com> Date: Thu, 30 Apr 2009 23:03:29 +0300 Message-ID: <49fa0498.0405560a.615f.677e@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnJgq+DQP1j7cRATQa6PC9zcfp8gAAD/6reAAsScqAAAXPloAAB7PmA Content-Language: en-us Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [AVT] [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 20:04:24 -0000 Ali, You can find examples in section 8.6 to 8.8 of RFC 4588, notice that = there is an optional parameter for the rtx stream that defines the = relation between the original and the rtx stream. Similar solution is = also specified for redundant encoding red payload type (RFC 2198). You = are offering both streams with different payload type numbers in the = same m-line. In this case the media type must be video or audio same as the media = type of the protected stream. This is why you needed the registration = for type audio and video Roni -----Original Message----- From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 Sent: Thursday, April 30, 2009 10:01 PM To: Roni Even; vincent.roca@inrialpes.fr Cc: avt@ietf.org; fecframe@ietf.org Subject: RE: [AVT] [Fecframe] FW: New Version Notification for = draft-ietf-fecframe-interleaved-fec-scheme-04 Hi Roni,=20 > I noticed that the fec framework will allow SSRC=20 Yes, it will not be the recommended way of using FEC, but it will be = supported. The 4756bis draft also supports it now. > multiplexing, are you going to specify this in this draft in=20 > the SDP offer answer section.=20 I am not sure what I need to specify additionally in this section = regarding SSRC multiplexing. Could you let me know if there is such an = example? =20 > Maybe you should also discuss when to use application media=20 > type and when to use video or audio I believe the FEC is always application type, we did registration for = video, audio, etc. since FEC could relate to sessions carrying such = types. BR, -acbegen =20 > =20 >=20 > Roni >=20 > =20 >=20 > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of Ali C. Begen (abegen) > Sent: Thursday, April 30, 2009 3:54 PM > To: vincent.roca@inrialpes.fr > Cc: avt@ietf.org; fecframe@ietf.org > Subject: Re: [AVT] [Fecframe] FW: New Version Notification=20 > for draft-ietf-fecframe-interleaved-fec-scheme-04 >=20 > =20 >=20 > Hi Vincent >=20 > This draft is not an fec scheme so it is not related to fec=20 > framework. It is an rtp payload format draft. The wglc has=20 > been running almost a month now. If you have comments in this=20 > perspective, pls submit them soon. >=20 >=20 >=20 >=20 > -acbegen >=20 > ----- Original Message ----- > From: Vincent Roca > To: Ali C. Begen (abegen) > Cc: fecframe@ietf.org ; avt@ietf.org > Sent: Thu Apr 30 03:58:35 2009 > Subject: Re: [Fecframe] FW: New Version Notification for =20 > draft-ietf-fecframe-interleaved-fec-scheme-04 >=20 > Hello Ali, >=20 > I'm not in favor of finalizing the WGLC for this document.=20 > IMHO we must, > first of all, finalize the framework document itself. >=20 > For instance, the terminology used by the interleaved-fec-scheme I-D > (section 3.1.) is not in line with the terminology used by the > fecframe-framework-03 I-D (Section 2): > "Source Flow" vs. "Source data flow" > "Repair Flow" vs. "Repair data flow" > "Source Symbol" vs. nothing > "Repair Symbol" vs. nothing > "Source Packet" vs. nothing > "Repair Packet" vs. nothing > And as I said before, IMHO the terminology proposed in the framework > I-D should be discussed too. >=20 > So let's do things in the right order, especially as the framework > WGLC finishes soon. >=20 > Additionally, I may have some comments for the=20 > interleaved-fec-scheme-04 > I-D. Since I missed the WGLC deadline, you have the right to=20 > blame me ;-) > and I apologize in advance. >=20 > Regards, >=20 > Vincent >=20 >=20 > Ali C. Begen (abegen) wrote: > > This version addresses the comments received from fecframe=20 > and avt so far. > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interl eaved-fec-scheme-04.txt > > > > > > Fecframe chairs, > > > > Could we proceed and finalize WGLC? > > > > -acbegen > >=20 > > > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: Wednesday, April 29, 2009 2:56 PM > > To: Ali C. Begen (abegen) > > Subject: New Version Notification for=20 > draft-ietf-fecframe-interleaved-fec-scheme-04 > > > > > > A new version of I-D,=20 > draft-ietf-fecframe-interleaved-fec-scheme-04.txt has been=20 > successfuly submitted by Ali Begen and posted to the IETF repository. > > > > Filename: draft-ietf-fecframe-interleaved-fec-scheme > > Revision: 04 > > Title: RTP Payload Format for 1-D=20 > Interleaved Parity FEC > > Creation_date: 2009-04-29 > > WG ID: fecframe > > Number_of_pages: 31 > > > > Abstract: > > This document defines a new RTP payload format for the Forward Error > > Correction (FEC) that is generated by the 1-D interleaved=20 > parity code > > from a source media encapsulated in RTP. The 1-D interleaved parity > > code is a systematic code, where a number of repair symbols are > > generated from a set of source symbols and sent in a repair flow > > separate from the source flow that carries the source symbols. The > > 1-D interleaved parity code offers a good protection against bursty > > packet losses at a cost of decent complexity. The new=20 > payload format > > defined in this document is used (with some exceptions) as a part of > > the DVB Application-layer FEC specification. > > =20 > =20 > > > > > > The IETF Secretariat. > > > > > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe >=20 >=20 From ron.even.tlv@gmail.com Thu Apr 30 13:13:19 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DA043A67F7 for ; Thu, 30 Apr 2009 13:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYi6vnMHubH5 for ; Thu, 30 Apr 2009 13:13:18 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 252D43A6B01 for ; Thu, 30 Apr 2009 13:13:17 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 13so859795fge.18 for ; Thu, 30 Apr 2009 13:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=CpWeM+qvG8Mt2qIDphnj0tyWhvrMjcgjiZbVN0CnJAE=; b=iI3DfZGJmLI8ncizkUAmPCGfRLsdu0o6gtsfbOOtq9KS95whjZrHPcQR6UGWGBO7W7 aknGiPuUudXXZdnhxEZ6Rqd/iCEvH9PfZWwaTQilZ9qSxG3kkmm1yc/2J3oZ+o798sqN EpzyxN/i7HgaC7FL8uRfJRVmbcfHXDAlmrGgs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; b=eWfE9sSFolk+VY75jZJaqfD+DE5J+dH1md+u29XtLClKLx1Sukkdbd4rEfF3r01GiX dkThSJb+qpjVWNqRrzShdV784c/aYkWk9C90c5zMfg7qcNah9zZPmCnrMyOGglBTpuaz IzFRbsvwDMfeeqoFIRa/zVljlAj3wm3OLIvtc= Received: by 10.86.49.13 with SMTP id w13mr2238420fgw.38.1241122480635; Thu, 30 Apr 2009 13:14:40 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-57-219.red.bezeqint.net [79.177.57.219]) by mx.google.com with ESMTPS id d6sm4257576fga.12.2009.04.30.13.14.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Apr 2009 13:14:40 -0700 (PDT) From: "Roni Even" To: Date: Thu, 30 Apr 2009 23:12:34 +0300 Message-ID: <49fa06b0.0637560a.430f.ffffb534@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C2_01C9C9E9.302C1C90" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnJz//7XHcxZE/BR5mcPjQI3rd8Qw== Content-Language: en-us Cc: 'Tom Taylor' Subject: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 20:13:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C2_01C9C9E9.302C1C90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I would like to ask if there is interest to adopt Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item. The suggestion is to start the work using http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp- 03 as the initial text for the work. I would also like to suggest that Bill Versteeg will be the editor of the WG document if adopted. Please send any feedback to the mailing list by Friday May 8th. If there will be a consensus we will accept this topic and have the above draft as the initial document. Thanks Roni Even AVT co-chair ------=_NextPart_000_00C2_01C9C9E9.302C1C90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I would like to ask if there is interest to adopt = Rapid = Acquisition of Multicast RTP Sessions (RAMS) as a working group item. The suggestion is = to start the work using http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchr= onization-for-rtp-03 as the initial text for the work.

 

I would also like to suggest that Bill Versteeg will be the editor of the = WG document if adopted.

 

Please send any feedback to the mailing list by Friday May 8th. = If there will be a consensus we will accept this topic and have the above = draft as the initial document.

 

Thanks

Roni Even

AVT co-chair

------=_NextPart_000_00C2_01C9C9E9.302C1C90-- From abegen@cisco.com Thu Apr 30 16:43:59 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 500FC3A6ABE; Thu, 30 Apr 2009 16:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.375 X-Spam-Level: X-Spam-Status: No, score=-6.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a905FygRRXFB; Thu, 30 Apr 2009 16:43:58 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 02E373A6AB5; Thu, 30 Apr 2009 16:43:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,275,1238976000"; d="scan'208";a="158172953" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 30 Apr 2009 23:45:21 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3UNjLZA004702; Thu, 30 Apr 2009 16:45:21 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3UNjLPk005582; Thu, 30 Apr 2009 23:45:21 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 16:45:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 30 Apr 2009 16:45:12 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540934937B@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49fa0498.0405560a.615f.677e@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 Thread-Index: AcnJgq+DQP1j7cRATQa6PC9zcfp8gAAD/6reAAsScqAAAXPloAAB7PmAAAfhEBA= References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> <49f9ea83.0637560a.4488.62d2@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D540934913F@xmb-sjc-215.amer.cisco.com> <49fa0498.0405560a.615f.677e@mx.google.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , X-OriginalArrivalTime: 30 Apr 2009 23:45:21.0332 (UTC) FILETIME=[B97F2740:01C9C9ED] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9998; t=1241135121; x=1241999121; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[AVT]=20[Fecframe]=20FW=3A=20New=20Vers ion=20Notification=09for=09draft-ietf-fecframe-interleaved-f ec-scheme-04 |Sender:=20; bh=SXNuIcS6QYlWbQ2Z63KMfPJ0z/ZtY2lPnkpmma7e60o=; b=gTkvPzWGoO6JWifyY/FdZ+GJxNW9A8FcFoWB0vR+CMHZWxpE9uPWlzeM8W rsgePUIV7MBufTL0fWSHALeDZj9Pp3+I4v/n4PB/tcODm1dZuO3EZ2z2MDX9 MhQVA+HJHS2Hrd7c2+scSDrO0/0qEz8kchMZBpmUrCd/vqNHCX418=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [AVT] [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 23:43:59 -0000 SGkgUm9uaSwNCg0KVGhhbmtzIGZvciB0aGUgcmVmZXJlbmNlcy4gSG93ZXZlciwgd2UgY2Fubm90 IGhhdmUgYSBwYXJhbWV0ZXIgdGhhdCB3aWxsIHJlbGF0ZSB0aGUgRkVDIHN0cmVhbSB0byB0aGUg c291cmNlIGFzIFJGQyA0NTg4IGRpZCB3aXRoICJhcHQiIHNpbmNlIGEgbG90IG9mIHBvc3NpYmls aXRpZXMgKG11bHRpcGxlIHNvdXJjZXMgYW5kL29yIG11bHRpcGxlIHJlcGFpciBmbG93cykgYXJl IHBvc3NpYmxlIHdpdGggRkVDLiBJbnN0ZWFkLCB3ZSB1c2UgZ3JvdXBpbmcgYW5kIHRoaXMgd29y a3MganVzdCBmaW5lIGluIHNlc3Npb24gbXVsdGlwbGV4aW5nLg0KDQpSZWdhcmRpbmcgU1NSQyBt dWx0aXBsZXhpbmcgb2Ygc291cmNlIGFuZCBGRUMgc3RyZWFtcywgSSBkb24ndCB0aGluayBnaXZp bmcgYW4gZXhwbGljaXQgZXhhbXBsZSBpcyBuZWVkZWQgb3IgaXQgaXMgYSBnb29kIGlkZWEgZm9y IHRoaXMgZHJhZnQgc2luY2UgU1NSQy1sZXZlbCBncm91cGluZyBpcyBqdXN0IGludHJvZHVjZWQg aW4gNDc1NmJpcyBhbmQgaXQgd2lsbCBpbmNsdWRlIHN1Y2ggZXhhbXBsZXMgYW55d2F5IChhY3R1 YWxseSB0aGUgdmVyc2lvbiBJIHN1Ym1pdHRlZCB0b2RheSBpbmNsdWRlcyBhbiBleGFtcGxlKS4g V2Ugc2hvdWxkIGJldHRlciBvbmx5IHByb3ZpZGUgc2Vzc2lvbiBtdWx0aXBsZXhpbmcgZXhhbXBs ZXMgaW4gdGhpcyBkcmFmdC4gVGhpcyBhbHNvIGVtcGhhc2l6ZXMgdGhlIHJlY29tbWVuZGVkIHdh eSBvZiBkb2luZyBGRUMuDQoNClJlZyB0aGUgcmVnaXN0cmF0aW9uIG9mIHRoZSBtZWRpYSB0eXBl cyBhbmQgU0RQIG1hcHBpbmdzLCBJIGJlbGlldmUgdGhlIGRyYWZ0IGhhcyB0aGUgbmVjZXNzYXJ5 IGRldGFpbHMuDQoNCkJSLA0KLWFjYmVnZW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBSb25pIEV2ZW4gW21haWx0bzpyb24uZXZlbi50bHZAZ21haWwuY29tXSANCj4g U2VudDogVGh1cnNkYXksIEFwcmlsIDMwLCAyMDA5IDE6MDMgUE0NCj4gVG86IEFsaSBDLiBCZWdl biAoYWJlZ2VuKTsgdmluY2VudC5yb2NhQGlucmlhbHBlcy5mcg0KPiBDYzogYXZ0QGlldGYub3Jn OyBmZWNmcmFtZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW0FWVF0gW0ZlY2ZyYW1lXSBGVzog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIA0KPiBmb3IgZHJhZnQtaWV0Zi1mZWNmcmFtZS1pbnRl cmxlYXZlZC1mZWMtc2NoZW1lLTA0DQo+IA0KPiBBbGksDQo+IFlvdSBjYW4gZmluZCBleGFtcGxl cyBpbiBzZWN0aW9uIDguNiB0byA4Ljggb2YgUkZDIDQ1ODgsIA0KPiBub3RpY2UgdGhhdCB0aGVy ZSBpcyBhbiBvcHRpb25hbCBwYXJhbWV0ZXIgZm9yIHRoZSBydHggc3RyZWFtIA0KPiB0aGF0IGRl ZmluZXMgdGhlIHJlbGF0aW9uIGJldHdlZW4gdGhlIG9yaWdpbmFsIGFuZCB0aGUgcnR4IA0KPiBz dHJlYW0uIFNpbWlsYXIgc29sdXRpb24gaXMgYWxzbyBzcGVjaWZpZWQgZm9yIHJlZHVuZGFudCAN Cj4gZW5jb2RpbmcgcmVkIHBheWxvYWQgdHlwZSAoUkZDIDIxOTgpLiBZb3UgYXJlIG9mZmVyaW5n IGJvdGggDQo+IHN0cmVhbXMgd2l0aCBkaWZmZXJlbnQgcGF5bG9hZCB0eXBlIG51bWJlcnMgaW4g dGhlIHNhbWUgbS1saW5lLg0KPiBJbiB0aGlzIGNhc2UgdGhlIG1lZGlhIHR5cGUgbXVzdCBiZSB2 aWRlbyBvciBhdWRpbyBzYW1lIGFzIA0KPiB0aGUgbWVkaWEgdHlwZSBvZiB0aGUgcHJvdGVjdGVk IHN0cmVhbS4gVGhpcyBpcyB3aHkgeW91IA0KPiBuZWVkZWQgdGhlIHJlZ2lzdHJhdGlvbiBmb3Ig dHlwZSBhdWRpbyBhbmQgdmlkZW8NCj4gDQo+IFJvbmkNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IEFsaSBDLiBCZWdlbiAoYWJlZ2VuKSBbbWFpbHRvOmFiZWdlbkBj aXNjby5jb21dIA0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMzAsIDIwMDkgMTA6MDEgUE0NCj4g VG86IFJvbmkgRXZlbjsgdmluY2VudC5yb2NhQGlucmlhbHBlcy5mcg0KPiBDYzogYXZ0QGlldGYu b3JnOyBmZWNmcmFtZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW0FWVF0gW0ZlY2ZyYW1lXSBG VzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIA0KPiBmb3IgZHJhZnQtaWV0Zi1mZWNmcmFtZS1p bnRlcmxlYXZlZC1mZWMtc2NoZW1lLTA0DQo+IA0KPiBIaSBSb25pLCANCj4gDQo+ID4gSSBub3Rp Y2VkIHRoYXQgdGhlIGZlYyBmcmFtZXdvcmsgd2lsbCBhbGxvdyBTU1JDIA0KPiANCj4gWWVzLCBp dCB3aWxsIG5vdCBiZSB0aGUgcmVjb21tZW5kZWQgd2F5IG9mIHVzaW5nIEZFQywgYnV0IGl0IA0K PiB3aWxsIGJlIHN1cHBvcnRlZC4gVGhlIDQ3NTZiaXMgZHJhZnQgYWxzbyBzdXBwb3J0cyBpdCBu b3cuDQo+IA0KPiA+IG11bHRpcGxleGluZywgYXJlIHlvdSBnb2luZyB0byBzcGVjaWZ5IHRoaXMg aW4gdGhpcyBkcmFmdCBpbiANCj4gPiB0aGUgU0RQIG9mZmVyIGFuc3dlciBzZWN0aW9uLiANCj4g DQo+IEkgYW0gbm90IHN1cmUgd2hhdCBJIG5lZWQgdG8gc3BlY2lmeSBhZGRpdGlvbmFsbHkgaW4g dGhpcyANCj4gc2VjdGlvbiByZWdhcmRpbmcgU1NSQyBtdWx0aXBsZXhpbmcuIENvdWxkIHlvdSBs ZXQgbWUga25vdyBpZiANCj4gdGhlcmUgaXMgc3VjaCBhbiBleGFtcGxlPw0KPiAgDQo+ID4gTWF5 YmUgeW91IHNob3VsZCBhbHNvIGRpc2N1c3Mgd2hlbiB0byB1c2UgYXBwbGljYXRpb24gbWVkaWEg DQo+ID4gdHlwZSBhbmQgd2hlbiB0byB1c2UgdmlkZW8gb3IgYXVkaW8NCj4gDQo+IEkgYmVsaWV2 ZSB0aGUgRkVDIGlzIGFsd2F5cyBhcHBsaWNhdGlvbiB0eXBlLCB3ZSBkaWQgDQo+IHJlZ2lzdHJh dGlvbiBmb3IgdmlkZW8sIGF1ZGlvLCBldGMuIHNpbmNlIEZFQyBjb3VsZCByZWxhdGUgdG8gDQo+ IHNlc3Npb25zIGNhcnJ5aW5nIHN1Y2ggdHlwZXMuDQo+IA0KPiBCUiwNCj4gLWFjYmVnZW4NCj4g IA0KPiA+ICANCj4gPiANCj4gPiBSb25pDQo+ID4gDQo+ID4gIA0KPiA+IA0KPiA+IEZyb206IGF2 dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXZ0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIA0KPiA+ IEJlaGFsZiBPZiBBbGkgQy4gQmVnZW4gKGFiZWdlbikNCj4gPiBTZW50OiBUaHVyc2RheSwgQXBy aWwgMzAsIDIwMDkgMzo1NCBQTQ0KPiA+IFRvOiB2aW5jZW50LnJvY2FAaW5yaWFscGVzLmZyDQo+ ID4gQ2M6IGF2dEBpZXRmLm9yZzsgZmVjZnJhbWVAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTog W0FWVF0gW0ZlY2ZyYW1lXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIA0KPiA+IGZvciBk cmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUtMDQNCj4gPiANCj4gPiAg DQo+ID4gDQo+ID4gSGkgVmluY2VudA0KPiA+IA0KPiA+IFRoaXMgZHJhZnQgaXMgbm90IGFuIGZl YyBzY2hlbWUgc28gaXQgaXMgbm90IHJlbGF0ZWQgdG8gZmVjIA0KPiA+IGZyYW1ld29yay4gSXQg aXMgYW4gcnRwIHBheWxvYWQgZm9ybWF0IGRyYWZ0LiBUaGUgd2dsYyBoYXMgDQo+ID4gYmVlbiBy dW5uaW5nIGFsbW9zdCBhIG1vbnRoIG5vdy4gSWYgeW91IGhhdmUgY29tbWVudHMgaW4gdGhpcyAN Cj4gPiBwZXJzcGVjdGl2ZSwgcGxzIHN1Ym1pdCB0aGVtIHNvb24uDQo+ID4gDQo+ID4gDQo+ID4g DQo+ID4gDQo+ID4gLWFjYmVnZW4NCj4gPiANCj4gPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t LS0tDQo+ID4gRnJvbTogVmluY2VudCBSb2NhIDx2aW5jZW50LnJvY2FAaW5yaWFscGVzLmZyPg0K PiA+IFRvOiBBbGkgQy4gQmVnZW4gKGFiZWdlbikNCj4gPiBDYzogZmVjZnJhbWVAaWV0Zi5vcmcg PGZlY2ZyYW1lQGlldGYub3JnPjsgYXZ0QGlldGYub3JnIA0KPiA8YXZ0QGlldGYub3JnPg0KPiA+ IFNlbnQ6IFRodSBBcHIgMzAgMDM6NTg6MzUgMjAwOQ0KPiA+IFN1YmplY3Q6IFJlOiBbRmVjZnJh bWVdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yICAgICAgDQo+ID4gICBkcmFmdC1p ZXRmLWZlY2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUtMDQNCj4gPiANCj4gPiBIZWxsbyBB bGksDQo+ID4gDQo+ID4gSSdtIG5vdCBpbiBmYXZvciBvZiBmaW5hbGl6aW5nIHRoZSBXR0xDIGZv ciB0aGlzIGRvY3VtZW50LiANCj4gPiBJTUhPIHdlIG11c3QsDQo+ID4gZmlyc3Qgb2YgYWxsLCBm aW5hbGl6ZSB0aGUgZnJhbWV3b3JrIGRvY3VtZW50IGl0c2VsZi4NCj4gPiANCj4gPiBGb3IgaW5z dGFuY2UsIHRoZSB0ZXJtaW5vbG9neSB1c2VkIGJ5IHRoZSBpbnRlcmxlYXZlZC1mZWMtc2NoZW1l IEktRA0KPiA+IChzZWN0aW9uIDMuMS4pIGlzIG5vdCBpbiBsaW5lIHdpdGggdGhlIHRlcm1pbm9s b2d5IHVzZWQgYnkgdGhlDQo+ID4gZmVjZnJhbWUtZnJhbWV3b3JrLTAzIEktRCAoU2VjdGlvbiAy KToNCj4gPiAgICAgICAgICJTb3VyY2UgRmxvdyIgICB2cy4gIlNvdXJjZSBkYXRhIGZsb3ciDQo+ ID4gICAgICAgICAiUmVwYWlyIEZsb3ciICAgdnMuICJSZXBhaXIgZGF0YSBmbG93Ig0KPiA+ICAg ICAgICAgIlNvdXJjZSBTeW1ib2wiIHZzLiBub3RoaW5nDQo+ID4gICAgICAgICAiUmVwYWlyIFN5 bWJvbCIgdnMuIG5vdGhpbmcNCj4gPiAgICAgICAgICJTb3VyY2UgUGFja2V0IiB2cy4gbm90aGlu Zw0KPiA+ICAgICAgICAgIlJlcGFpciBQYWNrZXQiIHZzLiBub3RoaW5nDQo+ID4gQW5kIGFzIEkg c2FpZCBiZWZvcmUsIElNSE8gdGhlIHRlcm1pbm9sb2d5IHByb3Bvc2VkIGluIHRoZSBmcmFtZXdv cmsNCj4gPiBJLUQgc2hvdWxkIGJlIGRpc2N1c3NlZCB0b28uDQo+ID4gDQo+ID4gU28gbGV0J3Mg ZG8gdGhpbmdzIGluIHRoZSByaWdodCBvcmRlciwgZXNwZWNpYWxseSBhcyB0aGUgZnJhbWV3b3Jr DQo+ID4gV0dMQyBmaW5pc2hlcyBzb29uLg0KPiA+IA0KPiA+IEFkZGl0aW9uYWxseSwgSSBtYXkg aGF2ZSBzb21lIGNvbW1lbnRzIGZvciB0aGUgDQo+ID4gaW50ZXJsZWF2ZWQtZmVjLXNjaGVtZS0w NA0KPiA+IEktRC4gU2luY2UgSSBtaXNzZWQgdGhlIFdHTEMgZGVhZGxpbmUsIHlvdSBoYXZlIHRo ZSByaWdodCB0byANCj4gPiBibGFtZSBtZSA7LSkNCj4gPiBhbmQgSSBhcG9sb2dpemUgaW4gYWR2 YW5jZS4NCj4gPiANCj4gPiBSZWdhcmRzLA0KPiA+IA0KPiA+ICAgVmluY2VudA0KPiA+IA0KPiA+ IA0KPiA+IEFsaSBDLiBCZWdlbiAoYWJlZ2VuKSB3cm90ZToNCj4gPiA+IFRoaXMgdmVyc2lvbiBh ZGRyZXNzZXMgdGhlIGNvbW1lbnRzIHJlY2VpdmVkIGZyb20gZmVjZnJhbWUgDQo+ID4gYW5kIGF2 dCBzbyBmYXIuDQo+ID4gPiANCj4gPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybA0KPiBlYXZlZC1mZWMtc2NoZW1lLTA0LnR4dA0K PiA+ID4NCj4gPiA+DQo+ID4gPiBGZWNmcmFtZSBjaGFpcnMsDQo+ID4gPg0KPiA+ID4gQ291bGQg d2UgcHJvY2VlZCBhbmQgZmluYWxpemUgV0dMQz8NCj4gPiA+DQo+ID4gPiAtYWNiZWdlbg0KPiA+ ID4gDQo+ID4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206 IElFVEYgSS1EIFN1Ym1pc3Npb24gVG9vbCBbbWFpbHRvOmlkc3VibWlzc2lvbkBpZXRmLm9yZ10N Cj4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjksIDIwMDkgMjo1NiBQTQ0KPiA+ID4gVG86 IEFsaSBDLiBCZWdlbiAoYWJlZ2VuKQ0KPiA+ID4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciANCj4gPiBkcmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hl bWUtMDQNCj4gPiA+DQo+ID4gPg0KPiA+ID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIA0KPiA+IGRy YWZ0LWlldGYtZmVjZnJhbWUtaW50ZXJsZWF2ZWQtZmVjLXNjaGVtZS0wNC50eHQgaGFzIGJlZW4g DQo+ID4gc3VjY2Vzc2Z1bHkgc3VibWl0dGVkIGJ5IEFsaSBCZWdlbiBhbmQgcG9zdGVkIHRvIHRo ZSBJRVRGIA0KPiByZXBvc2l0b3J5Lg0KPiA+ID4NCj4gPiA+IEZpbGVuYW1lOiAgICAgIGRyYWZ0 LWlldGYtZmVjZnJhbWUtaW50ZXJsZWF2ZWQtZmVjLXNjaGVtZQ0KPiA+ID4gUmV2aXNpb246ICAg ICAgMDQNCj4gPiA+IFRpdGxlOiAgICAgICAgICAgICAgICAgUlRQIFBheWxvYWQgRm9ybWF0IGZv ciAxLUQgDQo+ID4gSW50ZXJsZWF2ZWQgUGFyaXR5IEZFQw0KPiA+ID4gQ3JlYXRpb25fZGF0ZTog ICAgICAgICAyMDA5LTA0LTI5DQo+ID4gPiBXRyBJRDogICAgICAgICAgICAgICAgIGZlY2ZyYW1l DQo+ID4gPiBOdW1iZXJfb2ZfcGFnZXM6IDMxDQo+ID4gPg0KPiA+ID4gQWJzdHJhY3Q6DQo+ID4g PiBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgUlRQIHBheWxvYWQgZm9ybWF0IGZvciB0aGUg DQo+IEZvcndhcmQgRXJyb3INCj4gPiA+IENvcnJlY3Rpb24gKEZFQykgdGhhdCBpcyBnZW5lcmF0 ZWQgYnkgdGhlIDEtRCBpbnRlcmxlYXZlZCANCj4gPiBwYXJpdHkgY29kZQ0KPiA+ID4gZnJvbSBh IHNvdXJjZSBtZWRpYSBlbmNhcHN1bGF0ZWQgaW4gUlRQLiAgVGhlIDEtRCANCj4gaW50ZXJsZWF2 ZWQgcGFyaXR5DQo+ID4gPiBjb2RlIGlzIGEgc3lzdGVtYXRpYyBjb2RlLCB3aGVyZSBhIG51bWJl ciBvZiByZXBhaXIgc3ltYm9scyBhcmUNCj4gPiA+IGdlbmVyYXRlZCBmcm9tIGEgc2V0IG9mIHNv dXJjZSBzeW1ib2xzIGFuZCBzZW50IGluIGEgcmVwYWlyIGZsb3cNCj4gPiA+IHNlcGFyYXRlIGZy b20gdGhlIHNvdXJjZSBmbG93IHRoYXQgY2FycmllcyB0aGUgc291cmNlIA0KPiBzeW1ib2xzLiAg VGhlDQo+ID4gPiAxLUQgaW50ZXJsZWF2ZWQgcGFyaXR5IGNvZGUgb2ZmZXJzIGEgZ29vZCBwcm90 ZWN0aW9uIA0KPiBhZ2FpbnN0IGJ1cnN0eQ0KPiA+ID4gcGFja2V0IGxvc3NlcyBhdCBhIGNvc3Qg b2YgZGVjZW50IGNvbXBsZXhpdHkuICBUaGUgbmV3IA0KPiA+IHBheWxvYWQgZm9ybWF0DQo+ID4g PiBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgaXMgdXNlZCAod2l0aCBzb21lIGV4Y2VwdGlvbnMp IA0KPiBhcyBhIHBhcnQgb2YNCj4gPiA+IHRoZSBEVkIgQXBwbGljYXRpb24tbGF5ZXIgRkVDIHNw ZWNpZmljYXRpb24uDQo+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCj4gPiAgICAgICAgICAgICAgICAgICAgICANCj4gPiA+ DQo+ID4gPg0KPiA+ID4gVGhlIElFVEYgU2VjcmV0YXJpYXQuDQo+ID4gPg0KPiA+ID4NCj4gPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBG ZWNmcmFtZSBtYWlsaW5nIGxpc3QNCj4gPiA+IEZlY2ZyYW1lQGlldGYub3JnDQo+ID4gPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZlY2ZyYW1lDQo+ID4gDQo+ID4gDQo+ IA0KPiANCg== From ron.even.tlv@gmail.com Thu Apr 30 23:57:16 2009 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEF8E3A6F3F; Thu, 30 Apr 2009 23:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67wLWRqiBjoW; Thu, 30 Apr 2009 23:57:15 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 9AECA3A6E0A; Thu, 30 Apr 2009 23:57:14 -0700 (PDT) Received: by bwz7 with SMTP id 7so2193054bwz.37 for ; Thu, 30 Apr 2009 23:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=vNj7MudDL3Env6XYGraqiWWyG8SkfD6TWM9T1I7p1TI=; b=rnJd2W6F9qvHbEyn4KFO68BlqOx6xKFwjDb5YBAve0pNliXIMRcUacj4V/SB6dvDG/ gMCeKtf1RyTCh/myYh9Uzf8CFI3equK+nwDeRvH1P6rwq2aZR+6ZPUKjS57/T5IPVxSM 8lgG/YlLqS7JK9YepDVbTvQTAd2wLM5jLjwvQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=FNvMN0Q/IaX88zU67BMQ2nwiFc80gOgDrZKQRes4Y1m1bUapMDGmsnFHnHv5xF+b8y SZXdghgRceL6f0M6Vj/pRUfgYoQ0GeelAaTXiLpePv6iPdyeNJZBe1zpfoIoddSuHofS vkpVoRLEeUzBqXBvUE36h/Sg0kAuRRRUJjbHw= Received: by 10.86.68.1 with SMTP id q1mr2616470fga.34.1241161117214; Thu, 30 Apr 2009 23:58:37 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-57-219.red.bezeqint.net [79.177.57.219]) by mx.google.com with ESMTPS id 3sm288086fge.14.2009.04.30.23.58.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Apr 2009 23:58:36 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> <49f9ea83.0637560a.4488.62d2@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D540934913F@xmb-sjc-215.amer.cisco.com> <49fa0498.0405560a.615f.677e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D540934937B@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540934937B@xmb-sjc-215.amer.cisco.com> Date: Fri, 1 May 2009 09:56:31 +0300 Message-ID: <49fa9d9c.0305560a.5885.7b1f@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnJgq+DQP1j7cRATQa6PC9zcfp8gAAD/6reAAsScqAAAXPloAAB7PmAAAfhEBAAD01A8A== Content-Language: en-us Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [AVT] [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 06:57:16 -0000 Hi Ali, This is up to the WG to decide if they want to have support for SSRC = multiplexing and the implications of this support. I am not sure what = you mean by "we cannot have a parameter", I see only your view on the = list. If only session multiplexing is allowed then the draft should clearly = state it and in this case I am not sure why you are registering the = video, audio and text media subtypes. Roni -----Original Message----- From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 Sent: Friday, May 01, 2009 2:45 AM To: Roni Even; vincent.roca@inrialpes.fr Cc: avt@ietf.org; fecframe@ietf.org Subject: RE: [AVT] [Fecframe] FW: New Version Notification for = draft-ietf-fecframe-interleaved-fec-scheme-04 Hi Roni, Thanks for the references. However, we cannot have a parameter that will = relate the FEC stream to the source as RFC 4588 did with "apt" since a = lot of possibilities (multiple sources and/or multiple repair flows) are = possible with FEC. Instead, we use grouping and this works just fine in = session multiplexing. Regarding SSRC multiplexing of source and FEC streams, I don't think = giving an explicit example is needed or it is a good idea for this draft = since SSRC-level grouping is just introduced in 4756bis and it will = include such examples anyway (actually the version I submitted today = includes an example). We should better only provide session multiplexing = examples in this draft. This also emphasizes the recommended way of = doing FEC. Reg the registration of the media types and SDP mappings, I believe the = draft has the necessary details. BR, -acbegen > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > Sent: Thursday, April 30, 2009 1:03 PM > To: Ali C. Begen (abegen); vincent.roca@inrialpes.fr > Cc: avt@ietf.org; fecframe@ietf.org > Subject: RE: [AVT] [Fecframe] FW: New Version Notification=20 > for draft-ietf-fecframe-interleaved-fec-scheme-04 >=20 > Ali, > You can find examples in section 8.6 to 8.8 of RFC 4588,=20 > notice that there is an optional parameter for the rtx stream=20 > that defines the relation between the original and the rtx=20 > stream. Similar solution is also specified for redundant=20 > encoding red payload type (RFC 2198). You are offering both=20 > streams with different payload type numbers in the same m-line. > In this case the media type must be video or audio same as=20 > the media type of the protected stream. This is why you=20 > needed the registration for type audio and video >=20 > Roni >=20 > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > Sent: Thursday, April 30, 2009 10:01 PM > To: Roni Even; vincent.roca@inrialpes.fr > Cc: avt@ietf.org; fecframe@ietf.org > Subject: RE: [AVT] [Fecframe] FW: New Version Notification=20 > for draft-ietf-fecframe-interleaved-fec-scheme-04 >=20 > Hi Roni,=20 >=20 > > I noticed that the fec framework will allow SSRC=20 >=20 > Yes, it will not be the recommended way of using FEC, but it=20 > will be supported. The 4756bis draft also supports it now. >=20 > > multiplexing, are you going to specify this in this draft in=20 > > the SDP offer answer section.=20 >=20 > I am not sure what I need to specify additionally in this=20 > section regarding SSRC multiplexing. Could you let me know if=20 > there is such an example? > =20 > > Maybe you should also discuss when to use application media=20 > > type and when to use video or audio >=20 > I believe the FEC is always application type, we did=20 > registration for video, audio, etc. since FEC could relate to=20 > sessions carrying such types. >=20 > BR, > -acbegen > =20 > > =20 > >=20 > > Roni > >=20 > > =20 > >=20 > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > > Behalf Of Ali C. Begen (abegen) > > Sent: Thursday, April 30, 2009 3:54 PM > > To: vincent.roca@inrialpes.fr > > Cc: avt@ietf.org; fecframe@ietf.org > > Subject: Re: [AVT] [Fecframe] FW: New Version Notification=20 > > for draft-ietf-fecframe-interleaved-fec-scheme-04 > >=20 > > =20 > >=20 > > Hi Vincent > >=20 > > This draft is not an fec scheme so it is not related to fec=20 > > framework. It is an rtp payload format draft. The wglc has=20 > > been running almost a month now. If you have comments in this=20 > > perspective, pls submit them soon. > >=20 > >=20 > >=20 > >=20 > > -acbegen > >=20 > > ----- Original Message ----- > > From: Vincent Roca > > To: Ali C. Begen (abegen) > > Cc: fecframe@ietf.org ; avt@ietf.org=20 > > > Sent: Thu Apr 30 03:58:35 2009 > > Subject: Re: [Fecframe] FW: New Version Notification for =20 > > draft-ietf-fecframe-interleaved-fec-scheme-04 > >=20 > > Hello Ali, > >=20 > > I'm not in favor of finalizing the WGLC for this document.=20 > > IMHO we must, > > first of all, finalize the framework document itself. > >=20 > > For instance, the terminology used by the interleaved-fec-scheme I-D > > (section 3.1.) is not in line with the terminology used by the > > fecframe-framework-03 I-D (Section 2): > > "Source Flow" vs. "Source data flow" > > "Repair Flow" vs. "Repair data flow" > > "Source Symbol" vs. nothing > > "Repair Symbol" vs. nothing > > "Source Packet" vs. nothing > > "Repair Packet" vs. nothing > > And as I said before, IMHO the terminology proposed in the framework > > I-D should be discussed too. > >=20 > > So let's do things in the right order, especially as the framework > > WGLC finishes soon. > >=20 > > Additionally, I may have some comments for the=20 > > interleaved-fec-scheme-04 > > I-D. Since I missed the WGLC deadline, you have the right to=20 > > blame me ;-) > > and I apologize in advance. > >=20 > > Regards, > >=20 > > Vincent > >=20 > >=20 > > Ali C. Begen (abegen) wrote: > > > This version addresses the comments received from fecframe=20 > > and avt so far. > > >=20 > > http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interl > eaved-fec-scheme-04.txt > > > > > > > > > Fecframe chairs, > > > > > > Could we proceed and finalize WGLC? > > > > > > -acbegen > > >=20 > > > > > > -----Original Message----- > > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > > Sent: Wednesday, April 29, 2009 2:56 PM > > > To: Ali C. Begen (abegen) > > > Subject: New Version Notification for=20 > > draft-ietf-fecframe-interleaved-fec-scheme-04 > > > > > > > > > A new version of I-D,=20 > > draft-ietf-fecframe-interleaved-fec-scheme-04.txt has been=20 > > successfuly submitted by Ali Begen and posted to the IETF=20 > repository. > > > > > > Filename: draft-ietf-fecframe-interleaved-fec-scheme > > > Revision: 04 > > > Title: RTP Payload Format for 1-D=20 > > Interleaved Parity FEC > > > Creation_date: 2009-04-29 > > > WG ID: fecframe > > > Number_of_pages: 31 > > > > > > Abstract: > > > This document defines a new RTP payload format for the=20 > Forward Error > > > Correction (FEC) that is generated by the 1-D interleaved=20 > > parity code > > > from a source media encapsulated in RTP. The 1-D=20 > interleaved parity > > > code is a systematic code, where a number of repair symbols are > > > generated from a set of source symbols and sent in a repair flow > > > separate from the source flow that carries the source=20 > symbols. The > > > 1-D interleaved parity code offers a good protection=20 > against bursty > > > packet losses at a cost of decent complexity. The new=20 > > payload format > > > defined in this document is used (with some exceptions)=20 > as a part of > > > the DVB Application-layer FEC specification. > > > =20 > > =20 > > > > > > > > > The IETF Secretariat. > > > > > > > > > _______________________________________________ > > > Fecframe mailing list > > > Fecframe@ietf.org > > > https://www.ietf.org/mailman/listinfo/fecframe > >=20 > >=20 >=20 >=20