From Peter.Stevens@bbc.co.uk Wed Sep 4 06:09:17 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B73021F9F40 for ; Wed, 4 Sep 2013 06:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAUUsH5fBroy for ; Wed, 4 Sep 2013 06:09:12 -0700 (PDT) Received: from mailout0.thls.bbc.co.uk (mailout0.thls.bbc.co.uk [132.185.240.35]) by ietfa.amsl.com (Postfix) with ESMTP id E683A11E816F for ; Wed, 4 Sep 2013 06:09:11 -0700 (PDT) Received: from BGB01XI1009.national.core.bbc.co.uk (bgb01xi1009.national.core.bbc.co.uk [10.161.14.23]) by mailout0.thls.bbc.co.uk (8.14.4/8.14.3) with ESMTP id r84D94nf003244; Wed, 4 Sep 2013 14:09:05 +0100 (BST) Received: from BGB01XUD1002.national.core.bbc.co.uk ([169.254.11.246]) by BGB01XI1009.national.core.bbc.co.uk ([10.161.14.23]) with mapi id 14.02.0342.003; Wed, 4 Sep 2013 14:09:04 +0100 From: Peter Stevens To: "John Lindsay (Lindsay@worldcastsystems.com)" , "'payload@ietf.org'" Thread-Topic: Re: [payload] I-D Action: draft-ietf-payload-rtp-aptx-00.txt Thread-Index: Ac6pb+yV9qXp2OBbR9a6jPbN2JKFbw== Date: Wed, 4 Sep 2013 13:09:01 +0000 Message-ID: <2F938AAE444ADB47AFEE6307955A30CE1656E89F@BGB01XUD1002.national.core.bbc.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.14.10] x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769 Content-Type: multipart/alternative; boundary="_000_2F938AAE444ADB47AFEE6307955A30CE1656E89FBGB01XUD1002nat_" MIME-Version: 1.0 Cc: "'Foerster@worldcastsystems.com'" Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-aptx-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 13:10:48 -0000 --_000_2F938AAE444ADB47AFEE6307955A30CE1656E89FBGB01XUD1002nat_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJ4oCZdmUgcmVhZCB0aHJvdWdoIHRoaXMgZHJhZnQgUkZDIGFuZCBkaWQgbm90 aWNlIGEgY291cGxlIG9mIG1pbm9yIGVkaXRvcmlhbCBpdGVtcyBmb3IgeW91ciBhdHRlbnRpb246 DQoNCkNsYXVzZSA2LjIuMSBTRFAgVXNhZ2UgRXhhbXBsZXMsIEV4YW1wbGUgMSwgY3VycmVudGx5 Og0KDQpFeGFtcGxlIDE6IEFuIHN0YW5kYXJkIOKApg0KDQpDbGF1c2UgNi4yLjEgU0RQIFVzYWdl IEV4YW1wbGVzLCBFeGFtcGxlIDEsIGNoYW5nZSB0bzoNCg0KRXhhbXBsZSAxOiBBIHN0YW5kYXJk IOKApg0KDQpDbGF1c2UgNyBJQU5BIENvbnNpZGVyYXRpb25zLCBTZWNvbmQgc2VudGVuY2UgY3Vy cmVudGx5Og0KDQpTZWUgU2VjdGlvbiA3LjENCg0KQ2xhdXNlIDcgSUFOQSBDb25zaWRlcmF0aW9u cywgU2Vjb25kIHNlbnRlbmNlLCBzaG91bGQgdGhpcyBiZSAoSeKAmW0gYXNzdW1pbmcgdGhhdCB0 aGUgcmVmZXJlbmNlIGlzIHdpdGhpbiB0aGUgc2FtZSBkb2N1bWVudCBhbmQgbm90IGluIG9uZSBv ZiB0aGUgcmVmZXJyZWQgdG8gUkZDKToNCg0KU2VlIFNlY3Rpb24gNi4xDQoNCkFsdGhvdWdoIEkg Y2Fubm90IHNwZWFrIG9mZmljaWFsbHkgZm9yIHRoZSBCQkMsIHRoZSBCQkMgYWxyZWFkeSB1c2Vz IGJvdGggU3RhbmRhcmQgYXB0LVggYW5kIEVuaGFuY2VkIGFwdC1YIGF1ZGlvIGNvZGVjcyB3aXRo aW4gcHJvZHVjdHMgYW5kIGl0IGlzIG11Y2ggYmV0dGVyIGZvciB1cyB0byBoYXZlIHByb2R1Y3Rz IGFuZCBhbGdvcml0aG1zIHRoYXQgYXJlIGJhc2VkIG9uIGludGVybmF0aW9uYWwgc3RhbmRhcmRz LCBpbiBwYXJ0aWN1bGFyIHRvIGFsbG93IHByb2R1Y3RzIG9mIGRpZmZlcmVudCBtYW51ZmFjdHVy ZSBvcmlnaW4gdG8gd29yayB0b2dldGhlciB3aGVuIHVzaW5nIHRoZSBzYW1lIGNvZGVjLg0KDQpB ZGRpdGlvbmFsbHksIHNpbWlsYXJseSwgSSBjYW5ub3Qgc3BlYWsgb2ZmaWNpYWxseSBmb3IgdGhl IEVCVSBBQ0lQIElJIEdyb3VwLCBidXQgaW5jbHVzaW9uIG9mIHRoaXMgUkZDIGludG8gb3VyIHRl Y2huaWNhbCBkb2N1bWVudCBvbiBpbnRlcm9wZXJhYmlsaXR5IGlzIGltcG9ydGFudCBhbmQgY2Fu IG9ubHkgb2NjdXIgaWYgaXQgc3VjY2VlZHMgdG8gb2ZmaWNpYWwgSUVURiBSRkMgU3RhbmRhcmRz IFRyYWNrLg0KDQpTbywgcGVyc29uYWxseSwgSSB3b3VsZCBzdXBwb3J0IGl0cyBpbnRlbmRlZCBz dGF0dXMuDQoNCkJlc3QgcmVnYXJkcywNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpQZXRlciBT dGV2ZW5zDQpSZXNlYXJjaCBFbmdpbmVlcg0KDQpCQkMgUmVzZWFyY2ggJiBEZXZlbG9wbWVudA0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0KaHR0cDovL3d3dy5iYmMuY28udWsNClRoaXMgZS1tYWlsIChhbmQgYW55IGF0dGFjaG1l bnRzKSBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHBlcnNvbmFsIHZpZXdzIHdoaWNo IGFyZSBub3QgdGhlIHZpZXdzIG9mIHRoZSBCQkMgdW5sZXNzIHNwZWNpZmljYWxseSBzdGF0ZWQu DQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBmcm9t IHlvdXIgc3lzdGVtLg0KRG8gbm90IHVzZSwgY29weSBvciBkaXNjbG9zZSB0aGUgaW5mb3JtYXRp b24gaW4gYW55IHdheSBub3IgYWN0IGluIHJlbGlhbmNlIG9uIGl0IGFuZCBub3RpZnkgdGhlIHNl bmRlciBpbW1lZGlhdGVseS4NClBsZWFzZSBub3RlIHRoYXQgdGhlIEJCQyBtb25pdG9ycyBlLW1h aWxzIHNlbnQgb3IgcmVjZWl2ZWQuDQpGdXJ0aGVyIGNvbW11bmljYXRpb24gd2lsbCBzaWduaWZ5 IHlvdXIgY29uc2VudCB0byB0aGlzLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== --_000_2F938AAE444ADB47AFEE6307955A30CE1656E89FBGB01XUD1002nat_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjwhLS0gVGVtcGxhdGUgZ2VuZXJhdGVkIGJ5IEV4Y2xh aW1lciBNYWlsIERpc2NsYWltZXJzIG9uIDAyOjA5OjA0IFdlZG5lc2RheSwgNCBTZXB0ZW1iZXIg MjAxMyAtLT4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+UC5kMWNlYWRiYS1j NTVhLTQ3M2MtYWNiMy00ZTdjMGMzM2Y4M2Qgew0KCU1BUkdJTjogMGNtIDBjbSAwcHQNCn0NCkxJ LmQxY2VhZGJhLWM1NWEtNDczYy1hY2IzLTRlN2MwYzMzZjgzZCB7DQoJTUFSR0lOOiAwY20gMGNt IDBwdA0KfQ0KRElWLmQxY2VhZGJhLWM1NWEtNDczYy1hY2IzLTRlN2MwYzMzZjgzZCB7DQoJTUFS R0lOOiAwY20gMGNtIDBwdA0KfQ0KVEFCTEUuZDFjZWFkYmEtYzU1YS00NzNjLWFjYjMtNGU3YzBj MzNmODNkVGFibGUgew0KCU1BUkdJTjogMGNtIDBjbSAwcHQNCn0NCkRJVi5TZWN0aW9uMSB7DQoJ cGFnZTogU2VjdGlvbjENCn0NCjwvc3R5bGU+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5j aG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg NCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFu b3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxwIGNsYXNzPSJk MWNlYWRiYS1jNTVhLTQ3M2MtYWNiMy00ZTdjMGMzM2Y4M2QiPjwvcD4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+SGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+SeKAmXZlIHJlYWQgdGhyb3VnaCB0aGlzIGRyYWZ0IFJGQyBhbmQgZGlkIG5vdGljZSBhIGNv dXBsZSBvZiBtaW5vciBlZGl0b3JpYWwgaXRlbXMgZm9yIHlvdXIgYXR0ZW50aW9uOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Q2xhdXNlIDYuMi4xIFNEUCBVc2Fn ZSBFeGFtcGxlcywgRXhhbXBsZSAxLCBjdXJyZW50bHk6PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjM2LjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDozNi4wcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij5FeGFtcGxlIDE6IEFuIHN0YW5kYXJkIOKApjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Q2xhdXNlIDYuMi4xIFNEUCBVc2FnZSBFeGFt cGxlcywgRXhhbXBsZSAxLCBjaGFuZ2UgdG86PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVu dDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5FeGFtcGxlIDE6IEEgc3Rh bmRhcmQg4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5DbGF1 c2UgNyBJQU5BIENvbnNpZGVyYXRpb25zLCBTZWNvbmQgc2VudGVuY2UgY3VycmVudGx5OjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+U2VlIFNlY3Rpb24gNy4xPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij5DbGF1c2UgNyBJQU5BIENvbnNpZGVyYXRpb25zLCBTZWNvbmQgc2VudGVuY2Us IHNob3VsZCB0aGlzIGJlIChJ4oCZbSBhc3N1bWluZyB0aGF0IHRoZSByZWZlcmVuY2UgaXMgd2l0 aGluIHRoZSBzYW1lIGRvY3VtZW50IGFuZCBub3QgaW4gb25lIG9mIHRoZSByZWZlcnJlZCB0byBS RkMpOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+U2VlIFNlY3Rpb24gNi4xPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij5BbHRob3VnaCBJIGNhbm5vdCBzcGVhayBvZmZpY2lhbGx5IGZv ciB0aGUgQkJDLCB0aGUgQkJDIGFscmVhZHkgdXNlcyBib3RoIFN0YW5kYXJkIGFwdC1YIGFuZCBF bmhhbmNlZCBhcHQtWCBhdWRpbyBjb2RlY3Mgd2l0aGluIHByb2R1Y3RzIGFuZCBpdCBpcyBtdWNo IGJldHRlciBmb3IgdXMgdG8gaGF2ZSBwcm9kdWN0cyBhbmQgYWxnb3JpdGhtcyB0aGF0IGFyZQ0K IGJhc2VkIG9uIGludGVybmF0aW9uYWwgc3RhbmRhcmRzLCBpbiBwYXJ0aWN1bGFyIHRvIGFsbG93 IHByb2R1Y3RzIG9mIGRpZmZlcmVudCBtYW51ZmFjdHVyZSBvcmlnaW4gdG8gd29yayB0b2dldGhl ciB3aGVuIHVzaW5nIHRoZSBzYW1lIGNvZGVjLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+QWRkaXRpb25hbGx5LCBzaW1pbGFybHksIEkgY2Fubm90IHNwZWFrIG9m ZmljaWFsbHkgZm9yIHRoZSBFQlUgQUNJUCBJSSBHcm91cCwgYnV0IGluY2x1c2lvbiBvZiB0aGlz IFJGQyBpbnRvIG91ciB0ZWNobmljYWwgZG9jdW1lbnQgb24gaW50ZXJvcGVyYWJpbGl0eSBpcyBp bXBvcnRhbnQgYW5kIGNhbiBvbmx5IG9jY3VyIGlmIGl0IHN1Y2NlZWRzIHRvIG9mZmljaWFsDQog SUVURiBSRkMgU3RhbmRhcmRzIFRyYWNrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+U28sIHBlcnNvbmFsbHksIEkgd291bGQgc3VwcG9ydCBpdHMgaW50ZW5kZWQg c3RhdHVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QmVzdCBy ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ PGJyPg0KUGV0ZXIgU3RldmVuczxicj4NClJlc2VhcmNoIEVuZ2luZWVyPGJyPg0KPGJyPg0KQkJD IFJlc2VhcmNoICZhbXA7IERldmVsb3BtZW50PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cD48L3A+DQo8cCBjbGFzcz0iZDFjZWFkYmEtYzU1YS00NzNj LWFjYjMtNGU3YzBjMzNmODNkIj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iZDFjZWFkYmEtYzU1YS00 NzNjLWFjYjMtNGU3YzBjMzNmODNkIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0K PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Zm9udCBzaXplPSIzIiBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PGJyPg0KPGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YSBocmVmPSJodHRw Oi8vd3d3LmJiYy5jby51ayIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuPHNwYW4gY2xhc3M9 ImlsIj5iYmM8L3NwYW4+LjxzcGFuIGNsYXNzPSJpbCI+Y288L3NwYW4+LjxzcGFuIGNsYXNzPSJp bCI+dWs8L3NwYW4+PC9hPjxicj4NClRoaXMgZS1tYWlsIChhbmQgYW55IGF0dGFjaG1lbnRzKSBp cyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHBlcnNvbmFsIHZpZXdzIHdoaWNoIGFyZSBu b3QgdGhlIHZpZXdzIG9mIHRoZQ0KPHNwYW4gY2xhc3M9ImlsIj5CQkM8L3NwYW4+IHVubGVzcyBz cGVjaWZpY2FsbHkgc3RhdGVkLjxicj4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9y LCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0uPGJyPg0KRG8gbm90IHVzZSwgY29w eSBvciBkaXNjbG9zZSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IHdheSBub3IgYWN0IGluIHJlbGlh bmNlIG9uIGl0IGFuZCBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseS48YnI+DQpQbGVhc2Ug bm90ZSB0aGF0IHRoZSA8c3BhbiBjbGFzcz0iaWwiPkJCQzwvc3Bhbj4gbW9uaXRvcnMgZS1tYWls cyBzZW50IG9yIHJlY2VpdmVkLjxicj4NCkZ1cnRoZXIgY29tbXVuaWNhdGlvbiB3aWxsIHNpZ25p ZnkgeW91ciBjb25zZW50IHRvIHRoaXMuPC9mb250PjwvZm9udD48L2ZvbnQ+PC9mb250PjwvcD4N CjxwIGNsYXNzPSJkMWNlYWRiYS1jNTVhLTQ3M2MtYWNiMy00ZTdjMGMzM2Y4M2QiPi0tLS0tLS0t LS0tLS0tLS0tLS0tLTwvcD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2F938AAE444ADB47AFEE6307955A30CE1656E89FBGB01XUD1002nat_-- From internet-drafts@ietf.org Fri Sep 6 00:55:34 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3373B11E8173; Fri, 6 Sep 2013 00:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bb8uiyYp9bW2; Fri, 6 Sep 2013 00:54:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA45811E80C5; Fri, 6 Sep 2013 00:54:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130906075453.13307.93411.idtracker@ietfa.amsl.com> Date: Fri, 06 Sep 2013 00:54:53 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-aptx-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 07:55:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Working Gr= oup of the IETF. Title : RTP Payload Format for Standard apt-X and Enhanced apt-X= Codecs Author(s) : John Lindsay Hartmut Foerster Filename : draft-ietf-payload-rtp-aptx-01.txt Pages : 22 Date : 2013-09-05 Abstract: This document specifies a scheme for packetizing Standard apt-X, or Enhanced apt-X, encoded audio data into Real-time Transport Protocol (RTP) packets. The document describes a payload format that permits transmission of multiple related audio channels in a single RTP payload, and a means of establishing Standard apt-X and Enhanced apt-X connections through the Session Description Protocol (SDP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-aptx There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-aptx-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-aptx-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tlegrand@google.com Fri Sep 6 05:15:28 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A35821E80E3 for ; Fri, 6 Sep 2013 05:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.144 X-Spam-Level: X-Spam-Status: No, score=-1.144 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22gPnwKyVHEl for ; Fri, 6 Sep 2013 05:15:27 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 66F4221E80B3 for ; Fri, 6 Sep 2013 05:15:27 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id u16so6454710iet.20 for ; Fri, 06 Sep 2013 05:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=xxAFwpzj9hGwVlGvcZ+zWTSnN69Hvks1V7adcvZdKhE=; b=DCyw7GAaahg1l/O9OQYv/THhLxMKpKjJMeb22q/EcBBcauXNk63Ak06MrlqHCGvBpV qfAkbSqABiRuDL3o/0qnkmi87Gh8pftZaOVyjDbPA9QF8ANPz+RCz8hyEHc0VOQ3hoqA WFu3KgZ6zVrt2TLcuCLKoRxzYOdqxFHf8dj0d0KY5SUGGecXyxBG1XOdKEjqLGmZ+BE3 wd9NyPRDzI8Q/NMiVL127Ruv/cbO50+LPf/g4fyFNPv/4jUK2DAxKqbNcx4VyWeZ5vGG VfjYtip1gov47JYYBF6eTMdlx08WEjpOgyWEbGL7nzlboIq2y9FuDAHTDvacAhBpxIIP dRxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:content-type; bh=xxAFwpzj9hGwVlGvcZ+zWTSnN69Hvks1V7adcvZdKhE=; b=fj213A+e8mlwaI9yB7d7LyiJkT/hYBnAD9wFUTXMujzvQwN6Q71TDaKop2v+NdCeFq sqrW5Rv8eukVD9eVJWcL9seLO4qNwJOtjS9gyJtseG+pzLstajjeRuEfEM2UDfue9Wn9 1kIhbdnEjY33yOEYqpZQ8l99UbZYUT7J4L/9mP+6zWXo/lvEml+1pbDc7TPjig/asLIL YGjUQp+eG8pua1mvWvWU4XAT5+x+1gxZ+x6e1q14VpMibOzsV+Rrfw/VrPYJ1C60NPhH pUN8IyEHCX4LiY7Ht+2BGTFGYvqZzAJJ6pmN8QZmZXamIZCSkY6rpdQ+jI+U536H3Gg8 NeDQ== X-Gm-Message-State: ALoCoQk2UHVwfNclMxfte0/wsfzq+etksNaJdNbYQv8qVehkzOryKr8Eowc6ER2LxrXj4jamUfPqIzFP4QmkhNZdH8HT644zEzWdCHqqEBMoTYayMahqDlvqDtIqTYL0b4/egh7BgQnSYNNIvELx5zNlFhfBmfi/IxCJHTLep6QH0kpklU064gyfJ2cnQzZGrWn6HEb2O+El X-Received: by 10.42.82.73 with SMTP id c9mr1256813icl.32.1378469726662; Fri, 06 Sep 2013 05:15:26 -0700 (PDT) MIME-Version: 1.0 Sender: tlegrand@google.com Received: by 10.64.26.165 with HTTP; Fri, 6 Sep 2013 05:15:06 -0700 (PDT) From: Tina le Grand Date: Fri, 6 Sep 2013 14:15:06 +0200 X-Google-Sender-Auth: Ro0Ij9wn_CwBdJOhNUruqAwTdyM Message-ID: To: payload@ietf.org Content-Type: multipart/alternative; boundary=20cf303345836448c304e5b5fe5f Subject: [payload] Comment to draft-ietf-payload-rtp-opus-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 12:15:28 -0000 --20cf303345836448c304e5b5fe5f Content-Type: text/plain; charset=ISO-8859-1 In section 3.1.3 Discontinuous Transmission (DTX), I'm missing some text that explains how to update the RTP packets correctly after a silent period. How should rtp timestamp and sequence number be updated while not sending rtp packets (silent period), to prepare for when we eventually have data to transmit again? My thinking is that rtp timestamp should be updated with the number of samples that were not sent, while sequence number should only be updated when sending packets. Correct? /Tina le Grand. --20cf303345836448c304e5b5fe5f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In section 3.1.3 Discontinuous Transmission (DTX), I'm= missing some text that explains how to update the RTP packets correctly af= ter a silent period. How should rtp timestamp and sequence number be update= d while not sending rtp packets (silent period), to prepare for when we eve= ntually have data to transmit again? My thinking is that rtp timestamp shou= ld be updated with the number of samples that were not sent, while sequence= number should only be updated when sending packets. Correct?

/Tina le Grand.
--20cf303345836448c304e5b5fe5f-- From internet-drafts@ietf.org Fri Sep 6 08:53:39 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1AFF21F9E89; Fri, 6 Sep 2013 08:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjK98sKdxtpl; Fri, 6 Sep 2013 08:53:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DCF21F9E0A; Fri, 6 Sep 2013 08:53:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130906155338.4333.68101.idtracker@ietfa.amsl.com> Date: Fri, 06 Sep 2013 08:53:38 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 15:53:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Working Gr= oup of the IETF. Title : RTP Payload Format for High Efficiency Video Coding Author(s) : Ye-Kui Wang Yago Sanchez Thomas Schierl Stephan Wenger Miska M. Hannuksela Filename : draft-ietf-payload-rtp-h265-01.txt Pages : 76 Date : 2013-09-06 Abstract: This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) [HEVC], developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC stream over a single as well as multiple RTP flows. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-h265-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-h265-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yekuiw@qti.qualcomm.com Fri Sep 6 09:06:55 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B79F21E80C2; Fri, 6 Sep 2013 09:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQDXPMskwxvX; Fri, 6 Sep 2013 09:06:43 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id B30C621E80C1; Fri, 6 Sep 2013 09:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1378483602; x=1410019602; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=hh14xbDrCxgzIAZCWFO0CyQhSY5DUmSej5mghsJfdYU=; b=ESOnIVZVhLfF6BAG3R4WHy1J+r7kwwpWf2t+xzODIRqjd7PsTPevfWeJ +Xc5AFmP2cwL6zcj8gfL56Ux2x1jDvO2ceFYY/iB5xB/j98bIPgHuM2b4 +USNuJO1oEgtHsGcX86Y+9GJhT9OxLSKMROFz5p93QnDuirFbCFcWfi4E o=; X-IronPort-AV: E=McAfee;i="5400,1158,7189"; a="50973909" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP; 06 Sep 2013 09:06:42 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7189"; a="596696717" Received: from nasanexhc17.na.qualcomm.com ([10.45.158.129]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 06 Sep 2013 09:06:42 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.196]) by NASANEXHC17.na.qualcomm.com ([10.45.158.129]) with mapi id 14.03.0146.002; Fri, 6 Sep 2013 09:06:42 -0700 From: "Wang, Ye-Kui" To: "payload@ietf.org" , "avt@ietf.org" Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-h265-01.txt Thread-Index: AQHOqxlDBXq4DcuMK02tZyMRQbIdrpm43bQg Date: Fri, 6 Sep 2013 16:06:41 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A833851F152@nasanexd02f.na.qualcomm.com> References: <20130906155338.4333.68101.idtracker@ietfa.amsl.com> In-Reply-To: <20130906155338.4333.68101.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 16:06:55 -0000 Dear All, The main changes (in addition to some other, basically editorial, changes) = compared to -00 are: - Added the media type parameter dec-parallel-cap that was agreed in Berlin - Added media type parameters max-fps, max-tr, and max-tc as agreed on the = reflector - Added an informative note on detection of the last NAL unit of an AU afte= r the semantics of the M bit as agreed on the reflector Comments are welcome! BR, YK > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > Behalf Of internet-drafts@ietf.org > Sent: Friday, September 06, 2013 8:54 AM > To: i-d-announce@ietf.org > Cc: payload@ietf.org > Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Audio/Video Transport Payloads Working > Group of the IETF. >=20 > Title : RTP Payload Format for High Efficiency Video Coding > Author(s) : Ye-Kui Wang > Yago Sanchez > Thomas Schierl > Stephan Wenger > Miska M. Hannuksela > Filename : draft-ietf-payload-rtp-h265-01.txt > Pages : 76 > Date : 2013-09-06 >=20 > Abstract: > This memo describes an RTP payload format for the video coding > standard ITU-T Recommendation H.265 and ISO/IEC International > Standard 23008-2, both also known as High Efficiency Video Coding > (HEVC) [HEVC], developed by the Joint Collaborative Team on Video > Coding (JCT-VC). The RTP payload format allows for packetization of > one or more Network Abstraction Layer (NAL) units in each RTP packet > payload, as well as fragmentation of a NAL unit into multiple RTP > packets. Furthermore, it supports transmission of an HEVC stream > over a single as well as multiple RTP flows. The payload format has > wide applicability in videoconferencing, Internet video streaming, > and high bit-rate entertainment-quality video, among others. >=20 >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265 >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-payload-rtp-h265-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-h265-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From jmvalin@mozilla.com Fri Sep 6 12:19:48 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A125011E80F3 for ; Fri, 6 Sep 2013 12:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-bX5VBb7U87 for ; Fri, 6 Sep 2013 12:19:43 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFD011E8193 for ; Fri, 6 Sep 2013 12:19:42 -0700 (PDT) Received: from [192.168.1.15] (modemcable130.97-201-24.mc.videotron.ca [24.201.97.130]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 9E41CF250C; Fri, 6 Sep 2013 12:19:40 -0700 (PDT) Message-ID: <522A2ACB.9030809@mozilla.com> Date: Fri, 06 Sep 2013 15:19:39 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Tina le Grand References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: payload@ietf.org Subject: Re: [payload] Comment to draft-ietf-payload-rtp-opus-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 19:19:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/06/2013 08:15 AM, Tina le Grand wrote: > In section 3.1.3 Discontinuous Transmission (DTX), I'm missing some > text that explains how to update the RTP packets correctly after a > silent period. How should rtp timestamp and sequence number be > updated while not sending rtp packets (silent period), to prepare > for when we eventually have data to transmit again? My thinking is > that rtp timestamp should be updated with the number of samples > that were not sent, while sequence number should only be updated > when sending packets. Correct? That's also my understanding, but I'm far from an expert on this. Can anyone with good knowledge of RTP confirm that it's the right thing to do? Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSKirLAAoJEJ6/8sItn9q97+MH+gMeS7L1FzqITx9lnOSsbMCQ FKSFoTkp8TgiHaNY2bhoGNO0S/OzvxF5tHnWyg6euaEOUDU5IYIQZqwRHEoGVnGT 2oDmZHJPIC9EC3QydeyVyEblPXXJ1wSia+5LoijGkuwFFsn2yEMcIAXtBA3nTJsG PK9GrfKiWdIUcg9mi7+cAohWN4Sl5Xc2NQXf+Q/DoUEaRdDJoxw23wN4XHVMsBNZ 3fkmEHMlFbgPW+Ddga06hmio5pdwrle9qLPEjxOYOP311D4fk9ALWT9GdXzkbI1F 2GhtYVIgOo4RuE79vJcawP8NTl0qzTtXsXyP1eJpuUDhXEX1R+li4yeJByCZFZY= =zPUo -----END PGP SIGNATURE----- From roman@telurix.com Fri Sep 6 12:46:59 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6C411E80FF for ; Fri, 6 Sep 2013 12:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZvAMdqCVez5 for ; Fri, 6 Sep 2013 12:46:54 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id 4123411E80E7 for ; Fri, 6 Sep 2013 12:46:54 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hm2so1347237wib.10 for ; Fri, 06 Sep 2013 12:46:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dc5JUbPIrEEWTZdSuwpuQ+1osCj/hNXkGkB2elWtnKE=; b=UFr+263i41p/NzV3WSlnzKcYdxvuhT6mIEbvwjirOb2EJkI8jKl23bre8uZr2tAOyM GMGYLHVLP+BDVJNDMAMTEc5CVVLBKy9J8JW3CjfoRjTydVBPf/OOJZlJcbO4gZDpOC8+ Vd+fflL69MzAvzuy7Jsf+tYYIWhla7ai/puNiV/zjIktORHnD0pt+zE3ZXi5kDR+qi2S 4TGRIF1xvCRnW726jHCHPGYGSzCBrpvLtJucVZZmIeeGBWew2AK1omnsIUV9g0jVkcWE PDIDN2My2gptkOiDEDgfKoDseRfbo7lgrcyySdyPd2csY/sn72N2wtcvRgrKDi45yJe3 sqCw== X-Gm-Message-State: ALoCoQmpGDR+fVDiuyytlEdlUMzVD1HTqs+BYru6htRTeHCHDENwlK3F0V2yrpVp1qaLoxGyZRPN X-Received: by 10.180.100.202 with SMTP id fa10mr11563599wib.8.1378496812025; Fri, 06 Sep 2013 12:46:52 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [2a00:1450:400c:c03::235]) by mx.google.com with ESMTPSA id pn7sm6406789wic.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Sep 2013 12:46:51 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p61so2338341wes.12 for ; Fri, 06 Sep 2013 12:46:50 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.181.11.163 with SMTP id ej3mr3237551wid.47.1378496810581; Fri, 06 Sep 2013 12:46:50 -0700 (PDT) Received: by 10.216.26.1 with HTTP; Fri, 6 Sep 2013 12:46:50 -0700 (PDT) In-Reply-To: <522A2ACB.9030809@mozilla.com> References: <522A2ACB.9030809@mozilla.com> Date: Fri, 6 Sep 2013 15:46:50 -0400 Message-ID: From: Roman Shpount To: Jean-Marc Valin Content-Type: multipart/alternative; boundary=f46d043be1e0b8083504e5bc4c29 Cc: payload@ietf.org Subject: Re: [payload] Comment to draft-ietf-payload-rtp-opus-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 19:46:59 -0000 --f46d043be1e0b8083504e5bc4c29 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 6, 2013 at 3:19 PM, Jean-Marc Valin wrote: > On 09/06/2013 08:15 AM, Tina le Grand wrote: > > In section 3.1.3 Discontinuous Transmission (DTX), I'm missing some > > text that explains how to update the RTP packets correctly after a > > silent period. How should rtp timestamp and sequence number be > > updated while not sending rtp packets (silent period), to prepare > > for when we eventually have data to transmit again? My thinking is > > that rtp timestamp should be updated with the number of samples > > that were not sent, while sequence number should only be updated > > when sending packets. Correct? > > That's also my understanding, but I'm far from an expert on this. Can > anyone with good knowledge of RTP confirm that it's the right thing to do? > > In my experience and according to RFC 3551 this is the right thing to do. Furthermore, the first packet of a talkspurt, that is, the first packet after a silence period during which packets have not been transmitted contiguously, SHOULD be distinguished by setting the marker bit in the RTP data header to one. Also, since this is already standard behavior for all audio codecs according to RFC 3551 there is probably no need to define this behavior specifically for OPUS. _____________ Roman Shpount --f46d043be1e0b8083504e5bc4c29 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Fri, Sep 6, 2013 at 3:19 PM, Jean-Marc Valin <jmvalin@mozilla.com= > wrote:
On 09/06/2013 08:15 AM, T= ina le Grand wrote:
> In section 3.1.3 Discontinuous Transmission (DTX), I'm missing som= e
> text that explains how to update the RTP packets correctly after a
> silent period. How should rtp timestamp and sequence number be
> updated while not sending rtp packets (silent period), to prepare
> for when we eventually have data to transmit again? My thinking is
> that rtp timestamp should be updated with the number of samples
> that were not sent, while sequence number should only be updated
> when sending packets. Correct?

That's also my understanding, but I'm far from an expert on this. C= an
anyone with good knowledge of RTP confirm that it's the right thing to = do?


In my experience and according to RFC 3551= this is the right thing to do. Furthermore, the first packet of a talkspur= t, that is, the first packet after a silence period during which packets ha= ve not been transmitted contiguously, SHOULD be distinguished by setting th= e marker bit in the RTP data header to one. Also, since this is already sta= ndard behavior for all audio codecs according to RFC 3551 there is probably= no need to define this behavior specifically for OPUS.
_____________
Roman Shpount

