From nobody Wed Apr 8 14:24:50 2020 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 754CC3A180A; Wed, 8 Apr 2020 14:24:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: avt@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.125.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: avt@ietf.org Message-ID: <158638108441.24392.9320385311889759632@ietfa.amsl.com> Date: Wed, 08 Apr 2020 14:24:44 -0700 Archived-At: Subject: [AVTCORE] I-D Action: draft-ietf-payload-rtp-jpegxs-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 21:24:50 -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 Core Maintenance WG of the IETF. Title : RTP Payload Format for ISO/IEC 21122 (JPEG XS) Authors : Sébastien Lugan Antonin Descampe Corentin Damman Thomas Richter Alexandre Willeme Filename : draft-ietf-payload-rtp-jpegxs-03.txt Pages : 23 Date : 2020-04-08 Abstract: This document specifies a Real-Time Transport Protocol (RTP) payload format to be used for transporting JPEG XS (ISO/IEC 21122) encoded video. JPEG XS is a low-latency, lightweight image coding system. Compared to an uncompressed video use case, it allows higher resolutions and frame rates, while offering visually lossless quality, reduced power consumption, and end-to-end latency confined to a fraction of a frame. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-jpegxs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-payload-rtp-jpegxs-03 https://datatracker.ietf.org/doc/html/draft-ietf-payload-rtp-jpegxs-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-jpegxs-03 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 Wed Apr 8 14:28:03 2020 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698EF3A17BE for ; Wed, 8 Apr 2020 14:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJC-wXUc946A for ; Wed, 8 Apr 2020 14:27:59 -0700 (PDT) Received: from mailwdc.intopix.com (mailwdc.intopix.com [212.166.5.108]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD0563A17BB for ; Wed, 8 Apr 2020 14:27:58 -0700 (PDT) Received: from IPX-MAIL.Intopix.com ([172.30.30.1]) by IPX-MAIL.Intopix.com ([172.30.30.1]) with mapi id 14.03.0487.000; Wed, 8 Apr 2020 23:27:56 +0200 From: Antonin Descampe To: "avt@ietf.org" Thread-Topic: [AVTCORE] I-D Action: draft-ietf-payload-rtp-jpegxs-03.txt Thread-Index: AQHWDewr83W1g/uU1UyNLmvCW0f6Tqhvm8EA Date: Wed, 8 Apr 2020 21:27:55 +0000 Message-ID: References: <158638108441.24392.9320385311889759632@ietfa.amsl.com> In-Reply-To: <158638108441.24392.9320385311889759632@ietfa.amsl.com> Accept-Language: fr-FR, fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [81.240.62.237] x-tm-as-product-ver: SMEX-11.7.0.1024-8.500.1020-25342.004 x-tm-as-result: No--15.426700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_B9AA27D5FF464C4D804F9685A01CC95Dintopixcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [AVTCORE] I-D Action: draft-ietf-payload-rtp-jpegxs-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 21:28:02 -0000 --_000_B9AA27D5FF464C4D804F9685A01CC95Dintopixcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCkFzIHRoZSBub3RpZmljYXRpb24geW91IHJlY2VpdmVkIGluZGljYXRlcywg YSBuZXcgdmVyc2lvbiBvZiB0aGUgUlRQIHBheWxvYWQgZm9ybWF0IGZvciBJU08vSUVDIDIxMTIy IChKUEVHIFhTKSBoYXMgYmVlbiBzdWJtaXR0ZWQuDQoNCkNvbXBhcmVkIHRvIHZlcnNpb24gMiwg YSBudW1iZXIgb2YgY2hhbmdlcyBoYXZlIGJlZW4gYnJvdWdodCB0byB0aGUgZG9jdW1lbnQsIHdo aWNoIEkgc3VtbWFyaXNlIGhlcmV1bmRlcjoNCg0KLSAyIGRpZmZlcmVudCBwb3NzaWJsZSBwYWNr ZXRpemF0aW9uIG1vZGVzOiBvbmUgYmFzZWQgb24gSlBFRyBYUyBzbGljZXMgYW5kIG9uZSBiYXNl ZCBvbiBKUEVHIFhTIGNvZGVzdHJlYW0uIFRoZSBsYXRlciBoYXMgYmVlbiBpbnRyb2R1Y2VkIGJl Y2F1c2Ugd2UgbmVlZGVkIGEgcGFja2V0aXphdGlvbiBtb2RlIGltcGx5aW5nIHZlcnkgbGl0dGxl IHByb2Nlc3NpbmcgaW4gYSDCqyB0cmFucy1jYXBzdWxhdGlvbiDCuyB1c2UgY2FzZS4gIEZvciBp bnN0YW5jZSwgd2hlbiBzd2l0Y2hpbmcgZnJvbSBNUEVHLTIgVFMgdG8gU1QyMTEwLTIyLCB3ZSBu ZWVkZWQgYSB3YXkgdG8gcGFja2V0aXNlIHRoYXQgd291bGQgKm5vdCogaW52b2x2ZSBhbnkgcGFy c2luZyBvZiB0aGUgY29kZXN0cmVhbSwgc28gYXMgdG8gbWluaW1pc2UgdGhlIHByb2Nlc3Npbmcg cmVxdWlyZWQgYnkgc3VjaCBzeXN0ZW0gdHJhbnNsYXRpbmcgZnJvbSBvbmUgZW5jYXBzdWxhdGlv biB0byB0aGUgb3RoZXIuIFRoaXMgY29kZXN0cmVhbS1iYXNlZCBwYWNrZXRpemF0aW9uIGFsc28g YXV0b21hdGljYWxseSBlbnN1cmUgdG8gZnVsZmlsIHRoZSBTVDIxMTAtMjIgcmVxdWlyZW1lbnRz IG9mIGhhdmluZyB0aGUgc2FtZSBhbW91bnQgb2YgYnl0ZXMgYW5kIHRoZSBzYW1lIGFtb3VudCBv ZiBSVFAgcGFja2V0cyBwZXIgZnJhbWUuIFdlIGRpZCBsZWF2ZSB0aGUgc2xpY2UtYmFzZWQgcGFj a2V0aXphdGlvbiBhcyB3ZWxsIGFzIGl0IGNhbiBiZSB1c2VmdWwgaW4gY2VydGFpbiB1c2UgY2Fz ZXMgYW5kIGlmIFJUUCBwYWNrZXRzIGFyZSBzZW50IG91dC1vZi1vcmRlciBieSB0aGUgdHJhbnNt aXR0ZXIgKHdoaWNoIGNhbiBiZSByZWxldmFudCBmb3Igc29tZSBpbXBsZW1lbnRhdGlvbnMgb2Yg YSBmdWxsIFNXIHdvcmtmbG93KS4gTm90ZSBob3dldmVyIHRoYXQgaW4gdGhlIHNsaWNlLWJhc2Vk IHBhY2tldGl6YXRpb24sIGFkZGl0aW9uYWwgY29uc3RyYWludCBuZWVkIHRvIGJlIHNldCBhdCBy YXRlIGFsbG9jYXRpb24gc3RhZ2UgdG8gZnVsZmlsIFNUMjExMC0yMiByZXF1aXJlbWVudHMgbWVu dGlvbmVkIGFib3ZlLg0KLSBBIGJpdCBpbmRpY2F0aW5nIGlmIHRoZSB0cmFuc21pdHRlciBoYXMg c2VudCB0aGUgcGFja2V0cyBpbiBzZXF1ZW50aWFsIG9yZGVyLiBJZiBwYWNrZXRzIGhhdmUgYmVl biBzZW50IG91dC1vZi1vcmRlciwgdGhlIHNsaWNlLWJhc2VkIHBhY2tldGl6YXRpb24gaXMgcmVx dWlyZWQgdG8gYmUgdXNlZC4NCi0gRXhwbGljaXQgc3VwcG9ydCBmb3IgaW50ZXJsYWNlIHZpZGVv DQotIFJlLWluY2x1c2lvbiBvZiBFT0MgbWFya2VyIHRvIGtlZXAgdGhlIEpQRUcgWFMgY29kZXN0 cmVhbSBjb25zaXN0ZW50IGFuZCBzZWxmLWNvbnRhaW5lZC4NCg0KVGhhbmtzIHRvIHRoZXNlIGNo YW5nZXMsIHRoZSB0cmFuc3BvcnQgb2YgSlBFRyBYUyBvdmVyIFJUUCBpbmhlcmVudGx5IGdpdmVz IHRoZSBmb2xsb3dpbmcgZ3VhcmFudGVlczoNCjEuIENvbnN0YW50IG51bWJlciBvZiBieXRlcyBh bmQgbnVtYmVyIG9mIHBhY2tldHMgcGVyIGZyYW1lIChTVDIxMTAtMjIpLg0KMi4gTm8gdHJhbnNj b2Rpbmcgb3IgZGVlcCBjb2Rlc3RyZWFtIGluc3BlY3Rpb24gd2hlbiBjaGFuZ2luZyB0aGUgZW5j YXBzdWxhdGlvbiAoc2VlIGNvZGVzdHJlYW0tcGFja2V0aXphdGlvbiBleHBsYW5hdGlvbiBhYm92 ZSkuDQozLiBMb3ctbGF0ZW5jeSBiZWhhdmlvdXIuDQo0LiBObyBxdWFsaXR5IGxvc3MgaW5kdWNl ZCBieSB0aGUgdHJhbnNwb3J0DQo1LiBMb3cgY29tcGxleCBIVyBhbmQgZmFzdCBTVyBkZWNvZGlu Zy4NCg0KUGxlYXNlIHByb3ZpZGUgeW91ciBjb21tZW50cyBvciBxdWVzdGlvbnMsIGlmIGFueS4N Cg0KS2luZCByZWdhcmRzLA0KDQpBbnRvbmluDQoNCkxlIDggYXZyLiAyMDIwIMOgIDIzOjI0LCBp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4g YSDDqWNyaXQgOg0KDQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRo ZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NClRoaXMgZHJhZnQgaXMgYSB3 b3JrIGl0ZW0gb2YgdGhlIEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlIFdH IG9mIHRoZSBJRVRGLg0KDQogICAgICAgVGl0bGUgICAgICAgICAgIDogUlRQIFBheWxvYWQgRm9y bWF0IGZvciBJU08vSUVDIDIxMTIyIChKUEVHIFhTKQ0KICAgICAgIEF1dGhvcnMgICAgICAgICA6 IFPDqWJhc3RpZW4gTHVnYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICBBbnRvbmluIERlc2Nh bXBlDQogICAgICAgICAgICAgICAgICAgICAgICAgQ29yZW50aW4gRGFtbWFuDQogICAgICAgICAg ICAgICAgICAgICAgICAgVGhvbWFzIFJpY2h0ZXINCiAgICAgICAgICAgICAgICAgICAgICAgICBB bGV4YW5kcmUgV2lsbGVtZQ0KRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0 cC1qcGVneHMtMDMudHh0DQpQYWdlcyAgICAgICAgICAgOiAyMw0KRGF0ZSAgICAgICAgICAgIDog MjAyMC0wNC0wOA0KDQpBYnN0cmFjdDoNCiAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBSZWFs LVRpbWUgVHJhbnNwb3J0IFByb3RvY29sIChSVFApIHBheWxvYWQNCiAgZm9ybWF0IHRvIGJlIHVz ZWQgZm9yIHRyYW5zcG9ydGluZyBKUEVHIFhTIChJU08vSUVDIDIxMTIyKSBlbmNvZGVkDQogIHZp ZGVvLiAgSlBFRyBYUyBpcyBhIGxvdy1sYXRlbmN5LCBsaWdodHdlaWdodCBpbWFnZSBjb2Rpbmcg c3lzdGVtLg0KICBDb21wYXJlZCB0byBhbiB1bmNvbXByZXNzZWQgdmlkZW8gdXNlIGNhc2UsIGl0 IGFsbG93cyBoaWdoZXINCiAgcmVzb2x1dGlvbnMgYW5kIGZyYW1lIHJhdGVzLCB3aGlsZSBvZmZl cmluZyB2aXN1YWxseSBsb3NzbGVzcw0KICBxdWFsaXR5LCByZWR1Y2VkIHBvd2VyIGNvbnN1bXB0 aW9uLCBhbmQgZW5kLXRvLWVuZCBsYXRlbmN5IGNvbmZpbmVkDQogIHRvIGEgZnJhY3Rpb24gb2Yg YSBmcmFtZS4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBk cmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcGF5 bG9hZC1ydHAtanBlZ3hzLw0KDQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFp bGFibGUgYXQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1wYXlsb2Fk LXJ0cC1qcGVneHMtMDMNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJh ZnQtaWV0Zi1wYXlsb2FkLXJ0cC1qcGVneHMtMDMNCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3Vz IHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtanBlZ3hzLTAzDQoNCg0KUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCB0b29scy5pZXRmLm9yZy4NCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBi eSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8N Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQXVk aW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UNCmF2dEBpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnQNCg0KLS0NCkFudG9uaW4gRGVzY2Ft cGUgLSBQaC5ELg0KQ29tcHJlc3Npb24gdGVjaG5vbG9naXN0DQoNCkludG9QSVggcy5hLg0KKzMy IDEwIDIzIDg0IDcwIChPZmZpY2UpDQphLmRlc2NhbXBlQGludG9waXguY29tPG1haWx0bzphLmRl c2NhbXBlQGludG9waXguY29tPg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBVbmxlc3Mgb3Ro ZXJ3aXNlIGV4cGxpY2l0bHkgb3IgaW1wbGljdGx5IHN0YXRlZCwgdGhpcyBlbWFpbCBtZXNzYWdl IGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIGFyZSB0aGUgcHJvcGVydHkgb2YgaW50b1BJWCBT QSBhbmQgYXJlIHN0cmljdGx5IGNvbmZpZGVudGlhbC4NCklmIHlvdSBhcmUgYW4gdW5pbnRlbmRl ZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseS4NCg0K --_000_B9AA27D5FF464C4D804F9685A01CC95Dintopixcom_ Content-Type: text/html; charset="utf-8" Content-ID: <6A916F657FDED14886473254B2122C2E@Intopix.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkRlYXIgYWxsLA0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QXMgdGhlIG5vdGlmaWNhdGlvbiB5b3Ug cmVjZWl2ZWQgaW5kaWNhdGVzLCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBSVFAgcGF5bG9hZCBmb3Jt YXQgZm9yIElTTy9JRUMgMjExMjIgKEpQRUcgWFMpIGhhcyBiZWVuIHN1Ym1pdHRlZC48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkNvbXBh cmVkIHRvIHZlcnNpb24gMiwgYSBudW1iZXIgb2YgY2hhbmdlcyBoYXZlIGJlZW4gYnJvdWdodCB0 byB0aGUgZG9jdW1lbnQsIHdoaWNoIEkgc3VtbWFyaXNlIGhlcmV1bmRlcjo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj4tIDIgZGlmZmVyZW50IHBvc3NpYmxlIHBhY2tldGl6YXRpb24gbW9kZXM6IG9uZSBiYXNl ZCBvbiBKUEVHIFhTIHNsaWNlcyBhbmQgb25lIGJhc2VkIG9uIEpQRUcgWFMgY29kZXN0cmVhbS4g VGhlIGxhdGVyIGhhcyBiZWVuIGludHJvZHVjZWQgYmVjYXVzZSB3ZSBuZWVkZWQgYSBwYWNrZXRp emF0aW9uIG1vZGUgaW1wbHlpbmcgdmVyeSBsaXR0bGUgcHJvY2Vzc2luZyBpbiBhIMKrJm5ic3A7 dHJhbnMtY2Fwc3VsYXRpb24mbmJzcDvCuyB1c2UgY2FzZS4NCiAmbmJzcDtGb3IgaW5zdGFuY2Us IHdoZW4gc3dpdGNoaW5nIGZyb20gTVBFRy0yIFRTIHRvIFNUMjExMC0yMiwgd2UgbmVlZGVkIGEg d2F5IHRvIHBhY2tldGlzZSB0aGF0IHdvdWxkICpub3QqIGludm9sdmUgYW55IHBhcnNpbmcgb2Yg dGhlIGNvZGVzdHJlYW0sIHNvIGFzIHRvIG1pbmltaXNlIHRoZSBwcm9jZXNzaW5nIHJlcXVpcmVk IGJ5IHN1Y2ggc3lzdGVtIHRyYW5zbGF0aW5nIGZyb20gb25lIGVuY2Fwc3VsYXRpb24gdG8gdGhl IG90aGVyLiBUaGlzIGNvZGVzdHJlYW0tYmFzZWQNCiBwYWNrZXRpemF0aW9uIGFsc28gYXV0b21h dGljYWxseSBlbnN1cmUgdG8gZnVsZmlsIHRoZSBTVDIxMTAtMjIgcmVxdWlyZW1lbnRzIG9mIGhh dmluZyB0aGUgc2FtZSBhbW91bnQgb2YgYnl0ZXMgYW5kIHRoZSBzYW1lIGFtb3VudCBvZiBSVFAg cGFja2V0cyBwZXIgZnJhbWUuIFdlIGRpZCBsZWF2ZSB0aGUgc2xpY2UtYmFzZWQgcGFja2V0aXph dGlvbiBhcyB3ZWxsIGFzIGl0IGNhbiBiZSB1c2VmdWwgaW4gY2VydGFpbiB1c2UgY2FzZXMgYW5k IGlmDQogUlRQIHBhY2tldHMgYXJlIHNlbnQgb3V0LW9mLW9yZGVyIGJ5IHRoZSB0cmFuc21pdHRl ciAod2hpY2ggY2FuIGJlIHJlbGV2YW50IGZvciBzb21lIGltcGxlbWVudGF0aW9ucyBvZiBhIGZ1 bGwgU1cgd29ya2Zsb3cpLiBOb3RlIGhvd2V2ZXIgdGhhdCBpbiB0aGUgc2xpY2UtYmFzZWQgcGFj a2V0aXphdGlvbiwgYWRkaXRpb25hbCBjb25zdHJhaW50IG5lZWQgdG8gYmUgc2V0IGF0IHJhdGUg YWxsb2NhdGlvbiBzdGFnZSB0byBmdWxmaWwgU1QyMTEwLTIyDQogcmVxdWlyZW1lbnRzIG1lbnRp b25lZCBhYm92ZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LSBBIGJpdCBpbmRpY2F0aW5nIGlmIHRo ZSB0cmFuc21pdHRlciBoYXMgc2VudCB0aGUgcGFja2V0cyBpbiBzZXF1ZW50aWFsIG9yZGVyLiBJ ZiBwYWNrZXRzIGhhdmUgYmVlbiBzZW50IG91dC1vZi1vcmRlciwgdGhlIHNsaWNlLWJhc2VkIHBh Y2tldGl6YXRpb24gaXMgcmVxdWlyZWQgdG8gYmUgdXNlZC48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+LSBFeHBsaWNpdCBzdXBwb3J0IGZvciBpbnRlcmxhY2Ug dmlkZW88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LSBSZS1pbmNsdXNpb24gb2YgRU9DIG1hcmtlciB0 byBrZWVwIHRoZSBKUEVHIFhTIGNvZGVzdHJlYW0gY29uc2lzdGVudCBhbmQgc2VsZi1jb250YWlu ZWQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5UaGFua3MgdG8gdGhlc2UgY2hhbmdlcywgdGhlIHRyYW5zcG9ydCBvZiBKUEVHIFhTIG92 ZXIgUlRQIGluaGVyZW50bHkgZ2l2ZXMgdGhlIGZvbGxvd2luZyBndWFyYW50ZWVzOjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4xLiBDb25zdGFudCBudW1iZXIgb2YgYnl0ZXMgYW5kIG51bWJlciBvZiBw YWNrZXRzIHBlciBmcmFtZSAoU1QyMTEwLTIyKS48YnIgY2xhc3M9IiI+DQoyLiZuYnNwO05vIHRy YW5zY29kaW5nIG9yIGRlZXAgY29kZXN0cmVhbSBpbnNwZWN0aW9uIHdoZW4gY2hhbmdpbmcgdGhl IGVuY2Fwc3VsYXRpb24gKHNlZSBjb2Rlc3RyZWFtLXBhY2tldGl6YXRpb24gZXhwbGFuYXRpb24g YWJvdmUpLjxiciBjbGFzcz0iIj4NCjMuJm5ic3A7TG93LWxhdGVuY3kgYmVoYXZpb3VyLjxiciBj bGFzcz0iIj4NCjQuJm5ic3A7Tm8gcXVhbGl0eSBsb3NzIGluZHVjZWQgYnkgdGhlIHRyYW5zcG9y dDxiciBjbGFzcz0iIj4NCjUuJm5ic3A7TG93IGNvbXBsZXggSFcgYW5kIGZhc3QgU1cgZGVjb2Rp bmcuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5QbGVhc2UgcHJvdmlkZSB5b3VyIGNvbW1lbnRzIG9yIHF1ZXN0aW9ucywgaWYg YW55LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+S2luZCByZWdhcmRzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QW50b25pbiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxi ciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj5MZSA4IGF2ci4gMjAyMCDDoCAyMzoyNCwgPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyIgY2xhc3M9IiI+DQppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+IGEg w6ljcml0IDo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpBIE5ldyBJbnRlcm5l dC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGly ZWN0b3JpZXMuPGJyIGNsYXNzPSIiPg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUg QXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UgV0cgb2YgdGhlIElFVEYuPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7VGl0bGUgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBSVFAgUGF5bG9hZCBGb3JtYXQgZm9yIElTTy9JRUMgMjEx MjIgKEpQRUcgWFMpPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7QXV0aG9ycyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs6IFPDqWJhc3RpZW4gTHVnYW48YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtBbnRvbmluIERlc2NhbXBlPGJyIGNsYXNzPSIiPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Q29yZW50aW4gRGFtbWFuPGJyIGNsYXNz PSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhvbWFzIFJpY2h0ZXI8 YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtBbGV4YW5k cmUgV2lsbGVtZTxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5 bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPkZpbGVuYW1lICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1qcGVneHMtMDMu dHh0PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hp dGUtc3BhY2U6cHJlIj48L3NwYW4+UGFnZXMgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiAyMzxiciBjbGFzcz0iIj4NCjxzcGFuIGNs YXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPkRhdGUg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7OiAyMDIwLTA0LTA4PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQWJzdHJh Y3Q6PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7VGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBS ZWFsLVRpbWUgVHJhbnNwb3J0IFByb3RvY29sIChSVFApIHBheWxvYWQ8YnIgY2xhc3M9IiI+DQom bmJzcDsmbmJzcDtmb3JtYXQgdG8gYmUgdXNlZCBmb3IgdHJhbnNwb3J0aW5nIEpQRUcgWFMgKElT Ty9JRUMgMjExMjIpIGVuY29kZWQ8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDt2aWRlby4gJm5i c3A7SlBFRyBYUyBpcyBhIGxvdy1sYXRlbmN5LCBsaWdodHdlaWdodCBpbWFnZSBjb2Rpbmcgc3lz dGVtLjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO0NvbXBhcmVkIHRvIGFuIHVuY29tcHJlc3Nl ZCB2aWRlbyB1c2UgY2FzZSwgaXQgYWxsb3dzIGhpZ2hlcjxiciBjbGFzcz0iIj4NCiZuYnNwOyZu YnNwO3Jlc29sdXRpb25zIGFuZCBmcmFtZSByYXRlcywgd2hpbGUgb2ZmZXJpbmcgdmlzdWFsbHkg bG9zc2xlc3M8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtxdWFsaXR5LCByZWR1Y2VkIHBvd2Vy IGNvbnN1bXB0aW9uLCBhbmQgZW5kLXRvLWVuZCBsYXRlbmN5IGNvbmZpbmVkPGJyIGNsYXNzPSIi Pg0KJm5ic3A7Jm5ic3A7dG8gYSBmcmFjdGlvbiBvZiBhIGZyYW1lLjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBw YWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcGF5bG9hZC1ydHAtanBlZ3hzLyIgY2xh c3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1wYXlsb2Fk LXJ0cC1qcGVneHMvPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZXJlIGFyZSBh bHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDo8YnIgY2xhc3M9IiI+DQpodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1qcGVneHMtMDM8YnIg Y2xhc3M9IiI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWll dGYtcGF5bG9hZC1ydHAtanBlZ3hzLTAzPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQSBk aWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0OjxiciBjbGFzcz0i Ij4NCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXBheWxvYWQt cnRwLWpwZWd4cy0wMzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N ClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb248YnIgY2xhc3M9IiI+DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkg YW5vbnltb3VzIEZUUCBhdDo8YnIgY2xhc3M9IiI+DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzLzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIi Pg0KQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2U8YnIgY2xhc3M9IiI+DQph dnRAaWV0Zi5vcmc8YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2F2dDxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Vi a2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3Bh Y2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9InRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsg LXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0idGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHdvcmQtd3JhcDogYnJl YWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFm dGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3At bW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5i c3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0 LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7 IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Vi a2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3Bh Y2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAt d2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUt c3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3Jk OyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hp dGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13 b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXIt d2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVh ay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg MCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBi cmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazog YWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwg MCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFw OiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVh azogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+LS08L2Rpdj4N CjxkaXYgY2xhc3M9IiI+QW50b25pbiBEZXNjYW1wZSAtIFBoLkQuPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPkNvbXByZXNzaW9uIHRlY2hub2xvZ2lzdCZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SW50b1BJWCBzLmEuPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPiYjNDM7MzIgMTAgMjMgODQgNzAgKE9mZmljZSk8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGEgaHJlZj0ibWFpbHRvOmEuZGVzY2FtcGVAaW50b3BpeC5jb20iIGNsYXNzPSIiPmEu ZGVzY2FtcGVAaW50b3BpeC5jb208L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KQ09ORklERU5USUFMSVRZIE5PVElDRTombmJzcDtV bmxlc3Mgb3RoZXJ3aXNlIGV4cGxpY2l0bHkgb3IgaW1wbGljdGx5IHN0YXRlZCwgdGhpcyBlbWFp bCBtZXNzYWdlIGFuZCZuYnNwO2FueSBvZiBpdHMgYXR0YWNobWVudHMgYXJlIHRoZSBwcm9wZXJ0 eSBvZiBpbnRvUElYIFNBIGFuZCBhcmUgc3RyaWN0bHkgY29uZmlkZW50aWFsLjxiciBjbGFzcz0i Ij4NCklmIHlvdSBhcmUgYW4gdW5pbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBpbW1lZGlhdGVseS48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGJyIGNsYXNzPSIiPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B9AA27D5FF464C4D804F9685A01CC95Dintopixcom_-- From nobody Thu Apr 9 14:24:25 2020 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BB93A0EE7 for ; Thu, 9 Apr 2020 14:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, 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=egensajt.se 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 MQcFYOdPVyib for ; Thu, 9 Apr 2020 14:24:20 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E36A3A0EE5 for ; Thu, 9 Apr 2020 14:24:19 -0700 (PDT) Received: from [192.168.2.136] (h83-209-157-29.cust.a3fiber.se [83.209.157.29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id ADD712201C for ; Thu, 9 Apr 2020 23:24:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1586467457; bh=SqnuuX32ENLxIbMarbNvk4ljJzMGqebh66njfSTIKN8=; h=Subject:References:To:From:Date:In-Reply-To:From; b=XJkhY6pfXkakP+jzYs8BjDn3g+3zb8P9NEWd5WAceltFETJvRofoAu+oebI0DanGe oMPJBFV4QQr2Suentec+5fid96i9ki2WUOp247e8z9TDATZX0cjCAiJCcx7nfBxUfz 36kGHNL9h17XSz4R7jnP69PTPwD0mYnp5N3DwaJQ= References: <158646590390.1752.844894769869952053@ietfa.amsl.com> To: "avtcore@ietf.org" From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= X-Forwarded-Message-Id: <158646590390.1752.844894769869952053@ietfa.amsl.com> Message-ID: <881c27b6-ef8c-077c-6954-c38bfaa65644@ghaccess.se> Date: Thu, 9 Apr 2020 23:24:15 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <158646590390.1752.844894769869952053@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: sv Archived-At: Subject: [AVTCORE] New Version : draft-hellstrom-avtcore-multi-party-rtt-source-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 21:24:23 -0000 A new version has been submitted of draft-hellstrom-avtcore-multi-party-rtt-source Summary of changes: New title to better match contents: RTP-mixer formatting of multi-party Real-time text New company and e-mail of the author Checked and modified RFC 2119 - wording Enhanced section on mixing for multi-party-unaware endpoints to be a complete specification. A paragraph recommending characters per second CPS=150 inserted in the performance section. ---------------------------------------------------------------------------------------- Comments are welcome, Regards Gunnar Hellström gunnar.hellstrom@ghaccess.se ------------------------------------------------------------------------------------------------ A new version of I-D, draft-hellstrom-avtcore-multi-party-rtt-source-03.txt has been successfully submitted by Gunnar Hellstrom and posted to the IETF repository. Name: draft-hellstrom-avtcore-multi-party-rtt-source Revision: 03 Title: RTP-mixer formatting of multi-party Real-time text Document date: 2020-04-09 Group: Individual Submission Pages: 24 URL: https://www.ietf.org/internet-drafts/draft-hellstrom-avtcore-multi-party-rtt-source-03.txt Status: https://datatracker.ietf.org/doc/draft-hellstrom-avtcore-multi-party-rtt-source/ Htmlized: https://tools.ietf.org/html/draft-hellstrom-avtcore-multi-party-rtt-source-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-hellstrom-avtcore-multi-party-rtt-source Diff: https://www.ietf.org/rfcdiff?url2=draft-hellstrom-avtcore-multi-party-rtt-source-03 Abstract: Real-time text mixers for multi-party sessions need to identify the source of each transmitted group of text so that the text can be presented by endpoints in suitable grouping with other text from the same source. Regional regulatory requirements specify provision of real-time text in multi-party calls. RFC 4103 mixer implementations can use traditional RTP functions for source identification, but the mixer source switching performance is limited when using the default transmission with redundancy. An enhancement for RFC 4103 real-time text mixing is provided in the present specification, suitable for a centralized conference model that enables source identification and efficient source switching. The intended use is for real-time text mixers and multi-party-aware participant endpoints. The mechanism builds on use of the CSRC list in the RTP packet. A capability exchange is specified so that it can be verified that a participant can handle the multi-party coded real-time text stream. The capability is indicated by an sdp media attribute "rtt-mix". A brief description about how a mixer can format text for the case when the endpoint is not multi-party aware is also provided. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri Apr 10 05:47:42 2020 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8E63A08E4; Fri, 10 Apr 2020 05:47:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: avt@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.126.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: avt@ietf.org Message-ID: <158652285643.19330.14322869993707227822@ietfa.amsl.com> Date: Fri, 10 Apr 2020 05:47:36 -0700 Archived-At: Subject: [AVTCORE] I-D Action: draft-ietf-payload-tsvcis-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2020 12:47:37 -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 Core Maintenance WG of the IETF. Title : RTP Payload Format for TSVCIS Codec Authors : Victor Demjanenko John Punaro David Satterlee Filename : draft-ietf-payload-tsvcis-05.txt Pages : 20 Date : 2020-04-10 Abstract: This document describes the RTP payload format for the Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) speech coder. TSVCIS is a scalable narrowband voice coder supporting varying encoder data rates and fallbacks. It is implemented as an augmentation to the Mixed Excitation Linear Prediction Enhanced (MELPe) speech coder by conveying additional speech coder parameters for enhancing voice quality. TSVCIS augmented speech data is processed in conjunction with its temporal matched MELP 2400 speech data. The RTP packetization of TSVCIS and MELPe speech coder data is described in detail. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-tsvcis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-payload-tsvcis-05 https://datatracker.ietf.org/doc/html/draft-ietf-payload-tsvcis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-tsvcis-05 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 Fri Apr 10 11:01:51 2020 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FD23A0B9A; Fri, 10 Apr 2020 11:01:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-payload-tsvcis@ietf.org, avtcore-chairs@ietf.org, avt@ietf.org, Ali Begen , ali.begen@networked.media X-Test-IDTracker: no X-IETF-IDTracker: 6.126.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <158654170958.11534.12008321834761714150@ietfa.amsl.com> Date: Fri, 10 Apr 2020 11:01:49 -0700 Archived-At: Subject: [AVTCORE] Benjamin Kaduk's No Objection on draft-ietf-payload-tsvcis-05: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2020 18:01:50 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-payload-tsvcis-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-payload-tsvcis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my Discuss points! From nobody Wed Apr 15 11:31:24 2020 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C5B3A0863 for ; Wed, 15 Apr 2020 11:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=8x8.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 hQ4eZUI8k-1T for ; Wed, 15 Apr 2020 11:31:21 -0700 (PDT) Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (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 D246F3A0866 for ; Wed, 15 Apr 2020 11:31:20 -0700 (PDT) Received: by mail-qv1-xf36.google.com with SMTP id c12so618352qvj.5 for ; Wed, 15 Apr 2020 11:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=8x8.com; s=googlemail; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=Qi1KJ9ghIq4LAe1trJnIFeQ47WQ5YNfu1Iu2sZYiOM8=; b=XrSVXXeFe5yjbJyt+re6zuQaha4RFKGeWu4ZV5r9HArR2TJ2jFMQw5a7jF7xfmTgyt nz+aQNgEZu/xlDpBfYHu+zIKKdeoWwrAr45N0OGM8A92dP5xnIXGD3t+xrpPASu+z4mf VJ2VDcFaYyMT+b9zpHFeegHa7UVeqdGj2p/Fk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=Qi1KJ9ghIq4LAe1trJnIFeQ47WQ5YNfu1Iu2sZYiOM8=; b=X2XzzbIU/KEnB7qCurFx2W+Du4wJ+Qv4dA/rtm+HYAp0so/y2wLMEIzXyH5d2Cs3Dv nzO7cu8NaLFUp9sm0p9702b1APBy4I3a1xt1sTc2HRnABqIy//0y/ne/vBtcIJOJ1XLF 0uS4dHspBGWcTURcZcPbHSwlqqTLyF5jF8cJIBoiTzfAv4m4V5DwCQXrKIFcfTTqZ/6r 1QOY+vw4GUxAmYRaaSaxjGf5IgXPeoD/5xdRs5b2c0dnE8rPjQyWIy49UiEfiQk9zMPd UAa6gWnGh0gA3rtUpJO/ev/V9/37coGnrEsCUpD2U3Sy96uZvS9XkVAbGM3Q3YK0EgIR ZIbQ== X-Gm-Message-State: AGi0PuYz3adkJf5Ba0rwclA4UbsP/GRrUvb00UyUcGkg12Z+y2Xb2MNk x5+OIK+x1ZEFsNJNGg/e6dgXvuK8nkc= X-Google-Smtp-Source: APiQypJOaLenW4eHH7pFS7f9p7V+3m6SDhG2S0ol37n79NETJlNFr/8hjv6ItRkYJo1TqRUugAejyg== X-Received: by 2002:ad4:49c9:: with SMTP id j9mr6286441qvy.147.1586975479492; Wed, 15 Apr 2020 11:31:19 -0700 (PDT) Received: from ?IPv6:2601:86:101:74d0:dd6:a759:a641:eb37? ([2601:86:101:74d0:dd6:a759:a641:eb37]) by smtp.gmail.com with ESMTPSA id w27sm13928663qtc.18.2020.04.15.11.31.18 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Apr 2020 11:31:18 -0700 (PDT) From: Jonathan Lennox Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Message-Id: <591BF32C-0FBD-4E24-BC99-77CB7AC6DE0F@8x8.com> Date: Wed, 15 Apr 2020 14:31:18 -0400 To: avt@ietf.org X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: [AVTCORE] Call for adoption: RTP mixer formatting of multi-party real-time text X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 18:31:23 -0000 Hi all, The working group chairs are asking for adoption of a new milestone for = RTP mixer formatting of multi-party real-time text, with = draft-hellstrom-avtcore-multi-party-rtt-source-03 as the basis for the = initial WG document. Please respond by Wednesday, April 29th with whether you agree with this = adoption. Technical comments comments on document itself are also always welcome, = of course! Thanks, Jonathan Lennox AVTcore co-chair From nobody Wed Apr 15 13:41:29 2020 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C873A0A29 for ; Wed, 15 Apr 2020 13:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=alum.mit.edu 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 0mGpj-S3c7Hs for ; Wed, 15 Apr 2020 13:41:12 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on20612.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe59::612]) (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 C451C3A0A9F for ; Wed, 15 Apr 2020 13:41:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TDK486VZY/Ua2mtp1l5vcpsMEUDv65DxZc8is7iJkDCzmyENq3tGYB6p9sDmpG6ukUxeXoOdpGEUVlIXQmm84hWGLQVZ+M97c3Fu7+WqXPDrt7o7SQweDQJd5N8/gV7FPS/oL/djzlf8w8FpABCMKtZc0p8mmXLAmeVqvauxwGeeycTQgwz0DpqZHinx8EwEh1+W0B15a37mCc0aoUBqO0GkpzZbwdKbDzlIFOaS/05zuaxjHWhYVOP1f+9Ykn+ELMmp/yG11fyMcDWUoukkEPZUssUx9U5NRp0vX6HOtp2uc6Nmt5V6d8D/Nz3oB9QOcz8WAXJgfpNoRaphzp/kOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LRO7SigOQF8gOFSImiO+InZHZ1nFv0SINgI4Kkb8byE=; b=E5/8wAluyJZJwMIOxTixm+XSmioQMPwyE+bjO7h4obVBb79RUERCRPpupKCfC+LA/XdSpBrmdwndpCW7SOQZci4aKzZW2cUnZFW6SCusN6XzM0hvBVa3HFz8cTqFKrJYq/i8OPVhW+eN8BKW2f1SZiLiaVsbopU0XLgevg1TCNmdhJYJkmXfeucxe1xOStkiWY60yzcF0wmHD4GQNspL/4CVpAaYLvr8ux8gmWH61OSNhoNd6pPlvZ1H8xYkeKMO/155KterntEEmQtO8d4/dPy0LWaUPPJtmI0VYpBmyLXKcoqLBmmk+Lz+fUa/Ofzg9KSXTnkw0vPtmjgCxCtM8g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LRO7SigOQF8gOFSImiO+InZHZ1nFv0SINgI4Kkb8byE=; b=E3oTey9EfqaB/lID7wUjnBiJEuaoFtWvuANRAyDzQ28mRt71T45pCfmKKGaYjkEo2a+YedDlQ7aDiIkX0cNWDY+LKUxfOYXSDqDg1+7uGwSeL0V3KNlWsMOHTUvJ2B5PHbNb2qEViyIBj3rtfLb0YBuhG6+xyKlINB+CcVx8mz4= Received: from MN2PR11CA0017.namprd11.prod.outlook.com (2603:10b6:208:23b::22) by BN6PR12MB1732.namprd12.prod.outlook.com (2603:10b6:404:107::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.26; Wed, 15 Apr 2020 20:41:09 +0000 Received: from BL2NAM02FT020.eop-nam02.prod.protection.outlook.com (2603:10b6:208:23b:cafe::91) by MN2PR11CA0017.outlook.office365.com (2603:10b6:208:23b::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.25 via Frontend Transport; Wed, 15 Apr 2020 20:41:09 +0000 Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT020.mail.protection.outlook.com (10.152.77.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.25 via Frontend Transport; Wed, 15 Apr 2020 20:41:08 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 03FKf67j026660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 15 Apr 2020 16:41:07 -0400 To: "avt@ietf.org" References: <591BF32C-0FBD-4E24-BC99-77CB7AC6DE0F@8x8.com> From: Paul Kyzivat Message-ID: <4f2d5a22-fae0-da3f-a14f-730292dd52b4@alum.mit.edu> Date: Wed, 15 Apr 2020 16:41:06 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <591BF32C-0FBD-4E24-BC99-77CB7AC6DE0F@8x8.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(10009020)(136003)(396003)(39860400002)(346002)(376002)(46966005)(6916009)(186003)(356005)(7596003)(26826003)(47076004)(8676002)(336012)(8936002)(478600001)(246002)(31696002)(4744005)(966005)(82740400003)(2906002)(86362001)(75432002)(31686004)(36906005)(53546011)(316002)(26005)(956004)(786003)(2616005)(70586007)(70206006)(5660300002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c93035d9-80b5-4d40-3b67-08d7e17d539e X-MS-TrafficTypeDiagnostic: BN6PR12MB1732: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7691; X-Forefront-PRVS: 0374433C81 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: MdBXaMcka2N+JHvnn7FMlrFdy/JUGvNiqoDF0sH7rSub9Z2DnzfdBoo0Jx9XSLzsVDhkCMx7EAcpaZZ1MuejRKAVMmTm6z7Sap62+BxOirv978FMUcaHFHtwWMGLg7Dagi6zB53pH0BHwnjQ8zULJ/Y4Ez2037W/aj74v/Pk8aQx1MRwjMMUxlzmpgvrSxQzxrKZJCTTe3rKTQaU3GNcIJe9y1tZ96yvyMBAyL4t9TyOVH/8t2ywVPYnLg4K6au9V38+qC6bdQOOMDlzCsSjsb1TpRSJf+USrmh/ItSsjMdxJUwpY9ZEtAvF9zHykoYf8gAiMgdAAFNS0B+j5zBQXHf4eM8iY+vEQbhTaV6Ft2chq6rqd5tm17h0QjAu//T0UY3FjtYbTENZlHUNhW2WnAON6zphO5goBnHGHkt0tS8llcHFStnWRpyuOn3zjBee46xI6zQ0FxJTlkUCEPoWWLy6bsG4zfYAyQDopJtCHtiJlxbeTkP6CJAU/Oj4rBbtT39a1p9ViaZAXhrG9CvJc/LDQp3QcPV/Y4YHl5SSRIsHhLGxpbfLU6zJPBsL4n1KS5TnjiKczFTPypGaZPC+JA== X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Apr 2020 20:41:08.5625 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c93035d9-80b5-4d40-3b67-08d7e17d539e X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR12MB1732 Archived-At: Subject: Re: [AVTCORE] Call for adoption: RTP mixer formatting of multi-party real-time text X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 20:41:16 -0000 I support this. On 4/15/20 2:31 PM, Jonathan Lennox wrote: > Hi all, > > The working group chairs are asking for adoption of a new milestone for RTP mixer formatting of multi-party real-time text, with draft-hellstrom-avtcore-multi-party-rtt-source-03 as the basis for the initial WG document. > > Please respond by Wednesday, April 29th with whether you agree with this adoption. > > Technical comments comments on document itself are also always welcome, of course! > > Thanks, > > Jonathan Lennox > AVTcore co-chair > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From nobody Wed Apr 15 22:00:18 2020 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707C03A0DB8 for ; Wed, 15 Apr 2020 22:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=egensajt.se 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 C5akTt8FAcw2 for ; Wed, 15 Apr 2020 22:00:13 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [193.42.159.246]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F1B83A0DB6 for ; Wed, 15 Apr 2020 22:00:12 -0700 (PDT) Received: from [192.168.2.199] (h77-53-230-67.cust.a3fiber.se [77.53.230.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 6418A2006F; Thu, 16 Apr 2020 07:00:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1587013209; bh=ZxlO4ctMsxx/XiK7MgIJY2OI/YbrvgMD2Vmrn9chNnw=; h=Date:Subject:From:To:In-Reply-To:References:From; b=aDk/5QosGU3OaBQt4AfSdIElYaWxDxL/E8ADYE1w+aiFQSr/gAvGZnJW2SmiH5nbA K+AQC0Ur5QFsGOs9tIRDk55lSTqQ9ZvfBrRowSTDBHJpWX7Ghmj9QEadw2hT830Wo3 xeq+jcmK7oxgTyaUZHtise9XV+t6vhdIDVAK7Sx0= Date: Thu, 16 Apr 2020 07:00:54 +0200 Message-ID: From: Gunnar Hellstrom To: AVT IETF , Jonathan Lennox MIME-Version: 1.0 In-Reply-To: <591BF32C-0FBD-4E24-BC99-77CB7AC6DE0F@8x8.com> References: <591BF32C-0FBD-4E24-BC99-77CB7AC6DE0F@8x8.com> Content-Type: multipart/alternative; boundary="--_com.sonymobile.email_667776728380150" Archived-At: Subject: Re: [AVTCORE] Call for adoption: RTP mixer formatting of multi-party real-time text X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 05:00:17 -0000 ----_com.sonymobile.email_667776728380150 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 WWVzLCBJIGFncmVlCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCkd1bm5hciBIZWxsc3Ryw7ZtCkd1bm5hci5IZWxsc3Ryb21AR0hBQ2Nl c3Muc2UKKzQ2IDcwOCAyMCA0MiA4OAoKLS0tLSBKb25hdGhhbiBMZW5ub3ggc2tyZXYgLS0tLQoK PkhpIGFsbCwKPgo+VGhlIHdvcmtpbmcgZ3JvdXAgY2hhaXJzIGFyZSBhc2tpbmcgZm9yIGFkb3B0 aW9uIG9mIGEgbmV3IG1pbGVzdG9uZSBmb3IgUlRQIG1peGVyIGZvcm1hdHRpbmcgb2YgbXVsdGkt cGFydHkgcmVhbC10aW1lIHRleHQsIHdpdGggZHJhZnQtaGVsbHN0cm9tLWF2dGNvcmUtbXVsdGkt cGFydHktcnR0LXNvdXJjZS0wMyBhcyB0aGUgYmFzaXMgZm9yIHRoZSBpbml0aWFsIFdHIGRvY3Vt ZW50Lgo+Cj5QbGVhc2UgcmVzcG9uZCBieSBXZWRuZXNkYXksIEFwcmlsIDI5dGggd2l0aCB3aGV0 aGVyIHlvdSBhZ3JlZSB3aXRoIHRoaXMgYWRvcHRpb24uCj4KPlRlY2huaWNhbCBjb21tZW50cyBj b21tZW50cyBvbiBkb2N1bWVudCBpdHNlbGYgYXJlIGFsc28gYWx3YXlzIHdlbGNvbWUsIG9mIGNv dXJzZSEKPgo+VGhhbmtzLAo+Cj5Kb25hdGhhbiBMZW5ub3gKPkFWVGNvcmUgY28tY2hhaXIKPgo+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPkF1ZGlvL1Zp ZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlCj5hdnRAaWV0Zi5vcmcKPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0Cg== ----_com.sonymobile.email_667776728380150 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 WWVzLCBJIGFncmVlPGJyPjxicj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPkd1bm5hciBIZWxsc3Ryw7ZtPGJyPjxhIGhyZWY9Im1h aWx0bzpHdW5uYXIuSGVsbHN0cm9tQEdIQUNjZXNzLnNlIj5HdW5uYXIuSGVsbHN0cm9tQEdIQUNj ZXNzLnNlPC9hPjxicj48YSBocmVmPSJ0ZWw6KzQ2IDcwOCAyMCA0MiA4OCI+KzQ2IDcwOCAyMCA0 MiA4ODwvYT48YnI+PGJyPi0tLS0gSm9uYXRoYW4gTGVubm94IHNrcmV2IC0tLS08YnI+PGJyPkhp IGFsbCw8YnI+PGJyPlRoZSB3b3JraW5nIGdyb3VwIGNoYWlycyBhcmUgYXNraW5nIGZvciBhZG9w dGlvbiBvZiBhIG5ldyBtaWxlc3RvbmUgZm9yIFJUUCBtaXhlciBmb3JtYXR0aW5nIG9mIG11bHRp LXBhcnR5IHJlYWwtdGltZSB0ZXh0LCB3aXRoIGRyYWZ0LWhlbGxzdHJvbS1hdnRjb3JlLW11bHRp LXBhcnR5LXJ0dC1zb3VyY2UtMDMgYXMgdGhlIGJhc2lzIGZvciB0aGUgaW5pdGlhbCBXRyBkb2N1 bWVudC48YnI+PGJyPlBsZWFzZSByZXNwb25kIGJ5IFdlZG5lc2RheSwgQXByaWwgMjl0aCB3aXRo IHdoZXRoZXIgeW91IGFncmVlIHdpdGggdGhpcyBhZG9wdGlvbi48YnI+PGJyPlRlY2huaWNhbCBj b21tZW50cyBjb21tZW50cyBvbiBkb2N1bWVudCBpdHNlbGYgYXJlIGFsc28gYWx3YXlzIHdlbGNv bWUsIG9mIGNvdXJzZSE8YnI+PGJyPlRoYW5rcyw8YnI+PGJyPkpvbmF0aGFuIExlbm5veDxicj5B VlRjb3JlIGNvLWNoYWlyPGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj5BdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZTxi cj48YSBocmVmPSJtYWlsdG86YXZ0QGlldGYub3JnIj5hdnRAaWV0Zi5vcmc8L2E+PGJyPjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0Ij5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dDwvYT48YnI+ ----_com.sonymobile.email_667776728380150-- From nobody Thu Apr 16 04:06:10 2020 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F783A147A for ; Thu, 16 Apr 2020 04:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=ericsson.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 MfuOTJBRCeMS for ; Thu, 16 Apr 2020 04:06:05 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2040.outbound.protection.outlook.com [40.107.20.40]) (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 9A6883A1475 for ; Thu, 16 Apr 2020 04:06:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OUMcFufRPpgm/L/4TGjCf4mPAGFdGTm2qMAzGiTieVwu53/EN5HXvxaIH5ZL4me5aZBfeyRoZQyMJ9SiV66dI3N3YcvqLUmm+PwoMDEXYkQv/9hM6TfpP1hBR/5Ha7A6/mVRLDTl7jK12WQ/hLt3Ao/pWZ6fa2DeJQBz7CNQ6Dk8LFl7lNFg7AdsHNdPwPv6tuwy9F9aSWSjLlrlrJEfxGbf3jfCJlbK0wu1dZ2vqrUXlnwK1usHow5o5t82y9pdGD24TdpVCQsFoSDvxcLLKbb4O2itffQ1XDyO3v5nHuHQjIIDwf3NdRoA5kibWTFfuVQ4a6pYeDrqTZpKkBKc9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cczBgvrJjZrDOqv4H+I9DKW39AwFKStw97m6ekGd8Tg=; b=G5XO1INEUPKRgiOfQJ7RI84uiO7wT/QpVtFLRgmbfenOfmeD3wSy8IbXcDhnTLTmwEyFehQgGkcThcqFaiLN1vAqa0XxtenYr4NEXN83SsuHbNrXrYjm8G6nn6QN7pmdVizVXQ129lyXWV00KuFIea5aY92O2zwAnBY053suX/eZ7iIsLFB6kRap6LHvFLJIs8alNYs5Wa91DwpGTLSZ3gOcwglAqrCnF0lg+44Ehzx2A/WQzM9C+xhhKWnWFCSadCOix8QpeXiDclG9ZR3p1ZAAWSAvsXZ9JVVGrkZihrx7yN0/TBxHmJC+vI8JjXTKNhtD7nrdP2dzaOKd6dfrzw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cczBgvrJjZrDOqv4H+I9DKW39AwFKStw97m6ekGd8Tg=; b=fFuMd7Q1Wb1mql3gABZicFydLM0vE5bv2VSaDtsWrviNL6EydbzHTjFz0Py/b+OlSR4YfltPEvSXExfM/dDHxdntp0GB80w+9u690ANPx588VMUBfihSId1MOlmwxK+ZDAWkUDjjVDTetmy/w6kDtqNHOEPWVBufpFE8nJKg2f4= Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (2603:10a6:208:46::31) by AM0PR07MB6065.eurprd07.prod.outlook.com (2603:10a6:208:113::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.14; Thu, 16 Apr 2020 11:06:03 +0000 Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc%7]) with mapi id 15.20.2937.000; Thu, 16 Apr 2020 11:06:03 +0000 From: Christer Holmberg To: Jonathan Lennox , "avt@ietf.org" Thread-Topic: [AVTCORE] Call for adoption: RTP mixer formatting of multi-party real-time text Thread-Index: AQHWE1QYIWtXVP+oRkWqnsaKPZVZWqh7yaoA Date: Thu, 16 Apr 2020 11:06:03 +0000 Message-ID: References: <591BF32C-0FBD-4E24-BC99-77CB7AC6DE0F@8x8.com> In-Reply-To: <591BF32C-0FBD-4E24-BC99-77CB7AC6DE0F@8x8.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a3e206d0-f27a-4b83-b52a-08d7e1f6274c x-ms-traffictypediagnostic: AM0PR07MB6065: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0375972289 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3987.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(396003)(39860400002)(136003)(376002)(366004)(76116006)(66476007)(64756008)(66946007)(91956017)(33656002)(6486002)(2616005)(66446008)(66556008)(86362001)(2906002)(110136005)(966005)(5660300002)(478600001)(316002)(6506007)(44832011)(8936002)(6512007)(186003)(36756003)(71200400001)(4744005)(26005)(8676002)(81156014); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VfaiHgSrAo7rlvbpXFfZNSTXmoR34VwEo77UmFrAYXGCwGQb9nV/wJEB27JagapMVaKzCy+mV0Jmr2BP/aNLlD7TZMVfF+66Ccd8GjAs7Fr4drp7UM9QyAqsr/5TZmKCOQ9jw7S3Hrd3xgX1zukqifdsP9wcFYJYDVWuV5kfUtxXIDfkIXHosSpvla7Be0JRfIivucMfPmhxu2t0G5Wqg/wmQAqHOx74+pc48oEr2G4Id7ieyITxA6bezpBMPSnYve3wPkQVnVP4i/LPG8UUtqjZ+/wUb1WpBNYfEb83Q1Mc6KgGxloiTkgnTMxI9oEPAAVLRA6MJIB30K/5SLNbr910SstGEslzVibyF9aoBIFwr9KhUe73OpWG5vybyi/QrnUXqgES34uBgV40GcG8cvspjXibwi+NeooM2yom8HtkWHzp86b+N+lE0iivFXyqyXNb/DGpwp5vai6VjdZPR0kel9G2G1W7IkOaDoe8xGIXO7l3+zOEZadOLfWb/+o8d2HiqcQ2cIdguMNotle7VQ== x-ms-exchange-antispam-messagedata: 9OjgsKDMwlF0IIxOpK6PCxRDl5ycsriEs8owuTDchICvnebKtM0ysklyswUJiTrRwR/UrNpxfzOIAokiTD+2dfEDJB2E9kRhPMNVNOROtOQvcDLi10FgbRO+jLIDAooIRZ3unkw9FqzYU/GkeK97FA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <0BAC2B96E61D074A9580EC00CFA1BA3B@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: a3e206d0-f27a-4b83-b52a-08d7e1f6274c X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2020 11:06:03.2838 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /LfYW1GXIaxRKHdHo/kRAAfSzwRYCPejLPl5RPfMblb2wl4See8GAKwXnF9FNji22C7xAVsIJ85PfX+fEip7HD6ubutzXDutMTd8uBBao2g= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6065 Archived-At: Subject: Re: [AVTCORE] Call for adoption: RTP mixer formatting of multi-party real-time text X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 11:06:08 -0000 SGksDQoNCkkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhlIG5ldyBtaWxlc3RvbmUsIHVzaW5n IHRoZSBkcmFmdCBtZW50aW9uZWQgYmVsb3cgYXMgYmFzZSBmb3IgdGhlIHdvcmssIGFuZCBJIHdp bGwgZm9sbG93IGFuZCByZXZpZXcgdGhlIHdvcmsuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN Cg0K77u/T24gMTUvMDQvMjAyMCwgMjEuMzEsICJhdnQgb24gYmVoYWxmIG9mIEpvbmF0aGFuIExl bm5veCIgPGF2dC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqb25hdGhhbi5sZW5ub3hA OHg4LmNvbT4gd3JvdGU6DQoNCiAgICBIaSBhbGwsDQogICAgDQogICAgVGhlIHdvcmtpbmcgZ3Jv dXAgY2hhaXJzIGFyZSBhc2tpbmcgZm9yIGFkb3B0aW9uIG9mIGEgbmV3IG1pbGVzdG9uZSBmb3Ig UlRQIG1peGVyIGZvcm1hdHRpbmcgb2YgbXVsdGktcGFydHkgcmVhbC10aW1lIHRleHQsIHdpdGgg ZHJhZnQtaGVsbHN0cm9tLWF2dGNvcmUtbXVsdGktcGFydHktcnR0LXNvdXJjZS0wMyBhcyB0aGUg YmFzaXMgZm9yIHRoZSBpbml0aWFsIFdHIGRvY3VtZW50Lg0KICAgIA0KICAgIFBsZWFzZSByZXNw b25kIGJ5IFdlZG5lc2RheSwgQXByaWwgMjl0aCB3aXRoIHdoZXRoZXIgeW91IGFncmVlIHdpdGgg dGhpcyBhZG9wdGlvbi4NCiAgICANCiAgICBUZWNobmljYWwgY29tbWVudHMgY29tbWVudHMgb24g ZG9jdW1lbnQgaXRzZWxmIGFyZSBhbHNvIGFsd2F5cyB3ZWxjb21lLCBvZiBjb3Vyc2UhDQogICAg DQogICAgVGhhbmtzLA0KICAgIA0KICAgIEpvbmF0aGFuIExlbm5veA0KICAgIEFWVGNvcmUgY28t Y2hhaXINCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KICAgIEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQogICAg YXZ0QGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9h dnQNCiAgICANCg0K From nobody Thu Apr 16 22:29:48 2020 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25FED3A0BAC; Wed, 8 Apr 2020 08:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.102 X-Spam-Level: *** X-Spam-Status: No, score=3.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 qDOUk5e6Hg6u; Wed, 8 Apr 2020 08:48:32 -0700 (PDT) Received: from host105.olm1.com (host105.olm1.com [72.236.255.15]) (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 3D2263A0BA1; Wed, 8 Apr 2020 08:48:29 -0700 (PDT) Received: from HERTELLT (cpe-98-5-223-142.buffalo.res.rr.com [98.5.223.142]) by host105.olm1.com (Postfix) with ESMTPSA id 9DB22B93C3E; Wed, 8 Apr 2020 11:48:27 -0400 (EDT) From: To: "'Benjamin Kaduk'" , "'Barry Leiba'" Cc: "'Roni Even \(A\)'" , "'The IESG'" , "'Catherine Meadows'" , "'IETF SecDir'" , , "'Ali Begen'" , , , "'Dave Satterlee \(Vocal\)'" , "'IETF discussion list'" , , References: <001601d57af9$405efcf0$c11cf6d0$@vocal.com> <6E58094ECC8D8344914996DAD28F1CCD23D79BC0@DGGEMM506-MBX.china.huawei.com> <034a01d58a73$f4d3a1c0$de7ae540$@vocal.com> <037e01d58a92$72287510$56795f30$@vocal.com> <20191101001153.GQ88302@kduck.mit.edu> <06e101d59f15$ee937b30$cbba7190$@vocal.com> <20191125064606.GL32847@mit.edu> <00c601d5e339$965ebd90$c31c38b0$@vocal.com> <20200214194321.GF43385@kduck.mit.edu> In-Reply-To: <20200214194321.GF43385@kduck.mit.edu> Date: Wed, 8 Apr 2020 11:48:26 -0400 Message-ID: <002b01d60dbd$25675f80$70361e80$@vocal.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_002C_01D60D9B.9E56D0F0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLglFUw/9Hrg4xFnJGl+gKOw+IttgKP/a5DAUK4sQ4C/qBe9QJw6xekAqUwBBcB6AFNSwEOtkf1AdJM/WIBsvGQ0QGhq9LkpYGDUMA= Content-Language: en-us Archived-At: X-Mailman-Approved-At: Thu, 16 Apr 2020 22:29:36 -0700 Subject: Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 15:48:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002C_01D60D9B.9E56D0F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_002D_01D60D9B.9E56D0F0" ------=_NextPart_001_002D_01D60D9B.9E56D0F0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ben, With this social distancing situation, I'm finally catching up on open = items myself. I have made the changes as we have discussed and = incorporated your suggestions. I believe the changes are fully = contained in the two paragraphs below: Section 2 (last paragraph) - Clarification for octet count (was) In order to accommodate a varying amount of TSVCIS augmented speech data, it is only necessary to specify the number of octets containing the packed TSVCIS parameters. The encoding to do so is presented in Section 3.2. TSVCIS specifically uses the NRL VDR in two configurations using 15 and 35 packed octet parameters [TSVCIS]. =20 (now) In order to accommodate a varying amount of TSVCIS augmented speech data, an octet count specifies the number of octets representing the packed TSVCIS parameters. The encoding to do so is presented in Section 3.2. TSVCIS specifically uses the NRL VDR in two configurations using a fixed set of 15 and 35 packed octet parameters in a standardized order [TSVCIS]. =20 Section 3.1 (first sentence in last paragraph) - Clarification for CODA, = CODB (was) It should be noted that CODB for MELPe 600 bps mode MAY deviate from the value in Table 1 when bit 55 is used as an end-to-end framing bit. (now) It should be noted that CODB for MELPe 600 bps mode MAY deviate from the value in Table 1 when bit 55 is used as an alternating 1/0 end-to-end framing bit. =20 Ben, I believe this addresses your comments and requests for = clarifications as per our email discussion chain below. Thanks for you comments and with your concurrence (and my home = computer's cooperation), I will post a new draft hopefully acceptable = for final approval. Regards to all and stay on the good side of Darwin. Victor -----Original Message----- From: Benjamin Kaduk =20 Sent: Friday, February 14, 2020 2:43 PM To: victor.demjanenko@vocal.com; 'Barry Leiba' Cc: 'Roni Even (A)' ; 'The IESG' ; = 'Catherine Meadows' ; 'IETF SecDir' = ; draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' = ; avtcore-chairs@ietf.org; avt@ietf.org; = 'Dave Satterlee (Vocal)' ; 'IETF discussion = list' ; draft-ietf-payload-tsvcis.all@ietf.org Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: = (with DISCUSS and COMMENT) Hi Barry, As Victor notes, this one was/is waiting on me; he did reply (offlist) = on 15 January but I seem to have missed it amid a deluge of other mail that = arrived at that time. Thanks for the reminder, and thanks Victor for = re-sending the comments. (inline) On Fri, Feb 14, 2020 at 08:20:54AM -0500, victor.demjanenko@vocal.com = wrote: > HI Barry, >=20 > Thanks for recalling this was still outstanding. I had emailed Ben = just after the holidays and did not realize we had no response. The = below is what we suggested to Ben to address concerns he raised. >=20 > -------------------- > Hi Ben, >=20 > Hope your holidays were good. Our were both good and busy. = Deliveries for two NASA projects and the holidays kept us from = responding sooner. But we do want to get this draft completed. >=20 > With your permission, I=E2=80=99d like to address your comments = directly, resolve what changes we should make and then publish a new = version with a summary of our out-of-band discussions. We don=E2=80=99t = have a lot of experience with drafting such documents and would like to = know exactly what is needed to make this draft acceptable. >=20 > I believe there are two comments/issues to address: >=20 > 1) CODA, CODB >=20 > Your comment ends by stating: =E2=80=9C(Or, of course, the use of = CODB as an alternating 1/0 bit as the framing usage could be documented = instead.)=E2=80=9D We can do this as follows: >=20 > (original) > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > the value in Table 1 when bit 55 is used as an end-to-end framing > bit. Frame decoding would remain distinct as CODA being zero on its > own would indicate a 7-byte frame for either 2400 or 600 bps rate = and > the use of 600 bps speech coding could be deduced from the RTP > timestamp (and anticipated by the SDP negotiations). >=20 > (adding =E2=80=9Calternating 1/0=E2=80=9D) > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > the value in Table 1 when bit 55 is used as an alternating 1/0 = end-to-end framing > bit. Frame decoding would remain distinct as CODA being zero on its > own would indicate a 7-byte frame for either 2400 or 600 bps rate = and > the use of 600 bps speech coding could be deduced from the RTP > timestamp (and anticipated by the SDP negotiations). >=20 > I think this change would be sufficient to address your concern about = what to expect for CODB. This looks like the minimal sufficient change, yes. (I use "minimal" because I would say more if I was writing it, but I don't think I can = insist that you write it the way I would -- it's your document after = all!) > 2. Packing and unpacking >=20 > You are correct that I am trying to vaguely describe a middle layer = shim that is neither RTP nor speech coder. So it definitely does need = to be clear. The vagueness comes from the speech coder description = being a FOUO document. Its now unclassified so I can potentially say = more (and I did make some enhancements of the parameter description = already). =20 >=20 > So I am trying to understand exactly what you think is vague in our = current description: >=20 > TSVCIS augmented speech data is derived from the signal processing > and data already performed by the MELPe speech coder. For the > purposes of this specification, only the general parameter nature = of > TSVCIS will be characterized. Depending on the bandwidth available > (and FEC requirements), a varying number of TSVCIS-specific speech > coder parameters need to be transported. These are first = byte-packed > and then conveyed from encoder to decoder. >=20 > Byte packing of TSVCIS speech data into packed parameters is > processed as per the following example: >=20 > Three-bit field: bits A, B, and C (A is MSB, C is LSB) > Five-bit field: bits D, E, F, G, and H (D is MSB, H is LSB) >=20 > MSB LSB > 0 1 2 3 4 5 6 7 > +------+------+------+------+------+------+------+------+ > | H | G | F | E | D | C | B | A |=20 > +------+------+------+------+------+------+------+------+ >=20 > This packing method places the three-bit field "first" in the = lowest > bits followed by the next five-bit field. Parameters may be split > between octets with the most significant bits in the earlier octet. > Any unfilled bits in the last octet MUST be filled with zero. [not actually relevant to the Discuss part, but if there is always = exactly one 3-bit parameter and one 5-bit parameter, then this text = allowing splitting across octets will never be used and is potentially = confusing to mention.] > In order to accommodate a varying amount of TSVCIS augmented speech > data, it is only necessary to specify the number of octets = containing > the packed TSVCIS parameters. The encoding to do so is presented=20 > in I think the "only necessary to specify the number of octets" is the key = stumbling point, for me -- I need to know the number of octets as well = as the order of the parameters within the list, which is more = information than just the number of octets. > Section 3.2. TSVCIS specifically uses the NRL VDR in two > configurations using 15 and 35 packed octet parameters [TSVCIS]. =20 I think I failed to internalize the "two configurations using 15 and 35 = packed octet parameters" the first time I read the document, as this = does help give the reader a clue that [TSVCIS] gives a good picture of = what parameters go where. So it seems like we could easily append to = that, for "using a fixed set of 15 and 35 packed octet parameters in a = fixed order [TSVCIS]" and that would resolve my concerns. > The speech coder description of the parameters is the following: >=20 > =20 >=20 > So the three bit pitch is first (bits 56 to 58), followed by a five = bit amplitude (bits 59 to 63) and then an array of spectral components, = each 8-bit wide (starting at bit 64). [And maybe TSVCIS specifes that the spectral components are derived from = some fundamental harmonic decomposition that naturally quantizes to a = number-of-parameters/accuracy tradeoff with a natural order. If so, we = could also rely on that instead of my proposed change above; let me know = if you want to explore that path further.] > Based on this information, I=E2=80=99m not sure what we should add to = our=20 > draft to make the description of packing/unpacking clearer. Can you=20 > make any suggestions or does this table help you with what you did not = > know? (I don=E2=80=99t think I should put this table into the draft = RFC=20 > however.) Hopefully the above helps to clarify. Thanks, and sorry for the delay. -Ben > Thanks for your attention and comments. >=20 > Victor & Dave >=20 >=20 >=20 > -----Original Message----- > From: Barry Leiba > Sent: Friday, February 14, 2020 7:38 AM > To: Benjamin Kaduk > Cc: victor.demjanenko@vocal.com; Roni Even (A) ; = > The IESG ; Catherine Meadows=20 > ; IETF SecDir ;=20 > draft-ietf-payload-tsvcis@ietf.org; Ali Begen=20 > ; avtcore-chairs@ietf.org; avt@ietf.org;=20 > Dave Satterlee (Vocal) ; IETF discussion=20 > list ; draft-ietf-payload-tsvcis.all@ietf.orgygv=20 > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: = > (with DISCUSS and COMMENT) >=20 > This is still outstanding, since November. Victor, where are we on = this one? >=20 > Barry >=20 > On Mon, Nov 25, 2019 at 1:46 AM Benjamin Kaduk wrote: > > > > Hi Victor, > > > > On Tue, Nov 19, 2019 at 03:14:21PM -0500, = victor.demjanenko@vocal.com wrote: > > > Hi Ben, > > > > > > Sorry I overlooked sending you a response. I would like to=20 > > > address the two concerns you have by explaining what the speech = coders are doing. > > > > Thanks for the extra clarifications. To supply one of my own: I'm=20 > > not concerned that the protocol doesn't work as implemented, but=20 > > just want to make sure that the document includes enough information = > > to admit new implementations without guesswork. That is to say,=20 > > "either tell me how to do it or tell me where to look that tells me = how to do it". > > > > > WRT to 600 bps MELP, there is one TSVCIS mode that uses one bit=20 > > > beyond the 54-bit frame for MELP 600 as a frame sync which = alternates between frames. > > > With two or more MELP 600bps frames in one RTP packet, if any=20 > > > frame indicates 600 bps by CODA being 0 and CODB being 1, then we=20 > > > know the stream is 600bps. If there is a single frame in an RTP=20 > > > packet, you can still deduce this by looking at every other RTP=20 > > > packet (every other MELP 600bps > > > frame) and by the timestamp advance. Most likely the two ends=20 > > > would negotiate 600 bps in SDP anyways so there really should not=20 > > > be a problem. I know it's not pretty but its workable. I hope=20 > > > this explanation helps you with the concerns for this issue. > > > > In this case, the use as an "end-to-end framing bit" (i.e., the=20 > > alternating behavior you describe above) is not explicitly stated;=20 > > one might imagine a scheme where the framing usage is to have the=20 > > bit cycle through 1, 1, 0, and 0, or some other scheme. I'd suggest = > > to note in the document that if any instance of (CODA, CODB) =3D=3D = (0,=20 > > 1) is observed, then the 600bps mode is in use. It might also be=20 > > helpful to include the observation that two successive MELPe=20 > > payloads with CODA =3D=3D CODB =3D=3D 0 indicates the 2400bps mode = (and that=20 > > seeing them in a single RTP packet is decisive, whereas additional=20 > > information about packet non-loss would be needed in the=20 > > one-MELPe-frame-per-RTP-packet case), but that would be a fair bit=20 > > of additional text and might be diminishing returns. (Or, of=20 > > course, the use of CODB as an alternating 1/0 bit as the framing=20 > > usage could be documented > > instead.) > > > > > As for the TSVCIS parameter packing/unpacking, this is really=20 > > > simple. There is exactly on three bit parameter, exactly one five = > > > bit parameter and a variable number of eight bit parameters. In=20 > > > our view, the speech coder itself (or a wrapper for it) is=20 > > > responsible for preparing the block of octets. RTP then just=20 > > > transports it. On receive, the complementary wrapper reverses the = packing operation. > > > I hope this clarifies and explains the simplicity. > > > > That's exactly what I expected to happen; however, it's not what I=20 > > believe the current text of the document is describing. =20 > > Specifically, I think that the current text implies that the=20 > > "preparing the block of octets" and "complementary wrapper reverses=20 > > the packing operation" are supposed to be part of the RTP payload=20 > > format that this document describes, but this document does not have = > > enough information to actually perform those operations reversibly. = > > If the packing is to be done in the speech coder, then this document = > > doesn't need to talk about the packing at all (e.g., at the end of=20 > > Section 2); if we need to keep the packing/wrapper in this document=20 > > then we need to indicate that there's a defined priority order for=20 > > the (8-octet) TSVCIS parameters in the TSVCIS references, to allow = the packing/unpacking to be deterministic. > > > > Thanks, > > > > Ben > > > > > > > > -----Original Message----- > > > From: Benjamin Kaduk > > > Sent: Thursday, October 31, 2019 8:12 PM > > > To: Barry Leiba > > > Cc: victor.demjanenko@vocal.com; Roni Even (A)=20 > > > ; The IESG ; Catherine=20 > > > Meadows ; IETF SecDir=20 > > > ; draft-ietf-payload-tsvcis@ietf.org; Ali Begen=20 > > > ; avtcore-chairs@ietf.org;=20 > > > avt@ietf.org; Dave Satterlee (Vocal) ;=20 > > > IETF discussion list ;=20 > > > draft-ietf-payload-tsvcis.all@ietf.org > > > Subject: Re: Benjamin Kaduk's Discuss on > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > I don't think so, unfortunately. > > > > > > I do see the clarification about CODB's potential for deviation=20 > > > from Table 1, that only the 600 bps MELPe is allowed to deviate,=20 > > > and that CODA gets us to "it's one of 2400 or 600 bps" and the RTP = > > > timestamp disambiguates that > > > 600 bps is in use. But, it seems that this means that the=20 > > > recipient in general should not rely on CODB to differentiate 600=20 > > > from 2400 bps, and instead is more robustly implemented by=20 > > > *always* using the RTP timestamp to detect 600 bps, since that=20 > > > will always work and CODB will sometimes not work under conditions = > > > not fully specified here. So, if we are unwilling or unable to=20 > > > clarify what those conditions are (e.g., whether at a minimum=20 > > > mutual agreement is required), then I think we need to describe=20 > > > this procedure of consulting the RTP timestamp as the default = behavior and avoid giving the impression that CODB should be used to do = so. > > > > > > Additionally, I don't see anything to address my concern about=20 > > > TSVCIS parameter decoding. To be clear, the procedure I see this=20 > > > document describing is that: > > > - TSVCIS gives parameters (and their lengths in bits) to the codec > > > described in this document > > > - this document specifies how to densely encode those parameters = into a > > > byetstream > > > - RTP transmits that encoded bytestream to the peer > > > - the codec specified by this is responsible for turning that = encoded > > > bystream back into a list of TSVCIS parameters (and their length = > > > in bits) > > > > > > I don't see how that last step is attainable with only the=20 > > > information provided by this document. I *assume* that one of the = > > > TSVCIS specifications has a canonical (ordered) listing of=20 > > > parameters, and that the list of parmeters given to this codec in=20 > > > the first step will always be an initial prefix of that list, but=20 > > > that's just me guessing at how to make sense of the stated=20 > > > procedure given insufficient information. I don't think it's=20 > > > appropriate to make the reader of an RFC guess at what to do; we=20 > > > need to either say how to do it or give a pointer to an external = reference that does. > > > > > > -Ben > > > > > > On Tue, Oct 29, 2019 at 02:26:09PM -0400, Barry Leiba wrote: > > > > Ben, does the -04 version address everything? > > > > > > > > Barry > > > > > > > > On Thu, Oct 24, 2019 at 1:42 PM = wrote: > > > > > > > > > > I forgot to address security comments in one email. The = changes are: > > > > > > > > > > Section 8, second paragraph - Suggested edit by reviewer > > > > > > > > > > (was) > > > > > This RTP payload format and the TSVCIS decoder do not = exhibit any > > > > > significant non-uniformity in the receiver-side = computational > > > > > complexity for packet processing and thus are unlikely to = pose a > > > > > denial-of-service threat due to the receipt of pathological = data. > > > > > Additionally, the RTP payload format does not contain any = active > > > > > content. > > > > > > > > > > (now) > > > > > This RTP payload format and the TSVCIS decoder, to the best = of our > > > > > knowledge, do not exhibit any significant non-uniformity in = the > > > > > receiver-side computational complexity for packet = processing and thus > > > > > are unlikely to pose a denial-of-service threat due to the = receipt of > > > > > pathological data. Additionally, the RTP payload format = does not > > > > > contain any active content. > > > > > > > > > > > > > > > Section 8, third paragraph - Suggested edit by reviewer > > > > > > > > > > (was) > > > > > Please see the security considerations discussed in = [RFC6562] > > > > > regarding VAD and its effect on bitrates. > > > > > > > > > > (now) > > > > > Please see the security considerations discussed in = [RFC6562] > > > > > regarding Voice Activity Detect (VAD) and its effect on = bitrates. > > > > > > > > > > Victor > > > > > > > > > > -----Original Message----- > > > > > From: victor.demjanenko@vocal.com=20 > > > > > > > > > > Sent: Thursday, October 24, 2019 10:05 AM > > > > > To: 'Roni Even (A)' ; 'Benjamin Kaduk' > > > > > ; 'The IESG' > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' > > > > > ; avtcore-chairs@ietf.org;=20 > > > > > avt@ietf.org; 'Dave Satterlee (Vocal)' > > > > > > > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > > > Hi Everyone, > > > > > > > > > > First we want to thank everyone for their review and comments=20 > > > > > for this > > > draft RFC. We believe we reviewed all the comments and=20 > > > suggestions and incorporated them adequately in the next draft=20 > > > (04). We'd like to send out this list of exact changes in case=20 > > > anyone has additional comments or thinks the clarifications are=20 > > > inadequate. We would be most happy to address concerns before = publishing draft 04 tomorrow. > > > > > > > > > > With so many emails from a half dozen or more reviewers, we=20 > > > > > apologize > > > that we cannot address each sender individually. We hope this=20 > > > detail is sufficient for everyone. > > > > > > > > > > Again, many thanks to all. > > > > > > > > > > Victor & Dave > > > > > > > > > > -------------------------------------------------------------- > > > > > -- > > > > > ---- > > > > > -------------------------- > > > > > > > > > > Section 1.1 - Suggested reference to RFC 8088 added. > > > > > > > > > > (was) > > > > > Best current practices for writing an RTP payload format > > > > > specification were followed [RFC2736]. > > > > > > > > > > (now) > > > > > Best current practices for writing an RTP payload format > > > > > specification were followed [RFC2736] [RFC8088]. > > > > > > > > > > > > > > > Section 2, paragraphs 3 and 4 - Suggested edits by reviewers > > > > > > > > > > (was) > > > > > In addition to the augmented speech data, the TSVCIS = specification > > > > > identifies which speech coder and framing bits are to be = encrypted, > > > > > and how they are protected by forward error correction = (FEC) > > > > > techniques (using block codes). At the RTP transport = layer, only the > > > > > speech coder related bits need to be considered and are = conveyed in > > > > > unencrypted form. In most IP-based network deployments, = standard > > > > > link encryption methods (SRTP, VPNs, FIPS 140 link = encryptors or Type > > > > > 1 Ethernet encryptors) would be used to secure the RTP = speech > > > > > contents. Further, it is desirable to support the highest = voice > > > > > quality between endpoints which is only possible without = the overhead > > > > > of FEC. > > > > > > > > > > TSVCIS augmented speech data is derived from the signal = processing > > > > > and data already performed by the MELPe speech coder. For = the > > > > > purposes of this specification, only the general parameter = nature of > > > > > TSVCIS will be characterized. Depending on the bandwidth = available > > > > > (and FEC requirements), a varying number of TSVCIS specific = speech > > > > > coder parameters need to be transported. These are first = byte-packed > > > > > and then conveyed from encoder to decoder. > > > > > > > > > > (now) > > > > > In addition to the augmented speech data, the TSVCIS = specification > > > > > identifies which speech coder and framing bits are to be = encrypted, > > > > > and how they are protected by forward error correction = (FEC) > > > > > techniques (using block codes). At the RTP transport = layer, only the > > > > > speech-coder-related bits need to be considered and are = conveyed in > > > > > unencrypted form. In most IP-based network deployments, = standard > > > > > link encryption methods (SRTP, VPNs, FIPS 140 link = encryptors or Type > > > > > 1 Ethernet encryptors) would be used to secure the RTP = speech > > > > > contents. > > > > > > > > > > TSVCIS augmented speech data is derived from the signal = processing > > > > > and data already performed by the MELPe speech coder. For = the > > > > > purposes of this specification, only the general parameter = nature of > > > > > TSVCIS will be characterized. Depending on the bandwidth = available > > > > > (and FEC requirements), a varying number of TSVCIS-specific = speech > > > > > coder parameters need to be transported. These are first = byte-packed > > > > > and then conveyed from encoder to decoder. > > > > > > > > > > > > > > > Section 3, last sentence paragraph 3 - Suggested edit by=20 > > > > > reviewer > > > > > > > > > > (was) > > > > > When more than one codec data frame is > > > > > present in a single RTP packet, the timestamp is, as = always, that of > > > > > the oldest data frame represented in the RTP packet. > > > > > > > > > > (now) > > > > > When more than one codec data frame is > > > > > present in a single RTP packet, the timestamp specified is = that of > > > > > the oldest data frame represented in the RTP packet. > > > > > > > > > > > > > > > Section 3.1, last paragraph - Clarified permission for MELP=20 > > > > > 600 end-to-end framing bit > > > > > > > > > > (was) > > > > > It should be noted that CODB for both the 2400 and 600 bps = modes MAY > > > > > deviate from the values in Table 1 when bit 55 is used as = an end-to- > > > > > end framing bit. Frame decoding would remain distinct as = CODA being > > > > > zero on its own would indicate a 7-byte frame for either = rate and the > > > > > use of 600 bps speech coding could be deduced from the RTP = timestamp > > > > > (and anticipated by the SDP negotiations). > > > > > > > > > > (now) > > > > > It should be noted that CODB for MELPe 600 bps mode MAY = deviate from > > > > > the value in Table 1 when bit 55 is used as an end-to-end = framing > > > > > bit. Frame decoding would remain distinct as CODA being = zero on its > > > > > own would indicate a 7-byte frame for either 2400 or 600 = bps rate and > > > > > the use of 600 bps speech coding could be deduced from the = RTP > > > > > timestamp (and anticipated by the SDP negotiations). > > > > > > > > > > > > > > > Section 3.2, first paragraph - Clarifications requested by=20 > > > > > reviewers > > > > > > > > > > (was) > > > > > The TSVCIS augmented speech data as packed parameters MUST = be placed > > > > > immediately after a corresponding MELPe 2400 bps payload in = the same > > > > > RTP packet. The packed parameters are counted in octets = (TC). In > > > > > the preferred placement, shown in Figure 6, a single = trailing octet > > > > > SHALL be appended to include a two-bit rate code, CODA and = CODB, > > > > > (both bits set to one) and a six-bit modified count (MTC). = The > > > > > special modified count value of all ones (representing a = MTC value of > > > > > 63) SHALL NOT be used for this format as it is used as the = indicator > > > > > for the alternate packing format shown next. In a standard > > > > > implementation, the TSVCIS speech coder uses a minimum of = 15 octets > > > > > for parameters in octet packed form. The modified count = (MTC) MUST > > > > > be reduced by 15 from the full octet count (TC). Computed = MTC =3D TC- > > > > > 15. This accommodates a maximum of 77 parameter octets = (maximum > > > > > value of MTC is 62, 77 is the sum of 62+15). > > > > > > > > > > (now) > > > > > The TSVCIS augmented speech data as packed parameters MUST = be placed > > > > > immediately after a corresponding MELPe 2400 bps payload in = the same > > > > > RTP packet. The packed parameters are counted in octets = (TC). The > > > > > preferred placement SHOULD be used for TSVCIS payloads with = TC less > > > > > than or equal to 77 octets, is shown in Figure 6. In the = preferred > > > > > placement, a single trailing octet SHALL be appended to = include a > > > > > two-bit rate code, CODA and CODB, (both bits set to one) = and a six- > > > > > bit modified count (MTC). The special modified count value = of all > > > > > ones (representing a MTC value of 63) SHALL NOT be used for = this > > > > > format as it is used as the indicator for the alternate = packing > > > > > format shown next. In a standard implementation, the = TSVCIS speech > > > > > coder uses a minimum of 15 octets for parameters in octet = packed > > > > > form. The modified count (MTC) MUST be reduced by 15 from = the full > > > > > octet count (TC). Computed MTC =3D TC-15. This = accommodates a maximum > > > > > of 77 parameter octets (maximum value of MTC is 62, 77 is = the sum of > > > > > 62+15). > > > > > > > > > > > > > > > Section 3.3, first paragraph - Suggested edit by reviewer > > > > > > > > > > (was) > > > > > A TSVCIS RTP packet consists of zero or more TSVCIS coder = frames > > > > > (each consisting of MELPe and TSVCIS coder data) followed = by zero or > > > > > one MELPe comfort noise frame. The presence of a comfort = noise frame > > > > > can be determined by its rate code bits in its last octet. > > > > > > > > > > (now) > > > > > A TSVCIS RTP packet payload consists of zero or more = consecutive > > > > > TSVCIS coder frames (each consisting of MELPe 2400 and = TSVCIS coder > > > > > data), with the oldest frame first, followed by zero or one = MELPe > > > > > comfort noise frame. The presence of a comfort noise frame = can be > > > > > determined by its rate code bits in its last octet. > > > > > > > > > > > > > > > Section 3.3, fourth paragraph - Clarification requested by=20 > > > > > reviewers > > > > > > > > > > (was) > > > > > TSVCIS coder frames in a single RTP packet MAY be of = different coder > > > > > bitrates. With the exception for the variable length = TSVCIS > > > > > parameter frames, the coder rate bits in the trailing byte = identify > > > > > the contents and length as per Table 1. > > > > > > > > > > (now) > > > > > TSVCIS coder frames in a single RTP packet MAY have varying = TSVCIS > > > > > parameter octet counts. Its packed parameter octet count = (length) is > > > > > indicated in the trailing byte(s). All MELPe frames in a = single RTP > > > > > packet MUST be of the same coder bitrate. For all MELPe = coder > > > > > frames, the coder rate bits in the trailing byte identify = the > > > > > contents and length as per Table 1. > > > > > > > > > > > > > > > Section 4.1 - Editor note removed > > > > > > > > > > > > > > > Section 4.1 - Change controller is now > > > > > > > > > > (now) > > > > > Change controller: IETF, contact > > > > > > > > > > > > > > > Section 5, first paragraph - Suggested edits by reviewers > > > > > > > > > > (was) > > > > > A primary application of TSVCIS is for radio communications = of voice > > > > > conversations, and discontinuous transmissions are normal. = When > > > > > TSVCIS is used in an IP network, TSVCIS RTP packet = transmissions may > > > > > cease and resume frequently. RTP synchronization source = (SSRC) > > > > > sequence number gaps indicate lost packets to be filled by = PLC, while > > > > > abrupt loss of RTP packets indicates intended discontinuous > > > > > transmissions. > > > > > > > > > > (now) > > > > > A primary application of TSVCIS is for radio communications = of voice > > > > > conversations, and discontinuous transmissions are normal. = When > > > > > TSVCIS is used in an IP network, TSVCIS RTP packet = transmissions may > > > > > cease and resume frequently. RTP synchronization source = (SSRC) > > > > > sequence number gaps indicate lost packets to be filled by = Packet > > > > > Loss Concealment (PLC), while abrupt loss of RTP packets = indicates > > > > > intended discontinuous transmissions. Resumption of voice > > > > > transmission SHOULD be indicated by the RTP marker bit (M) = set to 1. > > > > > > > > > > > > > > > Section 10 - Added reference > > > > > > > > > > (added) > > > > > [RFC8088] Westerlund, M., "How to Write an RTP Payload = Format", > > > > > RFC 8088, DOI 10.17487/RFC8088, May 2017, > > > > > . > > > > > > > > > > -------------------------------------------------------------- > > > > > -- > > > > > ---- > > > > > ----------------------------- > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Roni Even (A) > > > > > Sent: Sunday, October 6, 2019 2:09 AM > > > > > To: victor.demjanenko@vocal.com; 'Benjamin Kaduk'=20 > > > > > ; 'The IESG' > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' > > > > > ; avtcore-chairs@ietf.org;=20 > > > > > avt@ietf.org; 'Dave Satterlee (Vocal)' > > > > > > > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > > > Hi, > > > > > About the reference to TSVCIS. > > > > > The RTP payload is about how to encapsulate the payload in an=20 > > > > > RTP > > > packet. The objective is to define how an RTP stack can insert the = > > > tsvcis frames and extract the tsvcis frames from the RTP packet. > > > Typically it is not required to understand the payload structure=20 > > > in order to be able to perform the encapsulation. > > > > > This is why the reference to the payload is Informational and=20 > > > > > we did not require to have it publically available. If there=20 > > > > > is a need to understand the payload itself for the=20 > > > > > encapsulating than we need more information in the RTP payload = > > > > > specification and a publically available normative reference.=20 > > > > > I think this is not the case here > > > > > > > > > > Roni Even > > > > > > > > > > AVTCore co-chair (ex Payload) > > > > > > > > > > -----Original Message----- > > > > > From: victor.demjanenko@vocal.com=20 > > > > > [mailto:victor.demjanenko@vocal.com] > > > > > Sent: Saturday, October 05, 2019 12:18 AM > > > > > To: 'Benjamin Kaduk'; 'The IESG' > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen'; > > > avtcore-chairs@ietf.org; avt@ietf.org; 'Victor Demjanenko, Ph.D.'; = > > > 'Dave Satterlee (Vocal)' > > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > > > Everyone, > > > > > > > > > > Thanks for the comments. I think I mis-understood the=20 > > > > > ambiguity with > > > respect to to changing rates within a RTP packet. That was not=20 > > > plan. An RTP packet must have MELP speech frames of the same = rate. > > > What is possible is that the amount of augmented TSVCIS speech=20 > > > data may vary from one speech frame to the next. This allows for=20 > > > a dynamic VDR as suggested by the NRL paper. So an RTP packet may = > > > have varying TSVCIS data but must always have MELPe 2400 data. > > > > > > > > > > Again backwards parsing is necessary but the timestamp=20 > > > > > uniformly > > > increments 22.5msec per combined MELP/TSVCIS speech frame. > > > > > > > > > > The NRL is a good public reference on the VDR aspects. The=20 > > > > > actual > > > TSVCIS spec we had was FOUO so we could not replicate its detail. = > > > (I believe a later spec is public or at least partially public. I = > > > am trying to get this.) The opaque data is pretty obvious with = the TSVCIS spec in hand. > > > > > > > > > > We will address the issues/concerns raised next week. Other=20 > > > > > business > > > had priority. > > > > > > > > > > Thank you and enjoy the weekend. > > > > > > > > > > Regards, > > > > > > > > > > Victor & Dave > > > > > > > > > > -----Original Message----- > > > > > From: Benjamin Kaduk via Datatracker > > > > > Sent: Wednesday, October 2, 2019 10:40 PM > > > > > To: The IESG > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; Ali Begen=20 > > > > > ; avtcore-chairs@ietf.org;=20 > > > > > ali.begen@networked.media; avt@ietf.org > > > > > Subject: Benjamin Kaduk's Discuss on = draft-ietf-payload-tsvcis-03: > > > > > (with DISCUSS and COMMENT) > > > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > > draft-ietf-payload-tsvcis-03: Discuss > > > > > > > > > > When responding, please keep the subject line intact and reply = > > > > > to all email addresses included in the To and CC lines. (Feel=20 > > > > > free to cut this introductory paragraph, however.) > > > > > > > > > > > > > > > Please refer to > > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > > > > The document, along with other ballot positions, can be found = here: > > > > > https://datatracker.ietf.org/doc/draft-ietf-payload-tsvcis/ > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > -- > > > > > ---- > > > > > -- > > > > > DISCUSS: > > > > > -------------------------------------------------------------- > > > > > -- > > > > > ---- > > > > > -- > > > > > > > > > > I support Magnus' point about the time-ordering of adjacent=20 > > > > > frames in a > > > packet. > > > > > > > > > > Additionally, I am not sure that there's quite enough here to=20 > > > > > be > > > interoperably implementable. Specifically, we seem to be lacking=20 > > > a description of how an encoder or decoder knows which TSVCIS=20 > > > parameters, and in what order, to byte-pack or unpack, = respectively. > > > One might surmise that there is a canonical listing in [TSVCIS],=20 > > > but this document does not say that, and furthermore [TSVCIS] is = only listed as an informative reference. > > > (I couldn't get my hands on my copy, at least on short notice.) =20 > > > If we limited ourselves to treating the TSVCIS parameters as an=20 > > > entirely opaque blob (codec, convey these N octets to the peer=20 > > > with the appropriate one- or two-byte trailer for payload type=20 > > > identification and framing), that would be interoperably=20 > > > implementable, since the black-box bits are up to some other codec = to interpret. > > > > > > > > > > In a similar vein, we mention but do not completely specify=20 > > > > > the > > > potential for using CODB as an end-to-end framing bit, in Section > > > 3.1 (see Comment), which is not interoperably implementable = without further details. > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > -- > > > > > ---- > > > > > -- > > > > > COMMENT: > > > > > -------------------------------------------------------------- > > > > > -- > > > > > ---- > > > > > -- > > > > > > > > > > Where is [TSVCIS] available? > > > > > > > > > > Is [NRLVDR] the same as > > > > > https://apps.dtic.mil/dtic/tr/fulltext/u2/a588068.pdf ? A URL = > > > > > in the > > > references would be helpful. > > > > > > > > > > Is additional TSVCIS data only present after 2400bps MELPe and = > > > > > the first > > > thing to get dropped under bandwidth pressure? The abstract and=20 > > > introduction imply this by calling out MELPe 2400 bps speech=20 > > > parameters explicitly, but Section 3 says that TSVCIS augments=20 > > > standard 600, 1200, and > > > 2400 bps MELP frames. > > > > > > > > > > It's helpful that Section 3.3 gives some general guidance for=20 > > > > > decoding > > > this payload type ("[t]he way to determine the number of=20 > > > TSVCIS/MELPe frames is to identify each frame type and length"),=20 > > > but I think some generic considerations would be very helpful to=20 > > > the reader much earlier, along the lines of "MELPe and TSVCIS data = > > > payloads are decoded from the end, using the CODA and CODB (and,=20 > > > if necessary, CODC and others) bits to determine the type of = payload. > > > For MELPe payloads the type also indicates the payload length,=20 > > > whereas for TSVCIS data an additional length field is present, in=20 > > > one of two possible formats. A TSVCIS coder frame consists of a=20 > > > MELPe data payload followed by zero or one TSVCIS data payload;=20 > > > after the TSVCIS payload's presence/length is determined, then the = > > > preceding MELPe payload can be determined and decoded. Per=20 > > > Section 3.3, multiple TSVCIS frames can be present in a single RTP = packet." > > > This (or something like it) would also serve to clarify the role = of the COD* bits, which is otherwise only implicitly introduced. > > > > > > > > > > Section 1.1 > > > > > > > > > > RFC 2736 is BCP 36 (but it's updated by RFC 8088 which is for=20 > > > > > some > > > reason an Informational document and not part of BCP 36?!). > > > > > > > > > > Section 2 > > > > > > > > > > In addition to the augmented speech data, the TSVCIS = specification > > > > > identifies which speech coder and framing bits are to be = encrypted, > > > > > and how they are protected by forward error correction = (FEC) > > > > > techniques (using block codes). At the RTP transport = layer, only the > > > > > speech coder related bits need to be considered and are = conveyed in > > > > > unencrypted form. In most IP-based network deployments,=20 > > > > > standard > > > > > > > > > > Am I reading this correctly that this text is just summarizing = > > > > > what's in > > > the TSVCIS spec in terms of what needs to be in unencrypted form,=20 > > > so the "only the speech coder related bits[...]" is not new=20 > > > information from this document? I'm not sure I agree with the=20 > > > conclusion, regardless -- won't the > > > (MELPe) speech coder bits be enough to convey the semantic content = > > > of the audio stream, something that one might desire to keep = confidential? > > > > > > > > > > link encryption methods (SRTP, VPNs, FIPS 140 link = encryptors or Type > > > > > 1 Ethernet encryptors) would be used to secure the RTP = speech > > > > > contents. Further, it is desirable to support the highest = voice > > > > > quality between endpoints which is only possible without = the overhead > > > > > of FEC. > > > > > > > > > > I think I'm missing a step in how this conclusion was reached. > > > > > > > > > > TSVCIS will be characterized. Depending on the bandwidth = available > > > > > (and FEC requirements), a varying number of TSVCIS specific = speech > > > > > coder parameters need to be transported. These are first = byte-packed > > > > > and then conveyed from encoder to decoder. > > > > > > > > > > Per the Discuss point, how do I know which parameters need to=20 > > > > > be > > > transported, and in what order? > > > > > > > > > > Byte packing of TSVCIS speech data into packed parameters = is > > > > > processed as per the following example: > > > > > > > > > > Three-bit field: bits A, B, and C (A is MSB, C is LSB) > > > > > Five-bit field: bits D, E, F, G, and H (D is MSB, H is > > > > > LSB) > > > > > > > > > > MSB = LSB > > > > > 0 1 2 3 4 5 6 7 > > > > > = +------+------+------+------+------+------+------+------+ > > > > > | H | G | F | E | D | C | B | A = | > > > > > =20 > > > > > +------+------+------+------+------+------+------+------+ > > > > > > > > > > This packing method places the three-bit field "first" in = the lowest > > > > > bits followed by the next five-bit field. Parameters may = be split > > > > > between octets with the most significant bits in the = earlier octet. > > > > > Any unfilled bits in the last octet MUST be filled with = zero. > > > > > > > > > > I agree with Adam that this is very unclear. A is the MSB of=20 > > > > > the > > > three-bit field but the LSB of the octet overall? > > > > > We probably need an example of splitting a parameter across=20 > > > > > octets as > > > well, to get the bit ordering right. > > > > > > > > > > Section 3.1 > > > > > > > > > > It should be noted that CODB for both the 2400 and 600 bps = modes MAY > > > > > deviate from the values in Table 1 when bit 55 is used as = an end-to- > > > > > end framing bit. Frame decoding would remain distinct as=20 > > > > > CODA being > > > > > > > > > > Where is the use of CODB as an end-to-end framing bit defined? = =20 > > > > > If we're > > > going to provide neither a complete description of how to do it=20 > > > nor a reference to a better description, we probably shouldn't = mention it at all. > > > > > > > > > > Section 3.2 > > > > > > > > > > RTP packet. The packed parameters are counted in octets = (TC). In > > > > > the preferred placement, shown in Figure 6, a single = trailing octet > > > > > SHALL be appended to include a two-bit rate code, CODA and=20 > > > > > CODB, > > > > > > > > > > I'd consider saying something about this being the preferred=20 > > > > > format > > > > > ("placement") due to its shorter length than the alternative,=20 > > > > > and say > > > that it "SHOULD be used for TSVCIS payloads with TC less than or=20 > > > equal to 77 octetes". > > > > > > > > > > Section 3.3 > > > > > > > > > > When a longer packetization interval is used, is that=20 > > > > > indicated by > > > signaling or RTP timestamps or otherwise? > > > > > > > > > > TSVCIS coder frames in a single RTP packet MAY be of = different coder > > > > > bitrates. With the exception for the variable length = TSVCIS > > > > > parameter frames, the coder rate bits in the trailing byte = identify > > > > > the contents and length as per Table 1. > > > > > > > > > > Maybe also note that the penultimate octet gives the length = there? > > > > > > > > > > Information describing the number of frames contained in an = RTP > > > > > packet is not transmitted as part of the RTP payload. The = way to > > > > > determine the number of TSVCIS/MELPe frames is to identify = each frame > > > > > type and length thereby counting the total number of octets = within > > > > > the RTP packet. > > > > > > > > > > terminology nit: if a frame is the combination of MELPe and=20 > > > > > TSVCIS > > > payload data units then there are two layres of decoding to get a=20 > > > length for the frame, since we have to get the TSVCIS length and = then the MELPe length. > > > > > > > > > > Section 4.2 > > > > > > > > > > Parameter "ptime" cannot be used for the purpose of=20 > > > > > specifying the > > > > > > > > > > nit: missing article ("The parameter") > > > > > > > > > > will be impossible to distinguish which mode is about to be = used > > > > > (e.g., when ptime=3D68, it would be impossible to = distinguish if the > > > > > packet is carrying one frame of 67.5 ms or three frames of = 22.5 ms). > > > > > > > > > > So how is the operating mode determined, then? > > > > > (I think this is the same question I asked above) > > > > > > > > > > Section 4.4 > > > > > > > > > > For example, if offerer bitrates are "2400,600" and answer = bitrates > > > > > are "600,2400", the initial bitrate is 600. If other = bitrates are > > > > > provided by the answerer, any common bitrate between the = offer and > > > > > answer MAY be used at any time in the future. Activation = of these > > > > > other common bitrates is beyond the scope of this document. > > > > > > > > > > It seems important to specify whether this requires a new O/A=20 > > > > > exchange > > > or can be done "spontaneously" by just encoding different frame = types. > > > > > (It seems like the latter is possible, on first glance, and=20 > > > > > this is implied by Section 3.3's discussion of mixing them in=20 > > > > > a single > > > > > packet.) > > > > > > > > > > Section 5 > > > > > > > > > > Please expand PLC at first use (not second). > > > > > > > > > > Section 6 > > > > > > > > > > I don't understand the PLC usage. Is the idea that a=20 > > > > > receiver, on > > > seeing an SSRC gap, constructs fictitious PLC frames to "fill the = gap" > > > > > and passes the resulting stream to the decoder? > > > > > > > > > > Section 8 > > > > > > > > > > and important considerations in [RFC7201]. Applications = SHOULD use > > > > > one or more appropriate strong security mechanisms. The = rest of this > > > > > section discusses the security-impacting properties of the = payload > > > > > format itself. > > > > > > > > > > I thought we described TSVCIS itself (much earlier in the > > > > > document) as > > > requiring encryption for some data; wouldn't that translate to a = "MUST" > > > > > here and not a "SHOULD"? > > > > > > > > > > > > > > > > > > > =20 ------=_NextPart_001_002D_01D60D9B.9E56D0F0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable RE: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: = (with DISCUSS and COMMENT)

