From nobody Sun Oct 1 04:25:26 2017 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 1C40E13489B; Sun, 1 Oct 2017 04:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hM-fYGwIsJ8g; Sun, 1 Oct 2017 04:25:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC287134897; Sun, 1 Oct 2017 04:25:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DWP73025; Sun, 01 Oct 2017 11:25:18 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 1 Oct 2017 12:25:17 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.187]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0301.000; Sun, 1 Oct 2017 19:25:14 +0800 From: Roni Even To: Thomas Edwards CC: "payload-chairs@ietf.org" , "draft-ietf-payload-rtp-ancillary@ietf.org" , "payload@ietf.org" , "acbegen@gmail.com" , Adam Roach Thread-Topic: Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) Thread-Index: AQHTFjbD5uxO79354kmKPbq9ZGEoqKK9h+8AgAIma4CAAROegIAAhb4AgAZyKgCAARPlsP//4DOAgAZ1aQA= Date: Sun, 1 Oct 2017 11:25:13 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD810751@DGGEMM506-MBX.china.huawei.com> References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <3B259563-1075-4C41-A832-D7633C39173B@foxeg.com> <61440eb5-32c3-3696-be38-8dc7c4eaf72f@nostrum.com> <863974D7-E112-4794-AD4D-C39C99BD40C9@foxeg.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> <6E58094ECC8D8344914996DAD28F1CCD80FC21@DGGEMM506-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.141] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.59D0D09F.0008, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.187, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f750718b734afeec8e62afd780ca3f05 Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 01 Oct 2017 11:25:25 -0000 SGkgVGhvbWFzLA0KSSB0aGluayB0aGF0IHlvdSBzaG91bGQgYWxzbyBoYXZlIGluIHRoZSBncm91 cGluZyBzZWN0aW9uIGEgcmVjb21tZW5kYXRpb24gdG8gdXNlIHRoZSBzYW1lIHBlcnNpc3RlbnQg Q05BTUUgKG1heWJlIHNob3J0IHRlcm0/KSBmb3IgdGhlIEFOQyBhbmQgdmlkZW8gc3RyZWFtIHNl ZSBSRkMgNzAyMiB0aGlzIGlzIHJlcXVpcmVkIGluIFJUQ1AgaWYgdGhlc2UgUlRQIHN0cmVhbXMg bmVlZCB0byBiZSBzeW5jaHJvbml6ZWQgKFJGQzM1NTApDQpSb25pDQoNCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBUaG9tYXMgRWR3YXJkcyBbbWFpbHRvOlRob21hcy5F ZHdhcmRzQGZveC5jb21dDQo+IFNlbnQ6INeZ15XXncKg15MgMjcg16HXpNeY157XkdeoIDIwMTcg MTg6NDcNCj4gVG86IFJvbmkgRXZlbjsgQWRhbSBSb2FjaDsgVGhlIElFU0cNCj4gQ2M6IHBheWxv YWQtY2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRmLXBheWxvYWQtcnRwLWFuY2lsbGFyeUBpZXRm Lm9yZzsNCj4gcGF5bG9hZEBpZXRmLm9yZzsgYWNiZWdlbkBnbWFpbC5jb20NCj4gU3ViamVjdDog UmU6IEFkYW0gUm9hY2gncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtYW5jaWxs YXJ5LTEwOg0KPiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiANCj4gUm9uaSwgdGhhbmtz IGZvciB0aGUgZmVlZGJhY2sgb24gTFMhDQo+IA0KPiBJ4oCZbSBzdGlsbCBub3Qgc3VyZSBpZiBp dCBpcyBhcHByb3ByaWF0ZSB0byBpbmNsdWRlIHRoZSBoaWVyYXJjaGljYWwgZ3JvdXBpbmcgU0RQ DQo+IGV4YW1wbGUgaW4gZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1hbmNpbGxhcnkuICBJIHN1c3Bl Y3QgaXQgY291bGQgYmUgY29uZnVzaW5nLg0KPiANCj4gSG93ZXZlciwgSSB3aWxsIG5vdGUgdGhh dCB0aGUgQWxsaWFuY2UgZm9yIElQIE1lZGlhIFNvbHV0aW9ucw0KPiAoaHR0cDovL2FpbXNhbGxp YW5jZS5vcmcpIFRlY2huaWNhbCBDb21taXR0ZWUgaXMgY29uc2lkZXJpbmcgd29yayBvbg0KPiBk b2N1bWVudGluZyBkaWZmZXJlbnQgU0RQIGdyb3VwaW5ncyBmb3IgbGl2ZSB0ZWxldmlzaW9uIHBy b2R1Y3Rpb24gc2NlbmFyaW9zLA0KPiBzbyBpdCBpcyBwb3NzaWJsZSB0aGF0IGEgZnV0dXJlIEkt RCB3aWxsIGJlIHN1Ym1pdHRlZCB0aGF0IGNvdWxkIGluY2x1ZGUgYSByYW5nZQ0KPiBvZiBTRFAg YXBwbGljYXRpb25zIGluIHRoaXMgYXJlYSwgcGVyaGFwcyBpbmNsdWRpbmcgZG9jdW1lbnRhdGlv biBvZiBBZGFtDQo+IFJvYWNo4oCZcyBzY2VuYXJpby4NCj4gDQo+IEkgY2FuIGdvIGFoZWFkIGFu ZCB1cGxvYWQgYSBkcmFmdC1pZXRmLXBheWxvYWQtcnRwLWFuY2lsbGFyeS0xMSBiYXNlZCBvbiB0 aGUNCj4gSUVTRyBmZWVkYmFjay4NCj4gDQo+IC1UaG9tYXMNCj4gDQo+IC0tDQo+IFRob21hcyBF ZHdhcmRzDQo+IEZPWCBOZXR3b3JrcyBFbmdpbmVlcmluZyAmIE9wZXJhdGlvbnMNCj4gVlAgRW5n aW5lZXJpbmcgJiBEZXZlbG9wbWVudA0KPiB0aG9tYXMuZWR3YXJkc0Bmb3guY29tDQo+ICsxLTMx MC0zNjktNjY5Ng0KPiAxMDIwMSBXIFBpY28gQmx2ZA0KPiBMb3MgQW5nZWxlcywgQ0EgOTAwMzUN Cj4gDQo+IA0KPiBPbiA5LzI3LzE3LCA0OjA3IEFNLCAiUm9uaSBFdmVuIiA8cm9uaS5ldmVuQGh1 YXdlaS5jb20+IHdyb3RlOg0KPiANCj4gICAgIEhpLA0KPiANCj4gICAgIEkgYWdyZWUgdGhhdCBM UyBpcyBiZXR0ZXIgZml0IGZvciBBTkMNCj4gDQo+IA0KPiANCj4gICAgIEFzIGZvciBBZGFtJ3Mg ZXhhbXBsZSBpdCBpcyBhbGxvd2VkIGJ5IFJGQzU4ODggdG8gc3BlY2lmeQ0KPiANCj4gICAgICAg ICAgICAgYT1ncm91cDpMUyBWMSBWMiBNMSBNMg0KPiANCj4gICAgICAgICAgICAgYT1ncm91cDpM UyBWMSBNMQ0KPiANCj4gICAgICAgICAgICAgYT1ncm91cDpMUyBWMiAgTTINCj4gDQo+ICAgICB0 aGlzIGlzIHNpbWlsYXIgdG8gUkZDNTk1NiAgd2hpY2ggcmVwbGFjZWQgUkZDNDc1Ng0KPiANCj4g DQo+IA0KPiAgICAgdGhpcyBpcyBub3QgYSBjbGVhbiB3YXkgYnV0ICBpcyBhbGxvd2VkIG90aGVy d2lzZSB0aGVyZSBpcyBhIG5lZWQgdG8gc3BlY2lmeQ0KPiBzb21lIFNEUCBhdHRyaWJ1dGUgZm9y IHNwZWNpZnlpbmcgZGVwZW5kZW5jaWVzLg0KPiANCj4gDQo+IA0KPiAgICAgUm9uaSBFdmVuDQo+ IA0KPiANCj4gDQo+IA0KPiANCj4gICAgID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g DQo+ICAgICA+IEZyb206IFRob21hcyBFZHdhcmRzIFttYWlsdG86VGhvbWFzLkVkd2FyZHNAZm94 LmNvbV0NCj4gDQo+ICAgICA+IFNlbnQ6INeZ15XXnSDXkyAyNyDXodek15jXnteR16ggMjAxNyAw NDoxMw0KPiANCj4gICAgID4gVG86IEFkYW0gUm9hY2g7IFRoZSBJRVNHDQo+IA0KPiAgICAgPiBD YzogcGF5bG9hZC1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtYW5jaWxs YXJ5QGlldGYub3JnOw0KPiANCj4gICAgID4gcGF5bG9hZEBpZXRmLm9yZzsgYWNiZWdlbkBnbWFp bC5jb20NCj4gDQo+ICAgICA+IFN1YmplY3Q6IFJlOiBBZGFtIFJvYWNoJ3MgRGlzY3VzcyBvbiBk cmFmdC1pZXRmLXBheWxvYWQtcnRwLWFuY2lsbGFyeS0xMDoNCj4gDQo+ICAgICA+ICh3aXRoIERJ U0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gUmVnYXJkaW5nIGRy YWZ0LWlldGYtcGF5bG9hZC1ydHAtYW5jaWxsYXJ5LTEwLCBvbiBmdXJ0aGVyIHRob3VnaHQgSSBi ZWxpZXZlDQo+IA0KPiAgICAgPiB0aGF0IEZJRCBncm91cGluZyBpcyBOT1QgYXBwcm9wcmlhdGUg Zm9yIFNlY3Rpb24gNC4xIOKAnEdyb3VwaW5nIEFOQw0KPiBTdHJlYW1zDQo+IA0KPiAgICAgPiB3 aXRoIG90aGVyIE1lZGlhIFN0cmVhbXPigJ0uDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gUkZD IDU4ODggU2VjdGlvbiA4LjQuICjigJxGSUQgU2VtYW50aWNz4oCdKSBzdGF0ZXM6DQo+IA0KPiAg ICAgPg0KPiANCj4gICAgID4gICAgICAgIOKAnEl0IGlzIGFzc3VtZWQgdGhhdCB0aGUgYXBwbGlj YXRpb24gdXNlcyBvbmx5IG9uZSBjb2RlYyBhdCBhIHRpbWUgdG8NCj4gDQo+ICAgICA+IGVuY29k ZSB0aGUgbWVkaWEgcHJvZHVjZWQuICBUaGlzIGNvZGVjIE1BWSBjaGFuZ2UgZHluYW1pY2FsbHkg ZHVyaW5nDQo+IHRoZQ0KPiANCj4gICAgID4gc2Vzc2lvbiwgYnV0IGF0IGFueSBwYXJ0aWN1bGFy IG1vbWVudCwgb25seSBvbmUgY29kZWMgaXMgaW4gdXNlLuKAnQ0KPiANCj4gICAgID4NCj4gDQo+ ICAgICA+IFJGQyA1ODg4IFNlY3Rpb24gOC41LjEgc3RhdGVzOg0KPiANCj4gICAgID4NCj4gDQo+ ICAgICA+IAnigJxGSUQgc2VtYW50aWNzIGFyZSB1c2VmdWwgd2hlbiB0aGUgYXBwbGljYXRpb24g b25seSB1c2VzIG9uZSBjb2RlYw0KPiANCj4gICAgID4gYXQgYSB0aW1lLiAgQW4gYXBwbGljYXRp b24gdGhhdCBlbmNvZGVzIHRoZSBzYW1lIG1lZGlhIHVzaW5nIGRpZmZlcmVudA0KPiANCj4gICAg ID4gY29kZWNzIHNpbXVsdGFuZW91c2x5IE1VU1QgTk9UIHVzZSBGSUQgdG8gZ3JvdXAgdGhvc2Ug bWVkaWEgbGluZXMu4oCdDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gV2hlbiB3ZSBoYXZlIG9u ZSB2aWRlbyBzdHJlYW0gYW5kIG9uZSBhbmNpbGxhcnkgZGF0YSBzdHJlYW0sIHNlbmRlcnMNCj4g YXJlDQo+IA0KPiAgICAgPiBub3Qgc3dpdGNoaW5nIGJldHdlZW4gY29kZWNzLiAgRklEIHJlYWxs eSBzb3VuZHMgdG8gbWUgbGlrZSBhIHNpdHVhdGlvbg0KPiB3aGVyZQ0KPiANCj4gICAgID4geW91 IGhhdmUgb25lIG1lZGlhIHN0cmVhbSwgYnV0IHNlbmRlcnMgY291bGQgc2VuZCB0aGF0IHN0cmVh bSBvbmUgb2YNCj4gDQo+ICAgICA+IG11bHRpcGxlIGNvZGVjcywgYnV0IG5vdCBhdCB0aGUgc2Ft ZSB0aW1lLg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+IENvbXBhcmUgd2l0aCBSRkMgNTg4OCBT ZWN0aW9uIDc6DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gCeKAnE5vdGUgdGhhdCBMUyBzZW1h bnRpY3MgYXBwbHkgbm90IG9ubHkgdG8gYSB2aWRlbyBzdHJlYW0gdGhhdCBoYXMgdG8NCj4gDQo+ ICAgICA+IGJlIHN5bmNocm9uaXplZCB3aXRoIGFuIGF1ZGlvIHN0cmVhbTsgdGhlIHBsYXlvdXQg b2YgdHdvIHN0cmVhbXMgb2YgdGhlDQo+IA0KPiAgICAgPiBzYW1lIHR5cGUgY2FuIGJlIHN5bmNo cm9uaXplZCBhcyB3ZWxsLuKAnQ0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+IFN5bmNocm9uaXpl ZCBwcmVzZW50YXRpb24gdG8gdGhlIHVzZXIgb2YgYW4gYXVkaW8sIHZpZGVvLCBhbmQgb2YgY291 cnNlDQo+IA0KPiAgICAgPiBhbmNpbGxhcnkgZGF0YSBmbG93IGlzIGdlbmVyYWxseSB3aGF0IHdl IG5lZWQgZm9yIHByb2R1Y3Rpb24gdGVsZXZpc2lvbg0KPiANCj4gICAgID4gd29ya2Zsb3dzLg0K PiANCj4gICAgID4NCj4gDQo+ICAgICA+IGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtYW5jaWxsYXJ5 LTEwIFNlY3Rpb24gNC4xIGhhcyB0aGUgZXhhbXBsZToNCj4gDQo+ICAgICA+DQo+IA0KPiAgICAg PiAgICAgICAgIHY9MA0KPiANCj4gICAgID4gICAgICAgICBvPUFsIDEyMzQ1NiAxMSBJTiBJUDQN Cj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtDQo+IDNB X19ob3N0LmV4YW1wbGUuY29tJmQ9RHdJR2FRJmM9dXc2VEx1NGh3aEhkaUdKT2d3Y1dENEFqS1F4 DQo+IDZ6dkZjR0VzYmZpWTktDQo+IEVJJnI9bGVrTk9PTTVub1Y2MXpyUEgzcndQeWh0Tm5MTFdv TEVIZ2QwcXVReGx5OCZtPW1tdHlMWHR5YQ0KPiBXSEVnM0pZY3EzeFNWTFh6UnFrSVZnV0FKRGdx eUlncmVVJnM9VXVPd0NsWG9HQ3ZHUDJxa3NpVjNoODVIDQo+IE5nUVJvX1o3YjBIZ1UycVZ3elEm ZT0NCj4gDQo+ICAgICA+ICAgICAgICAgcz1Qcm9mZXNzaW9uYWwgTmV0d29ya2VkIE1lZGlhIFRl c3QNCj4gDQo+ICAgICA+ICAgICAgICAgaT1BIHRlc3Qgb2Ygc3luY2hyb25pemVkIHZpZGVvIGFu ZCBBTkMgZGF0YQ0KPiANCj4gICAgID4gICAgICAgICB0PTAgMA0KPiANCj4gICAgID4gICAgICAg ICBhPWdyb3VwOkxTIFYxIE0xDQo+IA0KPiAgICAgPiAgICAgICAgIG09dmlkZW8gNTAwMDAgUlRQ L0FWUCA5Ng0KPiANCj4gICAgID4gICAgICAgICBjPUlOIElQNCBodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0NCj4gM0FfXzIzMy4yNTIuMC4xXzI1NSZkPUR3 SUdhUSZjPXV3NlRMdTRod2hIZGlHSk9nd2NXRDRBaktReDZ6dg0KPiBGY0dFc2JmaVk5LQ0KPiBF SSZyPWxla05PT001bm9WNjF6clBIM3J3UHlodE5uTExXb0xFSGdkMHF1UXhseTgmbT1tbXR5TFh0 eWENCj4gV0hFZzNKWWNxM3hTVkxYelJxa0lWZ1dBSkRncXlJZ3JlVSZzPW1EamNjZEZSOE1XbmZR Y1BfeGlNaGItDQo+IGJoLVdlZl8ydEtoUkR5UmlsWVVNJmU9DQo+IA0KPiAgICAgPiAgICAgICAg IGE9cnRwbWFwOjk2IHJhdy85MDAwMA0KPiANCj4gICAgID4gICAgICAgICBhPWZtdHA6OTYgc2Ft cGxpbmc9WUNiQ3ItNDoyOjI7IHdpZHRoPTEyODA7IGhlaWdodD03MjA7IGRlcHRoPTEwDQo+IA0K PiAgICAgPiAgICAgICAgIGE9bWlkOlYxDQo+IA0KPiAgICAgPiAgICAgICAgIG09dmlkZW8gNTAw MTAgUlRQL0FWUCA5Nw0KPiANCj4gICAgID4gICAgICAgICBjPUlOIElQNCBodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0NCj4gM0FfXzIzMy4yNTIuMC4yXzI1 NSZkPUR3SUdhUSZjPXV3NlRMdTRod2hIZGlHSk9nd2NXRDRBaktReDZ6dg0KPiBGY0dFc2JmaVk5 LQ0KPiBFSSZyPWxla05PT001bm9WNjF6clBIM3J3UHlodE5uTExXb0xFSGdkMHF1UXhseTgmbT1t bXR5TFh0eWENCj4gV0hFZzNKWWNxM3hTVkxYelJxa0lWZ1dBSkRncXlJZ3JlVSZzPTdlNjZld1FW QXVMMVlVcTJGekFTeUVKcA0KPiBxdzdUYzVwOGZPOGxaYlo0dFVvJmU9DQo+IA0KPiAgICAgPiAg ICAgICAgIGE9cnRwbWFwOjk3IHNtcHRlMjkxLzkwMDAwDQo+IA0KPiAgICAgPiAgICAgICAgIGE9 Zm10cDo5NyBESURfU0RJRD17MHg2MSwweDAyfTtESURfU0RJRD17MHg0MSwweDA1fQ0KPiANCj4g ICAgID4gICAgICAgICBhPW1pZDpNMQ0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+IEFzIHNvbWUg aGF2ZSBwb2ludGVkIG91dCwgUlRQIHRpbWVzdGFtcHMgYW5kIFJUQ1AgcHJvdmlkZSBpbmhlcmVu dA0KPiANCj4gICAgID4gc3luY2hyb25pemF0aW9uIGJldHdlZW4g4oCcbeKAnSBsaW5lcywgYnV0 IG9mIGNvdXJzZSBhcyBSRkMgNTg4OCBTZWN0aW9uIDENCj4gc2F5cw0KPiANCj4gICAgID4gd2l0 aG91dCBncm91cGluZzog4oCcV2hlbiBhIHNlc3Npb24gZGVzY3JpcHRpb24gY29udGFpbnMgbW9y ZSB0aGFuIG9uZQ0KPiAibSINCj4gDQo+ICAgICA+IGxpbmUsIFNEUCBkb2VzIG5vdCBwcm92aWRl IGFueSBtZWFucyB0byBleHByZXNzIGEgcGFydGljdWxhciByZWxhdGlvbnNoaXANCj4gDQo+ICAg ICA+IGJldHdlZW4gdHdvIG9yIG1vcmUgb2YgdGhlbS7igJ0gIOKAnExT4oCdIGdyb3VwaW5nIG1h a2VzIGl0IHByZXR0eSBjbGVhciB0aGF0DQo+IA0KPiAgICAgPiB0aGVzZSBzdHJlYW1zIGFyZSBp bnRlbmRlZCBmb3Igc3luY2hyb25pemVkIHByZXNlbnRhdGlvbi4NCj4gDQo+ICAgICA+DQo+IA0K PiAgICAgPiBBbiBhbHRlcm5hdGl2ZSB0byDigJxMU+KAnSBncm91cGluZyBpcyB0byBkcm9wIGFs bCBncm91cGluZyBpbiB0aGUgZXhhbXBsZSwgYW5kDQo+IGJlDQo+IA0KPiAgICAgPiB1bmNsZWFy IGFib3V0IHdoYXQgdGhlc2Ug4oCcbeKAnSBsaW5lcyBhcmUgZG9pbmcgdG9nZXRoZXIgaW4gdGhl IHNhbWUgZmlsZToNCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgICAgIHY9MA0KPiANCj4g ICAgID4gICAgICAgICBvPUFsIDEyMzQ1NiAxMSBJTiBJUDQNCj4gaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtDQo+IDNBX19ob3N0LmV4YW1wbGUuY29tJmQ9 RHdJR2FRJmM9dXc2VEx1NGh3aEhkaUdKT2d3Y1dENEFqS1F4DQo+IDZ6dkZjR0VzYmZpWTktDQo+ IEVJJnI9bGVrTk9PTTVub1Y2MXpyUEgzcndQeWh0Tm5MTFdvTEVIZ2QwcXVReGx5OCZtPW1tdHlM WHR5YQ0KPiBXSEVnM0pZY3EzeFNWTFh6UnFrSVZnV0FKRGdxeUlncmVVJnM9VXVPd0NsWG9HQ3ZH UDJxa3NpVjNoODVIDQo+IE5nUVJvX1o3YjBIZ1UycVZ3elEmZT0NCj4gDQo+ICAgICA+ICAgICAg ICAgcz1Qcm9mZXNzaW9uYWwgTmV0d29ya2VkIE1lZGlhIFRlc3QNCj4gDQo+ICAgICA+ICAgICAg ICAgaT1BIHRlc3Qgb2Ygc3luY2hyb25pemVkIHZpZGVvIGFuZCBBTkMgZGF0YQ0KPiANCj4gICAg ID4gICAgICAgICB0PTAgMA0KPiANCj4gICAgID4gICAgICAgICBtPXZpZGVvIDUwMDAwIFJUUC9B VlAgOTYNCj4gDQo+ICAgICA+ICAgICAgICAgYz1JTiBJUDQgaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtDQo+IDNBX18yMzMuMjUyLjAuMV8yNTUmZD1Ed0lH YVEmYz11dzZUTHU0aHdoSGRpR0pPZ3djV0Q0QWpLUXg2enYNCj4gRmNHRXNiZmlZOS0NCj4gRUkm cj1sZWtOT09NNW5vVjYxenJQSDNyd1B5aHRObkxMV29MRUhnZDBxdVF4bHk4Jm09bW10eUxYdHlh DQo+IFdIRWczSlljcTN4U1ZMWHpScWtJVmdXQUpEZ3F5SWdyZVUmcz1tRGpjY2RGUjhNV25mUWNQ X3hpTWhiLQ0KPiBiaC1XZWZfMnRLaFJEeVJpbFlVTSZlPQ0KPiANCj4gICAgID4gICAgICAgICBh PXJ0cG1hcDo5NiByYXcvOTAwMDANCj4gDQo+ICAgICA+ICAgICAgICAgYT1mbXRwOjk2IHNhbXBs aW5nPVlDYkNyLTQ6MjoyOyB3aWR0aD0xMjgwOyBoZWlnaHQ9NzIwOyBkZXB0aD0xMA0KPiANCj4g ICAgID4gICAgICAgICBtPXZpZGVvIDUwMDEwIFJUUC9BVlAgOTcNCj4gDQo+ICAgICA+ICAgICAg ICAgYz1JTiBJUDQgaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHAtDQo+IDNBX18yMzMuMjUyLjAuMl8yNTUmZD1Ed0lHYVEmYz11dzZUTHU0aHdoSGRpR0pPZ3dj V0Q0QWpLUXg2enYNCj4gRmNHRXNiZmlZOS0NCj4gRUkmcj1sZWtOT09NNW5vVjYxenJQSDNyd1B5 aHRObkxMV29MRUhnZDBxdVF4bHk4Jm09bW10eUxYdHlhDQo+IFdIRWczSlljcTN4U1ZMWHpScWtJ VmdXQUpEZ3F5SWdyZVUmcz03ZTY2ZXdRVkF1TDFZVXEyRnpBU3lFSnANCj4gcXc3VGM1cDhmTzhs WmJaNHRVbyZlPQ0KPiANCj4gICAgID4gICAgICAgICBhPXJ0cG1hcDo5NyBzbXB0ZTI5MS85MDAw MA0KPiANCj4gICAgID4gICAgICAgICBhPWZtdHA6OTcgRElEX1NESUQ9ezB4NjEsMHgwMn07RElE X1NESUQ9ezB4NDEsMHgwNX0NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiBCdXQgSeKAmW0gc3Rp bGwgbW9yZSBjb21mb3J0YWJsZSB3aXRoIGtlZXBpbmcgdGhlIOKAnExT4oCdIGdyb3VwaW5nIGlu IHRoZQ0KPiBleGFtcGxlDQo+IA0KPiAgICAgPiB1bmxlc3MgdGhlcmUgYXJlIG9iamVjdGlvbnMu DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gVGhpcyBicmluZ3MgdXMgdG8gdGhlIG1haW4gcG9p bnQgb2YgQWRhbSBSb2FjaOKAmXMgRElTQ1VTUyBpdGVtLCBob3cgZG8NCj4geW91DQo+IA0KPiAg ICAgPiBwcm92aWRlIG11bHRpLWxldmVsIGhpZXJhcmNoaWNhbCBncm91cGluZyBpbiBTRFAuICBJ bWFnaW5lIGEgZ3JvdXAgb2YgKGENCj4gZ3JvdXANCj4gDQo+ICAgICA+IG9mIHZpZGVvIGFuZCBh bmNpbGxhcnkgZGF0YSkgYW5kIChhIGdyb3VwIG9mIHZpZGVvIGFuZCBhbmNpbGxhcnkgZGF0YSku DQo+IFRoZXJlDQo+IA0KPiAgICAgPiBhY3R1YWxseSBpcyBhIGNhc2Ugb2YgdGhpcyBpbiBwcm9k dWN0aW9uIHRlbGV2aXNpb24sIHRoZSBtdWx0aXZpZXdlciAoZS5nLiBzZWUNCj4gDQo+ICAgICA+ IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0NCj4gM0Ff X3d3dy5ibGFja21hZ2ljZGVzaWduLmNvbV9wcm9kdWN0c19tdWx0aXZpZXcmZD1Ed0lHYVEmYz11 dzZUDQo+IEx1NGh3aEhkaUdKT2d3Y1dENEFqS1F4Nnp2RmNHRXNiZmlZOS0NCj4gRUkmcj1sZWtO T09NNW5vVjYxenJQSDNyd1B5aHRObkxMV29MRUhnZDBxdVF4bHk4Jm09bW10eUxYdHlhDQo+IFdI RWczSlljcTN4U1ZMWHpScWtJVmdXQUpEZ3F5SWdyZVUmcz1JZEtvelNaV2JvaEswRmdfQ3ZaY21l Tk8NCj4gNkp4akdadndrbnJDUkxhUVZYOCZlPSkuDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4g VW5mb3J0dW5hdGVseSwgSSByZWFsbHkgY2Fu4oCZdCBmaW5kIGFueSBTRFAgbWVjaGFuaXNtIHRv IGRlc2NyaWJlIG11bHRpLQ0KPiBsZXZlbA0KPiANCj4gICAgID4gaGllcmFyY2h5LiAgUkZDIDQ3 OTYg4oCcVGhlIFNlc3Npb24gRGVzY3JpcHRpb24gUHJvdG9jb2wgKFNEUCkgQ29udGVudA0KPiAN Cj4gICAgID4gQXR0cmlidXRl4oCdIGlzIGFib3V0IHRoZSBiZXN0IEkgY2FuIGZpbmQsIHdoZXJl IHN5bmNocm9uaXplZCBtdWx0aW1lZGlhDQo+IChzdWNoDQo+IA0KPiAgICAgPiBhcyDigJxzbGlk ZXPigJ0sIOKAnHNwZWFrZXLigJ0sIOKAnG1haW7igJ0sIGV0Yy4pIGlzIHByZXNlbnRlZC4gIEJ1 dCB0aGlzIGlzIGEgdmVyeSBsaW1pdGVkDQo+IHNldA0KPiANCj4gICAgID4gb2YgdmFsdWVzLiAg UkZDIDU1ODMg4oCcU2lnbmFsaW5nIE1lZGlhIERlY29kaW5nIERlcGVuZGVuY3kgaW4gdGhlDQo+ IFNlc3Npb24NCj4gDQo+ICAgICA+IERlc2NyaXB0aW9uIFByb3RvY29sIChTRFAp4oCdIGhhcyB2 YXJpb3VzIGRlcGVuZGVuY2llcyBvZiBzdHJlYW1zLCBidXQNCj4gdGhpcyBpcw0KPiANCj4gICAg ID4gZm9yIGxheWVyZWQgb3IgbXVsdGlwbGUgZGVzY3JpcHRpdmUgbWVkaWEgY29kaW5nLiAgTmVp dGhlciBvZiB0aGVzZSBzZWVtcw0KPiANCj4gICAgID4gYXBwcm9wcmlhdGUuDQo+IA0KPiAgICAg Pg0KPiANCj4gICAgID4gUGVyaGFwcyB0aGlzIGlzc3VlIG5lZWRzIHRvIGJlIGJyb3VnaHQgdXAg aW4gTXVsdGlwYXJ0eSBNdWx0aW1lZGlhDQo+IFNlc3Npb24NCj4gDQo+ICAgICA+IENvbnRyb2wg KG1tdXNpYykgV0csIGJ1dCBJ4oCZbSBub3Qgc3VyZSB0aGF0IGl0IGlzIHdpc2UgdG8gaG9sZCB1 cCB0aGUgQU5DDQo+IFJUUA0KPiANCj4gICAgID4gUGF5bG9hZCBvdmVyIHRoaXMuDQo+IA0KPiAg ICAgPg0KPiANCj4gICAgID4gVGhhbmtzIGV2ZXJ5b25lIQ0KPiANCj4gICAgID4NCj4gDQo+ICAg ICA+IC1UaG9tYXMNCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAtLQ0KPiANCj4gICAgID4gVGhv bWFzIEVkd2FyZHMNCj4gDQo+ICAgICA+IEZPWCBOZXR3b3JrcyBFbmdpbmVlcmluZyAmIE9wZXJh dGlvbnMNCj4gDQo+ICAgICA+IFZQIEVuZ2luZWVyaW5nICYgRGV2ZWxvcG1lbnQNCj4gDQo+ICAg ICA+IHRob21hcy5lZHdhcmRzQGZveC5jb20NCj4gDQo+ICAgICA+ICsxLTMxMC0zNjktNjY5Ng0K PiANCj4gICAgID4gMTAyMDEgVyBQaWNvIEJsdmQNCj4gDQo+ICAgICA+IExvcyBBbmdlbGVzLCBD QSA5MDAzNQ0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAg ID4NCj4gDQo+IA0KPiANCj4gDQoNCg== From nobody Tue Oct 3 09:56:20 2017 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 99885132396; Tue, 3 Oct 2017 09:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxsoNoVtTFAN; Tue, 3 Oct 2017 09:56:12 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAFEB134F0D; Tue, 3 Oct 2017 09:56:12 -0700 (PDT) Received: from [82.132.217.62] (port=62317 helo=[172.20.10.3]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1dzQUL-0008NU-1x; Tue, 03 Oct 2017 17:56:09 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Colin Perkins In-Reply-To: Date: Tue, 3 Oct 2017 17:55:53 +0100 Cc: Thomas Edwards , The IESG , "payload-chairs@ietf.org" , "draft-ietf-payload-rtp-ancillary@ietf.org" , "payload@ietf.org" , "acbegen@gmail.com" Content-Transfer-Encoding: quoted-printable Message-Id: References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <3B259563-1075-4C41-A832-D7633C39173B@foxeg.com> <61440eb5-32c3-3696-be38-8dc7c4eaf72f@nostrum.com> <863974D7-E112-4794-AD4D-C39C99BD40C9@foxeg.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> To: Adam Roach X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 03 Oct 2017 16:56:15 -0000 > On 29 Sep 2017, at 22:00, Adam Roach wrote: > On 9/26/17 8:13 PM, Thomas Edwards wrote: >> Regarding draft-ietf-payload-rtp-ancillary-10, on further thought I = believe that FID grouping is NOT appropriate for Section 4.1 =E2=80=9CGrou= ping ANC Streams with other Media Streams=E2=80=9D. >>=20 >> RFC 5888 Section 8.4. (=E2=80=9CFID Semantics=E2=80=9D) states: >>=20 >> =E2=80=9CIt is assumed that the application uses only one = codec at a time to encode the media produced. This codec MAY change = dynamically during the session, but at any particular moment, only one = codec is in use.=E2=80=9D >>=20 >> RFC 5888 Section 8.5.1 states: >>=20 >> =E2=80=9CFID semantics are useful when the application only uses = one codec at a time. An application that encodes the same media using = different codecs simultaneously MUST NOT use FID to group those media = lines.=E2=80=9D >>=20 >> When we have one video stream and one ancillary data stream, senders = are not switching between codecs. FID really sounds to me like a = situation where you have one media stream, but senders could send that = stream one of multiple codecs, but not at the same time. >=20 > In this case, where you have data and meta-data, it's arguably two = different codecs; and, since they don't represent the same data, you're = encoding with one codec or the other, based on whether you're sending = video data or meta-data. =46rom that perspective, I don't see the use of = FID as being outside the spirit of what is intended. >=20 > That said, if the WG agrees with your evaluation that FID isn't quite = the right fit, I'm happy for y'all to come up with some alternate = solution... I tend to agree with Adam that FID is appropriate to group the ancillary = data with its associated media stream. The metadata in the ancillary = stream is conceptually part of the media stream, which matches the = definition of FID. They MUST be sent with the same CNAME, to ensure they = can be synchronised, but that doesn=E2=80=99t require any explicit = signalling. You can use LS signalling in addition to FID if two streams, with their = associated ancillary streams, need to be synchronised.=20 --=20 Colin Perkins https://csperkins.org/ From nobody Tue Oct 3 09:59:53 2017 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 B91C91346A6; Tue, 3 Oct 2017 09:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ko602Xbb8VWK; Tue, 3 Oct 2017 09:59:44 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36C7E132396; Tue, 3 Oct 2017 09:59:44 -0700 (PDT) Received: from [82.132.217.62] (port=63090 helo=[172.20.10.3]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1dzQXe-0000KU-6U; Tue, 03 Oct 2017 17:59:36 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Colin Perkins In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD810751@DGGEMM506-MBX.china.huawei.com> Date: Tue, 3 Oct 2017 17:59:20 +0100 Cc: Thomas Edwards , Adam Roach , "payload-chairs@ietf.org" , "draft-ietf-payload-rtp-ancillary@ietf.org" , "payload@ietf.org" , "acbegen@gmail.com" Content-Transfer-Encoding: quoted-printable Message-Id: <4D3BF24A-2927-4F9A-A435-7DA6A9F777D7@csperkins.org> References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <3B259563-1075-4C41-A832-D7633C39173B@foxeg.com> <61440eb5-32c3-3696-be38-8dc7c4eaf72f@nostrum.com> <863974D7-E112-4794-AD4D-C39C99BD40C9@foxeg.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> <6E58094ECC8D8344914996DAD28F1CCD80FC21@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD810751@DGGEMM506-MBX.china.huawei.com> To: Roni Even X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 03 Oct 2017 16:59:52 -0000 Roni, The requirement for RTP, in general, is that streams that are to be = synchronised MUST have the same RTCP CNAME. It might be appropriate to = remind readers of that, but it=E2=80=99s independent on the grouping = framework.=20 How that CNAME is chosen doesn=E2=80=99t matter for the purposes of = synchronisation, provided the SSRCs that are to be synchronised use the = same CNAME. The suggestions in RFC 7022 are appropriate, but there=E2=80=99= s no reason to mandate them, or require a particular one of those = suggestions be used. Colin > On 1 Oct 2017, at 12:25, Roni Even wrote: >=20 > Hi Thomas, > I think that you should also have in the grouping section a = recommendation to use the same persistent CNAME (maybe short term?) for = the ANC and video stream see RFC 7022 this is required in RTCP if these = RTP streams need to be synchronized (RFC3550) > Roni >=20 >=20 >> -----Original Message----- >> From: Thomas Edwards [mailto:Thomas.Edwards@fox.com] >> Sent: =D7=99=D7=95=D7=9D =D7=93 27 =D7=A1=D7=A4=D7=98=D7=9E=D7=91=D7=A8= 2017 18:47 >> To: Roni Even; Adam Roach; The IESG >> Cc: payload-chairs@ietf.org; = draft-ietf-payload-rtp-ancillary@ietf.org; >> payload@ietf.org; acbegen@gmail.com >> Subject: Re: Adam Roach's Discuss on = draft-ietf-payload-rtp-ancillary-10: >> (with DISCUSS and COMMENT) >>=20 >> Roni, thanks for the feedback on LS! >>=20 >> I=E2=80=99m still not sure if it is appropriate to include the = hierarchical grouping SDP >> example in draft-ietf-payload-rtp-ancillary. I suspect it could be = confusing. >>=20 >> However, I will note that the Alliance for IP Media Solutions >> (http://aimsalliance.org) Technical Committee is considering work on >> documenting different SDP groupings for live television production = scenarios, >> so it is possible that a future I-D will be submitted that could = include a range >> of SDP applications in this area, perhaps including documentation of = Adam >> Roach=E2=80=99s scenario. >>=20 >> I can go ahead and upload a draft-ietf-payload-rtp-ancillary-11 based = on the >> IESG feedback. >>=20 >> -Thomas >>=20 >> -- >> Thomas Edwards >> FOX Networks Engineering & Operations >> VP Engineering & Development >> thomas.edwards@fox.com >> +1-310-369-6696 >> 10201 W Pico Blvd >> Los Angeles, CA 90035 >>=20 >>=20 >> On 9/27/17, 4:07 AM, "Roni Even" wrote: >>=20 >> Hi, >>=20 >> I agree that LS is better fit for ANC >>=20 >>=20 >>=20 >> As for Adam's example it is allowed by RFC5888 to specify >>=20 >> a=3Dgroup:LS V1 V2 M1 M2 >>=20 >> a=3Dgroup:LS V1 M1 >>=20 >> a=3Dgroup:LS V2 M2 >>=20 >> this is similar to RFC5956 which replaced RFC4756 >>=20 >>=20 >>=20 >> this is not a clean way but is allowed otherwise there is a need = to specify >> some SDP attribute for specifying dependencies. >>=20 >>=20 >>=20 >> Roni Even >>=20 >>=20 >>=20 >>=20 >>=20 >>> -----Original Message----- >>=20 >>> From: Thomas Edwards [mailto:Thomas.Edwards@fox.com] >>=20 >>> Sent: =D7=99=D7=95=D7=9D =D7=93 27 =D7=A1=D7=A4=D7=98=D7=9E=D7=91=D7=A8= 2017 04:13 >>=20 >>> To: Adam Roach; The IESG >>=20 >>> Cc: payload-chairs@ietf.org; = draft-ietf-payload-rtp-ancillary@ietf.org; >>=20 >>> payload@ietf.org; acbegen@gmail.com >>=20 >>> Subject: Re: Adam Roach's Discuss on = draft-ietf-payload-rtp-ancillary-10: >>=20 >>> (with DISCUSS and COMMENT) >>=20 >>>=20 >>=20 >>> Regarding draft-ietf-payload-rtp-ancillary-10, on further thought I = believe >>=20 >>> that FID grouping is NOT appropriate for Section 4.1 =E2=80=9CGrouping= ANC >> Streams >>=20 >>> with other Media Streams=E2=80=9D. >>=20 >>>=20 >>=20 >>> RFC 5888 Section 8.4. (=E2=80=9CFID Semantics=E2=80=9D) states: >>=20 >>>=20 >>=20 >>> =E2=80=9CIt is assumed that the application uses only one = codec at a time to >>=20 >>> encode the media produced. This codec MAY change dynamically during >> the >>=20 >>> session, but at any particular moment, only one codec is in use.=E2=80= =9D >>=20 >>>=20 >>=20 >>> RFC 5888 Section 8.5.1 states: >>=20 >>>=20 >>=20 >>> =E2=80=9CFID semantics are useful when the application only uses = one codec >>=20 >>> at a time. An application that encodes the same media using = different >>=20 >>> codecs simultaneously MUST NOT use FID to group those media = lines.=E2=80=9D >>=20 >>>=20 >>=20 >>> When we have one video stream and one ancillary data stream, senders >> are >>=20 >>> not switching between codecs. FID really sounds to me like a = situation >> where >>=20 >>> you have one media stream, but senders could send that stream one of >>=20 >>> multiple codecs, but not at the same time. >>=20 >>>=20 >>=20 >>> Compare with RFC 5888 Section 7: >>=20 >>>=20 >>=20 >>> =E2=80=9CNote that LS semantics apply not only to a video stream = that has to >>=20 >>> be synchronized with an audio stream; the playout of two streams of = the >>=20 >>> same type can be synchronized as well.=E2=80=9D >>=20 >>>=20 >>=20 >>> Synchronized presentation to the user of an audio, video, and of = course >>=20 >>> ancillary data flow is generally what we need for production = television >>=20 >>> workflows. >>=20 >>>=20 >>=20 >>> draft-ietf-payload-rtp-ancillary-10 Section 4.1 has the example: >>=20 >>>=20 >>=20 >>> v=3D0 >>=20 >>> o=3DAl 123456 11 IN IP4 >> https://urldefense.proofpoint.com/v2/url?u=3Dhttp- >> 3A__host.example.com&d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx >> 6zvFcGEsbfiY9- >> EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DmmtyLXtya >> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=3DUuOwClXoGCvGP2qksiV3h85H >> NgQRo_Z7b0HgU2qVwzQ&e=3D >>=20 >>> s=3DProfessional Networked Media Test >>=20 >>> i=3DA test of synchronized video and ANC data >>=20 >>> t=3D0 0 >>=20 >>> a=3Dgroup:LS V1 M1 >>=20 >>> m=3Dvideo 50000 RTP/AVP 96 >>=20 >>> c=3DIN IP4 https://urldefense.proofpoint.com/v2/url?u=3Dhttp- >> 3A__233.252.0.1_255&d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zv >> FcGEsbfiY9- >> EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DmmtyLXtya >> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=3DmDjccdFR8MWnfQcP_xiMhb- >> bh-Wef_2tKhRDyRilYUM&e=3D >>=20 >>> a=3Drtpmap:96 raw/90000 >>=20 >>> a=3Dfmtp:96 sampling=3DYCbCr-4:2:2; width=3D1280; height=3D720;= depth=3D10 >>=20 >>> a=3Dmid:V1 >>=20 >>> m=3Dvideo 50010 RTP/AVP 97 >>=20 >>> c=3DIN IP4 https://urldefense.proofpoint.com/v2/url?u=3Dhttp- >> 3A__233.252.0.2_255&d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zv >> FcGEsbfiY9- >> EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DmmtyLXtya >> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=3D7e66ewQVAuL1YUq2FzASyEJp >> qw7Tc5p8fO8lZbZ4tUo&e=3D >>=20 >>> a=3Drtpmap:97 smpte291/90000 >>=20 >>> a=3Dfmtp:97 DID_SDID=3D{0x61,0x02};DID_SDID=3D{0x41,0x05} >>=20 >>> a=3Dmid:M1 >>=20 >>>=20 >>=20 >>> As some have pointed out, RTP timestamps and RTCP provide inherent >>=20 >>> synchronization between =E2=80=9Cm=E2=80=9D lines, but of course as = RFC 5888 Section 1 >> says >>=20 >>> without grouping: =E2=80=9CWhen a session description contains more = than one >> "m" >>=20 >>> line, SDP does not provide any means to express a particular = relationship >>=20 >>> between two or more of them.=E2=80=9D =E2=80=9CLS=E2=80=9D grouping = makes it pretty clear that >>=20 >>> these streams are intended for synchronized presentation. >>=20 >>>=20 >>=20 >>> An alternative to =E2=80=9CLS=E2=80=9D grouping is to drop all = grouping in the example, and >> be >>=20 >>> unclear about what these =E2=80=9Cm=E2=80=9D lines are doing = together in the same file: >>=20 >>>=20 >>=20 >>> v=3D0 >>=20 >>> o=3DAl 123456 11 IN IP4 >> https://urldefense.proofpoint.com/v2/url?u=3Dhttp- >> 3A__host.example.com&d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx >> 6zvFcGEsbfiY9- >> EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DmmtyLXtya >> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=3DUuOwClXoGCvGP2qksiV3h85H >> NgQRo_Z7b0HgU2qVwzQ&e=3D >>=20 >>> s=3DProfessional Networked Media Test >>=20 >>> i=3DA test of synchronized video and ANC data >>=20 >>> t=3D0 0 >>=20 >>> m=3Dvideo 50000 RTP/AVP 96 >>=20 >>> c=3DIN IP4 https://urldefense.proofpoint.com/v2/url?u=3Dhttp- >> 3A__233.252.0.1_255&d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zv >> FcGEsbfiY9- >> EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DmmtyLXtya >> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=3DmDjccdFR8MWnfQcP_xiMhb- >> bh-Wef_2tKhRDyRilYUM&e=3D >>=20 >>> a=3Drtpmap:96 raw/90000 >>=20 >>> a=3Dfmtp:96 sampling=3DYCbCr-4:2:2; width=3D1280; height=3D720;= depth=3D10 >>=20 >>> m=3Dvideo 50010 RTP/AVP 97 >>=20 >>> c=3DIN IP4 https://urldefense.proofpoint.com/v2/url?u=3Dhttp- >> 3A__233.252.0.2_255&d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zv >> FcGEsbfiY9- >> EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DmmtyLXtya >> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=3D7e66ewQVAuL1YUq2FzASyEJp >> qw7Tc5p8fO8lZbZ4tUo&e=3D >>=20 >>> a=3Drtpmap:97 smpte291/90000 >>=20 >>> a=3Dfmtp:97 DID_SDID=3D{0x61,0x02};DID_SDID=3D{0x41,0x05} >>=20 >>>=20 >>=20 >>> But I=E2=80=99m still more comfortable with keeping the =E2=80=9CLS=E2= =80=9D grouping in the >> example >>=20 >>> unless there are objections. >>=20 >>>=20 >>=20 >>> This brings us to the main point of Adam Roach=E2=80=99s DISCUSS = item, how do >> you >>=20 >>> provide multi-level hierarchical grouping in SDP. Imagine a group = of (a >> group >>=20 >>> of video and ancillary data) and (a group of video and ancillary = data). >> There >>=20 >>> actually is a case of this in production television, the multiviewer = (e.g. see >>=20 >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.blackmagicdesign.com_products_multiview&d=3DDwIGaQ&c=3Duw6T >> Lu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9- >> EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DmmtyLXtya >> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=3DIdKozSZWbohK0Fg_CvZcmeNO >> 6JxjGZvwknrCRLaQVX8&e=3D). >>=20 >>>=20 >>=20 >>> Unfortunately, I really can=E2=80=99t find any SDP mechanism to = describe multi- >> level >>=20 >>> hierarchy. RFC 4796 =E2=80=9CThe Session Description Protocol (SDP) = Content >>=20 >>> Attribute=E2=80=9D is about the best I can find, where synchronized = multimedia >> (such >>=20 >>> as =E2=80=9Cslides=E2=80=9D, =E2=80=9Cspeaker=E2=80=9D, =E2=80=9Cmain=E2= =80=9D, etc.) is presented. But this is a very limited >> set >>=20 >>> of values. RFC 5583 =E2=80=9CSignaling Media Decoding Dependency in = the >> Session >>=20 >>> Description Protocol (SDP)=E2=80=9D has various dependencies of = streams, but >> this is >>=20 >>> for layered or multiple descriptive media coding. Neither of these = seems >>=20 >>> appropriate. >>=20 >>>=20 >>=20 >>> Perhaps this issue needs to be brought up in Multiparty Multimedia >> Session >>=20 >>> Control (mmusic) WG, but I=E2=80=99m not sure that it is wise to = hold up the ANC >> RTP >>=20 >>> Payload over this. >>=20 >>>=20 >>=20 >>> Thanks everyone! >>=20 >>>=20 >>=20 >>> -Thomas >>=20 >>>=20 >>=20 >>> -- >>=20 >>> Thomas Edwards >>=20 >>> FOX Networks Engineering & Operations >>=20 >>> VP Engineering & Development >>=20 >>> thomas.edwards@fox.com >>=20 >>> +1-310-369-6696 >>=20 >>> 10201 W Pico Blvd >>=20 >>> Los Angeles, CA 90035 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload --=20 Colin Perkins https://csperkins.org/ From nobody Tue Oct 3 10:53:58 2017 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 46FBD134FBA; Tue, 3 Oct 2017 10:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qspwKeDxpGYx; Tue, 3 Oct 2017 10:53:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EFE7134FBD; Tue, 3 Oct 2017 10:53:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DWT91057; Tue, 03 Oct 2017 17:53:48 +0000 (GMT) Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 3 Oct 2017 18:53:47 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.187]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0301.000; Wed, 4 Oct 2017 01:53:41 +0800 From: Roni Even To: Colin Perkins , Adam Roach CC: Thomas Edwards , The IESG , "payload-chairs@ietf.org" , "draft-ietf-payload-rtp-ancillary@ietf.org" , "payload@ietf.org" , "acbegen@gmail.com" Thread-Topic: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) Thread-Index: AQHTPGiKFmmTu6cjqEycsxsfqqlcLKLSZbaQ Date: Tue, 3 Oct 2017 17:53:40 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD810BB8@DGGEMM506-MBX.china.huawei.com> References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <3B259563-1075-4C41-A832-D7633C39173B@foxeg.com> <61440eb5-32c3-3696-be38-8dc7c4eaf72f@nostrum.com> <863974D7-E112-4794-AD4D-C39C99BD40C9@foxeg.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.145.77] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.59D3CEAC.0408, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.187, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d30f9eee019546dd46b8f9aefb3bfca2 Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 03 Oct 2017 17:53:54 -0000 SGkgQ29saW4sDQpJIHRoaW5rIHRoYXQgdGhlIHF1ZXN0aW9uIGlzIGlmIHRoZSB2aWRlbyBhbmQg YW5jIGFyZSBkZWNvZGVkIGF0IHRoZSBzYW1lIHRpbWUuIEluIFJGQyA1ODg4IHRoZSBjYXNlIHdo ZW4gRFRNRiBpcyBib3RoIGluIHRoZSBhdWRpbyBhbmQgYXMgRFRNRiB0b25lcyAoc2VjdGlvbiA4 LjUuMSApIEZJRCBjYW5ub3QgYmUgdXNlZCBvbmx5IGlmIGF1ZGlvIGlzIG11dGVkIHdoZW4gRFRN RiB0b25lcyBhcmUgc2VudC4NClNvIHRoZSBxdWVzdGlvbiBpcyBpZiB2aWRlbyBpcyBtdXRlZCB3 aGVuIEFOQyBpcyBzZW50IChvbmx5IG9uZSBkZWNvZGUgYXQgYSBzcGVjaWZpYyB0aW1lKS4gSSB0 aGluayB0aGF0IGluIHRlcm0gb2YgdGltZSB0aGV5IGFyZSBib3RoIHBhcnQgb2YgdGhlIHNhbWUg dmlkZW8gZnJhbWUgc28gdGhleSBoYXZlIHRoZSBzYW1lIHRpbWUgc28gSSBhbSBub3Qgc3VyZSBp ZiBGSUQgY2FuIGJlIHVzZWQuIE1heWJlIFRob21hcyBjYW4gcHJvdmlkZSBpcyB2aWV3IGhlcmUg aWYgdGhleSBhcmUgZGVjb2RlYyBpbiBwYXJhbGxlbCBvciBvbmUgYWZ0ZXIgdGhlIG90aGVyPw0K QW5kIHllcyB0aGV5IE1VU1QgaGF2ZSB0aGUgc2FtZSBDTkFNRSByZWdhcmRsZXNzIG9mIHRoZSBn cm91cGluZyBzcGVjaWZpZWQNClJvbmkNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IENvbGluIFBlcmtpbnMgW21haWx0bzpjc3BAY3NwZXJraW5zLm9yZ10NCj4gU2Vu dDog15nXldedwqDXkiAwMyDXkNeV16fXmNeV15HXqCAyMDE3IDE5OjU2DQo+IFRvOiBBZGFtIFJv YWNoDQo+IENjOiBUaG9tYXMgRWR3YXJkczsgVGhlIElFU0c7IHBheWxvYWQtY2hhaXJzQGlldGYu b3JnOyBkcmFmdC1pZXRmLXBheWxvYWQtDQo+IHJ0cC1hbmNpbGxhcnlAaWV0Zi5vcmc7IHBheWxv YWRAaWV0Zi5vcmc7IGFjYmVnZW5AZ21haWwuY29tDQo+IFN1YmplY3Q6IFJlOiBbcGF5bG9hZF0g QWRhbSBSb2FjaCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC0NCj4gYW5jaWxs YXJ5LTEwOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiANCj4gPiBPbiAyOSBTZXAgMjAx NywgYXQgMjI6MDAsIEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb20+IHdyb3RlOg0KPiA+IE9u IDkvMjYvMTcgODoxMyBQTSwgVGhvbWFzIEVkd2FyZHMgd3JvdGU6DQo+ID4+IFJlZ2FyZGluZyBk cmFmdC1pZXRmLXBheWxvYWQtcnRwLWFuY2lsbGFyeS0xMCwgb24gZnVydGhlciB0aG91Z2h0IEkg YmVsaWV2ZQ0KPiB0aGF0IEZJRCBncm91cGluZyBpcyBOT1QgYXBwcm9wcmlhdGUgZm9yIFNlY3Rp b24gNC4xIOKAnEdyb3VwaW5nIEFOQyBTdHJlYW1zDQo+IHdpdGggb3RoZXIgTWVkaWEgU3RyZWFt c+KAnS4NCj4gPj4NCj4gPj4gUkZDIDU4ODggU2VjdGlvbiA4LjQuICjigJxGSUQgU2VtYW50aWNz 4oCdKSBzdGF0ZXM6DQo+ID4+DQo+ID4+ICAgICAgICDigJxJdCBpcyBhc3N1bWVkIHRoYXQgdGhl IGFwcGxpY2F0aW9uIHVzZXMgb25seSBvbmUgY29kZWMgYXQgYSB0aW1lIHRvDQo+IGVuY29kZSB0 aGUgbWVkaWEgcHJvZHVjZWQuICBUaGlzIGNvZGVjIE1BWSBjaGFuZ2UgZHluYW1pY2FsbHkgZHVy aW5nIHRoZQ0KPiBzZXNzaW9uLCBidXQgYXQgYW55IHBhcnRpY3VsYXIgbW9tZW50LCBvbmx5IG9u ZSBjb2RlYyBpcyBpbiB1c2Uu4oCdDQo+ID4+DQo+ID4+IFJGQyA1ODg4IFNlY3Rpb24gOC41LjEg c3RhdGVzOg0KPiA+Pg0KPiA+PiAJ4oCcRklEIHNlbWFudGljcyBhcmUgdXNlZnVsIHdoZW4gdGhl IGFwcGxpY2F0aW9uIG9ubHkgdXNlcyBvbmUgY29kZWMNCj4gYXQgYSB0aW1lLiAgQW4gYXBwbGlj YXRpb24gdGhhdCBlbmNvZGVzIHRoZSBzYW1lIG1lZGlhIHVzaW5nIGRpZmZlcmVudA0KPiBjb2Rl Y3Mgc2ltdWx0YW5lb3VzbHkgTVVTVCBOT1QgdXNlIEZJRCB0byBncm91cCB0aG9zZSBtZWRpYSBs aW5lcy7igJ0NCj4gPj4NCj4gPj4gV2hlbiB3ZSBoYXZlIG9uZSB2aWRlbyBzdHJlYW0gYW5kIG9u ZSBhbmNpbGxhcnkgZGF0YSBzdHJlYW0sIHNlbmRlcnMNCj4gYXJlIG5vdCBzd2l0Y2hpbmcgYmV0 d2VlbiBjb2RlY3MuICBGSUQgcmVhbGx5IHNvdW5kcyB0byBtZSBsaWtlIGEgc2l0dWF0aW9uDQo+ IHdoZXJlIHlvdSBoYXZlIG9uZSBtZWRpYSBzdHJlYW0sIGJ1dCBzZW5kZXJzIGNvdWxkIHNlbmQg dGhhdCBzdHJlYW0gb25lDQo+IG9mIG11bHRpcGxlIGNvZGVjcywgYnV0IG5vdCBhdCB0aGUgc2Ft ZSB0aW1lLg0KPiA+DQo+ID4gSW4gdGhpcyBjYXNlLCB3aGVyZSB5b3UgaGF2ZSBkYXRhIGFuZCBt ZXRhLWRhdGEsIGl0J3MgYXJndWFibHkgdHdvDQo+IGRpZmZlcmVudCBjb2RlY3M7IGFuZCwgc2lu Y2UgdGhleSBkb24ndCByZXByZXNlbnQgdGhlIHNhbWUgZGF0YSwgeW91J3JlDQo+IGVuY29kaW5n IHdpdGggb25lIGNvZGVjIG9yIHRoZSBvdGhlciwgYmFzZWQgb24gd2hldGhlciB5b3UncmUgc2Vu ZGluZw0KPiB2aWRlbyBkYXRhIG9yIG1ldGEtZGF0YS4gRnJvbSB0aGF0IHBlcnNwZWN0aXZlLCBJ IGRvbid0IHNlZSB0aGUgdXNlIG9mIEZJRCBhcw0KPiBiZWluZyBvdXRzaWRlIHRoZSBzcGlyaXQg b2Ygd2hhdCBpcyBpbnRlbmRlZC4NCj4gPg0KPiA+IFRoYXQgc2FpZCwgaWYgdGhlIFdHIGFncmVl cyB3aXRoIHlvdXIgZXZhbHVhdGlvbiB0aGF0IEZJRCBpc24ndCBxdWl0ZSB0aGUNCj4gcmlnaHQg Zml0LCBJJ20gaGFwcHkgZm9yIHknYWxsIHRvIGNvbWUgdXAgd2l0aCBzb21lIGFsdGVybmF0ZSBz b2x1dGlvbi4uLg0KPiANCj4gSSB0ZW5kIHRvIGFncmVlIHdpdGggQWRhbSB0aGF0IEZJRCBpcyBh cHByb3ByaWF0ZSB0byBncm91cCB0aGUgYW5jaWxsYXJ5IGRhdGENCj4gd2l0aCBpdHMgYXNzb2Np YXRlZCBtZWRpYSBzdHJlYW0uIFRoZSBtZXRhZGF0YSBpbiB0aGUgYW5jaWxsYXJ5IHN0cmVhbSBp cw0KPiBjb25jZXB0dWFsbHkgcGFydCBvZiB0aGUgbWVkaWEgc3RyZWFtLCB3aGljaCBtYXRjaGVz IHRoZSBkZWZpbml0aW9uIG9mIEZJRC4NCj4gVGhleSBNVVNUIGJlIHNlbnQgd2l0aCB0aGUgc2Ft ZSBDTkFNRSwgdG8gZW5zdXJlIHRoZXkgY2FuIGJlDQo+IHN5bmNocm9uaXNlZCwgYnV0IHRoYXQg ZG9lc27igJl0IHJlcXVpcmUgYW55IGV4cGxpY2l0IHNpZ25hbGxpbmcuDQo+IA0KPiBZb3UgY2Fu IHVzZSBMUyBzaWduYWxsaW5nIGluIGFkZGl0aW9uIHRvIEZJRCBpZiB0d28gc3RyZWFtcywgd2l0 aCB0aGVpcg0KPiBhc3NvY2lhdGVkIGFuY2lsbGFyeSBzdHJlYW1zLCBuZWVkIHRvIGJlIHN5bmNo cm9uaXNlZC4NCj4gDQo+IC0tDQo+IENvbGluIFBlcmtpbnMNCj4gaHR0cHM6Ly9jc3BlcmtpbnMu b3JnLw0KPiANCj4gDQo+IA0KDQo= From nobody Tue Oct 3 11:01:10 2017 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 3F53C134F0C; Tue, 3 Oct 2017 11:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNqU5QGpJ_jS; Tue, 3 Oct 2017 11:01:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A5E713293A; Tue, 3 Oct 2017 11:01:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPV56077; Tue, 03 Oct 2017 18:01:01 +0000 (GMT) Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 3 Oct 2017 19:01:00 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.187]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0301.000; Wed, 4 Oct 2017 02:00:54 +0800 From: Roni Even To: Colin Perkins CC: Thomas Edwards , Adam Roach , "payload-chairs@ietf.org" , "draft-ietf-payload-rtp-ancillary@ietf.org" , "payload@ietf.org" , "acbegen@gmail.com" Thread-Topic: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) Thread-Index: AQHTPGj0FmmTu6cjqEycsxsfqqlcLKLSaffA Date: Tue, 3 Oct 2017 18:00:52 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD810BCC@DGGEMM506-MBX.china.huawei.com> References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <3B259563-1075-4C41-A832-D7633C39173B@foxeg.com> <61440eb5-32c3-3696-be38-8dc7c4eaf72f@nostrum.com> <863974D7-E112-4794-AD4D-C39C99BD40C9@foxeg.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> <6E58094ECC8D8344914996DAD28F1CCD80FC21@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD810751@DGGEMM506-MBX.china.huawei.com> <4D3BF24A-2927-4F9A-A435-7DA6A9F777D7@csperkins.org> In-Reply-To: <4D3BF24A-2927-4F9A-A435-7DA6A9F777D7@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.145.77] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.59D3D05E.0036, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.187, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 76507c793da638ed63087e0afbd24878 Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 03 Oct 2017 18:01:08 -0000 SGkgQ29saW4sDQpTbyBtYXliZSB0aGUgcmlnaHQgZGlyZWN0aW9uIGlzIHRoYXQgdGhlcmUgaXMg bm8gbmVlZCBmb3IgZ3JvdXBpbmcgYXQgYWxsIGluIHRoaXMgY2FzZSBhbmQgIGp1c3QgdXNlIHRo ZSBzYW1lIENOQU1FIGluIFJUQ1AuDQpSb25pDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogQ29saW4gUGVya2lucyBbbWFpbHRvOmNzcEBjc3BlcmtpbnMub3JnXQ0KPiBT ZW50OiDXmdeV153CoNeSIDAzINeQ15XXp9eY15XXkdeoIDIwMTcgMTk6NTkNCj4gVG86IFJvbmkg RXZlbg0KPiBDYzogVGhvbWFzIEVkd2FyZHM7IEFkYW0gUm9hY2g7IHBheWxvYWQtY2hhaXJzQGll dGYub3JnOyBkcmFmdC1pZXRmLQ0KPiBwYXlsb2FkLXJ0cC1hbmNpbGxhcnlAaWV0Zi5vcmc7IHBh eWxvYWRAaWV0Zi5vcmc7IGFjYmVnZW5AZ21haWwuY29tDQo+IFN1YmplY3Q6IFJlOiBbcGF5bG9h ZF0gQWRhbSBSb2FjaCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC0NCj4gYW5j aWxsYXJ5LTEwOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiANCj4gUm9uaSwNCj4gDQo+ IFRoZSByZXF1aXJlbWVudCBmb3IgUlRQLCBpbiBnZW5lcmFsLCBpcyB0aGF0IHN0cmVhbXMgdGhh dCBhcmUgdG8gYmUNCj4gc3luY2hyb25pc2VkIE1VU1QgaGF2ZSB0aGUgc2FtZSBSVENQIENOQU1F LiBJdCBtaWdodCBiZSBhcHByb3ByaWF0ZSB0bw0KPiByZW1pbmQgcmVhZGVycyBvZiB0aGF0LCBi dXQgaXTigJlzIGluZGVwZW5kZW50IG9uIHRoZSBncm91cGluZyBmcmFtZXdvcmsuDQo+IA0KPiBI b3cgdGhhdCBDTkFNRSBpcyBjaG9zZW4gZG9lc27igJl0IG1hdHRlciBmb3IgdGhlIHB1cnBvc2Vz IG9mDQo+IHN5bmNocm9uaXNhdGlvbiwgcHJvdmlkZWQgdGhlIFNTUkNzIHRoYXQgYXJlIHRvIGJl IHN5bmNocm9uaXNlZCB1c2UgdGhlDQo+IHNhbWUgQ05BTUUuIFRoZSBzdWdnZXN0aW9ucyBpbiBS RkMgNzAyMiBhcmUgYXBwcm9wcmlhdGUsIGJ1dCB0aGVyZeKAmXMgbm8NCj4gcmVhc29uIHRvIG1h bmRhdGUgdGhlbSwgb3IgcmVxdWlyZSBhIHBhcnRpY3VsYXIgb25lIG9mIHRob3NlIHN1Z2dlc3Rp b25zIGJlDQo+IHVzZWQuDQo+IA0KPiBDb2xpbg0KPiANCj4gDQo+IA0KPiA+IE9uIDEgT2N0IDIw MTcsIGF0IDEyOjI1LCBSb25pIEV2ZW4gPHJvbmkuZXZlbkBodWF3ZWkuY29tPiB3cm90ZToNCj4g Pg0KPiA+IEhpIFRob21hcywNCj4gPiBJIHRoaW5rIHRoYXQgeW91IHNob3VsZCBhbHNvIGhhdmUg aW4gdGhlIGdyb3VwaW5nIHNlY3Rpb24gYQ0KPiA+IHJlY29tbWVuZGF0aW9uIHRvIHVzZSB0aGUg c2FtZSBwZXJzaXN0ZW50IENOQU1FIChtYXliZSBzaG9ydCB0ZXJtPykNCj4gPiBmb3IgdGhlIEFO QyBhbmQgdmlkZW8gc3RyZWFtIHNlZSBSRkMgNzAyMiB0aGlzIGlzIHJlcXVpcmVkIGluIFJUQ1Ag aWYNCj4gPiB0aGVzZSBSVFAgc3RyZWFtcyBuZWVkIHRvIGJlIHN5bmNocm9uaXplZCAoUkZDMzU1 MCkgUm9uaQ0KPiA+DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4g RnJvbTogVGhvbWFzIEVkd2FyZHMgW21haWx0bzpUaG9tYXMuRWR3YXJkc0Bmb3guY29tXQ0KPiA+ PiBTZW50OiDXmdeV150g15MgMjcg16HXpNeY157XkdeoIDIwMTcgMTg6NDcNCj4gPj4gVG86IFJv bmkgRXZlbjsgQWRhbSBSb2FjaDsgVGhlIElFU0cNCj4gPj4gQ2M6IHBheWxvYWQtY2hhaXJzQGll dGYub3JnOw0KPiA+PiBkcmFmdC1pZXRmLXBheWxvYWQtcnRwLWFuY2lsbGFyeUBpZXRmLm9yZzsN Cj4gPj4gcGF5bG9hZEBpZXRmLm9yZzsgYWNiZWdlbkBnbWFpbC5jb20NCj4gPj4gU3ViamVjdDog UmU6IEFkYW0gUm9hY2gncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtYW5jaWxs YXJ5LTEwOg0KPiA+PiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiA+Pg0KPiA+PiBSb25p LCB0aGFua3MgZm9yIHRoZSBmZWVkYmFjayBvbiBMUyENCj4gPj4NCj4gPj4gSeKAmW0gc3RpbGwg bm90IHN1cmUgaWYgaXQgaXMgYXBwcm9wcmlhdGUgdG8gaW5jbHVkZSB0aGUgaGllcmFyY2hpY2Fs DQo+ID4+IGdyb3VwaW5nIFNEUCBleGFtcGxlIGluIGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtYW5j aWxsYXJ5LiAgSSBzdXNwZWN0IGl0IGNvdWxkDQo+IGJlIGNvbmZ1c2luZy4NCj4gPj4NCj4gPj4g SG93ZXZlciwgSSB3aWxsIG5vdGUgdGhhdCB0aGUgQWxsaWFuY2UgZm9yIElQIE1lZGlhIFNvbHV0 aW9ucw0KPiA+PiAoaHR0cDovL2FpbXNhbGxpYW5jZS5vcmcpIFRlY2huaWNhbCBDb21taXR0ZWUg aXMgY29uc2lkZXJpbmcgd29yayBvbg0KPiA+PiBkb2N1bWVudGluZyBkaWZmZXJlbnQgU0RQIGdy b3VwaW5ncyBmb3IgbGl2ZSB0ZWxldmlzaW9uIHByb2R1Y3Rpb24NCj4gPj4gc2NlbmFyaW9zLCBz byBpdCBpcyBwb3NzaWJsZSB0aGF0IGEgZnV0dXJlIEktRCB3aWxsIGJlIHN1Ym1pdHRlZCB0aGF0 DQo+ID4+IGNvdWxkIGluY2x1ZGUgYSByYW5nZSBvZiBTRFAgYXBwbGljYXRpb25zIGluIHRoaXMg YXJlYSwgcGVyaGFwcw0KPiA+PiBpbmNsdWRpbmcgZG9jdW1lbnRhdGlvbiBvZiBBZGFtIFJvYWNo 4oCZcyBzY2VuYXJpby4NCj4gPj4NCj4gPj4gSSBjYW4gZ28gYWhlYWQgYW5kIHVwbG9hZCBhIGRy YWZ0LWlldGYtcGF5bG9hZC1ydHAtYW5jaWxsYXJ5LTExIGJhc2VkDQo+ID4+IG9uIHRoZSBJRVNH IGZlZWRiYWNrLg0KPiA+Pg0KPiA+PiAtVGhvbWFzDQo+ID4+DQo+ID4+IC0tDQo+ID4+IFRob21h cyBFZHdhcmRzDQo+ID4+IEZPWCBOZXR3b3JrcyBFbmdpbmVlcmluZyAmIE9wZXJhdGlvbnMgVlAg RW5naW5lZXJpbmcgJiBEZXZlbG9wbWVudA0KPiA+PiB0aG9tYXMuZWR3YXJkc0Bmb3guY29tDQo+ ID4+ICsxLTMxMC0zNjktNjY5Ng0KPiA+PiAxMDIwMSBXIFBpY28gQmx2ZA0KPiA+PiBMb3MgQW5n ZWxlcywgQ0EgOTAwMzUNCj4gPj4NCj4gPj4NCj4gPj4gT24gOS8yNy8xNywgNDowNyBBTSwgIlJv bmkgRXZlbiIgPHJvbmkuZXZlbkBodWF3ZWkuY29tPiB3cm90ZToNCj4gPj4NCj4gPj4gICAgSGks DQo+ID4+DQo+ID4+ICAgIEkgYWdyZWUgdGhhdCBMUyBpcyBiZXR0ZXIgZml0IGZvciBBTkMNCj4g Pj4NCj4gPj4NCj4gPj4NCj4gPj4gICAgQXMgZm9yIEFkYW0ncyBleGFtcGxlIGl0IGlzIGFsbG93 ZWQgYnkgUkZDNTg4OCB0byBzcGVjaWZ5DQo+ID4+DQo+ID4+ICAgICAgICAgICAgYT1ncm91cDpM UyBWMSBWMiBNMSBNMg0KPiA+Pg0KPiA+PiAgICAgICAgICAgIGE9Z3JvdXA6TFMgVjEgTTENCj4g Pj4NCj4gPj4gICAgICAgICAgICBhPWdyb3VwOkxTIFYyICBNMg0KPiA+Pg0KPiA+PiAgICB0aGlz IGlzIHNpbWlsYXIgdG8gUkZDNTk1NiAgd2hpY2ggcmVwbGFjZWQgUkZDNDc1Ng0KPiA+Pg0KPiA+ Pg0KPiA+Pg0KPiA+PiAgICB0aGlzIGlzIG5vdCBhIGNsZWFuIHdheSBidXQgIGlzIGFsbG93ZWQg b3RoZXJ3aXNlIHRoZXJlIGlzIGEgbmVlZA0KPiA+PiB0byBzcGVjaWZ5IHNvbWUgU0RQIGF0dHJp YnV0ZSBmb3Igc3BlY2lmeWluZyBkZXBlbmRlbmNpZXMuDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+ ICAgIFJvbmkgRXZlbg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4NCj4gPj4+IEZyb206IFRob21hcyBFZHdhcmRzIFtt YWlsdG86VGhvbWFzLkVkd2FyZHNAZm94LmNvbV0NCj4gPj4NCj4gPj4+IFNlbnQ6INeZ15XXnSDX kyAyNyDXodek15jXnteR16ggMjAxNyAwNDoxMw0KPiA+Pg0KPiA+Pj4gVG86IEFkYW0gUm9hY2g7 IFRoZSBJRVNHDQo+ID4+DQo+ID4+PiBDYzogcGF5bG9hZC1jaGFpcnNAaWV0Zi5vcmc7DQo+ID4+ PiBkcmFmdC1pZXRmLXBheWxvYWQtcnRwLWFuY2lsbGFyeUBpZXRmLm9yZzsNCj4gPj4NCj4gPj4+ IHBheWxvYWRAaWV0Zi5vcmc7IGFjYmVnZW5AZ21haWwuY29tDQo+ID4+DQo+ID4+PiBTdWJqZWN0 OiBSZTogQWRhbSBSb2FjaCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1hbmNp bGxhcnktMTA6DQo+ID4+DQo+ID4+PiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiA+Pg0K PiA+Pj4NCj4gPj4NCj4gPj4+IFJlZ2FyZGluZyBkcmFmdC1pZXRmLXBheWxvYWQtcnRwLWFuY2ls bGFyeS0xMCwgb24gZnVydGhlciB0aG91Z2h0IEkNCj4gPj4+IGJlbGlldmUNCj4gPj4NCj4gPj4+ IHRoYXQgRklEIGdyb3VwaW5nIGlzIE5PVCBhcHByb3ByaWF0ZSBmb3IgU2VjdGlvbiA0LjEg4oCc R3JvdXBpbmcgQU5DDQo+ID4+IFN0cmVhbXMNCj4gPj4NCj4gPj4+IHdpdGggb3RoZXIgTWVkaWEg U3RyZWFtc+KAnS4NCj4gPj4NCj4gPj4+DQo+ID4+DQo+ID4+PiBSRkMgNTg4OCBTZWN0aW9uIDgu NC4gKOKAnEZJRCBTZW1hbnRpY3PigJ0pIHN0YXRlczoNCj4gPj4NCj4gPj4+DQo+ID4+DQo+ID4+ PiAgICAgICDigJxJdCBpcyBhc3N1bWVkIHRoYXQgdGhlIGFwcGxpY2F0aW9uIHVzZXMgb25seSBv bmUgY29kZWMgYXQgYQ0KPiA+Pj4gdGltZSB0bw0KPiA+Pg0KPiA+Pj4gZW5jb2RlIHRoZSBtZWRp YSBwcm9kdWNlZC4gIFRoaXMgY29kZWMgTUFZIGNoYW5nZSBkeW5hbWljYWxseSBkdXJpbmcNCj4g Pj4gdGhlDQo+ID4+DQo+ID4+PiBzZXNzaW9uLCBidXQgYXQgYW55IHBhcnRpY3VsYXIgbW9tZW50 LCBvbmx5IG9uZSBjb2RlYyBpcyBpbiB1c2Uu4oCdDQo+ID4+DQo+ID4+Pg0KPiA+Pg0KPiA+Pj4g UkZDIDU4ODggU2VjdGlvbiA4LjUuMSBzdGF0ZXM6DQo+ID4+DQo+ID4+Pg0KPiA+Pg0KPiA+Pj4g CeKAnEZJRCBzZW1hbnRpY3MgYXJlIHVzZWZ1bCB3aGVuIHRoZSBhcHBsaWNhdGlvbiBvbmx5IHVz ZXMgb25lIGNvZGVjDQo+ID4+DQo+ID4+PiBhdCBhIHRpbWUuICBBbiBhcHBsaWNhdGlvbiB0aGF0 IGVuY29kZXMgdGhlIHNhbWUgbWVkaWEgdXNpbmcNCj4gPj4+IGRpZmZlcmVudA0KPiA+Pg0KPiA+ Pj4gY29kZWNzIHNpbXVsdGFuZW91c2x5IE1VU1QgTk9UIHVzZSBGSUQgdG8gZ3JvdXAgdGhvc2Ug bWVkaWEgbGluZXMu4oCdDQo+ID4+DQo+ID4+Pg0KPiA+Pg0KPiA+Pj4gV2hlbiB3ZSBoYXZlIG9u ZSB2aWRlbyBzdHJlYW0gYW5kIG9uZSBhbmNpbGxhcnkgZGF0YSBzdHJlYW0sIHNlbmRlcnMNCj4g Pj4gYXJlDQo+ID4+DQo+ID4+PiBub3Qgc3dpdGNoaW5nIGJldHdlZW4gY29kZWNzLiAgRklEIHJl YWxseSBzb3VuZHMgdG8gbWUgbGlrZSBhDQo+ID4+PiBzaXR1YXRpb24NCj4gPj4gd2hlcmUNCj4g Pj4NCj4gPj4+IHlvdSBoYXZlIG9uZSBtZWRpYSBzdHJlYW0sIGJ1dCBzZW5kZXJzIGNvdWxkIHNl bmQgdGhhdCBzdHJlYW0gb25lIG9mDQo+ID4+DQo+ID4+PiBtdWx0aXBsZSBjb2RlY3MsIGJ1dCBu b3QgYXQgdGhlIHNhbWUgdGltZS4NCj4gPj4NCj4gPj4+DQo+ID4+DQo+ID4+PiBDb21wYXJlIHdp dGggUkZDIDU4ODggU2VjdGlvbiA3Og0KPiA+Pg0KPiA+Pj4NCj4gPj4NCj4gPj4+IAnigJxOb3Rl IHRoYXQgTFMgc2VtYW50aWNzIGFwcGx5IG5vdCBvbmx5IHRvIGEgdmlkZW8gc3RyZWFtIHRoYXQg aGFzDQo+ID4+PiB0bw0KPiA+Pg0KPiA+Pj4gYmUgc3luY2hyb25pemVkIHdpdGggYW4gYXVkaW8g c3RyZWFtOyB0aGUgcGxheW91dCBvZiB0d28gc3RyZWFtcyBvZg0KPiA+Pj4gdGhlDQo+ID4+DQo+ ID4+PiBzYW1lIHR5cGUgY2FuIGJlIHN5bmNocm9uaXplZCBhcyB3ZWxsLuKAnQ0KPiA+Pg0KPiA+ Pj4NCj4gPj4NCj4gPj4+IFN5bmNocm9uaXplZCBwcmVzZW50YXRpb24gdG8gdGhlIHVzZXIgb2Yg YW4gYXVkaW8sIHZpZGVvLCBhbmQgb2YNCj4gPj4+IGNvdXJzZQ0KPiA+Pg0KPiA+Pj4gYW5jaWxs YXJ5IGRhdGEgZmxvdyBpcyBnZW5lcmFsbHkgd2hhdCB3ZSBuZWVkIGZvciBwcm9kdWN0aW9uDQo+ ID4+PiB0ZWxldmlzaW9uDQo+ID4+DQo+ID4+PiB3b3JrZmxvd3MuDQo+ID4+DQo+ID4+Pg0KPiA+ Pg0KPiA+Pj4gZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1hbmNpbGxhcnktMTAgU2VjdGlvbiA0LjEg aGFzIHRoZSBleGFtcGxlOg0KPiA+Pg0KPiA+Pj4NCj4gPj4NCj4gPj4+ICAgICAgICB2PTANCj4g Pj4NCj4gPj4+ICAgICAgICBvPUFsIDEyMzQ1NiAxMSBJTiBJUDQNCj4gPj4gaHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtDQo+ID4+DQo+IDNBX19ob3N0LmV4 YW1wbGUuY29tJmQ9RHdJR2FRJmM9dXc2VEx1NGh3aEhkaUdKT2d3Y1dENEFqS1F4DQo+ID4+IDZ6 dkZjR0VzYmZpWTktDQo+ID4+DQo+IEVJJnI9bGVrTk9PTTVub1Y2MXpyUEgzcndQeWh0Tm5MTFdv TEVIZ2QwcXVReGx5OCZtPW1tdHlMWHR5YQ0KPiA+Pg0KPiBXSEVnM0pZY3EzeFNWTFh6UnFrSVZn V0FKRGdxeUlncmVVJnM9VXVPd0NsWG9HQ3ZHUDJxa3NpVjNoODVIDQo+ID4+IE5nUVJvX1o3YjBI Z1UycVZ3elEmZT0NCj4gPj4NCj4gPj4+ICAgICAgICBzPVByb2Zlc3Npb25hbCBOZXR3b3JrZWQg TWVkaWEgVGVzdA0KPiA+Pg0KPiA+Pj4gICAgICAgIGk9QSB0ZXN0IG9mIHN5bmNocm9uaXplZCB2 aWRlbyBhbmQgQU5DIGRhdGENCj4gPj4NCj4gPj4+ICAgICAgICB0PTAgMA0KPiA+Pg0KPiA+Pj4g ICAgICAgIGE9Z3JvdXA6TFMgVjEgTTENCj4gPj4NCj4gPj4+ICAgICAgICBtPXZpZGVvIDUwMDAw IFJUUC9BVlAgOTYNCj4gPj4NCj4gPj4+ICAgICAgICBjPUlOIElQNCBodHRwczovL3VybGRlZmVu c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0NCj4gPj4NCj4gM0FfXzIzMy4yNTIuMC4x XzI1NSZkPUR3SUdhUSZjPXV3NlRMdTRod2hIZGlHSk9nd2NXRDRBaktReDZ6dg0KPiA+PiBGY0dF c2JmaVk5LQ0KPiA+Pg0KPiBFSSZyPWxla05PT001bm9WNjF6clBIM3J3UHlodE5uTExXb0xFSGdk MHF1UXhseTgmbT1tbXR5TFh0eWENCj4gPj4NCj4gV0hFZzNKWWNxM3hTVkxYelJxa0lWZ1dBSkRn cXlJZ3JlVSZzPW1EamNjZEZSOE1XbmZRY1BfeGlNaGItDQo+ID4+IGJoLVdlZl8ydEtoUkR5Umls WVVNJmU9DQo+ID4+DQo+ID4+PiAgICAgICAgYT1ydHBtYXA6OTYgcmF3LzkwMDAwDQo+ID4+DQo+ ID4+PiAgICAgICAgYT1mbXRwOjk2IHNhbXBsaW5nPVlDYkNyLTQ6MjoyOyB3aWR0aD0xMjgwOyBo ZWlnaHQ9NzIwOw0KPiA+Pj4gZGVwdGg9MTANCj4gPj4NCj4gPj4+ICAgICAgICBhPW1pZDpWMQ0K PiA+Pg0KPiA+Pj4gICAgICAgIG09dmlkZW8gNTAwMTAgUlRQL0FWUCA5Nw0KPiA+Pg0KPiA+Pj4g ICAgICAgIGM9SU4gSVA0IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwLQ0KPiA+Pg0KPiAzQV9fMjMzLjI1Mi4wLjJfMjU1JmQ9RHdJR2FRJmM9dXc2VEx1NGh3 aEhkaUdKT2d3Y1dENEFqS1F4Nnp2DQo+ID4+IEZjR0VzYmZpWTktDQo+ID4+DQo+IEVJJnI9bGVr Tk9PTTVub1Y2MXpyUEgzcndQeWh0Tm5MTFdvTEVIZ2QwcXVReGx5OCZtPW1tdHlMWHR5YQ0KPiA+ Pg0KPiBXSEVnM0pZY3EzeFNWTFh6UnFrSVZnV0FKRGdxeUlncmVVJnM9N2U2NmV3UVZBdUwxWVVx MkZ6QVN5RUpwDQo+ID4+IHF3N1RjNXA4Zk84bFpiWjR0VW8mZT0NCj4gPj4NCj4gPj4+ICAgICAg ICBhPXJ0cG1hcDo5NyBzbXB0ZTI5MS85MDAwMA0KPiA+Pg0KPiA+Pj4gICAgICAgIGE9Zm10cDo5 NyBESURfU0RJRD17MHg2MSwweDAyfTtESURfU0RJRD17MHg0MSwweDA1fQ0KPiA+Pg0KPiA+Pj4g ICAgICAgIGE9bWlkOk0xDQo+ID4+DQo+ID4+Pg0KPiA+Pg0KPiA+Pj4gQXMgc29tZSBoYXZlIHBv aW50ZWQgb3V0LCBSVFAgdGltZXN0YW1wcyBhbmQgUlRDUCBwcm92aWRlIGluaGVyZW50DQo+ID4+ DQo+ID4+PiBzeW5jaHJvbml6YXRpb24gYmV0d2VlbiDigJxt4oCdIGxpbmVzLCBidXQgb2YgY291 cnNlIGFzIFJGQyA1ODg4IFNlY3Rpb24NCj4gPj4+IDENCj4gPj4gc2F5cw0KPiA+Pg0KPiA+Pj4g d2l0aG91dCBncm91cGluZzog4oCcV2hlbiBhIHNlc3Npb24gZGVzY3JpcHRpb24gY29udGFpbnMg bW9yZSB0aGFuIG9uZQ0KPiA+PiAibSINCj4gPj4NCj4gPj4+IGxpbmUsIFNEUCBkb2VzIG5vdCBw cm92aWRlIGFueSBtZWFucyB0byBleHByZXNzIGEgcGFydGljdWxhcg0KPiA+Pj4gcmVsYXRpb25z aGlwDQo+ID4+DQo+ID4+PiBiZXR3ZWVuIHR3byBvciBtb3JlIG9mIHRoZW0u4oCdICDigJxMU+KA nSBncm91cGluZyBtYWtlcyBpdCBwcmV0dHkgY2xlYXINCj4gPj4+IHRoYXQNCj4gPj4NCj4gPj4+ IHRoZXNlIHN0cmVhbXMgYXJlIGludGVuZGVkIGZvciBzeW5jaHJvbml6ZWQgcHJlc2VudGF0aW9u Lg0KPiA+Pg0KPiA+Pj4NCj4gPj4NCj4gPj4+IEFuIGFsdGVybmF0aXZlIHRvIOKAnExT4oCdIGdy b3VwaW5nIGlzIHRvIGRyb3AgYWxsIGdyb3VwaW5nIGluIHRoZQ0KPiA+Pj4gZXhhbXBsZSwgYW5k DQo+ID4+IGJlDQo+ID4+DQo+ID4+PiB1bmNsZWFyIGFib3V0IHdoYXQgdGhlc2Ug4oCcbeKAnSBs aW5lcyBhcmUgZG9pbmcgdG9nZXRoZXIgaW4gdGhlIHNhbWUgZmlsZToNCj4gPj4NCj4gPj4+DQo+ ID4+DQo+ID4+PiAgICAgICAgdj0wDQo+ID4+DQo+ID4+PiAgICAgICAgbz1BbCAxMjM0NTYgMTEg SU4gSVA0DQo+ID4+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwLQ0KPiA+Pg0KPiAzQV9faG9zdC5leGFtcGxlLmNvbSZkPUR3SUdhUSZjPXV3NlRMdTRod2hI ZGlHSk9nd2NXRDRBaktReA0KPiA+PiA2enZGY0dFc2JmaVk5LQ0KPiA+Pg0KPiBFSSZyPWxla05P T001bm9WNjF6clBIM3J3UHlodE5uTExXb0xFSGdkMHF1UXhseTgmbT1tbXR5TFh0eWENCj4gPj4N Cj4gV0hFZzNKWWNxM3hTVkxYelJxa0lWZ1dBSkRncXlJZ3JlVSZzPVV1T3dDbFhvR0N2R1AycWtz aVYzaDg1SA0KPiA+PiBOZ1FSb19aN2IwSGdVMnFWd3pRJmU9DQo+ID4+DQo+ID4+PiAgICAgICAg cz1Qcm9mZXNzaW9uYWwgTmV0d29ya2VkIE1lZGlhIFRlc3QNCj4gPj4NCj4gPj4+ICAgICAgICBp PUEgdGVzdCBvZiBzeW5jaHJvbml6ZWQgdmlkZW8gYW5kIEFOQyBkYXRhDQo+ID4+DQo+ID4+PiAg ICAgICAgdD0wIDANCj4gPj4NCj4gPj4+ICAgICAgICBtPXZpZGVvIDUwMDAwIFJUUC9BVlAgOTYN Cj4gPj4NCj4gPj4+ICAgICAgICBjPUlOIElQNCBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cC0NCj4gPj4NCj4gM0FfXzIzMy4yNTIuMC4xXzI1NSZkPUR3SUdh USZjPXV3NlRMdTRod2hIZGlHSk9nd2NXRDRBaktReDZ6dg0KPiA+PiBGY0dFc2JmaVk5LQ0KPiA+ Pg0KPiBFSSZyPWxla05PT001bm9WNjF6clBIM3J3UHlodE5uTExXb0xFSGdkMHF1UXhseTgmbT1t bXR5TFh0eWENCj4gPj4NCj4gV0hFZzNKWWNxM3hTVkxYelJxa0lWZ1dBSkRncXlJZ3JlVSZzPW1E amNjZEZSOE1XbmZRY1BfeGlNaGItDQo+ID4+IGJoLVdlZl8ydEtoUkR5UmlsWVVNJmU9DQo+ID4+ DQo+ID4+PiAgICAgICAgYT1ydHBtYXA6OTYgcmF3LzkwMDAwDQo+ID4+DQo+ID4+PiAgICAgICAg YT1mbXRwOjk2IHNhbXBsaW5nPVlDYkNyLTQ6MjoyOyB3aWR0aD0xMjgwOyBoZWlnaHQ9NzIwOw0K PiA+Pj4gZGVwdGg9MTANCj4gPj4NCj4gPj4+ICAgICAgICBtPXZpZGVvIDUwMDEwIFJUUC9BVlAg OTcNCj4gPj4NCj4gPj4+ICAgICAgICBjPUlOIElQNCBodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cC0NCj4gPj4NCj4gM0FfXzIzMy4yNTIuMC4yXzI1NSZkPUR3 SUdhUSZjPXV3NlRMdTRod2hIZGlHSk9nd2NXRDRBaktReDZ6dg0KPiA+PiBGY0dFc2JmaVk5LQ0K PiA+Pg0KPiBFSSZyPWxla05PT001bm9WNjF6clBIM3J3UHlodE5uTExXb0xFSGdkMHF1UXhseTgm bT1tbXR5TFh0eWENCj4gPj4NCj4gV0hFZzNKWWNxM3hTVkxYelJxa0lWZ1dBSkRncXlJZ3JlVSZz PTdlNjZld1FWQXVMMVlVcTJGekFTeUVKcA0KPiA+PiBxdzdUYzVwOGZPOGxaYlo0dFVvJmU9DQo+ ID4+DQo+ID4+PiAgICAgICAgYT1ydHBtYXA6OTcgc21wdGUyOTEvOTAwMDANCj4gPj4NCj4gPj4+ ICAgICAgICBhPWZtdHA6OTcgRElEX1NESUQ9ezB4NjEsMHgwMn07RElEX1NESUQ9ezB4NDEsMHgw NX0NCj4gPj4NCj4gPj4+DQo+ID4+DQo+ID4+PiBCdXQgSeKAmW0gc3RpbGwgbW9yZSBjb21mb3J0 YWJsZSB3aXRoIGtlZXBpbmcgdGhlIOKAnExT4oCdIGdyb3VwaW5nIGluIHRoZQ0KPiA+PiBleGFt cGxlDQo+ID4+DQo+ID4+PiB1bmxlc3MgdGhlcmUgYXJlIG9iamVjdGlvbnMuDQo+ID4+DQo+ID4+ Pg0KPiA+Pg0KPiA+Pj4gVGhpcyBicmluZ3MgdXMgdG8gdGhlIG1haW4gcG9pbnQgb2YgQWRhbSBS b2FjaOKAmXMgRElTQ1VTUyBpdGVtLCBob3cNCj4gPj4+IGRvDQo+ID4+IHlvdQ0KPiA+Pg0KPiA+ Pj4gcHJvdmlkZSBtdWx0aS1sZXZlbCBoaWVyYXJjaGljYWwgZ3JvdXBpbmcgaW4gU0RQLiAgSW1h Z2luZSBhIGdyb3VwDQo+ID4+PiBvZiAoYQ0KPiA+PiBncm91cA0KPiA+Pg0KPiA+Pj4gb2Ygdmlk ZW8gYW5kIGFuY2lsbGFyeSBkYXRhKSBhbmQgKGEgZ3JvdXAgb2YgdmlkZW8gYW5kIGFuY2lsbGFy eSBkYXRhKS4NCj4gPj4gVGhlcmUNCj4gPj4NCj4gPj4+IGFjdHVhbGx5IGlzIGEgY2FzZSBvZiB0 aGlzIGluIHByb2R1Y3Rpb24gdGVsZXZpc2lvbiwgdGhlIG11bHRpdmlld2VyDQo+ID4+PiAoZS5n LiBzZWUNCj4gPj4NCj4gPj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0NCj4gPj4NCj4gM0FfX3d3dy5ibGFja21hZ2ljZGVzaWduLmNvbV9wcm9kdWN0 c19tdWx0aXZpZXcmZD1Ed0lHYVEmYz11dzZUDQo+ID4+IEx1NGh3aEhkaUdKT2d3Y1dENEFqS1F4 Nnp2RmNHRXNiZmlZOS0NCj4gPj4NCj4gRUkmcj1sZWtOT09NNW5vVjYxenJQSDNyd1B5aHRObkxM V29MRUhnZDBxdVF4bHk4Jm09bW10eUxYdHlhDQo+ID4+DQo+IFdIRWczSlljcTN4U1ZMWHpScWtJ VmdXQUpEZ3F5SWdyZVUmcz1JZEtvelNaV2JvaEswRmdfQ3ZaY21lTk8NCj4gPj4gNkp4akdadndr bnJDUkxhUVZYOCZlPSkuDQo+ID4+DQo+ID4+Pg0KPiA+Pg0KPiA+Pj4gVW5mb3J0dW5hdGVseSwg SSByZWFsbHkgY2Fu4oCZdCBmaW5kIGFueSBTRFAgbWVjaGFuaXNtIHRvIGRlc2NyaWJlDQo+ID4+ PiBtdWx0aS0NCj4gPj4gbGV2ZWwNCj4gPj4NCj4gPj4+IGhpZXJhcmNoeS4gIFJGQyA0Nzk2IOKA nFRoZSBTZXNzaW9uIERlc2NyaXB0aW9uIFByb3RvY29sIChTRFApIENvbnRlbnQNCj4gPj4NCj4g Pj4+IEF0dHJpYnV0ZeKAnSBpcyBhYm91dCB0aGUgYmVzdCBJIGNhbiBmaW5kLCB3aGVyZSBzeW5j aHJvbml6ZWQNCj4gPj4+IG11bHRpbWVkaWENCj4gPj4gKHN1Y2gNCj4gPj4NCj4gPj4+IGFzIOKA nHNsaWRlc+KAnSwg4oCcc3BlYWtlcuKAnSwg4oCcbWFpbuKAnSwgZXRjLikgaXMgcHJlc2VudGVk LiAgQnV0IHRoaXMgaXMgYQ0KPiA+Pj4gdmVyeSBsaW1pdGVkDQo+ID4+IHNldA0KPiA+Pg0KPiA+ Pj4gb2YgdmFsdWVzLiAgUkZDIDU1ODMg4oCcU2lnbmFsaW5nIE1lZGlhIERlY29kaW5nIERlcGVu ZGVuY3kgaW4gdGhlDQo+ID4+IFNlc3Npb24NCj4gPj4NCj4gPj4+IERlc2NyaXB0aW9uIFByb3Rv Y29sIChTRFAp4oCdIGhhcyB2YXJpb3VzIGRlcGVuZGVuY2llcyBvZiBzdHJlYW1zLCBidXQNCj4g Pj4gdGhpcyBpcw0KPiA+Pg0KPiA+Pj4gZm9yIGxheWVyZWQgb3IgbXVsdGlwbGUgZGVzY3JpcHRp dmUgbWVkaWEgY29kaW5nLiAgTmVpdGhlciBvZiB0aGVzZQ0KPiA+Pj4gc2VlbXMNCj4gPj4NCj4g Pj4+IGFwcHJvcHJpYXRlLg0KPiA+Pg0KPiA+Pj4NCj4gPj4NCj4gPj4+IFBlcmhhcHMgdGhpcyBp c3N1ZSBuZWVkcyB0byBiZSBicm91Z2h0IHVwIGluIE11bHRpcGFydHkgTXVsdGltZWRpYQ0KPiA+ PiBTZXNzaW9uDQo+ID4+DQo+ID4+PiBDb250cm9sIChtbXVzaWMpIFdHLCBidXQgSeKAmW0gbm90 IHN1cmUgdGhhdCBpdCBpcyB3aXNlIHRvIGhvbGQgdXAgdGhlDQo+ID4+PiBBTkMNCj4gPj4gUlRQ DQo+ID4+DQo+ID4+PiBQYXlsb2FkIG92ZXIgdGhpcy4NCj4gPj4NCj4gPj4+DQo+ID4+DQo+ID4+ PiBUaGFua3MgZXZlcnlvbmUhDQo+ID4+DQo+ID4+Pg0KPiA+Pg0KPiA+Pj4gLVRob21hcw0KPiA+ Pg0KPiA+Pj4NCj4gPj4NCj4gPj4+IC0tDQo+ID4+DQo+ID4+PiBUaG9tYXMgRWR3YXJkcw0KPiA+ Pg0KPiA+Pj4gRk9YIE5ldHdvcmtzIEVuZ2luZWVyaW5nICYgT3BlcmF0aW9ucw0KPiA+Pg0KPiA+ Pj4gVlAgRW5naW5lZXJpbmcgJiBEZXZlbG9wbWVudA0KPiA+Pg0KPiA+Pj4gdGhvbWFzLmVkd2Fy ZHNAZm94LmNvbQ0KPiA+Pg0KPiA+Pj4gKzEtMzEwLTM2OS02Njk2DQo+ID4+DQo+ID4+PiAxMDIw MSBXIFBpY28gQmx2ZA0KPiA+Pg0KPiA+Pj4gTG9zIEFuZ2VsZXMsIENBIDkwMDM1DQo+ID4+DQo+ ID4+Pg0KPiA+Pg0KPiA+Pj4NCj4gPj4NCj4gPj4+DQo+ID4+DQo+ID4+Pg0KPiA+Pg0KPiA+Pg0K PiA+Pg0KPiA+Pg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiBwYXlsb2FkIG1haWxpbmcgbGlzdA0KPiA+IHBheWxvYWRAaWV0Zi5v cmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BheWxvYWQNCj4g DQo+IA0KPiANCj4gLS0NCj4gQ29saW4gUGVya2lucw0KPiBodHRwczovL2NzcGVya2lucy5vcmcv DQo+IA0KPiANCj4gDQoNCg== From nobody Tue Oct 3 11:46:44 2017 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 2E5A613302A; Tue, 3 Oct 2017 11:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VO_sePVcGn2k; Tue, 3 Oct 2017 11:46:39 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD6BC133090; Tue, 3 Oct 2017 11:46:38 -0700 (PDT) Received: from [81.187.2.149] (port=38131 helo=[192.168.0.71]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1dzSD6-0004bw-4V; Tue, 03 Oct 2017 19:46:31 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Colin Perkins In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD810BCC@DGGEMM506-MBX.china.huawei.com> Date: Tue, 3 Oct 2017 19:46:22 +0100 Cc: Thomas Edwards , Adam Roach , "payload-chairs@ietf.org" , "draft-ietf-payload-rtp-ancillary@ietf.org" , "payload@ietf.org" , "acbegen@gmail.com" Content-Transfer-Encoding: quoted-printable Message-Id: References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <3B259563-1075-4C41-A832-D7633C39173B@foxeg.com> <61440eb5-32c3-3696-be38-8dc7c4eaf72f@nostrum.com> <863974D7-E112-4794-AD4D-C39C99BD40C9@foxeg.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> <6E58094ECC8D8344914996DAD28F1CCD80FC21@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD810751@DGGEMM506-MBX.china.huawei.com> <4D3BF24A-2927-4F9A-A435-7DA6A9F777D7@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810BCC@DGGEMM506-MBX.china.huawei.com> To: Roni Even X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 03 Oct 2017 18:46:42 -0000 No, I think it=E2=80=99s orthogonal to grouping. If the CNAME was = sufficient, then we wouldn=E2=80=99t need the LS grouping method. Colin > On 3 Oct 2017, at 19:00, Roni Even wrote: >=20 > Hi Colin, > So maybe the right direction is that there is no need for grouping at = all in this case and just use the same CNAME in RTCP. > Roni >=20 >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org] >> Sent: =D7=99=D7=95=D7=9D =D7=92 03 =D7=90=D7=95=D7=A7=D7=98=D7=95=D7=91= =D7=A8 2017 19:59 >> To: Roni Even >> Cc: Thomas Edwards; Adam Roach; payload-chairs@ietf.org; draft-ietf- >> payload-rtp-ancillary@ietf.org; payload@ietf.org; acbegen@gmail.com >> Subject: Re: [payload] Adam Roach's Discuss on = draft-ietf-payload-rtp- >> ancillary-10: (with DISCUSS and COMMENT) >>=20 >> Roni, >>=20 >> The requirement for RTP, in general, is that streams that are to be >> synchronised MUST have the same RTCP CNAME. It might be appropriate = to >> remind readers of that, but it=E2=80=99s independent on the grouping = framework. >>=20 >> How that CNAME is chosen doesn=E2=80=99t matter for the purposes of >> synchronisation, provided the SSRCs that are to be synchronised use = the >> same CNAME. The suggestions in RFC 7022 are appropriate, but = there=E2=80=99s no >> reason to mandate them, or require a particular one of those = suggestions be >> used. >>=20 >> Colin >>=20 >>=20 >>=20 >>> On 1 Oct 2017, at 12:25, Roni Even wrote: >>>=20 >>> Hi Thomas, >>> I think that you should also have in the grouping section a >>> recommendation to use the same persistent CNAME (maybe short term?) >>> for the ANC and video stream see RFC 7022 this is required in RTCP = if >>> these RTP streams need to be synchronized (RFC3550) Roni >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Thomas Edwards [mailto:Thomas.Edwards@fox.com] >>>> Sent: =D7=99=D7=95=D7=9D =D7=93 27 =D7=A1=D7=A4=D7=98=D7=9E=D7=91=D7=A8= 2017 18:47 >>>> To: Roni Even; Adam Roach; The IESG >>>> Cc: payload-chairs@ietf.org; >>>> draft-ietf-payload-rtp-ancillary@ietf.org; >>>> payload@ietf.org; acbegen@gmail.com >>>> Subject: Re: Adam Roach's Discuss on = draft-ietf-payload-rtp-ancillary-10: >>>> (with DISCUSS and COMMENT) >>>>=20 >>>> Roni, thanks for the feedback on LS! >>>>=20 >>>> I=E2=80=99m still not sure if it is appropriate to include the = hierarchical >>>> grouping SDP example in draft-ietf-payload-rtp-ancillary. I = suspect it could >> be confusing. >>>>=20 >>>> However, I will note that the Alliance for IP Media Solutions >>>> (http://aimsalliance.org) Technical Committee is considering work = on >>>> documenting different SDP groupings for live television production >>>> scenarios, so it is possible that a future I-D will be submitted = that >>>> could include a range of SDP applications in this area, perhaps >>>> including documentation of Adam Roach=E2=80=99s scenario. >>>>=20 >>>> I can go ahead and upload a draft-ietf-payload-rtp-ancillary-11 = based >>>> on the IESG feedback. >>>>=20 >>>> -Thomas >>>>=20 >>>> -- >>>> Thomas Edwards >>>> FOX Networks Engineering & Operations VP Engineering & Development >>>> thomas.edwards@fox.com >>>> +1-310-369-6696 >>>> 10201 W Pico Blvd >>>> Los Angeles, CA 90035 >>>>=20 >>>>=20 >>>> On 9/27/17, 4:07 AM, "Roni Even" wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> I agree that LS is better fit for ANC >>>>=20 >>>>=20 >>>>=20 >>>> As for Adam's example it is allowed by RFC5888 to specify >>>>=20 >>>> a=3Dgroup:LS V1 V2 M1 M2 >>>>=20 >>>> a=3Dgroup:LS V1 M1 >>>>=20 >>>> a=3Dgroup:LS V2 M2 >>>>=20 >>>> this is similar to RFC5956 which replaced RFC4756 >>>>=20 >>>>=20 >>>>=20 >>>> this is not a clean way but is allowed otherwise there is a need >>>> to specify some SDP attribute for specifying dependencies. >>>>=20 >>>>=20 >>>>=20 >>>> Roni Even >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>=20 >>>>> From: Thomas Edwards [mailto:Thomas.Edwards@fox.com] >>>>=20 >>>>> Sent: =D7=99=D7=95=D7=9D =D7=93 27 =D7=A1=D7=A4=D7=98=D7=9E=D7=91=D7= =A8 2017 04:13 >>>>=20 >>>>> To: Adam Roach; The IESG >>>>=20 >>>>> Cc: payload-chairs@ietf.org; >>>>> draft-ietf-payload-rtp-ancillary@ietf.org; >>>>=20 >>>>> payload@ietf.org; acbegen@gmail.com >>>>=20 >>>>> Subject: Re: Adam Roach's Discuss on = draft-ietf-payload-rtp-ancillary-10: >>>>=20 >>>>> (with DISCUSS and COMMENT) >>>>=20 >>>>>=20 >>>>=20 >>>>> Regarding draft-ietf-payload-rtp-ancillary-10, on further thought = I >>>>> believe >>>>=20 >>>>> that FID grouping is NOT appropriate for Section 4.1 =E2=80=9CGroupi= ng ANC >>>> Streams >>>>=20 >>>>> with other Media Streams=E2=80=9D. >>>>=20 >>>>>=20 >>>>=20 >>>>> RFC 5888 Section 8.4. (=E2=80=9CFID Semantics=E2=80=9D) states: >>>>=20 >>>>>=20 >>>>=20 >>>>> =E2=80=9CIt is assumed that the application uses only one = codec at a >>>>> time to >>>>=20 >>>>> encode the media produced. This codec MAY change dynamically = during >>>> the >>>>=20 >>>>> session, but at any particular moment, only one codec is in = use.=E2=80=9D >>>>=20 >>>>>=20 >>>>=20 >>>>> RFC 5888 Section 8.5.1 states: >>>>=20 >>>>>=20 >>>>=20 >>>>> =E2=80=9CFID semantics are useful when the application only uses = one codec >>>>=20 >>>>> at a time. An application that encodes the same media using >>>>> different >>>>=20 >>>>> codecs simultaneously MUST NOT use FID to group those media = lines.=E2=80=9D >>>>=20 >>>>>=20 >>>>=20 >>>>> When we have one video stream and one ancillary data stream, = senders >>>> are >>>>=20 >>>>> not switching between codecs. FID really sounds to me like a >>>>> situation >>>> where >>>>=20 >>>>> you have one media stream, but senders could send that stream one = of >>>>=20 >>>>> multiple codecs, but not at the same time. >>>>=20 >>>>>=20 >>>>=20 >>>>> Compare with RFC 5888 Section 7: >>>>=20 >>>>>=20 >>>>=20 >>>>> =E2=80=9CNote that LS semantics apply not only to a video stream = that has >>>>> to >>>>=20 >>>>> be synchronized with an audio stream; the playout of two streams = of >>>>> the >>>>=20 >>>>> same type can be synchronized as well.=E2=80=9D >>>>=20 >>>>>=20 >>>>=20 >>>>> Synchronized presentation to the user of an audio, video, and of >>>>> course >>>>=20 >>>>> ancillary data flow is generally what we need for production >>>>> television >>>>=20 >>>>> workflows. >>>>=20 >>>>>=20 >>>>=20 >>>>> draft-ietf-payload-rtp-ancillary-10 Section 4.1 has the example: >>>>=20 >>>>>=20 >>>>=20 >>>>> v=3D0 >>>>=20 >>>>> o=3DAl 123456 11 IN IP4 >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp- >>>>=20 >> 3A__host.example.com&d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx >>>> 6zvFcGEsbfiY9- >>>>=20 >> EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DmmtyLXtya >>>>=20 >> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=3DUuOwClXoGCvGP2qksiV3h85H >>>> NgQRo_Z7b0HgU2qVwzQ&e=3D >>>>=20 >>>>> s=3DProfessional Networked Media Test >>>>=20 >>>>> i=3DA test of synchronized video and ANC data >>>>=20 >>>>> t=3D0 0 >>>>=20 >>>>> a=3Dgroup:LS V1 M1 >>>>=20 >>>>> m=3Dvideo 50000 RTP/AVP 96 >>>>=20 >>>>> c=3DIN IP4 https://urldefense.proofpoint.com/v2/url?u=3Dhttp- >>>>=20 >> 3A__233.252.0.1_255&d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zv >>>> FcGEsbfiY9- >>>>=20 >> EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DmmtyLXtya >>>>=20 >> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=3DmDjccdFR8MWnfQcP_xiMhb- >>>> bh-Wef_2tKhRDyRilYUM&e=3D >>>>=20 >>>>> a=3Drtpmap:96 raw/90000 >>>>=20 >>>>> a=3Dfmtp:96 sampling=3DYCbCr-4:2:2; width=3D1280; = height=3D720; >>>>> depth=3D10 >>>>=20 >>>>> a=3Dmid:V1 >>>>=20 >>>>> m=3Dvideo 50010 RTP/AVP 97 >>>>=20 >>>>> c=3DIN IP4 https://urldefense.proofpoint.com/v2/url?u=3Dhttp- >>>>=20 >> 3A__233.252.0.2_255&d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zv >>>> FcGEsbfiY9- >>>>=20 >> EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DmmtyLXtya >>>>=20 >> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=3D7e66ewQVAuL1YUq2FzASyEJp >>>> qw7Tc5p8fO8lZbZ4tUo&e=3D >>>>=20 >>>>> a=3Drtpmap:97 smpte291/90000 >>>>=20 >>>>> a=3Dfmtp:97 DID_SDID=3D{0x61,0x02};DID_SDID=3D{0x41,0x05} >>>>=20 >>>>> a=3Dmid:M1 >>>>=20 >>>>>=20 >>>>=20 >>>>> As some have pointed out, RTP timestamps and RTCP provide inherent >>>>=20 >>>>> synchronization between =E2=80=9Cm=E2=80=9D lines, but of course = as RFC 5888 Section >>>>> 1 >>>> says >>>>=20 >>>>> without grouping: =E2=80=9CWhen a session description contains = more than one >>>> "m" >>>>=20 >>>>> line, SDP does not provide any means to express a particular >>>>> relationship >>>>=20 >>>>> between two or more of them.=E2=80=9D =E2=80=9CLS=E2=80=9D = grouping makes it pretty clear >>>>> that >>>>=20 >>>>> these streams are intended for synchronized presentation. >>>>=20 >>>>>=20 >>>>=20 >>>>> An alternative to =E2=80=9CLS=E2=80=9D grouping is to drop all = grouping in the >>>>> example, and >>>> be >>>>=20 >>>>> unclear about what these =E2=80=9Cm=E2=80=9D lines are doing = together in the same file: >>>>=20 >>>>>=20 >>>>=20 >>>>> v=3D0 >>>>=20 >>>>> o=3DAl 123456 11 IN IP4 >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp- >>>>=20 >> 3A__host.example.com&d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx >>>> 6zvFcGEsbfiY9- >>>>=20 >> EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DmmtyLXtya >>>>=20 >> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=3DUuOwClXoGCvGP2qksiV3h85H >>>> NgQRo_Z7b0HgU2qVwzQ&e=3D >>>>=20 >>>>> s=3DProfessional Networked Media Test >>>>=20 >>>>> i=3DA test of synchronized video and ANC data >>>>=20 >>>>> t=3D0 0 >>>>=20 >>>>> m=3Dvideo 50000 RTP/AVP 96 >>>>=20 >>>>> c=3DIN IP4 https://urldefense.proofpoint.com/v2/url?u=3Dhttp- >>>>=20 >> 3A__233.252.0.1_255&d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zv >>>> FcGEsbfiY9- >>>>=20 >> EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DmmtyLXtya >>>>=20 >> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=3DmDjccdFR8MWnfQcP_xiMhb- >>>> bh-Wef_2tKhRDyRilYUM&e=3D >>>>=20 >>>>> a=3Drtpmap:96 raw/90000 >>>>=20 >>>>> a=3Dfmtp:96 sampling=3DYCbCr-4:2:2; width=3D1280; = height=3D720; >>>>> depth=3D10 >>>>=20 >>>>> m=3Dvideo 50010 RTP/AVP 97 >>>>=20 >>>>> c=3DIN IP4 https://urldefense.proofpoint.com/v2/url?u=3Dhttp- >>>>=20 >> 3A__233.252.0.2_255&d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zv >>>> FcGEsbfiY9- >>>>=20 >> EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DmmtyLXtya >>>>=20 >> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=3D7e66ewQVAuL1YUq2FzASyEJp >>>> qw7Tc5p8fO8lZbZ4tUo&e=3D >>>>=20 >>>>> a=3Drtpmap:97 smpte291/90000 >>>>=20 >>>>> a=3Dfmtp:97 DID_SDID=3D{0x61,0x02};DID_SDID=3D{0x41,0x05} >>>>=20 >>>>>=20 >>>>=20 >>>>> But I=E2=80=99m still more comfortable with keeping the =E2=80=9CLS=E2= =80=9D grouping in the >>>> example >>>>=20 >>>>> unless there are objections. >>>>=20 >>>>>=20 >>>>=20 >>>>> This brings us to the main point of Adam Roach=E2=80=99s DISCUSS = item, how >>>>> do >>>> you >>>>=20 >>>>> provide multi-level hierarchical grouping in SDP. Imagine a group >>>>> of (a >>>> group >>>>=20 >>>>> of video and ancillary data) and (a group of video and ancillary = data). >>>> There >>>>=20 >>>>> actually is a case of this in production television, the = multiviewer >>>>> (e.g. see >>>>=20 >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >>>>=20 >> 3A__www.blackmagicdesign.com_products_multiview&d=3DDwIGaQ&c=3Duw6T >>>> Lu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9- >>>>=20 >> EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DmmtyLXtya >>>>=20 >> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=3DIdKozSZWbohK0Fg_CvZcmeNO >>>> 6JxjGZvwknrCRLaQVX8&e=3D). >>>>=20 >>>>>=20 >>>>=20 >>>>> Unfortunately, I really can=E2=80=99t find any SDP mechanism to = describe >>>>> multi- >>>> level >>>>=20 >>>>> hierarchy. RFC 4796 =E2=80=9CThe Session Description Protocol = (SDP) Content >>>>=20 >>>>> Attribute=E2=80=9D is about the best I can find, where = synchronized >>>>> multimedia >>>> (such >>>>=20 >>>>> as =E2=80=9Cslides=E2=80=9D, =E2=80=9Cspeaker=E2=80=9D, = =E2=80=9Cmain=E2=80=9D, etc.) is presented. But this is a >>>>> very limited >>>> set >>>>=20 >>>>> of values. RFC 5583 =E2=80=9CSignaling Media Decoding Dependency = in the >>>> Session >>>>=20 >>>>> Description Protocol (SDP)=E2=80=9D has various dependencies of = streams, but >>>> this is >>>>=20 >>>>> for layered or multiple descriptive media coding. Neither of = these >>>>> seems >>>>=20 >>>>> appropriate. >>>>=20 >>>>>=20 >>>>=20 >>>>> Perhaps this issue needs to be brought up in Multiparty Multimedia >>>> Session >>>>=20 >>>>> Control (mmusic) WG, but I=E2=80=99m not sure that it is wise to = hold up the >>>>> ANC >>>> RTP >>>>=20 >>>>> Payload over this. >>>>=20 >>>>>=20 >>>>=20 >>>>> Thanks everyone! >>>>=20 >>>>>=20 >>>>=20 >>>>> -Thomas >>>>=20 >>>>>=20 >>>>=20 >>>>> -- >>>>=20 >>>>> Thomas Edwards >>>>=20 >>>>> FOX Networks Engineering & Operations >>>>=20 >>>>> VP Engineering & Development >>>>=20 >>>>> thomas.edwards@fox.com >>>>=20 >>>>> +1-310-369-6696 >>>>=20 >>>>> 10201 W Pico Blvd >>>>=20 >>>>> Los Angeles, CA 90035 >>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> payload mailing list >>> payload@ietf.org >>> https://www.ietf.org/mailman/listinfo/payload >>=20 >>=20 >>=20 >> -- >> Colin Perkins >> https://csperkins.org/ >>=20 >>=20 >>=20 >=20 --=20 Colin Perkins https://csperkins.org/ From nobody Tue Oct 3 11:51:18 2017 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 42AE31331E4; Tue, 3 Oct 2017 11:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TF5RTuFsxH2; Tue, 3 Oct 2017 11:51:15 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF591330BF; Tue, 3 Oct 2017 11:51:15 -0700 (PDT) Received: from [81.187.2.149] (port=48692 helo=[192.168.0.71]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1dzSHb-0005DD-Ih; Tue, 03 Oct 2017 19:51:08 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Colin Perkins In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD810BB8@DGGEMM506-MBX.china.huawei.com> Date: Tue, 3 Oct 2017 19:51:05 +0100 Cc: Adam Roach , Thomas Edwards , The IESG , "payload-chairs@ietf.org" , "draft-ietf-payload-rtp-ancillary@ietf.org" , "payload@ietf.org" , "acbegen@gmail.com" Content-Transfer-Encoding: quoted-printable Message-Id: <37F6B554-530B-4A30-B66F-A70D026DD2B8@csperkins.org> References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <3B259563-1075-4C41-A832-D7633C39173B@foxeg.com> <61440eb5-32c3-3696-be38-8dc7c4eaf72f@nostrum.com> <863974D7-E112-4794-AD4D-C39C99BD40C9@foxeg.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> <6E58094ECC8D8344914996DAD28F1CCD810BB8@DGGEMM506-MBX.china.huawei.com> To: Roni Even X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 03 Oct 2017 18:51:17 -0000 Hi Roni, I tend to think the =E2=80=9Cdecoded at the sane time=E2=80=9D issue is = over-interpreting the wording of RFC 5888. The metadata and the media to = =E2=80=9Cform a media flow=E2=80=9D, which is the definition of FID. Colin > On 3 Oct 2017, at 18:53, Roni Even wrote: >=20 > Hi Colin, > I think that the question is if the video and anc are decoded at the = same time. In RFC 5888 the case when DTMF is both in the audio and as = DTMF tones (section 8.5.1 ) FID cannot be used only if audio is muted = when DTMF tones are sent. > So the question is if video is muted when ANC is sent (only one decode = at a specific time). I think that in term of time they are both part of = the same video frame so they have the same time so I am not sure if FID = can be used. Maybe Thomas can provide is view here if they are decodec = in parallel or one after the other? > And yes they MUST have the same CNAME regardless of the grouping = specified > Roni >=20 >=20 >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org] >> Sent: =D7=99=D7=95=D7=9D =D7=92 03 =D7=90=D7=95=D7=A7=D7=98=D7=95=D7=91= =D7=A8 2017 19:56 >> To: Adam Roach >> Cc: Thomas Edwards; The IESG; payload-chairs@ietf.org; = draft-ietf-payload- >> rtp-ancillary@ietf.org; payload@ietf.org; acbegen@gmail.com >> Subject: Re: [payload] Adam Roach's Discuss on = draft-ietf-payload-rtp- >> ancillary-10: (with DISCUSS and COMMENT) >>=20 >>> On 29 Sep 2017, at 22:00, Adam Roach wrote: >>> On 9/26/17 8:13 PM, Thomas Edwards wrote: >>>> Regarding draft-ietf-payload-rtp-ancillary-10, on further thought I = believe >> that FID grouping is NOT appropriate for Section 4.1 =E2=80=9CGrouping = ANC Streams >> with other Media Streams=E2=80=9D. >>>>=20 >>>> RFC 5888 Section 8.4. (=E2=80=9CFID Semantics=E2=80=9D) states: >>>>=20 >>>> =E2=80=9CIt is assumed that the application uses only one = codec at a time to >> encode the media produced. This codec MAY change dynamically during = the >> session, but at any particular moment, only one codec is in use.=E2=80=9D= >>>>=20 >>>> RFC 5888 Section 8.5.1 states: >>>>=20 >>>> =E2=80=9CFID semantics are useful when the application only uses = one codec >> at a time. An application that encodes the same media using = different >> codecs simultaneously MUST NOT use FID to group those media lines.=E2=80= =9D >>>>=20 >>>> When we have one video stream and one ancillary data stream, = senders >> are not switching between codecs. FID really sounds to me like a = situation >> where you have one media stream, but senders could send that stream = one >> of multiple codecs, but not at the same time. >>>=20 >>> In this case, where you have data and meta-data, it's arguably two >> different codecs; and, since they don't represent the same data, = you're >> encoding with one codec or the other, based on whether you're sending >> video data or meta-data. =46rom that perspective, I don't see the use = of FID as >> being outside the spirit of what is intended. >>>=20 >>> That said, if the WG agrees with your evaluation that FID isn't = quite the >> right fit, I'm happy for y'all to come up with some alternate = solution... >>=20 >> I tend to agree with Adam that FID is appropriate to group the = ancillary data >> with its associated media stream. The metadata in the ancillary = stream is >> conceptually part of the media stream, which matches the definition = of FID. >> They MUST be sent with the same CNAME, to ensure they can be >> synchronised, but that doesn=E2=80=99t require any explicit = signalling. >>=20 >> You can use LS signalling in addition to FID if two streams, with = their >> associated ancillary streams, need to be synchronised. >>=20 >> -- >> Colin Perkins >> https://csperkins.org/ >>=20 >>=20 >>=20 >=20 --=20 Colin Perkins https://csperkins.org/ From nobody Tue Oct 3 11:55:51 2017 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 B6DC1132FA7; Tue, 3 Oct 2017 11:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWHcTM9UbQJf; Tue, 3 Oct 2017 11:55:41 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9882C1270AB; Tue, 3 Oct 2017 11:55:41 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id n82so15921193oib.8; Tue, 03 Oct 2017 11:55:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=89cg0q0bqNfakbmWoT0H0s8quRTgUoS1OFaVaidDwcs=; b=cFpdlfdXBT3Toa09Bio/oy7UKJK5NQvje+r6h9D12FIugJLXKeFGs1Hux8AQq/Lg2b VVzSzdlT6zOm7zIxSxe13z3wvqR2NFfbxB0aByeMnHJ2JgKgmCpWslFrlgxQK+dUHcLH LVvr8s+fkz24sV0u/mjVYXnVLjowVmut83pcIpnqVkwOPxn1IB56Gc+3ay4aaDogl1KI kvgCJzu84HtltTY67+fzWPE9hX7qV1oFXwQWmUHMvo4QK6VvFrmRQoUvJ2tH5Bvqaz9/ lT+DiOvVBO/VnyVXcpYFMAVO0sfwueUGVLpR17jnOeSSxK7Q/ZhFA5EvxH3uGIFrdheA nzug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=89cg0q0bqNfakbmWoT0H0s8quRTgUoS1OFaVaidDwcs=; b=UpOlpcbfcX8w97byNl/pBelDqFB0Py/7cwJ2DZ44s/X74ZvHdqVzvXQyTrbFvyZfF5 cgwqxJHXqcuWWLrXBZkzt6i3uD7zlFvsGvTQ4x7H5cqqQcoeC+9jUJAMfa8Mq6uk8wkf 22ZxDMuMMYBUcnU749SKzxkOpoo861ADGjX560MrAvJGaTv1vCqrPFvJtRvvRn3TmAJ2 bI2l2NOwgzIH6tpJwIRURChChDqwK64KZvSDwI27xfWFJB6NTLyzFX6zFjA0ImJ9hvgN mdPCzO1qPgHmnGp13cL1Vrp1H6zhmusep2O35wRJMZ/j+zgZEGCt3zh95LDuRKEVceG6 9GdQ== X-Gm-Message-State: AMCzsaWdSR5HPgWu5NiLnZXfBELd8kFU9PMInZKq5o86ridH+vF+8HXj KwMTD1lk5PY1ljT6qUJgv2azhSqU71Rzw38R5wE= X-Google-Smtp-Source: AOwi7QDCtRE//Uj7hxjTZTXuV3tpsd2vhrduXRqj4KyAp21J/i5PmTZcQ3q5jaj9faxCwlgs/weoiz1zdxi3NRzECtk= X-Received: by 10.157.35.91 with SMTP id k27mr3448146otd.126.1507056940912; Tue, 03 Oct 2017 11:55:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.48.167 with HTTP; Tue, 3 Oct 2017 11:55:40 -0700 (PDT) In-Reply-To: <37F6B554-530B-4A30-B66F-A70D026DD2B8@csperkins.org> References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <3B259563-1075-4C41-A832-D7633C39173B@foxeg.com> <61440eb5-32c3-3696-be38-8dc7c4eaf72f@nostrum.com> <863974D7-E112-4794-AD4D-C39C99BD40C9@foxeg.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> <6E58094ECC8D8344914996DAD28F1CCD810BB8@DGGEMM506-MBX.china.huawei.com> <37F6B554-530B-4A30-B66F-A70D026DD2B8@csperkins.org> From: "Ali C. Begen" Date: Tue, 3 Oct 2017 21:55:40 +0300 Message-ID: To: Colin Perkins Cc: Roni Even , Adam Roach , Thomas Edwards , The IESG , "payload-chairs@ietf.org" , "draft-ietf-payload-rtp-ancillary@ietf.org" , "payload@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 03 Oct 2017 18:55:44 -0000 I will repeat myself and say I think the FID grouping is the right thing to do here unless one is willing to specify a new grouping semantics for ANC data. On Tue, Oct 3, 2017 at 9:51 PM, Colin Perkins wrote: > Hi Roni, > > I tend to think the =E2=80=9Cdecoded at the sane time=E2=80=9D issue is o= ver-interpreting the wording of RFC 5888. The metadata and the media to =E2= =80=9Cform a media flow=E2=80=9D, which is the definition of FID. > > Colin > > >> On 3 Oct 2017, at 18:53, Roni Even wrote: >> >> Hi Colin, >> I think that the question is if the video and anc are decoded at the sam= e time. In RFC 5888 the case when DTMF is both in the audio and as DTMF ton= es (section 8.5.1 ) FID cannot be used only if audio is muted when DTMF ton= es are sent. >> So the question is if video is muted when ANC is sent (only one decode a= t a specific time). I think that in term of time they are both part of the = same video frame so they have the same time so I am not sure if FID can be = used. Maybe Thomas can provide is view here if they are decodec in parallel= or one after the other? >> And yes they MUST have the same CNAME regardless of the grouping specifi= ed >> Roni >> >> >>> -----Original Message----- >>> From: Colin Perkins [mailto:csp@csperkins.org] >>> Sent: =D7=99=D7=95=D7=9D =D7=92 03 =D7=90=D7=95=D7=A7=D7=98=D7=95=D7=91= =D7=A8 2017 19:56 >>> To: Adam Roach >>> Cc: Thomas Edwards; The IESG; payload-chairs@ietf.org; draft-ietf-paylo= ad- >>> rtp-ancillary@ietf.org; payload@ietf.org; acbegen@gmail.com >>> Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp- >>> ancillary-10: (with DISCUSS and COMMENT) >>> >>>> On 29 Sep 2017, at 22:00, Adam Roach wrote: >>>> On 9/26/17 8:13 PM, Thomas Edwards wrote: >>>>> Regarding draft-ietf-payload-rtp-ancillary-10, on further thought I b= elieve >>> that FID grouping is NOT appropriate for Section 4.1 =E2=80=9CGrouping = ANC Streams >>> with other Media Streams=E2=80=9D. >>>>> >>>>> RFC 5888 Section 8.4. (=E2=80=9CFID Semantics=E2=80=9D) states: >>>>> >>>>> =E2=80=9CIt is assumed that the application uses only one codec= at a time to >>> encode the media produced. This codec MAY change dynamically during th= e >>> session, but at any particular moment, only one codec is in use.=E2=80= =9D >>>>> >>>>> RFC 5888 Section 8.5.1 states: >>>>> >>>>> =E2=80=9CFID semantics are useful when the application only uses o= ne codec >>> at a time. An application that encodes the same media using different >>> codecs simultaneously MUST NOT use FID to group those media lines.=E2= =80=9D >>>>> >>>>> When we have one video stream and one ancillary data stream, senders >>> are not switching between codecs. FID really sounds to me like a situa= tion >>> where you have one media stream, but senders could send that stream one >>> of multiple codecs, but not at the same time. >>>> >>>> In this case, where you have data and meta-data, it's arguably two >>> different codecs; and, since they don't represent the same data, you're >>> encoding with one codec or the other, based on whether you're sending >>> video data or meta-data. From that perspective, I don't see the use of = FID as >>> being outside the spirit of what is intended. >>>> >>>> That said, if the WG agrees with your evaluation that FID isn't quite = the >>> right fit, I'm happy for y'all to come up with some alternate solution.= .. >>> >>> I tend to agree with Adam that FID is appropriate to group the ancillar= y data >>> with its associated media stream. The metadata in the ancillary stream = is >>> conceptually part of the media stream, which matches the definition of = FID. >>> They MUST be sent with the same CNAME, to ensure they can be >>> synchronised, but that doesn=E2=80=99t require any explicit signalling. >>> >>> You can use LS signalling in addition to FID if two streams, with their >>> associated ancillary streams, need to be synchronised. >>> >>> -- >>> Colin Perkins >>> https://csperkins.org/ >>> >>> >>> >> > > > > -- > Colin Perkins > https://csperkins.org/ > > > > From nobody Tue Oct 3 13:40:58 2017 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 772C413301F; Tue, 3 Oct 2017 13:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIJ0bPWbL283; Tue, 3 Oct 2017 13:40:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32BAF13330C; Tue, 3 Oct 2017 13:40:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DWU06358; Tue, 03 Oct 2017 20:40:47 +0000 (GMT) Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 3 Oct 2017 21:40:45 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.187]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0301.000; Wed, 4 Oct 2017 04:40:41 +0800 From: Roni Even To: Colin Perkins CC: Adam Roach , Thomas Edwards , The IESG , "payload-chairs@ietf.org" , "draft-ietf-payload-rtp-ancillary@ietf.org" , "payload@ietf.org" , "acbegen@gmail.com" Thread-Topic: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) Thread-Index: AQHTPHiQrwezR2ryP0SsE+6CWBgxbKLSk1aQ Date: Tue, 3 Oct 2017 20:40:41 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD810CC5@DGGEMM506-MBX.china.huawei.com> References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <3B259563-1075-4C41-A832-D7633C39173B@foxeg.com> <61440eb5-32c3-3696-be38-8dc7c4eaf72f@nostrum.com> <863974D7-E112-4794-AD4D-C39C99BD40C9@foxeg.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> <6E58094ECC8D8344914996DAD28F1CCD810BB8@DGGEMM506-MBX.china.huawei.com> <37F6B554-530B-4A30-B66F-A70D026DD2B8@csperkins.org> In-Reply-To: <37F6B554-530B-4A30-B66F-A70D026DD2B8@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.247.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.59D3F5CF.0162, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.187, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d30f9eee019546dd46b8f9aefb3bfca2 Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 03 Oct 2017 20:40:52 -0000 SGkgQ29saW4sDQpJIHJlLXJlYWQgUkZDNTg4OCBhbmQgdHJpZWQgdG8gdW5kZXJzdGFuZCB3aGF0 IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gRklEIGFuZCBMUw0KSSB3YXMgdHJ5aW5nIHRvIHVu ZGVyc3RhbmQgd2hhdCBpcyBhIGZsb3cgYW5kIGZyb20gc2VjdGlvbiA4LjMgDQoNCiJUaGUgcHJl dmlvdXMgZXhhbXBsZXMgc2hvdyB0aGF0IHRoZSBkZWZpbml0aW9uIG9mIGEgbWVkaWEgc3RyZWFt IGluDQogICBbUkZDMjMyNl0gZG9lcyBub3QgY292ZXIgc29tZSBzY2VuYXJpb3MuICBJdCBjYW5u b3QgYmUgYXNzdW1lZCB0aGF0IGENCiAgIHNpbmdsZSBtZWRpYSBpbnN0YW5jZSBtYXBzIGludG8g YSBzaW5nbGUgUlRQIHNlc3Npb24uICBUaGVyZWZvcmUsIHdlDQogICBpbnRyb2R1Y2UgdGhlIGRl ZmluaXRpb24gb2YgYSBtZWRpYSBmbG93Og0KDQogICAgICBBIG1lZGlhIGZsb3cgY29uc2lzdHMg b2YgYSBzaW5nbGUgbWVkaWEgaW5zdGFuY2UsIGUuZy4sIGFuIGF1ZGlvDQogICAgICBzdHJlYW0g b3IgYSB2aWRlbyBzdHJlYW0gYXMgd2VsbCBhcyBhIHNpbmdsZSB3aGl0ZWJvYXJkIG9yIHNoYXJl ZA0KICAgICAgYXBwbGljYXRpb24gZ3JvdXAuICBXaGVuIHVzaW5nIFJUUCwgYSBtZWRpYSBmbG93 IGNvbXByaXNlcyBvbmUgb3INCiAgICAgIG1vcmUgUlRQIHNlc3Npb25zLiINCg0KSXQgbG9va3Mg dG8gbWUgdGhhdCBhIG1lZGlhIGZsb3cgaXMgYSBTSU5HTEUgbWVkaWEgc3RyZWFtIHRoYXQgc3Bh bnMgb3ZlciBtdWx0aXBsZSBSVFAgc2Vzc2lvbnMgKHRoZSB0ZXJtIG1lZGlhIGluc3RhbmNlIGlz IGEgd2hhdCB3ZSBjYWxsIGEgbWVkaWEgc3RyZWFtIGluIHRoZSB0YXhvbm9teSkuIFNlY3Rpb24g OC41ICg4LjUuMSkgZW5oYW5jZSB0aGlzIGJ5IHNheWluZyB3aGVuIEZJRCBjYW5ub3QgYmUgdXNl ZCAiIEZJRCBzZW1hbnRpY3MgYXJlIHVzZWZ1bCB3aGVuIHRoZSBhcHBsaWNhdGlvbiBvbmx5IHVz ZXMgb25lIGNvZGVjIGF0ICAgYSB0aW1lIiAgd2hpY2ggYWdhaW4gZGVzY3JpYmUgYSBmbG93IGFz IGEgc2luZ2xlIG1lZGlhIHN0cmVhbS4NCg0KSSBhbSBub3Qgc3VyZSBob3cgQU5DIGFuZCB0aGUg dmlkZW8gcmVsYXRlcyB0byBlYWNoIG90aGVyIHRoaXMgaXMgd2hhdCBJIGFtIGFza2luZyBUaG9t YXMgdG8gYmUgbW9yZSBjbGVhci4gSWYgdGhlIHZpZGVvIGFuZCBBTkMgYXJlIG9uZSBzdHJlYW0g b3ZlciBtdWx0aXBsZSBSVFAgc2Vzc2lvbnMgRklEIGlzIGNvcnJlY3Qgb3RoZXJ3aXNlIEkgdGhp bmsgdGhlIExTIHNob3VsZCBiZSB1c2VkLg0KTXkgcmVhZGluZyBvbiAgdGhlIGFuY2lsbGFyeSBk cmFmdCBpcyB0aGF0IEFOQyBhbmQgdGhlIHZpZGVvIGFyZSB3aGF0IHdlIGNhbGwgYSBzaW5nbGUg UlRQIHN0cmVhbSBidXQgdGhpcyBpcyBub3Qgd2hhdCBUaG9tYXMgc2F5cy4NCg0KUm9uaQ0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IENvbGluIFBlcmtpbnMgW21haWx0 bzpjc3BAY3NwZXJraW5zLm9yZ10NCj4gU2VudDog15nXldedwqDXkiAwMyDXkNeV16fXmNeV15HX qCAyMDE3IDIxOjUxDQo+IFRvOiBSb25pIEV2ZW4NCj4gQ2M6IEFkYW0gUm9hY2g7IFRob21hcyBF ZHdhcmRzOyBUaGUgSUVTRzsgcGF5bG9hZC1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LQ0KPiBpZXRm LXBheWxvYWQtcnRwLWFuY2lsbGFyeUBpZXRmLm9yZzsgcGF5bG9hZEBpZXRmLm9yZzsgYWNiZWdl bkBnbWFpbC5jb20NCj4gU3ViamVjdDogUmU6IFtwYXlsb2FkXSBBZGFtIFJvYWNoJ3MgRGlzY3Vz cyBvbiBkcmFmdC1pZXRmLXBheWxvYWQtcnRwLQ0KPiBhbmNpbGxhcnktMTA6ICh3aXRoIERJU0NV U1MgYW5kIENPTU1FTlQpDQo+IA0KPiBIaSBSb25pLA0KPiANCj4gSSB0ZW5kIHRvIHRoaW5rIHRo ZSDigJxkZWNvZGVkIGF0IHRoZSBzYW5lIHRpbWXigJ0gaXNzdWUgaXMgb3Zlci1pbnRlcnByZXRp bmcgdGhlDQo+IHdvcmRpbmcgb2YgUkZDIDU4ODguIFRoZSBtZXRhZGF0YSBhbmQgdGhlIG1lZGlh IHRvIOKAnGZvcm0gYSBtZWRpYSBmbG934oCdLA0KPiB3aGljaCBpcyB0aGUgZGVmaW5pdGlvbiBv ZiBGSUQuDQo+IA0KPiBDb2xpbg0KPiANCj4gDQo+ID4gT24gMyBPY3QgMjAxNywgYXQgMTg6NTMs IFJvbmkgRXZlbiA8cm9uaS5ldmVuQGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+DQo+ID4gSGkgQ29s aW4sDQo+ID4gSSB0aGluayB0aGF0IHRoZSBxdWVzdGlvbiBpcyBpZiB0aGUgdmlkZW8gYW5kIGFu YyBhcmUgZGVjb2RlZCBhdCB0aGUgc2FtZQ0KPiB0aW1lLiBJbiBSRkMgNTg4OCB0aGUgY2FzZSB3 aGVuIERUTUYgaXMgYm90aCBpbiB0aGUgYXVkaW8gYW5kIGFzIERUTUYNCj4gdG9uZXMgKHNlY3Rp b24gOC41LjEgKSBGSUQgY2Fubm90IGJlIHVzZWQgb25seSBpZiBhdWRpbyBpcyBtdXRlZCB3aGVu IERUTUYNCj4gdG9uZXMgYXJlIHNlbnQuDQo+ID4gU28gdGhlIHF1ZXN0aW9uIGlzIGlmIHZpZGVv IGlzIG11dGVkIHdoZW4gQU5DIGlzIHNlbnQgKG9ubHkgb25lIGRlY29kZSBhdCBhDQo+IHNwZWNp ZmljIHRpbWUpLiBJIHRoaW5rIHRoYXQgaW4gdGVybSBvZiB0aW1lIHRoZXkgYXJlIGJvdGggcGFy dCBvZiB0aGUgc2FtZQ0KPiB2aWRlbyBmcmFtZSBzbyB0aGV5IGhhdmUgdGhlIHNhbWUgdGltZSBz byBJIGFtIG5vdCBzdXJlIGlmIEZJRCBjYW4gYmUgdXNlZC4NCj4gTWF5YmUgVGhvbWFzIGNhbiBw cm92aWRlIGlzIHZpZXcgaGVyZSBpZiB0aGV5IGFyZSBkZWNvZGVjIGluIHBhcmFsbGVsIG9yIG9u ZQ0KPiBhZnRlciB0aGUgb3RoZXI/DQo+ID4gQW5kIHllcyB0aGV5IE1VU1QgaGF2ZSB0aGUgc2Ft ZSBDTkFNRSByZWdhcmRsZXNzIG9mIHRoZSBncm91cGluZw0KPiA+IHNwZWNpZmllZCBSb25pDQo+ ID4NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBDb2xp biBQZXJraW5zIFttYWlsdG86Y3NwQGNzcGVya2lucy5vcmddDQo+ID4+IFNlbnQ6INeZ15XXnSDX kiAwMyDXkNeV16fXmNeV15HXqCAyMDE3IDE5OjU2DQo+ID4+IFRvOiBBZGFtIFJvYWNoDQo+ID4+ IENjOiBUaG9tYXMgRWR3YXJkczsgVGhlIElFU0c7IHBheWxvYWQtY2hhaXJzQGlldGYub3JnOw0K PiA+PiBkcmFmdC1pZXRmLXBheWxvYWQtIHJ0cC1hbmNpbGxhcnlAaWV0Zi5vcmc7IHBheWxvYWRA aWV0Zi5vcmc7DQo+ID4+IGFjYmVnZW5AZ21haWwuY29tDQo+ID4+IFN1YmplY3Q6IFJlOiBbcGF5 bG9hZF0gQWRhbSBSb2FjaCdzIERpc2N1c3Mgb24NCj4gPj4gZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0 cC0NCj4gPj4gYW5jaWxsYXJ5LTEwOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiA+Pg0K PiA+Pj4gT24gMjkgU2VwIDIwMTcsIGF0IDIyOjAwLCBBZGFtIFJvYWNoIDxhZGFtQG5vc3RydW0u Y29tPiB3cm90ZToNCj4gPj4+IE9uIDkvMjYvMTcgODoxMyBQTSwgVGhvbWFzIEVkd2FyZHMgd3Jv dGU6DQo+ID4+Pj4gUmVnYXJkaW5nIGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtYW5jaWxsYXJ5LTEw LCBvbiBmdXJ0aGVyIHRob3VnaHQgSQ0KPiA+Pj4+IGJlbGlldmUNCj4gPj4gdGhhdCBGSUQgZ3Jv dXBpbmcgaXMgTk9UIGFwcHJvcHJpYXRlIGZvciBTZWN0aW9uIDQuMSDigJxHcm91cGluZyBBTkMN Cj4gPj4gU3RyZWFtcyB3aXRoIG90aGVyIE1lZGlhIFN0cmVhbXPigJ0uDQo+ID4+Pj4NCj4gPj4+ PiBSRkMgNTg4OCBTZWN0aW9uIDguNC4gKOKAnEZJRCBTZW1hbnRpY3PigJ0pIHN0YXRlczoNCj4g Pj4+Pg0KPiA+Pj4+ICAgICAgIOKAnEl0IGlzIGFzc3VtZWQgdGhhdCB0aGUgYXBwbGljYXRpb24g dXNlcyBvbmx5IG9uZSBjb2RlYyBhdCBhDQo+ID4+Pj4gdGltZSB0bw0KPiA+PiBlbmNvZGUgdGhl IG1lZGlhIHByb2R1Y2VkLiAgVGhpcyBjb2RlYyBNQVkgY2hhbmdlIGR5bmFtaWNhbGx5IGR1cmlu Zw0KPiA+PiB0aGUgc2Vzc2lvbiwgYnV0IGF0IGFueSBwYXJ0aWN1bGFyIG1vbWVudCwgb25seSBv bmUgY29kZWMgaXMgaW4gdXNlLuKAnQ0KPiA+Pj4+DQo+ID4+Pj4gUkZDIDU4ODggU2VjdGlvbiA4 LjUuMSBzdGF0ZXM6DQo+ID4+Pj4NCj4gPj4+PiAJ4oCcRklEIHNlbWFudGljcyBhcmUgdXNlZnVs IHdoZW4gdGhlIGFwcGxpY2F0aW9uIG9ubHkgdXNlcyBvbmUgY29kZWMNCj4gPj4gYXQgYSB0aW1l LiAgQW4gYXBwbGljYXRpb24gdGhhdCBlbmNvZGVzIHRoZSBzYW1lIG1lZGlhIHVzaW5nDQo+ID4+ IGRpZmZlcmVudCBjb2RlY3Mgc2ltdWx0YW5lb3VzbHkgTVVTVCBOT1QgdXNlIEZJRCB0byBncm91 cCB0aG9zZSBtZWRpYQ0KPiBsaW5lcy7igJ0NCj4gPj4+Pg0KPiA+Pj4+IFdoZW4gd2UgaGF2ZSBv bmUgdmlkZW8gc3RyZWFtIGFuZCBvbmUgYW5jaWxsYXJ5IGRhdGEgc3RyZWFtLA0KPiA+Pj4+IHNl bmRlcnMNCj4gPj4gYXJlIG5vdCBzd2l0Y2hpbmcgYmV0d2VlbiBjb2RlY3MuICBGSUQgcmVhbGx5 IHNvdW5kcyB0byBtZSBsaWtlIGENCj4gPj4gc2l0dWF0aW9uIHdoZXJlIHlvdSBoYXZlIG9uZSBt ZWRpYSBzdHJlYW0sIGJ1dCBzZW5kZXJzIGNvdWxkIHNlbmQNCj4gPj4gdGhhdCBzdHJlYW0gb25l IG9mIG11bHRpcGxlIGNvZGVjcywgYnV0IG5vdCBhdCB0aGUgc2FtZSB0aW1lLg0KPiA+Pj4NCj4g Pj4+IEluIHRoaXMgY2FzZSwgd2hlcmUgeW91IGhhdmUgZGF0YSBhbmQgbWV0YS1kYXRhLCBpdCdz IGFyZ3VhYmx5IHR3bw0KPiA+PiBkaWZmZXJlbnQgY29kZWNzOyBhbmQsIHNpbmNlIHRoZXkgZG9u J3QgcmVwcmVzZW50IHRoZSBzYW1lIGRhdGEsDQo+ID4+IHlvdSdyZSBlbmNvZGluZyB3aXRoIG9u ZSBjb2RlYyBvciB0aGUgb3RoZXIsIGJhc2VkIG9uIHdoZXRoZXIgeW91J3JlDQo+ID4+IHNlbmRp bmcgdmlkZW8gZGF0YSBvciBtZXRhLWRhdGEuIEZyb20gdGhhdCBwZXJzcGVjdGl2ZSwgSSBkb24n dCBzZWUNCj4gPj4gdGhlIHVzZSBvZiBGSUQgYXMgYmVpbmcgb3V0c2lkZSB0aGUgc3Bpcml0IG9m IHdoYXQgaXMgaW50ZW5kZWQuDQo+ID4+Pg0KPiA+Pj4gVGhhdCBzYWlkLCBpZiB0aGUgV0cgYWdy ZWVzIHdpdGggeW91ciBldmFsdWF0aW9uIHRoYXQgRklEIGlzbid0DQo+ID4+PiBxdWl0ZSB0aGUN Cj4gPj4gcmlnaHQgZml0LCBJJ20gaGFwcHkgZm9yIHknYWxsIHRvIGNvbWUgdXAgd2l0aCBzb21l IGFsdGVybmF0ZSBzb2x1dGlvbi4uLg0KPiA+Pg0KPiA+PiBJIHRlbmQgdG8gYWdyZWUgd2l0aCBB ZGFtIHRoYXQgRklEIGlzIGFwcHJvcHJpYXRlIHRvIGdyb3VwIHRoZQ0KPiA+PiBhbmNpbGxhcnkg ZGF0YSB3aXRoIGl0cyBhc3NvY2lhdGVkIG1lZGlhIHN0cmVhbS4gVGhlIG1ldGFkYXRhIGluIHRo ZQ0KPiA+PiBhbmNpbGxhcnkgc3RyZWFtIGlzIGNvbmNlcHR1YWxseSBwYXJ0IG9mIHRoZSBtZWRp YSBzdHJlYW0sIHdoaWNoIG1hdGNoZXMNCj4gdGhlIGRlZmluaXRpb24gb2YgRklELg0KPiA+PiBU aGV5IE1VU1QgYmUgc2VudCB3aXRoIHRoZSBzYW1lIENOQU1FLCB0byBlbnN1cmUgdGhleSBjYW4g YmUNCj4gPj4gc3luY2hyb25pc2VkLCBidXQgdGhhdCBkb2VzbuKAmXQgcmVxdWlyZSBhbnkgZXhw bGljaXQgc2lnbmFsbGluZy4NCj4gPj4NCj4gPj4gWW91IGNhbiB1c2UgTFMgc2lnbmFsbGluZyBp biBhZGRpdGlvbiB0byBGSUQgaWYgdHdvIHN0cmVhbXMsIHdpdGgNCj4gPj4gdGhlaXIgYXNzb2Np YXRlZCBhbmNpbGxhcnkgc3RyZWFtcywgbmVlZCB0byBiZSBzeW5jaHJvbmlzZWQuDQo+ID4+DQo+ ID4+IC0tDQo+ID4+IENvbGluIFBlcmtpbnMNCj4gPj4gaHR0cHM6Ly9jc3BlcmtpbnMub3JnLw0K PiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+DQo+IA0KPiANCj4gDQo+IC0tDQo+IENvbGluIFBlcmtpbnMN Cj4gaHR0cHM6Ly9jc3BlcmtpbnMub3JnLw0KPiANCj4gDQo+IA0KDQo= From nobody Tue Oct 3 14:01:53 2017 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 064B81332E4; Tue, 3 Oct 2017 14:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywiiy99UNLDX; Tue, 3 Oct 2017 14:01:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 606AD1321A2; Tue, 3 Oct 2017 14:01:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DWU08077; Tue, 03 Oct 2017 21:01:45 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 3 Oct 2017 22:01:44 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.187]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0301.000; Wed, 4 Oct 2017 05:01:38 +0800 From: Roni Even To: Colin Perkins CC: Thomas Edwards , Adam Roach , "payload-chairs@ietf.org" , "draft-ietf-payload-rtp-ancillary@ietf.org" , "payload@ietf.org" , "acbegen@gmail.com" Thread-Topic: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) Thread-Index: AQHTPHf1rwezR2ryP0SsE+6CWBgxbKLSlx8w Date: Tue, 3 Oct 2017 21:01:37 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD810CE3@DGGEMM506-MBX.china.huawei.com> References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <3B259563-1075-4C41-A832-D7633C39173B@foxeg.com> <61440eb5-32c3-3696-be38-8dc7c4eaf72f@nostrum.com> <863974D7-E112-4794-AD4D-C39C99BD40C9@foxeg.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> <6E58094ECC8D8344914996DAD28F1CCD80FC21@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD810751@DGGEMM506-MBX.china.huawei.com> <4D3BF24A-2927-4F9A-A435-7DA6A9F777D7@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810BCC@DGGEMM506-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.247.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.59D3FAB9.025F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.187, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d30f9eee019546dd46b8f9aefb3bfca2 Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 03 Oct 2017 21:01:51 -0000 Q29saW4sDQpJIHJlLXJlYWQgUkZDNTg4OCBzZWN0aW9uIDcgYW5kIDcuMS4gSSB0aGluayB0aGF0 IExTIGZvciB0d28gUlRQIHN0cmVhbXMgdGhhdCBuZWVkIHRvIGJlIHN5bmNocm9uaXplZCB3aWxs IHdvcmsgd2l0aG91dCBMUy4gVGhlIExTIGlzIG5lZWRlZCBmb3IgY2FzZSB3aGVuIGdyb3VwaW5n IG0tbGluZXMgdGhhdCAgYXJlIG5vdCBSVFAsIGZvciBleGFtcGxlIGFuIFJUUCB3aXRoIGEgbT1h cHBsaWNhdGlvbiBvciBsaWtlIGluIHNlY3Rpb24gNy4xIHlvdSBoYXZlIHRocmVlIHN0cmVhbXMg cHJvYmFibHkgZnJvbSB0aGUgc2FtZSBzb3VyY2UgYnV0IG9ubHkgdHdvIG11c3QgYmUgc3luY2hy b25pemVkLiBGb3IgdGhlIGNhc2Ugd2hlcmUgdGhlcmUgYXJlICBmb3IgZXhhbXBsZSBvbmUgdmlk ZW8gYW5kIG9uZSBhdWRpbyBzdHJlYW1zIHRoYXQgd2lsbCBiZSBzeW5jaHJvbml6ZWQgYmFzZWQg b24gdGhlIENOQU1FLCBJIGFtIG5vdCBzdXJlIHdoYXQgaXMgdGhlIHZhbHVlIG9mIExTIGV4Y2Vw dCB0aGF0IGl0IHByb3ZpZGVzIHNpZ25hbGluZyBwbGFuZSBpbmZvcm1hdGlvbiB0aGF0IHRoZXNl IGFyZSB0aGUgYXVkaW8gYW5kIHZpZGVvIHRoYXQgbXVzdCBiZSBzeW5jaHJvbml6ZWQgZXZlbiBp ZiB0aGV5IGRvIG5vdCBoYXZlIHRoZSBzYW1lIENOQU1FIGFuZCBob3cgdG8gc3luY2hyb25pemUg aXMgYW4gYXBwbGljYXRpb24gaXNzdWUgKGZvciBleGFtcGxlIHRoZSByZWNlaXZlciBjYW4gZGVs YXkgdGhlIGF1ZGlvICwgIHVzZSBjYXNlICBhdWRpbyBtaXhpbmcgaW4gdGhlIHZpZGVvIHN3aXRj aGluZyBNQ1UgdG9wb2xvZ3kgKQ0KUm9uaQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IENvbGluIFBlcmtpbnMgW21haWx0bzpjc3BAY3NwZXJraW5zLm9yZ10NCj4gU2Vu dDog15nXldedwqDXkiAwMyDXkNeV16fXmNeV15HXqCAyMDE3IDIxOjQ2DQo+IFRvOiBSb25pIEV2 ZW4NCj4gQ2M6IFRob21hcyBFZHdhcmRzOyBBZGFtIFJvYWNoOyBwYXlsb2FkLWNoYWlyc0BpZXRm Lm9yZzsgZHJhZnQtaWV0Zi0NCj4gcGF5bG9hZC1ydHAtYW5jaWxsYXJ5QGlldGYub3JnOyBwYXls b2FkQGlldGYub3JnOyBhY2JlZ2VuQGdtYWlsLmNvbQ0KPiBTdWJqZWN0OiBSZTogW3BheWxvYWRd IEFkYW0gUm9hY2gncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtDQo+IGFuY2ls bGFyeS0xMDogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IE5vLCBJIHRoaW5rIGl0 4oCZcyBvcnRob2dvbmFsIHRvIGdyb3VwaW5nLiBJZiB0aGUgQ05BTUUgd2FzIHN1ZmZpY2llbnQs IHRoZW4gd2UNCj4gd291bGRu4oCZdCBuZWVkIHRoZSBMUyBncm91cGluZyBtZXRob2QuDQo+IA0K PiBDb2xpbg0KPiANCj4gDQo+IA0KPiA+IE9uIDMgT2N0IDIwMTcsIGF0IDE5OjAwLCBSb25pIEV2 ZW4gPHJvbmkuZXZlbkBodWF3ZWkuY29tPiB3cm90ZToNCj4gPg0KPiA+IEhpIENvbGluLA0KPiA+ IFNvIG1heWJlIHRoZSByaWdodCBkaXJlY3Rpb24gaXMgdGhhdCB0aGVyZSBpcyBubyBuZWVkIGZv ciBncm91cGluZyBhdCBhbGwgaW4NCj4gdGhpcyBjYXNlIGFuZCAganVzdCB1c2UgdGhlIHNhbWUg Q05BTUUgaW4gUlRDUC4NCj4gPiBSb25pDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPj4gRnJvbTogQ29saW4gUGVya2lucyBbbWFpbHRvOmNzcEBjc3BlcmtpbnMub3Jn XQ0KPiA+PiBTZW50OiDXmdeV150g15IgMDMg15DXlden15jXldeR16ggMjAxNyAxOTo1OQ0KPiA+ PiBUbzogUm9uaSBFdmVuDQo+ID4+IENjOiBUaG9tYXMgRWR3YXJkczsgQWRhbSBSb2FjaDsgcGF5 bG9hZC1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtDQo+ID4+IHBheWxvYWQtcnRwLWFuY2ls bGFyeUBpZXRmLm9yZzsgcGF5bG9hZEBpZXRmLm9yZzsgYWNiZWdlbkBnbWFpbC5jb20NCj4gPj4g U3ViamVjdDogUmU6IFtwYXlsb2FkXSBBZGFtIFJvYWNoJ3MgRGlzY3VzcyBvbg0KPiA+PiBkcmFm dC1pZXRmLXBheWxvYWQtcnRwLQ0KPiA+PiBhbmNpbGxhcnktMTA6ICh3aXRoIERJU0NVU1MgYW5k IENPTU1FTlQpDQo+ID4+DQo+ID4+IFJvbmksDQo+ID4+DQo+ID4+IFRoZSByZXF1aXJlbWVudCBm b3IgUlRQLCBpbiBnZW5lcmFsLCBpcyB0aGF0IHN0cmVhbXMgdGhhdCBhcmUgdG8gYmUNCj4gPj4g c3luY2hyb25pc2VkIE1VU1QgaGF2ZSB0aGUgc2FtZSBSVENQIENOQU1FLiBJdCBtaWdodCBiZSBh cHByb3ByaWF0ZQ0KPiA+PiB0byByZW1pbmQgcmVhZGVycyBvZiB0aGF0LCBidXQgaXTigJlzIGlu ZGVwZW5kZW50IG9uIHRoZSBncm91cGluZw0KPiBmcmFtZXdvcmsuDQo+ID4+DQo+ID4+IEhvdyB0 aGF0IENOQU1FIGlzIGNob3NlbiBkb2VzbuKAmXQgbWF0dGVyIGZvciB0aGUgcHVycG9zZXMgb2YN Cj4gPj4gc3luY2hyb25pc2F0aW9uLCBwcm92aWRlZCB0aGUgU1NSQ3MgdGhhdCBhcmUgdG8gYmUg c3luY2hyb25pc2VkIHVzZQ0KPiA+PiB0aGUgc2FtZSBDTkFNRS4gVGhlIHN1Z2dlc3Rpb25zIGlu IFJGQyA3MDIyIGFyZSBhcHByb3ByaWF0ZSwgYnV0DQo+ID4+IHRoZXJl4oCZcyBubyByZWFzb24g dG8gbWFuZGF0ZSB0aGVtLCBvciByZXF1aXJlIGEgcGFydGljdWxhciBvbmUgb2YNCj4gPj4gdGhv c2Ugc3VnZ2VzdGlvbnMgYmUgdXNlZC4NCj4gPj4NCj4gPj4gQ29saW4NCj4gPj4NCj4gPj4NCj4g Pj4NCj4gPj4+IE9uIDEgT2N0IDIwMTcsIGF0IDEyOjI1LCBSb25pIEV2ZW4gPHJvbmkuZXZlbkBo dWF3ZWkuY29tPiB3cm90ZToNCj4gPj4+DQo+ID4+PiBIaSBUaG9tYXMsDQo+ID4+PiBJIHRoaW5r IHRoYXQgeW91IHNob3VsZCBhbHNvIGhhdmUgaW4gdGhlIGdyb3VwaW5nIHNlY3Rpb24gYQ0KPiA+ Pj4gcmVjb21tZW5kYXRpb24gdG8gdXNlIHRoZSBzYW1lIHBlcnNpc3RlbnQgQ05BTUUgKG1heWJl IHNob3J0DQo+IHRlcm0/KQ0KPiA+Pj4gZm9yIHRoZSBBTkMgYW5kIHZpZGVvIHN0cmVhbSBzZWUg UkZDIDcwMjIgdGhpcyBpcyByZXF1aXJlZCBpbiBSVENQDQo+ID4+PiBpZiB0aGVzZSBSVFAgc3Ry ZWFtcyBuZWVkIHRvIGJlIHN5bmNocm9uaXplZCAoUkZDMzU1MCkgUm9uaQ0KPiA+Pj4NCj4gPj4+ DQo+ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+PiBGcm9tOiBUaG9tYXMg RWR3YXJkcyBbbWFpbHRvOlRob21hcy5FZHdhcmRzQGZveC5jb21dDQo+ID4+Pj4gU2VudDog15nX ldedINeTIDI3INeh16TXmNee15HXqCAyMDE3IDE4OjQ3DQo+ID4+Pj4gVG86IFJvbmkgRXZlbjsg QWRhbSBSb2FjaDsgVGhlIElFU0cNCj4gPj4+PiBDYzogcGF5bG9hZC1jaGFpcnNAaWV0Zi5vcmc7 DQo+ID4+Pj4gZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1hbmNpbGxhcnlAaWV0Zi5vcmc7DQo+ID4+ Pj4gcGF5bG9hZEBpZXRmLm9yZzsgYWNiZWdlbkBnbWFpbC5jb20NCj4gPj4+PiBTdWJqZWN0OiBS ZTogQWRhbSBSb2FjaCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1hbmNpbGxh cnktDQo+IDEwOg0KPiA+Pj4+ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+ID4+Pj4NCj4g Pj4+PiBSb25pLCB0aGFua3MgZm9yIHRoZSBmZWVkYmFjayBvbiBMUyENCj4gPj4+Pg0KPiA+Pj4+ IEnigJltIHN0aWxsIG5vdCBzdXJlIGlmIGl0IGlzIGFwcHJvcHJpYXRlIHRvIGluY2x1ZGUgdGhl IGhpZXJhcmNoaWNhbA0KPiA+Pj4+IGdyb3VwaW5nIFNEUCBleGFtcGxlIGluIGRyYWZ0LWlldGYt cGF5bG9hZC1ydHAtYW5jaWxsYXJ5LiAgSQ0KPiA+Pj4+IHN1c3BlY3QgaXQgY291bGQNCj4gPj4g YmUgY29uZnVzaW5nLg0KPiA+Pj4+DQo+ID4+Pj4gSG93ZXZlciwgSSB3aWxsIG5vdGUgdGhhdCB0 aGUgQWxsaWFuY2UgZm9yIElQIE1lZGlhIFNvbHV0aW9ucw0KPiA+Pj4+IChodHRwOi8vYWltc2Fs bGlhbmNlLm9yZykgVGVjaG5pY2FsIENvbW1pdHRlZSBpcyBjb25zaWRlcmluZyB3b3JrDQo+ID4+ Pj4gb24gZG9jdW1lbnRpbmcgZGlmZmVyZW50IFNEUCBncm91cGluZ3MgZm9yIGxpdmUgdGVsZXZp c2lvbg0KPiA+Pj4+IHByb2R1Y3Rpb24gc2NlbmFyaW9zLCBzbyBpdCBpcyBwb3NzaWJsZSB0aGF0 IGEgZnV0dXJlIEktRCB3aWxsIGJlDQo+ID4+Pj4gc3VibWl0dGVkIHRoYXQgY291bGQgaW5jbHVk ZSBhIHJhbmdlIG9mIFNEUCBhcHBsaWNhdGlvbnMgaW4gdGhpcw0KPiA+Pj4+IGFyZWEsIHBlcmhh cHMgaW5jbHVkaW5nIGRvY3VtZW50YXRpb24gb2YgQWRhbSBSb2FjaOKAmXMgc2NlbmFyaW8uDQo+ ID4+Pj4NCj4gPj4+PiBJIGNhbiBnbyBhaGVhZCBhbmQgdXBsb2FkIGEgZHJhZnQtaWV0Zi1wYXls b2FkLXJ0cC1hbmNpbGxhcnktMTENCj4gPj4+PiBiYXNlZCBvbiB0aGUgSUVTRyBmZWVkYmFjay4N Cj4gPj4+Pg0KPiA+Pj4+IC1UaG9tYXMNCj4gPj4+Pg0KPiA+Pj4+IC0tDQo+ID4+Pj4gVGhvbWFz IEVkd2FyZHMNCj4gPj4+PiBGT1ggTmV0d29ya3MgRW5naW5lZXJpbmcgJiBPcGVyYXRpb25zIFZQ IEVuZ2luZWVyaW5nICYNCj4gRGV2ZWxvcG1lbnQNCj4gPj4+PiB0aG9tYXMuZWR3YXJkc0Bmb3gu Y29tDQo+ID4+Pj4gKzEtMzEwLTM2OS02Njk2DQo+ID4+Pj4gMTAyMDEgVyBQaWNvIEJsdmQNCj4g Pj4+PiBMb3MgQW5nZWxlcywgQ0EgOTAwMzUNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gT24gOS8y Ny8xNywgNDowNyBBTSwgIlJvbmkgRXZlbiIgPHJvbmkuZXZlbkBodWF3ZWkuY29tPiB3cm90ZToN Cj4gPj4+Pg0KPiA+Pj4+ICAgSGksDQo+ID4+Pj4NCj4gPj4+PiAgIEkgYWdyZWUgdGhhdCBMUyBp cyBiZXR0ZXIgZml0IGZvciBBTkMNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiAgIEFz IGZvciBBZGFtJ3MgZXhhbXBsZSBpdCBpcyBhbGxvd2VkIGJ5IFJGQzU4ODggdG8gc3BlY2lmeQ0K PiA+Pj4+DQo+ID4+Pj4gICAgICAgICAgIGE9Z3JvdXA6TFMgVjEgVjIgTTEgTTINCj4gPj4+Pg0K PiA+Pj4+ICAgICAgICAgICBhPWdyb3VwOkxTIFYxIE0xDQo+ID4+Pj4NCj4gPj4+PiAgICAgICAg ICAgYT1ncm91cDpMUyBWMiAgTTINCj4gPj4+Pg0KPiA+Pj4+ICAgdGhpcyBpcyBzaW1pbGFyIHRv IFJGQzU5NTYgIHdoaWNoIHJlcGxhY2VkIFJGQzQ3NTYNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4N Cj4gPj4+PiAgIHRoaXMgaXMgbm90IGEgY2xlYW4gd2F5IGJ1dCAgaXMgYWxsb3dlZCBvdGhlcndp c2UgdGhlcmUgaXMgYSBuZWVkDQo+ID4+Pj4gdG8gc3BlY2lmeSBzb21lIFNEUCBhdHRyaWJ1dGUg Zm9yIHNwZWNpZnlpbmcgZGVwZW5kZW5jaWVzLg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+ Pj4+ICAgUm9uaSBFdmVuDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0K PiA+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+DQo+ID4+Pj4+IEZyb206 IFRob21hcyBFZHdhcmRzIFttYWlsdG86VGhvbWFzLkVkd2FyZHNAZm94LmNvbV0NCj4gPj4+Pg0K PiA+Pj4+PiBTZW50OiDXmdeV150g15MgMjcg16HXpNeY157XkdeoIDIwMTcgMDQ6MTMNCj4gPj4+ Pg0KPiA+Pj4+PiBUbzogQWRhbSBSb2FjaDsgVGhlIElFU0cNCj4gPj4+Pg0KPiA+Pj4+PiBDYzog cGF5bG9hZC1jaGFpcnNAaWV0Zi5vcmc7DQo+ID4+Pj4+IGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAt YW5jaWxsYXJ5QGlldGYub3JnOw0KPiA+Pj4+DQo+ID4+Pj4+IHBheWxvYWRAaWV0Zi5vcmc7IGFj YmVnZW5AZ21haWwuY29tDQo+ID4+Pj4NCj4gPj4+Pj4gU3ViamVjdDogUmU6IEFkYW0gUm9hY2gn cyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtYW5jaWxsYXJ5LQ0KPiAxMDoNCj4g Pj4+Pg0KPiA+Pj4+PiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiA+Pj4+DQo+ID4+Pj4+ DQo+ID4+Pj4NCj4gPj4+Pj4gUmVnYXJkaW5nIGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtYW5jaWxs YXJ5LTEwLCBvbiBmdXJ0aGVyIHRob3VnaHQNCj4gPj4+Pj4gSSBiZWxpZXZlDQo+ID4+Pj4NCj4g Pj4+Pj4gdGhhdCBGSUQgZ3JvdXBpbmcgaXMgTk9UIGFwcHJvcHJpYXRlIGZvciBTZWN0aW9uIDQu MSDigJxHcm91cGluZyBBTkMNCj4gPj4+PiBTdHJlYW1zDQo+ID4+Pj4NCj4gPj4+Pj4gd2l0aCBv dGhlciBNZWRpYSBTdHJlYW1z4oCdLg0KPiA+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4NCj4gPj4+Pj4g UkZDIDU4ODggU2VjdGlvbiA4LjQuICjigJxGSUQgU2VtYW50aWNz4oCdKSBzdGF0ZXM6DQo+ID4+ Pj4NCj4gPj4+Pj4NCj4gPj4+Pg0KPiA+Pj4+PiAgICAgIOKAnEl0IGlzIGFzc3VtZWQgdGhhdCB0 aGUgYXBwbGljYXRpb24gdXNlcyBvbmx5IG9uZSBjb2RlYyBhdCBhDQo+ID4+Pj4+IHRpbWUgdG8N Cj4gPj4+Pg0KPiA+Pj4+PiBlbmNvZGUgdGhlIG1lZGlhIHByb2R1Y2VkLiAgVGhpcyBjb2RlYyBN QVkgY2hhbmdlIGR5bmFtaWNhbGx5DQo+ID4+Pj4+IGR1cmluZw0KPiA+Pj4+IHRoZQ0KPiA+Pj4+ DQo+ID4+Pj4+IHNlc3Npb24sIGJ1dCBhdCBhbnkgcGFydGljdWxhciBtb21lbnQsIG9ubHkgb25l IGNvZGVjIGlzIGluIHVzZS7igJ0NCj4gPj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+DQo+ID4+Pj4+IFJG QyA1ODg4IFNlY3Rpb24gOC41LjEgc3RhdGVzOg0KPiA+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4NCj4g Pj4+Pj4gCeKAnEZJRCBzZW1hbnRpY3MgYXJlIHVzZWZ1bCB3aGVuIHRoZSBhcHBsaWNhdGlvbiBv bmx5IHVzZXMgb25lDQo+ID4+Pj4+IGNvZGVjDQo+ID4+Pj4NCj4gPj4+Pj4gYXQgYSB0aW1lLiAg QW4gYXBwbGljYXRpb24gdGhhdCBlbmNvZGVzIHRoZSBzYW1lIG1lZGlhIHVzaW5nDQo+ID4+Pj4+ IGRpZmZlcmVudA0KPiA+Pj4+DQo+ID4+Pj4+IGNvZGVjcyBzaW11bHRhbmVvdXNseSBNVVNUIE5P VCB1c2UgRklEIHRvIGdyb3VwIHRob3NlIG1lZGlhDQo+IGxpbmVzLuKAnQ0KPiA+Pj4+DQo+ID4+ Pj4+DQo+ID4+Pj4NCj4gPj4+Pj4gV2hlbiB3ZSBoYXZlIG9uZSB2aWRlbyBzdHJlYW0gYW5kIG9u ZSBhbmNpbGxhcnkgZGF0YSBzdHJlYW0sDQo+ID4+Pj4+IHNlbmRlcnMNCj4gPj4+PiBhcmUNCj4g Pj4+Pg0KPiA+Pj4+PiBub3Qgc3dpdGNoaW5nIGJldHdlZW4gY29kZWNzLiAgRklEIHJlYWxseSBz b3VuZHMgdG8gbWUgbGlrZSBhDQo+ID4+Pj4+IHNpdHVhdGlvbg0KPiA+Pj4+IHdoZXJlDQo+ID4+ Pj4NCj4gPj4+Pj4geW91IGhhdmUgb25lIG1lZGlhIHN0cmVhbSwgYnV0IHNlbmRlcnMgY291bGQg c2VuZCB0aGF0IHN0cmVhbSBvbmUNCj4gPj4+Pj4gb2YNCj4gPj4+Pg0KPiA+Pj4+PiBtdWx0aXBs ZSBjb2RlY3MsIGJ1dCBub3QgYXQgdGhlIHNhbWUgdGltZS4NCj4gPj4+Pg0KPiA+Pj4+Pg0KPiA+ Pj4+DQo+ID4+Pj4+IENvbXBhcmUgd2l0aCBSRkMgNTg4OCBTZWN0aW9uIDc6DQo+ID4+Pj4NCj4g Pj4+Pj4NCj4gPj4+Pg0KPiA+Pj4+PiAJ4oCcTm90ZSB0aGF0IExTIHNlbWFudGljcyBhcHBseSBu b3Qgb25seSB0byBhIHZpZGVvIHN0cmVhbSB0aGF0IGhhcw0KPiA+Pj4+PiB0bw0KPiA+Pj4+DQo+ ID4+Pj4+IGJlIHN5bmNocm9uaXplZCB3aXRoIGFuIGF1ZGlvIHN0cmVhbTsgdGhlIHBsYXlvdXQg b2YgdHdvIHN0cmVhbXMNCj4gPj4+Pj4gb2YgdGhlDQo+ID4+Pj4NCj4gPj4+Pj4gc2FtZSB0eXBl IGNhbiBiZSBzeW5jaHJvbml6ZWQgYXMgd2VsbC7igJ0NCj4gPj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+ DQo+ID4+Pj4+IFN5bmNocm9uaXplZCBwcmVzZW50YXRpb24gdG8gdGhlIHVzZXIgb2YgYW4gYXVk aW8sIHZpZGVvLCBhbmQgb2YNCj4gPj4+Pj4gY291cnNlDQo+ID4+Pj4NCj4gPj4+Pj4gYW5jaWxs YXJ5IGRhdGEgZmxvdyBpcyBnZW5lcmFsbHkgd2hhdCB3ZSBuZWVkIGZvciBwcm9kdWN0aW9uDQo+ ID4+Pj4+IHRlbGV2aXNpb24NCj4gPj4+Pg0KPiA+Pj4+PiB3b3JrZmxvd3MuDQo+ID4+Pj4NCj4g Pj4+Pj4NCj4gPj4+Pg0KPiA+Pj4+PiBkcmFmdC1pZXRmLXBheWxvYWQtcnRwLWFuY2lsbGFyeS0x MCBTZWN0aW9uIDQuMSBoYXMgdGhlIGV4YW1wbGU6DQo+ID4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pg0K PiA+Pj4+PiAgICAgICB2PTANCj4gPj4+Pg0KPiA+Pj4+PiAgICAgICBvPUFsIDEyMzQ1NiAxMSBJ TiBJUDQNCj4gPj4+PiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cC0NCj4gPj4+Pg0KPiA+Pg0KPiAzQV9faG9zdC5leGFtcGxlLmNvbSZkPUR3SUdhUSZjPXV3 NlRMdTRod2hIZGlHSk9nd2NXRDRBaktReA0KPiA+Pj4+IDZ6dkZjR0VzYmZpWTktDQo+ID4+Pj4N Cj4gPj4NCj4gRUkmcj1sZWtOT09NNW5vVjYxenJQSDNyd1B5aHRObkxMV29MRUhnZDBxdVF4bHk4 Jm09bW10eUxYdHlhDQo+ID4+Pj4NCj4gPj4NCj4gV0hFZzNKWWNxM3hTVkxYelJxa0lWZ1dBSkRn cXlJZ3JlVSZzPVV1T3dDbFhvR0N2R1AycWtzaVYzaDg1SA0KPiA+Pj4+IE5nUVJvX1o3YjBIZ1Uy cVZ3elEmZT0NCj4gPj4+Pg0KPiA+Pj4+PiAgICAgICBzPVByb2Zlc3Npb25hbCBOZXR3b3JrZWQg TWVkaWEgVGVzdA0KPiA+Pj4+DQo+ID4+Pj4+ICAgICAgIGk9QSB0ZXN0IG9mIHN5bmNocm9uaXpl ZCB2aWRlbyBhbmQgQU5DIGRhdGENCj4gPj4+Pg0KPiA+Pj4+PiAgICAgICB0PTAgMA0KPiA+Pj4+ DQo+ID4+Pj4+ICAgICAgIGE9Z3JvdXA6TFMgVjEgTTENCj4gPj4+Pg0KPiA+Pj4+PiAgICAgICBt PXZpZGVvIDUwMDAwIFJUUC9BVlAgOTYNCj4gPj4+Pg0KPiA+Pj4+PiAgICAgICBjPUlOIElQNCBo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0NCj4gPj4+Pg0K PiA+Pg0KPiAzQV9fMjMzLjI1Mi4wLjFfMjU1JmQ9RHdJR2FRJmM9dXc2VEx1NGh3aEhkaUdKT2d3 Y1dENEFqS1F4Nnp2DQo+ID4+Pj4gRmNHRXNiZmlZOS0NCj4gPj4+Pg0KPiA+Pg0KPiBFSSZyPWxl a05PT001bm9WNjF6clBIM3J3UHlodE5uTExXb0xFSGdkMHF1UXhseTgmbT1tbXR5TFh0eWENCj4g Pj4+Pg0KPiA+Pg0KPiBXSEVnM0pZY3EzeFNWTFh6UnFrSVZnV0FKRGdxeUlncmVVJnM9bURqY2Nk RlI4TVduZlFjUF94aU1oYi0NCj4gPj4+PiBiaC1XZWZfMnRLaFJEeVJpbFlVTSZlPQ0KPiA+Pj4+ DQo+ID4+Pj4+ICAgICAgIGE9cnRwbWFwOjk2IHJhdy85MDAwMA0KPiA+Pj4+DQo+ID4+Pj4+ICAg ICAgIGE9Zm10cDo5NiBzYW1wbGluZz1ZQ2JDci00OjI6Mjsgd2lkdGg9MTI4MDsgaGVpZ2h0PTcy MDsNCj4gPj4+Pj4gZGVwdGg9MTANCj4gPj4+Pg0KPiA+Pj4+PiAgICAgICBhPW1pZDpWMQ0KPiA+ Pj4+DQo+ID4+Pj4+ICAgICAgIG09dmlkZW8gNTAwMTAgUlRQL0FWUCA5Nw0KPiA+Pj4+DQo+ID4+ Pj4+ICAgICAgIGM9SU4gSVA0IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwLQ0KPiA+Pj4+DQo+ID4+DQo+IDNBX18yMzMuMjUyLjAuMl8yNTUmZD1Ed0lHYVEm Yz11dzZUTHU0aHdoSGRpR0pPZ3djV0Q0QWpLUXg2enYNCj4gPj4+PiBGY0dFc2JmaVk5LQ0KPiA+ Pj4+DQo+ID4+DQo+IEVJJnI9bGVrTk9PTTVub1Y2MXpyUEgzcndQeWh0Tm5MTFdvTEVIZ2QwcXVR eGx5OCZtPW1tdHlMWHR5YQ0KPiA+Pj4+DQo+ID4+DQo+IFdIRWczSlljcTN4U1ZMWHpScWtJVmdX QUpEZ3F5SWdyZVUmcz03ZTY2ZXdRVkF1TDFZVXEyRnpBU3lFSnANCj4gPj4+PiBxdzdUYzVwOGZP OGxaYlo0dFVvJmU9DQo+ID4+Pj4NCj4gPj4+Pj4gICAgICAgYT1ydHBtYXA6OTcgc21wdGUyOTEv OTAwMDANCj4gPj4+Pg0KPiA+Pj4+PiAgICAgICBhPWZtdHA6OTcgRElEX1NESUQ9ezB4NjEsMHgw Mn07RElEX1NESUQ9ezB4NDEsMHgwNX0NCj4gPj4+Pg0KPiA+Pj4+PiAgICAgICBhPW1pZDpNMQ0K PiA+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4NCj4gPj4+Pj4gQXMgc29tZSBoYXZlIHBvaW50ZWQgb3V0 LCBSVFAgdGltZXN0YW1wcyBhbmQgUlRDUCBwcm92aWRlDQo+IGluaGVyZW50DQo+ID4+Pj4NCj4g Pj4+Pj4gc3luY2hyb25pemF0aW9uIGJldHdlZW4g4oCcbeKAnSBsaW5lcywgYnV0IG9mIGNvdXJz ZSBhcyBSRkMgNTg4OA0KPiA+Pj4+PiBTZWN0aW9uDQo+ID4+Pj4+IDENCj4gPj4+PiBzYXlzDQo+ ID4+Pj4NCj4gPj4+Pj4gd2l0aG91dCBncm91cGluZzog4oCcV2hlbiBhIHNlc3Npb24gZGVzY3Jp cHRpb24gY29udGFpbnMgbW9yZSB0aGFuDQo+ID4+Pj4+IG9uZQ0KPiA+Pj4+ICJtIg0KPiA+Pj4+ DQo+ID4+Pj4+IGxpbmUsIFNEUCBkb2VzIG5vdCBwcm92aWRlIGFueSBtZWFucyB0byBleHByZXNz IGEgcGFydGljdWxhcg0KPiA+Pj4+PiByZWxhdGlvbnNoaXANCj4gPj4+Pg0KPiA+Pj4+PiBiZXR3 ZWVuIHR3byBvciBtb3JlIG9mIHRoZW0u4oCdICDigJxMU+KAnSBncm91cGluZyBtYWtlcyBpdCBw cmV0dHkgY2xlYXINCj4gPj4+Pj4gdGhhdA0KPiA+Pj4+DQo+ID4+Pj4+IHRoZXNlIHN0cmVhbXMg YXJlIGludGVuZGVkIGZvciBzeW5jaHJvbml6ZWQgcHJlc2VudGF0aW9uLg0KPiA+Pj4+DQo+ID4+ Pj4+DQo+ID4+Pj4NCj4gPj4+Pj4gQW4gYWx0ZXJuYXRpdmUgdG8g4oCcTFPigJ0gZ3JvdXBpbmcg aXMgdG8gZHJvcCBhbGwgZ3JvdXBpbmcgaW4gdGhlDQo+ID4+Pj4+IGV4YW1wbGUsIGFuZA0KPiA+ Pj4+IGJlDQo+ID4+Pj4NCj4gPj4+Pj4gdW5jbGVhciBhYm91dCB3aGF0IHRoZXNlIOKAnG3igJ0g bGluZXMgYXJlIGRvaW5nIHRvZ2V0aGVyIGluIHRoZSBzYW1lDQo+IGZpbGU6DQo+ID4+Pj4NCj4g Pj4+Pj4NCj4gPj4+Pg0KPiA+Pj4+PiAgICAgICB2PTANCj4gPj4+Pg0KPiA+Pj4+PiAgICAgICBv PUFsIDEyMzQ1NiAxMSBJTiBJUDQNCj4gPj4+PiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cC0NCj4gPj4+Pg0KPiA+Pg0KPiAzQV9faG9zdC5leGFtcGxlLmNv bSZkPUR3SUdhUSZjPXV3NlRMdTRod2hIZGlHSk9nd2NXRDRBaktReA0KPiA+Pj4+IDZ6dkZjR0Vz YmZpWTktDQo+ID4+Pj4NCj4gPj4NCj4gRUkmcj1sZWtOT09NNW5vVjYxenJQSDNyd1B5aHRObkxM V29MRUhnZDBxdVF4bHk4Jm09bW10eUxYdHlhDQo+ID4+Pj4NCj4gPj4NCj4gV0hFZzNKWWNxM3hT VkxYelJxa0lWZ1dBSkRncXlJZ3JlVSZzPVV1T3dDbFhvR0N2R1AycWtzaVYzaDg1SA0KPiA+Pj4+ IE5nUVJvX1o3YjBIZ1UycVZ3elEmZT0NCj4gPj4+Pg0KPiA+Pj4+PiAgICAgICBzPVByb2Zlc3Np b25hbCBOZXR3b3JrZWQgTWVkaWEgVGVzdA0KPiA+Pj4+DQo+ID4+Pj4+ICAgICAgIGk9QSB0ZXN0 IG9mIHN5bmNocm9uaXplZCB2aWRlbyBhbmQgQU5DIGRhdGENCj4gPj4+Pg0KPiA+Pj4+PiAgICAg ICB0PTAgMA0KPiA+Pj4+DQo+ID4+Pj4+ICAgICAgIG09dmlkZW8gNTAwMDAgUlRQL0FWUCA5Ng0K PiA+Pj4+DQo+ID4+Pj4+ICAgICAgIGM9SU4gSVA0IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwLQ0KPiA+Pj4+DQo+ID4+DQo+IDNBX18yMzMuMjUyLjAuMV8y NTUmZD1Ed0lHYVEmYz11dzZUTHU0aHdoSGRpR0pPZ3djV0Q0QWpLUXg2enYNCj4gPj4+PiBGY0dF c2JmaVk5LQ0KPiA+Pj4+DQo+ID4+DQo+IEVJJnI9bGVrTk9PTTVub1Y2MXpyUEgzcndQeWh0Tm5M TFdvTEVIZ2QwcXVReGx5OCZtPW1tdHlMWHR5YQ0KPiA+Pj4+DQo+ID4+DQo+IFdIRWczSlljcTN4 U1ZMWHpScWtJVmdXQUpEZ3F5SWdyZVUmcz1tRGpjY2RGUjhNV25mUWNQX3hpTWhiLQ0KPiA+Pj4+ IGJoLVdlZl8ydEtoUkR5UmlsWVVNJmU9DQo+ID4+Pj4NCj4gPj4+Pj4gICAgICAgYT1ydHBtYXA6 OTYgcmF3LzkwMDAwDQo+ID4+Pj4NCj4gPj4+Pj4gICAgICAgYT1mbXRwOjk2IHNhbXBsaW5nPVlD YkNyLTQ6MjoyOyB3aWR0aD0xMjgwOyBoZWlnaHQ9NzIwOw0KPiA+Pj4+PiBkZXB0aD0xMA0KPiA+ Pj4+DQo+ID4+Pj4+ICAgICAgIG09dmlkZW8gNTAwMTAgUlRQL0FWUCA5Nw0KPiA+Pj4+DQo+ID4+ Pj4+ICAgICAgIGM9SU4gSVA0IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwLQ0KPiA+Pj4+DQo+ID4+DQo+IDNBX18yMzMuMjUyLjAuMl8yNTUmZD1Ed0lHYVEm Yz11dzZUTHU0aHdoSGRpR0pPZ3djV0Q0QWpLUXg2enYNCj4gPj4+PiBGY0dFc2JmaVk5LQ0KPiA+ Pj4+DQo+ID4+DQo+IEVJJnI9bGVrTk9PTTVub1Y2MXpyUEgzcndQeWh0Tm5MTFdvTEVIZ2QwcXVR eGx5OCZtPW1tdHlMWHR5YQ0KPiA+Pj4+DQo+ID4+DQo+IFdIRWczSlljcTN4U1ZMWHpScWtJVmdX QUpEZ3F5SWdyZVUmcz03ZTY2ZXdRVkF1TDFZVXEyRnpBU3lFSnANCj4gPj4+PiBxdzdUYzVwOGZP OGxaYlo0dFVvJmU9DQo+ID4+Pj4NCj4gPj4+Pj4gICAgICAgYT1ydHBtYXA6OTcgc21wdGUyOTEv OTAwMDANCj4gPj4+Pg0KPiA+Pj4+PiAgICAgICBhPWZtdHA6OTcgRElEX1NESUQ9ezB4NjEsMHgw Mn07RElEX1NESUQ9ezB4NDEsMHgwNX0NCj4gPj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+DQo+ID4+Pj4+ IEJ1dCBJ4oCZbSBzdGlsbCBtb3JlIGNvbWZvcnRhYmxlIHdpdGgga2VlcGluZyB0aGUg4oCcTFPi gJ0gZ3JvdXBpbmcgaW4NCj4gPj4+Pj4gdGhlDQo+ID4+Pj4gZXhhbXBsZQ0KPiA+Pj4+DQo+ID4+ Pj4+IHVubGVzcyB0aGVyZSBhcmUgb2JqZWN0aW9ucy4NCj4gPj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+ DQo+ID4+Pj4+IFRoaXMgYnJpbmdzIHVzIHRvIHRoZSBtYWluIHBvaW50IG9mIEFkYW0gUm9hY2ji gJlzIERJU0NVU1MgaXRlbSwgaG93DQo+ID4+Pj4+IGRvDQo+ID4+Pj4geW91DQo+ID4+Pj4NCj4g Pj4+Pj4gcHJvdmlkZSBtdWx0aS1sZXZlbCBoaWVyYXJjaGljYWwgZ3JvdXBpbmcgaW4gU0RQLiAg SW1hZ2luZSBhIGdyb3VwDQo+ID4+Pj4+IG9mIChhDQo+ID4+Pj4gZ3JvdXANCj4gPj4+Pg0KPiA+ Pj4+PiBvZiB2aWRlbyBhbmQgYW5jaWxsYXJ5IGRhdGEpIGFuZCAoYSBncm91cCBvZiB2aWRlbyBh bmQgYW5jaWxsYXJ5IGRhdGEpLg0KPiA+Pj4+IFRoZXJlDQo+ID4+Pj4NCj4gPj4+Pj4gYWN0dWFs bHkgaXMgYSBjYXNlIG9mIHRoaXMgaW4gcHJvZHVjdGlvbiB0ZWxldmlzaW9uLCB0aGUNCj4gPj4+ Pj4gbXVsdGl2aWV3ZXIgKGUuZy4gc2VlDQo+ID4+Pj4NCj4gPj4+Pj4gaHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiA+Pj4+DQo+ID4+DQo+IDNBX193 d3cuYmxhY2ttYWdpY2Rlc2lnbi5jb21fcHJvZHVjdHNfbXVsdGl2aWV3JmQ9RHdJR2FRJmM9dXc2 VA0KPiA+Pj4+IEx1NGh3aEhkaUdKT2d3Y1dENEFqS1F4Nnp2RmNHRXNiZmlZOS0NCj4gPj4+Pg0K PiA+Pg0KPiBFSSZyPWxla05PT001bm9WNjF6clBIM3J3UHlodE5uTExXb0xFSGdkMHF1UXhseTgm bT1tbXR5TFh0eWENCj4gPj4+Pg0KPiA+Pg0KPiBXSEVnM0pZY3EzeFNWTFh6UnFrSVZnV0FKRGdx eUlncmVVJnM9SWRLb3pTWldib2hLMEZnX0N2WmNtZU5PDQo+ID4+Pj4gNkp4akdadndrbnJDUkxh UVZYOCZlPSkuDQo+ID4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pg0KPiA+Pj4+PiBVbmZvcnR1bmF0ZWx5 LCBJIHJlYWxseSBjYW7igJl0IGZpbmQgYW55IFNEUCBtZWNoYW5pc20gdG8gZGVzY3JpYmUNCj4g Pj4+Pj4gbXVsdGktDQo+ID4+Pj4gbGV2ZWwNCj4gPj4+Pg0KPiA+Pj4+PiBoaWVyYXJjaHkuICBS RkMgNDc5NiDigJxUaGUgU2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCAoU0RQKQ0KPiA+Pj4+ PiBDb250ZW50DQo+ID4+Pj4NCj4gPj4+Pj4gQXR0cmlidXRl4oCdIGlzIGFib3V0IHRoZSBiZXN0 IEkgY2FuIGZpbmQsIHdoZXJlIHN5bmNocm9uaXplZA0KPiA+Pj4+PiBtdWx0aW1lZGlhDQo+ID4+ Pj4gKHN1Y2gNCj4gPj4+Pg0KPiA+Pj4+PiBhcyDigJxzbGlkZXPigJ0sIOKAnHNwZWFrZXLigJ0s IOKAnG1haW7igJ0sIGV0Yy4pIGlzIHByZXNlbnRlZC4gIEJ1dCB0aGlzIGlzIGENCj4gPj4+Pj4g dmVyeSBsaW1pdGVkDQo+ID4+Pj4gc2V0DQo+ID4+Pj4NCj4gPj4+Pj4gb2YgdmFsdWVzLiAgUkZD IDU1ODMg4oCcU2lnbmFsaW5nIE1lZGlhIERlY29kaW5nIERlcGVuZGVuY3kgaW4gdGhlDQo+ID4+ Pj4gU2Vzc2lvbg0KPiA+Pj4+DQo+ID4+Pj4+IERlc2NyaXB0aW9uIFByb3RvY29sIChTRFAp4oCd IGhhcyB2YXJpb3VzIGRlcGVuZGVuY2llcyBvZiBzdHJlYW1zLA0KPiA+Pj4+PiBidXQNCj4gPj4+ PiB0aGlzIGlzDQo+ID4+Pj4NCj4gPj4+Pj4gZm9yIGxheWVyZWQgb3IgbXVsdGlwbGUgZGVzY3Jp cHRpdmUgbWVkaWEgY29kaW5nLiAgTmVpdGhlciBvZg0KPiA+Pj4+PiB0aGVzZSBzZWVtcw0KPiA+ Pj4+DQo+ID4+Pj4+IGFwcHJvcHJpYXRlLg0KPiA+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4NCj4gPj4+ Pj4gUGVyaGFwcyB0aGlzIGlzc3VlIG5lZWRzIHRvIGJlIGJyb3VnaHQgdXAgaW4gTXVsdGlwYXJ0 eSBNdWx0aW1lZGlhDQo+ID4+Pj4gU2Vzc2lvbg0KPiA+Pj4+DQo+ID4+Pj4+IENvbnRyb2wgKG1t dXNpYykgV0csIGJ1dCBJ4oCZbSBub3Qgc3VyZSB0aGF0IGl0IGlzIHdpc2UgdG8gaG9sZCB1cA0K PiA+Pj4+PiB0aGUgQU5DDQo+ID4+Pj4gUlRQDQo+ID4+Pj4NCj4gPj4+Pj4gUGF5bG9hZCBvdmVy IHRoaXMuDQo+ID4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pg0KPiA+Pj4+PiBUaGFua3MgZXZlcnlvbmUh DQo+ID4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pg0KPiA+Pj4+PiAtVGhvbWFzDQo+ID4+Pj4NCj4gPj4+ Pj4NCj4gPj4+Pg0KPiA+Pj4+PiAtLQ0KPiA+Pj4+DQo+ID4+Pj4+IFRob21hcyBFZHdhcmRzDQo+ ID4+Pj4NCj4gPj4+Pj4gRk9YIE5ldHdvcmtzIEVuZ2luZWVyaW5nICYgT3BlcmF0aW9ucw0KPiA+ Pj4+DQo+ID4+Pj4+IFZQIEVuZ2luZWVyaW5nICYgRGV2ZWxvcG1lbnQNCj4gPj4+Pg0KPiA+Pj4+ PiB0aG9tYXMuZWR3YXJkc0Bmb3guY29tDQo+ID4+Pj4NCj4gPj4+Pj4gKzEtMzEwLTM2OS02Njk2 DQo+ID4+Pj4NCj4gPj4+Pj4gMTAyMDEgVyBQaWNvIEJsdmQNCj4gPj4+Pg0KPiA+Pj4+PiBMb3Mg QW5nZWxlcywgQ0EgOTAwMzUNCj4gPj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+DQo+ID4+Pj4+DQo+ID4+ Pj4NCj4gPj4+Pj4NCj4gPj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+ Pj4+DQo+ID4+Pg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPj4+IHBheWxvYWQgbWFpbGluZyBsaXN0DQo+ID4+PiBwYXlsb2FkQGlldGYu b3JnDQo+ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BheWxvYWQN Cj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gLS0NCj4gPj4gQ29saW4gUGVya2lucw0KPiA+PiBodHRw czovL2NzcGVya2lucy5vcmcvDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4NCj4gDQo+IA0KPiANCj4g LS0NCj4gQ29saW4gUGVya2lucw0KPiBodHRwczovL2NzcGVya2lucy5vcmcvDQo+IA0KPiANCj4g DQoNCg== From nobody Tue Oct 3 14:42:08 2017 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 B225A1321D8; Tue, 3 Oct 2017 14:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 784pZjQYaKRS; Tue, 3 Oct 2017 14:42:03 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE89A13219B; Tue, 3 Oct 2017 14:42:02 -0700 (PDT) Received: from [81.187.2.149] (port=44155 helo=[192.168.0.71]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1dzUwu-0008Pz-SI; Tue, 03 Oct 2017 22:41:57 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Colin Perkins In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD810CE3@DGGEMM506-MBX.china.huawei.com> Date: Tue, 3 Oct 2017 22:41:40 +0100 Cc: Thomas Edwards , Adam Roach , "payload-chairs@ietf.org" , "draft-ietf-payload-rtp-ancillary@ietf.org" , "payload@ietf.org" , "acbegen@gmail.com" Content-Transfer-Encoding: quoted-printable Message-Id: <0394089C-455C-486E-95C1-C8B2379482E0@csperkins.org> References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <3B259563-1075-4C41-A832-D7633C39173B@foxeg.com> <61440eb5-32c3-3696-be38-8dc7c4eaf72f@nostrum.com> <863974D7-E112-4794-AD4D-C39C99BD40C9@foxeg.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> <6E58094ECC8D8344914996DAD28F1CCD80FC21@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD810751@DGGEMM506-MBX.china.huawei.com> <4D3BF24A-2927-4F9A-A435-7DA6A9F777D7@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810BCC@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD810CE3@DGGEMM506-MBX.china.huawei.com> To: Roni Even X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 03 Oct 2017 21:42:07 -0000 Roni, LS is unnecessary, yes. Some people like signalling. Colin > On 3 Oct 2017, at 22:01, Roni Even wrote: >=20 > Colin, > I re-read RFC5888 section 7 and 7.1. I think that LS for two RTP = streams that need to be synchronized will work without LS. The LS is = needed for case when grouping m-lines that are not RTP, for example an = RTP with a m=3Dapplication or like in section 7.1 you have three streams = probably from the same source but only two must be synchronized. For the = case where there are for example one video and one audio streams that = will be synchronized based on the CNAME, I am not sure what is the value = of LS except that it provides signaling plane information that these are = the audio and video that must be synchronized even if they do not have = the same CNAME and how to synchronize is an application issue (for = example the receiver can delay the audio , use case audio mixing in = the video switching MCU topology ) > Roni >=20 >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org] >> Sent: =D7=99=D7=95=D7=9D =D7=92 03 =D7=90=D7=95=D7=A7=D7=98=D7=95=D7=91= =D7=A8 2017 21:46 >> To: Roni Even >> Cc: Thomas Edwards; Adam Roach; payload-chairs@ietf.org; draft-ietf- >> payload-rtp-ancillary@ietf.org; payload@ietf.org; acbegen@gmail.com >> Subject: Re: [payload] Adam Roach's Discuss on = draft-ietf-payload-rtp- >> ancillary-10: (with DISCUSS and COMMENT) >>=20 >> No, I think it=E2=80=99s orthogonal to grouping. If the CNAME was = sufficient, then we >> wouldn=E2=80=99t need the LS grouping method. >>=20 >> Colin >>=20 >>=20 >>=20 >>> On 3 Oct 2017, at 19:00, Roni Even wrote: >>>=20 >>> Hi Colin, >>> So maybe the right direction is that there is no need for grouping = at all in >> this case and just use the same CNAME in RTCP. >>> Roni >>>=20 >>>> -----Original Message----- >>>> From: Colin Perkins [mailto:csp@csperkins.org] >>>> Sent: =D7=99=D7=95=D7=9D =D7=92 03 =D7=90=D7=95=D7=A7=D7=98=D7=95=D7=91= =D7=A8 2017 19:59 >>>> To: Roni Even >>>> Cc: Thomas Edwards; Adam Roach; payload-chairs@ietf.org; = draft-ietf- >>>> payload-rtp-ancillary@ietf.org; payload@ietf.org; acbegen@gmail.com >>>> Subject: Re: [payload] Adam Roach's Discuss on >>>> draft-ietf-payload-rtp- >>>> ancillary-10: (with DISCUSS and COMMENT) >>>>=20 >>>> Roni, >>>>=20 >>>> The requirement for RTP, in general, is that streams that are to be >>>> synchronised MUST have the same RTCP CNAME. It might be appropriate >>>> to remind readers of that, but it=E2=80=99s independent on the = grouping >> framework. >>>>=20 >>>> How that CNAME is chosen doesn=E2=80=99t matter for the purposes of >>>> synchronisation, provided the SSRCs that are to be synchronised use >>>> the same CNAME. The suggestions in RFC 7022 are appropriate, but >>>> there=E2=80=99s no reason to mandate them, or require a particular = one of >>>> those suggestions be used. >>>>=20 >>>> Colin >>>>=20 >>>>=20 >>>>=20 >>>>> On 1 Oct 2017, at 12:25, Roni Even wrote: >>>>>=20 >>>>> Hi Thomas, >>>>> I think that you should also have in the grouping section a >>>>> recommendation to use the same persistent CNAME (maybe short >> term?) >>>>> for the ANC and video stream see RFC 7022 this is required in RTCP >>>>> if these RTP streams need to be synchronized (RFC3550) Roni >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Thomas Edwards [mailto:Thomas.Edwards@fox.com] >>>>>> Sent: =D7=99=D7=95=D7=9D =D7=93 27 =D7=A1=D7=A4=D7=98=D7=9E=D7=91=D7= =A8 2017 18:47 >>>>>> To: Roni Even; Adam Roach; The IESG >>>>>> Cc: payload-chairs@ietf.org; >>>>>> draft-ietf-payload-rtp-ancillary@ietf.org; >>>>>> payload@ietf.org; acbegen@gmail.com >>>>>> Subject: Re: Adam Roach's Discuss on = draft-ietf-payload-rtp-ancillary- >> 10: >>>>>> (with DISCUSS and COMMENT) >>>>>>=20 >>>>>> Roni, thanks for the feedback on LS! >>>>>>=20 >>>>>> I=E2=80=99m still not sure if it is appropriate to include the = hierarchical >>>>>> grouping SDP example in draft-ietf-payload-rtp-ancillary. I >>>>>> suspect it could >>>> be confusing. >>>>>>=20 >>>>>> However, I will note that the Alliance for IP Media Solutions >>>>>> (http://aimsalliance.org) Technical Committee is considering work >>>>>> on documenting different SDP groupings for live television >>>>>> production scenarios, so it is possible that a future I-D will be >>>>>> submitted that could include a range of SDP applications in this >>>>>> area, perhaps including documentation of Adam Roach=E2=80=99s = scenario. >>>>>>=20 >>>>>> I can go ahead and upload a draft-ietf-payload-rtp-ancillary-11 >>>>>> based on the IESG feedback. >>>>>>=20 >>>>>> -Thomas >>>>>>=20 >>>>>> -- >>>>>> Thomas Edwards >>>>>> FOX Networks Engineering & Operations VP Engineering & >> Development >>>>>> thomas.edwards@fox.com >>>>>> +1-310-369-6696 >>>>>> 10201 W Pico Blvd >>>>>> Los Angeles, CA 90035 >>>>>>=20 >>>>>>=20 >>>>>> On 9/27/17, 4:07 AM, "Roni Even" wrote: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> I agree that LS is better fit for ANC >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> As for Adam's example it is allowed by RFC5888 to specify >>>>>>=20 >>>>>> a=3Dgroup:LS V1 V2 M1 M2 >>>>>>=20 >>>>>> a=3Dgroup:LS V1 M1 >>>>>>=20 >>>>>> a=3Dgroup:LS V2 M2 >>>>>>=20 >>>>>> this is similar to RFC5956 which replaced RFC4756 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> this is not a clean way but is allowed otherwise there is a = need >>>>>> to specify some SDP attribute for specifying dependencies. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Roni Even >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>=20 >>>>>>> From: Thomas Edwards [mailto:Thomas.Edwards@fox.com] >>>>>>=20 >>>>>>> Sent: =D7=99=D7=95=D7=9D =D7=93 27 =D7=A1=D7=A4=D7=98=D7=9E=D7=91=D7= =A8 2017 04:13 >>>>>>=20 >>>>>>> To: Adam Roach; The IESG >>>>>>=20 >>>>>>> Cc: payload-chairs@ietf.org; >>>>>>> draft-ietf-payload-rtp-ancillary@ietf.org; >>>>>>=20 >>>>>>> payload@ietf.org; acbegen@gmail.com >>>>>>=20 >>>>>>> Subject: Re: Adam Roach's Discuss on = draft-ietf-payload-rtp-ancillary- >> 10: >>>>>>=20 >>>>>>> (with DISCUSS and COMMENT) >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> Regarding draft-ietf-payload-rtp-ancillary-10, on further = thought >>>>>>> I believe >>>>>>=20 >>>>>>> that FID grouping is NOT appropriate for Section 4.1 =E2=80=9CGrou= ping ANC >>>>>> Streams >>>>>>=20 >>>>>>> with other Media Streams=E2=80=9D. >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> RFC 5888 Section 8.4. (=E2=80=9CFID Semantics=E2=80=9D) states: >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> =E2=80=9CIt is assumed that the application uses only one = codec at a >>>>>>> time to >>>>>>=20 >>>>>>> encode the media produced. This codec MAY change dynamically >>>>>>> during >>>>>> the >>>>>>=20 >>>>>>> session, but at any particular moment, only one codec is in = use.=E2=80=9D >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> RFC 5888 Section 8.5.1 states: >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> =E2=80=9CFID semantics are useful when the application = only uses one >>>>>>> codec >>>>>>=20 >>>>>>> at a time. An application that encodes the same media using >>>>>>> different >>>>>>=20 >>>>>>> codecs simultaneously MUST NOT use FID to group those media >> lines.=E2=80=9D >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> When we have one video stream and one ancillary data stream, >>>>>>> senders >>>>>> are >>>>>>=20 >>>>>>> not switching between codecs. FID really sounds to me like a >>>>>>> situation >>>>>> where >>>>>>=20 >>>>>>> you have one media stream, but senders could send that stream = one >>>>>>> of >>>>>>=20 >>>>>>> multiple codecs, but not at the same time. >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> Compare with RFC 5888 Section 7: >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> =E2=80=9CNote that LS semantics apply not only to a = video stream that has >>>>>>> to >>>>>>=20 >>>>>>> be synchronized with an audio stream; the playout of two streams >>>>>>> of the >>>>>>=20 >>>>>>> same type can be synchronized as well.=E2=80=9D >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> Synchronized presentation to the user of an audio, video, and of >>>>>>> course >>>>>>=20 >>>>>>> ancillary data flow is generally what we need for production >>>>>>> television >>>>>>=20 >>>>>>> workflows. >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> draft-ietf-payload-rtp-ancillary-10 Section 4.1 has the example: >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> v=3D0 >>>>>>=20 >>>>>>> o=3DAl 123456 11 IN IP4 >>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp- >>>>>>=20 >>>>=20 >> 3A__host.example.com&d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx >>>>>> 6zvFcGEsbfiY9- >>>>>>=20 >>>>=20 >> EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DmmtyLXtya >>>>>>=20 >>>>=20 >> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=3DUuOwClXoGCvGP2qksiV3h85H >>>>>> NgQRo_Z7b0HgU2qVwzQ&e=3D >>>>>>=20 >>>>>>> s=3DProfessional Networked Media Test >>>>>>=20 >>>>>>> i=3DA test of synchronized video and ANC data >>>>>>=20 >>>>>>> t=3D0 0 >>>>>>=20 >>>>>>> a=3Dgroup:LS V1 M1 >>>>>>=20 >>>>>>> m=3Dvideo 50000 RTP/AVP 96 >>>>>>=20 >>>>>>> c=3DIN IP4 https://urldefense.proofpoint.com/v2/url?u=3Dhttp-= >>>>>>=20 >>>>=20 >> 3A__233.252.0.1_255&d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zv >>>>>> FcGEsbfiY9- >>>>>>=20 >>>>=20 >> EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DmmtyLXtya >>>>>>=20 >>>>=20 >> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=3DmDjccdFR8MWnfQcP_xiMhb- >>>>>> bh-Wef_2tKhRDyRilYUM&e=3D >>>>>>=20 >>>>>>> a=3Drtpmap:96 raw/90000 >>>>>>=20 >>>>>>> a=3Dfmtp:96 sampling=3DYCbCr-4:2:2; width=3D1280; = height=3D720; >>>>>>> depth=3D10 >>>>>>=20 >>>>>>> a=3Dmid:V1 >>>>>>=20 >>>>>>> m=3Dvideo 50010 RTP/AVP 97 >>>>>>=20 >>>>>>> c=3DIN IP4 https://urldefense.proofpoint.com/v2/url?u=3Dhttp-= >>>>>>=20 >>>>=20 >> 3A__233.252.0.2_255&d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zv >>>>>> FcGEsbfiY9- >>>>>>=20 >>>>=20 >> EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DmmtyLXtya >>>>>>=20 >>>>=20 >> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=3D7e66ewQVAuL1YUq2FzASyEJp >>>>>> qw7Tc5p8fO8lZbZ4tUo&e=3D >>>>>>=20 >>>>>>> a=3Drtpmap:97 smpte291/90000 >>>>>>=20 >>>>>>> a=3Dfmtp:97 DID_SDID=3D{0x61,0x02};DID_SDID=3D{0x41,0x05} >>>>>>=20 >>>>>>> a=3Dmid:M1 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> As some have pointed out, RTP timestamps and RTCP provide >> inherent >>>>>>=20 >>>>>>> synchronization between =E2=80=9Cm=E2=80=9D lines, but of course = as RFC 5888 >>>>>>> Section >>>>>>> 1 >>>>>> says >>>>>>=20 >>>>>>> without grouping: =E2=80=9CWhen a session description contains = more than >>>>>>> one >>>>>> "m" >>>>>>=20 >>>>>>> line, SDP does not provide any means to express a particular >>>>>>> relationship >>>>>>=20 >>>>>>> between two or more of them.=E2=80=9D =E2=80=9CLS=E2=80=9D = grouping makes it pretty clear >>>>>>> that >>>>>>=20 >>>>>>> these streams are intended for synchronized presentation. >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> An alternative to =E2=80=9CLS=E2=80=9D grouping is to drop all = grouping in the >>>>>>> example, and >>>>>> be >>>>>>=20 >>>>>>> unclear about what these =E2=80=9Cm=E2=80=9D lines are doing = together in the same >> file: >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> v=3D0 >>>>>>=20 >>>>>>> o=3DAl 123456 11 IN IP4 >>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp- >>>>>>=20 >>>>=20 >> 3A__host.example.com&d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx >>>>>> 6zvFcGEsbfiY9- >>>>>>=20 >>>>=20 >> EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DmmtyLXtya >>>>>>=20 >>>>=20 >> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=3DUuOwClXoGCvGP2qksiV3h85H >>>>>> NgQRo_Z7b0HgU2qVwzQ&e=3D >>>>>>=20 >>>>>>> s=3DProfessional Networked Media Test >>>>>>=20 >>>>>>> i=3DA test of synchronized video and ANC data >>>>>>=20 >>>>>>> t=3D0 0 >>>>>>=20 >>>>>>> m=3Dvideo 50000 RTP/AVP 96 >>>>>>=20 >>>>>>> c=3DIN IP4 https://urldefense.proofpoint.com/v2/url?u=3Dhttp-= >>>>>>=20 >>>>=20 >> 3A__233.252.0.1_255&d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zv >>>>>> FcGEsbfiY9- >>>>>>=20 >>>>=20 >> EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DmmtyLXtya >>>>>>=20 >>>>=20 >> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=3DmDjccdFR8MWnfQcP_xiMhb- >>>>>> bh-Wef_2tKhRDyRilYUM&e=3D >>>>>>=20 >>>>>>> a=3Drtpmap:96 raw/90000 >>>>>>=20 >>>>>>> a=3Dfmtp:96 sampling=3DYCbCr-4:2:2; width=3D1280; = height=3D720; >>>>>>> depth=3D10 >>>>>>=20 >>>>>>> m=3Dvideo 50010 RTP/AVP 97 >>>>>>=20 >>>>>>> c=3DIN IP4 https://urldefense.proofpoint.com/v2/url?u=3Dhttp-= >>>>>>=20 >>>>=20 >> 3A__233.252.0.2_255&d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zv >>>>>> FcGEsbfiY9- >>>>>>=20 >>>>=20 >> EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DmmtyLXtya >>>>>>=20 >>>>=20 >> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=3D7e66ewQVAuL1YUq2FzASyEJp >>>>>> qw7Tc5p8fO8lZbZ4tUo&e=3D >>>>>>=20 >>>>>>> a=3Drtpmap:97 smpte291/90000 >>>>>>=20 >>>>>>> a=3Dfmtp:97 DID_SDID=3D{0x61,0x02};DID_SDID=3D{0x41,0x05} >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> But I=E2=80=99m still more comfortable with keeping the =E2=80=9CL= S=E2=80=9D grouping in >>>>>>> the >>>>>> example >>>>>>=20 >>>>>>> unless there are objections. >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> This brings us to the main point of Adam Roach=E2=80=99s DISCUSS = item, how >>>>>>> do >>>>>> you >>>>>>=20 >>>>>>> provide multi-level hierarchical grouping in SDP. Imagine a = group >>>>>>> of (a >>>>>> group >>>>>>=20 >>>>>>> of video and ancillary data) and (a group of video and ancillary = data). >>>>>> There >>>>>>=20 >>>>>>> actually is a case of this in production television, the >>>>>>> multiviewer (e.g. see >>>>>>=20 >>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >>>>>>=20 >>>>=20 >> 3A__www.blackmagicdesign.com_products_multiview&d=3DDwIGaQ&c=3Duw6T >>>>>> Lu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9- >>>>>>=20 >>>>=20 >> EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DmmtyLXtya >>>>>>=20 >>>>=20 >> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=3DIdKozSZWbohK0Fg_CvZcmeNO >>>>>> 6JxjGZvwknrCRLaQVX8&e=3D). >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> Unfortunately, I really can=E2=80=99t find any SDP mechanism to = describe >>>>>>> multi- >>>>>> level >>>>>>=20 >>>>>>> hierarchy. RFC 4796 =E2=80=9CThe Session Description Protocol = (SDP) >>>>>>> Content >>>>>>=20 >>>>>>> Attribute=E2=80=9D is about the best I can find, where = synchronized >>>>>>> multimedia >>>>>> (such >>>>>>=20 >>>>>>> as =E2=80=9Cslides=E2=80=9D, =E2=80=9Cspeaker=E2=80=9D, = =E2=80=9Cmain=E2=80=9D, etc.) is presented. But this is a >>>>>>> very limited >>>>>> set >>>>>>=20 >>>>>>> of values. RFC 5583 =E2=80=9CSignaling Media Decoding = Dependency in the >>>>>> Session >>>>>>=20 >>>>>>> Description Protocol (SDP)=E2=80=9D has various dependencies of = streams, >>>>>>> but >>>>>> this is >>>>>>=20 >>>>>>> for layered or multiple descriptive media coding. Neither of >>>>>>> these seems >>>>>>=20 >>>>>>> appropriate. >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> Perhaps this issue needs to be brought up in Multiparty = Multimedia >>>>>> Session >>>>>>=20 >>>>>>> Control (mmusic) WG, but I=E2=80=99m not sure that it is wise to = hold up >>>>>>> the ANC >>>>>> RTP >>>>>>=20 >>>>>>> Payload over this. >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> Thanks everyone! >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> -Thomas >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> -- >>>>>>=20 >>>>>>> Thomas Edwards >>>>>>=20 >>>>>>> FOX Networks Engineering & Operations >>>>>>=20 >>>>>>> VP Engineering & Development >>>>>>=20 >>>>>>> thomas.edwards@fox.com >>>>>>=20 >>>>>>> +1-310-369-6696 >>>>>>=20 >>>>>>> 10201 W Pico Blvd >>>>>>=20 >>>>>>> Los Angeles, CA 90035 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> payload mailing list >>>>> payload@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/payload >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Colin Perkins >>>> https://csperkins.org/ >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >>=20 >> -- >> Colin Perkins >> https://csperkins.org/ >>=20 >>=20 >>=20 >=20 --=20 Colin Perkins https://csperkins.org/ From nobody Tue Oct 3 14:45:50 2017 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 5836D132F30; Tue, 3 Oct 2017 14:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPD9ZrFiEaYg; Tue, 3 Oct 2017 14:45:46 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B705213219B; Tue, 3 Oct 2017 14:45:46 -0700 (PDT) Received: from [81.187.2.149] (port=45674 helo=[192.168.0.71]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1dzV0W-0000LR-DQ; Tue, 03 Oct 2017 22:45:41 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Colin Perkins In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD810CC5@DGGEMM506-MBX.china.huawei.com> Date: Tue, 3 Oct 2017 22:45:36 +0100 Cc: Adam Roach , Thomas Edwards , The IESG , "payload-chairs@ietf.org" , "draft-ietf-payload-rtp-ancillary@ietf.org" , "payload@ietf.org" , "acbegen@gmail.com" Content-Transfer-Encoding: quoted-printable Message-Id: <04D71781-0E87-461C-BDA0-D44F94FED1A0@csperkins.org> References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <3B259563-1075-4C41-A832-D7633C39173B@foxeg.com> <61440eb5-32c3-3696-be38-8dc7c4eaf72f@nostrum.com> <863974D7-E112-4794-AD4D-C39C99BD40C9@foxeg.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> <6E58094ECC8D8344914996DAD28F1CCD810BB8@DGGEMM506-MBX.china.huawei.com> <37F6B554-530B-4A30-B66F-A70D026DD2B8@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810CC5@DGGEMM506-MBX.china.huawei.com> To: Roni Even X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 03 Oct 2017 21:45:48 -0000 > On 3 Oct 2017, at 21:40, Roni Even wrote: >=20 > Hi Colin, > I re-read RFC5888 and tried to understand what is the difference = between FID and LS > I was trying to understand what is a flow and from section 8.3=20 >=20 > "The previous examples show that the definition of a media stream in > [RFC2326] does not cover some scenarios. It cannot be assumed that = a > single media instance maps into a single RTP session. Therefore, we > introduce the definition of a media flow: >=20 > A media flow consists of a single media instance, e.g., an audio > stream or a video stream as well as a single whiteboard or shared > application group. When using RTP, a media flow comprises one or > more RTP sessions." >=20 > It looks to me that a media flow is a SINGLE media stream that spans = over multiple RTP sessions (the term media instance is a what we call a = media stream in the taxonomy). Section 8.5 (8.5.1) enhance this by = saying when FID cannot be used " FID semantics are useful when the = application only uses one codec at a time" which again describe a = flow as a single media stream. >=20 > I am not sure how ANC and the video relates to each other this is what = I am asking Thomas to be more clear. If the video and ANC are one stream = over multiple RTP sessions FID is correct otherwise I think the LS = should be used. My understanding is that the video and ancillary data are the same = stream. In broadcast TV the ancillary data is sent in-band, in the = blanking intervals. > My reading on the ancillary draft is that ANC and the video are what = we call a single RTP stream but this is not what Thomas says. I expect one could send the ancillary data using the same SSRC, and the = same 5-tuple, as the media data (in the same way comfort noise and = speech data can be sent), in which case you don=E2=80=99t need the = grouping. If they=E2=80=99re sent as separate RTP streams, with separate = m=3D lines, then you need grouping. I believe FID makes sense for this. --=20 Colin Perkins https://csperkins.org/ From nobody Tue Oct 3 15:19:27 2017 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 6D34A133226; Tue, 3 Oct 2017 15:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7TaZJ3R9tUp; Tue, 3 Oct 2017 15:19:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A60513308D; Tue, 3 Oct 2017 15:19:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPV78217; Tue, 03 Oct 2017 22:19:15 +0000 (GMT) Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 3 Oct 2017 23:19:15 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.187]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0301.000; Wed, 4 Oct 2017 06:19:05 +0800 From: Roni Even To: Colin Perkins CC: Adam Roach , Thomas Edwards , The IESG , "payload-chairs@ietf.org" , "draft-ietf-payload-rtp-ancillary@ietf.org" , "payload@ietf.org" , "acbegen@gmail.com" Thread-Topic: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) Thread-Index: AQHTPJDygbS9/SM8kEOuXwy9wqTbHqLSsBAg Date: Tue, 3 Oct 2017 22:19:05 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD810D79@DGGEMM506-MBX.china.huawei.com> References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <3B259563-1075-4C41-A832-D7633C39173B@foxeg.com> <61440eb5-32c3-3696-be38-8dc7c4eaf72f@nostrum.com> <863974D7-E112-4794-AD4D-C39C99BD40C9@foxeg.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> <6E58094ECC8D8344914996DAD28F1CCD810BB8@DGGEMM506-MBX.china.huawei.com> <37F6B554-530B-4A30-B66F-A70D026DD2B8@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810CC5@DGGEMM506-MBX.china.huawei.com> <04D71781-0E87-461C-BDA0-D44F94FED1A0@csperkins.org> In-Reply-To: <04D71781-0E87-461C-BDA0-D44F94FED1A0@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.28] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59D40CE3.01A2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.187, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 76507c793da638ed63087e0afbd24878 Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 03 Oct 2017 22:19:20 -0000 Q29saW4sDQpXZSBzdGlsbCBuZWVkIHNvbWUgZmVlZGJhY2sgZnJvbSBUaG9tYXMsIGluIGEgcHJl dmlvdXMgZW1haWwgcmVzcG9uc2UgdG8gQWRhbSBoZSBnYXZlIGEgcmVhc29uIGZvciB1c2luZyBt dWx0aXBsZSBSVFAgc2Vzc2lvbnM6DQoNCiJUaGUgY2hhbGxlbmdlIGlzIHRoYXQgdGhlIHVzZSBj YXNlIG9mIHRoZSBBbmNpbGxhcnkgSS1EIHdpdGhpbiB0aGUgU01QVEUgU1QgMjExMCBhcmNoaXRl Y3R1cmUgd291bGQgZ2VuZXJhbGx5IHJlcXVpcmUgc2VwYXJhdGUgbmV0d29yayBkZXN0aW5hdGlv biBhZGRyZXNzZXMgZm9yIHRoZSBkaWZmZXJlbnQgZWxlbWVudHMgKHZpZGVvLCBhdWRpbywgYW5j aWxsYXJ5IGRhdGEpIHNvIHRoZXkgY2FuIGJlIGZsZXhpYmx5IGNvbXBvc2VkIHdpdGhpbiBicm9h ZGNhc3QgcGxhbnRzIGF0IHRoZSBuZXR3b3JrIGxldmVsLiAgWW91ciBhbHRlcm5hdGl2ZSBTRFAg ZXhhbXBsZSBhcHBlYXJzIHRvIHBsYWNlIGJvdGggdGhlIHZpZGVvIGFuZCB0aGUgYW5jaWxsYXJ5 IGRhdGEgb250byB0aGUgc2FtZSBkZXN0aW5hdGlvbiBhZGRyZXNzICgyMzMuMjUyLjAuMSkuICBJ cyB0aGVyZSBhbiBhcHByb3ByaWF0ZSBTRFAgbWVjaGFuaXNtIHRvIGNvbW11bmljYXRlIHRoZSBp bnRpbWF0ZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgUlRQIHN0cmVhbXMsIGJ1dCBhbHNvIGhh dmUgdGhlbSB0cmFuc21pdHRlZCBvbiBzZXBhcmF0ZSBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzZXMg KGFuZCBzeW5jaHJvbml6ZWQpPw0KDQooSW4gcHJvZHVjdGlvbiBwcmFjdGljZSwgdGhpcyBtYXkg bm90IGJlIGEgc2lnbmlmaWNhbnQgaXNzdWUgYXMgdGhlIFJUUCBzdHJlYW1zIHRvIGJlIGNvbWJp bmVkIGJ5IElQIHJlY2VpdmVycyBmb3IgY29udmVyc2lvbiB0byBTREkvSERNSSBvciBmb3IgaW5w dXQgdG8gYSBkaXN0cmlidXRpb24gZW5jb2RlciBtYXkgYmUgc3BlY2lmaWVkIGJ5IGEgY29udHJv bCBzeXN0ZW0gZGlyZWN0bHkgdG8gdGhlIHJlY2VpdmVyIHVzaW5nIGFuIEFQSSB0aGF0IGlzbuKA mXQganVzdCBhbiBTRFAgZmlsZS4pIg0KDQpJIHdhbnQgdG8gYXNzdW1lIHRoYXQgYnkgZGlmZmVy ZW50IGRlc3RpbmF0aW9uIGFkZHJlc3NlcyBpdCByZWZlcnMgdG8gbXVsdGljYXN0IGFkZHJlc3Nl cyBsaWtlIGFib3ZlIGFuZCBub3QgdG8gZGlmZmVyZW50IHVuaWNhc3QgSVAgYWRkcmVzc2VzLiAN CllvdSBhcmUgcmlnaHQgdGhhdCBmb3IgdW5pY2FzdCBpdCB3aWxsIG1ha2Ugc2Vuc2UgdG8gdXNl IHRoZSBzYW1lIFJUUCBzZXNzaW9uIHdpdGggdGhlIHNhbWUgU1NSQy4NCg0KUm9uaQ0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IENvbGluIFBlcmtpbnMgW21haWx0bzpj c3BAY3NwZXJraW5zLm9yZ10NCj4gU2VudDog15nXldedwqDXkyAwNCDXkNeV16fXmNeV15HXqCAy MDE3IDAwOjQ2DQo+IFRvOiBSb25pIEV2ZW4NCj4gQ2M6IEFkYW0gUm9hY2g7IFRob21hcyBFZHdh cmRzOyBUaGUgSUVTRzsgcGF5bG9hZC1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LQ0KPiBpZXRmLXBh eWxvYWQtcnRwLWFuY2lsbGFyeUBpZXRmLm9yZzsgcGF5bG9hZEBpZXRmLm9yZzsgYWNiZWdlbkBn bWFpbC5jb20NCj4gU3ViamVjdDogUmU6IFtwYXlsb2FkXSBBZGFtIFJvYWNoJ3MgRGlzY3VzcyBv biBkcmFmdC1pZXRmLXBheWxvYWQtcnRwLQ0KPiBhbmNpbGxhcnktMTA6ICh3aXRoIERJU0NVU1Mg YW5kIENPTU1FTlQpDQo+IA0KPiANCj4gPiBPbiAzIE9jdCAyMDE3LCBhdCAyMTo0MCwgUm9uaSBF dmVuIDxyb25pLmV2ZW5AaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBIaSBDb2xpbiwNCj4g PiBJIHJlLXJlYWQgUkZDNTg4OCBhbmQgdHJpZWQgdG8gdW5kZXJzdGFuZCB3aGF0IGlzIHRoZSBk aWZmZXJlbmNlDQo+ID4gYmV0d2VlbiBGSUQgYW5kIExTIEkgd2FzIHRyeWluZyB0byB1bmRlcnN0 YW5kIHdoYXQgaXMgYSBmbG93IGFuZCBmcm9tDQo+ID4gc2VjdGlvbiA4LjMNCj4gPg0KPiA+ICJU aGUgcHJldmlvdXMgZXhhbXBsZXMgc2hvdyB0aGF0IHRoZSBkZWZpbml0aW9uIG9mIGEgbWVkaWEg c3RyZWFtIGluDQo+ID4gICBbUkZDMjMyNl0gZG9lcyBub3QgY292ZXIgc29tZSBzY2VuYXJpb3Mu ICBJdCBjYW5ub3QgYmUgYXNzdW1lZCB0aGF0IGENCj4gPiAgIHNpbmdsZSBtZWRpYSBpbnN0YW5j ZSBtYXBzIGludG8gYSBzaW5nbGUgUlRQIHNlc3Npb24uICBUaGVyZWZvcmUsIHdlDQo+ID4gICBp bnRyb2R1Y2UgdGhlIGRlZmluaXRpb24gb2YgYSBtZWRpYSBmbG93Og0KPiA+DQo+ID4gICAgICBB IG1lZGlhIGZsb3cgY29uc2lzdHMgb2YgYSBzaW5nbGUgbWVkaWEgaW5zdGFuY2UsIGUuZy4sIGFu IGF1ZGlvDQo+ID4gICAgICBzdHJlYW0gb3IgYSB2aWRlbyBzdHJlYW0gYXMgd2VsbCBhcyBhIHNp bmdsZSB3aGl0ZWJvYXJkIG9yIHNoYXJlZA0KPiA+ICAgICAgYXBwbGljYXRpb24gZ3JvdXAuICBX aGVuIHVzaW5nIFJUUCwgYSBtZWRpYSBmbG93IGNvbXByaXNlcyBvbmUgb3INCj4gPiAgICAgIG1v cmUgUlRQIHNlc3Npb25zLiINCj4gPg0KPiA+IEl0IGxvb2tzIHRvIG1lIHRoYXQgYSBtZWRpYSBm bG93IGlzIGEgU0lOR0xFIG1lZGlhIHN0cmVhbSB0aGF0IHNwYW5zIG92ZXINCj4gbXVsdGlwbGUg UlRQIHNlc3Npb25zICh0aGUgdGVybSBtZWRpYSBpbnN0YW5jZSBpcyBhIHdoYXQgd2UgY2FsbCBh IG1lZGlhDQo+IHN0cmVhbSBpbiB0aGUgdGF4b25vbXkpLiBTZWN0aW9uIDguNSAoOC41LjEpIGVu aGFuY2UgdGhpcyBieSBzYXlpbmcgd2hlbiBGSUQNCj4gY2Fubm90IGJlIHVzZWQgIiBGSUQgc2Vt YW50aWNzIGFyZSB1c2VmdWwgd2hlbiB0aGUgYXBwbGljYXRpb24gb25seSB1c2VzDQo+IG9uZSBj b2RlYyBhdCAgIGEgdGltZSIgIHdoaWNoIGFnYWluIGRlc2NyaWJlIGEgZmxvdyBhcyBhIHNpbmds ZSBtZWRpYSBzdHJlYW0uDQo+ID4NCj4gPiBJIGFtIG5vdCBzdXJlIGhvdyBBTkMgYW5kIHRoZSB2 aWRlbyByZWxhdGVzIHRvIGVhY2ggb3RoZXIgdGhpcyBpcyB3aGF0IEkgYW0NCj4gYXNraW5nIFRo b21hcyB0byBiZSBtb3JlIGNsZWFyLiBJZiB0aGUgdmlkZW8gYW5kIEFOQyBhcmUgb25lIHN0cmVh bSBvdmVyDQo+IG11bHRpcGxlIFJUUCBzZXNzaW9ucyBGSUQgaXMgY29ycmVjdCBvdGhlcndpc2Ug SSB0aGluayB0aGUgTFMgc2hvdWxkIGJlIHVzZWQuDQo+IA0KPiBNeSB1bmRlcnN0YW5kaW5nIGlz IHRoYXQgdGhlIHZpZGVvIGFuZCBhbmNpbGxhcnkgZGF0YSBhcmUgdGhlIHNhbWUgc3RyZWFtLiBJ bg0KPiBicm9hZGNhc3QgVFYgdGhlIGFuY2lsbGFyeSBkYXRhIGlzIHNlbnQgaW4tYmFuZCwgaW4g dGhlIGJsYW5raW5nIGludGVydmFscy4NCj4gDQo+ID4gTXkgcmVhZGluZyBvbiAgdGhlIGFuY2ls bGFyeSBkcmFmdCBpcyB0aGF0IEFOQyBhbmQgdGhlIHZpZGVvIGFyZSB3aGF0IHdlIGNhbGwNCj4g YSBzaW5nbGUgUlRQIHN0cmVhbSBidXQgdGhpcyBpcyBub3Qgd2hhdCBUaG9tYXMgc2F5cy4NCj4g DQo+IA0KPiBJIGV4cGVjdCBvbmUgY291bGQgc2VuZCB0aGUgYW5jaWxsYXJ5IGRhdGEgdXNpbmcg dGhlIHNhbWUgU1NSQywgYW5kIHRoZSBzYW1lDQo+IDUtdHVwbGUsIGFzIHRoZSBtZWRpYSBkYXRh IChpbiB0aGUgc2FtZSB3YXkgY29tZm9ydCBub2lzZSBhbmQgc3BlZWNoIGRhdGENCj4gY2FuIGJl IHNlbnQpLCBpbiB3aGljaCBjYXNlIHlvdSBkb27igJl0IG5lZWQgdGhlIGdyb3VwaW5nLiBJZiB0 aGV54oCZcmUgc2VudCBhcw0KPiBzZXBhcmF0ZSBSVFAgc3RyZWFtcywgd2l0aCBzZXBhcmF0ZSBt PSBsaW5lcywgdGhlbiB5b3UgbmVlZCBncm91cGluZy4gSQ0KPiBiZWxpZXZlIEZJRCBtYWtlcyBz ZW5zZSBmb3IgdGhpcy4NCj4gDQo+IC0tDQo+IENvbGluIFBlcmtpbnMNCj4gaHR0cHM6Ly9jc3Bl cmtpbnMub3JnLw0KPiANCj4gDQo+IA0KDQo= From nobody Tue Oct 3 15:50:35 2017 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 976FC13421C; Tue, 3 Oct 2017 15:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhYZ2gaD_AFx; Tue, 3 Oct 2017 15:50:27 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D92132992; Tue, 3 Oct 2017 15:50:27 -0700 (PDT) Received: from [81.187.2.149] (port=39164 helo=[192.168.0.71]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1dzW16-0005um-C4; Tue, 03 Oct 2017 23:50:21 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Colin Perkins In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD810D79@DGGEMM506-MBX.china.huawei.com> Date: Tue, 3 Oct 2017 23:50:13 +0100 Cc: Adam Roach , Thomas Edwards , The IESG , "payload-chairs@ietf.org" , "draft-ietf-payload-rtp-ancillary@ietf.org" , "payload@ietf.org" , "acbegen@gmail.com" Content-Transfer-Encoding: quoted-printable Message-Id: <7574DE41-96BB-45C1-8279-F9E2460E0452@csperkins.org> References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <3B259563-1075-4C41-A832-D7633C39173B@foxeg.com> <61440eb5-32c3-3696-be38-8dc7c4eaf72f@nostrum.com> <863974D7-E112-4794-AD4D-C39C99BD40C9@foxeg.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> <6E58094ECC8D8344914996DAD28F1CCD810BB8@DGGEMM506-MBX.china.huawei.com> <37F6B554-530B-4A30-B66F-A70D026DD2B8@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810CC5@DGGEMM506-MBX.china.huawei.com> <04D71781-0E87-461C-BDA0-D44F94FED1A0@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810D79@DGGEMM506-MBX.china.huawei.com> To: Roni Even X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 03 Oct 2017 22:50:30 -0000 Roni, I said nothing about multicast vs unicast, since I don=E2=80=99t think = that distinction is important.=20 Sending the streams on separate m=3D lines or sending using a single a = m=3D line both work. The draft doesn=E2=80=99t need to discuss this, = since it=E2=80=99s standard RTP as would apply to any RTP session. If = you use separate m=3D lines, then you need a grouping mechanism. The = choice of grouping mechanism is what we=E2=80=99re discussing. Colin > On 3 Oct 2017, at 23:19, Roni Even wrote: >=20 > Colin, > We still need some feedback from Thomas, in a previous email response = to Adam he gave a reason for using multiple RTP sessions: >=20 > "The challenge is that the use case of the Ancillary I-D within the = SMPTE ST 2110 architecture would generally require separate network = destination addresses for the different elements (video, audio, = ancillary data) so they can be flexibly composed within broadcast plants = at the network level. Your alternative SDP example appears to place = both the video and the ancillary data onto the same destination address = (233.252.0.1). Is there an appropriate SDP mechanism to communicate the = intimate relationship between the RTP streams, but also have them = transmitted on separate destination IP addresses (and synchronized)? >=20 > (In production practice, this may not be a significant issue as the = RTP streams to be combined by IP receivers for conversion to SDI/HDMI or = for input to a distribution encoder may be specified by a control system = directly to the receiver using an API that isn=E2=80=99t just an SDP = file.)" >=20 > I want to assume that by different destination addresses it refers to = multicast addresses like above and not to different unicast IP = addresses.=20 > You are right that for unicast it will make sense to use the same RTP = session with the same SSRC. >=20 > Roni >=20 >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org] >> Sent: =D7=99=D7=95=D7=9D =D7=93 04 =D7=90=D7=95=D7=A7=D7=98=D7=95=D7=91= =D7=A8 2017 00:46 >> To: Roni Even >> Cc: Adam Roach; Thomas Edwards; The IESG; payload-chairs@ietf.org; = draft- >> ietf-payload-rtp-ancillary@ietf.org; payload@ietf.org; = acbegen@gmail.com >> Subject: Re: [payload] Adam Roach's Discuss on = draft-ietf-payload-rtp- >> ancillary-10: (with DISCUSS and COMMENT) >>=20 >>=20 >>> On 3 Oct 2017, at 21:40, Roni Even wrote: >>>=20 >>> Hi Colin, >>> I re-read RFC5888 and tried to understand what is the difference >>> between FID and LS I was trying to understand what is a flow and = from >>> section 8.3 >>>=20 >>> "The previous examples show that the definition of a media stream in >>> [RFC2326] does not cover some scenarios. It cannot be assumed that = a >>> single media instance maps into a single RTP session. Therefore, = we >>> introduce the definition of a media flow: >>>=20 >>> A media flow consists of a single media instance, e.g., an audio >>> stream or a video stream as well as a single whiteboard or = shared >>> application group. When using RTP, a media flow comprises one = or >>> more RTP sessions." >>>=20 >>> It looks to me that a media flow is a SINGLE media stream that spans = over >> multiple RTP sessions (the term media instance is a what we call a = media >> stream in the taxonomy). Section 8.5 (8.5.1) enhance this by saying = when FID >> cannot be used " FID semantics are useful when the application only = uses >> one codec at a time" which again describe a flow as a single media = stream. >>>=20 >>> I am not sure how ANC and the video relates to each other this is = what I am >> asking Thomas to be more clear. If the video and ANC are one stream = over >> multiple RTP sessions FID is correct otherwise I think the LS should = be used. >>=20 >> My understanding is that the video and ancillary data are the same = stream. In >> broadcast TV the ancillary data is sent in-band, in the blanking = intervals. >>=20 >>> My reading on the ancillary draft is that ANC and the video are = what we call >> a single RTP stream but this is not what Thomas says. >>=20 >>=20 >> I expect one could send the ancillary data using the same SSRC, and = the same >> 5-tuple, as the media data (in the same way comfort noise and speech = data >> can be sent), in which case you don=E2=80=99t need the grouping. If = they=E2=80=99re sent as >> separate RTP streams, with separate m=3D lines, then you need = grouping. I >> believe FID makes sense for this. >>=20 >> -- >> Colin Perkins >> https://csperkins.org/ >>=20 >>=20 >>=20 >=20 --=20 Colin Perkins https://csperkins.org/ From nobody Wed Oct 4 09:27:19 2017 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 10A561329B5; Wed, 4 Oct 2017 09:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fbTDlvgjljm; Wed, 4 Oct 2017 09:27:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64497124F57; Wed, 4 Oct 2017 09:27:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPX19674; Wed, 04 Oct 2017 16:27:11 +0000 (GMT) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 4 Oct 2017 17:27:10 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.187]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0301.000; Thu, 5 Oct 2017 00:27:00 +0800 From: Roni Even To: Colin Perkins CC: Adam Roach , Thomas Edwards , The IESG , "payload-chairs@ietf.org" , "draft-ietf-payload-rtp-ancillary@ietf.org" , "payload@ietf.org" , "acbegen@gmail.com" Thread-Topic: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) Thread-Index: AQHTPJoDxadIruGsv0eH8EbEYYLgFqLT3xEA Date: Wed, 4 Oct 2017 16:26:58 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD81103C@DGGEMM506-MBX.china.huawei.com> References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <3B259563-1075-4C41-A832-D7633C39173B@foxeg.com> <61440eb5-32c3-3696-be38-8dc7c4eaf72f@nostrum.com> <863974D7-E112-4794-AD4D-C39C99BD40C9@foxeg.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> <6E58094ECC8D8344914996DAD28F1CCD810BB8@DGGEMM506-MBX.china.huawei.com> <37F6B554-530B-4A30-B66F-A70D026DD2B8@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810CC5@DGGEMM506-MBX.china.huawei.com> <04D71781-0E87-461C-BDA0-D44F94FED1A0@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810D79@DGGEMM506-MBX.china.huawei.com> <7574DE41-96BB-45C1-8279-F9E2460E0452@csperkins.org> In-Reply-To: <7574DE41-96BB-45C1-8279-F9E2460E0452@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.74] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0208.59D50BDF.012E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.187, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 76507c793da638ed63087e0afbd24878 Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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 Oct 2017 16:27:17 -0000 SGkgQ29saW4sDQpJIGFncmVlLg0KVGhlcmUgYXJlIHR3byBjYXNlcy4gVGhlIGFzc3VtcHRpb24g aXMgdGhhdCBib3RoIHZpZGVvIGFuZCBBTkMgaGF2ZSB0aGUgc2FtZSBzb3VyY2UgYW5kIGhhdmUg c2FtZSBDTkFNRSAoVGhvbWFzIC0gaXMgdGhpcyBjb3JyZWN0PykNCg0KMS4gQm90aCB2aWRlbyBh bmQgQU5DIGFyZSBpbiB0aGUgc2FtZSBSVFAgc2Vzc2lvbiAoc2FtZSBtLWxpbmUpICB3aWxsIGJl IHN5bmNocm9uaXplZC4gDQoNClRoZSBzZWNvbmQgaXMgdGhlIG9uZSB3ZSBhcmUgZGlzY3Vzc2lu ZzoNCjIuIFRoZSB2aWRlbyBhbmQgQU5DIGFyZSBpbiBzZXBhcmF0ZSBSVFAgc2Vzc2lvbnMgKHR3 byBtLWxpbmVzKS4gSWYgYm90aCBhcmUgYSBzaW5nbGUgZmxvdyAoc2luZ2xlIFJUUCBzdHJlYW0p IHNob3VsZCBncm91cCB1c2luZyBGSUQuIElmIHRoZXkgYXJlIG5vdCBhIHNpbmdsZSBSVFAgc3Ry ZWFtIChmbG93KSBzaG91bGQgdXNlIExTLg0KDQpJIGNhbiBhZ3JlZSB0aGF0IGl0IGxvb2tzIGxp a2UgYSBzaW5nbGUgZmxvdyAoRklEKSBidXQgd2FudCBjbGFyaWZpY2F0aW9uIGZyb20gdGhlIGF1 dGhvcnMgKFRob21hcykNCg0KDQoNClJvbmkNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBDb2xpbiBQZXJraW5zIFttYWlsdG86Y3NwQGNzcGVya2lucy5vcmddDQo+IFNl bnQ6INeZ15XXncKg15MgMDQg15DXlden15jXldeR16ggMjAxNyAwMTo1MA0KPiBUbzogUm9uaSBF dmVuDQo+IENjOiBBZGFtIFJvYWNoOyBUaG9tYXMgRWR3YXJkczsgVGhlIElFU0c7IHBheWxvYWQt Y2hhaXJzQGlldGYub3JnOyBkcmFmdC0NCj4gaWV0Zi1wYXlsb2FkLXJ0cC1hbmNpbGxhcnlAaWV0 Zi5vcmc7IHBheWxvYWRAaWV0Zi5vcmc7IGFjYmVnZW5AZ21haWwuY29tDQo+IFN1YmplY3Q6IFJl OiBbcGF5bG9hZF0gQWRhbSBSb2FjaCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0 cC0NCj4gYW5jaWxsYXJ5LTEwOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiANCj4gUm9u aSwNCj4gDQo+IEkgc2FpZCBub3RoaW5nIGFib3V0IG11bHRpY2FzdCB2cyB1bmljYXN0LCBzaW5j ZSBJIGRvbuKAmXQgdGhpbmsgdGhhdCBkaXN0aW5jdGlvbiBpcw0KPiBpbXBvcnRhbnQuDQo+IA0K PiBTZW5kaW5nIHRoZSBzdHJlYW1zIG9uIHNlcGFyYXRlIG09IGxpbmVzIG9yIHNlbmRpbmcgdXNp bmcgYSBzaW5nbGUgYSBtPSBsaW5lDQo+IGJvdGggd29yay4gVGhlIGRyYWZ0IGRvZXNu4oCZdCBu ZWVkIHRvIGRpc2N1c3MgdGhpcywgc2luY2UgaXTigJlzIHN0YW5kYXJkIFJUUCBhcw0KPiB3b3Vs ZCBhcHBseSB0byBhbnkgUlRQIHNlc3Npb24uIElmIHlvdSB1c2Ugc2VwYXJhdGUgbT0gbGluZXMs IHRoZW4geW91IG5lZWQNCj4gYSBncm91cGluZyBtZWNoYW5pc20uIFRoZSBjaG9pY2Ugb2YgZ3Jv dXBpbmcgbWVjaGFuaXNtIGlzIHdoYXQgd2XigJlyZQ0KPiBkaXNjdXNzaW5nLg0KPiANCj4gQ29s aW4NCj4gDQo+IA0KPiANCj4gDQo+ID4gT24gMyBPY3QgMjAxNywgYXQgMjM6MTksIFJvbmkgRXZl biA8cm9uaS5ldmVuQGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+DQo+ID4gQ29saW4sDQo+ID4gV2Ug c3RpbGwgbmVlZCBzb21lIGZlZWRiYWNrIGZyb20gVGhvbWFzLCBpbiBhIHByZXZpb3VzIGVtYWls IHJlc3BvbnNlIHRvDQo+IEFkYW0gaGUgZ2F2ZSBhIHJlYXNvbiBmb3IgdXNpbmcgbXVsdGlwbGUg UlRQIHNlc3Npb25zOg0KPiA+DQo+ID4gIlRoZSBjaGFsbGVuZ2UgaXMgdGhhdCB0aGUgdXNlIGNh c2Ugb2YgdGhlIEFuY2lsbGFyeSBJLUQgd2l0aGluIHRoZSBTTVBURSBTVA0KPiAyMTEwIGFyY2hp dGVjdHVyZSB3b3VsZCBnZW5lcmFsbHkgcmVxdWlyZSBzZXBhcmF0ZSBuZXR3b3JrIGRlc3RpbmF0 aW9uDQo+IGFkZHJlc3NlcyBmb3IgdGhlIGRpZmZlcmVudCBlbGVtZW50cyAodmlkZW8sIGF1ZGlv LCBhbmNpbGxhcnkgZGF0YSkgc28gdGhleQ0KPiBjYW4gYmUgZmxleGlibHkgY29tcG9zZWQgd2l0 aGluIGJyb2FkY2FzdCBwbGFudHMgYXQgdGhlIG5ldHdvcmsgbGV2ZWwuICBZb3VyDQo+IGFsdGVy bmF0aXZlIFNEUCBleGFtcGxlIGFwcGVhcnMgdG8gcGxhY2UgYm90aCB0aGUgdmlkZW8gYW5kIHRo ZSBhbmNpbGxhcnkNCj4gZGF0YSBvbnRvIHRoZSBzYW1lIGRlc3RpbmF0aW9uIGFkZHJlc3MgKDIz My4yNTIuMC4xKS4gIElzIHRoZXJlIGFuDQo+IGFwcHJvcHJpYXRlIFNEUCBtZWNoYW5pc20gdG8g Y29tbXVuaWNhdGUgdGhlIGludGltYXRlIHJlbGF0aW9uc2hpcA0KPiBiZXR3ZWVuIHRoZSBSVFAg c3RyZWFtcywgYnV0IGFsc28gaGF2ZSB0aGVtIHRyYW5zbWl0dGVkIG9uIHNlcGFyYXRlDQo+IGRl c3RpbmF0aW9uIElQIGFkZHJlc3NlcyAoYW5kIHN5bmNocm9uaXplZCk/DQo+ID4NCj4gPiAoSW4g cHJvZHVjdGlvbiBwcmFjdGljZSwgdGhpcyBtYXkgbm90IGJlIGEgc2lnbmlmaWNhbnQgaXNzdWUg YXMgdGhlIFJUUA0KPiBzdHJlYW1zIHRvIGJlIGNvbWJpbmVkIGJ5IElQIHJlY2VpdmVycyBmb3Ig Y29udmVyc2lvbiB0byBTREkvSERNSSBvciBmb3INCj4gaW5wdXQgdG8gYSBkaXN0cmlidXRpb24g ZW5jb2RlciBtYXkgYmUgc3BlY2lmaWVkIGJ5IGEgY29udHJvbCBzeXN0ZW0gZGlyZWN0bHkNCj4g dG8gdGhlIHJlY2VpdmVyIHVzaW5nIGFuIEFQSSB0aGF0IGlzbuKAmXQganVzdCBhbiBTRFAgZmls ZS4pIg0KPiA+DQo+ID4gSSB3YW50IHRvIGFzc3VtZSB0aGF0IGJ5IGRpZmZlcmVudCBkZXN0aW5h dGlvbiBhZGRyZXNzZXMgaXQgcmVmZXJzIHRvDQo+IG11bHRpY2FzdCBhZGRyZXNzZXMgbGlrZSBh Ym92ZSBhbmQgbm90IHRvIGRpZmZlcmVudCB1bmljYXN0IElQIGFkZHJlc3Nlcy4NCj4gPiBZb3Ug YXJlIHJpZ2h0IHRoYXQgZm9yIHVuaWNhc3QgaXQgd2lsbCBtYWtlIHNlbnNlIHRvIHVzZSB0aGUg c2FtZSBSVFAgc2Vzc2lvbg0KPiB3aXRoIHRoZSBzYW1lIFNTUkMuDQo+ID4NCj4gPiBSb25pDQo+ ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogQ29saW4gUGVy a2lucyBbbWFpbHRvOmNzcEBjc3BlcmtpbnMub3JnXQ0KPiA+PiBTZW50OiDXmdeV150g15MgMDQg 15DXlden15jXldeR16ggMjAxNyAwMDo0Ng0KPiA+PiBUbzogUm9uaSBFdmVuDQo+ID4+IENjOiBB ZGFtIFJvYWNoOyBUaG9tYXMgRWR3YXJkczsgVGhlIElFU0c7IHBheWxvYWQtY2hhaXJzQGlldGYu b3JnOw0KPiA+PiBkcmFmdC0gaWV0Zi1wYXlsb2FkLXJ0cC1hbmNpbGxhcnlAaWV0Zi5vcmc7IHBh eWxvYWRAaWV0Zi5vcmc7DQo+ID4+IGFjYmVnZW5AZ21haWwuY29tDQo+ID4+IFN1YmplY3Q6IFJl OiBbcGF5bG9hZF0gQWRhbSBSb2FjaCdzIERpc2N1c3Mgb24NCj4gPj4gZHJhZnQtaWV0Zi1wYXls b2FkLXJ0cC0NCj4gPj4gYW5jaWxsYXJ5LTEwOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0K PiA+Pg0KPiA+Pg0KPiA+Pj4gT24gMyBPY3QgMjAxNywgYXQgMjE6NDAsIFJvbmkgRXZlbiA8cm9u aS5ldmVuQGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+Pj4NCj4gPj4+IEhpIENvbGluLA0KPiA+Pj4g SSByZS1yZWFkIFJGQzU4ODggYW5kIHRyaWVkIHRvIHVuZGVyc3RhbmQgd2hhdCBpcyB0aGUgZGlm ZmVyZW5jZQ0KPiA+Pj4gYmV0d2VlbiBGSUQgYW5kIExTIEkgd2FzIHRyeWluZyB0byB1bmRlcnN0 YW5kIHdoYXQgaXMgYSBmbG93IGFuZA0KPiA+Pj4gZnJvbSBzZWN0aW9uIDguMw0KPiA+Pj4NCj4g Pj4+ICJUaGUgcHJldmlvdXMgZXhhbXBsZXMgc2hvdyB0aGF0IHRoZSBkZWZpbml0aW9uIG9mIGEg bWVkaWEgc3RyZWFtIGluDQo+ID4+PiBbUkZDMjMyNl0gZG9lcyBub3QgY292ZXIgc29tZSBzY2Vu YXJpb3MuICBJdCBjYW5ub3QgYmUgYXNzdW1lZCB0aGF0DQo+ID4+PiBhICBzaW5nbGUgbWVkaWEg aW5zdGFuY2UgbWFwcyBpbnRvIGEgc2luZ2xlIFJUUCBzZXNzaW9uLiAgVGhlcmVmb3JlLA0KPiA+ Pj4gd2UgIGludHJvZHVjZSB0aGUgZGVmaW5pdGlvbiBvZiBhIG1lZGlhIGZsb3c6DQo+ID4+Pg0K PiA+Pj4gICAgIEEgbWVkaWEgZmxvdyBjb25zaXN0cyBvZiBhIHNpbmdsZSBtZWRpYSBpbnN0YW5j ZSwgZS5nLiwgYW4gYXVkaW8NCj4gPj4+ICAgICBzdHJlYW0gb3IgYSB2aWRlbyBzdHJlYW0gYXMg d2VsbCBhcyBhIHNpbmdsZSB3aGl0ZWJvYXJkIG9yIHNoYXJlZA0KPiA+Pj4gICAgIGFwcGxpY2F0 aW9uIGdyb3VwLiAgV2hlbiB1c2luZyBSVFAsIGEgbWVkaWEgZmxvdyBjb21wcmlzZXMgb25lIG9y DQo+ID4+PiAgICAgbW9yZSBSVFAgc2Vzc2lvbnMuIg0KPiA+Pj4NCj4gPj4+IEl0IGxvb2tzIHRv IG1lIHRoYXQgYSBtZWRpYSBmbG93IGlzIGEgU0lOR0xFIG1lZGlhIHN0cmVhbSB0aGF0IHNwYW5z DQo+ID4+PiBvdmVyDQo+ID4+IG11bHRpcGxlIFJUUCBzZXNzaW9ucyAodGhlIHRlcm0gbWVkaWEg aW5zdGFuY2UgaXMgYSB3aGF0IHdlIGNhbGwgYQ0KPiA+PiBtZWRpYSBzdHJlYW0gaW4gdGhlIHRh eG9ub215KS4gU2VjdGlvbiA4LjUgKDguNS4xKSBlbmhhbmNlIHRoaXMgYnkNCj4gPj4gc2F5aW5n IHdoZW4gRklEIGNhbm5vdCBiZSB1c2VkICIgRklEIHNlbWFudGljcyBhcmUgdXNlZnVsIHdoZW4g dGhlDQo+IGFwcGxpY2F0aW9uIG9ubHkgdXNlcw0KPiA+PiBvbmUgY29kZWMgYXQgICBhIHRpbWUi ICB3aGljaCBhZ2FpbiBkZXNjcmliZSBhIGZsb3cgYXMgYSBzaW5nbGUgbWVkaWENCj4gc3RyZWFt Lg0KPiA+Pj4NCj4gPj4+IEkgYW0gbm90IHN1cmUgaG93IEFOQyBhbmQgdGhlIHZpZGVvIHJlbGF0 ZXMgdG8gZWFjaCBvdGhlciB0aGlzIGlzDQo+ID4+PiB3aGF0IEkgYW0NCj4gPj4gYXNraW5nIFRo b21hcyB0byBiZSBtb3JlIGNsZWFyLiBJZiB0aGUgdmlkZW8gYW5kIEFOQyBhcmUgb25lIHN0cmVh bQ0KPiA+PiBvdmVyIG11bHRpcGxlIFJUUCBzZXNzaW9ucyBGSUQgaXMgY29ycmVjdCBvdGhlcndp c2UgSSB0aGluayB0aGUgTFMgc2hvdWxkIGJlDQo+IHVzZWQuDQo+ID4+DQo+ID4+IE15IHVuZGVy c3RhbmRpbmcgaXMgdGhhdCB0aGUgdmlkZW8gYW5kIGFuY2lsbGFyeSBkYXRhIGFyZSB0aGUgc2Ft ZQ0KPiA+PiBzdHJlYW0uIEluIGJyb2FkY2FzdCBUViB0aGUgYW5jaWxsYXJ5IGRhdGEgaXMgc2Vu dCBpbi1iYW5kLCBpbiB0aGUgYmxhbmtpbmcNCj4gaW50ZXJ2YWxzLg0KPiA+Pg0KPiA+Pj4gTXkg cmVhZGluZyBvbiAgdGhlIGFuY2lsbGFyeSBkcmFmdCBpcyB0aGF0IEFOQyBhbmQgdGhlIHZpZGVv IGFyZQ0KPiA+Pj4gd2hhdCB3ZSBjYWxsDQo+ID4+IGEgc2luZ2xlIFJUUCBzdHJlYW0gYnV0IHRo aXMgaXMgbm90IHdoYXQgVGhvbWFzIHNheXMuDQo+ID4+DQo+ID4+DQo+ID4+IEkgZXhwZWN0IG9u ZSBjb3VsZCBzZW5kIHRoZSBhbmNpbGxhcnkgZGF0YSB1c2luZyB0aGUgc2FtZSBTU1JDLCBhbmQN Cj4gPj4gdGhlIHNhbWUgNS10dXBsZSwgYXMgdGhlIG1lZGlhIGRhdGEgKGluIHRoZSBzYW1lIHdh eSBjb21mb3J0IG5vaXNlDQo+ID4+IGFuZCBzcGVlY2ggZGF0YSBjYW4gYmUgc2VudCksIGluIHdo aWNoIGNhc2UgeW91IGRvbuKAmXQgbmVlZCB0aGUNCj4gPj4gZ3JvdXBpbmcuIElmIHRoZXnigJly ZSBzZW50IGFzIHNlcGFyYXRlIFJUUCBzdHJlYW1zLCB3aXRoIHNlcGFyYXRlIG09DQo+ID4+IGxp bmVzLCB0aGVuIHlvdSBuZWVkIGdyb3VwaW5nLiBJIGJlbGlldmUgRklEIG1ha2VzIHNlbnNlIGZv ciB0aGlzLg0KPiA+Pg0KPiA+PiAtLQ0KPiA+PiBDb2xpbiBQZXJraW5zDQo+ID4+IGh0dHBzOi8v Y3NwZXJraW5zLm9yZy8NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPg0KPiANCj4gDQo+IA0KPiAtLQ0K PiBDb2xpbiBQZXJraW5zDQo+IGh0dHBzOi8vY3NwZXJraW5zLm9yZy8NCj4gDQo+IA0KPiANCg0K From nobody Mon Oct 9 17:07:02 2017 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 E5A73132143; Mon, 9 Oct 2017 17:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=foxgroupinc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yx3LnDv0MFyb; Mon, 9 Oct 2017 17:06:58 -0700 (PDT) Received: from mx0a-00195501.pphosted.com (mx0a-00195501.pphosted.com [67.231.149.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CFD1120720; Mon, 9 Oct 2017 17:06:57 -0700 (PDT) Received: from pps.filterd (m0082295.ppops.net [127.0.0.1]) by mx0a-00195501.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9A06ToP019750; Mon, 9 Oct 2017 17:06:43 -0700 Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0182.outbound.protection.outlook.com [216.32.180.182]) by mx0a-00195501.pphosted.com with ESMTP id 2dgkcgr01r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 09 Oct 2017 17:06:42 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=FoxGroupInc.onmicrosoft.com; s=selector1-fox-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=L0TeoDFfDMSTtdHGA2czZK8GOYGMZ6/gy3vQTlUAAHE=; b=Z55vwV6QYnOKbhyWXxSz2mAmqWXVajkAl8hRCXQo+EgM4T7KBmkNJD9BRN0aOrjeLBaAepfHqaVavDpWF/jC71CuZwGieAbRijJAMc8hsVdn9IVH0mQZsNCN6ZGIWOWBeeNXFi+KZ/h+XIVk+/74VS+zLvC/rjaAHf6aIju6qnc= Received: from BN3PR05MB2657.namprd05.prod.outlook.com (10.166.72.21) by BN3PR05MB2658.namprd05.prod.outlook.com (10.166.72.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Tue, 10 Oct 2017 00:06:39 +0000 Received: from BN3PR05MB2657.namprd05.prod.outlook.com ([10.166.72.21]) by BN3PR05MB2657.namprd05.prod.outlook.com ([10.166.72.21]) with mapi id 15.20.0077.020; Tue, 10 Oct 2017 00:06:39 +0000 From: Thomas Edwards To: Roni Even , Colin Perkins CC: Adam Roach , The IESG , "payload-chairs@ietf.org" , "draft-ietf-payload-rtp-ancillary@ietf.org" , "payload@ietf.org" , "acbegen@gmail.com" Thread-Topic: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) Thread-Index: AQHTFjbD5uxO79354kmKPbq9ZGEoqKK9h+8AgAIma4CAAROegIAAhb4AgAZyKgCABOWIAIAGBRyAgAAQJQCAABALgIAAHp+AgAASIwCAAAlbgIAACLOAgAEnQQCAB+a9AA== Date: Tue, 10 Oct 2017 00:06:39 +0000 Message-ID: <7D009531-3DB3-4923-80B2-38BC3F9FB020@foxeg.com> References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <3B259563-1075-4C41-A832-D7633C39173B@foxeg.com> <61440eb5-32c3-3696-be38-8dc7c4eaf72f@nostrum.com> <863974D7-E112-4794-AD4D-C39C99BD40C9@foxeg.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> <6E58094ECC8D8344914996DAD28F1CCD810BB8@DGGEMM506-MBX.china.huawei.com> <37F6B554-530B-4A30-B66F-A70D026DD2B8@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810CC5@DGGEMM506-MBX.china.huawei.com> <04D71781-0E87-461C-BDA0-D44F94FED1A0@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810D79@DGGEMM506-MBX.china.huawei.com> <7574DE41-96BB-45C1-8279-F9E2460E0452@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD81103C@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD81103C@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 x-originating-ip: [216.205.246.234] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR05MB2658; 20:4VGCDnXqmkrhrLfl28VDJf8DMUmXuA0kHclV1Y8Fe3HU7V8GAPGzzuDrQ87XT9uki3b8mAeI2imEpBtbt4tobHLSEwWxsy5kfN9W5wZ5FxrNHZP7dltV4CnrijtbfXnL/ZCFOW3A1zh9w4PTuWisJrNMmUOQa0pMLXhEotkhqYZ4JfBmCR67uDDS4B9lfe6tysYAHgTmkmBj17WSf7jsQrvPLvSowkqOnpucCUweAzeAyE8wLtes/xZwJl58ihMW x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4e479f02-e754-413a-b827-08d50f72c7f0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:BN3PR05MB2658; x-ms-traffictypediagnostic: BN3PR05MB2658: x-exchange-antispam-report-test: UriScan:(10436049006162)(131327999870524)(50582790962513); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR05MB2658; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR05MB2658; x-forefront-prvs: 04569283F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(376002)(346002)(13464003)(377454003)(189002)(199003)(24454002)(68736007)(2900100001)(106356001)(101416001)(105586002)(81166006)(81156014)(8676002)(83716003)(83506001)(189998001)(54356999)(7736002)(305945005)(82746002)(50986999)(76176999)(8936002)(6116002)(3846002)(102836003)(97736004)(86362001)(575784001)(25786009)(53936002)(9686003)(6512007)(6306002)(39060400002)(6246003)(93886005)(3280700002)(2906002)(4326008)(3660700001)(6506006)(2950100002)(72206003)(6436002)(229853002)(6486002)(58126008)(33656002)(77096006)(966005)(14454004)(53546010)(54906003)(110136005)(316002)(478600001)(36756003)(99286003)(230783001)(66066001)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR05MB2658; H:BN3PR05MB2657.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fox.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: fox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2017 00:06:39.6048 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: de99ade3-81db-4070-ae0d-3c1562041b30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2658 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-09_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710100000 Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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 Oct 2017 00:07:01 -0000 SSB3aWxsIG5vdGUgdGhhdCBJIGhhdmUgdXBsb2FkZWQgYSBuZXcgdmVyc2lvbiwgZHJhZnQtaWV0 Zi1wYXlsb2FkLXJ0cC1hbmNpbGxhcnktMTEsIHRvIGFkZHJlc3MgbW9zdCBvZiB0aGUgY29tbWVu dHMgZnJvbSB0aGUgSUVTRyBldmFsdWF0aW9uLg0KDQpkcmFmdC1pZXRmLXBheWxvYWQtcnRwLWFu Y2lsbGFyeS0xMSwgU2VjdGlvbiA0LjEg4oCcR3JvdXBpbmcgQU5DIFN0cmVhbXMgd2l0aCBvdGhl ciBNZWRpYSBTdHJlYW1z4oCdIGhhcyB0d28gZXhhbXBsZXMuDQoNCkluIHRoZSBmaXJzdCBTRFAg ZXhhbXBsZSwgdHdvIOKAnG094oCdIGxpbmVzIGFyZSBwcmVzZW50ICh3aXRoIGVhY2ggaGF2aW5n IGEgZGlmZmVyZW50IOKAnGM94oCdIGxpbmUpLCBvbmUgZm9yIHVuY29tcHJlc3NlZCB2aWRlbywg YW5kIG9uZSBmb3IgYW5jaWxsYXJ5IGRhdGEuICBUaGUgdHdvIFJUUCBzZXNzaW9ucyBhcmUgaWRl bnRpZmllZCB3aXRoIFJGQyA1ODg4IE1lZGlhIFN0cmVhbSBJZGVudGlmaWNhdGlvbiBBdHRyaWJ1 dGVzIChtaWQpLCBhbmQgYXJlIGdyb3VwZWQgdG9nZXRoZXIgdXNpbmcgTGlwIFN5bmNocm9uaXph dGlvbiAoTFMpLCBpbiBhIGZhc2hpb24gc2ltaWxhciB0byB0aGUgTGlwIFN5bmNocm9uaXphdGlv biBvZiB2aWRlbyBhbmQgYXVkaW8gc3RyZWFtcyBpbiBSRkMgNTg4OCBTZWN0aW9uIDcuMSDigJxF eGFtcGxlIG9mIExT4oCdLg0KDQpJbiB0aGUgc2Vjb25kIFNEUCBleGFtcGxlLCBhIHNpbmdsZSDi gJxtPeKAnSBsaW5lIGlzIHByZXNlbnQgd2l0aG91dCBhbnkgZ3JvdXBpbmcsIGltcGx5aW5nIGFu eSBzeW5jaHJvbml6YXRpb24gd291bGQgYmUgZnJvbSBTU1JDL0NOQU1FIGxpbmthZ2UgYW5kL29y IFJUQ1AuDQoNClRoZSBtb3N0IGxpa2VseSBpbXBsZW1lbnRhdGlvbiBvZiB0aGlzIFJUUCBwYXls b2FkIGluIHByb2Zlc3Npb25hbCB2aWRlbyBwcm9kdWN0aW9uIHdvdWxkIGJlIHdoZXJlIG11bHRp cGxlIGVuZHBvaW50cyBhcmUgY29udHJpYnV0aW5nIGVsZW1lbnRhcnkgc3RyZWFtcyBvZiBtZWRp YTogdmlkZW8sIGF1ZGlvIGNoYW5uZWxzIG9yIGNoYW5uZWwgZ3JvdXBzLCBhbmQgU01QVEUgU1Qg MjkxLTEgYW5jaWxsYXJ5IGRhdGEgc291cmNlcy4gIFRob3NlIGVuZHBvaW50cyAobWljcm9waG9u ZXMsIGNhbWVyYXMsIENsb3NlZCBDYXB0aW9uIGdlbmVyYXRvcnMsIGV0Yy4pIGFyZSBhbGwgbGlr ZWx5IHRvIGJlIGRpZmZlcmVudCwgdGh1cyB3aXRoIGRpZmZlcmVudCBTU1JDcyBhbmQgQ05BTUVz LCBhbmQgdHJhbnNtaXR0aW5nIHRvIHNlcGFyYXRlIG11bHRpY2FzdCBJUCBhZGRyZXNzZXMgYW5k IFVEUCBwb3J0cy4gIEhvd2V2ZXIsIHRoZXkgd2lsbCBsaWtlbHkgYmUgdHJhbnNtaXR0ZWQgd2l0 aCBhIGNvbW1vbmx5IHN5bmNocm9uaXplZCBjbG9jayBhcyBwZXIgUkZDIDcyNzMg4oCcUlRQIENs b2NrIFNvdXJjZSBTaWduYWxsaW5n4oCdLCBtb3N0IGxpa2VseSBJRUVFIDE1ODggUFRQLiAgDQoN ClRoZSBpbmRpdmlkdWFsIGVsZW1lbnRhcnkgbWVkaWEgc3RyZWFtcyB3aWxsIGJlIGNvbXBvc2Vk IHRvZ2V0aGVyIGJ5IHJlY2VpdmVycyBhcyByZXF1aXJlZCBmb3IgcHJvZHVjdGlvbi4gIEZvciBl eGFtcGxlLCBmb3IgYW4gRW5nbGlzaCBsYW5ndWFnZSBzZXJ2aWNlLCBhbiBFbmdsaXNoIGF1ZGlv IGNoYW5uZWwgZ3JvdXAgb2YgQUVTNjcvUkZDIDMxOTAgUlRQIGF1ZGlvIHdvdWxkIGJlIGNvbXBv c2VkIHRvZ2V0aGVyIHdpdGggdGhlIFJGQyA0MTc1IHZpZGVvIGFuZCB0aGUgU1QgMjkxLTEgYW5j aWxsYXJ5IGRhdGEgZmxvdyBvZiBFbmdsaXNoIGxhbmd1YWdlIENsb3NlZCBDYXB0aW9ucyBhbmNp bGxhcnkgZGF0YSBhbmQgU01QVEUgMjAxNi0xIEFGRCBhbmNpbGxhcnkgZGF0YS4gICAgTWVhbndo aWxlIHRoZSBTcGFuaXNoIGxhbmd1YWdlIHNlcnZpY2Ugd291bGQgaGF2ZSB0aGUgc2FtZSB2aWRl byBhbmQgQUZEIGFuY2lsbGFyeSBkYXRhLCBidXQgd291bGQgaGF2ZSBTcGFuaXNoIGxhbmd1YWdl IGF1ZGlvIGFuZCBTcGFuaXNoIENsb3NlZCBDYXB0aW9ucy4gIExpa2VseSBpdCB3b3VsZCBiZSBh IGRpc3RyaWJ1dGlvbiBxdWFsaXR5IGVuY29kZXIgKHBlcmhhcHMgSC4yNjQgZW5jb2RlcikgdGhh dCBzdWJzY3JpYmVzIHRvIHRoZSBkaWZmZXJlbnQgc3RyZWFtcyBpbiBvcmRlciB0byBjcmVhdGUg dGhlIGZpbmFsIHNlcnZpY2UuDQoNCkV2ZXJ5IHRpbWUgSSByZWFkIGFib3V0IOKAnEZJROKAnSBp biBSRkMgNTg4OCwgSSBhbSBzdHJ1Y2sgYnkgdGhlIHNlbnRlbmNlIGluIFNlY3Rpb24gOCDigJxG bG93IElkZW50aWZpY2F0aW9uIChGSUQp4oCdIHRoYXQgc2F5cyDigJx0aGVyZSBhcmUgc2l0dWF0 aW9ucyB3aGVyZSBhIHNpbmdsZSBtZWRpYSBpbnN0YW5jZSAoZS5nLiwgYW4gYXVkaW8gc3RyZWFt IG9yIGEgdmlkZW8gc3RyZWFtKSBpcyBzZW50IHVzaW5nIG1vcmUgdGhhbiBvbmUgUlRQIHNlc3Np b24s4oCdIHdoaWNoIEkgYmVsaWV2ZSBpcyBub3QgdGhlIGNhc2UgaGVyZS4gIEZvciBleGFtcGxl LCB2aWRlbyBpcyBvbmUgbWVkaWEgaW5zdGFuY2UsIGFuZCBhbmNpbGxhcnkgZGF0YSBpcyBhIHNl Y29uZCBtZWRpYSBpbnN0YW5jZS4gIFlvdSBjYW7igJl0IOKAnGFkZOKAnSB2aWRlbyBhbmQgYW5j aWxsYXJ5IGRhdGEgdG9nZXRoZXIsIGxpa2UgeW91IGNhbiBhZGQgdG9nZXRoZXIgdm9pY2UgYXVk aW8gYW5kIERUTUYgdG9uZSBhdWRpbyAoYXMgaW4gUkZDIDU4ODggU2VjdGlvbiA4LjIpLiAgDQoN ClJGQyA1ODg4IFNlY3Rpb24gOC40IOKAnEZJRCBTZW1hbnRpY3PigJ0gYWxzbyBzdGF0ZXM6IOKA nEl0IGlzIGFzc3VtZWQgdGhhdCB0aGUgYXBwbGljYXRpb24gdXNlcyBvbmx5IG9uZSBjb2RlYyBh dCBhIHRpbWUgdG8gZW5jb2RlIHRoZSBtZWRpYSBwcm9kdWNlZC4gIFRoaXMgY29kZWMgTUFZIGNo YW5nZSBkeW5hbWljYWxseSBkdXJpbmcgdGhlIHNlc3Npb24sIGJ1dCBhdCBhbnkgcGFydGljdWxh ciBtb21lbnQsIG9ubHkgb25lIGNvZGVjIGlzIGluIHVzZS7igJ0gIEFnYWluLCB0aGlzIGRvZXMg bm90IHNlZW0gcmVsZXZhbnQgdG8gdGhlIFNEUCBkZXNjcmlwdGlvbiBvZiBtdWx0aXBsZSBSVFAg c3RyZWFtcyBvZiB2aWRlbywgYXVkaW8sIGFuZCBhbmNpbGxhcnkgZGF0YSBpbnRlbmRlZCBmb3Ig c3luY2hyb25pemVkIHByZXNlbnRhdGlvbi4gIEFsbCB0aHJlZSDigJxjb2RlY3PigJ0gYXJlIGlu IHVzZSBhdCBhbGwgdGltZXMgZm9yIHRoZWlyIHBhcnRpY3VsYXIgbWVkaWEgc3RyZWFtLiAgQW5k IGluIHBhcnRpY3VsYXIgcmVnYXJkaW5nIGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtYW5jaWxsYXJ5 LCB0aGVyZSBpcyBvbmx5IG9uZSDigJxjb2RlY+KAnSBldmVyIHVzZWQsIHRoZSBlbmNhcHN1bGF0 aW9uIG9mIFNNUFRFIFNUIDI5MS0xIGFuY2lsbGFyeSBkYXRhIHBhY2tldHMgaW50byBSVFAuDQoN CkkgY291bGQgcmVhbGx5IHVzZSB0aGUgaGVscCBvZiB0aGUgSUVTRyB0byBzZWUgaG93IHdlIGNh biBtb3ZlIGZvcndhcmQgcmVnYXJkaW5nIHRoZSBvcGVuIERJU0NVU1MgaXRlbSBvbiBkcmFmdC1p ZXRmLXBheWxvYWQtcnRwLWFuY2lsbGFyeS4NCg0KKEkgd2lsbCBub3RlIHRoYXQgU01QVEUgaXMg ZWFnZXJseSBhd2FpdGluZyB0aGUgcHVibGlzaGluZyBvZiB0aGlzIFJGQyBmb3IgdXNlIGFzIGEg bm9ybWF0aXZlIHJlZmVyZW5jZSBpbiB0aGUgdXBjb21pbmcgU1QgMjExMC00MCBzdGFuZGFyZCwg c2VlOiBodHRwczovL3d3dy5zbXB0ZS5vcmcvc3QtMjExMCkuDQoNClRoYW5rcyENCg0KLVRob21h cyBFZHdhcmRzDQogRk9YDQoNCk9uIDEwLzQvMTcsIDk6MjcgQU0sICJSb25pIEV2ZW4iIDxyb25p LmV2ZW5AaHVhd2VpLmNvbT4gd3JvdGU6DQoNCiAgICBIaSBDb2xpbiwNCiAgICANCiAgICBJIGFn cmVlLg0KICAgIA0KICAgIFRoZXJlIGFyZSB0d28gY2FzZXMuIFRoZSBhc3N1bXB0aW9uIGlzIHRo YXQgYm90aCB2aWRlbyBhbmQgQU5DIGhhdmUgdGhlIHNhbWUgc291cmNlIGFuZCBoYXZlIHNhbWUg Q05BTUUgKFRob21hcyAtIGlzIHRoaXMgY29ycmVjdD8pDQogICAgDQogICAgDQogICAgDQogICAg MS4gQm90aCB2aWRlbyBhbmQgQU5DIGFyZSBpbiB0aGUgc2FtZSBSVFAgc2Vzc2lvbiAoc2FtZSBt LWxpbmUpICB3aWxsIGJlIHN5bmNocm9uaXplZC4gDQogICAgDQogICAgDQogICAgDQogICAgVGhl IHNlY29uZCBpcyB0aGUgb25lIHdlIGFyZSBkaXNjdXNzaW5nOg0KICAgIA0KICAgIDIuIFRoZSB2 aWRlbyBhbmQgQU5DIGFyZSBpbiBzZXBhcmF0ZSBSVFAgc2Vzc2lvbnMgKHR3byBtLWxpbmVzKS4g SWYgYm90aCBhcmUgYSBzaW5nbGUgZmxvdyAoc2luZ2xlIFJUUCBzdHJlYW0pIHNob3VsZCBncm91 cCB1c2luZyBGSUQuIElmIHRoZXkgYXJlIG5vdCBhIHNpbmdsZSBSVFAgc3RyZWFtIChmbG93KSBz aG91bGQgdXNlIExTLg0KICAgIA0KICAgIA0KICAgIA0KICAgIEkgY2FuIGFncmVlIHRoYXQgaXQg bG9va3MgbGlrZSBhIHNpbmdsZSBmbG93IChGSUQpIGJ1dCB3YW50IGNsYXJpZmljYXRpb24gZnJv bSB0aGUgYXV0aG9ycyAoVGhvbWFzKQ0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KICAg IA0KICAgIA0KICAgIFJvbmkNCiAgICANCiAgICANCiAgICANCiAgICA+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQogICAgDQogICAgPiBGcm9tOiBDb2xpbiBQZXJraW5zIFttYWlsdG86Y3Nw QGNzcGVya2lucy5vcmddDQogICAgDQogICAgPiBTZW50OiDXmdeV150g15MgMDQg15DXlden15jX ldeR16ggMjAxNyAwMTo1MA0KICAgIA0KICAgID4gVG86IFJvbmkgRXZlbg0KICAgIA0KICAgID4g Q2M6IEFkYW0gUm9hY2g7IFRob21hcyBFZHdhcmRzOyBUaGUgSUVTRzsgcGF5bG9hZC1jaGFpcnNA aWV0Zi5vcmc7IGRyYWZ0LQ0KICAgIA0KICAgID4gaWV0Zi1wYXlsb2FkLXJ0cC1hbmNpbGxhcnlA aWV0Zi5vcmc7IHBheWxvYWRAaWV0Zi5vcmc7IGFjYmVnZW5AZ21haWwuY29tDQogICAgDQogICAg PiBTdWJqZWN0OiBSZTogW3BheWxvYWRdIEFkYW0gUm9hY2gncyBEaXNjdXNzIG9uIGRyYWZ0LWll dGYtcGF5bG9hZC1ydHAtDQogICAgDQogICAgPiBhbmNpbGxhcnktMTA6ICh3aXRoIERJU0NVU1Mg YW5kIENPTU1FTlQpDQogICAgDQogICAgPiANCiAgICANCiAgICA+IFJvbmksDQogICAgDQogICAg PiANCiAgICANCiAgICA+IEkgc2FpZCBub3RoaW5nIGFib3V0IG11bHRpY2FzdCB2cyB1bmljYXN0 LCBzaW5jZSBJIGRvbuKAmXQgdGhpbmsgdGhhdCBkaXN0aW5jdGlvbiBpcw0KICAgIA0KICAgID4g aW1wb3J0YW50Lg0KICAgIA0KICAgID4gDQogICAgDQogICAgPiBTZW5kaW5nIHRoZSBzdHJlYW1z IG9uIHNlcGFyYXRlIG09IGxpbmVzIG9yIHNlbmRpbmcgdXNpbmcgYSBzaW5nbGUgYSBtPSBsaW5l DQogICAgDQogICAgPiBib3RoIHdvcmsuIFRoZSBkcmFmdCBkb2VzbuKAmXQgbmVlZCB0byBkaXNj dXNzIHRoaXMsIHNpbmNlIGl04oCZcyBzdGFuZGFyZCBSVFAgYXMNCiAgICANCiAgICA+IHdvdWxk IGFwcGx5IHRvIGFueSBSVFAgc2Vzc2lvbi4gSWYgeW91IHVzZSBzZXBhcmF0ZSBtPSBsaW5lcywg dGhlbiB5b3UgbmVlZA0KICAgIA0KICAgID4gYSBncm91cGluZyBtZWNoYW5pc20uIFRoZSBjaG9p Y2Ugb2YgZ3JvdXBpbmcgbWVjaGFuaXNtIGlzIHdoYXQgd2XigJlyZQ0KICAgIA0KICAgID4gZGlz Y3Vzc2luZy4NCiAgICANCiAgICA+IA0KICAgIA0KICAgID4gQ29saW4NCiAgICANCiAgICA+IA0K ICAgIA0KICAgID4gDQogICAgDQogICAgPiANCiAgICANCiAgICA+IA0KICAgIA0KICAgID4gPiBP biAzIE9jdCAyMDE3LCBhdCAyMzoxOSwgUm9uaSBFdmVuIDxyb25pLmV2ZW5AaHVhd2VpLmNvbT4g d3JvdGU6DQogICAgDQogICAgPiA+DQogICAgDQogICAgPiA+IENvbGluLA0KICAgIA0KICAgID4g PiBXZSBzdGlsbCBuZWVkIHNvbWUgZmVlZGJhY2sgZnJvbSBUaG9tYXMsIGluIGEgcHJldmlvdXMg ZW1haWwgcmVzcG9uc2UgdG8NCiAgICANCiAgICA+IEFkYW0gaGUgZ2F2ZSBhIHJlYXNvbiBmb3Ig dXNpbmcgbXVsdGlwbGUgUlRQIHNlc3Npb25zOg0KICAgIA0KICAgID4gPg0KICAgIA0KICAgID4g PiAiVGhlIGNoYWxsZW5nZSBpcyB0aGF0IHRoZSB1c2UgY2FzZSBvZiB0aGUgQW5jaWxsYXJ5IEkt RCB3aXRoaW4gdGhlIFNNUFRFIFNUDQogICAgDQogICAgPiAyMTEwIGFyY2hpdGVjdHVyZSB3b3Vs ZCBnZW5lcmFsbHkgcmVxdWlyZSBzZXBhcmF0ZSBuZXR3b3JrIGRlc3RpbmF0aW9uDQogICAgDQog ICAgPiBhZGRyZXNzZXMgZm9yIHRoZSBkaWZmZXJlbnQgZWxlbWVudHMgKHZpZGVvLCBhdWRpbywg YW5jaWxsYXJ5IGRhdGEpIHNvIHRoZXkNCiAgICANCiAgICA+IGNhbiBiZSBmbGV4aWJseSBjb21w b3NlZCB3aXRoaW4gYnJvYWRjYXN0IHBsYW50cyBhdCB0aGUgbmV0d29yayBsZXZlbC4gIFlvdXIN CiAgICANCiAgICA+IGFsdGVybmF0aXZlIFNEUCBleGFtcGxlIGFwcGVhcnMgdG8gcGxhY2UgYm90 aCB0aGUgdmlkZW8gYW5kIHRoZSBhbmNpbGxhcnkNCiAgICANCiAgICA+IGRhdGEgb250byB0aGUg c2FtZSBkZXN0aW5hdGlvbiBhZGRyZXNzIChodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cC0zQV9fMjMzLjI1Mi4wLjEmZD1Ed0lHYVEmYz11dzZUTHU0aHdoSGRp R0pPZ3djV0Q0QWpLUXg2enZGY0dFc2JmaVk5LUVJJnI9bGVrTk9PTTVub1Y2MXpyUEgzcndQeWh0 Tm5MTFdvTEVIZ2QwcXVReGx5OCZtPWRPeEhBN2RuNWQyZW9fdFUzZGl2ZDRrczZtbVhQaGs1V21v ZExVTEhVUFkmcz1zcnpESERHMkxUY1RCSmV4SUR0YTQtcDkxNDJTWWtRMmdESDNTOFBNZFpnJmU9 KS4gIElzIHRoZXJlIGFuDQogICAgDQogICAgPiBhcHByb3ByaWF0ZSBTRFAgbWVjaGFuaXNtIHRv IGNvbW11bmljYXRlIHRoZSBpbnRpbWF0ZSByZWxhdGlvbnNoaXANCiAgICANCiAgICA+IGJldHdl ZW4gdGhlIFJUUCBzdHJlYW1zLCBidXQgYWxzbyBoYXZlIHRoZW0gdHJhbnNtaXR0ZWQgb24gc2Vw YXJhdGUNCiAgICANCiAgICA+IGRlc3RpbmF0aW9uIElQIGFkZHJlc3NlcyAoYW5kIHN5bmNocm9u aXplZCk/DQogICAgDQogICAgPiA+DQogICAgDQogICAgPiA+IChJbiBwcm9kdWN0aW9uIHByYWN0 aWNlLCB0aGlzIG1heSBub3QgYmUgYSBzaWduaWZpY2FudCBpc3N1ZSBhcyB0aGUgUlRQDQogICAg DQogICAgPiBzdHJlYW1zIHRvIGJlIGNvbWJpbmVkIGJ5IElQIHJlY2VpdmVycyBmb3IgY29udmVy c2lvbiB0byBTREkvSERNSSBvciBmb3INCiAgICANCiAgICA+IGlucHV0IHRvIGEgZGlzdHJpYnV0 aW9uIGVuY29kZXIgbWF5IGJlIHNwZWNpZmllZCBieSBhIGNvbnRyb2wgc3lzdGVtIGRpcmVjdGx5 DQogICAgDQogICAgPiB0byB0aGUgcmVjZWl2ZXIgdXNpbmcgYW4gQVBJIHRoYXQgaXNu4oCZdCBq dXN0IGFuIFNEUCBmaWxlLikiDQogICAgDQogICAgPiA+DQogICAgDQogICAgPiA+IEkgd2FudCB0 byBhc3N1bWUgdGhhdCBieSBkaWZmZXJlbnQgZGVzdGluYXRpb24gYWRkcmVzc2VzIGl0IHJlZmVy cyB0bw0KICAgIA0KICAgID4gbXVsdGljYXN0IGFkZHJlc3NlcyBsaWtlIGFib3ZlIGFuZCBub3Qg dG8gZGlmZmVyZW50IHVuaWNhc3QgSVAgYWRkcmVzc2VzLg0KICAgIA0KICAgID4gPiBZb3UgYXJl IHJpZ2h0IHRoYXQgZm9yIHVuaWNhc3QgaXQgd2lsbCBtYWtlIHNlbnNlIHRvIHVzZSB0aGUgc2Ft ZSBSVFAgc2Vzc2lvbg0KICAgIA0KICAgID4gd2l0aCB0aGUgc2FtZSBTU1JDLg0KICAgIA0KICAg ID4gPg0KICAgIA0KICAgID4gPiBSb25pDQogICAgDQogICAgPiA+DQogICAgDQogICAgPiA+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgIA0KICAgID4gPj4gRnJvbTogQ29saW4gUGVy a2lucyBbbWFpbHRvOmNzcEBjc3BlcmtpbnMub3JnXQ0KICAgIA0KICAgID4gPj4gU2VudDog15nX ldedINeTIDA0INeQ15XXp9eY15XXkdeoIDIwMTcgMDA6NDYNCiAgICANCiAgICA+ID4+IFRvOiBS b25pIEV2ZW4NCiAgICANCiAgICA+ID4+IENjOiBBZGFtIFJvYWNoOyBUaG9tYXMgRWR3YXJkczsg VGhlIElFU0c7IHBheWxvYWQtY2hhaXJzQGlldGYub3JnOw0KICAgIA0KICAgID4gPj4gZHJhZnQt IGlldGYtcGF5bG9hZC1ydHAtYW5jaWxsYXJ5QGlldGYub3JnOyBwYXlsb2FkQGlldGYub3JnOw0K ICAgIA0KICAgID4gPj4gYWNiZWdlbkBnbWFpbC5jb20NCiAgICANCiAgICA+ID4+IFN1YmplY3Q6 IFJlOiBbcGF5bG9hZF0gQWRhbSBSb2FjaCdzIERpc2N1c3Mgb24NCiAgICANCiAgICA+ID4+IGRy YWZ0LWlldGYtcGF5bG9hZC1ydHAtDQogICAgDQogICAgPiA+PiBhbmNpbGxhcnktMTA6ICh3aXRo IERJU0NVU1MgYW5kIENPTU1FTlQpDQogICAgDQogICAgPiA+Pg0KICAgIA0KICAgID4gPj4NCiAg ICANCiAgICA+ID4+PiBPbiAzIE9jdCAyMDE3LCBhdCAyMTo0MCwgUm9uaSBFdmVuIDxyb25pLmV2 ZW5AaHVhd2VpLmNvbT4gd3JvdGU6DQogICAgDQogICAgPiA+Pj4NCiAgICANCiAgICA+ID4+PiBI aSBDb2xpbiwNCiAgICANCiAgICA+ID4+PiBJIHJlLXJlYWQgUkZDNTg4OCBhbmQgdHJpZWQgdG8g dW5kZXJzdGFuZCB3aGF0IGlzIHRoZSBkaWZmZXJlbmNlDQogICAgDQogICAgPiA+Pj4gYmV0d2Vl biBGSUQgYW5kIExTIEkgd2FzIHRyeWluZyB0byB1bmRlcnN0YW5kIHdoYXQgaXMgYSBmbG93IGFu ZA0KICAgIA0KICAgID4gPj4+IGZyb20gc2VjdGlvbiA4LjMNCiAgICANCiAgICA+ID4+Pg0KICAg IA0KICAgID4gPj4+ICJUaGUgcHJldmlvdXMgZXhhbXBsZXMgc2hvdyB0aGF0IHRoZSBkZWZpbml0 aW9uIG9mIGEgbWVkaWEgc3RyZWFtIGluDQogICAgDQogICAgPiA+Pj4gW1JGQzIzMjZdIGRvZXMg bm90IGNvdmVyIHNvbWUgc2NlbmFyaW9zLiAgSXQgY2Fubm90IGJlIGFzc3VtZWQgdGhhdA0KICAg IA0KICAgID4gPj4+IGEgIHNpbmdsZSBtZWRpYSBpbnN0YW5jZSBtYXBzIGludG8gYSBzaW5nbGUg UlRQIHNlc3Npb24uICBUaGVyZWZvcmUsDQogICAgDQogICAgPiA+Pj4gd2UgIGludHJvZHVjZSB0 aGUgZGVmaW5pdGlvbiBvZiBhIG1lZGlhIGZsb3c6DQogICAgDQogICAgPiA+Pj4NCiAgICANCiAg ICA+ID4+PiAgICAgQSBtZWRpYSBmbG93IGNvbnNpc3RzIG9mIGEgc2luZ2xlIG1lZGlhIGluc3Rh bmNlLCBlLmcuLCBhbiBhdWRpbw0KICAgIA0KICAgID4gPj4+ICAgICBzdHJlYW0gb3IgYSB2aWRl byBzdHJlYW0gYXMgd2VsbCBhcyBhIHNpbmdsZSB3aGl0ZWJvYXJkIG9yIHNoYXJlZA0KICAgIA0K ICAgID4gPj4+ICAgICBhcHBsaWNhdGlvbiBncm91cC4gIFdoZW4gdXNpbmcgUlRQLCBhIG1lZGlh IGZsb3cgY29tcHJpc2VzIG9uZSBvcg0KICAgIA0KICAgID4gPj4+ICAgICBtb3JlIFJUUCBzZXNz aW9ucy4iDQogICAgDQogICAgPiA+Pj4NCiAgICANCiAgICA+ID4+PiBJdCBsb29rcyB0byBtZSB0 aGF0IGEgbWVkaWEgZmxvdyBpcyBhIFNJTkdMRSBtZWRpYSBzdHJlYW0gdGhhdCBzcGFucw0KICAg IA0KICAgID4gPj4+IG92ZXINCiAgICANCiAgICA+ID4+IG11bHRpcGxlIFJUUCBzZXNzaW9ucyAo dGhlIHRlcm0gbWVkaWEgaW5zdGFuY2UgaXMgYSB3aGF0IHdlIGNhbGwgYQ0KICAgIA0KICAgID4g Pj4gbWVkaWEgc3RyZWFtIGluIHRoZSB0YXhvbm9teSkuIFNlY3Rpb24gOC41ICg4LjUuMSkgZW5o YW5jZSB0aGlzIGJ5DQogICAgDQogICAgPiA+PiBzYXlpbmcgd2hlbiBGSUQgY2Fubm90IGJlIHVz ZWQgIiBGSUQgc2VtYW50aWNzIGFyZSB1c2VmdWwgd2hlbiB0aGUNCiAgICANCiAgICA+IGFwcGxp Y2F0aW9uIG9ubHkgdXNlcw0KICAgIA0KICAgID4gPj4gb25lIGNvZGVjIGF0ICAgYSB0aW1lIiAg d2hpY2ggYWdhaW4gZGVzY3JpYmUgYSBmbG93IGFzIGEgc2luZ2xlIG1lZGlhDQogICAgDQogICAg PiBzdHJlYW0uDQogICAgDQogICAgPiA+Pj4NCiAgICANCiAgICA+ID4+PiBJIGFtIG5vdCBzdXJl IGhvdyBBTkMgYW5kIHRoZSB2aWRlbyByZWxhdGVzIHRvIGVhY2ggb3RoZXIgdGhpcyBpcw0KICAg IA0KICAgID4gPj4+IHdoYXQgSSBhbQ0KICAgIA0KICAgID4gPj4gYXNraW5nIFRob21hcyB0byBi ZSBtb3JlIGNsZWFyLiBJZiB0aGUgdmlkZW8gYW5kIEFOQyBhcmUgb25lIHN0cmVhbQ0KICAgIA0K ICAgID4gPj4gb3ZlciBtdWx0aXBsZSBSVFAgc2Vzc2lvbnMgRklEIGlzIGNvcnJlY3Qgb3RoZXJ3 aXNlIEkgdGhpbmsgdGhlIExTIHNob3VsZCBiZQ0KICAgIA0KICAgID4gdXNlZC4NCiAgICANCiAg ICA+ID4+DQogICAgDQogICAgPiA+PiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhlIHZpZGVv IGFuZCBhbmNpbGxhcnkgZGF0YSBhcmUgdGhlIHNhbWUNCiAgICANCiAgICA+ID4+IHN0cmVhbS4g SW4gYnJvYWRjYXN0IFRWIHRoZSBhbmNpbGxhcnkgZGF0YSBpcyBzZW50IGluLWJhbmQsIGluIHRo ZSBibGFua2luZw0KICAgIA0KICAgID4gaW50ZXJ2YWxzLg0KICAgIA0KICAgID4gPj4NCiAgICAN CiAgICA+ID4+PiBNeSByZWFkaW5nIG9uICB0aGUgYW5jaWxsYXJ5IGRyYWZ0IGlzIHRoYXQgQU5D IGFuZCB0aGUgdmlkZW8gYXJlDQogICAgDQogICAgPiA+Pj4gd2hhdCB3ZSBjYWxsDQogICAgDQog ICAgPiA+PiBhIHNpbmdsZSBSVFAgc3RyZWFtIGJ1dCB0aGlzIGlzIG5vdCB3aGF0IFRob21hcyBz YXlzLg0KICAgIA0KICAgID4gPj4NCiAgICANCiAgICA+ID4+DQogICAgDQogICAgPiA+PiBJIGV4 cGVjdCBvbmUgY291bGQgc2VuZCB0aGUgYW5jaWxsYXJ5IGRhdGEgdXNpbmcgdGhlIHNhbWUgU1NS QywgYW5kDQogICAgDQogICAgPiA+PiB0aGUgc2FtZSA1LXR1cGxlLCBhcyB0aGUgbWVkaWEgZGF0 YSAoaW4gdGhlIHNhbWUgd2F5IGNvbWZvcnQgbm9pc2UNCiAgICANCiAgICA+ID4+IGFuZCBzcGVl Y2ggZGF0YSBjYW4gYmUgc2VudCksIGluIHdoaWNoIGNhc2UgeW91IGRvbuKAmXQgbmVlZCB0aGUN CiAgICANCiAgICA+ID4+IGdyb3VwaW5nLiBJZiB0aGV54oCZcmUgc2VudCBhcyBzZXBhcmF0ZSBS VFAgc3RyZWFtcywgd2l0aCBzZXBhcmF0ZSBtPQ0KICAgIA0KICAgID4gPj4gbGluZXMsIHRoZW4g eW91IG5lZWQgZ3JvdXBpbmcuIEkgYmVsaWV2ZSBGSUQgbWFrZXMgc2Vuc2UgZm9yIHRoaXMuDQog ICAgDQogICAgPiA+Pg0KICAgIA0KICAgID4gPj4gLS0NCiAgICANCiAgICA+ID4+IENvbGluIFBl cmtpbnMNCiAgICANCiAgICA+ID4+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fY3NwZXJraW5zLm9yZ18mZD1Ed0lHYVEmYz11dzZUTHU0aHdoSGRp R0pPZ3djV0Q0QWpLUXg2enZGY0dFc2JmaVk5LUVJJnI9bGVrTk9PTTVub1Y2MXpyUEgzcndQeWh0 Tm5MTFdvTEVIZ2QwcXVReGx5OCZtPWRPeEhBN2RuNWQyZW9fdFUzZGl2ZDRrczZtbVhQaGs1V21v ZExVTEhVUFkmcz1zMldlMmVzLU15MUpSZmNQbFlaRW1xR0NZWWk5cmY5V2M3ZFlSenhzcHNZJmU9 DQogICAgDQogICAgPiA+Pg0KICAgIA0KICAgID4gPj4NCiAgICANCiAgICA+ID4+DQogICAgDQog ICAgPiA+DQogICAgDQogICAgPiANCiAgICANCiAgICA+IA0KICAgIA0KICAgID4gDQogICAgDQog ICAgPiAtLQ0KICAgIA0KICAgID4gQ29saW4gUGVya2lucw0KICAgIA0KICAgID4gaHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19jc3BlcmtpbnMub3Jn XyZkPUR3SUdhUSZjPXV3NlRMdTRod2hIZGlHSk9nd2NXRDRBaktReDZ6dkZjR0VzYmZpWTktRUkm cj1sZWtOT09NNW5vVjYxenJQSDNyd1B5aHRObkxMV29MRUhnZDBxdVF4bHk4Jm09ZE94SEE3ZG41 ZDJlb190VTNkaXZkNGtzNm1tWFBoazVXbW9kTFVMSFVQWSZzPXMyV2UyZXMtTXkxSlJmY1BsWVpF bXFHQ1lZaTlyZjlXYzdkWVJ6eHNwc1kmZT0NCiAgICANCiAgICA+IA0KICAgIA0KICAgID4gDQog ICAgDQogICAgPiANCiAgICANCiAgICANCiAgICANCiAgICANCg0K From nobody Mon Oct 9 23:46:21 2017 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 4E73E134885 for ; Mon, 9 Oct 2017 23:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trnAIInNcKKU for ; Mon, 9 Oct 2017 23:46:15 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F38134824 for ; Mon, 9 Oct 2017 23:44:42 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id 34so31238180qtb.13 for ; Mon, 09 Oct 2017 23:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=unPDINAZj7U/eVE+Jtt1NJvnyy3aHOmPRC3BFhvUIy8=; b=1JFUc9ZD07AEZo8cUlfL0dcHvjCqH/4DMbh4Ss65oc98n+M1vhMxLSm3EeVWlGDoDx rCzf6j8t5wjPq2uACsCh8vZ80AWYOuZze9gyE/5NjgTK8WO8PG24jwSrNdIgWyCkWO1j Bc/liHWtF7hQkHx7hvLF5evdl4vkH5IfooDt67/DrtnCkqpx4fK6MDIv/naA4gik2zBI DlrBK2Ory7QOWdi46Yo6ZN1ldspwO7u47q4NAFTX2MT+NB0ea77g9up58nr4Pr82WxlR XEA6N54vwZcFWHeoH/Yh/I3Wruc8dfLu2pJ9r5d2MCQIlkBy7z/iE0xPDCCn3F9Glm8v 97WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=unPDINAZj7U/eVE+Jtt1NJvnyy3aHOmPRC3BFhvUIy8=; b=BnJKF9bS12Pb4Pr4E96+lnF+8PovC7X3Wtk7lFz/+SlTVEo/9TAZPFo1ofeRWePpJF TSReqor1VAAr8KWeknQe8iuI/3BNimuJzG/UH5k5iad/pLQU1rK2G0AlNrTBw9GDpYaO 4dNrt+ds1p2jObwA21ONhQA5SrKlJ0NRCuE573t68Whz+5i5EVVHEEA95xT2wkDVkBF6 91+b1bk1LeoR3Ch1Tj5YG47S/qjlV4+gq30mVoQc+VLMFQ0ftZGnW++E/JZZcBiKpTN0 vzbmBEwIqjqipHSmcuS0l/1nSPGDpF70mnj4oknbqI8yXHi2cT51YHAfWv28vfqUtq99 CM7A== X-Gm-Message-State: AMCzsaViHu26YkjB6jP6p9YZUKxFbImlsrVuHO6n1h0wHuZjt5vgUwMU z0LhvdeyDO28NSu0CwpJiOtXOE6kZsYBR4uSYb+qXg== X-Google-Smtp-Source: AOwi7QD9p1UrWVHSV6Kq91jCZO+0txJpi4ZNAU8oArJ4wfB2F4GptKv4asKzQWIhFTqm5Xj0Wbs6kf2fwFegrXdt0tQ= X-Received: by 10.37.87.198 with SMTP id l189mr1490040ybb.71.1507617881007; Mon, 09 Oct 2017 23:44:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.194.129 with HTTP; Mon, 9 Oct 2017 23:44:40 -0700 (PDT) In-Reply-To: <7D009531-3DB3-4923-80B2-38BC3F9FB020@foxeg.com> References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <3B259563-1075-4C41-A832-D7633C39173B@foxeg.com> <61440eb5-32c3-3696-be38-8dc7c4eaf72f@nostrum.com> <863974D7-E112-4794-AD4D-C39C99BD40C9@foxeg.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> <6E58094ECC8D8344914996DAD28F1CCD810BB8@DGGEMM506-MBX.china.huawei.com> <37F6B554-530B-4A30-B66F-A70D026DD2B8@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810CC5@DGGEMM506-MBX.china.huawei.com> <04D71781-0E87-461C-BDA0-D44F94FED1A0@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810D79@DGGEMM506-MBX.china.huawei.com> <7574DE41-96BB-45C1-8279-F9E2460E0452@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD81103C@DGGEMM506-MBX.china.huawei.com> <7D009531-3DB3-4923-80B2-38BC3F9FB020@foxeg.com> From: "Ali C. Begen" Date: Tue, 10 Oct 2017 09:44:40 +0300 Message-ID: To: Thomas Edwards Cc: Roni Even , Colin Perkins , Adam Roach , The IESG , "payload-chairs@ietf.org" , "payload@ietf.org" Content-Type: multipart/alternative; boundary="001a113ffca4413d1c055b2ba431" Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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 Oct 2017 06:46:18 -0000 --001a113ffca4413d1c055b2ba431 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Thomas Please go ahead and submit a revision. Then reach out to the individual DISCUSS holders to clear theirs. And then lets focus on Adam's discuss. Thanks -acbegen (your payload wg co-chair) On Tue, Oct 10, 2017 at 3:06 AM, Thomas Edwards wrote: > I will note that I have uploaded a new version, draft-ietf-payload-rtp-an= cillary-11, > to address most of the comments from the IESG evaluation. > > draft-ietf-payload-rtp-ancillary-11, Section 4.1 =E2=80=9CGrouping ANC St= reams > with other Media Streams=E2=80=9D has two examples. > > In the first SDP example, two =E2=80=9Cm=3D=E2=80=9D lines are present (w= ith each having a > different =E2=80=9Cc=3D=E2=80=9D line), one for uncompressed video, and o= ne for ancillary > data. The two RTP sessions are identified with RFC 5888 Media Stream > Identification Attributes (mid), and are grouped together using Lip > Synchronization (LS), in a fashion similar to the Lip Synchronization of > video and audio streams in RFC 5888 Section 7.1 =E2=80=9CExample of LS=E2= =80=9D. > > In the second SDP example, a single =E2=80=9Cm=3D=E2=80=9D line is presen= t without any > grouping, implying any synchronization would be from SSRC/CNAME linkage > and/or RTCP. > > The most likely implementation of this RTP payload in professional video > production would be where multiple endpoints are contributing elementary > streams of media: video, audio channels or channel groups, and SMPTE ST > 291-1 ancillary data sources. Those endpoints (microphones, cameras, > Closed Caption generators, etc.) are all likely to be different, thus wit= h > different SSRCs and CNAMEs, and transmitting to separate multicast IP > addresses and UDP ports. However, they will likely be transmitted with a > commonly synchronized clock as per RFC 7273 =E2=80=9CRTP Clock Source Sig= nalling=E2=80=9D, > most likely IEEE 1588 PTP. > > The individual elementary media streams will be composed together by > receivers as required for production. For example, for an English langua= ge > service, an English audio channel group of AES67/RFC 3190 RTP audio would > be composed together with the RFC 4175 video and the ST 291-1 ancillary > data flow of English language Closed Captions ancillary data and SMPTE > 2016-1 AFD ancillary data. Meanwhile the Spanish language service woul= d > have the same video and AFD ancillary data, but would have Spanish langua= ge > audio and Spanish Closed Captions. Likely it would be a distribution > quality encoder (perhaps H.264 encoder) that subscribes to the different > streams in order to create the final service. > > Every time I read about =E2=80=9CFID=E2=80=9D in RFC 5888, I am struck by= the sentence in > Section 8 =E2=80=9CFlow Identification (FID)=E2=80=9D that says =E2=80=9C= there are situations where > a single media instance (e.g., an audio stream or a video stream) is sent > using more than one RTP session,=E2=80=9D which I believe is not the case= here. > For example, video is one media instance, and ancillary data is a second > media instance. You can=E2=80=99t =E2=80=9Cadd=E2=80=9D video and ancill= ary data together, like > you can add together voice audio and DTMF tone audio (as in RFC 5888 > Section 8.2). > > RFC 5888 Section 8.4 =E2=80=9CFID Semantics=E2=80=9D also states: =E2=80= =9CIt is assumed that the > application uses only one codec at a time to encode the media produced. > This codec MAY change dynamically during the session, but at any particul= ar > moment, only one codec is in use.=E2=80=9D Again, this does not seem rel= evant to > the SDP description of multiple RTP streams of video, audio, and ancillar= y > data intended for synchronized presentation. All three =E2=80=9Ccodecs= =E2=80=9D are in use > at all times for their particular media stream. And in particular > regarding draft-ietf-payload-rtp-ancillary, there is only one =E2=80=9Cco= dec=E2=80=9D > ever used, the encapsulation of SMPTE ST 291-1 ancillary data packets int= o > RTP. > > I could really use the help of the IESG to see how we can move forward > regarding the open DISCUSS item on draft-ietf-payload-rtp-ancillary. > > (I will note that SMPTE is eagerly awaiting the publishing of this RFC fo= r > use as a normative reference in the upcoming ST 2110-40 standard, see: > https://www.smpte.org/st-2110). > > Thanks! > > -Thomas Edwards > FOX > > On 10/4/17, 9:27 AM, "Roni Even" wrote: > > Hi Colin, > > I agree. > > There are two cases. The assumption is that both video and ANC have > the same source and have same CNAME (Thomas - is this correct?) > > > > 1. Both video and ANC are in the same RTP session (same m-line) will > be synchronized. > > > > The second is the one we are discussing: > > 2. The video and ANC are in separate RTP sessions (two m-lines). If > both are a single flow (single RTP stream) should group using FID. If the= y > are not a single RTP stream (flow) should use LS. > > > > I can agree that it looks like a single flow (FID) but want > clarification from the authors (Thomas) > > > > > > > > Roni > > > > > -----Original Message----- > > > From: Colin Perkins [mailto:csp@csperkins.org] > > > Sent: =D7=99=D7=95=D7=9D =D7=93 04 =D7=90=D7=95=D7=A7=D7=98=D7=95= =D7=91=D7=A8 2017 01:50 > > > To: Roni Even > > > Cc: Adam Roach; Thomas Edwards; The IESG; payload-chairs@ietf.org; > draft- > > > ietf-payload-rtp-ancillary@ietf.org; payload@ietf.org; > acbegen@gmail.com > > > Subject: Re: [payload] Adam Roach's Discuss on > draft-ietf-payload-rtp- > > > ancillary-10: (with DISCUSS and COMMENT) > > > > > > Roni, > > > > > > I said nothing about multicast vs unicast, since I don=E2=80=99t th= ink that > distinction is > > > important. > > > > > > Sending the streams on separate m=3D lines or sending using a singl= e a > m=3D line > > > both work. The draft doesn=E2=80=99t need to discuss this, since it= =E2=80=99s > standard RTP as > > > would apply to any RTP session. If you use separate m=3D lines, the= n > you need > > > a grouping mechanism. The choice of grouping mechanism is what we= =E2=80=99re > > > discussing. > > > > > > Colin > > > > > > > > > > > > > > > > On 3 Oct 2017, at 23:19, Roni Even wrote: > > > > > > > > Colin, > > > > We still need some feedback from Thomas, in a previous email > response to > > > Adam he gave a reason for using multiple RTP sessions: > > > > > > > > "The challenge is that the use case of the Ancillary I-D within > the SMPTE ST > > > 2110 architecture would generally require separate network > destination > > > addresses for the different elements (video, audio, ancillary data) > so they > > > can be flexibly composed within broadcast plants at the network > level. Your > > > alternative SDP example appears to place both the video and the > ancillary > > > data onto the same destination address (https://urldefense. > proofpoint.com/v2/url?u=3Dhttp-3A__233.252.0.1&d=3DDwIGaQ&c=3D > uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=3D > lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DdOxHA7dn5d2eo_ > tU3divd4ks6mmXPhk5WmodLULHUPY&s=3DsrzDHDG2LTcTBJexIDta4- > p9142SYkQ2gDH3S8PMdZg&e=3D). Is there an > > > appropriate SDP mechanism to communicate the intimate relationship > > > between the RTP streams, but also have them transmitted on separate > > > destination IP addresses (and synchronized)? > > > > > > > > (In production practice, this may not be a significant issue as > the RTP > > > streams to be combined by IP receivers for conversion to SDI/HDMI o= r > for > > > input to a distribution encoder may be specified by a control syste= m > directly > > > to the receiver using an API that isn=E2=80=99t just an SDP file.)" > > > > > > > > I want to assume that by different destination addresses it refer= s > to > > > multicast addresses like above and not to different unicast IP > addresses. > > > > You are right that for unicast it will make sense to use the same > RTP session > > > with the same SSRC. > > > > > > > > Roni > > > > > > > >> -----Original Message----- > > > >> From: Colin Perkins [mailto:csp@csperkins.org] > > > >> Sent: =D7=99=D7=95=D7=9D =D7=93 04 =D7=90=D7=95=D7=A7=D7=98=D7= =95=D7=91=D7=A8 2017 00:46 > > > >> To: Roni Even > > > >> Cc: Adam Roach; Thomas Edwards; The IESG; payload-chairs@ietf.or= g > ; > > > >> draft- ietf-payload-rtp-ancillary@ietf.org; payload@ietf.org; > > > >> acbegen@gmail.com > > > >> Subject: Re: [payload] Adam Roach's Discuss on > > > >> draft-ietf-payload-rtp- > > > >> ancillary-10: (with DISCUSS and COMMENT) > > > >> > > > >> > > > >>> On 3 Oct 2017, at 21:40, Roni Even wrote= : > > > >>> > > > >>> Hi Colin, > > > >>> I re-read RFC5888 and tried to understand what is the differenc= e > > > >>> between FID and LS I was trying to understand what is a flow an= d > > > >>> from section 8.3 > > > >>> > > > >>> "The previous examples show that the definition of a media > stream in > > > >>> [RFC2326] does not cover some scenarios. It cannot be assumed > that > > > >>> a single media instance maps into a single RTP session. > Therefore, > > > >>> we introduce the definition of a media flow: > > > >>> > > > >>> A media flow consists of a single media instance, e.g., an > audio > > > >>> stream or a video stream as well as a single whiteboard or > shared > > > >>> application group. When using RTP, a media flow comprises > one or > > > >>> more RTP sessions." > > > >>> > > > >>> It looks to me that a media flow is a SINGLE media stream that > spans > > > >>> over > > > >> multiple RTP sessions (the term media instance is a what we call= a > > > >> media stream in the taxonomy). Section 8.5 (8.5.1) enhance this = by > > > >> saying when FID cannot be used " FID semantics are useful when t= he > > > application only uses > > > >> one codec at a time" which again describe a flow as a single > media > > > stream. > > > >>> > > > >>> I am not sure how ANC and the video relates to each other this = is > > > >>> what I am > > > >> asking Thomas to be more clear. If the video and ANC are one > stream > > > >> over multiple RTP sessions FID is correct otherwise I think the > LS should be > > > used. > > > >> > > > >> My understanding is that the video and ancillary data are the sa= me > > > >> stream. In broadcast TV the ancillary data is sent in-band, in > the blanking > > > intervals. > > > >> > > > >>> My reading on the ancillary draft is that ANC and the video ar= e > > > >>> what we call > > > >> a single RTP stream but this is not what Thomas says. > > > >> > > > >> > > > >> I expect one could send the ancillary data using the same SSRC, > and > > > >> the same 5-tuple, as the media data (in the same way comfort noi= se > > > >> and speech data can be sent), in which case you don=E2=80=99t ne= ed the > > > >> grouping. If they=E2=80=99re sent as separate RTP streams, with = separate > m=3D > > > >> lines, then you need grouping. I believe FID makes sense for thi= s. > > > >> > > > >> -- > > > >> Colin Perkins > > > >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__ > csperkins.org_&d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI= &r=3D > lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DdOxHA7dn5d2eo_ > tU3divd4ks6mmXPhk5WmodLULHUPY&s=3Ds2We2es-My1JRfcPlYZEmqGCYYi9rf9Wc7dYRz > xspsY&e=3D > > > >> > > > >> > > > >> > > > > > > > > > > > > > > > > -- > > > Colin Perkins > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__ > csperkins.org_&d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI= &r=3D > lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DdOxHA7dn5d2eo_ > tU3divd4ks6mmXPhk5WmodLULHUPY&s=3Ds2We2es-My1JRfcPlYZEmqGCYYi9rf9Wc7dYRz > xspsY&e=3D > > > > > > > > > > > > > > > --001a113ffca4413d1c055b2ba431 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Thomas

Please go ahead and submit a = revision. Then reach out to the individual DISCUSS holders to clear theirs.= And then lets focus on Adam's discuss.

Thanks=
-acbegen (your payload wg co-chair)

On Tue, Oct 10, 2017 at 3:06 AM, T= homas Edwards <Thomas.Edwards@fox.com> wrote:
I will note that I have uploaded a new version, dr= aft-ietf-payload-rtp-ancillary-11, to address most of the comments fro= m the IESG evaluation.

draft-ietf-payload-rtp-ancillary-11, Section 4.1 =E2=80=9CGrouping ANC= Streams with other Media Streams=E2=80=9D has two examples.

In the first SDP example, two =E2=80=9Cm=3D=E2=80=9D lines are present (wit= h each having a different =E2=80=9Cc=3D=E2=80=9D line), one for uncompresse= d video, and one for ancillary data.=C2=A0 The two RTP sessions are identif= ied with RFC 5888 Media Stream Identification Attributes (mid), and are gro= uped together using Lip Synchronization (LS), in a fashion similar to the L= ip Synchronization of video and audio streams in RFC 5888 Section 7.1 =E2= =80=9CExample of LS=E2=80=9D.

In the second SDP example, a single =E2=80=9Cm=3D=E2=80=9D line is present = without any grouping, implying any synchronization would be from SSRC/CNAME= linkage and/or RTCP.

The most likely implementation of this RTP payload in professional video pr= oduction would be where multiple endpoints are contributing elementary stre= ams of media: video, audio channels or channel groups, and SMPTE ST 291-1 a= ncillary data sources.=C2=A0 Those endpoints (microphones, cameras, Closed = Caption generators, etc.) are all likely to be different, thus with differe= nt SSRCs and CNAMEs, and transmitting to separate multicast IP addresses an= d UDP ports.=C2=A0 However, they will likely be transmitted with a commonly= synchronized clock as per RFC 7273 =E2=80=9CRTP Clock Source Signalling=E2= =80=9D, most likely IEEE 1588 PTP.

The individual elementary media streams will be composed together by receiv= ers as required for production.=C2=A0 For example, for an English language = service, an English audio channel group of AES67/RFC 3190 RTP audio would b= e composed together with the RFC 4175 video and the ST 291-1 ancillary data= flow of English language Closed Captions ancillary data and SMPTE 2016-1 A= FD ancillary data.=C2=A0 =C2=A0 Meanwhile the Spanish language service woul= d have the same video and AFD ancillary data, but would have Spanish langua= ge audio and Spanish Closed Captions.=C2=A0 Likely it would be a distributi= on quality encoder (perhaps H.264 encoder) that subscribes to the different= streams in order to create the final service.

Every time I read about =E2=80=9CFID=E2=80=9D in RFC 5888, I am struck by t= he sentence in Section 8 =E2=80=9CFlow Identification (FID)=E2=80=9D that s= ays =E2=80=9Cthere are situations where a single media instance (e.g., an a= udio stream or a video stream) is sent using more than one RTP session,=E2= =80=9D which I believe is not the case here.=C2=A0 For example, video is on= e media instance, and ancillary data is a second media instance.=C2=A0 You = can=E2=80=99t =E2=80=9Cadd=E2=80=9D video and ancillary data together, like= you can add together voice audio and DTMF tone audio (as in RFC 5888 Secti= on 8.2).

RFC 5888 Section 8.4 =E2=80=9CFID Semantics=E2=80=9D also states: =E2=80=9C= It is assumed that the application uses only one codec at a time to encode = the media produced.=C2=A0 This codec MAY change dynamically during the sess= ion, but at any particular moment, only one codec is in use.=E2=80=9D=C2=A0= Again, this does not seem relevant to the SDP description of multiple RTP = streams of video, audio, and ancillary data intended for synchronized prese= ntation.=C2=A0 All three =E2=80=9Ccodecs=E2=80=9D are in use at all times f= or their particular media stream.=C2=A0 And in particular regarding draft-i= etf-payload-rtp-ancillary, there is only one =E2=80=9Ccodec=E2=80=9D e= ver used, the encapsulation of SMPTE ST 291-1 ancillary data packets into R= TP.

I could really use the help of the IESG to see how we can move forward rega= rding the open DISCUSS item on draft-ietf-payload-rtp-ancillary.

(I will note that SMPTE is eagerly awaiting the publishing of this RFC for = use as a normative reference in the upcoming ST 2110-40 standard, see: = https://www.smpte.org/st-2110).

Thanks!

-Thomas Edwards
=C2=A0FOX

On 10/4/17, 9:27 AM, "Roni Even" <roni.even@huawei.com> wrote:

=C2=A0 =C2=A0 Hi Colin,

=C2=A0 =C2=A0 I agree.

=C2=A0 =C2=A0 There are two cases. The assumption is that both video and AN= C have the same source and have same CNAME (Thomas - is this correct?)



=C2=A0 =C2=A0 1. Both video and ANC are in the same RTP session (same m-lin= e)=C2=A0 will be synchronized.



=C2=A0 =C2=A0 The second is the one we are discussing:

=C2=A0 =C2=A0 2. The video and ANC are in separate RTP sessions (two m-line= s). If both are a single flow (single RTP stream) should group using FID. I= f they are not a single RTP stream (flow) should use LS.



=C2=A0 =C2=A0 I can agree that it looks like a single flow (FID) but want c= larification from the authors (Thomas)







=C2=A0 =C2=A0 Roni



=C2=A0 =C2=A0 > -----Original Message-----

=C2=A0 =C2=A0 > From: Colin Perkins [mailto:csp@csperkins.org]

=C2=A0 =C2=A0 > Sent: =D7=99=D7=95=D7=9D =D7=93 04 =D7=90=D7=95=D7=A7=D7= =98=D7=95=D7=91=D7=A8 2017 01:50

=C2=A0 =C2=A0 > To: Roni Even

=C2=A0 =C2=A0 > Cc: Adam Roach; Thomas Edwards; The IESG; payload-chairs@ietf.org; draft-

=C2=A0 =C2=A0 > i= etf-payload-rtp-ancillary@ietf.org; payload@ietf.org; acbegen@gm= ail.com

=C2=A0 =C2=A0 > Subject: Re: [payload] Adam Roach's Discuss on draft= -ietf-payload-rtp-

=C2=A0 =C2=A0 > ancillary-10: (with DISCUSS and COMMENT)

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > Roni,

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > I said nothing about multicast vs unicast, since I don= =E2=80=99t think that distinction is

=C2=A0 =C2=A0 > important.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > Sending the streams on separate m=3D lines or sending us= ing a single a m=3D line

=C2=A0 =C2=A0 > both work. The draft doesn=E2=80=99t need to discuss thi= s, since it=E2=80=99s standard RTP as

=C2=A0 =C2=A0 > would apply to any RTP session. If you use separate m=3D= lines, then you need

=C2=A0 =C2=A0 > a grouping mechanism. The choice of grouping mechanism i= s what we=E2=80=99re

=C2=A0 =C2=A0 > discussing.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > Colin

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > > On 3 Oct 2017, at 23:19, Roni Even <roni.even@huawei.com> wrote:

=C2=A0 =C2=A0 > >

=C2=A0 =C2=A0 > > Colin,

=C2=A0 =C2=A0 > > We still need some feedback from Thomas, in a previ= ous email response to

=C2=A0 =C2=A0 > Adam he gave a reason for using multiple RTP sessions:
=C2=A0 =C2=A0 > >

=C2=A0 =C2=A0 > > "The challenge is that the use case of the Anc= illary I-D within the SMPTE ST

=C2=A0 =C2=A0 > 2110 architecture would generally require separate netwo= rk destination

=C2=A0 =C2=A0 > addresses for the different elements (video, audio, anci= llary data) so they

=C2=A0 =C2=A0 > can be flexibly composed within broadcast plants at the = network level.=C2=A0 Your

=C2=A0 =C2=A0 > alternative SDP example appears to place both the video = and the ancillary

=C2=A0 =C2=A0 > data onto the same destination address (https://urldefense.proofpoi= nt.com/v2/url?u=3Dhttp-3A__233.252.0.1&d=3DDwIGaQ&c=3Duw6= TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=3DlekNOOM5noV61zrP= H3rwPyhtNnLLWoLEHgd0quQxly8&m=3DdOxHA7dn5d2eo_tU3divd4ks6mmXP= hk5WmodLULHUPY&s=3DsrzDHDG2LTcTBJexIDta4-p9142SYkQ2gDH3S8PMdZ= g&e=3D).=C2=A0 Is there an

=C2=A0 =C2=A0 > appropriate SDP mechanism to communicate the intimate re= lationship

=C2=A0 =C2=A0 > between the RTP streams, but also have them transmitted = on separate

=C2=A0 =C2=A0 > destination IP addresses (and synchronized)?

=C2=A0 =C2=A0 > >

=C2=A0 =C2=A0 > > (In production practice, this may not be a signific= ant issue as the RTP

=C2=A0 =C2=A0 > streams to be combined by IP receivers for conversion to= SDI/HDMI or for

=C2=A0 =C2=A0 > input to a distribution encoder may be specified by a co= ntrol system directly

=C2=A0 =C2=A0 > to the receiver using an API that isn=E2=80=99t just an = SDP file.)"

=C2=A0 =C2=A0 > >

=C2=A0 =C2=A0 > > I want to assume that by different destination addr= esses it refers to

=C2=A0 =C2=A0 > multicast addresses like above and not to different unic= ast IP addresses.

=C2=A0 =C2=A0 > > You are right that for unicast it will make sense t= o use the same RTP session

=C2=A0 =C2=A0 > with the same SSRC.

=C2=A0 =C2=A0 > >

=C2=A0 =C2=A0 > > Roni

=C2=A0 =C2=A0 > >

=C2=A0 =C2=A0 > >> -----Original Message-----

=C2=A0 =C2=A0 > >> From: Colin Perkins [mailto:csp@csperkins.org]

=C2=A0 =C2=A0 > >> Sent: =D7=99=D7=95=D7=9D =D7=93 04 =D7=90=D7=95= =D7=A7=D7=98=D7=95=D7=91=D7=A8 2017 00:46

=C2=A0 =C2=A0 > >> To: Roni Even

=C2=A0 =C2=A0 > >> Cc: Adam Roach; Thomas Edwards; The IESG; payload-chairs@ietf.org;

=C2=A0 =C2=A0 > >> draft- ietf-payload-rtp-ancillary@ietf.org; payload@ietf.org;

=C2=A0 =C2=A0 > >> acbegen@gm= ail.com

=C2=A0 =C2=A0 > >> Subject: Re: [payload] Adam Roach's Discuss= on

=C2=A0 =C2=A0 > >> draft-ietf-payload-rtp-

=C2=A0 =C2=A0 > >> ancillary-10: (with DISCUSS and COMMENT)

=C2=A0 =C2=A0 > >>

=C2=A0 =C2=A0 > >>

=C2=A0 =C2=A0 > >>> On 3 Oct 2017, at 21:40, Roni Even <roni.even@huawei.com> wrote:

=C2=A0 =C2=A0 > >>>

=C2=A0 =C2=A0 > >>> Hi Colin,

=C2=A0 =C2=A0 > >>> I re-read RFC5888 and tried to understand w= hat is the difference

=C2=A0 =C2=A0 > >>> between FID and LS I was trying to understa= nd what is a flow and

=C2=A0 =C2=A0 > >>> from section 8.3

=C2=A0 =C2=A0 > >>>

=C2=A0 =C2=A0 > >>> "The previous examples show that the d= efinition of a media stream in

=C2=A0 =C2=A0 > >>> [RFC2326] does not cover some scenarios.=C2= =A0 It cannot be assumed that

=C2=A0 =C2=A0 > >>> a=C2=A0 single media instance maps into a s= ingle RTP session.=C2=A0 Therefore,

=C2=A0 =C2=A0 > >>> we=C2=A0 introduce the definition of a medi= a flow:

=C2=A0 =C2=A0 > >>>

=C2=A0 =C2=A0 > >>>=C2=A0 =C2=A0 =C2=A0A media flow consists of= a single media instance, e.g., an audio

=C2=A0 =C2=A0 > >>>=C2=A0 =C2=A0 =C2=A0stream or a video stream= as well as a single whiteboard or shared

=C2=A0 =C2=A0 > >>>=C2=A0 =C2=A0 =C2=A0application group.=C2=A0= When using RTP, a media flow comprises one or

=C2=A0 =C2=A0 > >>>=C2=A0 =C2=A0 =C2=A0more RTP sessions."=

=C2=A0 =C2=A0 > >>>

=C2=A0 =C2=A0 > >>> It looks to me that a media flow is a SINGL= E media stream that spans

=C2=A0 =C2=A0 > >>> over

=C2=A0 =C2=A0 > >> multiple RTP sessions (the term media instance = is a what we call a

=C2=A0 =C2=A0 > >> media stream in the taxonomy). Section 8.5 (8.5= .1) enhance this by

=C2=A0 =C2=A0 > >> saying when FID cannot be used " FID seman= tics are useful when the

=C2=A0 =C2=A0 > application only uses

=C2=A0 =C2=A0 > >> one codec at=C2=A0 =C2=A0a time"=C2=A0 whi= ch again describe a flow as a single media

=C2=A0 =C2=A0 > stream.

=C2=A0 =C2=A0 > >>>

=C2=A0 =C2=A0 > >>> I am not sure how ANC and the video relates= to each other this is

=C2=A0 =C2=A0 > >>> what I am

=C2=A0 =C2=A0 > >> asking Thomas to be more clear. If the video an= d ANC are one stream

=C2=A0 =C2=A0 > >> over multiple RTP sessions FID is correct other= wise I think the LS should be

=C2=A0 =C2=A0 > used.

=C2=A0 =C2=A0 > >>

=C2=A0 =C2=A0 > >> My understanding is that the video and ancillar= y data are the same

=C2=A0 =C2=A0 > >> stream. In broadcast TV the ancillary data is s= ent in-band, in the blanking

=C2=A0 =C2=A0 > intervals.

=C2=A0 =C2=A0 > >>

=C2=A0 =C2=A0 > >>> My reading on=C2=A0 the ancillary draft is = that ANC and the video are

=C2=A0 =C2=A0 > >>> what we call

=C2=A0 =C2=A0 > >> a single RTP stream but this is not what Thomas= says.

=C2=A0 =C2=A0 > >>

=C2=A0 =C2=A0 > >>

=C2=A0 =C2=A0 > >> I expect one could send the ancillary data usin= g the same SSRC, and

=C2=A0 =C2=A0 > >> the same 5-tuple, as the media data (in the sam= e way comfort noise

=C2=A0 =C2=A0 > >> and speech data can be sent), in which case you= don=E2=80=99t need the

=C2=A0 =C2=A0 > >> grouping. If they=E2=80=99re sent as separate R= TP streams, with separate m=3D

=C2=A0 =C2=A0 > >> lines, then you need grouping. I believe FID ma= kes sense for this.

=C2=A0 =C2=A0 > >>

=C2=A0 =C2=A0 > >> --

=C2=A0 =C2=A0 > >> Colin Perkins

=C2=A0 =C2=A0 > >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A_= _csperkins.org_&d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQ= x6zvFcGEsbfiY9-EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHg= d0quQxly8&m=3DdOxHA7dn5d2eo_tU3divd4ks6mmXPhk5WmodLULHUPY&s=3Ds2We2es-My1JRfcPlYZEmqGCYYi9rf9Wc7dYRzxspsY&e=3D

=C2=A0 =C2=A0 > >>

=C2=A0 =C2=A0 > >>

=C2=A0 =C2=A0 > >>

=C2=A0 =C2=A0 > >

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > --

=C2=A0 =C2=A0 > Colin Perkins

=C2=A0 =C2=A0 > http= s://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__csperkins.org_= &d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-= EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DdO= xHA7dn5d2eo_tU3divd4ks6mmXPhk5WmodLULHUPY&s=3Ds2We2es-My= 1JRfcPlYZEmqGCYYi9rf9Wc7dYRzxspsY&e=3D

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >






--001a113ffca4413d1c055b2ba431-- From nobody Tue Oct 10 14:01:58 2017 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 83E6F13247A; Tue, 10 Oct 2017 14:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rk0zAxt4FyQE; Tue, 10 Oct 2017 14:01:50 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8097C133061; Tue, 10 Oct 2017 13:59:49 -0700 (PDT) Received: from [10.0.1.82] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v9AKxUWx022492 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Oct 2017 15:59:31 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.82] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) From: Ben Campbell In-Reply-To: <7D009531-3DB3-4923-80B2-38BC3F9FB020@foxeg.com> Date: Tue, 10 Oct 2017 15:59:29 -0500 Cc: Roni Even , Colin Perkins , Adam Roach , "payload-chairs@ietf.org" , "acbegen@gmail.com" , "payload@ietf.org" , "draft-ietf-payload-rtp-ancillary@ietf.org" , The IESG Content-Transfer-Encoding: quoted-printable Message-Id: References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <3B259563-1075-4C41-A832-D7633C39173B@foxeg.com> <61440eb5-32c3-3696-be38-8dc7c4eaf72f@nostrum.com> <863974D7-E112-4794-AD4D-C39C99BD40C9@foxeg.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> <6E58094ECC8D8344914996DAD28F1CCD810BB8@DGGEMM506-MBX.china.huawei.com> <37F6B554-530B-4A30-B66F-A70D026DD2B8@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810CC5@DGGEMM506-MBX.china.huawei.com> <04D71781-0E87-461C-BDA0-D44F94FED1A0@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810D79@DGGEMM506-MBX.china.huawei.com> <7574DE41-96BB-45C1-8279-F9E2460E0452@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD81103C@DGGEMM506-MBX.china.huawei.com> <7D009531-3DB3-4923-80B2-38BC3F9FB020@foxeg.com> To: Thomas Edwards X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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 Oct 2017 21:01:52 -0000 On Oct 9, 2017, at 7:06 PM, Thomas Edwards = wrote: >=20 > I will note that I have uploaded a new version, = draft-ietf-payload-rtp-ancillary-11, to address most of the comments = from the IESG evaluation. >=20 > draft-ietf-payload-rtp-ancillary-11, Section 4.1 =E2=80=9CGrouping ANC = Streams with other Media Streams=E2=80=9D has two examples. >=20 > In the first SDP example, two =E2=80=9Cm=3D=E2=80=9D lines are present = (with each having a different =E2=80=9Cc=3D=E2=80=9D line), one for = uncompressed video, and one for ancillary data. The two RTP sessions = are identified with RFC 5888 Media Stream Identification Attributes = (mid), and are grouped together using Lip Synchronization (LS), in a = fashion similar to the Lip Synchronization of video and audio streams in = RFC 5888 Section 7.1 =E2=80=9CExample of LS=E2=80=9D. >=20 > In the second SDP example, a single =E2=80=9Cm=3D=E2=80=9D line is = present without any grouping, implying any synchronization would be from = SSRC/CNAME linkage and/or RTCP. >=20 > The most likely implementation of this RTP payload in professional = video production would be where multiple endpoints are contributing = elementary streams of media: video, audio channels or channel groups, = and SMPTE ST 291-1 ancillary data sources. Those endpoints = (microphones, cameras, Closed Caption generators, etc.) are all likely = to be different, thus with different SSRCs and CNAMEs, and transmitting = to separate multicast IP addresses and UDP ports. However, they will = likely be transmitted with a commonly synchronized clock as per RFC 7273 = =E2=80=9CRTP Clock Source Signalling=E2=80=9D, most likely IEEE 1588 = PTP. =20 >=20 > The individual elementary media streams will be composed together by = receivers as required for production. For example, for an English = language service, an English audio channel group of AES67/RFC 3190 RTP = audio would be composed together with the RFC 4175 video and the ST = 291-1 ancillary data flow of English language Closed Captions ancillary = data and SMPTE 2016-1 AFD ancillary data. Meanwhile the Spanish = language service would have the same video and AFD ancillary data, but = would have Spanish language audio and Spanish Closed Captions. Likely = it would be a distribution quality encoder (perhaps H.264 encoder) that = subscribes to the different streams in order to create the final = service. >=20 > Every time I read about =E2=80=9CFID=E2=80=9D in RFC 5888, I am struck = by the sentence in Section 8 =E2=80=9CFlow Identification (FID)=E2=80=9D = that says =E2=80=9Cthere are situations where a single media instance = (e.g., an audio stream or a video stream) is sent using more than one = RTP session,=E2=80=9D which I believe is not the case here. For = example, video is one media instance, and ancillary data is a second = media instance. You can=E2=80=99t =E2=80=9Cadd=E2=80=9D video and = ancillary data together, like you can add together voice audio and DTMF = tone audio (as in RFC 5888 Section 8.2). =20 >=20 > RFC 5888 Section 8.4 =E2=80=9CFID Semantics=E2=80=9D also states: = =E2=80=9CIt is assumed that the application uses only one codec at a = time to encode the media produced. This codec MAY change dynamically = during the session, but at any particular moment, only one codec is in = use.=E2=80=9D Again, this does not seem relevant to the SDP description = of multiple RTP streams of video, audio, and ancillary data intended for = synchronized presentation. All three =E2=80=9Ccodecs=E2=80=9D are in = use at all times for their particular media stream. And in particular = regarding draft-ietf-payload-rtp-ancillary, there is only one = =E2=80=9Ccodec=E2=80=9D ever used, the encapsulation of SMPTE ST 291-1 = ancillary data packets into RTP. The argument against FID hinges on the rather philosophical question of = whether the ancillary data is a truly a separate codec vs just metadata. = I don=E2=80=99t find that particularly convincing, especially since = multiple experts have weighed in on this discussion in favor of FID. = Let=E2=80=99s say for the sake of argument that we treat is as =E2=80=9Cju= st metadata=E2=80=9D. Would you argue that FID still won=E2=80=99t work = in a practical sense? >=20 > I could really use the help of the IESG to see how we can move forward = regarding the open DISCUSS item on draft-ietf-payload-rtp-ancillary. My takeaways from the discussion so far: 1) LS doesn=E2=80=99t work, at least not cleanly. 2) FID would work, but there are philosophical objections. 3) People don=E2=80=99t want to create a new grouping semantic. So unless people want to argue that LS really does work, even in the = case of Adam=E2=80=99s multi-stream example, I think we are left = choosing between FID or creating something new. If people don=E2=80=99t = like FID, is creating something new (maybe a =E2=80=9Cmetadata=E2=80=9D = semantic) that hard? >=20 > (I will note that SMPTE is eagerly awaiting the publishing of this RFC = for use as a normative reference in the upcoming ST 2110-40 standard, = see: https://www.smpte.org/st-2110). >=20 > Thanks! >=20 > -Thomas Edwards > FOX >=20 > On 10/4/17, 9:27 AM, "Roni Even" wrote: >=20 > Hi Colin, >=20 > I agree. >=20 > There are two cases. The assumption is that both video and ANC have = the same source and have same CNAME (Thomas - is this correct?) >=20 >=20 >=20 > 1. Both video and ANC are in the same RTP session (same m-line) = will be synchronized.=20 >=20 >=20 >=20 > The second is the one we are discussing: >=20 > 2. The video and ANC are in separate RTP sessions (two m-lines). If = both are a single flow (single RTP stream) should group using FID. If = they are not a single RTP stream (flow) should use LS. >=20 >=20 >=20 > I can agree that it looks like a single flow (FID) but want = clarification from the authors (Thomas) >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Roni >=20 >=20 >=20 >> -----Original Message----- >=20 >> From: Colin Perkins [mailto:csp@csperkins.org] >=20 >> Sent: =D7=99=D7=95=D7=9D =D7=93 04 =D7=90=D7=95=D7=A7=D7=98=D7=95=D7=91= =D7=A8 2017 01:50 >=20 >> To: Roni Even >=20 >> Cc: Adam Roach; Thomas Edwards; The IESG; payload-chairs@ietf.org; = draft- >=20 >> ietf-payload-rtp-ancillary@ietf.org; payload@ietf.org; = acbegen@gmail.com >=20 >> Subject: Re: [payload] Adam Roach's Discuss on = draft-ietf-payload-rtp- >=20 >> ancillary-10: (with DISCUSS and COMMENT) >=20 >>=20 >=20 >> Roni, >=20 >>=20 >=20 >> I said nothing about multicast vs unicast, since I don=E2=80=99t = think that distinction is >=20 >> important. >=20 >>=20 >=20 >> Sending the streams on separate m=3D lines or sending using a single = a m=3D line >=20 >> both work. The draft doesn=E2=80=99t need to discuss this, since = it=E2=80=99s standard RTP as >=20 >> would apply to any RTP session. If you use separate m=3D lines, then = you need >=20 >> a grouping mechanism. The choice of grouping mechanism is what = we=E2=80=99re >=20 >> discussing. >=20 >>=20 >=20 >> Colin >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> On 3 Oct 2017, at 23:19, Roni Even wrote: >=20 >>>=20 >=20 >>> Colin, >=20 >>> We still need some feedback from Thomas, in a previous email = response to >=20 >> Adam he gave a reason for using multiple RTP sessions: >=20 >>>=20 >=20 >>> "The challenge is that the use case of the Ancillary I-D within the = SMPTE ST >=20 >> 2110 architecture would generally require separate network = destination >=20 >> addresses for the different elements (video, audio, ancillary data) = so they >=20 >> can be flexibly composed within broadcast plants at the network = level. Your >=20 >> alternative SDP example appears to place both the video and the = ancillary >=20 >> data onto the same destination address = (https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__233.252.0.1&d=3DDwI= GaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=3DlekNOOM5noV61zrPH3= rwPyhtNnLLWoLEHgd0quQxly8&m=3DdOxHA7dn5d2eo_tU3divd4ks6mmXPhk5WmodLULHUPY&= s=3DsrzDHDG2LTcTBJexIDta4-p9142SYkQ2gDH3S8PMdZg&e=3D). Is there an >=20 >> appropriate SDP mechanism to communicate the intimate relationship >=20 >> between the RTP streams, but also have them transmitted on separate >=20 >> destination IP addresses (and synchronized)? >=20 >>>=20 >=20 >>> (In production practice, this may not be a significant issue as the = RTP >=20 >> streams to be combined by IP receivers for conversion to SDI/HDMI or = for >=20 >> input to a distribution encoder may be specified by a control system = directly >=20 >> to the receiver using an API that isn=E2=80=99t just an SDP file.)" >=20 >>>=20 >=20 >>> I want to assume that by different destination addresses it refers = to >=20 >> multicast addresses like above and not to different unicast IP = addresses. >=20 >>> You are right that for unicast it will make sense to use the same = RTP session >=20 >> with the same SSRC. >=20 >>>=20 >=20 >>> Roni >=20 >>>=20 >=20 >>>> -----Original Message----- >=20 >>>> From: Colin Perkins [mailto:csp@csperkins.org] >=20 >>>> Sent: =D7=99=D7=95=D7=9D =D7=93 04 =D7=90=D7=95=D7=A7=D7=98=D7=95=D7=91= =D7=A8 2017 00:46 >=20 >>>> To: Roni Even >=20 >>>> Cc: Adam Roach; Thomas Edwards; The IESG; payload-chairs@ietf.org; >=20 >>>> draft- ietf-payload-rtp-ancillary@ietf.org; payload@ietf.org; >=20 >>>> acbegen@gmail.com >=20 >>>> Subject: Re: [payload] Adam Roach's Discuss on >=20 >>>> draft-ietf-payload-rtp- >=20 >>>> ancillary-10: (with DISCUSS and COMMENT) >=20 >>>>=20 >=20 >>>>=20 >=20 >>>>> On 3 Oct 2017, at 21:40, Roni Even wrote: >=20 >>>>>=20 >=20 >>>>> Hi Colin, >=20 >>>>> I re-read RFC5888 and tried to understand what is the difference >=20 >>>>> between FID and LS I was trying to understand what is a flow and >=20 >>>>> from section 8.3 >=20 >>>>>=20 >=20 >>>>> "The previous examples show that the definition of a media stream = in >=20 >>>>> [RFC2326] does not cover some scenarios. It cannot be assumed = that >=20 >>>>> a single media instance maps into a single RTP session. = Therefore, >=20 >>>>> we introduce the definition of a media flow: >=20 >>>>>=20 >=20 >>>>> A media flow consists of a single media instance, e.g., an = audio >=20 >>>>> stream or a video stream as well as a single whiteboard or = shared >=20 >>>>> application group. When using RTP, a media flow comprises one = or >=20 >>>>> more RTP sessions." >=20 >>>>>=20 >=20 >>>>> It looks to me that a media flow is a SINGLE media stream that = spans >=20 >>>>> over >=20 >>>> multiple RTP sessions (the term media instance is a what we call a >=20 >>>> media stream in the taxonomy). Section 8.5 (8.5.1) enhance this by >=20 >>>> saying when FID cannot be used " FID semantics are useful when the >=20 >> application only uses >=20 >>>> one codec at a time" which again describe a flow as a single = media >=20 >> stream. >=20 >>>>>=20 >=20 >>>>> I am not sure how ANC and the video relates to each other this is >=20 >>>>> what I am >=20 >>>> asking Thomas to be more clear. If the video and ANC are one stream >=20 >>>> over multiple RTP sessions FID is correct otherwise I think the LS = should be >=20 >> used. >=20 >>>>=20 >=20 >>>> My understanding is that the video and ancillary data are the same >=20 >>>> stream. In broadcast TV the ancillary data is sent in-band, in the = blanking >=20 >> intervals. >=20 >>>>=20 >=20 >>>>> My reading on the ancillary draft is that ANC and the video are >=20 >>>>> what we call >=20 >>>> a single RTP stream but this is not what Thomas says. >=20 >>>>=20 >=20 >>>>=20 >=20 >>>> I expect one could send the ancillary data using the same SSRC, and >=20 >>>> the same 5-tuple, as the media data (in the same way comfort noise >=20 >>>> and speech data can be sent), in which case you don=E2=80=99t need = the >=20 >>>> grouping. If they=E2=80=99re sent as separate RTP streams, with = separate m=3D >=20 >>>> lines, then you need grouping. I believe FID makes sense for this. >=20 >>>>=20 >=20 >>>> -- >=20 >>>> Colin Perkins >=20 >>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__csperkins.org_&d=3D= DwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=3DlekNOOM5noV61zr= PH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DdOxHA7dn5d2eo_tU3divd4ks6mmXPhk5WmodLULHU= PY&s=3Ds2We2es-My1JRfcPlYZEmqGCYYi9rf9Wc7dYRzxspsY&e=3D >=20 >>>>=20 >=20 >>>>=20 >=20 >>>>=20 >=20 >>>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> -- >=20 >> Colin Perkins >=20 >> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__csperkins.org_&d=3D= DwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=3DlekNOOM5noV61zr= PH3rwPyhtNnLLWoLEHgd0quQxly8&m=3DdOxHA7dn5d2eo_tU3divd4ks6mmXPhk5WmodLULHU= PY&s=3Ds2We2es-My1JRfcPlYZEmqGCYYi9rf9Wc7dYRzxspsY&e=3D >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >=20 >=20 >=20 >=20 From nobody Tue Oct 10 14:02:51 2017 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 CCC1F133061 for ; Tue, 10 Oct 2017 14:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNzjoasMlmWy for ; Tue, 10 Oct 2017 14:02:47 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D4571342EA for ; Tue, 10 Oct 2017 14:02:37 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v9AL2ZYs023200 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Oct 2017 16:02:35 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: "Ali C. Begen" , Thomas Edwards Cc: Roni Even , Colin Perkins , The IESG , "payload-chairs@ietf.org" , "payload@ietf.org" References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <3B259563-1075-4C41-A832-D7633C39173B@foxeg.com> <61440eb5-32c3-3696-be38-8dc7c4eaf72f@nostrum.com> <863974D7-E112-4794-AD4D-C39C99BD40C9@foxeg.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> <6E58094ECC8D8344914996DAD28F1CCD810BB8@DGGEMM506-MBX.china.huawei.com> <37F6B554-530B-4A30-B66F-A70D026DD2B8@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810CC5@DGGEMM506-MBX.china.huawei.com> <04D71781-0E87-461C-BDA0-D44F94FED1A0@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810D79@DGGEMM506-MBX.china.huawei.com> <7574DE41-96BB-45C1-8279-F9E2460E0452@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD81103C@DGGEMM506-MBX.china.huawei.com> <7D009531-3DB3-4923-80B2-38BC3F9FB020@foxeg.com> From: Adam Roach Message-ID: <5b0066c9-9f5b-0e71-0428-72a07cde3e3c@nostrum.com> Date: Tue, 10 Oct 2017 16:02:35 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3789C1FB717CA53EE749EBA9" Content-Language: en-US Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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 Oct 2017 21:02:51 -0000 This is a multi-part message in MIME format. --------------3789C1FB717CA53EE749EBA9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Here are the salient points that pertain to my discuss: 1. This mechanism is broken and must not be published unless there is an explicit way to correlate ancillary data with its corresponding video stream. 2. LS is 100% the wrong mechanism to do so. 3. I believe that what is needed here is in the spirit of what FID is intended to convey, although I take Thomas' point that there is some language in the specific definition of FID that he believes makes it unsuitable for this purpose. Given that we seem to have reached an impasse on the final point in particular, I would propose that the most straightforward solution here is to define a new group semantic (e.g., "a=group:ANC") that is explicitly intended to pair ancillary data with its corresponding video stream. This should take at most one short paragraph and an additional IANA registration. /a On 10/10/17 1:44 AM, Ali C. Begen wrote: > Hi Thomas > > Please go ahead and submit a revision. Then reach out to the > individual DISCUSS holders to clear theirs. And then lets focus on > Adam's discuss. > > Thanks > -acbegen (your payload wg co-chair) > > On Tue, Oct 10, 2017 at 3:06 AM, Thomas Edwards > > wrote: > > I will note that I have uploaded a new version, > draft-ietf-payload-rtp-ancillary-11, to address most of the > comments from the IESG evaluation. > > draft-ietf-payload-rtp-ancillary-11, Section 4.1 “Grouping ANC > Streams with other Media Streams” has two examples. > > In the first SDP example, two “m=” lines are present (with each > having a different “c=” line), one for uncompressed video, and one > for ancillary data.  The two RTP sessions are identified with RFC > 5888 Media Stream Identification Attributes (mid), and are grouped > together using Lip Synchronization (LS), in a fashion similar to > the Lip Synchronization of video and audio streams in RFC 5888 > Section 7.1 “Example of LS”. > > In the second SDP example, a single “m=” line is present without > any grouping, implying any synchronization would be from > SSRC/CNAME linkage and/or RTCP. > > The most likely implementation of this RTP payload in professional > video production would be where multiple endpoints are > contributing elementary streams of media: video, audio channels or > channel groups, and SMPTE ST 291-1 ancillary data sources.  Those > endpoints (microphones, cameras, Closed Caption generators, etc.) > are all likely to be different, thus with different SSRCs and > CNAMEs, and transmitting to separate multicast IP addresses and > UDP ports.  However, they will likely be transmitted with a > commonly synchronized clock as per RFC 7273 “RTP Clock Source > Signalling”, most likely IEEE 1588 PTP. > > The individual elementary media streams will be composed together > by receivers as required for production.  For example, for an > English language service, an English audio channel group of > AES67/RFC 3190 RTP audio would be composed together with the RFC > 4175 video and the ST 291-1 ancillary data flow of English > language Closed Captions ancillary data and SMPTE 2016-1 AFD > ancillary data.    Meanwhile the Spanish language service would > have the same video and AFD ancillary data, but would have Spanish > language audio and Spanish Closed Captions.  Likely it would be a > distribution quality encoder (perhaps H.264 encoder) that > subscribes to the different streams in order to create the final > service. > > Every time I read about “FID” in RFC 5888, I am struck by the > sentence in Section 8 “Flow Identification (FID)” that says “there > are situations where a single media instance (e.g., an audio > stream or a video stream) is sent using more than one RTP > session,” which I believe is not the case here.  For example, > video is one media instance, and ancillary data is a second media > instance.  You can’t “add” video and ancillary data together, like > you can add together voice audio and DTMF tone audio (as in RFC > 5888 Section 8.2). > > RFC 5888 Section 8.4 “FID Semantics” also states: “It is assumed > that the application uses only one codec at a time to encode the > media produced.  This codec MAY change dynamically during the > session, but at any particular moment, only one codec is in use.”  > Again, this does not seem relevant to the SDP description of > multiple RTP streams of video, audio, and ancillary data intended > for synchronized presentation.  All three “codecs” are in use at > all times for their particular media stream.  And in particular > regarding draft-ietf-payload-rtp-ancillary, there is only one > “codec” ever used, the encapsulation of SMPTE ST 291-1 ancillary > data packets into RTP. > > I could really use the help of the IESG to see how we can move > forward regarding the open DISCUSS item on > draft-ietf-payload-rtp-ancillary. > > (I will note that SMPTE is eagerly awaiting the publishing of this > RFC for use as a normative reference in the upcoming ST 2110-40 > standard, see: https://www.smpte.org/st-2110). > > Thanks! > > -Thomas Edwards >  FOX > > On 10/4/17, 9:27 AM, "Roni Even" > wrote: > >     Hi Colin, > >     I agree. > >     There are two cases. The assumption is that both video and ANC > have the same source and have same CNAME (Thomas - is this correct?) > > > >     1. Both video and ANC are in the same RTP session (same > m-line)  will be synchronized. > > > >     The second is the one we are discussing: > >     2. The video and ANC are in separate RTP sessions (two > m-lines). If both are a single flow (single RTP stream) should > group using FID. If they are not a single RTP stream (flow) should > use LS. > > > >     I can agree that it looks like a single flow (FID) but want > clarification from the authors (Thomas) > > > > > > > >     Roni > > > >     > -----Original Message----- > >     > From: Colin Perkins [mailto:csp@csperkins.org > ] > >     > Sent: יום ד 04 אוקטובר 2017 01:50 > >     > To: Roni Even > >     > Cc: Adam Roach; Thomas Edwards; The IESG; > payload-chairs@ietf.org ; draft- > >     > ietf-payload-rtp-ancillary@ietf.org > ; payload@ietf.org > ; acbegen@gmail.com > > >     > Subject: Re: [payload] Adam Roach's Discuss on > draft-ietf-payload-rtp- > >     > ancillary-10: (with DISCUSS and COMMENT) > >     > > >     > Roni, > >     > > >     > I said nothing about multicast vs unicast, since I don’t > think that distinction is > >     > important. > >     > > >     > Sending the streams on separate m= lines or sending using a > single a m= line > >     > both work. The draft doesn’t need to discuss this, since > it’s standard RTP as > >     > would apply to any RTP session. If you use separate m= > lines, then you need > >     > a grouping mechanism. The choice of grouping mechanism is > what we’re > >     > discussing. > >     > > >     > Colin > >     > > >     > > >     > > >     > > >     > > On 3 Oct 2017, at 23:19, Roni Even > wrote: > >     > > > >     > > Colin, > >     > > We still need some feedback from Thomas, in a previous > email response to > >     > Adam he gave a reason for using multiple RTP sessions: > >     > > > >     > > "The challenge is that the use case of the Ancillary I-D > within the SMPTE ST > >     > 2110 architecture would generally require separate network > destination > >     > addresses for the different elements (video, audio, > ancillary data) so they > >     > can be flexibly composed within broadcast plants at the > network level.  Your > >     > alternative SDP example appears to place both the video and > the ancillary > >     > data onto the same destination address > (https://urldefense.proofpoint.com/v2/url?u=http-3A__233.252.0.1&d=DwIGaQ&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=dOxHA7dn5d2eo_tU3divd4ks6mmXPhk5WmodLULHUPY&s=srzDHDG2LTcTBJexIDta4-p9142SYkQ2gDH3S8PMdZg&e= > ). > Is there an > >     > appropriate SDP mechanism to communicate the intimate > relationship > >     > between the RTP streams, but also have them transmitted on > separate > >     > destination IP addresses (and synchronized)? > >     > > > >     > > (In production practice, this may not be a significant > issue as the RTP > >     > streams to be combined by IP receivers for conversion to > SDI/HDMI or for > >     > input to a distribution encoder may be specified by a > control system directly > >     > to the receiver using an API that isn’t just an SDP file.)" > >     > > > >     > > I want to assume that by different destination addresses > it refers to > >     > multicast addresses like above and not to different unicast > IP addresses. > >     > > You are right that for unicast it will make sense to use > the same RTP session > >     > with the same SSRC. > >     > > > >     > > Roni > >     > > > >     > >> -----Original Message----- > >     > >> From: Colin Perkins [mailto:csp@csperkins.org > ] > >     > >> Sent: יום ד 04 אוקטובר 2017 00:46 > >     > >> To: Roni Even > >     > >> Cc: Adam Roach; Thomas Edwards; The IESG; > payload-chairs@ietf.org ; > >     > >> draft- ietf-payload-rtp-ancillary@ietf.org > ; payload@ietf.org > ; > >     > >> acbegen@gmail.com > >     > >> Subject: Re: [payload] Adam Roach's Discuss on > >     > >> draft-ietf-payload-rtp- > >     > >> ancillary-10: (with DISCUSS and COMMENT) > >     > >> > >     > >> > >     > >>> On 3 Oct 2017, at 21:40, Roni Even > wrote: > >     > >>> > >     > >>> Hi Colin, > >     > >>> I re-read RFC5888 and tried to understand what is the > difference > >     > >>> between FID and LS I was trying to understand what is a > flow and > >     > >>> from section 8.3 > >     > >>> > >     > >>> "The previous examples show that the definition of a > media stream in > >     > >>> [RFC2326] does not cover some scenarios.  It cannot be > assumed that > >     > >>> a  single media instance maps into a single RTP > session.  Therefore, > >     > >>> we  introduce the definition of a media flow: > >     > >>> > >     > >>>     A media flow consists of a single media instance, > e.g., an audio > >     > >>>     stream or a video stream as well as a single > whiteboard or shared > >     > >>>     application group.  When using RTP, a media flow > comprises one or > >     > >>>     more RTP sessions." > >     > >>> > >     > >>> It looks to me that a media flow is a SINGLE media > stream that spans > >     > >>> over > >     > >> multiple RTP sessions (the term media instance is a what > we call a > >     > >> media stream in the taxonomy). Section 8.5 (8.5.1) > enhance this by > >     > >> saying when FID cannot be used " FID semantics are useful > when the > >     > application only uses > >     > >> one codec at   a time"  which again describe a flow as a > single media > >     > stream. > >     > >>> > >     > >>> I am not sure how ANC and the video relates to each > other this is > >     > >>> what I am > >     > >> asking Thomas to be more clear. If the video and ANC are > one stream > >     > >> over multiple RTP sessions FID is correct otherwise I > think the LS should be > >     > used. > >     > >> > >     > >> My understanding is that the video and ancillary data are > the same > >     > >> stream. In broadcast TV the ancillary data is sent > in-band, in the blanking > >     > intervals. > >     > >> > >     > >>> My reading on  the ancillary draft is that ANC and the > video are > >     > >>> what we call > >     > >> a single RTP stream but this is not what Thomas says. > >     > >> > >     > >> > >     > >> I expect one could send the ancillary data using the same > SSRC, and > >     > >> the same 5-tuple, as the media data (in the same way > comfort noise > >     > >> and speech data can be sent), in which case you don’t > need the > >     > >> grouping. If they’re sent as separate RTP streams, with > separate m= > >     > >> lines, then you need grouping. I believe FID makes sense > for this. > >     > >> > >     > >> -- > >     > >> Colin Perkins > >     > >> > https://urldefense.proofpoint.com/v2/url?u=https-3A__csperkins.org_&d=DwIGaQ&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=dOxHA7dn5d2eo_tU3divd4ks6mmXPhk5WmodLULHUPY&s=s2We2es-My1JRfcPlYZEmqGCYYi9rf9Wc7dYRzxspsY&e= > > >     > >> > >     > >> > >     > >> > >     > > > >     > > >     > > >     > > >     > -- > >     > Colin Perkins > >     > > https://urldefense.proofpoint.com/v2/url?u=https-3A__csperkins.org_&d=DwIGaQ&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=dOxHA7dn5d2eo_tU3divd4ks6mmXPhk5WmodLULHUPY&s=s2We2es-My1JRfcPlYZEmqGCYYi9rf9Wc7dYRzxspsY&e= > > >     > > >     > > >     > > > > > > > --------------3789C1FB717CA53EE749EBA9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Here are the salient points that pertain to my discuss:

  1. This mechanism is broken and must not be published unless there is an explicit way to correlate ancillary data with its corresponding video stream.

  2. LS is 100% the wrong mechanism to do so.

  3. I believe that what is needed here is in the spirit of what FID is intended to convey, although I take Thomas' point that there is some language in the specific definition of FID that he believes makes it unsuitable for this purpose.

Given that we seem to have reached an impasse on the final point in particular, I would propose that the most straightforward solution here is to define a new group semantic (e.g., "a=group:ANC") that is explicitly intended to pair ancillary data with its corresponding video stream. This should take at most one short paragraph and an additional IANA registration.

/a


On 10/10/17 1:44 AM, Ali C. Begen wrote:
Hi Thomas

Please go ahead and submit a revision. Then reach out to the individual DISCUSS holders to clear theirs. And then lets focus on Adam's discuss.

Thanks
-acbegen (your payload wg co-chair)

On Tue, Oct 10, 2017 at 3:06 AM, Thomas Edwards <Thomas.Edwards@fox.com> wrote:
I will note that I have uploaded a new version, draft-ietf-payload-rtp-ancillary-11, to address most of the comments from the IESG evaluation.

draft-ietf-payload-rtp-ancillary-11, Section 4.1 “Grouping ANC Streams with other Media Streams” has two examples.

In the first SDP example, two “m=” lines are present (with each having a different “c=” line), one for uncompressed video, and one for ancillary data.  The two RTP sessions are identified with RFC 5888 Media Stream Identification Attributes (mid), and are grouped together using Lip Synchronization (LS), in a fashion similar to the Lip Synchronization of video and audio streams in RFC 5888 Section 7.1 “Example of LS”.

In the second SDP example, a single “m=” line is present without any grouping, implying any synchronization would be from SSRC/CNAME linkage and/or RTCP.

The most likely implementation of this RTP payload in professional video production would be where multiple endpoints are contributing elementary streams of media: video, audio channels or channel groups, and SMPTE ST 291-1 ancillary data sources.  Those endpoints (microphones, cameras, Closed Caption generators, etc.) are all likely to be different, thus with different SSRCs and CNAMEs, and transmitting to separate multicast IP addresses and UDP ports.  However, they will likely be transmitted with a commonly synchronized clock as per RFC 7273 “RTP Clock Source Signalling”, most likely IEEE 1588 PTP.

The individual elementary media streams will be composed together by receivers as required for production.  For example, for an English language service, an English audio channel group of AES67/RFC 3190 RTP audio would be composed together with the RFC 4175 video and the ST 291-1 ancillary data flow of English language Closed Captions ancillary data and SMPTE 2016-1 AFD ancillary data.    Meanwhile the Spanish language service would have the same video and AFD ancillary data, but would have Spanish language audio and Spanish Closed Captions.  Likely it would be a distribution quality encoder (perhaps H.264 encoder) that subscribes to the different streams in order to create the final service.

Every time I read about “FID” in RFC 5888, I am struck by the sentence in Section 8 “Flow Identification (FID)” that says “there are situations where a single media instance (e.g., an audio stream or a video stream) is sent using more than one RTP session,” which I believe is not the case here.  For example, video is one media instance, and ancillary data is a second media instance.  You can’t “add” video and ancillary data together, like you can add together voice audio and DTMF tone audio (as in RFC 5888 Section 8.2).

RFC 5888 Section 8.4 “FID Semantics” also states: “It is assumed that the application uses only one codec at a time to encode the media produced.  This codec MAY change dynamically during the session, but at any particular moment, only one codec is in use.”  Again, this does not seem relevant to the SDP description of multiple RTP streams of video, audio, and ancillary data intended for synchronized presentation.  All three “codecs” are in use at all times for their particular media stream.  And in particular regarding draft-ietf-payload-rtp-ancillary, there is only one “codec” ever used, the encapsulation of SMPTE ST 291-1 ancillary data packets into RTP.

I could really use the help of the IESG to see how we can move forward regarding the open DISCUSS item on draft-ietf-payload-rtp-ancillary.

(I will note that SMPTE is eagerly awaiting the publishing of this RFC for use as a normative reference in the upcoming ST 2110-40 standard, see: https://www.smpte.org/st-2110).

Thanks!

-Thomas Edwards
 FOX

On 10/4/17, 9:27 AM, "Roni Even" <roni.even@huawei.com> wrote:

    Hi Colin,
    I agree.

    There are two cases. The assumption is that both video and ANC have the same source and have same CNAME (Thomas - is this correct?)



    1. Both video and ANC are in the same RTP session (same m-line)  will be synchronized.



    The second is the one we are discussing:

    2. The video and ANC are in separate RTP sessions (two m-lines). If both are a single flow (single RTP stream) should group using FID. If they are not a single RTP stream (flow) should use LS.



    I can agree that it looks like a single flow (FID) but want clarification from the authors (Thomas)







    Roni



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

    > From: Colin Perkins [mailto:csp@csperkins.org]

    > Sent: יום ד 04 אוקטובר 2017 01:50

    > To: Roni Even

    > Cc: Adam Roach; Thomas Edwards; The IESG; payload-chairs@ietf.org; draft-

    > ietf-payload-rtp-ancillary@ietf.org; payload@ietf.org; acbegen@gmail.com

    > Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-

    > ancillary-10: (with DISCUSS and COMMENT)

    >

    > Roni,

    >

    > I said nothing about multicast vs unicast, since I don’t think that distinction is

    > important.

    >

    > Sending the streams on separate m= lines or sending using a single a m= line

    > both work. The draft doesn’t need to discuss this, since it’s standard RTP as

    > would apply to any RTP session. If you use separate m= lines, then you need

    > a grouping mechanism. The choice of grouping mechanism is what we’re

    > discussing.

    >

    > Colin

    >

    >

    >

    >

    > > On 3 Oct 2017, at 23:19, Roni Even <roni.even@huawei.com> wrote:

    > >

    > > Colin,

    > > We still need some feedback from Thomas, in a previous email response to

    > Adam he gave a reason for using multiple RTP sessions:

    > >

    > > "The challenge is that the use case of the Ancillary I-D within the SMPTE ST

    > 2110 architecture would generally require separate network destination

    > addresses for the different elements (video, audio, ancillary data) so they

    > can be flexibly composed within broadcast plants at the network level.  Your

    > alternative SDP example appears to place both the video and the ancillary

    > data onto the same destination address (https://urldefense.proofpoint.com/v2/url?u=http-3A__233.252.0.1&d=DwIGaQ&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=dOxHA7dn5d2eo_tU3divd4ks6mmXPhk5WmodLULHUPY&s=srzDHDG2LTcTBJexIDta4-p9142SYkQ2gDH3S8PMdZg&e=).  Is there an

    > appropriate SDP mechanism to communicate the intimate relationship

    > between the RTP streams, but also have them transmitted on separate

    > destination IP addresses (and synchronized)?

    > >

    > > (In production practice, this may not be a significant issue as the RTP

    > streams to be combined by IP receivers for conversion to SDI/HDMI or for

    > input to a distribution encoder may be specified by a control system directly

    > to the receiver using an API that isn’t just an SDP file.)"

    > >

    > > I want to assume that by different destination addresses it refers to

    > multicast addresses like above and not to different unicast IP addresses.

    > > You are right that for unicast it will make sense to use the same RTP session

    > with the same SSRC.

    > >

    > > Roni

    > >

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

    > >> From: Colin Perkins [mailto:csp@csperkins.org]

    > >> Sent: יום ד 04 אוקטובר 2017 00:46

    > >> To: Roni Even

    > >> Cc: Adam Roach; Thomas Edwards; The IESG; payload-chairs@ietf.org;

    > >> draft- ietf-payload-rtp-ancillary@ietf.org; payload@ietf.org;

    > >> acbegen@gmail.com

    > >> Subject: Re: [payload] Adam Roach's Discuss on

    > >> draft-ietf-payload-rtp-

    > >> ancillary-10: (with DISCUSS and COMMENT)

    > >>

    > >>

    > >>> On 3 Oct 2017, at 21:40, Roni Even <roni.even@huawei.com> wrote:

    > >>>

    > >>> Hi Colin,

    > >>> I re-read RFC5888 and tried to understand what is the difference

    > >>> between FID and LS I was trying to understand what is a flow and

    > >>> from section 8.3

    > >>>

    > >>> "The previous examples show that the definition of a media stream in

    > >>> [RFC2326] does not cover some scenarios.  It cannot be assumed that

    > >>> a  single media instance maps into a single RTP session.  Therefore,

    > >>> we  introduce the definition of a media flow:

    > >>>

    > >>>     A media flow consists of a single media instance, e.g., an audio

    > >>>     stream or a video stream as well as a single whiteboard or shared

    > >>>     application group.  When using RTP, a media flow comprises one or

    > >>>     more RTP sessions."

    > >>>

    > >>> It looks to me that a media flow is a SINGLE media stream that spans

    > >>> over

    > >> multiple RTP sessions (the term media instance is a what we call a

    > >> media stream in the taxonomy). Section 8.5 (8.5.1) enhance this by

    > >> saying when FID cannot be used " FID semantics are useful when the

    > application only uses

    > >> one codec at   a time"  which again describe a flow as a single media

    > stream.

    > >>>

    > >>> I am not sure how ANC and the video relates to each other this is

    > >>> what I am

    > >> asking Thomas to be more clear. If the video and ANC are one stream

    > >> over multiple RTP sessions FID is correct otherwise I think the LS should be

    > used.

    > >>

    > >> My understanding is that the video and ancillary data are the same

    > >> stream. In broadcast TV the ancillary data is sent in-band, in the blanking

    > intervals.

    > >>

    > >>> My reading on  the ancillary draft is that ANC and the video are

    > >>> what we call

    > >> a single RTP stream but this is not what Thomas says.

    > >>

    > >>

    > >> I expect one could send the ancillary data using the same SSRC, and

    > >> the same 5-tuple, as the media data (in the same way comfort noise

    > >> and speech data can be sent), in which case you don’t need the

    > >> grouping. If they’re sent as separate RTP streams, with separate m=

    > >> lines, then you need grouping. I believe FID makes sense for this.

    > >>

    > >> --

    > >> Colin Perkins

    > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__csperkins.org_&d=DwIGaQ&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=dOxHA7dn5d2eo_tU3divd4ks6mmXPhk5WmodLULHUPY&s=s2We2es-My1JRfcPlYZEmqGCYYi9rf9Wc7dYRzxspsY&e=

    > >>

    > >>

    > >>

    > >

    >

    >

    >

    > --

    > Colin Perkins

    > https://urldefense.proofpoint.com/v2/url?u=https-3A__csperkins.org_&d=DwIGaQ&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=dOxHA7dn5d2eo_tU3divd4ks6mmXPhk5WmodLULHUPY&s=s2We2es-My1JRfcPlYZEmqGCYYi9rf9Wc7dYRzxspsY&e=

    >

    >

    >







--------------3789C1FB717CA53EE749EBA9-- From nobody Tue Oct 10 14:40:12 2017 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 A6B5F1321A2 for ; Tue, 10 Oct 2017 14:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJevx4k0UfGg for ; Tue, 10 Oct 2017 14:40:04 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE0741326DF for ; Tue, 10 Oct 2017 14:40:02 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id p1so18345517qtg.2 for ; Tue, 10 Oct 2017 14:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KGtSQgsuMyaWPtkT2847CTgS62mvHnuadXLYr7MGr5w=; b=1zdqd/GOhR/VfHQAt7cQ77Bq3yg3Dd0NzH6Ydtzw08OP3fICqo1v8UZiUUsxeACM2Z 9v1fkay6UBFRBU092yHtofBrVw8KveuwyS9da3PFBcnBK8U5EVpwKAYNS+45XyEkcMZ+ s/YKGZkwL1xVhwZFOcjIycgj/3Ke5dJXWlIgS2k9z+62cYSqSgUMU3+G2buk/+xLY1Kt +k7yep3sgKbuJ3DeWX63YJo/wHbmfQr1rxk9iOSd72FhGK/1SqCeCSJAemumnGpfYyBD F8RgvEn8POKD7TXXd/GLaeTY6MqENkGMigoqza4otYOEGZs8SPFGU1bYAmTx6SmuDCdR vcOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KGtSQgsuMyaWPtkT2847CTgS62mvHnuadXLYr7MGr5w=; b=iTl7RVB20Ms05q4KQH+uiXFjyqQbdCo0ab6AzWN9nK4bZhWIyB8/Qz8qvh6DzFc48s 2cv0B/1ySs3bIBMCr3KjUlhHXHWeS9/JHW23/GU7ruQqIQzGqK+KPGNkjLmqNbviyNMy qkZKnBQVVpB4S+71+CQaFZHZQIs2dKRz8VQhFWn3jHOC2ZhbqaXEdOyarKfbX4sOTIEE qd/Ydxci5bJd4JwUiRbVwlexMDum39PP224q6qLvMGSiLqp7hQJRwNJ6f+sKlNeGOJR5 A/njrII4km+AoR+vSJdIFaLJPox+vdMyKgTT4D9QBGfLjabj1r7A2KePyZHkkX+Jt8B+ MlzA== X-Gm-Message-State: AMCzsaX60+ir/z0OqbPD2xfG7yBpdhYrImvAWnO2fxRCDseE/p6eTUlR nCTTAa47ourBBwODHG90tjr3iRqx/IOohGRKnvZiTQ== X-Google-Smtp-Source: AOwi7QDAggQtc+X1G8+Ho/ZGYe7Y3IG45dQbpxPZkGj3/Ltf3Yy6C9zPHrXaXLw776bninmBdTvmf2IM8ZJ6A9F3zk8= X-Received: by 10.129.83.213 with SMTP id h204mr3110552ywb.222.1507671601795; Tue, 10 Oct 2017 14:40:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.194.129 with HTTP; Tue, 10 Oct 2017 14:40:01 -0700 (PDT) In-Reply-To: References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <3B259563-1075-4C41-A832-D7633C39173B@foxeg.com> <61440eb5-32c3-3696-be38-8dc7c4eaf72f@nostrum.com> <863974D7-E112-4794-AD4D-C39C99BD40C9@foxeg.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> <6E58094ECC8D8344914996DAD28F1CCD810BB8@DGGEMM506-MBX.china.huawei.com> <37F6B554-530B-4A30-B66F-A70D026DD2B8@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810CC5@DGGEMM506-MBX.china.huawei.com> <04D71781-0E87-461C-BDA0-D44F94FED1A0@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810D79@DGGEMM506-MBX.china.huawei.com> <7574DE41-96BB-45C1-8279-F9E2460E0452@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD81103C@DGGEMM506-MBX.china.huawei.com> <7D009531-3DB3-4923-80B2-38BC3F9FB020@foxeg.com> From: "Ali C. Begen" Date: Wed, 11 Oct 2017 00:40:01 +0300 Message-ID: To: Ben Campbell Cc: Thomas Edwards , Adam Roach , "payload-chairs@ietf.org" , "payload@ietf.org" , "draft-ietf-payload-rtp-ancillary@ietf.org" , The IESG , Colin Perkins Content-Type: multipart/alternative; boundary="001a114d8e1643affa055b38267d" Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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 Oct 2017 21:40:06 -0000 --001a114d8e1643affa055b38267d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ben On Tue, Oct 10, 2017 at 11:59 PM, Ben Campbell wrote: > My takeaways from the discussion so far: > > 1) LS doesn=E2=80=99t work, at least not cleanly. > 2) FID would work, but there are philosophical objections. > 3) People don=E2=80=99t want to create a new grouping semantic. > > So unless people want to argue that LS really does work, even in the case > of Adam=E2=80=99s multi-stream example, I think we are left choosing betw= een FID or > creating something new. If people don=E2=80=99t like FID, is creating som= ething new > (maybe a =E2=80=9Cmetadata=E2=80=9D semantic) that hard? Yes, this is where we are. LS does not work, I agree. I believe FID works as the language in the RFC does not bother me because whoever needs to work with ANC data knows how to deal with it anyway. So bottomline is I am ready to ship this with FID. If that is absolutely not acceptable to Thomas or others, the only option is to define a new grouping semantics, which is not a significant work but needs blessing from MMUSIC. -acbegen --001a114d8e1643affa055b38267d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben

On Tue, Oct 10, 2017 at 11:59 PM, Ben Campbell <ben@nostrum.com> wrote:
My takeaways from th= e discussion so far:

1)=C2=A0 LS doesn=E2=80=99t work, at least not cleanly.
2)=C2=A0 FID would work, but there are philosophical objections.
3)=C2=A0 People don=E2=80=99t want to create a new grouping semantic.

So unless people want to argue that LS really does work, even in the case o= f Adam=E2=80=99s multi-stream example, I think we are left choosing between= FID or creating something new. If people don=E2=80=99t like FID, is creati= ng something new (maybe a =E2=80=9Cmetadata=E2=80=9D semantic) that hard?

Yes, this is where we are. LS does not work,= I agree. I believe FID works as the language in the RFC does not bother me= because whoever needs to work with ANC data knows how to deal with it anyw= ay. So bottomline is I am ready to ship this with FID. If that is absolutel= y not acceptable to Thomas or others, the only option is to define a new gr= ouping semantics, which is not a significant work but needs blessing from M= MUSIC.

-acbegen
--001a114d8e1643affa055b38267d-- From nobody Tue Oct 10 14:41:48 2017 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 CD09D1321A2 for ; Tue, 10 Oct 2017 14:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEwbMNp3mK7l for ; Tue, 10 Oct 2017 14:41:22 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F8471342FF for ; Tue, 10 Oct 2017 14:41:22 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id a43so49798161qta.0 for ; Tue, 10 Oct 2017 14:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YrKYBsLkjZEm4qQu9qSoPcfSaItuemU9YRu0O20gcHw=; b=oVL2FTXqRB1G/hyNuzJZ5doXBaRAx7TOa4kk2Iv8V0uVjqf883iU0mPIxE0sdbkhRJ CbTD79xYkiJtbIWL9+B6Q/GfDoFLSv1cykpeWgnt99wG7fMjZOawkKOMRBSlFZj2zWbQ HrdylkToSmmtLz1hkZ+jVddf0vYY6rXsH9hDM+jGYKM36lNdjNfL9xgFMb/PsAzhdcml ib4lRGSy3VcsHD5M7FU7WG3oCpXA+xSMv61HAEz86NLMmoul/ij+HgstRMJfjXFzHo94 lETi+wcmXgKiZ13TX5e0p859nKfyK0ZQnAn49ilD/0qKBPT1i3qxFs4olZp6fPGgLReo erOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YrKYBsLkjZEm4qQu9qSoPcfSaItuemU9YRu0O20gcHw=; b=DI84MNZN5rykoOfWBmLy3NjvxU4tdbnBlmYKFi66NhuMnD/aKxeI5MiDsp4ljUPvyr u3ijPatttOgqHG+SpfLk0eqR+fU9+Ly7AYSHGjgN5wYLGVsFMy7EtCq4oEyulxhvCIXz jZjAt03FtnHx8/9grvjtCnJjKuPlZw5nbQEwCazzXbJ/TZv9Dz3DT9awYiDSHC6iryh5 gX6gT6IQq9HYFicFFSN/8y9Y6WrN3eTDYxrxIK2h0QP3mByyyb9EAqsrpLSzwUo2hURm 18GzsoTBhKBJEF08srVv+3H9SuI/z0cDaZuXyliTvPDnyG+hlm0qiThcf0emqB5U1gKV gHsw== X-Gm-Message-State: AMCzsaUtr5KSsDwKVOXCV/aHMzVRs/6dBijB4sB+8pl3wHXF5aq+vP25 tt8q0CPV2grdHePri2LLS1FwKEFoJLwUgpn9HxASUg== X-Google-Smtp-Source: AOwi7QDWoh16QQCCESrw/bXqg9nyvGrGgTCwXnM4hv77dslEXrfu9iYeCP8FQfyrKBJAisnykLpIfWrQkacsOiGZG+U= X-Received: by 10.37.51.68 with SMTP id z65mr3087852ybz.353.1507671681232; Tue, 10 Oct 2017 14:41:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.194.129 with HTTP; Tue, 10 Oct 2017 14:41:20 -0700 (PDT) In-Reply-To: <5b0066c9-9f5b-0e71-0428-72a07cde3e3c@nostrum.com> References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <3B259563-1075-4C41-A832-D7633C39173B@foxeg.com> <61440eb5-32c3-3696-be38-8dc7c4eaf72f@nostrum.com> <863974D7-E112-4794-AD4D-C39C99BD40C9@foxeg.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> <6E58094ECC8D8344914996DAD28F1CCD810BB8@DGGEMM506-MBX.china.huawei.com> <37F6B554-530B-4A30-B66F-A70D026DD2B8@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810CC5@DGGEMM506-MBX.china.huawei.com> <04D71781-0E87-461C-BDA0-D44F94FED1A0@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810D79@DGGEMM506-MBX.china.huawei.com> <7574DE41-96BB-45C1-8279-F9E2460E0452@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD81103C@DGGEMM506-MBX.china.huawei.com> <7D009531-3DB3-4923-80B2-38BC3F9FB020@foxeg.com> <5b0066c9-9f5b-0e71-0428-72a07cde3e3c@nostrum.com> From: "Ali C. Begen" Date: Wed, 11 Oct 2017 00:41:20 +0300 Message-ID: To: Adam Roach Cc: Thomas Edwards , Roni Even , Colin Perkins , The IESG , "payload-chairs@ietf.org" , "payload@ietf.org" Content-Type: multipart/alternative; boundary="001a1148aa62ffb3ae055b382aa4" Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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 Oct 2017 21:41:28 -0000 --001a1148aa62ffb3ae055b382aa4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 11, 2017 at 12:02 AM, Adam Roach wrote: > Here are the salient points that pertain to my discuss: > > > 1. This mechanism is broken and must not be published unless there is > an explicit way to correlate ancillary data with its corresponding vid= eo > stream. > > 2. LS is 100% the wrong mechanism to do so. > > 3. I believe that what is needed here is in the spirit of what FID is > intended to convey, although I take Thomas' point that there is some > language in the specific definition of FID that he believes makes it > unsuitable for this purpose. > > > Given that we seem to have reached an impasse on the final point in > particular, I would propose that the most straightforward solution here i= s > to define a new group semantic (e.g., "a=3Dgroup:ANC") that is explicitly > intended to pair ancillary data with its corresponding video stream. This > should take at most one short paragraph and an additional IANA registrati= on. > Ah, did not see your email before my earlier email. I'd agree but I would do the new grouping semantics for generic metadata not just for ANC. -acbegen > > > /a > > > > On 10/10/17 1:44 AM, Ali C. Begen wrote: > > Hi Thomas > > Please go ahead and submit a revision. Then reach out to the individual > DISCUSS holders to clear theirs. And then lets focus on Adam's discuss. > > Thanks > -acbegen (your payload wg co-chair) > > On Tue, Oct 10, 2017 at 3:06 AM, Thomas Edwards > wrote: > >> I will note that I have uploaded a new version, >> draft-ietf-payload-rtp-ancillary-11, to address most of the comments >> from the IESG evaluation. >> >> draft-ietf-payload-rtp-ancillary-11, Section 4.1 =E2=80=9CGrouping ANC S= treams >> with other Media Streams=E2=80=9D has two examples. >> >> In the first SDP example, two =E2=80=9Cm=3D=E2=80=9D lines are present (= with each having a >> different =E2=80=9Cc=3D=E2=80=9D line), one for uncompressed video, and = one for ancillary >> data. The two RTP sessions are identified with RFC 5888 Media Stream >> Identification Attributes (mid), and are grouped together using Lip >> Synchronization (LS), in a fashion similar to the Lip Synchronization of >> video and audio streams in RFC 5888 Section 7.1 =E2=80=9CExample of LS= =E2=80=9D. >> >> In the second SDP example, a single =E2=80=9Cm=3D=E2=80=9D line is prese= nt without any >> grouping, implying any synchronization would be from SSRC/CNAME linkage >> and/or RTCP. >> >> The most likely implementation of this RTP payload in professional video >> production would be where multiple endpoints are contributing elementary >> streams of media: video, audio channels or channel groups, and SMPTE ST >> 291-1 ancillary data sources. Those endpoints (microphones, cameras, >> Closed Caption generators, etc.) are all likely to be different, thus wi= th >> different SSRCs and CNAMEs, and transmitting to separate multicast IP >> addresses and UDP ports. However, they will likely be transmitted with = a >> commonly synchronized clock as per RFC 7273 =E2=80=9CRTP Clock Source Si= gnalling=E2=80=9D, >> most likely IEEE 1588 PTP. >> >> The individual elementary media streams will be composed together by >> receivers as required for production. For example, for an English langu= age >> service, an English audio channel group of AES67/RFC 3190 RTP audio woul= d >> be composed together with the RFC 4175 video and the ST 291-1 ancillary >> data flow of English language Closed Captions ancillary data and SMPTE >> 2016-1 AFD ancillary data. Meanwhile the Spanish language service wou= ld >> have the same video and AFD ancillary data, but would have Spanish langu= age >> audio and Spanish Closed Captions. Likely it would be a distribution >> quality encoder (perhaps H.264 encoder) that subscribes to the different >> streams in order to create the final service. >> >> Every time I read about =E2=80=9CFID=E2=80=9D in RFC 5888, I am struck b= y the sentence in >> Section 8 =E2=80=9CFlow Identification (FID)=E2=80=9D that says =E2=80= =9Cthere are situations where >> a single media instance (e.g., an audio stream or a video stream) is sen= t >> using more than one RTP session,=E2=80=9D which I believe is not the cas= e here. >> For example, video is one media instance, and ancillary data is a second >> media instance. You can=E2=80=99t =E2=80=9Cadd=E2=80=9D video and ancil= lary data together, like >> you can add together voice audio and DTMF tone audio (as in RFC 5888 >> Section 8.2). >> >> RFC 5888 Section 8.4 =E2=80=9CFID Semantics=E2=80=9D also states: =E2=80= =9CIt is assumed that the >> application uses only one codec at a time to encode the media produced. >> This codec MAY change dynamically during the session, but at any particu= lar >> moment, only one codec is in use.=E2=80=9D Again, this does not seem re= levant to >> the SDP description of multiple RTP streams of video, audio, and ancilla= ry >> data intended for synchronized presentation. All three =E2=80=9Ccodecs= =E2=80=9D are in use >> at all times for their particular media stream. And in particular >> regarding draft-ietf-payload-rtp-ancillary, there is only one =E2=80=9Cc= odec=E2=80=9D >> ever used, the encapsulation of SMPTE ST 291-1 ancillary data packets in= to >> RTP. >> >> I could really use the help of the IESG to see how we can move forward >> regarding the open DISCUSS item on draft-ietf-payload-rtp-ancillary. >> >> (I will note that SMPTE is eagerly awaiting the publishing of this RFC >> for use as a normative reference in the upcoming ST 2110-40 standard, se= e: >> https://www.smpte.org/st-2110). >> >> Thanks! >> >> -Thomas Edwards >> FOX >> >> On 10/4/17, 9:27 AM, "Roni Even" wrote: >> >> Hi Colin, >> >> I agree. >> >> There are two cases. The assumption is that both video and ANC have >> the same source and have same CNAME (Thomas - is this correct?) >> >> >> >> 1. Both video and ANC are in the same RTP session (same m-line) wil= l >> be synchronized. >> >> >> >> The second is the one we are discussing: >> >> 2. The video and ANC are in separate RTP sessions (two m-lines). If >> both are a single flow (single RTP stream) should group using FID. If th= ey >> are not a single RTP stream (flow) should use LS. >> >> >> >> I can agree that it looks like a single flow (FID) but want >> clarification from the authors (Thomas) >> >> >> >> >> >> >> >> Roni >> >> >> >> > -----Original Message----- >> >> > From: Colin Perkins [mailto:csp@csperkins.org] >> >> > Sent: =D7=99=D7=95=D7=9D =D7=93 04 =D7=90=D7=95=D7=A7=D7=98=D7=95= =D7=91=D7=A8 2017 01:50 >> >> > To: Roni Even >> >> > Cc: Adam Roach; Thomas Edwards; The IESG; payload-chairs@ietf.org; >> draft- >> >> > ietf-payload-rtp-ancillary@ietf.org; payload@ietf.org; >> acbegen@gmail.com >> >> > Subject: Re: [payload] Adam Roach's Discuss on >> draft-ietf-payload-rtp- >> >> > ancillary-10: (with DISCUSS and COMMENT) >> >> > >> >> > Roni, >> >> > >> >> > I said nothing about multicast vs unicast, since I don=E2=80=99t t= hink that >> distinction is >> >> > important. >> >> > >> >> > Sending the streams on separate m=3D lines or sending using a sing= le >> a m=3D line >> >> > both work. The draft doesn=E2=80=99t need to discuss this, since i= t=E2=80=99s >> standard RTP as >> >> > would apply to any RTP session. If you use separate m=3D lines, th= en >> you need >> >> > a grouping mechanism. The choice of grouping mechanism is what we= =E2=80=99re >> >> > discussing. >> >> > >> >> > Colin >> >> > >> >> > >> >> > >> >> > >> >> > > On 3 Oct 2017, at 23:19, Roni Even wrote: >> >> > > >> >> > > Colin, >> >> > > We still need some feedback from Thomas, in a previous email >> response to >> >> > Adam he gave a reason for using multiple RTP sessions: >> >> > > >> >> > > "The challenge is that the use case of the Ancillary I-D within >> the SMPTE ST >> >> > 2110 architecture would generally require separate network >> destination >> >> > addresses for the different elements (video, audio, ancillary data= ) >> so they >> >> > can be flexibly composed within broadcast plants at the network >> level. Your >> >> > alternative SDP example appears to place both the video and the >> ancillary >> >> > data onto the same destination address ( >> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__233. >> 252.0.1&d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9- >> EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3D >> dOxHA7dn5d2eo_tU3divd4ks6mmXPhk5WmodLULHUPY&s=3D >> srzDHDG2LTcTBJexIDta4-p9142SYkQ2gDH3S8PMdZg&e=3D). Is there an >> >> > appropriate SDP mechanism to communicate the intimate relationship >> >> > between the RTP streams, but also have them transmitted on separat= e >> >> > destination IP addresses (and synchronized)? >> >> > > >> >> > > (In production practice, this may not be a significant issue as >> the RTP >> >> > streams to be combined by IP receivers for conversion to SDI/HDMI >> or for >> >> > input to a distribution encoder may be specified by a control >> system directly >> >> > to the receiver using an API that isn=E2=80=99t just an SDP file.)= " >> >> > > >> >> > > I want to assume that by different destination addresses it >> refers to >> >> > multicast addresses like above and not to different unicast IP >> addresses. >> >> > > You are right that for unicast it will make sense to use the sam= e >> RTP session >> >> > with the same SSRC. >> >> > > >> >> > > Roni >> >> > > >> >> > >> -----Original Message----- >> >> > >> From: Colin Perkins [mailto:csp@csperkins.org] >> >> > >> Sent: =D7=99=D7=95=D7=9D =D7=93 04 =D7=90=D7=95=D7=A7=D7=98=D7= =95=D7=91=D7=A8 2017 00:46 >> >> > >> To: Roni Even >> >> > >> Cc: Adam Roach; Thomas Edwards; The IESG; >> payload-chairs@ietf.org; >> >> > >> draft- ietf-payload-rtp-ancillary@ietf.org; payload@ietf.org; >> >> > >> acbegen@gmail.com >> >> > >> Subject: Re: [payload] Adam Roach's Discuss on >> >> > >> draft-ietf-payload-rtp- >> >> > >> ancillary-10: (with DISCUSS and COMMENT) >> >> > >> >> >> > >> >> >> > >>> On 3 Oct 2017, at 21:40, Roni Even >> wrote: >> >> > >>> >> >> > >>> Hi Colin, >> >> > >>> I re-read RFC5888 and tried to understand what is the differen= ce >> >> > >>> between FID and LS I was trying to understand what is a flow a= nd >> >> > >>> from section 8.3 >> >> > >>> >> >> > >>> "The previous examples show that the definition of a media >> stream in >> >> > >>> [RFC2326] does not cover some scenarios. It cannot be assumed >> that >> >> > >>> a single media instance maps into a single RTP session. >> Therefore, >> >> > >>> we introduce the definition of a media flow: >> >> > >>> >> >> > >>> A media flow consists of a single media instance, e.g., an >> audio >> >> > >>> stream or a video stream as well as a single whiteboard or >> shared >> >> > >>> application group. When using RTP, a media flow comprises >> one or >> >> > >>> more RTP sessions." >> >> > >>> >> >> > >>> It looks to me that a media flow is a SINGLE media stream that >> spans >> >> > >>> over >> >> > >> multiple RTP sessions (the term media instance is a what we cal= l >> a >> >> > >> media stream in the taxonomy). Section 8.5 (8.5.1) enhance this >> by >> >> > >> saying when FID cannot be used " FID semantics are useful when >> the >> >> > application only uses >> >> > >> one codec at a time" which again describe a flow as a single >> media >> >> > stream. >> >> > >>> >> >> > >>> I am not sure how ANC and the video relates to each other this >> is >> >> > >>> what I am >> >> > >> asking Thomas to be more clear. If the video and ANC are one >> stream >> >> > >> over multiple RTP sessions FID is correct otherwise I think the >> LS should be >> >> > used. >> >> > >> >> >> > >> My understanding is that the video and ancillary data are the >> same >> >> > >> stream. In broadcast TV the ancillary data is sent in-band, in >> the blanking >> >> > intervals. >> >> > >> >> >> > >>> My reading on the ancillary draft is that ANC and the video a= re >> >> > >>> what we call >> >> > >> a single RTP stream but this is not what Thomas says. >> >> > >> >> >> > >> >> >> > >> I expect one could send the ancillary data using the same SSRC, >> and >> >> > >> the same 5-tuple, as the media data (in the same way comfort >> noise >> >> > >> and speech data can be sent), in which case you don=E2=80=99t n= eed the >> >> > >> grouping. If they=E2=80=99re sent as separate RTP streams, with= separate >> m=3D >> >> > >> lines, then you need grouping. I believe FID makes sense for >> this. >> >> > >> >> >> > >> -- >> >> > >> Colin Perkins >> >> > >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__csperki >> ns.org_&d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9- >> EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3D >> dOxHA7dn5d2eo_tU3divd4ks6mmXPhk5WmodLULHUPY&s=3Ds2We2es-My1JRf >> cPlYZEmqGCYYi9rf9Wc7dYRzxspsY&e=3D >> >> > >> >> >> > >> >> >> > >> >> >> > > >> >> > >> >> > >> >> > >> >> > -- >> >> > Colin Perkins >> >> > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__csperki >> ns.org_&d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9- >> EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3D >> dOxHA7dn5d2eo_tU3divd4ks6mmXPhk5WmodLULHUPY&s=3Ds2We2es-My1JRf >> cPlYZEmqGCYYi9rf9Wc7dYRzxspsY&e=3D >> >> > >> >> > >> >> > >> >> >> >> >> >> > > --001a1148aa62ffb3ae055b382aa4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Oct 11, 2017 at 12:02 AM, Adam Roach <adam@nostrum.com><= /span> wrote:
=20 =20 =20
Here are the salien= t points that pertain to my discuss:

  1. This mechanism is broken and must not be published unless there is an explicit way to correlate ancillary data with its corresponding video stream.

  2. LS is 100% the wrong mechanism to do so.

  3. I believe that what is needed here is in the spirit of what FID is intended to convey, although I take Thomas' point that there is some language in the specific definition of FID that he believes makes it unsuitable for this purpose.

Given that we seem to have reached an impasse on the final point in particular, I would propose that the most straightforward solution here is to define a new group semantic (e.g., "a=3Dgroup:ANC") that is explicitly intended to pair ancill= ary data with its corresponding video stream. This should take at most one short paragraph and an additional IANA registration.

Ah, did not see your email before my earlier em= ail. I'd agree but I would do the new grouping semantics for generic me= tadata not just for ANC.=C2=A0

-acbegen
= =C2=A0


/a



On 10/10/17 1:44 AM, Ali C. Begen wrote:
Hi Thomas

Please go ahead and submit a revision. Then reach out to the individual DISCUSS holders to clear theirs. And then lets focus on Adam's discuss.

Thanks
-acbegen (your payload wg co-chair)

On Tue, Oct 10, 2017 at 3:06 AM, Thomas Edwards <Thomas.Edwards@fox.com> wrote:
I will note that I have uploaded a new version, draft-ietf-payload-rtp-ancillary-11, to address most of the comments from the IESG evaluation.

draft-ietf-payload-rtp-ancillary-11, Section 4.1 =E2=80=9CGrouping ANC Streams with other Media Streams=E2=80=9D= has two examples.

In the first SDP example, two =E2=80=9Cm=3D=E2=80=9D lines are = present (with each having a different =E2=80=9Cc=3D=E2=80=9D line), one for u= ncompressed video, and one for ancillary data.=C2=A0 The two RTP sessions a= re identified with RFC 5888 Media Stream Identification Attributes (mid), and are grouped together using Lip Synchronization (LS), in a fashion similar to the Lip Synchronization of video and audio streams in RFC 5888 Section 7.1 =E2=80=9CExample of LS=E2=80=9D.

In the second SDP example, a single =E2=80=9Cm=3D=E2=80=9D line= is present without any grouping, implying any synchronization would be from SSRC/CNAME linkage and/or RTCP.

The most likely implementation of this RTP payload in professional video production would be where multiple endpoints are contributing elementary streams of media: video, audio channels or channel groups, and SMPTE ST 291-1 ancillary data sources.=C2=A0 Those endpoints (microphones, cameras, Closed Caption generators, etc.) are all likely to be different, thus with different SSRCs and CNAMEs, and transmitting to separate multicast IP addresses and UDP ports.=C2=A0 However, they will likely be transmitted with a commonly synchronized clock as per RFC 7273 =E2=80=9CRTP Clock Source Signalling=E2=80=9D, most likely IEEE 1588 PTP.

The individual elementary media streams will be composed together by receivers as required for production.=C2=A0 For example, for an English language service, an English audio channel group of AES67/RFC 3190 RTP audio would be composed together with the RFC 4175 video and the ST 291-1 ancillary data flow of English language Closed Captions ancillary data and SMPTE 2016-1 AFD ancillary data.=C2=A0 =C2=A0 Meanwhile the Spanish language service would have the same video and AFD ancillary data, but would have Spanish language audio and Spanish Closed Captions.=C2=A0 Likely it would be a distributio= n quality encoder (perhaps H.264 encoder) that subscribes to the different streams in order to create the final service.

Every time I read about =E2=80=9CFID=E2=80=9D in RFC 5888, I am= struck by the sentence in Section 8 =E2=80=9CFlow Identification (FID)=E2= =80=9D that says =E2=80=9Cthere are situations where a single media instanc= e (e.g., an audio stream or a video stream) is sent using more than one RTP session,=E2=80=9D which I believe is not the case here.=C2=A0 For example, video is one media instance, and ancillary data is a second media instance.=C2=A0 You can=E2=80= =99t =E2=80=9Cadd=E2=80=9D video and ancillary data together, like you can add together voice audio and DTMF tone audio (as in RFC 5888 Section 8.2).

RFC 5888 Section 8.4 =E2=80=9CFID Semantics=E2=80=9D also state= s: =E2=80=9CIt is assumed that the application uses only one codec at a time to encode the media produced.=C2=A0 This codec MAY change dynamically during the session, but at any particular moment, only one codec is in use.=E2=80=9D=C2=A0 Again, this do= es not seem relevant to the SDP description of multiple RTP streams of video, audio, and ancillary data intended for synchronized presentation.=C2=A0 All three =E2=80=9Ccodecs=E2= =80=9D are in use at all times for their particular media stream.=C2=A0 And in particular regarding draft-ietf-payload-rtp-ancillary, there is only one =E2=80=9Ccodec=E2=80=9D ever used, the encaps= ulation of SMPTE ST 291-1 ancillary data packets into RTP.

I could really use the help of the IESG to see how we can move forward regarding the open DISCUSS item on draft-ietf-payload-rtp-ancillary.

(I will note that SMPTE is eagerly awaiting the publishing of this RFC for use as a normative reference in the upcoming ST 2110-40 standard, see: https://www.smpte.org/st-2110= ).

Thanks!

-Thomas Edwards
=C2=A0FOX

On 10/4/17, 9:27 AM, "Roni Even" <roni.even@huawei.com> wrote:

=C2=A0 =C2=A0 Hi Colin,
=C2=A0 =C2=A0 I agree.=

=C2=A0 =C2=A0 There are two cases. The assumption is that b= oth video and ANC have the same source and have same CNAME (Thomas - is this correct?)



=C2=A0 =C2=A0 1. Both video and ANC are in the same RTP ses= sion (same m-line)=C2=A0 will be synchronized.



=C2=A0 =C2=A0 The second is the one we are discussing:

=C2=A0 =C2=A0 2. The video and ANC are in separate RTP sess= ions (two m-lines). If both are a single flow (single RTP stream) should group using FID. If they are not a single RTP stream (flow) should use LS.



=C2=A0 =C2=A0 I can agree that it looks like a single flow = (FID) but want clarification from the authors (Thomas)







=C2=A0 =C2=A0 Roni



=C2=A0 =C2=A0 > -----Original Message-----

=C2=A0 =C2=A0 > From: Colin Perkins [mailto:csp@csperkins.org]

=C2=A0 =C2=A0 > Sent: =D7=99=D7=95=D7=9D =D7=93 04 =D7= =90=D7=95=D7=A7=D7=98=D7=95=D7=91=D7=A8 2017 01:50

=C2=A0 =C2=A0 > To: Roni Even

=C2=A0 =C2=A0 > Cc: Adam Roach; Thomas Edwards; The IESG= ; payload-chai= rs@ietf.org; draft-

=C2=A0 =C2=A0 > ietf-payload-rtp-ancillary@ietf.org; paylo= ad@ietf.org; acbe= gen@gmail.com

=C2=A0 =C2=A0 > Subject: Re: [payload] Adam Roach's = Discuss on draft-ietf-payload-rtp-

=C2=A0 =C2=A0 > ancillary-10: (with DISCUSS and COMMENT)=

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > Roni,

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > I said nothing about multicast vs unicas= t, since I don=E2=80=99t think that distinction is

=C2=A0 =C2=A0 > important.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > Sending the streams on separate m=3D lin= es or sending using a single a m=3D line

=C2=A0 =C2=A0 > both work. The draft doesn=E2=80=99t nee= d to discuss this, since it=E2=80=99s standard RTP as

=C2=A0 =C2=A0 > would apply to any RTP session. If you u= se separate m=3D lines, then you need

=C2=A0 =C2=A0 > a grouping mechanism. The choice of grou= ping mechanism is what we=E2=80=99re

=C2=A0 =C2=A0 > discussing.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > Colin

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > > On 3 Oct 2017, at 23:19, Roni Even = <roni.even@hua= wei.com> wrote:

=C2=A0 =C2=A0 > >

=C2=A0 =C2=A0 > > Colin,

=C2=A0 =C2=A0 > > We still need some feedback from Th= omas, in a previous email response to

=C2=A0 =C2=A0 > Adam he gave a reason for using multiple= RTP sessions:

=C2=A0 =C2=A0 > >

=C2=A0 =C2=A0 > > "The challenge is that the use= case of the Ancillary I-D within the SMPTE ST

=C2=A0 =C2=A0 > 2110 architecture would generally requir= e separate network destination

=C2=A0 =C2=A0 > addresses for the different elements (vi= deo, audio, ancillary data) so they

=C2=A0 =C2=A0 > can be flexibly composed within broadcas= t plants at the network level.=C2=A0 Your

=C2=A0 =C2=A0 > alternative SDP example appears to place= both the video and the ancillary

=C2=A0 =C2=A0 > data onto the same destination address (https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__233.252.0.1&d=3DDwIGaQ&c=3Duw6TLu4h= whHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=3DlekNOOM5noV61zrPH3rwP= yhtNnLLWoLEHgd0quQxly8&m=3DdOxHA7dn5d2eo_tU3divd4ks6mmXPhk5WmodLULHUPY&s=3DsrzDHDG2LTcTBJexIDta4-p9142SYkQ2gDH3S8PMdZ= g&e=3D).=C2=A0 Is there an

=C2=A0 =C2=A0 > appropriate SDP mechanism to communicate= the intimate relationship

=C2=A0 =C2=A0 > between the RTP streams, but also have t= hem transmitted on separate

=C2=A0 =C2=A0 > destination IP addresses (and synchroniz= ed)?

=C2=A0 =C2=A0 > >

=C2=A0 =C2=A0 > > (In production practice, this may n= ot be a significant issue as the RTP

=C2=A0 =C2=A0 > streams to be combined by IP receivers f= or conversion to SDI/HDMI or for

=C2=A0 =C2=A0 > input to a distribution encoder may be specified by a control system directly

=C2=A0 =C2=A0 > to the receiver using an API that isn=E2= =80=99t just an SDP file.)"

=C2=A0 =C2=A0 > >

=C2=A0 =C2=A0 > > I want to assume that by different destination addresses it refers to

=C2=A0 =C2=A0 > multicast addresses like above and not t= o different unicast IP addresses.

=C2=A0 =C2=A0 > > You are right that for unicast it w= ill make sense to use the same RTP session

=C2=A0 =C2=A0 > with the same SSRC.

=C2=A0 =C2=A0 > >

=C2=A0 =C2=A0 > > Roni

=C2=A0 =C2=A0 > >

=C2=A0 =C2=A0 > >> -----Original Message-----

=C2=A0 =C2=A0 > >> From: Colin Perkins [mailto:csp@csperkins.org]<= br>
=C2=A0 =C2=A0 > >> Sent: =D7=99=D7=95=D7=9D =D7=93= 04 =D7=90=D7=95=D7=A7=D7=98=D7=95=D7=91=D7=A8 2017 00:46

=C2=A0 =C2=A0 > >> To: Roni Even

=C2=A0 =C2=A0 > >> Cc: Adam Roach; Thomas Edwards;= The IESG; payload-chairs@ietf.org;

=C2=A0 =C2=A0 > >> draft- ietf-payload-rtp-ancillary= @ietf.org; paylo= ad@ietf.org;

=C2=A0 =C2=A0 > >> acbegen@gmail.com

=C2=A0 =C2=A0 > >> Subject: Re: [payload] Adam Roa= ch's Discuss on

=C2=A0 =C2=A0 > >> draft-ietf-payload-rtp-

=C2=A0 =C2=A0 > >> ancillary-10: (with DISCUSS and COMMENT)

=C2=A0 =C2=A0 > >>

=C2=A0 =C2=A0 > >>

=C2=A0 =C2=A0 > >>> On 3 Oct 2017, at 21:40, Ro= ni Even <roni.even@huawei.com> wrote:

=C2=A0 =C2=A0 > >>>

=C2=A0 =C2=A0 > >>> Hi Colin,

=C2=A0 =C2=A0 > >>> I re-read RFC5888 and tried= to understand what is the difference

=C2=A0 =C2=A0 > >>> between FID and LS I was tr= ying to understand what is a flow and

=C2=A0 =C2=A0 > >>> from section 8.3

=C2=A0 =C2=A0 > >>>

=C2=A0 =C2=A0 > >>> "The previous examples= show that the definition of a media stream in

=C2=A0 =C2=A0 > >>> [RFC2326] does not cover so= me scenarios.=C2=A0 It cannot be assumed that

=C2=A0 =C2=A0 > >>> a=C2=A0 single media instan= ce maps into a single RTP session.=C2=A0 Therefore,

=C2=A0 =C2=A0 > >>> we=C2=A0 introduce the defi= nition of a media flow:

=C2=A0 =C2=A0 > >>>

=C2=A0 =C2=A0 > >>>=C2=A0 =C2=A0 =C2=A0A media = flow consists of a single media instance, e.g., an audio

=C2=A0 =C2=A0 > >>>=C2=A0 =C2=A0 =C2=A0stream o= r a video stream as well as a single whiteboard or shared

=C2=A0 =C2=A0 > >>>=C2=A0 =C2=A0 =C2=A0applicat= ion group.=C2=A0 When using RTP, a media flow comprises one or

=C2=A0 =C2=A0 > >>>=C2=A0 =C2=A0 =C2=A0more RTP= sessions."

=C2=A0 =C2=A0 > >>>

=C2=A0 =C2=A0 > >>> It looks to me that a media= flow is a SINGLE media stream that spans

=C2=A0 =C2=A0 > >>> over

=C2=A0 =C2=A0 > >> multiple RTP sessions (the term= media instance is a what we call a

=C2=A0 =C2=A0 > >> media stream in the taxonomy). = Section 8.5 (8.5.1) enhance this by

=C2=A0 =C2=A0 > >> saying when FID cannot be used = " FID semantics are useful when the

=C2=A0 =C2=A0 > application only uses

=C2=A0 =C2=A0 > >> one codec at=C2=A0 =C2=A0a time= "=C2=A0 which again describe a flow as a single media

=C2=A0 =C2=A0 > stream.

=C2=A0 =C2=A0 > >>>

=C2=A0 =C2=A0 > >>> I am not sure how ANC and t= he video relates to each other this is

=C2=A0 =C2=A0 > >>> what I am

=C2=A0 =C2=A0 > >> asking Thomas to be more clear.= If the video and ANC are one stream

=C2=A0 =C2=A0 > >> over multiple RTP sessions FID = is correct otherwise I think the LS should be

=C2=A0 =C2=A0 > used.

=C2=A0 =C2=A0 > >>

=C2=A0 =C2=A0 > >> My understanding is that the vi= deo and ancillary data are the same

=C2=A0 =C2=A0 > >> stream. In broadcast TV the anc= illary data is sent in-band, in the blanking

=C2=A0 =C2=A0 > intervals.

=C2=A0 =C2=A0 > >>

=C2=A0 =C2=A0 > >>> My reading on=C2=A0 the anc= illary draft is that ANC and the video are

=C2=A0 =C2=A0 > >>> what we call

=C2=A0 =C2=A0 > >> a single RTP stream but this is= not what Thomas says.

=C2=A0 =C2=A0 > >>

=C2=A0 =C2=A0 > >>

=C2=A0 =C2=A0 > >> I expect one could send the anc= illary data using the same SSRC, and

=C2=A0 =C2=A0 > >> the same 5-tuple, as the media = data (in the same way comfort noise

=C2=A0 =C2=A0 > >> and speech data can be sent), i= n which case you don=E2=80=99t need the

=C2=A0 =C2=A0 > >> grouping. If they=E2=80=99re se= nt as separate RTP streams, with separate m=3D

=C2=A0 =C2=A0 > >> lines, then you need grouping. = I believe FID makes sense for this.

=C2=A0 =C2=A0 > >>

=C2=A0 =C2=A0 > >> --

=C2=A0 =C2=A0 > >> Colin Perkins

=C2=A0 =C2=A0 > >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A_= _csperkins.org_&d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQ= x6zvFcGEsbfiY9-EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQ= xly8&m=3DdOxHA7dn5d2eo_tU3divd4ks6mmXPhk5WmodLULHUPY&s=3D= s2We2es-My1JRfcPlYZEmqGCYYi9rf9Wc7dYRzxspsY&e=3D

=C2=A0 =C2=A0 > >>

=C2=A0 =C2=A0 > >>

=C2=A0 =C2=A0 > >>

=C2=A0 =C2=A0 > >

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > --

=C2=A0 =C2=A0 > Colin Perkins

=C2=A0 =C2=A0 > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__csperki<= wbr>ns.org_&d=3DDwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEs= bfiY9-EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&= m=3DdOxHA7dn5d2eo_tU3divd4ks6mmXPhk5WmodLULHUPY&s=3Ds2We2es-M= y1JRfcPlYZEmqGCYYi9rf9Wc7dYRzxspsY&e=3D

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >








--001a1148aa62ffb3ae055b382aa4-- From nobody Tue Oct 10 14:57:35 2017 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 609D7134330; Tue, 10 Oct 2017 14:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIdq8giKBcUv; Tue, 10 Oct 2017 14:57:22 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50DBA1342FF; Tue, 10 Oct 2017 14:56:32 -0700 (PDT) Received: from [10.0.1.82] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v9ALuODq032684 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Oct 2017 16:56:25 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.82] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) From: Ben Campbell In-Reply-To: Date: Tue, 10 Oct 2017 16:56:23 -0500 Cc: Thomas Edwards , Adam Roach , "payload-chairs@ietf.org" , "payload@ietf.org" , "draft-ietf-payload-rtp-ancillary@ietf.org" , The IESG , Colin Perkins Content-Transfer-Encoding: quoted-printable Message-Id: References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <3B259563-1075-4C41-A832-D7633C39173B@foxeg.com> <61440eb5-32c3-3696-be38-8dc7c4eaf72f@nostrum.com> <863974D7-E112-4794-AD4D-C39C99BD40C9@foxeg.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> <6E58094ECC8D8344914996DAD28F1CCD810BB8@DGGEMM506-MBX.china.huawei.com> <37F6B554-530B-4A30-B66F-A70D026DD2B8@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810CC5@DGGEMM506-MBX.china.huawei.com> <04D71781-0E87-461C-BDA0-D44F94FED1A0@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810D79@DGGEMM506-MBX.china.huawei.com> <7574DE41-96BB-45C1-8279-F9E2460E0452@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD81103C@DGGEMM506-MBX.china.huawei.com> <7D009531-3DB3-4923-80B2-38BC3F9FB020@foxeg.com> To: "Ali C. Begen" X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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 Oct 2017 21:57:27 -0000 > On Oct 10, 2017, at 4:40 PM, Ali C. Begen = wrote: >=20 > Hi Ben >=20 > On Tue, Oct 10, 2017 at 11:59 PM, Ben Campbell = wrote: > My takeaways from the discussion so far: >=20 > 1) LS doesn=E2=80=99t work, at least not cleanly. > 2) FID would work, but there are philosophical objections. > 3) People don=E2=80=99t want to create a new grouping semantic. >=20 > So unless people want to argue that LS really does work, even in the = case of Adam=E2=80=99s multi-stream example, I think we are left = choosing between FID or creating something new. If people don=E2=80=99t = like FID, is creating something new (maybe a =E2=80=9Cmetadata=E2=80=9D = semantic) that hard? >=20 > Yes, this is where we are. LS does not work, I agree. I believe FID = works as the language in the RFC does not bother me because whoever = needs to work with ANC data knows how to deal with it anyway. So = bottomline is I am ready to ship this with FID. If that is absolutely = not acceptable to Thomas or others, the only option is to define a new = grouping semantics, which is not a significant work but needs blessing = from MMUSIC. The IANA registration policy for the group semantics table is = =E2=80=9Cstandards action=E2=80=9D. It needs a standards track RFC, but = I am not aware of a requirement for that to come from MMUSIC. The most = recent one came from AVTEXT. I agree that we would want a new semantic = to be at least reviewed in MMUSIC. But I don=E2=80=99t think we are = talking about all that much text to add. FID would still be easier, though. :-) Ben.= From nobody Tue Oct 10 15:01:20 2017 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 5AAF6124B17; Tue, 10 Oct 2017 15:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-S4GxwvzCsB; Tue, 10 Oct 2017 15:01:11 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E9211241F3; Tue, 10 Oct 2017 15:01:11 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v9AM14Sf033541 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Oct 2017 17:01:06 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Ben Campbell , "Ali C. Begen" Cc: Thomas Edwards , "payload-chairs@ietf.org" , "payload@ietf.org" , "draft-ietf-payload-rtp-ancillary@ietf.org" , The IESG , Colin Perkins References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <863974D7-E112-4794-AD4D-C39C99BD40C9@foxeg.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> <6E58094ECC8D8344914996DAD28F1CCD810BB8@DGGEMM506-MBX.china.huawei.com> <37F6B554-530B-4A30-B66F-A70D026DD2B8@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810CC5@DGGEMM506-MBX.china.huawei.com> <04D71781-0E87-461C-BDA0-D44F94FED1A0@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810D79@DGGEMM506-MBX.china.huawei.com> <7574DE41-96BB-45C1-8279-F9E2460E0452@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD81103C@DGGEMM506-MBX.china.huawei.com> <7D009531-3DB3-4923-80B2-38BC3F9FB020@foxeg.com> From: Adam Roach Message-ID: <805546c9-c059-20ad-57ac-55767ffb5fc5@nostrum.com> Date: Tue, 10 Oct 2017 17:01:04 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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 Oct 2017 22:01:14 -0000 On 10/10/17 4:56 PM, Ben Campbell wrote: > >> On Oct 10, 2017, at 4:40 PM, Ali C. Begen wrote: >> >> Hi Ben >> >> On Tue, Oct 10, 2017 at 11:59 PM, Ben Campbell wrote: >> My takeaways from the discussion so far: >> >> 1) LS doesn’t work, at least not cleanly. >> 2) FID would work, but there are philosophical objections. >> 3) People don’t want to create a new grouping semantic. >> >> So unless people want to argue that LS really does work, even in the case of Adam’s multi-stream example, I think we are left choosing between FID or creating something new. If people don’t like FID, is creating something new (maybe a “metadata” semantic) that hard? >> >> Yes, this is where we are. LS does not work, I agree. I believe FID works as the language in the RFC does not bother me because whoever needs to work with ANC data knows how to deal with it anyway. So bottomline is I am ready to ship this with FID. If that is absolutely not acceptable to Thomas or others, the only option is to define a new grouping semantics, which is not a significant work but needs blessing from MMUSIC. > The IANA registration policy for the group semantics table is “standards action”. It needs a standards track RFC, but I am not aware of a requirement for that to come from MMUSIC. The most recent one came from AVTEXT. I agree that we would want a new semantic to be at least reviewed in MMUSIC. But I don’t think we are talking about all that much text to add. > > FID would still be easier, though. :-) To be clear, I absolutely agree that FID would be cleaner. /a From nobody Tue Oct 10 15:05:01 2017 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 4446B1241F3 for ; Tue, 10 Oct 2017 15:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3Hvb1PfHRUB for ; Tue, 10 Oct 2017 15:04:58 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0454132198 for ; Tue, 10 Oct 2017 15:04:58 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v9AM4t2x033888 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Oct 2017 17:04:57 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: "Ali C. Begen" Cc: Thomas Edwards , Roni Even , Colin Perkins , The IESG , "payload-chairs@ietf.org" , "payload@ietf.org" References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> <6E58094ECC8D8344914996DAD28F1CCD810BB8@DGGEMM506-MBX.china.huawei.com> <37F6B554-530B-4A30-B66F-A70D026DD2B8@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810CC5@DGGEMM506-MBX.china.huawei.com> <04D71781-0E87-461C-BDA0-D44F94FED1A0@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810D79@DGGEMM506-MBX.china.huawei.com> <7574DE41-96BB-45C1-8279-F9E2460E0452@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD81103C@DGGEMM506-MBX.china.huawei.com> <7D009531-3DB3-4923-80B2-38BC3F9FB020@foxeg.com> <5b0066c9-9f5b-0e71-0428-72a07cde3e3c@nostrum.com> From: Adam Roach Message-ID: <8b9e3a3a-d2fc-135f-078a-dee3cce82f61@nostrum.com> Date: Tue, 10 Oct 2017 17:04:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8AD1AA11786174E7829E69B2" Content-Language: en-US Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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 Oct 2017 22:05:00 -0000 This is a multi-part message in MIME format. --------------8AD1AA11786174E7829E69B2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 10/10/17 4:41 PM, Ali C. Begen wrote: > > On Wed, Oct 11, 2017 at 12:02 AM, Adam Roach > wrote: > > > Given that we seem to have reached an impasse on the final point > in particular, I would propose that the most straightforward > solution here is to define a new group semantic (e.g., > "a=group:ANC") that is explicitly intended to pair ancillary data > with its corresponding video stream. This should take at most one > short paragraph and an additional IANA registration. > > > Ah, did not see your email before my earlier email. I'd agree but I > would do the new grouping semantics for generic metadata not just for > ANC. I'm okay either way. Some obeservations: If we do a new type just for ANC, I think we could include it as part of this document. If we do it as a generic "metadata" type, I think we'd need to have a separate document for that. I imagine the separate document (and the more generic requirements) would take more time than adding to this document; and it would be a normative dependency for draft-ietf-payload-rtp-ancillary. But, again, I'm okay with either such approach. /a --------------8AD1AA11786174E7829E69B2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 10/10/17 4:41 PM, Ali C. Begen wrote:

On Wed, Oct 11, 2017 at 12:02 AM, Adam Roach <adam@nostrum.com> wrote:

Given that we seem to have reached an impasse on the final point in particular, I would propose that the most straightforward solution here is to define a new group semantic (e.g., "a=group:ANC") that is explicitly intended to pair ancillary data with its corresponding video stream. This should take at most one short paragraph and an additional IANA registration.

Ah, did not see your email before my earlier email. I'd agree but I would do the new grouping semantics for generic metadata not just for ANC. 

I'm okay either way.

Some obeservations: If we do a new type just for ANC, I think we could include it as part of this document. If we do it as a generic "metadata" type, I think we'd need to have a separate document for that. I imagine the separate document (and the more generic requirements) would take more time than adding to this document; and it would be a normative dependency for draft-ietf-payload-rtp-ancillary.

But, again, I'm okay with either such approach.

/a
--------------8AD1AA11786174E7829E69B2-- From nobody Tue Oct 10 15:09:20 2017 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 070EC132E24 for ; Tue, 10 Oct 2017 15:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUKdAxsIZIdU for ; Tue, 10 Oct 2017 15:09:11 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8556C1241F3 for ; Tue, 10 Oct 2017 15:09:09 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id x54so55837672qth.12 for ; Tue, 10 Oct 2017 15:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pj4RORk64hM6qHEStowTsRJ3IFh5WvbVGHiuN5eRN4c=; b=s7WIjj18YSsPxE2B+b2gU0PHArH9GKcvSqE58uQiOlBYm8q8b2XcNcZBCBQ0E4PYT8 4rK8xW7sqraHC7zsVB514xkD5KaqUE0vaNAxWFgK21+ljpBNsSbJMwrGSDYqH8WyDLu1 FlzKckWHrR973r+rYPthZVqyLJ6zEYpCVJSoqfonRb1myGCr68XhS3AYz2fHLEGFaHmM ZJ0lu1/FqqlXzOZcHtZdgLBwbYSW59cK5+l048+t321bl1iirCQSNPxGbDd9PYkrI+lC E/rjfUEiag19Kef7mHQgyia7z87luBPggQraGMSD8ttMHPte8ea1PN4QB4AMEWyOvqsm oqHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pj4RORk64hM6qHEStowTsRJ3IFh5WvbVGHiuN5eRN4c=; b=LNPoUZ+ljy6STE/IQNHPRbAC2IEjpjcwFRi16ajukdgy/N92IgEaA9IILJtnLprJ08 gFXUowJo/ABMZLA22uSTZxq+2c2XKuJaIu2RdFuKrJULA59LOgsZAvGltrusAlJwgsLq XVzRFo1lU1pHzB+hOemeBqJHqnGlCjOeYBtoGhgtaId86PMp+iPi8pWqZ5DGuBU2ZdO8 r83nMZ81/reThKQdC5rf0N4wfhJFKExO8qRLydsUDiBHp0ihZq5STVvfKb2lxxZQwKYX pLoAFj5nXgHoW9LCSzqbzmFDwx5+Lc/Kvv6EqasNU6H1Mf7PAlVZkaPpo9zrThY3HEQs +XhQ== X-Gm-Message-State: AMCzsaVTVr7RiB+PYL+nRookIq+jaspdN9Cou4IkY5Fo2qiv8ilRSm+E Li/JQzxpIIQr2YkVzFM2czLYbNJKYqY/OiFzplxRKw== X-Google-Smtp-Source: AOwi7QDrQt9YDHkIK8TQCyEXZAVWNDSQ/D997pbisrMOJ02q/kUYbto/b868mg/WWE0+s9OAd3x954xijI7DUJWnK/8= X-Received: by 10.13.228.4 with SMTP id n4mr3185887ywe.322.1507673348633; Tue, 10 Oct 2017 15:09:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.194.129 with HTTP; Tue, 10 Oct 2017 15:09:08 -0700 (PDT) In-Reply-To: <8b9e3a3a-d2fc-135f-078a-dee3cce82f61@nostrum.com> References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> <6E58094ECC8D8344914996DAD28F1CCD810BB8@DGGEMM506-MBX.china.huawei.com> <37F6B554-530B-4A30-B66F-A70D026DD2B8@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810CC5@DGGEMM506-MBX.china.huawei.com> <04D71781-0E87-461C-BDA0-D44F94FED1A0@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810D79@DGGEMM506-MBX.china.huawei.com> <7574DE41-96BB-45C1-8279-F9E2460E0452@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD81103C@DGGEMM506-MBX.china.huawei.com> <7D009531-3DB3-4923-80B2-38BC3F9FB020@foxeg.com> <5b0066c9-9f5b-0e71-0428-72a07cde3e3c@nostrum.com> <8b9e3a3a-d2fc-135f-078a-dee3cce82f61@nostrum.com> From: "Ali C. Begen" Date: Wed, 11 Oct 2017 01:09:08 +0300 Message-ID: To: Adam Roach Cc: Thomas Edwards , Roni Even , Colin Perkins , The IESG , "payload-chairs@ietf.org" , "payload@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0358606206ac055b388ef2" Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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 Oct 2017 22:09:12 -0000 --94eb2c0358606206ac055b388ef2 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 11, 2017 at 1:04 AM, Adam Roach wrote: > On 10/10/17 4:41 PM, Ali C. Begen wrote: > > > On Wed, Oct 11, 2017 at 12:02 AM, Adam Roach wrote: > >> >> Given that we seem to have reached an impasse on the final point in >> particular, I would propose that the most straightforward solution here is >> to define a new group semantic (e.g., "a=group:ANC") that is explicitly >> intended to pair ancillary data with its corresponding video stream. This >> should take at most one short paragraph and an additional IANA registration. >> > > Ah, did not see your email before my earlier email. I'd agree but I would > do the new grouping semantics for generic metadata not just for ANC. > > > I'm okay either way. > > Some obeservations: If we do a new type just for ANC, I think we could > include it as part of this document. If we do it as a generic "metadata" > type, I think we'd need to have a separate document for that. I imagine the > separate document (and the more generic requirements) would take more time > than adding to this document; and it would be a normative dependency for > draft-ietf-payload-rtp-ancillary. > Right, so I suggest we use FID for this draft and ship it. And once we have a volunteer, he can propose a grouping semantics for generic metadata in MMUSIC which will hopefully help future drafts similar to this one. @Ben, grouping semantics does not need to come from MMUSIC WG but that is where most people familiar with the issues are, hence my comment on needing MMUSIC's blessing. @Thomas, what do you think? -acbegen > > But, again, I'm okay with either such approach. > > /a > --94eb2c0358606206ac055b388ef2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Oct 11, 2017 at 1:04 AM, Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
On 10/10/17 4:41 P= M, Ali C. Begen wrote:

On Wed, Oct 11, 2017 = at 12:02 AM, Adam Roach <adam@nostrum.com> wrote:

Given that we seem to have reached an impasse on the final point in particular, I would propose that the most straightforward solution here is to define a new group semantic (e.g., "a=3Dgroup:ANC") that is explicitly intended to pair ancillary data with its corresponding video stream. This should take at most one short paragraph and an additional IANA registration.

Ah, did not see your email before my earlier email. I'= d agree but I would do the new grouping semantics for generic metadata not just for ANC.=C2=A0

I'm okay either way.

Some obeservations: If we do a new type just for ANC, I think we could include it as part of this document. If we do it as a generic "metadata" type, I think we'd need to have a separate doc= ument for that. I imagine the separate document (and the more generic requirements) would take more time than adding to this document; and it would be a normative dependency for draft-ietf-payload-rtp-ancillary.

<= /div>
Right, so I suggest we use FID for this draft and ship it. And on= ce we have a volunteer, he can propose a grouping semantics for generic met= adata in MMUSIC which will hopefully help future drafts similar to this one= . @Ben, grouping semantics does not need to come from MMUSIC WG but that is= where most people familiar with the issues are, hence my comment on needin= g MMUSIC's blessing.

@Thomas, what do you thin= k?

-acbegen
=C2=A0

But, again, I'm okay with either such approach.

/a

--94eb2c0358606206ac055b388ef2-- From nobody Tue Oct 10 17:32:52 2017 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 D7997134613; Tue, 10 Oct 2017 17:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=foxgroupinc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlrUt-CqDus0; Tue, 10 Oct 2017 17:32:46 -0700 (PDT) Received: from mx0a-00195501.pphosted.com (mx0b-00195501.pphosted.com [67.231.157.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63F871346F3; Tue, 10 Oct 2017 17:32:45 -0700 (PDT) Received: from pps.filterd (m0082293.ppops.net [127.0.0.1]) by mx0b-00195501.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9B0U7Xr006160; Tue, 10 Oct 2017 17:32:32 -0700 Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0082.outbound.protection.outlook.com [207.46.163.82]) by mx0b-00195501.pphosted.com with ESMTP id 2dh8j504vv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 10 Oct 2017 17:32:31 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=FoxGroupInc.onmicrosoft.com; s=selector1-fox-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ywgypMr0sFBVzZ/hTZAPTwbP90ZfSMigP3IlkelwK5E=; b=iNOnCjHjHFeRRaA9CFBJ6wGSzmdRJ+unfLcNN3PmQtMQ9R+dLDhLIu3hMhLOJN2brg3Lp+Id8K38sCd4qIdashOFumY7PeMVojTcgF8Z+uvfilUH6CXETFUqGS9Kxu7pAz5mqmgOF3Bw1mMD5i6q0yU/TzjNvgqb/NhviGO6PXk= Received: from SN2PR05MB2670.namprd05.prod.outlook.com (10.166.212.141) by SN2PR05MB2672.namprd05.prod.outlook.com (10.166.212.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Wed, 11 Oct 2017 00:32:30 +0000 Received: from SN2PR05MB2670.namprd05.prod.outlook.com ([fe80::304f:c44:7030:d78c]) by SN2PR05MB2670.namprd05.prod.outlook.com ([fe80::304f:c44:7030:d78c%17]) with mapi id 15.20.0077.020; Wed, 11 Oct 2017 00:32:30 +0000 From: Thomas Edwards To: "Ali C. Begen" , Adam Roach CC: Roni Even , Colin Perkins , "The IESG" , "payload-chairs@ietf.org" , "payload@ietf.org" Thread-Topic: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) Thread-Index: AQHTFjbD5uxO79354kmKPbq9ZGEoqKK9h+8AgAIma4CAAROegIAAhb4AgAZyKgCABOWIAIAGBRyAgAAQJQCAABALgIAAHp+AgAASIwCAAAlbgIAACLOAgAEnQQCAB+a9AIAA5I4AgADvs4CAAArUAIAABpeAgAABLQD//7K1gA== Date: Wed, 11 Oct 2017 00:32:30 +0000 Message-ID: References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> <6E58094ECC8D8344914996DAD28F1CCD810BB8@DGGEMM506-MBX.china.huawei.com> <37F6B554-530B-4A30-B66F-A70D026DD2B8@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810CC5@DGGEMM506-MBX.china.huawei.com> <04D71781-0E87-461C-BDA0-D44F94FED1A0@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810D79@DGGEMM506-MBX.china.huawei.com> <7574DE41-96BB-45C1-8279-F9E2460E0452@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD81103C@DGGEMM506-MBX.china.huawei.com> <7D009531-3DB3-4923-80B2-38BC3F9FB020@foxeg.com> <5b0066c9-9f5b-0e71-0428-72a07cde3e3c@nostrum.com> <8b9e3a3a-d2fc-135f-078a-dee3cce82f61@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 x-originating-ip: [216.205.246.242] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR05MB2672; 20:2VzSFiW9r/p4x4+oH2K0HiGo4xrR3LJDWLsO0TxsTQ0XuRq4a/QymIEsq63LXFmPSxEbTLfikgwNzPlF2ckMvouOr51b5iL5KOvtFClxi++FUIWBO71hhnbfHYW+P+MUUZ7yUuexZYi92BGvxdouS54KUp6HzLMDmI539+dVr8dTUgXGy0EXBnLwTbENXtdYHSWPX8db9+NuZHzFIjyJM24KzWWFn2OXfGu+LvQhw7AYkTp8Ncu0IMJKejNyNGqw x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ec829e6d-7d70-409e-ae0d-08d5103f8e9f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:SN2PR05MB2672; x-ms-traffictypediagnostic: SN2PR05MB2672: x-exchange-antispam-report-test: UriScan:(278428928389397)(50582790962513)(21748063052155)(177823376758907); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR05MB2672; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR05MB2672; x-forefront-prvs: 0457F11EAF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(76104003)(189002)(199003)(377454003)(24454002)(54896002)(6116002)(3280700002)(6512007)(6506006)(72206003)(106356001)(36756003)(33656002)(101416001)(105586002)(7736002)(230783001)(14454004)(66066001)(3846002)(53546010)(5660300001)(102836003)(8936002)(68736007)(2906002)(6436002)(25786009)(6246003)(5250100002)(189998001)(97736004)(2900100001)(478600001)(81156014)(50986999)(8676002)(3660700001)(4326008)(82746002)(99286003)(316002)(83716003)(2950100002)(229853002)(54906003)(58126008)(54356999)(9686003)(236005)(6486002)(93886005)(76176999)(53936002)(83506001)(110136005)(6306002)(86362001)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR05MB2672; H:SN2PR05MB2670.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fox.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_A95839AA26FE4DF58FBCFF93EAAC70DCfoxegcom_" MIME-Version: 1.0 X-OriginatorOrg: fox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2017 00:32:30.3825 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: de99ade3-81db-4070-ae0d-3c1562041b30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2672 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-10_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710110005 Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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 Oct 2017 00:32:49 -0000 --_000_A95839AA26FE4DF58FBCFF93EAAC70DCfoxegcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWZ0ZXIgcmUtcmVhZGluZyBBZGFtIFJvYWNo4oCZcyBESVNDVVNTIGl0ZW0gYWdhaW4sIEkgdGhp bmsgSSBub3cgY29tcHJlaGVuZCBoaXMgY29uY2Vybi4gIEkgdGhpbmsgaGUgaXMgc2F5aW5nIHRo YXQgdGhlcmUgaXMgYSBuZWVkIHRvIHNob3cgYSDigJxyZWxhdGlvbnNoaXDigJ0gYmV0d2VlbiBh biBhbmNpbGxhcnkgZGF0YSBzdHJlYW0gYW5kIGEgdmlkZW8gc3RyZWFtLCBub3QganVzdCBhIOKA nHN5bmNocm9uaXphdGlvbuKAnSAoYWx0aG91Z2ggdGhhdCBpcyByZXF1aXJlZCBhcyB3ZWxsKS4N Cg0KSW4gYW4gU0RQIG9mIGp1c3Qgb25lIHZpZGVvIHN0cmVhbSBhbmQgb25lIGFuY2lsbGFyeSBz dHJlYW0sIEkgYmVsaWV2ZSB0aGF0IGl0IGlzIHVuYW1iaWd1b3VzIHRoYXQgdGhlIHNpbmdsZSBh bmNpbGxhcnkgZGF0YSBpcyDigJxyZWxhdGVk4oCdIHRvIHRoZSBzaW5nbGUgdmlkZW8uDQoNCkJ1 dCBjbGVhcmx5IGluIGFuIFNEUCBvZiBtdWx0aXBsZSB2aWRlbyBzdHJlYW1zIGFuZCBtdWx0aXBs ZSBhbmNpbGxhcnkgc3RyZWFtcywgZXZlbiBpZiB5b3Ugd2FudGVkIHRoZW0gYWxsIHN5bmNocm9u aXplZCBmb3IgcHJlc2VudGF0aW9uLCB0aGVyZSBpcyBubyBpbmZvcm1hdGlvbiBhYm91dCB3aGlj aCBhbmNpbGxhcnkgc3RyZWFtIGlzIHJlbGF0ZWQgdG8gd2hpY2ggdmlkZW8gc3RyZWFtLg0KDQpU aGUg4oCccmVsYXRpb25zaGlw4oCdIGRvZXMgbWF0dGVyIGZvciBtYW55IGFuY2lsbGFyeSBkYXRh IGl0ZW1zLiAgRm9yIGV4YW1wbGUsIHRoZSBBY3RpdmUgRm9ybWF0IERlc2NyaXB0aW9uIChBRkQp IHJlbGF0ZXMgc3BlY2lmaWNhbGx5IHRvIHRoZSBhcHByb3ByaWF0ZSBjb252ZXJzaW9uIG9mIG1h dGVyaWFsIGluIGEgcGFydGljdWxhciB2aWRlbyBzdHJlYW0gZnJvbSAxNjo5IHBpY3R1cmVzIHRv IDQ6MyBkaXNwbGF5cywgYW5kIGNhbiBjaGFuZ2Ugb24gYSBmcmFtZS1ieS1mcmFtZSBiYXNpcy4g IFlvdSBhbHNvIG1pZ2h0IHdhbnQgQ2xvc2VkIENhcHRpb25zIHNob3dpbmcgdXAgb24gdGhlIHNh bWUgZGlzcGxheSBhcyB0aGUgdmlkZW8gaXQgaXMgcmVsYXRlZCB0by4NCg0KVW5mb3J0dW5hdGVs eSwgd2hpbGUgRklEIGNvdWxkIHN1Z2dlc3QgdGhpcyDigJxyZWxhdGlvbnNoaXDigJ0sIFJGQyA1 ODg4IHNheXMgbm90aGluZyBhYm91dCBGSUQgaW1wbHlpbmcg4oCcc3luY2hyb25pemVkIHByZXNl bnRhdGlvbuKAnS4gIEkgYW0gdmVyeSBjb25jZXJuZWQgYWJvdXQgYmVpbmcgY2xlYXIgdGhhdCB0 aGUgZ3JvdXBpbmcgc2hvdWxkIGltcGx5IHN5bmNocm9uaXplZCBwcmVzZW50YXRpb24gd2hlcmUg YXBwcm9wcmlhdGUuDQoNClRoZSBnb29kIG5ld3MgaXMgdGhhdCBSRkMgNTg4OCBzdGF0ZXM6IOKA nFRoZXJlIE1BWSBiZSBzZXZlcmFsICJhPWdyb3VwIiBsaW5lcyBpbiBhIHNlc3Npb24gZGVzY3Jp cHRpb24u4oCdDQoNClNvIEnigJlkIGxpa2UgdG8gc3VnZ2VzdCB0aGlzIGZvciBkcmFmdC1pZXRm LXBheWxvYWQtcnRwLWFuY2lsbGFyeSBzZWN0aW9uIDQuMS4g4oCcR3JvdXBpbmcgQU5DIFN0cmVh bXMgd2l0aCBvdGhlciBNZWRpYSBTdHJlYW1z4oCdOg0KDQoxKSBQcm92aWRlIGFuIGV4YW1wbGUg d2l0aCBhIHNpbmdsZSB2aWRlbyBSVFAgc3RyZWFtIGFuZCBhIHNpbmdsZSBhbmNpbGxhcnkgZGF0 YSBSVFAgc3RyZWFtLCBncm91cGVkIHdpdGgg4oCcTFPigJ0sIGFuZCBub3RlIHRoYXQgaW4gc3Vj aCBhIHNpdHVhdGlvbiwgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHZpZGVvIGFuZCBhbmNpbGxh cnkgUlRQIHN0cmVhbSBpcyB1bmFtYmlndW91cy4gIChJIHN1c3BlY3QgdGhpcyB3b3VsZCBiZSB0 aGUgdXNlIGNhc2UgZm9yIDkwJSBvZiBwcm9mZXNzaW9uYWwgbWVkaWEgaW1wbGVtZW50YXRpb25z KQ0KDQoyKSBQcm92aWRlIGEgc2Vjb25kIGV4YW1wbGUgd2l0aCB0d28gdmlkZW8gUlRQIHN0cmVh bXMgYW5kIHR3byBhbmNpbGxhcnkgZGF0YSBSVFAgc3RyZWFtcywgZ3JvdXBlZCB3aXRoIOKAnExT 4oCdIGFuZCBhbHNvIGdyb3VwZWQgd2l0aCDigJxGSUTigJ0gdG8gc2hvdyB0aGUgcmVsYXRpb25z aGlwIGJldHdlZW4gdmlkZW8gYW5kIGFuY2lsbGFyeSBSVFAgc3RyZWFtcw0KDQpUaGF0IGlzOg0K YT1ncm91cDpMUyBWMSBWMiBNMSBNMg0KYT1ncm91cDpGSUQgVjEgTTENCmE9Z3JvdXA6RklEIFYy IE0yDQoNCih3aGVyZSBWMT12aWRlbyAjMSwgVjI9dmlkZW8gIzIsIE0xPWFuY2lsbGFyeSAjMSwg TTI9YW5jaWxsYXJ5ICMyKS4NCg0KQW5kIHNwZWNpZmljYWxseSBjYWxsaW5nIG91dCB0aGF0IOKA nEZJROKAnSBpcyB1c2VkIHRvIHNob3cgdGhhdCBhbiBhbmNpbGxhcnkgUlRQIHN0cmVhbSBpcyB0 byBiZSBhc3NvY2lhdGVkIHdpdGggYSB2aWRlbyBSVFAgc3RyZWFtLiAgKEkgY2FuIHNlZSB0aGlz IHVzZSBjYXNlIGZvciBtdWx0aXZpZXdlcnMgaW4gcHJvZmVzc2lvbmFsIG1lZGlhIGFwcGxpY2F0 aW9ucyDigJMgZm9yIGV4YW1wbGUsIHRoZXJlIGFyZSA1MCBtdWx0aXZpZXdlcnMgb2YgNCB2aWRl byBzdHJlYW1zIGVhY2ggb24gdGhlIEdhbWUgQ3JlZWsgWW9naSBJUCBvdXRzaWRlIGJyb2FkY2Fz dCB0cnVja+KAmXMgcHJvZHVjdGlvbiBtb25pdG9yIHdhbGwgdGhhdCB3aWxsIGJlIHVzZWQgdG8g cHJvZHVjZSB0aGUgTWFqb3IgTGVhZ3VlIEJhc2ViYWxsIFdvcmxkIFNlcmllcyBvbiBGT1ggbGF0 ZXIgdGhpcyBtb250aCkuDQoNCkxldCBtZSBrbm93IGlmIHRoaXMgc291bmRzIGxpa2UgYSBnb29k IGNvbXByb21pc2UhDQoNCi1UaG9tYXMNCg0KLS0NClRob21hcyBFZHdhcmRzDQpGT1ggTmV0d29y a3MgRW5naW5lZXJpbmcgJiBPcGVyYXRpb25zDQpWUCBFbmdpbmVlcmluZyAmIERldmVsb3BtZW50 DQp0aG9tYXMuZWR3YXJkc0Bmb3guY29tDQorMS0zMTAtMzY5LTY2OTYNCjEwMjAxIFcgUGljbyBC bHZkDQpMb3MgQW5nZWxlcywgQ0EgOTAwMzUNCg0KDQpGcm9tOiAiQWxpIEMuIEJlZ2VuIiA8YWxp LmJlZ2VuQG5ldHdvcmtlZC5tZWRpYT4NCkRhdGU6IFR1ZXNkYXksIE9jdG9iZXIgMTAsIDIwMTcg YXQgMzowOSBQTQ0KVG86IEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb20+DQpDYzogVGhvbWFz IEVkd2FyZHMgPFRob21hcy5FZHdhcmRzQGZveC5jb20+LCBSb25pIEV2ZW4gPHJvbmkuZXZlbkBo dWF3ZWkuY29tPiwgQ29saW4gUGVya2lucyA8Y3NwQGNzcGVya2lucy5vcmc+LCBUaGUgSUVTRyA8 aWVzZ0BpZXRmLm9yZz4sICJwYXlsb2FkLWNoYWlyc0BpZXRmLm9yZyIgPHBheWxvYWQtY2hhaXJz QGlldGYub3JnPiwgInBheWxvYWRAaWV0Zi5vcmciIDxwYXlsb2FkQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtwYXlsb2FkXSBBZGFtIFJvYWNoJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXBheWxv YWQtcnRwLWFuY2lsbGFyeS0xMDogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCg0KDQoNCk9u IFdlZCwgT2N0IDExLCAyMDE3IGF0IDE6MDQgQU0sIEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5j b208bWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20+PiB3cm90ZToNCk9uIDEwLzEwLzE3IDQ6NDEgUE0s IEFsaSBDLiBCZWdlbiB3cm90ZToNCg0KT24gV2VkLCBPY3QgMTEsIDIwMTcgYXQgMTI6MDIgQU0s IEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb208bWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20+PiB3 cm90ZToNCg0KR2l2ZW4gdGhhdCB3ZSBzZWVtIHRvIGhhdmUgcmVhY2hlZCBhbiBpbXBhc3NlIG9u IHRoZSBmaW5hbCBwb2ludCBpbiBwYXJ0aWN1bGFyLCBJIHdvdWxkIHByb3Bvc2UgdGhhdCB0aGUg bW9zdCBzdHJhaWdodGZvcndhcmQgc29sdXRpb24gaGVyZSBpcyB0byBkZWZpbmUgYSBuZXcgZ3Jv dXAgc2VtYW50aWMgKGUuZy4sICJhPWdyb3VwOkFOQyIpIHRoYXQgaXMgZXhwbGljaXRseSBpbnRl bmRlZCB0byBwYWlyIGFuY2lsbGFyeSBkYXRhIHdpdGggaXRzIGNvcnJlc3BvbmRpbmcgdmlkZW8g c3RyZWFtLiBUaGlzIHNob3VsZCB0YWtlIGF0IG1vc3Qgb25lIHNob3J0IHBhcmFncmFwaCBhbmQg YW4gYWRkaXRpb25hbCBJQU5BIHJlZ2lzdHJhdGlvbi4NCg0KQWgsIGRpZCBub3Qgc2VlIHlvdXIg ZW1haWwgYmVmb3JlIG15IGVhcmxpZXIgZW1haWwuIEknZCBhZ3JlZSBidXQgSSB3b3VsZCBkbyB0 aGUgbmV3IGdyb3VwaW5nIHNlbWFudGljcyBmb3IgZ2VuZXJpYyBtZXRhZGF0YSBub3QganVzdCBm b3IgQU5DLg0KDQpJJ20gb2theSBlaXRoZXIgd2F5Lg0KDQpTb21lIG9iZXNlcnZhdGlvbnM6IElm IHdlIGRvIGEgbmV3IHR5cGUganVzdCBmb3IgQU5DLCBJIHRoaW5rIHdlIGNvdWxkIGluY2x1ZGUg aXQgYXMgcGFydCBvZiB0aGlzIGRvY3VtZW50LiBJZiB3ZSBkbyBpdCBhcyBhIGdlbmVyaWMgIm1l dGFkYXRhIiB0eXBlLCBJIHRoaW5rIHdlJ2QgbmVlZCB0byBoYXZlIGEgc2VwYXJhdGUgZG9jdW1l bnQgZm9yIHRoYXQuIEkgaW1hZ2luZSB0aGUgc2VwYXJhdGUgZG9jdW1lbnQgKGFuZCB0aGUgbW9y ZSBnZW5lcmljIHJlcXVpcmVtZW50cykgd291bGQgdGFrZSBtb3JlIHRpbWUgdGhhbiBhZGRpbmcg dG8gdGhpcyBkb2N1bWVudDsgYW5kIGl0IHdvdWxkIGJlIGEgbm9ybWF0aXZlIGRlcGVuZGVuY3kg Zm9yIGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtYW5jaWxsYXJ5Lg0KDQpSaWdodCwgc28gSSBzdWdn ZXN0IHdlIHVzZSBGSUQgZm9yIHRoaXMgZHJhZnQgYW5kIHNoaXAgaXQuIEFuZCBvbmNlIHdlIGhh dmUgYSB2b2x1bnRlZXIsIGhlIGNhbiBwcm9wb3NlIGEgZ3JvdXBpbmcgc2VtYW50aWNzIGZvciBn ZW5lcmljIG1ldGFkYXRhIGluIE1NVVNJQyB3aGljaCB3aWxsIGhvcGVmdWxseSBoZWxwIGZ1dHVy ZSBkcmFmdHMgc2ltaWxhciB0byB0aGlzIG9uZS4gQEJlbiwgZ3JvdXBpbmcgc2VtYW50aWNzIGRv ZXMgbm90IG5lZWQgdG8gY29tZSBmcm9tIE1NVVNJQyBXRyBidXQgdGhhdCBpcyB3aGVyZSBtb3N0 IHBlb3BsZSBmYW1pbGlhciB3aXRoIHRoZSBpc3N1ZXMgYXJlLCBoZW5jZSBteSBjb21tZW50IG9u IG5lZWRpbmcgTU1VU0lDJ3MgYmxlc3NpbmcuDQoNCkBUaG9tYXMsIHdoYXQgZG8geW91IHRoaW5r Pw0KDQotYWNiZWdlbg0KDQoNCkJ1dCwgYWdhaW4sIEknbSBva2F5IHdpdGggZWl0aGVyIHN1Y2gg YXBwcm9hY2guDQoNCi9hDQoNCg== --_000_A95839AA26FE4DF58FBCFF93EAAC70DCfoxegcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIixzZXJpZjt9DQpz cGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglm b250LWZhbWlseToiQ291cmllciIsc2VyaWY7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hl YWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFmdGVyIHJlLXJlYWRpbmcgQWRhbSBSb2FjaOKAmXMgRElTQ1VTUyBpdGVtIGFnYWluLCBJ IHRoaW5rIEkgbm93IGNvbXByZWhlbmQgaGlzIGNvbmNlcm4uICZuYnNwO0kgdGhpbmsgaGUgaXMg c2F5aW5nIHRoYXQgdGhlcmUgaXMgYSBuZWVkIHRvIHNob3cgYSDigJxyZWxhdGlvbnNoaXDigJ0g YmV0d2VlbiBhbiBhbmNpbGxhcnkgZGF0YSBzdHJlYW0gYW5kIGEgdmlkZW8gc3RyZWFtLCBub3Qg anVzdCBhIOKAnHN5bmNocm9uaXphdGlvbuKAnQ0KIChhbHRob3VnaCB0aGF0IGlzIHJlcXVpcmVk IGFzIHdlbGwpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBhbiBTRFAgb2YganVzdCBvbmUg dmlkZW8gc3RyZWFtIGFuZCBvbmUgYW5jaWxsYXJ5IHN0cmVhbSwgSSBiZWxpZXZlIHRoYXQgaXQg aXMgdW5hbWJpZ3VvdXMgdGhhdCB0aGUgc2luZ2xlIGFuY2lsbGFyeSBkYXRhIGlzIOKAnHJlbGF0 ZWTigJ0gdG8gdGhlIHNpbmdsZSB2aWRlby48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IGNs ZWFybHkgaW4gYW4gU0RQIG9mIG11bHRpcGxlIHZpZGVvIHN0cmVhbXMgYW5kIG11bHRpcGxlIGFu Y2lsbGFyeSBzdHJlYW1zLCBldmVuIGlmIHlvdSB3YW50ZWQgdGhlbSBhbGwgc3luY2hyb25pemVk IGZvciBwcmVzZW50YXRpb24sIHRoZXJlIGlzIG5vIGluZm9ybWF0aW9uIGFib3V0IHdoaWNoIGFu Y2lsbGFyeSBzdHJlYW0gaXMgcmVsYXRlZCB0byB3aGljaCB2aWRlbyBzdHJlYW0uPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoZSDigJxyZWxhdGlvbnNoaXDigJ0gZG9lcyBtYXR0ZXIgZm9yIG1h bnkgYW5jaWxsYXJ5IGRhdGEgaXRlbXMuJm5ic3A7IEZvciBleGFtcGxlLCB0aGUgQWN0aXZlIEZv cm1hdCBEZXNjcmlwdGlvbiAoQUZEKSByZWxhdGVzIHNwZWNpZmljYWxseSB0byB0aGUgYXBwcm9w cmlhdGUgY29udmVyc2lvbiBvZiBtYXRlcmlhbCBpbiBhIHBhcnRpY3VsYXIgdmlkZW8gc3RyZWFt IGZyb20gMTY6OSBwaWN0dXJlcyB0byA0OjMgZGlzcGxheXMsDQogYW5kIGNhbiBjaGFuZ2Ugb24g YSBmcmFtZS1ieS1mcmFtZSBiYXNpcy4mbmJzcDsgWW91IGFsc28gbWlnaHQgd2FudCBDbG9zZWQg Q2FwdGlvbnMgc2hvd2luZyB1cCBvbiB0aGUgc2FtZSBkaXNwbGF5IGFzIHRoZSB2aWRlbyBpdCBp cyByZWxhdGVkIHRvLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5VbmZvcnR1bmF0ZWx5LCB3aGls ZSBGSUQgY291bGQgc3VnZ2VzdCB0aGlzIOKAnHJlbGF0aW9uc2hpcOKAnSwgUkZDIDU4ODggc2F5 cyBub3RoaW5nIGFib3V0IEZJRCBpbXBseWluZyDigJxzeW5jaHJvbml6ZWQgcHJlc2VudGF0aW9u 4oCdLiZuYnNwOyBJIGFtIHZlcnkgY29uY2VybmVkIGFib3V0IGJlaW5nIGNsZWFyIHRoYXQgdGhl IGdyb3VwaW5nIHNob3VsZCBpbXBseSBzeW5jaHJvbml6ZWQgcHJlc2VudGF0aW9uIHdoZXJlIGFw cHJvcHJpYXRlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZ29vZCBuZXdzIGlzIHRoYXQg UkZDIDU4ODggc3RhdGVzOiDigJxUaGVyZSBNQVkgYmUgc2V2ZXJhbCAmcXVvdDthPWdyb3VwJnF1 b3Q7IGxpbmVzIGluIGEgc2Vzc2lvbiBkZXNjcmlwdGlvbi7igJ08bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+U28gSeKAmWQgbGlrZSB0byBzdWdnZXN0IHRoaXMgZm9yIGRyYWZ0LWlldGYtcGF5bG9h ZC1ydHAtYW5jaWxsYXJ5IHNlY3Rpb24gNC4xLiDigJxHcm91cGluZyBBTkMgU3RyZWFtcyB3aXRo IG90aGVyIE1lZGlhIFN0cmVhbXPigJ06PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEpIFByb3Zp ZGUgYW4gZXhhbXBsZSB3aXRoIGEgc2luZ2xlIHZpZGVvIFJUUCBzdHJlYW0gYW5kIGEgc2luZ2xl IGFuY2lsbGFyeSBkYXRhIFJUUCBzdHJlYW0sIGdyb3VwZWQgd2l0aCDigJxMU+KAnSwgYW5kIG5v dGUgdGhhdCBpbiBzdWNoIGEgc2l0dWF0aW9uLCB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdmlk ZW8gYW5kIGFuY2lsbGFyeSBSVFAgc3RyZWFtIGlzIHVuYW1iaWd1b3VzLiZuYnNwOyAoSSBzdXNw ZWN0IHRoaXMNCiB3b3VsZCBiZSB0aGUgdXNlIGNhc2UgZm9yIDkwJSBvZiBwcm9mZXNzaW9uYWwg bWVkaWEgaW1wbGVtZW50YXRpb25zKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yKSBQcm92aWRl IGEgc2Vjb25kIGV4YW1wbGUgd2l0aCB0d28gdmlkZW8gUlRQIHN0cmVhbXMgYW5kIHR3byBhbmNp bGxhcnkgZGF0YSBSVFAgc3RyZWFtcywgZ3JvdXBlZCB3aXRoIOKAnExT4oCdIGFuZCBhbHNvIGdy b3VwZWQgd2l0aCDigJxGSUTigJ0gdG8gc2hvdyB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdmlk ZW8gYW5kIGFuY2lsbGFyeSBSVFAgc3RyZWFtczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0 IGlzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hPWdyb3VwOkxTIFYxIFYyIE0xIE0yPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hPWdyb3VwOkZJRCBWMSBNMTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YT1ncm91cDpGSUQgVjIgTTI8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+KHdoZXJlIFYxPXZpZGVvICMxLCBWMj12aWRlbyAjMiwgTTE9YW5jaWxsYXJ5ICMx LCBNMj1hbmNpbGxhcnkgIzIpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgc3BlY2lmaWNh bGx5IGNhbGxpbmcgb3V0IHRoYXQg4oCcRklE4oCdIGlzIHVzZWQgdG8gc2hvdyB0aGF0IGFuIGFu Y2lsbGFyeSBSVFAgc3RyZWFtIGlzIHRvIGJlIGFzc29jaWF0ZWQgd2l0aCBhIHZpZGVvIFJUUCBz dHJlYW0uJm5ic3A7IChJIGNhbiBzZWUgdGhpcyB1c2UgY2FzZSBmb3IgbXVsdGl2aWV3ZXJzIGlu IHByb2Zlc3Npb25hbCBtZWRpYSBhcHBsaWNhdGlvbnMg4oCTIGZvciBleGFtcGxlLCB0aGVyZSBh cmUgNTANCiBtdWx0aXZpZXdlcnMgb2YgNCB2aWRlbyBzdHJlYW1zIGVhY2ggb24gdGhlIEdhbWUg Q3JlZWsgWW9naSBJUCBvdXRzaWRlIGJyb2FkY2FzdCB0cnVja+KAmXMgcHJvZHVjdGlvbiBtb25p dG9yIHdhbGwgdGhhdCB3aWxsIGJlIHVzZWQgdG8gcHJvZHVjZSB0aGUgTWFqb3IgTGVhZ3VlIEJh c2ViYWxsIFdvcmxkIFNlcmllcyBvbiBGT1ggbGF0ZXIgdGhpcyBtb250aCkuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkxldCBtZSBrbm93IGlmIHRoaXMgc291bmRzIGxpa2UgYSBnb29kIGNvbXBy b21pc2UhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1UaG9tYXM8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+LS0mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaG9tYXMgRWR3YXJkczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rk9Y IE5ldHdvcmtzIEVuZ2luZWVyaW5nICZhbXA7IE9wZXJhdGlvbnM8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlZQIEVuZ2luZWVyaW5nICZhbXA7IERldmVsb3BtZW50PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aG9tYXMuZWR3YXJkc0Bmb3guY29tPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzEtMzEwLTM2OS02Njk2PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xMDIwMSBXIFBpY28gQmx2ZDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Mb3MgQW5nZWxlcywgQ0Eg OTAwMzU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+JnF1b3Q7QWxpIEMuIEJlZ2VuJnF1 b3Q7ICZsdDthbGkuYmVnZW5AbmV0d29ya2VkLm1lZGlhJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5U dWVzZGF5LCBPY3RvYmVyIDEwLCAyMDE3IGF0IDM6MDkgUE08YnI+DQo8Yj5UbzogPC9iPkFkYW0g Um9hY2ggJmx0O2FkYW1Abm9zdHJ1bS5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5UaG9tYXMgRWR3 YXJkcyAmbHQ7VGhvbWFzLkVkd2FyZHNAZm94LmNvbSZndDssIFJvbmkgRXZlbiAmbHQ7cm9uaS5l dmVuQGh1YXdlaS5jb20mZ3Q7LCBDb2xpbiBQZXJraW5zICZsdDtjc3BAY3NwZXJraW5zLm9yZyZn dDssIFRoZSBJRVNHICZsdDtpZXNnQGlldGYub3JnJmd0OywgJnF1b3Q7cGF5bG9hZC1jaGFpcnNA aWV0Zi5vcmcmcXVvdDsgJmx0O3BheWxvYWQtY2hhaXJzQGlldGYub3JnJmd0OywgJnF1b3Q7cGF5 bG9hZEBpZXRmLm9yZyZxdW90OyAmbHQ7cGF5bG9hZEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJq ZWN0OiA8L2I+UmU6IFtwYXlsb2FkXSBBZGFtIFJvYWNoJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRm LXBheWxvYWQtcnRwLWFuY2lsbGFyeS0xMDogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE9jdCAxMSwgMjAxNyBhdCAx OjA0IEFNLCBBZGFtIFJvYWNoICZsdDs8YSBocmVmPSJtYWlsdG86YWRhbUBub3N0cnVtLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmFkYW1Abm9zdHJ1bS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IDEwLzEwLzE3IDQ6NDEgUE0sIEFsaSBDLiBCZWdlbiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgT2N0IDExLCAyMDE3 IGF0IDEyOjAyIEFNLCBBZGFtIFJvYWNoICZsdDs8YSBocmVmPSJtYWlsdG86YWRhbUBub3N0cnVt LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFkYW1Abm9zdHJ1bS5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCkdpdmVuIHRoYXQgd2Ugc2VlbSB0byBoYXZlIHJlYWNoZWQgYW4gaW1wYXNzZSBv biB0aGUgZmluYWwgcG9pbnQgaW4gcGFydGljdWxhciwgSSB3b3VsZCBwcm9wb3NlIHRoYXQgdGhl IG1vc3Qgc3RyYWlnaHRmb3J3YXJkIHNvbHV0aW9uIGhlcmUgaXMgdG8gZGVmaW5lIGEgbmV3IGdy b3VwIHNlbWFudGljIChlLmcuLCAmcXVvdDthPWdyb3VwOkFOQyZxdW90OykgdGhhdCBpcyBleHBs aWNpdGx5IGludGVuZGVkIHRvIHBhaXIgYW5jaWxsYXJ5IGRhdGEgd2l0aCBpdHMgY29ycmVzcG9u ZGluZw0KIHZpZGVvIHN0cmVhbS4gVGhpcyBzaG91bGQgdGFrZSBhdCBtb3N0IG9uZSBzaG9ydCBw YXJhZ3JhcGggYW5kIGFuIGFkZGl0aW9uYWwgSUFOQSByZWdpc3RyYXRpb24uPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QWgsIGRpZCBub3Qgc2VlIHlvdXIgZW1haWwgYmVmb3JlIG15IGVhcmxpZXIgZW1h aWwuIEknZCBhZ3JlZSBidXQgSSB3b3VsZCBkbyB0aGUgbmV3IGdyb3VwaW5nIHNlbWFudGljcyBm b3IgZ2VuZXJpYyBtZXRhZGF0YSBub3QganVzdCBmb3IgQU5DLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQpJJ20gb2theSBlaXRoZXIgd2F5Ljxicj4NCjxicj4NClNvbWUg b2Jlc2VydmF0aW9uczogSWYgd2UgZG8gYSBuZXcgdHlwZSBqdXN0IGZvciBBTkMsIEkgdGhpbmsg d2UgY291bGQgaW5jbHVkZSBpdCBhcyBwYXJ0IG9mIHRoaXMgZG9jdW1lbnQuIElmIHdlIGRvIGl0 IGFzIGEgZ2VuZXJpYyAmcXVvdDttZXRhZGF0YSZxdW90OyB0eXBlLCBJIHRoaW5rIHdlJ2QgbmVl ZCB0byBoYXZlIGEgc2VwYXJhdGUgZG9jdW1lbnQgZm9yIHRoYXQuIEkgaW1hZ2luZSB0aGUgc2Vw YXJhdGUgZG9jdW1lbnQgKGFuZCB0aGUgbW9yZSBnZW5lcmljDQogcmVxdWlyZW1lbnRzKSB3b3Vs ZCB0YWtlIG1vcmUgdGltZSB0aGFuIGFkZGluZyB0byB0aGlzIGRvY3VtZW50OyBhbmQgaXQgd291 bGQgYmUgYSBub3JtYXRpdmUgZGVwZW5kZW5jeSBmb3IgZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1h bmNpbGxhcnkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJpZ2h0LCBzbyBJIHN1Z2dlc3Qgd2UgdXNlIEZJRCBmb3Ig dGhpcyBkcmFmdCBhbmQgc2hpcCBpdC4gQW5kIG9uY2Ugd2UgaGF2ZSBhIHZvbHVudGVlciwgaGUg Y2FuIHByb3Bvc2UgYSBncm91cGluZyBzZW1hbnRpY3MgZm9yIGdlbmVyaWMgbWV0YWRhdGEgaW4g TU1VU0lDIHdoaWNoIHdpbGwgaG9wZWZ1bGx5IGhlbHAgZnV0dXJlIGRyYWZ0cyBzaW1pbGFyIHRv IHRoaXMgb25lLiBAQmVuLCBncm91cGluZyBzZW1hbnRpY3MNCiBkb2VzIG5vdCBuZWVkIHRvIGNv bWUgZnJvbSBNTVVTSUMgV0cgYnV0IHRoYXQgaXMgd2hlcmUgbW9zdCBwZW9wbGUgZmFtaWxpYXIg d2l0aCB0aGUgaXNzdWVzIGFyZSwgaGVuY2UgbXkgY29tbWVudCBvbiBuZWVkaW5nIE1NVVNJQydz IGJsZXNzaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5AVGhvbWFzLCB3aGF0IGRvIHlvdSB0aGluaz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LWFjYmVnZW48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N CkJ1dCwgYWdhaW4sIEknbSBva2F5IHdpdGggZWl0aGVyIHN1Y2ggYXBwcm9hY2guPHNwYW4gc3R5 bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPi9hPC9z cGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A95839AA26FE4DF58FBCFF93EAAC70DCfoxegcom_-- From nobody Tue Oct 17 17:35:06 2017 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 3858A1331D9; Tue, 17 Oct 2017 17:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=foxgroupinc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3PbvNkJazKc; Tue, 17 Oct 2017 17:34:58 -0700 (PDT) Received: from mx0a-00195501.pphosted.com (mx0b-00195501.pphosted.com [67.231.157.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE00A1331C2; Tue, 17 Oct 2017 17:34:57 -0700 (PDT) Received: from pps.filterd (m0087373.ppops.net [127.0.0.1]) by mx0b-00195501.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9I0Ys1d011260; Tue, 17 Oct 2017 17:34:54 -0700 Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0051.outbound.protection.outlook.com [207.46.163.51]) by mx0b-00195501.pphosted.com with ESMTP id 2dntrk0gd4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 17 Oct 2017 17:34:54 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=FoxGroupInc.onmicrosoft.com; s=selector1-fox-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HcUEJB/G3SuDcD0JF6thUjDs6GnhVa6zydDVm0lswxc=; b=SHPEPrXNJxDICwE/2+9JQwKbCjtt9n3Eje6vPcLsr+V5S4ym3CMgStSsGo2oYMlMSp7Qpb/BWRNqPkklse9IzknTDHKlCgqDYbDMHp4joVQyDxu7bXD8s/miGhiqjiUkPh24qkrjtW5JcMlM5vNuYCvB3TxfsdnPzQlj5Ithqwc= Received: from BN3PR05MB2657.namprd05.prod.outlook.com (10.166.72.21) by BN3PR05MB2660.namprd05.prod.outlook.com (10.166.72.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Wed, 18 Oct 2017 00:34:51 +0000 Received: from BN3PR05MB2657.namprd05.prod.outlook.com ([10.166.72.21]) by BN3PR05MB2657.namprd05.prod.outlook.com ([10.166.72.21]) with mapi id 15.20.0156.004; Wed, 18 Oct 2017 00:34:51 +0000 From: Thomas Edwards To: The IESG CC: "payload-chairs@ietf.org" , "draft-ietf-payload-rtp-ancillary@ietf.org" , "payload@ietf.org" , "acbegen@gmail.com" , Adam Roach Thread-Topic: Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) Thread-Index: AQHTFjbD5uxO79354kmKPbq9ZGEoqKK9h+8AgAIma4CAAROegIAAhb4AgCdoVAA= Date: Wed, 18 Oct 2017 00:34:51 +0000 Message-ID: References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <3B259563-1075-4C41-A832-D7633C39173B@foxeg.com> <61440eb5-32c3-3696-be38-8dc7c4eaf72f@nostrum.com> <863974D7-E112-4794-AD4D-C39C99BD40C9@foxeg.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 x-originating-ip: [216.205.246.242] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR05MB2660; 20:lqv8hWycPDGRd52bxpeCENHHPPPY7CaYbbyx76GFkWODWfzFew7sS8ESCrKTXkK8509ueRzOGFG5ci3s+BmlM8imxoz2FxDBjjCDmrp3mZx6L967bcHFMMnFG0KN+dFRp0iZEMMRoHvFsVirtRwam5a3NmOzxE1UHemPKbAUSwUKa6yb+DArS3Ecnxhj5Oc1XM3frD5ImZffcek5Y5YxeumFtbIb7sZXv9mXvztl1wlvuDeoIpLCHvbmKbWoF9Jy4vXY8XNzwluO0egw5dNzxOYAwGlDd/IScdm7p3iIOjw8EBKtNPEZw6VQJp1SiYJ4Gr5/j+ZG5svJkhRE9ZutYg== x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d01d55ba-691d-4b2f-3e08-08d515c00bd8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:BN3PR05MB2660; x-ms-traffictypediagnostic: BN3PR05MB2660: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR05MB2660; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR05MB2660; x-forefront-prvs: 0464DBBBC4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(39860400002)(376002)(189002)(199003)(6506006)(478600001)(99286003)(8936002)(3280700002)(25786009)(101416001)(33656002)(6512007)(9686003)(77096006)(6486002)(4326008)(105586002)(2900100001)(82746002)(86362001)(106356001)(6246003)(54906003)(3846002)(230783001)(68736007)(58126008)(6916009)(72206003)(14454004)(2950100002)(66066001)(50986999)(76176999)(3660700001)(5660300001)(81156014)(93886005)(6436002)(81166006)(54356999)(97736004)(7736002)(8676002)(36756003)(102836003)(53936002)(83506001)(83716003)(189998001)(305945005)(316002)(2906002)(229853002)(6116002)(39060400002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR05MB2660; H:BN3PR05MB2657.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fox.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <03830AA7378D1D4F9A950F3D6EE560FD@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: fox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2017 00:34:51.7543 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: de99ade3-81db-4070-ae0d-3c1562041b30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2660 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-17_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710180007 Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 18 Oct 2017 00:35:00 -0000 QWZ0ZXIgZnVydGhlciBkaXNjdXNzaW9uIHdpdGggQWRhbSBSb2FjaCwgSSBhbSBub3cgY29udmlu Y2VkIHRoYXQg4oCcRklE4oCdIGdyb3VwaW5nIGlzIGFwcHJvcHJpYXRlLiAgVGh1cywgSSBwcm9w b3NlIHRoYXQgU2VjdGlvbiA0LjEgb2YgdGhlIEktRCBiZSBhbHRlcmVkIHRvIHN0YXRlOg0KDQo0 LjEgR3JvdXBpbmcgQU5DIFN0cmVhbXMgd2l0aCBvdGhlciBNZWRpYSBTdHJlYW1zDQoNClRvIGlu ZGljYXRlIHRoZSBhc3NvY2lhdGlvbiBvZiBhbiBhbmNpbGxhcnkgZGF0YSBzdHJlYW0gd2l0aCBh IHBhcnRpY3VsYXIgdmlkZW8gc3RyZWFtLCBpbXBsZW1lbnRlcnMgTUFZIGdyb3VwIHRoZSAibSIg bGluZXMgdG9nZXRoZXIgdXNpbmcgRmxvdyBJZGVudGlmaWNhaXRvbiAoIkZJRCIpIHNlbWFudGlj cyBhcyBkZWZpbmVkIGluIFJGQyA1ODg4IFtSRkM1ODg4XS4NCg0KQSBzYW1wbGUgU0RQIG1hcHBp bmcgZm9yIGdyb3VwaW5nIEFOQyBkYXRhIHdpdGggUkZDIDQxNzUgdmlkZW8gaXMgYXMgZm9sbG93 czoNCg0KICAgICAgdj0wDQogICAgICBvPUFsIDEyMzQ1NiAxMSBJTiBJUDQgaG9zdC5leGFtcGxl LmNvbQ0KICAgICAgcz1Qcm9mZXNzaW9uYWwgTmV0d29ya2VkIE1lZGlhIFRlc3QNCiAgICAgIGk9 QSB0ZXN0IG9mIHN5bmNocm9uaXplZCB2aWRlbyBhbmQgQU5DIGRhdGENCiAgICAgIHQ9MCAwDQog ICAgICBhPWdyb3VwOkZJRCBWMSBNMQ0KICAgICAgbT12aWRlbyA1MDAwMCBSVFAvQVZQIDk2DQog ICAgICBjPUlOIElQNCAyMzMuMjUyLjAuMS8yNTUNCiAgICAgIGE9cnRwbWFwOjk2IHJhdy85MDAw MA0KICAgICAgYT1mbXRwOjk2IHNhbXBsaW5nPVlDYkNyLTQ6MjoyOyB3aWR0aD0xMjgwOyBoZWln aHQ9NzIwOyBkZXB0aD0xMA0KICAgICAgYT1taWQ6VjENCiAgICAgIG09dmlkZW8gNTAwMTAgUlRQ L0FWUCA5Nw0KICAgICAgYz1JTiBJUDQgMjMzLjI1Mi4wLjIvMjU1DQogICAgICBhPXJ0cG1hcDo5 NyBzbXB0ZTI5MS85MDAwMA0KICAgICAgYT1mbXRwOjk3IERJRF9TRElEPXsweDYxLDB4MDJ9O0RJ RF9TRElEPXsweDQxLDB4MDV9DQogICAgICBhPW1pZDpNMSAgICANCg0KLVRob21hcw0KDQo= From nobody Wed Oct 18 00:00:00 2017 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 328D8127517 for ; Tue, 17 Oct 2017 23:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5Im5GR3zBOb for ; Tue, 17 Oct 2017 23:59:53 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B58D61320CF for ; Tue, 17 Oct 2017 23:59:51 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id r79so3914169wrb.13 for ; Tue, 17 Oct 2017 23:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ECXl590d6kD6Z8xW3lvHVCbgcijpRo0qF5sTMeQSeLg=; b=Zy/q6l9t2hXKZtXLcIbc78FCl1CmcBUEhgQRAiJOOB5pchoacKr6pKcAhBjj0TO/x+ lDbKehAyGvfEf/y4JzmKOeNQu11VKWGO/1QW7DKOd7uCAyFHJwWqAxDFAVaEFpxrCcrZ CKVrLV69oQeBAoC4yB6rnZ3SOjHHGQKuCfzubLEYTZZ77OL2CXx4WxhqkWExgMaidsN1 DKmY9jz3sHNR8iNXr6p0NlcRUUKQaxIKe05HyhXNz4ZSpXLOsmb0ioc6HVtdnqA2H0BS xd4DzOMYoqjxDq7QwzIyoDv7mR3fmjKuseQDmxfEfkGGK10b3gAoEE8ZzWbWMPY01AzL ceZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ECXl590d6kD6Z8xW3lvHVCbgcijpRo0qF5sTMeQSeLg=; b=JNASoLNxpvGgXxRfxU2v2y6DVlV3km1t+68UNS7F2ThqpOCm+LOnt6hDUUHOn3F+fw ecJJFbdImwM0rIAlU22h+Vstn5RYbOEu10TjZapck0LIVGDBlmffLGCliLoXgsAYRc4T zbVPgeAiDrPRsWnq+zU+xSfP5gskHfsa3zSDzNJ1qB/kc5aZtop8UCadEDkRI/Gmd5OF 8IDGhW4rKVKik1a0Pt2gPQC9eu2m0obzt1R8sLibjQvWxmMY4Ij/M6aNri2SCUiSHbR4 eMwGpGDKOWLg3rJGhhkaCHPNl4MnN5j86LT3P67CcRyz8ktBbtBlzB1ITtVhgvqx3RgA /Jrg== X-Gm-Message-State: AMCzsaUMaMMYNQ/DNlz6O7xp3GNBcadF5zmKwPl+cnVSboMLIaOEkrxm PAs/kdbSlHGKybhwI6Fh2pj5fg== X-Google-Smtp-Source: ABhQp+Qb78m38223j6QjJCZMM6n94H/rAiT8gfRowqDBqN5Dsayeee5/7KgHx7TcF5LTYTu5qmva1A== X-Received: by 10.223.196.199 with SMTP id o7mr5551094wrf.119.1508309990229; Tue, 17 Oct 2017 23:59:50 -0700 (PDT) Received: from [192.168.1.159] ([85.105.47.236]) by smtp.gmail.com with ESMTPSA id p49sm22526625wrc.61.2017.10.17.23.59.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Oct 2017 23:59:49 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) From: "Ali C. Begen" In-Reply-To: Date: Wed, 18 Oct 2017 09:59:47 +0300 Cc: The IESG , "payload-chairs@ietf.org" , "payload@ietf.org" , Adam Roach Content-Transfer-Encoding: quoted-printable Message-Id: <385D74C0-F338-414E-A07F-03FA458628FD@networked.media> References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <3B259563-1075-4C41-A832-D7633C39173B@foxeg.com> <61440eb5-32c3-3696-be38-8dc7c4eaf72f@nostrum.com> <863974D7-E112-4794-AD4D-C39C99BD40C9@foxeg.com> To: Thomas Edwards X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 18 Oct 2017 06:59:54 -0000 Sounds good, I am glad we have an agreement. -acbegen > On Oct 18, 2017, at 3:34 AM, Thomas Edwards = wrote: >=20 > After further discussion with Adam Roach, I am now convinced that = =E2=80=9CFID=E2=80=9D grouping is appropriate. Thus, I propose that = Section 4.1 of the I-D be altered to state: >=20 > 4.1 Grouping ANC Streams with other Media Streams >=20 > To indicate the association of an ancillary data stream with a = particular video stream, implementers MAY group the "m" lines together = using Flow Identificaiton ("FID") semantics as defined in RFC 5888 = [RFC5888]. >=20 > A sample SDP mapping for grouping ANC data with RFC 4175 video is as = follows: >=20 > v=3D0 > o=3DAl 123456 11 IN IP4 host.example.com > s=3DProfessional Networked Media Test > i=3DA test of synchronized video and ANC data > t=3D0 0 > a=3Dgroup:FID V1 M1 > m=3Dvideo 50000 RTP/AVP 96 > c=3DIN IP4 233.252.0.1/255 > a=3Drtpmap:96 raw/90000 > a=3Dfmtp:96 sampling=3DYCbCr-4:2:2; width=3D1280; height=3D720; = depth=3D10 > a=3Dmid:V1 > m=3Dvideo 50010 RTP/AVP 97 > c=3DIN IP4 233.252.0.2/255 > a=3Drtpmap:97 smpte291/90000 > a=3Dfmtp:97 DID_SDID=3D{0x61,0x02};DID_SDID=3D{0x41,0x05} > a=3Dmid:M1 =20 >=20 > -Thomas >=20 From nobody Thu Oct 19 20:30:40 2017 Return-Path: X-Original-To: payload@ietf.org Delivered-To: payload@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF64126BF0; Thu, 19 Oct 2017 20:30:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: payload@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150847023234.26854.14202245797907134525@ietfa.amsl.com> Date: Thu, 19 Oct 2017 20:30:32 -0700 Archived-At: Subject: [payload] I-D Action: draft-ietf-payload-rtp-ancillary-12.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 20 Oct 2017 03:30:32 -0000 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 WG of the IETF. Title : RTP Payload for SMPTE ST 291-1 Ancillary Data Author : Thomas G. Edwards Filename : draft-ietf-payload-rtp-ancillary-12.txt Pages : 19 Date : 2017-10-19 Abstract: This memo describes a real-time transport protocol (RTP) payload format for the Society of Motion Picture and Television Engineers (SMPTE) Ancillary data, as defined by SMPTE ST 291-1. SMPTE Ancillary data is generally used along with professional video formats to carry a range of ancillary data types, including time code, Closed Captioning, and the Active Format Description (AFD). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-ancillary/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-payload-rtp-ancillary-12 https://datatracker.ietf.org/doc/html/draft-ietf-payload-rtp-ancillary-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-ancillary-12 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 nobody Thu Oct 19 21:53:56 2017 Return-Path: X-Original-To: payload@ietf.org Delivered-To: payload@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE451270AB; Thu, 19 Oct 2017 21:53:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-payload-rtp-ancillary@ietf.org, payload-chairs@ietf.org, acbegen@gmail.com, payload@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150847522936.26923.15462343206881584354.idtracker@ietfa.amsl.com> Date: Thu, 19 Oct 2017 21:53:49 -0700 Archived-At: Subject: [payload] Adam Roach's No Objection on draft-ietf-payload-rtp-ancillary-12: (with COMMENT) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 20 Oct 2017 04:53:49 -0000 Adam Roach has entered the following ballot position for draft-ietf-payload-rtp-ancillary-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-ancillary/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my DISCUSS. From nobody Fri Oct 20 14:29:20 2017 Return-Path: X-Original-To: payload@ietf.org Delivered-To: payload@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E963C13431F; Fri, 20 Oct 2017 14:29:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Cc: ben@nostrum.com, The IESG , payload-chairs@ietf.org, draft-ietf-payload-rtp-ancillary@ietf.org, payload@ietf.org, acbegen@gmail.com, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150853495894.15386.17757233540037886088.idtracker@ietfa.amsl.com> Date: Fri, 20 Oct 2017 14:29:18 -0700 Archived-At: Subject: [payload] Protocol Action: 'RTP Payload for SMPTE ST 291-1 Ancillary Data' to Proposed Standard (draft-ietf-payload-rtp-ancillary-12.txt) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 20 Oct 2017 21:29:19 -0000 The IESG has approved the following document: - 'RTP Payload for SMPTE ST 291-1 Ancillary Data' (draft-ietf-payload-rtp-ancillary-12.txt) as Proposed Standard This document is the product of the Audio/Video Transport Payloads Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-ancillary/ Technical Summary This memo describes an RTP Payload format for SMPTE Ancillary data, as defined by SMPTE ST 291-1. SMPTE Ancillary data is generally used along with professional video formats to carry a range of ancillary data types, including time code, Closed Captioning, and the Active Format Description (AFD). Working Group Summary The document was presented once during a meeting and follow-up revisions have been made based on the WG consensus. This version has been through 2 IETF last calls. The WG made material changes after the initial last call, due to feedback from implementors and external experts. Document Quality There are two known implementations: BBC Research & Development and Snell Advanced Media. The following vendors have committed to implement the protocol: COVELOZ, Imagine Communications, Lawo, Grass Valley, Utah Scientific. Personnel Ali Begen is the doc shepherd, Ben Campbell is the responsible AD.