From nobody Fri Dec 1 17:10:28 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 BE49C1293DA for ; Fri, 1 Dec 2017 17:10:26 -0800 (PST) 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_H3=-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 yJWtbupp-tEj for ; Fri, 1 Dec 2017 17:10:24 -0800 (PST) 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 78B8812717E for ; Fri, 1 Dec 2017 17:10:24 -0800 (PST) Received: from pps.filterd (m0087344.ppops.net [127.0.0.1]) by mx0a-00195501.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vB219wsb009654 for ; Fri, 1 Dec 2017 17:10:23 -0800 Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0047.outbound.protection.outlook.com [216.32.180.47]) by mx0a-00195501.pphosted.com with ESMTP id 2ekhqrr3jc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 01 Dec 2017 17:10:23 -0800 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=V5GkQuhDpmzzkMdvunuhUvG/UF5mgfeFqaEjQthU1IA=; b=jPAKhnx2p1vBrhdYdnrHg5Gh7Nar/I3qYM/Y1vfNdSlxzggfM3i6ElQGT5CL7YKQjC98kg0EQ90ldrdVsjenwNCcLGzzIBjIzqA2onDJb/cpbh4fSQ0aoYRKa8ZuEWA3GMEIOfG9PoqIMp20IwK7fBBtJZ869BWVtmhqH5mCcw0= Received: from BN3PR05MB2657.namprd05.prod.outlook.com (10.166.72.21) by BN3PR05MB2659.namprd05.prod.outlook.com (10.166.72.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Sat, 2 Dec 2017 01:10:21 +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.0282.006; Sat, 2 Dec 2017 01:10:21 +0000 From: Thomas Edwards To: "payload@ietf.org" Thread-Topic: Issues with draft-ietf-payload-rtp-ancillary-12 Thread-Index: AQHTawpT39dohZ/yJEOUMPaW1lg34Q== Date: Sat, 2 Dec 2017 01:10:21 +0000 Message-ID: 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.231] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR05MB2659; 20:JWEeTfmkHlNLf+91POAZ6xd4wMITBd7ke2ERXddKND1k96/WUIHv5A34fnIUOfQ16rTLvT8IfakEOQF+7CtUF/+l/tvuZN/kd6Y5FBMsvl0ytgxka6RmY7T+IPhXEw1Ck7kcvU4yIkyNZEUXrsVZDeLt+UkCXxaH9ctuuQ0cS4+ilyIdJ18p/rBSazCO1iYjptCsORvPpIV3F+q7lmB+1v069vim6IdDPI31y5bPrU4q+14KfFXacLU8jVRK7uZdrYaQpOsgycs51zFRwI37Y4YnBu/6FCauV/2yB5DDVJrUDiQpfiqYFxyzZQbYMkF30VA+ckLb2hAXNAmr1v/O0A== x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 0b901458-4e18-42e6-ada2-08d5392175b6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603286); SRVR:BN3PR05MB2659; x-ms-traffictypediagnostic: BN3PR05MB2659: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227612066756510)(21748063052155)(177823376758907); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231022)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123562025)(20161123558100)(20161123560025)(6072148)(201708071742011); SRVR:BN3PR05MB2659; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BN3PR05MB2659; x-forefront-prvs: 0509245D29 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(366004)(39860400002)(346002)(376002)(189002)(199003)(33896003)(54356011)(105586002)(106356001)(58126008)(102836003)(189998001)(5660300001)(8936002)(6116002)(36756003)(6506006)(68736007)(83506002)(2900100001)(5890100001)(2501003)(5640700003)(97736004)(6436002)(2351001)(478600001)(72206003)(54896002)(6306002)(3280700002)(6512007)(2906002)(86362001)(9686003)(6486002)(77096006)(82746002)(3660700001)(53936002)(101416001)(316002)(66066001)(14454004)(3846002)(7736002)(99286004)(33656002)(83716003)(6916009)(8676002)(25786009)(230783001)(81166006)(1730700003)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR05MB2659; 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: multipart/alternative; boundary="_000_F03678D1E2554381BA1FCAB227451663foxegcom_" MIME-Version: 1.0 X-OriginatorOrg: fox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0b901458-4e18-42e6-ada2-08d5392175b6 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2017 01:10:21.2840 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: de99ade3-81db-4070-ae0d-3c1562041b30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2659 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-01_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-1709140000 definitions=main-1712020013 Archived-At: Subject: [payload] Issues with draft-ietf-payload-rtp-ancillary-12 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: Sat, 02 Dec 2017 01:10:27 -0000 --_000_F03678D1E2554381BA1FCAB227451663foxegcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBJRVRGIFBheWxvYWQgV0csDQoNCldoaWxlIGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtYW5j aWxsYXJ5LTEyIHdhcyBpbiB0aGUgUkZDIEVkaXRvciBRdWV1ZSwgYSBwcm9ibGVtIGluIHRoZSBk b2N1bWVudCB3YXMgYnJvdWdodCB0byBteSBhdHRlbnRpb24uICBJIGhhdmUgcmVxdWVzdGVkIHRo YXQgdGhlIGRvY3VtZW50IGJlIHBhdXNlZCBpbiB0aGUgUkZDIEVkaXRvciBRdWV1ZSBmb3IgSUVT RyBhY3Rpb24uDQoNClRoZSBkcmFmdCBjdXJyZW50bHkgc3RhdGVzIG9mIHRoZSDigJxMaW5lX051 bWJlcuKAnSBmaWVsZDoNCg0KICAgICAgICAgICAgICAgIOKAnEEgdmFsdWUgb2YgMHg3RkUgaW5k aWNhdGVzIHRoYXQgdGhlIEFOQyBkYXRhIGlzIGludGVuZGVkIHRvIGJlIHBsYWNlZCBpbnRvIGFu eSBsZWdhbCBhcmVhIG9mIHRoZSB2ZXJ0aWNhbCBibGFua2luZyBwZXJpb2QgKCJWQU5DIGRhdGEg c3BhY2UiKSwgc3BlY2lmaWNhbGx5LuKAnQ0KDQpBcyB3ZSBrbm93LCDigJxhbnkgbGVnYWwgYXJl YSBvZiB0aGUgdmVydGljYWwgYmxhbmtpbmcgcGVyaW9k4oCdIGlzIG5vdCDigJxWQU5DIGRhdGEg c3BhY2XigJ0gYXMgZGVmaW5lZCBpbiBTTVBURSBTVCAyOTEtMSwgc28gdGhpcyBzdGF0ZW1lbnQg aXMgaW5jb3JyZWN0Lg0KDQpJIGJyaWVmbHkgY29uc2lkZXJlZCBhc2tpbmcgdGhlIFJGQyBFZGl0 b3IgdG8gc2ltcGx5IHJlbW92ZSB0aGUgcGFyZW50aGV0aWNhbCBzdGF0ZW1lbnQuICBCdXQgdHdv IHByb2JsZW1zIHNwcnVuZyB1cC4NCg0KRmlyc3QsIHdlIGRvbuKAmXQgaGF2ZSBhIEhvcml6b250 YWxfT2Zmc2V0IGNvZGUgZm9yIHBsYWNpbmcgYSBwYWNrZXQgaG9yaXpvbnRhbGx5IGFueXdoZXJl IGluIHRoZSBWQU5DIHNwYWNlIChpLmUuIGJldHdlZW4gU0FWIGFuZCBFQVYpLiAgIFdlIGRvIGhh dmUgYSBIb3Jpem9udGFsX09mZnNldCBjb2RlIGZvciBhbnl3aGVyZSBpbiBIQU5DIHNwYWNlIHRo b3VnaC4NCg0KQnV0IGEgYmlnZ2VyIHByb2JsZW0gaXMgdGhhdCBhIGdlbmVyaWMgY29kZSBmb3Ig QU5DIGRhdGEgb24gYW55IGxpbmUgaW4gdGhlIHZlcnRpY2FsIGludGVydmFsIGlzIGFjdHVhbGx5 IGEgQkFEIGlkZWEuDQoNCkltYWdpbmUgYW4gU0RJIHRvIElQIGNvbnZlcnRlciB0YWtpbmcgYSBW QU5DIHBhY2tldCBmcm9tIGJlbG93IHRoZSBSUCAxNjggc3dpdGNoIHBvaW50LCBjb2RpbmcgaXQg YXMgTGluZV9OdW1iZXIgMHg3RkUsIHRoZW4gYW4gSVAgdG8gU0RJIGNvbnZlcnRlciBwbGFjaW5n IHRoYXQgcGFja2V0IGluIGEgbGluZSBhYm92ZSB0aGUgUlAgMTY4IHN3aXRjaCBwb2ludC4gIFRo ZW4gYW4gU0RJIHN3aXRjaCBvY2N1cnMsIGFuZCB0aGF0IFZBTkMgcGFja2V0IGlzIG5vIGxvbmdl ciBhdHRhY2hlZCB0byBpdHMgY29ycmVzcG9uZGluZyBhY3RpdmUgdmlkZW8gZnJhbWUuDQoNCkFm dGVyIHN1cnZleWluZyBhbGwgbm9uLWF1ZGlvIEFOQyBkYXRhIHN0YW5kYXJkcyBhbmQgdGhlaXIg cHJlZmVycmVkIGxvY2F0aW9ucywgSSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgc29sdXRpb24gZm9y IHRoZSBzcGVjaWFsIHZhbHVlcyB0aGF0IGNvZGUgZm9yIHRoZSBsb2NhdGlvbiBvZiB0aGUgQU5D IGRhdGEgcGFja2V0IHRvIGJlIGluIGNlcnRhaW4gZ2VuZXJpYyB2ZXJ0aWNhbCByZWdpb25zIG9m IHRoZSBTREkgcmFzdGVyLiAgRm9yIExpbmVfTnVtYmVyOg0KDQoweDdGRjogV2l0aG91dCBzcGVj aWZpYyBsaW5lIGxvY2F0aW9uIHdpdGhpbiB0aGUgZmllbGQgb3IgZnJhbWUNCjB4N0ZFOiBPbiBh bnkgbGluZSBpbiB0aGUgcmFuZ2UgZnJvbSB0aGUgc2Vjb25kIGxpbmUgYWZ0ZXIgdGhlIGxpbmUg c3BlY2lmaWVkIGZvciBzd2l0Y2hpbmcsIGFzIGRlZmluZWQgaW4gU01QVEUgUlAgMTY4LCB0byB0 aGUgbGFzdCBsaW5lIGJlZm9yZSBhY3RpdmUgdmlkZW8sIGluY2x1c2l2ZQ0KMHg3RkQ6IE9uIGEg bGluZSBudW1iZXIgbGFyZ2VyIHRoYW4gY2FuIGJlIHJlcHJlc2VudGVkIGluIDExIGJpdHMgb2Yg dGhpcyBmaWVsZCAoaWYgbmVlZGVkIGZvciBmdXR1cmUgZm9ybWF0cykNCg0KQW5kIHNpbWlsYXJs eSwgZm9yIEhvcml6b250YWxfT2Zmc2V0Og0KDQoweEZGRjogV2l0aG91dCBzcGVjaWZpYyBob3Jp em9udGFsIGxvY2F0aW9uDQoweEZGRTogV2l0aGluIGhvcml6b250YWwgYW5jaWxsYXJ5IGRhdGEg c3BhY2UgKEhBTkMpIGFzIGRlZmluZWQgaW4gU01QVEUgU1QgMjkxLTENCjB4RkZEOiBXaXRoaW4g dGhlIGFuY2lsbGFyeSBkYXRhIHNwYWNlIGxvY2F0ZWQgYmV0d2VlbiBTQVYgKFN0YXJ0IG9mIEFj dGl2ZSBWaWRlbykgYW5kIEVBViAoRW5kIG9mIEFjdGl2ZSBWaWRlbykgbWFya2VycyBvZiB0aGUg c2VyaWFsIGRpZ2l0YWwgaW50ZXJmYWNlDQoweEZGQzogSG9yaXpvbnRhbCBvZmZzZXQgaXMgbGFy Z2VyIHRoYW4gY2FuIGJlIHJlcHJlc2VudGVkIGluIHRoZSAxMiBiaXRzIG9mIHRoaXMgZmllbGQg KGlmIG5lZWRlZCBmb3IgZnV0dXJlIGZvcm1hdHMsIG9yIGZvciBjZXJ0YWluIGxvdyBmcmFtZSBy YXRlIDcyMHAgZm9ybWF0cykNCg0KVGhpcyBtZXRob2RvbG9neSB3b3VsZCBjb2RlIHRoZSBtb3N0 IGltcG9ydGFudCBnZW5lcmljIHVzZSBjYXNlczoNCg0K4oCcVkFOQyBTcGFjZSBhZnRlciAybmQg bGluZSBhZnRlciBSUCAxNjjigJ0gTGluZV9udW1iZXI6IDB4N0ZFICwgSG9yaXpvbnRhbF9PZmZz ZXQgMHhGRkQgW21vc3QgVkFOQyBmb3JtYXRzXQ0K4oCcSEFOQyBTcGFjZSBhZnRlciAybmQgbGlu ZSBhZnRlciBSUCAxNjjigJ0gTGluZV9OdW1iZXI6IDB4N0ZFLCBIb3Jpem9udGFsX09mZnNldCAw eEZGRSBbZS5nLiBTTVBURSBTVCAxMi0yIEFUQywgU1QgMjA1MSBUd28gRnJhbWUgTWFya2VyIGlu IEhBTkNdDQrigJxIQU5DIFNwYWNlIChhbnkgbGluZSnigJ06IExpbmVfTnVtYmVyOiAweDdGRiwg SG9yaXpvbnRhbF9PZmZzZXQ6IDB4RkZFIFtlLmcuIFNNUFRFIFJQMjE0IEtMViBNZXRhZGF0YSB0 cmFuc3BvcnQgaW4gSEFOQyBzcGFjZV0NCuKAnG5vdCB0aWVkIHRvIGxvY2F0aW9uIGluIFNESSBy YXN0ZXIgYXQgYWxs4oCdOiBMaW5lX051bWJlcjogMHg3RkYsIEhvcml6b250YWxfT2Zmc2V0OiAw eEZGRiBbZS5nLiBhbGwtSVAgc3lzdGVtcyBpbiB0aGUgZnV0dXJlXQ0KDQpJIGFtIGN1cnJlbnRs eSBjb29yZGluYXRpbmcgd2l0aCBzdWJqZWN0IG1hdHRlciBleHBlcnRzIHdpdGhpbiBTTVBURSBh bmQgdGhlIEFsbGlhbmNlIGZvciBJUCBNZWRpYSBTb2x1dGlvbnMgKEFJTVMpIHRvIGNvbmZpcm0g dGhlc2UgY29kZSB2YWx1ZXMuDQoNCkkgaG9wZSB0byBoYXZlIGEgY29uZmlybWF0aW9uIG9mIHRo ZXNlIGNvZGUgdmFsdWVzIGJ5IHRoZSBlbmQgb2YgbmV4dCB3ZWVrLCBhdCB3aGljaCB0aW1lIEkg Y2FuIGlzc3VlIGEgLTEzIHZlcnNpb24gb2YgdGhlIGRyYWZ0IGlmIHRoZSBXRyBhcHByb3Zlcy4N Cg0KKE5vdGU6IEluIHN1Y2ggYSBkcmFmdCwgSSB3b3VsZCBwcm9iYWJseSBicmluZyBvdXQgdGhl c2Ugc3BlY2lhbCBjb2RlcyBhcyB0YWJsZXMgcmF0aGVyIHRoYW4gdGhlIGN1cnJlbnQgdGV4dCB0 byBtYWtlIHRoZW0gbW9yZSByZWFkYWJsZS4pDQoNCi1UaG9tYXMNCg0KLS0NClRob21hcyBFZHdh cmRzDQpGT1ggTmV0d29ya3MgRW5naW5lZXJpbmcgJiBPcGVyYXRpb25zDQpWUCBFbmdpbmVlcmlu ZyAmIERldmVsb3BtZW50DQp0aG9tYXMuZWR3YXJkc0Bmb3guY29tDQorMS0zMTAtMzY5LTY2OTYN CjEwMjAxIFcgUGljbyBCbHZkDQpMb3MgQW5nZWxlcywgQ0EgOTAwMzUNCg== --_000_F03678D1E2554381BA1FCAB227451663foxegcom_ Content-Type: text/html; charset="utf-8" Content-ID: <5F44EF5119E01D40A73321722CFB9A28@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29t cG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1z dHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxi b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5EZWFyIElFVEYgUGF5bG9hZCBXRyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPldoaWxlIGRyYWZ0LWlldGYt cGF5bG9hZC1ydHAtYW5jaWxsYXJ5LTEyIHdhcyBpbiB0aGUgUkZDIEVkaXRvciBRdWV1ZSwgYSBw cm9ibGVtIGluIHRoZSBkb2N1bWVudCB3YXMgYnJvdWdodCB0byBteSBhdHRlbnRpb24uJm5ic3A7 IEkgaGF2ZSByZXF1ZXN0ZWQgdGhhdCB0aGUgZG9jdW1lbnQgYmUgcGF1c2VkIGluIHRoZSBSRkMg RWRpdG9yIFF1ZXVlIGZvciBJRVNHDQogYWN0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+VGhlIGRyYWZ0IGN1cnJlbnRseSBzdGF0ZXMgb2YgdGhlIOKAnExp bmVfTnVtYmVy4oCdIGZpZWxkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnEEgdmFsdWUgb2YgMHg3 RkUgaW5kaWNhdGVzIHRoYXQgdGhlIEFOQyBkYXRhIGlzIGludGVuZGVkIHRvIGJlIHBsYWNlZCBp bnRvIGFueSBsZWdhbCBhcmVhIG9mIHRoZSB2ZXJ0aWNhbCBibGFua2luZyBwZXJpb2QgKCZxdW90 O1ZBTkMgZGF0YSBzcGFjZSZxdW90OyksIHNwZWNpZmljYWxseS7igJ08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFzIHdlIGtub3csIOKAnGFueSBsZWdhbCBhcmVh IG9mIHRoZSB2ZXJ0aWNhbCBibGFua2luZyBwZXJpb2TigJ0gaXMgbm90IOKAnFZBTkMgZGF0YSBz cGFjZeKAnSBhcyBkZWZpbmVkIGluIFNNUFRFIFNUIDI5MS0xLCBzbyB0aGlzIHN0YXRlbWVudCBp cyBpbmNvcnJlY3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5J IGJyaWVmbHkgY29uc2lkZXJlZCBhc2tpbmcgdGhlIFJGQyBFZGl0b3IgdG8gc2ltcGx5IHJlbW92 ZSB0aGUgcGFyZW50aGV0aWNhbCBzdGF0ZW1lbnQuJm5ic3A7IEJ1dCB0d28gcHJvYmxlbXMgc3By dW5nIHVwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Rmlyc3Qs IHdlIGRvbuKAmXQgaGF2ZSBhIEhvcml6b250YWxfT2Zmc2V0IGNvZGUgZm9yIHBsYWNpbmcgYSBw YWNrZXQgaG9yaXpvbnRhbGx5IGFueXdoZXJlIGluIHRoZSBWQU5DIHNwYWNlIChpLmUuIGJldHdl ZW4gU0FWIGFuZCBFQVYpLiZuYnNwOyZuYnNwOyBXZSBkbyBoYXZlIGEgSG9yaXpvbnRhbF9PZmZz ZXQgY29kZSBmb3IgYW55d2hlcmUgaW4gSEFOQyBzcGFjZSB0aG91Z2guPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5CdXQgYSBiaWdnZXIgcHJvYmxlbSBpcyB0aGF0 IGEgZ2VuZXJpYyBjb2RlIGZvciBBTkMgZGF0YSBvbiBhbnkgbGluZSBpbiB0aGUgdmVydGljYWwg aW50ZXJ2YWwgaXMgYWN0dWFsbHkgYSBCQUQgaWRlYS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPkltYWdpbmUgYW4gU0RJIHRvIElQIGNvbnZlcnRlciB0YWtpbmcg YSBWQU5DIHBhY2tldCBmcm9tIGJlbG93IHRoZSBSUCAxNjggc3dpdGNoIHBvaW50LCBjb2Rpbmcg aXQgYXMgTGluZV9OdW1iZXIgMHg3RkUsIHRoZW4gYW4gSVAgdG8gU0RJIGNvbnZlcnRlciBwbGFj aW5nIHRoYXQgcGFja2V0IGluIGEgbGluZSBhYm92ZSB0aGUgUlAgMTY4IHN3aXRjaCBwb2ludC4m bmJzcDsNCiBUaGVuIGFuIFNESSBzd2l0Y2ggb2NjdXJzLCBhbmQgdGhhdCBWQU5DIHBhY2tldCBp cyBubyBsb25nZXIgYXR0YWNoZWQgdG8gaXRzIGNvcnJlc3BvbmRpbmcgYWN0aXZlIHZpZGVvIGZy YW1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QWZ0 ZXIgc3VydmV5aW5nIGFsbCBub24tYXVkaW8gQU5DIGRhdGEgc3RhbmRhcmRzIGFuZCB0aGVpciBw cmVmZXJyZWQgbG9jYXRpb25zLCBJIHByb3Bvc2UgdGhlIGZvbGxvd2luZyBzb2x1dGlvbiBmb3Ig dGhlIHNwZWNpYWwgdmFsdWVzIHRoYXQgY29kZSBmb3IgdGhlIGxvY2F0aW9uIG9mIHRoZSBBTkMg ZGF0YSBwYWNrZXQgdG8gYmUgaW4gY2VydGFpbiBnZW5lcmljDQogdmVydGljYWwgcmVnaW9ucyBv ZiB0aGUgU0RJIHJhc3Rlci4mbmJzcDsgRm9yIExpbmVfTnVtYmVyOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+MHg3RkY6IFdpdGhvdXQgc3BlY2lmaWMgbGluZSBs b2NhdGlvbiB3aXRoaW4gdGhlIGZpZWxkIG9yIGZyYW1lPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjB4N0ZF OiBPbiBhbnkgbGluZSBpbiB0aGUgcmFuZ2UgZnJvbSB0aGUgc2Vjb25kIGxpbmUgYWZ0ZXIgdGhl IGxpbmUgc3BlY2lmaWVkIGZvciBzd2l0Y2hpbmcsIGFzIGRlZmluZWQgaW4gU01QVEUgUlAgMTY4 LCB0byB0aGUgbGFzdCBsaW5lIGJlZm9yZSBhY3RpdmUgdmlkZW8sIGluY2x1c2l2ZSZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjB4 N0ZEOiBPbiBhIGxpbmUgbnVtYmVyIGxhcmdlciB0aGFuIGNhbiBiZSByZXByZXNlbnRlZCBpbiAx MSBiaXRzIG9mIHRoaXMgZmllbGQgKGlmIG5lZWRlZCBmb3IgZnV0dXJlIGZvcm1hdHMpJm5ic3A7 Jm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFuZCBz aW1pbGFybHksIGZvciBIb3Jpem9udGFsX09mZnNldDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjB4RkZGOiBXaXRob3V0IHNwZWNpZmljIGhvcml6b250YWwgbG9j YXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+MHhGRkU6IFdpdGhpbiBob3Jpem9udGFsIGFuY2lsbGFy eSBkYXRhIHNwYWNlIChIQU5DKSBhcyBkZWZpbmVkIGluIFNNUFRFIFNUIDI5MS0xPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjB4RkZEOiBXaXRoaW4gdGhlIGFuY2lsbGFyeSBkYXRhIHNwYWNlIGxvY2F0ZWQg YmV0d2VlbiBTQVYgKFN0YXJ0IG9mIEFjdGl2ZSBWaWRlbykgYW5kIEVBViAoRW5kIG9mIEFjdGl2 ZSBWaWRlbykgbWFya2VycyBvZiB0aGUgc2VyaWFsIGRpZ2l0YWwgaW50ZXJmYWNlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjB4RkZDOiBIb3Jpem9udGFsIG9mZnNldCBpcyBsYXJnZXIgdGhhbiBjYW4gYmUg cmVwcmVzZW50ZWQgaW4gdGhlIDEyIGJpdHMgb2YgdGhpcyBmaWVsZCAoaWYgbmVlZGVkIGZvciBm dXR1cmUgZm9ybWF0cywgb3IgZm9yIGNlcnRhaW4gbG93IGZyYW1lIHJhdGUgNzIwcCBmb3JtYXRz KSZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGlz IG1ldGhvZG9sb2d5IHdvdWxkIGNvZGUgdGhlIG1vc3QgaW1wb3J0YW50IGdlbmVyaWMgdXNlIGNh c2VzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+4oCcVkFOQyBT cGFjZSBhZnRlciAybmQgbGluZSBhZnRlciBSUCAxNjjigJ0gTGluZV9udW1iZXI6IDB4N0ZFICwg SG9yaXpvbnRhbF9PZmZzZXQgMHhGRkQgW21vc3QgVkFOQyBmb3JtYXRzXTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij7igJxIQU5DIFNwYWNlIGFmdGVyIDJuZCBsaW5lIGFmdGVyIFJQIDE2OOKAnSBMaW5lX051 bWJlcjogMHg3RkUsIEhvcml6b250YWxfT2Zmc2V0IDB4RkZFIFtlLmcuIFNNUFRFIFNUIDEyLTIg QVRDLCBTVCAyMDUxIFR3byBGcmFtZSBNYXJrZXIgaW4gSEFOQ108bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ 4oCcSEFOQyBTcGFjZSAoYW55IGxpbmUp4oCdOiBMaW5lX051bWJlcjogMHg3RkYsIEhvcml6b250 YWxfT2Zmc2V0OiAweEZGRSBbZS5nLiBTTVBURSBSUDIxNCBLTFYgTWV0YWRhdGEgdHJhbnNwb3J0 IGluIEhBTkMgc3BhY2VdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuKAnG5vdCB0aWVkIHRvIGxvY2F0aW9u IGluIFNESSByYXN0ZXIgYXQgYWxs4oCdOiBMaW5lX051bWJlcjogMHg3RkYsIEhvcml6b250YWxf T2Zmc2V0OiAweEZGRiBbZS5nLiBhbGwtSVAgc3lzdGVtcyBpbiB0aGUgZnV0dXJlXTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SSBhbSBjdXJyZW50bHkgY29vcmRp bmF0aW5nIHdpdGggc3ViamVjdCBtYXR0ZXIgZXhwZXJ0cyB3aXRoaW4gU01QVEUgYW5kIHRoZSBB bGxpYW5jZSBmb3IgSVAgTWVkaWEgU29sdXRpb25zIChBSU1TKSB0byBjb25maXJtIHRoZXNlIGNv ZGUgdmFsdWVzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5J IGhvcGUgdG8gaGF2ZSBhIGNvbmZpcm1hdGlvbiBvZiB0aGVzZSBjb2RlIHZhbHVlcyBieSB0aGUg ZW5kIG9mIG5leHQgd2VlaywgYXQgd2hpY2ggdGltZSBJIGNhbiBpc3N1ZSBhIC0xMyB2ZXJzaW9u IG9mIHRoZSBkcmFmdCBpZiB0aGUgV0cgYXBwcm92ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij4oTm90ZTogSW4gc3VjaCBhIGRyYWZ0LCBJIHdvdWxkIHByb2Jh Ymx5IGJyaW5nIG91dCB0aGVzZSBzcGVjaWFsIGNvZGVzIGFzIHRhYmxlcyByYXRoZXIgdGhhbiB0 aGUgY3VycmVudCB0ZXh0IHRvIG1ha2UgdGhlbSBtb3JlIHJlYWRhYmxlLik8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi1UaG9tYXM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi0tJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5UaG9tYXMgRWR3YXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5GT1ggTmV0d29ya3MgRW5naW5lZXJp bmcgJmFtcDsgT3BlcmF0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5WUCBFbmdpbmVlcmluZyAmYW1w OyBEZXZlbG9wbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij50aG9tYXMuZWR3YXJkc0Bmb3guY29tPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPiYjNDM7MS0zMTAtMzY5LTY2OTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+MTAy MDEgVyBQaWNvIEJsdmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Mb3MgQW5nZWxlcywgQ0Eg OTAwMzU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F03678D1E2554381BA1FCAB227451663foxegcom_-- From nobody Sun Dec 3 01:37:22 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 0C4C9124239 for ; Sun, 3 Dec 2017 01:37:21 -0800 (PST) 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, HTML_MESSAGE=0.001, 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 TCziXWsppEaP for ; Sun, 3 Dec 2017 01:37:18 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 2F2F21201F2 for ; Sun, 3 Dec 2017 01:37:18 -0800 (PST) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 9103EEF39EF15 for ; Sun, 3 Dec 2017 09:37:13 +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.361.1; Sun, 3 Dec 2017 09:37:15 +0000 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.14]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0361.001; Sun, 3 Dec 2017 17:37:10 +0800 From: Roni Even To: Thomas Edwards , "payload@ietf.org" Thread-Topic: Issues with draft-ietf-payload-rtp-ancillary-12 Thread-Index: AQHTawpT39dohZ/yJEOUMPaW1lg34aMxWOpw Date: Sun, 3 Dec 2017 09:37:10 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD84FDB5@DGGEMM506-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.203.55] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD84FDB5DGGEMM506MBSchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [payload] Issues with draft-ietf-payload-rtp-ancillary-12 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, 03 Dec 2017 09:37:21 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD84FDB5DGGEMM506MBSchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGhvbWFzLA0KSSByZWFkIHRoaXMgcHJvcG9zYWwNCkkgdW5kZXJzdGFuZCB0aGF0IHRoZSBt YWpvciBjaGFuZ2UgaXMgdGhlIGRlZmluaXRpb24gb2YgdGhlIG1ldGhvZG9sb2d5Og0KDQoNClRo aXMgbWV0aG9kb2xvZ3kgd291bGQgY29kZSB0aGUgbW9zdCBpbXBvcnRhbnQgZ2VuZXJpYyB1c2Ug Y2FzZXM6DQoNCuKAnFZBTkMgU3BhY2UgYWZ0ZXIgMm5kIGxpbmUgYWZ0ZXIgUlAgMTY44oCdIExp bmVfbnVtYmVyOiAweDdGRSAsIEhvcml6b250YWxfT2Zmc2V0IDB4RkZEIFttb3N0IFZBTkMgZm9y bWF0c10NCuKAnEhBTkMgU3BhY2UgYWZ0ZXIgMm5kIGxpbmUgYWZ0ZXIgUlAgMTY44oCdIExpbmVf TnVtYmVyOiAweDdGRSwgSG9yaXpvbnRhbF9PZmZzZXQgMHhGRkUgW2UuZy4gU01QVEUgU1QgMTIt MiBBVEMsIFNUIDIwNTEgVHdvIEZyYW1lIE1hcmtlciBpbiBIQU5DXQ0K4oCcSEFOQyBTcGFjZSAo YW55IGxpbmUp4oCdOiBMaW5lX051bWJlcjogMHg3RkYsIEhvcml6b250YWxfT2Zmc2V0OiAweEZG RSBbZS5nLiBTTVBURSBSUDIxNCBLTFYgTWV0YWRhdGEgdHJhbnNwb3J0IGluIEhBTkMgc3BhY2Vd DQrigJxub3QgdGllZCB0byBsb2NhdGlvbiBpbiBTREkgcmFzdGVyIGF0IGFsbOKAnTogTGluZV9O dW1iZXI6IDB4N0ZGLCBIb3Jpem9udGFsX09mZnNldDogMHhGRkYgW2UuZy4gYWxsLUlQIHN5c3Rl bXMgaW4gdGhlIGZ1dHVyZV0NCg0KDQpNeSByZWNvbW1lbmRhdGlvbiBpcyB0aGF0IG9uY2UgeW91 IGRlY2lkZSBvbiB0aGUgY29ycmVjdCB0ZXh0IGl0IHdpbGwgaGVscCB1cyBpZiB3ZSBnZXQgZmVl ZGJhY2sgZnJvbSBvdGhlciBtZW1iZXJzIG9mIFNNUFRFIHRvIHRoZSBwYXlsb2FkIG1haWxpbmcg bGlzdCB0aGF0IHRoaXMgbWV0aG9kb2xvZ3kgaXMgdGhlIGNvcnJlY3Qgb25lLg0KDQpUaGFuaw0K Um9uaSBFdmVuDQpQYXlsb2FkIEcgY28tY2hhaXINCg0KRnJvbTogcGF5bG9hZCBbbWFpbHRvOnBh eWxvYWQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRob21hcyBFZHdhcmRzDQpTZW50 OiDXqdeR16ogMDIg15PXptee15HXqCAyMDE3IDAzOjEwDQpUbzogcGF5bG9hZEBpZXRmLm9yZw0K U3ViamVjdDogW3BheWxvYWRdIElzc3VlcyB3aXRoIGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtYW5j aWxsYXJ5LTEyDQoNCkRlYXIgSUVURiBQYXlsb2FkIFdHLA0KDQpXaGlsZSBkcmFmdC1pZXRmLXBh eWxvYWQtcnRwLWFuY2lsbGFyeS0xMiB3YXMgaW4gdGhlIFJGQyBFZGl0b3IgUXVldWUsIGEgcHJv YmxlbSBpbiB0aGUgZG9jdW1lbnQgd2FzIGJyb3VnaHQgdG8gbXkgYXR0ZW50aW9uLiAgSSBoYXZl IHJlcXVlc3RlZCB0aGF0IHRoZSBkb2N1bWVudCBiZSBwYXVzZWQgaW4gdGhlIFJGQyBFZGl0b3Ig UXVldWUgZm9yIElFU0cgYWN0aW9uLg0KDQpUaGUgZHJhZnQgY3VycmVudGx5IHN0YXRlcyBvZiB0 aGUg4oCcTGluZV9OdW1iZXLigJ0gZmllbGQ6DQoNCiAgICAgICAgICAgICAgICDigJxBIHZhbHVl IG9mIDB4N0ZFIGluZGljYXRlcyB0aGF0IHRoZSBBTkMgZGF0YSBpcyBpbnRlbmRlZCB0byBiZSBw bGFjZWQgaW50byBhbnkgbGVnYWwgYXJlYSBvZiB0aGUgdmVydGljYWwgYmxhbmtpbmcgcGVyaW9k ICgiVkFOQyBkYXRhIHNwYWNlIiksIHNwZWNpZmljYWxseS7igJ0NCg0KQXMgd2Uga25vdywg4oCc YW55IGxlZ2FsIGFyZWEgb2YgdGhlIHZlcnRpY2FsIGJsYW5raW5nIHBlcmlvZOKAnSBpcyBub3Qg 4oCcVkFOQyBkYXRhIHNwYWNl4oCdIGFzIGRlZmluZWQgaW4gU01QVEUgU1QgMjkxLTEsIHNvIHRo aXMgc3RhdGVtZW50IGlzIGluY29ycmVjdC4NCg0KSSBicmllZmx5IGNvbnNpZGVyZWQgYXNraW5n IHRoZSBSRkMgRWRpdG9yIHRvIHNpbXBseSByZW1vdmUgdGhlIHBhcmVudGhldGljYWwgc3RhdGVt ZW50LiAgQnV0IHR3byBwcm9ibGVtcyBzcHJ1bmcgdXAuDQoNCkZpcnN0LCB3ZSBkb27igJl0IGhh dmUgYSBIb3Jpem9udGFsX09mZnNldCBjb2RlIGZvciBwbGFjaW5nIGEgcGFja2V0IGhvcml6b250 YWxseSBhbnl3aGVyZSBpbiB0aGUgVkFOQyBzcGFjZSAoaS5lLiBiZXR3ZWVuIFNBViBhbmQgRUFW KS4gICBXZSBkbyBoYXZlIGEgSG9yaXpvbnRhbF9PZmZzZXQgY29kZSBmb3IgYW55d2hlcmUgaW4g SEFOQyBzcGFjZSB0aG91Z2guDQoNCkJ1dCBhIGJpZ2dlciBwcm9ibGVtIGlzIHRoYXQgYSBnZW5l cmljIGNvZGUgZm9yIEFOQyBkYXRhIG9uIGFueSBsaW5lIGluIHRoZSB2ZXJ0aWNhbCBpbnRlcnZh bCBpcyBhY3R1YWxseSBhIEJBRCBpZGVhLg0KDQpJbWFnaW5lIGFuIFNESSB0byBJUCBjb252ZXJ0 ZXIgdGFraW5nIGEgVkFOQyBwYWNrZXQgZnJvbSBiZWxvdyB0aGUgUlAgMTY4IHN3aXRjaCBwb2lu dCwgY29kaW5nIGl0IGFzIExpbmVfTnVtYmVyIDB4N0ZFLCB0aGVuIGFuIElQIHRvIFNESSBjb252 ZXJ0ZXIgcGxhY2luZyB0aGF0IHBhY2tldCBpbiBhIGxpbmUgYWJvdmUgdGhlIFJQIDE2OCBzd2l0 Y2ggcG9pbnQuICBUaGVuIGFuIFNESSBzd2l0Y2ggb2NjdXJzLCBhbmQgdGhhdCBWQU5DIHBhY2tl dCBpcyBubyBsb25nZXIgYXR0YWNoZWQgdG8gaXRzIGNvcnJlc3BvbmRpbmcgYWN0aXZlIHZpZGVv IGZyYW1lLg0KDQpBZnRlciBzdXJ2ZXlpbmcgYWxsIG5vbi1hdWRpbyBBTkMgZGF0YSBzdGFuZGFy ZHMgYW5kIHRoZWlyIHByZWZlcnJlZCBsb2NhdGlvbnMsIEkgcHJvcG9zZSB0aGUgZm9sbG93aW5n IHNvbHV0aW9uIGZvciB0aGUgc3BlY2lhbCB2YWx1ZXMgdGhhdCBjb2RlIGZvciB0aGUgbG9jYXRp b24gb2YgdGhlIEFOQyBkYXRhIHBhY2tldCB0byBiZSBpbiBjZXJ0YWluIGdlbmVyaWMgdmVydGlj YWwgcmVnaW9ucyBvZiB0aGUgU0RJIHJhc3Rlci4gIEZvciBMaW5lX051bWJlcjoNCg0KMHg3RkY6 IFdpdGhvdXQgc3BlY2lmaWMgbGluZSBsb2NhdGlvbiB3aXRoaW4gdGhlIGZpZWxkIG9yIGZyYW1l DQoweDdGRTogT24gYW55IGxpbmUgaW4gdGhlIHJhbmdlIGZyb20gdGhlIHNlY29uZCBsaW5lIGFm dGVyIHRoZSBsaW5lIHNwZWNpZmllZCBmb3Igc3dpdGNoaW5nLCBhcyBkZWZpbmVkIGluIFNNUFRF IFJQIDE2OCwgdG8gdGhlIGxhc3QgbGluZSBiZWZvcmUgYWN0aXZlIHZpZGVvLCBpbmNsdXNpdmUN CjB4N0ZEOiBPbiBhIGxpbmUgbnVtYmVyIGxhcmdlciB0aGFuIGNhbiBiZSByZXByZXNlbnRlZCBp biAxMSBiaXRzIG9mIHRoaXMgZmllbGQgKGlmIG5lZWRlZCBmb3IgZnV0dXJlIGZvcm1hdHMpDQoN CkFuZCBzaW1pbGFybHksIGZvciBIb3Jpem9udGFsX09mZnNldDoNCg0KMHhGRkY6IFdpdGhvdXQg c3BlY2lmaWMgaG9yaXpvbnRhbCBsb2NhdGlvbg0KMHhGRkU6IFdpdGhpbiBob3Jpem9udGFsIGFu Y2lsbGFyeSBkYXRhIHNwYWNlIChIQU5DKSBhcyBkZWZpbmVkIGluIFNNUFRFIFNUIDI5MS0xDQow eEZGRDogV2l0aGluIHRoZSBhbmNpbGxhcnkgZGF0YSBzcGFjZSBsb2NhdGVkIGJldHdlZW4gU0FW IChTdGFydCBvZiBBY3RpdmUgVmlkZW8pIGFuZCBFQVYgKEVuZCBvZiBBY3RpdmUgVmlkZW8pIG1h cmtlcnMgb2YgdGhlIHNlcmlhbCBkaWdpdGFsIGludGVyZmFjZQ0KMHhGRkM6IEhvcml6b250YWwg b2Zmc2V0IGlzIGxhcmdlciB0aGFuIGNhbiBiZSByZXByZXNlbnRlZCBpbiB0aGUgMTIgYml0cyBv ZiB0aGlzIGZpZWxkIChpZiBuZWVkZWQgZm9yIGZ1dHVyZSBmb3JtYXRzLCBvciBmb3IgY2VydGFp biBsb3cgZnJhbWUgcmF0ZSA3MjBwIGZvcm1hdHMpDQoNClRoaXMgbWV0aG9kb2xvZ3kgd291bGQg Y29kZSB0aGUgbW9zdCBpbXBvcnRhbnQgZ2VuZXJpYyB1c2UgY2FzZXM6DQoNCuKAnFZBTkMgU3Bh Y2UgYWZ0ZXIgMm5kIGxpbmUgYWZ0ZXIgUlAgMTY44oCdIExpbmVfbnVtYmVyOiAweDdGRSAsIEhv cml6b250YWxfT2Zmc2V0IDB4RkZEIFttb3N0IFZBTkMgZm9ybWF0c10NCuKAnEhBTkMgU3BhY2Ug YWZ0ZXIgMm5kIGxpbmUgYWZ0ZXIgUlAgMTY44oCdIExpbmVfTnVtYmVyOiAweDdGRSwgSG9yaXpv bnRhbF9PZmZzZXQgMHhGRkUgW2UuZy4gU01QVEUgU1QgMTItMiBBVEMsIFNUIDIwNTEgVHdvIEZy YW1lIE1hcmtlciBpbiBIQU5DXQ0K4oCcSEFOQyBTcGFjZSAoYW55IGxpbmUp4oCdOiBMaW5lX051 bWJlcjogMHg3RkYsIEhvcml6b250YWxfT2Zmc2V0OiAweEZGRSBbZS5nLiBTTVBURSBSUDIxNCBL TFYgTWV0YWRhdGEgdHJhbnNwb3J0IGluIEhBTkMgc3BhY2VdDQrigJxub3QgdGllZCB0byBsb2Nh dGlvbiBpbiBTREkgcmFzdGVyIGF0IGFsbOKAnTogTGluZV9OdW1iZXI6IDB4N0ZGLCBIb3Jpem9u dGFsX09mZnNldDogMHhGRkYgW2UuZy4gYWxsLUlQIHN5c3RlbXMgaW4gdGhlIGZ1dHVyZV0NCg0K SSBhbSBjdXJyZW50bHkgY29vcmRpbmF0aW5nIHdpdGggc3ViamVjdCBtYXR0ZXIgZXhwZXJ0cyB3 aXRoaW4gU01QVEUgYW5kIHRoZSBBbGxpYW5jZSBmb3IgSVAgTWVkaWEgU29sdXRpb25zIChBSU1T KSB0byBjb25maXJtIHRoZXNlIGNvZGUgdmFsdWVzLg0KDQpJIGhvcGUgdG8gaGF2ZSBhIGNvbmZp cm1hdGlvbiBvZiB0aGVzZSBjb2RlIHZhbHVlcyBieSB0aGUgZW5kIG9mIG5leHQgd2VlaywgYXQg d2hpY2ggdGltZSBJIGNhbiBpc3N1ZSBhIC0xMyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBpZiB0aGUg V0cgYXBwcm92ZXMuDQoNCihOb3RlOiBJbiBzdWNoIGEgZHJhZnQsIEkgd291bGQgcHJvYmFibHkg YnJpbmcgb3V0IHRoZXNlIHNwZWNpYWwgY29kZXMgYXMgdGFibGVzIHJhdGhlciB0aGFuIHRoZSBj dXJyZW50IHRleHQgdG8gbWFrZSB0aGVtIG1vcmUgcmVhZGFibGUuKQ0KDQotVGhvbWFzDQoNCi0t DQpUaG9tYXMgRWR3YXJkcw0KRk9YIE5ldHdvcmtzIEVuZ2luZWVyaW5nICYgT3BlcmF0aW9ucw0K VlAgRW5naW5lZXJpbmcgJiBEZXZlbG9wbWVudA0KdGhvbWFzLmVkd2FyZHNAZm94LmNvbTxtYWls dG86dGhvbWFzLmVkd2FyZHNAZm94LmNvbT4NCisxLTMxMC0zNjktNjY5Ng0KMTAyMDEgVyBQaWNv IEJsdmQNCkxvcyBBbmdlbGVzLCBDQSA5MDAzNQ0K --_000_6E58094ECC8D8344914996DAD28F1CCD84FDB5DGGEMM506MBSchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1 NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3 MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPkhpIFRob21hcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5JIHJlYWQgdGhpcyBwcm9wb3NhbA0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+SSB1bmRlcnN0YW5kIHRoYXQgdGhlIG1ham9y IGNoYW5nZSBpcyB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgbWV0aG9kb2xvZ3k6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoaXMgbWV0aG9kb2xvZ3kgd291bGQgY29kZSB0 aGUgbW9zdCBpbXBvcnRhbnQgZ2VuZXJpYyB1c2UgY2FzZXM6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij7igJxWQU5DIFNwYWNlIGFmdGVyIDJuZCBsaW5lIGFmdGVy IFJQIDE2OOKAnSBMaW5lX251bWJlcjogMHg3RkUgLCBIb3Jpem9udGFsX09mZnNldCAweEZGRCBb bW9zdCBWQU5DIGZvcm1hdHNdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuKAnEhBTkMgU3BhY2UgYWZ0ZXIg Mm5kIGxpbmUgYWZ0ZXIgUlAgMTY44oCdIExpbmVfTnVtYmVyOiAweDdGRSwgSG9yaXpvbnRhbF9P ZmZzZXQgMHhGRkUgW2UuZy4gU01QVEUgU1QgMTItMiBBVEMsIFNUIDIwNTEgVHdvIEZyYW1lIE1h cmtlciBpbiBIQU5DXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7igJxIQU5DIFNwYWNlIChhbnkgbGluZSni gJ06IExpbmVfTnVtYmVyOiAweDdGRiwgSG9yaXpvbnRhbF9PZmZzZXQ6IDB4RkZFIFtlLmcuIFNN UFRFIFJQMjE0IEtMViBNZXRhZGF0YSB0cmFuc3BvcnQgaW4gSEFOQyBzcGFjZV08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+4oCcbm90IHRpZWQgdG8gbG9jYXRpb24gaW4gU0RJIHJhc3RlciBhdCBhbGzigJ06 IExpbmVfTnVtYmVyOiAweDdGRiwgSG9yaXpvbnRhbF9PZmZzZXQ6IDB4RkZGIFtlLmcuIGFsbC1J UCBzeXN0ZW1zIGluIHRoZSBmdXR1cmVdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6IzFGNDk3RCI+TXkgcmVjb21tZW5kYXRpb24gaXMgdGhhdCBvbmNlIHlvdSBk ZWNpZGUgb24gdGhlIGNvcnJlY3QgdGV4dCBpdCB3aWxsIGhlbHAgdXMgaWYgd2UgZ2V0IGZlZWRi YWNrIGZyb20gb3RoZXIgbWVtYmVycyBvZiBTTVBURSB0byB0aGUgcGF5bG9hZCBtYWlsaW5nIGxp c3QgdGhhdCB0aGlzIG1ldGhvZG9sb2d5IGlzIHRoZSBjb3JyZWN0IG9uZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdE Ij5UaGFuayA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5Sb25pIEV2ZW48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5QYXlsb2FkIEcgY28tY2hhaXI8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBwYXlsb2FkIFttYWlsdG86cGF5bG9h ZC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5UaG9tYXMgRWR3YXJkczxi cj4NCjxiPlNlbnQ6PC9iPiA8c3BhbiBsYW5nPSJIRSIgZGlyPSJSVEwiPtep15HXqiAwMiDXk9em 157XkdeoIDIwMTcgMDM6MTA8L3NwYW4+PGJyPg0KPGI+VG86PC9iPiBwYXlsb2FkQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtwYXlsb2FkXSBJc3N1ZXMgd2l0aCBkcmFmdC1pZXRmLXBh eWxvYWQtcnRwLWFuY2lsbGFyeS0xMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5EZWFyIElFVEYgUGF5 bG9hZCBXRyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPldoaWxl IGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtYW5jaWxsYXJ5LTEyIHdhcyBpbiB0aGUgUkZDIEVkaXRv ciBRdWV1ZSwgYSBwcm9ibGVtIGluIHRoZSBkb2N1bWVudCB3YXMgYnJvdWdodCB0byBteSBhdHRl bnRpb24uJm5ic3A7IEkgaGF2ZSByZXF1ZXN0ZWQgdGhhdCB0aGUgZG9jdW1lbnQgYmUgcGF1c2Vk IGluIHRoZSBSRkMgRWRpdG9yIFF1ZXVlIGZvciBJRVNHDQogYWN0aW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhlIGRyYWZ0IGN1cnJlbnRseSBzdGF0ZXMg b2YgdGhlIOKAnExpbmVfTnVtYmVy4oCdIGZpZWxkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnEEg dmFsdWUgb2YgMHg3RkUgaW5kaWNhdGVzIHRoYXQgdGhlIEFOQyBkYXRhIGlzIGludGVuZGVkIHRv IGJlIHBsYWNlZCBpbnRvIGFueSBsZWdhbCBhcmVhIG9mIHRoZSB2ZXJ0aWNhbCBibGFua2luZyBw ZXJpb2QgKCZxdW90O1ZBTkMgZGF0YSBzcGFjZSZxdW90OyksIHNwZWNpZmljYWxseS7igJ08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFzIHdlIGtub3csIOKAnGFu eSBsZWdhbCBhcmVhIG9mIHRoZSB2ZXJ0aWNhbCBibGFua2luZyBwZXJpb2TigJ0gaXMgbm90IOKA nFZBTkMgZGF0YSBzcGFjZeKAnSBhcyBkZWZpbmVkIGluIFNNUFRFIFNUIDI5MS0xLCBzbyB0aGlz IHN0YXRlbWVudCBpcyBpbmNvcnJlY3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5JIGJyaWVmbHkgY29uc2lkZXJlZCBhc2tpbmcgdGhlIFJGQyBFZGl0b3IgdG8g c2ltcGx5IHJlbW92ZSB0aGUgcGFyZW50aGV0aWNhbCBzdGF0ZW1lbnQuJm5ic3A7IEJ1dCB0d28g cHJvYmxlbXMgc3BydW5nIHVwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+Rmlyc3QsIHdlIGRvbuKAmXQgaGF2ZSBhIEhvcml6b250YWxfT2Zmc2V0IGNvZGUgZm9y IHBsYWNpbmcgYSBwYWNrZXQgaG9yaXpvbnRhbGx5IGFueXdoZXJlIGluIHRoZSBWQU5DIHNwYWNl IChpLmUuIGJldHdlZW4gU0FWIGFuZCBFQVYpLiZuYnNwOyZuYnNwOyBXZSBkbyBoYXZlIGEgSG9y aXpvbnRhbF9PZmZzZXQgY29kZSBmb3IgYW55d2hlcmUgaW4gSEFOQyBzcGFjZSB0aG91Z2guPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5CdXQgYSBiaWdnZXIgcHJv YmxlbSBpcyB0aGF0IGEgZ2VuZXJpYyBjb2RlIGZvciBBTkMgZGF0YSBvbiBhbnkgbGluZSBpbiB0 aGUgdmVydGljYWwgaW50ZXJ2YWwgaXMgYWN0dWFsbHkgYSBCQUQgaWRlYS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkltYWdpbmUgYW4gU0RJIHRvIElQIGNvbnZl cnRlciB0YWtpbmcgYSBWQU5DIHBhY2tldCBmcm9tIGJlbG93IHRoZSBSUCAxNjggc3dpdGNoIHBv aW50LCBjb2RpbmcgaXQgYXMgTGluZV9OdW1iZXIgMHg3RkUsIHRoZW4gYW4gSVAgdG8gU0RJIGNv bnZlcnRlciBwbGFjaW5nIHRoYXQgcGFja2V0IGluIGEgbGluZSBhYm92ZSB0aGUgUlAgMTY4IHN3 aXRjaCBwb2ludC4mbmJzcDsNCiBUaGVuIGFuIFNESSBzd2l0Y2ggb2NjdXJzLCBhbmQgdGhhdCBW QU5DIHBhY2tldCBpcyBubyBsb25nZXIgYXR0YWNoZWQgdG8gaXRzIGNvcnJlc3BvbmRpbmcgYWN0 aXZlIHZpZGVvIGZyYW1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+QWZ0ZXIgc3VydmV5aW5nIGFsbCBub24tYXVkaW8gQU5DIGRhdGEgc3RhbmRhcmRz IGFuZCB0aGVpciBwcmVmZXJyZWQgbG9jYXRpb25zLCBJIHByb3Bvc2UgdGhlIGZvbGxvd2luZyBz b2x1dGlvbiBmb3IgdGhlIHNwZWNpYWwgdmFsdWVzIHRoYXQgY29kZSBmb3IgdGhlIGxvY2F0aW9u IG9mIHRoZSBBTkMgZGF0YSBwYWNrZXQgdG8gYmUgaW4gY2VydGFpbiBnZW5lcmljDQogdmVydGlj YWwgcmVnaW9ucyBvZiB0aGUgU0RJIHJhc3Rlci4mbmJzcDsgRm9yIExpbmVfTnVtYmVyOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+MHg3RkY6IFdpdGhvdXQgc3Bl Y2lmaWMgbGluZSBsb2NhdGlvbiB3aXRoaW4gdGhlIGZpZWxkIG9yIGZyYW1lPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjB4N0ZFOiBPbiBhbnkgbGluZSBpbiB0aGUgcmFuZ2UgZnJvbSB0aGUgc2Vjb25kIGxp bmUgYWZ0ZXIgdGhlIGxpbmUgc3BlY2lmaWVkIGZvciBzd2l0Y2hpbmcsIGFzIGRlZmluZWQgaW4g U01QVEUgUlAgMTY4LCB0byB0aGUgbGFzdCBsaW5lIGJlZm9yZSBhY3RpdmUgdmlkZW8sIGluY2x1 c2l2ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjB4N0ZEOiBPbiBhIGxpbmUgbnVtYmVyIGxhcmdlciB0aGFuIGNhbiBiZSByZXBy ZXNlbnRlZCBpbiAxMSBiaXRzIG9mIHRoaXMgZmllbGQgKGlmIG5lZWRlZCBmb3IgZnV0dXJlIGZv cm1hdHMpJm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPkFuZCBzaW1pbGFybHksIGZvciBIb3Jpem9udGFsX09mZnNldDo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjB4RkZGOiBXaXRob3V0IHNwZWNpZmljIGhv cml6b250YWwgbG9jYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+MHhGRkU6IFdpdGhpbiBob3Jpem9u dGFsIGFuY2lsbGFyeSBkYXRhIHNwYWNlIChIQU5DKSBhcyBkZWZpbmVkIGluIFNNUFRFIFNUIDI5 MS0xPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjB4RkZEOiBXaXRoaW4gdGhlIGFuY2lsbGFyeSBkYXRhIHNw YWNlIGxvY2F0ZWQgYmV0d2VlbiBTQVYgKFN0YXJ0IG9mIEFjdGl2ZSBWaWRlbykgYW5kIEVBViAo RW5kIG9mIEFjdGl2ZSBWaWRlbykgbWFya2VycyBvZiB0aGUgc2VyaWFsIGRpZ2l0YWwgaW50ZXJm YWNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjB4RkZDOiBIb3Jpem9udGFsIG9mZnNldCBpcyBsYXJnZXIg dGhhbiBjYW4gYmUgcmVwcmVzZW50ZWQgaW4gdGhlIDEyIGJpdHMgb2YgdGhpcyBmaWVsZCAoaWYg bmVlZGVkIGZvciBmdXR1cmUgZm9ybWF0cywgb3IgZm9yIGNlcnRhaW4gbG93IGZyYW1lIHJhdGUg NzIwcCBmb3JtYXRzKSZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5UaGlzIG1ldGhvZG9sb2d5IHdvdWxkIGNvZGUgdGhlIG1vc3QgaW1wb3J0YW50IGdl bmVyaWMgdXNlIGNhc2VzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+4oCcVkFOQyBTcGFjZSBhZnRlciAybmQgbGluZSBhZnRlciBSUCAxNjjigJ0gTGluZV9udW1i ZXI6IDB4N0ZFICwgSG9yaXpvbnRhbF9PZmZzZXQgMHhGRkQgW21vc3QgVkFOQyBmb3JtYXRzXTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij7igJxIQU5DIFNwYWNlIGFmdGVyIDJuZCBsaW5lIGFmdGVyIFJQIDE2 OOKAnSBMaW5lX051bWJlcjogMHg3RkUsIEhvcml6b250YWxfT2Zmc2V0IDB4RkZFIFtlLmcuIFNN UFRFIFNUIDEyLTIgQVRDLCBTVCAyMDUxIFR3byBGcmFtZSBNYXJrZXIgaW4gSEFOQ108bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+4oCcSEFOQyBTcGFjZSAoYW55IGxpbmUp4oCdOiBMaW5lX051bWJlcjogMHg3 RkYsIEhvcml6b250YWxfT2Zmc2V0OiAweEZGRSBbZS5nLiBTTVBURSBSUDIxNCBLTFYgTWV0YWRh dGEgdHJhbnNwb3J0IGluIEhBTkMgc3BhY2VdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuKAnG5vdCB0aWVk IHRvIGxvY2F0aW9uIGluIFNESSByYXN0ZXIgYXQgYWxs4oCdOiBMaW5lX051bWJlcjogMHg3RkYs IEhvcml6b250YWxfT2Zmc2V0OiAweEZGRiBbZS5nLiBhbGwtSVAgc3lzdGVtcyBpbiB0aGUgZnV0 dXJlXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SSBhbSBjdXJy ZW50bHkgY29vcmRpbmF0aW5nIHdpdGggc3ViamVjdCBtYXR0ZXIgZXhwZXJ0cyB3aXRoaW4gU01Q VEUgYW5kIHRoZSBBbGxpYW5jZSBmb3IgSVAgTWVkaWEgU29sdXRpb25zIChBSU1TKSB0byBjb25m aXJtIHRoZXNlIGNvZGUgdmFsdWVzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5JIGhvcGUgdG8gaGF2ZSBhIGNvbmZpcm1hdGlvbiBvZiB0aGVzZSBjb2RlIHZh bHVlcyBieSB0aGUgZW5kIG9mIG5leHQgd2VlaywgYXQgd2hpY2ggdGltZSBJIGNhbiBpc3N1ZSBh IC0xMyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBpZiB0aGUgV0cgYXBwcm92ZXMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4oTm90ZTogSW4gc3VjaCBhIGRyYWZ0LCBJ IHdvdWxkIHByb2JhYmx5IGJyaW5nIG91dCB0aGVzZSBzcGVjaWFsIGNvZGVzIGFzIHRhYmxlcyBy YXRoZXIgdGhhbiB0aGUgY3VycmVudCB0ZXh0IHRvIG1ha2UgdGhlbSBtb3JlIHJlYWRhYmxlLik8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi1UaG9tYXM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi0tJm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5UaG9tYXMgRWR3YXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5GT1ggTmV0d29y a3MgRW5naW5lZXJpbmcgJmFtcDsgT3BlcmF0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5WUCBFbmdp bmVlcmluZyAmYW1wOyBEZXZlbG9wbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48YSBocmVmPSJtYWls dG86dGhvbWFzLmVkd2FyZHNAZm94LmNvbSI+dGhvbWFzLmVkd2FyZHNAZm94LmNvbTwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+JiM0MzsxLTMxMC0zNjktNjY5NjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4xMDIw MSBXIFBpY28gQmx2ZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkxvcyBBbmdlbGVzLCBDQSA5 MDAzNTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_6E58094ECC8D8344914996DAD28F1CCD84FDB5DGGEMM506MBSchina_-- From nobody Sun Dec 3 14:06:56 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 786FD124BE8 for ; Sun, 3 Dec 2017 14:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] 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 ILaRQY1hYUxY for ; Sun, 3 Dec 2017 14:06:52 -0800 (PST) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 1BBB51200F1 for ; Sun, 3 Dec 2017 14:06:52 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id t1so8382893ite.5 for ; Sun, 03 Dec 2017 14:06:52 -0800 (PST) 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=O3iN73droHKinbn8OshSj0IR89NTTbCqzLWJ3XnHFt0=; b=vSDJ8A+Py0DO8UyDl7hpuUeA2MzPgQH3x/LKmXeyDaRq7Tmt1FRLmxBPJpQfNQpHhk GjuQ/qRL6O6qtWArjVFzeA7oSjG5WT4j47p7LzCgnXspB+eSAg23D/XWoEkRqo2gIq18 lfAIPYaHy09yZEn+0a6KyId1TEEznaI47YLWD+6ExCnk8eXC9Soh02qspxVCvVuRiW+b k4aX26w/ZKRIZ+ddl3WBjqnhOk4TURPJBggMiAX734+E9Vsf+0Rdd0OOxabL67drYUdp CY2IcXlHrLfXCWRBZ+nPli4M3X0z38GRo0EX8fiQMRuxCuruwfamePWYbHhcnmWKLGSl YQ7w== 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=O3iN73droHKinbn8OshSj0IR89NTTbCqzLWJ3XnHFt0=; b=ZOhzKTgZZ8763Rof4JCB0kJ9LYjUX5kHftl+RTHOE7P0rpIdgJBlLO+t8cXHEzoi/9 XNgxjTsw5Iua3bjDHOtlfXkvLJgkaj8AIWb+8QUkxkU1hfv2WfEn4JuEdmKjXj57Noaf nilzZlEihsiurX17fyaY6P6m9GNWYa3jFpN6nMvhgBuS/GvmrZdtztbPL26Z63Ocp2HR sF7MAUGdRp5IAYYOht2CQhb8VUI7Xp9rxGI3TpfooE5OHA5yaoPBIZRkSKCU0DvnRn70 K15u3cN0SW1qaHw91nxOD/ZWh6OPO5JpkjwdA2VQdUkK6Of41rE509JP2wZP/yB61JX2 gHuQ== X-Gm-Message-State: AKGB3mLfXhHSBxGTVLhl6pVJFTRebfuEyQdUkVIn+xr1Z9Um2wi9Sgwe sV80TWGwaYa+VKauuWAN1rQlfGYOq2tg3D44Wcc= X-Google-Smtp-Source: AGs4zMbkekO/Csi58PsA6sWYWxsmf4N7uhPsNKP9twozTmYO2kaB3/mtvfwQfuO48IMnRdSXEcUhlNWu78fXg8ikvOM= X-Received: by 10.36.40.194 with SMTP id h185mr11357075ith.101.1512338811300; Sun, 03 Dec 2017 14:06:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.157.14 with HTTP; Sun, 3 Dec 2017 14:06:50 -0800 (PST) In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD84FDB5@DGGEMM506-MBS.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD84FDB5@DGGEMM506-MBS.china.huawei.com> From: Kjetil Oftedal Date: Sun, 3 Dec 2017 23:06:50 +0100 Message-ID: To: Thomas Edwards Cc: "payload@ietf.org" , Roni Even Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [payload] Issues with draft-ietf-payload-rtp-ancillary-12 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, 03 Dec 2017 22:06:54 -0000 On 03/12/2017, Roni Even wrote: > Hi Thomas, > I read this proposal > I understand that the major change is the definition of the methodology: > > > This methodology would code the most important generic use cases: > > =E2=80=9CVANC Space after 2nd line after RP 168=E2=80=9D Line_number: 0x7= FE , > Horizontal_Offset 0xFFD [most VANC formats] > =E2=80=9CHANC Space after 2nd line after RP 168=E2=80=9D Line_Number: 0x7= FE, > Horizontal_Offset 0xFFE [e.g. SMPTE ST 12-2 ATC, ST 2051 Two Frame Marker= in > HANC] > =E2=80=9CHANC Space (any line)=E2=80=9D: Line_Number: 0x7FF, Horizontal_O= ffset: 0xFFE [e.g. > SMPTE RP214 KLV Metadata transport in HANC space] > =E2=80=9Cnot tied to location in SDI raster at all=E2=80=9D: Line_Number:= 0x7FF, > Horizontal_Offset: 0xFFF [e.g. all-IP systems in the future] > > > My recommendation is that once you decide on the correct text it will hel= p > us if we get feedback from other members of SMPTE to the payload mailing > list that this methodology is the correct one. > > Thank > Roni Even > Payload G co-chair > > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Thomas Edwar= ds > Sent: =D7=A9=D7=91=D7=AA 02 =D7=93=D7=A6=D7=9E=D7=91=D7=A8 2017 03:10 > To: payload@ietf.org > Subject: [payload] Issues with draft-ietf-payload-rtp-ancillary-12 > > Dear IETF Payload WG, > > While draft-ietf-payload-rtp-ancillary-12 was in the RFC Editor Queue, a > problem in the document was brought to my attention. I have requested th= at > the document be paused in the RFC Editor Queue for IESG action. > > The draft currently states of the =E2=80=9CLine_Number=E2=80=9D field: > > =E2=80=9CA value of 0x7FE indicates that the ANC data is = intended to > be placed into any legal area of the vertical blanking period ("VANC data > space"), specifically.=E2=80=9D > > As we know, =E2=80=9Cany legal area of the vertical blanking period=E2=80= =9D is not =E2=80=9CVANC > data space=E2=80=9D as defined in SMPTE ST 291-1, so this statement is in= correct. > > I briefly considered asking the RFC Editor to simply remove the > parenthetical statement. But two problems sprung up. > > First, we don=E2=80=99t have a Horizontal_Offset code for placing a packe= t > horizontally anywhere in the VANC space (i.e. between SAV and EAV). We = do > have a Horizontal_Offset code for anywhere in HANC space though. > > But a bigger problem is that a generic code for ANC data on any line in t= he > vertical interval is actually a BAD idea. > > Imagine an SDI to IP converter taking a VANC packet from below the RP 168 > switch point, coding it as Line_Number 0x7FE, then an IP to SDI converter > placing that packet in a line above the RP 168 switch point. Then an SDI > switch occurs, and that VANC packet is no longer attached to its > corresponding active video frame. > > After surveying all non-audio ANC data standards and their preferred > locations, I propose the following solution for the special values that c= ode > for the location of the ANC data packet to be in certain generic vertical > regions of the SDI raster. For Line_Number: > > 0x7FF: Without specific line location within the field or frame > 0x7FE: On any line in the range from the second line after the line > specified for switching, as defined in SMPTE RP 168, to the last line bef= ore > active video, inclusive > 0x7FD: On a line number larger than can be represented in 11 bits of this > field (if needed for future formats) > > And similarly, for Horizontal_Offset: > > 0xFFF: Without specific horizontal location > 0xFFE: Within horizontal ancillary data space (HANC) as defined in SMPTE = ST > 291-1 > 0xFFD: Within the ancillary data space located between SAV (Start of Acti= ve > Video) and EAV (End of Active Video) markers of the serial digital > interface > 0xFFC: Horizontal offset is larger than can be represented in the 12 bits= of > this field (if needed for future formats, or for certain low frame rate 7= 20p > formats) > > This methodology would code the most important generic use cases: > > =E2=80=9CVANC Space after 2nd line after RP 168=E2=80=9D Line_number: 0x7= FE , > Horizontal_Offset 0xFFD [most VANC formats] > =E2=80=9CHANC Space after 2nd line after RP 168=E2=80=9D Line_Number: 0x7= FE, > Horizontal_Offset 0xFFE [e.g. SMPTE ST 12-2 ATC, ST 2051 Two Frame Marker= in > HANC] > =E2=80=9CHANC Space (any line)=E2=80=9D: Line_Number: 0x7FF, Horizontal_O= ffset: 0xFFE [e.g. > SMPTE RP214 KLV Metadata transport in HANC space] > =E2=80=9Cnot tied to location in SDI raster at all=E2=80=9D: Line_Number:= 0x7FF, > Horizontal_Offset: 0xFFF [e.g. all-IP systems in the future] > > I am currently coordinating with subject matter experts within SMPTE and = the > Alliance for IP Media Solutions (AIMS) to confirm these code values. > > I hope to have a confirmation of these code values by the end of next wee= k, > at which time I can issue a -13 version of the draft if the WG approves. > > (Note: In such a draft, I would probably bring out these special codes as > tables rather than the current text to make them more readable.) > > -Thomas > > -- > 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 > Hi, I do agree that there will be an issue when mixing RP168 switching and this standard/ SMPTE2110. These new values will fix the issue at hand. However, when think= ing about hopefully replace RP168 with something suitable for network-based str= eam switching there is another issue that pops up: The simplest form for switching I would guess will be switching streams on the M-bit. However, the ANC payload standard defines: "Marker bit (M): 1 bit The marker bit set to "1" indicates the last ANC RTP packet for a frame (for progressive scan video) or the last ANC RTP packet for a field (for interlaced video)." I guess the question is about the definition of the last ANC RTP packet for= a frame/field? Is is the last line of a frame/field? Line 1125 for most HD formats? Or is it the line prior to the RP168 switching lines? If it isn't the line prior to the RP168 switching line, then switching on the M-bit will potentially splice ANC data onto a unrelated frame/field in the RP168 switching context. Best regards, Kjetil Oftedal From nobody Thu Dec 7 01:49: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 77662120724 for ; Thu, 7 Dec 2017 01:49:11 -0800 (PST) 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, HTML_MESSAGE=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=google.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 nA4zTZ4GRiZL for ; Thu, 7 Dec 2017 01:49:09 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 34EA0126C26 for ; Thu, 7 Dec 2017 01:49:09 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id t1so13370171ite.5 for ; Thu, 07 Dec 2017 01:49:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gM+d/BmmJtCWogPeyVy+EsPo30B63ZGqrsOfYgCwcH4=; b=mD4BdBoBpP9+Y8ujC4WbjSCcER0EtTh4Aby8PdbyaLJxbYd+V55026l/Ehu1N0DdKP iG0bhsbvHWJakE6lZNUG95mJ92qDDP4txOxuRQRnFwol+yUJ5Bs+4NJ99wGexe26NOMT +6yE6yhbEOJv2doyjSi/KeePGquilxwITDHvf2Dk42wUn/70v6sAKqoWdJELU6xER4Yo i42uiPxCmQda8bCGVdkqCIpPEYeUAj7LxSwOXdCPNdRMLoUHmlkwYWmvi8NtRm4OKpGL D09MKesEjO9aG5mmoIlt1grmAymcaUY2Mb6eiXtevjcJEpIkUoA7kmwlJnqLMxPB0Qql 1MSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gM+d/BmmJtCWogPeyVy+EsPo30B63ZGqrsOfYgCwcH4=; b=PxqqwoN6WW0Iw4cF6hU2KZvg8PofxzJIuA1AZPVlNWENOpjxzCRtD1pRHLH4jb4xQb sQ+oBUyc1VK2+4GBthpWR+SFYz7qOvhpZ0YjTchKbD+4heQqtvRZvJXnIbNV0MUEn4Ru 8axJuPsfcrM+bZFAa32yTEVisXW9qPS0akQwtsJIcVgQHVgyLp+nRKY/KB3xnZTLMJkb oA4evD66UCET/YMdV8uqfGGrXLz6UYC6Kj7Nt/qG9T6cACCeWMTXPhZ+NBTabF8N9lMX v4XrgXi3FCiZcKALzpduaA8ttFzU03vT3KDEAYbwkcXgkl50HMFAMFoHZhiGoz52dJ98 mnrQ== X-Gm-Message-State: AKGB3mLWN8/1ORCxsZh+KJtiKUKLu2ypl8j6Gew7VY/Q4Fs5Z0FfTxcp Z6TBHyxfxFqXfaf+wARJwVo+Uae/lcSGUMmnE2Nasp6H X-Google-Smtp-Source: AGs4zMaoUCOjtdEN4oo20B+6imucW5tg97NJxP1ZnpO2FN6oqX0hBFQn1r5jXk5YjqE0v/idbgXroSS3Fvnuy+gnslE= X-Received: by 10.107.180.5 with SMTP id d5mr7036932iof.281.1512640147671; Thu, 07 Dec 2017 01:49:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rasmus Brandt Date: Thu, 07 Dec 2017 09:48:56 +0000 Message-ID: To: payload@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0653b0ad664d055fbcfacd" Archived-At: Subject: Re: [payload] FlexFEC draft feedback 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: Thu, 07 Dec 2017 09:49:11 -0000 --94eb2c0653b0ad664d055fbcfacd Content-Type: text/plain; charset="UTF-8" > > ---------- Forwarded message ---------- > From: Brian Baldino > To: payload@ietf.org > Cc: > Bcc: > Date: Wed, 29 Nov 2017 12:18:18 -0800 > Subject: [payload] FlexFEC draft feedback > I've been implementing flexfec on the jitsi videobridge (starting with > just the receive side for now) and came across a couple things. Also Boris > Grozev has compiled some notes from his readings of the draft; I've tried > to summarize all our thoughts here: > > 1) It would be nice if the draft mentioned that the header extensions of > the FEC packets are totally independent of the media's header extensions, > and that one can add extensions to FEC packets without having any effect on > the recovery. > > 2) It would be nice if the draft explicitly stated that RTP header > extensions (and anything in the header beyond the 12 byte fixed header, > really) is protected as part of the payload. > > 3) I don't think it's explicitly mentioned that the first bit of the mask > represents a delta value of '0' (and, therefore, a '1' in that bit means > that the base sequence number itself is protected), it would be nice to > call this out [in Section 6.3.1.2 maybe?] > This is alluded to in Section 3.2 : bitmask: Run-length encoding of packets protected by a FEC packet. If the bit i in the mask is set to 1, the source packet number *N + i* is protected by this FEC packet. Here, N is the sequence number base, which is indicated in the FEC packet as well. and in Section 4.2 : The SN base_i (16 bits) field indicates the *lowest sequence number*, taking wrap around into account, of the source packets for a particular SSSRC (indicated in SSRC_i) *protected by this repair packet*. The draft is however not internally consistent, because in Section 4.2 it also says: If the F-bit is set to 0, it represents that the source packets of all the SSRCs protected by this particular repair packet are indicated by using a flexible bitmask. Mask is a run-length encoding of packets for a particular SSRC_i protected by the FEC packet. Where a bit j set to 1 indicates that the source packet with sequence number *(SN base_i + j + 1)* is protected by this FEC packet. which seems to be off-by-one compared to the earlier descriptions. When using the offset-based masks, the base sequence number is also inclusive: If M>0, N=0, is Row FEC, and no column FEC will follow Hence, FEC = SN, SN+1, SN+2, ... , SN+(M-1), SN+M. as well as when doing pure retransmissions: By setting R to 1, F to 1, this FEC protects only one packet, i.e., the FEC payload carries just the packet indicated by SN Base_i, which is effectively retransmitting the packet. To make the descriptions consistent, I think *(SN base_i + j + 1)* should be replaced by *(**SN base_i + j)* in Section 4.2. 4) In some of the diagrams there is a typo making it look like the 'P' > field is 2 bits instead of 1 (Figures 10, 12, 13, and 15) > > 4) From an implementation perspective, I found the extraction of the mask > to be a bit of a pain due to having to extract the k bits and shift the > actual mask to get the offsets. I wondered if there was a reason not to > move the second k bit next to the first to make them consecutive, followed > by a consecutive mask. I thought of two ways this might be done: > > a) Put a 2 bit k field at the start of the mask. There are multiple ways > to define an encoding for those 2 bits to represent a 14, 46 or 110 mask. > This has the downside of making the first mask 1 bit smaller (14 bits vs > 15) but does allow for encoding a 4th mask length, if so desired. > > b) Put a variable (either 1 or 2) bit k field at the start of the mask. > Similar to the current scheme, if the first bit was a '1' it would mean it > was only a 15 bit mask and the second bit would not be used to represent > the mask size, If the first bit was a '0', then the next bit will also be > used to determine the mask size. I.e.: > 1 -> 15 bit mask (only one bit spent) > 01 -> 46 bit mask > 00 -> 110 bit mask > > -brian > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > --94eb2c0653b0ad664d055fbcfacd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= ---------- Forwarded message ----------
From:=C2=A0Brian Baldino <brian@jitsi.org>To:=C2=A0payload@ie= tf.org
Cc:=C2=A0
Bcc:=C2=A0
Date:=C2=A0Wed, 29 Nov 2017 12:18:= 18 -0800
Subject:=C2=A0[payload] FlexFEC draft feedback
I've been implementing flexfec on the jitsi videobridge (starting w= ith just the receive side for now) and came across a couple things.=C2=A0 A= lso Boris Grozev has compiled some notes from his readings of the draft; I&= #39;ve tried to summarize all our thoughts here:

1)= It would be nice if the draft mentioned that the header extensions of the = FEC packets are totally independent of the media's header extensions, a= nd that one can add extensions to FEC packets without having any effect on = the recovery.

2) It would be nice if the draft exp= licitly stated that RTP header extensions (and anything in the header beyon= d the 12 byte fixed header, really) is protected as part of the payload.

3) I don't think it's explicitly mentioned t= hat the first bit of the mask represents a delta value of '0' (and,= therefore, a '1' in that bit means that the base sequence number i= tself is protected), it would be nice to call this out [in Section 6.3.1.2 = maybe?]

This is alluded t= o in=C2=A0Section 3.2:
bitmask: Run-length encoding of packets protected by a FEC packet.
         If the bit i in the mask is set to 1, the source packet number =
N + i
         is protected by this FEC packet.  Here, N is the sequence number
         base, which is indicated in the FEC packet as well.
and= in Section 4.2:
The SN base_i (16 bits) field indicates the lowest s= equence number, taking wrap around into account, of the source packets for a particular SSSRC (indicated in SSRC_i) protected by this repair packet= .

The draft is however not intern= ally consistent, because in Section 4.2 it also says:
If the F-bit is set to 0, it represents t=
hat the source packets of
all the SSRCs protected by this particular repair packet are
indicated by using a flexible bitmask.  Mask is a run-length
encoding of packets for a particular SSRC_i protected by the FEC
packet.  Where a bit j set to 1 indicates that the source packet
with sequence number (SN base_i + j + 1) is protected by this FEC
packet.
which seems to be off-by-one compared to the earlier descripti= ons.