Hi = Ben,

With this = social distancing situation, I'm finally catching up on open = items myself.  I have made the changes as we have discussed and = incorporated your = suggestions.  I believe the changes are fully contained in the two = paragraphs below:

Section 2 (last = paragraph) - Clarification for octet count

(was)

In order to = accommodate a varying amount of TSVCIS augmented = speech

data, it = is only necessary to specify the number of octets

containing = the packed TSVCIS parameters.  The encoding to do so = is

presented in = Section 3.2.  TSVCIS specifically uses the NRL VDR in = two

configurations = using 15 = and 35 packed octet parameters [TSVCIS].  =

(now)

In order to = accommodate a varying amount of TSVCIS augmented = speech

data, an = octet count specifies the number of octets = representing

the packed = TSVCIS parameters.  The encoding to do so is presented = in

Section = 3.2.  TSVCIS specifically uses the NRL VDR in two

configurations = using a = fixed set of 15 and 35 packed octet

parameters = in a standardized order [TSVCIS].  =


Section 3.1 = (first sentence in last paragraph) - Clarification for CODA, = CODB

(was)

It should be = noted that CODB for MELPe 600 bps mode MAY deviate = from

the value in = Table 1 when bit 55 is used as an end-to-end framing = bit.

(now)

It should be = noted that CODB for MELPe 600 bps mode MAY deviate = from