--f46d043be1e0b8083504e5bc4c29-- From mzanaty@cisco.com Fri Sep 6 13:10:23 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FD611E80E7 for ; Fri, 6 Sep 2013 13:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euVFtnjpdETq for ; Fri, 6 Sep 2013 13:10:18 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0200F21E8054 for ; Fri, 6 Sep 2013 13:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1982; q=dns/txt; s=iport; t=1378498213; x=1379707813; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QdJGVN0U42AAW3asau8kw1mGo0WlPV7VTQriAhQN4gg=; b=KRrwZLMYTYAWAZjwCGbpV5jKUyCz6xegQLC4D11PrI5T/NAnS12eUPVp iFoKJf4TnM9+2LL4jpEwZDzpHI512a+G5k8hzsh2MrkH87qpTfvhfEeys OMyqMx9hqMtsXSYTbDSxdZRXrl8YPAXohg+OPTumt3Jx34N4e377uSZr0 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFADE2KlKtJXG//2dsb2JhbABbgwc1UcFcgSYWdIIkAQEBBAEBATcxAwsMBAIBCBEEAQEBChQJBycLFAkIAgQBDQUIh3oMvVKPSzEHBoMXgQADqVuDIIIq X-IronPort-AV: E=Sophos;i="4.90,856,1371081600"; d="scan'208";a="256439655" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 06 Sep 2013 20:10:11 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r86KABN6025406 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Sep 2013 20:10:11 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.101]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Fri, 6 Sep 2013 15:10:10 -0500 From: "Mo Zanaty (mzanaty)" To: Jean-Marc Valin , Tina le Grand Thread-Topic: [payload] Comment to draft-ietf-payload-rtp-opus-01 Thread-Index: AQHOqzYPEBTQ7vcIU0+kKfbQFjcxZJm5G62g Date: Fri, 6 Sep 2013 20:10:10 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D527125@xmb-rcd-x14.cisco.com> References: <522A2ACB.9030809@mozilla.com> In-Reply-To: <522A2ACB.9030809@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.29.189] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "payload@ietf.org" Subject: Re: [payload] Comment to draft-ietf-payload-rtp-opus-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 20:10:23 -0000 That's correct. See RFC 3551 section 4.1. Since Opus DTX mode uses receiver concealment and comfort noise, it may be = good to specify that the generic CN payload (RFC 3389) should not be used w= ith Opus. Mo -----Original Message----- From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Jean-Marc Valin Sent: Friday, September 06, 2013 3:20 PM To: Tina le Grand Cc: payload@ietf.org Subject: Re: [payload] Comment to draft-ietf-payload-rtp-opus-01 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/06/2013 08:15 AM, Tina le Grand wrote: > In section 3.1.3 Discontinuous Transmission (DTX), I'm missing some > text that explains how to update the RTP packets correctly after a > silent period. How should rtp timestamp and sequence number be > updated while not sending rtp packets (silent period), to prepare > for when we eventually have data to transmit again? My thinking is > that rtp timestamp should be updated with the number of samples > that were not sent, while sequence number should only be updated > when sending packets. Correct? That's also my understanding, but I'm far from an expert on this. Can anyone with good knowledge of RTP confirm that it's the right thing to do? Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSKirLAAoJEJ6/8sItn9q97+MH+gMeS7L1FzqITx9lnOSsbMCQ FKSFoTkp8TgiHaNY2bhoGNO0S/OzvxF5tHnWyg6euaEOUDU5IYIQZqwRHEoGVnGT 2oDmZHJPIC9EC3QydeyVyEblPXXJ1wSia+5LoijGkuwFFsn2yEMcIAXtBA3nTJsG PK9GrfKiWdIUcg9mi7+cAohWN4Sl5Xc2NQXf+Q/DoUEaRdDJoxw23wN4XHVMsBNZ 3fkmEHMlFbgPW+Ddga06hmio5pdwrle9qLPEjxOYOP311D4fk9ALWT9GdXzkbI1F 2GhtYVIgOo4RuE79vJcawP8NTl0qzTtXsXyP1eJpuUDhXEX1R+li4yeJByCZFZY=3D =3DzPUo -----END PGP SIGNATURE----- _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From jmvalin@mozilla.com Fri Sep 6 14:19:18 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6009311E80F5 for ; Fri, 6 Sep 2013 14:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIu4nVlQw03U for ; Fri, 6 Sep 2013 14:19:07 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9401811E80E8 for ; Fri, 6 Sep 2013 14:19:07 -0700 (PDT) Received: from [192.168.1.15] (modemcable130.97-201-24.mc.videotron.ca [24.201.97.130]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id ACF5AF232D; Fri, 6 Sep 2013 14:19:05 -0700 (PDT) Message-ID: <522A46C8.9040904@mozilla.com> Date: Fri, 06 Sep 2013 17:19:04 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Roman Shpount References: <522A2ACB.9030809@mozilla.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: payload@ietf.org Subject: Re: [payload] Comment to draft-ietf-payload-rtp-opus-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 21:19:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/06/2013 03:46 PM, Roman Shpount wrote: > In my experience and according to RFC 3551 this is the right thing > to do. Furthermore, the first packet of a talkspurt, that is, the > first packet after a silence period during which packets have not > been transmitted contiguously, SHOULD be distinguished by setting > the marker bit in the RTP data header to one. Also, since this is > already standard behavior for all audio codecs according to RFC > 3551 there is probably no need to define this behavior specifically > for OPUS. When in DTX mode, the Opus encoder will send a single "refresh" packet every few seconds with the current noise level. Outside the encoder, these packets are indistinguishable from normal Opus packets. Should they have the marker bit set too or only the ones that correspond to new voice activity. In the latter case, we'd have to figure out a way to tell the refresh packets from the voice onset ones. Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSKkbIAAoJEJ6/8sItn9q98PQH/1n69AYYyV0Lrly8oZtVMhAG MGPUABoS9RdFcncdmAXT+Ry8/WT06y9RobGLjC/ri7Fx0SLFtMkYHepC1cZizvLG y1cTU7zE3SjXJjMadOprt3TxXBO91FTvkJP1fUQIB+kybhKDNXz+A4/qOd30KQ+b 3qBMaQcRmG3CQuvXPELgb+49oQJR/yVy0+UBDbHclucfqKLlwx7mRpwp7o4CTbEM NVKek84bCJjMpU7YHTVqSDHRa9t9EsIWooydEO0ScfyF8RNqXGoTKfY8mqOPiPA0 XFuJB2Ts4k7+4v0CRYNqoQOZyAQ84GmjOr/+sBGk+5U5W+hJFFiIHMkzHoY+c3Y= =Hf/T -----END PGP SIGNATURE----- From mzanaty@cisco.com Fri Sep 6 14:33:05 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3419A11E8119 for ; Fri, 6 Sep 2013 14:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRHZjFeU3rBa for ; Fri, 6 Sep 2013 14:33:00 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9139611E812B for ; Fri, 6 Sep 2013 14:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2162; q=dns/txt; s=iport; t=1378503180; x=1379712780; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=N6COq4dS+GDxbuvq2RyHlCrE5xr7c4pxaaGcDbGJXuo=; b=Jp0PEYKvl4cbPEKtxtm97slvqNyXUsf9YbeHxUWUen00u5I8K3vfIxsN Vh7U6/nhtGUSLoZ1/21nIy+OYbSnyWH3wstMTwte3pwy0qDyhBWNP88HD YPZCW/pEOX5eqAUl2R73Ixpi04o5kd791yAkwmjMtUf+wFLNVGZmJrmdj 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFACxJKlKtJV2Z/2dsb2JhbABbgwc1UcFggSYWdIIkAQEBBAEBATc0CwwEAgEIEQQBAQEKFAkHJwsUCQgCBAENBQiHegy9VI9LMQcGgxeBAAOpW4Mggio X-IronPort-AV: E=Sophos;i="4.90,857,1371081600"; d="scan'208";a="256467888" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 06 Sep 2013 21:33:00 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r86LX0AX000822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Sep 2013 21:33:00 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.101]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Fri, 6 Sep 2013 16:32:59 -0500 From: "Mo Zanaty (mzanaty)" To: Jean-Marc Valin , Roman Shpount Thread-Topic: [payload] Comment to draft-ietf-payload-rtp-opus-01 Thread-Index: AQHOq0a2EBTQ7vcIU0+kKfbQFjcxZJm5N2CA Date: Fri, 6 Sep 2013 21:32:59 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D5271C3@xmb-rcd-x14.cisco.com> References: <522A2ACB.9030809@mozilla.com> <522A46C8.9040904@mozilla.com> In-Reply-To: <522A46C8.9040904@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.29.189] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "payload@ietf.org" Subject: Re: [payload] Comment to draft-ietf-payload-rtp-opus-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 21:33:05 -0000 Only voice onset after silence should set the marker bit, to aid in adjusti= ng playout delay buffers. This, too, is covered in RFC 3551 section 4.1. Mo -----Original Message----- From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Jean-Marc Valin Sent: Friday, September 06, 2013 5:19 PM To: Roman Shpount Cc: payload@ietf.org Subject: Re: [payload] Comment to draft-ietf-payload-rtp-opus-01 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/06/2013 03:46 PM, Roman Shpount wrote: > In my experience and according to RFC 3551 this is the right thing > to do. Furthermore, the first packet of a talkspurt, that is, the > first packet after a silence period during which packets have not > been transmitted contiguously, SHOULD be distinguished by setting > the marker bit in the RTP data header to one. Also, since this is > already standard behavior for all audio codecs according to RFC > 3551 there is probably no need to define this behavior specifically > for OPUS. When in DTX mode, the Opus encoder will send a single "refresh" packet every few seconds with the current noise level. Outside the encoder, these packets are indistinguishable from normal Opus packets. Should they have the marker bit set too or only the ones that correspond to new voice activity. In the latter case, we'd have to figure out a way to tell the refresh packets from the voice onset ones. Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSKkbIAAoJEJ6/8sItn9q98PQH/1n69AYYyV0Lrly8oZtVMhAG MGPUABoS9RdFcncdmAXT+Ry8/WT06y9RobGLjC/ri7Fx0SLFtMkYHepC1cZizvLG y1cTU7zE3SjXJjMadOprt3TxXBO91FTvkJP1fUQIB+kybhKDNXz+A4/qOd30KQ+b 3qBMaQcRmG3CQuvXPELgb+49oQJR/yVy0+UBDbHclucfqKLlwx7mRpwp7o4CTbEM NVKek84bCJjMpU7YHTVqSDHRa9t9EsIWooydEO0ScfyF8RNqXGoTKfY8mqOPiPA0 XFuJB2Ts4k7+4v0CRYNqoQOZyAQ84GmjOr/+sBGk+5U5W+hJFFiIHMkzHoY+c3Y=3D =3DHf/T -----END PGP SIGNATURE----- _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From roman@telurix.com Fri Sep 6 14:35:28 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C257711E81A9 for ; Fri, 6 Sep 2013 14:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id di2PajzawDLP for ; Fri, 6 Sep 2013 14:35:23 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by ietfa.amsl.com (Postfix) with ESMTP id 22F3211E8198 for ; Fri, 6 Sep 2013 14:35:22 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cb5so1452163wib.4 for ; Fri, 06 Sep 2013 14:35:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KzgLVHyO628cSwfudcTOYOK8MbUeElfxPGTCk1nHvc4=; b=bSIcT+pDSVEIBhxVG6t8AcHwekhblMqEpLPzKRH2fdOPIp2kOzM/vGDOjoLn5/p5Fw bbDVcgXUUC+3RhF952bxYmPuYTEt651jCjsfe5OOVepDS4wZMkHd7ZF563wlGYGEjCxj hUhqt3i1r74t94g01+l4V3yTGktj7+tmmQNk8lQDKGophdesVy7ZdUfx9zCom3tJW7Sm feya0IClf2Cy91ZskIcSE4OrnlNVtQ9agXhPyd/A9Zun5rwqEV/F2IOreeW8e5G5XDCf 9FFzCxxVfNQ2O+PP7imwr5zN0mOp472IPBnFg3hYKnHwHjd3akn3fOblrF2qh/HJrkwt pc9w== X-Gm-Message-State: ALoCoQkLTgolLTNfw04kcbOqfjsZQF/4eDMITWp2r1t93ME7Y1rtOhdHUTLThJ4HlnCWzdNwvjAQ X-Received: by 10.180.39.134 with SMTP id p6mr3607017wik.9.1378503318744; Fri, 06 Sep 2013 14:35:18 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [2a00:1450:400c:c03::22c]) by mx.google.com with ESMTPSA id e5sm536215wiy.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Sep 2013 14:35:17 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id w61so2375835wes.17 for ; Fri, 06 Sep 2013 14:35:17 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.98.163 with SMTP id ej3mr11852996wib.47.1378503317410; Fri, 06 Sep 2013 14:35:17 -0700 (PDT) Received: by 10.216.26.1 with HTTP; Fri, 6 Sep 2013 14:35:17 -0700 (PDT) In-Reply-To: <522A46C8.9040904@mozilla.com> References: <522A2ACB.9030809@mozilla.com> <522A46C8.9040904@mozilla.com> Date: Fri, 6 Sep 2013 17:35:17 -0400 Message-ID: From: Roman Shpount To: Jean-Marc Valin Content-Type: multipart/alternative; boundary=f46d0442877a8e5f9404e5bdd0fc Cc: payload@ietf.org Subject: Re: [payload] Comment to draft-ietf-payload-rtp-opus-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 21:35:28 -0000 --f46d0442877a8e5f9404e5bdd0fc Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 6, 2013 at 5:19 PM, Jean-Marc Valin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 09/06/2013 03:46 PM, Roman Shpount wrote: > > In my experience and according to RFC 3551 this is the right thing > > to do. Furthermore, the first packet of a talkspurt, that is, the > > first packet after a silence period during which packets have not > > been transmitted contiguously, SHOULD be distinguished by setting > > the marker bit in the RTP data header to one. Also, since this is > > already standard behavior for all audio codecs according to RFC > > 3551 there is probably no need to define this behavior specifically > > for OPUS. > > When in DTX mode, the Opus encoder will send a single "refresh" packet > every few seconds with the current noise level. Outside the encoder, > these packets are indistinguishable from normal Opus packets. Should > they have the marker bit set too or only the ones that correspond to > new voice activity. In the latter case, we'd have to figure out a way > to tell the refresh packets from the voice onset ones. > > Per RFC 3551 Section 4.1: For applications which send either no packets or occasional comfort-noise packets during silence, the first packet of a talkspur, that is, the first packet after a silence period during which packets have not been transmitted contiguously, SHOULD be distinguished by setting the marker bit in the RTP data header to one. The marker bit in all other packets is zero. So according to this only the first packet in a talkspur with voice onset should have the marker bit set. Comfort noise packets should not have it. _____________ Roman Shpount --f46d0442877a8e5f9404e5bdd0fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On F= ri, Sep 6, 2013 at 5:19 PM, Jean-Marc Valin <jmvalin@mozilla.com&g= t; wrote:
-----BE= GIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/06/2013 03:46 PM, Roman Shpount wrote:
> In my experience and according to RFC 3551 this is the right thing
> to do. Furthermore, the first packet of a talkspurt, that is, the
> first packet after a silence period during which packets have not
> been transmitted contiguously, SHOULD be distinguished by setting
> the marker bit in the RTP data header to one. Also, since this is
> already standard behavior for all audio codecs according to RFC
> 3551 there is probably no need to define this behavior specifically > for OPUS.

When in DTX mode, the Opus encoder will send a single "refresh&q= uot; packet
every few seconds with the current noise level. Outside the encoder,
these packets are indistinguishable from normal Opus packets. Should
they have the marker bit set too or only the ones that correspond to
new voice activity. In the latter case, we'd have to figure out a way to tell the refresh packets from the voice onset ones.


Per RFC 3551 Sectio= n 4.1:

For applications which send either no packets or occasional comfort-noise packets during silence, the=20 first packet of a talkspur, that is, the first packet after a silence=20 period during which packets have not been transmitted contiguously,=20 SHOULD be distinguished by setting the marker bit in the RTP data header to one. =A0The marker bit in all other packets is zero.

So a= ccording to this only the first packet in a talkspur with voice onset shoul= d have the marker bit set. Comfort noise packets should not have it.
_____________
Roman Shpount

--f46d0442877a8e5f9404e5bdd0fc-- From magnus.westerlund@ericsson.com Mon Sep 9 07:13:14 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6453221F9FF1 for ; Mon, 9 Sep 2013 07:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKhjqOin82Mg for ; Mon, 9 Sep 2013 07:13:02 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7F88821E81E4 for ; Mon, 9 Sep 2013 07:07:27 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-75-522dd61edef5 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 43.BC.16099.E16DD225; Mon, 9 Sep 2013 16:07:26 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.150) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.2.328.9; Mon, 9 Sep 2013 16:07:24 +0200 Message-ID: <522DD636.5030806@ericsson.com> Date: Mon, 9 Sep 2013 16:07:50 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "payload@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvja7cNd0gg7PzJCwuXTzL5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujNmvPjMWbOeumL/hImMD42LOLkZODgkBE4n+yV1sELaYxIV7 64FsLg4hgcOMEo+eP2OHcJYxSly/P5kRpIpXQFviyqtZrCA2i4CKxJTWm2BxNgELiZs/GsEm iQoES7Rv/8oGUS8ocXLmE5YuRg4OEQFNiUffhUDCwgL2EgtmHQEbIyTgI/Hi/QdmEJtTwFei ecoZFoiDJCW2LTrGDmIzC+hJTLnawghhy0s0b53NDNGrLdHQ1ME6gVFwFpJts5C0zELSsoCR eRUje25iZk56ueEmRmD4HdzyW3cH46lzIocYpTlYlMR5N+mdCRQSSE8sSc1OTS1ILYovKs1J LT7EyMTBKdXA6PG2qUyt/I3ahzXHlDfomgT2cJiFnH3R8WlSr/zMybsXh3udXO/L9tphzhST KR5unxfsK1HO3rRCM3D6tJh9d29P2yZw4S/7ll2NIRkzZZeY6//Wl9rxp2mX2lrTvXHT1c28 F3f/42Q7xHHgn4FSvdulhissfxyElzk/ObHu8xEelaCHe7dxr1BiKc5INNRiLipOBADBXeSE DQIAAA== Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 14:13:14 -0000 WG, As author I would really appreciate some reviews that the content are appropriate. Thus I really appreciate responses even of the type. "Read it, no issues spotted". Don't assume that I am without flaws in my writing ;-). Cheers Magnus On 2013-08-22 10:58, Ali C. Begen (abegen) wrote: > (As a WG co-chair) > > I am starting WGLC for the following draft (version 05). > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto/ > > This is an important document as it outlines how someone is supposed to write the payload specs. > > If there are sections you don't understand or that are not clear enough, etc. please post them to the list. We need to get this right to minimize further headaches for future documents in our WG. > > The deadline for the WGLC is September 20th. > > -acbegen > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Sep 9 07:13:33 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4AD421E81F6 for ; Mon, 9 Sep 2013 07:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.424 X-Spam-Level: X-Spam-Status: No, score=-104.424 tagged_above=-999 required=5 tests=[AWL=-1.825, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAFZ-m0oVJXq for ; Mon, 9 Sep 2013 07:13:20 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id E565621F8460 for ; Mon, 9 Sep 2013 07:07:41 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-c5-522dd62cf7cd Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 64.0F.25272.C26DD225; Mon, 9 Sep 2013 16:07:40 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.149) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.2.328.9; Mon, 9 Sep 2013 16:07:40 +0200 Message-ID: <522DD647.8070406@ericsson.com> Date: Mon, 9 Sep 2013 16:08:07 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Roman Shpount References: <522A2ACB.9030809@mozilla.com> <522A46C8.9040904@mozilla.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+Jvja7ONd0ggz2bTCz+T+WwuHTxLJPF jAtTmR2YPZYs+cnk0Xegi9Xj1pSCAOYoLpuU1JzMstQifbsErozu/3+YCo4KV1xf9Ie9gXER fxcjJ4eEgIlE96TlTBC2mMSFe+vZuhi5OIQEjjJK3Jg+jQXCWcYocWDqbNYuRg4OXgFtiYYv sSANLAIqEkfapoA1swlYSNz80cgGYosKBEu0b/8KZvMKCEqcnPmEBcQWEVCV+Pt9Mlg9s4Ct xMeuJ6wgtrCAg8TFa9+gds1gkrj3ZjHYLk6BQIk1u3ggjpOU2LboGDtEr57ElKstjBC2vETz 1tnMILYQyGlNHawTGIVmIVk9C0nLLCQtCxiZVzFyFKcWJ+WmGxlsYgQG78Etvy12MF7+a3OI UZqDRUmcd4vemUAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjHPYug1Kvd2j3v3Tu6E1ifkP /yr140a5bCZcNwumRhxvdLj3NTng2sl1Mu5xYau7uHjcZOLv1N+PaOKYm3jpD1Ob8+VV3i+9 FK5+Oq+gcGF93cIfZso6PelNzvIrf/Pqhwhc4haQEJFQ2SfLWVkXXVzlq1tS9f7tvKnLP+X4 FG16tTeapeq0EktxRqKhFnNRcSIAyG5yqSwCAAA= Cc: payload@ietf.org Subject: Re: [payload] Comment to draft-ietf-payload-rtp-opus-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 14:13:33 -0000 On 2013-09-06 23:35, Roman Shpount wrote: > On Fri, Sep 6, 2013 at 5:19 PM, Jean-Marc Valin > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 09/06/2013 03:46 PM, Roman Shpount wrote: > > In my experience and according to RFC 3551 this is the right thing > > to do. Furthermore, the first packet of a talkspurt, that is, the > > first packet after a silence period during which packets have not > > been transmitted contiguously, SHOULD be distinguished by setting > > the marker bit in the RTP data header to one. Also, since this is > > already standard behavior for all audio codecs according to RFC > > 3551 there is probably no need to define this behavior specifically > > for OPUS. > > When in DTX mode, the Opus encoder will send a single "refresh" packet > every few seconds with the current noise level. Outside the encoder, > these packets are indistinguishable from normal Opus packets. Should > they have the marker bit set too or only the ones that correspond to > new voice activity. In the latter case, we'd have to figure out a way > to tell the refresh packets from the voice onset ones. > > > Per RFC 3551 Section 4.1: > > For applications which send either no packets or occasional > comfort-noise packets during silence, the first packet of a talkspur, > that is, the first packet after a silence period during which packets > have not been transmitted contiguously, SHOULD be distinguished by > setting the marker bit in the RTP data header to one. The marker bit in > all other packets is zero. > > So according to this only the first packet in a talkspur with voice > onset should have the marker bit set. Comfort noise packets should not > have it. The behavior of the marker bit is up to every RTP Payload format to define. However, I do recommend that you use this common behavior for any codec carrying voice. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Sep 9 07:18:26 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86CAE21E8204 for ; Mon, 9 Sep 2013 07:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.641 X-Spam-Level: X-Spam-Status: No, score=-105.641 tagged_above=-999 required=5 tests=[AWL=0.608, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6pwgaTIElXq for ; Mon, 9 Sep 2013 07:18:10 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5FE21E818F for ; Mon, 9 Sep 2013 07:12:08 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-41-522dd737e005 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 81.2D.16099.737DD225; Mon, 9 Sep 2013 16:12:07 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.150) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.2.328.9; Mon, 9 Sep 2013 16:11:55 +0200 Message-ID: <522DD745.2060003@ericsson.com> Date: Mon, 9 Sep 2013 16:12:21 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jean-Marc Valin References: <522A2ACB.9030809@mozilla.com> In-Reply-To: <522A2ACB.9030809@mozilla.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+Jvja75dd0gg9t94hb/p3JYXLp4lsmi adY0ZgdmjyVLfjJ59B3oYvX4vW8RWwBzFJdNSmpOZllqkb5dAlfGlisnmApaeSueH53P1MB4 mquLkYNDQsBE4s0Jzy5GTiBTTOLCvfVsXYxcHEIChxkl1s6/wQKSEBJYxigxC6KIV0BbYtHq a6wgNouAisS/eT1sIDabgIXEzR+NYLaoQLBE+/avbBD1ghInZz4BmyMioClx58cqdhCbWcBe ovP9dSYQW1jAQeLitW9Qu/IlNiz8ANbLCbRry6lnjBDHSUpsW3QMqldPYsrVFkYIW16ieets ZohebYmGpg7WCYxCs5CsnoWkZRaSlgWMzKsY2XMTM3PSyw03MQJD9+CW37o7GE+dEznEKM3B oiTOu0nvTKCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxqBtenvC36b37/7332ch/9K4JLNJ +0WzmP6FPr7TekF3kY71n7Rln/gs3tr4iuXUOOp3Z713vpRaukltW86hnC3GFe+uyzz9aSq3 xe/6fj/dnJMVGyqkZk0W7q0T/HerxM9wR0fF7c92HXoWx2RVG46/WVVQ4rfw00mWkPDojCbO zoT9WvW7lViKMxINtZiLihMBrOMONSsCAAA= Cc: payload@ietf.org Subject: Re: [payload] Comment to draft-ietf-payload-rtp-opus-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 14:18:26 -0000 On 2013-09-06 21:19, Jean-Marc Valin wrote: > On 09/06/2013 08:15 AM, Tina le Grand wrote: >> In section 3.1.3 Discontinuous Transmission (DTX), I'm missing >> some text that explains how to update the RTP packets correctly >> after a silent period. How should rtp timestamp and sequence >> number be updated while not sending rtp packets (silent period), >> to prepare for when we eventually have data to transmit again? My >> thinking is that rtp timestamp should be updated with the number >> of samples that were not sent, while sequence number should only >> be updated when sending packets. Correct? > > That's also my understanding, but I'm far from an expert on this. > Can anyone with good knowledge of RTP confirm that it's the right > thing to do? > Yes, that is correct and should be easily to derive based on your timestamp usage definition also. For voice the common rule is to define the TS as the timestamp value corresponding to the earliest sample present in the payload. Which is what you have done. >From that follows in case of DTX that the packet after "skipped" frames will have a TS field jumping to the start of the frame actually included. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From bill.wu@huawei.com Tue Sep 10 00:01:40 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD55B21E812E for ; Tue, 10 Sep 2013 00:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IKbnhK6sP3v for ; Tue, 10 Sep 2013 00:01:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9E45D21E813C for ; Tue, 10 Sep 2013 00:01:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVG16752; Tue, 10 Sep 2013 07:01:22 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 10 Sep 2013 08:01:00 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 10 Sep 2013 08:01:07 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.141]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0146.000; Tue, 10 Sep 2013 15:01:02 +0800 From: Qin Wu To: Magnus Westerlund , "payload@ietf.org" Thread-Topic: [payload] WGLC for draft-ietf-payload-rtp-howto-05 Thread-Index: AQHOnxW0JqQDumtvLE+Tk9S9gB3Jkpm9B6cAgAGcXIA= Date: Tue, 10 Sep 2013 07:01:01 +0000 Message-ID: References: <522DD636.5030806@ericsson.com> In-Reply-To: <522DD636.5030806@ericsson.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 07:01:41 -0000 Hi, Magnus: I have read this document and it looks good.=20 Here are a few minor comments: 1. Section 7 Section 7 discusses four special consideration including a. Media Format description b. Security Considerations c. Congestion Control d. IANA Consideration However it looks to me Media Format description or Congestion Control Is not important or could be optional sections that need to be described=20 comparing with Security and IANA Considerations Section=20 Since Section 7, 1st paragraph said: " These include the Security and IANA Considerations sections. " Also Section 7.1 seems just repeat what A.7 section said. 2.Section 7.2, 3rd paragraph: Suggest the following change: OLD TEXT: " That the decoding of the payload format or its media shows substantial non-uniformity, either in output or in complexity to perform the decoding operation. =20 " NEW TEXT: " The decoding of the payload format or its media shows substantial non-uniformity, either in output or in complexity to perform the decoding operation. =20 " 3. Section 7.2, 3rd paragraph: What does "goodput" mean? Good output?=20 4.Section 7.4, 2nd paragraph, 2nd sentence It looks this sentence is disconnected from the 1st sentence. Suggest the following change: OLD TEXT: " Independently the format of these should be such that they can be included in the SDP attribute "a=3Dfmtp" string (See Section 6 [RFC4566]) which is the common mapping. =20 " NEW TEXT: " These parameters are independent of the format of these should be such that they can be included in the SDP attribute "a=3Dfmtp" string (See = Section 6 [RFC4566]) which is the common mapping. =20 " Regards! -Qin -----Original Message----- From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Magnus Westerlund Sent: Monday, September 09, 2013 10:08 PM To: payload@ietf.org Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 WG, As author I would really appreciate some reviews that the content are appropriate. Thus I really appreciate responses even of the type. "Read it, no issues spotted". Don't assume that I am without flaws in my writing ;-). Cheers Magnus On 2013-08-22 10:58, Ali C. Begen (abegen) wrote: > (As a WG co-chair) >=20 > I am starting WGLC for the following draft (version 05).=20 > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto/ >=20 > This is an important document as it outlines how someone is supposed to w= rite the payload specs. >=20 > If there are sections you don't understand or that are not clear enough, = etc. please post them to the list. We need to get this right to minimize fu= rther headaches for future documents in our WG. >=20 > The deadline for the WGLC is September 20th. >=20 > -acbegen > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload >=20 >=20 --=20 Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From tterribe@xiph.org Tue Sep 10 00:47:36 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BB921E8145 for ; Tue, 10 Sep 2013 00:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id se924hMnYzGF for ; Tue, 10 Sep 2013 00:47:31 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id F1B8621E813C for ; Tue, 10 Sep 2013 00:47:30 -0700 (PDT) Received: from [192.168.1.141] (host81-136-161-25.in-addr.btopenworld.com [81.136.161.25]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 61B12F223A for ; Tue, 10 Sep 2013 00:47:30 -0700 (PDT) Message-ID: <522ECE90.2050303@xiph.org> Date: Tue, 10 Sep 2013 00:47:28 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 SeaMonkey/2.16 MIME-Version: 1.0 To: payload@ietf.org References: <522A2ACB.9030809@mozilla.com> <522A46C8.9040904@mozilla.com> <522DD647.8070406@ericsson.com> In-Reply-To: <522DD647.8070406@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [payload] Comment to draft-ietf-payload-rtp-opus-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 07:47:36 -0000 Magnus Westerlund wrote: > The behavior of the marker bit is up to every RTP Payload format to > define. However, I do recommend that you use this common behavior for > any codec carrying voice. Okay, sounds like we should add a normative reference to RFC 3551 Section 4.1, then. From magnus.westerlund@ericsson.com Tue Sep 10 01:51:05 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FAB21E80B9 for ; Tue, 10 Sep 2013 01:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.884 X-Spam-Level: X-Spam-Status: No, score=-105.884 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phFQdHH0MIr8 for ; Tue, 10 Sep 2013 01:51:00 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BE7AD21F9D50 for ; Tue, 10 Sep 2013 01:50:59 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-28-522edd728198 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 66.23.03802.27DDE225; Tue, 10 Sep 2013 10:50:58 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.19) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.2.328.9; Tue, 10 Sep 2013 10:50:57 +0200 Message-ID: <522EDD8D.7060306@ericsson.com> Date: Tue, 10 Sep 2013 10:51:25 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Qin Wu References: <522DD636.5030806@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsUyM+JvjW7RXb0gg/l7lCwez13AanHp4lkm ByaPliNvWT2WLPnJFMAUxWWTkpqTWZZapG+XwJVxcMoSpoL5ihV790xmbmA8KtXFyMEhIWAi seaeUhcjJ5ApJnHh3nq2LkYuDiGBw4wSTz60MkE4yxglnn/fxgxSxSugLbHuwUU2EJtFQFWi bddVdhCbTcBC4uaPRrC4qECwRPv2r2wQ9YISJ2c+YQGxRQTkJRo232UEsZkFNCUOfX4MViMs YC+xYNYRVohl2xgltu3fApbgFAiTePl0LxPEeZIS2xYdY4do1pOYcrUFapC8RPPW2WDHCQEd 19DUwTqBUWgWkt2zkLTMQtKygJF5FSN7bmJmTnq50SZGYLAe3PJbdQfjnXMihxilOViUxHk3 650JFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDI/V8k4m9uofsmqzsqc5kr1Zr3RNxbxHWb 7eiBykX3bjnocvCdmuPwbJrpNI9n3TrTmxm/azmf6mJfe16a3eLuvtWffqrlCG/eovU59Obq W2IRO2w2S/nohLMKmS0IkTnGGxu28Zie/cdZix29XfqXns5+0K393EFgg/zt+azOx+puX4/k jpuuxFKckWioxVxUnAgAJ0vyVCQCAAA= Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 08:51:05 -0000 Many Thanks for the review. See inline for comments. On 2013-09-10 09:01, Qin Wu wrote: > Hi, Magnus: > I have read this document and it looks good. > Here are a few minor comments: > 1. Section 7 > Section 7 discusses four special consideration including > a. Media Format description > b. Security Considerations > c. Congestion Control > d. IANA Consideration > However it looks to me Media Format description or Congestion Control > Is not important or could be optional sections that need to be described > comparing with Security and IANA Considerations Section > Since Section 7, 1st paragraph said: > " > These include the Security and IANA > Considerations sections. > " So the Security and IANA are required for all drafts. The Media format description I would recommend to ensure that people can understand the important feature of the codec. Congestion control discussion is not mandated by other procedures, but I at least thinks payload formats really should include them. I would propose tweaking the section 7 introduction to say: A number of sections in the payload format draft need special consideration. These include the Security and IANA Considerations sections that are required in all drafts. Payload formats are also strongly recommended to have the media format description and congestion control considerations. Better? > Also Section 7.1 seems just repeat what A.7 section said. Ok, I think it is important to have the text that is present in A.7 as it provides template instruction. What may need to consider is if the text in 7.1 should contain anything additionally. Nothing springs to mind immediately. I don't see the repetition as a major issue as it is within the body vs within the template. > > 2.Section 7.2, 3rd paragraph: > Suggest the following change: > OLD TEXT: > " > That the decoding of the payload format or its media shows > substantial non-uniformity, either in output or in complexity to > perform the decoding operation. > " > NEW TEXT: > " > The decoding of the payload format or its media shows > substantial non-uniformity, either in output or in complexity to > perform the decoding operation. > " Maybe this works better: Potential security issues with an RTP payload format and the media encoding that needs to be considered if they are applicable: 1. The decoding of the payload format or its media results in substantial non-uniformity, either in output or in complexity to perform the decoding operation. > 3. Section 7.2, 3rd paragraph: > What does "goodput" mean? Good output? Ahaa, goodput is how much actual usable (good) results that are produced. See: http://en.wikipedia.org/wiki/Goodput Maybe this is clearer: Such inputs can cause some sort of disruption, i.e. a denial of service attack on the receiver side by preventing that host from performing usable work. > > 4.Section 7.4, 2nd paragraph, 2nd sentence > It looks this sentence is disconnected from the 1st sentence. > Suggest the following change: > OLD TEXT: > " > Independently the format of these should be such that they can be > included in the SDP attribute "a=fmtp" string (See Section 6 > [RFC4566]) which is the common mapping. > " > NEW TEXT: > " > These parameters are independent of the format of these should be > such that they can be included in the SDP attribute "a=fmtp" string (See Section 6 > [RFC4566]) which is the common mapping. > " Actually, independently are just confusing here. I think simplification to: The format of these parameter should be such that they can be included in the SDP attribute "a=fmtp" string ... Is the right way to go. Once more, Thanks for the review. Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From bill.wu@huawei.com Tue Sep 10 02:03:09 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA1611E8111 for ; Tue, 10 Sep 2013 02:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDCEC1Sn-Cdr for ; Tue, 10 Sep 2013 02:03:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 20B0811E81AB for ; Tue, 10 Sep 2013 02:03:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AXE12275; Tue, 10 Sep 2013 09:03:01 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 10 Sep 2013 10:01:44 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 10 Sep 2013 10:01:51 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.141]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0146.000; Tue, 10 Sep 2013 17:01:43 +0800 From: Qin Wu To: Magnus Westerlund Thread-Topic: [payload] WGLC for draft-ietf-payload-rtp-howto-05 Thread-Index: AQHOnxW0JqQDumtvLE+Tk9S9gB3Jkpm9B6cAgAGcXID//52RgIAAiBaQ Date: Tue, 10 Sep 2013 09:01:43 +0000 Message-ID: References: <522DD636.5030806@ericsson.com> <522EDD8D.7060306@ericsson.com> In-Reply-To: <522EDD8D.7060306@ericsson.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 09:03:09 -0000 -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Tuesday, September 10, 2013 4:51 PM To: Qin Wu Cc: payload@ietf.org Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 Many Thanks for the review. See inline for comments. On 2013-09-10 09:01, Qin Wu wrote: > Hi, Magnus: > I have read this document and it looks good.=20 > Here are a few minor comments: > 1. Section 7 > Section 7 discusses four special consideration including > a. Media Format description > b. Security Considerations > c. Congestion Control > d. IANA Consideration > However it looks to me Media Format description or Congestion Control > Is not important or could be optional sections that need to be described= =20 > comparing with Security and IANA Considerations Section=20 > Since Section 7, 1st paragraph said: > " > These include the Security and IANA > Considerations sections. > " So the Security and IANA are required for all drafts. The Media format description I would recommend to ensure that people can understand the important feature of the codec. Congestion control discussion is not mandated by other procedures, but I at least thinks payload formats really should include them. I would propose tweaking the section 7 introduction to say: A number of sections in the payload format draft need special consideration. These include the Security and IANA Considerations sections that are required in all drafts. Payload formats are also strongly recommended to have the media format description and congestion control considerations. Better? [Qin]: That is the change I am looking for, thanks. > Also Section 7.1 seems just repeat what A.7 section said. Ok, I think it is important to have the text that is present in A.7 as it provides template instruction. What may need to consider is if the text in 7.1 should contain anything additionally. Nothing springs to mind immediately. I don't see the repetition as a major issue as it is within the body vs within the template. [Qin]: I can live with this, thanks for your clarification. >=20 > 2.Section 7.2, 3rd paragraph: > Suggest the following change: > OLD TEXT: > " > That the decoding of the payload format or its media shows > substantial non-uniformity, either in output or in complexity to > perform the decoding operation. =20 > " > NEW TEXT: > " > The decoding of the payload format or its media shows > substantial non-uniformity, either in output or in complexity to > perform the decoding operation. =20 > " Maybe this works better: Potential security issues with an RTP payload format and the media encoding that needs to be considered if they are applicable: 1. The decoding of the payload format or its media results in substantial non-uniformity, either in output or in complexity to perform the decoding operation. [Qin]:Your proposed change addresses my comment, thanks. > 3. Section 7.2, 3rd paragraph: > What does "goodput" mean? Good output?=20 Ahaa, goodput is how much actual usable (good) results that are produced. See: http://en.wikipedia.org/wiki/Goodput Maybe this is clearer: Such inputs can cause some sort of disruption, i.e. a denial of service attack on the receiver side by preventing that host from performing usable work. [Qin]: Looks good to me, thanks for taking my comment into account. >=20 > 4.Section 7.4, 2nd paragraph, 2nd sentence > It looks this sentence is disconnected from the 1st sentence. > Suggest the following change: > OLD TEXT: > " > Independently the format of these should be such that they can be > included in the SDP attribute "a=3Dfmtp" string (See Section 6 > [RFC4566]) which is the common mapping. =20 > " > NEW TEXT: > " > These parameters are independent of the format of these should be > such that they can be included in the SDP attribute "a=3Dfmtp" string (Se= e Section 6 > [RFC4566]) which is the common mapping. =20 > " Actually, independently are just confusing here. I think simplification to: The format of these parameter should be such that they can be included in the SDP attribute "a=3Dfmtp" string ... [Qin]: Make sense, thanks. Is the right way to go. Once more, Thanks for the review. Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From Lindsay@worldcastsystems.com Tue Sep 10 06:50:16 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CF221F9433 for ; Tue, 10 Sep 2013 06:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlTBW7zBeC84 for ; Tue, 10 Sep 2013 06:50:12 -0700 (PDT) Received: from mailgate.aptcodecs.com (mailgate.aptcodecs.com [217.33.179.85]) by ietfa.amsl.com (Postfix) with ESMTP id 831CC21E811D for ; Tue, 10 Sep 2013 06:50:11 -0700 (PDT) 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_01CEAE2C.A9CD37FE" Date: Tue, 10 Sep 2013 14:50:08 +0100 Message-ID: <8C4E0C2409735E4FBC22D754A238F94D02F74C4C@APTSBS.apt.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-aptx-01.txt Thread-Index: Ac6uLKmL42zZxpypQ6uVe6jQfjvAFQ== From: "John Lindsay" To: Cc: Foerster@worldcastsystems.com Subject: [payload] I-D Action: draft-ietf-payload-rtp-aptx-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 13:50:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CEAE2C.A9CD37FE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 A new draft has been uploaded to the IETF Payload workgroup at https://datatracker.ietf.org/wg/payload/. =20 The new document makes a few minor changes for IDNITS checking and also takes account of the comments made by Peter Stevens last week. =20 A summary of the changes are as follows. =20 Page 1, IETF Copyright notice updated to 2013. Page 10, updated formatting for IDNITS check. Page 14, Section 6 updated to reflect RFC 6838 which supersedes RFC 4288. Page 16, Section 6.2.1 type corrected An - A as per Peter Stevens comments. Page 18, Section 7 now reference 6.1 rather than 7.1, again thanks to Peters proof reading. Page 21, new RFC6338 referenced. =20 Thanks to everyone who has read and commented on the draft. =20 Regards =20 John =20 =20 ------_=_NextPart_001_01CEAE2C.A9CD37FE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