W= hen using the offset-based masks, the base sequence number is also inclusiv= e:
If M>0, N=3D0,=
  is Row FEC, and no column FEC will follow
               Hence, FEC =3D SN, SN+1, SN+2, ... , SN+(M-1), SN+M.
as= well as when doing pure retransmissions:
<= pre class=3D"inbox-inbox-newpage" style=3D"font-size:13.3333px;margin-top:0= px;margin-bottom:0px">By setting R to 1, F to 1, this FEC protects only one= packet, i.e., the FEC payload carries just the packet indicated by SN Base_i, which is effectively retransmitting the packet.

<=
/pre>To make the descriptions consistent, I think (SN base_i + j + 1)=C2=A0should be replaced by (SN base_i + j)=
=C2=A0in Section 4.2.

4) In some of the diagrams there is a typo making it look like the 'P= ' field is 2 bits instead of 1 (Figures 10, 12, 13, and 15)
<= br>
4) From an implementation perspective, I found the extraction= of the mask to be a bit of a pain due to having to extract the k bits and = shift the actual mask to get the offsets.=C2=A0 I wondered if there was a r= eason not to move the second k bit next to the first to make them consecuti= ve, followed by a consecutive mask.=C2=A0 I thought of two ways this might = be done:

a) Put a 2 bit k field at the start= of the mask.=C2=A0 There are multiple ways to define an encoding for those= 2 bits to represent a 14, 46 or 110 mask.=C2=A0 This has the downside of m= aking the first mask 1 bit smaller (14 bits vs 15) but does allow for encod= ing a 4th mask length, if so desired.

b) Put a var= iable (either 1 or 2) bit k field at the start of the mask.=C2=A0 Similar t= o the current scheme, if the first bit was a '1' it would mean it w= as only a 15 bit mask and the second bit would not be used to represent the= mask size,=C2=A0 If the first bit was a '0', then the next bit wil= l also be used to determine the mask size. I.e.:
1 -> 15 bit m= ask (only one bit spent)
01 -> 46 bit mask
00 -> = 110 bit mask

-brian
_______________________________________________
payload mailing list
payload@ietf.org<= br> https://www.ietf.org/mailman/listinfo/payload
--94eb2c0653b0ad664d055fbcfacd-- From nobody Thu Dec 7 13:45: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 4EA20128C9C; Thu, 7 Dec 2017 13:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 yECOJ6PKrbc0; Thu, 7 Dec 2017 13:45:18 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 959B0126DFE; Thu, 7 Dec 2017 13:45:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=101417; q=dns/txt; s=iport; t=1512683118; x=1513892718; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dut2dfM0Rnv1cxKo99HTy/JQkOMnkBGfXJKivbB3/g4=; b=ARXAbkx0P+KVas2yFJwjz+ctufTrCaQcFgXoNUYPHlBXhZnCEIdr6P53 gp93XpDDySV0TW5W5RLffxTg986TsOFe+IcASpOlKTxAj9Pd/6vlpHeid nkmISfzfvjqWwGQT4pEWFrNO2oP80dqiOIUWeIePIAkQZ9RW6vtQdjFmz U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CVAQCftSla/51dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKAUQvZnInB50agX1+h3eOFBSBfgMKGAEMhEdPAoVjQRYBAQE?= =?us-ascii?q?BAQEBAQFrKIUiAQEBAQIBAQEKDgFTCwULAgEIEQMBAgEVCwEGByEGCxQJCAIEA?= =?us-ascii?q?Q0FH4g0cEwDDQgQqi6HNQ2DIQEBAQEBAQEBAQEBAQEBAQEBAQEBARgFg1mCCoF?= =?us-ascii?q?WgWmCdTaCa4FxHg84FgmFOQWLSoY/hzqJAT0Ch3aIKYR8ghaGEYs1jQU9iGoCE?= =?us-ascii?q?RkBgToBJgMvgU9vFTqCKQmCEDYDHIFneAEBh1GBM4EVAQEB?= X-IronPort-AV: E=Sophos; i="5.45,374,1508803200"; d="scan'208,217"; a="41739751" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Dec 2017 21:45:17 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id vB7LjGZ7025645 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Dec 2017 21:45:16 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 7 Dec 2017 15:45:16 -0600 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1320.000; Thu, 7 Dec 2017 15:45:15 -0600 From: "Mo Zanaty (mzanaty)" To: Stephen Botzko , "Ali C. Begen" CC: "rtcweb@ietf.org" , "payload@ietf.org" Thread-Topic: [payload] WGLC on RTP Payload Format for Flexible Forward Error Correction Thread-Index: AQHTb6Sq5fMniPLQpk+FmOyhGufnSQ== Date: Thu, 7 Dec 2017 21:45:15 +0000 Message-ID: References: <6E58094ECC8D8344914996DAD28F1CCD83775A@DGGEMM506-MBX.china.huawei.com> <4A105783-051C-469E-8080-ED438E8DB803@networked.media> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.219.199] Content-Type: multipart/alternative; boundary="_000_D64EF1DF7668Emzanatyciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [payload] WGLC on RTP Payload Format for Flexible Forward Error Correction 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: Thu, 07 Dec 2017 21:45:23 -0000 --_000_D64EF1DF7668Emzanatyciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Stephen, Thank you for the detailed review and comments. We are updating the draft t= o address your comments as noted below (see Mo: inline). Thanks, Mo From: payload > o= n behalf of Stephen Botzko > Date: Tuesday, November 21, 2017 at 4:22 PM To: "Ali C. Begen" > Cc: "rtcweb@ietf.org" >, "payload@ietf.org" > Subject: Re: [payload] WGLC on RTP Payload Format for Flexible Forward Erro= r Correction I have reviewed it, but I don't think it is ready for publication yet. My commends follow. BR Stephen >>> Abstract >>> Overall, the purpose is to reconstruct RTP source packets that were lost in= transmission, using the source and repair packets that were received. I e= xpected that to be stated somewhere in the abstract and introduction. Mo: Agreed, some readers unfamiliar with FEC may benefit from a brief state= ment of the purpose of FEC, which we will add. >>> These parity codes are systematic codes, where a number of repair symbols are generated from a set of source symbols. >>> This is of course the usual FEC jargon. But it isn=92t clear if the symbol= s in this draft are bits, bytes, or the full source packets payloads. Overall, the draft generally uses the phrase =93source packet=94 and =93rep= air packet=94. =93repair symbols=94 shows up in section 4.2, and there it = seems to mean bits or bytes. The draft needs to clarify this, as the many = implementers won=92t have any real knowledge of FEC. I suggest removing references to =93symbols=94, as the XOR construction and= repair mechanisms really don=92t need to talk about =93symbols=94. Mo: Agreed, we will use packets not symbols throughout. Also, =93FEC packets=94 appears to be the same thing as =93repair packets= =94. It would be better to use one term for both. Repair packets might be= clearer (though they reconstruct lost packets, and don't actually repair t= hem). Mo: We will clarify that these are FEC repair packets, and any shorter name= will be consistent throughout. >>> These repair symbols are sent in a repair flow separate from the source flo= w >>> The word =93flow=94 appears 19 times in the document with no explanation on= what exactly is meant. I believe it simply means that the source and repa= ir packets use different SSRCs (or different payload types?), but this is n= ot as clear as it might be. FWIW, I realize that =93flow=94 is also used extensively in RFC6363. But = RFC6363 defines flows in terms of transport identifier (such as standard 5 = tuple), and that definition doesn=92t apply here, since source and repair f= lows can use the same 5 tuple. Mo: We will avoid 'flow', which is also used extensively in RFC7656 RTP Tax= onomy with no definition. The taxonomy terms relevant for this draft are Re= dundancy RTP Stream and Source RTP Stream. If this begins to sound awkward = repeated many times, we will choose a consistent shorthand and avoid 'flow'= (replace with stream). >>> Moreover, alternate FEC codes may be used with the payload formats presente= d. >>> Does this mean that the FEC codes might not be XOR? If so, the document do= esn=92t say anything about how that is done (and the repair generation and = recovery methods in the draft are specific to XOR). So if means what is me= ant, the sentence should probably be removed. If it doesn=92t mean that, then what does it mean? Mo: This will be removed. The original draft allowed other codes (e.g. Reed= -Solomon or Raptor) to be negotiated, but the workgroup decided to remove t= his flexibility. Section 1.1 >>> Note that the source and repair packets belong to different source and repair flows, and the sender must provide a way for the receivers to demultiplex them, even in the case they are sent in the same 5-tuple (i.e., same source/destination address/port with UDP). >>> The =93different source and repair flows=94 aspect of the note is repetitiv= e, since it is also stated in step 3 immediately above this paragraph. =93= Even in the case=94 is understated, =93especially in the case=94 is closer = to the truth of it. It might be simpler to just say that source and repair= packets MUST use different SSRCs (or different payload types?), and delet= e this sentence. Mo: This will be clarified when 'flow' is removed throughout. >>> The repair packets may be sent proactively or on-demand. >>> How are they sent on demand? I don=92t see any methods for requesting repa= ir packets. Either procedures should be defined/referenced or the sentence= deleted. Mo: We will clarify that on-demand means in response to RTCP NACK, or the n= ew CC (ACK) feedback under design for RMCAT (draft-avtcore-cc-feedback-mess= age). Or we can word this more generically for any current or future NACK o= r ACK based feedback messages. >>> In this document, we refer to the time that spans a FEC block, which consists of the source packets and the corresponding repair packets, as the repair window. At the receiver side, the FEC decoder should wait at least for the duration of the repair window after getting the first packet in a FEC block, to allow all the repair packets to arrive. >>> Not sure if the intent is SHOULD wait or should wait. Mo: We will clarify this as SHOULD wait, and more specifically, SHOULD buff= er source and repair packets this long to allow for recovery upon packet lo= ss. More importantly, the FEC patterns in the draft are all defined to have a f= ixed number of packets. The =93time that spans an FEC block=94 is not cons= tant, especially for variable-rate video. The receiver has no idea how lon= g that repair window time might be for a specific FEC block. At some point the receiver decides it=92s time to deliver the source packet= s =96 either because (a) It is receiving source packets with no break in sequence number, so = there is no need to wait for repair (b) It has received enough repair packets to recover the missing source = packets (c) It has received all the repair packets, and they aren=92t sufficien= t to recover the missing source packets (d) It is choosing not to wait any longer. Case (d) might be reached because it is starting to receive packets in the = next FEC block, or it might be reached because of a real-time constraint The wording in the above paragraph doesn=92t cover these cases very well. = And the FEC decoder doesn=92t always need to wait for all the repair packet= s to be received before it can begin the repair process. It=92s probably more useful to point out that using flexflec does add delay= , and it needs to be clear that the repair window (in time units) is nomina= l. Or maybe specify the repair window in packets? Mo: repair-window (in microseconds) is a required parameter when negotiatin= g this payload format. Fixed block size in packets is an optional parameter= (L=3Dcolumns, D=3Drows). >>> Suppose that we have a group of D x L source packets that have sequence numbers starting from 1 running to D x L, and a repair packet is generated by applying the XOR operation to every L consecutive packets as sketched in Figure 3. This process is referred to as 1-D non-interleaved FEC protection >>> I think the document would be clearer if this was in new section =96 preced= ed by a short into saying how flexspec provides non-interleaved (row), inte= rleaved (column), and hybrid row+column (2-D) FEC patterns. This is a key = concept in the draft, and should be more prominent. I think there should also be four use-case sections. Separate sections for= row and column, and the retransmission mode (=93R=94 bit) should probably = have a short section too. Mo: Agreed, we will separate into more sections. >>> 1.1.3. Overhead Computation >>> Overhead isn=92t used much in the document, and I am not sure this particul= ar definition adds much value. It might be better phrased as =93FEC Overhe= ad Considerations=94, since the overhead fractions really don=92t have much= practical use, especially when the source packets are of unequal size. Mo: Ok, we will rename this. >>> 3.1. Definitions >>> FEC Block, and repair window should be defined here (neither are defined in= RFC6363). Parity Codes are not defined in RFC6363 either, and probably sh= ould be defined here. 1-D non-interleaved, 1-D interleaved, 2-D protection perhaps should be defi= ned. It might be cleaner to define source block here, since the RFC6363 definiti= on doesn=92t precisely apply (because its definition of ADU flow depends on= 5-tuple). In general there are very few definitions in RFC6363 that are used in flexf= ec, so if it were my draft I=92d just redefine them explicitly here. Mo: Ok, we will define what is used. >>> 3.2. Notations >>> I=92m not sure that bitmask needs to be here, though the text is ok. Mo: We will keep it for clarity. 4.1. Source Packets >>> The source packets MUST contain the information that identifies the source block and the position within the source block occupied by the packet. >>> This is a meaningless MUST, since the source RTP packet is simply sent with= out modification. The sequence number and SSRC are used to map the packets= onto the repair packets. Overall, paragraph 4.1 is confusing, because it gives the impression that s= omething else needs to be done, and then says that there isn=92t. Plus, it= is supposed =93define the format of the source packet=94 - which it doesn= =92t do. I think it=92s better just to say earlier in the document that the source p= ackets can be any RTP packets, and leave it at that. Perhaps tie that stat= ement to the use of systematic codes. Then focus on defining the repair pa= cket format, which is the heart of the draft. The advantages of not modifying the source packets is better placed somewhe= re else in the document =96 perhaps in section 1.1, when the FEC encoder an= d Decoders are introduced. Mo: Agreed, nothing normative to do here, so we will remove this MUST and d= escribe what systematic codes are. 4.2. Repair Packets >>> o Marker (M) Bit: This bit is not used for this payload type, and SHALL be set to 0 >>> And ignored by receivers? Mo: Agreed, "SHALL be set to 0 by senders, and SHALL be ignored by receiver= s". >>> Note that this document registers new payload formats for the repair packets (Refer to Section 5 for details). According to [RFC3550], an RTP receiver that cannot recognize a payload type must discard it. This provides backward compatibility. If a non-FEC-capable receiver receives a repair packet, it will not recognize the payload type, and hence, will discard the repair packet. >>> This probably should be said somewhere, but I think it=92s better moved som= ewhere other than the repair packet format description. Mo: Agreed, will move to a better section. I believe this also requires that the CSRCs in the repair RTP header be set= to the SSRCs of the source packets. That isn=92t stated, but is implied b= y the structure in table 10. Mo: It is stated below Figure 10 in FEC Header (see CSRC_i), but should be = moved up before Figure 10 in RTP Header. >>> The format of the FEC header is shown in Figure 10. The FEC header consists of the following fields: >>> No. This is the first of four? possible formats, depending on R,F,M, and N= , shown in figures 10-15. M is ambiguous - appears as M and M (columns). = Some fields are really repair symbols (P,X,C,M, PT Recovery, Length Recover= y, recovery), and are meaningless on their own. This rather important deta= il doesn=92t show up until you get to 6.2. Figure 15 also affects figure 9, since the unspecified =93Repair symbols=94= in figure 9 are replaced by the =93retransmission payload=94 In figure 15.= The contents of that =93retransmission payload=94 are not specified anywh= ere in the draft. This whole section is a confusing mess, and needs to be restructured. I gu= ess one approach is to change 6.2 to =93Repair symbol construction=94, and = explicitly refer to it for all fields in the FEC header that are XORed. On= e way or another, you need to separate out the fields that specify the FEC = parameters from the embedded repair symbols mixed into the structure. Mo: Agreed, implementors have also asked for clearer separation of the diff= erent repair formats, especially for FEC vs Retransmission, so we will sepa= rate this into clearer sections. >>> o The CSRC_i (32 bits) field describes the SSRC of the packets protected by this particular FEC packet. If a FEC packet contains protects multiple SSRCs (indicated by the CSRC Count > 1), there will be multiple blocks of data containing the SN base and Mask fields. >>> Does this mean that a repair flow can protect multiple RTP sources? If so,= this should be clearly stated earlier. There might be other implications = of supporting this (do all the sources need to have the same CNAME???) Mo: Yes, a repair stream can span multiple source streams. We will clarify = this earlier. The same CNAME is noted earlier in this section under the SSR= C bullet. >>> If M>0, N=3D0, is Row FEC, and no column FEC will follow Hence, FEC =3D SN, SN+1, SN+2, ... , SN+(M-1), SN+M. If M>0, N=3D1, is Row FEC, and column FEC will follow. Hence, FEC =3D SN, SN+1, SN+2, ... , SN+(M-1), SN+M. and more to come If M>0, N>1, indicates column FEC of every M packet in a group of N packets starting at SN base. Hence, FEC =3D SN+(Mx0), SN+(Mx1), ... , SN+(MxN). Figure 14: Interpreting the M and N field values >>> First, this is not a figure. Second, the names are not consistent with the = 1-d non-interleaved, 1-d interleaved, and 2-d described above. The names n= eed to be consistent. FWIW, these names are a bit more intuitive to me. Mo: Agreed, we will add the 1-d non-interleaved, 1-d interleaved and 2-d la= bels to the row/column FEC shorthand names here. >>> Note that the parsing of this packet is different. >>> =93this=94 is indefinite. In general you should name the four(?) header ty= pes, I think that will make things simpler. Mo: Agreed, the different repair formats will be separated into cleaer sect= ions. >>> Figure 15: Protocol format for Retransmission >>> This is mis-titled. It also isn=92t clear. The figure shows the alternati= ve FEC header format, but I believe the intent is that the retransmission p= ayload replaces the =93repair symbols=94 shown in figure 9. That isn=92t o= bvious from the organization. Mo: Agreed, the different repair formats will be separated into cleaer sect= ions. >>> It should be noted that a mask-based approach (similar to the ones specified in [RFC2733] and [RFC5109= ]) may not be very efficient to indicate which source packets in the current source block are associated with a given repair packet. In particular, for the applications that would like to use large source block sizes, the size of the mask that is required to describe the source-repair packet associations may be prohibitively large. The 8-bit fields proposed in [SMPTE2022-1] indicate a systematized approach. = Instead the approach in this document uses the 8-bit fields to indicate packet offsets protected by the FEC packet. The approach in [SMPTE2022-1] is inherently more efficient for regular patte= rns, it does not provide flexibility to represent other protection patterns (e.g., staircase). >>> I have no idea why this note is here. I=92d delete it. There's no point i= n talking about all the roads not taken. Mo: Agreed, we will remove it. >>> 5. Payload Format Parameters >>> If no specific FEC code is specified in the subtype, then the FEC code defaults to the parity code defined in this specification. >>> Since there is no syntax to specify the FEC code, a receiver has no way to = know for certain that the parity code is being used. I guess that the stat= ement in 5.2.1 might cover this Mo: This will be removed. The original draft allowed other codes (e.g. Reed= -Solomon or Raptor) to be negotiated, but the workgroup decided to remove t= his flexibility. >>> =93There are no optional format parameters defined for this payload. Any unknown option in the offer MUST be ignored and deleted from the answer. If FEC is not desired by the receiver, it can be deleted from the answer. >>> For SDP at least, any FEC code in the offer would be deleted by an existing= receiver, so if parity is mandatory-to-implement you=92d get interoperabil= ity at least. But why not just specify the FEC code parameter (with Parity= as a choice) now? Mo: The original draft allowed other codes (e.g. Reed-Solomon or Raptor) to= be negotiated as a parameter, but the workgroup decided to remove this fle= xibility and require other codes to use other payload format names. >>> 6.2. Repair Packet Construction The RTP header of a repair packet is formed based on the guidelines given in Section 4.2. >>> Since 4.2 is a mess, it=92s not surprising that 6.2 is also. The FEC header length isn=92t limited to 28 octets in the retransmission ca= se (which is conveniently skipped in 6.2) It would be good to specify what=92s in the skipped bits in the header, rat= her than making people figure it out. (=93V-2=94 and Sequence Number) Also phrases like =93The next 4 bits of the FEC bit string are written into= the CC recovery field in the FEC header=94 should be written as like =93Th= e next 4 bits of the FEC bit string are XORed into the CC recovery field in= the FEC header=94 BTW, I don=92t think the =93FEC bit string=94 nomenclature is all that usef= ul, given that you end up specifying the XOR field by field anyway. Mo: Agreed, we will clarify this. >>> The repair packet payload consists of the bits that are generated by applying the XOR operation on the payloads of the source RTP packets. If the payload lengths of the source packets are not equal, each shorter packet MUST be padded to the length of the longest packet by adding octet 0's at the end. >>> This presumably defines what is placed into the =93repair symbols=94 back i= n figure 9. But it doesn=92t say that. I believe this is incomplete. It doesn=92t say how to handle extension hea= ders. It isn=92t clear whether padding octets are XORed (RFC 3550 says the= padding octets =93are not part of the payload=94). SRTP MKI and authentica= tion tag would also be recovered (which is not possible in the current draf= t). Mo: We will clarify this. We need a good name for the part of the RTP packe= t after the fixed 12 byte header (CSRC list, extension header, RTP payload = and padding, as described in the second bullet of this section). >>> 6.3.2. Recovering the RTP Header This procedure recovers the header of an RTP packet up to (and including) the SSRC field. >>> But it doesn=92t recover the full header, and that should be more clearly s= tated, Mo: Do you mean it can't recover RTP version (assumes 2)? We can clarify th= at. The rest of the header can be recovered. FWIW, =93if the repair symbols=94 were defined as running from the first by= te after the SSRC to the end of the source RTP packet, then the full RTP pa= cket would be recovered =96 including SRTP MKI and authentication tag, whic= h cannot be recovered now. Mo: Yes, that is the design, we will clarify this. Again, a word for that (= after SSRC to end, after fixed 12 byte header) would greatly clarify this. >>> 6.3.3. Recovering the RTP Payload 2. For each of the source packets that are successfully received in T, compute the bit string from the Y octets of data starting with the 13th octet of the packet. If any of the bit strings generated from the source packets has a length shorter than Y, pad them to that length. The padding of octet 0 MUST be added at the end of the bit string. Note that the information of the first 8 octets are protected by the FEC header >>> As is the SSRC, though in a different way. Mo: Yes, we will note this to avoid any confusion. >>> 2. For each of the source packets that are successfully received in T, compute the bit string from the Y octets of data starting with the 13th octet of the packet. If any of the bit strings generated from the source packets has a length shorter than Y, pad them to that length. The padding of octet 0 MUST be added at the end of the bit string. Note that the information of the first 8 octets are protected by the FEC header. 3. For the repair packet in T, compute the FEC bit string from the repair packet payload, i.e., the Y octets of data following the FEC header. Note that the FEC header may be 12, 16, 32 octets depending on the length of the bitmask. 4. Calculate the recovered bit string as the XOR of the bit strings generated from all source packets in T and the FEC bit string generated from the repair packet in T. 5. Append the recovered bit string (Y octets) to the new packet generated in Section 6.3.2. >>> This is close to the algorithm I suggested above (starting the =93Repair sy= mbols=94 in figure 9 from the first octet after the SSRC). That=92s good, but it isn=92t consistent with the text in 6.2 (=93The repai= r packet payload consists of the bits that are generated by applying the XO= R operation on the payloads of the source RTP packets). So the text as written fails to recover (or fails to generate the repair pa= cket correctly, depending on how you look at it). Also, any RTP padding, SRTP MKI + authentication tag in the repair packets = themselves shouldn=92t be included in the XOR. RTP Padding, RTP MKI and the authentication tag lengths that are part of th= e source packets do need to be taken into account when computing Y. I'm no= t sure the current FEC header handles that well. This section uses "FEC Bit String" to mean something different than it mean= t earlier in the document. Note the repair algorithms could include authentication of input packets an= d recovered source packets. Mo: Yes, "payloads" will be removed, it is overloaded and incorrect. Again,= we need a good word for all bytes after 12. >>> 8. Congestion Control Considerations >>> I=92d remove the reference to[I-D.singh-rmcat-adaptive-fec]. Mo: Agreed, we will remove it. >>> However, it MAY still continue to use FEC if considered for bandwidth estimation instead of speculatively probe for additional capacity [Holmer13][Nagy14]. >>> What does this sentence mean? The draft doesn=92t talk about using FEC for= either bandwidth estimation or capacity probing. I suggest deleting it. Mo: Agreed, we will remove it. >>> 9. Security Considerations >>> Since the sender of the repair packets might not be the sender of the sourc= e packets, there is an obvious threat of injection of bogus repair packets.= Authentication can be helpful in mitigating that threat. Such authentication (if possible) should be done an any packets that are us= ed in the recovery process, and also on the reconstructed output packets. One could strengthen this into "MUST not" normative language if one wished. Mo: Agreed, we will make it a MUST if the recovered packet can be authentic= ated (i.e. SRTP source packets). NITS Overall, the document frequently uses first person plural (Suppose we have,= If we apply, We generate, We refer, We assume, =85). I think the authors= should consider rephrasing those sentences. Mo: We will rephrase ;) Section 1 >>> Situations where adaptivitiy of FEC parameters is desired, the endpoint can use the in-band mechanism, whereas when the FEC parameters are fixed, the endpoint may prefer to negotiate them out-of-band. >>> The sentence uses incorrect grammar. I suggest The in-band mechanism is advantageous when the endpoint is adapting the FEC= parameters; the out-of-band mechanism may be preferable when the FEC param= eters are fixed. Mo: Agreed, we will reword. Section 1.1 >>> In a nutshell, >>> Informal English =96 I suggest rephrasing. Mo: Agreed, we will remove. >>> Section 8 However, it MAY still continue to use FEC if considered for bandwidth estimation instead of speculatively probe for additional capacity [Holmer13][Nagy14]. >>> Probing? Mo: We will remove this anyway. On Sun, Nov 19, 2017 at 4:07 AM, Ali C. Begen > wrote: Obviously the deadline for the WGLC is Dec. 7th. -acbegen > On Nov 17, 2017, at 5:35 AM, Roni Even > wrote: > > Hi, > I would like to start a three week WGLC on RTP Payload Format for Flexibl= e Forward Error Correction in draft-ietf-payload-flexible-fec-scheme-05. > The WGLC will end on November 7th > > Mo has posted some clarifications to the payload WG mailing list payload= mailing list archives > > Please send comments to the payload mailing list. > THe double posting is to notify RTCweb WG that the WGLC has started sinc= e this document is needed for RTCweb > > > Roni Even > Payload WG co-chair > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload --_000_D64EF1DF7668Emzanatyciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9CA4D2F7E1FCC84BA6A959ED878C53C1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Stephen,

Thank you for the detailed review and comments. We are updating the draft t= o address your comments as noted below (see Mo: inline).

Thanks,
Mo

From: payload <payload-bounces@ietf.org> on behalf of St= ephen Botzko <stephen.botzko= @gmail.com>
Date: Tuesday, November 21, 2017 at= 4:22 PM
To: "Ali C. Begen" <ali.begen@networked.media>= ;
Cc: "rtcweb@ietf.org" <= rtcweb@ietf.org>, "payload@= ietf.org" <payload@ietf.org= >
Subject: Re: [payload] WGLC on RTP = Payload Format for Flexible Forward Error Correction

I have reviewed it, but I don't think it is ready for publ= ication yet.

My commends follow.

BR
Stephen 

 

>>>
Abstract
>>>
Overall, the purpose is to reconstruct RTP source packets that were los=
t in transmission, using the source and repair packets that were received.&=
nbsp; I expected that to be stated somewhere in the abstract and introducti=
on.
Mo: Agreed, some readers unfamiliar with FEC may benefit from a brief = statement of the purpose of FEC, which we will add. 
 
>>> 

These parity codes are systematic codes, w=
here a number of repair


   symbols are generated from a =
set of source symbols.


>>> 

This is of =
course the usual FEC jargon.  But it isn=92t clear if the symbols in t=
his draft are bits, bytes, or the full source packets payloads.  


=
Overall, the draft generally uses the phrase =93source packet=94 and =93rep=
air packet=94.  =93repair symbols=94 shows up in section 4.2, and th=
ere it seems to mean bits or bytes.  The draft needs to clarify this, =
as the many implementers won=92t have any real knowledge of FEC.

 


I suggest removing references to =93symbols=94, as the XOR construction=
 and repair mechanisms really don=92t need to talk about =93symbols=94.


Mo: Agreed, we will use packets not symbols throughout. 


Also, =93FEC packets=94 appears to be the same thing as =93repair packe=
ts=94.  It would be better to use one term for both.  Repair pack=
ets might be clearer (though they reconstruct lost packets, and don't actua=
lly repair them).
Mo: We will clarify that these are FEC repair packets, and any shorter name= will be consistent throughout.

>>>  

These repair symbols are sent in a repair =
flow separate from the source flow


>>> 


The word =
=93flow=94 appears 19 times in the document with no explanation on what exa=
ctly is meant.  I believe it simply means that the source and repair p=
ackets use different SSRCs (or different payload
 types?), but this is not as clear as it might be.  


=
FWIW, I realize that =93flow=94 is also used extensively in RFC6363. &=
nbsp; But RFC6363 defines flows in terms of transport identifier (such as s=
tandard 5 tuple), and that definition doesn=92t apply here, since source an=
d repair flows can use the same 5 tuple.
Mo: We will avoid 'flow', which is also used extensively in RFC7656 RTP Tax= onomy with no definition. The taxonomy terms relevant for this draft are Re= dundancy RTP Stream and Source RTP Stream. If this begins to sound awkward = repeated many times, we will choose a consistent shorthand and avoid 'flow' (replace with stream).

>>> 

Moreover, alternate FEC codes may be used =
with the payload formats presented.

>>> 

Does this mean that the FEC codes might not be XOR?&= nbsp; If so, the document doesn=92t say anything about how that is done (an= d the repair generation and recovery methods in the draft are specific to X= OR).  So if means what is meant, the sentence should probably be removed.

If it doesn=92t mean that, then what does it mean?

Mo: This will be removed. The original draft allowed other codes (e.g. Reed= -Solomon or Raptor) to be negotiated, but the workgroup decided to remove t= his flexibility.

Section 1.1

>>> 

   Note that the source and repa=
ir packets belong to different source
   and repair flows, and the sen=
der must provide a way for the receivers
   to demultiplex them, even in =
the case they are sent in the same
   5-tuple (i.e., same source/de=
stination address/port with UDP).

>>> 

The =93different source and repair flows=94 aspect o= f the note is repetitive, since it is also stated in step 3 immediately abo= ve this paragraph.  =93Even in the case=94 is understated, =93especial= ly in the case=94 is closer to the truth of it.  It might be simpler to just say that source and repair packets MUST use diffe= rent SSRCs  (or different payload types?), and delete this sentence.

Mo: This will be clarified when 'flow' is remo= ved throughout. 

= >>> 

The repair packets may be sent proactively=
 or on-demand.

= >>> 

How are they sent on demand?  I don=92t see any= methods for requesting repair packets.  Either procedures should be d= efined/referenced or the sentence deleted.
Mo: We will clarify that on-demand means in response to RTCP NACK, or the n= ew CC (ACK) feedback under design for RMCAT (draft-avtcore-cc-feedback-mess= age). Or we can word this more generically for any current or future NACK o= r ACK based feedback messages.

>>> 

In this document, we refer to the time tha=
t
   spans a FEC block, which cons=
ists of the source packets and the
   corresponding repair packets,=
 as the repair window.  At the receiver
   side, the FEC decoder should =
wait at least for the duration of the
   repair window after getting t=
he first packet in a FEC block, to allow
   all the repair packets to arr=
ive.

>>> 

Not sure if the intent is SHOULD wait or should wait= .
Mo: We will clarify this as SHOULD wait, and more specifically, SHOULD buff= er source and repair packets this long to allow for recovery upon packet lo= ss.

More importantly, the FEC patterns in the draft are = all defined to have a fixed number of packets.  The =93time that spans= an FEC block=94 is not constant, especially for variable-rate video. = The receiver has no idea how long that repair window time might be for a specific FEC block.

At some point the receiver decides it=92s time to de= liver the source packets =96 either because

(a)    It is receiving source packets with no break in sequence number, so = there is no need to wait for repair

(b)    It has received enough repair packets to recover the missing source = packets

(c)     It has received all the repair packets, and they aren=92t sufficient= to recover the missing source packets

(d)    It is choosing not to wait any longer.

 

Case (d) might be reached bec= ause it is starting to receive packets in the next FEC block, or it might b= e reached because of a real-time constraint

 

The wording in the above paragraph doesn=92t cover t= hese cases very well.  And the FEC decoder doesn=92t always need to wa= it for all the repair packets to be received before it can begin the repair= process.

It=92s probably more useful to point out that using = flexflec does add delay, and it needs to be clear that the repair window (i= n time units) is nominal.  Or maybe specify the repair window in packe= ts? 

Mo: repair-window (in microseconds) is a required parameter when negotiatin= g this payload format. Fixed block size in packets is an optional parameter= (L=3Dcolumns, D=3Drows).

>>> 

Suppose that we have a group of D x L sour=
ce packets that have
   sequence numbers starting fro=
m 1 running to D x L, and a repair
   packet is generated by applyi=
ng the XOR operation to every L
   consecutive packets as sketch=
ed in Figure 3.  This process is
   referred to as 1-D non-interl=
eaved FEC protection

>>> 

I think the document would be clearer if this was in= new section =96 preceded by a short into saying how flexspec provides non-= interleaved (row), interleaved (column), and hybrid row+column (2-D) FE= C patterns.  This is a key concept in the draft, and should be more prominent. 

I think there should also be four use-case sections.=   Separate sections for row and column, and the retransmission mode (= =93R=94 bit) should probably have a short section too.
Mo: Agreed, we will separate into more sections.

>>> 

1.1.3<= span style=3D"font-size:10pt;font-family:"Courier New";color:blac= k">.  Overhead Computation

>>> 


Overhead isn=92t used much in the document, and I am= not sure this particular definition adds much value.  It might be bet= ter phrased as =93FEC Overhead Considerations=94, since the overhead fracti= ons really don=92t have much practical use, especially when the source packets are of unequal size.

Mo: Ok, we will rename this. 

>>> 

3.1.  Definitions

>>> 

FEC Block, and repair window should be defined here = (neither are defined in RFC6363).  Parity Codes are not defined in RFC= 6363 either, and probably should be defined here.


1-D non-interleaved, 1-D interleaved, 2-D protection= perhaps should be defined.


It might be cleaner to define source block here, sin= ce the RFC6363 definition doesn=92t precisely apply (because its definition= of ADU flow depends on 5-tuple). 


In general there are very few definitions in RFC6363= that are used in flexfec, so if it were my draft I=92d just redefine them = explicitly here.
Mo: Ok, we will define what is used.

>>> 

3.2.&= nbsp; Notations

>>> 

I=92m not sure that bitmask needs to be here, though= the text is ok.

Mo: We will keep it for clarity. <= /p>

 

4.1.  Source Packets

>>> 

   The source packets MUST conta=
in the information that identifies the
   source block and the position=
 within the source block occupied by the
   packet. 

>>> 

This is a meaningless MUST, since the source RTP pac= ket is simply sent without modification.  The sequence number and SSRC= are used to map the packets onto the repair packets.  

Overall, paragraph 4.1 is confusing, because it give= s the impression that something else needs to be done, and then says that t= here isn=92t.  Plus, it is supposed =93define the format of the source= packet=94 -  which it doesn=92t do. 


I think it=92s better just to say earlier in the doc= ument that the source packets can be any RTP packets, and leave it at that.=   Perhaps tie that statement to the use of systematic codes.  The= n focus on defining the repair packet format, which is the heart of the draft.


The advantages of not modifying the source packets i= s better placed somewhere else in the document =96 perhaps in section 1.1, = when the FEC encoder and Decoders are introduced.

Mo: Agreed, nothing normative to do here, so w= e will remove this MUST and describe what systematic codes are. 

4.2.&= nbsp; Repair Packets

 

>>> 

   o  Marker (M) Bit: This =
bit is not used for this payload type, and


      SHALL be se=
t to 0


>>> 


And ignored by receivers?
Mo: Agreed, "SHALL be set to 0 by senders, and SHALL be ignored by rec= eivers".

>>> 

Note that this document


      registers n=
ew payload formats for the repair packets (Refer to

      Section 5 for details).  According to [RFC3550], an RTP receiver


      that cannot=
 recognize a payload type must discard it.  This

      provides ba=
ckward compatibility.  If a non-FEC-capable receiver


      receives a =
repair packet, it will not recognize the payload type,<=
/pre>

      and hence, =
will discard the repair packet.


>>> 


This probably should be said somewhere, but I think =
it=92s better moved somewhere other than the repair packet format descripti=
on.


Mo: Agreed, will move to a better section.&nbs=
p;


I believe this also requires that the CSRCs in the r=
epair RTP header be set to the SSRCs of the source packets.  That isn=
=92t stated, but is implied by the structure in table 10.


Mo: It is stated below Figure 10 in FEC Header (see =
CSRC_i), but should be moved up before Figure 10 in RTP Header.


>>> 


The format of the FEC header is shown in F=
igure 10.


The FEC header consists of the following f=
ields:


>>> 


No.  This is the first of four? possible format=
s, depending on R,F,M, and N, shown in figures 10-15.  M is ambiguous =
- appears as M and M (columns).  Some fields are really repair symbols=
 (P,X,C,M, PT Recovery, Length Recovery, recovery),
 and are meaningless on their own.  This rather important detail doesn=
=92t show up until you get to 6.2.







Figure 15 also affects figure 9, since the unspecifi=
ed =93Repair symbols=94 in figure 9 are replaced by the =93retransmission p=
ayload=94 In figure 15.  The contents of that =93retransmission payloa=
d=94 are not specified anywhere in the draft.







This whole section is a confusing mess, and needs to=
 be restructured.  I guess one approach is to change 6.2 to =93Repair =
symbol construction=94, and explicitly refer to it for all fields in the FE=
C header that are XORed.  One way or another,
 you need to separate out the fields that specify the FEC parameters from t=