the value in = Table 1 when bit 55 is used as an alternating = 1/0

end-to-end = framing bit. 

Ben, I believe = this addresses your comments and requests for clarifications as per our = email discussion chain below.

Thanks for you = comments and with your concurrence (and my home computer's cooperation), = I will post a new draft hopefully acceptable for final = approval.

Regards to all = and stay on = the good side of Darwin.

Victor


-----Original = Message-----

From: Benjamin = Kaduk <kaduk@mit.edu>

Sent: Friday, = February 14, 2020 2:43 PM

To: = victor.demjanenko@vocal.com; 'Barry Leiba' = <barryleiba@computer.org>

Cc: 'Roni Even = (A)' <roni.even@huawei.com>; 'The IESG' <iesg@ietf.org>; = 'Catherine Meadows' <catherine.meadows@nrl.navy.mil>; 'IETF = SecDir' <secdir@ietf.org>; draft-ietf-payload-tsvcis@ietf.org; = 'Ali Begen' <ali.begen@networked.media>; avtcore-chairs@ietf.org; = avt@ietf.org; 'Dave Satterlee (Vocal)' <Dave.Satterlee@vocal.com>; = 'IETF discussion list' <ietf@ietf.org>; = draft-ietf-payload-tsvcis.all@ietf.org

Subject: Re: = Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS = and COMMENT)

Hi = Barry,

As Victor = notes, this one was/is waiting on me; he did reply (offlist) = on

15 January but = I seem to have missed it amid a deluge of other mail that arrived at = that time.  Thanks for the reminder, and thanks Victor for = re-sending the comments.

(inline)

On Fri, Feb 14, = 2020 at 08:20:54AM -0500, victor.demjanenko@vocal.com = wrote:

> HI = Barry,

> =

> Thanks for = recalling this was still outstanding.  I had emailed Ben just after = the holidays and did not realize we had no response.  The below is = what we suggested to Ben to address concerns he = raised.

> =

> = --------------------

> Hi = Ben,

> =

> Hope your = holidays were good.  Our were both good and busy.  Deliveries = for two NASA projects and the holidays kept us from responding = sooner.  But we do want to get this draft = completed.

> =

> With your = permission, I=E2=80=99d like to address your comments directly, resolve = what changes we should make and then publish a new version with a = summary of our out-of-band discussions.  We don=E2=80=99t have a = lot of experience with drafting such documents and would like to know = exactly what is needed to make this draft acceptable.

> =

> I believe = there are two comments/issues to address:

> =

> = 1)    CODA, CODB

> =

> Your = comment ends by stating:  =E2=80=9C(Or, of course, the use of CODB = as an alternating 1/0 bit as the framing usage could be documented = instead.)=E2=80=9D  We can do this as follows:

> =

> = (original)

> It should = be noted that CODB for MELPe 600 bps mode MAY deviate = from

>    the value in Table 1 when bit 55 = is used as an end-to-end framing

>    bit. Frame decoding would remain = distinct as CODA being zero on its

>    own would indicate a 7-byte = frame for either 2400 or 600 bps rate and

>    the use of 600 bps speech coding = could be deduced from the RTP

>    timestamp (and anticipated by = the SDP negotiations).

> =

> (adding = =E2=80=9Calternating 1/0=E2=80=9D)

> It should = be noted that CODB for MELPe 600 bps mode MAY deviate = from

>    the value in Table 1 when bit 55 = is used as an alternating 1/0 end-to-end framing

>    bit. Frame decoding would remain = distinct as CODA being zero on its

>    own would indicate a 7-byte = frame for either 2400 or 600 bps rate and

>    the use of 600 bps speech coding = could be deduced from the RTP

>    timestamp (and anticipated by = the SDP negotiations).

> =

> I think = this change would be sufficient to address your concern about what to = expect for CODB.

This looks like = the minimal sufficient change, yes.  (I use = "minimal"

because I would = say more if I was writing it, but I don't think I can insist that you = write it the way I would -- it's your document after = all!)

> = 2.    Packing and unpacking

> =

> You are = correct that I am trying to vaguely describe a middle layer shim that is = neither RTP nor speech coder.  So it definitely does need to be = clear.  The vagueness comes from the speech coder description being = a FOUO document.  Its now unclassified so I can potentially say = more (and I did make some enhancements of the parameter description = already). 

> =

> So I am = trying to understand exactly what you think is vague in our current = description:

> =

> TSVCIS = augmented speech data is derived from the signal = processing

>    and data already performed by = the MELPe speech coder.  For the

>    purposes of this specification, = only the general parameter nature of

>    TSVCIS will be = characterized.  Depending on the bandwidth = available

>    (and FEC requirements), a = varying number of TSVCIS-specific speech

>    coder parameters need to be = transported.  These are first byte-packed

>    and then conveyed from encoder = to decoder.

> =

>    Byte packing of TSVCIS speech = data into packed parameters is

>    processed as per the following = example:

> =

>       Three-bit = field: bits A, B, and C (A is MSB, C is LSB)

>       Five-bit = field: bits D, E, F, G, and H (D is MSB, H is LSB)

> =

>        &nbs= p;   = MSB           &nbs= p;            = ;            =           = LSB

>        &nbs= p;    0      = 1      2      = 3      4      = 5      6      = 7

>         = +------+------+------+------+------+------+------+------+

>         = |   H  |   G  |   F  = |   E  |   D  |   C  = |   B  |   A  |

>         = +------+------+------+------+------+------+------+------+

> =

>    This packing method places the = three-bit field "first" in the lowest

>    bits followed by the next = five-bit field.  Parameters may be split

>    between octets with the most = significant bits in the earlier octet.

>    Any unfilled bits in the last = octet MUST be filled with zero.

[not actually = relevant to the Discuss part, but if there is always exactly one 3-bit = parameter and one 5-bit parameter, then this text allowing splitting = across octets will never be used and is potentially confusing to = mention.]

>    In order to accommodate a = varying amount of TSVCIS augmented speech

>    data, it is only necessary to = specify the number of octets containing

>    the packed TSVCIS = parameters.  The encoding to do so is presented

> = in

I think the = "only necessary to specify the number of octets" is the key = stumbling point, for me -- I need to know the number of octets as well = as the order of the parameters within the list, which is more = information than just the number of octets.

>    Section 3.2.  TSVCIS = specifically uses the NRL VDR in two

>    configurations using 15 and 35 = packed octet parameters [TSVCIS]. 

I think I = failed to internalize the "two configurations using 15 and 35 = packed octet parameters" the first time I read the document, as = this does help give the reader a clue that [TSVCIS] gives a good picture = of what parameters go where.  So it seems like we could easily = append to that, for "using a fixed set of 15 and 35 packed octet = parameters in a fixed order [TSVCIS]" and that would resolve my = concerns.

> The speech = coder description of the parameters is the following:

> =

>  =

> =

> So the = three bit pitch is first (bits 56 to 58), followed by a five bit = amplitude (bits 59 to 63) and then an array of spectral components, each = 8-bit wide (starting at bit 64).

[And maybe = TSVCIS specifes that the spectral components are derived from some = fundamental harmonic decomposition that naturally quantizes to a = number-of-parameters/accuracy tradeoff with a natural order.  If = so, we could also rely on that instead of my proposed change above; let = me know if you want to explore that path further.]

> Based on = this information, I=E2=80=99m not sure what we should add to our =

> draft to = make the description of packing/unpacking clearer.  Can you =

> make any = suggestions or does this table help you with what you did not =

> = know?  (I don=E2=80=99t think I should put this table into the = draft RFC

> = however.)

Hopefully the = above helps to clarify.

Thanks, and = sorry for the delay.

-Ben

> Thanks for = your attention and comments.

> =

> Victor = & Dave

> =

> =

> =

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

> From: = Barry Leiba <barryleiba@computer.org>

> Sent: = Friday, February 14, 2020 7:38 AM

> To: = Benjamin Kaduk <kaduk@mit.edu>

> Cc: = victor.demjanenko@vocal.com; Roni Even (A) <roni.even@huawei.com>; =

> The IESG = <iesg@ietf.org>; Catherine Meadows

> = <catherine.meadows@nrl.navy.mil>; IETF SecDir = <secdir@ietf.org>;

> = draft-ietf-payload-tsvcis@ietf.org; Ali Begen

> = <ali.begen@networked.media>; avtcore-chairs@ietf.org; = avt@ietf.org;

> Dave = Satterlee (Vocal) <Dave.Satterlee@vocal.com>; IETF discussion =

> list = <ietf@ietf.org>;  draft-ietf-payload-tsvcis.all@ietf.orgygv =

> Subject: = Re: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: =

> (with = DISCUSS and COMMENT)

> =

> This is = still outstanding, since November.  Victor, where are we on this = one?

> =

> = Barry

> =

> On Mon, = Nov 25, 2019 at 1:46 AM Benjamin Kaduk <kaduk@mit.edu> = wrote:

> = >

> > Hi = Victor,

> = >

> > On = Tue, Nov 19, 2019 at 03:14:21PM -0500, victor.demjanenko@vocal.com = wrote:

> > > = Hi Ben,

> > = >

> > > = Sorry I overlooked sending you a response.  I would like to =

> > > = address the two concerns you have by explaining what the speech coders = are doing.

> = >

> > = Thanks for the extra clarifications.  To supply one of my own: I'm =

> > not = concerned that the protocol doesn't work as implemented, but =

> > just = want to make sure that the document includes enough information =

> > to = admit new implementations without guesswork.  That is to say, =

> > = "either tell me how to do it or tell me where to look that tells me = how to do it".

> = >

> > > = WRT to 600 bps MELP, there is one TSVCIS mode that uses one bit =

> > > = beyond the 54-bit frame for MELP 600 as a frame sync which alternates = between frames.

> > > = With two or more MELP 600bps frames in one RTP packet, if any =

> > > = frame indicates 600 bps by CODA being 0 and CODB being 1, then we =

> > > = know the stream is 600bps.  If there is a single frame in an RTP =

> > > = packet, you can still deduce this by looking at every other RTP =

> > > = packet (every other MELP 600bps

> > > = frame) and by the timestamp advance.  Most likely the two ends =

> > > = would negotiate 600 bps in SDP anyways so there really should not =

> > > = be a problem.  I know it's not pretty but its workable.  I = hope

