From nobody Sun Jan 8 20:56:21 2017 Return-Path: X-Original-To: payload@ietf.org Delivered-To: payload@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7591294CA; Sun, 8 Jan 2017 20:56:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148393777669.773.16545062980045822405.idtracker@ietfa.amsl.com> Date: Sun, 08 Jan 2017 20:56:16 -0800 Archived-At: Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-ancillary-07.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 04:56:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads of the IETF. Title : RTP Payload for SMPTE ST 291 Ancillary Data Author : Thomas G. Edwards Filename : draft-ietf-payload-rtp-ancillary-07.txt Pages : 16 Date : 2017-01-08 Abstract: This memo describes a real-time transport protocol (RTP) payload format for the Society of Motion Picture and Television Engineers (SMPTE) Ancillary data, as defined by SMPTE ST 291-1. SMPTE Ancillary data is generally used along with professional video formats to carry a range of ancillary data types, including time code, Closed Captioning, and the Active Format Description (AFD). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-ancillary/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-payload-rtp-ancillary-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-ancillary-07 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 Tue Jan 17 11:59:59 2017 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40FD7127077 for ; Tue, 17 Jan 2017 11:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=foxgroupinc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQgjhS4q8BLj for ; Tue, 17 Jan 2017 11:59:54 -0800 (PST) Received: from mx0a-00195501.pphosted.com (mx0a-00195501.pphosted.com [67.231.149.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED448127A91 for ; Tue, 17 Jan 2017 11:59:54 -0800 (PST) Received: from pps.filterd (m0072270.ppops.net [127.0.0.1]) by mx0a-00195501.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v0HJxlrR010441; Tue, 17 Jan 2017 11:59:54 -0800 Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0118.outbound.protection.outlook.com [207.46.163.118]) by mx0a-00195501.pphosted.com with ESMTP id 281hn0343f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 17 Jan 2017 11:59:54 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=FoxGroupInc.onmicrosoft.com; s=selector1-fox-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rG3vG2TUN6YmhX8p/JN7YhOvDlvGz0ldXqF7cup2sxI=; b=sPwG5Xs6k82Sz30tylel2PjCQN3tFCc09Xl5NV0QgJgMSV/NtotJAwb6sgQ3Irv7V7ETKdPvHm80/XwTAIIJc6wh9zhnvcBF2pcEi2+ebHFJGAQDRJ6D+hLG6WMC6Pw047/yLOT5E/4riIG9u9WiEw3desK63cH0RvPInxiWTQY= Received: from CY4PR05MB3109.namprd05.prod.outlook.com (10.172.157.7) by CY4PR05MB3109.namprd05.prod.outlook.com (10.172.157.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Tue, 17 Jan 2017 19:59:52 +0000 Received: from CY4PR05MB3109.namprd05.prod.outlook.com ([10.172.157.7]) by CY4PR05MB3109.namprd05.prod.outlook.com ([10.172.157.7]) with mapi id 15.01.0860.008; Tue, 17 Jan 2017 19:59:52 +0000 From: Thomas Edwards To: "payload@ietf.org" Thread-Topic: summary of changes to draft-ietf-payload-rtp-ancillary from -06 to -07 Thread-Index: AQHScPxE6yHFhNBl60aSHbW1p5ZbWA== Date: Tue, 17 Jan 2017 19:59:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [216.205.246.232] x-ms-office365-filtering-correlation-id: ae333540-018b-4044-352c-08d43f1366c6 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY4PR05MB3109; x-microsoft-exchange-diagnostics: 1; CY4PR05MB3109; 7:8/IH5tg4/o2JEQD1Mh7UXMCVe3iRyQqtjTupZ0YMR5C7p7nIqsHsOebJdcbbFk1gr4Jo0Tl9GDAfkzF6Ct59ae5ipVR6ly5ObNmt8ad3Olkai9lbmvYM6BnOleoZG+WmIVtWgbDEOhd4hgmP7RnD8HjjNhiLlHfq1TGwzs6ACtjxRZkdNByH6BwnnH4MXoibYdXqQ3Tbm4nFuHGgq/nGz5BkaapVl8mFbaqQNZv1QI3jcSqtC1Fw1YifYtCvmbyxb8n3dfXbv38fYWmS0K37OIR42DauLxdVEhVKfCTjV0mMHw6foVYQ1DVXsO6KKsjFckOyeH9+uoG9aGEq6Tv8Vy0BgdNnwcv0dr53fKJd6Caqny7Y3QYE2G4f/P30mD/DO5D/ofwjDNvyoNnQz+QMK5JOtdCLvLuzshgLfCSxdWgQx++shKtTktM8SZDRQn0tQeSWfD0CzKbCNgK0Tn5t1A== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(21748063052155)(177823376758907); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:CY4PR05MB3109; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3109; x-forefront-prvs: 01901B3451 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39840400002)(39410400002)(39860400002)(39450400003)(39850400002)(189002)(199003)(92566002)(4001350100001)(8676002)(102836003)(68736007)(106116001)(105586002)(97736004)(6916009)(106356001)(36756003)(110136003)(6436002)(50986999)(53936002)(33656002)(189998001)(38730400001)(54356999)(6486002)(5660300001)(2900100001)(77096006)(5640700003)(25786008)(101416001)(81166006)(82746002)(230783001)(3280700002)(83506001)(2351001)(3846002)(1730700003)(6506006)(8936002)(81156014)(83716003)(6306002)(6116002)(2906002)(66066001)(7736002)(2501003)(6512007)(122556002)(54896002)(99286003)(4326007)(3660700001)(86362001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR05MB3109; H:CY4PR05MB3109.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fox.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_FD97EAAF805C4D0DAA1A5ED468124518foxcom_" MIME-Version: 1.0 X-OriginatorOrg: fox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2017 19:59:52.5024 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: de99ade3-81db-4070-ae0d-3c1562041b30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3109 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-17_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701170264 Archived-At: Subject: [payload] summary of changes to draft-ietf-payload-rtp-ancillary from -06 to -07 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 19:59:58 -0000 --_000_FD97EAAF805C4D0DAA1A5ED468124518foxcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBQYXlsb2FkIFdHLA0KDQpJIHdvdWxkIGxpa2UgdG8gcmVwb3J0IHRoZSBmb2xsb3dpbmcg c3VtbWFyeSBvZiBjaGFuZ2VzIGJldHdlZW4gZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1hbmNpbGxh cnktMDYgYW5kIC0wNy4gIFRoaXMgaW5jbHVkZXMgY29tbWVudHMgZnJvbSB0aGUgSUVURiBMYXN0 IENhbGwsIGFzIHdlbGwgYXMgcmV2aWV3cyBmcm9tIFNFQ0RJUiwgT1BTRElSLCBhbmQgR0VOQVJU Lg0KDQoxKSBDaGFuZ2UgaW4gdGhlIGRldGFpbHMgb2YgcGF5bG9hZCBiaXQgZm9ybWF0DQoNClNl dmVyYWwgcG90ZW50aWFsIGltcGxlbWVudGVycyBub3RlZCB0aGF0IC0wNiBjb250YWluZWQgdHdv IHJlc2VydmVkIGJpdHMgYWZ0ZXIgRGF0YV9Db3VudCB0byAzMi1iaXQgd29yZCBhbGlnbiB0aGUg VXNlcl9EYXRhX1dvcmRzLiAgSXQgd2FzIHN1Z2dlc3RlZCB0aGF0IHRoaXMgdW5uZWNlc3Nhcmls eSBicmVha3MgdXAgdGhlIEFOQyBwYWNrZXQgYml0cyBhcyBleHByZXNzZWQgaW4gU0RJLCBhbmQg bW9yZW92ZXIgdGhlIHJlc2VydmVkIGJpdHMgZG8gbm90IGFjdHVhbGx5IGFjaGlldmUgMzItYml0 IHdvcmQgYWxpZ25tZW50IG9mIFVzZXJfRGF0YV9Xb3JkcyBvbiB0aGUgc2Vjb25kIGFuZCBmb2xs b3dpbmcgQU5DIGRhdGEgcGFja2V0cyBjYXJyaWVkIGluIHRoZSBwYXlsb2FkLg0KDQpBZnRlciBz dWJzdGFudGlhbCBpbnB1dCBmcm9tIHBvdGVudGlhbCBpbXBsZW1lbnRlcnMsIHRoZSBmb3JtYXQg d2FzIGNoYW5nZWQgdG8ga2VlcCB0aGUgU0RJIEFOQyBkYXRhIHBhY2tldCBjb250aWd1b3VzLCBh bmQgdG8gYWRkIHJlc2VydmVkIGJpdHMgdG8gZW5zdXJlIHRoYXQgdGhlIHN0YXJ0IG9mIGhlYWRl cnMgYmVmb3JlIGVhY2ggQU5DIGRhdGEgcGFja2V0IGlzIDMyLWJpdCB3b3JkIGFsaWduZWQuDQoN ClRoZSBwYXlsb2FkIGZvcm1hdCBleGFtcGxlIHdhcyBlbmxhcmdlZCB0byBjbGVhcmx5IHNob3cg dGhlIHByb3BlciBjYXJyaWFnZSBvZiB0d28gQU5DIGRhdGEgcGFja2V0cyBvZiBkaWZmZXJlbnQg bGVuZ3Rocy4NCg0KMikgQSBIb3Jpem9udGFsX09mZnNldCB2YWx1ZSBvZiAweEZGRSBub3cgaW5k aWNhdGVzIHRoYXQgdGhlIEFOQyBkYXRhIG1heSBiZSBwbGFjZWQgaW50byBhbnkgbGVnYWwgYXJl YSBvZiBIQU5DLCBhbmQgc2ltaWxhcmx5IGEgTGluZV9OdW1iZXIgdmFsdWUgb2YgMHg3RkUgbm93 IGluZGljYXRlcyB0aGF0IHRoZSBBTkMgZGF0YSBtYXkgYmUgcGxhY2VkIGludG8gYW55IGxlZ2Fs IGFyZWEgb2YgVkFOQy4NCg0KMykgVGhlIOKAnEPigJ0gYml0IGlzIG5vdCB0byBiZSBpZ25vcmVk IGV2ZW4gaWYgdGhlIEFOQyBkYXRhIHBhY2tldCBpcyBjb25zaWRlcmVkIHRvIGJlIGNhcnJpZWQg d2l0aG91dCBhbnkgc3BlY2lmaWMgbG9jYXRpb24gd2l0aGluIHRoZSBmaWVsZCBvciBmcmFtZS4g IEFOQyBwYWNrZXRzIGFyZSBhbHdheXMgZGVmaW5lZCB0byBiZSBjYXJyaWVkIGluIHRoZSBjb2xv ciBkaWZmZXJlbmNlIG9yIGx1bWEgY2hhbm5lbC4NCg0KNCkgQW4gb3B0aW9uYWwgTWVkaWEgVHlw ZSBwYXJhbWV0ZXIgTGlua051bWJlciB3YXMgYWRkZWQgZm9yIHRoZSBpZGVudGlmaWNhdGlvbiBv ZiBhIGxpbmsgbnVtYmVyIGluIGR1YWwgYW5kIHF1YWQgbGluayBTREkgYXBwbGljYXRpb25zLg0K DQo1KSBNYWRlIGl0IGNsZWFyIHRoYXQgTXVsdGlwbGUgRElEX1NESUQgcGFyYW1ldGVycyBkbyBu b3QgaW1wbHkgYW55IHBhcnRpY3VsYXIgb3JkZXJpbmcgb2YgdGhlIGRpZmZlcmVudCB0eXBlcyBv ZiBBTkMgcGFja2V0cyBpbiB0aGUgc3RyZWFtLg0KDQo2KSBBZGRlZCBub3RlIHRoYXQgdGhlIENo ZWNrc3VtX1dvcmQgaXMgdW5saWtlbHkgdG8gcHJvdmlkZSBhIHBheWxvYWQgaW50ZWdyaXR5IGNo ZWNrIGluIGNhc2Ugb2YgYSBkaXJlY3RlZCBhdHRhY2suDQoNCkkgd2lsbCBhZGQgdGhhdCAtMDcg aGFzIGJlZW4gcHJlc2VudGVkIHRvIHRoZSBBbGxpYW5jZSBmb3IgSVAgTWVkaWEgU29sdXRpb25z IChBSU1TKSBUZWNobmljYWwgV29ya2luZyBHcm91cCwgd2hpY2ggaGFkIG5vIHN1YnN0YW50aXZl IGNvbW1lbnRzLiAgSG93ZXZlciwgdGhlIEFJTVMgVFdHIGNvbnNlbnN1cyB3YXMgdG8gYXNrIGZv ciBhIGRlbGF5IGluIG1vdmluZyAtMDcgdG8gUkZDIHB1Ymxpc2hpbmcgdW50aWwgdGhlIFZpZGVv IFNlcnZpY2VzIEZvcnVtIC8gSm9pbnQgVGFzayBGb3JjZSBvbiBOZXR3b3JrZWQgTWVkaWEgaW50 ZXJvcCBldmVudCBGZWJydWFyeSA2LTEwIGF0IHRoZSBGb3ggU3BvcnRzIGZhY2lsaXR5IGluIEhv dXN0b24sIFRYLiAgVGhlIGZlZWxpbmcgd2FzIHRoYXQgdGhlIC0wNyB2ZXJzaW9uIGNvdWxkIGJl IGZ1bGx5IGV4ZXJjaXNlZCBieSB0aGUgcGFydGljaXBhbnRzIHRoZXJlLCBhbmQgYW55IHVuZXhw ZWN0ZWQgc2hvcnRjb21pbmdzIHJhcGlkbHkgaWRlbnRpZmllZC4NCg0KQmFzZWQgb24gdGhpcyBm ZWVkYmFjayBmcm9tIHRoZSBBSU1TIFRXRywgSSBoYXZlIGZvcndhcmRlZCB0aGlzIHJlcXVlc3Qg dG8gdGhlIElFU0cgcmVzcG9uc2libGUgQUQsIEJlbiBDYW1wYmVsbC4NCg0KLVRob21hcw0KDQot LQ0KVGhvbWFzIEVkd2FyZHMNClZQIEVuZ2luZWVyaW5nICYgRGV2ZWxvcG1lbnQNCkZPWCBOZXR3 b3JrcyBFbmdpbmVlcmluZyBhbmQgT3BlcmF0aW9ucw0KdGhvbWFzLmVkd2FyZHNAZm94LmNvbQ0K UGhvbmU6ICsxLjMxMC4zNjkuNjY5Ng0KMTAyMDEgV2VzdCBQaWNvIEJsdmQuDQpMb3MgQW5nZWxl cywgQ0EgOTAwMzUNCg== --_000_FD97EAAF805C4D0DAA1A5ED468124518foxcom_ Content-Type: text/html; charset="utf-8" Content-ID: <8BBF9F79DB67F04E950CBC05077CD9EC@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJy aTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3Nl Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lu cw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1V UyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5EZWFyIFBheWxvYWQgV0csPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5JIHdvdWxkIGxpa2UgdG8gcmVwb3J0IHRoZSBmb2xsb3dpbmcgc3VtbWFyeSBvZiBjaGFu Z2VzIGJldHdlZW4gZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1hbmNpbGxhcnktMDYgYW5kIC0wNy4m bmJzcDsgVGhpcyBpbmNsdWRlcyBjb21tZW50cyBmcm9tIHRoZSBJRVRGIExhc3QgQ2FsbCwgYXMg d2VsbCBhcyByZXZpZXdzIGZyb20gU0VDRElSLCBPUFNESVIsIGFuZCBHRU5BUlQuDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjEpIENoYW5nZSBpbiB0aGUgZGV0 YWlscyBvZiBwYXlsb2FkIGJpdCBmb3JtYXQ8YnI+DQo8YnI+DQpTZXZlcmFsIHBvdGVudGlhbCBp bXBsZW1lbnRlcnMgbm90ZWQgdGhhdCAtMDYgY29udGFpbmVkIHR3byByZXNlcnZlZCBiaXRzIGFm dGVyIERhdGFfQ291bnQgdG8gMzItYml0IHdvcmQgYWxpZ24gdGhlIFVzZXJfRGF0YV9Xb3Jkcy4m bmJzcDsgSXQgd2FzIHN1Z2dlc3RlZCB0aGF0IHRoaXMgdW5uZWNlc3NhcmlseSBicmVha3MgdXAg dGhlIEFOQyBwYWNrZXQgYml0cyBhcyBleHByZXNzZWQgaW4gU0RJLCBhbmQgbW9yZW92ZXIgdGhl IHJlc2VydmVkIGJpdHMNCiBkbyBub3QgYWN0dWFsbHkgYWNoaWV2ZSAzMi1iaXQgd29yZCBhbGln bm1lbnQgb2YgVXNlcl9EYXRhX1dvcmRzIG9uIHRoZSBzZWNvbmQgYW5kIGZvbGxvd2luZyBBTkMg ZGF0YSBwYWNrZXRzIGNhcnJpZWQgaW4gdGhlIHBheWxvYWQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BZnRlciBzdWJzdGFudGlhbCBpbnB1dCBmcm9tIHBvdGVu dGlhbCBpbXBsZW1lbnRlcnMsIHRoZSBmb3JtYXQgd2FzIGNoYW5nZWQgdG8ga2VlcCB0aGUgU0RJ IEFOQyBkYXRhIHBhY2tldCBjb250aWd1b3VzLCBhbmQgdG8gYWRkIHJlc2VydmVkIGJpdHMgdG8g ZW5zdXJlIHRoYXQgdGhlIHN0YXJ0IG9mIGhlYWRlcnMgYmVmb3JlIGVhY2ggQU5DIGRhdGEgcGFj a2V0DQogaXMgMzItYml0IHdvcmQgYWxpZ25lZC48YnI+DQo8YnI+DQpUaGUgcGF5bG9hZCBmb3Jt YXQgZXhhbXBsZSB3YXMgZW5sYXJnZWQgdG8gY2xlYXJseSBzaG93IHRoZSBwcm9wZXIgY2Fycmlh Z2Ugb2YgdHdvIEFOQyBkYXRhIHBhY2tldHMgb2YgZGlmZmVyZW50IGxlbmd0aHMuPGJyPg0KPGJy Pg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjIpIEEgSG9yaXpvbnRhbF9PZmZzZXQgdmFsdWUgb2YgMHhG RkUgbm93IGluZGljYXRlcyB0aGF0IHRoZSBBTkMgZGF0YSBtYXkgYmUgcGxhY2VkIGludG8gYW55 IGxlZ2FsIGFyZWEgb2YgSEFOQywgYW5kIHNpbWlsYXJseSBhIExpbmVfTnVtYmVyIHZhbHVlIG9m IDB4N0ZFIG5vdyBpbmRpY2F0ZXMgdGhhdCB0aGUgQU5DIGRhdGEgbWF5IGJlIHBsYWNlZCBpbnRv DQogYW55IGxlZ2FsIGFyZWEgb2YgVkFOQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjMpIFRoZSDigJxD4oCdIGJpdCBpcyBub3QgdG8gYmUgaWdub3JlZCBldmVu IGlmIHRoZSBBTkMgZGF0YSBwYWNrZXQgaXMgY29uc2lkZXJlZCB0byBiZSBjYXJyaWVkIHdpdGhv dXQgYW55IHNwZWNpZmljIGxvY2F0aW9uIHdpdGhpbiB0aGUgZmllbGQgb3IgZnJhbWUuJm5ic3A7 IEFOQyBwYWNrZXRzIGFyZSBhbHdheXMgZGVmaW5lZCB0byBiZSBjYXJyaWVkIGluIHRoZSBjb2xv cg0KIGRpZmZlcmVuY2Ugb3IgbHVtYSBjaGFubmVsLjxicj4NCjxicj4NCjQpIEFuIG9wdGlvbmFs IE1lZGlhIFR5cGUgcGFyYW1ldGVyIExpbmtOdW1iZXIgd2FzIGFkZGVkIGZvciB0aGUgaWRlbnRp ZmljYXRpb24gb2YgYSBsaW5rIG51bWJlciBpbiBkdWFsIGFuZCBxdWFkIGxpbmsgU0RJIGFwcGxp Y2F0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjUpIE1h ZGUgaXQgY2xlYXIgdGhhdCBNdWx0aXBsZSBESURfU0RJRCBwYXJhbWV0ZXJzIGRvIG5vdCBpbXBs eSBhbnkgcGFydGljdWxhciBvcmRlcmluZyBvZiB0aGUgZGlmZmVyZW50IHR5cGVzIG9mIEFOQyBw YWNrZXRzIGluIHRoZSBzdHJlYW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij42KSBBZGRlZCBub3RlIHRoYXQgdGhlIENoZWNrc3VtX1dvcmQgaXMgdW5saWtlbHkg dG8gcHJvdmlkZSBhIHBheWxvYWQgaW50ZWdyaXR5IGNoZWNrIGluIGNhc2Ugb2YgYSBkaXJlY3Rl ZCBhdHRhY2suPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIHdp bGwgYWRkIHRoYXQgLTA3IGhhcyBiZWVuIHByZXNlbnRlZCB0byB0aGUgQWxsaWFuY2UgZm9yIElQ IE1lZGlhIFNvbHV0aW9ucyAoQUlNUykgVGVjaG5pY2FsIFdvcmtpbmcgR3JvdXAsIHdoaWNoIGhh ZCBubyBzdWJzdGFudGl2ZSBjb21tZW50cy4mbmJzcDsgSG93ZXZlciwgdGhlIEFJTVMgVFdHIGNv bnNlbnN1cyB3YXMgdG8gYXNrIGZvciBhIGRlbGF5IGluIG1vdmluZw0KIC0wNyB0byBSRkMgcHVi bGlzaGluZyB1bnRpbCB0aGUgVmlkZW8gU2VydmljZXMgRm9ydW0gLyBKb2ludCBUYXNrIEZvcmNl IG9uIE5ldHdvcmtlZCBNZWRpYSBpbnRlcm9wIGV2ZW50IEZlYnJ1YXJ5IDYtMTAgYXQgdGhlIEZv eCBTcG9ydHMgZmFjaWxpdHkgaW4gSG91c3RvbiwgVFguJm5ic3A7IFRoZSBmZWVsaW5nIHdhcyB0 aGF0IHRoZSAtMDcgdmVyc2lvbiBjb3VsZCBiZSBmdWxseSBleGVyY2lzZWQgYnkgdGhlIHBhcnRp Y2lwYW50cyB0aGVyZSwgYW5kDQogYW55IHVuZXhwZWN0ZWQgc2hvcnRjb21pbmdzIHJhcGlkbHkg aWRlbnRpZmllZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkJh c2VkIG9uIHRoaXMgZmVlZGJhY2sgZnJvbSB0aGUgQUlNUyBUV0csIEkgaGF2ZSBmb3J3YXJkZWQg dGhpcyByZXF1ZXN0IHRvIHRoZSBJRVNHIHJlc3BvbnNpYmxlIEFELCBCZW4gQ2FtcGJlbGwuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4tVGhvbWFzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4tLSZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5UaG9tYXMgRWR3YXJkcyA8bzpwPg0KPC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOmJsYWNrIj5WUCBFbmdpbmVlcmluZyAmYW1wOyBEZXZlbG9wbWVudDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5GT1ggTmV0d29ya3MgRW5naW5lZXJpbmcgYW5kIE9w ZXJhdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+dGhvbWFzLmVkd2FyZHNAZm94 LmNvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5QaG9uZTogJiM0MzsxLjMxMC4zNjku NjY5NjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4xMDIwMSBXZXN0IFBpY28gQmx2ZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+TG9zIEFuZ2VsZXMsIENBIDkwMDM1PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_FD97EAAF805C4D0DAA1A5ED468124518foxcom_-- From nobody Wed Jan 18 13:58:40 2017 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17EC129495 for ; Wed, 18 Jan 2017 13:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 B1HAJ6K3PJ25 for ; Wed, 18 Jan 2017 13:58:38 -0800 (PST) Received: from cuda.olm1.com (cuda.olm1.com [72.236.255.32]) (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 F0850129485 for ; Wed, 18 Jan 2017 13:58:37 -0800 (PST) X-ASG-Debug-ID: 1484776712-092fd31b35248930001-U2jSCT Received: from host105.olm1.com (host105.olm1.com [72.236.255.15]) by cuda.olm1.com with ESMTP id 2M5anTAGOXEiRUzN (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 18 Jan 2017 16:58:32 -0500 (EST) X-Barracuda-Envelope-From: victor.demjanenko@vocal.com X-Barracuda-Apparent-Source-IP: 72.236.255.15 Received: from ClintonLT (rrcs-72-43-202-98.nys.biz.rr.com [72.43.202.98]) by host105.olm1.com (Postfix) with ESMTPSA id 6C3ECB44E40; Wed, 18 Jan 2017 16:58:32 -0500 (EST) From: "Victor Demjanenko, Ph.D." To: References: <148271835146.28347.7596373310873834703.idtracker@ietfa.amsl.com> <032901d25f53$436d5a50$ca480ef0$@gmail.com> In-Reply-To: <032901d25f53$436d5a50$ca480ef0$@gmail.com> Date: Wed, 18 Jan 2017 16:58:34 -0500 X-ASG-Orig-Subj: RE: [payload] Review of draft-ietf-payload-melpe-04 Message-ID: <00c101d271d6$044338a0$0cc9a9e0$@demjanenko@vocal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQGh7RTHRkjSPW71RMsHqDmGjiufkKF6y4iQgCUEvVA= Content-Language: en-us X-Barracuda-Connect: host105.olm1.com[72.236.255.15] X-Barracuda-Start-Time: 1484776712 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://72.236.255.32:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at olm1.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=BSF_SC0_MISMATCH_TO, MSGID_MULTIPLE_AT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.35901 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 MSGID_MULTIPLE_AT Message-ID contains multiple '@' characters 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: Cc: "'Ali C. Begen'" , "'Dave Satterlee \(Vocal\)'" Subject: Re: [payload] Review of draft-ietf-payload-melpe-04 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 21:58:40 -0000 Hi Everyone, I would like to thank everyone for their comments and specific improvements to our document, draft-ietf-payload-melpe-04. We will produce a full document after any responses to this email are collected. We have made the suggested changes and have the following detailed notes. If anyone can spot other deficiencies or NITS we would be happy to correct them in hopefully this last pass. Regards, Victor & Dave 1. Corrected Spelling - (Declaritive -> Declarative) 3 places (table of contents and section 4.3 twice) 2. Section 3 Improvement (removed last sentence, combined paragraphs, referenced Figure 1 explicitly) (was) The RTP payload for MELPe has the format shown in the figure below. No additional header specific to this payload format is required. This format is intended for the situations where the sender and the receiver send one or more codec data frames per packet. The RTP packet looks as follows: (now) The RTP payload for MELPe has the format shown in Figure 1. No additional header specific to this payload format is required. This format is intended for the situations where the sender and the receiver send one or more codec data frames per packet. 3. Section 3.1 Improvement (last sentence improved) (was) The total number of bits used to describe one frame of 2400 bps speech is 54, which fits in 7 octets (with two unused bits). For the 1200 bps speech the total number of bits used is 81, which fits in 11 octets (with seven unused bits). For the 600 bps speech the total number of bits used is 54, which fits in 7 octets (with two unused bits). Unused bits are coded as described in 3.3 in support of dynamic bit-rate switching. (now) The total number of bits used to describe one frame of 2400 bps speech is 54, which fits in 7 octets (with two unused bits). For the 1200 bps speech the total number of bits used is 81, which fits in 11 octets (with seven unused bits). For the 600 bps speech the total number of bits used is 54, which fits in 7 octets (with two unused bits). Unused bits, shown below as RSVA, RSVB, etc., are coded as described in 3.3 in support of dynamic bit-rate switching. 4. Table 3.4 Note (recommended -> preferred) (was) Note: The default value shall be the respective parameters from the vocoder frame. It is recommended that msvq[0] and gain[1] values be derived by averaging the respective parameter from some number of previous vocoder frames. (now) Note: The default value shall be the respective parameters from the vocoder frame. It is preferred that msvq[0] and gain[1] values be derived by averaging the respective parameter from some number of previous vocoder frames. 5. Section 3.3 Last Paragraph (recommended -> RECOMMENDED) (was) When dynamic bit-rate switching is used and more than one frame is contained in a RTP packet, it is recommended to inspect the coder rate bits contained in the last octet. If the coder bit rate indicates a Comfort Noise frame, then inspect the third last octet for the coder bit rate. All MELPe speech frames in the RTP packet will be of this same coder bit rate. (now) When dynamic bit-rate switching is used and more than one frame is contained in a RTP packet, it is RECOMMENDED to inspect the coder rate bits contained in the last octet. If the coder bit rate indicates a Comfort Noise frame, then inspect the third last octet for the coder bit rate. All MELPe speech frames in the RTP packet will be of this same coder bit rate. 6. Section 3.4 First Paragraph (efficient congestion control -> congestion management) and (the transmission rate -> packet rate) (was) The target bitrate of MELPe can be adjusted at any point in time, thus allowing efficient congestion control. Furthermore, the amount of encoded speech or audio data encoded in a single packet can be used for congestion control, since the transmission rate is inversely proportional to the packet duration. A lower packet transmission rate reduces the amount of header overhead, but at the same time increases latency and loss sensitivity, so it ought to be used with care. (now) The target bitrate of MELPe can be adjusted at any point in time, thus allowing congestion management. Furthermore, the amount of encoded speech or audio data encoded in a single packet can be used for congestion control, since packet rate is inversely proportional to the packet duration. A lower packet transmission rate reduces the amount of header overhead, but at the same time increases latency and loss sensitivity, so it ought to be used with care. 7. Section 4.2 Third Paragraph (may -> MAY) (was) When conveying information by SDP, the encoding name SHALL be "MELP" (the same as the media subtype). Alternative encoding name types, "MELP2400", "MELP1200", and "MELP600", may be used in SDP to convey fixed bit-rate configurations. These names have been observed in systems that do not support dynamic frame rate switching as specified by the parameter, "bitrate". (now) When conveying information by SDP, the encoding name SHALL be "MELP" (the same as the media subtype). Alternative encoding name types, "MELP2400", "MELP1200", and "MELP600", MAY be used in SDP to convey fixed bit-rate configurations. These names have been observed in systems that do not support dynamic frame rate switching as specified by the parameter, "bitrate". 8. Section 6 First Paragraph (may utilize -> utilizes) and (recommended -> preferred) (was) MELPe packet loss concealment (PLC) uses the special properties and coding for the pitch/voicing parameter of the MELPe 2400 bps coder. The PLC erasure indication may utilize any of the errored encodings of a non-voiced frame as identified in Table 1 of [MELPE]. For the sake of simplicity it is recommended to use a code value of 3 for the pitch/voicing parameter (represented by the bits P6 to P0 in Table 3.1). Hence, set bits P0 and P1 to one and bits P2, P3, P4, P5, and P6 to zero. (now) MELPe packet loss concealment (PLC) uses the special properties and coding for the pitch/voicing parameter of the MELPe 2400 bps coder. The PLC erasure indication utilizes any of the errored encodings of a non-voiced frame as identified in Table 1 of [MELPE]. For the sake of simplicity it is preferred to use a code value of 3 for the pitch/voicing parameter (represented by the bits P6 to P0 in Table 3.1). Hence, set bits P0 and P1 to one and bits P2, P3, P4, P5, and P6 to zero. 9. References (MELP, MELPE and SCIP210 are now normative) (I could not find meaningful URI for documents. Available from various search pages.) -----Original Message----- From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Monday, December 26, 2016 3:37 AM To: 'Dave Satterlee (Vocal)'; Victor.Demjanenko@vocal.com Cc: Ali C. Begen Subject: FW: [payload] Review of draft-ietf-payload-melpe-04 Hi guys, These comments make sense. Please look at using capital letters for RFC2119 language and if not meant to be RFC2119 try using other words to replace. As for the reference, I agree that they must be normative. You can respond to the mail on the list but wait for the IETF last call to finish before updating since there may be other comments Thanks Roni -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Carlos Pignataro Sent: Monday, December 26, 2016 4:13 AM To: ops-dir@ietf.org Cc: draft-ietf-payload-melpe.all@ietf.org; iesg@ietf.org; payload@ietf.org Subject: [payload] Review of draft-ietf-payload-melpe-04 Reviewer: Carlos Pignataro Review result: Has Nits Hi, This document is mostly ready but has some potential issues: 1. Normative statements -- there are a number of "recommended" and "shall" among "RECOMMENDED" and "SHALL". It would not hurt to revise and confirm the normative level of each of these. Specifically, a couple of these relate to one operational aspect of Default values: E.g.: Note: The default value shall be the respective parameters from the vocoder frame. It is recommended that msvq[0] and gain[1] values be derived by averaging the respective parameter from some number of previous vocoder frames. Should thouse be normative / uppercase as per its operational implications? 2. References It is not entirely clear to me that the references are adequately split in Normative vs. Informative. I understand these three for example are not produced by the IETF; but are they necessary to understand the spec? [MELP] Department of Defense Telecommunications Standard, "Analog-to- Digital Conversion of Voice by 2,400 Bit/Second Mixed Excitation Linear Prediction (MELP)", MIL-STD-3005, December 1999. [MELPE] North Atlantic Treaty Organization (NATO), "The 600 Bit/S, 1200 Bit/S and 2400 Bit/S NATO Interoperable Narrow Band Voice Coder", STANAG No. 4591, January 2006. [SCIP210] National Security Agency, "SCIP Signaling Plan", SCIP-210, December 2007. Also, sure, a google search can find them (I believe), but is there an authoritative pointer (URI) where these can be normatively found? Thanks, -- Carlos. _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From nobody Thu Jan 19 06:43:26 2017 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA9D1295F5 for ; Thu, 19 Jan 2017 06:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 H0tUr3VqK7Zw for ; Thu, 19 Jan 2017 06:43:23 -0800 (PST) Received: from cuda.olm1.com (cuda.olm1.com [72.236.255.32]) (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 E1AFF12961A for ; Thu, 19 Jan 2017 06:43:22 -0800 (PST) X-ASG-Debug-ID: 1484836750-092fd31b352bbb80001-U2jSCT Received: from host105.olm1.com (host105.olm1.com [72.236.255.15]) by cuda.olm1.com with ESMTP id itaxb6OMzmBIrTs6 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 19 Jan 2017 09:39:10 -0500 (EST) X-Barracuda-Envelope-From: victor.demjanenko@vocal.com X-Barracuda-Apparent-Source-IP: 72.236.255.15 Received: from ClintonLT (rrcs-72-43-202-98.nys.biz.rr.com [72.43.202.98]) by host105.olm1.com (Postfix) with ESMTPSA id B69B7B451FF; Thu, 19 Jan 2017 09:39:10 -0500 (EST) From: "Victor Demjanenko, Ph.D." To: Date: Thu, 19 Jan 2017 09:39:12 -0500 X-ASG-Orig-Subj: FW: [payload] Review of draft-ietf-payload-melpe-04 Message-ID: <015201d27261$cd5a7f60$680f7e20$@demjanenko@vocal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQGh7RTHRkjSPW71RMsHqDmGjiufkKF6y4iQgCUEvVCAARkG4A== Content-Language: en-us X-Barracuda-Connect: host105.olm1.com[72.236.255.15] X-Barracuda-Start-Time: 1484836750 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://72.236.255.32:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at olm1.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=MSGID_MULTIPLE_AT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.35915 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 MSGID_MULTIPLE_AT Message-ID contains multiple '@' characters Archived-At: Subject: [payload] FW: Review of draft-ietf-payload-melpe-04 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 14:43:25 -0000 Hi Everyone, I would like to thank everyone for their comments and specific improvements to our document, draft-ietf-payload-melpe-04. We will produce a full document after any responses to this email are collected. We have made the suggested changes and have the following detailed notes. If anyone can spot other deficiencies or NITS we would be happy to correct them in hopefully this last pass. Regards, Victor & Dave 1. Corrected Spelling - (Declaritive -> Declarative) 3 places (table of contents and section 4.3 twice) 2. Section 3 Improvement (removed last sentence, combined paragraphs, referenced Figure 1 explicitly) (was) The RTP payload for MELPe has the format shown in the figure below. No additional header specific to this payload format is required. This format is intended for the situations where the sender and the receiver send one or more codec data frames per packet. The RTP packet looks as follows: (now) The RTP payload for MELPe has the format shown in Figure 1. No additional header specific to this payload format is required. This format is intended for the situations where the sender and the receiver send one or more codec data frames per packet. 3. Section 3.1 Improvement (last sentence improved) (was) The total number of bits used to describe one frame of 2400 bps speech is 54, which fits in 7 octets (with two unused bits). For the 1200 bps speech the total number of bits used is 81, which fits in 11 octets (with seven unused bits). For the 600 bps speech the total number of bits used is 54, which fits in 7 octets (with two unused bits). Unused bits are coded as described in 3.3 in support of dynamic bit-rate switching. (now) The total number of bits used to describe one frame of 2400 bps speech is 54, which fits in 7 octets (with two unused bits). For the 1200 bps speech the total number of bits used is 81, which fits in 11 octets (with seven unused bits). For the 600 bps speech the total number of bits used is 54, which fits in 7 octets (with two unused bits). Unused bits, shown below as RSVA, RSVB, etc., are coded as described in 3.3 in support of dynamic bit-rate switching. 4. Table 3.4 Note (recommended -> preferred) (was) Note: The default value shall be the respective parameters from the vocoder frame. It is recommended that msvq[0] and gain[1] values be derived by averaging the respective parameter from some number of previous vocoder frames. (now) Note: The default value shall be the respective parameters from the vocoder frame. It is preferred that msvq[0] and gain[1] values be derived by averaging the respective parameter from some number of previous vocoder frames. 5. Section 3.3 Last Paragraph (recommended -> RECOMMENDED) (was) When dynamic bit-rate switching is used and more than one frame is contained in a RTP packet, it is recommended to inspect the coder rate bits contained in the last octet. If the coder bit rate indicates a Comfort Noise frame, then inspect the third last octet for the coder bit rate. All MELPe speech frames in the RTP packet will be of this same coder bit rate. (now) When dynamic bit-rate switching is used and more than one frame is contained in a RTP packet, it is RECOMMENDED to inspect the coder rate bits contained in the last octet. If the coder bit rate indicates a Comfort Noise frame, then inspect the third last octet for the coder bit rate. All MELPe speech frames in the RTP packet will be of this same coder bit rate. 6. Section 3.4 First Paragraph (efficient congestion control -> congestion management) and (the transmission rate -> packet rate) (was) The target bitrate of MELPe can be adjusted at any point in time, thus allowing efficient congestion control. Furthermore, the amount of encoded speech or audio data encoded in a single packet can be used for congestion control, since the transmission rate is inversely proportional to the packet duration. A lower packet transmission rate reduces the amount of header overhead, but at the same time increases latency and loss sensitivity, so it ought to be used with care. (now) The target bitrate of MELPe can be adjusted at any point in time, thus allowing congestion management. Furthermore, the amount of encoded speech or audio data encoded in a single packet can be used for congestion control, since packet rate is inversely proportional to the packet duration. A lower packet transmission rate reduces the amount of header overhead, but at the same time increases latency and loss sensitivity, so it ought to be used with care. 7. Section 4.2 Third Paragraph (may -> MAY) (was) When conveying information by SDP, the encoding name SHALL be "MELP" (the same as the media subtype). Alternative encoding name types, "MELP2400", "MELP1200", and "MELP600", may be used in SDP to convey fixed bit-rate configurations. These names have been observed in systems that do not support dynamic frame rate switching as specified by the parameter, "bitrate". (now) When conveying information by SDP, the encoding name SHALL be "MELP" (the same as the media subtype). Alternative encoding name types, "MELP2400", "MELP1200", and "MELP600", MAY be used in SDP to convey fixed bit-rate configurations. These names have been observed in systems that do not support dynamic frame rate switching as specified by the parameter, "bitrate". 8. Section 6 First Paragraph (may utilize -> utilizes) and (recommended -> preferred) (was) MELPe packet loss concealment (PLC) uses the special properties and coding for the pitch/voicing parameter of the MELPe 2400 bps coder. The PLC erasure indication may utilize any of the errored encodings of a non-voiced frame as identified in Table 1 of [MELPE]. For the sake of simplicity it is recommended to use a code value of 3 for the pitch/voicing parameter (represented by the bits P6 to P0 in Table 3.1). Hence, set bits P0 and P1 to one and bits P2, P3, P4, P5, and P6 to zero. (now) MELPe packet loss concealment (PLC) uses the special properties and coding for the pitch/voicing parameter of the MELPe 2400 bps coder. The PLC erasure indication utilizes any of the errored encodings of a non-voiced frame as identified in Table 1 of [MELPE]. For the sake of simplicity it is preferred to use a code value of 3 for the pitch/voicing parameter (represented by the bits P6 to P0 in Table 3.1). Hence, set bits P0 and P1 to one and bits P2, P3, P4, P5, and P6 to zero. 9. References (MELP, MELPE and SCIP210 are now normative) (I could not find meaningful URI for documents. Available from various search pages.) -----Original Message----- From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Monday, December 26, 2016 3:37 AM To: 'Dave Satterlee (Vocal)'; Victor.Demjanenko@vocal.com Cc: Ali C. Begen Subject: FW: [payload] Review of draft-ietf-payload-melpe-04 Hi guys, These comments make sense. Please look at using capital letters for RFC2119 language and if not meant to be RFC2119 try using other words to replace. As for the reference, I agree that they must be normative. You can respond to the mail on the list but wait for the IETF last call to finish before updating since there may be other comments Thanks Roni -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Carlos Pignataro Sent: Monday, December 26, 2016 4:13 AM To: ops-dir@ietf.org Cc: draft-ietf-payload-melpe.all@ietf.org; iesg@ietf.org; payload@ietf.org Subject: [payload] Review of draft-ietf-payload-melpe-04 Reviewer: Carlos Pignataro Review result: Has Nits Hi, This document is mostly ready but has some potential issues: 1. Normative statements -- there are a number of "recommended" and "shall" among "RECOMMENDED" and "SHALL". It would not hurt to revise and confirm the normative level of each of these. Specifically, a couple of these relate to one operational aspect of Default values: E.g.: Note: The default value shall be the respective parameters from the vocoder frame. It is recommended that msvq[0] and gain[1] values be derived by averaging the respective parameter from some number of previous vocoder frames. Should thouse be normative / uppercase as per its operational implications? 2. References It is not entirely clear to me that the references are adequately split in Normative vs. Informative. I understand these three for example are not produced by the IETF; but are they necessary to understand the spec? [MELP] Department of Defense Telecommunications Standard, "Analog-to- Digital Conversion of Voice by 2,400 Bit/Second Mixed Excitation Linear Prediction (MELP)", MIL-STD-3005, December 1999. [MELPE] North Atlantic Treaty Organization (NATO), "The 600 Bit/S, 1200 Bit/S and 2400 Bit/S NATO Interoperable Narrow Band Voice Coder", STANAG No. 4591, January 2006. [SCIP210] National Security Agency, "SCIP Signaling Plan", SCIP-210, December 2007. Also, sure, a google search can find them (I believe), but is there an authoritative pointer (URI) where these can be normatively found? Thanks, -- Carlos. _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From nobody Fri Jan 20 13:35:14 2017 Return-Path: X-Original-To: payload@ietf.org Delivered-To: payload@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A121294B0; Fri, 20 Jan 2017 13:35:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148494810935.13328.9215549711885172728.idtracker@ietfa.amsl.com> Date: Fri, 20 Jan 2017 13:35:09 -0800 Archived-At: Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-melpe-05.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 21:35:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads of the IETF. Title : RTP Payload Format for MELPe Codec Authors : Victor Demjanenko David Satterlee Filename : draft-ietf-payload-melpe-05.txt Pages : 28 Date : 2017-01-20 Abstract: This document describes the RTP payload format for the Mixed Excitation Linear Prediction Enhanced (MELPe) speech coder. MELPe's three different speech encoding rates and sample frames sizes are supported. Comfort noise procedures and packet loss concealment are detailed. INTERNET DRAFT RTP Payload Format for the MELPe Codec January 20, 2017 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-melpe/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-payload-melpe-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-melpe-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 Jan 20 13:40:12 2017 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E7F1294B5 for ; Fri, 20 Jan 2017 13:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 bCiz8Ud9TwgL for ; Fri, 20 Jan 2017 13:40:09 -0800 (PST) Received: from cuda.olm1.com (cuda.olm1.com [72.236.255.32]) (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 06E2B1294B4 for ; Fri, 20 Jan 2017 13:40:09 -0800 (PST) X-ASG-Debug-ID: 1484948406-092fd3687519b40001-U2jSCT Received: from host105.olm1.com (host105.olm1.com [72.236.255.15]) by cuda.olm1.com with ESMTP id sRhwlLI8jY1uAcHj (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 20 Jan 2017 16:40:06 -0500 (EST) X-Barracuda-Envelope-From: victor.demjanenko@vocal.com X-Barracuda-Apparent-Source-IP: 72.236.255.15 Received: from ClintonLT (rrcs-72-43-202-98.nys.biz.rr.com [72.43.202.98]) by host105.olm1.com (Postfix) with ESMTPSA id 71BCBB451CD; Fri, 20 Jan 2017 16:40:06 -0500 (EST) From: "Victor Demjanenko, Ph.D." To: References: <148494810935.13328.9215549711885172728.idtracker@ietfa.amsl.com> In-Reply-To: <148494810935.13328.9215549711885172728.idtracker@ietfa.amsl.com> Date: Fri, 20 Jan 2017 16:40:05 -0500 X-ASG-Orig-Subj: RE: [payload] I-D Action: draft-ietf-payload-melpe-05.txt Message-ID: <028301d27365$c42e5e70$4c8b1b50$@demjanenko@vocal.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0284_01D2733B.DB585670" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdJzZSP/vIqrBw62TQmfQm6mRj8WvQAABslw Content-Language: en-us X-Barracuda-Connect: host105.olm1.com[72.236.255.15] X-Barracuda-Start-Time: 1484948406 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://72.236.255.32:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at olm1.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=MSGID_MULTIPLE_AT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.35951 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 MSGID_MULTIPLE_AT Message-ID contains multiple '@' characters Archived-At: Subject: Re: [payload] I-D Action: draft-ietf-payload-melpe-05.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 21:40:11 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0284_01D2733B.DB585670 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Everyone, We have reviewed and made a few more changes for RFC 2119 language. The note of our changes are below. Please let us know if any other NITs or changes are necessary. Victor and Dave 1. Corrected Spelling - (Declaritive -> Declarative) 3 places (table of contents and section 4.3 twice) 2. Section 3 Improvement (removed last sentence, combined paragraphs, referenced Figure 1 explicitly) (was) The RTP payload for MELPe has the format shown in the figure below. No additional header specific to this payload format is required. This format is intended for the situations where the sender and the receiver send one or more codec data frames per packet. The RTP packet looks as follows: (now) The RTP payload for MELPe has the format shown in Figure 1. No additional header specific to this payload format is required. This format is intended for the situations where the sender and the receiver send one or more codec data frames per packet. 3. Section 3.1 Improvement (last sentence improved) (was) The total number of bits used to describe one frame of 2400 bps speech is 54, which fits in 7 octets (with two unused bits). For the 1200 bps speech the total number of bits used is 81, which fits in 11 octets (with seven unused bits). For the 600 bps speech the total number of bits used is 54, which fits in 7 octets (with two unused bits). Unused bits are coded as described in 3.3 in support of dynamic bit-rate switching. (now) The total number of bits used to describe one frame of 2400 bps speech is 54, which fits in 7 octets (with two unused bits). For the 1200 bps speech the total number of bits used is 81, which fits in 11 octets (with seven unused bits). For the 600 bps speech the total number of bits used is 54, which fits in 7 octets (with two unused bits). Unused bits, shown below as RSVA, RSVB, etc., are coded as described in 3.3 in support of dynamic bit-rate switching. 4. Table 3.4 Note (value shall be -> values are) (recommended -> preferred) (was) Note: The default value shall be the respective parameters from the vocoder frame. It is recommended that msvq[0] and gain[1] values be derived by averaging the respective parameter from some number of previous vocoder frames. (now) Note: The default values are the respective parameters from the vocoder frame. It is preferred that msvq[0] and gain[1] values be derived by averaging the respective parameter from some number of previous vocoder frames. 5. Section 3.3 Last Paragraph (recommended -> RECOMMENDED) (was) When dynamic bit-rate switching is used and more than one frame is contained in a RTP packet, it is recommended to inspect the coder rate bits contained in the last octet. If the coder bit rate indicates a Comfort Noise frame, then inspect the third last octet for the coder bit rate. All MELPe speech frames in the RTP packet will be of this same coder bit rate. (now) When dynamic bit-rate switching is used and more than one frame is contained in a RTP packet, it is RECOMMENDED to inspect the coder rate bits contained in the last octet. If the coder bit rate indicates a Comfort Noise frame, then inspect the third last octet for the coder bit rate. All MELPe speech frames in the RTP packet will be of this same coder bit rate. 6. Section 3.4 First Paragraph (efficient congestion control -> congestion management) and (the transmission rate -> packet rate) (was) The target bitrate of MELPe can be adjusted at any point in time, thus allowing efficient congestion control. Furthermore, the amount of encoded speech or audio data encoded in a single packet can be used for congestion control, since the transmission rate is inversely proportional to the packet duration. A lower packet transmission rate reduces the amount of header overhead, but at the same time increases latency and loss sensitivity, so it ought to be used with care. (now) The target bitrate of MELPe can be adjusted at any point in time, thus allowing congestion management. Furthermore, the amount of encoded speech or audio data encoded in a single packet can be used for congestion control, since packet rate is inversely proportional to the packet duration. A lower packet transmission rate reduces the amount of header overhead, but at the same time increases latency and loss sensitivity, so it ought to be used with care. 7. Section 4.2 Third Paragraph (may -> MAY) (was) When conveying information by SDP, the encoding name SHALL be "MELP" (the same as the media subtype). Alternative encoding name types, "MELP2400", "MELP1200", and "MELP600", may be used in SDP to convey fixed bit-rate configurations. These names have been observed in systems that do not support dynamic frame rate switching as specified by the parameter, "bitrate". (now) When conveying information by SDP, the encoding name SHALL be "MELP" (the same as the media subtype). Alternative encoding name types, "MELP2400", "MELP1200", and "MELP600", MAY be used in SDP to convey fixed bit-rate configurations. These names have been observed in systems that do not support dynamic frame rate switching as specified by the parameter, "bitrate". 8. Section 6 First Paragraph (may utilize -> utilizes) and (recommended -> preferred) (was) MELPe packet loss concealment (PLC) uses the special properties and coding for the pitch/voicing parameter of the MELPe 2400 bps coder. The PLC erasure indication may utilize any of the errored encodings of a non-voiced frame as identified in Table 1 of [MELPE]. For the sake of simplicity it is recommended to use a code value of 3 for the pitch/voicing parameter (represented by the bits P6 to P0 in Table 3.1). Hence, set bits P0 and P1 to one and bits P2, P3, P4, P5, and P6 to zero. (now) MELPe packet loss concealment (PLC) uses the special properties and coding for the pitch/voicing parameter of the MELPe 2400 bps coder. The PLC erasure indication utilizes any of the errored encodings of a non-voiced frame as identified in Table 1 of [MELPE]. For the sake of simplicity it is preferred to use a code value of 3 for the pitch/voicing parameter (represented by the bits P6 to P0 in Table 3.1). Hence, set bits P0 and P1 to one and bits P2, P3, P4, P5, and P6 to zero. 9. References (MELP, MELPE and SCIP210 are now normative) (I could not find meaningful URI for documents. Available from various search pages.) 10. Section 2 Second to Last Paragraph (is recommended to follow -> follows the procedures in) (was) Comfort noise handling for MELPe is recommended to follow SCIP-210 Appendix B [SCIP210]. After VAD no longer indicates the presence of speech/voice, a grace period of a minimum of two comfort noise vocoder fames are to be transmitted. The contents of the comfort noise frames is described in the next section. (now) Comfort noise handling for MELPe follows the procedures in SCIP-210 Appendix B [SCIP210]. After VAD no longer indicates the presence of speech/voice, a grace period of a minimum of two comfort noise vocoder fames are to be transmitted. The contents of the comfort noise frames is described in the next section. 11. Section 3 Second Paragraph (required -> needed) (was) The RTP payload for MELPe has the format shown in Figure 1. No additional header specific to this payload format is required. This format is intended for the situations where the sender and the receiver send one or more codec data frames per packet. (now) The RTP payload for MELPe has the format shown in Figure 1. No additional header specific to this payload format is needed. This format is intended for the situations where the sender and the receiver send one or more codec data frames per packet. 12. Text after Table 3.4 (required -> needed) (was) Since only msvq[0] (also known as LSF1x or the first LSP) and gain[1] (also known as g2x or the second gain) are required, the following bit order is used for comfort noise frames. (now) Since only msvq[0] (also known as LSF1x or the first LSP) and gain[1] (also known as g2x or the second gain) are needed, the following bit order is used for comfort noise frames. 13. Section 3.3 First Paragraph (may -> MAY) (may be required -> is used) (was) A MELPe RTP packet may consist of zero or more MELPe coder frames, followed by zero or one MELPe Comfort Noise frames. The presence of a comfort noise frame can be deduced from the length of the RTP payload. The default packetization interval is one coder frame (22.5, 67.5 or 90 ms) according to the coder bit rate (2400, 1200 or 600 bps). For some applications, a longer packetization interval may be required to reduce the packet rate. (now) A MELPe RTP packet MAY consist of zero or more MELPe coder frames, followed by zero or one MELPe Comfort Noise frames. The presence of a comfort noise frame can be deduced from the length of the RTP payload. The default packetization interval is one coder frame (22.5, 67.5 or 90 ms) according to the coder bit rate (2400, 1200 or 600 bps). For some applications, a longer packetization interval is used to reduce the packet rate. 14. Section 3.3 Second Paragraph (may -> MAY) (was) A MELPe RTP packet comprised of no coder frame and no comfort noise frame may be used periodically by an end point to indicate connectivity by an otherwise idle receiver. (now) A MELPe RTP packet comprised of no coder frame and no comfort noise frame MAY be used periodically by an end point to indicate connectivity by an otherwise idle receiver. 15. Section 3.3 Second to Last Paragraph (may -> can) (was) 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 MELPe frames is to count the total number of octets within the RTP packet, and divide the octet count by the number of expected octets per frame (7/11/7 per frame). Keep in mind the last frame may be a 2 octet comfort noise frame. (now) 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 MELPe frames is to count the total number of octets within the RTP packet, and divide the octet count by the number of expected octets per frame (7/11/7 per frame). Keep in mind the last frame can be a 2 octet comfort noise frame. 16. Section 4.2 Last Paragraph (may -> can) (was) The value for "packet time" and "maximum packet time" parameters of the "ptime" and "maxptime" SDP attributes respectively, SHALL use the nearest rounded-up ms integer packet duration. For MELPe, this corresponds to the values: 23, 45, 68, 90, 112, 135, 156, and 180. Larger values may be used as long as they are properly rounded. (now) The value for "packet time" and "maximum packet time" parameters of the "ptime" and "maxptime" SDP attributes respectively, SHALL use the nearest rounded-up ms integer packet duration. For MELPe, this corresponds to the values: 23, 45, 68, 90, 112, 135, 156, and 180. Larger values can be used as long as they are properly rounded. 17. Section 4.3 First Paragraph (may -> MAY) (was) For declarative media, the "bitrate" parameter specifes the possible bit rates used by the sender. Multiple MELPe rtpmap values (such as 97, 98, and 99 as used below) may be used to convey MELPe coded voice at different bit rates. The receiver can then select an appropriate MELPe codec by using 97, 98, or 99. (now) For declarative media, the "bitrate" parameter specifes the possible bit rates used by the sender. Multiple MELPe rtpmap values (such as 97, 98, and 99 as used below) MAY be used to convey MELPe coded voice at different bit rates. The receiver can then select an appropriate MELPe codec by using 97, 98, or 99. 18. Section 4.4 First Two Paragraphs (may -> MAY) (may -> MAY) (may -> MAY) (was) In an Offer/Answer mode [RFC3264], "bitrate" is a bi-directional parameter. Both sides MUST use a common "bitrate" value or values. The offer contains the bit rates supported by the offerer listed in its preferred order. The answerer may agree to any bit rate by listing the bit rate first in the answerer response. Additionally the answerer may indicate any secondary bit rate or bit rates that it supports. The initial bit rate used by both parties SHALL be the first bit rate specified in the answerer response. For example if offerer bit rates are "2400,600", and answer bit rates are "600,2400", the initial bit rate is 600. If other bit rates are provided by the answerer, any common bit rate between offer and answer may be used at any time in the future. Activation of these other common bit rates is beyond the scope of this document. (now) In an Offer/Answer mode [RFC3264], "bitrate" is a bi-directional parameter. Both sides MUST use a common "bitrate" value or values. The offer contains the bit rates supported by the offerer listed in its preferred order. The answerer MAY agree to any bit rate by listing the bit rate first in the answerer response. Additionally the answerer MAY indicate any secondary bit rate or bit rates that it supports. The initial bit rate used by both parties SHALL be the first bit rate specified in the answerer response. For example if offerer bit rates are "2400,600", and answer bit rates are "600,2400", the initial bit rate is 600. If other bit rates are provided by the answerer, any common bit rate between offer and answer MAY be used at any time in the future. Activation of these other common bit rates is beyond the scope of this document. 19. Section 5 (review) (is) A primary application of MELPe is for radio communications of voice conversations and discontinuous transmissions are normal. When MELPe is used in an IP network, MELPe RTP packet transmissions may cease and resume frequently. RTP SSRC sequence number gaps indicate lost packets to be filled by PLC while abrupt loss of RTP packets indicate intended discontinuous transmission. If a MELPe coder so desires, it may send a comfort noise frame as per SCIP-210 Appendix B [SCIP210] prior to ceasing transmission. A receiver may optionally use comfort noise during its silence periods. No SDP negotiations are required. (review) This uses "may" three times and "required" and "optionally" one each. Should any be capitalized or changed to a different word? -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Friday, January 20, 2017 4:35 PM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-melpe-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads of the IETF. Title : RTP Payload Format for MELPe Codec Authors : Victor Demjanenko David Satterlee Filename : draft-ietf-payload-melpe-05.txt Pages : 28 Date : 2017-01-20 Abstract: This document describes the RTP payload format for the Mixed Excitation Linear Prediction Enhanced (MELPe) speech coder. MELPe's three different speech encoding rates and sample frames sizes are supported. Comfort noise procedures and packet loss concealment are detailed. INTERNET DRAFT RTP Payload Format for the MELPe Codec January 20, 2017 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-melpe/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-payload-melpe-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-melpe-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/ _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload ------=_NextPart_000_0284_01D2733B.DB585670 Content-Type: text/plain; name="notes_05.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="notes_05.txt" 1. Corrected Spelling - (Declaritive -> Declarative) 3 places (table of contents and section 4.3 twice) 2. Section 3 Improvement (removed last sentence, combined paragraphs, = referenced=20 Figure 1 explicitly) (was) The RTP payload for MELPe has the format shown in the figure below. No additional header specific to this payload format is required.=20 This format is intended for the situations where the sender and the = receiver send one or more codec data frames per packet. The RTP packet looks as = follows: (now) The RTP payload for MELPe has the format shown in Figure 1. No = additional header specific to this payload format is required. This format is = intended for the situations where the sender and the receiver send one or more = codec data frames per packet.=20 3. Section 3.1 Improvement (last sentence improved) (was) The total number of bits used to describe one frame of 2400 bps speech = is 54, which fits in 7 octets (with two unused bits). For the 1200 bps speech = the total number of bits used is 81, which fits in 11 octets (with seven unused = bits). For the 600 bps speech the total number of bits used is 54, which fits = in 7 octets (with two unused bits). Unused bits are coded as described in = 3.3 in support of dynamic bit-rate switching. (now) The total number of bits used to describe one frame of 2400 bps speech = is 54, which fits in 7 octets (with two unused bits). For the 1200 bps speech = the total number of bits used is 81, which fits in 11 octets (with seven = unused bits). For the 600 bps speech the total number of bits used is 54, = which fits in 7 octets (with two unused bits). Unused bits, shown below as RSVA, = RSVB, etc., are coded as described in 3.3 in support of dynamic bit-rate = switching. 4. Table 3.4 Note (value shall be -> values are) (recommended -> = preferred) (was) Note: The default value shall be the respective parameters from the = vocoder frame. It is recommended that msvq[0] and gain[1] values be derived by averaging the respective parameter from some number of previous vocoder = frames. (now) Note: The default values are the respective parameters from the vocoder frame. It is preferred that msvq[0] and gain[1] values be derived by averaging the respective parameter from some number of previous vocoder = frames. 5. Section 3.3 Last Paragraph (recommended -> RECOMMENDED) (was) When dynamic bit-rate switching is used and more than one frame is = contained in a RTP packet, it is recommended to inspect the coder rate bits contained = in the=20 last octet. If the coder bit rate indicates a Comfort Noise frame, = then inspect=20 the third last octet for the coder bit rate. All MELPe speech frames = in the RTP packet will be of this same coder bit rate. (now) When dynamic bit-rate switching is used and more than one frame is = contained in a RTP packet, it is RECOMMENDED to inspect the coder rate bits contained = in the=20 last octet. If the coder bit rate indicates a Comfort Noise frame, = then inspect=20 the third last octet for the coder bit rate. All MELPe speech frames = in the RTP packet will be of this same coder bit rate. 6. Section 3.4 First Paragraph (efficient congestion control -> = congestion=20 management) and (the transmission rate -> packet rate) (was) The target bitrate of MELPe can be adjusted at any point in time, thus = allowing efficient congestion control. Furthermore, the amount of encoded = speech or audio data encoded in a single packet can be used for congestion = control, since the transmission rate is inversely proportional to the packet duration. = A lower packet transmission rate reduces the amount of header overhead, = but at the same time increases latency and loss sensitivity, so it ought to be = used with care. (now) The target bitrate of MELPe can be adjusted at any point in time, thus = allowing congestion management. Furthermore, the amount of encoded speech or audio data encoded in a single packet can be used for congestion = control, since packet rate is inversely proportional to the packet duration. A lower packet transmission rate reduces the amount of header overhead, = but at the same time increases latency and loss sensitivity, so it ought to be = used with care. 7. Section 4.2 Third Paragraph (may -> MAY) (was) When conveying information by SDP, the encoding name SHALL be "MELP"=20 (the same as the media subtype). Alternative encoding name types, = "MELP2400",=20 "MELP1200", and "MELP600", may be used in SDP to convey fixed bit-rate=20 configurations. These names have been observed in systems that do not=20 support dynamic frame rate switching as specified by the parameter, = "bitrate". (now) When conveying information by SDP, the encoding name SHALL be "MELP"=20 (the same as the media subtype). Alternative encoding name types, = "MELP2400",=20 "MELP1200", and "MELP600", MAY be used in SDP to convey fixed bit-rate=20 configurations. These names have been observed in systems that do not=20 support dynamic frame rate switching as specified by the parameter, = "bitrate". 8. Section 6 First Paragraph (may utilize -> utilizes) and (recommended = -> preferred) (was) MELPe packet loss concealment (PLC) uses the special properties and = coding for the pitch/voicing parameter of the MELPe 2400 bps coder. The PLC = erasure indication may utilize any of the errored encodings of a non-voiced = frame as identified in Table 1 of [MELPE]. For the sake of simplicity it is = recommended to use a code value of 3 for the pitch/voicing parameter (represented = by the bits P6 to P0 in Table 3.1). Hence, set bits P0 and P1 to one and bits P2, P3, P4, P5, and P6 to zero. (now) MELPe packet loss concealment (PLC) uses the special properties and = coding for the pitch/voicing parameter of the MELPe 2400 bps coder. The PLC = erasure indication utilizes any of the errored encodings of a non-voiced frame = as identified in Table 1 of [MELPE]. For the sake of simplicity it is = preferred to use a code value of 3 for the pitch/voicing parameter (represented = by the bits P6 to P0 in Table 3.1). Hence, set bits P0 and P1 to one and bits P2, P3, P4, P5, and P6 to zero. 9. References (MELP, MELPE and SCIP210 are now normative) (I could not find meaningful URI for documents. Available from various = search=20 pages.) 10. Section 2 Second to Last Paragraph (is recommended to follow -> = follows the procedures in) (was) Comfort noise handling for MELPe is recommended to follow SCIP-210 = Appendix B [SCIP210]. After VAD no longer indicates the presence of speech/voice, = a grace period of a minimum of two comfort noise vocoder fames are to be = transmitted. The contents of the comfort noise frames is described in the next = section. (now) Comfort noise handling for MELPe follows the procedures in SCIP-210 = Appendix B [SCIP210]. After VAD no longer indicates the presence of speech/voice, = a grace period of a minimum of two comfort noise vocoder fames are to be = transmitted. The contents of the comfort noise frames is described in the next = section. 11. Section 3 Second Paragraph (required -> needed) (was) The RTP payload for MELPe has the format shown in Figure 1. No = additional header specific to this payload format is required. This format is = intended for the situations where the sender and the receiver send one or more = codec data frames per packet.=20 (now) The RTP payload for MELPe has the format shown in Figure 1. No = additional header specific to this payload format is needed. This format is = intended for the situations where the sender and the receiver send one or more = codec data frames per packet.=20 12. Text after Table 3.4 (required -> needed) (was) Since only msvq[0] (also known as LSF1x or the first LSP) and gain[1] = (also known as g2x or the second gain) are required, the following bit order = is used for comfort noise frames. (now) Since only msvq[0] (also known as LSF1x or the first LSP) and gain[1] = (also known as g2x or the second gain) are needed, the following bit order is = used for comfort noise frames. 13. Section 3.3 First Paragraph (may -> MAY) (may be required -> is = used) (was) A MELPe RTP packet may consist of zero or more MELPe coder frames, = followed by zero or one MELPe Comfort Noise frames. The presence of a comfort = noise frame can be deduced from the length of the RTP payload. The default = packetization interval is one coder frame (22.5, 67.5 or 90 ms) according to the = coder bit rate (2400, 1200 or 600 bps). For some applications, a longer packetization interval may be required to reduce the packet rate. (now) A MELPe RTP packet MAY consist of zero or more MELPe coder frames, = followed by zero or one MELPe Comfort Noise frames. The presence of a comfort = noise frame can be deduced from the length of the RTP payload. The default = packetization interval is one coder frame (22.5, 67.5 or 90 ms) according to the = coder bit rate (2400, 1200 or 600 bps). For some applications, a longer packetization interval is used to reduce the packet rate. 14. Section 3.3 Second Paragraph (may -> MAY) (was) A MELPe RTP packet comprised of no coder frame and no comfort noise = frame may be used periodically by an end point to indicate connectivity by an = otherwise idle receiver. (now) A MELPe RTP packet comprised of no coder frame and no comfort noise = frame MAY be used periodically by an end point to indicate connectivity by an = otherwise idle receiver. 15. Section 3.3 Second to Last Paragraph (may -> can) (was) 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 MELPe frames is to count the total number of octets within the RTP = packet, and divide the octet count by the number of expected octets per frame = (7/11/7 per frame). Keep in mind the last frame may be a 2 octet comfort noise = frame. =20 (now) 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 MELPe frames is to count the total number of octets within the RTP = packet, and divide the octet count by the number of expected octets per frame = (7/11/7 per frame). Keep in mind the last frame can be a 2 octet comfort noise = frame. =20 16. Section 4.2 Last Paragraph (may -> can) (was) The value for "packet time" and "maximum packet time" parameters of the = "ptime" and "maxptime" SDP attributes respectively, SHALL use the nearest = rounded-up ms integer packet duration. For MELPe, this corresponds to the values: = 23, 45, 68, 90, 112, 135, 156, and 180. Larger values may be used as long as = they are properly rounded. (now) The value for "packet time" and "maximum packet time" parameters of the = "ptime" and "maxptime" SDP attributes respectively, SHALL use the nearest = rounded-up ms integer packet duration. For MELPe, this corresponds to the values: = 23, 45, 68, 90, 112, 135, 156, and 180. Larger values can be used as long as = they are properly rounded. 17. Section 4.3 First Paragraph (may -> MAY) (was) For declarative media, the "bitrate" parameter specifes the possible = bit rates used by the sender. Multiple MELPe rtpmap values (such as 97, 98, and = 99 as used below) may be used to convey MELPe coded voice at different bit = rates. The receiver can then select an appropriate MELPe codec by using 97, = 98, or 99. (now) For declarative media, the "bitrate" parameter specifes the possible = bit rates used by the sender. Multiple MELPe rtpmap values (such as 97, 98, and = 99 as used below) MAY be used to convey MELPe coded voice at different bit = rates. The receiver can then select an appropriate MELPe codec by using 97, = 98, or 99. 18. Section 4.4 First Two Paragraphs (may -> MAY) (may -> MAY) (may -> = MAY) (was) In an Offer/Answer mode [RFC3264], "bitrate" is a bi-directional = parameter. Both sides MUST use a common "bitrate" value or values. The offer = contains the bit rates supported by the offerer listed in its preferred order. The = answerer may agree to any bit rate by listing the bit rate first in the answerer response. Additionally the answerer may indicate any secondary bit = rate or bit rates that it supports. The initial bit rate used by both parties = SHALL be the first bit rate specified in the answerer response.=20 For example if offerer bit rates are "2400,600", and answer bit rates = are "600,2400", the initial bit rate is 600. If other bit rates are provided by the = answerer, any common bit rate between offer and answer may be used at any time in the = future. =20 Activation of these other common bit rates is beyond the scope of this = document. (now) In an Offer/Answer mode [RFC3264], "bitrate" is a bi-directional = parameter. Both sides MUST use a common "bitrate" value or values. The offer = contains the bit rates supported by the offerer listed in its preferred order. The = answerer MAY agree to any bit rate by listing the bit rate first in the answerer response. Additionally the answerer MAY indicate any secondary bit = rate or bit rates that it supports. The initial bit rate used by both parties = SHALL be the first bit rate specified in the answerer response.=20 For example if offerer bit rates are "2400,600", and answer bit rates = are "600,2400", the initial bit rate is 600. If other bit rates are provided by the = answerer, any common bit rate between offer and answer MAY be used at any time in the = future. =20 Activation of these other common bit rates is beyond the scope of this = document. 19. Section 5 (review) (is) A primary application of MELPe is for radio communications of voice conversations and discontinuous transmissions are normal. When MELPe = is used in an IP network, MELPe RTP packet transmissions may cease and resume frequently. RTP SSRC sequence number gaps indicate lost packets to be = filled=20 by PLC while abrupt loss of RTP packets indicate intended discontinuous = transmission. If a MELPe coder so desires, it may send a comfort noise frame as per = SCIP-210 Appendix B [SCIP210] prior to ceasing transmission. A receiver may = optionally use comfort noise during its silence periods. No SDP negotiations are required. (review) This uses "may" three times and "required" and "optionally" one each. = Should any be capitalized or changed to a different word? ------=_NextPart_000_0284_01D2733B.DB585670--