he embedded repair symbols mixed into the structure.


Mo: Agreed, implementors have also asked for c=
learer separation of the different repair formats, especially for FEC vs Re=
transmission, so we will separate this into clearer sections. <=
/p>

>>> 


   o  The CSRC_i (32 bits) =
field describes the SSRC of the packets


      protected b=
y this particular FEC packet.  If a FEC packet contains


      protects mu=
ltiple SSRCs (indicated by the CSRC Count > 1), there


      will be mul=
tiple blocks of data containing the SN base and Mask

      fields.


>>> 


Does this mean that a repair flow can protect multip=
le RTP sources?  If so, this should be clearly stated earlier.  T=
here might be other implications of supporting this (do all the sources nee=
d to have the same CNAME???)


Mo: Yes, a repair stream can span multiple source st=
reams. We will clarify this earlier. The same CNAME is noted earlier in thi=
s section under the SSRC bullet.


>>> 


If M>0, N=3D0,  is Row FEC, and no=
 column FEC will follow


       =
        Hence, FEC =3D SN, SN+1, SN&=
#43;2, ... , SN+(M-1), SN+M.


 


   If M>0, N=3D1,  is Ro=
w FEC, and column FEC will follow.


       =
          Hence, FEC =3D SN, S=
N+1, SN+2, ... , SN+(M-1), SN+M.


       =
     and more to come


 


   If M>0, N>1,  indi=
cates column FEC of every M packet


       =
             in=
 a group of N packets starting at SN base.


       =
          Hence, FEC =3D SN=
3;(Mx0), SN+(Mx1), ... , SN+(MxN).


 


 


       =
      Figure 14: Interpreting the M and N field va=
lues


>>> 


First, this is not a figure. Second, the names are n=
ot consistent with the 1-d non-interleaved, 1-d interleaved, and 2-d descri=
bed above.  The names need to be consistent.  FWIW, these names a=
re a bit more intuitive to me.


Mo: Agreed, we will add the 1-d non-interleave=
d, 1-d interleaved and 2-d labels to the row/column FEC shorthand names her=
e.  


>>> 


Note that the parsing of this packet is di=
fferent. 


>>> 


=93this=94 is indefinite.  In general you shoul=
d name the four(?) header types, I think that will make things simpler.&nbs=
p;



Mo: Agreed, the different repair formats will =
be separated into cleaer sections. 


>>> 


Figure 15: Protocol format for Retransmiss=
ion


>>> 


This is mis-titled.  It also isn=92t clear.&nbs=
p; The figure shows the alternative FEC header format, but I believe the in=
tent is that the retransmission payload replaces the =93repair symbols=94 s=
hown in figure 9.  That isn=92t obvious from the organization. &n=
bsp;



Mo: Agreed, the different repair formats will be sep=
arated into cleaer sections. 







>>> 


=
   It should be noted that a mask-based approach (similar to =
the ones


=
   specified in [RFC2733]
 and [RFC5109]) may =
not be very efficient to


=
   indicate which source packets in the current source block =
are


=
   associated with a given repair packet.  In particular=
, for the


=
   applications that would like to use large source block siz=
es, the


=
   size of the mask that is required to describe the source-r=
epair


=
   packet associations may be prohibitively large.  The =
8-bit fields


=
   proposed in [SMPTE2022-1]
 indicate a systematized approach.  Instead


=
   the approach in this document uses the 8-bit fields to ind=
icate


=
   packet offsets protected by the FEC packet.  The appr=
oach in


=
   [SMPTE2022-1] is
 inherently more efficient for regular patterns, it


=
   does not provide flexibility to represent other protection=
 patterns


=
   (e.g., staircase).


>>> 


I have no idea why this note is here.  I=92d de=
lete it.  There's no point in talking about all the roads not taken.


Mo: Agreed, we will remove it.







>>> 


5. 
 Payload Format Parameters


>>> 


If no specific FEC code is specified=



   in the subtype, then the FEC =
code defaults to the parity code defined


   in this specification.<=
/span>


>>> 


Since th=
ere is no syntax to specify the FEC code, a receiver has no way to know for=
 certain that the parity code is being used.  I guess that the =
statement in 5.2.1 might cover this 


M=
o: This will be removed. The original draft allowed other codes (e.g. Reed-=
Solomon or Raptor) to be negotiated, but the workgroup decided to remove th=
is flexibility.


>>> 


=93There are no optional format parameters=
 defined for this payload.


      Any unknown=
 option in the offer MUST be ignored and deleted from

      the answer.=
  If FEC is not desired by the receiver, it can be=



      deleted fro=
m the answer.


>>> 

=
For SDP at least, any FEC code in the offer would be deleted by an existing=
 receiver, so if parity is mandatory-to-implement you=92d get interoperabil=
ity at least.  But why not just specify the FEC code parameter (with P=
arity as a choice) now?


Mo: The original draft=
 allowed other codes (e.g. Reed-Solomon or Raptor) to be negotiated as a pa=
rameter, but the workgroup decided to remove this flexibility and require o=
ther codes to use other payload format names. =



>>> 




6.2.  Repair Packet Construction






   The RTP header of a repair pa=
cket is formed based on the guidelines


   given in S=
ection 4.2.


>>> 


Since 4.2 is a mess, it=92s not surprising that 6.2 =
is also.


The FEC header length isn=92t limited to 28 octets i=
n the retransmission case (which is conveniently skipped in 6.2)


It would be good to specify what=92s in the skipped =
bits in the header, rather than making people figure it out. (=93V-2=94 and=
 Sequence Number)


Also phr=
ases like =93The next 4 bits of the FEC bit str=
ing are written into the CC recovery field in the FEC header=94 should be w=
ritten as like =93The next 4 bits of the=
 FEC bit string are XORed into the CC recovery field in the FEC header=94


 


BTW, I don=92t think the =93FEC bit string=94 nomenc=
lature is all that useful, given that you end up specifying the XOR field b=
y field anyway.


Mo: Agreed, we will clarify this.


>>> 


   The repair packet payload con=
sists of the bits that are generated by


   applying the XOR operation on=
 the payloads of the source RTP packets.


   If the payload lengths of the=
 source packets are not equal, each


   shorter packet MUST be padded=
 to the length of the longest packet by


   adding octet 0's at the end.<=
span>


>>> 


This presumably defines what is placed into the =93r=
epair symbols=94 back in figure 9.  But it doesn=92t say that.


I believe this is incomplete.  It doesn=92t say=
 how to handle extension headers.  It isn=92t clear whether padding oc=
tets are XORed (RFC 3550 says the padding octets =93are not part of the pay=
load=94). SRTP MKI and authentication tag would also
 be recovered (which is not possible in the current draft).

Mo: We will clarify this. We need a good name for th=
e part of the RTP packet after the fixed 12 byte header (CSRC list, extensi=
on header, RTP payload and padding, as described in the second bullet of th=
is section).


>>> 


6.3.2=
. 
 Recovering the RTP Header


This procedure recovers the header of an R=
TP packet up to (and


   including) the SSRC field.


 


>>> 


But it doesn=92t recover the full header, and that s=
hould be more clearly stated,
Mo: Do you mean it can't recover RTP version (assumes 2)? We can clarify th= at. The rest of the header can be recovered.

FWIW, =93if the repair symbols=94 were defined as ru= nning from the first byte after the SSRC to the end of the source RTP packe= t, then the full RTP packet would be recovered =96 including SRTP MKI and a= uthentication tag, which cannot be recovered now.

Mo: Yes, that is the design, we will clarify t= his. Again, a word for that (after SSRC to end, after fixed 12 byte header)= would greatly clarify this.

>>> 

6.3.3= .  Recovering the RTP Payload

 

   2.  For each of the sour=
ce packets that are successfully received in
       T, co=
mpute the bit string from the Y octets of data starting with
       the 1=
3th octet of the packet.  If any of the bit strings
       gener=
ated from the source packets has a length shorter than Y,
       pad t=
hem to that length.  The padding of octet 0 MUST be added at
       the e=
nd of the bit string.  Note that the information of the
      =
 first 8 octets are protected by the FEC header=

>>> 

As is the SSRC, though in a different way.
Mo: Yes, we will note this to avoid any confusion.

>>> 

   2.  For each of the source packets that are successfu= lly received in

       T, compute the bit string from the= Y octets of data starting with

       the 13th octet of the packet. = ; If any of the bit strings

       generated from the source packets = has a length shorter than Y,

       pad them to that length.  The= padding of octet 0 MUST be added at

       the end of the bit string.  N= ote that the information of the

       first 8 octets are protected by th= e FEC header.

 

   3.  For the repair packet in T, compute the FEC bit s= tring from the

       repair packet payload, i.e., the Y= octets of data following the

       FEC header.  Note that the FE= C header may be 12, 16, 32 octets

       depending on the length of the bit= mask.

 

 

   4.  Calculate the recovered bit string as the XOR of = the bit strings

       generated from all source packets = in T and the FEC bit string

       generated from the repair packet i= n T.

 

   5.  Append the recovered bit string (Y octets) to the= new packet

       generated in Section 6.3.2.

>>> 

This is close to the al=
gorithm I suggested above (starting the =93Repair symbols=94 in figure 9 fr=
om the first octet after the SSRC).  
That=92s good, but it i=
sn=92t consistent with the text in 6.2 (=93The =
repair packet payload consists of the bits that are generated by applying t=
he XOR operation on the payloads of the source RTP packets).&=
nbsp; 
So the text as written fails to recover (or fails to generate the repa=
ir packet correctly, depending on how you look at it).
Also, any RTP padding, SRTP MKI + authentication tag in the repair=
 packets themselves shouldn=92t be included in the XOR.  

RTP Padding, RTP MKI and the authentication tag lengths that are part =
of the source packets do need to be taken into account when computing Y.  I=
'm not sure the current FEC header handles that well.





This section uses "FEC Bit String" to mean something d=
ifferent than it meant earlier in the document.





Note the repair algorithms could include authentication of input=
 packets and recovered source packets.


Mo: Yes, "payloads" will be removed, it is overloaded a=
nd incorrect. Again, we need a good word for all bytes after 12.



>>> 




8.  Congestion Control Considerations


 



>>> 


I=92d remove the reference to[I-D.singh-rmcat-adaptive-fec].



Mo: Agreed, we will remove it.



>>> 


However, it MAY still continue to use=
 FEC if considered for bandwidth


   estimation instead of sp=
eculatively probe for additional capacity


   [Hol=
mer13][Nagy14].



>>> 



What does this sentence mean?  The draft doesn=92t talk about using FE=
C for either bandwidth estimation or capacity probing.  I suggest dele=
ting it.



Mo: Agreed, we will remove it. 



>>> 



9<=
/span>. 
 Security Considerations



>>> 





Since the sender of the repair packets might not be the sender of the sourc=
e packets, there is an obvious threat of injection of bogus repair packets.=
  Authentication can be helpful in mitigating that threat.  =




Such authentication (if possible) should be done an any packets that are us=
ed in the recovery process, and also on the reconstructed output packets.









One could strengthen this into "MUST not" normative language if o=
ne wished.


Mo: Agreed, we will =
make it a MUST if the recovered packet can be authenticated (i.e. SRTP=
 source packets). 









NITS



Overall, the document frequently uses first person plural (Suppose we have,=
 If we apply, We generate,  We refer, We assume, =85).  I think t=
he authors should consider rephrasing those sentences.



Mo: We will rephrase ;)



 



Section 1



>>> 



Situations where adaptivitiy



   of FEC parameters is desired, the endpoint can use the in-=
band



   mechanism, whereas when the FEC parameters are fixed, the =
endpoint



   may prefer to negotiate them out-of-band.



>>> 



The sentence uses incorrect grammar.  I suggest



The in-band mechanism is advantageous when the endpoint is adapting the FEC=
 parameters; the out-of-band mechanism may be preferable when the FEC param=
eters are fixed.



Mo: Agreed, we will reword.



Section 1.1



>>> 


In a nutshell,


>>> 



Informal English =96 I suggest rephrasing.



Mo: Agreed, we will remove. 



>>> 



Section 8


However, it MAY still continue to use=
 FEC if considered for bandwidth


   estimation instead of sp=
eculatively probe for additional capacity


   [Hol=
mer13][Nagy14].



>>> 



Probing?



Mo: We will remove this anyway.



 

On Sun, Nov 19, 2017 at 4:07 AM, Ali C. Begen <ali.bege= n@networked.media> wrote:
Obviously the deadline for the WGLC is Dec. 7th.

-acbegen

> On Nov 17, 2017, at 5:35 AM, Roni Even <roni.even@huawei.com> wrote:
>
> Hi,
> I would like to start a three week WGLC on RTP Payload Format for Flex= ible Forward Error Correction in draft-ietf-payload-flexible-fec-schem= e-05.
> The WGLC will end on November 7th
>
> Mo has posted some clarifications to the payload WG mailing list = payload mailing list archives
>
> Please send comments to the payload mailing list.
> THe double posting is to  notify RTCweb WG that the WGLC has star= ted since this document is needed for RTCweb
>
>
> Roni Even
> Payload WG co-chair
>
>
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload

_______________________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload<= br>

--_000_D64EF1DF7668Emzanatyciscocom_-- From nobody Thu Dec 7 14:06: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 EAF0D128C9C for ; Thu, 7 Dec 2017 14:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 i_8iPVYadLwY for ; Thu, 7 Dec 2017 14:05:57 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DA25128796 for ; Thu, 7 Dec 2017 14:05:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10875; q=dns/txt; s=iport; t=1512684357; x=1513893957; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=wOnDOGVTFxf5dKoBhPu753IkSkmjWxPRsqjGqNYlPfk=; b=InfA8TAB6N29YIbkG5ba2iGi7tkNHX3ZpdLWwHMtUdszgSr2Q8C9dbOp cVD9lrGcY8PTYVZCmgZGzZ5NDQ0TRZMYuDUBsUatRQh+aEjl8gE6x+3s2 bu54RC3FDkiyO3vx+DE8Ttmw65i2dwLIzY3kFY27p3jBVHVCuU4FtFF67 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAQAquila/5NdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKRS+BWCcHjhuOf4F9kT6FS4IVCoU7AoVjPxgBAQEBAQEBAQF?= =?us-ascii?q?rKIUiAQEBAQMnYgIBCBEDAQIoBzIUCQgCBAESiUNkqgg6imMBAQEBAQEBAwEBA?= =?us-ascii?q?QEBAQEhg1mCCoFWhRSFQYVYBYpFmDwClRuTXJYsAhEZAYE6AR85gU9vFYJjgk8?= =?us-ascii?q?fgWd4iQaBFQEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,374,1508803200"; d="scan'208,217";a="327954464" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Dec 2017 22:05:55 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id vB7M5t3S028131 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Dec 2017 22:05:55 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 7 Dec 2017 16:05:54 -0600 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1320.000; Thu, 7 Dec 2017 16:05:54 -0600 From: "Mo Zanaty (mzanaty)" To: Brian Baldino , "payload@ietf.org" Thread-Topic: [payload] FlexFEC draft feedback Thread-Index: AQHTb6eNY3tEHAhmmUKFnGSBSFkHQg== Date: Thu, 7 Dec 2017 22:05:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.219.199] Content-Type: multipart/alternative; boundary="_000_D64F20BE76831mzanatyciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [payload] FlexFEC draft feedback 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: Thu, 07 Dec 2017 22:05:59 -0000 --_000_D64F20BE76831mzanatyciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brian, Thank you for the review and comments. We are updating the draft to address= your comments as noted below (see Mo: inline). Thanks, Mo From: payload > o= n behalf of Brian Baldino > Date: Wednesday, November 29, 2017 at 3:18 PM To: "payload@ietf.org" > Subject: [payload] FlexFEC draft feedback I've been implementing flexfec on the jitsi videobridge (starting with just= the receive side for now) and came across a couple things. Also Boris Gro= zev has compiled some notes from his readings of the draft; I've tried to s= ummarize all our thoughts here: 1) It would be nice if the draft mentioned that the header extensions of th= e FEC packets are totally independent of the media's header extensions, and= that one can add extensions to FEC packets without having any effect on th= e recovery. Mo: Agreed, will do. 2) It would be nice if the draft explicitly stated that RTP header extensio= ns (and anything in the header beyond the 12 byte fixed header, really) is = protected as part of the payload. Mo: Agreed, will do. As noted in my reply to Stephen, a good word for that = (bytes after 12) will greatly clarify things. 3) I don't think it's explicitly mentioned that the first bit of the mask r= epresents a delta value of '0' (and, therefore, a '1' in that bit means tha= t the base sequence number itself is protected), it would be nice to call t= his out [in Section 6.3.1.2 maybe?] Mo: Agreed, will do. 4) In some of the diagrams there is a typo making it look like the 'P' fiel= d is 2 bits instead of 1 (Figures 10, 12, 13, and 15) Mo: Yes, good catch. 4) From an implementation perspective, I found the extraction of the mask t= o be a bit of a pain due to having to extract the k bits and shift the actu= al mask to get the offsets. I wondered if there was a reason not to move t= he second k bit next to the first to make them consecutive, followed by a c= onsecutive mask. I thought of two ways this might be done: a) Put a 2 bit k field at the start of the mask. There are multiple ways t= o define an encoding for those 2 bits to represent a 14, 46 or 110 mask. T= his has the downside of making the first mask 1 bit smaller (14 bits vs 15)= but does allow for encoding a 4th mask length, if so desired. b) Put a variable (either 1 or 2) bit k field at the start of the mask. Si= milar to the current scheme, if the first bit was a '1' it would mean it wa= s only a 15 bit mask and the second bit would not be used to represent the = mask size, If the first bit was a '0', then the next bit will also be used= to determine the mask size. I.e.: 1 -> 15 bit mask (only one bit spent) 01 -> 46 bit mask 00 -> 110 bit mask Mo: The original -00 draft had this design in section 4.2: The FEC header consists of the following fields: o The MSK field (2 bits) indicates the type of the mask. Namely: +---------------+-------------------------------------+ | MSK bits | Use | +---------------+-------------------------------------+ | 00 | 16-bit mask | | 01 | 48-bit mask | | 10 | 112-bit mask | | 11 | packets indicated by offset M and N | +---------------+-------------------------------------+ Figure 11: MSK bit values Mo: When we added the optimized retransmission format, the MSK bits were re= placed by the RF bits and the mask size was extended in each mask. If you w= ant to convince the workgroup to move back to the original design or someth= ing similar, I am personally neutral on this point. But let's decide quickl= y either way. -brian --_000_D64F20BE76831mzanatyciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8DA77CB6CE5E4E49AF5521F59C8BB051@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Brian,

Thank you for the review and comments. We are updating the draft to ad= dress your comments as noted below (see Mo: inline).

Thanks,
Mo


From: payload <payload-bounces@ietf.org> on behalf of Br= ian Baldino <brian@jitsi.org><= br> Date: Wednesday, November 29, 2017 = at 3:18 PM
To: "payload@ietf.org" <payload@ietf.org>
Subject: [payload] FlexFEC draft fe= edback

I've been implementing flexfec on the jitsi videobridge (s= tarting with just the receive side for now) and came across a couple things= .  Also Boris Grozev has compiled some notes from his readings of the = draft; I've tried to summarize all our thoughts here:

1) It would be nice if the draft mentioned that the header extensions = of the FEC packets are totally independent of the media's header extensions= , and that one can add extensions to FEC packets without having any effect = on the recovery.

Mo: Agreed, will do.

2) It would be nice if the draft explicitly stated that RTP header ext= ensions (and anything in the header beyond the 12 byte fixed header, really= ) is protected as part of the payload.

Mo: Agreed, will do. As noted in my reply to Stephen, a good word for = that (bytes after 12) will greatly clarify things.

3) I don't think it's explicitly mentioned that the first bit of the m= ask represents a delta value of '0' (and, therefore, a '1' in that bit mean= s that the base sequence number itself is protected), it would be nice to c= all this out [in Section 6.3.1.2 maybe?]

Mo: Agreed, will do.

4) In some of the diagrams there is a typo making it look like the 'P'= field is 2 bits instead of 1 (Figures 10, 12, 13, and 15)

Mo: Yes, good catch.

4) From an implementation perspective, I found the extraction of the m= ask to be a bit of a pain due to having to extract the k bits and shift the= actual mask to get the offsets.  I wondered if there was a reason not= to move the second k bit next to the first to make them consecutive, followed by a consecutive mask.  I th= ought of two ways this might be done:

a) Put a 2 bit k field at the start of the mask.  There are multi= ple ways to define an encoding for those 2 bits to represent a 14, 46 or 11= 0 mask.  This has the downside of making the first mask 1 bit smaller = (14 bits vs 15) but does allow for encoding a 4th mask length, if so desired.

b) Put a variable (either 1 or 2) bit k field at the start of the mask= .  Similar to the current scheme, if the first bit was a '1' it would = mean it was only a 15 bit mask and the second bit would not be used to repr= esent the mask size,  If the first bit was a '0', then the next bit will also be used to determine the mask size.= I.e.:
1 -> 15 bit mask (only one bit spent)
01 -> 46 bit mask
00 -> 110 bit mask

Mo: The original -00 draft had this design in section 4.2:

   The FEC header consists of the following fields:

   o  The MSK field (2 bits) indicates the type of the mask.  Namely:

    +---------------+-------------------------------------+
    |    MSK bits   | Use                                 |
    +---------------+-------------------------------------+
    |      00       | 16-bit mask                         |
    |      01       | 48-bit mask                         |
    |      10       | 112-bit mask                        |
    |      11       | packets indicated by offset M and N |
    +---------------+-------------------------------------+

                         Figure 11: MSK bit values

Mo: When we added the optimized retransmission format, the MSK bits we= re replaced by the RF bits and the mask size was extended in each mask. If = you want to convince the workgroup to move back to the original design or s= omething similar, I am personally neutral on this point. But let's decide quickly either way.


-brian
 --_000_D64F20BE76831mzanatyciscocom_-- From nobody Thu Dec 7 14:21:41 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 7B95D1294CC for ; Thu, 7 Dec 2017 14:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 t1l59vrb5wCa for ; Thu, 7 Dec 2017 14:21:38 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB3FB12717E for ; Thu, 7 Dec 2017 14:21:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15201; q=dns/txt; s=iport; t=1512685297; x=1513894897; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=7KDzOPS2qiW2wbmTdJGxYvNIkBJRsG/G+V7QHmxhDUY=; b=PbFQGt7h6Q3ZaX0z8WtrWwMrykVIMI72TLmKmzvKbj0MxukBMtOXMQJD muvn5zcRzuSAxLjXlq7NOuWR5FS/c9kNRr03lIxbFVz4tjmaHYtC0vNwD KrSbj1gxXauLTD5rwaM1/V/RoL3vFxHEXzheuk9UzRfIx3e+it8aeORGX 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAQCevila/4gNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKRS9mcicHjhuOf4F9kT6FSxSBIgNcChgBDIRHTwKFYz8YAQE?= =?us-ascii?q?BAQEBAQEBayiFIgEBAQEDAQElQAcbAgEIEQMBAhYSBycLFAkIAgQBEolDZBCpd?= =?us-ascii?q?DqKYwEBAQEBAQEBAQEBAQEBAQEBAQEaBYNZggqBVoUUhFxlFgmFOQWKRZg8Aod?= =?us-ascii?q?2jSWTXI0FiScCERkBgToBHzkzgRxvFTqCKYRVeAGJBYEVAQEB?= X-IronPort-AV: E=Sophos; i="5.45,374,1508803200"; d="scan'208,217"; a="41737435" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Dec 2017 22:21:36 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vB7MLahi012060 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Dec 2017 22:21:36 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 7 Dec 2017 16:21:35 -0600 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1320.000; Thu, 7 Dec 2017 16:21:35 -0600 From: "Mo Zanaty (mzanaty)" To: Rasmus Brandt , "payload@ietf.org" Thread-Topic: [payload] FlexFEC draft feedback Thread-Index: AQHTb6m+dHf2gkv21UumkTDPsWzgnA== Date: Thu, 7 Dec 2017 22:21:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.219.199] Content-Type: multipart/alternative; boundary="_000_D64F25B476862mzanatyciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [payload] FlexFEC draft feedback 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: Thu, 07 Dec 2017 22:21:40 -0000 --_000_D64F25B476862mzanatyciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rasmus, Thank you for the review and comments. We are updating the draft to address= your comments as noted below (see Mo: inline). Thanks, Mo From: payload > o= n behalf of Rasmus Brandt > Date: Thursday, December 7, 2017 at 4:48 AM To: "payload@ietf.org" > Subject: Re: [payload] FlexFEC draft feedback ---------- Forwarded message ---------- From: Brian Baldino > To: payload@ietf.org Cc: Bcc: Date: Wed, 29 Nov 2017 12:18:18 -0800 Subject: [payload] FlexFEC draft feedback I've been implementing flexfec on the jitsi videobridge (starting with just= the receive side for now) and came across a couple things. Also Boris Gro= zev has compiled some notes from his readings of the draft; I've tried to s= ummarize all our thoughts here: 1) It would be nice if the draft mentioned that the header extensions of th= e FEC packets are totally independent of the media's header extensions, and= that one can add extensions to FEC packets without having any effect on th= e recovery. 2) It would be nice if the draft explicitly stated that RTP header extensio= ns (and anything in the header beyond the 12 byte fixed header, really) is = protected as part of the payload. 3) I don't think it's explicitly mentioned that the first bit of the mask r= epresents a delta value of '0' (and, therefore, a '1' in that bit means tha= t the base sequence number itself is protected), it would be nice to call t= his out [in Section 6.3.1.2 maybe?] This is alluded to in Section 3.2: bitmask: Run-length encoding of packets protected by a FEC packet. If the bit i in the mask is set to 1, the source packet number N += i is protected by this FEC packet. Here, N is the sequence number base, which is indicated in the FEC packet as well. and in Section 4.2: The SN base_i (16 bits) field indicates the lowest sequence number, taking wrap around into account, of the source packets for a particular SSSRC (indicated in SSRC_i) protected by this repair packet. The draft is however not internally consistent, because in Section 4.2 it a= lso says: If the F-bit is set to 0, it represents that the source packets of all the SSRCs protected by this particular repair packet are indicated by using a flexible bitmask. Mask is a run-length encoding of packets for a particular SSRC_i protected by the FEC packet. Where a bit j set to 1 indicates that the source packet with sequence number (SN base_i + j + 1) is protected by this FEC packet. which seems to be off-by-one compared to the earlier descriptions. When using the offset-based masks, the base sequence number is also inclusi= ve: If M>0, N=3D0, is Row FEC, and no column FEC will follow Hence, FEC =3D SN, SN+1, SN+2, ... , SN+(M-1), SN+M. as well as when doing pure retransmissions: By setting R to 1, F to 1, this FEC protects only one packet, i.e., the FEC payload carries just the packet indicated by SN Base_i, which is effectively retransmitting the packet. To make the descriptions consistent, I think (SN base_i + j + 1) should be = replaced by (SN base_i + j) in Section 4.2. Mo: I can see confusion here if j is zero-based so +j+1 works (which was th= e intent), or if j is one-based so +j works (which was not the intent). We = will clarify this in 3.2, 4.2, 6.2. Mo: A question to implementors: Do you see any value in signaling whether t= he SN_base itself is protected or not, rather than always assuming / requir= ing it to be protected? That is, should the lowest bit in the mask map to S= N_base or SN_base+1? 4) In some of the diagrams there is a typo making it look like the 'P' fiel= d is 2 bits instead of 1 (Figures 10, 12, 13, and 15) 4) From an implementation perspective, I found the extraction of the mask t= o be a bit of a pain due to having to extract the k bits and shift the actu= al mask to get the offsets. I wondered if there was a reason not to move t= he second k bit next to the first to make them consecutive, followed by a c= onsecutive mask. I thought of two ways this might be done: a) Put a 2 bit k field at the start of the mask. There are multiple ways t= o define an encoding for those 2 bits to represent a 14, 46 or 110 mask. T= his has the downside of making the first mask 1 bit smaller (14 bits vs 15)= but does allow for encoding a 4th mask length, if so desired. b) Put a variable (either 1 or 2) bit k field at the start of the mask. Si= milar to the current scheme, if the first bit was a '1' it would mean it wa= s only a 15 bit mask and the second bit would not be used to represent the = mask size, If the first bit was a '0', then the next bit will also be used= to determine the mask size. I.e.: 1 -> 15 bit mask (only one bit spent) 01 -> 46 bit mask 00 -> 110 bit mask -brian _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload --_000_D64F25B476862mzanatyciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <3FD1CA558CD6734DAD5C5ACEA430FE68@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Rasmus,

Thank you for the review and comments. We are updating the draft to ad= dress your comments as noted below (see Mo: inline).

Thanks,
Mo

From: payload <payload-bounces@ietf.org> on behalf of Ra= smus Brandt <brandtr@google.com>
Date: Thursday, December 7, 2017 at= 4:48 AM
To: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] FlexFEC draf= t feedback

---------- Forwarded message ----------
From: Brian Baldino <brian@jitsi.org>
To: payload@ietf= .org
Cc: 
Bcc: 
Date: Wed, 29 Nov 2017 12:18:18 -0800
Subject: [payload] FlexFEC draft feedback
I've been implementing flexfec on the jitsi videobridge (s= tarting with just the receive side for now) and came across a couple things= .  Also Boris Grozev has compiled some notes from his readings of the = draft; I've tried to summarize all our thoughts here:

1) It would be nice if the draft mentioned that the header extensions = of the FEC packets are totally independent of the media's header extensions= , and that one can add extensions to FEC packets without having any effect = on the recovery.

2) It would be nice if the draft explicitly stated that RTP header ext= ensions (and anything in the header beyond the 12 byte fixed header, really= ) is protected as part of the payload.

3) I don't think it's explicitly mentioned that the first bit of the m= ask represents a delta value of '0' (and, therefore, a '1' in that bit mean= s that the base sequence number itself is protected), it would be nice to c= all this out [in Section 6.3.1.2 maybe?]

This is alluded to in Section 3.2:
bitmask: Run-length encoding of packets protected by=
 a FEC packet.
         If the bit i in the mask is set to 1, the source packet number =
N + i
         is protected by this FEC packet.  Here, N is the sequence number
         base, which is indicated in the FEC packet as well.
and in Section 4.2:
The SN base_i (16 bits) field indicates the lowes=
t sequence
number, taking wrap around into account, of the source packets for
a particular SSSRC (indicated in SSRC_i) protected by this repair packet=
.

The draft is however not internally consistent, because in Section 4.2 it a= lso says:
If the F-bit is set to 0, it represents that the sou=
rce packets of
all the SSRCs protected by this particular repair packet are
indicated by using a flexible bitmask.  Mask is a run-length
encoding of packets for a particular SSRC_i protected by the FEC
packet.  Where a bit j set to 1 indicates that the source packet
with sequence number (SN base_i + j + 1) is protected by thi=
s FEC
packet.
which seems to be off-by-one compared to the earlier descriptions.

When using the offset-based masks, the base sequ= ence number is also inclusive:
If M>0, N=3D0,  is Row FEC, and no column FEC wil=
l follow
               Hence, FEC =3D SN, SN+1, SN+2, ... , SN+(M-1), S=
N+M.
as well as when doing pure retransmissions:
By setting R to 1, F to 1, this FEC protects only on=
e packet, i.e.,
the FEC payload carries just the packet indicated by SN Base_i, which
is effectively retransmitting the packet.

To make the descriptions consistent, I think (SN base_i + j + 1) should be replaced by (SN base_i + j) in Section 4.2.

Mo: I can see confusion here if j is zero-based so +j+1 works = (which was the intent), or if j is one-based so +j works (which was not= the intent). We will clarify this in 3.2, 4.2, 6.2.

Mo: A question to implementors: Do you see any value in signaling whet= her the SN_base itself is protected or not, rather than always assuming / r= equiring it to be protected? That is, should the lowest bit in the mask map= to SN_base or SN_base+1?


4) In some of the diagrams there is a typo making it look like the 'P'= field is 2 bits instead of 1 (Figures 10, 12, 13, and 15)

4) From an implementation perspective, I found the extraction of the m= ask to be a bit of a pain due to having to extract the k bits and shift the= actual mask to get the offsets.  I wondered if there was a reason not= to move the second k bit next to the first to make them consecutive, followed by a consecutive mask.  I th= ought of two ways this might be done:

a) Put a 2 bit k field at the start of the mask.  There are multi= ple ways to define an encoding for those 2 bits to represent a 14, 46 or 11= 0 mask.  This has the downside of making the first mask 1 bit smaller = (14 bits vs 15) but does allow for encoding a 4th mask length, if so desired.

b) Put a variable (either 1 or 2) bit k field at the start of the mask= .  Similar to the current scheme, if the first bit was a '1' it would = mean it was only a 15 bit mask and the second bit would not be used to repr= esent the mask size,  If the first bit was a '0', then the next bit will also be used to determine the mask size.= I.e.:
1 -> 15 bit mask (only one bit spent)
01 -> 46 bit mask
00 -> 110 bit mask

-brian
_______________________________________________
payload mailing list
payload@ietf.org<= br> https://www.ietf.org/mailman/listinfo/payload
 --_000_D64F25B476862mzanatyciscocom_-- From nobody Thu Dec 7 14:39:29 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 7DC321294F0 for ; Thu, 7 Dec 2017 14:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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=sip-communicator-org.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 FgZm5w35pwzm for ; Thu, 7 Dec 2017 14:39:25 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 B52F0127A91 for ; Thu, 7 Dec 2017 14:39:24 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id 74so9932017lfs.0 for ; Thu, 07 Dec 2017 14:39:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sip-communicator-org.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+x3iWEiGE1+SCeV+JNuP3ACB2qIgS2fQVYaOAmOfykw=; b=q1VA/C6d66S0V4d7nDH/wzLP1pjP64YRakJSh7Bn1rFiwlulE7bNNUfXcn0t2dv7sS ZeseiXTYxIUslPF2F9jEwNGbGq1AaUHrwMff7tJYS4HcJBEcaIS/YhCLgK2nHjDwGJSb 7DpU8Q1IULoS3QxAFOa9MBV4ctWyc8NpA2odKy2YZX+Niz6ldc+7DVJC1AugrPsFyXdM XriKbolTwCPRAe2Caj91VPFPZvWKoEPWvqWH1bZkekWQAOPdaunRqLsLBmjV/eO3DZ25 zfcCYA0yBzGDrMD6rkxZb+rrRtCx2xPJrDM3WReaBbNH1GkfO3SHSboEUp2+o8YAzUEp Nw4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+x3iWEiGE1+SCeV+JNuP3ACB2qIgS2fQVYaOAmOfykw=; b=Zovo6XdeiUT5Z2IKSh1D3G5HKiPAMQP0N0xVh881qnEhNa59LULItpeZK9N2T9TfM5 4Gc2QofxFP/GJAinyMT4Zebh+ld81LfIxge9eK0PNWN4f33jxzX97xN4dF69aCqsTigy AfN9bE3kMEG90vYzX1Byt+CB01KrIswHTgsGxLHj8CECWGdu1CPa16zsfvdZ8r3BMBi1 wWeigSdO5oGhYDptziL8b2dtjFs3dZ98zKln9xftJGbMxnh0Wfh0OKDz37bY9y3cJpHN OXw6mRcGu8sxzW5TU2cRb9IUWepkueoCttBdQCZTwyO4KiCXRQReznL+nDrwXD7uX2pA LO2A== X-Gm-Message-State: AJaThX4uKZiHVDAYpoU62qtxhMgLC81Vz1TFkVdRLPnb302qXi1qYbTw 37TQ0sS9+tO19R2vyWCc2+S5Dq9C8Yu4fqEcmn6Z X-Google-Smtp-Source: AGs4zMbxmERPXaMaE9964UMHY1yZ6SEBmPW95j3G24HDGQgmvo/l1QGK2MBynHrJ4Vo49oDaYkqul9dKExDImTDmhSw= X-Received: by 10.46.29.13 with SMTP id d13mr14922046ljd.8.1512686362869; Thu, 07 Dec 2017 14:39:22 -0800 (PST) MIME-Version: 1.0 Sender: brian@sip-communicator.org Received: by 10.46.85.85 with HTTP; Thu, 7 Dec 2017 14:39:22 -0800 (PST) In-Reply-To: References: From: Brian Baldino Date: Thu, 7 Dec 2017 14:39:22 -0800 X-Google-Sender-Auth: XnE8mObYb5RHo5o9zX_C40hRLgE Message-ID: To: "Mo Zanaty (mzanaty)" Cc: "payload@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c082cdc50d944055fc7bdd7" Archived-At: Subject: Re: [payload] FlexFEC draft feedback 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: Thu, 07 Dec 2017 22:39:27 -0000 --94eb2c082cdc50d944055fc7bdd7 Content-Type: text/plain; charset="UTF-8" Hey Mo, thanks for the reply...definitely interested in the discussion about the move, but I'm having trouble tracking it down. I found this email about retransmission optimization, but it looks like the 'k' bit scheme was already in use there. In the -02 draft (where the MSK bits are removed) I see in the changelog that the format was updated to reflect discussions in IETF94, Tokyo...does that mean perhaps that discussion was all in person, and not on the mailing list? Searching the list archives for 'msk' didn't turn up much either, but maybe I'm missing something. If the group was convinced to move away from it, not sure I'd have anything that would sway people back, but I'd be interested to read about the reasons. And can certainly testify that implementing it was not very fun (though having to do it in Java didn't do me any favors, either). -brian On Thu, Dec 7, 2017 at 2:05 PM, Mo Zanaty (mzanaty) wrote: > Hi Brian, > > Thank you for the review and comments. We are updating the draft to > address your comments as noted below (see Mo: inline). > > Thanks, > Mo > > > From: payload on behalf of Brian Baldino < > brian@jitsi.org> > Date: Wednesday, November 29, 2017 at 3:18 PM > To: "payload@ietf.org" > Subject: [payload] FlexFEC draft feedback > > I've been implementing flexfec on the jitsi videobridge (starting with > just the receive side for now) and came across a couple things. Also Boris > Grozev has compiled some notes from his readings of the draft; I've tried > to summarize all our thoughts here: > > 1) It would be nice if the draft mentioned that the header extensions of > the FEC packets are totally independent of the media's header extensions, > and that one can add extensions to FEC packets without having any effect on > the recovery. > > Mo: Agreed, will do. > > 2) It would be nice if the draft explicitly stated that RTP header > extensions (and anything in the header beyond the 12 byte fixed header, > really) is protected as part of the payload. > > Mo: Agreed, will do. As noted in my reply to Stephen, a good word for that > (bytes after 12) will greatly clarify things. > > 3) I don't think it's explicitly mentioned that the first bit of the mask > represents a delta value of '0' (and, therefore, a '1' in that bit means > that the base sequence number itself is protected), it would be nice to > call this out [in Section 6.3.1.2 maybe?] > > Mo: Agreed, will do. > > 4) In some of the diagrams there is a typo making it look like the 'P' > field is 2 bits instead of 1 (Figures 10, 12, 13, and 15) > > Mo: Yes, good catch. > > 4) From an implementation perspective, I found the extraction of the mask > to be a bit of a pain due to having to extract the k bits and shift the > actual mask to get the offsets. I wondered if there was a reason not to > move the second k bit next to the first to make them consecutive, followed > by a consecutive mask. I thought of two ways this might be done: > > a) Put a 2 bit k field at the start of the mask. There are multiple ways > to define an encoding for those 2 bits to represent a 14, 46 or 110 mask. > This has the downside of making the first mask 1 bit smaller (14 bits vs > 15) but does allow for encoding a 4th mask length, if so desired. > > b) Put a variable (either 1 or 2) bit k field at the start of the mask. > Similar to the current scheme, if the first bit was a '1' it would mean it > was only a 15 bit mask and the second bit would not be used to represent > the mask size, If the first bit was a '0', then the next bit will also be > used to determine the mask size. I.e.: > 1 -> 15 bit mask (only one bit spent) > 01 -> 46 bit mask > 00 -> 110 bit mask > > Mo: The original -00 draft had this design in section 4.2: > > The FEC header consists of the following fields: > > o The MSK field (2 bits) indicates the type of the mask. Namely: > > +---------------+-------------------------------------+ > | MSK bits | Use | > +---------------+-------------------------------------+ > | 00 | 16-bit mask | > | 01 | 48-bit mask | > | 10 | 112-bit mask | > | 11 | packets indicated by offset M and N | > +---------------+-------------------------------------+ > > Figure 11: MSK bit values > > > Mo: When we added the optimized retransmission format, the MSK bits were > replaced by the RF bits and the mask size was extended in each mask. If you > want to convince the workgroup to move back to the original design or > something similar, I am personally neutral on this point. But let's decide > quickly either way. > > > -brian > --94eb2c082cdc50d944055fc7bdd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Mo, thanks for the reply...definitely interested in th= e discussion about the move, but I'm having trouble tracking it down.= =C2=A0 I found this=C2=A0email about retransmission optimiza= tion, but it looks like the 'k' bit scheme was already in use there= .=C2=A0 In the -02 draft (where the MSK bits are removed) I see in the chan= gelog that the format was updated to reflect discussions in=C2=A0IETF94, Tokyo...does that mean p= erhaps that discussion was all in person, and not on the mailing list?=C2= =A0 Searching the list archives for 'msk' didn't turn up much e= ither, but maybe I'm missing something.