> > > = this explanation helps you with the concerns for this = issue.

> = >

> > In = this case, the use as an "end-to-end framing bit" (i.e., the =

> > = alternating behavior you describe above) is not explicitly stated; =

> > one = might imagine a scheme where the framing usage is to have the =

> > bit = cycle through 1, 1, 0, and 0, or some other scheme.  I'd suggest =

> > to = note in the document that if any instance of (CODA, CODB) =3D=3D (0, =

> > 1) is = observed, then the 600bps mode is in use.  It might also be =

> > = helpful to include the observation that two successive MELPe =

> > = payloads with CODA =3D=3D CODB =3D=3D 0 indicates the 2400bps mode (and = that

> > = seeing them in a single RTP packet is decisive, whereas additional =

> > = information about packet non-loss would be needed in the =

> > = one-MELPe-frame-per-RTP-packet case), but that would be a fair bit =

> > of = additional text and might be diminishing returns.  (Or, of =

> > = course, the use of CODB as an alternating 1/0 bit as the framing =

> > usage = could be documented

> > = instead.)

> = >

> > > = As for the TSVCIS parameter packing/unpacking, this is really =

> > > = simple.  There is exactly on three bit parameter, exactly one five =

> > > = bit parameter and a variable number of eight bit parameters.  In =

> > > = our view, the speech coder itself (or a wrapper for it) is =

> > > = responsible for preparing the block of octets.  RTP then just =

> > > = transports it.  On receive, the complementary wrapper reverses the = packing operation.

> > > = I hope this clarifies and explains the simplicity.

> = >

> > = That's exactly what I expected to happen; however, it's not what I =

> > = believe the current text of the document is describing.  =

> > = Specifically, I think that the current text implies that the =

> > = "preparing the block of octets" and "complementary = wrapper reverses

> > the = packing operation" are supposed to be part of the RTP payload =

> > = format that this document describes, but this document does not have =

> > = enough information to actually perform those operations = reversibly. 

> > If = the packing is to be done in the speech coder, then this document =

> > = doesn't need to talk about the packing at all (e.g., at the end of =

> > = Section 2); if we need to keep the packing/wrapper in this document =

> > then = we need to indicate that there's a defined priority order for =

> > the = (8-octet) TSVCIS parameters in the TSVCIS references, to allow the = packing/unpacking to be deterministic.

> = >

> > = Thanks,

> = >

> > = Ben

> = >

> > = >

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

> > > = From: Benjamin Kaduk <kaduk@mit.edu>

> > > = Sent: Thursday, October 31, 2019 8:12 PM

> > > = To: Barry Leiba <barryleiba@computer.org>

> > > = Cc: victor.demjanenko@vocal.com; Roni Even (A)

> > > = <roni.even@huawei.com>; The IESG <iesg@ietf.org>; Catherine =

> > > = Meadows <catherine.meadows@nrl.navy.mil>; IETF SecDir =

> > > = <secdir@ietf.org>; draft-ietf-payload-tsvcis@ietf.org; Ali Begen =

> > > = <ali.begen@networked.media>; avtcore-chairs@ietf.org; =

> > > = avt@ietf.org; Dave Satterlee (Vocal) <Dave.Satterlee@vocal.com>; =

> > > = IETF discussion list <ietf@ietf.org>;

> > > = draft-ietf-payload-tsvcis.all@ietf.org

> > > = Subject: Re: Benjamin Kaduk's Discuss on

> > > = draft-ietf-payload-tsvcis-03: (with DISCUSS and = COMMENT)

> > = >

> > > = I don't think so, unfortunately.

> > = >

> > > = I do see the clarification about CODB's potential for deviation =

> > > = from Table 1, that only the 600 bps MELPe is allowed to deviate, =

> > > = and that CODA gets us to "it's one of 2400 or 600 bps" and the = RTP

> > > = timestamp disambiguates that

> > > = 600 bps is in use.  But, it seems that this means that the =

> > > = recipient in general should not rely on CODB to differentiate 600 =

> > > = from 2400 bps, and instead is more robustly implemented by =

> > > = *always* using the RTP timestamp to detect 600 bps, since that =

> > > = will always work and CODB will sometimes not work under conditions =

> > > = not fully specified here.  So, if we are unwilling or unable to =

> > > = clarify what those conditions are (e.g., whether at a minimum =

> > > = mutual agreement is required), then I think we need to describe =

> > > = this procedure of consulting the RTP timestamp as the default behavior = and avoid giving the impression that CODB should be used to do = so.

> > = >

> > > = Additionally, I don't see anything to address my concern about =

> > > = TSVCIS parameter decoding.  To be clear, the procedure I see this =

> > > = document describing is that:

> > > = - TSVCIS gives parameters (and their lengths in bits) to the = codec

> > = >   described in this document

> > > = - this document specifies how to densely encode those parameters into = a

> > = >   byetstream

> > > = - RTP transmits that encoded bytestream to the peer

> > > = - the codec specified by this is responsible for turning that = encoded

> > = >   bystream back into a list of TSVCIS parameters (and = their length

> > > = in bits)

> > = >

> > > = I don't see how that last step is attainable with only the =

> > > = information provided by this document.  I *assume* that one of the =

> > > = TSVCIS specifications has a canonical (ordered) listing of =

> > > = parameters, and that the list of parmeters given to this codec in =

> > > = the first step will always be an initial prefix of that list, but =

> > > = that's just me guessing at how to make sense of the stated =

> > > = procedure given insufficient information.  I don't think it's =

> > > = appropriate to make the reader of an RFC guess at what to do; we =

> > > = need to either say how to do it or give a pointer to an external = reference that does.

> > = >

> > > = -Ben

> > = >

> > > = On Tue, Oct 29, 2019 at 02:26:09PM -0400, Barry Leiba = wrote:

> > > = > Ben, does the -04 version address everything?

> > > = >

> > > = > Barry

> > > = >

> > > = > On Thu, Oct 24, 2019 at 1:42 PM <victor.demjanenko@vocal.com> = wrote:

> > > = > >

> > > = > > I forgot to address security comments in one email.  The = changes are:

> > > = > >

> > > = > > Section 8, second paragraph - Suggested edit by = reviewer

> > > = > >

> > > = > > (was)

> > > = > >    This RTP payload format and the TSVCIS = decoder do not exhibit any

> > > = > >    significant non-uniformity in the = receiver-side computational

> > > = > >    complexity for packet processing and thus = are unlikely to pose a

> > > = > >    denial-of-service threat due to the receipt = of pathological data.

> > > = > >    Additionally, the RTP payload format does = not contain any active

> > > = > >    content.

> > > = > >

> > > = > > (now)

> > > = > >    This RTP payload format and the TSVCIS = decoder, to the best of our

> > > = > >    knowledge, do not exhibit any significant = non-uniformity in the

> > > = > >    receiver-side computational complexity for = packet processing and thus

> > > = > >    are unlikely to pose a denial-of-service = threat due to the receipt of

> > > = > >    pathological data. Additionally, the RTP = payload format does not

> > > = > >    contain any active = content.

> > > = > >

> > > = > >

> > > = > > Section 8, third paragraph - Suggested edit by = reviewer

> > > = > >

> > > = > > (was)

> > > = > >    Please see the security considerations = discussed in [RFC6562]

> > > = > >    regarding VAD and its effect on = bitrates.

> > > = > >

> > > = > > (now)

> > > = > >    Please see the security considerations = discussed in [RFC6562]

> > > = > >    regarding Voice Activity Detect (VAD) and = its effect on bitrates.

> > > = > >

> > > = > > Victor

> > > = > >

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

> > > = > > From: victor.demjanenko@vocal.com

> > > = > > <victor.demjanenko@vocal.com>

> > > = > > Sent: Thursday, October 24, 2019 10:05 AM

> > > = > > To: 'Roni Even (A)' <roni.even@huawei.com>; 'Benjamin = Kaduk'

> > > = > > <kaduk@mit.edu>; 'The IESG' = <iesg@ietf.org>

> > > = > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali = Begen'

> > > = > > <ali.begen@networked.media>; avtcore-chairs@ietf.org; =

> > > = > > avt@ietf.org; 'Dave Satterlee (Vocal)'

> > > = > > <Dave.Satterlee@vocal.com>

> > > = > > Subject: RE: Benjamin Kaduk's Discuss on

> > > = > > draft-ietf-payload-tsvcis-03: (with DISCUSS and = COMMENT)

> > > = > >

> > > = > > Hi Everyone,

> > > = > >

> > > = > > First we want to thank everyone for their review and comments =

> > > = > > for this

> > > = draft RFC.  We believe we reviewed all the comments and =

> > > = suggestions and incorporated them adequately in the next draft =

> > > = (04).  We'd like to send out this list of exact changes in case =

> > > = anyone has additional comments or thinks the clarifications are =

> > > = inadequate.  We would be most happy to address concerns before = publishing draft 04 tomorrow.

> > > = > >

> > > = > > With so many emails from a half dozen or more reviewers, we =

> > > = > > apologize

> > > = that we cannot address each sender individually.  We hope this =

> > > = detail is sufficient for everyone.

> > > = > >

> > > = > > Again, many thanks to all.

> > > = > >

> > > = > > Victor & Dave

> > > = > >

> > > = > > = --------------------------------------------------------------

> > > = > > --

> > > = > > ----

> > > = > > --------------------------

> > > = > >

> > > = > > Section 1.1 - Suggested reference to RFC 8088 = added.

> > > = > >

> > > = > > (was)

> > > = > >    Best current practices for writing an RTP = payload format

> > > = > >    specification were followed = [RFC2736].

> > > = > >

> > > = > > (now)

> > > = > >    Best current practices for writing an RTP = payload format

> > > = > >    specification were followed [RFC2736] = [RFC8088].

> > > = > >

> > > = > >

> > > = > > Section 2, paragraphs 3 and 4 - Suggested edits by = reviewers

> > > = > >

> > > = > > (was)

> > > = > >    In addition to the augmented speech data, = the TSVCIS specification

> > > = > >    identifies which speech coder and framing = bits are to be encrypted,

> > > = > >    and how they are protected by forward error = correction (FEC)

> > > = > >    techniques (using block codes).  At the = RTP transport layer, only the

> > > = > >    speech coder related bits need to be = considered and are conveyed in

> > > = > >    unencrypted form.  In most IP-based = network deployments, standard

> > > = > >    link encryption methods (SRTP, VPNs, FIPS = 140 link encryptors or Type

> > > = > >    1 Ethernet encryptors) would be used to = secure the RTP speech

> > > = > >    contents.  Further, it is desirable to = support the highest voice

> > > = > >    quality between endpoints which is only = possible without the overhead

> > > = > >    of FEC.

> > > = > >

> > > = > >    TSVCIS augmented speech data is derived from = the signal processing

> > > = > >    and data already performed by the MELPe = speech coder.  For the

> > > = > >    purposes of this specification, only the = general parameter nature of

> > > = > >    TSVCIS will be characterized.  = Depending on the bandwidth available

> > > = > >    (and FEC requirements), a varying number of = TSVCIS specific speech

> > > = > >    coder parameters need to be = transported.  These are first byte-packed

> > > = > >    and then conveyed from encoder to = decoder.

> > > = > >

> > > = > > (now)

> > > = > >    In addition to the augmented speech data, = the TSVCIS specification

> > > = > >    identifies which speech coder and framing = bits are to be encrypted,

> > > = > >    and how they are protected by forward error = correction (FEC)

> > > = > >    techniques (using block codes).  At the = RTP transport layer, only the

> > > = > >    speech-coder-related bits need to be = considered and are conveyed in

> > > = > >    unencrypted form.  In most IP-based = network deployments, standard

> > > = > >    link encryption methods (SRTP, VPNs, FIPS = 140 link encryptors or Type

> > > = > >    1 Ethernet encryptors) would be used to = secure the RTP speech

> > > = > >    contents.

> > > = > >

> > > = > >    TSVCIS augmented speech data is derived from = the signal processing

> > > = > >    and data already performed by the MELPe = speech coder.  For the

> > > = > >    purposes of this specification, only the = general parameter nature of

> > > = > >    TSVCIS will be characterized.  = Depending on the bandwidth available

> > > = > >    (and FEC requirements), a varying number of = TSVCIS-specific speech

> > > = > >    coder parameters need to be = transported.  These are first byte-packed

> > > = > >    and then conveyed from encoder to = decoder.

> > > = > >

> > > = > >

> > > = > > Section 3, last sentence paragraph 3 - Suggested edit by =

> > > = > > reviewer

> > > = > >

> > > = > > (was)

> > > = > >    When more than one codec data frame = is

> > > = > >    present in a single RTP packet, the = timestamp is, as always, that of

> > > = > >    the oldest data frame represented in the RTP = packet.

> > > = > >

> > > = > > (now)

> > > = > >    When more than one codec data frame = is

> > > = > >    present in a single RTP packet, the = timestamp specified is that of

> > > = > >    the oldest data frame represented in the RTP = packet.

> > > = > >

> > > = > >

> > > = > > Section 3.1, last paragraph - Clarified permission for MELP =

> > > = > > 600 end-to-end framing bit

> > > = > >

> > > = > > (was)

> > > = > >    It should be noted that CODB for both the = 2400 and 600 bps modes MAY

> > > = > >    deviate from the values in Table 1 when bit = 55 is used as an end-to-

> > > = > >    end framing bit.  Frame decoding would = remain distinct as CODA being

> > > = > >    zero on its own would indicate a 7-byte = frame for either rate and the

> > > = > >    use of 600 bps speech coding could be = deduced from the RTP timestamp

> > > = > >    (and anticipated by the SDP = negotiations).

> > > = > >

> > > = > > (now)

> > > = > >    It should be noted that CODB for MELPe 600 = bps mode MAY deviate from

> > > = > >    the value in Table 1 when bit 55 is used as = an end-to-end framing

> > > = > >    bit. Frame decoding would remain distinct as = CODA being zero on its

> > > = > >    own would indicate a 7-byte frame for either = 2400 or 600 bps rate and

> > > = > >    the use of 600 bps speech coding could be = deduced from the RTP

> > > = > >    timestamp (and anticipated by the SDP = negotiations).

> > > = > >

> > > = > >

> > > = > > Section 3.2, first paragraph - Clarifications requested by =

> > > = > > reviewers

> > > = > >

> > > = > > (was)

> > > = > >    The TSVCIS augmented speech data as packed = parameters MUST be placed

> > > = > >    immediately after a corresponding MELPe 2400 = bps payload in the same

> > > = > >    RTP packet.  The packed parameters are = counted in octets (TC).  In

> > > = > >    the preferred placement, shown in Figure 6, = a single trailing octet

> > > = > >    SHALL be appended to include a two-bit rate = code, CODA and CODB,

> > > = > >    (both bits set to one) and a six-bit = modified count (MTC).  The

> > > = > >    special modified count value of all ones = (representing a MTC value of

> > > = > >    63) SHALL NOT be used for this format as it = is used as the indicator

> > > = > >    for the alternate packing format shown = next.  In a standard

> > > = > >    implementation, the TSVCIS speech coder uses = a minimum of 15 octets

> > > = > >    for parameters in octet packed form.  = The modified count (MTC) MUST

> > > = > >    be reduced by 15 from the full octet count = (TC).  Computed MTC =3D TC-

> > > = > >    15.  This accommodates a maximum of 77 = parameter octets (maximum

> > > = > >    value of MTC is 62, 77 is the sum of = 62+15).

> > > = > >

> > > = > > (now)

> > > = > >    The TSVCIS augmented speech data as packed = parameters MUST be placed

> > > = > >    immediately after a corresponding MELPe 2400 = bps payload in the same

> > > = > >    RTP packet.  The packed parameters are = counted in octets (TC).  The

> > > = > >    preferred placement SHOULD be used for = TSVCIS payloads with TC less

> > > = > >    than or equal to 77 octets, is shown in = Figure 6.  In the preferred

> > > = > >    placement, a single trailing octet SHALL be = appended to include a

> > > = > >    two-bit rate code, CODA and CODB, (both bits = set to one) and a six-

> > > = > >    bit modified count (MTC).  The special = modified count value of all

> > > = > >    ones (representing a MTC value of 63) SHALL = NOT be used for this

> > > = > >    format as it is used as the indicator for = the alternate packing

> > > = > >    format shown next.  In a standard = implementation, the TSVCIS speech

> > > = > >    coder uses a minimum of 15 octets for = parameters in octet packed

> > > = > >    form.  The modified count (MTC) MUST be = reduced by 15 from the full

> > > = > >    octet count (TC).  Computed MTC =3D = TC-15.  This accommodates a maximum

> > > = > >    of 77 parameter octets (maximum value of MTC = is 62, 77 is the sum of

> > > = > >    62+15).

> > > = > >

> > > = > >

> > > = > > Section 3.3, first paragraph - Suggested edit by = reviewer

> > > = > >

> > > = > > (was)

> > > = > >    A TSVCIS RTP packet consists of zero or more = TSVCIS coder frames

> > > = > >    (each consisting of MELPe and TSVCIS coder = data) followed by zero or

> > > = > >    one MELPe comfort noise frame.  The = presence of a comfort noise frame

> > > = > >    can be determined by its rate code bits in = its last octet.

> > > = > >

> > > = > > (now)

> > > = > >    A TSVCIS RTP packet payload consists of zero = or more consecutive

> > > = > >    TSVCIS coder frames (each consisting of = MELPe 2400 and TSVCIS coder

> > > = > >    data), with the oldest frame first, followed = by zero or one MELPe

> > > = > >    comfort noise frame.  The presence of a = comfort noise frame can be

> > > = > >    determined by its rate code bits in its last = octet.

> > > = > >

> > > = > >

> > > = > > Section 3.3, fourth paragraph - Clarification requested by =

> > > = > > reviewers

> > > = > >

> > > = > > (was)

> > > = > >    TSVCIS coder frames in a single RTP packet = MAY be of different coder

> > > = > >    bitrates.  With the exception for the = variable length TSVCIS

> > > = > >    parameter frames, the coder rate bits in the = trailing byte identify

> > > = > >    the contents and length as per Table = 1.

> > > = > >

> > > = > > (now)

> > > = > >    TSVCIS coder frames in a single RTP packet = MAY have varying TSVCIS

> > > = > >    parameter octet counts.  Its packed = parameter octet count (length) is

> > > = > >    indicated in the trailing byte(s).  All = MELPe frames in a single RTP

> > > = > >    packet MUST be of the same coder = bitrate.  For all MELPe coder

> > > = > >    frames, the coder rate bits in the trailing = byte identify the

> > > = > >    contents and length as per Table = 1.

> > > = > >

> > > = > >

> > > = > > Section 4.1 - Editor note removed

> > > = > >

> > > = > >

> > > = > > Section 4.1 - Change controller is now

> > > = > >

> > > = > > (now)

> > > = > >    Change controller: IETF, contact = <avt@ietf.org>

> > > = > >

> > > = > >

> > > = > > Section 5, first paragraph - Suggested edits by = reviewers

> > > = > >

> > > = > > (was)

> > > = > >    A primary application of TSVCIS is for radio = communications of voice

> > > = > >    conversations, and discontinuous = transmissions are normal.  When

> > > = > >    TSVCIS is used in an IP network, TSVCIS RTP = packet transmissions may

> > > = > >    cease and resume frequently.  RTP = synchronization source (SSRC)

> > > = > >    sequence number gaps indicate lost packets = to be filled by PLC, while

> > > = > >    abrupt loss of RTP packets indicates = intended discontinuous

> > > = > >    transmissions.

> > > = > >

> > > = > > (now)

> > > = > >    A primary application of TSVCIS is for radio = communications of voice

> > > = > >    conversations, and discontinuous = transmissions are normal.  When

> > > = > >    TSVCIS is used in an IP network, TSVCIS RTP = packet transmissions may

> > > = > >    cease and resume frequently.  RTP = synchronization source (SSRC)

> > > = > >    sequence number gaps indicate lost packets = to be filled by Packet

> > > = > >    Loss Concealment (PLC), while abrupt loss of = RTP packets indicates

> > > = > >    intended discontinuous transmissions.  = Resumption of voice

> > > = > >    transmission SHOULD be indicated by the RTP = marker bit (M) set to 1.

> > > = > >

> > > = > >

> > > = > > Section 10 - Added reference

> > > = > >

> > > = > > (added)

> > > = > >    [RFC8088]  Westerlund, M., "How to = Write an RTP Payload Format",

> > > = > = >           &nb= sp;   RFC 8088, DOI 10.17487/RFC8088, May = 2017,

> > > = > = >           &nb= sp;   <http://www.rfc-editor.org= /info/rfc8088>.

> > > = > >

> > > = > > = --------------------------------------------------------------

> > > = > > --

> > > = > > ----

> > > = > > -----------------------------

> > > = > >

> > > = > >

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

> > > = > > From: Roni Even (A) = <roni.even@huawei.com>

> > > = > > Sent: Sunday, October 6, 2019 2:09 AM

> > > = > > To: victor.demjanenko@vocal.com; 'Benjamin Kaduk' =

> > > = > > <kaduk@mit.edu>; 'The IESG' = <iesg@ietf.org>

> > > = > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali = Begen'

> > > = > > <ali.begen@networked.media>; avtcore-chairs@ietf.org; =

> > > = > > avt@ietf.org; 'Dave Satterlee (Vocal)'

> > > = > > <Dave.Satterlee@vocal.com>

> > > = > > Subject: RE: Benjamin Kaduk's Discuss on

> > > = > > draft-ietf-payload-tsvcis-03: (with DISCUSS and = COMMENT)

> > > = > >

> > > = > > Hi,

> > > = > > About the reference to TSVCIS.

> > > = > > The RTP payload is about how to encapsulate the payload in an =

> > > = > > RTP

> > > = packet. The objective is to define how an RTP stack can insert the =

> > > = tsvcis frames and  extract the tsvcis frames from the RTP = packet.

> > > = Typically it is not required to understand the payload structure =

> > > = in order to be able to perform the encapsulation.

> > > = > > This is why the reference to the payload is Informational and =

> > > = > > we did not require to have it publically available.  If = there

> > > = > > is a need to understand the payload itself for the =

> > > = > > encapsulating than we need more information in the RTP payload =

> > > = > > specification and a publically available normative reference. =

> > > = > > I think this is not the case here

> > > = > >

> > > = > > Roni Even

> > > = > >

> > > = > > AVTCore co-chair (ex Payload)

> > > = > >

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

> > > = > > From: victor.demjanenko@vocal.com

> > > = > > [mailto:victor.demjanenko@voca= l.com]

> > > = > > Sent: Saturday, October 05, 2019 12:18 AM

> > > = > > To: 'Benjamin Kaduk'; 'The IESG'

> > > = > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali = Begen';

> > > = avtcore-chairs@ietf.org; avt@ietf.org; 'Victor Demjanenko, Ph.D.'; =

> > > = 'Dave Satterlee (Vocal)'

> > > = > > Subject: RE: Benjamin Kaduk's Discuss on

> > > = > > draft-ietf-payload-tsvcis-03: (with DISCUSS and = COMMENT)

> > > = > >

> > > = > > Everyone,

> > > = > >

> > > = > > Thanks for the comments.  I think I mis-understood the =

> > > = > > ambiguity with

> > > = respect to to changing rates within a RTP packet.  That was not =

> > > = plan.  An RTP packet must have MELP speech frames of the same = rate.

> > > = What is possible is that the amount of augmented TSVCIS speech =

> > > = data may vary from one speech frame to the next.  This allows for =

> > > = a dynamic VDR as suggested by the NRL paper.  So an RTP packet may =

> > > = have varying TSVCIS data but must always have MELPe 2400 = data.

> > > = > >

> > > = > > Again backwards parsing is necessary but the timestamp =

> > > = > > uniformly

> > > = increments 22.5msec per combined MELP/TSVCIS speech = frame.

> > > = > >

> > > = > > The NRL is a good public reference on the VDR aspects.  = The

> > > = > > actual

> > > = TSVCIS spec we had was FOUO so we could not replicate its detail.  =

> > > = (I believe a later spec is public or at least partially public.  I =

> > > = am trying to get this.)  The opaque data is pretty obvious with the = TSVCIS spec in hand.

> > > = > >

> > > = > > We will address the issues/concerns raised next week.  = Other

> > > = > > business

> > > = had priority.

> > > = > >

> > > = > > Thank you and enjoy the weekend.

> > > = > >

> > > = > > Regards,

> > > = > >

> > > = > > Victor & Dave

> > > = > >

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

> > > = > > From: Benjamin Kaduk via Datatracker = <noreply@ietf.org>

> > > = > > Sent: Wednesday, October 2, 2019 10:40 PM

> > > = > > To: The IESG <iesg@ietf.org>

> > > = > > Cc: draft-ietf-payload-tsvcis@ietf.org; Ali Begen =

> > > = > > <ali.begen@networked.media>; avtcore-chairs@ietf.org; =

> > > = > > ali.begen@networked.media; avt@ietf.org

> > > = > > Subject: Benjamin Kaduk's Discuss on = draft-ietf-payload-tsvcis-03:

> > > = > > (with DISCUSS and COMMENT)

> > > = > >

> > > = > > Benjamin Kaduk has entered the following ballot position = for

> > > = > > draft-ietf-payload-tsvcis-03: Discuss

> > > = > >

> > > = > > When responding, please keep the subject line intact and reply =

> > > = > > to all email addresses included in the To and CC lines. (Feel =

> > > = > > free to cut this introductory paragraph, = however.)

> > > = > >

> > > = > >

> > > = > > Please refer to

> > > = > > https:= //www.ietf.org/iesg/statement/discuss-criteria.html

=

> > > = > > for more information about IESG DISCUSS and COMMENT = positions.

> > > = > >

> > > = > >

> > > = > > The document, along with other ballot positions, can be found = here:

> > > = > > http= s://datatracker.ietf.org/doc/draft-ietf-payload-tsvcis/=

> > > = > >

> > > = > >

> > > = > >

> > > = > > = --------------------------------------------------------------

> > > = > > --

> > > = > > ----

> > > = > > --

> > > = > > DISCUSS:

> > > = > > = --------------------------------------------------------------

> > > = > > --

> > > = > > ----

> > > = > > --

> > > = > >

> > > = > > I support Magnus' point about the time-ordering of adjacent =

> > > = > > frames in a

> > > = packet.

> > > = > >

> > > = > > Additionally, I am not sure that there's quite enough here to =

> > > = > > be

> > > = interoperably implementable.  Specifically, we seem to be lacking =

> > > = a description of how an encoder or decoder knows which TSVCIS =

> > > = parameters, and in what order, to byte-pack or unpack, = respectively.

> > > = One might surmise that there is a canonical listing in [TSVCIS], =

> > > = but this document does not say that, and furthermore [TSVCIS] is only = listed as an informative reference.