A new draft has been = uploaded to the IETF Payload workgroup at https://datatracker.iet= f.org/wg/payload/.

 

The new document makes a = few minor changes for IDNITS checking and also takes account of the = comments made by Peter Stevens last week.

 

A summary of the changes = are as follows.

 

Page 1, IETF Copyright = notice updated to 2013.

Page 10, updated formatting for IDNITS = check.

Page 14, Section 6 updated to reflect RFC 6838 = which supersedes RFC 4288.

Page 16, Section 6.2.1 = type corrected An – A as per Peter Stevens = comments.

Page 18, Section 7 now reference 6.1 rather than = 7.1, again thanks to Peters proof reading.

Page 21, new RFC6338 = referenced.

 

Thanks to everyone who = has read and commented on the draft.

 

Regards

 

John

 

 

------_=_NextPart_001_01CEAE2C.A9CD37FE-- From hhhansen@MAYAH.com Tue Sep 10 12:49:50 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30D921E80B5; Tue, 10 Sep 2013 12:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9L-++NIc0mjm; Tue, 10 Sep 2013 12:49:46 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8375C21E819E; Tue, 10 Sep 2013 12:49:44 -0700 (PDT) Received: from [217.91.215.225] (helo=mayah-sbs.MAYAH.COM) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1VJTwT-0006WE-Nx; Tue, 10 Sep 2013 21:49:42 +0200 Date: Tue, 10 Sep 2013 21:49:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <031C6AD0F5FEAB449C77DF4E9D047A5C4049FB@mayah-sbs.mayah.com> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 X-MS-TNEF-Correlator: content-class: urn:content-classes:message Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-aptx-01.txt Thread-Index: Ac6q1zmuw6KfrVvlQ4WsWDBm85FrawDh2dJQ From: "Hans-Heinrich Hansen" To: , X-Df-Sender: MzI2MjQx Cc: payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-aptx-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 19:49:50 -0000 We will support and this draft in all our audio codecs! Best regards, Hans-Heinrich Hansen MAYAH Communications GmbH -----Original Message----- From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]On Behalf Of internet-drafts@ietf.org Sent: Friday, September 06, 2013 9:55 AM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-aptx-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 Payloads Working = Group of the IETF. Title : RTP Payload Format for Standard apt-X and Enhanced = apt-X Codecs Author(s) : John Lindsay Hartmut Foerster Filename : draft-ietf-payload-rtp-aptx-01.txt Pages : 22 Date : 2013-09-05 Abstract: This document specifies a scheme for packetizing Standard apt-X, or Enhanced apt-X, encoded audio data into Real-time Transport Protocol (RTP) packets. The document describes a payload format that permits transmission of multiple related audio channels in a single RTP payload, and a means of establishing Standard apt-X and Enhanced apt-X connections through the Session Description Protocol (SDP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-aptx There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-aptx-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-aptx-01 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From prvs=959f67906=HeinzPeter.Reykers@wdr.de Wed Sep 11 03:24:17 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0F521E8093 for ; Wed, 11 Sep 2013 03:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.759 X-Spam-Level: X-Spam-Status: No, score=-0.759 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSyEALeCTSFo for ; Wed, 11 Sep 2013 03:24:13 -0700 (PDT) Received: from smtp39.wdr.de (smtp39.wdr.de [149.219.195.39]) by ietfa.amsl.com (Postfix) with ESMTP id C666F21E809D for ; Wed, 11 Sep 2013 03:24:12 -0700 (PDT) Message-Id: <523060CC0200005600079274@wdr.de> Date: Wed, 11 Sep 2013 12:23:40 +0200 From: "Heinz Peter Reykers" To: ,"John Lindsay" References: <8C4E0C2409735E4FBC22D754A238F94D02F74C4C@APTSBS.apt.local> In-Reply-To: <8C4E0C2409735E4FBC22D754A238F94D02F74C4C@APTSBS.apt.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartF2C19DBC.0__=" Cc: Foerster@worldcastsystems.com Subject: [payload] Antw: I-D Action: draft-ietf-payload-rtp-aptx-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 10:24:17 -0000 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartF2C19DBC.0__= Content-Type: multipart/alternative; boundary="=__PartF2C19DBC.1__=" --=__PartF2C19DBC.1__= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Dear John, thank you for the corrections. Due to the fact that several manufacturers already have implemented e-aptx as described in the draft i hope instandly that it will become a rfc soon, so that all other manufacturers will be compatible to each other! That's what we need for our daily work in the master control rooms and also in the field. Best regards Heinz Peter ____________________________________ Dipl.-Ing. Heinz Peter Reykers Westdeutscher Rundfunk Köln Programmverbreitung / WAN Audio-Encoding - Kontribution Tel.: +49 (0)221 220 - 4183 Fax: +49 (0)221 220 - 774183 mobil: +49 (0)172 251 3066 e-mail: heinzpeter.reykers@wdr.de Appellhofplatz 1 D-50600 Köln Archivhaus 1331 >>> "John Lindsay" 10.09.13 15:50 >>> Hi A new draft has been uploaded to the IETF Payload workgroup at https://datatracker.ietf.org/wg/payload/. The new document makes a few minor changes for IDNITS checking and also takes account of the comments made by Peter Stevens last week. A summary of the changes are as follows. Page 1, IETF Copyright notice updated to 2013. Page 10, updated formatting for IDNITS check. Page 14, Section 6 updated to reflect RFC 6838 which supersedes RFC 4288. Page 16, Section 6.2.1 type corrected An – A as per Peter Stevens comments. Page 18, Section 7 now reference 6.1 rather than 7.1, again thanks to Peters proof reading. Page 21, new RFC6338 referenced. Thanks to everyone who has read and commented on the draft. Regards John --=__PartF2C19DBC.1__= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Description: HTML
Dear John,
 
thank you for the corrections. Due to the fact that several manufactur= ers already have implemented e-aptx as described in the draft i hope = instandly that it will become a rfc soon, so that all other manufacturers = will be compatible to each other! That's what we need for our daily work = in the master control rooms and also in the field.
 
 
Best regards
 
Heinz Peter 

 
____________________________________


Dipl.-Ing. Heinz = Peter Reykers

Westdeutscher Rundfunk K=C3=B6ln
Programmverbreitun= g / WAN=20
Audio-Encoding - Kontribution 

Tel.: +49 (0)221 220 = - 4183
Fax: +49 (0)221 220 - 774183
mobil: +49 (0)172 251 3066
e-mail: heinzpeter.reykers@wd= r.de
 
Appellhofplatz 1
D-50600 K=C3=B6ln
Archivhaus 1331
>>> "John Lindsay" <Lindsay@worldcast= systems.com> 10.09.13 15:50 >>>

Hi

 

A new draft has been = uploaded to the IETF Payload workgroup at https://datatracker.ietf.org/wg/payload/.

 

The new document makes = a few minor changes for IDNITS checking and also takes account of the = comments made by Peter Stevens last week.

 

A summary of the = changes are as follows.

 

Page 1, IETF Copyright = notice updated to 2013.

Page 10, updated = formatting for IDNITS check.

Page 14, Section 6 = updated to reflect RFC 6838 which supersedes RFC 4288.

Page 16, Section 6.2.1 = type corrected An =E2=80=93 A as per Peter Stevens comments.

Page 18, Section 7 now = reference 6.1 rather than 7.1, again thanks to Peters proof reading.

Page 21, new RFC6338 = referenced.

 

Thanks to everyone who = has read and commented on the draft.

 

Regards

 

John<= /P>

 

 

--=__PartF2C19DBC.1__=-- --=__PartF2C19DBC.0__= Content-Type: application/octet-stream; name="Reykers, Heinz Peter.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Reykers, Heinz Peter.vcf" QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpQUk9ESUQ6LS8vTm92ZWxsIEluYy8vR3JvdXB3aXNl IDguMC4yIA0KWC1HV1RZUEU6VVNFUg0KRk46UmV5a2VycywgSGVpbnogUGV0ZXINCk46UmV5a2Vy cztIZWlueiBQZXRlcg0KRU1BSUw7SU5URVJORVQ7UFJFRjpIZWluelBldGVyLlJleWtlcnNAV0RS LkRFDQpVSUQ6QTBGRUFDMjAtMTI2RC0wMDAwLTg3NUItN0UwMDk1REI0Qzg0DQpURUw7Vk9JQ0U7 UFJFRjorNDkgKDIyMSkgMjIwLTQxODMNClRFTDtWT0lDRTtXT1JLOis0OSAoMjIxKSAyMjAtNDE4 Mw0KVEVMO0ZBWDtQUkVGOis0OSAoMjIxKSAyMjAtNzc0MTgzDQpUSVRMRTpEaXBsLi1JbmcuDQpS RVY6MjAxMzA5MTBUMTI0NDI1Wg0KRU5EOlZDQVJEDQoNCg== --=__PartF2C19DBC.0__=-- From jonathan@vidyo.com Thu Sep 12 08:49:43 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA6611E824F for ; Thu, 12 Sep 2013 08:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.654 X-Spam-Level: X-Spam-Status: No, score=-1.654 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNwdtd4EC72x for ; Thu, 12 Sep 2013 08:49:39 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id 4920B11E821E for ; Thu, 12 Sep 2013 08:49:39 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id BB1638BECA4 for ; Thu, 12 Sep 2013 11:49:38 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 2DA548BED3D for ; Thu, 12 Sep 2013 11:49:38 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Thu, 12 Sep 2013 11:49:37 -0400 From: Jonathan Lennox To: "payload@ietf.org" Date: Thu, 12 Sep 2013 11:49:37 -0400 Thread-Topic: [payload] WGLC for draft-ietf-payload-rtp-howto-05 Thread-Index: Ac6vz0u/nejq6W0sTBKDc4Ob5jLQYA== Message-ID: <0191B13C-4865-41D7-84E0-828CF54E84E3@vidyo.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 15:49:43 -0000 One point that's not mentioned in this document, but which might be worth b= ringing up, is the conventions on how you choose a payload format's clock r= ate. I.e., the fact that clock rates are conventionally 90000 Hz for video (and = we should give some background as to why), and they're conventionally the s= ampling rate for audio. It might also be worth discussing the benefits of the Opus clock rate appro= ach (always use the maximum supported clock rate, i.e., 48000 Hz), vs. the = conventional one, in the context of the multiple-clock-rates draft. On Aug 22, 2013, at 4:58 AM, "Ali C. Begen (abegen)" wro= te: > (As a WG co-chair) >=20 > I am starting WGLC for the following draft (version 05).=20 > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto/ >=20 > This is an important document as it outlines how someone is supposed to w= rite the payload specs. >=20 > If there are sections you don't understand or that are not clear enough, = etc. please post them to the list. We need to get this right to minimize fu= rther headaches for future documents in our WG. >=20 > The deadline for the WGLC is September 20th. >=20 > -acbegen > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload >=20 -- Jonathan Lennox jonathan@vidyo.com From csp@csperkins.org Thu Sep 12 13:44:13 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1215911E80EE for ; Thu, 12 Sep 2013 13:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.555 X-Spam-Level: X-Spam-Status: No, score=-106.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQ37rPqYvR9S for ; Thu, 12 Sep 2013 13:44:08 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 5E34121F9E6D for ; Thu, 12 Sep 2013 13:44:08 -0700 (PDT) Received: from [31.50.77.234] (port=49875 helo=[192.168.5.70]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1VKDk5-0002WQ-EH; Thu, 12 Sep 2013 21:43:58 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Colin Perkins In-Reply-To: Date: Thu, 12 Sep 2013 18:04:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4CD0A460-A92F-418E-9D6D-6F1B6BEF278F@csperkins.org> References: To: Ali C. Begen (abegen) X-Mailer: Apple Mail (2.1508) X-BlackCat-Spam-Score: -12 X-Mythic-Debug: Threshold = On = Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 20:44:13 -0000 On 22 Aug 2013, at 09:58, Ali C. Begen (abegen) = wrote: > (As a WG co-chair) >=20 > I am starting WGLC for the following draft (version 05).=20 > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto/ >=20 > This is an important document as it outlines how someone is supposed = to write the payload specs. >=20 > If there are sections you don't understand or that are not clear = enough, etc. please post them to the list. We need to get this right to = minimize further headaches for future documents in our WG. >=20 > The deadline for the WGLC is September 20th. I think this is an important draft, and I'm glad to see it progressing. = It seems to be generally well written and containing good advice. I have = some number of comments, but these are generally all minor points: - In Section 3.1.2 the discussion of RFC 6015 mentions RFC 2733, but RFC = 2733 hasn=92t been cited or discussed - In Section 3.1.2 the discussion of RFC 3611 might usefully point to = the IANA registry for XR blocks and the XRBLOCK working group - Section 3.2: the introduction to this section could be clearer that = this is an overview of RTP features that are available independent of = the payload format, and not a list of things that the payload format = needs to explicitly opt in to/out of. - Section 3.2.2 expands SSRC as =93Sender Source Identifier=94 but this = should be =93Synchronisation Source Identifier=94. - In Section 3.2.2 the statement =93[RFC5285] specifies how to extend = the RTP header to carry metadata relating to the payload=94 is = potentially misleading, since the type of information that usually goes = into an RTP payload header is also =93metadata relating to the payload=94.= It might be useful to expand this discussion slightly, to make the = distinction clear. - In Section 3.2.2, it might be useful to explain that video payload = formats are a common example of =93payload formats with a timestamp = definition which results in no or little correlation between the media = time instance and its transmission time=94; otherwise this sounds like = such payload formats are something unusual. - In Section 3.2.2, would it be helpful to explain typical RTP timestamp = and sequence number behaviour when using discontinuous transmission? - In Section 3.2.2, when talking about the RTP timestamp, it might be = appropriate to reference to leap-seconds draft - In Section 3.2.2, when talking about payload type numbers, it might be = useful to be explicit that the binding is dynamic, and that other = out-of-band configuration information in addition to the payload type to = payload format binding is usually needed to understand a payload format. = Reference Section 3.3. - Should Section 3.2.3 reference the multiplex-guidelines or = transport-multiplexing drafts? - Section 3.2.4 says =93SSRCs with the same CNAME in different RTP = sessions can be synchronized=94; this is also true of flows with = different SSRC but the same CNAME within an RTP session.=20 - Section 3.4: should this say anything about AQM and/or QoS support? - Section 4 might be clearer titled =93Standardisation Process for an = RTP Payload Format=94 - Section 4 =93registration of the RTP payload format name=94 =96 how = does this relate to the =93media type=94 discussed in Section 3.3? - The discussion of SST and MST in Section 5.1.5 seems to confuse = sessions with SSRCs. Isn=92t it more important whether the layers are = sent within a single RTP media stream, or as separate RTP media streams = with different SSRC values? Whether the different SSRCs are sent in one = RTP session of many is then a separate issue, depending on how easily = one wants to be able to separate the flows for QoS purposes. - In Section 5.1.6, avoiding wrap-around within the RTCP reporting = timeout interval is also important. - The introduction to Section 7 could usefully reference the template = payload format. - Appendix A.10: mention that the RTP circuit breaker ought to be used = and respected? --=20 Colin Perkins http://csperkins.org/ From magnus.westerlund@ericsson.com Fri Sep 13 01:06:26 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D098611E817F for ; Fri, 13 Sep 2013 01:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.483 X-Spam-Level: X-Spam-Status: No, score=-105.483 tagged_above=-999 required=5 tests=[AWL=0.766, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjLUWLCid421 for ; Fri, 13 Sep 2013 01:06:21 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECF511E8179 for ; Fri, 13 Sep 2013 01:06:18 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-81-5232c7792f30 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 8C.9F.16099.977C2325; Fri, 13 Sep 2013 10:06:17 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.149) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.2.328.9; Fri, 13 Sep 2013 10:06:17 +0200 Message-ID: <5232C7A9.6050504@ericsson.com> Date: Fri, 13 Sep 2013 10:07:05 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jonathan Lennox References: <0191B13C-4865-41D7-84E0-828CF54E84E3@vidyo.com> In-Reply-To: <0191B13C-4865-41D7-84E0-828CF54E84E3@vidyo.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3RrfyuFGQwdrbWhb7F59ntrh08SyT A5PHkiU/mTzant1hD2CK4rJJSc3JLEst0rdL4MqY+3kaW8E924q+a93sDYx7DLoYOTgkBEwk uk8ZdzFyApliEhfurWfrYuTiEBI4zCjx6+9nKGc5o8S7FY+ZQBp4BbQl3pyJAWlgEVCVuHDm NiOIzSZgIXHzRyMbiC0qECzRvv0rmM0rIChxcuYTFhBbREBD4uKzD2BxZgFNiUOfH4PZwgL2 EgtmHWEFsYUEaiUOvbgHZnMK2EpMfrCECeI4SYlti46xQ/TqSUy52sIIYctLNG+dzQzRqy3R 0NTBOoFRaBaS1bOQtMxC0rKAkXkVI3tuYmZOernhJkZgoB7c8lt3B+OpcyKHGKU5WJTEeTfp nQkUEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwCjiE/Dha2B2hUKgQv8Ld/Xu/RdURCPtkwr2 vVdP3S530GvjbS6P/d88X3KtO6y78uBErWNXmFaqt5zPetJ5Smde58Et/Sxds570b5+e03fi +hMrbb2XHy8f2KRuI7rogmdKV7f1s8Ipy3O/zNQ0UV2g8jdv24GvRzk2yFkaz2Saujfhn+NR CR4lluKMREMt5qLiRAD9quWbIgIAAA== Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 08:06:27 -0000 Hi Jonathan, Thanks for the review. On 2013-09-12 17:49, Jonathan Lennox wrote: > One point that's not mentioned in this document, but which might be > worth bringing up, is the conventions on how you choose a payload > format's clock rate. > > I.e., the fact that clock rates are conventionally 90000 Hz for video > (and we should give some background as to why), and they're > conventionally the sampling rate for audio. > > It might also be worth discussing the benefits of the Opus clock rate > approach (always use the maximum supported clock rate, i.e., 48000 > Hz), vs. the conventional one, in the context of the > multiple-clock-rates draft. Agreed, this should be better covered. I propose to add a new sub-section in Section 5 covering this subject. I have therefore been able to shorten the timestamp text in Section 3.2.2 to: Timestamp: The RTP timestamp indicates the time instance the media sample belongs to. For discrete media like video, it normally indicates when the media (frame) was sampled. For continuous media it normally indicates the first time instance the media present in the payload represents. For audio this is the sampling time of the first sample. All RTP payload formats must specify the meaning of the timestamp value and the clock rates allowed. Selecting Timestamp rate is an active design choice and is further discussed in Section 5.2. and remove a whole paragraph in Section 6.1: Audio Payloads 5.2. Selecting Timestamp Definition The RTP Timestamp is an important part and have two design choices associated with it. The first is the definition that determines what the timestamp value in a particular RTP packet will be, the second is which timestamp rate should be used. The timestamp definition needs to explicitly define what the timestamp value in the RTP packet represent for a particular payload format. Two common definitions are used; for discretely sampled media, like video frames, the sampling time of the earliest included video frame which the data represent (fully or partially) is used; for continuous media like audio, the sampling time of the earliest sample which the payload data represent. There exist cases where more elaborate or other definitions are used. RTP payload formats with a timestamp definition which results in no or little correlation between the media time instance and its transmission time cause the RTCP jitter calculation to become unusable due to the errors introduced on the sender side. Such examples are for example payload formats for video that requires multiple packets, where a set of packets will have the same timestamp, another are payloads that includes alternating set of redundant information, if the definition used are for the earliest data included, the the timestamp may jump back and forth. It should be noted if the payload format has this property or not. A RTP payload format also needs to define what timestamp rates, or clock rates (as it is also called), that may be used. Depending on the RTP payload format this may be a single rate or multiple ones or theoretically any rate. So what needs to be considered when selecting rate? The rate needs be selected so that one can determine where in the timeline of the media a particular sample (e.g. individual audio sample, or video frame) or set of samples (e.g. audio frames) belong. To enable correct synchronization of this data with previous frames, including over periods of discontinuous transmission or irregularities. For audio it is common to require audio sample accuracy. Thus one commonly selects the input sampling rate to the code. This can however be challenging for for audio codecs that support multiple different sampling frequencies, either as codec input or being used internally but effecting output, for example frame duration. Depending on how one expects to use these different sampling rates one can allow multiple timestamp rates, each matching a particular codec input or sampling rate. However, due to the issues with using multiple different RTP timestamp rates for the same source (SSRC) [I-D.ietf-avtext-multiple-clock-rates] this should be avoided if one expects to need to switch between modes. An alternatives then is to find a common denominator frequency between the different modes, e.g. OPUS [I-D.ietf-payload-rtp-opus] that uses 48 KHz. If the different modes uses or can use a common input/output frequency then selecting this also needs to be considered. However, it is important to consider all aspects as the case of AMR-WB+ [RFC4352] illustrates. AMR-WB+'s RTP timestamp rate has the very unusual value of 72 kHz, despite the fact that output normally is at a sample rate of 48kHz. The design is motivated by the media codec's production of a large range of different frame lengths in time perspective. The 72 kHz timestamp rate is the smallest found value that would make all of the frames the codec could produce result in an integer frame length in RTP timestamp ticks. This way, a receiver can always correctly place the frames in relation to any other frame, even when the frame length changes. The downside is that the decoder outputs for certain frame lengths is in fact partial samples. The result is that the output in samples from the codec will vary from frame to frame, potentially making implementation more difficult. Video codecs has commonly been using 90 kHz, the reason is this is a common denominator between the usually used frame rates such as 24, 25, 30, 50 and 60, and NTSC's odd 29.97 Hz. There does however exist at least one exception in the payload format for SMPTE 292M video [RFC3497] that uses a clock rate of 148.5 Mhz. The reason here is that the timestamp then identify the exact start sample within a video frame. Timestamp rates below 1000 Hz are not appropriate because it will cause a too low resolution in the RTCP measurements that are expressed in RTP timestamps. This is the main reason that the text RTP payload formats, like T.140 [RFC4103] uses 1000 Hz. > > On Aug 22, 2013, at 4:58 AM, "Ali C. Begen (abegen)" > wrote: > >> (As a WG co-chair) >> >> I am starting WGLC for the following draft (version 05). >> https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto/ >> >> This is an important document as it outlines how someone is >> supposed to write the payload specs. >> >> If there are sections you don't understand or that are not clear >> enough, etc. please post them to the list. We need to get this >> right to minimize further headaches for future documents in our >> WG. >> >> The deadline for the WGLC is September 20th. >> >> -acbegen _______________________________________________ payload >> mailing list payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >> > > -- Jonathan Lennox jonathan@vidyo.com > > > _______________________________________________ payload mailing list > payload@ietf.org https://www.ietf.org/mailman/listinfo/payload > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From rlb@ipv.sx Fri Sep 13 11:29:39 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F3321F9EB5 for ; Fri, 13 Sep 2013 11:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dWR5f4syIic for ; Fri, 13 Sep 2013 11:29:35 -0700 (PDT) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4E29021F9E51 for ; Fri, 13 Sep 2013 11:29:35 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id wn1so1414841obc.38 for ; Fri, 13 Sep 2013 11:29:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=j2IuxCtuudgqrNJx8KLsS6zZw0elnubnNxXRvuU+VX8=; b=Dpj5koPz/hqOpOM55mBxJVeGCe32QskabK778HolnkarfmhcukoXf32UbKy7NFDixD 5Pzzce5B6mA2XsZthPYzpnAScDHdyzk2po2Zslux833xLemw3TBTe/1KKGlDWM8gxwBC IrzIAiG/RoLTdN5qOC2MpX3/TFqCRl8OttiigzDq4Mbr539PhdO9KrhtWOlRPmhTf+Hb 5b0qhFqi0oAHZSGyeK5uJBD5YbmKLtjD6Uyd/hIrpJ3mIv7dtytJOGDjPzy/zDv9BktR UNMryGvLm2p8iG/CVBiqwBDFJCfkP41Xm39MrB8j0Es3l+6dLER1f2hpO/sj6H06GDoc LRwQ== X-Gm-Message-State: ALoCoQleGbTzPyMAj7l84gI+7RjQDEndCDeRAI49lFxO972WWaB+ukR6agXa/kmfe8S+HfkIdSYh MIME-Version: 1.0 X-Received: by 10.60.116.230 with SMTP id jz6mr13706033oeb.21.1379096974853; Fri, 13 Sep 2013 11:29:34 -0700 (PDT) Received: by 10.60.31.74 with HTTP; Fri, 13 Sep 2013 11:29:34 -0700 (PDT) In-Reply-To: <51B9BF06.80609@alvestrand.no> References: <062e01ce2f03$33956840$9ac038c0$@gmail.com> <065f01ce2f22$26c76b80$74564280$@gmail.com> <51B9BF06.80609@alvestrand.no> Date: Fri, 13 Sep 2013 14:29:34 -0400 Message-ID: From: Richard Barnes To: Harald Alvestrand Content-Type: multipart/alternative; boundary=089e0115e84a4c189104e64809dd Cc: draft-ietf-avt-rtp-isac@tools.ietf.org, "payload@ietf.org" Subject: Re: [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 18:29:39 -0000 --089e0115e84a4c189104e64809dd Content-Type: text/plain; charset=ISO-8859-1 Since Real Soon Now has turned into Not Very Soon At All, I'm moving this one back to Active. When you guys are ready to get around to it, please re-request publication. --Richard On Thu, Jun 13, 2013 at 8:45 AM, Harald Alvestrand wrote: > On 05/28/2013 08:34 PM, Richard Barnes wrote: > > Dear Authors, > > Any update on these issues? > > > Working on it, but as you know from other discussions, there isn't exactly > a lack of things to work on at the moment - it dropped off my queue, and > I'm picking it up again now. > > We'll get back to you Real Soon Now. > > > Thanks, > --Richard > > > On Mon, Apr 1, 2013 at 5:44 PM, Roni Even wrote: > >> Hi Richard, >> >> These fields are not part of the RTP header but part of the iSAC payload >> header and I agree that it will be better to clarify them. >> >> Roni >> >> >> >> *From:* Richard Barnes [mailto:rlb@ipv.sx] >> *Sent:* 01 April, 2013 9:47 PM >> *To:* Roni Even >> *Cc:* payload@ietf.org; draft-ietf-avt-rtp-isac@tools.ietf.org >> *Subject:* Re: [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04 >> >> >> >> Sure. I didn't mean to imply that we need a reference to the codec, in >> fact the opposite. I was looking for this document to tell me how to parse >> out the fields I would feed into the black box of the codec. They describe >> the fields, but it seems to me that they need more detail in order for >> people to know how to parse them out of the payload. >> >> >> >> --Richard >> >> >> >> On Mon, Apr 1, 2013 at 2:03 PM, Roni Even wrote: >> >> Hi Richard, >> >> As a general comment, for RTP payload specifications we do not require a >> normative reference to the codec. We only require enough information that >> will allow an RTP receiver to parse the information and move it to the >> decoder that can be a black box. This allows us to publish RTP payload >> specification also for codecs whose specifications are not publically >> available. >> >> Still in this case more information can be supplied. >> >> >> >> As for the comments the authors should address them >> >> >> >> Roni Even >> >> >> >> *From:* payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] *On >> Behalf Of *Richard Barnes >> *Sent:* 01 April, 2013 8:06 PM >> *To:* payload@ietf.org >> *Cc:* draft-ietf-avt-rtp-isac@tools.ietf.org >> *Subject:* [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04 >> >> >> >> Overall, this document looks in pretty good shape. A couple of comments >> I would like to get resolved before IETF LC: >> >> >> >> Section 3.1., "Consult source code for details" >> >> If the details are only specified in the source code, then the source >> needs to be a normative reference. And I would prefer to avoid that :) >> Better to specify here how the BEI and FL fields are encoded. >> Alternatively, if the codec really does expect a combined BEI/FL field, you >> could specify such a field here, opaque to the RTP layer. However, you >> would at least need to say how the recipient knows where this field starts >> and stops. >> >> >> >> Section 3.2., "The length of the encoded data is variable and depends >> on the signal characteristics and the target bit rate." >> >> However, there's nothing in this section that tells a recipient how to >> determine what this length is. >> >> >> >> Section 3.3., "... verifying the CRC checksum ..." >> >> Please specify which CRC function is to be applied, and how the CRC value >> field is formatted. >> >> >> >> Section 3.3., "If this value would exceed 255 at encoding..." >> >> It sounds like the LEN field is a single octet unsigned integer. Please >> state that explicitly. >> >> >> >> Section 9.2. Informative References. >> >> Better path to source code would be "webrtc/ >> modules/audio_coding/codecs/isac" >> >> >> >> Thanks, >> >> --Richard >> >> >> > > > > _______________________________________________ > payload mailing listpayload@ietf.orghttps://www.ietf.org/mailman/listinfo/payload > > > --089e0115e84a4c189104e64809dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Since Real Soon Now has turned into Not Very Soon At All, = I'm moving this one back to Active. =A0When you guys are ready to get a= round to it, please re-request publication.
--Richard


On Thu, Jun 13, 2013 at 8:45 AM, Harald = Alvestrand <harald@alvestrand.no> wrote:
=20 =20 =20
On 05/28/2013 08:34 PM, Richard Barnes wrote:
Dear Authors,

Any update on these issues?

Working on it, but as you know from other discussions, there isn't exactly a lack of things to work on at the moment - it dropped off my queue, and I'm picking it up again now.

We'll get back to you Real Soon Now.


Thanks,
--Richard


On Mon, Apr 1, 2013 at 5:44 PM, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi Richard,

These fields are not part of the RTP header but part of the iSAC payload header and I agree that it will be better to clarify them.

Roni

=A0

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: 01 April, 2013 9:47 PM
To: Roni Even
Cc: payload@ietf.org; draft-ietf-avt-rtp-isac@tools.ietf.org
Subject: Re: [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04

=A0

Sure. I didn't mean to imply that we need a reference to the codec, in fact the opposite. =A0I was looking for this document to tell me how to parse out the fields I would feed into the black box of the codec. =A0They describe the fields, but it seems to me that they need more detail in order for people to know how to parse them out of the payload.

=A0

--Richard

=A0

On Mon, Apr 1, 2013 at 2:03 PM, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi Richard,

As a general comment, for RTP payload specifications we do not require a normative reference to the codec. We only require enough information that will allow an RTP receiver to parse the information and move it to the decoder that can be a black box. This allows us to publish RTP payload specification also for codecs whose specifications are not publically available.

Still in this case more information can be supplied.

=A0

As for the comments the authors should address them

=A0

Roni Even

=A0

From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: 01 April, 2013 8:06 PM
To: payload@ietf.org
Cc: draft-ietf-avt-rtp-isac@tools.i= etf.org
Subject: [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04

=A0

Overall, this document looks in pretty good shape. =A0A couple of comments I would like to get resolved before IETF LC:

=A0

Section 3.1., "Consult source code for details&q= uot;

If the details are only specified in the source code, then the source needs to be a normative reference. =A0And I would prefer to avoid that =A0:) =A0Better to specify here how the BEI and FL fields are encoded. =A0 Alternatively, if the codec really does expect a combined BEI/FL field, you could specify such a field here, opaque to the RTP layer. =A0However, you would at least need to say how the recipient knows where this field starts and stops.

=A0

Section 3.2., &quo= t;The length of the encoded data is variable and depends on=A0the signal characteristics and the target bit rate."

However, there'= ;s nothing in this section that tells a recipient how to determine what this length is. =A0

=A0

Section 3.3., "...=A0verifying the CRC checksum ..."

Please specify which CRC function is to be applied, and how the CRC value field is formatted.

=A0

Section 3.3., &quo= t;If this value would exceed 255 at encoding..."

It sounds like the LEN field is a single octet unsigned integer. =A0Please state that explicitly.=A0

=A0

Section 9.2. Informative References.

Better path to source code would be "webrtc/modules/audio_coding/codecs/isac"

=A0

Thanks,

--Richard

=A0




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


--089e0115e84a4c189104e64809dd-- From ietf-ipr@ietf.org Tue Sep 10 10:06:17 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8766921E8156; Tue, 10 Sep 2013 10:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.347 X-Spam-Level: X-Spam-Status: No, score=-102.347 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoPNya5C1ftK; Tue, 10 Sep 2013 10:06:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB9921F9D44; Tue, 10 Sep 2013 10:06:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: yekuiw@qti.qualcomm.com, yago.sanchez@hhi.fraunhofer.de, ts@thomas-schierl.de, stewe@stewe.org, miska.hannuksela@nokia.com X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130910170609.32624.24559.idtracker@ietfa.amsl.com> Date: Tue, 10 Sep 2013 10:06:09 -0700 X-Mailman-Approved-At: Fri, 13 Sep 2013 13:56:10 -0700 Cc: payload@ietf.org, ipr-announce@ietf.org Subject: [payload] IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-payload-rtp-h265-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 17:06:17 -0000 Dear Ye-Kui Wang, Yago Sanchez, Thomas Schierl, Stephan Wenger, Miska M. Ha= nnuksela: An IPR disclosure that pertains to your Internet-Draft entitled "RTP Paylo= ad Format for High Efficiency Video Coding" (draft-ietf-payload-rtp-h265) was submitted to the IETF Secretariat on 2013-09-09 and has been posted on the = "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2190/). The title of the IPR disclosure is "Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to dr= aft- ietf-payload-rtp-h265-01.""); The IETF Secretariat From abegen@cisco.com Mon Sep 16 06:08:27 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937B811E8246 for ; Mon, 16 Sep 2013 06:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Xy6rPSWHjZ4 for ; Mon, 16 Sep 2013 06:08:10 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9AD11E824B for ; Mon, 16 Sep 2013 06:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=329; q=dns/txt; s=iport; t=1379336887; x=1380546487; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=yPg2/XDPpmMeCOVYNqXv4dZe2yOmNTWBZoPl7oY+9R0=; b=KuAF+POcZwkG0sQFZX+k5o7pK6kHpkgSoMq4dRo5v+q7wC/bzjzweNca wLtyVQKTCAZ5nZaI+y/tsLL8t5eiqBITwZn253ko3afKfX0CZLKoo5wJZ ZKYEE0UZmWmhQmpHvrdjRZQjl0oJmBPnzyTGnyjku5PPtFtQ8y0+vHqhy 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAE0CN1KtJV2c/2dsb2JhbABbgmYhOFKCY74UgRsWdIInAQQ6UQEqFEInBBuHewELmSygKwSPQoNWgQADqW+DJIIq X-IronPort-AV: E=Sophos;i="4.90,915,1371081600"; d="scan'208";a="260261944" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 16 Sep 2013 13:08:03 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8GD83le018278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 16 Sep 2013 13:08:03 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Mon, 16 Sep 2013 08:08:03 -0500 From: "Ali C. Begen (abegen)" To: "payload@ietf.org" Thread-Topic: WGLC for draft-ietf-payload-rtp-aptx-01 Thread-Index: AQHOst3GQJ5PwGEhn0qLtw2WH9fA5Q== Date: Mon, 16 Sep 2013 13:08:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.103.8] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [payload] WGLC for draft-ietf-payload-rtp-aptx-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 13:08:27 -0000 (As a WG co-chair) I am starting WGLC for the following draft (version 01).=20 https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-aptx/ It is a short document. If you have comments, agreements or disagreements, = please let the list know in either case. The deadline for the WGLC is September 30th. -acbegen= From jonathan@vidyo.com Mon Sep 16 11:36:59 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D8D21F85BB for ; Mon, 16 Sep 2013 11:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.263 X-Spam-Level: X-Spam-Status: No, score=-2.263 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iz+j9w6sGm5x for ; Mon, 16 Sep 2013 11:36:43 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAB121F84D0 for ; Mon, 16 Sep 2013 11:36:30 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 853FB7ACFFB; Mon, 16 Sep 2013 14:36:24 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB024.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 09CF97ACFA7; Mon, 16 Sep 2013 14:36:24 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Mon, 16 Sep 2013 14:36:24 -0400 From: Jonathan Lennox To: "Ali C. Begen (abegen)" Date: Mon, 16 Sep 2013 14:36:22 -0400 Thread-Topic: [payload] WGLC for draft-ietf-payload-rtp-aptx-01 Thread-Index: Ac6zCz/NRAIJ+BVMRiaGH9ixCdwj8g== Message-ID: <0B7378E0-0124-4121-8DA0-B01EF1186715@vidyo.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-aptx-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 18:36:59 -0000 The document discusses that a number of items are dependent on the "deliver= y method", and says that the delivery method can be negotiated through offe= r/answer. However, the delivery method parameter is never actually defined= anywhere. Either delivery method needs to be defined, or discussion of it= needs to be removed, depending on whether or not delivery-method was actua= lly meant to be included in the final spec. The SDP mapping says that maxptime is encoded in the fmtp parameter. This = is incorrect; as specified by RFC 4566, maxptime is carried in its own SDP = a=3D attribute. The RTP header section says that the marker bit is not used. Unless there'= s a good reason for this, I suggest that instead the usual RFC 3551 marker = bit semantic for audio be applied (i.e., the marker bit is set for end of s= ilence / beginning of talkspurt). If there's a reason this semantic is ina= ppropriate, it should be explained. The RTP header section also says that the RTP dynamic payload types can onl= y be in the range 96 - 127. This is incorrect; that's the primary range, b= ut other values can be used once that range is exhausted. See, e.g., the r= ecent discussion on the avtcore list. No information is given about the semantic content of the data carried in t= he auxiliary data channel. Is the semantic of this data defined by the cod= ec, or would it need to be described or negotiated in SDP? (Doing neither,= i.e. providing an arbitrary data channel with no mechanism for describing = or negotiating its content, seems likely to lead to interoperability proble= ms.) Also, are there any security considerations introduced by the auxilia= ry data channel? It would be good to have a reference to some document by CSR plc describing= the apt-X codecs, even if they don't include full proprietary details of t= he workings of the codec. On Sep 16, 2013, at 9:08 AM, "Ali C. Begen (abegen)" wro= te: > (As a WG co-chair) >=20 > I am starting WGLC for the following draft (version 01).=20 > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-aptx/ >=20 > It is a short document. If you have comments, agreements or disagreements= , please let the list know in either case. >=20 > The deadline for the WGLC is September 30th. >=20 > -acbegen > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload >=20 -- Jonathan Lennox jonathan@vidyo.com From harald@alvestrand.no Tue Sep 17 05:52:44 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670E711E83F0 for ; Tue, 17 Sep 2013 05:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.523 X-Spam-Level: X-Spam-Status: No, score=-110.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DH+FHeQZAb6H for ; Tue, 17 Sep 2013 05:52:38 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB0111E824C for ; Tue, 17 Sep 2013 05:52:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6E88E39E1B7 for ; Tue, 17 Sep 2013 14:52:36 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bx5FEQCATwCF for ; Tue, 17 Sep 2013 14:52:35 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0155F39E1AC for ; Tue, 17 Sep 2013 14:52:34 +0200 (CEST) Message-ID: <52385092.5000000@alvestrand.no> Date: Tue, 17 Sep 2013 14:52:34 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: payload@ietf.org References: <8C4E0C2409735E4FBC22D754A238F94D02F74C4C@APTSBS.apt.local> In-Reply-To: <8C4E0C2409735E4FBC22D754A238F94D02F74C4C@APTSBS.apt.local> Content-Type: multipart/alternative; boundary="------------050809080000090604080107" Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-aptx-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 12:52:44 -0000 This is a multi-part message in MIME format. --------------050809080000090604080107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brief scan, one question: Is it possible to offer a stable reference for what "Standard apt-x" and "Enhanced apt-x" means? The closest I can get is "licensed by CSR plc", which presumably means that "it means what CSR plc thinks it means", but it would be great to have that stated explicitly. Something like: The codecs "apt-x" and "Extended apt-x" are defined by CSR plc, an UK company. Section 3 of the draft *almost* says that, but isn't completely unambiguous ("licensed by" can mean both "CSR is a licensor" and "CSR is a licensee, someone else defines it"). I *think* this is a nit. On 09/10/2013 03:50 PM, John Lindsay wrote: > > Hi > > A new draft has been uploaded to the IETF Payload workgroup at > https://datatracker.ietf.org/wg/payload/. > > The new document makes a few minor changes for IDNITS checking and > also takes account of the comments made by Peter Stevens last week. > > A summary of the changes are as follows. > > Page 1, IETF Copyright notice updated to 2013. > > Page 10, updated formatting for IDNITS check. > > Page 14, Section 6 updated to reflect RFC 6838 which supersedes RFC 4288. > > Page 16, Section 6.2.1 type corrected An -- A as per Peter Stevens > comments. > > Page 18, Section 7 now reference 6.1 rather than 7.1, again thanks to > Peters proof reading. > > Page 21, new RFC6338 referenced. > > Thanks to everyone who has read and commented on the draft. > > Regards > > John > > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload --------------050809080000090604080107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Brief scan, one question:

Is it possible to offer a stable reference for what "Standard apt-x" and "Enhanced apt-x" means?

The closest I can get is "licensed by CSR plc", which presumably means that "it means what CSR plc thinks it means", but it would be great to have that stated explicitly.

Something like:

The codecs "apt-x" and "Extended apt-x" are defined by CSR plc, an UK company.

Section 3 of the draft *almost* says that, but isn't completely unambiguous ("licensed by" can mean both "CSR is a licensor" and "CSR is a licensee, someone else defines it").

I *think* this is a nit.


On 09/10/2013 03:50 PM, John Lindsay wrote:

Hi

 

A new draft has been uploaded to the IETF Payload workgroup at https://datatracker.ietf.org/wg/payload/.

 

The new document makes a few minor changes for IDNITS checking and also takes account of the comments made by Peter Stevens last week.

 

A summary of the changes are as follows.

 

Page 1, IETF Copyright notice updated to 2013.

Page 10, updated formatting for IDNITS check.

Page 14, Section 6 updated to reflect RFC 6838 which supersedes RFC 4288.

Page 16, Section 6.2.1 type corrected An – A as per Peter Stevens comments.

Page 18, Section 7 now reference 6.1 rather than 7.1, again thanks to Peters proof reading.

Page 21, new RFC6338 referenced.

 

Thanks to everyone who has read and commented on the draft.

 

Regards

 

John

 

 



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

--------------050809080000090604080107-- From magnus.westerlund@ericsson.com Sat Sep 21 04:56:16 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDAF511E8156 for ; Sat, 21 Sep 2013 04:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.417 X-Spam-Level: X-Spam-Status: No, score=-104.417 tagged_above=-999 required=5 tests=[AWL=-0.768, BAYES_50=0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mu5omMyon7Rb for ; Sat, 21 Sep 2013 04:56:11 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1528E11E8153 for ; Sat, 21 Sep 2013 04:56:10 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-8d-523d895938a7 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 74.27.16099.9598D325; Sat, 21 Sep 2013 13:56:09 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.148) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.2.328.9; Sat, 21 Sep 2013 13:56:09 +0200 Message-ID: <523D8979.10902@ericsson.com> Date: Sat, 21 Sep 2013 13:56:41 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Colin Perkins References: <4CD0A460-A92F-418E-9D6D-6F1B6BEF278F@csperkins.org> In-Reply-To: <4CD0A460-A92F-418E-9D6D-6F1B6BEF278F@csperkins.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+JvrW5kp22QwcaDahYPts9ltFj+8gSj xaWLZ5kcmD2m/N7I6jHt/n02jyVLfjIFMEdx2aSk5mSWpRbp2yVwZfz7/IexYMI+xoqjk86x NjD+m8zYxcjBISFgInH/nUMXIyeQKSZx4d56ti5GLg4hgcOMEr1rFjFBOMsZJfZM2csCUsUr oClxYMFHZhCbRUBV4tHBS4wgNpuAhcTNH41sILaoQLBE+/avbBD1ghInZz4B6xUBqt9x/B9Y PbOAp8Sr9udMILawgL3EgllHWEFsIYFGRolvX1lAjuMUcJS4Nb0G4jhJiW2LjrFDtBpIHFk0 hxXClpdo3jqbGaJVW6KhqYN1AqPQLCSbZyFpmYWkZQEj8ypG9tzEzJz0csNNjMAAPrjlt+4O xlPnRA4xSnOwKInzbtI7EygkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBceZV5oc7Xzm8jrwY v2Jt3OYOQTdVjTyvKcIhK87ufsnlVbDXUf7mAgvOmd+/zQ0WWNwlllWz4/suyZWPgm3f3OVS kTvkpS88pTyBac/ZOT0PAqoXPr1a7W17zSlmV+psnbnK/tM6by3c0lEUZLr22le5D/f4Go3K 376PvcVdeWWDZZms1EtPfiWW4oxEQy3mouJEAA0gfWcuAgAA Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 11:56:16 -0000 Hi, Thanks for the review comments. I have tried addressing them. I am submitting an updated draft including these edits. But, I do need feedback on these edits. See below. On 2013-09-12 19:04, Colin Perkins wrote: > On 22 Aug 2013, at 09:58, Ali C. Begen (abegen) > wrote: >> (As a WG co-chair) >> >> I am starting WGLC for the following draft (version 05). >> https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto/ >> >> This is an important document as it outlines how someone is >> supposed to write the payload specs. >> >> If there are sections you don't understand or that are not clear >> enough, etc. please post them to the list. We need to get this >> right to minimize further headaches for future documents in our >> WG. >> >> The deadline for the WGLC is September 20th. > > > I think this is an important draft, and I'm glad to see it > progressing. It seems to be generally well written and containing > good advice. I have some number of comments, but these are generally > all minor points: > > - In Section 3.1.2 the discussion of RFC 6015 mentions RFC 2733, but > RFC 2733 hasn’t been cited or discussed Correct, I added a reference in RFC 5109 text to state that this replaced RFC 2733, and added as references in both places. RFC 5109: The "RTP Payload Format for Generic Forward Error Correction (FEC)" [RFC5109] provides an XOR based FEC of the whole or parts of a number of RTP packets. This specification replaced the previous specification for XOR based FEC [RFC2733]. These FEC packets are sent in a separate stream or as a redundant encoding using RFC 2198. This FEC scheme has certain restrictions in the number of packets it can protect. It is suitable for low-to- medium delay tolerant applications with limited amount of RTP packets. RFC 6015: The "RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC)" [RFC6015] provides a variant of the XOR based Generic protection defined in [RFC2733]. The main difference is to use interleaving scheme on which packets gets included as source packets for a particular protection packet. The interleaving is defined by using every L packets as source data. And then produce protection data over D number of packets. Thus each block of D x L source packets will result in L number of Repair packets, each capable of repairing one loss. The goal is to provide better burst error robustness when the packet rate is higher. > > - In Section 3.1.2 the discussion of RFC 3611 might usefully point to > the IANA registry for XR blocks and the XRBLOCK working group RFC 3611: The RTCP Extended Reports (RTCP XR) [RFC3611] consists of a framework for reports sent within RTCP. It can easily be extended by defining new report formats, which has occurred. The list of specified formats are available in IANA's RTCP XR Block Type registry (http://www.iana.org/assignments/rtcp-xr-block-types /rtcp-xr-block-types.xhtml). The report formats that are defined in RFC3611 provide report information on packet loss, packet duplication, packet reception times, RTCP statistics summary and VoIP Quality. [RFC3611] also defines a mechanism that allows receivers to calculate the RTT to other session participants when used. > > - Section 3.2: the introduction to this section could be clearer that > this is an overview of RTP features that are available independent of > the payload format, and not a list of things that the payload format > needs to explicitly opt in to/out of. This section reviews a number of RTP features and concepts that are available in RTP independent of the payload format. The RTP payload format can make use of these when appropriate, and in some cases even effect the behavior (RTP Timestamp and marker bit). This section does not remove the necessity to read up on RTP. However it does point out a few important details to remember when designing a payload format. > > - Section 3.2.2 expands SSRC as “Sender Source Identifier” but this > should be “Synchronisation Source Identifier”. Note that I also change the fourth line to say "of multiple media sources" rather than "from multiple senders. SSRC: The Synchronisation Source Identifier (SSRC) is normally not used by a payload format other than to identify the RTP timestamp and sequence number space a packet belongs to, allowing simultaneously reception of multiple media sources. However, some of the RTP mechanisms for improving resilience to packet loss uses multiple SSRCs to separate original data and repair or redundant data. > > - In Section 3.2.2 the statement “[RFC5285] specifies how to extend > the RTP header to carry metadata relating to the payload” is > potentially misleading, since the type of information that usually > goes into an RTP payload header is also “metadata relating to the > payload”. It might be useful to expand this discussion slightly, to > make the distinction clear. Is this better? Header extensions: Payload formats normally specifies the carrying of meta data related to the media payload in the payload header. In some cases the meta data may be more generic, e.g. relevant more to the media type (e.g. audio or video), or RTP packets in general. In those cases the carrying of this additional meta data can be specified in a header extension. One example is the transport of SMPTE time-codes in the RTP header [RFC5484]. As [RFC5285] specifies, header extensions must not contain information required in order to decode the payload successfully. > > - In Section 3.2.2, it might be useful to explain that video payload > formats are a common example of “payload formats with a timestamp > definition which results in no or little correlation between the > media time instance and its transmission time”; otherwise this sounds > like such payload formats are something unusual. This discussion got moved into the new section 5.2, where the related text says: RTP payload formats with a timestamp definition which results in no or little correlation between the media time instance and its transmission time cause the RTCP jitter calculation to become unusable due to the errors introduced on the sender side. Such examples are for example payload formats for video that requires multiple packets, where a set of packets will have the same timestamp, another are payloads that includes alternating set of redundant information, if the definition used are for the earliest data included, the the timestamp may jump back and forth. It should be noted if the payload format has this property or not. Good enough? > > - In Section 3.2.2, would it be helpful to explain typical RTP > timestamp and sequence number behaviour when using discontinuous > transmission? Timestamp: The RTP timestamp indicates the time instance the media sample belongs to. For discrete media like video, it normally indicates when the media (frame) was sampled. For continuous media it normally indicates the first time instance the media present in the payload represents. For audio this is the sampling time of the first sample. All RTP payload formats must specify the meaning of the timestamp value and the clock rates allowed. Selecting Timestamp rate is an active design choice and is further discussed in Section 5.2. Discontinuous transmissions (DTX) that is common among speech codecs, typically results in gaps or jumps in the timestamp values due that there are no media payload to transmit and the next used timestamp value represent the actual sampling time of the data transmitted. Sequence number: The sequence number is monotonically increasing and is set as the packet is sent. This property is used in many payload formats to recover the order of everything from the whole stream down to fragments of application data units (ADUs) and the order they need to be decoded. Discontinuous transmissions does not result in gaps in the sequence number, as it is monotonically increasing for each sent RTP packet. > > - In Section 3.2.2, when talking about the RTP timestamp, it might be > appropriate to reference to leap-seconds draft I chose to add a paragraph on this in Section 3.2.4 Leap Seconds are extra seconds added or seconds removed to keep our clocks in sync with earths rotation. Adding or removing seconds can impact first of all the reference clock as discussed in "RTP and Leap Seconds" [I-D.ietf-avtcore-leap-second]. But also in cases where the RTP timestamp value are derived using the wall clock during the leap second event errors can occur. Implementations needs to consider leap seconds and should consider the recommendations in [I-D.ietf-avtcore-leap-second]. > > - In Section 3.2.2, when talking about payload type numbers, it might > be useful to be explicit that the binding is dynamic, and that other > out-of-band configuration information in addition to the payload type > to payload format binding is usually needed to understand a payload > format. Reference Section 3.3. Payload Type: The payload type is used to indicate on a per packet basis which format is used. The binding between a payload type number and a payload format and its configuration are dynamically bound and RTP session specific. The configuration information can be bound to a payload type value by out-of-band signalling (Section 3.3). An example of this would be video decoder configuration information. Commonly the same payload type is used for a media stream for the whole duration of a session. However in some cases it may be necessary to change the payload format or its configuration during the session. > > - Should Section 3.2.3 reference the multiplex-guidelines or > transport-multiplexing drafts? I think the multiplexing guidelines makes sense. The transport multiplexing being focused on providing a specific solution to one combination of RTP sessions to transport mapping appears to specific. I added the following last in the section. For more discussion and consideration of how and when to use the different RTP multiplexing points see [I-D.ietf-avtcore-multiplex-guidelines]. > > - Section 3.2.4 says “SSRCs with the same CNAME in different RTP > sessions can be synchronized”; this is also true of flows with > different SSRC but the same CNAME within an RTP session. Correct, I changed this to: SSRCs with the same CNAME sent in any of multiple RTP sessions can be synchronized. > > - Section 3.4: should this say anything about AQM and/or QoS > support? I tried writing something about this. I don't know how useful this is. Feedback much appreciated. 3.4.2. Different Queuing Algorithms Routers and Switches on the network path between an IP sender and a particular receiver can exhibit different behaviors affecting the end to end characteristics. One of the more important aspects of this is queuing behavior. Routers and Switches has some amount of queuing to handle temporary bursts of data that designated to leave the switch or router on the same egress link. A queue when not empty results in an increased path delay. The implementation of the queuing effects the delay and also how congestion signals (Explicint Congestion Marking (ECN) or packet drops) are provided to the flow. The other aspects are if the flow shares the queue with other flows and how the implementation affects the flow interaction. This becomes important for example when real- time flows interacts with long lived TCP flows. TCP have a built in behavior in its congestion control that strive to fill the buffer, thus all flows sharing the buffer experienced the delay build up. A common but quite poor queue handling mechanism is tail-drop, i.e. only drop packets when the incoming packet doesn't fit in the queue. Active Queue Management (AQM) is a term covering mechanism that tries to do something smarter buy actively managing the queue, for example by sending congestion signals earlier by droping packets earlier in the queue. The behavior also affects the flow interactions. For example Random Early Drop (RED) selects which packet to drop randomly. This to give flows that have more packets in the queue a higher probability to experience the packet loss (congestion signal). There is ongoing work to find suitable mechanisms to recommend for implementation and reduce the use of tail-drop. 3.4.3. Quality of Service Using best effort Internet one have no guaratees for the paths properties. Quality of Service (QoS) mechanism are intended to provide the possility to bound the path properties. Where Diffserv [RFC2475] markings effects the queing and forwarding behaviors of routers, the mechanism provides only statistical guarantees and care in how much marked packets of different types that are entering the network. Flow based QoS like IntServ [RFC1663] has the potential for stricter guarantees as the properties are agreed on by each hop on the path. > > - Section 4 might be clearer titled “Standardisation Process for an > RTP Payload Format” Agreed > > - Section 4 “registration of the RTP payload format name” – how does > this relate to the “media type” discussed in Section 3.3? It really should be referencing the Media Type as this is the registry which matters. Thus changed sentence to: For specifications that are defined by standards bodies other than the IETF the primary milestone is registration of the Media Type for the RTP payload format. > > - The discussion of SST and MST in Section 5.1.5 seems to confuse > sessions with SSRCs. Isn’t it more important whether the layers are > sent within a single RTP media stream, or as separate RTP media > streams with different SSRC values? Whether the different SSRCs are > sent in one RTP session of many is then a separate issue, depending > on how easily one wants to be able to separate the flows for QoS > purposes. The issue is that the SVC payload RFC is a bit confused on this matter. I agree that there are two separate important distinctions here. First if the layers are sent in one RTP packet stream or used multiple ones. In the second case one gets the question of how one distributes that over RTP sessions and underlying transports. Especially as some that implements SVC MST clearly uses a single RTP session and are after the possibility on a SSRC level to control transmission of layers in RTP middleboxes. I have tried to address this in the text, please review. 5.1.5. Media Scalability Some codecs support various types of media scalability, i.e. some data of a media stream may be removed to adapt the media's properties, such as bitrate and quality. The adaptation may be applied in the following dimensions of the media: Temporal: For video codecs it is possible to adapt the frame rate, e.g. for H.264 [RFC6184]. Spatial: Video codecs supporting scalability may adapt the resolution, e.g. in SVC [RFC6190]. Quality: The quality of the media stream may be scaled by adapting the accuracy of the coding process, as, e.g. possible with Signal to Noise Ratio (SNR) fidelity scalability of SVC [RFC6190]. At the time of writing this document, codecs that support scalability have a bit of revival. It has been realized that getting the required functionality for supporting the features of the media stream into the RTP framework is quite challenging. One of the recent examples for layered and scalable codecs is Scalable Video Coding [RFC6190] (SVC). SVC is a good example for a payload format supporting media scalability features, which have been in its basic form already included in RTP. A layered codec supports the dropping of data parts of a media stream, i.e. RTP packets may be not transmitted or forwarded to a client in order to adapt the media stream rate as well as the media stream quality, while still providing a decodable subset of the media stream to a client. One example for using the scalability feature may be an RTP Mixer (Multipoint Control Unit) which controls the rate and quality sent out to participants in a communication based on dropping RTP packets or removing part of the payload. Another example may be an transport channel which allows for differentiation in Quality of Service (QoS) parameters based on RTP sessions in a multicast session. In such a case, the more important packets of the scalable media stream (base layer) may get better QoS parameters, then the less important packets (enhancement layer) in order to provide some kind of graceful degradation. The scalability features required for allowing an adaptive transport as described in the two examples above are based on RTP multiplexing in order to identify the packets to be dropped or transmitted/forwarded. The multiplexing features defined for Scalable Video Coding [RFC6190] are: single session transmission (SST), where all media layers of the media are transported as single source (SSRC) in a single RTP session; as well as multi session transmission (MST), which should more accurately be called multi stream transmission, where different media layers or a set of media layers are transported in different RTP streams, i.e. using multiple sources (SSRCs). In the first case (SST), additional in-band as well as out-of-band signaling is required in order to allow identification of packets belonging to a specific media layer. Furthermore, an adaptation of the media stream requires dropping of specific packets in order to provide the client with a compliant media stream. In case of using encryption, it is typically required for an adapting network device to be in the security context to allow packet dropping and providing an intact RTP session to the client. This typically requires the network device to be an RTP mixer. In general having a media unaware network device dropping excessive packets will be more problematic than having a Media Aware Network Entity (MANE). First is the need to understand the media format and know which ADUs or payloads that belongs to the layers, that no other layer will be dependent on after the dropping. Secondly, if the MANE can work as RTP mixer or translator it can rewrite the RTP and RTCP in such a way that the receiver will not suspect non-intentional RTP packet losses needing repair actions. This as the receiver can't determine if a lost packet was an important base layer packet or one of the less important extension layers. In the second case (MST), the RTP packet streams can be sent using a single or multiple RTP sessions, and thus transport flows, e.g. on differnt multicast groups. Transmitting the streams in different RTP sessions then the out-of-band signaling typically provides enough information to identify the media layers and its properties. The decision for dropping packets is based on the Network Address which identifies the RTP session to be dropped. In order to allow correct data provision to a decoder after reception from different sessions, data re-alignment mechanisms are described for Scalable Video Coding [RFC6190]. A more generic one is also described in Rapid Sync for RTP flows [RFC6051], which is purely based on existing RTP mechanisms, i.e. the NTP timestamp, for inter-session synchronization. Another signaling feature is the generic indication of dependencies of RTP sessions in SDP, as defined in the Media Decoding Dependency Grouping in SDP [RFC5583]. Using MST within a single RTP session is also possible and allow stream level handling instead of looking deeper into the packets by a MANE. However, transport flow level properties will be the same unless packet based mechanisms like DiffServ is used. When QoS settings, e.g. DiffServ markings, are used to ensure that the extension layers are dropped prior the base layer the receiving end-point has the benefit in MST to know which layer or set of layers the missing packets belong as it will be bound to different RTP sessions. Thus explicitly indicating the importance of the loss. > > - In Section 5.1.6, avoiding wrap-around within the RTCP reporting > timeout interval is also important. If I understand this correctly, this is a minor issue with the RTCP SR and RR packet types as they all uses 32-bit counters. However, other packet types may have issues if they not use extended sequence number counters. This might be more relevant to considerations for configuring RTCP bandwidth and design of RTCP extensions, rather than being an RTP Payload issue. There exists a configuration goal to ensure that RTCP reporting doesn't wrap its fields within multiple reporting intervals. I propose that the following paragraph is added in this section: RTCP is also affected by high packet rates. For RTCP mechanism that do not use extended counters there is significant risk that they wrap multiple times between RTCP reporting or feedback, thus producing uncertainty which packet(s) that are referenced. The payload designer can't effect the RTCP packet formats used and their design, but can note this considerations when configuring RTCP bandwidth and reporting intervals to avoid to wrapping issues. > > - The introduction to Section 7 could usefully reference the template > payload format. Yes, is this ok? A number of sections in the payload format draft need special consideration. These include the Security and IANA Considerations sections that are required in all drafts. Payload formats are also strongly recommended to have the media format description and congestion control considerations. The included RTP Payload format template (Appendix A) contains draft text for some of these sections. > > - Appendix A.10: mention that the RTP circuit breaker ought to be > used and respected? > Okay, added text, I have avoided RFC 2119 language. I think circuit breakers should make clear as an update to RFC 3550 when they are required. The proposed text is: Congestion control for RTP SHALL be used in accordance with RFC 3550 [RFC3550], and with any applicable RTP profile; e.g., RFC 3551 [RFC3551]. An additional requirement if best-effort service is being used is: users of this payload format MUST monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Circuit Breakers [I-D.ietf-avtcore-rtp-circuit-breakers] is an update to RTP [RFC3550] that defines criteria for when one is required to stop sending RTP Packet Streams. The circuit breakers is to be implemented and followed. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From internet-drafts@ietf.org Sat Sep 21 04:58:50 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2238711E8153; Sat, 21 Sep 2013 04:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HL2slrHTlZ2Z; Sat, 21 Sep 2013 04:58:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 286C311E815B; Sat, 21 Sep 2013 04:58:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130921115849.21119.80104.idtracker@ietfa.amsl.com> Date: Sat, 21 Sep 2013 04:58:49 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-howto-06.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 11:58:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Working Gr= oup of the IETF. Title : How to Write an RTP Payload Format Author(s) : Magnus Westerlund Filename : draft-ietf-payload-rtp-howto-06.txt Pages : 56 Date : 2013-09-21 Abstract: This document contains information on how to best write an RTP payload format. It provides reading tips, design practices, and practical tips on how to produce an RTP payload format specification quickly and with good results. A template is also included with instructions that can be used when writing an RTP payload format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-howto-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-howto-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From csp@csperkins.org Sun Sep 22 09:31:27 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33C321F9EA2 for ; Sun, 22 Sep 2013 09:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.669 X-Spam-Level: X-Spam-Status: No, score=-105.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJ50pW2DwBrb for ; Sun, 22 Sep 2013 09:31:22 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9CE11E80F9 for ; Sun, 22 Sep 2013 09:31:18 -0700 (PDT) Received: from [81.187.2.149] (port=38578 helo=[192.168.0.14]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1VNmYv-0005AO-J3; Sun, 22 Sep 2013 17:31:14 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Colin Perkins In-Reply-To: <523D8979.10902@ericsson.com> Date: Sun, 22 Sep 2013 17:31:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CD0A460-A92F-418E-9D6D-6F1B6BEF278F@csperkins.org> <523D8979.10902@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1510) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 16:31:27 -0000 Hi Magnus, On 21 Sep 2013, at 12:56, Magnus Westerlund = wrote: > Thanks for the review comments. I have tried addressing them. I am > submitting an updated draft including these edits. But, I do need > feedback on these edits. >=20 > See below. >=20 > On 2013-09-12 19:04, Colin Perkins wrote: >> On 22 Aug 2013, at 09:58, Ali C. Begen (abegen) >> wrote: >>> (As a WG co-chair) >>>=20 >>> I am starting WGLC for the following draft (version 05). >>> https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto/ >>>=20 >>> This is an important document as it outlines how someone is >>> supposed to write the payload specs. >>>=20 >>> If there are sections you don't understand or that are not clear >>> enough, etc. please post them to the list. We need to get this >>> right to minimize further headaches for future documents in our >>> WG. >>>=20 >>> The deadline for the WGLC is September 20th. >>=20 >>=20 >> I think this is an important draft, and I'm glad to see it >> progressing. It seems to be generally well written and containing >> good advice. I have some number of comments, but these are generally >> all minor points: >>=20 >> - In Section 3.1.2 the discussion of RFC 6015 mentions RFC 2733, but >> RFC 2733 hasn=92t been cited or discussed >=20 > Correct, I added a reference in RFC 5109 text to state that this > replaced RFC 2733, and added as references in both places. >=20 > RFC 5109: The "RTP Payload Format for Generic Forward Error > Correction (FEC)" [RFC5109] provides an XOR based FEC of the = whole > or parts of a number of RTP packets. This specification replaced > the previous specification for XOR based FEC [RFC2733]. These = FEC > packets are sent in a separate stream or as a redundant encoding > using RFC 2198. This FEC scheme has certain restrictions in the > number of packets it can protect. It is suitable for low-to- > medium delay tolerant applications with limited amount of RTP > packets. >=20 > RFC 6015: The "RTP Payload Format for 1-D Interleaved Parity = Forward > Error Correction (FEC)" [RFC6015] provides a variant of the XOR > based Generic protection defined in [RFC2733]. The main > difference is to use interleaving scheme on which packets gets > included as source packets for a particular protection packet. > The interleaving is defined by using every L packets as source > data. And then produce protection data over D number of packets. > Thus each block of D x L source packets will result in L number = of > Repair packets, each capable of repairing one loss. The goal is > to provide better burst error robustness when the packet rate is > higher. This looks good. >> - In Section 3.1.2 the discussion of RFC 3611 might usefully point to >> the IANA registry for XR blocks and the XRBLOCK working group >=20 > RFC 3611: The RTCP Extended Reports (RTCP XR) [RFC3611] consists of > a framework for reports sent within RTCP. It can easily be > extended by defining new report formats, which has occurred. The > list of specified formats are available in IANA's RTCP XR Block > Type registry = (http://www.iana.org/assignments/rtcp-xr-block-types > /rtcp-xr-block-types.xhtml). The report formats that are defined > in RFC3611 provide report information on packet loss, packet > duplication, packet reception times, RTCP statistics summary and > VoIP Quality. [RFC3611] also defines a mechanism that allows > receivers to calculate the RTT to other session participants when > used. Good. >> - Section 3.2: the introduction to this section could be clearer that >> this is an overview of RTP features that are available independent of >> the payload format, and not a list of things that the payload format >> needs to explicitly opt in to/out of. >=20 > This section reviews a number of RTP features and concepts that are > available in RTP independent of the payload format. The RTP payload > format can make use of these when appropriate, and in some cases even > effect the behavior (RTP Timestamp and marker bit). This section does > not remove the necessity to read up on RTP. However it does point out = a > few important details to remember when designing a payload format. It might be worth expanding this to say "...even affect the behaviour = (RTP timestamp and marker bit), but it is important to note that not all = features and concepts are relevant to every payload format"? >> - Section 3.2.2 expands SSRC as =93Sender Source Identifier=94 but = this >> should be =93Synchronisation Source Identifier=94. >=20 > Note that I also change the fourth line to say "of multiple media > sources" rather than "from multiple senders. >=20 > SSRC: The Synchronisation Source Identifier (SSRC) is normally not > used by a payload format other than to identify the RTP timestamp > and sequence number space a packet belongs to, allowing > simultaneously reception of multiple media sources. However, = some > of the RTP mechanisms for improving resilience to packet loss = uses > multiple SSRCs to separate original data and repair or redundant > data. Ok. >> - In Section 3.2.2 the statement =93[RFC5285] specifies how to extend >> the RTP header to carry metadata relating to the payload=94 is >> potentially misleading, since the type of information that usually >> goes into an RTP payload header is also =93metadata relating to the >> payload=94. It might be useful to expand this discussion slightly, to >> make the distinction clear. >=20 > Is this better? >=20 > Header extensions: Payload formats normally specifies the carrying > of meta data related to the media payload in the payload header. > In some cases the meta data may be more generic, e.g. relevant > more to the media type (e.g. audio or video), or RTP packets in > general. In those cases the carrying of this additional meta = data > can be specified in a header extension. One example is the > transport of SMPTE time-codes in the RTP header [RFC5484]. As > [RFC5285] specifies, header extensions must not contain > information required in order to decode the payload successfully. That's better, but I might suggest even stronger wording: "RTP payload = formats often need to include metadata relating to the payload data = being transported. Such metadata is sent as a payload header, at the = start of the payload section of the RTP packet. The RTP packet also = includes space for a header extension [RFC5275]; this can be used to = transport payload format independent metadata, for example a SMPTE time = code for the packet [RFC5484]. The RTP header extensions is not intended = to carry headers that relate to a particular payload format., and must = not contain information needed in order to decode the payload." The last sentence of the first paragraph of Section 3.2.2 also needs = updating. I suggest "Finally, [RFC5285] specifies how to transport = payload format independent metadata relating to the RTP packet". >> - In Section 3.2.2, it might be useful to explain that video payload >> formats are a common example of =93payload formats with a timestamp >> definition which results in no or little correlation between the >> media time instance and its transmission time=94; otherwise this = sounds >> like such payload formats are something unusual. >=20 > This discussion got moved into the new section 5.2, where the related > text says: >=20 > RTP payload formats with a timestamp definition which results in no > or little correlation between the media time instance and its > transmission time cause the RTCP jitter calculation to become > unusable due to the errors introduced on the sender side. Such > examples are for example payload formats for video that requires > multiple packets, where a set of packets will have the same > timestamp, another are payloads that includes alternating set of > redundant information, if the definition used are for the earliest > data included, the the timestamp may jump back and forth. It should > be noted if the payload format has this property or not. >=20 > Good enough? Better, but could still be more explicit. How about changing the "Such = examples are..." sentence to "A common example is a payload format for a = video codec where the RTP timestamp represents the capture time of the = video frame, but frames are large enough that multiple RTP packets need = to be sent for each frame spread across the framing interval". >> - In Section 3.2.2, would it be helpful to explain typical RTP >> timestamp and sequence number behaviour when using discontinuous >> transmission? >=20 > Timestamp: The RTP timestamp indicates the time instance the media > sample belongs to. For discrete media like video, it normally > indicates when the media (frame) was sampled. For continuous > media it normally indicates the first time instance the media > present in the payload represents. For audio this is the = sampling > time of the first sample. All RTP payload formats must specify > the meaning of the timestamp value and the clock rates allowed. > Selecting Timestamp rate is an active design choice and is = further > discussed in Section 5.2. >=20 > Discontinuous transmissions (DTX) that is common among speech > codecs, typically results in gaps or jumps in the timestamp = values > due that there are no media payload to transmit and the next used > timestamp value represent the actual sampling time of the data > transmitted. >=20 > Sequence number: The sequence number is monotonically increasing = and > is set as the packet is sent. This property is used in many > payload formats to recover the order of everything from the whole > stream down to fragments of application data units (ADUs) and the > order they need to be decoded. Discontinuous transmissions does > not result in gaps in the sequence number, as it is monotonically > increasing for each sent RTP packet. Good. >> - In Section 3.2.2, when talking about the RTP timestamp, it might be >> appropriate to reference to leap-seconds draft >=20 > I chose to add a paragraph on this in Section 3.2.4 >=20 > Leap Seconds are extra seconds added or seconds removed to keep our > clocks in sync with earths rotation. Adding or removing seconds can > impact first of all the reference clock as discussed in "RTP and = Leap > Seconds" [I-D.ietf-avtcore-leap-second]. But also in cases where = the > RTP timestamp value are derived using the wall clock during the leap > second event errors can occur. Implementations needs to consider > leap seconds and should consider the recommendations in > [I-D.ietf-avtcore-leap-second]. >=20 Okay. >> - In Section 3.2.2, when talking about payload type numbers, it might >> be useful to be explicit that the binding is dynamic, and that other >> out-of-band configuration information in addition to the payload type >> to payload format binding is usually needed to understand a payload >> format. Reference Section 3.3. >=20 > Payload Type: The payload type is used to indicate on a per packet > basis which format is used. The binding between a payload type > number and a payload format and its configuration are dynamically > bound and RTP session specific. The configuration information = can > be bound to a payload type value by out-of-band signalling > (Section 3.3). An example of this would be video decoder > configuration information. Commonly the same payload type is = used > for a media stream for the whole duration of a session. However > in some cases it may be necessary to change the payload format or > its configuration during the session. Good. >> - Should Section 3.2.3 reference the multiplex-guidelines or >> transport-multiplexing drafts? >=20 >=20 > I think the multiplexing guidelines makes sense. The transport > multiplexing being focused on providing a specific solution to one > combination of RTP sessions to transport mapping appears to specific. >=20 > I added the following last in the section. >=20 > For more discussion and consideration of how and when to use the > different RTP multiplexing points see > [I-D.ietf-avtcore-multiplex-guidelines]. Okay. >> - Section 3.2.4 says =93SSRCs with the same CNAME in different RTP >> sessions can be synchronized=94; this is also true of flows with >> different SSRC but the same CNAME within an RTP session. >=20 > Correct, I changed this to: >=20 > SSRCs with the same CNAME sent in any of multiple RTP sessions can be > synchronized. Okay. >> - Section 3.4: should this say anything about AQM and/or QoS >> support? >=20 > I tried writing something about this. I don't know how useful this is. > Feedback much appreciated. >=20 >=20 > 3.4.2. Different Queuing Algorithms >=20 > Routers and Switches on the network path between an IP sender and a > particular receiver can exhibit different behaviors affecting the = end > to end characteristics. One of the more important aspects of this = is > queuing behavior. Routers and Switches has some amount of queuing = to > handle temporary bursts of data that designated to leave the switch > or router on the same egress link. A queue when not empty results = in > an increased path delay. >=20 > The implementation of the queuing effects the delay and also how > congestion signals (Explicint Congestion Marking (ECN) or packet > drops) are provided to the flow. Reference RFC 6679 here? > The other aspects are if the flow > shares the queue with other flows and how the implementation affects > the flow interaction. This becomes important for example when real- > time flows interacts with long lived TCP flows. TCP have a built in > behavior in its congestion control that strive to fill the buffer, > thus all flows sharing the buffer experienced the delay build up. >=20 > A common but quite poor queue handling mechanism is tail-drop, i.e. > only drop packets when the incoming packet doesn't fit in the queue. > Active Queue Management (AQM) is a term covering mechanism that = tries > to do something smarter buy actively managing the queue, for example > by sending congestion signals earlier by droping packets earlier in > the queue. The behavior also affects the flow interactions. For > example Random Early Drop (RED) selects which packet to drop > randomly. This to give flows that have more packets in the queue a > higher probability to experience the packet loss (congestion = signal). > There is ongoing work to find suitable mechanisms to recommend for > implementation and reduce the use of tail-drop. >=20 > 3.4.3. Quality of Service >=20 > Using best effort Internet one have no guaratees for the paths > properties. Quality of Service (QoS) mechanism are intended to > provide the possility to bound the path properties. Where Diffserv > [RFC2475] markings effects the queing and forwarding behaviors of > routers, the mechanism provides only statistical guarantees and care > in how much marked packets of different types that are entering the > network. Flow based QoS like IntServ [RFC1663] has the potential = for > stricter guarantees as the properties are agreed on by each hop on > the path. I think this is useful. It highlights that there are issues to consider, = which is the goal. >> - Section 4 might be clearer titled =93Standardisation Process for an >> RTP Payload Format=94 >=20 > Agreed >=20 >=20 >>=20 >> - Section 4 =93registration of the RTP payload format name=94 =96 how = does >> this relate to the =93media type=94 discussed in Section 3.3? >=20 > It really should be referencing the Media Type as this is the registry > which matters. Thus changed sentence to: >=20 > For specifications that are defined by standards bodies other than the > IETF the primary milestone is registration of the Media Type for the = RTP > payload format. Ok. >> - The discussion of SST and MST in Section 5.1.5 seems to confuse >> sessions with SSRCs. Isn=92t it more important whether the layers are >> sent within a single RTP media stream, or as separate RTP media >> streams with different SSRC values? Whether the different SSRCs are >> sent in one RTP session of many is then a separate issue, depending >> on how easily one wants to be able to separate the flows for QoS >> purposes. >=20 > The issue is that the SVC payload RFC is a bit confused on this = matter. > I agree that there are two separate important distinctions here. First > if the layers are sent in one RTP packet stream or used multiple ones. > In the second case one gets the question of how one distributes that > over RTP sessions and underlying transports. Especially as some that > implements SVC MST clearly uses a single RTP session and are after the > possibility on a SSRC level to control transmission of layers in RTP > middleboxes. >=20 > I have tried to address this in the text, please review. >=20 > 5.1.5. Media Scalability >=20 > Some codecs support various types of media scalability, i.e. some > data of a media stream may be removed to adapt the media's > properties, such as bitrate and quality. The adaptation may be > applied in the following dimensions of the media: >=20 > Temporal: For video codecs it is possible to adapt the frame rate, > e.g. for H.264 [RFC6184]. >=20 > Spatial: Video codecs supporting scalability may adapt the > resolution, e.g. in SVC [RFC6190]. >=20 > Quality: The quality of the media stream may be scaled by adapting > the accuracy of the coding process, as, e.g. possible with = Signal > to Noise Ratio (SNR) fidelity scalability of SVC [RFC6190]. >=20 > At the time of writing this document, codecs that support = scalability > have a bit of revival. It has been realized that getting the > required functionality for supporting the features of the media > stream into the RTP framework is quite challenging. One of the > recent examples for layered and scalable codecs is Scalable Video > Coding [RFC6190] (SVC). >=20 > SVC is a good example for a payload format supporting media > scalability features, which have been in its basic form already > included in RTP. A layered codec supports the dropping of data = parts > of a media stream, i.e. RTP packets may be not transmitted or > forwarded to a client in order to adapt the media stream rate as = well > as the media stream quality, while still providing a decodable = subset > of the media stream to a client. One example for using the > scalability feature may be an RTP Mixer (Multipoint Control Unit) > which controls the rate and quality sent out to participants in a > communication based on dropping RTP packets or removing part of the > payload. Another example may be an transport channel which allows > for differentiation in Quality of Service (QoS) parameters based on > RTP sessions in a multicast session. In such a case, the more > important packets of the scalable media stream (base layer) may get > better QoS parameters, then the less important packets (enhancement > layer) in order to provide some kind of graceful degradation. The > scalability features required for allowing an adaptive transport as > described in the two examples above are based on RTP multiplexing in > order to identify the packets to be dropped or = transmitted/forwarded. > The multiplexing features defined for Scalable Video Coding = [RFC6190] > are: >=20 > single session transmission (SST), where all media layers of the > media are transported as single source (SSRC) in a single RTP > session; as well as >=20 > multi session transmission (MST), which should more accurately be > called multi stream transmission, where different media layers or > a set of media layers are transported in different RTP streams, > i.e. using multiple sources (SSRCs). >=20 > In the first case (SST), additional in-band as well as out-of-band > signaling is required in order to allow identification of packets > belonging to a specific media layer. Furthermore, an adaptation of > the media stream requires dropping of specific packets in order to > provide the client with a compliant media stream. In case of using > encryption, it is typically required for an adapting network device > to be in the security context to allow packet dropping and providing > an intact RTP session to the client. This typically requires the > network device to be an RTP mixer. >=20 > In general having a media unaware network device dropping excessive > packets will be more problematic than having a Media Aware Network > Entity (MANE). First is the need to understand the media format and > know which ADUs or payloads that belongs to the layers, that no = other > layer will be dependent on after the dropping. Secondly, if the = MANE > can work as RTP mixer or translator it can rewrite the RTP and RTCP > in such a way that the receiver will not suspect non-intentional RTP > packet losses needing repair actions. This as the receiver can't > determine if a lost packet was an important base layer packet or one > of the less important extension layers. >=20 > In the second case (MST), the RTP packet streams can be sent using a > single or multiple RTP sessions, and thus transport flows, e.g. on > differnt multicast groups. Transmitting the streams in different = RTP > sessions then the out-of-band signaling typically provides enough > information to identify the media layers and its properties. The > decision for dropping packets is based on the Network Address which > identifies the RTP session to be dropped. In order to allow correct > data provision to a decoder after reception from different sessions, > data re-alignment mechanisms are described for Scalable Video Coding > [RFC6190]. A more generic one is also described in Rapid Sync for > RTP flows [RFC6051], which is purely based on existing RTP >=20 > mechanisms, i.e. the NTP timestamp, for inter-session > synchronization. Another signaling feature is the generic = indication > of dependencies of RTP sessions in SDP, as defined in the Media > Decoding Dependency Grouping in SDP [RFC5583]. >=20 > Using MST within a single RTP session is also possible and allow > stream level handling instead of looking deeper into the packets by = a > MANE. However, transport flow level properties will be the same > unless packet based mechanisms like DiffServ is used. >=20 > When QoS settings, e.g. DiffServ markings, are used to ensure that > the extension layers are dropped prior the base layer the receiving > end-point has the benefit in MST to know which layer or set of = layers > the missing packets belong as it will be bound to different RTP > sessions. Thus explicitly indicating the importance of the loss. I think this is okay, but it really needs an implementer of the SVC = format to comment too. >> - In Section 5.1.6, avoiding wrap-around within the RTCP reporting >> timeout interval is also important. >=20 > If I understand this correctly, this is a minor issue with the RTCP SR > and RR packet types as they all uses 32-bit counters. However, other > packet types may have issues if they not use extended sequence number > counters. >=20 > This might be more relevant to considerations for configuring RTCP > bandwidth and design of RTCP extensions, rather than being an RTP > Payload issue. There exists a configuration goal to ensure that RTCP > reporting doesn't wrap its fields within multiple reporting intervals. >=20 > I propose that the following paragraph is added in this section: >=20 > RTCP is also affected by high packet rates. For RTCP mechanism that do > not use extended counters there is significant risk that they wrap > multiple times between RTCP reporting or feedback, thus producing > uncertainty which packet(s) that are referenced. The payload designer > can't effect the RTCP packet formats used and their design, but can = note > this considerations when configuring RTCP bandwidth and reporting > intervals to avoid to wrapping issues. That's fine, although I was actually suggesting something simpler, which = is to change "As rule of thumb, it must not be possible to wrap the = sequence number space in less than 2 minutes (TCP maximum segment = lifetime)" to "...must not be possible to wrap the sequence number space = in less than an RTCP reporting interval". >> - The introduction to Section 7 could usefully reference the template >> payload format. >=20 > Yes, is this ok? >=20 > A number of sections in the payload format draft need special > consideration. These include the Security and IANA Considerations > sections that are required in all drafts. Payload formats are also > strongly recommended to have the media format description and > congestion control considerations. The included RTP Payload format > template (Appendix A) contains draft text for some of these = sections. Yes. >> - Appendix A.10: mention that the RTP circuit breaker ought to be >> used and respected? >>=20 >=20 > Okay, added text, I have avoided RFC 2119 language. I think circuit > breakers should make clear as an update to RFC 3550 when they are > required. The proposed text is: >=20 > Congestion control for RTP SHALL be used in accordance with RFC 3550 > [RFC3550], and with any applicable RTP profile; e.g., RFC 3551 > [RFC3551]. An additional requirement if best-effort service is = being > used is: users of this payload format MUST monitor packet loss to > ensure that the packet loss rate is within acceptable parameters. > Circuit Breakers [I-D.ietf-avtcore-rtp-circuit-breakers] is an = update > to RTP [RFC3550] that defines criteria for when one is required to > stop sending RTP Packet Streams. The circuit breakers is to be > implemented and followed. Looks good. Cheers, Colin --=20 Colin Perkins http://csperkins.org/ From Lindsay@worldcastsystems.com Tue Sep 24 10:03:19 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AE521F9A05 for ; Tue, 24 Sep 2013 10:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_19=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GPkkuWJUkZG for ; Tue, 24 Sep 2013 10:03:15 -0700 (PDT) Received: from mailgate.aptcodecs.com (mailgate.aptcodecs.com [217.33.179.85]) by ietfa.amsl.com (Postfix) with ESMTP id A8ED811E813A for ; Tue, 24 Sep 2013 10:03:13 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 24 Sep 2013 18:03:10 +0100 Message-ID: <8C4E0C2409735E4FBC22D754A238F94D02F74FD4@APTSBS.apt.local> In-Reply-To: <0B7378E0-0124-4121-8DA0-B01EF1186715@vidyo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] WGLC for draft-ietf-payload-rtp-aptx-01 Thread-Index: Ac6zCz/NRAIJ+BVMRiaGH9ixCdwj8gGO4OIg References: <0B7378E0-0124-4121-8DA0-B01EF1186715@vidyo.com> From: "John Lindsay" To: Cc: Jonathan Lennox , Foerster@worldcastsystems.com Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-aptx-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 17:03:19 -0000 Hi Jonathon Thanks for reviewing this and the points raised. I agree on re-reading that the delivery method test is a bit abstract and maybe doesn't add anything, by delivery method we mean the algorithm selected e.g. Standard or Enhanced APTX. As I think this is clear to the reader I think these lines could be removed. Hence I propose changing some sections to remove these references. 6.2 From The required parameters "variant" and "bitresolution" MUST be included in the SDP "a=3Dfmtp" attribute and MUST follow the delivery-method that applies.=20 To The required parameters "variant" and "bitresolution" MUST be included in the SDP "a=3Dfmtp" attribute. From The optional parameters "stereo-channel-pairs", "embedded- autosync-channels", "embedded-aux-channels", and "maxptime" when present, MUST be included in the SDP "a=3Dfmtp" attribute and MUST follow the delivery-method that applies.=20 To The optional parameters "stereo-channel-pairs", "embedded- autosync-channels", "embedded-aux-channels", MUST be=20 included in the SDP "a=3Dfmtp" attribute. SDP-Mapping Agreed this should have its own SDP a=3Dattribute, suggest changing section 6.2 from The parameter "maxptime" when present, MUST be included in the=20 SDP "a=3Dmaxptime" attribute. Marker bit. Again this can be changed as per RFC3551, as we have no use for this in our profile (RFC3550) it can follow the recommendations of RFC 3551 where it will be zero for most of the intended applications that we can see.=20 Suggest changing section 5.1 from o M - This payload format defines no use for this bit. Senders SHOULD set this bit to zero in each outgoing packet. o M - As per [RFC3551] Payload types As I understand it the avtcore group has been discussing a new RFC that will update RFC3551 due to conflicts but it is currently unpublished work. What recommendations does the group have for the doc on this? Currently I feel we reflect what is stated in RFC3551? Aux data The Aux data channel can be used for whatever the codec user requires and is not defined by this draft, it provides a point to point channel and is embedded within the Audio payload at 1/4 of the Audio sampling rate? To get access to this you would have to decode the audio payload, for which you would need either a standard of Enhanced apt-X codec. Hence we feel any security issues are minimal? What is the feeling of the workgroup? Section 3 of the doc provides an overview of the codecs operation. The aim of the draft is how to packetize Standard or Enhanced apt-X over RTP not to explain the operation of the codec. Further details are likely to be proprietary to CSR and interested parties would need to talk to CSR directly about obtaining licenses and setting up NDA's for further information.=20 Please feel free to comment on the above. Thanks John -----Original Message----- From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Jonathan Lennox Sent: 16 September 2013 19:36 To: Ali C. Begen (abegen) Cc: payload@ietf.org Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-aptx-01 The document discusses that a number of items are dependent on the "delivery method", and says that the delivery method can be negotiated through offer/answer. However, the delivery method parameter is never actually defined anywhere. Either delivery method needs to be defined, or discussion of it needs to be removed, depending on whether or not delivery-method was actually meant to be included in the final spec. The SDP mapping says that maxptime is encoded in the fmtp parameter. This is incorrect; as specified by RFC 4566, maxptime is carried in its own SDP a=3D attribute. The RTP header section says that the marker bit is not used. Unless there's a good reason for this, I suggest that instead the usual RFC 3551 marker bit semantic for audio be applied (i.e., the marker bit is set for end of silence / beginning of talkspurt). If there's a reason this semantic is inappropriate, it should be explained. The RTP header section also says that the RTP dynamic payload types can only be in the range 96 - 127. This is incorrect; that's the primary range, but other values can be used once that range is exhausted. See, e.g., the recent discussion on the avtcore list. No information is given about the semantic content of the data carried in the auxiliary data channel. Is the semantic of this data defined by the codec, or would it need to be described or negotiated in SDP? (Doing neither, i.e. providing an arbitrary data channel with no mechanism for describing or negotiating its content, seems likely to lead to interoperability problems.) Also, are there any security considerations introduced by the auxiliary data channel? It would be good to have a reference to some document by CSR plc describing the apt-X codecs, even if they don't include full proprietary details of the workings of the codec. On Sep 16, 2013, at 9:08 AM, "Ali C. Begen (abegen)" wrote: > (As a WG co-chair) >=20 > I am starting WGLC for the following draft (version 01).=20 > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-aptx/ >=20 > It is a short document. If you have comments, agreements or disagreements, please let the list know in either case. >=20 > The deadline for the WGLC is September 30th. >=20 > -acbegen > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload >=20 -- Jonathan Lennox jonathan@vidyo.com _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From Lindsay@worldcastsystems.com Tue Sep 24 10:06:20 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4B021F9A05 for ; Tue, 24 Sep 2013 10:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.054 X-Spam-Level: X-Spam-Status: No, score=-1.054 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhIIik2KHPBm for ; Tue, 24 Sep 2013 10:06:16 -0700 (PDT) Received: from mailgate.aptcodecs.com (mailgate.aptcodecs.com [217.33.179.85]) by ietfa.amsl.com (Postfix) with ESMTP id C35B621F9A57 for ; Tue, 24 Sep 2013 10:06:07 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CEB948.5BC4E9CB" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 24 Sep 2013 18:06:06 +0100 Message-ID: <8C4E0C2409735E4FBC22D754A238F94D02F74FD5@APTSBS.apt.local> In-Reply-To: <52385092.5000000@alvestrand.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-aptx-01.txt Thread-Index: Ac6zpNo0fG4bNb95TlOQvwwB2MldaAFoxssQ References: <8C4E0C2409735E4FBC22D754A238F94D02F74C4C@APTSBS.apt.local> <52385092.5000000@alvestrand.no> From: "John Lindsay" To: Cc: Foerster@worldcastsystems.com Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-aptx-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 17:06:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CEB948.5BC4E9CB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Harald =20 Thanks for reviewing this and the points raised. =20 To increase clarity we can change the statement in section 3 =20 From Standard apt-X and Enhanced apt-X are proprietary audio coding algorithms, licensed by CSR plc and widely deployed in a variety of audio processing equipment. =20 To Standard apt-X and Enhanced apt-X are proprietary audio coding algorithms, which can be licensed from CSR plc and are widely=20 deployed in a variety of audio processing equipment. =20 Section 3 of the doc provides an overview of the codecs operation. The aim of the draft is how to packetize Standard or Enhanced apt-X over RTP not to explain the operation of the codec. Further details are likely to be proprietary to CSR and interested parties would need to talk to CSR directly about obtaining licenses and setting up NDA's etc for further information.=20 =20 Regards =20 John =20 From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Harald Alvestrand Sent: 17 September 2013 13:53 To: payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-aptx-01.txt =20 Brief scan, one question: Is it possible to offer a stable reference for what "Standard apt-x" and "Enhanced apt-x" means? The closest I can get is "licensed by CSR plc", which presumably means that "it means what CSR plc thinks it means", but it would be great to have that stated explicitly. Something like: The codecs "apt-x" and "Extended apt-x" are defined by CSR plc, an UK company. Section 3 of the draft *almost* says that, but isn't completely unambiguous ("licensed by" can mean both "CSR is a licensor" and "CSR is a licensee, someone else defines it"). I *think* this is a nit. On 09/10/2013 03:50 PM, John Lindsay wrote: Hi =20 A new draft has been uploaded to the IETF Payload workgroup at https://datatracker.ietf.org/wg/payload/. =20 The new document makes a few minor changes for IDNITS checking and also takes account of the comments made by Peter Stevens last week. =20 A summary of the changes are as follows. =20 Page 1, IETF Copyright notice updated to 2013. Page 10, updated formatting for IDNITS check. Page 14, Section 6 updated to reflect RFC 6838 which supersedes RFC 4288. Page 16, Section 6.2.1 type corrected An - A as per Peter Stevens comments. Page 18, Section 7 now reference 6.1 rather than 7.1, again thanks to Peters proof reading. Page 21, new RFC6338 referenced. =20 Thanks to everyone who has read and commented on the draft. =20 Regards =20 John =20 =20 =09 =09 =09 =09 _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload =20 ------_=_NextPart_001_01CEB948.5BC4E9CB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Harald

 

Thanks for = reviewing this and the points raised.

 

To increase clarity = we can change the statement in section 3

 

From

Standard apt-X and = Enhanced apt-X are proprietary audio coding

   = algorithms, licensed by CSR plc and widely deployed in a variety = of

   audio processing = equipment.

 

To

Standard apt-X and = Enhanced apt-X are proprietary audio coding

   = algorithms, which can be licensed from CSR plc and are widely =

  deployed in a variety of audio = processing equipment.

 

Section 3 of the = doc provides an overview of the codecs operation. The aim of the draft = is how to packetize Standard or Enhanced apt-X over RTP not to explain = the operation of the codec. Further details are likely to be proprietary = to CSR and interested parties would need to talk to CSR directly about = obtaining licenses and setting up NDA's etc for further information. =

 

Regards

 

John

 

From: payload-bounces@ietf.org = [mailto:payload-bounces@ietf.org] On Behalf Of Harald = Alvestrand
Sent: 17 September 2013 13:53
To: = payload@ietf.org
Subject: Re: [payload] I-D Action: = draft-ietf-payload-rtp-aptx-01.txt

 

Brief = scan, one question:

Is it possible to offer a stable reference = for what "Standard apt-x" and "Enhanced apt-x" = means?

The closest I can get is "licensed by CSR plc", = which presumably means that "it means what CSR plc thinks it = means", but it would be great to have that stated = explicitly.

Something like:

The codecs "apt-x" = and "Extended apt-x" are defined by CSR plc, an UK = company.

Section 3 of the draft *almost* says that, but isn't = completely unambiguous ("licensed by" can mean both "CSR = is a licensor" and "CSR is a licensee, someone else defines = it").

I *think* this is a nit.


On 09/10/2013 = 03:50 PM, John Lindsay wrote:

Hi

 

A new draft has been = uploaded to the IETF Payload workgroup at https://datatracker.iet= f.org/wg/payload/.

 

The new document makes a = few minor changes for IDNITS checking and also takes account of the = comments made by Peter Stevens last week.

 

A summary of the changes = are as follows.

 

Page 1, IETF Copyright = notice updated to 2013.

Page 10, updated formatting for IDNITS = check.

Page 14, Section 6 updated to reflect RFC 6838 = which supersedes RFC 4288.

Page 16, Section 6.2.1 = type corrected An – A as per Peter Stevens = comments.

Page 18, Section 7 now reference 6.1 rather than = 7.1, again thanks to Peters proof reading.

Page 21, new RFC6338 = referenced.

 

Thanks to everyone who = has read and commented on the draft.

 

Regards

 

John

 

 




= 

_______________________________________________
= 
payload mailing list
payload@ietf.org
https://www.ietf.o= rg/mailman/listinfo/payload

 

------_=_NextPart_001_01CEB948.5BC4E9CB-- From jonathan@vidyo.com Tue Sep 24 13:36:51 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFB821F8F61 for ; Tue, 24 Sep 2013 13:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_19=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEcE81oHUp1Q for ; Tue, 24 Sep 2013 13:36:35 -0700 (PDT) Received: from server209.appriver.com (server209c.appriver.com [8.31.233.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1067221F9D7D for ; Tue, 24 Sep 2013 13:36:19 -0700 (PDT) X-Note-AR-ScanTimeLocal: 9/24/2013 4:36:10 PM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-72/SG:2 9/24/2013 4:35:33 PM X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.848191 p=-0.94727 Source White X-Signature-Violations: 0-0-0-16394-c X-Note-419: 31.201 ms. Fail:0 Chk:1347 of 1347 total X-Note: SCH-CT/SI:0-1347/SG:1 9/24/2013 4:35:54 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNKNOWN->LOCAL X-Note-Sending-IP: 162.209.16.214 X-Note-Reverse-DNS: X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G340 G341 G342 G343 G347 G348 G455 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.214] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 59817262; Tue, 24 Sep 2013 16:36:10 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0146.000; Tue, 24 Sep 2013 15:36:09 -0500 From: Jonathan Lennox To: John Lindsay Thread-Topic: [payload] WGLC for draft-ietf-payload-rtp-aptx-01 Thread-Index: AQHOst3GQJ5PwGEhn0qLtw2WH9fA5ZnJBV4AgAx4nACAADuBAA== Date: Tue, 24 Sep 2013 20:36:08 +0000 Message-ID: References: <0B7378E0-0124-4121-8DA0-B01EF1186715@vidyo.com> <8C4E0C2409735E4FBC22D754A238F94D02F74FD4@APTSBS.apt.local> In-Reply-To: <8C4E0C2409735E4FBC22D754A238F94D02F74FD4@APTSBS.apt.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.1.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <0C0CEC57FF353B44B599E43C1D35CDCD@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-aptx-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 20:36:51 -0000 On Sep 24, 2013, at 1:03 PM, John Lindsay wrote: > Hi Jonathon >=20 > Thanks for reviewing this and the points raised. >=20 > I agree on re-reading that the delivery method test is a bit abstract > and maybe doesn't add anything, by delivery method we mean the algorithm > selected e.g. Standard or Enhanced APTX. > As I think this is clear to the reader I think these lines could be > removed. Okay. > Hence I propose changing some sections to remove these references. >=20 > 6.2 > From > The required parameters "variant" and "bitresolution" MUST be > included in the SDP "a=3Dfmtp" attribute and MUST follow the > delivery-method that applies.=20 > To > The required parameters "variant" and "bitresolution" MUST be > included in the SDP "a=3Dfmtp" attribute. Seems good. > From > The optional parameters "stereo-channel-pairs", "embedded- > autosync-channels", "embedded-aux-channels", and "maxptime" when > present, MUST be included in the SDP "a=3Dfmtp" attribute and MUST > follow the delivery-method that applies.=20 > To > The optional parameters "stereo-channel-pairs", "embedded- > autosync-channels", "embedded-aux-channels", MUST be=20 > included in the SDP "a=3Dfmtp" attribute. You lost the "when present" in your edit, which I assume should still be th= ere. > SDP-Mapping >=20 > Agreed this should have its own SDP a=3Dattribute, suggest changing > section 6.2 from >=20 > The parameter "maxptime" when present, MUST be included in the=20 > SDP "a=3Dmaxptime" attribute. That seems good. > Marker bit. >=20 > Again this can be changed as per RFC3551, as we have no use for this in > our profile (RFC3550) it can follow the recommendations of RFC 3551 > where it will be zero for most of the intended applications that we can > see.=20 >=20 > Suggest changing section 5.1 from >=20 > o M - This payload format defines no use for this bit. Senders > SHOULD set this bit to zero in each outgoing packet. >=20 > o M - As per [RFC3551] A bit vague, since RFC 3551 has other usages of the M bit for video. I'd s= uggest "As per [RFC3551] Section 4.1". > Payload types > As I understand it the avtcore group has been discussing a new RFC that > will update RFC3551 due to conflicts but it is currently unpublished > work. What recommendations does the group have for the doc on this? > Currently I feel we reflect what is stated in RFC3551? I'd just say "A dynamic payload type MUST be used", and drop the reference = to the range. > Aux data > The Aux data channel can be used for whatever the codec user requires > and is not defined by this draft, it provides a point to point channel > and is embedded within the Audio payload at 1/4 of the Audio sampling > rate? The problem with "whatever the codec user requires" is that it's "whatever = the sender wants", not "whatever the receiver wants" -- so the receiver mig= ht have no idea what the sender is putting in this channel. Unless you're = assuming that both sides are under the same administrative control, this se= ems to me like it can to interoperability problems. What is this channel commonly used for, and how is it configured? > To get access to this you would have to decode the audio payload, for > which you would need either a standard of Enhanced apt-X codec. Hence we > feel any security issues are minimal? What is the feeling of the > workgroup? Again, it's what it's used for, and whether you can always guarantee that t= he other end isn't sending you something hostile if the channel is used for= some sort of active data. (Don't assume security-through-obscurity; i.e.,= the apt-X codec being proprietary doesn't mean that a bad guy can't encode= or decode it.) >=20 > Section 3 of the doc provides an overview of the codecs operation. The > aim of the draft is how to packetize Standard or Enhanced apt-X over RTP > not to explain the operation of the codec. Further details are likely to > be proprietary to CSR and interested parties would need to talk to CSR > directly about obtaining licenses and setting up NDA's for further > information.=20 That's fine -- but does CSR have any public (non-technical) data sheets tha= t can be cited, or anything else that an interested party can use to figure= out how to contact CSR to decide whether they want to begin this process? = I see for instance -- citing that (or something better) as an inf= ormative reference for background on apt-X would seem reasonable. >=20 > Please feel free to comment on the above. >=20 > Thanks >=20 > John >=20 >=20 > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > Behalf Of Jonathan Lennox > Sent: 16 September 2013 19:36 > To: Ali C. Begen (abegen) > Cc: payload@ietf.org > Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-aptx-01 >=20 > The document discusses that a number of items are dependent on the > "delivery method", and says that the delivery method can be negotiated > through offer/answer. However, the delivery method parameter is never > actually defined anywhere. Either delivery method needs to be defined, > or discussion of it needs to be removed, depending on whether or not > delivery-method was actually meant to be included in the final spec. >=20 > The SDP mapping says that maxptime is encoded in the fmtp parameter. > This is incorrect; as specified by RFC 4566, maxptime is carried in its > own SDP a=3D attribute. >=20 > The RTP header section says that the marker bit is not used. Unless > there's a good reason for this, I suggest that instead the usual RFC > 3551 marker bit semantic for audio be applied (i.e., the marker bit is > set for end of silence / beginning of talkspurt). If there's a reason > this semantic is inappropriate, it should be explained. >=20 > The RTP header section also says that the RTP dynamic payload types can > only be in the range 96 - 127. This is incorrect; that's the primary > range, but other values can be used once that range is exhausted. See, > e.g., the recent discussion on the avtcore list. >=20 > No information is given about the semantic content of the data carried > in the auxiliary data channel. Is the semantic of this data defined by > the codec, or would it need to be described or negotiated in SDP? > (Doing neither, i.e. providing an arbitrary data channel with no > mechanism for describing or negotiating its content, seems likely to > lead to interoperability problems.) Also, are there any security > considerations introduced by the auxiliary data channel? >=20 > It would be good to have a reference to some document by CSR plc > describing the apt-X codecs, even if they don't include full proprietary > details of the workings of the codec. >=20 > On Sep 16, 2013, at 9:08 AM, "Ali C. Begen (abegen)" > wrote: >=20 >> (As a WG co-chair) >>=20 >> I am starting WGLC for the following draft (version 01).=20 >> https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-aptx/ >>=20 >> It is a short document. If you have comments, agreements or > disagreements, please let the list know in either case. >>=20 >> The deadline for the WGLC is September 30th. >>=20 >> -acbegen >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >>=20 >=20 > -- > Jonathan Lennox > jonathan@vidyo.com >=20 >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From Lindsay@worldcastsystems.com Wed Sep 25 05:09:18 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488DE21F9E40 for ; Wed, 25 Sep 2013 05:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.517 X-Spam-Level: X-Spam-Status: No, score=-1.517 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_00=-2.599, J_CHICKENPOX_19=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIbZWM9-L65i for ; Wed, 25 Sep 2013 05:09:14 -0700 (PDT) Received: from mailgate.aptcodecs.com (mailgate.aptcodecs.com [217.33.179.85]) by ietfa.amsl.com (Postfix) with ESMTP id D7AC621F9FF9 for ; Wed, 25 Sep 2013 05:09:13 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 25 Sep 2013 13:09:11 +0100 Message-ID: <8C4E0C2409735E4FBC22D754A238F94D02F74FF4@APTSBS.apt.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] WGLC for draft-ietf-payload-rtp-aptx-01 Thread-Index: AQHOst3GQJ5PwGEhn0qLtw2WH9fA5ZnJBV4AgAx4nACAADuBAIAArYBg References: <0B7378E0-0124-4121-8DA0-B01EF1186715@vidyo.com> <8C4E0C2409735E4FBC22D754A238F94D02F74FD4@APTSBS.apt.local> From: "John Lindsay" To: "Jonathan Lennox" Cc: Hartmut Foerster , payload@ietf.org Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-aptx-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 12:09:18 -0000 Hi Jonathon Editorial comments noted and will be included in next draft. Specifically the missing "when present" and "As per [RFC3551] Section 4.1" notes. Payload types, ok, agreed, again will be added to next draft. In terms of Aux data the majority of users in the EBU ACIP workgroup (where the requests for an apt-X RFC originated ) are codec manufacturers typically aiming at a studio to transmitter (STL) application, (however apt-x over RTP obviously has other uses). Hence the majority of the current users we know of will uses the aux data channel to transmit RS232 data up to 1/4 sampling rate typically containing RDS data. It will be up to the implementer of the solution to decide what data the channel is used for and typically the units would be used in a complete network hence all the equipment is generally controlled by one broadcaster. >From a security point of view the aux channel travels in the compressed audio stream and encapsulated in an RTP packet hence security concerns for the aux channel are exactly the same as the audio channel and pose no different risk? As above its generally an RS232 data channel with a Protocol, hence if malicious data were to be sent in this channel it would be up to end equipment to decide if it was protocol compliant legitimate data and hence to decode or not.=20 I have taken a look at CSR's website, CSR's main focus is Bluetooth audio and they operate in a more commercial environment than apt-X's previous 25 year history in broadcast audio. Hence the data on apt-X and Enhanced apt-X now more reflects this focus. However some useful links may be. http://www.csr.com/products/60/aptx http://www.csr.com/products/58/aptx-enhanced Regards John -----Original Message----- From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 Sent: 24 September 2013 21:36 To: John Lindsay Cc: ; Ali C. Begen (abegen); Hartmut Foerster Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-aptx-01 On Sep 24, 2013, at 1:03 PM, John Lindsay wrote: > Hi Jonathon >=20 > Thanks for reviewing this and the points raised. >=20 > I agree on re-reading that the delivery method test is a bit abstract=20 > and maybe doesn't add anything, by delivery method we mean the=20 > algorithm selected e.g. Standard or Enhanced APTX. > As I think this is clear to the reader I think these lines could be=20 > removed. Okay. > Hence I propose changing some sections to remove these references. >=20 > 6.2 > From > The required parameters "variant" and "bitresolution" MUST be > included in the SDP "a=3Dfmtp" attribute and MUST follow the > delivery-method that applies.=20 > To > The required parameters "variant" and "bitresolution" MUST be > included in the SDP "a=3Dfmtp" attribute. Seems good. > From > The optional parameters "stereo-channel-pairs", "embedded- > autosync-channels", "embedded-aux-channels", and "maxptime" when > present, MUST be included in the SDP "a=3Dfmtp" attribute and = MUST > follow the delivery-method that applies.=20 > To > The optional parameters "stereo-channel-pairs", "embedded- > autosync-channels", "embedded-aux-channels", MUST be=20 > included in the SDP "a=3Dfmtp" attribute. You lost the "when present" in your edit, which I assume should still be there. > SDP-Mapping >=20 > Agreed this should have its own SDP a=3Dattribute, suggest changing=20 > section 6.2 from >=20 > The parameter "maxptime" when present, MUST be included in the=20 > SDP "a=3Dmaxptime" attribute. That seems good. > Marker bit. >=20 > Again this can be changed as per RFC3551, as we have no use for this=20 > in our profile (RFC3550) it can follow the recommendations of RFC 3551 > where it will be zero for most of the intended applications that we=20 > can see. >=20 > Suggest changing section 5.1 from >=20 > o M - This payload format defines no use for this bit. Senders > SHOULD set this bit to zero in each outgoing packet. >=20 > o M - As per [RFC3551] A bit vague, since RFC 3551 has other usages of the M bit for video. I'd suggest "As per [RFC3551] Section 4.1". > Payload types > As I understand it the avtcore group has been discussing a new RFC=20 > that will update RFC3551 due to conflicts but it is currently=20 > unpublished work. What recommendations does the group have for the doc on this? > Currently I feel we reflect what is stated in RFC3551? I'd just say "A dynamic payload type MUST be used", and drop the reference to the range. > Aux data > The Aux data channel can be used for whatever the codec user requires=20 > and is not defined by this draft, it provides a point to point channel > and is embedded within the Audio payload at 1/4 of the Audio sampling=20 > rate? The problem with "whatever the codec user requires" is that it's "whatever the sender wants", not "whatever the receiver wants" -- so the receiver might have no idea what the sender is putting in this channel. Unless you're assuming that both sides are under the same administrative control, this seems to me like it can to interoperability problems. What is this channel commonly used for, and how is it configured? > To get access to this you would have to decode the audio payload, for=20 > which you would need either a standard of Enhanced apt-X codec. Hence=20 > we feel any security issues are minimal? What is the feeling of the=20 > workgroup? Again, it's what it's used for, and whether you can always guarantee that the other end isn't sending you something hostile if the channel is used for some sort of active data. (Don't assume security-through-obscurity; i.e., the apt-X codec being proprietary doesn't mean that a bad guy can't encode or decode it.) >=20 > Section 3 of the doc provides an overview of the codecs operation. The > aim of the draft is how to packetize Standard or Enhanced apt-X over=20 > RTP not to explain the operation of the codec. Further details are=20 > likely to be proprietary to CSR and interested parties would need to=20 > talk to CSR directly about obtaining licenses and setting up NDA's for > further information. That's fine -- but does CSR have any public (non-technical) data sheets that can be cited, or anything else that an interested party can use to figure out how to contact CSR to decide whether they want to begin this process? I see for instance -- citing that (or something better) as an informative reference for background on apt-X would seem reasonable. >=20 > Please feel free to comment on the above. >=20 > Thanks >=20 > John >=20 >=20 > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On=20 > Behalf Of Jonathan Lennox > Sent: 16 September 2013 19:36 > To: Ali C. Begen (abegen) > Cc: payload@ietf.org > Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-aptx-01 >=20 > The document discusses that a number of items are dependent on the=20 > "delivery method", and says that the delivery method can be negotiated > through offer/answer. However, the delivery method parameter is never > actually defined anywhere. Either delivery method needs to be=20 > defined, or discussion of it needs to be removed, depending on whether > or not delivery-method was actually meant to be included in the final spec. >=20 > The SDP mapping says that maxptime is encoded in the fmtp parameter. > This is incorrect; as specified by RFC 4566, maxptime is carried in=20 > its own SDP a=3D attribute. >=20 > The RTP header section says that the marker bit is not used. Unless=20 > there's a good reason for this, I suggest that instead the usual RFC > 3551 marker bit semantic for audio be applied (i.e., the marker bit is > set for end of silence / beginning of talkspurt). If there's a reason > this semantic is inappropriate, it should be explained. >=20 > The RTP header section also says that the RTP dynamic payload types=20 > can only be in the range 96 - 127. This is incorrect; that's the=20 > primary range, but other values can be used once that range is=20 > exhausted. See, e.g., the recent discussion on the avtcore list. >=20 > No information is given about the semantic content of the data carried > in the auxiliary data channel. Is the semantic of this data defined=20 > by the codec, or would it need to be described or negotiated in SDP? > (Doing neither, i.e. providing an arbitrary data channel with no=20 > mechanism for describing or negotiating its content, seems likely to=20 > lead to interoperability problems.) Also, are there any security=20 > considerations introduced by the auxiliary data channel? >=20 > It would be good to have a reference to some document by CSR plc=20 > describing the apt-X codecs, even if they don't include full=20 > proprietary details of the workings of the codec. >=20 > On Sep 16, 2013, at 9:08 AM, "Ali C. Begen (abegen)"=20 > > wrote: >=20 >> (As a WG co-chair) >>=20 >> I am starting WGLC for the following draft (version 01).=20 >> https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-aptx/ >>=20 >> It is a short document. If you have comments, agreements or > disagreements, please let the list know in either case. >>=20 >> The deadline for the WGLC is September 30th. >>=20 >> -acbegen >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >>=20 >=20 > -- > Jonathan Lennox > jonathan@vidyo.com >=20 >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From mramalho@cisco.com Wed Sep 25 14:16:45 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8159A11E80EC for ; Wed, 25 Sep 2013 14:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.765 X-Spam-Level: X-Spam-Status: No, score=-9.765 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvejzqPQROfa for ; Wed, 25 Sep 2013 14:16:40 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 250FB21F9E2B for ; Wed, 25 Sep 2013 14:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4539; q=dns/txt; s=iport; t=1380143799; x=1381353399; h=from:to:subject:date:message-id:mime-version; bh=XGe/1XjZKxHHOVmBM0kx3YVoIvFPzvq5bVmfN+HxM0Q=; b=SceYvRET0/W6PsaAasi2DsF6hThD5Gcrgi2E0gWNavk5P3Fcm79cROox 9pQkNyQJGozXQ7S5Koy30ODQN7Oy0eUu6bSa4Y3C+fHtPTx2ua88LtqTy EFnE7aAl2Y4E7wFg4UD+vFtuCK+qflV4KC4fbpMbaWE32FvbFSvmcVgUg o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8HAOhRQ1KtJV2Y/2dsb2JhbABbgkNEOFKuM4leiEOBIRZtB4InAQQtXgEMHlYmAQQbh34MmmyhSI8gg1WBAAOZK5BIgySCKg X-IronPort-AV: E=Sophos;i="4.90,980,1371081600"; d="scan'208,217";a="264472681" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 25 Sep 2013 21:16:38 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8PLGcN1003157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 25 Sep 2013 21:16:38 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.19]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Wed, 25 Sep 2013 16:16:38 -0500 From: "Michael Ramalho (mramalho)" To: "payload@ietf.org" Thread-Topic: Toward WGLC on G.711.0 RTP Payload Spec Thread-Index: Ac66NIJIYK6mF56FR8aFqe5fsMHitg== Date: Wed, 25 Sep 2013 21:16:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.20.110] Content-Type: multipart/alternative; boundary="_000_D21571530BF9644D9A443D6BD95B91031564BB1Cxmbrcdx12ciscoc_" MIME-Version: 1.0 Subject: [payload] Toward WGLC on G.711.0 RTP Payload Spec X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 21:16:45 -0000 --_000_D21571530BF9644D9A443D6BD95B91031564BB1Cxmbrcdx12ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, The payload WG has a milestone to submit the RTP Payload Format for G.711.0= for proposed standard in December 2013 (http://datatracker.ietf.org/wg/pay= load/charter/ ). The current working group draft is draft-ietf-payload-g7110-00 ( http://dat= atracker.ietf.org/doc/draft-ietf-payload-g7110/ ). Although this working group document is a "00" draft, it spent much time an= d prior re-writes as an individual contribution draft known as draft-ramalh= o-payload-g7110-0X. I have not received any requests to change this document since the conversi= on of the individual contribution draft to the working group draft (which o= ccurred in June 2013). As I would like to ask the Payload chairs to last call this document at the= Vancouver IETF, please provide any input you have on this document to this= list (including if you think it is ready as it is). Thanks in advance, Michael A. Ramalho --_000_D21571530BF9644D9A443D6BD95B91031564BB1Cxmbrcdx12ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

The payload WG has a milestone to submit the RTP Pay= load Format for G.711.0 for proposed standard in December 2013 (http://data= tracker.ietf.org/wg/payload/charter/ ).

 

The current working group draft is draft-ietf-payloa= d-g7110-00 ( http:= //datatracker.ietf.org/doc/draft-ietf-payload-g7110/ ).

 

Although this working group document is a “00&= #8221; draft, it spent much time and prior re-writes as an individual contr= ibution draft known as draft-ramalho-payload-g7110-0X.

 

I have not received any requests to change this docu= ment since the conversion of the individual contribution draft to the worki= ng group draft (which occurred in June 2013).

 

As I would like to ask the Payload chairs to last ca= ll this document at the Vancouver IETF, please provide any input you have o= n this document to this list (including if you think it is ready as it is).=

 

Thanks in advance,

 

Michael A. Ramalho

--_000_D21571530BF9644D9A443D6BD95B91031564BB1Cxmbrcdx12ciscoc_-- From magnus.westerlund@ericsson.com Thu Sep 26 00:06:54 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E0811E8168 for ; Thu, 26 Sep 2013 00:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.728 X-Spam-Level: X-Spam-Status: No, score=-105.728 tagged_above=-999 required=5 tests=[AWL=0.521, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtD8lbe8JDBb for ; Thu, 26 Sep 2013 00:06:48 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E7B7111E815F for ; Thu, 26 Sep 2013 00:06:32 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-5f-5243dcefd180 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 22.AC.22048.FECD3425; Thu, 26 Sep 2013 09:06:24 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.147) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.2.328.9; Thu, 26 Sep 2013 09:06:21 +0200 Message-ID: <5243DD28.3080000@ericsson.com> Date: Thu, 26 Sep 2013 09:07:20 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Colin Perkins References: <4CD0A460-A92F-418E-9D6D-6F1B6BEF278F@csperkins.org> <523D8979.10902@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+Jvre6HO85BBpPu8Fs82D6X0WL5yxOM FpcunmVyYPaY8nsjq8e0+/fZPJYs+ckUwBzFZZOSmpNZllqkb5fAldHw5Q5bweypjBX/Lrcx NTC+Ke9i5OSQEDCRWLCtgw3CFpO4cG89kM3FISRwmFGiZ/t2KGc5o8Sn7rVgVbwC2hL9c68w dzFycLAIqEr86ZMGCbMJWEjc/NEIViIqECzRvv0rVLmgxMmZT1hAbBGg8h3H/zGC2MwCnhKv 2p8zgdjCAvYSC2YdYYXYdYVRomnzI7AiTgFHiTt3NkBdJymxbdExdohmA4kji+awQtjyEs1b ZzOD2EJAtzU0dbBOYBSahWT3LCQts5C0LGBkXsXInpuYmZNebr6JERjCB7f8NtjBuOm+2CFG aQ4WJXHezXpnAoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwmpckdx2a/mRL5HWTU9sq3q6M uPjhTla/uoz68aXHGJ5EbOHMV2Q+HL9l0auadzWe2vNrIyxNmiO6852PJ0ut7rOQ+Cba3Xk9 VOtw3iFuzaL1k2dcD9Eou1J5KSK6L2Tu9tLXHn1uiw8sVQ1ZrmwXcMZqW/eHo2UaE6Ney//3 2yLYvaVxEtdbJZbijERDLeai4kQAHaK37y8CAAA= Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 07:06:55 -0000 Hi, Removing everything except questions / comments. Feedback especially requested on the last comment. Anyone with SVC experience should review the changes for Section 5.1.5. Inline On 2013-09-22 18:31, Colin Perkins wrote: > Hi Magnus, > > On 21 Sep 2013, at 12:56, Magnus Westerlund > wrote: >> Thanks for the review comments. I have tried addressing them. I am > > >>> - Section 3.2: the introduction to this section could be clearer >>> that this is an overview of RTP features that are available >>> independent of the payload format, and not a list of things that >>> the payload format needs to explicitly opt in to/out of. >> >> This section reviews a number of RTP features and concepts that >> are available in RTP independent of the payload format. The RTP >> payload format can make use of these when appropriate, and in some >> cases even effect the behavior (RTP Timestamp and marker bit). This >> section does not remove the necessity to read up on RTP. However it >> does point out a few important details to remember when designing a >> payload format. > > It might be worth expanding this to say "...even affect the behaviour > (RTP timestamp and marker bit), but it is important to note that not > all features and concepts are relevant to every payload format"? Good suggestion: The resulting text now reads: This section reviews a number of RTP features and concepts that are available in RTP independent of the payload format. The RTP payload format can make use of these when appropriate, and even affect the behaviour (RTP timestamp and marker bit), but it is important to note that not all features and concepts are relevant to every payload format. This section does not remove the necessity to read up on RTP. However it does point out a few important details to remember when designing a payload format. > >>> - In Section 3.2.2 the statement “[RFC5285] specifies how to >>> extend the RTP header to carry metadata relating to the payload” >>> is potentially misleading, since the type of information that >>> usually goes into an RTP payload header is also “metadata >>> relating to the payload”. It might be useful to expand this >>> discussion slightly, to make the distinction clear. >> >> Is this better? >> >> Header extensions: Payload formats normally specifies the >> carrying of meta data related to the media payload in the payload >> header. In some cases the meta data may be more generic, e.g. >> relevant more to the media type (e.g. audio or video), or RTP >> packets in general. In those cases the carrying of this additional >> meta data can be specified in a header extension. One example is >> the transport of SMPTE time-codes in the RTP header [RFC5484]. As >> [RFC5285] specifies, header extensions must not contain information >> required in order to decode the payload successfully. > > That's better, but I might suggest even stronger wording: "RTP > payload formats often need to include metadata relating to the > payload data being transported. Such metadata is sent as a payload > header, at the start of the payload section of the RTP packet. The > RTP packet also includes space for a header extension [RFC5275]; this > can be used to transport payload format independent metadata, for > example a SMPTE time code for the packet [RFC5484]. The RTP header > extensions is not intended to carry headers that relate to a > particular payload format., and must not contain information needed > in order to decode the payload." > > The last sentence of the first paragraph of Section 3.2.2 also needs > updating. I suggest "Finally, [RFC5285] specifies how to transport > payload format independent metadata relating to the RTP packet". > I like this, I will include this. >>> - In Section 3.2.2, it might be useful to explain that video >>> payload formats are a common example of “payload formats with a >>> timestamp definition which results in no or little correlation >>> between the media time instance and its transmission time”; >>> otherwise this sounds like such payload formats are something >>> unusual. >> >> This discussion got moved into the new section 5.2, where the >> related text says: >> >> RTP payload formats with a timestamp definition which results in >> no or little correlation between the media time instance and its >> transmission time cause the RTCP jitter calculation to become >> unusable due to the errors introduced on the sender side. Such >> examples are for example payload formats for video that requires >> multiple packets, where a set of packets will have the same >> timestamp, another are payloads that includes alternating set of >> redundant information, if the definition used are for the earliest >> data included, the the timestamp may jump back and forth. It >> should be noted if the payload format has this property or not. >> >> Good enough? > > Better, but could still be more explicit. How about changing the > "Such examples are..." sentence to "A common example is a payload > format for a video codec where the RTP timestamp represents the > capture time of the video frame, but frames are large enough that > multiple RTP packets need to be sent for each frame spread across the > framing interval". Yes, that is more focused. > >>> - Section 3.4: should this say anything about AQM and/or QoS >>> support? >> >> I tried writing something about this. I don't know how useful this >> is. Feedback much appreciated. >> >> >> 3.4.2. Different Queuing Algorithms >> >> Routers and Switches on the network path between an IP sender and >> a particular receiver can exhibit different behaviors affecting the >> end to end characteristics. One of the more important aspects of >> this is queuing behavior. Routers and Switches has some amount of >> queuing to handle temporary bursts of data that designated to leave >> the switch or router on the same egress link. A queue when not >> empty results in an increased path delay. >> >> The implementation of the queuing effects the delay and also how >> congestion signals (Explicint Congestion Marking (ECN) or packet >> drops) are provided to the flow. > > Reference RFC 6679 here? Yes, for people that like to dig into ECN, going to the RTP spec is a good first step. > >> The other aspects are if the flow shares the queue with other flows >> and how the implementation affects the flow interaction. This >> becomes important for example when real- time flows interacts with >> long lived TCP flows. TCP have a built in behavior in its >> congestion control that strive to fill the buffer, thus all flows >> sharing the buffer experienced the delay build up. >> >> A common but quite poor queue handling mechanism is tail-drop, >> i.e. only drop packets when the incoming packet doesn't fit in the >> queue. Active Queue Management (AQM) is a term covering mechanism >> that tries to do something smarter buy actively managing the queue, >> for example by sending congestion signals earlier by droping >> packets earlier in the queue. The behavior also affects the flow >> interactions. For example Random Early Drop (RED) selects which >> packet to drop randomly. This to give flows that have more packets >> in the queue a higher probability to experience the packet loss >> (congestion signal). There is ongoing work to find suitable >> mechanisms to recommend for implementation and reduce the use of >> tail-drop. >> >> 3.4.3. Quality of Service >> >> Using best effort Internet one have no guarantees for the paths >> properties. Quality of Service (QoS) mechanism are intended to >> provide the possibility to bound the path properties. Where >> Diffserv [RFC2475] markings effects the queuing and forwarding >> behaviors of routers, the mechanism provides only statistical >> guarantees and care in how much marked packets of different types >> that are entering the network. Flow based QoS like IntServ >> [RFC1663] has the potential for stricter guarantees as the >> properties are agreed on by each hop on the path. > > I think this is useful. It highlights that there are issues to > consider, which is the goal. Good, I was uncertain if this text said the right things. > >>> - The discussion of SST and MST in Section 5.1.5 seems to >>> confuse sessions with SSRCs. Isn’t it more important whether the >>> layers are sent within a single RTP media stream, or as separate >>> RTP media streams with different SSRC values? Whether the >>> different SSRCs are sent in one RTP session of many is then a >>> separate issue, depending on how easily one wants to be able to >>> separate the flows for QoS purposes. >> >> The issue is that the SVC payload RFC is a bit confused on this >> matter. I agree that there are two separate important distinctions >> here. First if the layers are sent in one RTP packet stream or used >> multiple ones. In the second case one gets the question of how one >> distributes that over RTP sessions and underlying transports. >> Especially as some that implements SVC MST clearly uses a single >> RTP session and are after the possibility on a SSRC level to >> control transmission of layers in RTP middleboxes. >> >> I have tried to address this in the text, please review. >> >> 5.1.5. Media Scalability >> >> Some codecs support various types of media scalability, i.e. some >> data of a media stream may be removed to adapt the media's >> properties, such as bitrate and quality. The adaptation may be >> applied in the following dimensions of the media: >> >> Temporal: For video codecs it is possible to adapt the frame >> rate, e.g. for H.264 [RFC6184]. >> >> Spatial: Video codecs supporting scalability may adapt the >> resolution, e.g. in SVC [RFC6190]. >> >> Quality: The quality of the media stream may be scaled by >> adapting the accuracy of the coding process, as, e.g. possible >> with Signal to Noise Ratio (SNR) fidelity scalability of SVC >> [RFC6190]. >> >> At the time of writing this document, codecs that support >> scalability have a bit of revival. It has been realized that >> getting the required functionality for supporting the features of >> the media stream into the RTP framework is quite challenging. One >> of the recent examples for layered and scalable codecs is Scalable >> Video Coding [RFC6190] (SVC). >> >> SVC is a good example for a payload format supporting media >> scalability features, which have been in its basic form already >> included in RTP. A layered codec supports the dropping of data >> parts of a media stream, i.e. RTP packets may be not transmitted >> or forwarded to a client in order to adapt the media stream rate as >> well as the media stream quality, while still providing a decodable >> subset of the media stream to a client. One example for using the >> scalability feature may be an RTP Mixer (Multipoint Control Unit) >> which controls the rate and quality sent out to participants in a >> communication based on dropping RTP packets or removing part of >> the payload. Another example may be an transport channel which >> allows for differentiation in Quality of Service (QoS) parameters >> based on RTP sessions in a multicast session. In such a case, the >> more important packets of the scalable media stream (base layer) >> may get better QoS parameters, then the less important packets >> (enhancement layer) in order to provide some kind of graceful >> degradation. The scalability features required for allowing an >> adaptive transport as described in the two examples above are based >> on RTP multiplexing in order to identify the packets to be dropped >> or transmitted/forwarded. The multiplexing features defined for >> Scalable Video Coding [RFC6190] are: >> >> single session transmission (SST), where all media layers of the >> media are transported as single source (SSRC) in a single RTP >> session; as well as >> >> multi session transmission (MST), which should more accurately be >> called multi stream transmission, where different media layers or a >> set of media layers are transported in different RTP streams, i.e. >> using multiple sources (SSRCs). >> >> In the first case (SST), additional in-band as well as out-of-band >> signaling is required in order to allow identification of packets >> belonging to a specific media layer. Furthermore, an adaptation >> of the media stream requires dropping of specific packets in order >> to provide the client with a compliant media stream. In case of >> using encryption, it is typically required for an adapting network >> device to be in the security context to allow packet dropping and >> providing an intact RTP session to the client. This typically >> requires the network device to be an RTP mixer. >> >> In general having a media unaware network device dropping >> excessive packets will be more problematic than having a Media >> Aware Network Entity (MANE). First is the need to understand the >> media format and know which ADUs or payloads that belongs to the >> layers, that no other layer will be dependent on after the >> dropping. Secondly, if the MANE can work as RTP mixer or >> translator it can rewrite the RTP and RTCP in such a way that the >> receiver will not suspect non-intentional RTP packet losses needing >> repair actions. This as the receiver can't determine if a lost >> packet was an important base layer packet or one of the less >> important extension layers. >> >> In the second case (MST), the RTP packet streams can be sent using >> a single or multiple RTP sessions, and thus transport flows, e.g. >> on differnt multicast groups. Transmitting the streams in >> different RTP sessions then the out-of-band signaling typically >> provides enough information to identify the media layers and its >> properties. The decision for dropping packets is based on the >> Network Address which identifies the RTP session to be dropped. In >> order to allow correct data provision to a decoder after reception >> from different sessions, data re-alignment mechanisms are described >> for Scalable Video Coding [RFC6190]. A more generic one is also >> described in Rapid Sync for RTP flows [RFC6051], which is purely >> based on existing RTP >> >> mechanisms, i.e. the NTP timestamp, for inter-session >> synchronization. Another signaling feature is the generic >> indication of dependencies of RTP sessions in SDP, as defined in >> the Media Decoding Dependency Grouping in SDP [RFC5583]. >> >> Using MST within a single RTP session is also possible and allow >> stream level handling instead of looking deeper into the packets by >> a MANE. However, transport flow level properties will be the same >> unless packet based mechanisms like DiffServ is used. >> >> When QoS settings, e.g. DiffServ markings, are used to ensure that >> the extension layers are dropped prior the base layer the >> receiving end-point has the benefit in MST to know which layer or >> set of layers the missing packets belong as it will be bound to >> different RTP sessions. Thus explicitly indicating the importance >> of the loss. > > I think this is okay, but it really needs an implementer of the SVC > format to comment too. Yes, that would be desirable. > >>> - In Section 5.1.6, avoiding wrap-around within the RTCP >>> reporting timeout interval is also important. >> >> If I understand this correctly, this is a minor issue with the RTCP >> SR and RR packet types as they all uses 32-bit counters. However, >> other packet types may have issues if they not use extended >> sequence number counters. >> >> This might be more relevant to considerations for configuring RTCP >> bandwidth and design of RTCP extensions, rather than being an RTP >> Payload issue. There exists a configuration goal to ensure that >> RTCP reporting doesn't wrap its fields within multiple reporting >> intervals. >> >> I propose that the following paragraph is added in this section: >> >> RTCP is also affected by high packet rates. For RTCP mechanism that >> do not use extended counters there is significant risk that they >> wrap multiple times between RTCP reporting or feedback, thus >> producing uncertainty which packet(s) that are referenced. The >> payload designer can't effect the RTCP packet formats used and >> their design, but can note this considerations when configuring >> RTCP bandwidth and reporting intervals to avoid to wrapping >> issues. > > That's fine, although I was actually suggesting something simpler, > which is to change "As rule of thumb, it must not be possible to wrap > the sequence number space in less than 2 minutes (TCP maximum segment > lifetime)" to "...must not be possible to wrap the sequence number > space in less than an RTCP reporting interval". That is difficult for someone that is new to quantify into meaningful values. Especially as we have reporting intervals between milliseconds (a scaled RTCP interval for the gigabit raw video) to many seconds for large groups with small amounts of receiver reporting bandwidths. In addition I don't think one reporting interval is really sufficient. In absence of RTCP packet loss it provides the bare minimum to detect a wrap in RTCP. But one really need to take the maximum interval between two RTCP packets into account and considering loss I think 3-4 intervals are needed to have reasonable saftey. The motivation for using TCP MSL was the argument that TCP MSL is selected as the time interval no emitted packet would still be possible to arrive after. That is true also for RTP packets and thus a valid considerations providing sufficient margins. It also covers almost all RTCP usages that I can think of. I have changed the text to now say: Some media codecs require high packet rates, and in these cases the RTP sequence number wraps too quickly. As rule of thumb, it must not be possible to wrap the sequence number space within at least three RTCP reporting intervals. As the reporting interval can vary widely due to configuration and session properties, and also must take into account the randomization of the interval, one can use the TCP maximum segment lifetime, which is 2 minutes in ones calculations. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Thu Sep 26 00:27:21 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D9A11E80E2 for ; Thu, 26 Sep 2013 00:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.747 X-Spam-Level: X-Spam-Status: No, score=-105.747 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zv1x-Qxx6fAq for ; Thu, 26 Sep 2013 00:27:16 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 02CBC21F9D09 for ; Thu, 26 Sep 2013 00:27:14 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-c0-5243e1d198e1 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id F5.20.22048.1D1E3425; Thu, 26 Sep 2013 09:27:14 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.16) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.2.328.9; Thu, 26 Sep 2013 09:27:13 +0200 Message-ID: <5243E20C.30104@ericsson.com> Date: Thu, 26 Sep 2013 09:28:12 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "payload@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3VvfSQ+cgg8UfmSwebJ/LaHHp4lkm ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugStjXeMd5oKVkhVfflxkbGCcLdLFyMkhIWAi sfvEDDYIW0ziwr31QDYXh5DAYUaJbRNeMUE4yxglzh04B1bFK6Ap8a7vIpjNIqAqMXHaLiYQ m03AQuLmj0awuKhAsET79q9Q9YISJ2c+Yeli5OAQAep99F0IxGQW0JN49EUfpEJYwF5iwawj rCC2kICPxIv3H5hBbE4BX4nmKWdYIG6TlNi26Bg7iA3SOuVqCyOELS/RvHU2M0SvtkRDUwfr BEahWUgWz0LSMgtJywJG5lWM7LmJmTnp5eabGIGBenDLb4MdjJvuix1ilOZgURLn3ax3JlBI ID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY/qrrH9+Hd+m7leycVyfeSN+xbPll6fI/pLNWLft ts61ZycieSamsH5ZttV42+muAxdv/VapvKHw5aSGnozOYl75QDapuplPGMJYqyvnfyh0T3JL FvlzQ6s0f1nqxqntHtk7T2fd52iY5dS7SO/Y022H28R4dRpXli7ZEff/9dlevWTxFKNpj5RY ijMSDbWYi4oTAT88ypkiAgAA Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 07:27:21 -0000 WG, As part of editing the comments I am proposing one additional change. This is a clarification of text in Section 3.3.2.1 that used to say: A further issue with offer/answer which complicates things is that the answerer is allowed to renumber the payload types between offer and answer. This is not recommended but allowed for support of gateways to the ITU conferencing suite. This means that it must be possible to bind answers for payload types to the payload types in the offer even when the payload type number has been changed, and some of the proposed payload types have been removed. This binding must normally be done by matching the configurations originally offered against those in the answer. Which I propose to change to: A further issue with offer/answer which complicates things is that the answerer is allowed to renumber the payload types between offer and answer. This is not recommended but allowed for support of gateways to the ITU conferencing suite. This means that it must be possible to bind answers for payload types to the payload types in the offer even when the payload type number has been changed, and some of the proposed payload types have been removed. This binding must normally be done by matching the configurations originally offered against those in the answer. This may require specification in the payload format of which parameters that constitute a configuration, for example as done in Section 8.2.2 of the H.264 RTP Payload format [RFC6184]; "The parameters identifying a media format configuration for H.264 are profile-level-id and packetization-mode". Making clear that one may have to write a definition of it. This has become relevant in the discussion in MMUSIC regarding BUNDLE and what a codec configuration really is. But the basic requirement for this originates from Offer/Answer itself (RFC 3264). I appreciate feedback on this change. Cheers Magnus On 2013-08-22 10:58, Ali C. Begen (abegen) wrote: > (As a WG co-chair) > > I am starting WGLC for the following draft (version 05). > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto/ > > This is an important document as it outlines how someone is supposed to write the payload specs. > > If there are sections you don't understand or that are not clear enough, etc. please post them to the list. We need to get this right to minimize further headaches for future documents in our WG. > > The deadline for the WGLC is September 20th. > > -acbegen > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From simao.campos@itu.int Thu Sep 26 02:09:37 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087A111E817C for ; Thu, 26 Sep 2013 02:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxGGVLNJl9yQ for ; Thu, 26 Sep 2013 02:09:32 -0700 (PDT) Received: from itu4out.svc.unicc.org (itu4out.svc.unicc.org [206.155.102.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6153711E8170 for ; Thu, 26 Sep 2013 02:09:31 -0700 (PDT) Received: from TUCHM01.TUECSP.UNICC.ORG (unknown [10.81.6.60]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by iccpfxor04.svc.unicc.org (Postfix) with ESMTPS id 2B5A460C8B; Thu, 26 Sep 2013 09:09:29 +0000 (UTC) Received: from TUCHM02.TUECSP.UNICC.ORG ([169.254.2.3]) by TUCHM01.TUECSP.UNICC.ORG ([169.254.1.88]) with mapi id 14.03.0123.003; Thu, 26 Sep 2013 09:09:23 +0000 From: "Campos, Simao" To: "Michael Ramalho (mramalho)" , "payload@ietf.org" Thread-Topic: Toward WGLC on G.711.0 RTP Payload Spec Thread-Index: Ac66NIJIYK6mF56FR8aFqe5fsMHitgAY2+og Date: Thu, 26 Sep 2013 09:09:27 +0000 Message-ID: <47625A4A3006CE47BB72AF5BC1EBBEFDCB30C662@TUCHM02.TUECSP.UNICC.ORG> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.81.64.160] Content-Type: multipart/alternative; boundary="_000_47625A4A3006CE47BB72AF5BC1EBBEFDCB30C662TUCHM02TUECSPUN_" MIME-Version: 1.0 Subject: Re: [payload] Toward WGLC on G.711.0 RTP Payload Spec X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 09:09:37 -0000 --_000_47625A4A3006CE47BB72AF5BC1EBBEFDCB30C662TUCHM02TUECSPUN_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Michael I support your proposal of starting WGLC for this I-D. Sim=E3o From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Michael Ramalho (mramalho) Sent: Wednesday, September 25, 2013 11:17 PM To: payload@ietf.org Subject: [payload] Toward WGLC on G.711.0 RTP Payload Spec All, The payload WG has a milestone to submit the RTP Payload Format for G.711.0= for proposed standard in December 2013 (http://datatracker.ietf.org/wg/pay= load/charter/ ). The current working group draft is draft-ietf-payload-g7110-00 ( http://dat= atracker.ietf.org/doc/draft-ietf-payload-g7110/ ). Although this working group document is a "00" draft, it spent much time an= d prior re-writes as an individual contribution draft known as draft-ramalh= o-payload-g7110-0X. I have not received any requests to change this document since the conversi= on of the individual contribution draft to the working group draft (which o= ccurred in June 2013). As I would like to ask the Payload chairs to last call this document at the= Vancouver IETF, please provide any input you have on this document to this= list (including if you think it is ready as it is). Thanks in advance, Michael A. Ramalho --_000_47625A4A3006CE47BB72AF5BC1EBBEFDCB30C662TUCHM02TUECSPUN_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Michael

 

I support your proposa= l of starting WGLC for this I-D.

 

Sim=E3o

 

From: payload-= bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Michael Ramalho (mramalho)
Sent: Wednesday, September 25, 2013 11:17 PM
To: payload@ietf.org
Subject: [payload] Toward WGLC on G.711.0 RTP Payload Spec

 

All,

 

The payload WG has a milestone to submit the RTP Pay= load Format for G.711.0 for proposed standard in December 2013 (http://datatracker.ietf.or= g/wg/payload/charter/ ).

 

The current working group draft is draft-ietf-payloa= d-g7110-00 ( http:= //datatracker.ietf.org/doc/draft-ietf-payload-g7110/ ).

 

Although this working group document is a “00&= #8221; draft, it spent much time and prior re-writes as an individual contr= ibution draft known as draft-ramalho-payload-g7110-0X.

 

I have not received any requests to change this docu= ment since the conversion of the individual contribution draft to the worki= ng group draft (which occurred in June 2013).

 

As I would like to ask the Payload chairs to last ca= ll this document at the Vancouver IETF, please provide any input you have o= n this document to this list (including if you think it is ready as it is).=

 

Thanks in advance,

 

Michael A. Ramalho

--_000_47625A4A3006CE47BB72AF5BC1EBBEFDCB30C662TUCHM02TUECSPUN_-- From abegen@cisco.com Thu Sep 26 02:46:35 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7FD11E8180 for ; Thu, 26 Sep 2013 02:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.799 X-Spam-Level: X-Spam-Status: No, score=-10.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChP8bQljtvFi for ; Thu, 26 Sep 2013 02:46:24 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C5D2C11E8181 for ; Thu, 26 Sep 2013 02:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5148; q=dns/txt; s=iport; t=1380188783; x=1381398383; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=tQXs9Qsm7sqlWuSZV7gb2fiSDzDEjhkWXXwcP5jQQl4=; b=ar0P3vkdnEXC7dGj4ud1j89MybTa8m9m3+XWzx+m3oJQq0ZikXBbr83+ IsYNc0ti5r2UM6cDGyO7SIXCZZPzKdzZjY7Jaee3YqcLK5f2dIW5Q2Zmv WH61PNekjb7ODlR7LI8QY3D+wwmDwi/h4LFU2ZLyB8lkZ/4MRVqQaD6o9 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAOcBRFKtJXG//2dsb2JhbABbgmYhOFKCUFm8XkoXgQsWdIIlAQEBBAEBAQkXEToXAgQBBgIRAwECAQICBh0DAgQZDAsUAQgIAgQBEgiHfgELjhibVpJLBASBJY13FiIGgmI1gQEDqXWDJIIq X-IronPort-AV: E=Sophos;i="4.90,984,1371081600"; d="scan'208";a="264725979" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 26 Sep 2013 09:46:23 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8Q9kN5L005671 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Sep 2013 09:46:23 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Thu, 26 Sep 2013 04:46:22 -0500 From: "Ali C. Begen (abegen)" To: Magnus Westerlund , "payload@ietf.org" Thread-Topic: [payload] WGLC for draft-ietf-payload-rtp-howto-05 Thread-Index: AQHOnxW0JqQDumtvLE+Tk9S9gB3JkpnYKY8AgABY1oA= Date: Thu, 26 Sep 2013 09:46:22 +0000 Message-ID: In-Reply-To: <5243E20C.30104@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.86.254.200] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 09:46:36 -0000 TG9va3MgZ29vZCB0byBtZSBleGNlcHQgdGhhdCB0aGVyZSBhcmUgYnVuY2ggb2YgbG93ZXItY2Fz ZSAyMTE5IGtleXdvcmRzLg0KQW55IHBvc3NpYmlsaXR5IHRvIGF2b2lkIHRoZW0gb3IgaXMgaXQg YmV0dGVyIHRvIG1ha2UgdGhlbSB1cHBlciBjYXNlPw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogTWFnbnVzIFdlc3Rlcmx1bmQgPG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u LmNvbT4NCkRhdGU6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMjYsIDIwMTMgMTA6MjggQU0NClRvOiAi cGF5bG9hZEBpZXRmLm9yZyIgPHBheWxvYWRAaWV0Zi5vcmc+DQpDYzogIkFsaSBDLiBCZWdlbiIg PGFiZWdlbkBjaXNjby5jb20+DQpTdWJqZWN0OiBSZTogW3BheWxvYWRdIFdHTEMgZm9yIGRyYWZ0 LWlldGYtcGF5bG9hZC1ydHAtaG93dG8tMDUNCg0KPldHLA0KPg0KPkFzIHBhcnQgb2YgZWRpdGlu ZyB0aGUgY29tbWVudHMgSSBhbSBwcm9wb3Npbmcgb25lIGFkZGl0aW9uYWwgY2hhbmdlLg0KPlRo aXMgaXMgYSBjbGFyaWZpY2F0aW9uIG9mIHRleHQgaW4gU2VjdGlvbiAzLjMuMi4xIHRoYXQgdXNl ZCB0byBzYXk6DQo+DQo+ICAgQSBmdXJ0aGVyIGlzc3VlIHdpdGggb2ZmZXIvYW5zd2VyIHdoaWNo IGNvbXBsaWNhdGVzIHRoaW5ncyBpcyB0aGF0DQo+ICAgdGhlIGFuc3dlcmVyIGlzIGFsbG93ZWQg dG8gcmVudW1iZXIgdGhlIHBheWxvYWQgdHlwZXMgYmV0d2VlbiBvZmZlcg0KPiAgIGFuZCBhbnN3 ZXIuICBUaGlzIGlzIG5vdCByZWNvbW1lbmRlZCBidXQgYWxsb3dlZCBmb3Igc3VwcG9ydCBvZg0K PiAgIGdhdGV3YXlzIHRvIHRoZSBJVFUgY29uZmVyZW5jaW5nIHN1aXRlLiAgVGhpcyBtZWFucyB0 aGF0IGl0IG11c3QgYmUNCj4gICBwb3NzaWJsZSB0byBiaW5kIGFuc3dlcnMgZm9yIHBheWxvYWQg dHlwZXMgdG8gdGhlIHBheWxvYWQgdHlwZXMgaW4NCj4gICB0aGUgb2ZmZXIgZXZlbiB3aGVuIHRo ZSBwYXlsb2FkIHR5cGUgbnVtYmVyIGhhcyBiZWVuIGNoYW5nZWQsIGFuZA0KPiAgIHNvbWUgb2Yg dGhlIHByb3Bvc2VkIHBheWxvYWQgdHlwZXMgaGF2ZSBiZWVuIHJlbW92ZWQuICBUaGlzIGJpbmRp bmcNCj4gICBtdXN0IG5vcm1hbGx5IGJlIGRvbmUgYnkgbWF0Y2hpbmcgdGhlIGNvbmZpZ3VyYXRp b25zIG9yaWdpbmFsbHkNCj4gICBvZmZlcmVkIGFnYWluc3QgdGhvc2UgaW4gdGhlIGFuc3dlci4N Cj4NCj5XaGljaCBJIHByb3Bvc2UgdG8gY2hhbmdlIHRvOg0KPg0KPiAgIEEgZnVydGhlciBpc3N1 ZSB3aXRoIG9mZmVyL2Fuc3dlciB3aGljaCBjb21wbGljYXRlcyB0aGluZ3MgaXMgdGhhdA0KPiAg IHRoZSBhbnN3ZXJlciBpcyBhbGxvd2VkIHRvIHJlbnVtYmVyIHRoZSBwYXlsb2FkIHR5cGVzIGJl dHdlZW4gb2ZmZXINCj4gICBhbmQgYW5zd2VyLiAgVGhpcyBpcyBub3QgcmVjb21tZW5kZWQgYnV0 IGFsbG93ZWQgZm9yIHN1cHBvcnQgb2YNCj4gICBnYXRld2F5cyB0byB0aGUgSVRVIGNvbmZlcmVu Y2luZyBzdWl0ZS4gIFRoaXMgbWVhbnMgdGhhdCBpdCBtdXN0IGJlDQo+ICAgcG9zc2libGUgdG8g YmluZCBhbnN3ZXJzIGZvciBwYXlsb2FkIHR5cGVzIHRvIHRoZSBwYXlsb2FkIHR5cGVzIGluDQo+ ICAgdGhlIG9mZmVyIGV2ZW4gd2hlbiB0aGUgcGF5bG9hZCB0eXBlIG51bWJlciBoYXMgYmVlbiBj aGFuZ2VkLCBhbmQNCj4gICBzb21lIG9mIHRoZSBwcm9wb3NlZCBwYXlsb2FkIHR5cGVzIGhhdmUg YmVlbiByZW1vdmVkLiAgVGhpcyBiaW5kaW5nDQo+ICAgbXVzdCBub3JtYWxseSBiZSBkb25lIGJ5 IG1hdGNoaW5nIHRoZSBjb25maWd1cmF0aW9ucyBvcmlnaW5hbGx5DQo+ICAgb2ZmZXJlZCBhZ2Fp bnN0IHRob3NlIGluIHRoZSBhbnN3ZXIuICBUaGlzIG1heSByZXF1aXJlIHNwZWNpZmljYXRpb24N Cj4gICBpbiB0aGUgcGF5bG9hZCBmb3JtYXQgb2Ygd2hpY2ggcGFyYW1ldGVycyB0aGF0IGNvbnN0 aXR1dGUgYQ0KPiAgIGNvbmZpZ3VyYXRpb24sIGZvciBleGFtcGxlIGFzIGRvbmUgaW4gU2VjdGlv biA4LjIuMiBvZiB0aGUgSC4yNjQgUlRQDQo+ICAgUGF5bG9hZCBmb3JtYXQgW1JGQzYxODRdOyAi VGhlIHBhcmFtZXRlcnMgaWRlbnRpZnlpbmcgYSBtZWRpYSBmb3JtYXQNCj4gICBjb25maWd1cmF0 aW9uIGZvciBILjI2NCBhcmUgcHJvZmlsZS1sZXZlbC1pZCBhbmQgcGFja2V0aXphdGlvbi1tb2Rl Ii4NCj4NCj5NYWtpbmcgY2xlYXIgdGhhdCBvbmUgbWF5IGhhdmUgdG8gd3JpdGUgYSBkZWZpbml0 aW9uIG9mIGl0LiBUaGlzIGhhcw0KPmJlY29tZSByZWxldmFudCBpbiB0aGUgZGlzY3Vzc2lvbiBp biBNTVVTSUMgcmVnYXJkaW5nIEJVTkRMRSBhbmQgd2hhdCBhDQo+Y29kZWMgY29uZmlndXJhdGlv biByZWFsbHkgaXMuIEJ1dCB0aGUgYmFzaWMgcmVxdWlyZW1lbnQgZm9yIHRoaXMNCj5vcmlnaW5h dGVzIGZyb20gT2ZmZXIvQW5zd2VyIGl0c2VsZiAoUkZDIDMyNjQpLg0KPg0KPkkgYXBwcmVjaWF0 ZSBmZWVkYmFjayBvbiB0aGlzIGNoYW5nZS4NCj4NCj5DaGVlcnMNCj4NCj5NYWdudXMNCj4NCj5P biAyMDEzLTA4LTIyIDEwOjU4LCBBbGkgQy4gQmVnZW4gKGFiZWdlbikgd3JvdGU6DQo+PiAoQXMg YSBXRyBjby1jaGFpcikNCj4+IA0KPj4gSSBhbSBzdGFydGluZyBXR0xDIGZvciB0aGUgZm9sbG93 aW5nIGRyYWZ0ICh2ZXJzaW9uIDA1KS4NCj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtcGF5bG9hZC1ydHAtaG93dG8vDQo+PiANCj4+IFRoaXMgaXMgYW4gaW1w b3J0YW50IGRvY3VtZW50IGFzIGl0IG91dGxpbmVzIGhvdyBzb21lb25lIGlzIHN1cHBvc2VkIHRv DQo+PndyaXRlIHRoZSBwYXlsb2FkIHNwZWNzLg0KPj4gDQo+PiBJZiB0aGVyZSBhcmUgc2VjdGlv bnMgeW91IGRvbid0IHVuZGVyc3RhbmQgb3IgdGhhdCBhcmUgbm90IGNsZWFyDQo+PmVub3VnaCwg ZXRjLiBwbGVhc2UgcG9zdCB0aGVtIHRvIHRoZSBsaXN0LiBXZSBuZWVkIHRvIGdldCB0aGlzIHJp Z2h0IHRvDQo+Pm1pbmltaXplIGZ1cnRoZXIgaGVhZGFjaGVzIGZvciBmdXR1cmUgZG9jdW1lbnRz IGluIG91ciBXRy4NCj4+IA0KPj4gVGhlIGRlYWRsaW5lIGZvciB0aGUgV0dMQyBpcyBTZXB0ZW1i ZXIgMjB0aC4NCj4+IA0KPj4gLWFjYmVnZW4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+PiBwYXlsb2FkIG1haWxpbmcgbGlzdA0KPj4gcGF5bG9h ZEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXls b2FkDQo+PiANCj4+IA0KPg0KPg0KPi0tIA0KPg0KPk1hZ251cyBXZXN0ZXJsdW5kDQo+DQo+LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPk11bHRpbWVkaWEgVGVjaG5vbG9naWVzLCBFcmljc3NvbiBSZXNlYXJjaCBF QUIvVFZNDQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPkVyaWNzc29uIEFCICAgICAgICAgICAgICAgIHwgUGhv bmUgICs0NiAxMCA3MTQ4Mjg3DQo+RsOkcsO2Z2F0YW4gNiAgICAgICAgICAgICAgICB8IE1vYmls ZSArNDYgNzMgMDk0OTA3OQ0KPlNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbnwgbWFpbHRvOiBt YWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+DQoNCg0K From magnus.westerlund@ericsson.com Thu Sep 26 05:04:06 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5AE11E8184 for ; Thu, 26 Sep 2013 05:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.764 X-Spam-Level: X-Spam-Status: No, score=-105.764 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNWYw9b-2lAK for ; Thu, 26 Sep 2013 05:04:01 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D4C0011E80D2 for ; Thu, 26 Sep 2013 05:04:00 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-b6-524422af56e4 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D4.2D.03802.FA224425; Thu, 26 Sep 2013 14:03:59 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.20) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.2.328.9; Thu, 26 Sep 2013 14:03:58 +0200 Message-ID: <524422EA.7090408@ericsson.com> Date: Thu, 26 Sep 2013 14:04:58 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3Vne9kkuQwfNLUhYPts9ltLh08SyT A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJVxax9vwRbVigO3XrM3ME6V62Lk5JAQMJFY MHMmM4QtJnHh3nq2LkYuDiGBw4wSi75tZ4dwljFKnHtyjQmkildAW6L1xTZ2EJtFQFViy9P1 jCA2m4CFxM0fjWwgtqhAsET79q9sEPWCEidnPmEBsUUE9CT2d0wDq2cW0JQ49PkxWI2wgL3E gllHWEFsIQEfiff7DgFdxMHBKeArMfNmFcRxkhLbFh1jh2lt3f4bypaXaN46mxmiVVuioamD dQKj0Cwkm2chaZmFpGUBI/MqRvbcxMyc9HKjTYzAQD245bfqDsY750QOMUpzsCiJ83546xwk JJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgbHhSU2Y76SOlEVOR3aUvNXXWPN19a1lx8o3z567 4v9iwT8PGOftD3o0Ka1mV8Zinu1rGFQCmedP4zq0XXO+qNhaDV2upxEO1ye9PRNyz9bYUPzG HD+BTJutZTyXP1Q5SV3s3r6iUl1MzvmOvfvTGW8KshrWuDVZhF5xWLTxZNSlWb8i7m14+Fpa iaU4I9FQi7moOBEAPv1CCiICAAA= Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 12:04:06 -0000 On 2013-09-26 11:46, Ali C. Begen (abegen) wrote: > Looks good to me except that there are bunch of lower-case 2119 keywords. > Any possibility to avoid them or is it better to make them upper case? No, they should not be interpreted in the RFC 2119 upper case meaning. This is an informative document and regular English interpretation are fine. I find it difficult to write without using may, should, recommend and to some degree must. And removing these out of the document would be a massive undertaking which I fail to see the benefit with. Cheers Magnus > > -----Original Message----- > From: Magnus Westerlund > Date: Thursday, September 26, 2013 10:28 AM > To: "payload@ietf.org" > Cc: "Ali C. Begen" > Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 > >> WG, >> >> As part of editing the comments I am proposing one additional change. >> This is a clarification of text in Section 3.3.2.1 that used to say: >> >> A further issue with offer/answer which complicates things is that >> the answerer is allowed to renumber the payload types between offer >> and answer. This is not recommended but allowed for support of >> gateways to the ITU conferencing suite. This means that it must be >> possible to bind answers for payload types to the payload types in >> the offer even when the payload type number has been changed, and >> some of the proposed payload types have been removed. This binding >> must normally be done by matching the configurations originally >> offered against those in the answer. >> >> Which I propose to change to: >> >> A further issue with offer/answer which complicates things is that >> the answerer is allowed to renumber the payload types between offer >> and answer. This is not recommended but allowed for support of >> gateways to the ITU conferencing suite. This means that it must be >> possible to bind answers for payload types to the payload types in >> the offer even when the payload type number has been changed, and >> some of the proposed payload types have been removed. This binding >> must normally be done by matching the configurations originally >> offered against those in the answer. This may require specification >> in the payload format of which parameters that constitute a >> configuration, for example as done in Section 8.2.2 of the H.264 RTP >> Payload format [RFC6184]; "The parameters identifying a media format >> configuration for H.264 are profile-level-id and packetization-mode". >> >> Making clear that one may have to write a definition of it. This has >> become relevant in the discussion in MMUSIC regarding BUNDLE and what a >> codec configuration really is. But the basic requirement for this >> originates from Offer/Answer itself (RFC 3264). >> >> I appreciate feedback on this change. >> >> Cheers >> >> Magnus >> >> On 2013-08-22 10:58, Ali C. Begen (abegen) wrote: >>> (As a WG co-chair) >>> >>> I am starting WGLC for the following draft (version 05). >>> https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto/ >>> >>> This is an important document as it outlines how someone is supposed to >>> write the payload specs. >>> >>> If there are sections you don't understand or that are not clear >>> enough, etc. please post them to the list. We need to get this right to >>> minimize further headaches for future documents in our WG. >>> >>> The deadline for the WGLC is September 20th. >>> >>> -acbegen >>> _______________________________________________ >>> payload mailing list >>> payload@ietf.org >>> https://www.ietf.org/mailman/listinfo/payload >>> >>> >> >> >> -- >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From abegen@cisco.com Thu Sep 26 05:59:32 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA11721F9901 for ; Thu, 26 Sep 2013 05:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.766 X-Spam-Level: X-Spam-Status: No, score=-10.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoye8ww6cDeu for ; Thu, 26 Sep 2013 05:59:27 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5F221F9B8A for ; Thu, 26 Sep 2013 05:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5309; q=dns/txt; s=iport; t=1380200358; x=1381409958; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Wkf2h7UDSm/MFZOfTgReIK/GJ9Vu97qtqeHn5EStu1E=; b=SgG73PCo5TaDSeAvMSX0af/kVUiqh2ZSQKTDhsYFq9fYh9ZeNrwJFKz1 rx3qcxPudkso4JXiTE0NtX/fQqkLncqML9+jWXHgU0BZK5XULXqQkNKTY 6p+ti8FIZOBAIWLIJBbT1YQinEufaq1sdPpNIuEapHovmQVA/2dFe0yS1 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAHcuRFKtJV2Z/2dsb2JhbABbgmYhOFLACUqBIxZ0giUBAQEDAQEBAQliCwUHAgICAQgRAwECAQodBxsMCxQJCAIEDgUIh3gGAQu9EwQEjxoCMQcGgxeBAQOJAaB0gySCKg X-IronPort-AV: E=Sophos;i="4.90,985,1371081600"; d="scan'208";a="264791390" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 26 Sep 2013 12:59:16 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8QCxGQA012369 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Sep 2013 12:59:16 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Thu, 26 Sep 2013 07:59:16 -0500 From: "Ali C. Begen (abegen)" To: Magnus Westerlund Thread-Topic: [payload] WGLC for draft-ietf-payload-rtp-howto-05 Thread-Index: AQHOnxW0JqQDumtvLE+Tk9S9gB3JkpnYKY8AgABY1oD///R+AIAADyiA Date: Thu, 26 Sep 2013 12:59:16 +0000 Message-ID: References: <524422EA.7090408@ericsson.com> In-Reply-To: <524422EA.7090408@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.105.122] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 12:59:32 -0000 On Sep 26, 2013, at 3:04 PM, Magnus Westerlund wrote: > On 2013-09-26 11:46, Ali C. Begen (abegen) wrote: >> Looks good to me except that there are bunch of lower-case 2119 keywords= . >> Any possibility to avoid them or is it better to make them upper case? >=20 > No, they should not be interpreted in the RFC 2119 upper case meaning. > This is an informative document and regular English interpretation are > fine. yes, it is information and I keep forgetting that. > I find it difficult to write without using may, should, recommend > and to some degree must. And removing these out of the document would be > a massive undertaking which I fail to see the benefit with. >=20 I think putting a note somewhere around the intro part about the use of the= se keywords in lower case would be beneficial.=20 > Cheers >=20 > Magnus >=20 >=20 >>=20 >> -----Original Message----- >> From: Magnus Westerlund >> Date: Thursday, September 26, 2013 10:28 AM >> To: "payload@ietf.org" >> Cc: "Ali C. Begen" >> Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 >>=20 >>> WG, >>>=20 >>> As part of editing the comments I am proposing one additional change. >>> This is a clarification of text in Section 3.3.2.1 that used to say: >>>=20 >>> A further issue with offer/answer which complicates things is that >>> the answerer is allowed to renumber the payload types between offer >>> and answer. This is not recommended but allowed for support of >>> gateways to the ITU conferencing suite. This means that it must be >>> possible to bind answers for payload types to the payload types in >>> the offer even when the payload type number has been changed, and >>> some of the proposed payload types have been removed. This binding >>> must normally be done by matching the configurations originally >>> offered against those in the answer. >>>=20 >>> Which I propose to change to: >>>=20 >>> A further issue with offer/answer which complicates things is that >>> the answerer is allowed to renumber the payload types between offer >>> and answer. This is not recommended but allowed for support of >>> gateways to the ITU conferencing suite. This means that it must be >>> possible to bind answers for payload types to the payload types in >>> the offer even when the payload type number has been changed, and >>> some of the proposed payload types have been removed. This binding >>> must normally be done by matching the configurations originally >>> offered against those in the answer. This may require specification >>> in the payload format of which parameters that constitute a >>> configuration, for example as done in Section 8.2.2 of the H.264 RTP >>> Payload format [RFC6184]; "The parameters identifying a media format >>> configuration for H.264 are profile-level-id and packetization-mode". >>>=20 >>> Making clear that one may have to write a definition of it. This has >>> become relevant in the discussion in MMUSIC regarding BUNDLE and what a >>> codec configuration really is. But the basic requirement for this >>> originates from Offer/Answer itself (RFC 3264). >>>=20 >>> I appreciate feedback on this change. >>>=20 >>> Cheers >>>=20 >>> Magnus >>>=20 >>> On 2013-08-22 10:58, Ali C. Begen (abegen) wrote: >>>> (As a WG co-chair) >>>>=20 >>>> I am starting WGLC for the following draft (version 05). >>>> https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto/ >>>>=20 >>>> This is an important document as it outlines how someone is supposed t= o >>>> write the payload specs. >>>>=20 >>>> If there are sections you don't understand or that are not clear >>>> enough, etc. please post them to the list. We need to get this right t= o >>>> minimize further headaches for future documents in our WG. >>>>=20 >>>> The deadline for the WGLC is September 20th. >>>>=20 >>>> -acbegen >>>> _______________________________________________ >>>> payload mailing list >>>> payload@ietf.org >>>> https://www.ietf.org/mailman/listinfo/payload >>>>=20 >>>>=20 >>>=20 >>>=20 >>> --=20 >>>=20 >>> Magnus Westerlund >>>=20 >>> ---------------------------------------------------------------------- >>> Multimedia Technologies, Ericsson Research EAB/TVM >>> ---------------------------------------------------------------------- >>> Ericsson AB | Phone +46 10 7148287 >>> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >>> ---------------------------------------------------------------------- >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 From csp@csperkins.org Thu Sep 26 09:08:16 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB6621F9D68 for ; Thu, 26 Sep 2013 09:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ASZLv3xiqvL for ; Thu, 26 Sep 2013 09:08:11 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id B567821F99F4 for ; Thu, 26 Sep 2013 09:08:08 -0700 (PDT) Received: from [130.209.247.112] (port=60211 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1VPE6k-0007GA-HV; Thu, 26 Sep 2013 17:08:05 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Colin Perkins In-Reply-To: <5243DD28.3080000@ericsson.com> Date: Thu, 26 Sep 2013 17:07:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <09380714-E29F-4274-845A-FF3B051EEB90@csperkins.org> References: <4CD0A460-A92F-418E-9D6D-6F1B6BEF278F@csperkins.org> <523D8979.10902@ericsson.com> <5243DD28.3080000@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1510) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 16:08:16 -0000 Hi Magnus, This all looks fine.=20 Thanks, Colin On 26 Sep 2013, at 08:07, Magnus Westerlund = wrote: > Hi, >=20 > Removing everything except questions / comments. >=20 > Feedback especially requested on the last comment. Anyone with SVC > experience should review the changes for Section 5.1.5. >=20 > Inline >=20 > On 2013-09-22 18:31, Colin Perkins wrote: >> Hi Magnus, >>=20 >> On 21 Sep 2013, at 12:56, Magnus Westerlund >> wrote: >>> Thanks for the review comments. I have tried addressing them. I am >>=20 >>=20 >>>> - Section 3.2: the introduction to this section could be clearer >>>> that this is an overview of RTP features that are available >>>> independent of the payload format, and not a list of things that >>>> the payload format needs to explicitly opt in to/out of. >>>=20 >>> This section reviews a number of RTP features and concepts that >>> are available in RTP independent of the payload format. The RTP >>> payload format can make use of these when appropriate, and in some >>> cases even effect the behavior (RTP Timestamp and marker bit). This >>> section does not remove the necessity to read up on RTP. However it >>> does point out a few important details to remember when designing a >>> payload format. >>=20 >> It might be worth expanding this to say "...even affect the behaviour >> (RTP timestamp and marker bit), but it is important to note that not >> all features and concepts are relevant to every payload format"? >=20 > Good suggestion: The resulting text now reads: >=20 > This section reviews a number of RTP features and concepts that are > available in RTP independent of the payload format. The RTP payload > format can make use of these when appropriate, and even affect the > behaviour (RTP timestamp and marker bit), but it is important to note > that not all features and concepts are relevant to every payload = format. > This section does not remove the necessity to read up on RTP. However = it > does point out a few important details to remember when designing a > payload format. >=20 >=20 >=20 >>=20 >>>> - In Section 3.2.2 the statement =93[RFC5285] specifies how to >>>> extend the RTP header to carry metadata relating to the payload=94 >>>> is potentially misleading, since the type of information that >>>> usually goes into an RTP payload header is also =93metadata >>>> relating to the payload=94. It might be useful to expand this >>>> discussion slightly, to make the distinction clear. >>>=20 >>> Is this better? >>>=20 >>> Header extensions: Payload formats normally specifies the >>> carrying of meta data related to the media payload in the payload >>> header. In some cases the meta data may be more generic, e.g. >>> relevant more to the media type (e.g. audio or video), or RTP >>> packets in general. In those cases the carrying of this additional >>> meta data can be specified in a header extension. One example is >>> the transport of SMPTE time-codes in the RTP header [RFC5484]. As >>> [RFC5285] specifies, header extensions must not contain information >>> required in order to decode the payload successfully. >>=20 >> That's better, but I might suggest even stronger wording: "RTP >> payload formats often need to include metadata relating to the >> payload data being transported. Such metadata is sent as a payload >> header, at the start of the payload section of the RTP packet. The >> RTP packet also includes space for a header extension [RFC5275]; this >> can be used to transport payload format independent metadata, for >> example a SMPTE time code for the packet [RFC5484]. The RTP header >> extensions is not intended to carry headers that relate to a >> particular payload format., and must not contain information needed >> in order to decode the payload." >>=20 >> The last sentence of the first paragraph of Section 3.2.2 also needs >> updating. I suggest "Finally, [RFC5285] specifies how to transport >> payload format independent metadata relating to the RTP packet". >>=20 >=20 > I like this, I will include this. >=20 >=20 >>>> - In Section 3.2.2, it might be useful to explain that video >>>> payload formats are a common example of =93payload formats with a >>>> timestamp definition which results in no or little correlation >>>> between the media time instance and its transmission time=94; >>>> otherwise this sounds like such payload formats are something >>>> unusual. >>>=20 >>> This discussion got moved into the new section 5.2, where the >>> related text says: >>>=20 >>> RTP payload formats with a timestamp definition which results in >>> no or little correlation between the media time instance and its >>> transmission time cause the RTCP jitter calculation to become >>> unusable due to the errors introduced on the sender side. Such >>> examples are for example payload formats for video that requires >>> multiple packets, where a set of packets will have the same >>> timestamp, another are payloads that includes alternating set of >>> redundant information, if the definition used are for the earliest >>> data included, the the timestamp may jump back and forth. It >>> should be noted if the payload format has this property or not. >>>=20 >>> Good enough? >>=20 >> Better, but could still be more explicit. How about changing the >> "Such examples are..." sentence to "A common example is a payload >> format for a video codec where the RTP timestamp represents the >> capture time of the video frame, but frames are large enough that >> multiple RTP packets need to be sent for each frame spread across the >> framing interval". >=20 > Yes, that is more focused. >=20 >>=20 >>>> - Section 3.4: should this say anything about AQM and/or QoS >>>> support? >>>=20 >>> I tried writing something about this. I don't know how useful this >>> is. Feedback much appreciated. >>>=20 >>>=20 >>> 3.4.2. Different Queuing Algorithms >>>=20 >>> Routers and Switches on the network path between an IP sender and >>> a particular receiver can exhibit different behaviors affecting the >>> end to end characteristics. One of the more important aspects of >>> this is queuing behavior. Routers and Switches has some amount of >>> queuing to handle temporary bursts of data that designated to leave >>> the switch or router on the same egress link. A queue when not >>> empty results in an increased path delay. >>>=20 >>> The implementation of the queuing effects the delay and also how >>> congestion signals (Explicint Congestion Marking (ECN) or packet >>> drops) are provided to the flow. >>=20 >> Reference RFC 6679 here? >=20 > Yes, for people that like to dig into ECN, going to the RTP spec is a > good first step. >=20 >>=20 >>> The other aspects are if the flow shares the queue with other flows >>> and how the implementation affects the flow interaction. This >>> becomes important for example when real- time flows interacts with >>> long lived TCP flows. TCP have a built in behavior in its >>> congestion control that strive to fill the buffer, thus all flows >>> sharing the buffer experienced the delay build up. >>>=20 >>> A common but quite poor queue handling mechanism is tail-drop, >>> i.e. only drop packets when the incoming packet doesn't fit in the >>> queue. Active Queue Management (AQM) is a term covering mechanism >>> that tries to do something smarter buy actively managing the queue, >>> for example by sending congestion signals earlier by droping >>> packets earlier in the queue. The behavior also affects the flow >>> interactions. For example Random Early Drop (RED) selects which >>> packet to drop randomly. This to give flows that have more packets >>> in the queue a higher probability to experience the packet loss >>> (congestion signal). There is ongoing work to find suitable >>> mechanisms to recommend for implementation and reduce the use of >>> tail-drop. >>>=20 >>> 3.4.3. Quality of Service >>>=20 >>> Using best effort Internet one have no guarantees for the paths >>> properties. Quality of Service (QoS) mechanism are intended to >>> provide the possibility to bound the path properties. Where >>> Diffserv [RFC2475] markings effects the queuing and forwarding >>> behaviors of routers, the mechanism provides only statistical >>> guarantees and care in how much marked packets of different types >>> that are entering the network. Flow based QoS like IntServ >>> [RFC1663] has the potential for stricter guarantees as the >>> properties are agreed on by each hop on the path. >>=20 >> I think this is useful. It highlights that there are issues to >> consider, which is the goal. >=20 >=20 > Good, I was uncertain if this text said the right things. >=20 >>=20 >>>> - The discussion of SST and MST in Section 5.1.5 seems to >>>> confuse sessions with SSRCs. Isn=92t it more important whether the >>>> layers are sent within a single RTP media stream, or as separate >>>> RTP media streams with different SSRC values? Whether the >>>> different SSRCs are sent in one RTP session of many is then a >>>> separate issue, depending on how easily one wants to be able to >>>> separate the flows for QoS purposes. >>>=20 >>> The issue is that the SVC payload RFC is a bit confused on this >>> matter. I agree that there are two separate important distinctions >>> here. First if the layers are sent in one RTP packet stream or used >>> multiple ones. In the second case one gets the question of how one >>> distributes that over RTP sessions and underlying transports. >>> Especially as some that implements SVC MST clearly uses a single >>> RTP session and are after the possibility on a SSRC level to >>> control transmission of layers in RTP middleboxes. >>>=20 >>> I have tried to address this in the text, please review. >>>=20 >>> 5.1.5. Media Scalability >>>=20 >>> Some codecs support various types of media scalability, i.e. some >>> data of a media stream may be removed to adapt the media's >>> properties, such as bitrate and quality. The adaptation may be >>> applied in the following dimensions of the media: >>>=20 >>> Temporal: For video codecs it is possible to adapt the frame >>> rate, e.g. for H.264 [RFC6184]. >>>=20 >>> Spatial: Video codecs supporting scalability may adapt the >>> resolution, e.g. in SVC [RFC6190]. >>>=20 >>> Quality: The quality of the media stream may be scaled by >>> adapting the accuracy of the coding process, as, e.g. possible >>> with Signal to Noise Ratio (SNR) fidelity scalability of SVC >>> [RFC6190]. >>>=20 >>> At the time of writing this document, codecs that support >>> scalability have a bit of revival. It has been realized that >>> getting the required functionality for supporting the features of >>> the media stream into the RTP framework is quite challenging. One >>> of the recent examples for layered and scalable codecs is Scalable >>> Video Coding [RFC6190] (SVC). >>>=20 >>> SVC is a good example for a payload format supporting media >>> scalability features, which have been in its basic form already >>> included in RTP. A layered codec supports the dropping of data >>> parts of a media stream, i.e. RTP packets may be not transmitted >>> or forwarded to a client in order to adapt the media stream rate as >>> well as the media stream quality, while still providing a decodable >>> subset of the media stream to a client. One example for using the >>> scalability feature may be an RTP Mixer (Multipoint Control Unit) >>> which controls the rate and quality sent out to participants in a >>> communication based on dropping RTP packets or removing part of >>> the payload. Another example may be an transport channel which >>> allows for differentiation in Quality of Service (QoS) parameters >>> based on RTP sessions in a multicast session. In such a case, the >>> more important packets of the scalable media stream (base layer) >>> may get better QoS parameters, then the less important packets >>> (enhancement layer) in order to provide some kind of graceful >>> degradation. The scalability features required for allowing an >>> adaptive transport as described in the two examples above are based >>> on RTP multiplexing in order to identify the packets to be dropped >>> or transmitted/forwarded. The multiplexing features defined for >>> Scalable Video Coding [RFC6190] are: >>>=20 >>> single session transmission (SST), where all media layers of the >>> media are transported as single source (SSRC) in a single RTP >>> session; as well as >>>=20 >>> multi session transmission (MST), which should more accurately be >>> called multi stream transmission, where different media layers or a >>> set of media layers are transported in different RTP streams, i.e. >>> using multiple sources (SSRCs). >>>=20 >>> In the first case (SST), additional in-band as well as out-of-band >>> signaling is required in order to allow identification of packets >>> belonging to a specific media layer. Furthermore, an adaptation >>> of the media stream requires dropping of specific packets in order >>> to provide the client with a compliant media stream. In case of >>> using encryption, it is typically required for an adapting network >>> device to be in the security context to allow packet dropping and >>> providing an intact RTP session to the client. This typically >>> requires the network device to be an RTP mixer. >>>=20 >>> In general having a media unaware network device dropping >>> excessive packets will be more problematic than having a Media >>> Aware Network Entity (MANE). First is the need to understand the >>> media format and know which ADUs or payloads that belongs to the >>> layers, that no other layer will be dependent on after the >>> dropping. Secondly, if the MANE can work as RTP mixer or >>> translator it can rewrite the RTP and RTCP in such a way that the >>> receiver will not suspect non-intentional RTP packet losses needing >>> repair actions. This as the receiver can't determine if a lost >>> packet was an important base layer packet or one of the less >>> important extension layers. >>>=20 >>> In the second case (MST), the RTP packet streams can be sent using >>> a single or multiple RTP sessions, and thus transport flows, e.g. >>> on differnt multicast groups. Transmitting the streams in >>> different RTP sessions then the out-of-band signaling typically >>> provides enough information to identify the media layers and its >>> properties. The decision for dropping packets is based on the >>> Network Address which identifies the RTP session to be dropped. In >>> order to allow correct data provision to a decoder after reception >>> from different sessions, data re-alignment mechanisms are described >>> for Scalable Video Coding [RFC6190]. A more generic one is also >>> described in Rapid Sync for RTP flows [RFC6051], which is purely >>> based on existing RTP >>>=20 >>> mechanisms, i.e. the NTP timestamp, for inter-session >>> synchronization. Another signaling feature is the generic >>> indication of dependencies of RTP sessions in SDP, as defined in >>> the Media Decoding Dependency Grouping in SDP [RFC5583]. >>>=20 >>> Using MST within a single RTP session is also possible and allow >>> stream level handling instead of looking deeper into the packets by >>> a MANE. However, transport flow level properties will be the same >>> unless packet based mechanisms like DiffServ is used. >>>=20 >>> When QoS settings, e.g. DiffServ markings, are used to ensure that >>> the extension layers are dropped prior the base layer the >>> receiving end-point has the benefit in MST to know which layer or >>> set of layers the missing packets belong as it will be bound to >>> different RTP sessions. Thus explicitly indicating the importance >>> of the loss. >>=20 >> I think this is okay, but it really needs an implementer of the SVC >> format to comment too. >=20 > Yes, that would be desirable. >=20 >>=20 >>>> - In Section 5.1.6, avoiding wrap-around within the RTCP >>>> reporting timeout interval is also important. >>>=20 >>> If I understand this correctly, this is a minor issue with the RTCP >>> SR and RR packet types as they all uses 32-bit counters. However, >>> other packet types may have issues if they not use extended >>> sequence number counters. >>>=20 >>> This might be more relevant to considerations for configuring RTCP >>> bandwidth and design of RTCP extensions, rather than being an RTP >>> Payload issue. There exists a configuration goal to ensure that >>> RTCP reporting doesn't wrap its fields within multiple reporting >>> intervals. >>>=20 >>> I propose that the following paragraph is added in this section: >>>=20 >>> RTCP is also affected by high packet rates. For RTCP mechanism that >>> do not use extended counters there is significant risk that they >>> wrap multiple times between RTCP reporting or feedback, thus >>> producing uncertainty which packet(s) that are referenced. The >>> payload designer can't effect the RTCP packet formats used and >>> their design, but can note this considerations when configuring >>> RTCP bandwidth and reporting intervals to avoid to wrapping >>> issues. >>=20 >> That's fine, although I was actually suggesting something simpler, >> which is to change "As rule of thumb, it must not be possible to wrap >> the sequence number space in less than 2 minutes (TCP maximum segment >> lifetime)" to "...must not be possible to wrap the sequence number >> space in less than an RTCP reporting interval". >=20 > That is difficult for someone that is new to quantify into meaningful > values. Especially as we have reporting intervals between milliseconds > (a scaled RTCP interval for the gigabit raw video) to many seconds for > large groups with small amounts of receiver reporting bandwidths. >=20 > In addition I don't think one reporting interval is really sufficient. > In absence of RTCP packet loss it provides the bare minimum to detect = a > wrap in RTCP. But one really need to take the maximum interval between > two RTCP packets into account and considering loss I think 3-4 = intervals > are needed to have reasonable saftey. >=20 > The motivation for using TCP MSL was the argument that TCP MSL is > selected as the time interval no emitted packet would still be = possible > to arrive after. That is true also for RTP packets and thus a valid > considerations providing sufficient margins. It also covers almost all > RTCP usages that I can think of. >=20 > I have changed the text to now say: >=20 > Some media codecs require high packet rates, and in these cases the = RTP > sequence number wraps too quickly. As rule of thumb, it must not be > possible to wrap the sequence number space within at least three RTCP > reporting intervals. As the reporting interval can vary widely due to > configuration and session properties, and also must take into account > the randomization of the interval, one can use the TCP maximum segment > lifetime, which is 2 minutes in ones calculations. >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 --=20 Colin Perkins http://csperkins.org/ From harada.noboru@lab.ntt.co.jp Thu Sep 26 10:24:10 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2EB21F9F20 for ; Thu, 26 Sep 2013 10:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYB4RqEGsdHp for ; Thu, 26 Sep 2013 10:24:05 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id 96F5521F999B for ; Thu, 26 Sep 2013 10:23:49 -0700 (PDT) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id r8QHNdtF001549; Fri, 27 Sep 2013 02:23:39 +0900 Received: from mfs5.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 5D71DE0132; Fri, 27 Sep 2013 02:23:39 +0900 (JST) Received: from lab-m2.a.ecl.ntt.co.jp (lab-m2.a.ecl.ntt.co.jp [129.60.155.101]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 4D1B8E0131; Fri, 27 Sep 2013 02:23:39 +0900 (JST) Received: from interscan.a.ecl.ntt.co.jp (interscan.a.ecl.ntt.co.jp [129.60.155.102]) by lab-m2.a.ecl.ntt.co.jp (Postfix) with ESMTP id 2DD641458037; Fri, 27 Sep 2013 02:23:39 +0900 (JST) Received: from interscan.a.ecl.ntt.co.jp (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 1B5FD218057; Fri, 27 Sep 2013 02:23:39 +0900 (JST) Received: from lab-s25.a.ecl.ntt.co.jp (unknown [129.60.155.114]) by interscan.a.ecl.ntt.co.jp (Postfix) with ESMTP id 03F88218056; Fri, 27 Sep 2013 02:23:39 +0900 (JST) Received: from [129.60.211.213] (unknown [129.60.211.213]) by lab-s25.a.ecl.ntt.co.jp (Postfix) with SMTP id D479E2518217; Fri, 27 Sep 2013 02:23:38 +0900 (JST) Date: Fri, 27 Sep 2013 02:23:38 +0900 From: Noboru Harada To: "Michael Ramalho (mramalho)" In-Reply-To: References: Message-Id: <20130927022338.CA3A.24F8F98F@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.65.03 [ja] X-TM-AS-MML: No Cc: "payload@ietf.org" Subject: Re: [payload] Toward WGLC on G.711.0 RTP Payload Spec X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: harada.noboru@lab.ntt.co.jp List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 17:24:10 -0000 Michael, The document has been stable quite a while. I support your proposal to move this draft to the next step. Best Regards, Noboru > All, > > The payload WG has a milestone to submit the RTP Payload Format for G.711.0 for proposed standard in December 2013 (http://datatracker.ietf.org/wg/payload/charter/ ). > > The current working group draft is draft-ietf-payload-g7110-00 ( http://datatracker.ietf.org/doc/draft-ietf-payload-g7110/ ). > > Although this working group document is a "00" draft, it spent much time and prior re-writes as an individual contribution draft known as draft-ramalho-payload-g7110-0X. > > I have not received any requests to change this document since the conversion of the individual contribution draft to the working group draft (which occurred in June 2013). > > As I would like to ask the Payload chairs to last call this document at the Vancouver IETF, please provide any input you have on this document to this list (including if you think it is ready as it is). > > Thanks in advance, > > Michael A. Ramalho -------------------------------------- Noboru Harada NTT Communication Science Laboratories Tel: +81 46 240 3676 FAX: +81 46 240 3145 E-mail: harada.noboru@lab.ntt.co.jp -------------------------------------- From stewe@stewe.org Thu Sep 26 11:08:37 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6CF21F9AD8 for ; Thu, 26 Sep 2013 11:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oth7mjsX3ipB for ; Thu, 26 Sep 2013 11:08:21 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1594511E80E8 for ; Thu, 26 Sep 2013 11:07:49 -0700 (PDT) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB362.namprd07.prod.outlook.com (10.141.75.21) with Microsoft SMTP Server (TLS) id 15.0.775.9; Thu, 26 Sep 2013 18:07:41 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.183]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.3]) with mapi id 15.00.0775.005; Thu, 26 Sep 2013 18:07:40 +0000 From: Stephan Wenger To: Magnus Westerlund , "payload@ietf.org" Thread-Topic: [payload] WGLC for draft-ietf-payload-rtp-howto-05 Thread-Index: AQHOnxW0JqQDumtvLE+Tk9S9gB3Jkpm9jcQAgBqFRAA= Date: Thu, 26 Sep 2013 18:07:39 +0000 Message-ID: In-Reply-To: <522DD636.5030806@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.202.147.60] x-forefront-prvs: 0981815F2F x-forefront-antispam-report: SFV:NSPM; SFS:(51704005)(199002)(189002)(24454002)(51444003)(377424004)(74502001)(77096001)(50986001)(47976001)(49866001)(54356001)(56816003)(76796001)(46102001)(81686001)(81816001)(76176001)(53806001)(561944002)(4396001)(76786001)(47446002)(79102001)(56776001)(76482001)(77982001)(54316002)(63696002)(59766001)(31966008)(83072001)(74662001)(47736001)(65816001)(66066001)(36756003)(81342001)(69226001)(74366001)(74876001)(19580405001)(80976001)(80022001)(51856001)(81542001)(15975445006)(83322001)(74706001)(19580395003)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB362; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:71.202.147.60; FPR:; RD:InfoNoRecords; A:0; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-ID: <55D3D55222DB9B46AF41D32E9528F3C5@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 18:08:38 -0000 Hi Magnus, group, A few random comments. None of them are showstoppers. Yes, I should have contributed those earlier. Sorry. Perhaps add a section about "writing style". Aspects here: (1) contrary to most other SDOs, the IETF has a history of spelling out not only WHAT an implementation is to do, but also WHY. As a lot of RTP payload formats are written by media guys (who's home SDO is not necessarily the IETF), mentioning this could help overcoming a culture shock. (2) OTOH, many/most implementers of RTP payload specs are the same people that also implement the network centric parts of the media codec--at least for well designed media codecs, systems, and payload formats. Therefore, it is also good to reflect the style and terminology of the media codings pec in the payload format--even if that makes the payload spec a little bit less accessible for folks working only in the IETF. This is one reason why I don't feel bad about the often lamented "density" of the H.264 payload specs. No compromises should be made on core IETF habits like the use of 2119 keywords, though. (3) It's also worth spelling out that the IETF has a historic (albeit arguably not current) preference for lean and mean specs, even at the cost of some functionality. Most media codec SDOs operate under an assumption that if there were a use-case/requirement (however exotic/weak it may be, and I note that use/case and requirements discussions have quite often nothing to do with the real world) and no competing tool, a proposal goes in, pleasing certain IPR departments and leading to patent bonuses and career advancements, at the cost of a bloated document. Some RTP payload formats written predominantly by media codec people arguably are bloated as well for the same reason. (And yes, I take personal blame for some of this.) While I do not see that we can change the situation (you want to have the media competence of the media coding people), I think we can at least point it out--hopefully in somewhat more diplomatic language--so to explain a very common culture clash between IETF regulars and payload format writers. In 3.1.1 I would mention prominently the early and personal IPR disclosure obligations in the IETF, as these differ from other SDOs which specify media codecs. Simply pointing to the policy docs may be not enough. Section 3 (and section 1). I think a lot of this description is written for someone who wants to write an RTP payload format for an existing media codec (with a stable and essentially unchangeable spec). While this is probably still the most common scenario, there are a number of cases where the transport aspects of the media coder and the media aspects of the transport (RTP payload format) have been developed concurrently, generally with very pleasing results for both specs. H.264 is one prominent example, but there are others. Arguably, joint development of codec and RTP payload format is becoming a trend. I think that a 2013 generation RTP payload how-to should acknowledge this situation. One way to do that would be to include, in section 3, subsections "read and understand the media coding spec", and "influence the media coding spec". If people think this is a good idea, I'm willing to draft a few paragraphs. I think the 9000 byte path MTU is generally not available in home environments. Instead, MTU sizes larger than the 1500 bytes (from Ethernet) are AFAICT, available only in a few selected (large/medium) enterprises and in the academic world. If that's true, it should be stated. And, in home environments, the limiting factor is often not even the ISP, but those old $50 router boxes (and their NAT implementations) that infest the world. Mentioning this, perhaps with an informative reference to a recent study, would send a message: if your codec will be used a lot in home environments, don't go above 1500 bytes. Not this year, and not next. Sections 5.1.1 and 5.1.2: one key use case of both aggregation and fragmentation is the effective packetization of pre-recorded content, where one cannot change the size of ADUs without transcoding. The key use case of aggregation is the packetization overhead for small ADUs such as parameter sets or SEI messages in H.264. In a different email, you asked for review of 5.1.5. There are more qualified people on this list to comment, but here are a few points. (1) citing H.264 RFC 6184 for temporal scalability is a bit questionable, as 6184 doe snot include a single mechanism to support temporal scalability (although H.264 does). So if people would go to 6184 as the payload format for base H.264 and read it, expecting ideas on how to deal with temporal scalability, they would come up blank after digging through 101 pages of not exactly easy to read spec language. I fear that it would be best to point to SVC and 6190 for temporal scalability, just as it is done for spatial and SNR. (2) with respect to MST: the doc could be read that re-alignment for H.264-SVC could be implemented through 6051. This is not the case, as decoding time and NAL unit order are mostly decoupled (not only in SVC, but in all modern video codecs). (3) Perhaps write something to the extent that MST was unpopular because of the impracticality of multiple transport addresses, and that this reason is slowly going away through IETF-acceptance of RTP mux techniques. Section 6.2, "recent" VC-1. You probably wanted to cite VP8? Calling VC-1 and its payload spec "recent" is a bit of a stretch. Perhaps add a "Do and don't" sections listing key mistakes. In the don't section, list the handling of the timestamp in RFCs 2038 and 2250. Stephan =20 On 9.9.2013 07:07 , "Magnus Westerlund" wrote: >WG, > >As author I would really appreciate some reviews that the content are >appropriate. Thus I really appreciate responses even of the type. "Read >it, no issues spotted". > >Don't assume that I am without flaws in my writing ;-). > >Cheers > >Magnus > >On 2013-08-22 10:58, Ali C. Begen (abegen) wrote: >> (As a WG co-chair) >>=20 >> I am starting WGLC for the following draft (version 05). >> https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto/ >>=20 >> This is an important document as it outlines how someone is supposed to >>write the payload specs. >>=20 >> If there are sections you don't understand or that are not clear >>enough, etc. please post them to the list. We need to get this right to >>minimize further headaches for future documents in our WG. >>=20 >> The deadline for the WGLC is September 20th. >>=20 >> -acbegen >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >>=20 >>=20 > > >--=20 > >Magnus Westerlund > >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > >_______________________________________________ >payload mailing list >payload@ietf.org >https://www.ietf.org/mailman/listinfo/payload From paulej@packetizer.com Thu Sep 26 11:20:11 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE4311E80E8 for ; Thu, 26 Sep 2013 11:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuPmwrvuH0Cn for ; Thu, 26 Sep 2013 11:19:53 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA7B21E80AB for ; Thu, 26 Sep 2013 11:19:30 -0700 (PDT) Received: from [192.168.1.20] (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r8QIJSen013648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Sep 2013 14:19:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1380219568; bh=dgxyY8VzgyTO9iVHJIyP4FimAQqZDi2UZPrjLvnip/Y=; h=From:To:Subject:Date:Content-Type:In-Reply-To:Message-Id: Mime-Version:Reply-To; b=Zj4thPz4+rEjSGyMherKhrlc7eGDGECR7co4BmlwPtIiPNd74jnwgMI7A5g1vpKeM 4rT1fOiBN7eLmCR+l6b5f9poc2T/z/3XwB4XkwQi0S2qLdPGG7dooOIh4v9S+tO8Ih KWKr+ANUaOxVZoeUHIr5fDvzdMa+CYuqXM1hF0+g= From: "Paul E. Jones" To: "Michael Ramalho (mramalho)" , "payload@ietf.org" Date: Thu, 26 Sep 2013 18:19:37 +0000 Content-Type: multipart/alternative; boundary="------=_MB914453BF-6028-41CB-A74D-D6AD7C635494" In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/5.0.18661.0 Subject: Re: [payload] Toward WGLC on G.711.0 RTP Payload Spec X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Paul E. Jones" List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 18:20:12 -0000 --------=_MB914453BF-6028-41CB-A74D-D6AD7C635494 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 I support going for LC. Paul ------ Original Message ------ From: "Michael Ramalho (mramalho)" To: "payload@ietf.org" Sent: 9/25/2013 5:16:37 PM Subject: [payload] Toward WGLC on G.711.0 RTP Payload Spec >All, > > > >The payload WG has a milestone to submit the RTP Payload Format for=20 >G.711.0 for proposed standard in December 2013=20 >(http://datatracker.ietf.org/wg/payload/charter/ ). > > > >The current working group draft is draft-ietf-payload-g7110-00 (=20 >http://datatracker.ietf.org/doc/draft-ietf-payload-g7110/ ). > > > >Although this working group document is a =E2=80=9C00=E2=80=9D draft, it= spent much=20 >time and prior re-writes as an individual contribution draft known as=20 >draft-ramalho-payload-g7110-0X. > > > >I have not received any requests to change this document since the=20 >conversion of the individual contribution draft to the working group=20 >draft (which occurred in June 2013). > > > >As I would like to ask the Payload chairs to last call this document at= =20 >the Vancouver IETF, please provide any input you have on this document=20 >to this list (including if you think it is ready as it is). > > > >Thanks in advance, > > > >Michael A. Ramalho > --------=_MB914453BF-6028-41CB-A74D-D6AD7C635494 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I support going for LC.
 
Paul
 
------ Original Message ------
From: "Michael Ramalho (mramalho)" <mramalho@cisco.com>
To: "payload@ietf.org" <payload= @ietf.org>
Sent: 9/25/2013 5:16:37 PM
Subject: [payload] Toward WGLC on G.711.0 RTP Payload Spec

All,

 

The payload WG has a milestone to submit the RTP Paylo= ad Format for G.711.0 for proposed standard in December 2013 (http://datatracker.ietf.o= rg/wg/payload/charter/ ).

 

The current working group draft is draft-ietf-payload-= g7110-00 ( http://datatracker.ietf.org/doc/draft-ietf-payload-g7110/ ).=

 

Although this working group document is a =E2=80=9C= 00=E2=80=9D draft, it spent much time and prior re-writes as an individual= contribution draft known as draft-ramalho-payload-g7110-0X.

 

I have not received any requests to change this docume= nt since the conversion of the individual contribution draft to the working= group draft (which occurred in June 2013).

 

As I would like to ask the Payload chairs to last call= this document at the Vancouver IETF, please provide any input you have = on this document to this list (including if you think it is ready as it = is).

 

Thanks in advance,

 

Michael A. Ramalho

--------=_MB914453BF-6028-41CB-A74D-D6AD7C635494-- From stewe@stewe.org Thu Sep 26 13:18:43 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF6821F9343 for ; Thu, 26 Sep 2013 13:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_EXTNSN=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCMMRDv1oMFy for ; Thu, 26 Sep 2013 13:18:38 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id 8853A21E80B1 for ; Thu, 26 Sep 2013 13:18:38 -0700 (PDT) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB362.namprd07.prod.outlook.com (10.141.75.21) with Microsoft SMTP Server (TLS) id 15.0.775.9; Thu, 26 Sep 2013 20:18:35 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.183]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.3]) with mapi id 15.00.0775.005; Thu, 26 Sep 2013 20:18:35 +0000 From: Stephan Wenger To: "payload@ietf.org" Thread-Topic: New Version Notification for draft-wenger-payload-h265-payload-header-extension-00.txt Thread-Index: AQHOuvWTBG5KaPm+6ESXmTTaE/l+pA== Date: Thu, 26 Sep 2013 20:18:34 +0000 Message-ID: In-Reply-To: <20130926200808.29653.4083.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.202.147.60] x-forefront-prvs: 0981815F2F x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(51704005)(189002)(24454002)(164054003)(377424004)(53754006)(77096001)(74502001)(50986001)(47976001)(49866001)(54356001)(56816003)(46102001)(81686001)(81816001)(76796001)(76176001)(76786001)(561944002)(4396001)(53806001)(47446002)(79102001)(56776001)(76482001)(77982001)(54316002)(63696002)(59766001)(31966008)(83072001)(74662001)(47736001)(65816001)(66066001)(36756003)(81342001)(69226001)(74876001)(74366001)(19580405001)(80976001)(80022001)(51856001)(81542001)(15975445006)(83322001)(74706001)(19580395003)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB362; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:71.202.147.60; FPR:; RD:InfoNoRecords; A:0; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: Jonathan Lennox , Jill Boyce Subject: [payload] FW: New Version Notification for draft-wenger-payload-h265-payload-header-extension-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 20:18:43 -0000 Hi all, In Berlin's payload session presentation of the H.265 payload format (graciously hosted by AVTcore), I mentioned that we want to include support for temporal scalability in the draft H.265 payload format. Attached a quick draft showing how this could be done--basically a (we believe) improved variant of the PACSI NAL unit of RFC 6190. There are two alternative proposals in the draft, trading off alignment with design principles of H.265 one one side and efficiency on the other. Vidyo has IPR on this draft, which we will make available under terms like this: https://datatracker.ietf.org/ipr/1622/. I believe that the concepts of this draft should be included in the H.265 payload format itself, rather than being stand-alone. Once that happens, or if the group decides the draft to stay stand-alone, we will file the official IPR disclosure against the then-current and appropriate document, so not to clutter the database. =20 Comments welcome. Thanks, Stephan On 9.26.2013 13:08 , "internet-drafts@ietf.org" wrote: > >A new version of I-D, >draft-wenger-payload-h265-payload-header-extension-00.txt >has been successfully submitted by Stephan Wenger and posted to the >IETF repository. > >Filename: draft-wenger-payload-h265-payload-header-extension >Revision: 00 >Title: H.265 Payload Header Extension and Temporal Scalability Support >Creation date: 2013-09-26 >Group: Individual Submission >Number of pages: 10 >URL: =20 >http://www.ietf.org/internet-drafts/draft-wenger-payload-h265-payload-head >er-extension-00.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-wenger-payload-h265-payload-header-e >xtension >Htmlized: =20 >http://tools.ietf.org/html/draft-wenger-payload-h265-payload-header-extens >ion-00 > > >Abstract: > Proposed are the allocation of a NAL unit type from the > "unspecified" set of NAL units of H.265 [HEVC] for the purpose of > payload header extensions, a generic syntax for the use of that > pseudo NAL unit, and one application for it: the signaling of > temporal scalability support information. Two alternative designs > are included. The content of this draft is intended for > incorporation into the H.265 RTP payload [h265-payload]. > > > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From harald@alvestrand.no Fri Sep 27 03:01:13 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B8721F9C10 for ; Fri, 27 Sep 2013 03:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.504 X-Spam-Level: X-Spam-Status: No, score=-110.504 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXYQspB+kt3L for ; Fri, 27 Sep 2013 03:01:08 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id AA73021F9AA4 for ; Fri, 27 Sep 2013 03:01:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9709E39E1E4; Fri, 27 Sep 2013 12:01:03 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ua9uA3K2hChO; Fri, 27 Sep 2013 12:01:01 +0200 (CEST) Received: from [192.168.1.17] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id CEE0939E04C; Fri, 27 Sep 2013 12:01:01 +0200 (CEST) Message-ID: <52455761.7030002@alvestrand.no> Date: Fri, 27 Sep 2013 12:01:05 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: John Lindsay References: <8C4E0C2409735E4FBC22D754A238F94D02F74C4C@APTSBS.apt.local> <52385092.5000000@alvestrand.no> <8C4E0C2409735E4FBC22D754A238F94D02F74FD5@APTSBS.apt.local> In-Reply-To: <8C4E0C2409735E4FBC22D754A238F94D02F74FD5@APTSBS.apt.local> Content-Type: multipart/alternative; boundary="------------010902030706040207070505" Cc: Foerster@worldcastsystems.com, payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-aptx-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 10:01:13 -0000 This is a multi-part message in MIME format. --------------010902030706040207070505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/24/2013 07:06 PM, John Lindsay wrote: > > Hi Harald > > Thanks for reviewing this and the points raised. > > To increase clarity we can change the statement in section 3 > > From > > Standard apt-X and Enhanced apt-X are proprietary audio coding > > algorithms, licensed by CSR plc and widely deployed in a variety of > > audio processing equipment. > > To > > Standard apt-X and Enhanced apt-X are proprietary audio coding > > algorithms, which can be licensed from CSR plc and are widely > > deployed in a variety of audio processing equipment. > That looks good to me. It was a nit, but worth fixing! > > Section 3 of the doc provides an overview of the codecs operation. The > aim of the draft is how to packetize Standard or Enhanced apt-X over > RTP not to explain the operation of the codec. Further details are > likely to be proprietary to CSR and interested parties would need to > talk to CSR directly about obtaining licenses and setting up NDA's etc > for further information. > > Regards > > John > > *From:*payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] *On > Behalf Of *Harald Alvestrand > *Sent:* 17 September 2013 13:53 > *To:* payload@ietf.org > *Subject:* Re: [payload] I-D Action: draft-ietf-payload-rtp-aptx-01.txt > > Brief scan, one question: > > Is it possible to offer a stable reference for what "Standard apt-x" > and "Enhanced apt-x" means? > > The closest I can get is "licensed by CSR plc", which presumably means > that "it means what CSR plc thinks it means", but it would be great to > have that stated explicitly. > > Something like: > > The codecs "apt-x" and "Extended apt-x" are defined by CSR plc, an UK > company. > > Section 3 of the draft *almost* says that, but isn't completely > unambiguous ("licensed by" can mean both "CSR is a licensor" and "CSR > is a licensee, someone else defines it"). > > I *think* this is a nit. > > > On 09/10/2013 03:50 PM, John Lindsay wrote: > > Hi > > A new draft has been uploaded to the IETF Payload workgroup at > https://datatracker.ietf.org/wg/payload/. > > The new document makes a few minor changes for IDNITS checking and > also takes account of the comments made by Peter Stevens last week. > > A summary of the changes are as follows. > > Page 1, IETF Copyright notice updated to 2013. > > Page 10, updated formatting for IDNITS check. > > Page 14, Section 6 updated to reflect RFC 6838 which supersedes > RFC 4288. > > Page 16, Section 6.2.1 type corrected An -- A as per Peter Stevens > comments. > > Page 18, Section 7 now reference 6.1 rather than 7.1, again thanks > to Peters proof reading. > > Page 21, new RFC6338 referenced. > > Thanks to everyone who has read and commented on the draft. > > Regards > > John > > > > > _______________________________________________ > > payload mailing list > > payload@ietf.org > > https://www.ietf.org/mailman/listinfo/payload > --------------010902030706040207070505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 09/24/2013 07:06 PM, John Lindsay wrote:

Hi Harald

 

Thanks for reviewing this and the points raised.

 

To increase clarity we can change the statement in section 3

 

From

Standard apt-X and Enhanced apt-X are proprietary audio coding

   algorithms, licensed by CSR plc and widely deployed in a variety of

   audio processing equipment.

 

To

Standard apt-X and Enhanced apt-X are proprietary audio coding

   algorithms, which can be licensed from CSR plc and are widely

  deployed in a variety of audio processing equipment.


That looks good to me. It was a nit, but worth fixing!

 

Section 3 of the doc provides an overview of the codecs operation. The aim of the draft is how to packetize Standard or Enhanced apt-X over RTP not to explain the operation of the codec. Further details are likely to be proprietary to CSR and interested parties would need to talk to CSR directly about obtaining licenses and setting up NDA's etc for further information.

 

Regards

 

John

 

From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: 17 September 2013 13:53
To: payload@ietf.org
Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-aptx-01.txt

 

Brief scan, one question:

Is it possible to offer a stable reference for what "Standard apt-x" and "Enhanced apt-x" means?

The closest I can get is "licensed by CSR plc", which presumably means that "it means what CSR plc thinks it means", but it would be great to have that stated explicitly.

Something like:

The codecs "apt-x" and "Extended apt-x" are defined by CSR plc, an UK company.

Section 3 of the draft *almost* says that, but isn't completely unambiguous ("licensed by" can mean both "CSR is a licensor" and "CSR is a licensee, someone else defines it").

I *think* this is a nit.


On 09/10/2013 03:50 PM, John Lindsay wrote:

Hi

 

A new draft has been uploaded to the IETF Payload workgroup at https://datatracker.ietf.org/wg/payload/.

 

The new document makes a few minor changes for IDNITS checking and also takes account of the comments made by Peter Stevens last week.

 

A summary of the changes are as follows.

 

Page 1, IETF Copyright notice updated to 2013.

Page 10, updated formatting for IDNITS check.

Page 14, Section 6 updated to reflect RFC 6838 which supersedes RFC 4288.

Page 16, Section 6.2.1 type corrected An – A as per Peter Stevens comments.

Page 18, Section 7 now reference 6.1 rather than 7.1, again thanks to Peters proof reading.

Page 21, new RFC6338 referenced.

 

Thanks to everyone who has read and commented on the draft.

 

Regards

 

John

 

 




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

 


--------------010902030706040207070505--