If the group was conv= inced to move away from it, not sure I'd have anything that would sway = people back, but I'd be interested to read about the reasons.=C2=A0 And= can certainly testify that implementing it was not very fun (though having= to do it in Java didn't do me any favors, either).

-brian
=

On Th= u, Dec 7, 2017 at 2:05 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.com><= /span> wrote:
Hi Brian,

Thank you for the review and comments. We are updating the draft to ad= dress your comments as noted below (see Mo: inline).

Thanks,
Mo


From: payload <payload-bounces@ietf.org&g= t; on behalf of Brian Baldino <brian@jitsi.org>
Date: Wednesday, November 29, 2017 = at 3:18 PM
To: "payload@ietf.org" <payload@ietf.org>
Subject: [payload] FlexFEC draft fe= edback

I've been implementing flexfec on the jitsi videobridg= e (starting with just the receive side for now) and came across a couple th= ings.=C2=A0 Also Boris Grozev has compiled some notes from his readings of = the draft; I've tried to summarize all our thoughts here:

1) It would be nice if the draft mentioned that the header extensions = of the FEC packets are totally independent of the media's header extens= ions, and that one can add extensions to FEC packets without having any eff= ect on the recovery.

Mo: Agreed, will do.

2) It would be nice if the draft explicitly stated that RTP header ext= ensions (and anything in the header beyond the 12 byte fixed header, really= ) is protected as part of the payload.

Mo: Agreed, will do. As noted in my reply to Stephen, a good wo= rd for that (bytes after 12) will greatly clarify things.

3) I don't think it's explicitly mentioned that the first bit = of the mask represents a delta value of '0' (and, therefore, a '= ;1' in that bit means that the base sequence number itself is protected= ), it would be nice to call this out [in Section 6.3.1.2 maybe?]

Mo: Agreed, will do.

4) In some of the diagrams there is a typo making it look like the = 9;P' field is 2 bits instead of 1 (Figures 10, 12, 13, and 15)

Mo: Yes, good catch.

4) From an implementation perspective, I found the extraction of the m= ask to be a bit of a pain due to having to extract the k bits and shift the= actual mask to get the offsets.=C2=A0 I wondered if there was a reason not= to move the second k bit next to the first to make them consecutive, followed by a consecutive mask.=C2=A0 I th= ought of two ways this might be done:

a) Put a 2 bit k field at the start of the mask.=C2=A0 There are multi= ple ways to define an encoding for those 2 bits to represent a 14, 46 or 11= 0 mask.=C2=A0 This has the downside of making the first mask 1 bit smaller = (14 bits vs 15) but does allow for encoding a 4th mask length, if so desired.

b) Put a variable (either 1 or 2) bit k field at the start of the mask= .=C2=A0 Similar to the current scheme, if the first bit was a '1' i= t would mean it was only a 15 bit mask and the second bit would not be used= to represent the mask size,=C2=A0 If the first bit was a '0', then the next bit will also be used to determine the ma= sk size. I.e.:
1 -> 15 bit mask (only one bit spent)
01 -> 46 bit mask
00 -> 110 bit mask

Mo: The original -00 draft had this design in section 4.2: 

   The FEC h=
eader consists of the following fields:

   o  The MSK field (2 bits) indicates the type of the mask.  Namely:

    +---------------+-------------------------------------+
    |    MSK bits   | Use                                 |
    +---------------+-------------------------------------+
    |      00       | 16-bit mask                         |
    |      01       | 48-bit mask                         |
    |      10       | 112-bit mask                        |
    |      11       | packets indicated by offset M and N |
    +---------------+-------------------------------------+

                         Figure 11: MSK bit values

Mo: When we added the optimized retransmission format, the MSK bits we= re replaced by the RF bits and the mask size was extended in each mask. If = you want to convince the workgroup to move back to the original design or s= omething similar, I am personally neutral on this point. But let's decide quickly either way.


-brian

--94eb2c082cdc50d944055fc7bdd7-- From nobody Thu Dec 7 14:43:05 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 94C29127A91 for ; Thu, 7 Dec 2017 14:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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=sip-communicator-org.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 P5UxnDT9uX4x for ; Thu, 7 Dec 2017 14:43:00 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 08396126B72 for ; Thu, 7 Dec 2017 14:43:00 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id j124so9940191lfg.2 for ; Thu, 07 Dec 2017 14:42:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sip-communicator-org.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=GOobB8OMeBclZh6zX3yin60speuR/QfdaDEZecd/SuE=; b=wxQA09s4nUvzuoN7PlJHPphUPOS6UMWB7UFqbkJFlVKCzpJDpYLgqiYk5GqPW3rgww E8BoQbSNIAATEeuwCSLwVLAGmNEamFUa1PcQectWqg5IZtYOFYskB8IBPRbsggLiodsn 19i64oiSarMsVkh0CN0e9ntbfFZirGG/pytOetjXcaZ9YZvucwxW+OyCmVUAP4S5X+BK C+O1Y1yyIHAkHgMNBwBUn6GpvqZV2Jc2wT3bOtT8qmoEtWWpj7XosF3eZHPdpxV8A6In Hz7WdYfT0lUsUJrCho4MLt44CkbYCVtYwSKdwt/r1SnTQ79yKqpIpdwUia/yluYh8ohM sL7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=GOobB8OMeBclZh6zX3yin60speuR/QfdaDEZecd/SuE=; b=rrUv0tH7XCGXGWBwMXO6WZ9ejmx6CRFiGFkCqXcjUeVQfwwaQRxxoqoP2IIYUD+LiY OKFdj/XZGbR+noe82J0mmD82XWXFnb+zFkQfxHOpDv8ooa2jYWS4Tq9jtx1bNO1v09Sa nQIdX3iOIzgF0+D4wMHFfKRhE0gTMYWppSgVgCs6ATkK69wKdRph3oKxD9zDcW7q8vr2 fzoI0KyrX0doTWrIC3aPUgQeAmrg4OugTDkh4dZghxpU9T3sytYfwvDszT/YszMGT5jH xCevoMOiXSqvxJPnR+WWVCa8tBkpy2ULFNSZ6rumE/p0DHXa0hxuD67OKXdaWFZI5EXp X+1Q== X-Gm-Message-State: AJaThX6Vni/1E17nME+dvMxO5cv6B6BdSf+MwhQR518kEzP7moW9UI80 3NvKXOh8ypore1hgakc5eskyGYXkrwj3rWWnei+g X-Google-Smtp-Source: AGs4zMZqnxnEqHyIfdMq17ZsnPawofUCuXGUQVTglnBDl54VcPTnPhRaAmMbTnVQxKAv7UsJ8seFQKQJhge470PVyvU= X-Received: by 10.46.71.133 with SMTP id u127mr15154175lja.52.1512686578306; Thu, 07 Dec 2017 14:42:58 -0800 (PST) MIME-Version: 1.0 Sender: brian@sip-communicator.org Received: by 10.46.85.85 with HTTP; Thu, 7 Dec 2017 14:42:57 -0800 (PST) In-Reply-To: References: From: Brian Baldino Date: Thu, 7 Dec 2017 14:42:57 -0800 X-Google-Sender-Auth: anCSCNS2veTGoSgC9Z1uEmWI60U Message-ID: To: "Mo Zanaty (mzanaty)" Cc: Rasmus Brandt , "payload@ietf.org" Content-Type: multipart/alternative; boundary="001a1140754c282629055fc7ca60" Archived-At: Subject: Re: [payload] FlexFEC draft feedback 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: Thu, 07 Dec 2017 22:43:03 -0000 --001a1140754c282629055fc7ca60 Content-Type: text/plain; charset="UTF-8" > > Mo: A question to implementors: Do you see any value in signaling whether > the SN_base itself is protected or not, rather than always assuming / > requiring it to be protected? That is, should the lowest bit in the mask > map to SN_base or SN_base+1? Personally I'd prefer the first bit map to SN_base, so determining all of the packets which are protected is calculated in the same way (as opposed to the special case of adding SN_base to the protected list, and then getting the rest from the mask). On Thu, Dec 7, 2017 at 2:21 PM, Mo Zanaty (mzanaty) wrote: > Hi Rasmus, > > Thank you for the review and comments. We are updating the draft to > address your comments as noted below (see Mo: inline). > > Thanks, > Mo > > From: payload on behalf of Rasmus Brandt < > brandtr@google.com> > Date: Thursday, December 7, 2017 at 4:48 AM > To: "payload@ietf.org" > Subject: Re: [payload] FlexFEC draft feedback > > ---------- Forwarded message ---------- >> From: Brian Baldino >> To: payload@ietf.org >> Cc: >> Bcc: >> Date: Wed, 29 Nov 2017 12:18:18 -0800 >> Subject: [payload] FlexFEC draft feedback >> I've been implementing flexfec on the jitsi videobridge (starting with >> just the receive side for now) and came across a couple things. Also Boris >> Grozev has compiled some notes from his readings of the draft; I've tried >> to summarize all our thoughts here: >> >> 1) It would be nice if the draft mentioned that the header extensions of >> the FEC packets are totally independent of the media's header extensions, >> and that one can add extensions to FEC packets without having any effect on >> the recovery. >> >> 2) It would be nice if the draft explicitly stated that RTP header >> extensions (and anything in the header beyond the 12 byte fixed header, >> really) is protected as part of the payload. >> >> 3) I don't think it's explicitly mentioned that the first bit of the mask >> represents a delta value of '0' (and, therefore, a '1' in that bit means >> that the base sequence number itself is protected), it would be nice to >> call this out [in Section 6.3.1.2 maybe?] >> > > This is alluded to in Section 3.2 > > : > > bitmask: Run-length encoding of packets protected by a FEC packet. > If the bit i in the mask is set to 1, the source packet number *N + i* > is protected by this FEC packet. Here, N is the sequence number > base, which is indicated in the FEC packet as well. > > and in Section 4.2 > > : > > The SN base_i (16 bits) field indicates the *lowest sequence > number*, taking wrap around into account, of the source packets for > a particular SSSRC (indicated in SSRC_i) *protected by this repair packet*. > > > The draft is however not internally consistent, because in Section 4.2 it > also says: > > If the F-bit is set to 0, it represents that the source packets of > all the SSRCs protected by this particular repair packet are > indicated by using a flexible bitmask. Mask is a run-length > encoding of packets for a particular SSRC_i protected by the FEC > packet. Where a bit j set to 1 indicates that the source packet > with sequence number *(SN base_i + j + 1)* is protected by this FEC > packet. > > which seems to be off-by-one compared to the earlier descriptions. > > When using the offset-based masks, the base sequence number is also > inclusive: > > If M>0, N=0, is Row FEC, and no column FEC will follow > Hence, FEC = SN, SN+1, SN+2, ... , SN+(M-1), SN+M. > > as well as when doing pure retransmissions: > > By setting R to 1, F to 1, this FEC protects only one packet, i.e., > the FEC payload carries just the packet indicated by SN Base_i, which > is effectively retransmitting the packet. > > > To make the descriptions consistent, I think *(SN base_i + j + 1)* should > be replaced by *(**SN base_i + j)* in Section 4.2. > > Mo: I can see confusion here if j is zero-based so +j+1 works (which was > the intent), or if j is one-based so +j works (which was not the intent). > We will clarify this in 3.2, 4.2, 6.2. > > Mo: A question to implementors: Do you see any value in signaling whether > the SN_base itself is protected or not, rather than always assuming / > requiring it to be protected? That is, should the lowest bit in the mask > map to SN_base or SN_base+1? > > > 4) In some of the diagrams there is a typo making it look like the 'P' >> field is 2 bits instead of 1 (Figures 10, 12, 13, and 15) >> >> 4) From an implementation perspective, I found the extraction of the mask >> to be a bit of a pain due to having to extract the k bits and shift the >> actual mask to get the offsets. I wondered if there was a reason not to >> move the second k bit next to the first to make them consecutive, followed >> by a consecutive mask. I thought of two ways this might be done: >> >> a) Put a 2 bit k field at the start of the mask. There are multiple ways >> to define an encoding for those 2 bits to represent a 14, 46 or 110 mask. >> This has the downside of making the first mask 1 bit smaller (14 bits vs >> 15) but does allow for encoding a 4th mask length, if so desired. >> >> b) Put a variable (either 1 or 2) bit k field at the start of the mask. >> Similar to the current scheme, if the first bit was a '1' it would mean it >> was only a 15 bit mask and the second bit would not be used to represent >> the mask size, If the first bit was a '0', then the next bit will also be >> used to determine the mask size. I.e.: >> 1 -> 15 bit mask (only one bit spent) >> 01 -> 46 bit mask >> 00 -> 110 bit mask >> > >> -brian >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >> > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > > --001a1140754c282629055fc7ca60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mo: A question to implem= entors: Do you see any value in signaling whether the SN_base itself is pro= tected or not, rather than always assuming / requiring it to be protected? = That is, should the lowest bit in the mask map to SN_base or SN_base+1?

Personally I'd prefer the first bit= map to SN_base, so determining all of the packets which are protected is c= alculated in the same way (as opposed to the special case of adding SN_base= to the protected list, and then getting the rest from the mask).=C2=A0

On Thu, Dec 7, 2017 at 2:21 PM, Mo Zanaty (mzanaty)= <mzanaty@cisco.com> wrote:
Hi Rasmus,

Thank you for the review and comments. We are updating the draft to ad= dress your comments as noted below (see Mo: inline).

Thanks,
Mo

From: payload <payload-bounces@ietf.org&g= t; on behalf of Rasmus Brandt <brandtr@google.com>
Date: Thursday, December 7, 2017 at= 4:48 AM
To: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] FlexFEC draf= t feedback

---------- Forwarded message ----------
From:=C2=A0Brian Baldino <brian@jitsi.org>
To:=C2=A0payload@ietf= .org
Cc:=C2=A0
Bcc:=C2=A0
Date:=C2=A0Wed, 29 Nov 2017 12:18:18 -0800
Subject:=C2=A0[payload] FlexFEC draft feedback
I've been implementing flexfec on the jitsi videobridg= e (starting with just the receive side for now) and came across a couple th= ings.=C2=A0 Also Boris Grozev has compiled some notes from his readings of = the draft; I've tried to summarize all our thoughts here:

1) It would be nice if the draft mentioned that the header extensions = of the FEC packets are totally independent of the media's header extens= ions, and that one can add extensions to FEC packets without having any eff= ect on the recovery.

2) It would be nice if the draft explicitly stated that RTP header ext= ensions (and anything in the header beyond the 12 byte fixed header, really= ) is protected as part of the payload.

3) I don't think it's explicitly mentioned that the first bit = of the mask represents a delta value of '0' (and, therefore, a '= ;1' in that bit means that the base sequence number itself is protected= ), it would be nice to call this out [in Section 6.3.1.2 maybe?]

This is alluded to in=C2=A0Sectio= n 3.2:
bitmask: Run-length encoding o=
f packets protected by a FEC packet.
         If the bit i in the mask is set to 1, the source packet number =
N + i
         is protected by this FEC packet.  Here, N is the sequence number
         base, which is indicated in the FEC packet as well.
and in Section 4.2:
The SN base_i (16 bits) field =
indicates the lowest sequence
number, taking wrap around into account, of the source packets for
a particular SSSRC (indicated in SSRC_i) protected by this repair packet=
.

The draft is however not internally consistent, because in Section 4.2 it a= lso says:
If the F-bit is set to 0, it r=
epresents that the source packets of
all the SSRCs protected by this particular repair packet are
indicated by using a flexible bitmask.  Mask is a run-length
encoding of packets for a particular SSRC_i protected by the FEC
packet.  Where a bit j set to 1 indicates that the source packet
with sequence number (SN base_i + j + 1) is protected by this FEC
packet.
which seems to be off-by-one compared to the earlier descriptions.

When using the offset-based masks, the base sequ= ence number is also inclusive:
If M>0, N=3D0,  is Row FEC,=
 and no column FEC will follow
               Hence, FEC =3D SN, SN+1, SN+2, ... , SN+(M-1), SN+M.
as well as when doing pure retransmissions:
By setting R to 1, F to 1, thi=
s FEC protects only one packet, i.e.,
the FEC payload carries just the packet indicated by SN Base_i, which
is effectively retransmitting the packet.

To make the descriptions consistent, I think (SN base_i + j + 1)= =C2=A0should be replaced by (SN base_i + j)=C2=A0in Section 4.2.

Mo: I can see confusion here if j is zero-based so +j+1 works (which w= as the intent), or if j is one-based so +j works (which was not the intent)= . We will clarify this in 3.2, 4.2, 6.2.

Mo: A question to implementors: Do you see any value in signaling whet= her the SN_base itself is protected or not, rather than always assuming / r= equiring it to be protected? That is, should the lowest bit in the mask map= to SN_base or SN_base+1?


4) In some of the diagrams there is a typo making it look like the = 9;P' field is 2 bits instead of 1 (Figures 10, 12, 13, and 15)

4) From an implementation perspective, I found the extraction of the m= ask to be a bit of a pain due to having to extract the k bits and shift the= actual mask to get the offsets.=C2=A0 I wondered if there was a reason not= to move the second k bit next to the first to make them consecutive, followed by a consecutive mask.=C2=A0 I th= ought of two ways this might be done:

a) Put a 2 bit k field at the start of the mask.=C2=A0 There are multi= ple ways to define an encoding for those 2 bits to represent a 14, 46 or 11= 0 mask.=C2=A0 This has the downside of making the first mask 1 bit smaller = (14 bits vs 15) but does allow for encoding a 4th mask length, if so desired.

b) Put a variable (either 1 or 2) bit k field at the start of the mask= .=C2=A0 Similar to the current scheme, if the first bit was a '1' i= t would mean it was only a 15 bit mask and the second bit would not be used= to represent the mask size,=C2=A0 If the first bit was a '0', then the next bit will also be used to determine the ma= sk size. I.e.:
1 -> 15 bit mask (only one bit spent)
01 -> 46 bit mask
00 -> 110 bit mask

-brian
_______________________________________________
payload mailing list
payload@ietf.org<= br> https://www.ietf.org/mailman/listinfo/payload<= br>

_______________________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload<= br>

--001a1140754c282629055fc7ca60-- From nobody Thu Dec 7 14:55: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 EEC4F1294EC for ; Thu, 7 Dec 2017 14:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 nDBTU6wIWxIi for ; Thu, 7 Dec 2017 14:55:06 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DDB6127A91 for ; Thu, 7 Dec 2017 14:55:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16639; q=dns/txt; s=iport; t=1512687306; x=1513896906; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9xoxPQiVHvz3GbH9AKpyfI3SqmkWK7FKTmuMmFsEMgo=; b=CQL6Tk7cnhGMxUQhNGVVbUrn8D/0BkRrYyxvfJTfu81pWSobjpNby9pB XvHCKqdum0N5VhMIMjhUB9+sumlTgJAS+rwCokZWJDRD6cVvgbFYvrpAB WZcqE9eiIb2lLRcRF3Sy0BK8yAicFRA+JngmdAQ3SwxZqyEAyrYy+kpcA o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C4AgApxila/5FdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKRS9mcicHhF6YPIF9kT6FSxSCAQolhRYChWNAFwEBAQEBAQE?= =?us-ascii?q?BAWsohSIBAQEBAydHCxACAQgRAwECKAcyFAkIAgQOBYlDZBADqWw6imIBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYNZggqBVoUUhG4BEgEHOIVYBYpFmDwCh3aNJYI?= =?us-ascii?q?WihqHLI0FiScCERkBgToBIAE3YW5vFTqCKYJPH4FneAGHYYEkgRUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,374,1508803200"; d="scan'208,217";a="323614189" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Dec 2017 22:55:05 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vB7Mt5nS028755 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Dec 2017 22:55:05 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 7 Dec 2017 16:55:04 -0600 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1320.000; Thu, 7 Dec 2017 16:55:04 -0600 From: "Mo Zanaty (mzanaty)" To: Brian Baldino CC: "payload@ietf.org" Thread-Topic: [payload] FlexFEC draft feedback Thread-Index: AQHTb65rg/G61tOEKEib21sHQH+8GA== Date: Thu, 7 Dec 2017 22:55:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.219.199] Content-Type: multipart/alternative; boundary="_000_D64F2F12768ABmzanatyciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [payload] FlexFEC draft feedback 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: Thu, 07 Dec 2017 22:55:09 -0000 --_000_D64F2F12768ABmzanatyciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The minutes from that meeting are terse, but perhaps the recordings are an = option if you have the patience? https://www.ietf.org/proceedings/94/payload.html Or maybe Varun recalls the reasons. I don't recall any strong argument eith= er way on that point. I don't have any personal preference either. Thanks, Mo From: > on be= half of Brian Baldino > Date: Thursday, December 7, 2017 at 5:39 PM To: mzanaty > Cc: "payload@ietf.org" > Subject: Re: [payload] FlexFEC draft feedback Hey Mo, thanks for the reply...definitely interested in the discussion abou= t the move, but I'm having trouble tracking it down. I found this email ab= out retransmission optimization, but it looks like the 'k' bit scheme was a= lready in use there. In the -02 draft (where the MSK bits are removed) I s= ee in the changelog that the format was updated to reflect discussions in I= ETF94, Tokyo...does that mean perhaps that discussion was all in person, an= d not on the mailing list? Searching the list archives for 'msk' didn't tu= rn up much either, but maybe I'm missing something. If the group was convinced to move away from it, not sure I'd have anything= that would sway people back, but I'd be interested to read about the reaso= ns. And can certainly testify that implementing it was not very fun (thoug= h having to do it in Java didn't do me any favors, either). -brian On Thu, Dec 7, 2017 at 2:05 PM, Mo Zanaty (mzanaty) > wrote: Hi Brian, Thank you for the review and comments. We are updating the draft to address= your comments as noted below (see Mo: inline). Thanks, Mo From: payload > o= n behalf of Brian Baldino > Date: Wednesday, November 29, 2017 at 3:18 PM To: "payload@ietf.org" > Subject: [payload] FlexFEC draft feedback I've been implementing flexfec on the jitsi videobridge (starting with just= the receive side for now) and came across a couple things. Also Boris Gro= zev has compiled some notes from his readings of the draft; I've tried to s= ummarize all our thoughts here: 1) It would be nice if the draft mentioned that the header extensions of th= e FEC packets are totally independent of the media's header extensions, and= that one can add extensions to FEC packets without having any effect on th= e recovery. Mo: Agreed, will do. 2) It would be nice if the draft explicitly stated that RTP header extensio= ns (and anything in the header beyond the 12 byte fixed header, really) is = protected as part of the payload. Mo: Agreed, will do. As noted in my reply to Stephen, a good word for that = (bytes after 12) will greatly clarify things. 3) I don't think it's explicitly mentioned that the first bit of the mask r= epresents a delta value of '0' (and, therefore, a '1' in that bit means tha= t the base sequence number itself is protected), it would be nice to call t= his out [in Section 6.3.1.2 maybe?] Mo: Agreed, will do. 4) In some of the diagrams there is a typo making it look like the 'P' fiel= d is 2 bits instead of 1 (Figures 10, 12, 13, and 15) Mo: Yes, good catch. 4) From an implementation perspective, I found the extraction of the mask t= o be a bit of a pain due to having to extract the k bits and shift the actu= al mask to get the offsets. I wondered if there was a reason not to move t= he second k bit next to the first to make them consecutive, followed by a c= onsecutive mask. I thought of two ways this might be done: a) Put a 2 bit k field at the start of the mask. There are multiple ways t= o define an encoding for those 2 bits to represent a 14, 46 or 110 mask. T= his has the downside of making the first mask 1 bit smaller (14 bits vs 15)= but does allow for encoding a 4th mask length, if so desired. b) Put a variable (either 1 or 2) bit k field at the start of the mask. Si= milar to the current scheme, if the first bit was a '1' it would mean it wa= s only a 15 bit mask and the second bit would not be used to represent the = mask size, If the first bit was a '0', then the next bit will also be used= to determine the mask size. I.e.: 1 -> 15 bit mask (only one bit spent) 01 -> 46 bit mask 00 -> 110 bit mask Mo: The original -00 draft had this design in section 4.2: The FEC header consists of the following fields: o The MSK field (2 bits) indicates the type of the mask. Namely: +---------------+-------------------------------------+ | MSK bits | Use | +---------------+-------------------------------------+ | 00 | 16-bit mask | | 01 | 48-bit mask | | 10 | 112-bit mask | | 11 | packets indicated by offset M and N | +---------------+-------------------------------------+ Figure 11: MSK bit values Mo: When we added the optimized retransmission format, the MSK bits were re= placed by the RF bits and the mask size was extended in each mask. If you w= ant to convince the workgroup to move back to the original design or someth= ing similar, I am personally neutral on this point. But let's decide quickl= y either way. -brian --_000_D64F2F12768ABmzanatyciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
The minutes from that meeting are terse, but perhaps the recordin= gs are an option if you have the patience?

Or maybe Varun recalls the reasons. I don't recall any strong argument= either way on that point. I don't have any personal preference either.

Thanks,
Mo

From: <brian@sip-communicator.org> on behalf of Brian = Baldino <brian@jitsi.org>
Date: Thursday, December 7, 2017 at= 5:39 PM
To: mzanaty <mzanaty@cisco.com>
Cc: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] FlexFEC draf= t feedback

Hey Mo, thanks for the reply...definitely interested in th= e discussion about the move, but I'm having trouble tracking it down. = I found this email about retransmission optimization, but it looks like th= e 'k' bit scheme was already in use there.  In the -02 draft (where th= e MSK bits are removed) I see in the changelog that the format was updated = to reflect discussions in IETF94, Tokyo...does that mean perhaps that discussion was all in person, and not = on the mailing list?  Searching the list archives for 'msk' didn't tur= n up much either, but maybe I'm missing something.

If the gro= up was convinced to move away from it, not sure I'd have anything that woul= d sway people back, but I'd be interested to read about the reasons.  = And can certainly testify that implementing it was not very fun (though having to do it in Java didn't do me any favor= s, either).

-brian

On Thu, Dec 7, 2017 at 2:05 PM, Mo Zanaty (mzana= ty) <mzanaty@cisco.co= m> wrote:
Hi Brian,

Thank you for the review and comments. We are updating the draft to ad= dress your comments as noted below (see Mo: inline).

Thanks,
Mo


From: payload <payload-bounces@ietf.org&g= t; on behalf of Brian Baldino <brian@jitsi.org>
Date: Wednesday, November 29, 2017 = at 3:18 PM
To: "payload@ietf.org" <payload@ietf.org>
Subject: [payload] FlexFEC draft fe= edback

I've been implementing flexfec on the jitsi videobridge (s= tarting with just the receive side for now) and came across a couple things= .  Also Boris Grozev has compiled some notes from his readings of the = draft; I've tried to summarize all our thoughts here:

1) It would be nice if the draft mentioned that the header extensions = of the FEC packets are totally independent of the media's header extensions= , and that one can add extensions to FEC packets without having any effect = on the recovery.

Mo: Agreed, will do.

2) It would be nice if the draft explicitly stated that RTP header ext= ensions (and anything in the header beyond the 12 byte fixed header, really= ) is protected as part of the payload.

Mo: Agreed, will do. As noted in my reply to Stephen, a good word for = that (bytes after 12) will greatly clarify things.

3) I don't think it's explicitly mentioned that the first bit of the m= ask represents a delta value of '0' (and, therefore, a '1' in that bit mean= s that the base sequence number itself is protected), it would be nice to c= all this out [in Section 6.3.1.2 maybe?]

Mo: Agreed, will do.

4) In some of the diagrams there is a typo making it look like the 'P'= field is 2 bits instead of 1 (Figures 10, 12, 13, and 15)

Mo: Yes, good catch.

4) From an implementation perspective, I found the extraction of the m= ask to be a bit of a pain due to having to extract the k bits and shift the= actual mask to get the offsets.  I wondered if there was a reason not= to move the second k bit next to the first to make them consecutive, followed by a consecutive mask.  I th= ought of two ways this might be done:

a) Put a 2 bit k field at the start of the mask.  There are multi= ple ways to define an encoding for those 2 bits to represent a 14, 46 or 11= 0 mask.  This has the downside of making the first mask 1 bit smaller = (14 bits vs 15) but does allow for encoding a 4th mask length, if so desired.

b) Put a variable (either 1 or 2) bit k field at the start of the mask= .  Similar to the current scheme, if the first bit was a '1' it would = mean it was only a 15 bit mask and the second bit would not be used to repr= esent the mask size,  If the first bit was a '0', then the next bit will also be used to determine the mask size.= I.e.:
1 -> 15 bit mask (only one bit spent)
01 -> 46 bit mask
00 -> 110 bit mask

Mo: The original -00 draft had this design in section 4.2:

   The FEC h=
eader consists of the following fields:

   o  The MSK field (2 bits) indicates the type of the mask.  Namely:

    +---------------+-------------------------------------+=
;
    |    MSK bits   | Use                                 |
    +---------------+-------------------------------------+=
;
    |      00       | 16-bit mask                         |
    |      01       | 48-bit mask                         |
    |      10       | 112-bit mask                        |
    |      11       | packets indicated by offset M and N |
    +---------------+-------------------------------------+=
;

                         Figure 11: MSK bit values

Mo: When we added the optimized retransmission format, the MSK bits we= re replaced by the RF bits and the mask size was extended in each mask. If = you want to convince the workgroup to move back to the original design or s= omething similar, I am personally neutral on this point. But let's decide quickly either way.


-brian