> > > = (I couldn't get my hands on my copy, at least on short notice.)  =

> > > = If we limited ourselves to treating the TSVCIS parameters as an =

> > > = entirely opaque blob (codec, convey these N octets to the peer =

> > > = with the appropriate one- or two-byte trailer for payload type =

> > > = identification and framing), that would be interoperably =

> > > = implementable, since the black-box bits are up to some other codec to = interpret.

> > > = > >

> > > = > > In a similar vein, we mention but do not completely specify =

> > > = > > the

> > > = potential for using CODB as an end-to-end framing bit, in = Section

> > > = 3.1 (see Comment), which is not interoperably implementable without = further details.

> > > = > >

> > > = > >

> > > = > > = --------------------------------------------------------------

> > > = > > --

> > > = > > ----

> > > = > > --

> > > = > > COMMENT:

> > > = > > = --------------------------------------------------------------

> > > = > > --

> > > = > > ----

> > > = > > --

> > > = > >

> > > = > > Where is [TSVCIS] available?

> > > = > >

> > > = > > Is [NRLVDR] the same as

> > > = > > https://ap= ps.dtic.mil/dtic/tr/fulltext/u2/a588068.pdf ?  A URL =

> > > = > > in the

> > > = references would be helpful.

> > > = > >

> > > = > > Is additional TSVCIS data only present after 2400bps MELPe and =

> > > = > > the first

> > > = thing to get dropped under bandwidth pressure?  The abstract and =

> > > = introduction imply this by calling out MELPe 2400 bps speech =

> > > = parameters explicitly, but Section 3 says that TSVCIS augments =

> > > = standard 600, 1200, and

> > > = 2400 bps MELP frames.

> > > = > >

> > > = > > It's helpful that Section 3.3 gives some general guidance for =

> > > = > > decoding

> > > = this payload type ("[t]he way to determine the number of =

> > > = TSVCIS/MELPe frames is to identify each frame type and length"), =

> > > = but I think some generic considerations would be very helpful to =

> > > = the reader much earlier, along the lines of "MELPe and TSVCIS data =

> > > = payloads are decoded from the end, using the CODA and CODB (and, =

> > > = if necessary, CODC and others) bits to determine the type of = payload.

> > > = For MELPe payloads the type also indicates the payload length, =

> > > = whereas for TSVCIS data an additional length field is present, in =

> > > = one of two possible formats.  A TSVCIS coder frame consists of a =

> > > = MELPe data payload followed by zero or one TSVCIS data payload; =

> > > = after the TSVCIS payload's presence/length is determined, then the =

> > > = preceding MELPe payload can be determined and decoded.  Per =

> > > = Section 3.3, multiple TSVCIS frames can be present in a single RTP = packet."

> > > = This (or something like it) would also serve to clarify the role of the = COD* bits, which is otherwise only implicitly = introduced.

> > > = > >

> > > = > > Section 1.1

> > > = > >

> > > = > > RFC 2736 is BCP 36 (but it's updated by RFC 8088 which is for =

> > > = > > some

> > > = reason an Informational document and not part of BCP = 36?!).

> > > = > >

> > > = > > Section 2

> > > = > >

> > > = > >    In addition to the augmented speech data, = the TSVCIS specification

> > > = > >    identifies which speech coder and framing = bits are to be encrypted,

> > > = > >    and how they are protected by forward error = correction (FEC)

> > > = > >    techniques (using block codes).  At the = RTP transport layer, only the

> > > = > >    speech coder related bits need to be = considered and are conveyed in

> > > = > >    unencrypted form.  In most IP-based = network deployments,

> > > = > > standard

> > > = > >

> > > = > > Am I reading this correctly that this text is just summarizing =

> > > = > > what's in

> > > = the TSVCIS spec in terms of what needs to be in unencrypted form, =

> > > = so the "only the speech coder related bits[...]" is not new =

> > > = information from this document?  I'm not sure I agree with the =

> > > = conclusion, regardless -- won't the

> > > = (MELPe) speech coder bits be enough to convey the semantic content =

> > > = of the audio stream, something that one might desire to keep = confidential?

> > > = > >

> > > = > >    link encryption methods (SRTP, VPNs, FIPS = 140 link encryptors or Type

> > > = > >    1 Ethernet encryptors) would be used to = secure the RTP speech

> > > = > >    contents.  Further, it is desirable to = support the highest voice

> > > = > >    quality between endpoints which is only = possible without the overhead

> > > = > >    of FEC.

> > > = > >

> > > = > > I think I'm missing a step in how this conclusion was = reached.

> > > = > >

> > > = > >    TSVCIS will be characterized.  = Depending on the bandwidth available

> > > = > >    (and FEC requirements), a varying number of = TSVCIS specific speech

> > > = > >    coder parameters need to be = transported.  These are first byte-packed

> > > = > >    and then conveyed from encoder to = decoder.

> > > = > >

> > > = > > Per the Discuss point, how do I know which parameters need to =

> > > = > > be

> > > = transported, and in what order?

> > > = > >

> > > = > >    Byte packing of TSVCIS speech data into = packed parameters is

> > > = > >    processed as per the following = example:

> > > = > >

> > > = > >       Three-bit field: bits A, = B, and C (A is MSB, C is LSB)

> > > = > >       Five-bit field: bits D, E, = F, G, and H (D is MSB, H is

> > > = > > LSB)

> > > = > >

> > > = > = >            = MSB           &nbs= p;            = ;            =           = LSB

> > > = > = >           &nb= sp; 0      1      = 2      3      = 4      5      = 6      7

> > > = > >         = +------+------+------+------+------+------+------+------+

> > > = > >         |   = H  |   G  |   F  |   = E  |   D  |   C  |   = B  |   A  |

> > > = > >         =

> > > = > > = +------+------+------+------+------+------+------+------+

> > > = > >

> > > = > >    This packing method places the three-bit = field "first" in the lowest

> > > = > >    bits followed by the next five-bit = field.  Parameters may be split

> > > = > >    between octets with the most significant = bits in the earlier octet.

> > > = > >    Any unfilled bits in the last octet MUST be = filled with zero.

> > > = > >

> > > = > > I agree with Adam that this is very unclear.  A is the = MSB of

> > > = > > the

> > > = three-bit field but the LSB of the octet overall?

> > > = > > We probably need an example of splitting a parameter across =

> > > = > > octets as

> > > = well, to get the bit ordering right.

> > > = > >

> > > = > > Section 3.1

> > > = > >

> > > = > >    It should be noted that CODB for both the = 2400 and 600 bps modes MAY

> > > = > >    deviate from the values in Table 1 when bit = 55 is used as an end-to-

> > > = > >    end framing bit.  Frame decoding would = remain distinct as

> > > = > > CODA being

> > > = > >

> > > = > > Where is the use of CODB as an end-to-end framing bit = defined? 

> > > = > > If we're

> > > = going to provide neither a complete description of how to do it =

> > > = nor a reference to a better description, we probably shouldn't mention = it at all.

> > > = > >

> > > = > > Section 3.2

> > > = > >

> > > = > >    RTP packet.  The packed parameters are = counted in octets (TC).  In

> > > = > >    the preferred placement, shown in Figure 6, = a single trailing octet

> > > = > >    SHALL be appended to include a two-bit rate = code, CODA and

> > > = > > CODB,

> > > = > >

> > > = > > I'd consider saying something about this being the preferred =

> > > = > > format

> > > = > > ("placement") due to its shorter length than the = alternative,

> > > = > > and say

> > > = that it "SHOULD be used for TSVCIS payloads with TC less than or =

> > > = equal to 77 octetes".

> > > = > >

> > > = > > Section 3.3

> > > = > >

> > > = > > When a longer packetization interval is used, is that =

> > > = > > indicated by

> > > = signaling or RTP timestamps or otherwise?

> > > = > >

> > > = > >    TSVCIS coder frames in a single RTP packet = MAY be of different coder

> > > = > >    bitrates.  With the exception for the = variable length TSVCIS

> > > = > >    parameter frames, the coder rate bits in the = trailing byte identify

> > > = > >    the contents and length as per Table = 1.

> > > = > >

> > > = > > Maybe also note that the penultimate octet gives the length = there?

> > > = > >

> > > = > >    Information describing the number of frames = contained in an RTP

> > > = > >    packet is not transmitted as part of the RTP = payload.  The way to

> > > = > >    determine the number of TSVCIS/MELPe frames = is to identify each frame

> > > = > >    type and length thereby counting the total = number of octets within

> > > = > >    the RTP packet.

> > > = > >

> > > = > > terminology nit: if a frame is the combination of MELPe and =

> > > = > > TSVCIS

> > > = payload data units then there are two layres of decoding to get a =

> > > = length for the frame, since we have to get the TSVCIS length and then = the MELPe length.

> > > = > >

> > > = > > Section 4.2

> > > = > >

> > > = > >    Parameter "ptime" cannot be used = for the purpose of

> > > = > > specifying the

> > > = > >

> > > = > > nit: missing article ("The = parameter")

> > > = > >

> > > = > >    will be impossible to distinguish which mode = is about to be used

> > > = > >    (e.g., when ptime=3D68, it would be = impossible to distinguish if the

> > > = > >    packet is carrying one frame of 67.5 ms or = three frames of 22.5 ms).

> > > = > >

> > > = > > So how is the operating mode determined, = then?

> > > = > > (I think this is the same question I asked = above)

> > > = > >

> > > = > > Section 4.4

> > > = > >

> > > = > >    For example, if offerer bitrates are = "2400,600" and answer bitrates

> > > = > >    are "600,2400", the initial = bitrate is 600.  If other bitrates are

> > > = > >    provided by the answerer, any common bitrate = between the offer and

> > > = > >    answer MAY be used at any time in the = future.  Activation of these

> > > = > >    other common bitrates is beyond the scope of = this document.

> > > = > >

> > > = > > It seems important to specify whether this requires a new O/A =

> > > = > > exchange

> > > = or can be done "spontaneously" by just encoding different = frame types.

> > > = > > (It seems like the latter is possible, on first glance, and =

> > > = > > this is implied by Section 3.3's discussion of mixing them in =

> > > = > > a single

> > > = > > packet.)

> > > = > >

> > > = > > Section 5

> > > = > >

> > > = > > Please expand PLC at first use (not second).

> > > = > >

> > > = > > Section 6

> > > = > >

> > > = > > I don't understand the PLC usage.  Is the idea that a =

> > > = > > receiver, on

> > > = seeing an SSRC gap, constructs fictitious PLC frames to "fill the = gap"

> > > = > > and passes the resulting stream to the = decoder?

> > > = > >

> > > = > > Section 8

> > > = > >

> > > = > >    and important considerations in = [RFC7201].  Applications SHOULD use

> > > = > >    one or more appropriate strong security = mechanisms.  The rest of this

> > > = > >    section discusses the security-impacting = properties of the payload

> > > = > >    format itself.

> > > = > >

> > > = > > I thought we described TSVCIS itself (much earlier in = the

> > > = > > document) as

> > > = requiring encryption for some data; wouldn't that translate to a = "MUST"

> > > = > > here and not a "SHOULD"?

> > > = > >

> > > = > >

> > > = > >

> > = >

> <<...>>

------=_NextPart_001_002D_01D60D9B.9E56D0F0-- ------=_NextPart_000_002C_01D60D9B.9E56D0F0 Content-Type: text/plain; name="changes_04_05.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="changes_04_05.txt" Section 2 (first sentence in last paragraph) - Clarification for octet count (was) In order to accommodate a varying amount of TSVCIS augmented speech data, it is only necessary to specify the number of octets containing the packed TSVCIS parameters. The encoding to do so is presented in Section 3.2. TSVCIS specifically uses the NRL VDR in two configurations using 15 and 35 packed octet parameters [TSVCIS]. (now) In order to accommodate a varying amount of TSVCIS augmented speech data, an octect count specifies the number of octets representing the packed TSVCIS parameters. The encoding to do so is presented in Section 3.2. TSVCIS specifically uses the NRL VDR in two configurations using a fixed set of 15 and 35 packed octet parameters in a fixed order [TSVCIS]. Section 3.1 (first sentence in last paragraph) - Clarification for CODA, CODB (was) It should be noted that CODB for MELPe 600 bps mode MAY deviate from the value in Table 1 when bit 55 is used as an end-to-end framing bit. (now) It should be noted that CODB for MELPe 600 bps mode MAY deviate from the value in Table 1 when bit 55 is used as an alternating 1/0 end-to-end framing bit. ------=_NextPart_000_002C_01D60D9B.9E56D0F0-- From nobody Thu Apr 16 22:29:52 2020 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AD73A11A2; Thu, 9 Apr 2020 15:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.101 X-Spam-Level: *** X-Spam-Status: No, score=3.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 wTFUyT8S1ktV; Thu, 9 Apr 2020 15:50:42 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 5F0AC3A11C4; Thu, 9 Apr 2020 15:50:31 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 039MoH0c029093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Apr 2020 18:50:19 -0400 Date: Thu, 9 Apr 2020 15:50:16 -0700 From: Benjamin Kaduk To: victor.demjanenko@vocal.com Cc: "'Barry Leiba'" , avtcore-chairs@ietf.org, "'Ali Begen'" , "'IETF discussion list'" , "'IETF SecDir'" , avt@ietf.org, "'Roni Even (A)'" , "'The IESG'" , "'Dave Satterlee (Vocal)'" , draft-ietf-payload-tsvcis@ietf.org, "'Catherine Meadows'" , draft-ietf-payload-tsvcis.all@ietf.org Message-ID: <20200409225016.GP88064@kduck.mit.edu> References: <034a01d58a73$f4d3a1c0$de7ae540$@vocal.com> <037e01d58a92$72287510$56795f30$@vocal.com> <20191101001153.GQ88302@kduck.mit.edu> <06e101d59f15$ee937b30$cbba7190$@vocal.com> <20191125064606.GL32847@mit.edu> <00c601d5e339$965ebd90$c31c38b0$@vocal.com> <20200214194321.GF43385@kduck.mit.edu> <002b01d60dbd$25675f80$70361e80$@vocal.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <002b01d60dbd$25675f80$70361e80$@vocal.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: X-Mailman-Approved-At: Thu, 16 Apr 2020 22:29:36 -0700 Subject: Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 22:50:47 -0000 Hi Victor, On Wed, Apr 08, 2020 at 11:48:26AM -0400, victor.demjanenko@vocal.com wrote: > Hi Ben, > > With this social distancing situation, I'm finally catching up on open items myself. I have made the changes as we have discussed and incorporated your suggestions. I believe the changes are fully contained in the two paragraphs below: > > Section 2 (last paragraph) - Clarification for octet count > > (was) > In order to accommodate a varying amount of TSVCIS augmented speech > data, it is only necessary to specify the number of octets > containing the packed TSVCIS parameters. The encoding to do so is > presented in Section 3.2. TSVCIS specifically uses the NRL VDR in two > configurations using 15 and 35 packed octet parameters [TSVCIS]. > > (now) > In order to accommodate a varying amount of TSVCIS augmented speech > data, an octet count specifies the number of octets representing > the packed TSVCIS parameters. The encoding to do so is presented in > Section 3.2. TSVCIS specifically uses the NRL VDR in two > configurations using a fixed set of 15 and 35 packed octet > parameters in a standardized order [TSVCIS]. > > > Section 3.1 (first sentence in last paragraph) - Clarification for CODA, CODB > > (was) > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > the value in Table 1 when bit 55 is used as an end-to-end framing bit. > > (now) > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > the value in Table 1 when bit 55 is used as an alternating 1/0 > end-to-end framing bit. > > Ben, I believe this addresses your comments and requests for clarifications as per our email discussion chain below. I also believe that :) > Thanks for you comments and with your concurrence (and my home computer's cooperation), I will post a new draft hopefully acceptable for final approval. Okay, I'll keep an eye out. > Regards to all and stay on the good side of Darwin. You, too! (And that phrasing brought a smile to my face, which I appreciate especially in these trying times.) Thanks, Ben > > > -----Original Message----- > From: Benjamin Kaduk > Sent: Friday, February 14, 2020 2:43 PM > To: victor.demjanenko@vocal.com; 'Barry Leiba' > Cc: 'Roni Even (A)' ; 'The IESG' ; 'Catherine Meadows' ; 'IETF SecDir' ; draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' ; avtcore-chairs@ietf.org; avt@ietf.org; 'Dave Satterlee (Vocal)' ; 'IETF discussion list' ; draft-ietf-payload-tsvcis.all@ietf.org > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > Hi Barry, > > As Victor notes, this one was/is waiting on me; he did reply (offlist) on > 15 January but I seem to have missed it amid a deluge of other mail that arrived at that time. Thanks for the reminder, and thanks Victor for re-sending the comments. > (inline) > > On Fri, Feb 14, 2020 at 08:20:54AM -0500, victor.demjanenko@vocal.com wrote: > > HI Barry, > > > > Thanks for recalling this was still outstanding. I had emailed Ben just after the holidays and did not realize we had no response. The below is what we suggested to Ben to address concerns he raised. > > > > -------------------- > > Hi Ben, > > > > Hope your holidays were good. Our were both good and busy. Deliveries for two NASA projects and the holidays kept us from responding sooner. But we do want to get this draft completed. > > > > With your permission, I’d like to address your comments directly, resolve what changes we should make and then publish a new version with a summary of our out-of-band discussions. We don’t have a lot of experience with drafting such documents and would like to know exactly what is needed to make this draft acceptable. > > > > I believe there are two comments/issues to address: > > > > 1) CODA, CODB > > > > Your comment ends by stating: “(Or, of course, the use of CODB as an alternating 1/0 bit as the framing usage could be documented instead.)” We can do this as follows: > > > > (original) > > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > > the value in Table 1 when bit 55 is used as an end-to-end framing > > bit. Frame decoding would remain distinct as CODA being zero on its > > own would indicate a 7-byte frame for either 2400 or 600 bps rate and > > the use of 600 bps speech coding could be deduced from the RTP > > timestamp (and anticipated by the SDP negotiations). > > > > (adding “alternating 1/0”) > > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > > the value in Table 1 when bit 55 is used as an alternating 1/0 end-to-end framing > > bit. Frame decoding would remain distinct as CODA being zero on its > > own would indicate a 7-byte frame for either 2400 or 600 bps rate and > > the use of 600 bps speech coding could be deduced from the RTP > > timestamp (and anticipated by the SDP negotiations). > > > > I think this change would be sufficient to address your concern about what to expect for CODB. > > This looks like the minimal sufficient change, yes. (I use "minimal" > because I would say more if I was writing it, but I don't think I can insist that you write it the way I would -- it's your document after all!) > > > 2. Packing and unpacking > > > > You are correct that I am trying to vaguely describe a middle layer shim that is neither RTP nor speech coder. So it definitely does need to be clear. The vagueness comes from the speech coder description being a FOUO document. Its now unclassified so I can potentially say more (and I did make some enhancements of the parameter description already). > > > > So I am trying to understand exactly what you think is vague in our current description: > > > > TSVCIS augmented speech data is derived from the signal processing > > and data already performed by the MELPe speech coder. For the > > purposes of this specification, only the general parameter nature of > > TSVCIS will be characterized. Depending on the bandwidth available > > (and FEC requirements), a varying number of TSVCIS-specific speech > > coder parameters need to be transported. These are first byte-packed > > and then conveyed from encoder to decoder. > > > > Byte packing of TSVCIS speech data into packed parameters is > > processed as per the following example: > > > > Three-bit field: bits A, B, and C (A is MSB, C is LSB) > > Five-bit field: bits D, E, F, G, and H (D is MSB, H is LSB) > > > > MSB LSB > > 0 1 2 3 4 5 6 7 > > +------+------+------+------+------+------+------+------+ > > | H | G | F | E | D | C | B | A | > > +------+------+------+------+------+------+------+------+ > > > > This packing method places the three-bit field "first" in the lowest > > bits followed by the next five-bit field. Parameters may be split > > between octets with the most significant bits in the earlier octet. > > Any unfilled bits in the last octet MUST be filled with zero. > > [not actually relevant to the Discuss part, but if there is always exactly one 3-bit parameter and one 5-bit parameter, then this text allowing splitting across octets will never be used and is potentially confusing to mention.] > > > In order to accommodate a varying amount of TSVCIS augmented speech > > data, it is only necessary to specify the number of octets containing > > the packed TSVCIS parameters. The encoding to do so is presented > > in > > I think the "only necessary to specify the number of octets" is the key stumbling point, for me -- I need to know the number of octets as well as the order of the parameters within the list, which is more information than just the number of octets. > > > Section 3.2. TSVCIS specifically uses the NRL VDR in two > > configurations using 15 and 35 packed octet parameters [TSVCIS]. > > I think I failed to internalize the "two configurations using 15 and 35 packed octet parameters" the first time I read the document, as this does help give the reader a clue that [TSVCIS] gives a good picture of what parameters go where. So it seems like we could easily append to that, for "using a fixed set of 15 and 35 packed octet parameters in a fixed order [TSVCIS]" and that would resolve my concerns. > > > The speech coder description of the parameters is the following: > > > > > > > > So the three bit pitch is first (bits 56 to 58), followed by a five bit amplitude (bits 59 to 63) and then an array of spectral components, each 8-bit wide (starting at bit 64). > > [And maybe TSVCIS specifes that the spectral components are derived from some fundamental harmonic decomposition that naturally quantizes to a number-of-parameters/accuracy tradeoff with a natural order. If so, we could also rely on that instead of my proposed change above; let me know if you want to explore that path further.] > > > Based on this information, I’m not sure what we should add to our > > draft to make the description of packing/unpacking clearer. Can you > > make any suggestions or does this table help you with what you did not > > know? (I don’t think I should put this table into the draft RFC > > however.) > > Hopefully the above helps to clarify. > > Thanks, and sorry for the delay. > > -Ben > > > Thanks for your attention and comments. > > > > Victor & Dave > > > > > > > > -----Original Message----- > > From: Barry Leiba > > Sent: Friday, February 14, 2020 7:38 AM > > To: Benjamin Kaduk > > Cc: victor.demjanenko@vocal.com; Roni Even (A) ; > > The IESG ; Catherine Meadows > > ; IETF SecDir ; > > draft-ietf-payload-tsvcis@ietf.org; Ali Begen > > ; avtcore-chairs@ietf.org; avt@ietf.org; > > Dave Satterlee (Vocal) ; IETF discussion > > list ; draft-ietf-payload-tsvcis.all@ietf.orgygv > > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: > > (with DISCUSS and COMMENT) > > > > This is still outstanding, since November. Victor, where are we on this one? > > > > Barry > > > > On Mon, Nov 25, 2019 at 1:46 AM Benjamin Kaduk wrote: > > > > > > Hi Victor, > > > > > > On Tue, Nov 19, 2019 at 03:14:21PM -0500, victor.demjanenko@vocal.com wrote: > > > > Hi Ben, > > > > > > > > Sorry I overlooked sending you a response. I would like to > > > > address the two concerns you have by explaining what the speech coders are doing. > > > > > > Thanks for the extra clarifications. To supply one of my own: I'm > > > not concerned that the protocol doesn't work as implemented, but > > > just want to make sure that the document includes enough information > > > to admit new implementations without guesswork. That is to say, > > > "either tell me how to do it or tell me where to look that tells me how to do it". > > > > > > > WRT to 600 bps MELP, there is one TSVCIS mode that uses one bit > > > > beyond the 54-bit frame for MELP 600 as a frame sync which alternates between frames. > > > > With two or more MELP 600bps frames in one RTP packet, if any > > > > frame indicates 600 bps by CODA being 0 and CODB being 1, then we > > > > know the stream is 600bps. If there is a single frame in an RTP > > > > packet, you can still deduce this by looking at every other RTP > > > > packet (every other MELP 600bps > > > > frame) and by the timestamp advance. Most likely the two ends > > > > would negotiate 600 bps in SDP anyways so there really should not > > > > be a problem. I know it's not pretty but its workable. I hope > > > > this explanation helps you with the concerns for this issue. > > > > > > In this case, the use as an "end-to-end framing bit" (i.e., the > > > alternating behavior you describe above) is not explicitly stated; > > > one might imagine a scheme where the framing usage is to have the > > > bit cycle through 1, 1, 0, and 0, or some other scheme. I'd suggest > > > to note in the document that if any instance of (CODA, CODB) == (0, > > > 1) is observed, then the 600bps mode is in use. It might also be > > > helpful to include the observation that two successive MELPe > > > payloads with CODA == CODB == 0 indicates the 2400bps mode (and that > > > seeing them in a single RTP packet is decisive, whereas additional > > > information about packet non-loss would be needed in the > > > one-MELPe-frame-per-RTP-packet case), but that would be a fair bit > > > of additional text and might be diminishing returns. (Or, of > > > course, the use of CODB as an alternating 1/0 bit as the framing > > > usage could be documented > > > instead.) > > > > > > > As for the TSVCIS parameter packing/unpacking, this is really > > > > simple. There is exactly on three bit parameter, exactly one five > > > > bit parameter and a variable number of eight bit parameters. In > > > > our view, the speech coder itself (or a wrapper for it) is > > > > responsible for preparing the block of octets. RTP then just > > > > transports it. On receive, the complementary wrapper reverses the packing operation. > > > > I hope this clarifies and explains the simplicity. > > > > > > That's exactly what I expected to happen; however, it's not what I > > > believe the current text of the document is describing. > > > Specifically, I think that the current text implies that the > > > "preparing the block of octets" and "complementary wrapper reverses > > > the packing operation" are supposed to be part of the RTP payload > > > format that this document describes, but this document does not have > > > enough information to actually perform those operations reversibly. > > > If the packing is to be done in the speech coder, then this document > > > doesn't need to talk about the packing at all (e.g., at the end of > > > Section 2); if we need to keep the packing/wrapper in this document > > > then we need to indicate that there's a defined priority order for > > > the (8-octet) TSVCIS parameters in the TSVCIS references, to allow the packing/unpacking to be deterministic. > > > > > > Thanks, > > > > > > Ben > > > > > > > > > > > -----Original Message----- > > > > From: Benjamin Kaduk > > > > Sent: Thursday, October 31, 2019 8:12 PM > > > > To: Barry Leiba > > > > Cc: victor.demjanenko@vocal.com; Roni Even (A) > > > > ; The IESG ; Catherine > > > > Meadows ; IETF SecDir > > > > ; draft-ietf-payload-tsvcis@ietf.org; Ali Begen > > > > ; avtcore-chairs@ietf.org; > > > > avt@ietf.org; Dave Satterlee (Vocal) ; > > > > IETF discussion list ; > > > > draft-ietf-payload-tsvcis.all@ietf.org > > > > Subject: Re: Benjamin Kaduk's Discuss on > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > I don't think so, unfortunately. > > > > > > > > I do see the clarification about CODB's potential for deviation > > > > from Table 1, that only the 600 bps MELPe is allowed to deviate, > > > > and that CODA gets us to "it's one of 2400 or 600 bps" and the RTP > > > > timestamp disambiguates that > > > > 600 bps is in use. But, it seems that this means that the > > > > recipient in general should not rely on CODB to differentiate 600 > > > > from 2400 bps, and instead is more robustly implemented by > > > > *always* using the RTP timestamp to detect 600 bps, since that > > > > will always work and CODB will sometimes not work under conditions > > > > not fully specified here. So, if we are unwilling or unable to > > > > clarify what those conditions are (e.g., whether at a minimum > > > > mutual agreement is required), then I think we need to describe > > > > this procedure of consulting the RTP timestamp as the default behavior and avoid giving the impression that CODB should be used to do so. > > > > > > > > Additionally, I don't see anything to address my concern about > > > > TSVCIS parameter decoding. To be clear, the procedure I see this > > > > document describing is that: > > > > - TSVCIS gives parameters (and their lengths in bits) to the codec > > > > described in this document > > > > - this document specifies how to densely encode those parameters into a > > > > byetstream > > > > - RTP transmits that encoded bytestream to the peer > > > > - the codec specified by this is responsible for turning that encoded > > > > bystream back into a list of TSVCIS parameters (and their length > > > > in bits) > > > > > > > > I don't see how that last step is attainable with only the > > > > information provided by this document. I *assume* that one of the > > > > TSVCIS specifications has a canonical (ordered) listing of > > > > parameters, and that the list of parmeters given to this codec in > > > > the first step will always be an initial prefix of that list, but > > > > that's just me guessing at how to make sense of the stated > > > > procedure given insufficient information. I don't think it's > > > > appropriate to make the reader of an RFC guess at what to do; we > > > > need to either say how to do it or give a pointer to an external reference that does. > > > > > > > > -Ben > > > > > > > > On Tue, Oct 29, 2019 at 02:26:09PM -0400, Barry Leiba wrote: > > > > > Ben, does the -04 version address everything? > > > > > > > > > > Barry > > > > > > > > > > On Thu, Oct 24, 2019 at 1:42 PM wrote: > > > > > > > > > > > > I forgot to address security comments in one email. The changes are: > > > > > > > > > > > > Section 8, second paragraph - Suggested edit by reviewer > > > > > > > > > > > > (was) > > > > > > This RTP payload format and the TSVCIS decoder do not exhibit any > > > > > > significant non-uniformity in the receiver-side computational > > > > > > complexity for packet processing and thus are unlikely to pose a > > > > > > denial-of-service threat due to the receipt of pathological data. > > > > > > Additionally, the RTP payload format does not contain any active > > > > > > content. > > > > > > > > > > > > (now) > > > > > > This RTP payload format and the TSVCIS decoder, to the best of our > > > > > > knowledge, do not exhibit any significant non-uniformity in the > > > > > > receiver-side computational complexity for packet processing and thus > > > > > > are unlikely to pose a denial-of-service threat due to the receipt of > > > > > > pathological data. Additionally, the RTP payload format does not > > > > > > contain any active content. > > > > > > > > > > > > > > > > > > Section 8, third paragraph - Suggested edit by reviewer > > > > > > > > > > > > (was) > > > > > > Please see the security considerations discussed in [RFC6562] > > > > > > regarding VAD and its effect on bitrates. > > > > > > > > > > > > (now) > > > > > > Please see the security considerations discussed in [RFC6562] > > > > > > regarding Voice Activity Detect (VAD) and its effect on bitrates. > > > > > > > > > > > > Victor > > > > > > > > > > > > -----Original Message----- > > > > > > From: victor.demjanenko@vocal.com > > > > > > > > > > > > Sent: Thursday, October 24, 2019 10:05 AM > > > > > > To: 'Roni Even (A)' ; 'Benjamin Kaduk' > > > > > > ; 'The IESG' > > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' > > > > > > ; avtcore-chairs@ietf.org; > > > > > > avt@ietf.org; 'Dave Satterlee (Vocal)' > > > > > > > > > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > > > > > Hi Everyone, > > > > > > > > > > > > First we want to thank everyone for their review and comments > > > > > > for this > > > > draft RFC. We believe we reviewed all the comments and > > > > suggestions and incorporated them adequately in the next draft > > > > (04). We'd like to send out this list of exact changes in case > > > > anyone has additional comments or thinks the clarifications are > > > > inadequate. We would be most happy to address concerns before publishing draft 04 tomorrow. > > > > > > > > > > > > With so many emails from a half dozen or more reviewers, we > > > > > > apologize > > > > that we cannot address each sender individually. We hope this > > > > detail is sufficient for everyone. > > > > > > > > > > > > Again, many thanks to all. > > > > > > > > > > > > Victor & Dave > > > > > > > > > > > > -------------------------------------------------------------- > > > > > > -- > > > > > > ---- > > > > > > -------------------------- > > > > > > > > > > > > Section 1.1 - Suggested reference to RFC 8088 added. > > > > > > > > > > > > (was) > > > > > > Best current practices for writing an RTP payload format > > > > > > specification were followed [RFC2736]. > > > > > > > > > > > > (now) > > > > > > Best current practices for writing an RTP payload format > > > > > > specification were followed [RFC2736] [RFC8088]. > > > > > > > > > > > > > > > > > > Section 2, paragraphs 3 and 4 - Suggested edits by reviewers > > > > > > > > > > > > (was) > > > > > > In addition to the augmented speech data, the TSVCIS specification > > > > > > identifies which speech coder and framing bits are to be encrypted, > > > > > > and how they are protected by forward error correction (FEC) > > > > > > techniques (using block codes). At the RTP transport layer, only the > > > > > > speech coder related bits need to be considered and are conveyed in > > > > > > unencrypted form. In most IP-based network deployments, standard > > > > > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type > > > > > > 1 Ethernet encryptors) would be used to secure the RTP speech > > > > > > contents. Further, it is desirable to support the highest voice > > > > > > quality between endpoints which is only possible without the overhead > > > > > > of FEC. > > > > > > > > > > > > TSVCIS augmented speech data is derived from the signal processing > > > > > > and data already performed by the MELPe speech coder. For the > > > > > > purposes of this specification, only the general parameter nature of > > > > > > TSVCIS will be characterized. Depending on the bandwidth available > > > > > > (and FEC requirements), a varying number of TSVCIS specific speech > > > > > > coder parameters need to be transported. These are first byte-packed > > > > > > and then conveyed from encoder to decoder. > > > > > > > > > > > > (now) > > > > > > In addition to the augmented speech data, the TSVCIS specification > > > > > > identifies which speech coder and framing bits are to be encrypted, > > > > > > and how they are protected by forward error correction (FEC) > > > > > > techniques (using block codes). At the RTP transport layer, only the > > > > > > speech-coder-related bits need to be considered and are conveyed in > > > > > > unencrypted form. In most IP-based network deployments, standard > > > > > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type > > > > > > 1 Ethernet encryptors) would be used to secure the RTP speech > > > > > > contents. > > > > > > > > > > > > TSVCIS augmented speech data is derived from the signal processing > > > > > > and data already performed by the MELPe speech coder. For the > > > > > > purposes of this specification, only the general parameter nature of > > > > > > TSVCIS will be characterized. Depending on the bandwidth available > > > > > > (and FEC requirements), a varying number of TSVCIS-specific speech > > > > > > coder parameters need to be transported. These are first byte-packed > > > > > > and then conveyed from encoder to decoder. > > > > > > > > > > > > > > > > > > Section 3, last sentence paragraph 3 - Suggested edit by > > > > > > reviewer > > > > > > > > > > > > (was) > > > > > > When more than one codec data frame is > > > > > > present in a single RTP packet, the timestamp is, as always, that of > > > > > > the oldest data frame represented in the RTP packet. > > > > > > > > > > > > (now) > > > > > > When more than one codec data frame is > > > > > > present in a single RTP packet, the timestamp specified is that of > > > > > > the oldest data frame represented in the RTP packet. > > > > > > > > > > > > > > > > > > Section 3.1, last paragraph - Clarified permission for MELP > > > > > > 600 end-to-end framing bit > > > > > > > > > > > > (was) > > > > > > It should be noted that CODB for both the 2400 and 600 bps modes MAY > > > > > > deviate from the values in Table 1 when bit 55 is used as an end-to- > > > > > > end framing bit. Frame decoding would remain distinct as CODA being > > > > > > zero on its own would indicate a 7-byte frame for either rate and the > > > > > > use of 600 bps speech coding could be deduced from the RTP timestamp > > > > > > (and anticipated by the SDP negotiations). > > > > > > > > > > > > (now) > > > > > > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > > > > > > the value in Table 1 when bit 55 is used as an end-to-end framing > > > > > > bit. Frame decoding would remain distinct as CODA being zero on its > > > > > > own would indicate a 7-byte frame for either 2400 or 600 bps rate and > > > > > > the use of 600 bps speech coding could be deduced from the RTP > > > > > > timestamp (and anticipated by the SDP negotiations). > > > > > > > > > > > > > > > > > > Section 3.2, first paragraph - Clarifications requested by > > > > > > reviewers > > > > > > > > > > > > (was) > > > > > > The TSVCIS augmented speech data as packed parameters MUST be placed > > > > > > immediately after a corresponding MELPe 2400 bps payload in the same > > > > > > RTP packet. The packed parameters are counted in octets (TC). In > > > > > > the preferred placement, shown in Figure 6, a single trailing octet > > > > > > SHALL be appended to include a two-bit rate code, CODA and CODB, > > > > > > (both bits set to one) and a six-bit modified count (MTC). The > > > > > > special modified count value of all ones (representing a MTC value of > > > > > > 63) SHALL NOT be used for this format as it is used as the indicator > > > > > > for the alternate packing format shown next. In a standard > > > > > > implementation, the TSVCIS speech coder uses a minimum of 15 octets > > > > > > for parameters in octet packed form. The modified count (MTC) MUST > > > > > > be reduced by 15 from the full octet count (TC). Computed MTC = TC- > > > > > > 15. This accommodates a maximum of 77 parameter octets (maximum > > > > > > value of MTC is 62, 77 is the sum of 62+15). > > > > > > > > > > > > (now) > > > > > > The TSVCIS augmented speech data as packed parameters MUST be placed > > > > > > immediately after a corresponding MELPe 2400 bps payload in the same > > > > > > RTP packet. The packed parameters are counted in octets (TC). The > > > > > > preferred placement SHOULD be used for TSVCIS payloads with TC less > > > > > > than or equal to 77 octets, is shown in Figure 6. In the preferred > > > > > > placement, a single trailing octet SHALL be appended to include a > > > > > > two-bit rate code, CODA and CODB, (both bits set to one) and a six- > > > > > > bit modified count (MTC). The special modified count value of all > > > > > > ones (representing a MTC value of 63) SHALL NOT be used for this > > > > > > format as it is used as the indicator for the alternate packing > > > > > > format shown next. In a standard implementation, the TSVCIS speech > > > > > > coder uses a minimum of 15 octets for parameters in octet packed > > > > > > form. The modified count (MTC) MUST be reduced by 15 from the full > > > > > > octet count (TC). Computed MTC = TC-15. This accommodates a maximum > > > > > > of 77 parameter octets (maximum value of MTC is 62, 77 is the sum of > > > > > > 62+15). > > > > > > > > > > > > > > > > > > Section 3.3, first paragraph - Suggested edit by reviewer > > > > > > > > > > > > (was) > > > > > > A TSVCIS RTP packet consists of zero or more TSVCIS coder frames > > > > > > (each consisting of MELPe and TSVCIS coder data) followed by zero or > > > > > > one MELPe comfort noise frame. The presence of a comfort noise frame > > > > > > can be determined by its rate code bits in its last octet. > > > > > > > > > > > > (now) > > > > > > A TSVCIS RTP packet payload consists of zero or more consecutive > > > > > > TSVCIS coder frames (each consisting of MELPe 2400 and TSVCIS coder > > > > > > data), with the oldest frame first, followed by zero or one MELPe > > > > > > comfort noise frame. The presence of a comfort noise frame can be > > > > > > determined by its rate code bits in its last octet. > > > > > > > > > > > > > > > > > > Section 3.3, fourth paragraph - Clarification requested by > > > > > > reviewers > > > > > > > > > > > > (was) > > > > > > TSVCIS coder frames in a single RTP packet MAY be of different coder > > > > > > bitrates. With the exception for the variable length TSVCIS > > > > > > parameter frames, the coder rate bits in the trailing byte identify > > > > > > the contents and length as per Table 1. > > > > > > > > > > > > (now) > > > > > > TSVCIS coder frames in a single RTP packet MAY have varying TSVCIS > > > > > > parameter octet counts. Its packed parameter octet count (length) is > > > > > > indicated in the trailing byte(s). All MELPe frames in a single RTP > > > > > > packet MUST be of the same coder bitrate. For all MELPe coder > > > > > > frames, the coder rate bits in the trailing byte identify the > > > > > > contents and length as per Table 1. > > > > > > > > > > > > > > > > > > Section 4.1 - Editor note removed > > > > > > > > > > > > > > > > > > Section 4.1 - Change controller is now > > > > > > > > > > > > (now) > > > > > > Change controller: IETF, contact > > > > > > > > > > > > > > > > > > Section 5, first paragraph - Suggested edits by reviewers > > > > > > > > > > > > (was) > > > > > > A primary application of TSVCIS is for radio communications of voice > > > > > > conversations, and discontinuous transmissions are normal. When > > > > > > TSVCIS is used in an IP network, TSVCIS RTP packet transmissions may > > > > > > cease and resume frequently. RTP synchronization source (SSRC) > > > > > > sequence number gaps indicate lost packets to be filled by PLC, while > > > > > > abrupt loss of RTP packets indicates intended discontinuous > > > > > > transmissions. > > > > > > > > > > > > (now) > > > > > > A primary application of TSVCIS is for radio communications of voice > > > > > > conversations, and discontinuous transmissions are normal. When > > > > > > TSVCIS is used in an IP network, TSVCIS RTP packet transmissions may > > > > > > cease and resume frequently. RTP synchronization source (SSRC) > > > > > > sequence number gaps indicate lost packets to be filled by Packet > > > > > > Loss Concealment (PLC), while abrupt loss of RTP packets indicates > > > > > > intended discontinuous transmissions. Resumption of voice > > > > > > transmission SHOULD be indicated by the RTP marker bit (M) set to 1. > > > > > > > > > > > > > > > > > > Section 10 - Added reference > > > > > > > > > > > > (added) > > > > > > [RFC8088] Westerlund, M., "How to Write an RTP Payload Format", > > > > > > RFC 8088, DOI 10.17487/RFC8088, May 2017, > > > > > > . > > > > > > > > > > > > -------------------------------------------------------------- > > > > > > -- > > > > > > ---- > > > > > > ----------------------------- > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Roni Even (A) > > > > > > Sent: Sunday, October 6, 2019 2:09 AM > > > > > > To: victor.demjanenko@vocal.com; 'Benjamin Kaduk' > > > > > > ; 'The IESG' > > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' > > > > > > ; avtcore-chairs@ietf.org; > > > > > > avt@ietf.org; 'Dave Satterlee (Vocal)' > > > > > > > > > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > > > > > Hi, > > > > > > About the reference to TSVCIS. > > > > > > The RTP payload is about how to encapsulate the payload in an > > > > > > RTP > > > > packet. The objective is to define how an RTP stack can insert the > > > > tsvcis frames and extract the tsvcis frames from the RTP packet. > > > > Typically it is not required to understand the payload structure > > > > in order to be able to perform the encapsulation. > > > > > > This is why the reference to the payload is Informational and > > > > > > we did not require to have it publically available. If there > > > > > > is a need to understand the payload itself for the > > > > > > encapsulating than we need more information in the RTP payload > > > > > > specification and a publically available normative reference. > > > > > > I think this is not the case here > > > > > > > > > > > > Roni Even > > > > > > > > > > > > AVTCore co-chair (ex Payload) > > > > > > > > > > > > -----Original Message----- > > > > > > From: victor.demjanenko@vocal.com > > > > > > [mailto:victor.demjanenko@vocal.com] > > > > > > Sent: Saturday, October 05, 2019 12:18 AM > > > > > > To: 'Benjamin Kaduk'; 'The IESG' > > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen'; > > > > avtcore-chairs@ietf.org; avt@ietf.org; 'Victor Demjanenko, Ph.D.'; > > > > 'Dave Satterlee (Vocal)' > > > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > > > > > Everyone, > > > > > > > > > > > > Thanks for the comments. I think I mis-understood the > > > > > > ambiguity with > > > > respect to to changing rates within a RTP packet. That was not > > > > plan. An RTP packet must have MELP speech frames of the same rate. > > > > What is possible is that the amount of augmented TSVCIS speech > > > > data may vary from one speech frame to the next. This allows for > > > > a dynamic VDR as suggested by the NRL paper. So an RTP packet may > > > > have varying TSVCIS data but must always have MELPe 2400 data. > > > > > > > > > > > > Again backwards parsing is necessary but the timestamp > > > > > > uniformly > > > > increments 22.5msec per combined MELP/TSVCIS speech frame. > > > > > > > > > > > > The NRL is a good public reference on the VDR aspects. The > > > > > > actual > > > > TSVCIS spec we had was FOUO so we could not replicate its detail. > > > > (I believe a later spec is public or at least partially public. I > > > > am trying to get this.) The opaque data is pretty obvious with the TSVCIS spec in hand. > > > > > > > > > > > > We will address the issues/concerns raised next week. Other > > > > > > business > > > > had priority. > > > > > > > > > > > > Thank you and enjoy the weekend. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Victor & Dave > > > > > > > > > > > > -----Original Message----- > > > > > > From: Benjamin Kaduk via Datatracker > > > > > > Sent: Wednesday, October 2, 2019 10:40 PM > > > > > > To: The IESG > > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; Ali Begen > > > > > > ; avtcore-chairs@ietf.org; > > > > > > ali.begen@networked.media; avt@ietf.org > > > > > > Subject: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: > > > > > > (with DISCUSS and COMMENT) > > > > > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > > > draft-ietf-payload-tsvcis-03: Discuss > > > > > > > > > > > > When responding, please keep the subject line intact and reply > > > > > > to all email addresses included in the To and CC lines. (Feel > > > > > > free to cut this introductory paragraph, however.) > > > > > > > > > > > > > > > > > > Please refer to > > > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > > > https://datatracker.ietf.org/doc/draft-ietf-payload-tsvcis/ > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > > -- > > > > > > ---- > > > > > > -- > > > > > > DISCUSS: > > > > > > -------------------------------------------------------------- > > > > > > -- > > > > > > ---- > > > > > > -- > > > > > > > > > > > > I support Magnus' point about the time-ordering of adjacent > > > > > > frames in a > > > > packet. > > > > > > > > > > > > Additionally, I am not sure that there's quite enough here to > > > > > > be > > > > interoperably implementable. Specifically, we seem to be lacking > > > > a description of how an encoder or decoder knows which TSVCIS > > > > parameters, and in what order, to byte-pack or unpack, respectively. > > > > One might surmise that there is a canonical listing in [TSVCIS], > > > > but this document does not say that, and furthermore [TSVCIS] is only listed as an informative reference. > > > > (I couldn't get my hands on my copy, at least on short notice.) > > > > If we limited ourselves to treating the TSVCIS parameters as an > > > > entirely opaque blob (codec, convey these N octets to the peer > > > > with the appropriate one- or two-byte trailer for payload type > > > > identification and framing), that would be interoperably > > > > implementable, since the black-box bits are up to some other codec to interpret. > > > > > > > > > > > > In a similar vein, we mention but do not completely specify > > > > > > the > > > > potential for using CODB as an end-to-end framing bit, in Section > > > > 3.1 (see Comment), which is not interoperably implementable without further details. > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > > -- > > > > > > ---- > > > > > > -- > > > > > > COMMENT: > > > > > > -------------------------------------------------------------- > > > > > > -- > > > > > > ---- > > > > > > -- > > > > > > > > > > > > Where is [TSVCIS] available? > > > > > > > > > > > > Is [NRLVDR] the same as > > > > > > https://apps.dtic.mil/dtic/tr/fulltext/u2/a588068.pdf ? A URL > > > > > > in the > > > > references would be helpful. > > > > > > > > > > > > Is additional TSVCIS data only present after 2400bps MELPe and > > > > > > the first > > > > thing to get dropped under bandwidth pressure? The abstract and > > > > introduction imply this by calling out MELPe 2400 bps speech > > > > parameters explicitly, but Section 3 says that TSVCIS augments > > > > standard 600, 1200, and > > > > 2400 bps MELP frames. > > > > > > > > > > > > It's helpful that Section 3.3 gives some general guidance for > > > > > > decoding > > > > this payload type ("[t]he way to determine the number of > > > > TSVCIS/MELPe frames is to identify each frame type and length"), > > > > but I think some generic considerations would be very helpful to > > > > the reader much earlier, along the lines of "MELPe and TSVCIS data > > > > payloads are decoded from the end, using the CODA and CODB (and, > > > > if necessary, CODC and others) bits to determine the type of payload. > > > > For MELPe payloads the type also indicates the payload length, > > > > whereas for TSVCIS data an additional length field is present, in > > > > one of two possible formats. A TSVCIS coder frame consists of a > > > > MELPe data payload followed by zero or one TSVCIS data payload; > > > > after the TSVCIS payload's presence/length is determined, then the > > > > preceding MELPe payload can be determined and decoded. Per > > > > Section 3.3, multiple TSVCIS frames can be present in a single RTP packet." > > > > This (or something like it) would also serve to clarify the role of the COD* bits, which is otherwise only implicitly introduced. > > > > > > > > > > > > Section 1.1 > > > > > > > > > > > > RFC 2736 is BCP 36 (but it's updated by RFC 8088 which is for > > > > > > some > > > > reason an Informational document and not part of BCP 36?!). > > > > > > > > > > > > Section 2 > > > > > > > > > > > > In addition to the augmented speech data, the TSVCIS specification > > > > > > identifies which speech coder and framing bits are to be encrypted, > > > > > > and how they are protected by forward error correction (FEC) > > > > > > techniques (using block codes). At the RTP transport layer, only the > > > > > > speech coder related bits need to be considered and are conveyed in > > > > > > unencrypted form. In most IP-based network deployments, > > > > > > standard > > > > > > > > > > > > Am I reading this correctly that this text is just summarizing > > > > > > what's in > > > > the TSVCIS spec in terms of what needs to be in unencrypted form, > > > > so the "only the speech coder related bits[...]" is not new > > > > information from this document? I'm not sure I agree with the > > > > conclusion, regardless -- won't the > > > > (MELPe) speech coder bits be enough to convey the semantic content > > > > of the audio stream, something that one might desire to keep confidential? > > > > > > > > > > > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type > > > > > > 1 Ethernet encryptors) would be used to secure the RTP speech > > > > > > contents. Further, it is desirable to support the highest voice > > > > > > quality between endpoints which is only possible without the overhead > > > > > > of FEC. > > > > > > > > > > > > I think I'm missing a step in how this conclusion was reached. > > > > > > > > > > > > TSVCIS will be characterized. Depending on the bandwidth available > > > > > > (and FEC requirements), a varying number of TSVCIS specific speech > > > > > > coder parameters need to be transported. These are first byte-packed > > > > > > and then conveyed from encoder to decoder. > > > > > > > > > > > > Per the Discuss point, how do I know which parameters need to > > > > > > be > > > > transported, and in what order? > > > > > > > > > > > > Byte packing of TSVCIS speech data into packed parameters is > > > > > > processed as per the following example: > > > > > > > > > > > > Three-bit field: bits A, B, and C (A is MSB, C is LSB) > > > > > > Five-bit field: bits D, E, F, G, and H (D is MSB, H is > > > > > > LSB) > > > > > > > > > > > > MSB LSB > > > > > > 0 1 2 3 4 5 6 7 > > > > > > +------+------+------+------+------+------+------+------+ > > > > > > | H | G | F | E | D | C | B | A | > > > > > > > > > > > > +------+------+------+------+------+------+------+------+ > > > > > > > > > > > > This packing method places the three-bit field "first" in the lowest > > > > > > bits followed by the next five-bit field. Parameters may be split > > > > > > between octets with the most significant bits in the earlier octet. > > > > > > Any unfilled bits in the last octet MUST be filled with zero. > > > > > > > > > > > > I agree with Adam that this is very unclear. A is the MSB of > > > > > > the > > > > three-bit field but the LSB of the octet overall? > > > > > > We probably need an example of splitting a parameter across > > > > > > octets as > > > > well, to get the bit ordering right. > > > > > > > > > > > > Section 3.1 > > > > > > > > > > > > It should be noted that CODB for both the 2400 and 600 bps modes MAY > > > > > > deviate from the values in Table 1 when bit 55 is used as an end-to- > > > > > > end framing bit. Frame decoding would remain distinct as > > > > > > CODA being > > > > > > > > > > > > Where is the use of CODB as an end-to-end framing bit defined? > > > > > > If we're > > > > going to provide neither a complete description of how to do it > > > > nor a reference to a better description, we probably shouldn't mention it at all. > > > > > > > > > > > > Section 3.2 > > > > > > > > > > > > RTP packet. The packed parameters are counted in octets (TC). In > > > > > > the preferred placement, shown in Figure 6, a single trailing octet > > > > > > SHALL be appended to include a two-bit rate code, CODA and > > > > > > CODB, > > > > > > > > > > > > I'd consider saying something about this being the preferred > > > > > > format > > > > > > ("placement") due to its shorter length than the alternative, > > > > > > and say > > > > that it "SHOULD be used for TSVCIS payloads with TC less than or > > > > equal to 77 octetes". > > > > > > > > > > > > Section 3.3 > > > > > > > > > > > > When a longer packetization interval is used, is that > > > > > > indicated by > > > > signaling or RTP timestamps or otherwise? > > > > > > > > > > > > TSVCIS coder frames in a single RTP packet MAY be of different coder > > > > > > bitrates. With the exception for the variable length TSVCIS > > > > > > parameter frames, the coder rate bits in the trailing byte identify > > > > > > the contents and length as per Table 1. > > > > > > > > > > > > Maybe also note that the penultimate octet gives the length there? > > > > > > > > > > > > Information describing the number of frames contained in an RTP > > > > > > packet is not transmitted as part of the RTP payload. The way to > > > > > > determine the number of TSVCIS/MELPe frames is to identify each frame > > > > > > type and length thereby counting the total number of octets within > > > > > > the RTP packet. > > > > > > > > > > > > terminology nit: if a frame is the combination of MELPe and > > > > > > TSVCIS > > > > payload data units then there are two layres of decoding to get a > > > > length for the frame, since we have to get the TSVCIS length and then the MELPe length. > > > > > > > > > > > > Section 4.2 > > > > > > > > > > > > Parameter "ptime" cannot be used for the purpose of > > > > > > specifying the > > > > > > > > > > > > nit: missing article ("The parameter") > > > > > > > > > > > > will be impossible to distinguish which mode is about to be used > > > > > > (e.g., when ptime=68, it would be impossible to distinguish if the > > > > > > packet is carrying one frame of 67.5 ms or three frames of 22.5 ms). > > > > > > > > > > > > So how is the operating mode determined, then? > > > > > > (I think this is the same question I asked above) > > > > > > > > > > > > Section 4.4 > > > > > > > > > > > > For example, if offerer bitrates are "2400,600" and answer bitrates > > > > > > are "600,2400", the initial bitrate is 600. If other bitrates are > > > > > > provided by the answerer, any common bitrate between the offer and > > > > > > answer MAY be used at any time in the future. Activation of these > > > > > > other common bitrates is beyond the scope of this document. > > > > > > > > > > > > It seems important to specify whether this requires a new O/A > > > > > > exchange > > > > or can be done "spontaneously" by just encoding different frame types. > > > > > > (It seems like the latter is possible, on first glance, and > > > > > > this is implied by Section 3.3's discussion of mixing them in > > > > > > a single > > > > > > packet.) > > > > > > > > > > > > Section 5 > > > > > > > > > > > > Please expand PLC at first use (not second). > > > > > > > > > > > > Section 6 > > > > > > > > > > > > I don't understand the PLC usage. Is the idea that a > > > > > > receiver, on > > > > seeing an SSRC gap, constructs fictitious PLC frames to "fill the gap" > > > > > > and passes the resulting stream to the decoder? > > > > > > > > > > > > Section 8 > > > > > > > > > > > > and important considerations in [RFC7201]. Applications SHOULD use > > > > > > one or more appropriate strong security mechanisms. The rest of this > > > > > > section discusses the security-impacting properties of the payload > > > > > > format itself. > > > > > > > > > > > > I thought we described TSVCIS itself (much earlier in the > > > > > > document) as > > > > requiring encryption for some data; wouldn't that translate to a "MUST" > > > > > > here and not a "SHOULD"? > > > > > > > > > > > > > > > > > > > > > > > > > Section 2 (first sentence in last paragraph) - Clarification for octet count > > (was) > In order to accommodate a varying amount of TSVCIS augmented speech > data, it is only necessary to specify the number of octets > containing the packed TSVCIS parameters. The encoding to do so is > presented in Section 3.2. TSVCIS specifically uses the NRL VDR in two > configurations using 15 and 35 packed octet parameters [TSVCIS]. > > (now) > In order to accommodate a varying amount of TSVCIS augmented speech > data, an octect count specifies the number of octets representing > the packed TSVCIS parameters. The encoding to do so is presented in > Section 3.2. TSVCIS specifically uses the NRL VDR in two > configurations using a fixed set of 15 and 35 packed octet > parameters in a fixed order [TSVCIS]. > > > Section 3.1 (first sentence in last paragraph) - Clarification for CODA, CODB > > (was) > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > the value in Table 1 when bit 55 is used as an end-to-end framing bit. > > (now) > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > the value in Table 1 when bit 55 is used as an alternating 1/0 > end-to-end framing bit. > > From nobody Fri Apr 17 10:44:55 2020 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6EE53A0DA3 for ; Fri, 17 Apr 2020 10:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZnPtAfG6_k6 for ; Fri, 17 Apr 2020 10:44:45 -0700 (PDT) Received: from ESA4-Dor.bell.ca (esa4-dor.bell.ca [204.101.223.61]) (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 179B33A0E79 for ; Fri, 17 Apr 2020 10:41:37 -0700 (PDT) Received: from dc5cmz-d01.bellca.int.bell.ca (HELO DG3MBX01-DOR.bell.corp.bce.ca) ([198.235.121.232]) by esa04corp-dor.bell.corp.bce.ca with ESMTP; 17 Apr 2020 13:41:30 -0400 Received: from DG3MBX02-DOR.bell.corp.bce.ca (2002:8e75:d11b::8e75:d11b) by DG3MBX01-DOR.bell.corp.bce.ca (2002:8e75:d11a::8e75:d11a) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 17 Apr 2020 13:41:29 -0400 Received: from DG3MBX02-DOR.bell.corp.bce.ca ([fe80::dc0d:a9d8:b30d:879c]) by DG3MBX02-DOR.bell.corp.bce.ca ([fe80::dc0d:a9d8:b30d:879c%22]) with mapi id 15.00.1473.003; Fri, 17 Apr 2020 13:41:29 -0400 From: "Pierre, Nicolas" To: "avt@ietf.org" Thread-Topic: [AVTCORE] Call for adoption: RTP mixer formatting of multi-party real-time text Thread-Index: AdYU3lLtsIeTRWiNQvKJ3pLBXMyMAA== Date: Fri, 17 Apr 2020 17:41:29 +0000 Message-ID: <163d2c5ab0234d1bb8efb4f1b385ddaa@DG3MBX02-DOR.bell.corp.bce.ca> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.28.92.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [AVTCORE] Call for adoption: RTP mixer formatting of multi-party real-time text X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 17:44:54 -0000 I agree with this adoption. Thanks, Nicolas Pierre Wireless 9-1-1 Program Manager Bell Mobility Emergency Services Working Group (Canada) - NG9-1-1 RTT committee co-chair -----Original Message----- Date: Wed, 15 Apr 2020 14:31:18 -0400 From: Jonathan Lennox To: avt@ietf.org Subject: [AVTCORE] Call for adoption: RTP mixer formatting of multi-party real-time text Message-ID: <591BF32C-0FBD-4E24-BC99-77CB7AC6DE0F@8x8.com> Content-Type: text/plain; charset=3Dus-ascii Hi all, The working group chairs are asking for adoption of a new milestone for RTP= mixer formatting of multi-party real-time text, with draft-hellstrom-avtco= re-multi-party-rtt-source-03 as the basis for the initial WG document. Please respond by Wednesday, April 29th with whether you agree with this ad= option. Technical comments comments on document itself are also always welcome, of = course! Thanks, Jonathan Lennox AVTcore co-chair ------------------------------ Subject: Digest Footer _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt ------------------------------ End of avt Digest, Vol 191, Issue 3 *********************************** ---------------------------------------------------------------------------= --- External Email: Please use caution when opening links and attachments / Cou= rriel externe: Soyez prudent avec les liens et documents joints From nobody Sun Apr 19 19:45:38 2020 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61CF23A0CFA for ; Sun, 19 Apr 2020 19:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.224 X-Spam-Level: * X-Spam-Status: No, score=1.224 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.972, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net 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 L9aprEzXMiI0 for ; Sun, 19 Apr 2020 19:45:34 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (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 24FB33A0CF9 for ; Sun, 19 Apr 2020 19:45:33 -0700 (PDT) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-09v.sys.comcast.net with ESMTP id QMKvjlPNXdWWZQMRAjoVTD; Mon, 20 Apr 2020 02:45:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1587350732; bh=GgJG34nsOP+/zhVM6a0mUyduTN9AJ5tWbMovicaCVw0=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=ZItv4tkXxTTkdwToWTZN+d8bSw4RVo7c530EcDqIUTpAa6+OJ7363J3w+A6A4b2Wg JIeDMhyMLu2PiBmst6vX6UNoiSQ0VvjdzC74fqoLJfHBuBtcrDRRt+KvYqQWnYPMDV G7fNGYcVSfuXTTx3Z7Eqh6eqhoFwiPvZC8Z1LZuUyymEOLTjxHF7ELly/C7j4TFACV 6kxU8YAkrWSDOEGePMz5r6G4vV269oIUKUUbGuWrAWg+oGrqwaKRUcZbGU16ZRo6wa 2vySogy7R6iMDeGeeBMwc/29CmXimaueLUbrcRCQOWNudqhvKcRHcBO4EpY5PLRKx7 DfD2SsuOpA5cw== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-16v.sys.comcast.net with ESMTPA id QMR3jRpIX7vgvQMR5j3UQf; Mon, 20 Apr 2020 02:45:31 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 03K2jPOD022164; Sun, 19 Apr 2020 22:45:25 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 03K2jOq4022161; Sun, 19 Apr 2020 22:45:24 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Jonathan Lennox Cc: avt@ietf.org In-Reply-To: <591BF32C-0FBD-4E24-BC99-77CB7AC6DE0F@8x8.com> (jonathan.lennox@8x8.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 19 Apr 2020 22:45:23 -0400 Message-ID: <87eesiyiws.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [AVTCORE] Call for adoption: RTP mixer formatting of multi-party real-time text X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 02:45:35 -0000 Jonathan Lennox writes: > The working group chairs are asking for adoption of a new milestone > for RTP mixer formatting of multi-party real-time text [...] I haven't judged the technological value of this proposal, but the social value of providing a good solution to this problem is undeniable. Dale From nobody Mon Apr 20 08:18:17 2020 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4A93A08CC for ; Mon, 20 Apr 2020 08:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=motorolasolutions.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 u7WCw9bP0qBN for ; Mon, 20 Apr 2020 08:18:11 -0700 (PDT) Received: from mx0a-0019e102.pphosted.com (mx0a-0019e102.pphosted.com [67.231.149.242]) (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 968E73A08C3 for ; Mon, 20 Apr 2020 08:18:11 -0700 (PDT) Received: from pps.filterd (m0120855.ppops.net [127.0.0.1]) by mx0b-0019e102.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 03KFErNO003004 for ; Mon, 20 Apr 2020 10:18:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=motorolasolutions.com; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=PPS--2020-03-17; bh=HYSjqKt5qPauBT7E+s1mXn5b21hslcKmMiqiKztJZ9A=; b=msej4s0p2B9sKk3Dg5KvBpdFNwY7K92Dx2UE54Gpz4oayhzO5xbGVeftaERkwWwVbIWz 9U0hX5siH3kebzExLcaACTck392KaT3B43x2lp3B1wrSSCdQ6XMw2O1HGCokjvf3wshk uAbWnGSNqb4TREBxOODPEuXKTBaettxWVaHAykaRPel5Yyeko5MUX9PMT7ngKCgfnn8A qNYiXnwftj6yIgEBzzJVMWTSKHEOR0AEw3GS/b1g4vKVCOXs/1B5AoQZy2Mzv6l3R0bF BXRZNu3q2IyopujM83P0z/N0dwWZhl0dnDGO/19xtkBcBPLmnllkCxp2gG/Riu3XJKxl xg== Received: from mail-vs1-f70.google.com (mail-vs1-f70.google.com [209.85.217.70]) by mx0b-0019e102.pphosted.com with ESMTP id 30fv1f6ark-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Mon, 20 Apr 2020 10:18:11 -0500 Received: by mail-vs1-f70.google.com with SMTP id y63so1801847vsc.2 for ; Mon, 20 Apr 2020 08:18:10 -0700 (PDT) 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=HYSjqKt5qPauBT7E+s1mXn5b21hslcKmMiqiKztJZ9A=; b=Ht7ncHVcwN8BQ7l6WKiEAS+VZZUl7jPp+U0niTs454gufeSj/gVA3ohy+8CNWGt3Z2 TtqcyrMEzP0Rlu8nrkXYhPr0Co7cEWyp7ZNbxW2qyws5eRGOVm56FxdNWJuZ+x9qCkxf 3A6adylRFKXXptIHEGlDgm/5+kXqiqd2+ulrJ4UDXLDi+j2uUUw9q3t/KN2CIfuMXqlV xNwsAqoR0MQuSy9COVeKvNwjzQx5rmrHhGyTzWLmfYrsqSf0ENoPel/xGEjlVnoectPv k8bRtt0JXfFIZvPwkHN2Rnsm2xPCfd04B9owttWS/jsG1Z1WimLsEEZ29baL831ZnrkF kBCA== X-Gm-Message-State: AGi0PuYYUrjB1gTg5UyqdxpQyWm6vzplTGK6wOSkoweuzYpzm8LtSZEs MXaxrMRW/8W8MBhD/g3p1/mGlEJPi59ONNqMEUANz+m/xgcgDqLfVJfsBX6Ln1z8JNtE5wPTSbk J/cHDFlCwtKby5YJFxdU= X-Received: by 2002:a05:6102:737:: with SMTP id u23mr10870628vsg.211.1587395889261; Mon, 20 Apr 2020 08:18:09 -0700 (PDT) X-Google-Smtp-Source: APiQypIckB+2i7Kia6dlho4GuYr8UpZhfHMp08VB4gBBZQvAJcO+EAURYyr4JhEr2YON8rVrGIr+0ffmRwZ8UQfdqIc= X-Received: by 2002:a05:6102:737:: with SMTP id u23mr10870591vsg.211.1587395888844; Mon, 20 Apr 2020 08:18:08 -0700 (PDT) MIME-Version: 1.0 References: <591BF32C-0FBD-4E24-BC99-77CB7AC6DE0F@8x8.com> In-Reply-To: <591BF32C-0FBD-4E24-BC99-77CB7AC6DE0F@8x8.com> From: Dan Mongrain Date: Mon, 20 Apr 2020 11:17:57 -0400 Message-ID: To: Jonathan Lennox Cc: avt@ietf.org Content-Type: multipart/alternative; boundary="00000000000012a78905a3ba6853" X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 lowpriorityscore=0 impostorscore=0 suspectscore=1 phishscore=0 mlxscore=0 mlxlogscore=999 bulkscore=0 adultscore=0 spamscore=0 malwarescore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004200129 Archived-At: Subject: Re: [AVTCORE] Call for adoption: RTP mixer formatting of multi-party real-time text X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 15:18:15 -0000 --00000000000012a78905a3ba6853 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I (and my employer) strongly recommend the adoption of the new milestone and will fully support the working group to move the working group draft forward. Thanx, Dan *Dan Mongrain, eng.*Principal Engineer, Standards *Motorola Solutions* *o*: +1.819.931.2129 *m*: +1.613.558.0764 e: Dan.Mongrain@MotorolaSolutions.com www.linkedin.com/in/DanMongrain *[image: https://www.motorolasolutions.com/content/dam/msi/images/logos/corporate/ms= iemailsignature.png]* On Wed, Apr 15, 2020 at 2:31 PM Jonathan Lennox wrote: > Hi all, > > The working group chairs are asking for adoption of a new milestone for > RTP mixer formatting of multi-party real-time text, with > draft-hellstrom-avtcore-multi-party-rtt-source-03 as the basis for the > initial WG document. > > Please respond by Wednesday, April 29th with whether you agree with this > adoption. > > Technical comments comments on document itself are also always welcome, o= f > course! > > Thanks, > > Jonathan Lennox > AVTcore co-chair > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_avt&d=3DDwICAg&c=3Dq3cDpHe1hF8lXU5EFjNM_A&r=3Dn9aaU9xSQM4-mK_yF= 4tJzi7SeOWS3tTUWut1BhcRBI5vMR5LUWrTKzC_1DF8wC_4&m=3Dzs7LYvejEckKb0rUvrZHJ7q= SDwS1cvC0CKCXc58q-KA&s=3D4R0I19Xdq7S_c1i8wYlUbh0Betf43qwfj-7fTOSW960&e=3D > --=20 *Your privacy is important to us. That is why we have taken appropriate=20 measures to ensure the data you provide to us is kept secure. To learn more= =20 about how we process your personal information, how we comply with=20 applicable data protection laws, and care for the security and privacy of= =20 your personal data, please review our Privacy Policy. If you have any=20 questions related to data protection and compliance with applicable laws,= =20 please contact us at our Security Operations Center at 1-800-674-4357.* --00000000000012a78905a3ba6853 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I (and my employer) strongly recommend the adoption of the= new milestone and will fully support the working group to move the working= group draft forward.

