Internet Engineering Task Force (IETF) V. Demjanenko
Request for Comments: 8130 D. Satterlee
Category: Standards Track VOCAL Technologies, Ltd.
ISSN: 2070-1721 March 2017
Internet Engineering Task Force (IETF) V. Demjanenko
Request for Comments: 8130 D. Satterlee
Category: Standards Track VOCAL Technologies, Ltd.
ISSN: 2070-1721 March 2017
RTP Payload Format for the Mixed Excitation Linear Prediction Enhanced (MELPe) Codec
混合激励线性预测增强（MELPe）编解码器的RTP有效载荷格式
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 frame sizes are supported. Comfort noise procedures and packet loss concealment are described in detail.
本文描述了混合激励线性预测增强（MELPe）语音编码器的RTP有效载荷格式。MELPe支持三种不同的语音编码速率和样本帧大小。详细描述了舒适噪声过程和包丢失隐藏。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8130.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8130.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions ................................................2
2. Background ......................................................3
3. Payload Format ..................................................4
3.1. MELPe Bitstream Definitions ................................5
3.1.1. 2400 bps Bitstream Structure ........................6
3.1.2. 1200 bps Bitstream Structure ........................9
3.1.3. 600 bps Bitstream Structure ........................13
3.2. MELPe Comfort Noise Bitstream Definition ..................18
3.3. Multiple MELPe Frames in an RTP Packet ....................20
3.4. Congestion Control Considerations .........................21
4. Payload Format Parameters ......................................22
4.1. Media Type Definitions ....................................22
4.2. Mapping to SDP ............................................23
4.3. Declarative SDP Considerations ............................25
4.4. Offer/Answer SDP Considerations ...........................25
5. Discontinuous Transmissions ....................................26
6. Packet Loss Concealment ........................................26
7. IANA Considerations ............................................26
8. Security Considerations ........................................27
9. References .....................................................27
9.1. Normative References ......................................27
9.2. Informative References ....................................29
Authors' Addresses ................................................30
1. Introduction ....................................................2
1.1. Conventions ................................................2
2. Background ......................................................3
3. Payload Format ..................................................4
3.1. MELPe Bitstream Definitions ................................5
3.1.1. 2400 bps Bitstream Structure ........................6
3.1.2. 1200 bps Bitstream Structure ........................9
3.1.3. 600 bps Bitstream Structure ........................13
3.2. MELPe Comfort Noise Bitstream Definition ..................18
3.3. Multiple MELPe Frames in an RTP Packet ....................20
3.4. Congestion Control Considerations .........................21
4. Payload Format Parameters ......................................22
4.1. Media Type Definitions ....................................22
4.2. Mapping to SDP ............................................23
4.3. Declarative SDP Considerations ............................25
4.4. Offer/Answer SDP Considerations ...........................25
5. Discontinuous Transmissions ....................................26
6. Packet Loss Concealment ........................................26
7. IANA Considerations ............................................26
8. Security Considerations ........................................27
9. References .....................................................27
9.1. Normative References ......................................27
9.2. Informative References ....................................29
Authors' Addresses ................................................30
This document describes how compressed Mixed Excitation Linear Prediction Enhanced (MELPe) speech as produced by the MELPe codec may be formatted for use as an RTP payload. Details are provided to packetize the three different codec bitrate data frames (2400, 1200, and 600) into RTP packets. The sender may send one or more codec data frames per packet, depending on the application scenario or based on transport network conditions, bandwidth restrictions, delay requirements, and packet loss tolerance.
本文档描述了如何格式化由MELPe编解码器产生的压缩混合激励线性预测增强（MELPe）语音，以用作RTP有效负载。提供了将三个不同编解码器比特率数据帧（2400、1200和600）打包成RTP包的详细信息。发送方可以根据应用场景或基于传输网络条件、带宽限制、延迟要求和分组丢失容限，为每个分组发送一个或多个编解码器数据帧。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Best current practices for writing an RTP payload format specification were followed [RFC2736].
遵循了编写RTP有效负载格式规范的最佳当前实践[RFC2736]。
The MELP speech coder was developed by the US military as an upgrade from the LPC-based CELP standard vocoder for low-bitrate communications [MELP]. ("LPC" stands for "Linear-Predictive Coding", and "CELP" stands for "Code-Excited Linear Prediction".) MELP was further enhanced and subsequently adopted by NATO as MELPe for use by its members and Partnership for Peace countries for military and other governmental communications [MELPE]. The MELP speech coder algorithm was developed by Atlanta Signal Processing (ASPI), Texas Instruments (TI), SignalCom (now Microsoft), and Thales Communications, with noise preprocessor contributions from AT&T, under contract with NSA/DOD as international NATO Standard STANAG 4591 [MELPE].
MELP语音编码器是美国军方从基于LPC的CELP标准声码器升级而来，用于低比特率通信[MELP]。（“LPC”代表“线性预测编码”，“CELP”代表“码激励线性预测”。）MELP进一步增强，随后被北约作为MELPe采用，供其成员国和和平伙伴关系国家用于军事和其他政府通信[MELPe]。MELP语音编码器算法由亚特兰大信号处理公司（ASPI）、德克萨斯仪器公司（TI）、SignalCom公司（现为微软）和泰利斯通信公司开发，噪声预处理器由AT&T提供，并作为北约国际标准STANAG 4591[MELPE]与NSA/DOD签订合同。
Commercial/civilian applications have arisen because of the low-bitrate property of MELPe with its (relatively) high intelligibility. As such, MELPe is being used in a variety of wired and radio communications systems. Voice over IP (VoIP) / SIP systems need to transport MELPe without decoding and re-encoding in order to preserve its intelligibility. Hence, it is desirable and necessary to define the proper payload formatting and use conventions of MELPe in RTP payloads.
由于MELPe具有（相对）高清晰度的低比特率特性，因此出现了商业/民用应用。因此，MELPe被用于各种有线和无线通信系统。IP语音（VoIP）/SIP系统需要在不解码和重新编码的情况下传输MELPe，以保持其可懂度。因此，在RTP有效载荷中定义适当的有效载荷格式和MELPe的使用约定是可取和必要的。
The MELPe codec [MELPE] supports three different vocoder bitrates: 2400, 1200, and 600 bps. The basic 2400 bps bitrate vocoder uses a 22.5 ms frame of speech consisting of 180 8000-Hz, 16-bit speech samples. The 1200 and 600 bps bitrate vocoders each use three and four 22.5 ms frames of speech, respectively. These reduced-bitrate vocoders internally use multiple 2400 bps parameter sets with further processing to strategically remove redundancy. The payload sizes for each of the bitrates are 54, 81, and 54 bits for the 2400, 1200, and 600 bps frames, respectively. Dynamic bitrate switching is permitted but only if supported by both endpoints.
MELPe编解码器[MELPe]支持三种不同的声码器比特率：2400、1200和600 bps。基本2400 bps比特率声码器使用22.5 ms的语音帧，包括180 8000 Hz的16位语音样本。1200和600 bps比特率声码器分别使用三帧和四帧22.5 ms的语音帧。这些降低比特率的声码器在内部使用多个2400 bps参数集，并进行进一步处理，以从战略上消除冗余。对于2400、1200和600 bps帧，每个比特率的有效负载大小分别为54、81和54比特。允许动态比特率切换，但仅当两个端点都支持时。
The MELPe algorithm distinguishes between voiced and unvoiced speech and encodes each differently. Unvoiced speech can be coded with fewer information bits for the same quality. Forward error correction (FEC) is applied to the 2400 bps codec unvoiced speech for better protection of the subtle differences in signal reconstruction. The lower-bitrate coders do not allocate any bits for FEC and rely on strong error protection and correction in the communications channel.
MELPe算法区分浊音和清音语音，并对每种语音进行不同的编码。对于相同的质量，清音语音可以用较少的信息位进行编码。前向纠错（FEC）应用于2400 bps编解码器清音语音，以更好地保护信号重建中的细微差异。低比特率编码器不为FEC分配任何比特，并且依赖于通信信道中的强错误保护和校正。
Comfort noise handling for MELPe follows the procedures in Appendix B of SCIP-210 [SCIP210]. After Voice Activity Detection (VAD) no longer indicates the presence of speech/voice, a minimum of two comfort noise vocoder frames (serving as a grace period) are to be transmitted. The contents of the comfort noise frames are described in the next section.
MELPe的舒适性噪声处理遵循SCIP-210[SCIP210]附录B中的程序。在语音活动检测（VAD）不再指示存在语音/语音后，至少要发送两个舒适噪声声码器帧（用作宽限期）。舒适噪音框架的内容将在下一节中介绍。
Packet loss concealment (PLC) exploits the FEC (and, more precisely, any combination of two set bits in the pitch/voicing parameter) of the 2400 bps speech coder. The pitch/voicing parameter has a sparse set of permitted values. A value of zero indicates a non-voiced frame. At least three bits are set for all valid pitch parameters. The PLC erasure indication utilizes any errored/erasure encodings of the pitch/voicing parameter with exactly two set bits, as described below.
丢包隐藏（PLC）利用2400 bps语音编码器的FEC（更准确地说，是基音/语音参数中两个设定位的任意组合）。俯仰/发声参数有一组稀疏的允许值。值为零表示非浊音帧。至少为所有有效变桨参数设置三位。PLC擦除指示利用音高/语音参数的任何错误/擦除编码和两个设定位，如下所述。
The MELPe codec uses 22.5, 67.5, or 90 ms frames with a sampling rate clock of 8 kHz, so the RTP timestamp MUST be in units of 1/8000 of a second.
MELPe编解码器使用采样率时钟为8 kHz的22.5、67.5或90 ms帧，因此RTP时间戳必须以1/8000秒为单位。
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 situations where the sender and the receiver send one or more codec data frames per packet.
MELPe的RTP有效负载的格式如图1所示。不需要特定于此有效负载格式的附加标头。此格式适用于发送方和接收方每个数据包发送一个或多个编解码器数据帧的情况。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+ one or more frames of MELPe |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+ one or more frames of MELPe |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Packet Format Diagram
图1：数据包格式图
The RTP header of the packetized encoded MELPe speech has the expected values as described in [RFC3550]. The usage of the M bit SHOULD be as specified in the applicable RTP profile -- for example, [RFC3551], where [RFC3551] specifies that if the sender does not suppress silence (i.e., sends a frame on every frame interval), the M bit will always be zero. 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.
分组编码MELPe语音的RTP报头具有[RFC3550]中所述的预期值。M位的使用应符合适用RTP配置文件的规定——例如，[RFC3551]，其中[RFC3551]规定，如果发送方不抑制静默（即，在每个帧间隔发送一帧），M位将始终为零。当单个RTP数据包中存在多个编解码器数据帧时，时间戳总是RTP数据包中表示的最旧数据帧的时间戳。
The assignment of an RTP payload type for this new packet format is outside the scope of this document and will not be specified here. It is expected that the RTP profile for a particular class of applications will assign a payload type for this encoding, or if that is not done, then a payload type in the dynamic range shall be chosen by the sender.
此新数据包格式的RTP有效负载类型的分配超出了本文档的范围，此处将不进行指定。预计特定类别应用的RTP配置文件将为此编码分配有效负载类型，或者如果未分配有效负载类型，则发送方应选择动态范围内的有效负载类型。
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 1200 bps speech, the total number of bits used is 81, which fits in 11 octets (with seven unused bits). For 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 Section 3.3 in support of dynamic bitrate switching.
用于描述2400 bps语音的一帧的总位数为54，适合7个八位字节（有两个未使用的位）。对于1200 bps的语音，使用的总比特数为81，可容纳11个八位字节（7个未使用的比特）。对于600 bps的语音，使用的总比特数为54，适合7个八位字节（有两个未使用的比特）。未使用的位（如下所示为RSVA、RSVB等）按照第3.3节所述进行编码，以支持动态比特率切换。
In the MELPe bitstream definitions, the most significant bits are considered priority bits. The intention was that these bits receive greater protection in the underlying communications channel. For IP networks, such additional protection is irrelevant. However, for the convenience of interoperable gateway devices, the bitstreams will be presented identically in IP networks.
在MELPe比特流定义中，最高有效位被视为优先级位。其目的是使这些比特在底层通信信道中得到更大的保护。对于IP网络，这种额外的保护是不相关的。然而，为了便于互操作网关设备，比特流将在IP网络中以相同的方式呈现。
According to Table 3 of [MELPE], the 2400 bps MELPe bit transmission order (for clarity, the bit priority is not shown) is as follows:
根据[MELPE]的表3，2400 bps的MELPE比特传输顺序（为清楚起见，未显示比特优先级）如下所示：
+--------+-------------+-------------+
| Bit | Voiced | Unvoiced |
+--------+-------------+-------------+
| B_01 | g20 | g20 |
| B_02 | BP0 | FEC10 |
| B_03 | P0 | P0 |
| B_04 | LSF20 | LSF20 |
| B_05 | LSF30 | LSF30 |
| B_06 | g23 | g23 |
| B_07 | g24 | g24 |
| B_08 | LSF35 | LSF35 |
+--------+-------------+-------------+
| B_09 | g21 | g21 |
| B_10 | g22 | g22 |
| B_11 | P4 | P4 |
| B_12 | LSF34 | LSF34 |
| B_13 | P5 | P5 |
| B_14 | P1 | P1 |
| B_15 | P2 | P2 |
| B_16 | LSF40 | LSF40 |
+--------+-------------+-------------+
| B_17 | P6 | P6 |
| B_18 | LSF10 | LSF10 |
| B_19 | LSF16 | LSF16 |
| B_20 | LSF45 | LSF45 |
| B_21 | P3 | P3 |
| B_22 | LSF15 | LSF15 |
| B_23 | LSF14 | LSF14 |
| B_24 | LSF25 | LSF25 |
+--------+-------------+-------------+
| B_25 | BP3 | FEC13 |
| B_26 | LSF13 | LSF13 |
| B_27 | LSF12 | LSF12 |
| B_28 | LSF24 | LSF24 |
| B_29 | LSF44 | LSF44 |
| B_30 | FM0 | FEC40 |
| B_31 | LSF11 | LSF11 |
| B_32 | LSF23 | LSF23 |
+--------+-------------+-------------+
| Bit | Voiced | Unvoiced |
+--------+-------------+-------------+
| B_01 | g20 | g20 |
| B_02 | BP0 | FEC10 |
| B_03 | P0 | P0 |
| B_04 | LSF20 | LSF20 |
| B_05 | LSF30 | LSF30 |
| B_06 | g23 | g23 |
| B_07 | g24 | g24 |
| B_08 | LSF35 | LSF35 |
+--------+-------------+-------------+
| B_09 | g21 | g21 |
| B_10 | g22 | g22 |
| B_11 | P4 | P4 |
| B_12 | LSF34 | LSF34 |
| B_13 | P5 | P5 |
| B_14 | P1 | P1 |
| B_15 | P2 | P2 |
| B_16 | LSF40 | LSF40 |
+--------+-------------+-------------+
| B_17 | P6 | P6 |
| B_18 | LSF10 | LSF10 |
| B_19 | LSF16 | LSF16 |
| B_20 | LSF45 | LSF45 |
| B_21 | P3 | P3 |
| B_22 | LSF15 | LSF15 |
| B_23 | LSF14 | LSF14 |
| B_24 | LSF25 | LSF25 |
+--------+-------------+-------------+
| B_25 | BP3 | FEC13 |
| B_26 | LSF13 | LSF13 |
| B_27 | LSF12 | LSF12 |
| B_28 | LSF24 | LSF24 |
| B_29 | LSF44 | LSF44 |
| B_30 | FM0 | FEC40 |
| B_31 | LSF11 | LSF11 |
| B_32 | LSF23 | LSF23 |
+--------+-------------+-------------+
| B_33 | FM7 | FEC22 |
| B_34 | FM6 | FEC21 |
| B_35 | FM5 | FEC20 |
| B_36 | g11 | g11 |
| B_37 | g10 | g10 |
| B_38 | BP2 | FEC12 |
| B_39 | BP1 | FEC11 |
| B_40 | LSF21 | LSF21 |
+--------+-------------+-------------+
| B_41 | LSF33 | LSF33 |
| B_42 | LSF22 | LSF22 |
| B_43 | LSF32 | LSF32 |
| B_44 | LSF31 | LSF31 |
| B_45 | LSF43 | LSF43 |
| B_46 | LSF42 | LSF42 |
| B_47 | AF | FEC42 |
| B_48 | LSF41 | LSF41 |
+--------+-------------+-------------+
| B_49 | FM4 | FEC32 |
| B_50 | FM3 | FEC31 |
| B_51 | FM2 | FEC30 |
| B_52 | FM1 | FEC41 |
| B_53 | g12 | g12 |
| B_54 | SYNC | SYNC |
+--------+-------------+-------------+
+--------+-------------+-------------+
| B_33 | FM7 | FEC22 |
| B_34 | FM6 | FEC21 |
| B_35 | FM5 | FEC20 |
| B_36 | g11 | g11 |
| B_37 | g10 | g10 |
| B_38 | BP2 | FEC12 |
| B_39 | BP1 | FEC11 |
| B_40 | LSF21 | LSF21 |
+--------+-------------+-------------+
| B_41 | LSF33 | LSF33 |
| B_42 | LSF22 | LSF22 |
| B_43 | LSF32 | LSF32 |
| B_44 | LSF31 | LSF31 |
| B_45 | LSF43 | LSF43 |
| B_46 | LSF42 | LSF42 |
| B_47 | AF | FEC42 |
| B_48 | LSF41 | LSF41 |
+--------+-------------+-------------+
| B_49 | FM4 | FEC32 |
| B_50 | FM3 | FEC31 |
| B_51 | FM2 | FEC30 |
| B_52 | FM1 | FEC41 |
| B_53 | g12 | g12 |
| B_54 | SYNC | SYNC |
+--------+-------------+-------------+
Notes: g = Gain BP = Bandpass Voicing P = Pitch/Voicing LSF = Line Spectral Frequencies FEC = Forward Error Correction Parity Bits FM = Fourier Magnitudes AF = Aperiodic Flag B_01 = least significant bit of data set
注：g=增益BP=带通语音P=基音/语音LSF=线路频谱频率FEC=前向纠错奇偶校验位FM=傅里叶幅度AF=非周期标志B_01=数据集的最低有效位
Table 1: Bitstream Definition for MELPe 2400 bps
表1:MELPe 2400 bps的比特流定义
The 2400 bps MELPe RTP payload is constructed as per Figure 2. Note that bit B_01 is placed in the least significant bit (LSB) of the first byte with all other bits in sequence. When filling octets, the least significant bits of the seventh octet are filled with bits B_49 to B_54, respectively.
2400 bps MELPe RTP有效载荷如图2所示。请注意，位B_01与序列中的所有其他位一起放置在第一个字节的最低有效位（LSB）中。当填充八位字节时，第七个八位字节的最低有效位分别被位B_49至B_54填充。
MSB LSB
0 1 2 3 4 5 6 7
+------+------+------+------+------+------+------+------+
| B_08 | B_07 | B_06 | B_05 | B_04 | B_03 | B_02 | B_01 |
+------+------+------+------+------+------+------+------+
| B_16 | B_15 | B_14 | B_13 | B_12 | B_11 | B_10 | B_09 |
+------+------+------+------+------+------+------+------+
| B_24 | B_23 | B_22 | B_21 | B_20 | B_19 | B_18 | B_17 |
+------+------+------+------+------+------+------+------+
| B_32 | B_31 | B_30 | B_29 | B_28 | B_27 | B_26 | B_25 |
+------+------+------+------+------+------+------+------+
| B_40 | B_39 | B_38 | B_37 | B_36 | B_35 | B_34 | B_33 |
+------+------+------+------+------+------+------+------+
| B_48 | B_47 | B_46 | B_45 | B_44 | B_43 | B_42 | B_41 |
+------+------+------+------+------+------+------+------+
| RSVA | RSVB | B_54 | B_53 | B_52 | B_51 | B_50 | B_49 |
+------+------+------+------+------+------+------+------+
MSB LSB
0 1 2 3 4 5 6 7
+------+------+------+------+------+------+------+------+
| B_08 | B_07 | B_06 | B_05 | B_04 | B_03 | B_02 | B_01 |
+------+------+------+------+------+------+------+------+
| B_16 | B_15 | B_14 | B_13 | B_12 | B_11 | B_10 | B_09 |
+------+------+------+------+------+------+------+------+
| B_24 | B_23 | B_22 | B_21 | B_20 | B_19 | B_18 | B_17 |
+------+------+------+------+------+------+------+------+
| B_32 | B_31 | B_30 | B_29 | B_28 | B_27 | B_26 | B_25 |
+------+------+------+------+------+------+------+------+
| B_40 | B_39 | B_38 | B_37 | B_36 | B_35 | B_34 | B_33 |
+------+------+------+------+------+------+------+------+
| B_48 | B_47 | B_46 | B_45 | B_44 | B_43 | B_42 | B_41 |
+------+------+------+------+------+------+------+------+
| RSVA | RSVB | B_54 | B_53 | B_52 | B_51 | B_50 | B_49 |
+------+------+------+------+------+------+------+------+
Figure 2: Packed MELPe 2400 bps Payload Octets
图2：打包的MELPe 2400 bps有效负载八位字节
According to Tables D-9a and D-9b of [MELPE], the 1200 bps MELPe bit transmission order is as follows:
根据[MELPE]的表D-9a和D-9b，1200 bps MELPE比特传输顺序如下：
+--------+-------------+-------------+
| Bit | Modes 1-4 | Mode 5 |
| | (Voiced) | (Unvoiced) |
+--------+-------------+-------------+
| B_01 | Syn | Syn |
| B_02 | Pitch&UV0 | Pitch&UV0 |
| B_03 | Pitch&UV1 | Pitch&UV1 |
| B_04 | Pitch&UV2 | Pitch&UV2 |
| B_05 | Pitch&UV3 | Pitch&UV3 |
| B_06 | Pitch&UV4 | Pitch&UV4 |
| B_07 | Pitch&UV5 | Pitch&UV5 |
| B_08 | Pitch&UV6 | Pitch&UV6 |
+--------+-------------+-------------+
| B_09 | Pitch&UV7 | Pitch&UV7 |
| B_10 | Pitch&UV8 | Pitch&UV8 |
| B_11 | Pitch&UV9 | Pitch&UV9 |
| B_12 | Pitch&UV10 | Pitch&UV10 |
| B_13 | Pitch&UV11 | Pitch&UV11 |
| B_14 | LSP0 | LSP0 |
| B_15 | LSP1 | LSP1 |
| B_16 | LSP2 | LSP2 |
+--------+-------------+-------------+
| B_17 | LSP3 | LSP3 |
| B_18 | LSP4 | LSP4 |
| B_19 | LSP5 | LSP5 |
| B_20 | LSP6 | LSP6 |
| B_21 | LSP7 | LSP7 |
| B_22 | LSP8 | LSP8 |
| B_23 | LSP9 | LSP9 |
| B_24 | LSP10 | LSP10 |
+--------+-------------+-------------+
| B_25 | LSP11 | LSP11 |
| B_26 | LSP12 | LSP12 |
| B_27 | LSP13 | LSP13 |
| B_28 | LSP14 | LSP14 |
| B_29 | LSP15 | LSP15 |
| B_30 | LSP16 | LSP16 |
| B_31 | LSP17 | LSP17 |
| B_32 | LSP18 | LSP18 |
+--------+-------------+-------------+
| Bit | Modes 1-4 | Mode 5 |
| | (Voiced) | (Unvoiced) |
+--------+-------------+-------------+
| B_01 | Syn | Syn |
| B_02 | Pitch&UV0 | Pitch&UV0 |
| B_03 | Pitch&UV1 | Pitch&UV1 |
| B_04 | Pitch&UV2 | Pitch&UV2 |
| B_05 | Pitch&UV3 | Pitch&UV3 |
| B_06 | Pitch&UV4 | Pitch&UV4 |
| B_07 | Pitch&UV5 | Pitch&UV5 |
| B_08 | Pitch&UV6 | Pitch&UV6 |
+--------+-------------+-------------+
| B_09 | Pitch&UV7 | Pitch&UV7 |
| B_10 | Pitch&UV8 | Pitch&UV8 |
| B_11 | Pitch&UV9 | Pitch&UV9 |
| B_12 | Pitch&UV10 | Pitch&UV10 |
| B_13 | Pitch&UV11 | Pitch&UV11 |
| B_14 | LSP0 | LSP0 |
| B_15 | LSP1 | LSP1 |
| B_16 | LSP2 | LSP2 |
+--------+-------------+-------------+
| B_17 | LSP3 | LSP3 |
| B_18 | LSP4 | LSP4 |
| B_19 | LSP5 | LSP5 |
| B_20 | LSP6 | LSP6 |
| B_21 | LSP7 | LSP7 |
| B_22 | LSP8 | LSP8 |
| B_23 | LSP9 | LSP9 |
| B_24 | LSP10 | LSP10 |
+--------+-------------+-------------+
| B_25 | LSP11 | LSP11 |
| B_26 | LSP12 | LSP12 |
| B_27 | LSP13 | LSP13 |
| B_28 | LSP14 | LSP14 |
| B_29 | LSP15 | LSP15 |
| B_30 | LSP16 | LSP16 |
| B_31 | LSP17 | LSP17 |
| B_32 | LSP18 | LSP18 |
+--------+-------------+-------------+
| B_33 | LSP19 | LSP19 |
| B_34 | LSP20 | LSP20 |
| B_35 | LSP21 | LSP21 |
| B_36 | LSP22 | LSP22 |
| B_37 | LSP23 | LSP23 |
| B_38 | LSP24 | LSP24 |
| B_39 | LSP25 | LSP25 |
| B_40 | LSP26 | LSP26 |
+--------+-------------+-------------+
| B_41 | LSP27 | GAIN0 |
| B_42 | LSP28 | GAIN1 |
| B_43 | LSP29 | GAIN2 |
| B_44 | LSP30 | GAIN3 |
| B_45 | LSP31 | GAIN4 |
| B_46 | LSP32 | GAIN5 |
| B_47 | LSP33 | GAIN6 |
| B_48 | LSP34 | GAIN7 |
+--------+-------------+-------------+
| B_49 | LSP35 | GAIN8 |
| B_50 | LSP36 | GAIN9 |
| B_51 | LSP37 | |
| B_52 | LSP38 | |
| B_53 | LSP39 | |
| B_54 | LSP40 | |
| B_55 | LSP41 | |
| B_56 | LSP42 | |
+--------+-------------+-------------+
| B_57 | GAIN0 | |
| B_58 | GAIN1 | |
| B_59 | GAIN2 | |
| B_60 | GAIN3 | |
| B_61 | GAIN4 | |
| B_62 | GAIN5 | |
| B_63 | GAIN6 | |
| B_64 | GAIN7 | |
+--------+-------------+-------------+
| B_65 | GAIN8 | |
| B_66 | GAIN9 | |
| B_67 | BP0 | |
| B_68 | BP1 | |
| B_69 | BP2 | |
| B_70 | BP3 | |
| B_71 | BP4 | |
| B_72 | BP5 | |
+--------+-------------+-------------+
| B_33 | LSP19 | LSP19 |
| B_34 | LSP20 | LSP20 |
| B_35 | LSP21 | LSP21 |
| B_36 | LSP22 | LSP22 |
| B_37 | LSP23 | LSP23 |
| B_38 | LSP24 | LSP24 |
| B_39 | LSP25 | LSP25 |
| B_40 | LSP26 | LSP26 |
+--------+-------------+-------------+
| B_41 | LSP27 | GAIN0 |
| B_42 | LSP28 | GAIN1 |
| B_43 | LSP29 | GAIN2 |
| B_44 | LSP30 | GAIN3 |
| B_45 | LSP31 | GAIN4 |
| B_46 | LSP32 | GAIN5 |
| B_47 | LSP33 | GAIN6 |
| B_48 | LSP34 | GAIN7 |
+--------+-------------+-------------+
| B_49 | LSP35 | GAIN8 |
| B_50 | LSP36 | GAIN9 |
| B_51 | LSP37 | |
| B_52 | LSP38 | |
| B_53 | LSP39 | |
| B_54 | LSP40 | |
| B_55 | LSP41 | |
| B_56 | LSP42 | |
+--------+-------------+-------------+
| B_57 | GAIN0 | |
| B_58 | GAIN1 | |
| B_59 | GAIN2 | |
| B_60 | GAIN3 | |
| B_61 | GAIN4 | |
| B_62 | GAIN5 | |
| B_63 | GAIN6 | |
| B_64 | GAIN7 | |
+--------+-------------+-------------+
| B_65 | GAIN8 | |
| B_66 | GAIN9 | |
| B_67 | BP0 | |
| B_68 | BP1 | |
| B_69 | BP2 | |
| B_70 | BP3 | |
| B_71 | BP4 | |
| B_72 | BP5 | |
+--------+-------------+-------------+
| B_73 | JITTER | |
| B_74 | FS0 | |
| B_75 | FS1 | |
| B_76 | FS2 | |
| B_77 | FS3 | |
| B_78 | FS4 | |
| B_79 | FS5 | |
| B_80 | FS6 | |
+--------+-------------+-------------+
| B_81 | FS7 | |
+--------+-------------+-------------+
+--------+-------------+-------------+
| B_73 | JITTER | |
| B_74 | FS0 | |
| B_75 | FS1 | |
| B_76 | FS2 | |
| B_77 | FS3 | |
| B_78 | FS4 | |
| B_79 | FS5 | |
| B_80 | FS6 | |
+--------+-------------+-------------+
| B_81 | FS7 | |
+--------+-------------+-------------+
Notes: BP = Bandpass voicing FS = Fourier magnitudes LSP = Line Spectral Pair Pitch&UV = Pitch/voicing GAIN = Gain JITTER = Jitter
注：BP=带通语音FS=傅里叶幅度LSP=线谱对基音&UV=基音/语音增益=增益抖动=抖动
Table 2: Bitstream Definition for MELPe 1200 bps
表2:MELPe 1200 bps的比特流定义
The 1200 bps MELPe RTP payload is constructed as per Figure 3. Note that bit B_01 is placed in the LSB of the first byte with all other bits in sequence. When filling octets, the least significant bit of the eleventh octet is filled with bit B_81.
1200 bps MELPe RTP有效载荷如图3所示。请注意，位B_01与所有其他位按顺序放置在第一个字节的LSB中。填充八位字节时，第十一个八位字节的最低有效位用位B_81填充。
MSB LSB
0 1 2 3 4 5 6 7
+------+------+------+------+------+------+------+------+
| B_08 | B_07 | B_06 | B_05 | B_04 | B_03 | B_02 | B_01 |
+------+------+------+------+------+------+------+------+
| B_16 | B_15 | B_14 | B_13 | B_12 | B_11 | B_10 | B_09 |
+------+------+------+------+------+------+------+------+
| B_24 | B_23 | B_22 | B_21 | B_20 | B_19 | B_18 | B_17 |
+------+------+------+------+------+------+------+------+
| B_32 | B_31 | B_30 | B_29 | B_28 | B_27 | B_26 | B_25 |
+------+------+------+------+------+------+------+------+
| B_40 | B_39 | B_38 | B_37 | B_36 | B_35 | B_34 | B_33 |
+------+------+------+------+------+------+------+------+
| B_48 | B_47 | B_46 | B_45 | B_44 | B_43 | B_42 | B_41 |
+------+------+------+------+------+------+------+------+
| B_56 | B_55 | B_54 | B_53 | B_52 | B_51 | B_50 | B_49 |
+------+------+------+------+------+------+------+------+
| B_64 | B_63 | B_62 | B_61 | B_60 | B_59 | B_58 | B_57 |
+------+------+------+------+------+------+------+------+
| B_72 | B_71 | B_70 | B_69 | B_68 | B_67 | B_66 | B_65 |
+------+------+------+------+------+------+------+------+
| B_80 | B_79 | B_78 | B_77 | B_76 | B_75 | B_74 | B_73 |
+------+------+------+------+------+------+------+------+
| RSVA | RSVB | RSVC | RSV0 | RSV0 | RSV0 | RSV0 | B_81 |
+------+------+------+------+------+------+------+------+
MSB LSB
0 1 2 3 4 5 6 7
+------+------+------+------+------+------+------+------+
| B_08 | B_07 | B_06 | B_05 | B_04 | B_03 | B_02 | B_01 |
+------+------+------+------+------+------+------+------+
| B_16 | B_15 | B_14 | B_13 | B_12 | B_11 | B_10 | B_09 |
+------+------+------+------+------+------+------+------+
| B_24 | B_23 | B_22 | B_21 | B_20 | B_19 | B_18 | B_17 |
+------+------+------+------+------+------+------+------+
| B_32 | B_31 | B_30 | B_29 | B_28 | B_27 | B_26 | B_25 |
+------+------+------+------+------+------+------+------+
| B_40 | B_39 | B_38 | B_37 | B_36 | B_35 | B_34 | B_33 |
+------+------+------+------+------+------+------+------+
| B_48 | B_47 | B_46 | B_45 | B_44 | B_43 | B_42 | B_41 |
+------+------+------+------+------+------+------+------+
| B_56 | B_55 | B_54 | B_53 | B_52 | B_51 | B_50 | B_49 |
+------+------+------+------+------+------+------+------+
| B_64 | B_63 | B_62 | B_61 | B_60 | B_59 | B_58 | B_57 |
+------+------+------+------+------+------+------+------+
| B_72 | B_71 | B_70 | B_69 | B_68 | B_67 | B_66 | B_65 |
+------+------+------+------+------+------+------+------+
| B_80 | B_79 | B_78 | B_77 | B_76 | B_75 | B_74 | B_73 |
+------+------+------+------+------+------+------+------+
| RSVA | RSVB | RSVC | RSV0 | RSV0 | RSV0 | RSV0 | B_81 |
+------+------+------+------+------+------+------+------+
Figure 3: Packed MELPe 1200 bps Payload Octets
图3：压缩MELPe 1200 bps有效负载八位字节
According to Tables M-11 to M-16 of [MELPE], the 600 bps MELPe bit transmission order (for clarity, the bit priority is not shown) is as follows:
根据[MELPE]的表M-11至M-16，600 bps MELPE比特传输顺序（为清楚起见，未显示比特优先级）如下所示：
+--------+-------------+-------------+-------------+
| Bit | Mode 1 | Mode 2 | Mode 3 |
| | (Voiced) | (voiced) | (voiced) |
+--------+-------------+-------------+-------------+
| B_01 | Voicing (4) | Voicing (4) | Voicing (4) |
| B_02 | Voicing (3) | Voicing (3) | Voicing (3) |
| B_03 | Voicing (2) | Voicing (2) | Voicing (2) |
| B_04 | Voicing (1) | Voicing (1) | Voicing (1) |
| B_05 | Voicing (0) | Voicing (0) | Voicing (0) |
| B_06 | LSF1,4 (3) | Pitch (5) | Pitch (7) |
| B_07 | LSF1,4 (2) | Pitch (4) | Pitch (6) |
| B_08 | LSF1,4 (1) | Pitch (3) | Pitch (5) |
+--------+-------------+-------------+-------------+
| B_09 | LSF1,4 (0) | Pitch (2) | Pitch (4) |
| B_10 | LSF1,3 (3) | Pitch (1) | Pitch (3) |
| B_11 | LSF1,3 (2) | Pitch (0) | Pitch (2) |
| B_12 | LSF1,3 (1) | LSF1,3 (3) | Pitch (1) |
| B_13 | LSF1,3 (0) | LSF1,3 (2) | Pitch (0) |
| B_14 | LSF1,2 (3) | LSF1,3 (1) | LSF1,3 (3) |
| B_15 | LSF1,2 (2) | LSF1,3 (0) | LSF1,3 (2) |
| B_16 | LSF1,2 (1) | LSF1,2 (3) | LSF1,3 (1) |
+--------+-------------+-------------+-------------+
| B_17 | LSF1,2 (0) | LSF1,2 (2) | LSF1,3 (0) |
| B_18 | LSF1,1 (5) | LSF1,2 (1) | LSF1,2 (4) |
| B_19 | LSF1,1 (4) | LSF1,2 (0) | LSF1,2 (3) |
| B_20 | LSF1,1 (3) | LSF1,1 (5) | LSF1,2 (2) |
| B_21 | LSF1,1 (2) | LSF1,1 (4) | LSF1,2 (1) |
| B_22 | LSF1,1 (1) | LSF1,1 (3) | LSF1,2 (0) |
| B_23 | LSF1,1 (0) | LSF1,1 (2) | LSF1,1 (5) |
| B_24 | LSF2,4 (3) | LSF1,1 (1) | LSF1,1 (4) |
+--------+-------------+-------------+-------------+
| B_25 | LSF2,4 (2) | LSF1,1 (0) | LSF1,1 (3) |
| B_26 | LSF2,4 (1) | LSF2,3 (3) | LSF1,1 (2) |
| B_27 | LSF2,4 (0) | LSF2,3 (2) | LSF1,1 (1) |
| B_28 | LSF2,3 (3) | LSF2,3 (1) | LSF1,1 (0) |
| B_29 | LSF2,3 (2) | LSF2,3 (0) | LSF2,3 (3) |
| B_30 | LSF2,3 (1) | LSF2,2 (4) | LSF2,3 (2) |
| B_31 | LSF2,3 (0) | LSF2,2 (3) | LSF2,3 (1) |
| B_32 | LSF2,2 (3) | LSF2,2 (2) | LSF2,3 (0) |
+--------+-------------+-------------+-------------+
| Bit | Mode 1 | Mode 2 | Mode 3 |
| | (Voiced) | (voiced) | (voiced) |
+--------+-------------+-------------+-------------+
| B_01 | Voicing (4) | Voicing (4) | Voicing (4) |
| B_02 | Voicing (3) | Voicing (3) | Voicing (3) |
| B_03 | Voicing (2) | Voicing (2) | Voicing (2) |
| B_04 | Voicing (1) | Voicing (1) | Voicing (1) |
| B_05 | Voicing (0) | Voicing (0) | Voicing (0) |
| B_06 | LSF1,4 (3) | Pitch (5) | Pitch (7) |
| B_07 | LSF1,4 (2) | Pitch (4) | Pitch (6) |
| B_08 | LSF1,4 (1) | Pitch (3) | Pitch (5) |
+--------+-------------+-------------+-------------+
| B_09 | LSF1,4 (0) | Pitch (2) | Pitch (4) |
| B_10 | LSF1,3 (3) | Pitch (1) | Pitch (3) |
| B_11 | LSF1,3 (2) | Pitch (0) | Pitch (2) |
| B_12 | LSF1,3 (1) | LSF1,3 (3) | Pitch (1) |
| B_13 | LSF1,3 (0) | LSF1,3 (2) | Pitch (0) |
| B_14 | LSF1,2 (3) | LSF1,3 (1) | LSF1,3 (3) |
| B_15 | LSF1,2 (2) | LSF1,3 (0) | LSF1,3 (2) |
| B_16 | LSF1,2 (1) | LSF1,2 (3) | LSF1,3 (1) |
+--------+-------------+-------------+-------------+
| B_17 | LSF1,2 (0) | LSF1,2 (2) | LSF1,3 (0) |
| B_18 | LSF1,1 (5) | LSF1,2 (1) | LSF1,2 (4) |
| B_19 | LSF1,1 (4) | LSF1,2 (0) | LSF1,2 (3) |
| B_20 | LSF1,1 (3) | LSF1,1 (5) | LSF1,2 (2) |
| B_21 | LSF1,1 (2) | LSF1,1 (4) | LSF1,2 (1) |
| B_22 | LSF1,1 (1) | LSF1,1 (3) | LSF1,2 (0) |
| B_23 | LSF1,1 (0) | LSF1,1 (2) | LSF1,1 (5) |
| B_24 | LSF2,4 (3) | LSF1,1 (1) | LSF1,1 (4) |
+--------+-------------+-------------+-------------+
| B_25 | LSF2,4 (2) | LSF1,1 (0) | LSF1,1 (3) |
| B_26 | LSF2,4 (1) | LSF2,3 (3) | LSF1,1 (2) |
| B_27 | LSF2,4 (0) | LSF2,3 (2) | LSF1,1 (1) |
| B_28 | LSF2,3 (3) | LSF2,3 (1) | LSF1,1 (0) |
| B_29 | LSF2,3 (2) | LSF2,3 (0) | LSF2,3 (3) |
| B_30 | LSF2,3 (1) | LSF2,2 (4) | LSF2,3 (2) |
| B_31 | LSF2,3 (0) | LSF2,2 (3) | LSF2,3 (1) |
| B_32 | LSF2,2 (3) | LSF2,2 (2) | LSF2,3 (0) |
+--------+-------------+-------------+-------------+
| B_33 | LSF2,2 (2) | LSF2,2 (1) | LSF2,2 (4) |
| B_34 | LSF2,2 (1) | LSF2,2 (0) | LSF2,2 (3) |
| B_35 | LSF2,2 (0) | LSF2,1 (6) | LSF2,2 (2) |
| B_36 | LSF2,1 (5) | LSF2,1 (5) | LSF2,2 (1) |
| B_37 | LSF2,1 (4) | LSF2,1 (4) | LSF2,2 (0) |
| B_38 | LSF2,1 (3) | LSF2,1 (3) | LSF2,1 (5) |
| B_39 | LSF2,1 (2) | LSF2,1 (2) | LSF2,1 (4) |
| B_40 | LSF2,1 (1) | LSF2,1 (1) | LSF2,1 (3) |
+--------+-------------+-------------+-------------+
| B_41 | LSF2,1 (0) | LSF2,1 (0) | LSF2,1 (2) |
| B_42 | GAIN2 (5) | GAIN2 (5) | LSF2,1 (1) |
| B_43 | GAIN2 (4) | GAIN2 (4) | LSF2,1 (0) |
| B_44 | GAIN2 (3) | GAIN2 (3) | GAIN2 (4) |
| B_45 | GAIN2 (2) | GAIN2 (2) | GAIN2 (3) |
| B_46 | GAIN2 (1) | GAIN2 (1) | GAIN2 (2) |
| B_47 | GAIN2 (0) | GAIN2 (0) | GAIN2 (1) |
| B_48 | GAIN1 (6) | GAIN1 (6) | GAIN2 (0) |
+--------+-------------+-------------+-------------+
| B_49 | GAIN1 (5) | GAIN1 (5) | GAIN1 (5) |
| B_50 | GAIN1 (4) | GAIN1 (4) | GAIN1 (4) |
| B_51 | GAIN1 (3) | GAIN1 (3) | GAIN1 (3) |
| B_52 | GAIN1 (2) | GAIN1 (2) | GAIN1 (2) |
| B_53 | GAIN1 (1) | GAIN1 (1) | GAIN1 (1) |
| B_54 | GAIN1 (0) | GAIN1 (0) | GAIN1 (0) |
+--------+-------------+-------------+-------------+
+--------+-------------+-------------+-------------+
| B_33 | LSF2,2 (2) | LSF2,2 (1) | LSF2,2 (4) |
| B_34 | LSF2,2 (1) | LSF2,2 (0) | LSF2,2 (3) |
| B_35 | LSF2,2 (0) | LSF2,1 (6) | LSF2,2 (2) |
| B_36 | LSF2,1 (5) | LSF2,1 (5) | LSF2,2 (1) |
| B_37 | LSF2,1 (4) | LSF2,1 (4) | LSF2,2 (0) |
| B_38 | LSF2,1 (3) | LSF2,1 (3) | LSF2,1 (5) |
| B_39 | LSF2,1 (2) | LSF2,1 (2) | LSF2,1 (4) |
| B_40 | LSF2,1 (1) | LSF2,1 (1) | LSF2,1 (3) |
+--------+-------------+-------------+-------------+
| B_41 | LSF2,1 (0) | LSF2,1 (0) | LSF2,1 (2) |
| B_42 | GAIN2 (5) | GAIN2 (5) | LSF2,1 (1) |
| B_43 | GAIN2 (4) | GAIN2 (4) | LSF2,1 (0) |
| B_44 | GAIN2 (3) | GAIN2 (3) | GAIN2 (4) |
| B_45 | GAIN2 (2) | GAIN2 (2) | GAIN2 (3) |
| B_46 | GAIN2 (1) | GAIN2 (1) | GAIN2 (2) |
| B_47 | GAIN2 (0) | GAIN2 (0) | GAIN2 (1) |
| B_48 | GAIN1 (6) | GAIN1 (6) | GAIN2 (0) |
+--------+-------------+-------------+-------------+
| B_49 | GAIN1 (5) | GAIN1 (5) | GAIN1 (5) |
| B_50 | GAIN1 (4) | GAIN1 (4) | GAIN1 (4) |
| B_51 | GAIN1 (3) | GAIN1 (3) | GAIN1 (3) |
| B_52 | GAIN1 (2) | GAIN1 (2) | GAIN1 (2) |
| B_53 | GAIN1 (1) | GAIN1 (1) | GAIN1 (1) |
| B_54 | GAIN1 (0) | GAIN1 (0) | GAIN1 (0) |
+--------+-------------+-------------+-------------+
Table 3: Bitstream Definition for MELPe 600 bps (Part 1 of 2)
表3:MELPe 600 bps的比特流定义（第1部分，共2部分）
+--------+-------------+-------------+-------------+
| Bit | Mode 4 | Mode 5 | Mode 6 |
| | (voiced) | (voiced) | (voiced) |
+--------+-------------+-------------+-------------+
| B_01 | Voicing (4) | Voicing (4) | Voicing (4) |
| B_02 | Voicing (3) | Voicing (3) | Voicing (3) |
| B_03 | Voicing (2) | Voicing (2) | Voicing (2) |
| B_04 | Voicing (1) | Voicing (1) | Voicing (1) |
| B_05 | Voicing (0) | Voicing (0) | Voicing (0) |
| B_06 | Pitch (7) | Pitch (7) | Pitch (7) |
| B_07 | Pitch (6) | Pitch (6) | Pitch (6) |
| B_08 | Pitch (5) | Pitch (5) | Pitch (5) |
+--------+-------------+-------------+-------------+
| B_09 | Pitch (4) | Pitch (4) | Pitch (4) |
| B_10 | Pitch (3) | Pitch (3) | Pitch (3) |
| B_11 | Pitch (2) | Pitch (2) | Pitch (2) |
| B_12 | Pitch (1) | Pitch (1) | Pitch (1) |
| B_13 | Pitch (0) | Pitch (0) | Pitch (0) |
| B_14 | LSF1,3 (3) | LSF1,3 (3) | LSF1,3 (3) |
| B_15 | LSF1,3 (2) | LSF1,3 (2) | LSF1,3 (2) |
| B_16 | LSF1,3 (1) | LSF1,3 (1) | LSF1,3 (1) |
+--------+-------------+-------------+-------------+
| B_17 | LSF1,3 (0) | LSF1,3 (0) | LSF1,3 (0) |
| B_18 | LSF1,2 (3) | LSF1,2 (4) | LSF1,2 (4) |
| B_19 | LSF1,2 (2) | LSF1,2 (3) | LSF1,2 (3) |
| B_20 | LSF1,2 (1) | LSF1,2 (2) | LSF1,2 (2) |
| B_21 | LSF1,2 (0) | LSF1,2 (1) | LSF1,2 (1) |
| B_22 | LSF1,1 (5) | LSF1,2 (0) | LSF1,2 (0) |
| B_23 | LSF1,1 (4) | LSF1,1 (5) | LSF1,1 (6) |
| B_24 | LSF1,1 (3) | LSF1,1 (4) | LSF1,1 (5) |
+--------+-------------+-------------+-------------+
| B_25 | LSF1,1 (2) | LSF1,1 (3) | LSF1,1 (4) |
| B_26 | LSF1,1 (1) | LSF1,1 (2) | LSF1,1 (3) |
| B_27 | LSF1,1 (0) | LSF1,1 (1) | LSF1,1 (2) |
| B_28 | LSF2,3 (3) | LSF1,1 (0) | LSF1,1 (1) |
| B_29 | LSF2,3 (2) | LSF2,3 (3) | LSF1,1 (0) |
| B_30 | LSF2,3 (1) | LSF2,3 (2) | LSF2,3 (3) |
| B_31 | LSF2,3 (0) | LSF2,3 (1) | LSF2,3 (2) |
| B_32 | LSF2,2 (4) | LSF2,3 (0) | LSF2,3 (1) |
+--------+-------------+-------------+-------------+
| B_33 | LSF2,2 (3) | LSF2,2 (4) | LSF2,3 (0) |
| B_34 | LSF2,2 (2) | LSF2,2 (3) | LSF2,2 (4) |
| B_35 | LSF2,2 (1) | LSF2,2 (2) | LSF2,2 (3) |
| B_36 | LSF2,2 (0) | LSF2,2 (1) | LSF2,2 (2) |
| B_37 | LSF2,1 (6) | LSF2,2 (0) | LSF2,2 (1) |
| B_38 | LSF2,1 (5) | LSF2,1 (5) | LSF2,2 (0) |
| B_39 | LSF2,1 (4) | LSF2,1 (4) | LSF2,1 (6) |
| B_40 | LSF2,1 (3) | LSF2,1 (3) | LSF2,1 (5) |
+--------+-------------+-------------+-------------+
| Bit | Mode 4 | Mode 5 | Mode 6 |
| | (voiced) | (voiced) | (voiced) |
+--------+-------------+-------------+-------------+
| B_01 | Voicing (4) | Voicing (4) | Voicing (4) |
| B_02 | Voicing (3) | Voicing (3) | Voicing (3) |
| B_03 | Voicing (2) | Voicing (2) | Voicing (2) |
| B_04 | Voicing (1) | Voicing (1) | Voicing (1) |
| B_05 | Voicing (0) | Voicing (0) | Voicing (0) |
| B_06 | Pitch (7) | Pitch (7) | Pitch (7) |
| B_07 | Pitch (6) | Pitch (6) | Pitch (6) |
| B_08 | Pitch (5) | Pitch (5) | Pitch (5) |
+--------+-------------+-------------+-------------+
| B_09 | Pitch (4) | Pitch (4) | Pitch (4) |
| B_10 | Pitch (3) | Pitch (3) | Pitch (3) |
| B_11 | Pitch (2) | Pitch (2) | Pitch (2) |
| B_12 | Pitch (1) | Pitch (1) | Pitch (1) |
| B_13 | Pitch (0) | Pitch (0) | Pitch (0) |
| B_14 | LSF1,3 (3) | LSF1,3 (3) | LSF1,3 (3) |
| B_15 | LSF1,3 (2) | LSF1,3 (2) | LSF1,3 (2) |
| B_16 | LSF1,3 (1) | LSF1,3 (1) | LSF1,3 (1) |
+--------+-------------+-------------+-------------+
| B_17 | LSF1,3 (0) | LSF1,3 (0) | LSF1,3 (0) |
| B_18 | LSF1,2 (3) | LSF1,2 (4) | LSF1,2 (4) |
| B_19 | LSF1,2 (2) | LSF1,2 (3) | LSF1,2 (3) |
| B_20 | LSF1,2 (1) | LSF1,2 (2) | LSF1,2 (2) |
| B_21 | LSF1,2 (0) | LSF1,2 (1) | LSF1,2 (1) |
| B_22 | LSF1,1 (5) | LSF1,2 (0) | LSF1,2 (0) |
| B_23 | LSF1,1 (4) | LSF1,1 (5) | LSF1,1 (6) |
| B_24 | LSF1,1 (3) | LSF1,1 (4) | LSF1,1 (5) |
+--------+-------------+-------------+-------------+
| B_25 | LSF1,1 (2) | LSF1,1 (3) | LSF1,1 (4) |
| B_26 | LSF1,1 (1) | LSF1,1 (2) | LSF1,1 (3) |
| B_27 | LSF1,1 (0) | LSF1,1 (1) | LSF1,1 (2) |
| B_28 | LSF2,3 (3) | LSF1,1 (0) | LSF1,1 (1) |
| B_29 | LSF2,3 (2) | LSF2,3 (3) | LSF1,1 (0) |
| B_30 | LSF2,3 (1) | LSF2,3 (2) | LSF2,3 (3) |
| B_31 | LSF2,3 (0) | LSF2,3 (1) | LSF2,3 (2) |
| B_32 | LSF2,2 (4) | LSF2,3 (0) | LSF2,3 (1) |
+--------+-------------+-------------+-------------+
| B_33 | LSF2,2 (3) | LSF2,2 (4) | LSF2,3 (0) |
| B_34 | LSF2,2 (2) | LSF2,2 (3) | LSF2,2 (4) |
| B_35 | LSF2,2 (1) | LSF2,2 (2) | LSF2,2 (3) |
| B_36 | LSF2,2 (0) | LSF2,2 (1) | LSF2,2 (2) |
| B_37 | LSF2,1 (6) | LSF2,2 (0) | LSF2,2 (1) |
| B_38 | LSF2,1 (5) | LSF2,1 (5) | LSF2,2 (0) |
| B_39 | LSF2,1 (4) | LSF2,1 (4) | LSF2,1 (6) |
| B_40 | LSF2,1 (3) | LSF2,1 (3) | LSF2,1 (5) |
+--------+-------------+-------------+-------------+
| B_41 | LSF2,1 (2) | LSF2,1 (2) | LSF2,1 (4) |
| B_42 | LSF2,1 (1) | LSF2,1 (1) | LSF2,1 (3) |
| B_43 | LSF2,1 (0) | LSF2,1 (0) | LSF2,1 (2) |
| B_44 | GAIN2 (4) | GAIN2 (4) | LSF2,1 (1) |
| B_45 | GAIN2 (3) | GAIN2 (3) | LSF2,1 (0) |
| B_46 | GAIN2 (2) | GAIN2 (2) | GAIN1 (8) |
| B_47 | GAIN2 (1) | GAIN2 (1) | GAIN1 (7) |
| B_48 | GAIN2 (0) | GAIN2 (0) | GAIN1 (6) |
+--------+-------------+-------------+-------------+
| B_49 | GAIN1 (5) | GAIN1 (5) | GAIN1 (5) |
| B_50 | GAIN1 (4) | GAIN1 (4) | GAIN1 (4) |
| B_51 | GAIN1 (3) | GAIN1 (3) | GAIN1 (3) |
| B_52 | GAIN1 (2) | GAIN1 (2) | GAIN1 (2) |
| B_53 | GAIN1 (1) | GAIN1 (1) | GAIN1 (1) |
| B_54 | GAIN1 (0) | GAIN1 (0) | GAIN1 (0) |
+--------+-------------+-------------+-------------+
+--------+-------------+-------------+-------------+
| B_41 | LSF2,1 (2) | LSF2,1 (2) | LSF2,1 (4) |
| B_42 | LSF2,1 (1) | LSF2,1 (1) | LSF2,1 (3) |
| B_43 | LSF2,1 (0) | LSF2,1 (0) | LSF2,1 (2) |
| B_44 | GAIN2 (4) | GAIN2 (4) | LSF2,1 (1) |
| B_45 | GAIN2 (3) | GAIN2 (3) | LSF2,1 (0) |
| B_46 | GAIN2 (2) | GAIN2 (2) | GAIN1 (8) |
| B_47 | GAIN2 (1) | GAIN2 (1) | GAIN1 (7) |
| B_48 | GAIN2 (0) | GAIN2 (0) | GAIN1 (6) |
+--------+-------------+-------------+-------------+
| B_49 | GAIN1 (5) | GAIN1 (5) | GAIN1 (5) |
| B_50 | GAIN1 (4) | GAIN1 (4) | GAIN1 (4) |
| B_51 | GAIN1 (3) | GAIN1 (3) | GAIN1 (3) |
| B_52 | GAIN1 (2) | GAIN1 (2) | GAIN1 (2) |
| B_53 | GAIN1 (1) | GAIN1 (1) | GAIN1 (1) |
| B_54 | GAIN1 (0) | GAIN1 (0) | GAIN1 (0) |
+--------+-------------+-------------+-------------+
Notes:
xxxx (0) = LSB
xxxx (nbits-1) = MSB
LSF1,p = MSVQ* index of the pth stage of the two first frames
LSF2,p = MSVQ index of the pth stage of the two last frames
GAIN1 = VQ/MSVQ index of the 1st stage
GAIN2 = MSVQ index of the 2nd stage
* MSVQ: Multi-Stage Vector Quantizer
Notes:
xxxx (0) = LSB
xxxx (nbits-1) = MSB
LSF1,p = MSVQ* index of the pth stage of the two first frames
LSF2,p = MSVQ index of the pth stage of the two last frames
GAIN1 = VQ/MSVQ index of the 1st stage
GAIN2 = MSVQ index of the 2nd stage
* MSVQ: Multi-Stage Vector Quantizer
Table 4: Bitstream Definition for MELPe 600 bps (Part 2 of 2)
表4:MELPe 600 bps的比特流定义（第2部分，共2部分）
The 600 bps MELPe RTP payload is constructed as per Figure 4. Note that bit B_01 is placed in the LSB of the first byte with all other bits in sequence. When filling octets, the least significant bits of the seventh octet are filled with bits B_49 to B_54, respectively.
600 bps MELPe RTP有效载荷如图4所示。请注意，位B_01与所有其他位按顺序放置在第一个字节的LSB中。当填充八位字节时，第七个八位字节的最低有效位分别被位B_49至B_54填充。
MSB LSB
0 1 2 3 4 5 6 7
+------+------+------+------+------+------+------+------+
| B_08 | B_07 | B_06 | B_05 | B_04 | B_03 | B_02 | B_01 |
+------+------+------+------+------+------+------+------+
| B_16 | B_15 | B_14 | B_13 | B_12 | B_11 | B_10 | B_09 |
+------+------+------+------+------+------+------+------+
| B_24 | B_23 | B_22 | B_21 | B_20 | B_19 | B_18 | B_17 |
+------+------+------+------+------+------+------+------+
| B_32 | B_31 | B_30 | B_29 | B_28 | B_27 | B_26 | B_25 |
+------+------+------+------+------+------+------+------+
| B_40 | B_39 | B_38 | B_37 | B_36 | B_35 | B_34 | B_33 |
+------+------+------+------+------+------+------+------+
| B_48 | B_47 | B_46 | B_45 | B_44 | B_43 | B_42 | B_41 |
+------+------+------+------+------+------+------+------+
| RSVA | RSVB | B_54 | B_53 | B_52 | B_51 | B_50 | B_49 |
+------+------+------+------+------+------+------+------+
MSB LSB
0 1 2 3 4 5 6 7
+------+------+------+------+------+------+------+------+
| B_08 | B_07 | B_06 | B_05 | B_04 | B_03 | B_02 | B_01 |
+------+------+------+------+------+------+------+------+
| B_16 | B_15 | B_14 | B_13 | B_12 | B_11 | B_10 | B_09 |
+------+------+------+------+------+------+------+------+
| B_24 | B_23 | B_22 | B_21 | B_20 | B_19 | B_18 | B_17 |
+------+------+------+------+------+------+------+------+
| B_32 | B_31 | B_30 | B_29 | B_28 | B_27 | B_26 | B_25 |
+------+------+------+------+------+------+------+------+
| B_40 | B_39 | B_38 | B_37 | B_36 | B_35 | B_34 | B_33 |
+------+------+------+------+------+------+------+------+
| B_48 | B_47 | B_46 | B_45 | B_44 | B_43 | B_42 | B_41 |
+------+------+------+------+------+------+------+------+
| RSVA | RSVB | B_54 | B_53 | B_52 | B_51 | B_50 | B_49 |
+------+------+------+------+------+------+------+------+
Figure 4: Packed MELPe 600 bps Payload Octets
图4：打包MELPe 600 bps有效负载八位字节
Table B.3-1 of [SCIP210] identifies the usage of MELPe 2400 bps parameters for conveying comfort noise.
[SCIP210]的表B.3-1确定了MELPe 2400 bps参数用于传递舒适性噪声。
+-------------------------------------+----------------+
| MELPe Parameter | Value |
+-------------------------------------+----------------+
| msvq[0] (line spectral frequencies) | * See Note |
+-------------------------------------+----------------+
| msvq[1] (line spectral frequencies) | Set to 0 |
+-------------------------------------+----------------+
| msvq[2] (line spectral frequencies) | Set to 0 |
+-------------------------------------+----------------+
| msvq[3] (line spectral frequencies) | Set to 0 |
+-------------------------------------+----------------+
| fsvq (Fourier magnitudes) | Set to 0 |
+-------------------------------------+----------------+
| gain[0] (gain) | Set to 0 |
+-------------------------------------+----------------+
| gain[1] (gain) | * See Note |
+-------------------------------------+----------------+
| pitch (pitch - overall voicing) | Set to 0 |
+-------------------------------------+----------------+
| bp (bandpass voicing) | Set to 0 |
+-------------------------------------+----------------+
| af (aperiodic flag/jitter index) | Set to 0 |
+-------------------------------------+----------------+
| sync (sync bit) | Alternations |
+-------------------------------------+----------------+
+-------------------------------------+----------------+
| MELPe Parameter | Value |
+-------------------------------------+----------------+
| msvq[0] (line spectral frequencies) | * See Note |
+-------------------------------------+----------------+
| msvq[1] (line spectral frequencies) | Set to 0 |
+-------------------------------------+----------------+
| msvq[2] (line spectral frequencies) | Set to 0 |
+-------------------------------------+----------------+
| msvq[3] (line spectral frequencies) | Set to 0 |
+-------------------------------------+----------------+
| fsvq (Fourier magnitudes) | Set to 0 |
+-------------------------------------+----------------+
| gain[0] (gain) | Set to 0 |
+-------------------------------------+----------------+
| gain[1] (gain) | * See Note |
+-------------------------------------+----------------+
| pitch (pitch - overall voicing) | Set to 0 |
+-------------------------------------+----------------+
| bp (bandpass voicing) | Set to 0 |
+-------------------------------------+----------------+
| af (aperiodic flag/jitter index) | Set to 0 |
+-------------------------------------+----------------+
| sync (sync bit) | Alternations |
+-------------------------------------+----------------+
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.
注意：默认值是声码器帧中的相应参数。优选的是，msvq[0]和增益[1]值可以通过平均来自一些先前声码器帧的相应参数来导出。
Table 5: MELPe Comfort Noise Parameters
表5:MELPe舒适性噪声参数
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:
由于只需要msvq[0]（也称为LSF1x或第一LSP）和增益[1]（也称为g2x或第二增益），因此舒适噪声帧使用以下位顺序：
+--------+-------------+
| Bit | Comfort |
| | Noise |
+--------+-------------+
| B_01 | LSF10 |
| B_02 | LSF11 |
| B_03 | LSF12 |
| B_04 | LSF13 |
| B_05 | LSF14 |
| B_06 | LSF15 |
| B_07 | LSF16 |
| B_08 | g20 |
+--------+-------------+
| B_09 | g21 |
| B_10 | g22 |
| B_11 | g23 |
| B_12 | g24 |
| B_13 | SYNC |
+--------+-------------+
+--------+-------------+
| Bit | Comfort |
| | Noise |
+--------+-------------+
| B_01 | LSF10 |
| B_02 | LSF11 |
| B_03 | LSF12 |
| B_04 | LSF13 |
| B_05 | LSF14 |
| B_06 | LSF15 |
| B_07 | LSF16 |
| B_08 | g20 |
+--------+-------------+
| B_09 | g21 |
| B_10 | g22 |
| B_11 | g23 |
| B_12 | g24 |
| B_13 | SYNC |
+--------+-------------+
Notes: g = Gain LSF = Line Spectral Frequencies
注：g=增益LSF=线频谱频率
Table 6: Bitstream Definition for MELPe Comfort Noise
表6:MELPe舒适性噪声的比特流定义
The comfort noise MELPe RTP payload is constructed as per Figure 5. Note that bit B_01 is placed in the LSB of the first byte with all other bits in sequence. When filling octets, the least significant bits of the second octet are filled with bits B_09 to B_13, respectively.
舒适性噪声MELPe RTP有效载荷如图5所示。请注意，位B_01与所有其他位按顺序放置在第一个字节的LSB中。当填充八位字节时，第二个八位字节的最低有效位分别被比特B_09到B_13填充。
MSB LSB
0 1 2 3 4 5 6 7
+------+------+------+------+------+------+------+------+
| B_08 | B_07 | B_06 | B_05 | B_04 | B_03 | B_02 | B_01 |
+------+------+------+------+------+------+------+------+
| RSVA | RSVB | RSVC | B_13 | B_12 | B_11 | B_10 | B_09 |
+------+------+------+------+------+------+------+------+
MSB LSB
0 1 2 3 4 5 6 7
+------+------+------+------+------+------+------+------+
| B_08 | B_07 | B_06 | B_05 | B_04 | B_03 | B_02 | B_01 |
+------+------+------+------+------+------+------+------+
| RSVA | RSVB | RSVC | B_13 | B_12 | B_11 | B_10 | B_09 |
+------+------+------+------+------+------+------+------+
Figure 5: Packed MELPe Comfort Noise Payload Octets
图5：打包MELPe舒适性噪声有效载荷八位字节
A MELPe RTP packet MAY consist of zero or more MELPe coder frames followed by zero or one MELPe comfort noise frame. 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 bitrate (2400, 1200, or 600 bps). For some applications, a longer packetization interval is used to reduce the packet rate.
一个MELPe RTP包可以由零个或多个MELPe编码器帧和零个或一个MELPe舒适噪声帧组成。舒适性噪声帧的存在可以从RTP有效载荷的长度推断出来。根据编码器比特率（2400、1200或600 bps），默认分组间隔为一个编码器帧（22.5、67.5或90 ms）。对于某些应用，使用更长的分组间隔来降低分组速率。
A MELPe RTP packet comprised of no coder frame and no comfort noise frame MAY be used periodically by an endpoint to indicate connectivity by an otherwise idle receiver.
端点可周期性地使用由无编码器帧和无舒适噪声帧组成的MELPe RTP分组，以指示由其他空闲接收器的连接。
All MELPe frames in a single RTP packet MUST be of the same coder bitrate. Dynamic switching between frame rates within an RTP stream may be permitted (if supported by both ends) provided that reserved bits RSVA, RSVB, and RSVC are filled in as per Table 7. If bitrate switching is not used, all reserved bits are encoded as 0 by the sender and ignored by the receiver. (RSV0 is always coded as 0.)
单个RTP数据包中的所有MELPe帧必须具有相同的编码器比特率。如果按照表7填写保留位RSVA、RSVB和RSVC，则可以允许RTP流内的帧速率之间的动态切换（如果两端都支持）。如果未使用比特率切换，则发送方将所有保留位编码为0，接收方将忽略。（RSV0始终编码为0。）
+-------------------+------+------+------+
| Coder Bitrate | RSVA | RSVB | RSVC |
+-------------------+------+------+------+
| 2400 bps | 0 | 0 | N/A |
+-------------------+------+------+------+
| 1200 bps | 1 | 0 | 0 |
+-------------------+------+------+------+
| 600 bps | 0 | 1 | N/A |
+-------------------+------+------+------+
| Comfort Noise | 1 | 0 | 1 |
+-------------------+------+------+------+
| (reserved) | 1 | 1 | N/A |
+-------------------+------+------+------+
+-------------------+------+------+------+
| Coder Bitrate | RSVA | RSVB | RSVC |
+-------------------+------+------+------+
| 2400 bps | 0 | 0 | N/A |
+-------------------+------+------+------+
| 1200 bps | 1 | 0 | 0 |
+-------------------+------+------+------+
| 600 bps | 0 | 1 | N/A |
+-------------------+------+------+------+
| Comfort Noise | 1 | 0 | 1 |
+-------------------+------+------+------+
| (reserved) | 1 | 1 | N/A |
+-------------------+------+------+------+
Table 7: MELPe Frame Bitrate Indicators
表7:MELPe帧比特率指示器
It is important to observe that senders have the following additional restrictions:
请务必注意，发件人有以下附加限制：
Senders SHOULD NOT include more MELPe frames in a single RTP packet than will fit in the MTU of the RTP transport protocol.
发送方在单个RTP数据包中包含的MELPe帧不应超过RTP传输协议的MTU所能容纳的数量。
Frames MUST NOT be split between RTP packets.
帧不能在RTP数据包之间分割。
It is RECOMMENDED that the number of frames contained within an RTP packet be consistent with the application. For example, in telephony and other real-time applications where delay is important, then the fewer frames per packet the lower the delay, whereas for bandwidth-constrained links or delay-insensitive streaming messaging applications, more than one frame per packet or many frames per packet would be acceptable.
建议RTP数据包中包含的帧数与应用程序一致。例如，在延迟很重要的电话和其他实时应用中，每个数据包的帧数越少，延迟就越低，而对于带宽受限的链路或对延迟不敏感的流式消息传递应用，每个数据包超过一个帧或每个数据包多个帧是可以接受的。
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 that the last frame can be a 2-octet comfort noise frame.
描述RTP分组中包含的帧数的信息不作为RTP有效载荷的一部分传输。确定MELPe帧数的方法是计算RTP数据包内的八位字节总数，并将八位字节数除以每帧的预期八位字节数（每帧7/11/7）。请记住，最后一帧可以是2-octet舒适噪音帧。
When dynamic bitrate switching is used and more than one frame is contained in an RTP packet, it is RECOMMENDED that the coder rate bits contained in the last octet be inspected. If the coder bitrate indicates a comfort noise frame, then inspect the third last octet for the coder bitrate. All MELPe speech frames in the RTP packet will be of this same coder bitrate.
当使用动态比特率交换且RTP数据包中包含多个帧时，建议检查最后八位字节中包含的编码器速率比特。如果编码器比特率指示舒适噪声帧，则检查编码器比特率的最后第三个八位字节。RTP数据包中的所有MELPe语音帧将具有相同的编码器比特率。
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 the 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.
MELPe的目标比特率可以在任何时间点进行调整，从而允许拥塞管理。此外，编码在单个分组中的编码语音或音频数据量可用于拥塞控制，因为分组速率与分组持续时间成反比。较低的数据包传输速率降低了报头开销，但同时增加了延迟和丢失敏感性，因此应谨慎使用。
Since UDP does not provide congestion control, applications that use RTP over UDP SHOULD implement their own congestion control above the UDP layer [RFC8085] and MAY also implement a transport circuit breaker [RFC8083]. Work in the RMCAT working group [RMCAT] describes the interactions and conceptual interfaces necessary between the application components that relate to congestion control, including the RTP layer, the higher-level media codec control layer, and the lower-level transport interface, as well as components dedicated to congestion control functions.
由于UDP不提供拥塞控制，在UDP上使用RTP的应用程序应该在UDP层[RFC8085]上实现自己的拥塞控制，并且还可以实现传输断路器[RFC8083]。RMCAT工作组[RMCAT]中的工作描述了与拥塞控制相关的应用程序组件之间必要的交互和概念接口，包括RTP层、高级媒体编解码器控制层和低级传输接口，以及专用于拥塞控制功能的组件。
This RTP payload format is identified using the MELP, MELP2400, MELP1200, and MELP600 media subtypes, which are registered in accordance with RFC 4855 [RFC4855] and per the media type registration template from RFC 6838 [RFC6838].
此RTP有效负载格式使用MELP、MELP2400、MELP1200和MELP600媒体子类型标识，这些媒体子类型根据RFC 4855[RFC4855]和RFC 6838[RFC6838]中的媒体类型注册模板注册。
Type name: audio
类型名称：音频
Subtype names: MELP, MELP2400, MELP1200, and MELP600
子类型名称：MELP、MELP2400、MELP1200和MELP600
Required parameters: N/A
所需参数：不适用
Optional parameters:
可选参数：
ptime: the recommended length of time (in milliseconds) represented by the media in a packet. It SHALL use the nearest rounded-up ms integer packet duration. For MELPe, this corresponds to the following values: 23, 45, 68, 90, 112, 135, 156, and 180. Larger values can be used as long as they are properly rounded. See Section 6 of RFC 4566 [RFC4566].
ptime：由数据包中的媒体表示的建议时间长度（毫秒）。应使用最接近的四舍五入ms整数包持续时间。对于MELPe，这对应于以下值：23、45、68、90、112、135、156和180。只要正确四舍五入，就可以使用较大的值。参见RFC 4566[RFC4566]第6节。
maxptime: the maximum length of time (in milliseconds) that can be encapsulated in a packet. It SHALL use the nearest rounded-up ms integer packet duration. For MELPe, this corresponds to the following values: 23, 45, 68, 90, 112, 135, 156, and 180. Larger values can be used as long as they are properly rounded. See Section 6 of RFC 4566 [RFC4566].
maxptime：可以封装在数据包中的最大时间长度（以毫秒为单位）。应使用最接近的四舍五入ms整数包持续时间。对于MELPe，这对应于以下值：23、45、68、90、112、135、156和180。只要正确四舍五入，就可以使用较大的值。参见RFC 4566[RFC4566]第6节。
bitrate: specifies the MELPe coder bitrates supported. Possible values are a comma-separated list of rates from the following set: 2400, 1200, 600. The modes are listed in order of preference; first is preferred. If "bitrate" is not present, the fixed coder bitrate of 2400 MUST be used. The alternate encoding names "MELP2400", "MELP1200", and "MELP600" directly specify the MELPe coder bitrates of 2400, 1200, and 600, respectively, and MUST NOT specify a "bitrate" parameter.
比特率：指定支持的MELPe编码器比特率。可能的值是以下集合中以逗号分隔的速率列表：2400、1200、600。模式按优先顺序列出；首选第一种。如果“比特率”不存在，则必须使用2400的固定编码器比特率。备选编码名称“MELP2400”、“MELP1200”和“MELP600”分别直接指定2400、1200和600的MELPe编码器比特率，并且不得指定“比特率”参数。
Encoding considerations: These media subtypes are framed and binary; see Section 4.8 of RFC 6838 [RFC6838].
编码注意事项：这些媒体子类型是框架和二进制的；参见RFC 6838[RFC6838]第4.8节。
Security considerations: Please see Section 8 of RFC 8130.
安全注意事项：请参阅RFC 8130第8节。
Interoperability considerations: Early implementations used MELP2400, MELP1200, and MELP600 to indicate both coder type and bitrate. These media type names should be preserved with this registration.
互操作性注意事项：早期的实现使用MELP2400、MELP1200和MELP600来指示编码器类型和比特率。这些媒体类型名称应与此注册一起保留。
Published specification: N/A
已发布规范：不适用
Applications that use this media type: N/A
使用此媒体类型的应用程序：不适用
Additional information: N/A
其他信息：不适用
Deprecated alias names for this type: N/A
此类型的已弃用别名：不适用
Magic number(s): N/A
Magic number(s): N/A
File extension(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Macintosh file type code(s): N/A
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Victor Demjanenko, Ph.D. VOCAL Technologies, Ltd. 520 Lee Entrance, Suite 202 Buffalo, NY 14228 United States of America Phone: +1 716 688 4675 Email: victor.demjanenko@vocal.com
Victor Demjanenko博士。VOCAL Technologies，Ltd.纽约州布法罗市李入口520号202室，邮编14228美利坚合众国电话：+1 716 688 4675电子邮件：victor。demjanenko@vocal.com
Intended usage: COMMON
预期用途：普通
Restrictions on usage: These media subtypes depend on RTP framing and hence are only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.
使用限制：这些媒体子类型取决于RTP帧，因此仅定义为通过RTP传输[RFC3550]。此时未定义其他帧协议内的传输。
Author: Victor Demjanenko
作者：Victor Demjanenko
Change controller: IETF Payload working group delegated from the IESG.
变更控制员：IESG授权的IETF有效载荷工作组。
Provisional registration? (standards tree only): No
临时登记？（仅限标准树）：否
The mapping of the above-defined payload format media subtypes and their parameters SHALL be done according to Section 3 of RFC 4855 [RFC4855].
应根据RFC 4855[RFC4855]第3节的规定，映射上述定义的有效负载格式媒体子类型及其参数。
The information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [RFC4566], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the MELPe codec, the mapping is as follows:
媒体类型规范中包含的信息与会话描述协议（SDP）[RFC4566]中的字段具有特定映射，该协议通常用于描述RTP会话。使用SDP指定使用MELPe编解码器的会话时，映射如下：
o The media type ("audio") goes in SDP "m=" as the media name.
o 媒体类型（“音频”）以SDP“m=”作为媒体名称。
o The media subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name.
o 媒体子类型（有效负载格式名称）以SDP“a=rtpmap”作为编码名称。
o The parameter "bitrate" goes in the SDP "a=fmtp" attribute by copying it as a "bitrate=<value>" string.
o 参数“bitrate”通过将其复制为“bitrate=<value>”字符串而进入SDP“a=fmtp”属性。
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
o 参数“ptime”和“maxptime”分别位于SDP“a=ptime”和“a=maxptime”属性中。
When conveying information via SDP, the encoding name SHALL be "MELP" (the same as the media subtype). Alternate encoding name subtypes "MELP2400", "MELP1200", and "MELP600" MAY be used in SDP to convey fixed-bitrate configurations. These names have been observed in systems that do not support dynamic frame-rate switching as specified by the parameter "bitrate".
通过SDP传输信息时，编码名称应为“MELP”（与媒体子类型相同）。备用编码名称子类型“MELP2400”、“MELP1200”和“MELP600”可在SDP中用于传送固定比特率配置。在不支持参数“比特率”指定的动态帧速率切换的系统中观察到了这些名称。
An example of the media representation in SDP for describing MELPe might be:
SDP中用于描述MELPe的媒体表示的示例可能是：
m=audio 49120 RTP/AVP 97
a=rtpmap:97 MELP/8000
m=audio 49120 RTP/AVP 97
a=rtpmap:97 MELP/8000
An alternative example of SDP for fixed-bitrate configurations might be:
用于固定比特率配置的SDP的另一个示例可能是：
m=audio 49120 RTP/AVP 97 100 101 102
a=rtpmap:97 MELP/8000
a=rtpmap:100 MELP2400/8000
a=rtpmap:101 MELP1200/8000
a=rtpmap:102 MELP600/8000
m=audio 49120 RTP/AVP 97 100 101 102
a=rtpmap:97 MELP/8000
a=rtpmap:100 MELP2400/8000
a=rtpmap:101 MELP1200/8000
a=rtpmap:102 MELP600/8000
If the encoding name "MELP" is received without a "bitrate" parameter, the fixed coder bitrate of 2400 MUST be used. The alternate encoding names "MELP2400", "MELP1200", and "MELP600" directly specify the MELPe coder bitrates of 2400, 1200, and 600, respectively, and MUST NOT specify a "bitrate" parameter.
如果接收到的编码名称“MELP”没有“比特率”参数，则必须使用2400的固定编码器比特率。备选编码名称“MELP2400”、“MELP1200”和“MELP600”分别直接指定2400、1200和600的MELPe编码器比特率，并且不得指定“比特率”参数。
The optional media type parameter "bitrate", when present, MUST be included in the "a=fmtp" attribute in the SDP, expressed as a media type string in the form of a semicolon-separated list of
可选媒体类型参数“bitrate”（如果存在）必须包含在SDP中的“a=fmtp”属性中，以分号分隔的媒体类型字符串的形式表示
parameter=value pairs. The string "value" can be one or more of 2400, 1200, and 600, separated by commas (where each bitrate value indicates the corresponding MELPe coder). An example of the media representation in SDP for describing MELPe when all three coder bitrates are supported might be:
参数=值对。字符串“value”可以是2400、1200和600中的一个或多个，用逗号分隔（其中每个比特率值表示相应的MELPe编码器）。当支持所有三个编码器比特率时，SDP中用于描述MELPe的媒体表示的示例可能是：
m=audio 49120 RTP/AVP 97
a=rtpmap:97 MELP/8000
a=fmtp:97 bitrate=2400,600,1200
m=audio 49120 RTP/AVP 97
a=rtpmap:97 MELP/8000
a=fmtp:97 bitrate=2400,600,1200
Parameter "ptime" cannot be used for the purpose of specifying the MELPe operating mode, due to the fact that for certain values it 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).
参数“ptime”不能用于指定MELPe操作模式，因为对于某些值，无法区分将要使用的模式（例如，当ptime=68时，无法区分数据包是承载一帧67.5 ms还是三帧22.5 ms）。
Note that the payload format (encoding) names are commonly shown in upper case. Media subtypes are commonly shown in lower case. These names are case insensitive in both places. Similarly, parameter names are case insensitive in both the media subtype name and the default mapping to the SDP a=fmtp attribute.
请注意，有效负载格式（编码）名称通常以大写形式显示。媒体子类型通常以小写形式显示。这些名称在两个位置都不区分大小写。类似地，参数名称在媒体子类型名称和到SDP a=fmtp属性的默认映射中都不区分大小写。
For declarative media, the "bitrate" parameter specifies the possible bitrates 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 bitrates. The receiver can then select an appropriate MELPe codec by using 97, 98, or 99.
对于声明性媒体，“比特率”参数指定发送方可能使用的比特率。多个MELPe rtpmap值（例如97、98和99，如下所述）可用于以不同比特率传送MELPe编码语音。然后，接收器可以使用97、98或99选择适当的MELPe编解码器。
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 MELP/8000
a=fmtp:97 bitrate=2400
a=rtpmap:98 MELP/8000
a=fmtp:98 bitrate=1200
a=rtpmap:99 MELP/8000
a=fmtp:99 bitrate=600
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 MELP/8000
a=fmtp:97 bitrate=2400
a=rtpmap:98 MELP/8000
a=fmtp:98 bitrate=1200
a=rtpmap:99 MELP/8000
a=fmtp:99 bitrate=600
In the Offer/Answer model [RFC3264], "bitrate" is a bidirectional parameter. Both sides MUST use a common "bitrate" value or values. The offer contains the bitrates supported by the offerer, listed in its preferred order. The answerer MAY agree to any bitrate by listing the bitrate first in the answerer response. Additionally, the answerer MAY indicate any secondary bitrate or bitrates that it supports. The initial bitrate used by both parties SHALL be the first bitrate specified in the answerer response.
在提供/应答模型[RFC3264]中，“比特率”是一个双向参数。双方必须使用一个或多个公共“比特率”值。报价包含报价人支持的比特率，按优先顺序列出。应答者可以通过在应答者响应中首先列出比特率来同意任何比特率。此外，应答者可指示其支持的任何二级比特率或比特率。双方使用的初始比特率应为应答方响应中规定的第一比特率。
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.
例如，如果提供方比特率为“2400600”，而应答比特率为“6002400”，则初始比特率为600。如果应答者提供其他比特率，则在将来的任何时候都可以使用要约和应答之间的任何公共比特率。这些其他通用比特率的激活超出了本文档的范围。
The use of a lower bitrate is often important for a case such as when one endpoint utilizes a bandwidth-constrained link (e.g., 1200 bps radio link or slower), where only the lower coder bitrate will work.
较低比特率的使用对于例如当一个端点利用带宽受限链路（例如，1200 bps或更慢的无线电链路）时的情况通常是重要的，其中只有较低的编码器比特率将工作。
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 synchronization source (SSRC) sequence number gaps indicate lost packets to be filled by PLC, while abrupt loss of RTP packets indicates intended discontinuous transmissions.
MELPe的主要应用是语音对话的无线电通信，不连续传输是正常的。当在IP网络中使用MELPe时，MELPe RTP数据包传输可能会频繁停止和恢复。RTP同步源（SSRC）序列号间隙表示丢失的数据包将由PLC填充，而RTP数据包的突然丢失表示预期的不连续传输。
If a MELPe coder so desires, it may send a comfort noise frame as per Appendix B of [SCIP210] prior to ceasing transmission. A receiver may optionally use comfort noise during its silence periods. No SDP negotiations are required.
如果MELPe编码器需要，可根据[SCIP210]附录B在停止传输前发送舒适噪声帧。接收机可在其静音期间选择性地使用舒适噪声。不需要SDP谈判。
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 that a code value of 3 for the pitch/voicing parameter (represented by the bits P6 to P0 in Table 1 of this document) be used. Hence, set bits P0 and P1 to one and bits P2, P3, P4, P5, and P6 to zero.
MELPe丢包隐藏（PLC）使用MELPe 2400 bps编码器的基音/语音参数的特殊属性和编码。PLC擦除指示利用[MELPE]表1中确定的非语音帧的任何错误编码。为了简单起见，优选使用音调/语音参数的代码值3（由本文件表1中的位P6到P0表示）。因此，将位P0和P1设置为1，将位P2、P3、P4、P5和P6设置为0。
When using PLC in 1200 bps or 600 bps mode, the MELPe 2400 bps decoder is called three or four times, respectively, to cover the loss of a MELPe frame.
在1200 bps或600 bps模式下使用PLC时，分别调用MELPe 2400 bps解码器三次或四次，以覆盖MELPe帧的丢失。
IANA has registered MELP, MELP2400, MELP1200, and MELP600 as specified in Section 4.1. IANA has also added these media subtypes to the "RTP Payload Format media types" registry (http://www.iana.org/assignments/rtp-parameters).
IANA已按照第4.1节的规定注册了MELP、MELP2400、MELP1200和MELP600。IANA还将这些媒体子类型添加到“RTP有效负载格式媒体类型”注册表中(http://www.iana.org/assignments/rtp-parameters).
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and in any applicable RTP profile such as RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], or RTP/SAVPF [RFC5124]. However, as discussed in [RFC7202], it is not an RTP payload format's responsibility to discuss or mandate what solutions are used to meet such basic security goals as confidentiality, integrity, and source authenticity for RTP in general. This responsibility lies with anyone using RTP in an application. They can find guidance on available security mechanisms 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.
使用本规范中定义的有效负载格式的RTP数据包受RTP规范[RFC3550]和任何适用RTP配置文件（如RTP/AVP[RFC3551]、RTP/AVPF[RFC4585]、RTP/SAVP[RFC3711]或RTP/SAVPF[RFC5124]中讨论的安全注意事项的约束。但是，如[RFC7202]中所述，RTP有效负载格式不负责讨论或授权使用什么解决方案来满足RTP的基本安全目标，如机密性、完整性和源真实性。任何在应用程序中使用RTP的人都有责任。他们可以在[RFC7201]中找到关于可用安全机制和重要注意事项的指导。应用程序应使用一个或多个适当的强安全机制。本节的其余部分将讨论影响有效负载格式本身安全性的属性。
This RTP payload format and the MELPe 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.
该RTP有效载荷格式和MELPe解码器在用于分组处理的接收器端计算复杂度方面不表现出任何显著的非均匀性，因此不太可能由于接收病理数据而造成拒绝服务威胁。此外，RTP有效负载格式不包含任何活动内容。
Please see the security considerations discussed in [RFC6562] regarding VAD and its effect on bitrates.
有关VAD及其对比特率的影响，请参见[RFC6562]中讨论的安全注意事项。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP Payload Format Specifications", BCP 36, RFC 2736, DOI 10.17487/RFC2736, December 1999, <http://www.rfc-editor.org/info/rfc2736>.
[RFC2736]Handley，M.和C.Perkins，“RTP有效载荷格式规范编写者指南”，BCP 36，RFC 2736，DOI 10.17487/RFC2736，1999年12月<http://www.rfc-editor.org/info/rfc2736>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <http://www.rfc-editor.org/info/rfc3264>.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，DOI 10.17487/RFC3264，2002年6月<http://www.rfc-editor.org/info/rfc3264>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 3550，DOI 10.17487/RFC3550，2003年7月<http://www.rfc-editor.org/info/rfc3550>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, <http://www.rfc-editor.org/info/rfc3551>.
[RFC3551]Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，DOI 10.17487/RFC3551，2003年7月<http://www.rfc-editor.org/info/rfc3551>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <http://www.rfc-editor.org/info/rfc3711>.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 3711，DOI 10.17487/RFC3711，2004年3月<http://www.rfc-editor.org/info/rfc3711>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC 4566，DOI 10.17487/RFC4566，2006年7月<http://www.rfc-editor.org/info/rfc4566>.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, <http://www.rfc-editor.org/info/rfc4855>.
[RFC4855]Casner，S.，“RTP有效载荷格式的媒体类型注册”，RFC 4855，DOI 10.17487/RFC4855，2007年2月<http://www.rfc-editor.org/info/rfc4855>.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, <http://www.rfc-editor.org/info/rfc5124>.
[RFC5124]Ott，J.和E.Carrara，“基于实时传输控制协议（RTCP）的反馈扩展安全RTP配置文件（RTP/SAVPF）”，RFC 5124DOI 10.17487/RFC5124，2008年2月<http://www.rfc-editor.org/info/rfc5124>.
[RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, DOI 10.17487/RFC6562, March 2012, <http://www.rfc-editor.org/info/rfc6562>.
[RFC6562]Perkins，C.和JM。Valin，“带安全RTP的可变比特率音频使用指南”，RFC 6562，DOI 10.17487/RFC6562，2012年3月<http://www.rfc-editor.org/info/rfc6562>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-editor.org/info/rfc6838>.
[RFC6838]Freed，N.，Klensin，J.和T.Hansen，“介质类型规范和注册程序”，BCP 13，RFC 6838，DOI 10.17487/RFC6838，2013年1月<http://www.rfc-editor.org/info/rfc6838>.
[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", RFC 8083, DOI 10.17487/RFC8083, March 2017, <http://www.rfc-editor.org/info/rfc8083>.
[RFC8083]Perkins，C.和V.Singh，“多媒体拥塞控制：单播RTP会话的断路器”，RFC 8083，DOI 10.17487/RFC8083，2017年3月<http://www.rfc-editor.org/info/rfc8083>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", RFC 8085, DOI 10.17487/RFC8085, March 2017, <http://www.rfc-editor.org/info/rfc8085>.
[RFC8085]Eggert，L.，Fairhurst，G.和G.Shepherd，“UDP使用指南”，RFC 8085，DOI 10.17487/RFC8085，2017年3月<http://www.rfc-editor.org/info/rfc8085>.
[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.
[MELP]国防部电信标准，“2400位/秒混合激励线性预测（MELP）语音的模数转换”，MIL-STD-30052999年12月。
[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.
北大西洋公约组织（北约），“600比特/秒、1200比特/秒和2400比特/秒北约互操作窄带语音编码器”，STANAG第4591号，2006年1月。
[SCIP210] National Security Agency, "SCIP Signaling Plan", SCIP-210, December 2007.
[SCIP210]国家安全局，“SCIP信号计划”，SCIP-210，2007年12月。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <http://www.rfc-editor.org/info/rfc4585>.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 4585，DOI 10.17487/RFC4585，2006年7月<http://www.rfc-editor.org/info/rfc4585>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <http://www.rfc-editor.org/info/rfc7201>.
[RFC7201]Westerlund，M.和C.Perkins，“保护RTP会话的选项”，RFC 7201，DOI 10.17487/RFC7201，2014年4月<http://www.rfc-editor.org/info/rfc7201>.
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2014, <http://www.rfc-editor.org/info/rfc7202>.
[RFC7202]Perkins，C.和M.Westerlund，“保护RTP框架：为什么RTP不要求单一媒体安全解决方案”，RFC 7202，DOI 10.17487/RFC7202，2014年4月<http://www.rfc-editor.org/info/rfc7202>.
[RMCAT] IETF, RTP Media Congestion Avoidance Techniques (rmcat) Working Group, <https://datatracker.ietf.org/wg/rmcat/about/>.
[RMCAT]IETF，RTP媒体拥塞避免技术（RMCAT）工作组<https://datatracker.ietf.org/wg/rmcat/about/>.
Authors' Addresses
作者地址
Victor Demjanenko, Ph.D. VOCAL Technologies, Ltd. 520 Lee Entrance, Suite 202 Buffalo, NY 14228 United States of America
Victor Demjanenko博士。美国纽约州布法罗市李入口520号202室声乐技术有限公司，邮编14228
Phone: +1 716 688 4675
Email: victor.demjanenko@vocal.com
Phone: +1 716 688 4675
Email: victor.demjanenko@vocal.com
David Satterlee VOCAL Technologies, Ltd. 520 Lee Entrance, Suite 202 Buffalo, NY 14228 United States of America
David Satterlee VOCAL Technologies，Ltd.美国纽约州布法罗市李入口520号202室，邮编14228
Phone: +1 716 688 4675
Email: david.satterlee@vocal.com
Phone: +1 716 688 4675
Email: david.satterlee@vocal.com