--_000_D64F2F12768ABmzanatyciscocom_-- From nobody Thu Dec 7 17:47:55 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 E48131286CA for ; Thu, 7 Dec 2017 17:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sip-communicator-org.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 O-2lEOQin94L for ; Thu, 7 Dec 2017 17:47:51 -0800 (PST) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 47125128B44 for ; Thu, 7 Dec 2017 17:47:51 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id b5so1649268itc.3 for ; Thu, 07 Dec 2017 17:47:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sip-communicator-org.20150623.gappssmtp.com; s=20150623; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2+nj0U2LEMP0DaaG+iT/CSov5gtjN6RKAyV9FYEHEbo=; b=WVm3utxD7IwJByMbQb9bvD2/0UPci3Q/oFG/hlvLBSf5SY5fOGIYM2AP1557jyXerD AMFiWAc/6CRt2p0wn/9CrDOI22WwxmjyPTa+bTfV6an7SHs/fSxsy3z6vEd2pd27mToU F7CCPwk4hsnQslbBxaaoBjkRvgvPSXm2bPIhZ/iGKARN37tXcUAreMRQhFWH7k25Ucpg 4gpHfzTl4+2X/jxhYtQJfXZiPkcsBaOPqQKFwpOZLu3HQanoH3RoUXa35HCycrmPBVTX 8Zu5rwrtNMBwUyReditOeZkqH7rS7IwJBHFDArkTsxlT8GKeMZ9y0S5GIU92WzCGeXdY STzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2+nj0U2LEMP0DaaG+iT/CSov5gtjN6RKAyV9FYEHEbo=; b=RTSQyFG8shPg3lnCcE6yBcwKkpmAWy1IEge3RYYgGAB4bqplkmC79IoFCiX+Ij9Ow+ oEgUSsZnhbGxeGpxzwG+Lz94JA6cNtdXUTeVeoOM/aQfqx7zcSSY1THGcLm2sRVulE3e bR8oDbq/L3XUoUFi8teTLe5AzkKWEkI9f7IkjEoA6GesurU2Wi1v08Do87OF1T6ePMA5 voabzqfKzU7E8ao2HJKuq8QkpMMvq3Iu7HUye9waFmnjI6nhlKRkzJJBLUZ0IrEqyqcV pS2jfrMDmGB91nhyZLyJSFkVpyPB1OcM/0SLdCjBmHhM7/SecB+OCWfWtbsQl4Xrw7yM E+1A== X-Gm-Message-State: AKGB3mJCQBNbx8rKVMSLXIhAHK6eM/EDxQO876MXoycLjOWUu246Wert APwCaXBPn0NypjvZNji+fVgwk4wQ X-Google-Smtp-Source: AGs4zMYPApBut9kdIXHL0j0+MEPgs3vhsW2YoD96ZWq3+hYlFutU0ouobVYZfc6KHoQBT++ZRYUxRg== X-Received: by 10.36.33.87 with SMTP id e84mr3692375ita.79.1512697670468; Thu, 07 Dec 2017 17:47:50 -0800 (PST) Received: from ?IPv6:2605:a601:1155:dc00:410a:788c:1324:6e5d? ([2605:a601:1155:dc00:410a:788c:1324:6e5d]) by smtp.gmail.com with ESMTPSA id 15sm3076806ioj.80.2017.12.07.17.47.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Dec 2017 17:47:49 -0800 (PST) Sender: Boris Grozev To: "Mo Zanaty (mzanaty)" , Brian Baldino Cc: "payload@ietf.org" References: From: Boris Grozev Message-ID: Date: Thu, 7 Dec 2017 19:47:47 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [payload] FlexFEC draft feedback 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: Fri, 08 Dec 2017 01:47:54 -0000 Hello, On 07/12/2017 16:55, Mo Zanaty (mzanaty) wrote: > The minutes from that meeting are terse, but perhaps the recordings are > an option if you have the patience? > https://www.ietf.org/proceedings/94/payload.html > > Or maybe Varun recalls the reasons. I don't recall any strong argument > either way on that point. I don't have any personal preference either. Note that Brian's suggestion "b" is equivalent to the -05 format in terms of the sets of sequence numbers that it can describe and the number of bits used for any given set. It only moves the second part of the "k" field, so that it's two bits (if both are present) are consecutive. If there are reasons for switching away from the fixed-length 2-bit field, or if time constraints make it hard to determine whether there are such reasons, please consider adopting this format. It is "safe" in that it doesn't change any higher level protocol characteristics, and more convenient for implementers. Regards, Boris From nobody Fri Dec 8 00:45:25 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 1383D124D68 for ; Fri, 8 Dec 2017 00:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 MZqrtejs3Ska for ; Fri, 8 Dec 2017 00:45:21 -0800 (PST) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 7556C1242F7 for ; Fri, 8 Dec 2017 00:45:21 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id x28so3432818ita.0 for ; Fri, 08 Dec 2017 00:45:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0zyf0SQNMDpoPp9t+BjFRBHQHOCNDKex3qTZtRCRv1w=; b=fFbsD19lJ4xpf+/Cv6S1uW0oPaJJKE/s9p19bfwP09CFHCmveBX4cJ9rerDHRpTxCE Kb6TATOrw6isurUZ/LZhJjAWEsQXsYFJEMYZCrBEPIpwfG2SDO81yDHaWBdgl7n0A/Gh lgFmFZFIgZz6LRDDWPizyvE6TJYPanAr5PGybiQu2pFthyRip7AIhRGAGw3CBpDtO9yo FTJkR39XUqgV4365uDT7+HBTJ1ocZhJVDksfLNWdXqdVWmyCvEmB1x5fe7x4XmR7vHUr 1Ng254MJ6d2HBkl1avFO5txa7fqcZBrl9aPJ668UqF/F6MoNCS9+KldALdfEOynLkN+X zxUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0zyf0SQNMDpoPp9t+BjFRBHQHOCNDKex3qTZtRCRv1w=; b=MhG7C5YR8y19TCelEryd9DUFeKpuk7DCKfHeYs+0/Kf0iyA9a5u4jaDpLqcl6p6xZ4 x2N2xlHFsD0+8Zu7H695NemQ7j3KF7XWygXzlWfqjYdmnUyHLsRDrOZUbgDbE5tByyBC m7BLvdDO0dVf2/KSvmkcDSnbg55B7doxJakfjfnVabr9MLtn13TXoIlageKFaV9HS2DE btP8x1ISJ4H2dpyar4O/YgzNI/ofjYIUpZjIIwRjJkSOHcerkBp2Hb64Rwfv1lrnRDTw XiIf5hg7X9Xzeqo+RYYTu9WrvHYdp11fPYB54snRWN4RJOxoWXVI2tpJ9VwPTzQGnltC 0t5w== X-Gm-Message-State: AJaThX7W7eDakjMl8BUTQnqTSLBAGT6LukIvEsFYzzV8wia51Ya7NrKr zs5TxEFGthYbm2pc8HPG8YbZAZMkcEhL5H4QES4meI0+ X-Google-Smtp-Source: AGs4zMbhh8yyvnpKaTIam9PB7LtIgMS1aNXMnQDiySDMxYhKM+SQP6EBri+7X1AJTjw58jYOSc0n/CypqMDihWWmQCo= X-Received: by 10.107.160.145 with SMTP id j139mr39573180ioe.236.1512722720354; Fri, 08 Dec 2017 00:45:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rasmus Brandt Date: Fri, 08 Dec 2017 08:45:09 +0000 Message-ID: To: Brian Baldino Cc: "Mo Zanaty (mzanaty)" , "payload@ietf.org" Content-Type: multipart/alternative; boundary="001a11403fb864821e055fd0345d" Archived-At: Subject: Re: [payload] FlexFEC draft feedback 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: Fri, 08 Dec 2017 08:45:24 -0000 --001a11403fb864821e055fd0345d Content-Type: text/plain; charset="UTF-8" On Thu, Dec 7, 2017 at 11:42 PM Brian Baldino wrote: Mo: A question to implementors: Do you see any value in signaling whether >> the SN_base itself is protected or not, rather than always assuming / >> requiring it to be protected? That is, should the lowest bit in the mask >> map to SN_base or SN_base+1? > > > Personally I'd prefer the first bit map to SN_base, so determining all of > the packets which are protected is calculated in the same way (as opposed > to the special case of adding SN_base to the protected list, and then > getting the rest from the mask). > I agree with Brian on this. That would also be consistent with how the packet masks are treated in ULPFEC : The mask field in the FEC level header indicates which packets are associated with the FEC packet at the current level. It is either 16 or 48 bits depending on the value of the L bit. If bit i in the mask is set to 1, then the media packet with sequence number N + i is associated with this FEC packet, where N is the SN Base field in the FEC packet header. The most significant bit of the mask corresponds to i=0, and the least significant to i=15 when the L bit is set to 0, or i=47 when the L bit is set to 1. On Thu, Dec 7, 2017 at 2:21 PM, Mo Zanaty (mzanaty) > wrote: > >> Hi Rasmus, >> >> Thank you for the review and comments. We are updating the draft to >> address your comments as noted below (see Mo: inline). >> >> Thanks, >> Mo >> >> From: payload on behalf of Rasmus Brandt < >> brandtr@google.com> >> Date: Thursday, December 7, 2017 at 4:48 AM >> To: "payload@ietf.org" >> Subject: Re: [payload] FlexFEC draft feedback >> >> ---------- Forwarded message ---------- >>> From: Brian Baldino >>> To: payload@ietf.org >>> Cc: >>> Bcc: >>> Date: Wed, 29 Nov 2017 12:18:18 -0800 >>> Subject: [payload] FlexFEC draft feedback >>> I've been implementing flexfec on the jitsi videobridge (starting with >>> just the receive side for now) and came across a couple things. Also Boris >>> Grozev has compiled some notes from his readings of the draft; I've tried >>> to summarize all our thoughts here: >>> >>> 1) It would be nice if the draft mentioned that the header extensions of >>> the FEC packets are totally independent of the media's header extensions, >>> and that one can add extensions to FEC packets without having any effect on >>> the recovery. >>> >>> 2) It would be nice if the draft explicitly stated that RTP header >>> extensions (and anything in the header beyond the 12 byte fixed header, >>> really) is protected as part of the payload. >>> >>> 3) I don't think it's explicitly mentioned that the first bit of the >>> mask represents a delta value of '0' (and, therefore, a '1' in that bit >>> means that the base sequence number itself is protected), it would be nice >>> to call this out [in Section 6.3.1.2 maybe?] >>> >> >> This is alluded to in Section 3.2 >> >> : >> >> bitmask: Run-length encoding of packets protected by a FEC packet. >> If the bit i in the mask is set to 1, the source packet number *N + i* >> is protected by this FEC packet. Here, N is the sequence number >> base, which is indicated in the FEC packet as well. >> >> and in Section 4.2 >> >> : >> >> The SN base_i (16 bits) field indicates the *lowest sequence >> number*, taking wrap around into account, of the source packets for >> a particular SSSRC (indicated in SSRC_i) *protected by this repair packet*. >> >> >> The draft is however not internally consistent, because in Section 4.2 it >> also says: >> >> If the F-bit is set to 0, it represents that the source packets of >> all the SSRCs protected by this particular repair packet are >> indicated by using a flexible bitmask. Mask is a run-length >> encoding of packets for a particular SSRC_i protected by the FEC >> packet. Where a bit j set to 1 indicates that the source packet >> with sequence number *(SN base_i + j + 1)* is protected by this FEC >> packet. >> >> which seems to be off-by-one compared to the earlier descriptions. >> >> When using the offset-based masks, the base sequence number is also >> inclusive: >> >> If M>0, N=0, is Row FEC, and no column FEC will follow >> Hence, FEC = SN, SN+1, SN+2, ... , SN+(M-1), SN+M. >> >> as well as when doing pure retransmissions: >> >> By setting R to 1, F to 1, this FEC protects only one packet, i.e., >> the FEC payload carries just the packet indicated by SN Base_i, which >> is effectively retransmitting the packet. >> >> >> To make the descriptions consistent, I think *(SN base_i + j + 1)* should >> be replaced by *(**SN base_i + j)* in Section 4.2. >> >> Mo: I can see confusion here if j is zero-based so +j+1 works (which was >> the intent), or if j is one-based so +j works (which was not the intent). >> We will clarify this in 3.2, 4.2, 6.2. >> >> Mo: A question to implementors: Do you see any value in signaling whether >> the SN_base itself is protected or not, rather than always assuming / >> requiring it to be protected? That is, should the lowest bit in the mask >> map to SN_base or SN_base+1? >> >> >> 4) In some of the diagrams there is a typo making it look like the 'P' >>> field is 2 bits instead of 1 (Figures 10, 12, 13, and 15) >>> >>> 4) From an implementation perspective, I found the extraction of the >>> mask to be a bit of a pain due to having to extract the k bits and shift >>> the actual mask to get the offsets. I wondered if there was a reason not >>> to move the second k bit next to the first to make them consecutive, >>> followed by a consecutive mask. I thought of two ways this might be done: >>> >>> a) Put a 2 bit k field at the start of the mask. There are multiple >>> ways to define an encoding for those 2 bits to represent a 14, 46 or 110 >>> mask. This has the downside of making the first mask 1 bit smaller (14 >>> bits vs 15) but does allow for encoding a 4th mask length, if so desired. >>> >>> b) Put a variable (either 1 or 2) bit k field at the start of the mask. >>> Similar to the current scheme, if the first bit was a '1' it would mean it >>> was only a 15 bit mask and the second bit would not be used to represent >>> the mask size, If the first bit was a '0', then the next bit will also be >>> used to determine the mask size. I.e.: >>> 1 -> 15 bit mask (only one bit spent) >>> 01 -> 46 bit mask >>> 00 -> 110 bit mask >>> >> >>> -brian >>> _______________________________________________ >>> payload mailing list >>> payload@ietf.org >>> https://www.ietf.org/mailman/listinfo/payload >>> >> >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >> >> > --001a11403fb864821e055fd0345d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
On Thu, Dec 7, 2017 at 11:42 P=
M Brian Baldino <brian@jitsi.org&=
gt; wrote:
Mo: A question to= implementors: Do you see any value in signaling whether the SN_base itself= is protected or not, rather than always assuming / requiring it to be prot= ected? That is, should the lowest bit in the mask map to SN_base or SN_base= +1?

Personally I'd prefer the first bit map to SN_base, so deter= mining all of the packets which are protected is calculated in the same way= (as opposed to the special case of adding SN_base to the protected list, a= nd then getting the rest from the mask).=C2=A0

I agree with Brian on this. That would also b= e consistent with how the packet masks are treated in=C2=A0ULPFEC:
   The mask field in the FEC level header indicates whi=
ch packets are
   associated with the FEC packet at the current level.  It is either 16
   or 48 bits depending on the value of the L bit.  If bit i in the mask
   is set to 1, then the media packet with sequence number N + i is
   associated with this FEC packet, where N is the SN Base field in the
   FEC packet header.  The most significant bit of the mask corresponds
   to i=3D0, and the least significant to i=3D15 when the L bit is set to 0=
,=C2=A0
=C2=A0 =C2=A0or i=3D47 when the L bit is set to 1.<= /div>

On Thu, Dec 7, 2017 at 2:21 PM, Mo Zanaty (mz= anaty) <mzanaty@cisco.com> wrote:
Hi Rasmus,

Thank you for the review and comments. We are updating the draft to ad= dress your comments as noted below (see Mo: inline).

Thanks,
Mo

From: payload <payload-bounces@ietf.org&g= t; on behalf of Rasmus Brandt <brandtr@google.com>
Date: Thursday, December 7, 2017 at= 4:48 AM
To: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] FlexFEC draf= t feedback

---------- Forwarded message ----------
From:=C2=A0Brian Baldino <brian@jitsi.org>
To:=C2=A0payload@ietf= .org
Cc:=C2=A0
Bcc:=C2=A0
Date:=C2=A0Wed, 29 Nov 2017 12:18:18 -0800
Subject:=C2=A0[payload] FlexFEC draft feedback
I've been implementing flexfec on the jitsi videobridg= e (starting with just the receive side for now) and came across a couple th= ings.=C2=A0 Also Boris Grozev has compiled some notes from his readings of = the draft; I've tried to summarize all our thoughts here:

1) It would be nice if the draft mentioned that the header extensions = of the FEC packets are totally independent of the media's header extens= ions, and that one can add extensions to FEC packets without having any eff= ect on the recovery.

2) It would be nice if the draft explicitly stated that RTP header ext= ensions (and anything in the header beyond the 12 byte fixed header, really= ) is protected as part of the payload.

3) I don't think it's explicitly mentioned that the first bit = of the mask represents a delta value of '0' (and, therefore, a '= ;1' in that bit means that the base sequence number itself is protected= ), it would be nice to call this out [in Section 6.3.1.2 maybe?]

This is alluded to in=C2=A0Sectio= n 3.2:
bitmask: =
Run-length encoding of packets protected by a FEC packet.
         If the bit i in the mask is set to 1, the source packet number =
N + i
         is protected by this FEC packet.  Here, N is the sequence number
         base, which is indicated in the FEC packet as well.
and in Section 4.2:
The SN ba=
se_i (16 bits) field indicates the lowest sequence
number, taking wrap around into account, of the source packets for
a particular SSSRC (indicated in SSRC_i) protected by this repair packet=
.


The draft is however not internally consistent, because in Section 4.2 it a=
lso says:
If the F-=
bit is set to 0, it represents that the source packets of
all the SSRCs protected by this particular repair packet are
indicated by using a flexible bitmask.  Mask is a run-length
encoding of packets for a particular SSRC_i protected by the FEC
packet.  Where a bit j set to 1 indicates that the source packet
with sequence number (SN base_i + j + 1) is protected by this FEC
packet.
which seems to be off-by-one compared to the earlier descriptions.

When using the offset-based masks, the base sequ= ence number is also inclusive:
If M>0=
, N=3D0,  is Row FEC, and no column FEC will follow
               Hence, FEC =3D SN, SN+1, SN+2, ... , SN+(M-1), SN+M.
as well as when doing pure retransmissions:
By settin=
g R to 1, F to 1, this FEC protects only one packet, i.e.,
the FEC payload carries just the packet indicated by SN Base_i, which
is effectively retransmitting the packet.


To make the descriptions consistent, I think (SN base_i + j + 1)=
=C2=A0should be replaced by
(SN base_i + j)=C2=A0in
Section 4.2.

Mo: I can see confusion here if j is zero-based so +j+1 works (which w= as the intent), or if j is one-based so +j works (which was not the intent)= . We will clarify this in 3.2, 4.2, 6.2.

Mo: A question to implementors: Do you see any value in signaling whet= her the SN_base itself is protected or not, rather than always assuming / r= equiring it to be protected? That is, should the lowest bit in the mask map= to SN_base or SN_base+1?
4) In some of the diagrams there is a typo making it look like the = 9;P' field is 2 bits instead of 1 (Figures 10, 12, 13, and 15)

4) From an implementation perspective, I found the extraction of the m= ask to be a bit of a pain due to having to extract the k bits and shift the= actual mask to get the offsets.=C2=A0 I wondered if there was a reason not= to move the second k bit next to the first to make them consecutive, followed by a consecutive mask.=C2=A0 I th= ought of two ways this might be done:

a) Put a 2 bit k field at the start of the mask.=C2=A0 There are multi= ple ways to define an encoding for those 2 bits to represent a 14, 46 or 11= 0 mask.=C2=A0 This has the downside of making the first mask 1 bit smaller = (14 bits vs 15) but does allow for encoding a 4th mask length, if so desired.

b) Put a variable (either 1 or 2) bit k field at the start of the mask= .=C2=A0 Similar to the current scheme, if the first bit was a '1' i= t would mean it was only a 15 bit mask and the second bit would not be used= to represent the mask size,=C2=A0 If the first bit was a '0', then the next bit will also be used to determine the ma= sk size. I.e.:
1 -> 15 bit mask (only one bit spent)
01 -> 46 bit mask
00 -> 110 bit mask

-brian
_______________________________________________
payload mailing list
payload@ietf.org<= br> https://www.ietf.org/mailman/listinfo/payload

_______________________________________________
payload mailing list
payload@ietf.org<= br> https://www.ietf.org/mailman/listinfo/payload


--001a11403fb864821e055fd0345d-- From nobody Fri Dec 8 04:48:36 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 46786124B17; Fri, 8 Dec 2017 04:48:34 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-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 I97wrQIwAUGE; Fri, 8 Dec 2017 04:48:30 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 E795C124D68; Fri, 8 Dec 2017 04:48:29 -0800 (PST) X-AuditID: c1b4fb3a-3d5ff70000003538-b5-5a2a8a1b3558 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 40.91.13624.B1A8A2A5; Fri, 8 Dec 2017 13:48:28 +0100 (CET) Received: from [147.214.162.243] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.90) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 8 Dec 2017 13:48:27 +0100 To: Roni Even , "payload@ietf.org" CC: "rtcweb@ietf.org" References: <6E58094ECC8D8344914996DAD28F1CCD83775A@DGGEMM506-MBX.china.huawei.com> From: Magnus Westerlund Message-ID: Date: Fri, 8 Dec 2017 13:50:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD83775A@DGGEMM506-MBX.china.huawei.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060606050603090003020403" X-Originating-IP: [153.88.183.153] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGIsWRmVeSWpSXmKPExsUyM2J7lK5Ml1aUQU8jq8Wli2eZLD4dO89i sfZfO7sDs0fLkbesHkuW/GQKYIrisklJzcksSy3St0vgynh3oIWtYN0vxor2ed9ZGhiXXmDs YuTkkBAwkei8dB7I5uIQEjjMKPFj0TZ2CGczo0TL/Q4mkCphgQiJ549us4HYIgLeEhunH2cH sZkF1CXuLD4HZgsJBEv8vDEBrJ5NwELi5o9GsHpeAXuJz2ePgm1jEVCRODJnMSuILSoQI3G4 ZzorRI2gxMmZT1hAbE6BEImlj/tZQI5gFuhmlNjw8h0rxAJtiYamDlaIs5Ukrs+7zjKBUWAW kv5ZyHpmgR0YJrHj4QUmCFtcounLSqi4rcSdubuZIWxtiWULX0PZuhKLtq1gxxS3lpjx6yAb hK0oMaX7IVSNqcTrox8ZIWwjiXd7GtkXMPKsYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3ZxAiM wYNbflvtYDz43PEQowAHoxIP77okrSgh1sSy4srcQ4wqQHMebVh9gVGKJS8/L1VJhJfLHyjN m5JYWZValB9fVJqTWnyIUZqDRUmc96Qnb5SQQHpiSWp2ampBahFMlomDU6qBUXyN9Ksls/QU J/2ziryb6SB1IntrsMm/MwEbfiuvjZOoudfe27qam3P7v0sLHr8zftHy72kKS7yRzT8Hr7e1 5ruTMiY8j5pfmtGkW9cfvSqyoexVYOu368xzzpU8qti25fZ6kZ3GT69o/9e83HLghpcGw3eZ i7J9LxizN7RVtP1d8cM0691bIyWW4oxEQy3mouJEAGXQwKzJAgAA Archived-At: Subject: Re: [payload] [rtcweb] WGLC on RTP Payload Format for Flexible Forward Error Correction 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: Fri, 08 Dec 2017 12:48:34 -0000 --------------ms060606050603090003020403 Content-Type: multipart/alternative; boundary="------------FAE74EA59A17C036B41BDBDD" Content-Language: en-GB This is a multi-part message in MIME format. --------------FAE74EA59A17C036B41BDBDD Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi, Sorry for being a day late, but here are my WGLC comments. I thought this was in better shape, but clearly not ready. I actually=20 have not reviewed all in detail. I hope I will have time to do that when = you have addressed these issues. 1. Section 4.2: =A0 =A0=A0 =A0=A0=A0=A0=A0=A0 +------------------------------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 IP Header= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------------------------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0 Transport Header=A0= =A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------------------------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 RTP Heade= r=A0=A0=A0=A0=A0=A0=A0=A0=A0 | __ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------------------------+=A0=A0= | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 FEC Heade= r=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 \ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------------------------+=A0=A0= =A0=A0 > RTP Payload =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 Repair Symbols=A0= =A0=A0=A0=A0=A0=A0 |=A0=A0=A0 / =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------------------------+ __| =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Figure 9: Form= at of repair packets The bracket appears to big as it indicates that parts of the RTP header=20 is payload. I would prefer drawing this like this: =A0=A0=A0=A0=A0=A0 =A0 =A0=A0 +------------------------------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 IP Header= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------------------------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0 Transport Header=A0= =A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------------------------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 RTP Heade= r=A0=A0=A0=A0=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------------------------+ --+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 FEC Heade= r=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 \ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------------------------+=A0=A0= =A0=A0 > RTP Payload =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 Repair Symbols=A0= =A0=A0=A0=A0=A0=A0 |=A0=A0=A0 / =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------------------------+ --+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Figure 9: Form= at of repair packets 2. Section 4.2: =A0=A0 o=A0 Synchronization Source (SSRC): The SSRC value SHALL be rando= mly =A0=A0=A0=A0=A0 assigned as suggested by [RFC3550]. I would suggest that you make it clear that the SSRC value should be set = randomly for a particular Repair flow, to avoid the misinterpretation=20 that each packet should have a random SSRC value. 3. Section 4.2: This allows the sender to =A0=A0=A0=A0=A0 multiplex the source and repair flows on the same port, = or =A0=A0=A0=A0=A0 multiplex multiple repair flows on a single port. I would suggest that you rewrite this like this: This allows the sender to =A0=A0=A0=A0=A0 multiplex the source and repair flows in the same RTP se= ssion, or =A0=A0=A0=A0=A0 multiplex multiple repair flows in a single RTP session.= 4. Section 4.2: The repair =A0=A0=A0=A0=A0 flows SHOULD use the RTCP CNAME field to associate thems= elves with =A0=A0=A0=A0=A0 the source flow. I think you should reformulate this to be more precise to say: The repair =A0=A0=A0=A0=A0 flows SHOULD use the same RTCP SDES CNAME value as the s= ource=20 flows to associate them when source and repair flows originate from the same endpoint. 5. Section 4.2: =A0=A0=A0=A0=A0 In some networks, the RTP Source, which produces the sou= rce =A0=A0=A0=A0=A0 packets and the FEC Source, which generates the repair p= ackets =A0=A0=A0=A0=A0 from the source packets may not be the same host.=A0 In = such =A0=A0=A0=A0=A0 scenarios, using the same CNAME for the source and repai= r flows =A0=A0=A0=A0=A0 means that the RTP Source and the FEC Source MUST share = the same =A0=A0=A0=A0=A0 CNAME (for this specific source-repair flow association)= =2E=A0 A =A0=A0=A0=A0=A0 common CNAME may be produced based on an algorithm that = is known =A0=A0=A0=A0=A0 both to the RTP and FEC Source [RFC7022].=A0 This usage = is compliant =A0=A0=A0=A0=A0 with [RFC3550]. I think this may actually be the wrong way of handling this. Is it=20 really important that the CNAME can be used to determine which SSRC are=20 plausible as source flows for a given repair flow. If we skip that=20 feature, one can use CNAMES as usual where they are primarily depending=20 on the endpoint that originates the RTP flow with a given SSRC and the=20 synchronization context. As the repair packet is indicating explicitly=20 which source packets, this should not be a real issue. Thus, I suggest that the above text removes sentence with MUST. Instead=20 one could add the following sentence directly after the propsed sentence = in issue 4: However, repair flows that protects source flows from multiple different = endpoints SHOULD instead use a CNAME value associated with the Repair=20 Flow sending endpoint. And the above text could be deleted. 6. Section 4.2: Figure 9 should include the CSRC list and the FEC payload formats use of = the CSRC list should be listed prior to Figure 10. This as the CSRC list = is part of the RTP header. 7. Section 4.2: =A0=A0 o=A0 The SN base_i (16 bits) field indicates the lowest sequence =A0=A0=A0=A0=A0 number, taking wrap around into account, of the source p= ackets for =A0=A0=A0=A0=A0 a particular SSSRC (indicated in CSRC_i) protected by th= is repair =A0=A0=A0=A0=A0 packet. Note spelling SSSRC / SSRC. 8. Label on Figures 12, 13, 15: They all says "Protocol format for ..." While I think for clarity they should say: "Payload FEC header format=20 for ..." 9. Section 4.2: =A0=A0 Note that the parsing of this packet is different.=A0 The sequenc= e =A0=A0 number (SN base_i) replaces the length recovery in the FEC packet= =2E =A0=A0 The CSRC Count (CC) which would be 1, M and N would be set to 0, = and =A0=A0 the reserved bits from the FEC header are removed.=A0 By doing th= is, we =A0=A0 save 64 bits. I actually don't fully understand this paragraph: In the third sentence: Why will the CC field be 1? This is the CC field=20 value of the reconstructed (retransmitted) packet, isn't it? Thus, you=20 can't say anything about its original value here? The CC field value in=20 the RTP header of the FEC packet will have CC =3D 1, but not this field. Then you have a confusion around what M and N is. Actually, I think the=20 M (Columns) needs to change letter to something that isn't used in the=20 packet already. M is colliding with M (marker bit) recovery field, thus=20 please change the letter. 10. Figure 15: When retransmitting an packet, where is the source packets CSRC list=20 going? That should be indicated in this figure for clarity. Same is true = for RTP header Extensions present in the source packet. 11. Section 6.2: =A0=A0 The FEC header includes 12 octets (or upto 28 octets when the lon= ger =A0=A0 optional masks are used). This is not strictly true, it is dependent on the number of SSRCs that=20 the packet repairs. 12. Section 6.2: Missing discussion of what to do with source packet CSRC list and RTP=20 header extension. 13. Section 6.3.2: Missing text for recovery of source packets CSRC list and RTP header=20 extensions. 14. Section 6.2: =A0=A0 Due to this possible padding and mandatory FEC header, a repair =A0=A0 packet has a larger size than the source packets it protects. Thi= s =A0=A0 may cause problems if the resulting repair packet size exceeds th= e =A0=A0 Maximum Transmission Unit (MTU) size of the path over which the =A0=A0 repair flow is sent. I think this should add a recommendation that the media encoding and RTP = payload packetization for source packets should be adjusted to a lower=20 maximum packet size to allow space for the FEC headers to avoid forcing=20 them into being fragmented. This of course only is possible in cases=20 where the source packet generating endpoint is aware of the addition of=20 the FEC packets and its strategy of combining them. Cheers Magnus Den 2017-11-17 kl. 03:35, skrev Roni Even: > > Hi, > > I would like to start a three week WGLC on RTP Payload Format for=20 > Flexible Forward Error Correction in=20 > draft-ietf-payload-flexible-fec-scheme-05=20 > = =2E > > The WGLC will end on November 7^th > > Mo has posted some clarifications to the payload WG mailing list=20 > payload mailing list archives=20 > > > Please send comments to the payload mailing list. > > THe double posting is to =A0notify RTCweb WG that the WGLC has started = > since this document is needed for RTCweb > > Roni Even > > Payload WG co-chair > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------FAE74EA59A17C036B41BDBDD Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi,

Sorry for being a day late, but here are my WGLC comments.

I thought this was in better shape, but clearly not ready. I actually have not reviewed all in detail. I hope I will have time to do that when you have addressed these issues.


1. Section 4.2:

=A0 =A0=A0 =A0=A0=A0=A0=A0=A0 +------------------------------+=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0= =A0 IP Header=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-----------------------= -------+
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0 Tran= sport Header=A0=A0=A0=A0=A0=A0 |
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-----------------------= -------+
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0= =A0 RTP Header=A0=A0=A0=A0=A0=A0=A0=A0=A0 | __
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-----------------------= -------+=A0=A0 |
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0= =A0 FEC Header=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 \
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-----------------------= -------+=A0=A0=A0=A0 > RTP Payload
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 R= epair Symbols=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 /
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-----------------------= -------+ __|

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Figure 9:= Format of repair packets

The bracket appears to big as it indicates that parts of the RTP header is payload. I would prefer drawing this like this:

=A0=A0=A0=A0=A0=A0 =A0 =A0=A0 +------------------------------+=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0= =A0 IP Header=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-----------------------= -------+
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0 Tran= sport Header=A0=A0=A0=A0=A0=A0 |
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-----------------------= -------+
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0= =A0 RTP Header=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-----------------------= -------+ --+=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0= =A0 FEC Header=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 \
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-----------------------= -------+=A0=A0=A0=A0 > RTP Payload
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 R= epair Symbols=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 /
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-----------------------= -------+ --+

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Figure 9: Format of repair packets

2. Section 4.2:

=A0=A0 o=A0 Synchronization Source (SSRC): The SSRC value SHALL be= randomly
=A0=A0=A0=A0=A0 assigned as suggested by [RFC3550].

I would suggest that you make it clear that the SSRC value should be set randomly for a particular Repair flow, to avoid the misinterpretation that each packet should have a random SSRC value.

3. Section 4.2:

This allows the sender to
=A0=A0=A0=A0=A0 multiplex the source and repair flows on the same p= ort, or
=A0=A0=A0=A0=A0 multiplex multiple repair flows on a single port.

I would suggest that you rewrite this like this:

This allows the sender to
=A0=A0=A0=A0=A0 multiplex the source and repair flows in the same R= TP session, or
=A0=A0=A0=A0=A0 multiplex multiple repair flows in a single RTP ses= sion.

4. Section 4.2:

The repair
=A0=A0=A0=A0=A0 flows SHOULD use the RTCP CNAME field to associate themselves with
=A0=A0=A0=A0=A0 the source flow.

I think you should reformulate this to be more precise to say:

=

The repair
=A0=A0=A0=A0=A0 flows SHOULD use the same RTCP SDES CNAME value as = the source flows to associate them when
source and repair flows originate from the same endpoint.


5. Section 4.2:

=A0=A0=A0=A0=A0 In some networks, the RTP Source, which produces t= he source
=A0=A0=A0=A0=A0 packets and the FEC Source, which generates the rep= air packets
=A0=A0=A0=A0=A0 from the source packets may not be the same host.=A0= In such
=A0=A0=A0=A0=A0 scenarios, using the same CNAME for the source and = repair flows
=A0=A0=A0=A0=A0 means that the RTP Source and the FEC Source MUST s= hare the same
=A0=A0=A0=A0=A0 CNAME (for this specific source-repair flow associa= tion).=A0 A
=A0=A0=A0=A0=A0 common CNAME may be produced based on an algorithm = that is known
=A0=A0=A0=A0=A0 both to the RTP and FEC Source [RFC7022].=A0 This u= sage is compliant
=A0=A0=A0=A0=A0 with [RFC3550].

I think this may actually be the wrong way of handling this. Is it really important that the CNAME can be used to determine which SSRC are plausible as source flows for a given repair flow. If we skip that feature, one can use CNAMES as usual where they are primarily depending on the endpoint that originates the RTP flow with a given SSRC and the synchronization context. As the repair packet is indicating explicitly which source packets, this should not be a real issue.

Thus, I suggest that the above text removes sentence with MUST. Instead one could add the following sentence directly after the propsed sentence in issue 4:

However, repair flows that protects source flows from multiple different endpoints SHOULD instead use a CNAME value associated with the Repair Flow sending endpoint.

And the above text could be deleted.


6. Section 4.2:

Figure 9 should include the CSRC list and the FEC payload formats use of the CSRC list should be listed prior to Figure 10. This as the CSRC list is part of the RTP header.

7. Section 4.2:

=A0=A0 o=A0 The SN base_i (16 bits) field indicates the lowest seq= uence
=A0=A0=A0=A0=A0 number, taking wrap around into account, of the sou= rce packets for
=A0=A0=A0=A0=A0 a particular SSSRC (indicated in CSRC_i) protected = by this repair
=A0=A0=A0=A0=A0 packet.

Note spelling SSSRC / SSRC.

8. Label on Figures 12, 13, 15:

They all says "Protocol format for ..."

While I think for clarity they should say: "Payload FEC header format for ..."

9. Section 4.2:

=A0=A0 Note that the parsing of this packet is different.=A0 The sequence
=A0=A0 number (SN base_i) replaces the length recovery in the FEC packet.
=A0=A0 The CSRC Count (CC) which would be 1, M and N would be set t= o 0, and
=A0=A0 the reserved bits from the FEC header are removed.=A0 By doi= ng this, we
=A0=A0 save 64 bits.

I actually don't fully understand this paragraph:

In the third sentence: Why will the CC field be 1? This is the CC field value of the reconstructed (retransmitted) packet, isn't it? Thus, you can't say anything about its original value here? The CC field value in the RTP header of the FEC packet will have CC =3D 1,= but not this field.=A0

Then you have a confusion around what M and N is. Actually, I think the M (Columns) needs to change letter to something that isn't used in the packet already. M is colliding with M (marker bit) recovery field, thus please change the letter.

10. Figure 15:

When retransmitting an packet, where is the source packets CSRC list going? That should be indicated in this figure for clarity. Same is true for RTP header Extensions present in the source packet.

11. Section 6.2:

=A0=A0 The FEC header includes 12 octets (or upto 28 octets when t= he longer
=A0=A0 optional masks are used).=A0

This is not strictly true, it is dependent on the number of SSRCs that the packet repairs.

12. Section 6.2:

Missing discussion of what to do with source packet CSRC list and RTP header extension.

13. Section 6.3.2:

Missing text for recovery of source packets CSRC list and RTP header extensions.

14. Section 6.2:

=A0=A0 Due to this possible padding and mandatory FEC header, a repair
=A0=A0 packet has a larger size than the source packets it protects= =2E=A0 This
=A0=A0 may cause problems if the resulting repair packet size excee= ds the
=A0=A0 Maximum Transmission Unit (MTU) size of the path over which = the
=A0=A0 repair flow is sent.

I think this should add a recommendation that the media encoding and RTP payload packetization for source packets should be adjusted to a lower maximum packet size to allow space for the FEC headers to avoid forcing them into being fragmented. This of course only is possible in cases where the source packet generating endpoint is aware of the addition of the FEC packets and its strategy of combining them.

Cheers

Magnus



Den 2017-11-17 kl. 03:35, skrev Roni Even:

Hi,

I would like to start a three week WGLC on= RTP Payload Format for Flexible Forward Error Correction in draft-ietf-payload-flexible-fec-scheme-05.<= /o:p>

The WGLC will end on November 7th

=A0

Mo has posted some clarifications to the payload WG mailing list =A0payload mailing list archives

=A0

Please send comments to the payload mailin= g list.

THe double posting is to =A0notify RTCweb WG that the WGLC has started since this document is needed for RTCweb

=A0=

=A0=

Roni Even=

Payload WG co-chair

=A0=

=A0



_______________________________________________
rtcweb mailing list
rtc=
web@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


--=20

Magnus Westerlund=20

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@erics=
son.com
----------------------------------------------------------------------
  


--------------FAE74EA59A17C036B41BDBDD--

--------------ms060606050603090003020403
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME-kryptografisk signatur

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DLkwggX7MIID46ADAgECAhEA75oIXW3eBHJH2u7brn5gnDANBgkqhkiG9w0BAQUFADA6MREw
DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2
MjAeFw0xNTAxMjMwODUwNTdaFw0xODAxMjMwODUwNTdaMHAxETAPBgNVBAoMCEVyaWNzc29u
MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndl
c3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAkULrp/ViIWFfDbY2Ycew0bXJc2In2WNQbPORLyFXNpRhjhmg
ot5P/0w90T4HY0H6QayjIPK6qIGt1DBXwkq/QHoRsFZiDK9JDnk2WUDcqbJaHqMXvkhj4Jl4
KvonZ31T3NF/8OlcEjumVc8AUA6iccOeUva3TvL/EOqY3f4bsem4ER3KAcY/lTPWivSY+/Aw
vS64JjaANOHVhZ0LUj10JTe9CpdXB+1nMpqLFYkjse/2ahQuKyaBKhKJs35pSYijh3Ln+vMv
YUNEna2LjHvkCPVo5Oihylxjmd1OSDXND7125tgo/kB08RtaJ9u6PNw0CoUgA+d23UzVzlYg
aSJbhwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50
ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0
MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAC
hjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs
Y2F2Mi5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMFUG
A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np
dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjAdBgNVHQ4EFgQUwff+Y5pMEPJX7xortCv8deSKeQEwHwYDVR0jBBgwFoAUsQ3K
1Ea3r4YCwy9vBsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQBy
rk0JhGgu9Fd/0Fg1cMhSa882HMQZWQLT1V4PFQpU6t2an8xaqT5JsxOpuxb+WxwpKG+UDbzQ
cWgcb/DPW3Mc0AvhTFII1qAYf6Smkq6SOD/8TACjH+dy7JrbcNYJcTlVNBlC/V/C+waICkER
wuMC/8QjXs0ExJekAD3i/3GUok9WnvEHsohIL04qk1lbvJN4WGHCHFercX11Ch+UjStHwtyw
zyFWi64CqD48kKqPwEne3Lj7ozxzuwCCaJI9fmCQgLfSL+UcDgEb7cQucMAnB/Zxlz6U6ohd
PRlQHaLevAYD2UK+BlhZKLAv/DNUz0nk6fx4CiJF5DIRteUdzGoeGcnWMWO9hv5PkEJC1WkZ
gYXZ/91HMUjsYUuy5/EsmkqvkCalRudoqe6Pex3A34iFGNvDhI3fCrbvmRS4FARPse5D8BLu
e/PIvAPNUC7xl8UcfnTNVgy5ITzWNiY9hIrbAzfPbTXyZSIdMD+HTNg33ziMbu2Iry/2eS1X
/whXkApnQNpHplvzf1xMEeNPlDKtL8OOg+9y4ESdn27EKxeeaaFXsrhb3z1woIjQxXINft5W
EPXWnks/YBCvrLTH8kRCLZgH17zDxb+MLqKj1XUQtBKgDhb+VswJM6GF+dDeBJoEYjvLR1Sx
l5yfaRj0F7HYkjRUwyehwSHgTVqtgnT9QjCCBrYwggSeoAMCAQICEQCgDMvMm5mY7OI6cPR8
wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZU
ZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVow
OjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwg
Q0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4
Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWX
hPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehB
raHZabrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI
7LvMiZtVaqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd
0D7TGJtkdldVJtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGj
A/CxX9aC5Vi1EMRJiOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2F
GBaauE8qHEO6qR3WAEgvjVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXd
vo+6eAt45Bhvmeka2TrJDxMLWiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzx
b3nT1iHue5co9J93ta06kxiASHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0
Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYh
aHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8v
cmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j
ZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgG
CCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQ
UzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29t
L3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD
BDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1Ud
IwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3
PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n
65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+x
hsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fv
dcy04/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdnes
s3e1qAEueSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZW
Os38FQhGWHWXI0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9byw
hEfXjxLIC3Qhtu5lJPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92w
behSZD3mSSAemDVwGB2Yu0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEm
Jqe6g4XSQFj4mqtwvqhP4dg2QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/em
OtwCGXQ6tZCByMNLxeDwU1TGbTGCAxcwggMTAgEBME8wOjERMA8GA1UECgwIRXJpY3Nzb24x
JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuu
fmCcMA0GCWCGSAFlAwQCAQUAoIIBmTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNzEyMDgxMjUwNTBaMC8GCSqGSIb3DQEJBDEiBCAaS7ALooeleiw55BVO
0QDP8U6mYkU3eodbYXxBJMhytDBeBgkrBgEEAYI3EAQxUTBPMDoxETAPBgNVBAoMCEVyaWNz
c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEA75oIXW3eBHJH
2u7brn5gnDBgBgsqhkiG9w0BCRACCzFRoE8wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV
BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuufmCcMGwG
CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
DQYJKoZIhvcNAQEBBQAEggEAhpx5JMKxcUF2NiSX3UKXJ+LvYpjwx5DGqCK0Ac4k3ad/wEiG
yh13GdOrEPLl2rl2V9TX88mCy+l4JZ6NPKHxC00qFPBKnR3AiID1I3353DYc7DbH0wQP4aNi
wZTKKmgVzvO/vQvu+JitXAVv6frjSsM2IgiAhu8GE9dhPta4/Y/ZpEO1e3nePocSgUTb8C5+
iHTtcccs4LPGs9U8SYSfYtkk6Z5pXfyqzn0siy1q6nsA+9s6aNu3t1FHW8E4lYPNkIFgAOxj
uix7r5IChbdALRFnC3iVUKi3tvG9q1BFQEp3lEbtCjiLhM9f9cmErvEgx7TzXZ4dDRQUYcUf
+RwQnwAAAAAAAA==
--------------ms060606050603090003020403--