Thanx,
Dan

Dan Mongrain, eng.
Principal Engineer, Standards
<= b>Motorola Solutions

o: +1.819.931.2129=C2=A0
= m: +1.= 613.558.0764
e:=C2=A0Dan.Mongrain@MotorolaSolutions.com
www.linkedin.com/in/DanMongrain



=

= On Wed, Apr 15, 2020 at 2:31 PM Jonathan Lennox <jonathan.lennox@8x8.com> wrote= :
Hi all,

The working group chairs are asking for adoption of a new milestone for RTP= mixer formatting of multi-party real-time text, with draft-hellstrom-avtco= re-multi-party-rtt-source-03 as the basis for the initial WG document.

Please respond by Wednesday, April 29th with whether you agree with this ad= option.

Technical comments comments on document itself are also always welcome, of = course!

Thanks,

Jonathan Lennox
AVTcore co-chair

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
http= s://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_lis= tinfo_avt&d=3DDwICAg&c=3Dq3cDpHe1hF8lXU5EFjNM_A&r=3Dn9aaU9xSQM4= -mK_yF4tJzi7SeOWS3tTUWut1BhcRBI5vMR5LUWrTKzC_1DF8wC_4&m=3Dzs7LYvejEckKb= 0rUvrZHJ7qSDwS1cvC0CKCXc58q-KA&s=3D4R0I19Xdq7S_c1i8wYlUbh0Betf43qwfj-7f= TOSW960&e=3D

<= font color=3D"#263238" face=3D"Roboto, sans-serif">Your privacy is important to us. That is why= we have taken appropriate measures to ensure the data you provide to us is= kept secure. To learn more about how we process your personal information,= how we comply with applicable data protection laws, and care for the secur= ity and privacy of your personal data, please review our Privacy Policy. If= you have any questions related to data protection and compliance with appl= icable laws, please contact us at our Security Operations Center at 1-800-6= 74-4357.

--00000000000012a78905a3ba6853-- From nobody Tue Apr 21 02:18:28 2020 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51253A09E3 for ; Tue, 21 Apr 2020 02:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=egensajt.se 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 eWYwnmCzKAas for ; Tue, 21 Apr 2020 02:18:20 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [193.42.159.246]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 818573A09EF for ; Tue, 21 Apr 2020 02:18:18 -0700 (PDT) Received: from [192.168.2.136] (h77-53-230-67.cust.a3fiber.se [77.53.230.67]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 6B62B2003C for ; Tue, 21 Apr 2020 11:18:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1587460696; bh=6/9xApAVDulCM3sqGvbnaisEQLVodhH0mJnmALDd9Ew=; h=To:From:Subject:Date:From; b=shheT+NQPw1yi1ok3B0l8zZGR9ugHFULooJrP5IqWQmyEpopxZR7uww1bCJlCziCG ScxC+4PA9eKcX+WHTvM2lWlQqRw7oDFzfBnUph/Rux4NcASpwwzPaUAXXEmii0sElP 9QBZGo7M+L/3cYCcbkvsEB3Wz51A7aFLNTMRAqIw= To: "avtcore@ietf.org" From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Tue, 21 Apr 2020 11:18:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------59E7894BB72C1166AEC84AF8" Content-Language: sv Archived-At: Subject: [AVTCORE] Multi-party real-time text requiring new RTP payload type X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 09:18:26 -0000 This is a multi-part message in MIME format. --------------59E7894BB72C1166AEC84AF8 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi, I have got an off-list comment that the proposed use of the CSRC-list members to indicate source of the primary and the different redundancy generations of the T140blocks would require registration of a new payload type instead of saying that it is a refined use of text/red updated from RFC 4103. ( this is about https://www.ietf.org/id/draft-hellstrom-avtcore-multi-party-rtt-source-03.txt ) The purpose is to speed up the switch of source of text from the mixer so that every packet can have primary text from another source than the previous packet. Without the update, the mixer would need to send two packets with just redundant text before sending new text from another source. I am not yet totally convinced that we need to introduce a new payload type, but find it possible. Let us call it "text/rex" for "redundancy extended". It would cause a quite straightforward sdp negotiation of parties supporting both the traditional text/red format from RFC 4103, and the updated text/rex. Offer example : m=text 11000 RTP/AVP 101 100 98 a=rtpmap:98 t140/1000 a=rtpmap:100 red/1000 a=rtpmap:101 rex/1000 a=fmtp:100 98/98/98 a=fmtp:101 98/98/98 a=rtt-mix Answer example from a multi-party capable device m=text 11000 RTP/AVP 101 98 a=rtpmap:98 t140/1000 a=rtpmap:101 rex/1000 a=fmtp:101 98/98/98 a=rtt-mix Answer example from a multi-party unaware device: m=text 11000 RTP/AVP 100 98 a=rtpmap:98 t140/1000 a=rtpmap:100 red/1000 a=fmtp:100 98/98/98 It may look strange that the attribute a=rtt-mix is still there as an indication of multi-party capability when that already is implied in the "rex" payload type. But it is for the very rare case that the network conditions would allow use of bare t140 payload type without redundancy. Then there is a need to indicate multi-party awareness by a=rtt-mix . If we accept this move, we could also open for discussion if the format proposed by James Hamlin earlier in this list, where the maximum number of 16 members in the CSRC list allows transport of text from up to 16 sources in the same packet. That would make the mixing of real-time text as efficient and rapid as that of audio and video. A question is though if current implementations are well behaving and do not collapse by getting the combined sdp. If we do not accept this move and instead base the multi-party mixing on the current text/red format with short transmission intervals, we can claim that simultaneous typing is quite rare and that the introduced delay of the first few characters of about 200 ms from a second source when one is already sending is acceptable, knowing that most text conversations are at speeds of under 12 characters per second and that the transmissions from each source anyway comes in 300 ms intervals. Some jerkiness and delay will be noticable when there is more than two simultaneous senders. Regards Gunnar -- Gunnar Hellstrm GHAccess gunnar.hellstrom@ghaccess.se --------------59E7894BB72C1166AEC84AF8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi,

I have got an off-list comment that the proposed use of the CSRC-list members to indicate source of the primary and the different redundancy generations of the T140blocks would require registration of a new payload type instead of saying that it is a refined use of text/red updated from RFC 4103.

( this is about https://www.ietf.org/id/draft-hellstrom-avtcore-multi-party-rtt-source-03.txt )

The purpose is to speed up the switch of source of text from the mixer so that every packet can have primary text from another source than the previous packet. Without the update, the mixer would need to send two packets with just redundant text before sending new text from another source.

I am not yet totally convinced that we need to introduce a new payload type, but find it possible.

Let us call it "text/rex" for "redundancy extended".

It would cause a quite straightforward sdp negotiation of parties supporting both the traditional text/red format from RFC 4103, and the updated text/rex.

Offer example :

      m=text 11000 RTP/AVP 101 100 98
      a=rtpmap:98 t140/1000
      a=rtpmap:100 red/1000
      a=rtpmap:101 rex/1000
     a=fmtp:100 98/98/98
      a=fmtp:101 98/98/98
      a=rtt-mix

Answer example  from a multi-party capable device
      m=text 11000 RTP/AVP 101 98
      a=rtpmap:98 t140/1000
      a=rtpmap:101 rex/1000
      a=fmtp:101 98/98/98
      a=rtt-mix

Answer example from a multi-party unaware device:

      m=text 11000 RTP/AVP 100 98
      a=rtpmap:98 t140/1000
      a=rtpmap:100 red/1000
     a=fmtp:100 98/98/98

It may look strange that the attribute a=rtt-mix is still there as an indication of multi-party capability when that already is implied in the "rex" payload type. But it is for the very rare case that the network conditions would allow use of bare t140 payload type without redundancy. Then there is a need to indicate multi-party awareness by a=rtt-mix .

If we accept this move, we could also open for discussion if the format proposed by James Hamlin earlier in this list, where the maximum number of 16 members in the CSRC list allows transport of text from up to 16 sources in the same packet. That would make the mixing of real-time text as efficient and rapid as that of audio and video. A question is though if current implementations are well behaving and do not collapse by getting the combined sdp.

If we do not accept this move and instead base the multi-party mixing on the current text/red format with short transmission intervals, we can claim that simultaneous typing is quite rare and that the introduced delay of the first few characters of about 200 ms from a second source when one is already sending is acceptable, knowing that most text conversations are at speeds of under 12 characters per second and that the transmissions from each source anyway comes in 300 ms intervals. Some jerkiness and delay will be noticable when there is more than two simultaneous senders.

Regards

Gunnar 

-- 
Gunnar Hellstrm
GHAccess
gunnar.hellstrom@ghaccess.se
--------------59E7894BB72C1166AEC84AF8-- From nobody Tue Apr 21 11:50:24 2020 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4553A0440 for ; Tue, 21 Apr 2020 11:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 wqeVCCmJVUTI for ; Tue, 21 Apr 2020 11:50:10 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 D3E373A0528 for ; Tue, 21 Apr 2020 11:50:02 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id t3so15681130qkg.1 for ; Tue, 21 Apr 2020 11:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BBwfff3ECgO4qOiEv+JheAfGX5luCFjR9/U2C82WsoM=; b=P3L4F7PCyocAbFbbkwVZcPJkSPKuy+7dTmImczZNugw8RcTz7shpJ8vWeVz9WQTnqq O6zeipvWHtUnCjPiVBxNTpjbSSpjR7BM04rdy2IDXCLZ3y+tCd9RZPtXB9wI7eIrhVXc +Sk7UL04cT1cwIAQE+50HK4aB1bI+aX7A8ox2SVAC0IpEGGC0qnXAF+t8n41OpiUWMoX 64cUMFnsXkbVOlMBvnoqpysKm119rYvuMj4XtE/25g5zP6DwAwR9Fd6g0LBe++9FredJ QKCrhWs5V+HDHqFifoiilinmdrKswuWCKd+8rbZ5MQOyw1PE8EAX0etQ0utiC0cRkYCr +vvQ== 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=BBwfff3ECgO4qOiEv+JheAfGX5luCFjR9/U2C82WsoM=; b=bjfmLNXlcE7NUWqw8B+MAjAzUNlqy0MjI6Cl4QO/H3hnKrpdo3Ai6M5buMVD0/f2E8 h7aYhGlnW0UxIXwZ/Iz2DJrRCT5fDE6RdoqoTnqYfTNk3ErRmjYGEYaaXDMFnFtK+p1a 2pFTClteGefVyWxmeK1e2nT8qE5a5vKQGJxUcptVn7oLRjWwQ7WPGyiYkusgxNgqVxns MfoKd5TmPYVnLccsXYhNtPCUs72xuiZlOsAX4I1/iJ4DSddjyfRxqr5ekQzIvaho7cGC vDAcgcck6XwnO/Hzn+VG+HBjYra3ChEvyUlxRtPIYSPL/2D1jQTnoxaun9RF3m9h3Fi+ dnEA== X-Gm-Message-State: AGi0PuYlNZcnNbj6PIqaV8PFeH995uhQMj801HWbDDpwJ53J6bRWUkgZ HV0wgU1C39IPQC8YLFaf9jwx1Q== X-Google-Smtp-Source: APiQypI1GnPzWD3zam6EwD7hcfyQhULwP5cvxaQ+qddtlGqD4vOcTo9ayCCFHhkcudhTTAAgiQNo0A== X-Received: by 2002:a37:4c4d:: with SMTP id z74mr22616810qka.53.1587495000082; Tue, 21 Apr 2020 11:50:00 -0700 (PDT) Received: from brians-mbp-2871.lan ([72.23.94.147]) by smtp.gmail.com with ESMTPSA id p80sm2270151qke.96.2020.04.21.11.49.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2020 11:49:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Brian Rosen In-Reply-To: <591BF32C-0FBD-4E24-BC99-77CB7AC6DE0F@8x8.com> Date: Tue, 21 Apr 2020 14:49:57 -0400 Cc: avt@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <591BF32C-0FBD-4E24-BC99-77CB7AC6DE0F@8x8.com> To: Jonathan Lennox X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [AVTCORE] Call for adoption: RTP mixer formatting of multi-party real-time text X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 18:50:21 -0000 I support the adoption of this work and will provide reviews and = comments on the text. Brian > On Apr 15, 2020, at 2:31 PM, Jonathan Lennox = wrote: >=20 > Hi all, >=20 > The working group chairs are asking for adoption of a new milestone = for RTP mixer formatting of multi-party real-time text, with = draft-hellstrom-avtcore-multi-party-rtt-source-03 as the basis for the = initial WG document. >=20 > Please respond by Wednesday, April 29th with whether you agree with = this adoption. >=20 > Technical comments comments on document itself are also always = welcome, of course! >=20 > Thanks, >=20 > Jonathan Lennox > AVTcore co-chair >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From nobody Tue Apr 21 11:56:25 2020 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324293A052C for ; Tue, 21 Apr 2020 11:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 bNPf_uv0oR8G for ; Tue, 21 Apr 2020 11:56:19 -0700 (PDT) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (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 A3EEC3A0524 for ; Tue, 21 Apr 2020 11:56:18 -0700 (PDT) Received: by mail-qv1-xf32.google.com with SMTP id y19so7113500qvv.4 for ; Tue, 21 Apr 2020 11:56:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/lNTLANoneOk09ctHvrep7GVtm82hGrpAnF06EmOHv0=; b=a37rf0VJF1wMOMShCfAybjydOfX1RWGHo7o4bWUpbOUPuKH/UfcTT4KgJmZxx0i2+u OJxsDEzsSvHS4psk9eAmoj9J1xko7cgTA4Af/Fnk2TTXWJeSZ9+tCvyGMo4IrDmStAKR KH8eK4YTdK/B7rH4MCAq1H53SpuRRSAFl9382ILhToe/KhzFzIQr/eh+1Sba/sDZWqur 78qzlRu0VCzdn6b2mQx88aUzBVeXalHfZ176bn1GxC89s/wKgVVZvyALaw+FC/xVRCCl McG2oK6jOAYJfyB7W9EZkBazoyNRmfaRk3+0thnnrAzQb5yEhXr+c15DO8vjh/3mgxAi qMFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=/lNTLANoneOk09ctHvrep7GVtm82hGrpAnF06EmOHv0=; b=IjALB7EyDabbmQai2K/pTI40AUO1ZD5U8WVEPRSJ/W53NXdFchkfymeLnjbLTOzc44 sEio6da9pRYLkJNdMKjDNMSqXceyZknTVv7udZpSlDzqmwJH2pxxl7VyoCSfEFsBzkIR BuJANaMh6kA9BXwbZtJT4jOIquTyZetxpyQoNq1bsBisgKyBQEWIfMpsgomlzcX1+rbu WWGuOS4YQ77PDxP1skiBwO7SN+iQT5c/KhF1CqxgJe+yz35z7ew0CscO1v3BZI3q8Bbn daJW3aGkXWqJ8HYjqrwauE3v/Kebx0KF3lUUgHgbwIvV9fYAaOfA24fqqz2kOSLT4Gwi JF0Q== X-Gm-Message-State: AGi0PuaqI8x055AoX3/Eox+VEQcCafdlRL5flqqtqVe1Rmeh9RDc+yuG oW92lfNoSNvsclLM/OM23uPRsGRc97s= X-Google-Smtp-Source: APiQypIwxOdwdx0Fd9dmgsKS/X+n4xYha8xlt1oHWpVU3wlOAuxg2hcTjpPKfW0vuzito+8EIikX2g== X-Received: by 2002:a05:6214:530:: with SMTP id x16mr9077440qvw.55.1587495376157; Tue, 21 Apr 2020 11:56:16 -0700 (PDT) Received: from brians-mbp-2871.lan ([72.23.94.147]) by smtp.gmail.com with ESMTPSA id c11sm2258678qkj.78.2020.04.21.11.56.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2020 11:56:15 -0700 (PDT) From: Brian Rosen Message-Id: <197C0C31-FDCB-46A8-9642-5F4D98F63F75@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_3AC490FF-0B73-428E-9870-C627F032532C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 21 Apr 2020 14:56:14 -0400 In-Reply-To: Cc: "avtcore@ietf.org" To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [AVTCORE] Multi-party real-time text requiring new RTP payload type X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 18:56:24 -0000 --Apple-Mail=_3AC490FF-0B73-428E-9870-C627F032532C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m okay with the new payload type. All of this would be new = code, so dealing with the new payload type wouldn=E2=80=99t be confusing = or difficult.=20 I=E2=80=99m not aware of any implementations of t140 without redundancy, = but I=E2=80=99m also not bothered by including rtt-mix. I=E2=80=99m also okay with James Hamlin=E2=80=99s proposal. I like the = effect enough that I=E2=80=99m not going to worry about bad = implementations. Again, supporting this is new code, so if your = implementation of T140 and SDP in general is lacking, this would be a = good time to fix that. Brian > On Apr 21, 2020, at 5:18 AM, Gunnar Hellstr=C3=B6m = wrote: >=20 > Hi, >=20 > I have got an off-list comment that the proposed use of the CSRC-list = members to indicate source of the primary and the different redundancy = generations of the T140blocks would require registration of a new = payload type instead of saying that it is a refined use of text/red = updated from RFC 4103. >=20 > ( this is about = https://www.ietf.org/id/draft-hellstrom-avtcore-multi-party-rtt-source-03.= txt = ) >=20 > The purpose is to speed up the switch of source of text from the mixer = so that every packet can have primary text from another source than the = previous packet. Without the update, the mixer would need to send two = packets with just redundant text before sending new text from another = source. >=20 > I am not yet totally convinced that we need to introduce a new payload = type, but find it possible.=20 >=20 > Let us call it "text/rex" for "redundancy extended". >=20 > It would cause a quite straightforward sdp negotiation of parties = supporting both the traditional text/red format from RFC 4103, and the = updated text/rex.=20 >=20 > Offer example : >=20 > m=3Dtext 11000 RTP/AVP 101 100 98 > a=3Drtpmap:98 t140/1000 > a=3Drtpmap:100 red/1000 > a=3Drtpmap:101 rex/1000 > a=3Dfmtp:100 98/98/98 > a=3Dfmtp:101 98/98/98 > a=3Drtt-mix >=20 > Answer example from a multi-party capable device > m=3Dtext 11000 RTP/AVP 101 98 > a=3Drtpmap:98 t140/1000 > a=3Drtpmap:101 rex/1000 > a=3Dfmtp:101 98/98/98 > a=3Drtt-mix >=20 > Answer example from a multi-party unaware device: >=20 > m=3Dtext 11000 RTP/AVP 100 98 > a=3Drtpmap:98 t140/1000 > a=3Drtpmap:100 red/1000 > a=3Dfmtp:100 98/98/98 >=20 > =20 > It may look strange that the attribute a=3Drtt-mix is still there as = an indication of multi-party capability when that already is implied in = the "rex" payload type. But it is for the very rare case that the = network conditions would allow use of bare t140 payload type without = redundancy. Then there is a need to indicate multi-party awareness by = a=3Drtt-mix . >=20 > If we accept this move, we could also open for discussion if the = format proposed by James Hamlin earlier in this list, where the maximum = number of 16 members in the CSRC list allows transport of text from up = to 16 sources in the same packet. That would make the mixing of = real-time text as efficient and rapid as that of audio and video. A = question is though if current implementations are well behaving and do = not collapse by getting the combined sdp. >=20 > If we do not accept this move and instead base the multi-party mixing = on the current text/red format with short transmission intervals, we can = claim that simultaneous typing is quite rare and that the introduced = delay of the first few characters of about 200 ms from a second source = when one is already sending is acceptable, knowing that most text = conversations are at speeds of under 12 characters per second and that = the transmissions from each source anyway comes in 300 ms intervals. = Some jerkiness and delay will be noticable when there is more than two = simultaneous senders. >=20 > Regards >=20 > Gunnar=20 >=20 > --=20 > Gunnar Hellstr=C3=B6m > GHAccess > gunnar.hellstrom@ghaccess.se = _____________________________________= __________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --Apple-Mail=_3AC490FF-0B73-428E-9870-C627F032532C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80= =99m okay with the new payload type.  All of this would be new = code, so dealing with the new payload type wouldn=E2=80=99t be confusing = or difficult. 
I=E2=80=99m not aware of any = implementations of t140 without redundancy, but I=E2=80=99m also not = bothered by including rtt-mix.

I=E2=80=99m also okay with James = Hamlin=E2=80=99s proposal.  I like the effect enough that I=E2=80=99m= not going to worry about bad implementations.  Again, supporting = this is new code, so if your implementation of T140 and SDP in general = is lacking, this would be a good time to fix that.

Brian


On Apr 21, 2020, at 5:18 AM, Gunnar = Hellstr=C3=B6m <gunnar.hellstrom@ghaccess.se> wrote:

=20 =20

Hi,

I have got an = off-list comment that the proposed use of the CSRC-list members to indicate source of the primary and the different redundancy generations of the T140blocks would require registration of a new payload type instead of saying that it is a refined use of text/red updated from RFC 4103.

( = this is about https://www.ietf.org/id/draft-hellstrom-avtcore-multi-party-rtt= -source-03.txt )

The purpose is to speed up the switch of source = of text from the mixer so that every packet can have primary text from another source than the previous packet. Without the update, the mixer would need to send two packets with just redundant text before sending new text from another source.

I am not yet totally convinced that we need to = introduce a new payload type, but find it possible.

Let us call it "text/rex" for "redundancy = extended".

It would cause a quite straightforward sdp = negotiation of parties supporting both the traditional text/red format from RFC 4103, and the updated text/rex.

Offer example :

      m=3Dtext 11000 RTP/AVP 101 100 98
      a=3Drtpmap:98 t140/1000
      a=3Drtpmap:100 red/1000
      a=3Drtpmap:101 rex/1000
      a=3Dfmtp:100 98/98/98
      a=3Dfmtp:101 98/98/98
      a=3Drtt-mix

 Answer example  from a multi-party capable device
      m=3Dtext 11000 RTP/AVP 101 98
      a=3Drtpmap:98 t140/1000
      a=3Drtpmap:101 rex/1000
      a=3Dfmtp:101 98/98/98
      a=3Drtt-mix

Answer example from a multi-party unaware device:

      m=3Dtext 11000 RTP/AVP 100 98
      a=3Drtpmap:98 t140/1000
      a=3Drtpmap:100 red/1000
      a=3Dfmtp:100 98/98/98

 

It may look strange that the attribute a=3Drtt-mix = is still there as an indication of multi-party capability when that already is implied in the "rex" payload type. But it is for the very rare case that the network conditions would allow use of bare t140 payload type without redundancy. Then there is a need to indicate multi-party awareness by a=3Drtt-mix .

If we = accept this move, we could also open for discussion if the format proposed by James Hamlin earlier in this list, where the maximum number of 16 members in the CSRC list allows transport of text from up to 16 sources in the same packet. That would make the mixing of real-time text as efficient and rapid as that of audio and video. A question is though if current implementations are well behaving and do not collapse by getting the combined sdp.

If we do not accept this move and instead base the = multi-party mixing on the current text/red format with short transmission intervals, we can claim that simultaneous typing is quite rare and that the introduced delay of the first few characters of about 200 ms from a second source when one is already sending is acceptable, knowing that most text conversations are at speeds of under 12 characters per second and that the transmissions from each source anyway comes in 300 ms intervals.  Some jerkiness and delay = will be noticable when there is more than two simultaneous senders.

Regards

Gunnar  

--=20
Gunnar Hellstr=C3=B6m
GHAccess
gunnar.hellstrom@ghaccess.se<=
/a>
_______________________________________________
Audio/Video = Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt

= --Apple-Mail=_3AC490FF-0B73-428E-9870-C627F032532C-- From nobody Wed Apr 22 13:01:40 2020 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753483A07B5 for ; Wed, 22 Apr 2020 13:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=egensajt.se 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 aiOBdVaZDePz for ; Wed, 22 Apr 2020 13:01:34 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 224333A07AD for ; Wed, 22 Apr 2020 13:01:33 -0700 (PDT) Received: from [192.168.2.136] (h77-53-230-67.cust.a3fiber.se [77.53.230.67]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 0F30520093; Wed, 22 Apr 2020 22:01:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1587585691; bh=hIDk0SAc+R54G+6I+wQGYcOWou1S3O8VJwpfMmqONx0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=aRIIT2lgB/CplFg66YZHPYrU56+zg1MAK6vhduib+wBUrVgj6NnXT55BrUmdjfGW7 vnhHYUbJzKNwmgleg8VOM8GlwjEujtV+LJoU5dYFmamkJmVjC1ydJtL88uZUH4OXsx Sxf7BDNnOt3Ft6t8mW2MeA7lalJMigko3PXiM3YM= To: Brian Rosen Cc: "avtcore@ietf.org" References: <197C0C31-FDCB-46A8-9642-5F4D98F63F75@brianrosen.net> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <45d55958-fb0f-6298-807b-ce375b60d60f@ghaccess.se> Date: Wed, 22 Apr 2020 22:01:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <197C0C31-FDCB-46A8-9642-5F4D98F63F75@brianrosen.net> Content-Type: multipart/alternative; boundary="------------71432BD9D44A40CFE5F76DBF" Content-Language: sv Archived-At: Subject: Re: [AVTCORE] Multi-party real-time text requiring new RTP payload type X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 20:01:39 -0000 This is a multi-part message in MIME format. --------------71432BD9D44A40CFE5F76DBF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks Brian, Den 2020-04-21 kl. 20:56, skrev Brian Rosen: > I’m okay with the new payload type.  All of this would be new code, so > dealing with the new payload type wouldn’t be confusing or difficult. Right. And a lot from RFC 4103 is still valid with the new payload type, so that it can be an update to RFC 4103. > I’m not aware of any implementations of t140 without redundancy, but > I’m also not bothered by including rtt-mix. Right. No one using plain T.140 without redundancy currently. > > I’m also okay with James Hamlin’s proposal.  I like the effect enough > that I’m not going to worry about bad implementations. I aim at including this new payload type in next version. I also intend to look at what sdp would look like if we include negotiation between RTP and SRTP. > Again, supporting this is new code, so if your implementation of T140 > and SDP in general is lacking, this would be a good time to fix that. > > Brian > Thanks, Gunnar > >> On Apr 21, 2020, at 5:18 AM, Gunnar Hellström >> > >> wrote: >> >> Hi, >> >> I have got an off-list comment that the proposed use of the CSRC-list >> members to indicate source of the primary and the different >> redundancy generations of the T140blocks would require registration >> of a new payload type instead of saying that it is a refined use of >> text/red updated from RFC 4103. >> >> ( this is about >> https://www.ietf.org/id/draft-hellstrom-avtcore-multi-party-rtt-source-03.txt >> ) >> >> The purpose is to speed up the switch of source of text from the >> mixer so that every packet can have primary text from another source >> than the previous packet. Without the update, the mixer would need to >> send two packets with just redundant text before sending new text >> from another source. >> >> I am not yet totally convinced that we need to introduce a new >> payload type, but find it possible. >> >> Let us call it "text/rex" for "redundancy extended". >> >> It would cause a quite straightforward sdp negotiation of parties >> supporting both the traditional text/red format from RFC 4103, and >> the updated text/rex. >> >> Offer example : >> >> m=text 11000 RTP/AVP 101 100 98 >> a=rtpmap:98 t140/1000 >> a=rtpmap:100 red/1000 >> a=rtpmap:101 rex/1000 >>   a=fmtp:100 98/98/98 >> a=fmtp:101 98/98/98 >> a=rtt-mix >> >>  Answer example from a multi-party capable device >> m=text 11000 RTP/AVP 101 98 >> a=rtpmap:98 t140/1000 >> a=rtpmap:101 rex/1000 >> a=fmtp:101 98/98/98 >> a=rtt-mix >> >> Answer example from a multi-party unaware device: >> >> m=text 11000 RTP/AVP 100 98 >> a=rtpmap:98 t140/1000 >> a=rtpmap:100 red/1000 >>   a=fmtp:100 98/98/98 >> >> >> >> It may look strange that the attribute a=rtt-mix is still there as an >> indication of multi-party capability when that already is implied in >> the "rex" payload type. But it is for the very rare case that the >> network conditions would allow use of bare t140 payload type without >> redundancy. Then there is a need to indicate multi-party awareness by >> a=rtt-mix . >> >> If we accept this move, we could also open for discussion if the >> format proposed by James Hamlin earlier in this list, where the >> maximum number of 16 members in the CSRC list allows transport of >> text from up to 16 sources in the same packet. That would make the >> mixing of real-time text as efficient and rapid as that of audio and >> video. A question is though if current implementations are well >> behaving and do not collapse by getting the combined sdp. >> >> If we do not accept this move and instead base the multi-party mixing >> on the current text/red format with short transmission intervals, we >> can claim that simultaneous typing is quite rare and that the >> introduced delay of the first few characters of about 200 ms from a >> second source when one is already sending is acceptable, knowing that >> most text conversations are at speeds of under 12 characters per >> second and that the transmissions from each source anyway comes in >> 300 ms intervals.  Some jerkiness and delay will be noticable when >> there is more than two simultaneous senders. >> >> Regards >> >> Gunnar >> >> -- >> Gunnar Hellström >> GHAccess >> gunnar.hellstrom@ghaccess.se >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt > -- Gunnar Hellström GHAccess gunnar.hellstrom@ghaccess.se --------------71432BD9D44A40CFE5F76DBF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Thanks Brian,

Den 2020-04-21 kl. 20:56, skrev Brian Rosen:
I’m okay with the new payload type.  All of this would be new code, so dealing with the new payload type wouldn’t be confusing or difficult.
Right. And a lot from RFC 4103 is still valid with the new payload type, so that it can be an update to RFC 4103.
 
I’m not aware of any implementations of t140 without redundancy, but I’m also not bothered by including rtt-mix.
Right. No one using plain T.140 without redundancy currently.

I’m also okay with James Hamlin’s proposal.  I like the effect enough that I’m not going to worry about bad implementations. 
I aim at including this new payload type in next version. I also intend to look at what sdp would look like if we include negotiation between RTP and SRTP.
Again, supporting this is new code, so if your implementation of T140 and SDP in general is lacking, this would be a good time to fix that.


Brian

Thanks,

Gunnar


On Apr 21, 2020, at 5:18 AM, Gunnar Hellström <gunnar.hellstrom@ghaccess.se> wrote:

Hi,

I have got an off-list comment that the proposed use of the CSRC-list members to indicate source of the primary and the different redundancy generations of the T140blocks would require registration of a new payload type instead of saying that it is a refined use of text/red updated from RFC 4103.

( this is about https://www.ietf.org/id/draft-hellstrom-avtcore-multi-party-rtt-source-03.txt )

The purpose is to speed up the switch of source of text from the mixer so that every packet can have primary text from another source than the previous packet. Without the update, the mixer would need to send two packets with just redundant text before sending new text from another source.

I am not yet totally convinced that we need to introduce a new payload type, but find it possible.

Let us call it "text/rex" for "redundancy extended".

It would cause a quite straightforward sdp negotiation of parties supporting both the traditional text/red format from RFC 4103, and the updated text/rex.

Offer example :

      m=text 11000 RTP/AVP 101 100 98
      a=rtpmap:98 t140/1000
      a=rtpmap:100 red/1000
      a=rtpmap:101 rex/1000
      a=fmtp:100 98/98/98
      a=fmtp:101 98/98/98
      a=rtt-mix

 Answer example  from a multi-party capable device
      m=text 11000 RTP/AVP 101 98
      a=rtpmap:98 t140/1000
      a=rtpmap:101 rex/1000
      a=fmtp:101 98/98/98
      a=rtt-mix

Answer example from a multi-party unaware device:

      m=text 11000 RTP/AVP 100 98
      a=rtpmap:98 t140/1000
      a=rtpmap:100 red/1000
      a=fmtp:100 98/98/98

 

It may look strange that the attribute a=rtt-mix is still there as an indication of multi-party capability when that already is implied in the "rex" payload type. But it is for the very rare case that the network conditions would allow use of bare t140 payload type without redundancy. Then there is a need to indicate multi-party awareness by a=rtt-mix .

If we accept this move, we could also open for discussion if the format proposed by James Hamlin earlier in this list, where the maximum number of 16 members in the CSRC list allows transport of text from up to 16 sources in the same packet. That would make the mixing of real-time text as efficient and rapid as that of audio and video. A question is though if current implementations are well behaving and do not collapse by getting the combined sdp.

If we do not accept this move and instead base the multi-party mixing on the current text/red format with short transmission intervals, we can claim that simultaneous typing is quite rare and that the introduced delay of the first few characters of about 200 ms from a second source when one is already sending is acceptable, knowing that most text conversations are at speeds of under 12 characters per second and that the transmissions from each source anyway comes in 300 ms intervals.  Some jerkiness and delay will be noticable when there is more than two simultaneous senders.

Regards

Gunnar  

-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se
_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt

-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se
--------------71432BD9D44A40CFE5F76DBF-- From nobody Wed Apr 22 19:27:20 2020 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0143A1134 for ; Wed, 22 Apr 2020 19:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.983 X-Spam-Level: X-Spam-Status: No, score=-0.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net 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 Vhvj96jniWRV for ; Wed, 22 Apr 2020 19:27:14 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 4422B3A0E65 for ; Wed, 22 Apr 2020 19:27:13 -0700 (PDT) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-08v.sys.comcast.net with ESMTP id RRPIjhkpwLoTbRRa4jA1Cd; Thu, 23 Apr 2020 02:27:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1587608832; bh=3sFtLjOVCYdjZl4Ph8gkrusNWyo8FwFMUbqpLqdklmg=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=gtgGM57IvVqu/+Sy6naYdRlKP8wlCUkak/svX1VP2OHTXmEKcFOFTKFzlSHewEEDt izYEdc9KHbMrH9Lk2UX2AHh2qI3u1HkReKzirF7i/jXZma6SPMpd97LesVJzlSAIcr 6qAFgRRn5B6usrUTHl02wfET7L+OqNeWobqkj2CrF+9pbZbp0juVZrvvU0tG5iBmJC DkGrN0y1x2oUj0jjotM337ytk0IwxQdxDoiyMW384phlzr9LXWKLYLdZp066kFfzYS do9+QH+u2YlX/zk+Mef5Pw9uC0VbnZPBSM0Rcepx53u6jpbNdqtHaOLxTdxEIHHMd3 WWukiUb/uoAnQ== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-02v.sys.comcast.net with ESMTPA id RRa2jJry8TY9rRRa2jCq4Q; Thu, 23 Apr 2020 02:27:11 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 03N2R9JS005334; Wed, 22 Apr 2020 22:27:09 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 03N2R8pI005312; Wed, 22 Apr 2020 22:27:08 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Gunnar =?utf-8?Q?Hellstr=C3=B6m?= Cc: avtcore@ietf.org In-Reply-To: (gunnar.hellstrom@ghaccess.se) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 22 Apr 2020 22:27:07 -0400 Message-ID: <87h7xbuebo.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [AVTCORE] Multi-party real-time text requiring new RTP payload type X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 02:27:18 -0000 I assume that there's a good reason why the case of redundant transmission of multi-party text isn't done by suitably interleaving the redundant packets of the serveral text sources (which can be separated by their SSRC values). I can't remember if this is a violation of the RTP rules, or perhaps it's just inefficient. But a quick read of the draft didn't mention why this approach doesn't work, and it seems like it would be a useful note to the reader. Dale From nobody Thu Apr 23 01:37:10 2020 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA5A3A1711 for ; Thu, 23 Apr 2020 01:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=egensajt.se 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 AThzNaJcYOrd for ; Thu, 23 Apr 2020 01:37:03 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B23323A1712 for ; Thu, 23 Apr 2020 01:37:02 -0700 (PDT) Received: from [192.168.2.136] (h77-53-230-67.cust.a3fiber.se [77.53.230.67]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id D60B8202BA; Thu, 23 Apr 2020 10:36:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1587631019; bh=DCnM1kPIlrgL0UibNqlrVi2+jh+C4Nx6tv82wIWr9M4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=C/YgE9r/JVEo4r7oAVyegkhR+F1qY8qeKd6lkT/gBkzbxfkC3GIt7xo65/n+wal/+ 7MSoUJB17S4thnExRzpneVWqxv5g1gVV1rmzE0gd1ziz7SWTaGQLhJmPloiywKrzXf BIe9cI7HIPzQW9iiErS8gmseXkfGV4X523Errk9E= To: "Dale R. Worley" Cc: avtcore@ietf.org References: <87h7xbuebo.fsf@hobgoblin.ariadne.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <8cec232d-1341-9d33-447a-49263c550a92@ghaccess.se> Date: Thu, 23 Apr 2020 10:36:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <87h7xbuebo.fsf@hobgoblin.ariadne.com> Content-Type: multipart/alternative; boundary="------------31E464FC11F3D0320E7BA0A9" Content-Language: sv Archived-At: Subject: Re: [AVTCORE] Multi-party real-time text requiring new RTP payload type X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 08:37:08 -0000 This is a multi-part message in MIME format. --------------31E464FC11F3D0320E7BA0A9 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Dale, Thanks, a good question. It is the right time to consider which source multiplexing and reliability method to select, now when we need to introduce a new negotiation. More below Den 2020-04-23 kl. 04:27, skrev Dale R. Worley: > I assume that there's a good reason why the case of redundant > transmission of multi-party text isn't done by suitably interleaving the > redundant packets of the serveral text sources (which can be separated > by their SSRC values). I can't remember if this is a violation of the > RTP rules, or perhaps it's just inefficient. But a quick read of the > draft didn't mention why this approach doesn't work, and it seems like > it would be a useful note to the reader. Draft-hellstrom-avtcore-multi-party-rtt-source is intended to contain the solution for the type of bridge used in NG9-1-1 and 3GPP IMS, which seems to be based on the RFC4535 SIP centralised conference framework. Backgrounds and discussions of possible methods with a wider scope are collected in draft-hellstrom-avtcore-multi-party-rtt-solutions where section 4.2.1 is similar to what you propose with separate ssrc:s per source. Each discussed method also has pros and cons briefly documented. Having separate SSRC per source is what RTP calls using a RTP translator. Yes, I would have liked to use that method. But we have an urgency in implementing the selected method in NG9-1-1 systems and in 3GPP IMS. And it is said that many current RTP implementations do not support multiple SSRCs in the same RTP session and even that RFC 3264 says that one m-section in sdp can only support one SSRC. However, RFC 4588 (FEC) section 8.8 shows an SSRC-multiplexing sdp example where the original media stream has one SSRC and the redundancy another within the same m-section. But that is of course no evidence that current RTP implementations support it. RFC 8108 clarifies in section 3.3 that one of its applications is for combining multiple media sources of the same kind in the same RTP session. But it has the total goal of multiplexing also multiple media in the same RTP session. The corresponding sdp specification (with a much wider scope than we need) is draft-ietf-mmusic-sdp-bundle-negotiation and it is not supported by many current RTP implementations ( but maybe soon is because of its use in WebRTC). Methods that could be considered but are not yet documented in draft-hellstrom-avtcore-multi-party-rtt-solutions are (excuse me if some look far fetched): RFC 4588 FEC, using SSRC multiplexing if that works or session multiplexing if needed. In this case plain T.140 RTP would be sent from the mixer in one stream, with the ssrc of the mixer and csrc of the source, and in the redundancy stream the packets would be repeated (twice) with another ssrc in a small redundancy header. RFC 8122 Comedia to improve reliability, but then I have not studied how to arrange for multi-party use. draft-ietf-mmusic-t140-usage-data-channel using one WebRTC data channel per source. RFC 8108 section 3.3 and draft-ietf-mmusic-sdp-bundle-negotiation Avoiding solutions because of imagined limitations in current implementations may be a bad design criterium, so do you suggest that we rapidly look further into any of these or other options? Thanks Gunnar > > Dale -- Gunnar Hellstrm GHAccess gunnar.hellstrom@ghaccess.se --------------31E464FC11F3D0320E7BA0A9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Dale,

Thanks, a good question. It is the right time to consider which source multiplexing and reliability method to select, now when we need to introduce a new negotiation.

More below

Den 2020-04-23 kl. 04:27, skrev Dale R. Worley:
I assume that there's a good reason why the case of redundant
transmission of multi-party text isn't done by suitably interleaving the
redundant packets of the serveral text sources (which can be separated
by their SSRC values).  I can't remember if this is a violation of the
RTP rules, or perhaps it's just inefficient.  But a quick read of the
draft didn't mention why this approach doesn't work, and it seems like
it would be a useful note to the reader.
Draft-hellstrom-avtcore-multi-party-rtt-source is intended to contain the solution for the type of bridge used in NG9-1-1 and 3GPP IMS, which seems to be based on the RFC4535 SIP centralised conference framework.
Backgrounds and discussions of possible methods with a wider scope are collected in

draft-hellstrom-avtcore-multi-party-rtt-solutions

where section 4.2.1 is similar to what you propose with separate ssrc:s per source. Each discussed method also has pros and cons briefly documented. Having separate SSRC per source is what RTP calls using a RTP translator.

Yes, I would have liked to use that method. But we have an urgency in implementing the selected method in NG9-1-1 systems and in 3GPP IMS. And it is said that many current RTP implementations do not support multiple SSRCs in the same RTP session and even that RFC 3264 says that one m-section in sdp can only support one SSRC. However, RFC 4588 (FEC) section 8.8 shows an SSRC-multiplexing sdp example where the original media stream has one SSRC and the redundancy another within the same m-section. But that is of course no evidence that current RTP implementations support it.

RFC 8108 clarifies in section 3.3 that one of its applications is for combining multiple media sources of the same kind in the same RTP session. But it has the total goal of multiplexing also multiple media in the same RTP session. The corresponding sdp specification (with a much wider scope than we need) is draft-ietf-mmusic-sdp-bundle-negotiation and it is not supported by many current RTP implementations ( but maybe soon is because of its use in WebRTC).

Methods that could be considered but are not yet documented in draft-hellstrom-avtcore-multi-party-rtt-solutions are (excuse me if some look far fetched):

RFC 4588 FEC, using SSRC multiplexing if that works or session multiplexing if needed. In this case plain T.140 RTP would be sent from the mixer in one stream, with the ssrc of the mixer and csrc of the source, and in the redundancy stream the packets would be repeated (twice) with another ssrc in a small redundancy header.

RFC 8122 Comedia to improve reliability, but then I have not studied how to arrange for multi-party use.

draft-ietf-mmusic-t140-usage-data-channel using one WebRTC data channel per source.

RFC 8108 section 3.3 and draft-ietf-mmusic-sdp-bundle-negotiation

Avoiding solutions because of imagined limitations in current implementations may be a bad design criterium, so do you suggest that we rapidly look further into any of these or other options?

Thanks

Gunnar



Dale

-- 
Gunnar Hellstrm
GHAccess
gunnar.hellstrom@ghaccess.se
--------------31E464FC11F3D0320E7BA0A9-- From nobody Thu Apr 23 09:59:44 2020 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7686B3A0CDE for ; Thu, 23 Apr 2020 09:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=egensajt.se 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 SUVCghvbzf5U for ; Thu, 23 Apr 2020 09:59:38 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [193.42.159.246]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F26C3A0C41 for ; Thu, 23 Apr 2020 09:59:36 -0700 (PDT) Received: from [192.168.2.136] (h77-53-230-67.cust.a3fiber.se [77.53.230.67]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 8DBF620052; Thu, 23 Apr 2020 18:59:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1587661174; bh=d2yoZv9JbkVhy5kBi+eiRV/61zTP3IBzI+FmKtRFWtE=; h=Subject:From:To:Cc:References:Date:In-Reply-To:From; b=pyLjcwf+LJWaHMvGgyFf3zJzFbDiitZg5p+kqAl3iwA78tE48oY+Berq4wAanUiZA VJZsS22BEw00rwdA94tYTJSeFIuN+AvRJ1LUh53NMvrcgQMHYg8B/xZ2xmu1z6efIc 0EVUHe9HdMix5Ow1L7W7f1KRWn6IMb6wqpW96aJ0= From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= To: "Dale R. Worley" Cc: avtcore@ietf.org References: <87h7xbuebo.fsf@hobgoblin.ariadne.com> <8cec232d-1341-9d33-447a-49263c550a92@ghaccess.se> Message-ID: <2485532a-5ab8-94ae-0256-735da0542e22@ghaccess.se> Date: Thu, 23 Apr 2020 18:59:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <8cec232d-1341-9d33-447a-49263c550a92@ghaccess.se> Content-Type: multipart/alternative; boundary="------------F114FA113883D24FC5935F17" Content-Language: sv Archived-At: Subject: Re: [AVTCORE] Multi-party real-time text requiring new RTP payload type X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 16:59:43 -0000 This is a multi-part message in MIME format. --------------F114FA113883D24FC5935F17 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Dale, Here is a bit more on the use of multiple SSRC:s in an RTP session. https://mailarchive.ietf.org/arch/msg/avt/l1_r_4O4CYbjA_A9dPGX5vyEJ3Y/ In that old discussion, there was no idea proposed for how to signal a new participant in the conference. But there were multiple people preferring a solution with multiple SSRCs in the same RTP session. Similarly in this new discussion. There is a possibility to signal a new SSRC for the case that the RFC 4535 - 4575 - 4579 family for SIP centralised conference is used. Then the RFC 4575 SIP Notify sent by the focus can be specified to contain a text media member, with a src-id element containing the SSRC of the added participant. So, if current RTP implementations have an API that tells it to accept a new stream with SSRC=x then a mechanism with multiple SSRCs might be used. Do they have that? For simplicitly, the Payload Type numbers should be the same for all streams, otherwise there would need to be reInvites for every new participant, adding PT numbers to the m-line. I am afraid that we get into too many uncertain areas just as we did when discussing the same topic in 2011, so that we should return to the single stream solution. Regards Gunnar Den 2020-04-23 kl. 10:36, skrev Gunnar Hellstrm: > > Hi Dale, > > Thanks, a good question. It is the right time to consider which source > multiplexing and reliability method to select, now when we need to > introduce a new negotiation. > > More below > > Den 2020-04-23 kl. 04:27, skrev Dale R. Worley: >> I assume that there's a good reason why the case of redundant >> transmission of multi-party text isn't done by suitably interleaving the >> redundant packets of the serveral text sources (which can be separated >> by their SSRC values). I can't remember if this is a violation of the >> RTP rules, or perhaps it's just inefficient. But a quick read of the >> draft didn't mention why this approach doesn't work, and it seems like >> it would be a useful note to the reader. > Draft-hellstrom-avtcore-multi-party-rtt-source is intended to contain > the solution for the type of bridge used in NG9-1-1 and 3GPP IMS, > which seems to be based on the RFC4535 SIP centralised conference > framework. > Backgrounds and discussions of possible methods with a wider scope are > collected in > > draft-hellstrom-avtcore-multi-party-rtt-solutions > > > where section 4.2.1 is similar to what you propose with separate > ssrc:s per source. Each discussed method also has pros and cons > briefly documented. Having separate SSRC per source is what RTP calls > using a RTP translator. > > Yes, I would have liked to use that method. But we have an urgency in > implementing the selected method in NG9-1-1 systems and in 3GPP IMS. > And it is said that many current RTP implementations do not support > multiple SSRCs in the same RTP session and even that RFC 3264 says > that one m-section in sdp can only support one SSRC. However, RFC 4588 > (FEC) section 8.8 shows an SSRC-multiplexing sdp example where the > original media stream has one SSRC and the redundancy another within > the same m-section. But that is of course no evidence that current RTP > implementations support it. > > RFC 8108 clarifies in section 3.3 that one of its applications is for > combining multiple media sources of the same kind in the same RTP > session. But it has the total goal of multiplexing also multiple media > in the same RTP session. The corresponding sdp specification (with a > much wider scope than we need) is > draft-ietf-mmusic-sdp-bundle-negotiation and it is not supported by > many current RTP implementations ( but maybe soon is because of its > use in WebRTC). > > Methods that could be considered but are not yet documented in > draft-hellstrom-avtcore-multi-party-rtt-solutions > > are (excuse me if some look far fetched): > > RFC 4588 FEC, using SSRC multiplexing if that works or session > multiplexing if needed. In this case plain T.140 RTP would be sent > from the mixer in one stream, with the ssrc of the mixer and csrc of > the source, and in the redundancy stream the packets would be repeated > (twice) with another ssrc in a small redundancy header. > > RFC 8122 Comedia to improve reliability, but then I have not studied > how to arrange for multi-party use. > > draft-ietf-mmusic-t140-usage-data-channel using one WebRTC data > channel per source. > > RFC 8108 section 3.3 and draft-ietf-mmusic-sdp-bundle-negotiation > > Avoiding solutions because of imagined limitations in current > implementations may be a bad design criterium, so do you suggest that > we rapidly look further into any of these or other options? > > Thanks > > Gunnar > > >> Dale > -- > Gunnar Hellstrm > GHAccess > gunnar.hellstrom@ghaccess.se > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt -- Gunnar Hellstrm GHAccess gunnar.hellstrom@ghaccess.se --------------F114FA113883D24FC5935F17 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Dale,

Here is a bit more on the use of multiple SSRC:s in an RTP session.

https://mailarchive.ietf.org/arch/msg/avt/l1_r_4O4CYbjA_A9dPGX5vyEJ3Y/

In that old discussion, there was no idea proposed for how to signal a new participant in the conference. But there were multiple people preferring a solution with multiple SSRCs in the same RTP session. Similarly in this new discussion.

There is a possibility to signal a new SSRC for the case that the RFC 4535 - 4575 - 4579 family for SIP centralised conference is used. Then the RFC 4575 SIP Notify sent by the focus can be specified to contain a text media member, with a src-id element containing the SSRC of the added participant. So, if current RTP implementations have an API that tells it to accept a new stream with SSRC=x then a mechanism with multiple SSRCs might be used. Do they have that?

For simplicitly, the Payload Type numbers should be the same for all streams, otherwise there would need to be reInvites for every new participant, adding PT numbers to the m-line.

I am afraid that we get into too many uncertain areas just as we did when discussing the same topic in 2011, so that we should return to the single stream solution.

Regards

Gunnar


Den 2020-04-23 kl. 10:36, skrev Gunnar Hellstrm:

Hi Dale,

Thanks, a good question. It is the right time to consider which source multiplexing and reliability method to select, now when we need to introduce a new negotiation.

More below

Den 2020-04-23 kl. 04:27, skrev Dale R. Worley:
I assume that there's a good reason why the case of redundant
transmission of multi-party text isn't done by suitably interleaving the
redundant packets of the serveral text sources (which can be separated
by their SSRC values).  I can't remember if this is a violation of the
RTP rules, or perhaps it's just inefficient.  But a quick read of the
draft didn't mention why this approach doesn't work, and it seems like
it would be a useful note to the reader.
Draft-hellstrom-avtcore-multi-party-rtt-source is intended to contain the solution for the type of bridge used in NG9-1-1 and 3GPP IMS, which seems to be based on the RFC4535 SIP centralised conference framework.
Backgrounds and discussions of possible methods with a wider scope are collected in

draft-hellstrom-avtcore-multi-party-rtt-solutions

where section 4.2.1 is similar to what you propose with separate ssrc:s per source. Each discussed method also has pros and cons briefly documented. Having separate SSRC per source is what RTP calls using a RTP translator.

Yes, I would have liked to use that method. But we have an urgency in implementing the selected method in NG9-1-1 systems and in 3GPP IMS. And it is said that many current RTP implementations do not support multiple SSRCs in the same RTP session and even that RFC 3264 says that one m-section in sdp can only support one SSRC. However, RFC 4588 (FEC) section 8.8 shows an SSRC-multiplexing sdp example where the original media stream has one SSRC and the redundancy another within the same m-section. But that is of course no evidence that current RTP implementations support it.

RFC 8108 clarifies in section 3.3 that one of its applications is for combining multiple media sources of the same kind in the same RTP session. But it has the total goal of multiplexing also multiple media in the same RTP session. The corresponding sdp specification (with a much wider scope than we need) is draft-ietf-mmusic-sdp-bundle-negotiation and it is not supported by many current RTP implementations ( but maybe soon is because of its use in WebRTC).

Methods that could be considered but are not yet documented in draft-hellstrom-avtcore-multi-party-rtt-solutions are (excuse me if some look far fetched):

RFC 4588 FEC, using SSRC multiplexing if that works or session multiplexing if needed. In this case plain T.140 RTP would be sent from the mixer in one stream, with the ssrc of the mixer and csrc of the source, and in the redundancy stream the packets would be repeated (twice) with another ssrc in a small redundancy header.

RFC 8122 Comedia to improve reliability, but then I have not studied how to arrange for multi-party use.

draft-ietf-mmusic-t140-usage-data-channel using one WebRTC data channel per source.

RFC 8108 section 3.3 and draft-ietf-mmusic-sdp-bundle-negotiation

Avoiding solutions because of imagined limitations in current implementations may be a bad design criterium, so do you suggest that we rapidly look further into any of these or other options?

Thanks

Gunnar


Dale

-- 
Gunnar Hellstrm
GHAccess
gunnar.hellstrom@ghaccess.se

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt

-- 
Gunnar Hellstrm
GHAccess
gunnar.hellstrom@ghaccess.se
--------------F114FA113883D24FC5935F17-- From nobody Thu Apr 23 18:23:08 2020 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FCD3A0CCD for ; Thu, 23 Apr 2020 18:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.983 X-Spam-Level: X-Spam-Status: No, score=-0.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net 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 a1W4rYEDhRBy for ; Thu, 23 Apr 2020 18:23:04 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (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 4794C3A0CD3 for ; Thu, 23 Apr 2020 18:22:52 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-11v.sys.comcast.net with ESMTP id RmzSjzRnLhhLnRn3MjwWFN; Fri, 24 Apr 2020 01:22:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1587691372; bh=c/m8Gxmvx7o9EqkBhkv9BobFeMVmcK0qynX2D721cpU=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=oI3k+q7amkQ+aKXN/4bjLdHmwUT0fS6vnyYFIxa1+mLxFRHXfXtcVlATxsP5wfQYN ZmW1RYWbO9rjJTHNEIRQecZZ5iQU4TSyfI2DqJyr9RtM/ZZEBT4S/m9iR+wQPGOo4d giOR8rSprChcp1uJyFz/pDy548mDkiINm/5Ec3StX0koj8z4Sn5aeK47exv8u8Tpq3 7GyhTISKN35uDgdrCQGx1uWBAmuh8PFAlqpsA1UmqYu6rBBowVtREIEiSk6EH80F5N 6apD/4LhzFpGLyLRh5MPZZ9edtZS4lvwkVcwaUsgd3CVrsGX3bjnGaaWEFCRuhLant n3HIW8jVxWKmg== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-18v.sys.comcast.net with ESMTPA id Rn3JjnpRuC5ukRn3KjsnLq; Fri, 24 Apr 2020 01:22:51 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 03O1MnZF017893; Thu, 23 Apr 2020 21:22:49 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 03O1MmHZ017890; Thu, 23 Apr 2020 21:22:48 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Gunnar =?utf-8?Q?Hellstr=C3=B6m?= Cc: avtcore@ietf.org In-Reply-To: <8cec232d-1341-9d33-447a-49263c550a92@ghaccess.se> (gunnar.hellstrom@ghaccess.se) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 23 Apr 2020 21:22:48 -0400 Message-ID: <87y2qlu17b.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [AVTCORE] Multi-party real-time text requiring new RTP payload type X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 01:23:07 -0000 Gunnar Hellstr\"om writes: > Thanks, a good question. It is the right time to consider which source > multiplexing and reliability method to select, now when we need to > introduce a new negotiation. My idea wasn't that I had any better idea, but rather that there were some obvious ideas, and clearly, people who had studied the matter found that the obvious ideas were not the best. What I really meant was that it would be useful to give brief documentation why the obvious ideas aren't best. Dale From nobody Fri Apr 24 01:55:20 2020 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124FF3A1056 for ; Fri, 24 Apr 2020 01:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, 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=egensajt.se 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 uYNBci-ahIIL for ; Fri, 24 Apr 2020 01:55:14 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [193.42.159.246]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3175D3A1046 for ; Fri, 24 Apr 2020 01:55:09 -0700 (PDT) Received: from [192.168.2.136] (h77-53-230-67.cust.a3fiber.se [77.53.230.67]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id EFF3520097; Fri, 24 Apr 2020 10:55:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1587718507; bh=AJZp6yIc1ErbL0hWgZbpu+PhdA8YL1NHHSYzDM9Q5ig=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=mv+XLDBzSFMZonclszaFPJ6APYHseF+G0NcI2yRLX1HUkntzKiYTXY7m9NI3b8e8N CtUrbL0hsD7fHbGSWTcOpOFJKyNs4Pbah242HkiuxGq1zcLjL7LvgQzBoj9VxROgWM lNm7Tyc+TQGWCAQrNSd95GJ5jb2YuwMCLMmvL+ZM= To: "Dale R. Worley" Cc: avtcore@ietf.org References: <87y2qlu17b.fsf@hobgoblin.ariadne.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <23b9e138-b346-8fcb-4627-dee75aba79c4@ghaccess.se> Date: Fri, 24 Apr 2020 10:55:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <87y2qlu17b.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: sv Archived-At: Subject: Re: [AVTCORE] Multi-party real-time text requiring new RTP payload type X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 08:55:18 -0000 Den 2020-04-24 kl. 03:22, skrev Dale R. Worley: > Gunnar Hellstrom writes: >> Thanks, a good question. It is the right time to consider which source >> multiplexing and reliability method to select, now when we need to >> introduce a new negotiation. > My idea wasn't that I had any better idea, but rather that there were > some obvious ideas, and clearly, people who had studied the matter found > that the obvious ideas were not the best. What I really meant was that > it would be useful to give brief documentation why the obvious ideas > aren't best. Your question provided a good opportunity to review solution alternatives. Since the effort to specify multi-party real-time text aims at additions to current implementations of bridges and endpoints I think one requirement should be to keep the solution as close to the current solutions for the other media handles by these bridges and endpoints. NG9-1-1, NG 112 and 3GPP CONF services specify use of the RFC 4535 SIP conference framework. Adding new participants in that framework usually does not cause any new sdp interaction with the other participants, as long as no new media is added. Just a notification is sent. I assume that it can be good to keep that way of action also for adding participants with real-time text. Using the RTP mixer model adding just members in the CSRC lists is then the most simple model. So, this is yet another reason for why to keep to the RTP-mixer solution for the first specification in the draft-hellstrom-avtcore-multi-party-rtt-source draft. It might be followed by other selected cases in the draft-hellstrom-avtcore-multi-party-rtt-solutions draft, where WebRTC and use of sdp-bundle can be spcified, which are out of scope for the first case. Even if different solutions are discussed in the draft-hellstrom-avtcore-multi-party-rtt-solutions draft, I accept your point and will include a brief motivation also in the draft-hellstrom-avtcore-multi-party-rtt-source draft. Comments are very welcome about the reasoning. Thanks Gunnar > > Dale -- Gunnar Hellstrm GHAccess gunnar.hellstrom@ghaccess.se From nobody Fri Apr 24 07:38:02 2020 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11EDC3A07ED for ; Fri, 24 Apr 2020 07:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=8x8.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 Asfsw0uSp6uR for ; Fri, 24 Apr 2020 07:37:59 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 6806E3A0814 for ; Fri, 24 Apr 2020 07:37:59 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id n143so10331949qkn.8 for ; Fri, 24 Apr 2020 07:37:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=8x8.com; s=googlemail; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=4pvdzzSwufUxRM2GGIyzeo0/GNIL3ETiCzTr5ZDjVYw=; b=kABiKnpFphGw3nLd9q8Q5mdYa8PSJdkInB2WecgvKwW4c8vDc5jVq2W03I6xQYbFQL w6JMGlJqb/NOjJLW4bIHyKzsQaxuSny8H4XakXa4Kmgz3Zb2O8H3t32bHwZqtZMcUWQW e9/RuTv27kRK1kdEBI17S+tSwQWqXLk63ybPA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=4pvdzzSwufUxRM2GGIyzeo0/GNIL3ETiCzTr5ZDjVYw=; b=jUIrqNtHucsXAf7vu6FHaLF8Vm+fxDXqxQTa3VEoDLxwPIz/IjLRL67Q7nmA/VuqW/ yyXQ9AKzmpJsbjgS93gwllCU50V9B25IwL90wYoknBNzZzK/8NMkadjR0FnhUxZJWeXH pGsPML8k6iYqZZqFBVfs9fBUfUrjdkQrvM9XzoN9wbDt5NjWhNcVH/gPsyvDPulNJahg tjOXQmKTrltHsIFJm7UOYypVbK8AGcsqdD0Q4YIxs/S7FN0FHSNc5sgycud19lWm2B// BLUkNYiWxfrIU0LCaZ2oSGEIY89IY+8s8SOT6dv5NMN3q0DIUUgwTgkeuHHrfqz4ian8 dOaA== X-Gm-Message-State: AGi0PuZ//qujsmYzHiEOvaUOw9MMcVIc4dc6eYs0F1CA2jV/iWN27VYn +2xn9IZQ1p3yb2WLNZxe+BNSaUUyiO0= X-Google-Smtp-Source: APiQypKIBm7MSMS2fQuUEh6CGvgqHzQ0L6SUlHGFVLIbiskyP1XrkG2RbIzj9RLKtJkmON/+tRd2vw== X-Received: by 2002:a37:b03:: with SMTP id 3mr8719767qkl.67.1587739077913; Fri, 24 Apr 2020 07:37:57 -0700 (PDT) Received: from ?IPv6:2601:86:101:74d0:51c8:7797:f477:e0b9? ([2601:86:101:74d0:51c8:7797:f477:e0b9]) by smtp.gmail.com with ESMTPSA id l9sm3937442qth.60.2020.04.24.07.37.57 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Apr 2020 07:37:57 -0700 (PDT) From: Jonathan Lennox Content-Type: multipart/alternative; boundary="Apple-Mail=_C9CAB740-2EBA-4256-AD9B-292D9E6ADC90" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Fri, 24 Apr 2020 10:37:56 -0400 References: <24226.62407.692120.712033@paris.clic.cs.columbia.edu> To: avtcore@ietf.org In-Reply-To: <24226.62407.692120.712033@paris.clic.cs.columbia.edu> Message-Id: X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [AVTCORE] Multi-party real-time text requiring new RTP payload type (fwd) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 14:38:01 -0000 --Apple-Mail=_C9CAB740-2EBA-4256-AD9B-292D9E6ADC90 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 23, 2020, at 9:22 PM, worley@ariadne.com (Dale R. Worley) = wrote: >=20 > Gunnar Hellstr\"om writes: >> Thanks, a good question. It is the right time to consider which = source=20 >> multiplexing and reliability method to select, now when we need to=20 >> introduce a new negotiation. >=20 > My idea wasn't that I had any better idea, but rather that there were > some obvious ideas, and clearly, people who had studied the matter = found > that the obvious ideas were not the best. What I really meant was = that > it would be useful to give brief documentation why the obvious ideas > aren't best. As chair, my initial judgement was that there wasn=E2=80=99t any need to = publish the draft-hellstrom-avtcore-multi-party-rtt-solutions draft as = an RFC; I felt it was useful as a development document but didn=E2=80=99t = need to go through the whole IETF consensus process. That said, all decisions are of course subject to WG consensus, so if = you disagree and think this would be useful as an informational = document, let us know. =E2=80=94=20 Jonathan Lennox AVTCORE co-chair --Apple-Mail=_C9CAB740-2EBA-4256-AD9B-292D9E6ADC90 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Apr 23, 2020, at 9:22 = PM, worley@ariadne.com = (Dale R. Worley) wrote:

Gunnar Hellstr\"om <gunnar.hellstrom@ghaccess.se> writes:
Thanks, a good question. It is the right time = to consider which source
multiplexing and reliability = method to select, now when we need to
introduce a new = negotiation.

My idea wasn't = that I had any better idea, but rather that there were
some = obvious ideas, and clearly, people who had studied the matter found
that the obvious ideas were not the best.  What I really = meant was that
it would be useful to give brief = documentation why the obvious ideas
aren't best.

As = chair, my initial judgement was that there wasn=E2=80=99t any need to = publish the draft-hellstrom-avtcore-multi-party-rtt-solutions draft as = an RFC; I felt it was useful as a development document but didn=E2=80=99t = need to go through the whole IETF consensus process.

That said, all decisions = are of course subject to WG consensus, so if you disagree and think this = would be useful as an informational document, let us know.

=E2=80=94 
Jonathan Lennox
AVTCORE = co-chair

= --Apple-Mail=_C9CAB740-2EBA-4256-AD9B-292D9E6ADC90-- From nobody Fri Apr 24 12:38:07 2020 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646B63A0919 for ; Fri, 24 Apr 2020 12:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, 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=omnitorab.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 CTkaWFrjewWO for ; Fri, 24 Apr 2020 12:38:04 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80113.outbound.protection.outlook.com [40.107.8.113]) (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 8042A3A0ABB for ; Fri, 24 Apr 2020 12:37:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NY02DtqJP9o42FMYNJUaZq9xF53JvHMrZkgIFu1TzffURYivkm3Ik1P6c2YJOVN1655Bqrh9FFt5ZmWRue6kvuv/lxA9vFUdCwP98b4T+7Fg8QcYIPN5tTuCFR2QsAQfZbdWTQ99c+DEjKXYoc7KDQDooTHQMnCRaRoCAfNfUmkKhiTm4DUV+jR514IAVOsrsccA2HF+uQqraL6FsL93s0/uqZnD6MQtvHY/7gCEGj2VEQzPfqdl+R5BbgiIdeAKPEAClBU8QPwbjZLtLqbJymHO91j+uu9wLHuh6GX+jr3J6gj+HTepHsao2fkbUktQKEbkY4FrZIyws5eGTyYyzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i7Zt7+6Z6UbtqyULVgdXkTMarrvW8zPUhizqJE7gDlg=; b=GJpX8vdQjnEep4agkRklUXkHV8mUb3EGX4yxs1eF74OBl0S/22EdeppyOKBlJUahOocxu9GqjCeCr83bSsoJxkBdUYA2ZufLRs7PVC3ZYsw+2Zp8Vqc6tGZD11NKM9bk7qBLTfOET0oHckd1YY6/tynfCY357D8E+JV26KKE2zn61039ejDJcrj1/CHMGRn0ATdSIKrlavua8z3NMEaBZrVl1JkHzk/AD+lCXbgW5qXP6bNvP5dO9cuxOfpB1TEx+F6qghuNQ1TsX85iqfIWMrNmqe2hRIgEA9iZLGZ89GTBbHNwT8OFVakGXtO9LZkLDcSGiau81sAvZ4MOwVwHBg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=omnitor.se; dmarc=pass action=none header.from=omnitor.se; dkim=pass header.d=omnitor.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=omnitorab.onmicrosoft.com; s=selector2-omnitorab-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i7Zt7+6Z6UbtqyULVgdXkTMarrvW8zPUhizqJE7gDlg=; b=mGrJl4++RbIlHScDub6yemo5DTp7pwD5dSnxGNN+d9OxcCekU7azAs1eLdlxEjntdSLa54Lx4PYMOcdtodYEx8FVclofwhkTCkjc6NfCn8BtjNQGM3YnJWaHOhqi0f1AbBi9kNxi0Vsj+KtZYJ2v6JAyxUhj1LsXNIBh7xxJS2s= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gunnar.hellstrom@omnitor.se; Received: from DB8P193MB0614.EURP193.PROD.OUTLOOK.COM (2603:10a6:10:155::17) by DB8P193MB0600.EURP193.PROD.OUTLOOK.COM (2603:10a6:10:15f::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Fri, 24 Apr 2020 19:37:32 +0000 Received: from DB8P193MB0614.EURP193.PROD.OUTLOOK.COM ([fe80::dc41:5a1b:d575:f456]) by DB8P193MB0614.EURP193.PROD.OUTLOOK.COM ([fe80::dc41:5a1b:d575:f456%8]) with mapi id 15.20.2937.020; Fri, 24 Apr 2020 19:37:32 +0000 To: Jonathan Lennox , avtcore@ietf.org References: <24226.62407.692120.712033@paris.clic.cs.columbia.edu> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <17d0ec81-7b8c-bbd9-26bf-d11cff36f20f@omnitor.se> Date: Fri, 24 Apr 2020 21:37:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CC9B21C17A6AE5D7C4F74B0E" Content-Language: sv X-ClientProxiedBy: AM0PR01CA0134.eurprd01.prod.exchangelabs.com (2603:10a6:208:168::39) To DB8P193MB0614.EURP193.PROD.OUTLOOK.COM (2603:10a6:10:155::17) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.2.136] (77.53.230.67) by AM0PR01CA0134.eurprd01.prod.exchangelabs.com (2603:10a6:208:168::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Fri, 24 Apr 2020 19:37:32 +0000 X-Originating-IP: [77.53.230.67] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a0ca3fdf-2835-41b0-caa8-08d7e886eeaa X-MS-TrafficTypeDiagnostic: DB8P193MB0600: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 03838E948C X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P193MB0614.EURP193.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(39830400003)(396003)(346002)(376002)(366004)(136003)(26005)(36756003)(8936002)(31686004)(53546011)(33964004)(2906002)(956004)(2616005)(66556008)(508600001)(52116002)(966005)(66946007)(186003)(5660300002)(66476007)(16526019)(66574012)(31696002)(81156014)(6486002)(86362001)(316002)(16576012)(8676002); DIR:OUT; SFP:1102; Received-SPF: None (protection.outlook.com: omnitor.se does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: N6kxEcNMogo7gLzevyl2XOWBlOkACzFxY6XZ518GSutGykmeSGgc7NQKK/aiuyizzSA5SfurDS4b1NnBuiSHfzhIL//OpdqOz44IAXdeypQMQsGhhODheyO78pj7HYqhHu+WMX8wXeC7etLA0cWhWNGOqZm2MLUpNZMAPn/brCM3Zw97qoEz4Dpo4WYLyzY/f4nC/7Q1sDfCSPGjMBwVss+brIZ32CIJEpcwPqrSB3wYTZYyL+WTqUW/hab0tx/72mqI234c75nQPuPAtqJJ2VjknWb15A726dyeabnl63og5KZDb6asPsG6iiSckl6aSa3IROzyBPMuXakmFZSXd5JMfyWapl1BeNPlEJN0fPTNOLtS8jjw9sYVu2ePrvbVpjRMpUteLgQtOB59mLpt80IyBBtfBP2AceVhxO/H1u+H2aDgizOT9DWC9mm7uZKt9kZTBMD5VuLALA8Ty+7Nh/Nf6u5glON+AOiQJHrYthPrVb7UexASMm+RIGFuPaErTnctkPIzhO83kBgU1YJ2Mw== X-MS-Exchange-AntiSpam-MessageData: N2K0/buT85vmHzXRY/6GB6r6+EaHIUxsm4wdrKOgsL1QDTG6ceioqfhTRD2Scz6DUv11z2jrKGdBbW4rQaoYhAFmdp9XHspnAlCskhhGXx3jluOEPapFSV13ZqEpp0vV8NNaLUSlq+yCTLaoUzg9EsoZdrlDfnoTYQHzHJ6eIo4gA4j2BQvvjr/YY/hFY+Q9hNZhIpmaUFcgIY0kElG+tMqLxDCS6MzMD3SSXzjfm8ABX9zbyEgZzWNXXVIxci6EwGV6hO9cZYQVu0ItV3j6bqA7SohyrdaBy0dvnTABxgFCq4R9+V6y7ipCZwJtQumqLqVPUf/uS9kngCzTsuavOy6cMSAnWf4CKHyJrrTp4YBXKVahz47NrCaMQNTOrQG0RzdSWN62mYxM6FSnx+/PYnBMnHzw72lNqZ9YS9KUFcYGKp7fexTSpbp4Wqdv2iSn9lM1QLHVBUsGqNyEJLUabbQU12l18fhnZrv3LlekjpyJ27qEuSwix/iMfXtpc8Cs6O9i/1fomWNTlnLqMSMesIPUo4Q4E+SsIrVPmd0ywX422z4VV0A/mYILzu/kJrNx0xSxhFdvXcX/swk3LFMxxDjadp2NX8BHfbLOaxpPrO8R+4rWb1A1nwzna/cP79wqpuen/Pf0d4dspOop7WhLxk+X4DrIYpBh0/kalSXfdVsfvyMFNjohWqKUotvXfLksQPg4wSCUcJ2c72zUf2IuvdW0i9rR0dNzRJ1WZoV4GYlttm2wMcu7Nmtt+0XOgXm2ykyP6+xzOnrrVQYu95raVwb+SLNfCDPEuOcflbUuC7Q= X-OriginatorOrg: omnitor.se X-MS-Exchange-CrossTenant-Network-Message-Id: a0ca3fdf-2835-41b0-caa8-08d7e886eeaa X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Apr 2020 19:37:32.6723 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2df8b35f-363f-46b8-a0d1-ee9b1723225b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: O0xflKmfiHkeyq0+6W3uMIyr2QpgEKUDd5Rc96bjA48XAm30nr9WT5OsY3oVLujoGGmW4s2HgL0qBrCDfMy+5TkjGZPOX2Sg32XRkx+ZKB4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P193MB0600 Archived-At: Subject: Re: [AVTCORE] Multi-party real-time text requiring new RTP payload type (fwd) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 19:38:07 -0000 --------------CC9B21C17A6AE5D7C4F74B0E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Jonathan, Den 2020-04-24 kl. 16:37, skrev Jonathan Lennox: > >> On Apr 23, 2020, at 9:22 PM, worley@ariadne.com >> (Dale R. Worley) wrote: >> >> Gunnar Hellstr\"om > > writes: >>> Thanks, a good question. It is the right time to consider which source >>> multiplexing and reliability method to select, now when we need to >>> introduce a new negotiation. >> >> My idea wasn't that I had any better idea, but rather that there were >> some obvious ideas, and clearly, people who had studied the matter found >> that the obvious ideas were not the best.  What I really meant was that >> it would be useful to give brief documentation why the obvious ideas >> aren't best. > > As chair, my initial judgement was that there wasn’t any need to > publish the draft-hellstrom-avtcore-multi-party-rtt-solutions draft as > an RFC; I felt it was useful as a development document but didn’t need > to go through the whole IETF consensus process. > > That said, all decisions are of course subject to WG consensus, so if > you disagree and think this would be useful as an informational > document, let us know. I see a value in it, because it contains multi-party real-time text considerations for a few different technologies not at all covered in draft-hellstrom-avtcore-multi-party-rtt-source. E.g. WebRTC and multiple RTP stream cases. It is not as urgent as draft-hellstrom-avtcore-multi-party-rtt-source, but I thing it would be good to aim at publication eventually. Regards Gunnar > > — > Jonathan Lennox > AVTCORE co-chair > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt -- + + + + + + + + + + + + + + Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------CC9B21C17A6AE5D7C4F74B0E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Jonathan,

Den 2020-04-24 kl. 16:37, skrev Jonathan Lennox:

On Apr 23, 2020, at 9:22 PM, worley@ariadne.com (Dale R. Worley) wrote:

Gunnar Hellstr\"om <gunnar.hellstrom@ghaccess.se> writes:
Thanks, a good question. It is the right time to consider which source
multiplexing and reliability method to select, now when we need to
introduce a new negotiation.

My idea wasn't that I had any better idea, but rather that there were
some obvious ideas, and clearly, people who had studied the matter found
that the obvious ideas were not the best.  What I really meant was that
it would be useful to give brief documentation why the obvious ideas
aren't best.

As chair, my initial judgement was that there wasn’t any need to publish the draft-hellstrom-avtcore-multi-party-rtt-solutions draft as an RFC; I felt it was useful as a development document but didn’t need to go through the whole IETF consensus process.

That said, all decisions are of course subject to WG consensus, so if you disagree and think this would be useful as an informational document, let us know.

I see a value in it, because it contains multi-party real-time text considerations for a few different technologies not at all covered in draft-hellstrom-avtcore-multi-party-rtt-source.

E.g. WebRTC and multiple RTP stream cases.

It is not as urgent as draft-hellstrom-avtcore-multi-party-rtt-source, but I thing it would be good to aim at publication eventually.

Regards

Gunnar


— 
Jonathan Lennox
AVTCORE co-chair


_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt

-- 

+ + + + + + + + + + + + + + 

Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------CC9B21C17A6AE5D7C4F74B0E-- From nobody Sat Apr 25 01:54:06 2020 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6779D3A0E5F for ; Sat, 25 Apr 2020 01:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 OTHxrWW6ekMM for ; Sat, 25 Apr 2020 01:54:02 -0700 (PDT) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 A25E53A0E57 for ; Sat, 25 Apr 2020 01:54:02 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id s10so11635735iln.11 for ; Sat, 25 Apr 2020 01:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Lnh5zsRoMzDvOqLGHYeSHxOjaW8VK5GAylDhjCeM7sA=; b=I0beCJF9PwEU7us8RL0EWPOXAmzYsnZhlG04FLH463BDbTs0IxmjH+ywuyg2MRqK7n 78xTweMGuT0OOY8IRXZUA0SMwMbN4TpAICCPMdfC4VxK5rbkYWylluwO450GFG36a5s3 FuImg5uL8nMlmRriiMwm5KqbKjNzmJDQbodPhV9M0VzxJFoXVMAwVj3/wQ4JqUZsX3wp o3d18NAP0GceRLXGWp4f1yg6MALyT2Wl1C1W+0ZxEpcXso1xAl7ddRz+VucK91Pkf/Ie Y8x1pzAQCsOi7NxVoGIMwlRUb8v3OXszClBfRU6vgc6xRMaf3Vur9+NMdNJ67hX5MclW fZtQ== 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=Lnh5zsRoMzDvOqLGHYeSHxOjaW8VK5GAylDhjCeM7sA=; b=j0GHfP4gPFggqBy8DKkhp/fuAvgKP+qrJ2oEO7RMO7MiG06unMAiM8qh9bTyPCzJp+ 6va61n3Amb5uwBkX19zmOOUTHmhuj4Oo8QFiuj9RUdP0K0sQB5yvjyT0K61hImMV8mYx L5boL/pcdsz0W8BxTV8yCw7WT++X2OHVrq0vry3XeIzts5+nbRy4GBoT96F7CsMPUdrY 9u6+/yr5kM5QRGJ+Nd9RLbWSy/l0XSYSIlFEvGk8wMdmId6aJ+7NZ1q/rTJsRqBO/I9v Lb6LhWBpZ2GhP+PufC8HcFh47yNYC86HnNhHg9eYIRtGShEu/nyIm5AZbs3ScVQtB9w7 VTVw== X-Gm-Message-State: AGi0PubjKZM/HyHlaTu7bBhbxFFo1DNld2viFgz2OicMlkWAeAIzOdiE c6vblEx2sv3/+Mv7yk+oAl1LcMgxp85of1WnSaQ= X-Google-Smtp-Source: APiQypJvbG3fMp79yBRiknRdqudpmLPlVp6rXK/ILD5GvYqfhNIoPw9ydnrfBwzUO5faC+xcdB+cvQzSvcdtp19YzNA= X-Received: by 2002:a92:485b:: with SMTP id v88mr12567066ila.271.1587804842038; Sat, 25 Apr 2020 01:54:02 -0700 (PDT) MIME-Version: 1.0 References: <591BF32C-0FBD-4E24-BC99-77CB7AC6DE0F@8x8.com> In-Reply-To: From: Alexandre GOUAILLARD Date: Sat, 25 Apr 2020 10:53:51 +0200 Message-ID: To: Brian Rosen Cc: Jonathan Lennox , avt@ietf.org Content-Type: multipart/alternative; boundary="000000000000951d1105a4199f88" Archived-At: Subject: Re: [AVTCORE] Call for adoption: RTP mixer formatting of multi-party real-time text X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2020 08:54:04 -0000 --000000000000951d1105a4199f88 Content-Type: text/plain; charset="UTF-8" We support adoption and will try to carve out time to provide review. We plan to implement at one point, hopefully in a timely manner to provide implementor feedback. On Tue, Apr 21, 2020 at 8:51 PM Brian Rosen wrote: > I support the adoption of this work and will provide reviews and comments > on the text. > > Brian > > > On Apr 15, 2020, at 2:31 PM, Jonathan Lennox > wrote: > > > > Hi all, > > > > The working group chairs are asking for adoption of a new milestone for > RTP mixer formatting of multi-party real-time text, with > draft-hellstrom-avtcore-multi-party-rtt-source-03 as the basis for the > initial WG document. > > > > Please respond by Wednesday, April 29th with whether you agree with this > adoption. > > > > Technical comments comments on document itself are also always welcome, > of course! > > > > Thanks, > > > > Jonathan Lennox > > AVTcore co-chair > > > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- Alex. Gouaillard, PhD, PhD, MBA ------------------------------------------------------------------------------------ President - CoSMo Software Consulting, Singapore ------------------------------------------------------------------------------------ sg.linkedin.com/agouaillard - --000000000000951d1105a4199f88 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We support adoption and will try to carve out time to prov= ide review.
We plan to implement at one point, hopefully in a timely ma= nner to provide implementor feedback.

On Tue, Apr 21, 2020 at 8:51 PM = Brian Rosen <br@brianrosen.net&= gt; wrote:
I support the adoption of this work an= d will provide reviews and comments on the text.

Brian

> On Apr 15, 2020, at 2:31 PM, Jonathan Lennox <jonathan.lennox@8x8.com> wro= te:
>
> Hi all,
>
> The working group chairs are asking for adoption of a new milestone fo= r RTP mixer formatting of multi-party real-time text, with draft-hellstrom-= avtcore-multi-party-rtt-source-03 as the basis for the initial WG document.=
>
> Please respond by Wednesday, April 29th with whether you agree with th= is adoption.
>
> Technical comments comments on document itself are also always welcome= , of course!
>
> Thanks,
>
> Jonathan Lennox
> AVTcore co-chair
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt


--
Alex. Gouaillard, PhD, PhD, MBA
-------------= -----------------------------------------------------------------------
President - CoSMo Software Consulting, Singapore
---------= ---------------------------------------------------------------------------=

--000000000000951d1105a4199f88-- From nobody Tue Apr 28 09:51:16 2020 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14423A0659 for ; Tue, 28 Apr 2020 09:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=comtechtel.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 Ywb3XxCI9QO5 for ; Tue, 28 Apr 2020 09:51:04 -0700 (PDT) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2130.outbound.protection.outlook.com [40.107.91.130]) (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 1CC5B3A0433 for ; Tue, 28 Apr 2020 09:51:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QjPDiLcfeyl37EbcYxTGpEfGJFaDU8o3U6d0l98s4oRIAAvwHfJzkzTASq9LJxCXG5rEsmzge3Bzz7kBW7Vg0WVN+4rYZdvXzbbxZEwZC7ocnypc4H/2cVsQVgKko4z8yTza10D5updxtb/lBTSSsSfuzPJ3tZYDftbiCjmdctZQIoGFRNXufdUOa1fzJNYqEKTfTnICEZnlx1Jz5OWSbhjAsFbKrDJ1fWF0hyZQW1t0miJWr0zYuMuKvjvDhe2JNOpDbpFLTWiFqsmxHS69CB9eUUAFmBdDn6y8bLCWkU/hs5ICFDGAffvXsF/ddBsuwCOmAT/iIvgKqBBnagDaqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=10LBBo9aFgmCFSMOeFFe3A2pkFc+yftDqMFKmkcFgas=; b=Td7zXtZHa1amHvIndODyZvUGhgHdanEy+1T/ZwzUn/doTzT7FzDDODFuR4iHoqNqYssfudcsamPV/PSHi/iA0StUlITvO2sTmpXpvtx6jJ+wTjV6Y0o7ZacX4ZAElJVhpaoANYvlww8sXxXAzPjlFWGqANxXBpLrAqd7VjEdS9nUIo9DV2UGgMX/qD8L3+TrKRkQwG10aoiahEBtcvgQxXZ8M3Ye2V84gxyhJYaVaNiVBO8zumfgQw7IZ5w8o5vXAgd4mZVuuqng3OtXhZNtPdqFeOlhJ+iWrHf9+8igxC1C5CgxIxOfX8FT3TdloDDQBKuSZW8pfAAxhQ7zNn8T1Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comtechtel.com; dmarc=pass action=none header.from=comtechtel.com; dkim=pass header.d=comtechtel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comtechtel.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=10LBBo9aFgmCFSMOeFFe3A2pkFc+yftDqMFKmkcFgas=; b=nsEtsgD0/79XbPVpCRxn2K/zIliEE7mJw1qwTwQ+9JL5ZUoj207AbV/Y60KCllOJrgwczIZ0BxaPSf0hYHZIkY4XKWEkV3GgOeiB6kuGqKQ7qiXoZT9vfUIiSje30WS+A3TGQVQ9A2l3vVWYKexEoWbe8LqWyi9DWZjTTm0WLnU= Received: from MW2PR0901MB3756.namprd09.prod.outlook.com (2603:10b6:302:b::31) by MW2PR0901MB3721.namprd09.prod.outlook.com (2603:10b6:302:7::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Tue, 28 Apr 2020 16:51:02 +0000 Received: from MW2PR0901MB3756.namprd09.prod.outlook.com ([fe80::118e:ca70:232f:86df]) by MW2PR0901MB3756.namprd09.prod.outlook.com ([fe80::118e:ca70:232f:86df%7]) with mapi id 15.20.2937.023; Tue, 28 Apr 2020 16:51:02 +0000 From: Roger Marshall To: "avt@ietf.org" CC: "jonathan.lennox@8x8.com" Thread-Topic: Call for adoption: RTP mixer formatting of multi-party real-time text Thread-Index: AdYdfQVfaKux38IkTWyHFrEIt3azJw== Date: Tue, 28 Apr 2020 16:51:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=comtechtel.com; x-originating-ip: [70.35.116.220] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3157c491-3452-4d94-8260-08d7eb9455fd x-ms-traffictypediagnostic: MW2PR0901MB3721: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 0387D64A71 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW2PR0901MB3756.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(396003)(39860400002)(366004)(136003)(376002)(346002)(4326008)(8676002)(33656002)(9686003)(86362001)(8936002)(6916009)(478600001)(316002)(71200400001)(55016002)(52536014)(7696005)(5660300002)(76116006)(186003)(64756008)(66476007)(66946007)(26005)(2906002)(6506007)(66556008)(66446008); DIR:OUT; SFP:1102; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: t6749pQjFKo96mEm3NKpqQ+rlv2l2Mxb0/7N94e1+8akWkDHY43fBNh5G6PxIKa6LfnYvfvex3xPkBT4NT8jZ2/hTMdgjL585FS7mc21mr9res3dzXt28RcNlxufpS62/IPhR5939EYvClTzC3ScBT7IHpysgGMMkzAsGTU+NBqxbRGhoYhZ8sEyLHSG89iXMS+Fzelr0qxxUHBSInagu5ccXZPYId9Y9st3sZR17GNzdZX3rfVE+amNPYjml+feAq5pTNkIZVUN6xAc/+YUxC0nyGRdVJaVOAqNPfMZixIGY/Obx48NXKsQm8Bua6sPUf1BV4XIK00dBOVZj6o9qoSygcYWu8FXRHAvSj92fo4t1ef6Xd3cForqYhja7uiB0D9MrmuEfRcXNLmsEskLUZovdKVj0OTCknkZYTUIM9DoDHy6h8ZFim37BcTxP4wjtAnLZd/YFxc49nTPSy5Q5dLaI4lBlaWzBAAqkFpuyud4XC3u9ORncd1tKkxAkk2kS6/u+qgjGC2Kos+S3zO8lw== x-ms-exchange-antispam-messagedata: QC25YkrOsHchnJuRH+SxjliTrNBv8Trcz5WM6fDzDCXXf9rq5rT6WMxeeJ9Jcxger96NAPlrEfrqJC6Jxle3SM7xFPKdAZmY1RO5IQWGK8+RBP/y5rqX25OhS2kQe+ocPsnsOmogOji0j60D4qHp+FYBWv0cqxWv+zP/4UOS4NOZEXbr3hUo4gqK0oXO+nwsy7o2TWj5YZJqXP2glnKpvCGj+SIH0y5mp08yVHJ8nng2e/yR6N64oSWuu9SZJvOdNyomCuZwiJDuwwSR4yLK+bwOjqqNQjBsCfyNPmuesNLZGkzAQ79a96aLzdrvs9FxQ/PLpnYi4fCKgGpJdUISlgvVODjmysET95v1Goyj3XTddlUEWD6ykSGQVSpU1X6vTPGKL92pH32hHXTYNKkTBBQq1+rK6j0WKJttCKt0uP3zZ17aqUYZfoXAkQb7VZEsY1k4/XpFbsXpXGCy+57AFgkBzeAU5qUgqlBfpPJ+pCIH3q68t8vpYEYyyfdReCVMjOMkibZy49g2ie0ygcfcOOyKZHSejjXMAqMzfbJmYezWHKaw5wotKa9IqJ+4zjVjXgzMvZ/IwN8yltBblGfyj5nNXvQ4PMORtgiH8RqDcFne+NhVe/Qy2BStHWb/hOhhgSUbJs+l2k2W342iXaCl1dobHH8cIvY5APTa9OVPL8YiXqkyEwLlzZTumdzLeJ6Abbq+00aYbQWd/xxGJD0FgaCWw2ij+XYAGSsC3hwvLoT/dDEMBUb8HNFUy3dWQ0GxAYiKrfszvbH1w49ERjIhh4CG46WitaJUv7HcVzJQ2Ik= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW2PR0901MB37567FD3EE33E2DB36354859F4AC0MW2PR0901MB3756_" MIME-Version: 1.0 X-OriginatorOrg: comtechtel.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3157c491-3452-4d94-8260-08d7eb9455fd X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2020 16:51:02.4390 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a9a26e69-6ae0-40c1-bd80-1ca6cc677828 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: iuz8irgLijr5C7eR8B9AQJTcSpa1LHH5jn/p/XBoev8r4aWuDslA8e1g+NozaJgoCvhGvVgqnyqhGIeOtG/mk664UA9W01ShA6thPOESCek= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR0901MB3721 Archived-At: Subject: [AVTCORE] Call for adoption: RTP mixer formatting of multi-party real-time text X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 16:51:13 -0000 --_000_MW2PR0901MB37567FD3EE33E2DB36354859F4AC0MW2PR0901MB3756_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support adopting this work in avtcore. I plan on being active in the com= menting process for the documents. -roger. Roger Marshall | Sr. Member of Technical Staff | Safety & Security Technolo= gies | Comtech Telecommunications Corp. | 2401 Elliott Ave, 2nd floor, Seat= tle, WA 98121 | 206.792.2424 (o) | 206.240.3556 (m) | roger.marshall@comtec= htel.com | www.comtechtel.com | @ComtechSST NOTICE TO RECIPIENT: This email, including attachments, may contain informa= tion which is confidential, proprietary, attorney-client privileged and / o= r controlled under U.S. export laws and regulations and may be restricted f= rom disclosure by applicable State and Federal law. Nothing in this email s= hall create any legal binding agreement between the parties unless expressl= y stated herein and provided by an authorized representative of Comtech Tel= ecommunications Corp. or its subsidiaries. If you are not the intended reci= pient of this message, be advised that any dissemination, distribution, or = use of the contents of this message is strictly prohibited. If you received= this message in error, please notify us immediately by return email and pe= rmanently delete all copies of the original email and any attached document= ation from any computer or other media. --_000_MW2PR0901MB37567FD3EE33E2DB36354859F4AC0MW2PR0901MB3756_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support adopting this work in avtcore.  I pla= n on being active in the commenting process for the documents.

 

-roger.

 

Roger Marshall | Sr. Member of Technical Staf= f | Safety & Security Technologies | Comtech Telecommunications Corp. |= 2401 Elliott Ave, 2nd floor, Seattle, WA 98121 | 206.792.2424 (o) | 206.24= 0.3556 (m) | roger.marshall@comtechtel.com | www.comte= chtel.com | @ComtechSST

 

NOTICE TO RECIPIENT: This email, including attachments, may contain informa= tion which is confidential, proprietary, attorney-client privileged and / o= r controlled under U.S. export laws and regulations and may be restricted f= rom disclosure by applicable State and Federal law. Nothing in this email shall create any legal binding agre= ement between the parties unless expressly stated herein and provided by an= authorized representative of Comtech Telecommunications Corp. or its subsi= diaries. If you are not the intended recipient of this message, be advised that any dissemination, distribution= , or use of the contents of this message is strictly prohibited. If you rec= eived this message in error, please notify us immediately by return email a= nd permanently delete all copies of the original email and any attached documentation from any computer or = other media. --_000_MW2PR0901MB37567FD3EE33E2DB36354859F4AC0MW2PR0901MB3756_--