From nobody Fri Dec  8 10:52:39 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 E1AE3128B38; Fri,  8 Dec 2017 10:52:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 r-SiZG_hNqRi; Fri,  8 Dec 2017 10:52:34 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33A34128B8E; Fri,  8 Dec 2017 10:52:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32185; q=dns/txt; s=iport; t=1512759154; x=1513968754; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=D6ioEaPly2C/UqpwDqT7GAdGGyIo5w965SDsW6rv5Bo=; b=ZhdisYbWBC86ILrlXAJdEL0ijAEjmzPCwhQ7CXD/aTbrQ736pLOGyICc C9D5HpNSr+WBxkO+M1IKKGFXm00Q/8Nd+BpqwsrbUIf9QfJc70nGeA/Kw 0k6AHsKXsGLDI15EF2x8bblIXKNgzBs6NYygHRm96yBS0rTz/FyVCtplR 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C5AADu3Spa/4oNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKRS9mdCcHjhyPAYF9lwwUggEKGAEKhElPAoRfPxgBAQEBAQE?= =?us-ascii?q?BAQFrKIUiAQEBAQMBAStBCw4CAgEIEQMBAhYLBwcbDAsUCQgCBAENBQmJO2QQq?= =?us-ascii?q?jMmij4BAQEBAQEBAQEBAQEBAQEBAQEBAQEdBYNWgguBVoFpgyuCWEsmgRERHDg?= =?us-ascii?q?fhTkFikWYQwKHd40nghaGEos5ikCCSIknAhEZAYE6AR85JoEpbxU6gikJgkYfG?= =?us-ascii?q?YFOeIkhgRUBAQE?=
X-IronPort-AV: E=Sophos; i="5.45,378,1508803200"; d="scan'208,217"; a="41626922"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Dec 2017 18:52:33 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id vB8IqXMF016055 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Dec 2017 18:52:33 GMT
Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 8 Dec 2017 12:52:32 -0600
Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1320.000; Fri, 8 Dec 2017 12:52:32 -0600
From: "Mo Zanaty (mzanaty)" 
To: Magnus Westerlund , Roni Even , "payload@ietf.org" 
CC: "rtcweb@ietf.org" 
Thread-Topic: [payload] [rtcweb] WGLC on RTP Payload Format for Flexible Forward Error Correction
Thread-Index: AQHTcFW0HojzYcah6EWMBE4vaDiXiA==
Date: Fri, 8 Dec 2017 18:52:32 +0000
Message-ID: 
References: <6E58094ECC8D8344914996DAD28F1CCD83775A@DGGEMM506-MBX.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.3.170325
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.217.90]
Content-Type: multipart/alternative; boundary="_000_D65040BB7693Dmzanatyciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [payload] [rtcweb] WGLC on RTP Payload Format for Flexible Forward Error Correction
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: Fri, 08 Dec 2017 18:52:38 -0000

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

Hi Magnus,

Thank you for the review and comments. We are updating the draft to address=
 your comments as noted below (see Mo: inline).

Thanks,
Mo


From: payload > o=
n behalf of 'Magnus Westerlund' >
Date: Friday, December 8, 2017 at 7:50 AM
To: Roni Even >, "payload=
@ietf.org" >
Cc: "rtcweb@ietf.org" >
Subject: Re: [payload] [rtcweb] WGLC on RTP Payload Format for Flexible For=
ward Error Correction


Hi,

Sorry for being a day late, but here are my WGLC comments.

I thought this was in better shape, but clearly not ready. I actually have =
not reviewed all in detail. I hope I will have time to do that when you hav=
e addressed these issues.


1. Section 4.2:

            +------------------------------+
            |          IP Header           |
            +------------------------------+
            |       Transport Header       |
            +------------------------------+
            |          RTP Header          | __
            +------------------------------+   |
            |          FEC Header          |    \
            +------------------------------+     > RTP Payload
            |        Repair Symbols        |    /
            +------------------------------+ __|

                    Figure 9: Format of repair packets

The bracket appears to big as it indicates that parts of the RTP header is =
payload. I would prefer drawing this like this:

            +------------------------------+
            |          IP Header           |
            +------------------------------+
            |       Transport Header       |
            +------------------------------+
            |          RTP Header          |
            +------------------------------+ --+
            |          FEC Header          |    \
            +------------------------------+     > RTP Payload
            |        Repair Symbols        |    /
            +------------------------------+ --+

                    Figure 9: Format of repair packets

Mo: Agreed, we will update the ASCII art.


2. Section 4.2:

   o  Synchronization Source (SSRC): The SSRC value SHALL be randomly
      assigned as suggested by [RFC3550].

I would suggest that you make it clear that the SSRC value should be set ra=
ndomly for a particular Repair flow, to avoid the misinterpretation that ea=
ch packet should have a random SSRC value.

Mo: Agreed, will do.


3. Section 4.2:

This allows the sender to
      multiplex the source and repair flows on the same port, or
      multiplex multiple repair flows on a single port.

I would suggest that you rewrite this like this:

This allows the sender to
      multiplex the source and repair flows in the same RTP session, or
      multiplex multiple repair flows in a single RTP session.

Mo: Agreed, we will reword as suggested.


4. Section 4.2:

The repair
      flows SHOULD use the RTCP CNAME field to associate themselves with
      the source flow.

I think you should reformulate this to be more precise to say:

The repair
      flows SHOULD use the same RTCP SDES CNAME value as the source flows t=
o associate them when
source and repair flows originate from the same endpoint.

Mo: Per the point below, I am inclined to remove CNAME guidance or restrict=
ions entirely, since they seem irrelevant.


5. Section 4.2:

      In some networks, the RTP Source, which produces the source
      packets and the FEC Source, which generates the repair packets
      from the source packets may not be the same host.  In such
      scenarios, using the same CNAME for the source and repair flows
      means that the RTP Source and the FEC Source MUST share the same
      CNAME (for this specific source-repair flow association).  A
      common CNAME may be produced based on an algorithm that is known
      both to the RTP and FEC Source [RFC7022].  This usage is compliant
      with [RFC3550].

I think this may actually be the wrong way of handling this. Is it really i=
mportant that the CNAME can be used to determine which SSRC are plausible a=
s source flows for a given repair flow. If we skip that feature, one can us=
e CNAMES as usual where they are primarily depending on the endpoint that o=
riginates the RTP flow with a given SSRC and the synchronization context. A=
s the repair packet is indicating explicitly which source packets, this sho=
uld not be a real issue.

Thus, I suggest that the above text removes sentence with MUST. Instead one=
 could add the following sentence directly after the propsed sentence in is=
sue 4:

However, repair flows that protects source flows from multiple different en=
dpoints SHOULD instead use a CNAME value associated with the Repair Flow se=
nding endpoint.

And the above text could be deleted.

Mo: Since all source and repair streams must be in the same RTP session, I =
agree CNAME is mostly irrelevant, and I am inclined to remove all mention o=
f CNAME, except maybe to say it should follow RFC 7022.


6. Section 4.2:

Figure 9 should include the CSRC list and the FEC payload formats use of th=
e CSRC list should be listed prior to Figure 10. This as the CSRC list is p=
art of the RTP header.

Mo: Agreed, the text on CSRC_i / list will move up before Figure 10.


7. Section 4.2:

   o  The SN base_i (16 bits) field indicates the lowest sequence
      number, taking wrap around into account, of the source packets for
      a particular SSSRC (indicated in CSRC_i) protected by this repair
      packet.

Note spelling SSSRC / SSRC.

Mo: Noted.


8. Label on Figures 12, 13, 15:

They all says "Protocol format for ..."

While I think for clarity they should say: "Payload FEC header format for .=
.."

Mo: Ok, we will rename the labels.


9. Section 4.2:

   Note that the parsing of this packet is different.  The sequence
   number (SN base_i) replaces the length recovery in the FEC packet.
   The CSRC Count (CC) which would be 1, M and N would be set to 0, and
   the reserved bits from the FEC header are removed.  By doing this, we
   save 64 bits.

I actually don't fully understand this paragraph:

In the third sentence: Why will the CC field be 1? This is the CC field val=
ue of the reconstructed (retransmitted) packet, isn't it? Thus, you can't s=
ay anything about its original value here? The CC field value in the RTP he=
ader of the FEC packet will have CC =3D 1, but not this field.

Then you have a confusion around what M and N is. Actually, I think the M (=
Columns) needs to change letter to something that isn't used in the packet =
already. M is colliding with M (marker bit) recovery field, thus please cha=
nge the letter.

Mo: We will clarify this by splitting into separate sections for each repai=
r format variant, and perhaps use L/D instead of M/N (to match the SDP para=
meters L/D).


10. Figure 15:

When retransmitting an packet, where is the source packets CSRC list going?=
 That should be indicated in this figure for clarity. Same is true for RTP =
header Extensions present in the source packet.

Mo: We will clarify this by splitting into separate sections for each repai=
r format variant. For all variants, all bytes after 12 (including any CSRC =
list or extension headers) are considered "payload" (we will find a better =
word for this since payload is obviously very overloaded).


11. Section 6.2:

   The FEC header includes 12 octets (or upto 28 octets when the longer
   optional masks are used).

This is not strictly true, it is dependent on the number of SSRCs that the =
packet repairs.

Mo: Yes, we will clarify this.


12. Section 6.2:

Missing discussion of what to do with source packet CSRC list and RTP heade=
r extension.

Mo: Yes, the updates to section 4.2 will be echoed in 6.2.


13. Section 6.3.2:

Missing text for recovery of source packets CSRC list and RTP header extens=
ions.

Mo: Yes, we will add this.


14. Section 6.2:

   Due to this possible padding and mandatory FEC header, a repair
   packet has a larger size than the source packets it protects.  This
   may cause problems if the resulting repair packet size exceeds the
   Maximum Transmission Unit (MTU) size of the path over which the
   repair flow is sent.

I think this should add a recommendation that the media encoding and RTP pa=
yload packetization for source packets should be adjusted to a lower maximu=
m packet size to allow space for the FEC headers to avoid forcing them into=
 being fragmented. This of course only is possible in cases where the sourc=
e packet generating endpoint is aware of the addition of the FEC packets an=
d its strategy of combining them.

Mo: Agreed, this seems like an appropriate recommendation, so we will add i=
t.


Cheers

Magnus


Den 2017-11-17 kl. 03:35, skrev Roni Even:
Hi,
I would like to start a three week WGLC on RTP Payload Format for Flexible =
Forward Error Correction in draft-ietf-payload-flexible-fec-scheme-05.
The WGLC will end on November 7th

Mo has posted some clarifications to the payload WG mailing list  payload m=
ailing list archives

Please send comments to the payload mailing list.
THe double posting is to  notify RTCweb WG that the WGLC has started since =
this document is needed for RTCweb


Roni Even
Payload WG co-chair





_______________________________________________
rtcweb mailing list
rtcweb@ietf.orghttps://www.ietf.org/mailman/listinf=
o/rtcweb


--

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

--_000_D65040BB7693Dmzanatyciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <56E745B5E32A664287FEDE446939460A@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Hi Magnus,











Thank you for the review and comments. We are updating the draft to ad=
dress your comments as noted below (see Mo: inline).







Thanks,


Mo


















From: payload <payload-bounces@ietf.org> on behalf of 'M=
agnus Westerlund' <mag=
nus.westerlund@ericsson.com>

Date: Friday, December 8, 2017 at 7=
:50 AM

To: Roni Even <roni.even@huawei.com>, "payload@ietf.org" <payload@ietf.org>

Cc: "rtcweb@ietf.org" <=
rtcweb@ietf.org>

Subject: Re: [payload] [rtcweb] WGL=
C on RTP Payload Format for Flexible Forward Error Correction













Hi,


Sorry for being a day late, but here are my WGLC comments.


I thought this was in better shape, but clearly not ready. I actually ha=
ve not reviewed all in detail. I hope I will have time to do that when you =
have addressed these issues.










1. Section 4.2:




            +------=
------------------------+

           =
 |          IP Header &nb=
sp;         |

           =
 +------------------------------+

           =
 |       Transport Header   &n=
bsp;   |

           =
 +------------------------------+

           =
 |          RTP Header &n=
bsp;        | __

           =
 +------------------------------+   |

           =
 |          FEC Header &n=
bsp;        |    \

           =
 +------------------------------+     > RTP =
Payload

           =
 |        Repair Symbols  &nbs=
p;     |    /

           =
 +------------------------------+ __|



            &nb=
sp;       Figure 9: Format of repair packets<=
br>



The bracket appears to big as it indicates that parts of the RTP header =
is payload. I would prefer drawing this like this:


            +------=
------------------------+

           =
 |          IP Header &nb=
sp;         |

           =
 +------------------------------+

           =
 |       Transport Header   &n=
bsp;   |

           =
 +------------------------------+

           =
 |          RTP Header &n=
bsp;        | 

           =
 +------------------------------+ --+  

           =
 |          FEC Header &n=
bsp;        |    \

           =
 +------------------------------+     > RTP =
Payload

           =
 |        Repair Symbols  &nbs=
p;     |    /

           =
 +------------------------------+ --+



           =
         Figure 9: Format of repair=
 packets














Mo: Agreed, we will update the ASCII art.












2. Section 4.2:


   o  Synchronization Source (SSRC): The SSRC value SHALL=
 be randomly

      assigned as suggested by [RFC3550]. 




I would suggest that you make it clear that the SSRC value should be set=
 randomly for a particular Repair flow, to avoid the misinterpretation that=
 each packet should have a random SSRC value.













Mo: Agreed, will do.












3. Section 4.2:


This allows the sender to

      multiplex the source and repair flows on the=
 same port, or

      multiplex multiple repair flows on a single =
port.


I would suggest that you rewrite this like this:


This allows the sender to

      multiplex the source and repair flows in the=
 same RTP session, or

      multiplex multiple repair flows in a single =
RTP session.












Mo: Agreed, we will reword as suggested.












4. Section 4.2:


The repair

      flows SHOULD use the RTCP CNAME field to ass=
ociate themselves with

      the source flow.


I think you should reformulate this to be more precise to say:


The repair

      flows SHOULD use the same RTCP SDES CNAME va=
lue as the source flows to associate them when

source and repair flows originate from the same endpoint. 




Mo: Per the point below, I am inclined to remove CNAME guidance or restr=
ictions entirely, since they seem irrelevant.

















5. Section 4.2:


      In some networks, the RTP Source, which p=
roduces the source

      packets and the FEC Source, which generates =
the repair packets

      from the source packets may not be the same =
host.  In such

      scenarios, using the same CNAME for the sour=
ce and repair flows

      means that the RTP Source and the FEC Source=
 MUST share the same

      CNAME (for this specific source-repair flow =
association).  A

      common CNAME may be produced based on an alg=
orithm that is known

      both to the RTP and FEC Source [RFC7022].&nb=
sp; This usage is compliant

      with [RFC3550].




I think this may actually be the wrong way of handling this. Is it reall=
y important that the CNAME can be used to determine which SSRC are plausibl=
e as source flows for a given repair flow. If we skip that feature, one can=
 use CNAMES as usual where they
 are primarily depending on the endpoint that originates the RTP flow with =
a given SSRC and the synchronization context. As the repair packet is indic=
ating explicitly which source packets, this should not be a real issue.





Thus, I suggest that the above text removes sentence with MUST. Instead =
one could add the following sentence directly after the propsed sentence in=
 issue 4:


However, repair flows that protects source flows from multiple different=
 endpoints SHOULD instead use a CNAME value associated with the Repair Flow=
 sending endpoint.


And the above text could be deleted. 




Mo: Since all source and repair streams must be in the same RTP session,=
 I agree CNAME is mostly irrelevant, and I am inclined to remove all mentio=
n of CNAME, except maybe to say it should follow RFC 7022.

















6. Section 4.2: 




Figure 9 should include the CSRC list and the FEC payload formats use of=
 the CSRC list should be listed prior to Figure 10. This as the CSRC list i=
s part of the RTP header.








Mo: Agreed, the text on CSRC_i / list will move up before Figure 10.&n=
bsp;












7. Section 4.2:


   o  The SN base_i (16 bits) field indicates the lowest =
sequence

      number, taking wrap around into account, of =
the source packets for

      a particular SSSRC (indicated in CSRC_i) pro=
tected by this repair

      packet.


Note spelling SSSRC / SSRC.












Mo: Noted.












8. Label on Figures 12, 13, 15:


They all says "Protocol format for ..."


While I think for clarity they should say: "Payload FEC header form=
at for ..."












Mo: Ok, we will rename the labels.












9. Section 4.2:


   Note that the parsing of this packet is different.  Th=
e sequence

   number (SN base_i) replaces the length recovery in the FEC pac=
ket.

   The CSRC Count (CC) which would be 1, M and N would be set to =
0, and

   the reserved bits from the FEC header are removed.  By do=
ing this, we

   save 64 bits.




I actually don't fully understand this paragraph: 




In the third sentence: Why will the CC field be 1? This is the CC field =
value of the reconstructed (retransmitted) packet, isn't it? Thus, you can'=
t say anything about its original value here? The CC field value in the RTP=
 header of the FEC packet will have
 CC =3D 1, but not this field. 


Then you have a confusion around what M and N is. Actually, I think the =
M (Columns) needs to change letter to something that isn't used in the pack=
et already. M is colliding with M (marker bit) recovery field, thus please =
change the letter.













Mo: We will clarify this by splitting into separate sections for each =
repair format variant, and perhaps use L/D instead of M/N (to match the SDP=
 parameters L/D).












10. Figure 15:


When retransmitting an packet, where is the source packets CSRC list goi=
ng? That should be indicated in this figure for clarity. Same is true for R=
TP header Extensions present in the source packet.








Mo: We will clarify this by splitting into separate sections for each =
repair format variant. For all variants, all bytes after 12 (including any =
CSRC list or extension headers) are considered "payload" (we will=
 find a better word for this since payload
 is obviously very overloaded).












11. Section 6.2:


   The FEC header includes 12 octets (or upto 28 octets when t=
he longer

   optional masks are used).  




This is not strictly true, it is dependent on the number of SSRCs that t=
he packet repairs.












Mo: Yes, we will clarify this.












12. Section 6.2:


Missing discussion of what to do with source packet CSRC list and RTP he=
ader extension.








Mo: Yes, the updates to section 4.2 will be echoed in 6.2.












13. Section 6.3.2:


Missing text for recovery of source packets CSRC list and RTP header ext=
ensions.








Mo: Yes, we will add this.












14. Section 6.2:


   Due to this possible padding and mandatory FEC header, a re=
pair

   packet has a larger size than the source packets it protects.&=
nbsp; This

   may cause problems if the resulting repair packet size exceeds=
 the

   Maximum Transmission Unit (MTU) size of the path over which th=
e

   repair flow is sent.


I think this should add a recommendation that the media encoding and RTP=
 payload packetization for source packets should be adjusted to a lower max=
imum packet size to allow space for the FEC headers to avoid forcing them i=
nto being fragmented. This of course
 only is possible in cases where the source packet generating endpoint is a=
ware of the addition of the FEC packets and its strategy of combining them.








Mo: Agreed, this seems like an appropriate recommendation, so we will =
add it.












Cheers


Magnus











Den 2017-11-17 kl. 03:35, skrev Roni Even:









Hi,


I would like to start a three week WGLC on 
RTP Payload Format for Flexible Forward Error Correction in 
draft-ietf-payload-flexible-fec-scheme-05.


The WGLC will end on November 7th 


 


Mo has posted some clarifications to the payload WG =
mailing list  payload mailing list archives


 


Please send comments to the payload mailing list. 


THe double posting is to  notify RTCweb WG that the WGLC has started since this document is ne=
eded for RTCweb


 =



 =



Roni Even


Payload WG co-chair=



 =



 






 


_______________________________________________
rtcweb mailing list
rtcwe=
b@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb






--=20

Magnus Westerlund=20

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.=
com
----------------------------------------------------------------------








--_000_D65040BB7693Dmzanatyciscocom_--


From nobody Tue Dec 12 16:46:33 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 E0685127137 for ; Tue, 12 Dec 2017 16:46:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 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_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 wV3LxgUKir4N for ; Tue, 12 Dec 2017 16:46:29 -0800 (PST)
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 057E812711D for ; Tue, 12 Dec 2017 16:46:28 -0800 (PST)
Received: from pps.filterd (m0072270.ppops.net [127.0.0.1]) by mx0a-00195501.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBD0jsjZ020984 for ; Tue, 12 Dec 2017 16:46:27 -0800
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0088.outbound.protection.outlook.com [207.46.163.88]) by mx0a-00195501.pphosted.com with ESMTP id 2etr8erf6f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 12 Dec 2017 16:46:27 -0800
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=EnMvxrBbFNm2Y+WJtEVyRV2jzxqxvkdfsZSTAXjBnJY=; b=B7TD6NH2HxR5lwpXJ9otpMK+BryD059nvPFYwEmtTG7lGOiBaI6+NGcH/mXJFtDiozZdJ1ulFwLiNBzow/zJ8OOzLUk6T41aguIDEGeC7SwM+PkjtIL12xblDdDefi/kKY+Alud0i65uYDcSzGqakRk8FqgJ9xZjyymXv5UjneA=
Received: from BN3PR05MB2657.namprd05.prod.outlook.com (10.166.72.21) by BN3PR05MB2659.namprd05.prod.outlook.com (10.166.72.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.4; Wed, 13 Dec 2017 00:46:25 +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.0323.011; Wed, 13 Dec 2017 00:46:24 +0000
From: Thomas Edwards 
To: "payload@ietf.org" 
Thread-Topic: draft-ietf-payload-rtp-ancillary status
Thread-Index: AQHTc6vN0fdzhVamQkyio+b+5AsqgA==
Date: Wed, 13 Dec 2017 00:46:24 +0000
Message-ID: <5A52312B-8CEA-46B4-A047-2CEB02404C52@foxeg.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: [76.171.122.204]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR05MB2659; 20:eBBM9tkjU+Gmu9JGKJ6j6pMY7UOOVMZSuXwQw+OwzQgaSglSfiYmjyJhN66Cmcja3D6d5zIarDUhGSkjAVGxsF1cplMQrLCRIGDtd4x/970c+Vh48WjKp3KYKuqf/JIRTrvXFTcrMzzaOZILQ/3PPsaomfr33tlo7drHwmvQHbOlGhXJsPyb/wP5CEfT8iI2hblbcWGug74v9hOaCGi4jPH40ToN7+hBLbZ8NJef+ANk9qcHVWkTc1wZXOd9u0AGGQzT8Lb7+NqzafHhbyGVzm1xHM9dceIfFQ0QMNzaYCK0HJ0BX8JuaWGciMCyqT8bCPgl9FonyiwQ4lg/aWnPtA==
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 5acd5e1b-e172-419b-1763-08d541c2f00e
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307); SRVR:BN3PR05MB2659; 
x-ms-traffictypediagnostic: BN3PR05MB2659:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(21748063052155)(177823376758907);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3002001)(3231023)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123562025)(20161123564025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011); SRVR:BN3PR05MB2659; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BN3PR05MB2659; 
x-forefront-prvs: 052017CAF1
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(39860400002)(346002)(189003)(199004)(5660300001)(53936002)(1730700003)(106356001)(5640700003)(66066001)(99286004)(81166006)(105586002)(8676002)(77096006)(83506002)(81156014)(3660700001)(6486002)(2906002)(478600001)(72206003)(316002)(102836003)(6116002)(3846002)(68736007)(54896002)(86362001)(58126008)(97736004)(2501003)(36756003)(2351001)(83716003)(7736002)(6306002)(82746002)(3280700002)(14454004)(2900100001)(6916009)(8936002)(33656002)(561944003)(59450400001)(230783001)(25786009)(9686003)(6512007)(6506007)(6436002)(33896004); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR05MB2659; 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: multipart/alternative; boundary="_000_5A52312B8CEA46B4A0472CEB02404C52foxegcom_"
MIME-Version: 1.0
X-OriginatorOrg: fox.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5acd5e1b-e172-419b-1763-08d541c2f00e
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2017 00:46:24.7365 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: de99ade3-81db-4070-ae0d-3c1562041b30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2659
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-12_18:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=650 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712130009
Archived-At: 
Subject: [payload] draft-ietf-payload-rtp-ancillary status
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, 13 Dec 2017 00:46:32 -0000

--_000_5A52312B8CEA46B4A0472CEB02404C52foxegcom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RGVhciBJRVRGIFBheWxvYWQgV0csDQoNCkkgaGF2ZSBwcmVzZW50ZWQgdGhlIG5ldyBwcm9wb3Nh
bCBmb3IgZ2VuZXJpYyBsb2NhdGlvbiBjb2RlcyBpbiBMaW5lX051bWJlciBhbmQgSG9yaXpvbnRh
bF9PZmZzZXQgZmllbGRzIHRvIHN1YmplY3QgbWF0dGVyIGV4cGVydHMgaW4gU01QVEUgYW5kIEFJ
TVMsIGFuZCB0aGVyZSBpcyBnZW5lcmFsIGFncmVlbWVudCB3aXRoIHRoZSBwcm9wb3NhbC4NCg0K
VGhleSB3aWxsIGJlOg0KDQpMaW5lX051bWJlciB8IEFOQyBkYXRhIHBhY2tldCBnZW5lcmljIHZl
cnRpY2FsIGxvY2F0aW9uDQoNCjB4N0ZGICAgICB8IFdpdGhvdXQgc3BlY2lmaWMgbGluZSBsb2Nh
dGlvbiB3aXRoaW4gdGhlIGZpZWxkIG9yIGZyYW1lDQoweDdGRSAgICAgfCBPbiBhbnkgbGluZSBp
biB0aGUgcmFuZ2UgZnJvbSB0aGUgc2Vjb25kIGxpbmUgYWZ0ZXINCnRoZSBsaW5lIHNwZWNpZmll
ZCBmb3Igc3dpdGNoaW5nLCBhcyBkZWZpbmVkIGluIFNNUFRFDQpSUCAxNjgsIHRvIHRoZSBsYXN0
IGxpbmUgYmVmb3JlIGFjdGl2ZSB2aWRlbywgaW5jbHVzaXZlDQoweDdGRCAgICAgfCBPbiBhIGxp
bmUgbnVtYmVyIGxhcmdlciB0aGFuIGNhbiBiZSByZXByZXNlbnRlZCBpbiAxMQ0KYml0cyBvZiB0
aGlzIGZpZWxkIChpZiBuZWVkZWQgZm9yIGZ1dHVyZSBmb3JtYXRzKQ0KDQpIb3Jpem9udGFsX09m
ZnNldCB8IEFOQyBkYXRhIHBhY2tldCBnZW5lcmljIGhvcml6b250YWwgbG9jYXRpb24NCg0KMHhG
RkYgICAgIHwgV2l0aG91dCBzcGVjaWZpYyBob3Jpem9udGFsIGxvY2F0aW9uDQoweEZGRSAgICAg
fCBXaXRoaW4gaG9yaXpvbnRhbCBhbmNpbGxhcnkgZGF0YSBzcGFjZSAoSEFOQykgYXMNCmRlZmlu
ZWQgaW4gU01QVEUgU1QgMjkxLTENCjB4RkZEICAgICB8IFdpdGhpbiB0aGUgYW5jaWxsYXJ5IGRh
dGEgc3BhY2UgbG9jYXRlZCBiZXR3ZWVuIFNBVg0KICAgICAgICAgICAgICAgKFN0YXJ0IG9mIEFj
dGl2ZSBWaWRlbykgYW5kIEVBViAoRW5kIG9mIEFjdGl2ZSBWaWRlbykNCm1hcmtlcnMgb2YgdGhl
IHNlcmlhbCBkaWdpdGFsIGludGVyZmFjZQ0KMHhGRkMgICAgIHwgSG9yaXpvbnRhbCBvZmZzZXQg
aXMgbGFyZ2VyIHRoYW4gY2FuIGJlIHJlcHJlc2VudGVkIGluDQp0aGUgMTIgYml0cyBvZiB0aGlz
IGZpZWxkIChpZiBuZWVkZWQgZm9yIGZ1dHVyZSBmb3JtYXRzLCBvciBmb3INCmNlcnRhaW4gbG93
IGZyYW1lIHJhdGUgNzIwcCBmb3JtYXRzKQ0KDQpPbmUgZnVydGhlciBpdGVtIGNhbWUgdXAgcmVn
YXJkaW5nIEhvcml6b250YWxfT2Zmc2V0LiAgSW4gU01QVEUgU1QgMjAzOCAoQU5DIERhdGEgaW4g
TVBFRy1UUywgdGhlIGRhdGEgbW9kZWwgd2Ugb3JpZ2luYWxseSBiYXNlZCB0aGlzIEktRCBvbiks
IEhvcml6b250YWxfT2Zmc2V0IGp1c3Qgc2F5czoNCg0KICAgICAgICAgICAgICAgIOKAnEZvciBI
RCwgdGhpcyBpcyBpbiB1bml0cyBvZiBZIHNhbXBsZXMgKGUuZy4sIHRoZSByYW5nZSAwIHRvIDIx
OTkgZm9yIDEwODBpIEAgNTkuOTQpLuKAnQ0KDQpXaGVuIEkgYXV0aG9yZWQgZHJhZnQtaWV0Zi1w
YXlsb2FkLXJ0cC1hbmNpbGxhcnktMCwgSSB0aG91Z2h0IEnigJlkIGJlIG1vcmUgdmVyYm9zZSBh
bmQgc2F5IG9mIEhvcmlvem50YWxfT2Zmc2V0Og0KDQrigJxGb3IgSEQsIHRoaXMgaXMgaW4gdW5p
dHMgb2YgbHVtYSBzYW1wbGUgbnVtYmVycyBhcyBzcGVjaWZpZWQgYnkgdGhlIGRlZmluaW5nIGRv
Y3VtZW50IG9mIHRoZSBwYXJ0aWN1bGFyIGltYWdlIChlLmcuLCBTTVBURSBTVCAyNzQgW1NUMjc0
XSBmb3IgMTkyMA0KeCAxMDgwIGFjdGl2ZSBpbWFnZXMsIG9yIFNNUFRFIFNUIDI5NiBbU1QyOTZd
IGZvciAxMjgwIHggNzIwIHByb2dyZXNzaXZlIGFjdGl2ZSBpbWFnZXMpLuKAnQ0KDQpUaGlzIGFw
cGVhcnMgdG8gbGltaXQgdXMgdG8gaW1hZ2VzIGNhcnJpZWQgaW4gYSBzaW5nbGUgU0RJIHN0cmVh
bS4gIEJ1dCBub3cgdGhhdCB3ZeKAmXZlIGV4dGVuZGVkIHRoaXMgcGF5bG9hZCB0byBiZSBhYmxl
IHRvIGhhbmRsZSBpbWFnZXMgY2FycmllZCBvdmVyIFNESSBtdWx0aXBsZSBzdHJlYW1zIChzdWNo
IGFzIFVIRCBpbWFnZXMpLCBhbmQgd2UgYXJlIHNwZWNpZmljYWxseSBkZWFsaW5nIHdpdGggdGhl
IGxvY2F0aW9uIG9mIGFuY2lsbGFyeSBkYXRhIGluIFNESSBzdHJlYW1zIHJhdGhlciB0aGFuIGlt
YWdlcywgSSBiZWxpZXZlIGl0IGlzIHRpbWUgdG8gbGVhbiBiYWNrIHRvd2FyZHMgc2ltcGxpY2l0
eSwgYW5kIGhhdmUgSG9yaXpvbnRhbF9PZmZzZXQgc3RhdGU6DQoNCiAgICAgICAgICAgICAgICDi
gJxGb3IgSEQsIHRoaXMgaXMgaW4gdW5pdHMgb2YgWSBzYW1wbGVzIGFzIGRlZmluZWQgaW4gSVRV
LVIgQlQuMTEyMC7igJ0NCg0KSWYgaXQgc3VpdHMgdGhlIFBheWxvYWQgV0csIEkgY2FuIHN1Ym1p
dCBhIC0xMyB2ZXJzaW9uIG9mIHRoZSBJLUQgd2l0aCB0aGVzZSBjaGFuZ2VzLg0KDQotVGhvbWFz
DQoNCi0tDQpUaG9tYXMgRWR3YXJkcw0KRk9YIE5ldHdvcmtzIEVuZ2luZWVyaW5nICYgT3BlcmF0
aW9ucw0KVlAgRW5naW5lZXJpbmcgJiBEZXZlbG9wbWVudA0KdGhvbWFzLmVkd2FyZHNAZm94LmNv
bQ0KKzEtMzEwLTM2OS02Njk2DQoxMDIwMSBXIFBpY28gQmx2ZA0KTG9zIEFuZ2VsZXMsIENBIDkw
MDM1DQo=

--_000_5A52312B8CEA46B4A0472CEB02404C52foxegcom_
Content-Type: text/html; charset="utf-8"
Content-ID: <40A1276675947A47B0AC029D6AB15EFE@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1
bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29t
cG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0
ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1z
dHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9
DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4
LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk
U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxi
b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5
NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5EZWFyIElFVEYgUGF5bG9hZCBXRyw8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgaGF2ZSBwcmVzZW50ZWQg
dGhlIG5ldyBwcm9wb3NhbCBmb3IgZ2VuZXJpYyBsb2NhdGlvbiBjb2RlcyBpbiBMaW5lX051bWJl
ciBhbmQgSG9yaXpvbnRhbF9PZmZzZXQgZmllbGRzIHRvIHN1YmplY3QgbWF0dGVyIGV4cGVydHMg
aW4gU01QVEUgYW5kIEFJTVMsIGFuZCB0aGVyZSBpcyBnZW5lcmFsIGFncmVlbWVudCB3aXRoIHRo
ZSBwcm9wb3NhbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRo
ZXkgd2lsbCBiZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi41aW4iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0Ij5MaW5lX051bWJlciB8IEFOQyBkYXRhIHBhY2tldCBnZW5l
cmljIHZlcnRpY2FsIGxvY2F0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDouNWlu
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+MHg3RkYmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgfCBXaXRob3V0IHNwZWNpZmljIGxpbmUgbG9jYXRpb24gd2l0aGluIHRoZSBmaWVsZCBv
ciBmcmFtZSZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9InRleHQtaW5kZW50Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
Ij4weDdGRSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IE9uIGFueSBsaW5lIGluIHRoZSByYW5n
ZSBmcm9tIHRoZSBzZWNvbmQgbGluZSBhZnRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDouNWluIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdCI+dGhlIGxpbmUgc3BlY2lmaWVkIGZvciBzd2l0Y2hpbmcsIGFzIGRlZmlu
ZWQgaW4gU01QVEU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0idGV4dC1pbmRlbnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlJQ
IDE2OCwgdG8gdGhlIGxhc3QgbGluZSBiZWZvcmUgYWN0aXZlIHZpZGVvLCBpbmNsdXNpdmUmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDouNWluIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+MHg3RkQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
fCBPbiBhIGxpbmUgbnVtYmVyIGxhcmdlciB0aGFuIGNhbiBiZSByZXByZXNlbnRlZCBpbiAxMTxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWlu
ZGVudDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Yml0cyBvZiB0aGlzIGZp
ZWxkIChpZiBuZWVkZWQgZm9yIGZ1dHVyZSBmb3JtYXRzKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4
dC1pbmRlbnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhvcml6b250YWxf
T2Zmc2V0IHwgQU5DIGRhdGEgcGFja2V0IGdlbmVyaWMgaG9yaXpvbnRhbCBsb2NhdGlvbjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQiPjB4RkZGJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgV2l0aG91dCBzcGVjaWZpYyBo
b3Jpem9udGFsIGxvY2F0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0Ij4weEZGRSZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDt8IFdpdGhpbiBob3Jpem9udGFsIGFu
Y2lsbGFyeSBkYXRhIHNwYWNlIChIQU5DKSBhczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDouNWluIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdCI+ZGVmaW5lZCBpbiBTTVBURSBTVCAyOTEtMTxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDouNWluIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+MHhGRkQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
fCBXaXRoaW4gdGhlIGFuY2lsbGFyeSBkYXRhIHNwYWNlIGxvY2F0ZWQgYmV0d2VlbiBTQVY8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IChTdGFydCBvZiBBY3Rp
dmUgVmlkZW8pIGFuZCBFQVYgKEVuZCBvZiBBY3RpdmUgVmlkZW8pDQo8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LjVpbiI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPm1hcmtlcnMgb2YgdGhlIHNlcmlhbCBkaWdpdGFs
IGludGVyZmFjZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJ0ZXh0LWluZGVudDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+MHhG
RkMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBIb3Jpem9udGFsIG9mZnNldCBpcyBsYXJnZXIg
dGhhbiBjYW4gYmUgcmVwcmVzZW50ZWQgaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQiPnRoZSAxMiBiaXRzIG9mIHRoaXMgZmllbGQgKGlmIG5lZWRlZCBmb3IgZnV0
dXJlIGZvcm1hdHMsIG9yIGZvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdCI+Y2VydGFpbiBsb3cgZnJhbWUgcmF0ZSA3MjBwIGZvcm1hdHMpPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5PbmUgZnVydGhlciBpdGVtIGNhbWUgdXAgcmVn
YXJkaW5nIEhvcml6b250YWxfT2Zmc2V0LiZuYnNwOyBJbiBTTVBURSBTVCAyMDM4IChBTkMgRGF0
YSBpbiBNUEVHLVRTLCB0aGUgZGF0YSBtb2RlbCB3ZSBvcmlnaW5hbGx5IGJhc2VkIHRoaXMgSS1E
IG9uKSwgSG9yaXpvbnRhbF9PZmZzZXQganVzdCBzYXlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKA
nEZvciBIRCwgdGhpcyBpcyBpbiB1bml0cyBvZiBZIHNhbXBsZXMgKGUuZy4sIHRoZSByYW5nZSAw
IHRvIDIxOTkgZm9yIDEwODBpIEAgNTkuOTQpLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+V2hlbiBJIGF1dGhvcmVkIGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAt
YW5jaWxsYXJ5LTAsIEkgdGhvdWdodCBJ4oCZZCBiZSBtb3JlIHZlcmJvc2UgYW5kIHNheSBvZiBI
b3Jpb3pudGFsX09mZnNldDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi41aW4iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7igJxGb3IgSEQsIHRoaXMgaXMgaW4gdW5pdHMg
b2YgbHVtYSBzYW1wbGUgbnVtYmVycyBhcyBzcGVjaWZpZWQgYnkgdGhlIGRlZmluaW5nIGRvY3Vt
ZW50IG9mIHRoZSBwYXJ0aWN1bGFyIGltYWdlIChlLmcuLCBTTVBURSBTVCAyNzQgW1NUMjc0XSBm
b3IgMTkyMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJ0ZXh0LWluZGVudDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+eCAxMDgw
IGFjdGl2ZSBpbWFnZXMsIG9yIFNNUFRFIFNUIDI5NiBbU1QyOTZdIGZvciAxMjgwIHggNzIwIHBy
b2dyZXNzaXZlIGFjdGl2ZSBpbWFnZXMpLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdCI+VGhpcyBhcHBlYXJzIHRvIGxpbWl0IHVzIHRvIGltYWdlcyBjYXJyaWVk
IGluIGEgc2luZ2xlIFNESSBzdHJlYW0uJm5ic3A7IEJ1dCBub3cgdGhhdCB3ZeKAmXZlIGV4dGVu
ZGVkIHRoaXMgcGF5bG9hZCB0byBiZSBhYmxlIHRvIGhhbmRsZSBpbWFnZXMgY2FycmllZCBvdmVy
IFNESSBtdWx0aXBsZSBzdHJlYW1zIChzdWNoIGFzIFVIRCBpbWFnZXMpLCBhbmQgd2UgYXJlIHNw
ZWNpZmljYWxseQ0KIGRlYWxpbmcgd2l0aCB0aGUgbG9jYXRpb24gb2YgYW5jaWxsYXJ5IGRhdGEg
aW4gU0RJIHN0cmVhbXMgcmF0aGVyIHRoYW4gaW1hZ2VzLCBJIGJlbGlldmUgaXQgaXMgdGltZSB0
byBsZWFuIGJhY2sgdG93YXJkcyBzaW1wbGljaXR5LCBhbmQgaGF2ZSBIb3Jpem9udGFsX09mZnNl
dCBzdGF0ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigJxGb3IgSEQsIHRoaXMgaXMgaW4gdW5pdHMg
b2YgWSBzYW1wbGVzIGFzIGRlZmluZWQgaW4gSVRVLVIgQlQuMTEyMC7igJ08bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPklmIGl0IHN1aXRzIHRoZSBQYXlsb2FkIFdH
LCBJIGNhbiBzdWJtaXQgYSAtMTMgdmVyc2lvbiBvZiB0aGUgSS1EIHdpdGggdGhlc2UgY2hhbmdl
cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi1UaG9tYXM8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi0tJm5ic3A7PG86cD48L286
cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0Ij5UaG9tYXMgRWR3YXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5GT1ggTmV0
d29ya3MgRW5naW5lZXJpbmcgJmFtcDsgT3BlcmF0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5WUCBF
bmdpbmVlcmluZyAmYW1wOyBEZXZlbG9wbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij50aG9tYXMuZWR3
YXJkc0Bmb3guY29tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiYjNDM7MS0zMTAtMzY5LTY2OTY8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdCI+MTAyMDEgVyBQaWNvIEJsdmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5M
b3MgQW5nZWxlcywgQ0EgOTAwMzU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9k
eT4NCjwvaHRtbD4NCg==

--_000_5A52312B8CEA46B4A0472CEB02404C52foxegcom_--


From nobody Fri Dec 15 11:41:01 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 99BD3126C19; Fri, 15 Dec 2017 11:40:59 -0800 (PST)
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.67.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151336685958.30439.12106998885650898556@ietfa.amsl.com>
Date: Fri, 15 Dec 2017 11:40:59 -0800
Archived-At: 
Subject: [payload] I-D Action: draft-ietf-payload-rtp-ancillary-13.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, 15 Dec 2017 19:40:59 -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-13.txt
	Pages           : 19
	Date            : 2017-12-15

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-13
https://datatracker.ietf.org/doc/html/draft-ietf-payload-rtp-ancillary-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-ancillary-13


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 Sat Dec 16 06:22:04 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 C726812762F for ; Sat, 16 Dec 2017 06:22:02 -0800 (PST)
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=ham 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 cl5v9Emy1Dsn for ; Sat, 16 Dec 2017 06:22:00 -0800 (PST)
Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::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 2DA31127599 for ; Sat, 16 Dec 2017 06:22:00 -0800 (PST)
Received: by mail-wr0-x229.google.com with SMTP id g17so1139967wrd.13 for ; Sat, 16 Dec 2017 06:22:00 -0800 (PST)
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=lw4LSZWyxFuQkxHtJKFXxEkl5AUFHSnGSQbowdeARm0=; b=iBvVFs5PxO6Cq+IisskzspuCA0/tRIWugC0RTy780LrLELc/bsZTtAKX8lvqsvrmwo C8arf6waigo9BsrYnCgbB697ZoqsP+vA1v/3oSSN2o1ULh3ihDt6pGFpFBwMD2BsGUpF CyHO7dDnnXxOJPeDGszsHV1xdbNZEyejUMmeKlGqdbTC0ShqwWaANew/TIR3ghm4V3Qv hODef0/Xs10RJUJ4bgHinegary6II5EVvD+nxiNlTM1Qn4D1SkJ4iq5Lh2TmUPLEadNL Z7n6wqxVbc2zu1Cx7yAIo8cPxEGFpV/wvRB3A2t4c9pT/u0eQJz0FwN2XwE3Mt9o4u1q /0aA==
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=lw4LSZWyxFuQkxHtJKFXxEkl5AUFHSnGSQbowdeARm0=; b=sYZTfLtA/7DB6x6liKl/0S+V4BePj0ux/S/22e2QTvKGvFCvEG09YD4LNf6aoGbuxh BCyKI9GWbS9CbUZU24l4XkqvhvuyGGYfGg2IHg7l2ctAmIvQo8/ic6TSjQaRjmUHu5p6 ZiQzt4dNR/J+HiCvJ1wSY+KH05InXEfZ1WtZ+kTpN+ydDbZYcG+6fwaV16jWVKrdcWXT geVSw1Jk2ss+7CSkkoQpB7VIlCLrA93GgMJiKQjNMckzIAcKTC5vKQx0sgjXi9QlsSyf TMYMTGyaAsmXqzHoRr6wv1ouUX47/msHHXl+2cASstCoXgp4Fal6C0OCc/OD9NpaVail R+yQ==
X-Gm-Message-State: AKGB3mIsN+CysJte7e/GqKRXeTJielB/s6bao+l+mcFgleTuRmKC5RPl gdby+MmWgc1B3o+UZGQofZzzlJXtp48=
X-Google-Smtp-Source: ACJfBosW4QjIjVcJ83otic8uIMaRjjZ98xnIVbPwPVhlHV0jLUWE3W9mYVRRrjI6E8GqaR9ss+jJ4Q==
X-Received: by 10.223.195.136 with SMTP id p8mr13638741wrf.4.1513434118354; Sat, 16 Dec 2017 06:21:58 -0800 (PST)
Received: from [192.168.1.174] ([85.105.47.236]) by smtp.gmail.com with ESMTPSA id b48sm4754915wrb.1.2017.12.16.06.21.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Dec 2017 06:21:57 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: "Ali C. Begen" 
In-Reply-To: <151336685958.30439.12106998885650898556@ietfa.amsl.com>
Date: Sat, 16 Dec 2017 17:21:55 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <4E1ED364-EACD-48FA-A80E-C029EFCD96C8@networked.media>
References: <151336685958.30439.12106998885650898556@ietfa.amsl.com>
To: payload@ietf.org
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-ancillary-13.txt
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: Sat, 16 Dec 2017 14:22:03 -0000

Payload WG,

Is there any objection to the latest revision that addresses the issues =
Thomas pointed out earlier? The draft was in the RFC editor queue and if =
there are no objections, we will soon ship it back there. But to give =
people a chance to read and officially comment on the revision, I think =
we should start a new IETF LC for a week.

@Ben, could we do that?

-acbegen

=20

> On Dec 15, 2017, at 10:40 PM, internet-drafts@ietf.org wrote:
>=20
>=20
> 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.
>=20
>        Title           : RTP Payload for SMPTE ST 291-1 Ancillary Data
>        Author          : Thomas G. Edwards
> 	Filename        : draft-ietf-payload-rtp-ancillary-13.txt
> 	Pages           : 19
> 	Date            : 2017-12-15
>=20
> 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).
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-ancillary/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-payload-rtp-ancillary-13
> =
https://datatracker.ietf.org/doc/html/draft-ietf-payload-rtp-ancillary-13
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-ancillary-13
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload


From nobody Sat Dec 16 09:34:11 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 5481A124B0A for ; Sat, 16 Dec 2017 09:34:10 -0800 (PST)
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 lSytTIVPvlnw for ; Sat, 16 Dec 2017 09:34:08 -0800 (PST)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 291B1120454 for ; Sat, 16 Dec 2017 09:34:08 -0800 (PST)
Received: by mail-it0-x22c.google.com with SMTP id z6so24004049iti.4 for ; Sat, 16 Dec 2017 09:34:08 -0800 (PST)
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; bh=zrkrQV1UinTgetyl5axCwQrcMqq+DN80lCBNhyy/lho=; b=cgLuV4fSgzpjwcgp2a+D/pg+lOQOk/hrhSzA2r3d5r2G+dM6FoH/tL25tUG/3QRFE/ l5pYQTeM0ym6FLtAZa7lA5W433gy9mbayr5QfClGZn1aM8gvNtwQRRmWLtnC0kccuLd1 CvHUiz6aOAneQoau0r8KdHEXzxFYEOg0iLrAds3VbuKa7fZ+lRpcNaOz9M+c7EDnzBGM LsSf0IhIeCORh3Rz3gSG0KnVBZjPnRrw/j6bKIGuGxDUM9DyniUsxFhAEllq6FbRlFDg vbboy3gPkm+rTPOiZkmJYPEo0/wfShlQ6ZJifhdYGRZpKBI4PqMDf1XBcpJr2CI+80SV tSOg==
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=zrkrQV1UinTgetyl5axCwQrcMqq+DN80lCBNhyy/lho=; b=KUYLyamclH5bdwrAz4WR9SnSFY/yZVADKuN7t/zjBdscOvsUUWtff3q3itxII3XEnG ZGkMrHFkOIoQ78id8WrjgN+yapU6z6ICr+reIyOQIjJ9iWipDz0Zzjf4zzZeqdEEH/Zl 7inqoD/tRwn3F4FnjzncS8oMyBtMGn4POvQUCToTXMMF0XRw07X+TictN0EcqIhQbixG HBX2J3LuvzdexnKUIvNC3Mlbh/Y5VjzKYx93d5oK8+m4/VsViEvSWCSv2vvl0xBRebAF NIPVZ0ykM/HNNkMRa2kHRDxNTeba/S4V1Zus9aocD1okj3/wegtr/3CRCH9yKGVivGVk J+Uw==
X-Gm-Message-State: AKGB3mJs2nP28taCC8SopnXuQPHe7UeeojSon3eSCAPt6wzYS4zuXjvk 7MIdzutgJoW9VO4xA1OdPKjj0jAgnk3lZHxkwC4=
X-Google-Smtp-Source: ACJfBoul24sQVvXJr3444WuknPJb9Dp4nFrrjXgC2cxJ3T9oIoP8JXkWI2eTuveyRo81Y4cr8sJu2s9KALywX8p8jb8=
X-Received: by 10.36.117.210 with SMTP id y201mr13215431itc.149.1513445647187;  Sat, 16 Dec 2017 09:34:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.79.157.14 with HTTP; Sat, 16 Dec 2017 09:34:06 -0800 (PST)
In-Reply-To: <4E1ED364-EACD-48FA-A80E-C029EFCD96C8@networked.media>
References: <151336685958.30439.12106998885650898556@ietfa.amsl.com> <4E1ED364-EACD-48FA-A80E-C029EFCD96C8@networked.media>
From: Kjetil Oftedal 
Date: Sat, 16 Dec 2017 18:34:06 +0100
Message-ID: 
To: payload@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-ancillary-13.txt
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: Sat, 16 Dec 2017 17:34:10 -0000

Hi,

The submitted changes does not address the previous concern
regarding the M-bit in the RTP Header.
The M-bit should signal the end of a access unit in the stream.
Currently that access unit is a field/frame and is signaled in the
last RTP packet before the field/frame boundary. However, the SDI
splicing points are not on the field/frame boundary, but several video
lines into the field/frame.

Thus the result of splicing streams at the M-bit will be that the
ANC/SDI streams is not to be spliced at the SDI splicing point.
There should be little or no ANC data above the switching line in
a field/frame, so it might not be a big issue. But if care is taken to
avoid switching line problems in the standard. Such care should
also be taken with the M-bit signaling.

Changing the M-bit signaling creates secondary considerations with
the line signaling in the header. As the line numbers will wrap
before the M-bit is set.

Best regards,
Kjetil Oftedal


On 16/12/2017, Ali C. Begen  wrote:
> Payload WG,
>
> Is there any objection to the latest revision that addresses the issues
> Thomas pointed out earlier? The draft was in the RFC editor queue and if
> there are no objections, we will soon ship it back there. But to give people
> a chance to read and officially comment on the revision, I think we should
> start a new IETF LC for a week.
>
> @Ben, could we do that?
>
> -acbegen
>
>
>
>> On Dec 15, 2017, at 10:40 PM, internet-drafts@ietf.org wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the 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-13.txt
>> 	Pages           : 19
>> 	Date            : 2017-12-15
>>
>> 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-13
>> https://datatracker.ietf.org/doc/html/draft-ietf-payload-rtp-ancillary-13
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-ancillary-13
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> payload mailing list
>> payload@ietf.org
>> https://www.ietf.org/mailman/listinfo/payload
>
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload
>


From nobody Sat Dec 16 20:33: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 1DF36124207 for ; Sat, 16 Dec 2017 20:33:00 -0800 (PST)
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 jdq9Z9ZWkdLG for ; Sat, 16 Dec 2017 20:32:57 -0800 (PST)
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 63832120721 for ; Sat, 16 Dec 2017 20:32:57 -0800 (PST)
Received: from pps.filterd (m0087372.ppops.net [127.0.0.1]) by mx0b-00195501.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBH4Uiao025997; Sat, 16 Dec 2017 20:32:54 -0800
Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0020.outbound.protection.outlook.com [207.46.163.20]) by mx0b-00195501.pphosted.com with ESMTP id 2ewbgagsxb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 16 Dec 2017 20:32:54 -0800
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=iNPPZXCbEDV6fGuTPHajb0UojYENI5yMFthrYrn/G8E=; b=f8PUxkb4e0WIR1Tmhg/kKDkvzwXEQIURo1yBhuKsZbPTnIWk3j2u184eXLNVoD99jxMSLH8YhLOGiZ3fyFqQPAoQNI7BkfEh9/ppwHJdbzeR8OgU4DHOz64+zUpd8vpiphwzOZbBFN022PTte0nowWRGk3+kt4xkwEMli1QGNgY=
Received: from BN3PR05MB2657.namprd05.prod.outlook.com (10.166.72.21) by BN3PR05MB2657.namprd05.prod.outlook.com (10.166.72.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.4; Sun, 17 Dec 2017 04:32:52 +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.0323.018; Sun, 17 Dec 2017 04:32:52 +0000
From: Thomas Edwards 
To: Kjetil Oftedal , "payload@ietf.org" 
Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-ancillary-13.txt
Thread-Index: AQHTddymwcEukxVJm0G8Lb9K6pWzMKNGBrmAgAA1sgCAADHyAA==
Date: Sun, 17 Dec 2017 04:32:52 +0000
Message-ID: <09C98B9B-68C2-45B3-8134-8966B87B6E9D@foxeg.com>
References: <151336685958.30439.12106998885650898556@ietfa.amsl.com> <4E1ED364-EACD-48FA-A80E-C029EFCD96C8@networked.media> 
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: [76.171.122.204]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR05MB2657; 20:V3eLWZGG7qAtxD3PvbEjJRqL7UfdlGhFesk0Cd49cK6QE/QmZZYqErEs27TKrHgxRrr6SaJPMtV6Nt5OMobvEFtUnSzJKkAfRblCuUeanhdVO8aY/RoZvJ0dU3uzkyf9Hn96mF6yzOAbLRYL7RDyrbWscHS9SxHaXDAYgeCahPByETv7vF/SagkCoqaV6a5N782roBvLEvW8qZgWj+YEf9hTlb2GWdJX6GSlYIyR5W5RSCiZNTOBOnJehYxpzxJElz0TMBxBpzn2wCJSEuws9VHV+wL/QP+JzmJv8CkwNYZmpbTQQLsRpJM0q4MpM385bQ7wusshwR4ali1lFHe6Ow==
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 7506a1e2-7956-4f0e-68d8-08d545073cbc
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603307); SRVR:BN3PR05MB2657; 
x-ms-traffictypediagnostic: BN3PR05MB2657:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(10436049006162);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231023)(10201501046)(6055026)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BN3PR05MB2657; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BN3PR05MB2657; 
x-forefront-prvs: 05245CA661
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(346002)(376002)(396003)(377424004)(24454002)(199004)(189003)(4001150100001)(3660700001)(2906002)(6486002)(9686003)(6512007)(82746002)(77096006)(68736007)(59450400001)(97736004)(2900100001)(6436002)(2501003)(8676002)(105586002)(25786009)(230783001)(6306002)(83716003)(81166006)(81156014)(53936002)(3280700002)(8936002)(478600001)(966005)(58126008)(66066001)(2950100002)(316002)(5660300001)(36756003)(3846002)(305945005)(7736002)(6116002)(102836003)(83506002)(72206003)(14454004)(106356001)(39060400002)(110136005)(33656002)(86362001)(575784001)(76176011)(33896004)(6246003)(99286004)(53546011)(229853002)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR05MB2657; H:BN3PR05MB2657.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX: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: <4DC1780E863A0A4A9B274A18D8BA2C63@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: fox.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7506a1e2-7956-4f0e-68d8-08d545073cbc
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2017 04:32:52.7298 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: de99ade3-81db-4070-ae0d-3c1562041b30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2657
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-17_03:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712170063
Archived-At: 
Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-ancillary-13.txt
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, 17 Dec 2017 04:33:00 -0000

SSB0aGluayB0aGVyZSBpcyBnZW5lcmFsIGFjY2VwdGFuY2Ugd2l0aGluIFNNUFRFIGFuZCBBSU1T
IGZvciB0aGUgY3VycmVudCBNLWJpdCBkZWZpbml0aW9uLg0KDQpXaGF0IHdvdWxkIGJlIHlvdXIg
cHJlY2lzZSBzdWdnZXN0ZWQgbGFuZ3VhZ2U/DQoNCi1UaG9tYXMNCg0KT24gMTIvMTYvMTcsIDk6
MzQgQU0sICJwYXlsb2FkIG9uIGJlaGFsZiBvZiBLamV0aWwgT2Z0ZWRhbCIgPHBheWxvYWQtYm91
bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygb2Z0ZWRhbEBnbWFpbC5jb20+IHdyb3RlOg0KDQog
ICAgSGksDQogICAgDQogICAgVGhlIHN1Ym1pdHRlZCBjaGFuZ2VzIGRvZXMgbm90IGFkZHJlc3Mg
dGhlIHByZXZpb3VzIGNvbmNlcm4NCiAgICByZWdhcmRpbmcgdGhlIE0tYml0IGluIHRoZSBSVFAg
SGVhZGVyLg0KICAgIFRoZSBNLWJpdCBzaG91bGQgc2lnbmFsIHRoZSBlbmQgb2YgYSBhY2Nlc3Mg
dW5pdCBpbiB0aGUgc3RyZWFtLg0KICAgIEN1cnJlbnRseSB0aGF0IGFjY2VzcyB1bml0IGlzIGEg
ZmllbGQvZnJhbWUgYW5kIGlzIHNpZ25hbGVkIGluIHRoZQ0KICAgIGxhc3QgUlRQIHBhY2tldCBi
ZWZvcmUgdGhlIGZpZWxkL2ZyYW1lIGJvdW5kYXJ5LiBIb3dldmVyLCB0aGUgU0RJDQogICAgc3Bs
aWNpbmcgcG9pbnRzIGFyZSBub3Qgb24gdGhlIGZpZWxkL2ZyYW1lIGJvdW5kYXJ5LCBidXQgc2V2
ZXJhbCB2aWRlbw0KICAgIGxpbmVzIGludG8gdGhlIGZpZWxkL2ZyYW1lLg0KICAgIA0KICAgIFRo
dXMgdGhlIHJlc3VsdCBvZiBzcGxpY2luZyBzdHJlYW1zIGF0IHRoZSBNLWJpdCB3aWxsIGJlIHRo
YXQgdGhlDQogICAgQU5DL1NESSBzdHJlYW1zIGlzIG5vdCB0byBiZSBzcGxpY2VkIGF0IHRoZSBT
REkgc3BsaWNpbmcgcG9pbnQuDQogICAgVGhlcmUgc2hvdWxkIGJlIGxpdHRsZSBvciBubyBBTkMg
ZGF0YSBhYm92ZSB0aGUgc3dpdGNoaW5nIGxpbmUgaW4NCiAgICBhIGZpZWxkL2ZyYW1lLCBzbyBp
dCBtaWdodCBub3QgYmUgYSBiaWcgaXNzdWUuIEJ1dCBpZiBjYXJlIGlzIHRha2VuIHRvDQogICAg
YXZvaWQgc3dpdGNoaW5nIGxpbmUgcHJvYmxlbXMgaW4gdGhlIHN0YW5kYXJkLiBTdWNoIGNhcmUg
c2hvdWxkDQogICAgYWxzbyBiZSB0YWtlbiB3aXRoIHRoZSBNLWJpdCBzaWduYWxpbmcuDQogICAg
DQogICAgQ2hhbmdpbmcgdGhlIE0tYml0IHNpZ25hbGluZyBjcmVhdGVzIHNlY29uZGFyeSBjb25z
aWRlcmF0aW9ucyB3aXRoDQogICAgdGhlIGxpbmUgc2lnbmFsaW5nIGluIHRoZSBoZWFkZXIuIEFz
IHRoZSBsaW5lIG51bWJlcnMgd2lsbCB3cmFwDQogICAgYmVmb3JlIHRoZSBNLWJpdCBpcyBzZXQu
DQogICAgDQogICAgQmVzdCByZWdhcmRzLA0KICAgIEtqZXRpbCBPZnRlZGFsDQogICAgDQogICAg
DQogICAgT24gMTYvMTIvMjAxNywgQWxpIEMuIEJlZ2VuIDxhbGkuYmVnZW5AbmV0d29ya2VkLm1l
ZGlhPiB3cm90ZToNCiAgICA+IFBheWxvYWQgV0csDQogICAgPg0KICAgID4gSXMgdGhlcmUgYW55
IG9iamVjdGlvbiB0byB0aGUgbGF0ZXN0IHJldmlzaW9uIHRoYXQgYWRkcmVzc2VzIHRoZSBpc3N1
ZXMNCiAgICA+IFRob21hcyBwb2ludGVkIG91dCBlYXJsaWVyPyBUaGUgZHJhZnQgd2FzIGluIHRo
ZSBSRkMgZWRpdG9yIHF1ZXVlIGFuZCBpZg0KICAgID4gdGhlcmUgYXJlIG5vIG9iamVjdGlvbnMs
IHdlIHdpbGwgc29vbiBzaGlwIGl0IGJhY2sgdGhlcmUuIEJ1dCB0byBnaXZlIHBlb3BsZQ0KICAg
ID4gYSBjaGFuY2UgdG8gcmVhZCBhbmQgb2ZmaWNpYWxseSBjb21tZW50IG9uIHRoZSByZXZpc2lv
biwgSSB0aGluayB3ZSBzaG91bGQNCiAgICA+IHN0YXJ0IGEgbmV3IElFVEYgTEMgZm9yIGEgd2Vl
ay4NCiAgICA+DQogICAgPiBAQmVuLCBjb3VsZCB3ZSBkbyB0aGF0Pw0KICAgID4NCiAgICA+IC1h
Y2JlZ2VuDQogICAgPg0KICAgID4NCiAgICA+DQogICAgPj4gT24gRGVjIDE1LCAyMDE3LCBhdCAx
MDo0MCBQTSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KICAgID4+DQogICAgPj4N
CiAgICA+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGlu
ZSBJbnRlcm5ldC1EcmFmdHMNCiAgICA+PiBkaXJlY3Rvcmllcy4NCiAgICA+PiBUaGlzIGRyYWZ0
IGlzIGEgd29yayBpdGVtIG9mIHRoZSBBdWRpby9WaWRlbyBUcmFuc3BvcnQgUGF5bG9hZHMgV0cg
b2YgdGhlDQogICAgPj4gSUVURi4NCiAgICA+Pg0KICAgID4+ICAgICAgICBUaXRsZSAgICAgICAg
ICAgOiBSVFAgUGF5bG9hZCBmb3IgU01QVEUgU1QgMjkxLTEgQW5jaWxsYXJ5IERhdGENCiAgICA+
PiAgICAgICAgQXV0aG9yICAgICAgICAgIDogVGhvbWFzIEcuIEVkd2FyZHMNCiAgICA+PiAJRmls
ZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1hbmNpbGxhcnktMTMudHh0DQog
ICAgPj4gCVBhZ2VzICAgICAgICAgICA6IDE5DQogICAgPj4gCURhdGUgICAgICAgICAgICA6IDIw
MTctMTItMTUNCiAgICA+Pg0KICAgID4+IEFic3RyYWN0Og0KICAgID4+ICAgVGhpcyBtZW1vIGRl
c2NyaWJlcyBhIHJlYWwtdGltZSB0cmFuc3BvcnQgcHJvdG9jb2wgKFJUUCkgcGF5bG9hZA0KICAg
ID4+ICAgZm9ybWF0IGZvciB0aGUgU29jaWV0eSBvZiBNb3Rpb24gUGljdHVyZSBhbmQgVGVsZXZp
c2lvbiBFbmdpbmVlcnMNCiAgICA+PiAgIChTTVBURSkgQW5jaWxsYXJ5IGRhdGEsIGFzIGRlZmlu
ZWQgYnkgU01QVEUgU1QgMjkxLTEuICBTTVBURQ0KICAgID4+ICAgQW5jaWxsYXJ5IGRhdGEgaXMg
Z2VuZXJhbGx5IHVzZWQgYWxvbmcgd2l0aCBwcm9mZXNzaW9uYWwgdmlkZW8NCiAgICA+PiAgIGZv
cm1hdHMgdG8gY2FycnkgYSByYW5nZSBvZiBhbmNpbGxhcnkgZGF0YSB0eXBlcywgaW5jbHVkaW5n
IHRpbWUNCiAgICA+PiAgIGNvZGUsIENsb3NlZCBDYXB0aW9uaW5nLCBhbmQgdGhlIEFjdGl2ZSBG
b3JtYXQgRGVzY3JpcHRpb24gKEFGRCkuDQogICAgPj4NCiAgICA+Pg0KICAgID4+IFRoZSBJRVRG
IGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KICAgID4+IGh0dHBz
Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNr
ZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJEaWV0Zi0yRHBheWxvYWQtMkRydHAtMkRhbmNpbGxhcnlf
JmQ9RHdJQ0FnJmM9dXc2VEx1NGh3aEhkaUdKT2d3Y1dENEFqS1F4Nnp2RmNHRXNiZmlZOS1FSSZy
PWxla05PT001bm9WNjF6clBIM3J3UHlodE5uTExXb0xFSGdkMHF1UXhseTgmbT14dXpoNDJYcnQ4
bkFXZVpSVWRJS09fQWRrOEpVcXUzeXpFSnZoN21IZEtVJnM9N3Z5YUE3Y1hFQUktTVlseWxabGts
M1NUaWRwUTFjdGNZQWpqazZiSjQ0YyZlPQ0KICAgID4+DQogICAgPj4gVGhlcmUgYXJlIGFsc28g
aHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KICAgID4+IGh0dHBzOi8vdXJsZGVmZW5z
ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9k
cmFmdC0yRGlldGYtMkRwYXlsb2FkLTJEcnRwLTJEYW5jaWxsYXJ5LTJEMTMmZD1Ed0lDQWcmYz11
dzZUTHU0aHdoSGRpR0pPZ3djV0Q0QWpLUXg2enZGY0dFc2JmaVk5LUVJJnI9bGVrTk9PTTVub1Y2
MXpyUEgzcndQeWh0Tm5MTFdvTEVIZ2QwcXVReGx5OCZtPXh1emg0MlhydDhuQVdlWlJVZElLT19B
ZGs4SlVxdTN5ekVKdmg3bUhkS1Umcz1iMzlTeGRFRmg0cHhUNGVaTkprX01mV2xrYzkyMzhyNVJS
aGtfUEtBVjVrJmU9DQogICAgPj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy
L3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfaHRtbF9kcmFmdC0yRGll
dGYtMkRwYXlsb2FkLTJEcnRwLTJEYW5jaWxsYXJ5LTJEMTMmZD1Ed0lDQWcmYz11dzZUTHU0aHdo
SGRpR0pPZ3djV0Q0QWpLUXg2enZGY0dFc2JmaVk5LUVJJnI9bGVrTk9PTTVub1Y2MXpyUEgzcndQ
eWh0Tm5MTFdvTEVIZ2QwcXVReGx5OCZtPXh1emg0MlhydDhuQVdlWlJVZElLT19BZGs4SlVxdTN5
ekVKdmg3bUhkS1Umcz1EQ2cySkZHYUJWbGx1R3pvQnh2SnZrc0pfTjdRT0x3b3c3YTBfampIaFZB
JmU9DQogICAgPj4NCiAgICA+PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBh
dmFpbGFibGUgYXQ6DQogICAgPj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy
L3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfcmZjZGlmZi0zRnVybDItM0RkcmFmdC0yRGll
dGYtMkRwYXlsb2FkLTJEcnRwLTJEYW5jaWxsYXJ5LTJEMTMmZD1Ed0lDQWcmYz11dzZUTHU0aHdo
SGRpR0pPZ3djV0Q0QWpLUXg2enZGY0dFc2JmaVk5LUVJJnI9bGVrTk9PTTVub1Y2MXpyUEgzcndQ
eWh0Tm5MTFdvTEVIZ2QwcXVReGx5OCZtPXh1emg0MlhydDhuQVdlWlJVZElLT19BZGs4SlVxdTN5
ekVKdmg3bUhkS1Umcz11WTc2azRZbnRqOS1ZTC1tV2xIaVhvQUdJQ09aUWZkUVFmamtsTlZ6d0c0
JmU9DQogICAgPj4NCiAgICA+Pg0KICAgID4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug
YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQogICAgPj4gc3VibWlzc2lvbg0K
ICAgID4+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg
YXQgaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3Rv
b2xzLmlldGYub3JnJmQ9RHdJQ0FnJmM9dXc2VEx1NGh3aEhkaUdKT2d3Y1dENEFqS1F4Nnp2RmNH
RXNiZmlZOS1FSSZyPWxla05PT001bm9WNjF6clBIM3J3UHlodE5uTExXb0xFSGdkMHF1UXhseTgm
bT14dXpoNDJYcnQ4bkFXZVpSVWRJS09fQWRrOEpVcXUzeXpFSnZoN21IZEtVJnM9SG9iU0ViYVZt
bUtHcHJYc3BWMUE2eVo3QUxlZXMyQ1FFZ3FVTmc5ZEt4dyZlPS4NCiAgICA+Pg0KICAgID4+IElu
dGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCiAg
ICA+PiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9ZnRwLTNBX19m
dHAuaWV0Zi5vcmdfaW50ZXJuZXQtMkRkcmFmdHNfJmQ9RHdJQ0FnJmM9dXc2VEx1NGh3aEhkaUdK
T2d3Y1dENEFqS1F4Nnp2RmNHRXNiZmlZOS1FSSZyPWxla05PT001bm9WNjF6clBIM3J3UHlodE5u
TExXb0xFSGdkMHF1UXhseTgmbT14dXpoNDJYcnQ4bkFXZVpSVWRJS09fQWRrOEpVcXUzeXpFSnZo
N21IZEtVJnM9NWp2OUJVQ3hBaUJXU3JsOWtnZnpNSEZkaXJUSXBJSjQ0OS1hdmRySFl5cyZlPQ0K
ICAgID4+DQogICAgPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCiAgICA+PiBwYXlsb2FkIG1haWxpbmcgbGlzdA0KICAgID4+IHBheWxvYWRAaWV0Zi5v
cmcNCiAgICA+PiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0
cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3BheWxvYWQmZD1Ed0lDQWcmYz11
dzZUTHU0aHdoSGRpR0pPZ3djV0Q0QWpLUXg2enZGY0dFc2JmaVk5LUVJJnI9bGVrTk9PTTVub1Y2
MXpyUEgzcndQeWh0Tm5MTFdvTEVIZ2QwcXVReGx5OCZtPXh1emg0MlhydDhuQVdlWlJVZElLT19B
ZGs4SlVxdTN5ekVKdmg3bUhkS1Umcz1ocmJlVTdmUFpYNUR5NE82MEFQZVFmN05vel93Y3lFNDBU
NmU5ZWhHSnpFJmU9DQogICAgPg0KICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCiAgICA+IHBheWxvYWQgbWFpbGluZyBsaXN0DQogICAgPiBwYXls
b2FkQGlldGYub3JnDQogICAgPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv
dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3BheWxvYWQmZD1E
d0lDQWcmYz11dzZUTHU0aHdoSGRpR0pPZ3djV0Q0QWpLUXg2enZGY0dFc2JmaVk5LUVJJnI9bGVr
Tk9PTTVub1Y2MXpyUEgzcndQeWh0Tm5MTFdvTEVIZ2QwcXVReGx5OCZtPXh1emg0MlhydDhuQVdl
WlJVZElLT19BZGs4SlVxdTN5ekVKdmg3bUhkS1Umcz1ocmJlVTdmUFpYNUR5NE82MEFQZVFmN05v
el93Y3lFNDBUNmU5ZWhHSnpFJmU9DQogICAgPg0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgcGF5bG9hZCBtYWlsaW5nIGxpc3QN
CiAgICBwYXlsb2FkQGlldGYub3JnDQogICAgaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu
Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19wYXls
b2FkJmQ9RHdJQ0FnJmM9dXc2VEx1NGh3aEhkaUdKT2d3Y1dENEFqS1F4Nnp2RmNHRXNiZmlZOS1F
SSZyPWxla05PT001bm9WNjF6clBIM3J3UHlodE5uTExXb0xFSGdkMHF1UXhseTgmbT14dXpoNDJY
cnQ4bkFXZVpSVWRJS09fQWRrOEpVcXUzeXpFSnZoN21IZEtVJnM9aHJiZVU3ZlBaWDVEeTRPNjBB
UGVRZjdOb3pfd2N5RTQwVDZlOWVoR0p6RSZlPQ0KICAgIA0KDQo=


From nobody Wed Dec 20 09:30:34 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 E9C82128C0A for ; Wed, 20 Dec 2017 09:30:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 qj_hgx-FY2ev for ; Wed, 20 Dec 2017 09:30:30 -0800 (PST)
Received: from mailout0.cwwtf.bbc.co.uk (mailout0.cwwtf.bbc.co.uk [132.185.160.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E0FE12711E for ; Wed, 20 Dec 2017 09:30:30 -0800 (PST)
Received: from BGB01XI1011.national.core.bbc.co.uk (bgb01xi1011.national.core.bbc.co.uk [10.161.14.15]) by mailout0.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id vBKHUSr8001213; Wed, 20 Dec 2017 17:30:28 GMT
Received: from BGB01XUD1011.national.core.bbc.co.uk ([10.161.14.9]) by BGB01XI1011.national.core.bbc.co.uk ([10.161.14.15]) with mapi id 14.03.0361.001; Wed, 20 Dec 2017 17:30:27 +0000
From: John Fletcher 
To: "Ali C. Begen" , "payload@ietf.org" 
Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-ancillary-13.txt
Thread-Index: AQHTddyoPsNc+Sr2Y02pCni/2NRTZ6NGBrmAgAZ7MAU=
Date: Wed, 20 Dec 2017 17:30:26 +0000
Message-ID: 
References: <151336685958.30439.12106998885650898556@ietfa.amsl.com>, <4E1ED364-EACD-48FA-A80E-C029EFCD96C8@networked.media>
In-Reply-To: <4E1ED364-EACD-48FA-A80E-C029EFCD96C8@networked.media>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.19.161.213]
x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7
x-tm-as-product-ver: SMEX-11.0.0.4255-8.200.1013-23542.001
x-tm-as-result: No--14.133200-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-ancillary-13.txt
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, 20 Dec 2017 17:30:32 -0000

I think there may still be an issue with the definition of Horizontal_Offse=
t.  No definition is given for UHD and I'm not sure that the HD definition =
in terms of Y samples is always applicable.=0A=
=0A=
The ANC data consists of 10-bit words in a 10-bit data stream (or a data ch=
annel of a data stream).  The position should be measured in terms of  10-b=
it words relative to the SAV sequence in the data stream.  A definition alo=
ng those lines works regardless of the image format (YCbCr, RGB, 10-bit, 12=
-bit) or the mapping from source image to interface.=0A=
=0A=
John Fletcher=0A=
________________________________________=0A=
From: payload [payload-bounces@ietf.org] on behalf of Ali C. Begen [ali.beg=
en@networked.media]=0A=
Sent: 16 December 2017 14:21=0A=
To: payload@ietf.org=0A=
Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-ancillary-13.txt=
=0A=
=0A=
Payload WG,=0A=
=0A=
Is there any objection to the latest revision that addresses the issues Tho=
mas pointed out earlier? The draft was in the RFC editor queue and if there=
 are no objections, we will soon ship it back there. But to give people a c=
hance to read and officially comment on the revision, I think we should sta=
rt a new IETF LC for a week.=0A=
=0A=
@Ben, could we do that?=0A=
=0A=
-acbegen=0A=
=0A=
=0A=
=0A=
> On Dec 15, 2017, at 10:40 PM, internet-drafts@ietf.org wrote:=0A=
>=0A=
>=0A=
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.=0A=
> This draft is a work item of the Audio/Video Transport Payloads WG of the=
 IETF.=0A=
>=0A=
>        Title           : RTP Payload for SMPTE ST 291-1 Ancillary Data=0A=
>        Author          : Thomas G. Edwards=0A=
>       Filename        : draft-ietf-payload-rtp-ancillary-13.txt=0A=
>       Pages           : 19=0A=
>       Date            : 2017-12-15=0A=
>=0A=
> Abstract:=0A=
>   This memo describes a real-time transport protocol (RTP) payload=0A=
>   format for the Society of Motion Picture and Television Engineers=0A=
>   (SMPTE) Ancillary data, as defined by SMPTE ST 291-1.  SMPTE=0A=
>   Ancillary data is generally used along with professional video=0A=
>   formats to carry a range of ancillary data types, including time=0A=
>   code, Closed Captioning, and the Active Format Description (AFD).=0A=
>=0A=
>=0A=
> The IETF datatracker status page for this draft is:=0A=
> https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-ancillary/=0A=
>=0A=
> There are also htmlized versions available at:=0A=
> https://tools.ietf.org/html/draft-ietf-payload-rtp-ancillary-13=0A=
> https://datatracker.ietf.org/doc/html/draft-ietf-payload-rtp-ancillary-13=
=0A=
>=0A=
> A diff from the previous version is available at:=0A=
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-ancillary-13=
=0A=
>=0A=
>=0A=
> Please note that it may take a couple of minutes from the time of submiss=
ion=0A=
> until the htmlized version and diff are available at tools.ietf.org.=0A=
>=0A=
> Internet-Drafts are also available by anonymous FTP at:=0A=
> ftp://ftp.ietf.org/internet-drafts/=0A=
>=0A=
> _______________________________________________=0A=
> payload mailing list=0A=
> payload@ietf.org=0A=
> https://www.ietf.org/mailman/listinfo/payload=0A=
=0A=
_______________________________________________=0A=
payload mailing list=0A=
payload@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/payload=0A=