Internet Engineering Task Force (IETF) Z. Fang
Request for Comments: 6884 Qualcomm Incorporated
Category: Standards Track March 2013
ISSN: 2070-1721
Internet Engineering Task Force (IETF) Z. Fang
Request for Comments: 6884 Qualcomm Incorporated
Category: Standards Track March 2013
ISSN: 2070-1721
RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW)
增强型可变速率窄带宽带编解码器（EVRC-NW）的RTP有效载荷格式
Abstract
摘要
This document specifies Real-time Transport Protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Three media type registrations are included for EVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as email.
本文件规定了用于增强型可变速率窄带宽带编解码器（EVRC-NW）的实时传输协议（RTP）有效载荷格式。EVRC-NW RTP有效负载格式包括三种媒体类型注册。此外，还为存储模式应用程序（如电子邮件）中的EVRC-NW语音数据传输指定了文件格式。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第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/rfc6884.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6884.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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
2. Conventions .....................................................2
3. Background ......................................................3
4. EVRC-NW Codec ...................................................3
5. RTP Header Usage ................................................4
6. Payload Format ..................................................4
6.1. Encoding Capability Identification in EVRC-NW
Interleaved/Bundled Format .................................5
7. Congestion Control Considerations ...............................6
8. Storage Format for the EVRC-NW Codec ............................6
9. IANA Considerations .............................................7
9.1. Media Type Registrations ...................................7
9.1.1. Registration of Media Type audio/EVRCNW .............7
9.1.2. Registration of Media Type audio/EVRCNW0 ............9
9.1.3. Registration of Media Type audio/EVRCNW1 ...........10
10. SDP Mode Attributes for EVRC-NW ...............................12
11. Mode Change Request/Response Considerations ...................13
12. Mapping EVRC-NW Media Type Parameters into SDP ................14
13. Offer-Answer Model Considerations for EVRC-NW .................14
14. Declarative SDP Considerations ................................16
15. Examples ......................................................16
16. Security Considerations .......................................19
17. References ....................................................19
17.1. Normative References .....................................19
17.2. Informative References ...................................20
1. Introduction ....................................................2
2. Conventions .....................................................2
3. Background ......................................................3
4. EVRC-NW Codec ...................................................3
5. RTP Header Usage ................................................4
6. Payload Format ..................................................4
6.1. Encoding Capability Identification in EVRC-NW
Interleaved/Bundled Format .................................5
7. Congestion Control Considerations ...............................6
8. Storage Format for the EVRC-NW Codec ............................6
9. IANA Considerations .............................................7
9.1. Media Type Registrations ...................................7
9.1.1. Registration of Media Type audio/EVRCNW .............7
9.1.2. Registration of Media Type audio/EVRCNW0 ............9
9.1.3. Registration of Media Type audio/EVRCNW1 ...........10
10. SDP Mode Attributes for EVRC-NW ...............................12
11. Mode Change Request/Response Considerations ...................13
12. Mapping EVRC-NW Media Type Parameters into SDP ................14
13. Offer-Answer Model Considerations for EVRC-NW .................14
14. Declarative SDP Considerations ................................16
15. Examples ......................................................16
16. Security Considerations .......................................19
17. References ....................................................19
17.1. Normative References .....................................19
17.2. Informative References ...................................20
This document specifies the payload formats for packetization of EVRC-NW encoded speech signals into the Real-time Transport Protocol (RTP). It defines support for the header-free, interleaved/bundled, and compact bundle packet formats for the EVRC-NW codec as well as discontinuous transmission (DTX) support for EVRC-NW encoded speech transported via RTP. The EVRC-NW codec offers better speech quality than the EVRC and EVRC-B codecs and better capacity than the Enhanced Variable Rate Wideband Codec (EVRC-WB). EVRC-NW belongs to the EVRC family of codecs.
本文件规定了将EVRC-NW编码语音信号打包成实时传输协议（RTP）的有效载荷格式。它定义了对EVRC-NW编解码器的无报头、交织/捆绑和紧凑捆绑包格式的支持，以及对通过RTP传输的EVRC-NW编码语音的不连续传输（DTX）支持。EVRC-NW编解码器比EVRC和EVRC-B编解码器提供更好的语音质量，比增强型可变速率宽带编解码器（EVRC-WB）提供更好的容量。EVRC-NW属于EVRC编解码器系列。
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 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
EVRC-NW is an extension of both the EVRC-B [2] and EVRC-WB [3] speech codecs developed in the Third Generation Partnership Project 2 (3GPP2) with support for DTX. It provides enhanced voice quality and high spectral efficiency.
EVRC-NW是第三代合作伙伴项目2（3GPP2）中开发的支持DTX的EVRC-B[2]和EVRC-WB[3]语音编解码器的扩展。它提供增强的语音质量和高频谱效率。
The EVRC-NW codec operates on 20 ms frames, and the default sampling rate is 16 kHz (wideband). Input and output at the 8 kHz sampling rate (narrowband) is also supported. The EVRC-NW codec can operate in eight modes (0 to 7) as defined in 3GPP2 C.S0014-D [4]. EVRC-NW modes 0, 1, and 7 are interoperable with EVRC-WB. EVRC-NW modes 1 to 7 are interoperable with EVRC-B. EVRC-NW modes 0 to 6 use the full set or a subset of full rate, 1/2 rate, 1/4 rate, and 1/8 rate frames. EVRC-NW mode 7 uses only 1/2 rate and 1/8 rate frames. By default, EVRC-NW supports all narrowband modes (modes 1 to 7). The support of wideband mode (mode 0) is optional. Mode change among modes 1 to 7 (or among modes 0 to 7 if the receiver supports wideband mode) results in codec output bit-rate change but does not cause any decoding problems at the receiver. EVRC-NW provides a standardized solution for packetized voice applications that allow transitions between enhanced quality and increased capacity. The most important service addressed is IP telephony. Target devices can be IP phones or VoIP handsets, media gateways, voice messaging servers, etc.
EVRC-NW编解码器在20ms帧上运行，默认采样率为16kHz（宽带）。还支持8 kHz采样率（窄带）的输入和输出。EVRC-NW编解码器可以在3GPP2 C.S0014-D[4]中定义的八种模式（0到7）下工作。EVRC-NW模式0、1和7可与EVRC-WB互操作。EVRC-NW模式1至7可与EVRC-B互操作。EVRC-NW模式0至6使用全速率、1/2速率、1/4速率和1/8速率帧的完整集或子集。EVRC-NW模式7仅使用1/2速率和1/8速率帧。默认情况下，EVRC-NW支持所有窄带模式（模式1至7）。支持宽带模式（模式0）是可选的。模式1到7之间的模式变化（或者如果接收机支持宽带模式，则模式0到7之间的模式变化）会导致编解码器输出比特率变化，但不会在接收机处引起任何解码问题。EVRC-NW为分组语音应用程序提供了标准化解决方案，允许在增强的质量和增加的容量之间进行转换。最重要的服务是IP电话。目标设备可以是IP电话或VoIP手机、媒体网关、语音消息服务器等。
The EVRC-NW codec operates on 20 ms frames. It produces output frames of one of the four different sizes: 171 bits (Rate 1), 80 bits (Rate 1/2), 40 bits (Rate 1/4), or 16 bits (Rate 1/8). In addition, there are two zero-bit codec frame types: blank (null) frames and erasure frames. The default sampling rate is 16 kHz. Input and output at the 8 kHz sampling rate is also supported.
EVRC-NW编解码器在20毫秒帧上运行。它产生四种不同大小的输出帧之一：171位（速率1）、80位（速率1/2）、40位（速率1/4）或16位（速率1/8）。此外，还有两种零位编解码器帧类型：空白（null）帧和擦除帧。默认采样率为16 kHz。还支持8 kHz采样率下的输入和输出。
The frame type values and sizes of the associated codec data frames are listed in the table below:
下表列出了相关编解码器数据帧的帧类型值和大小：
Value Rate Total codec data frame size in bytes (and in bits)
--------------------------------------------------------------------
0 Blank (Null) 0 (0 bits)
1 1/8 2 (16 bits)
2 1/4 5 (40 bits)
3 1/2 10 (80 bits)
4 1 22 (171 bits; 5 bits padded at the end)
5 Erasure 0 (SHOULD NOT be transmitted by sender)
Value Rate Total codec data frame size in bytes (and in bits)
--------------------------------------------------------------------
0 Blank (Null) 0 (0 bits)
1 1/8 2 (16 bits)
2 1/4 5 (40 bits)
3 1/2 10 (80 bits)
4 1 22 (171 bits; 5 bits padded at the end)
5 Erasure 0 (SHOULD NOT be transmitted by sender)
The format of the RTP header is specified in RFC 3550 [5]. The EVRC-NW payload formats (Section 6) use the fields of the RTP header as specified in RFC 3550 [5].
RTP报头的格式在RFC 3550[5]中规定。EVRC-NW有效载荷格式（第6节）使用RFC 3550[5]中规定的RTP报头字段。
EVRC-NW also has the capability to operate with 8 kHz sampled input/ output signals. The decoder does not require a priori knowledge about the sampling rate of the original signal at the input of the encoder. The decoder output can be at 8 kHz or 16 kHz regardless of the sampling rate used at the encoder. Therefore, depending on the implementation and the electroacoustic audio capabilities of the devices, the input of the encoder and/or the output of the decoder can be configured at 8 kHz; however, a 16 kHz RTP clock rate MUST always be used. The RTP timestamp is increased by 320 for each 20 milliseconds.
EVRC-NW还具有使用8 kHz采样输入/输出信号的能力。解码器不需要关于编码器输入处原始信号的采样率的先验知识。解码器输出可为8 kHz或16 kHz，与编码器使用的采样率无关。因此，根据设备的实现和电声音频能力，编码器的输入和/或解码器的输出可以配置为8khz；但是，必须始终使用16 kHz RTP时钟频率。RTP时间戳每20毫秒增加320。
The RTP header marker bit (M) SHALL be set to 1 if the first frame carried in the packet contains a speech frame that is the first in a talkspurt. For all other packets, the marker bit SHALL be set to zero (M=0).
如果包中携带的第一帧包含TalkSport中的第一个语音帧，则RTP报头标记位（M）应设置为1。对于所有其他数据包，标记位应设置为零（M=0）。
Three RTP packet formats are supported for the EVRC-NW codec -- the interleaved/bundled packet format, the header-free packet format, and the compact bundled packet format. For all these formats, the operational details and capabilities of EVRC-NW, such as TOC, interleaving, DTX, and bundling, are exactly the same as those defined in EVRC [6], EVRC-B [2], and EVRC-WB [3], except that
EVRC-NW编解码器支持三种RTP数据包格式——交织/捆绑数据包格式、无报头数据包格式和紧凑捆绑数据包格式。对于所有这些格式，EVRC-NW的操作细节和功能，如TOC、交织、DTX和捆绑，与EVRC[6]、EVRC-B[2]和EVRC-WB[3]中定义的完全相同，只是
1. the mode change request field in the interleaved/bundled packet format MUST be interpreted according to the definition of the RATE_REDUC parameter as described for EVRC-NW in 3GPP2 C.S0014-D [4].
1. 交织/捆绑数据包格式中的模式更改请求字段必须根据3GPP2 C.S0014-D[4]中针对EVRC-NW所述的RATE_Reduce参数的定义进行解释。
2. the mode change request field in the interleaved/bundled packet format SHOULD be honored by an EVRC-NW encoding endpoint in a one-to-one session with a dedicated EVRC-NW decoding endpoint, such as in a two-party call or in a conference leg.
2. 在与专用EVRC-NW解码端点的一对一会话中，EVRC-NW编码端点应遵守交错/捆绑数据包格式中的模式更改请求字段，例如在两方呼叫或会议分支中。
3. the reserved bit field in the first octet of the interleaved/ bundled format has only one bit. Bit 1 of the first octet is an EVRC-NW wideband/narrowband encoding capability identification flag.
3. 交织/捆绑格式的第一个八位字节中的保留位字段只有一位。第一个八位组的比特1是EVRC-NW宽带/窄带编码能力识别标志。
The media type audio/EVRCNW maps to the interleaved/bundled packet format, audio/EVRCNW0 maps to the header-free packet format, and audio/EVRCNW1 maps to the compact bundled packet format.
媒体类型audio/EVRCNW映射到交织/捆绑包格式，audio/EVRCNW0映射到无报头包格式，audio/EVRCNW1映射到紧凑捆绑包格式。
6.1. Encoding Capability Identification in EVRC-NW Interleaved/Bundled Format
6.1. EVRC-NW交织/捆绑格式的编码能力识别
The EVRC-NW interleaved/bundled format defines an encoding capability identification flag, which is used to signal the local EVRC-NW wideband/narrowband encoding capability at the time of construction of an RTP packet to the far end of a communication session. This capability identification flag allows the far end to use the MMM field in its outgoing (returning) EVRC-NW interleaved/bundled format packets to request the desired EVRC-NW wideband or narrowband encoding mode in accordance with the dynamic/instantaneous encoding capability information. See RFC 3558 [6] for the definition of the MMM field. The following examples illustrate a few scenarios where the encoding capability information is used:
EVRC-NW交织/捆绑格式定义了编码能力识别标志，该标志用于在构建RTP分组时向通信会话的远端发送本地EVRC-NW宽带/窄带编码能力的信号。该能力标识标志允许远端在其输出（返回）EVRC-NW交织/捆绑格式分组中使用MMM字段，以根据动态/瞬时编码能力信息请求期望的EVRC-NW宽带或窄带编码模式。有关MMM字段的定义，请参见RFC 3558[6]。以下示例说明了使用编码能力信息的几个场景：
o An end-to-end wideband communication is established first between two communication endpoints using the EVRC-NW interleaved/bundled format. The called endpoint becomes wideband encoding incapable during the call and makes the other end aware of this change by using the encoding capability identification flag. Based on the new information, the calling endpoint could change the MMM value in its outgoing EVRC-NW packets from mode 0 to mode 4 to request narrowband encoded traffic for bandwidth efficiency or from mode 0 to mode 1 for best perceptual quality.
o 首先使用EVRC-NW交织/捆绑格式在两个通信端点之间建立端到端宽带通信。被呼叫的端点在呼叫期间变得无法进行宽带编码，并通过使用编码能力标识标志使另一端意识到这一变化。基于新的信息，呼叫端点可以将其传出的EVRC-NW分组中的MMM值从模式0更改为模式4，以请求窄带编码业务以提高带宽效率，或者从模式0更改为模式1以获得最佳感知质量。
o An end-to-end narrowband communication is established between a calling endpoint that is EVRC-NW wideband encoding capable and a called endpoint that is EVRC-NW wideband encoding incapable. The called endpoint becomes EVRC-NW wideband encoding capable during the call and makes the other end aware of this change using the encoding capability identification flag. Based on the new information, the calling endpoint could change the MMM value in its outgoing EVRC-NW packets from non-mode-0 to mode 0 to request wideband traffic.
o 在能够进行EVRC-NW宽带编码的主叫端点和不能进行EVRC-NW宽带编码的被叫端点之间建立端到端窄带通信。被呼叫的端点在呼叫期间变为具有EVRC-NW宽带编码能力，并使用编码能力标识标志使另一端意识到这一变化。根据新信息，呼叫端点可以将其传出EVRC-NW数据包中的MMM值从非模式0更改为模式0，以请求宽带业务。
The EVRC-NW interleaved/bundled format defines the encoding capability identification flag in bit 1 of the first octet, as illustrated in the figure below. The flag shall be set to zero (C=0) when the local EVRC-NW encoder is capable of mode 0 wideband encoding. The flag shall be set to one (C=1) when the local EVRC-NW encoder is capable of non-mode-0 narrowband encoding only. See RFC 3558 [6] for original definitions of other fields in the interleaved/bundled format.
EVRC-NW交织/捆绑格式在第一个八位字节的第1位定义编码能力标识标志，如下图所示。当本地EVRC-NW编码器能够进行模式0宽带编码时，该标志应设置为零（C=0）。当本地EVRC-NW编码器只能进行非模式-0窄带编码时，该标志应设置为1（C=1）。交叉/捆绑格式的其他字段的原始定义，请参见RFC 3558[6]。
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 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|R|C| LLL | NNN | MMM | Count | TOC | ... | TOC |padding|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| one or more codec data frames, one per TOC entry |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|R|C| LLL | NNN | MMM | Count | TOC | ... | TOC |padding|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| one or more codec data frames, one per TOC entry |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved (R): 1 bit
保留（R）：1位
Reserved bit. MUST be set to zero by sender; SHOULD be ignored by receiver.
保留位。发送方必须将其设置为零；应被接收者忽略。
Encoding capability identification (C): 1 bit
编码能力识别（C）：1位
Must be set to zero by sender to indicate wideband encoding capable or set to one to indicate narrowband encoding capable only.
发送方必须将设置为零以表示支持宽带编码，或将设置为1以表示仅支持窄带编码。
C = 0 : mode 0 wideband encoding capable
C=0：支持模式0宽带编码
= 1 : mode 0 wideband encoding incapable, i.e., narrowband encoding only.
=1：模式0无法进行宽带编码，即仅限窄带编码。
Congestion control for RTP is discussed in RFC 3550 [5] and in applicable RTP profiles, e.g., RFC3551 [7]. This document does not change those considerations.
RFC 3550[5]和适用的RTP配置文件（如RFC3551[7]）中讨论了RTP的拥塞控制。本文件不会改变这些考虑因素。
Due to the header overhead, the number of frames encapsulated in each RTP packet influences the overall bandwidth of the RTP stream. Packing more frames in each RTP packet can reduce the number of packets sent and hence the header overhead, at the expense of increased delay and reduced error robustness.
由于报头开销，每个RTP数据包中封装的帧数影响RTP流的总带宽。在每个RTP数据包中封装更多帧可以减少发送的数据包数量，从而减少报头开销，但代价是增加延迟和降低错误鲁棒性。
The storage format is used for storing EVRC-NW encoded speech frames, e.g., as a file or email attachment.
存储格式用于存储EVRC-NW编码的语音帧，例如，作为文件或电子邮件附件。
The file begins with a magic number to identify the vocoder that is used. The magic number for EVRC-NW corresponds to the ASCII character string "#!EVRCNW\n", i.e., "0x23 0x21 0x45 0x56 0x52 0x43 0x4E 0x57 0x0A".
该文件以一个幻数开始，以标识所使用的声码器。EVRC-NW的幻数对应于ASCII字符串“#！EVRCNW\n”，即“0x23 0x21 0x45 0x56 0x52 0x43 0x4E 0x57 0x0A”。
The codec data frames are stored in consecutive order, with a single TOC entry field, extended to one octet, prefixing each codec data frame. The TOC field is extended to one octet by setting the four most significant bits of the octet to zero. For example, a TOC value of 4 (a full-rate frame) is stored as 0x04. The Value column in the table in Section 4 provides the TOC values for corresponding frame types.
编解码器数据帧以连续顺序存储，具有单个TOC输入字段，扩展为一个八位字节，在每个编解码器数据帧前加前缀。通过将八位字节的四个最高有效位设置为零，TOC字段扩展为一个八位字节。例如，TOC值4（全速率帧）存储为0x04。第4节表格中的值列提供了相应帧类型的TOC值。
Speech frames lost in transmission and non-received frames MUST be stored as erasure frames (TOC value of 5) to maintain synchronization with the original media.
传输中丢失的语音帧和未接收的帧必须存储为擦除帧（TOC值为5），以保持与原始媒体的同步。
This document introduces a new EVRC-NW 'audio' media subtype.
本文档介绍了一种新的EVRC-NW“音频”媒体子类型。
Following the guidelines in RFC 4855 [8] and RFC 6838 [9], this section registers new 'audio' media subtypes for EVRC-NW.
按照RFC 4855[8]和RFC 6838[9]中的指南，本节为EVRC-NW注册了新的“音频”媒体子类型。
Type name: audio
类型名称：音频
Subtype name: EVRCNW
子类型名称：EVRCNW
Required parameters: None
所需参数：无
Optional parameters: These parameters apply to RTP transfer only.
可选参数：这些参数仅适用于RTP传输。
mode-set-recv: A subset of EVRC-NW modes. Possible values are a comma-separated list of modes from the set {0,1,2,3,4,5,6,7} (see Table 2.6.1.2-1 in 3GPP2 C.S0014-D [4]). A decoder can use this attribute to inform an encoder of its preference to operate in a specified subset of modes. Absence of this parameter signals the mode set {1,2,3,4,5,6,7}.
模式集recv：EVRC-NW模式的子集。可能的值是集合{0,1,2,3,4,5,6,7}中以逗号分隔的模式列表（参见3GPP2 C.S0014-D[4]中的表2.6.1.2-1）。解码器可以使用此属性通知编码器其在指定模式子集中操作的偏好。缺少此参数表示模式集{1,2,3,4,5,6,7}。
ptime: See RFC 4566 [10].
ptime：见RFC 4566[10]。
maxptime: See RFC 4566.
最大时间：见RFC 4566。
maxinterleave: Maximum number for interleaving length (field LLL in the Interleaving Octet) [0..7]. The interleaving lengths used in the entire session MUST NOT exceed this maximum value. If not signaled, the maxinterleave length MUST be 5.
maxinterleave：交织长度的最大数目（交织八位字节中的字段LLL）[0..7]。整个会话中使用的交织长度不得超过此最大值。如果未发出信号，则maxinterleave长度必须为5。
silencesupp: See Section 6.1 in RFC 4788.
消声抑制：见RFC 4788第6.1节。
dtxmax: See Section 6.1 in RFC 4788.
dtxmax：见RFC 4788第6.1节。
dtxmin: See Section 6.1 in RFC 4788.
dtxmin：见RFC 4788第6.1节。
hangover: See Section 6.1 in RFC 4788.
宿醉：见RFC 4788第6.1节。
Encoding considerations: This media type is framed binary data (see RFC 6838, Section 4.8) and is defined for transfer of EVRC-NW encoded data via RTP using the interleaved/bundled packet format specified in RFC 3558 [6].
编码注意事项：该媒体类型为帧二进制数据（见RFC 6838，第4.8节），定义用于使用RFC 3558[6]中规定的交织/捆绑包格式，通过RTP传输EVRC-NW编码数据。
Security considerations: See Section 16.
安全注意事项：见第16节。
Interoperability considerations: None
互操作性注意事项：无
Published specification: The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D [4]. The transfer method with the interleaved/bundled packet format via RTP is specified in RFC 3558 [6]. See Section 6 of RFC 6884 for details for EVRC-NW.
已发布规范：EVRC-NW声码器在3GPP2 C.S0014-D[4]中有规定。RFC 3558[6]中规定了通过RTP采用交织/捆绑包格式的传输方法。有关EVRC-NW的详细信息，请参见RFC 6884第6节。
Applications that use this media type: It is expected that many VoIP applications (as well as mobile applications) will use this type.
使用此媒体类型的应用程序：预计许多VoIP应用程序（以及移动应用程序）将使用此类型。
Additional information:
其他信息：
The following applies to stored-file transfer methods:
以下内容适用于存储的文件传输方法：
Magic number: #!EVRCNW\n (see Section 8)
Magic number: #!EVRCNW\n (see Section 8)
File extensions: enw, ENW
文件扩展名：enw，enw
Macintosh file type code: None
Macintosh文件类型代码：无
Object identifier or OID: None
对象标识符或OID:无
EVRC-NW speech frames may also be stored in the file format "3g2" as defined in 3GPP2 C.S0050-B [14], which is identified using the media types "audio/3gpp2" or "video/3gpp2" registered by RFC 4393 [11].
EVRC-NW语音帧也可以3GPP2 C.S0050-B[14]中定义的文件格式“3g2”存储，该文件格式使用RFC 4393[11]注册的媒体类型“音频/3GPP2”或“视频/3GPP2”识别。
Person & email address to contact for further information:
Zheng Fang <zfang@qualcomm.com>
Person & email address to contact for further information:
Zheng Fang <zfang@qualcomm.com>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type can be used with the file format defined in Section 8 of RFC 6884 in contexts other than RTP. In the context of transfers over RTP, the RTP payload format specified in Section 4.1 of RFC 3558 [6] is used for this media type.
使用限制：此媒体类型可与RFC 6884第8节中定义的文件格式一起在RTP以外的上下文中使用。在通过RTP传输的情况下，RFC 3558[6]第4.1节中规定的RTP有效负载格式用于此媒体类型。
Author: Zheng Fang <zfang@qualcomm.com>
Author: Zheng Fang <zfang@qualcomm.com>
Change controller: IETF Payload working group delegated from the IESG.
变更控制员：IESG授权的IETF有效载荷工作组。
Type name: audio
类型名称：音频
Subtype name: EVRCNW0
子类型名称：EVRCNW0
Required parameters: None
所需参数：无
Optional parameters: These parameters apply to RTP transfer only.
可选参数：这些参数仅适用于RTP传输。
mode-set-recv: A subset of EVRC-NW modes. Possible values are a comma-separated list of modes from the set {0,1,2,3,4,5,6,7} (see Table 2.6.1.2-1 in 3GPP2 C.S0014-D [4]). A decoder can use this attribute to inform an encoder of its preference to operate in a specified subset of modes. Absence of this parameter signals the mode set {1,2,3,4,5,6,7}.
模式集recv：EVRC-NW模式的子集。可能的值是集合{0,1,2,3,4,5,6,7}中以逗号分隔的模式列表（参见3GPP2 C.S0014-D[4]中的表2.6.1.2-1）。解码器可以使用此属性通知编码器其在指定模式子集中操作的偏好。缺少此参数表示模式集{1,2,3,4,5,6,7}。
ptime: See RFC 4566.
ptime：见RFC 4566。
silencesupp: See Section 6.1 in RFC 4788.
消声抑制：见RFC 4788第6.1节。
dtxmax: See Section 6.1 in RFC 4788.
dtxmax：见RFC 4788第6.1节。
dtxmin: See Section 6.1 in RFC 4788.
dtxmin：见RFC 4788第6.1节。
hangover: See Section 6.1 in RFC 4788.
宿醉：见RFC 4788第6.1节。
Encoding considerations: This media type is framed binary data (see RFC 6838, Section 4.8) and is defined for transfer of EVRC-NW encoded data via RTP using the header-free packet format specified in RFC 3558 [6].
编码注意事项：该媒体类型为帧二进制数据（见RFC 6838，第4.8节），定义为使用RFC 3558[6]中规定的无报头数据包格式，通过RTP传输EVRC-NW编码数据。
Security considerations: See Section 16.
安全注意事项：见第16节。
Interoperability considerations: None
互操作性注意事项：无
Published specification: The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D [4]. The transfer method with the header-free packet format via RTP is specified in RFC 3558 [6].
已发布规范：EVRC-NW声码器在3GPP2 C.S0014-D[4]中有规定。RFC 3558[6]中规定了通过RTP的无报头数据包格式的传输方法。
Applications that use this media type: It is expected that many VoIP applications (as well as mobile applications) will use this type.
使用此媒体类型的应用程序：预计许多VoIP应用程序（以及移动应用程序）将使用此类型。
Additional information: None
其他信息：无
Person & email address to contact for further information:
Zheng Fang <zfang@qualcomm.com>
Person & email address to contact for further information:
Zheng Fang <zfang@qualcomm.com>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing and hence is only defined for transfer via RTP [5]. The RTP payload format specified in Section 4.2 of RFC 3558 [6] SHALL be used. This media type SHALL NOT be used for storage or file transfer; instead, audio/EVRCNW SHALL be used.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输[5]。应使用RFC 3558[6]第4.2节中规定的RTP有效载荷格式。此媒体类型不得用于存储或文件传输；相反，应使用音频/EVRCNW。
Author: Zheng Fang <zfang@qualcomm.com>
Author: Zheng Fang <zfang@qualcomm.com>
Change controller: IETF Payload working group delegated from the IESG.
变更控制员：IESG授权的IETF有效载荷工作组。
Type name: audio
类型名称：音频
Subtype name: EVRCNW1
子类型名称：EVRCNW1
Required parameters: None
所需参数：无
Optional parameters: These parameters apply to RTP transfer only.
可选参数：这些参数仅适用于RTP传输。
mode-set-recv: A subset of EVRC-NW modes. Possible values are a comma-separated list of modes from the set {0,1} (see Table 2.6.1.2-1 in 3GPP2 C.S0014-D [4]). A decoder can use this attribute to inform an encoder of its preference to operate in a specified subset of modes. A value of 0 signals support for wideband fixed rate (full or half rate, depending on the value of the 'fixedrate' parameter). A value of 1 signals narrowband fixed rate (full or half rate, depending on the value of the 'fixedrate' parameter). Absence of this parameter signals mode 1.
模式集recv：EVRC-NW模式的子集。可能的值是集合{0,1}中以逗号分隔的模式列表（参见3GPP2 C.S0014-D[4]中的表2.6.1.2-1）。解码器可以使用此属性通知编码器其在指定模式子集中操作的偏好。值为0的信号支持宽带固定速率（全速率或半速率，取决于“fixedrate”参数的值）。值为1表示窄带固定速率（全速率或半速率，取决于“fixedrate”参数的值）。没有此参数表示模式1。
ptime: See RFC 4566.
ptime：见RFC 4566。
maxptime: See RFC 4566.
最大时间：见RFC 4566。
fixedrate: Indicates the EVRC-NW rate of the session while in single rate operation. Valid values include 0.5 and 1, where a value of 0.5 indicates the 1/2 rate while a value of 1 indicates the full rate. If this parameter is not present, 1/2 rate is assumed.
fixedrate：表示单速率操作时会话的EVRC-NW速率。有效值包括0.5和1，其中0.5表示1/2速率，1表示全速率。如果此参数不存在，则假定为1/2速率。
silencesupp: See Section 6.1 in RFC 4788.
消声抑制：见RFC 4788第6.1节。
dtxmax: See Section 6.1 in RFC 4788.
dtxmax：见RFC 4788第6.1节。
dtxmin: See Section 6.1 in RFC 4788.
dtxmin：见RFC 4788第6.1节。
hangover: See Section 6.1 in RFC 4788.
宿醉：见RFC 4788第6.1节。
Encoding considerations: This media type is framed binary data (see RFC 6838, Section 4.8) and is defined for transfer of EVRC-NW encoded data via RTP using the compact bundled packet format specified in RFC 4788.
编码注意事项：该媒体类型为帧二进制数据（见RFC 6838，第4.8节），定义为使用RFC 4788中规定的紧凑捆绑包格式，通过RTP传输EVRC-NW编码数据。
Security considerations: See Section 16.
安全注意事项：见第16节。
Interoperability considerations: None
互操作性注意事项：无
Published specification: The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D [4]. The transfer method with the compact bundled packet format via RTP is specified in RFC 4788.
已发布规范：EVRC-NW声码器在3GPP2 C.S0014-D[4]中有规定。RFC 4788中规定了通过RTP的紧凑捆绑包格式的传输方法。
Applications that use this media type: It is expected that many VoIP applications (as well as mobile applications) will use this type.
使用此媒体类型的应用程序：预计许多VoIP应用程序（以及移动应用程序）将使用此类型。
Additional information: None
其他信息：无
Person & email address to contact for further information:
Zheng Fang <zfang@qualcomm.com>
Person & email address to contact for further information:
Zheng Fang <zfang@qualcomm.com>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing and hence is only defined for transfer via RTP [5]. The RTP payload format specified in Section 4 of RFC 4788 SHALL be used. This media type SHALL NOT be used for storage or file transfer; instead, audio/EVRCNW SHALL be used.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输[5]。应使用RFC 4788第4节中规定的RTP有效载荷格式。此媒体类型不得用于存储或文件传输；相反，应使用音频/EVRCNW。
Author: Zheng Fang <zfang@qualcomm.com>
Author: Zheng Fang <zfang@qualcomm.com>
Change controller: IETF Payload working group delegated from the IESG.
变更控制员：IESG授权的IETF有效载荷工作组。
'mode-set-recv' can be used by a decoder to inform an encoder of its preference to operate in a specified subset of modes. Note that indicating a preference implicitly indicates support for that capability. If mode 0 is not preferred for media type EVRCNW0 or EVRCNW1, then there is no indication that mode 0 is supported. However, absence of this parameter or absence of mode 0 in this parameter for media type EVRCNW shall not preclude mode 0 support during a call where mode 0 may be requested via the MMM field.
解码器可使用“模式集recv”通知编码器其在指定模式子集中操作的偏好。请注意，指示首选项隐式表示支持该功能。如果媒体类型EVRCNW0或EVRCNW1不首选模式0，则没有迹象表明支持模式0。但是，对于媒体类型EVRCNW，如果该参数中没有此参数或没有模式0，则不应排除在呼叫期间对模式0的支持，其中可以通过MMM字段请求模式0。
1. To inform other nodes of its capability for wideband mode support: a decoder can always decode all the narrowband modes (modes 1 to 7). Unless the decoder indicates support of mode 0 (i.e., preference) in this parameter or in the MMM mode request field in the interleaved/bundled payload format, an encoder at the other side shall not operate in mode 0.
1. 告知其他节点其支持宽带模式的能力：解码器始终可以解码所有窄带模式（模式1至7）。除非解码器在该参数中或在交织/捆绑有效载荷格式的MMM模式请求字段中指示支持模式0（即首选项），否则另一侧的编码器不得在模式0下工作。
2. To indicate a preference to operate in a subset of modes: a set has been defined so that several modes can be expressed as a preference in one attempt. For instance, the set {4,5,6,7} signals that the receiver prefers that the sender operate in bandwidth-efficient narrowband modes of EVRC-NW.
2. 指示在模式子集中操作的首选项：已定义一个集合，以便在一次尝试中将多个模式表示为首选项。例如，集合{4,5,6,7}表示接收机希望发送方在EVRC-NW的带宽有效的窄带模式下工作。
Note that during an active call session using the interleaved/bundled packet format, the MMM mode request received from a communication partner can contain a mode request different than the values in the last mode-set-recv attribute. The partner's EVRC-NW wideband decoding capability is determined by the latest mode-set-recv attribute or MMM mode request field. For example, a mode request with MMM=0 from a communication partner is an implicit indication of the partner's EVRC-NW wideband decoding capability and preference. An EVRC-NW wideband-capable node receiving the request can operate in wideband mode. A mode request with MMM=1, 2, ..., or 7 from a communication partner is an implicit indication of the partner's
注意，在使用交织/捆绑分组格式的活动呼叫会话期间，从通信伙伴接收的MMM模式请求可以包含不同于最后模式集recv属性中的值的模式请求。合作伙伴的EVRC-NW宽带解码能力由最新模式集recv属性或MMM模式请求字段确定。例如，来自通信伙伴的MMM＝0的模式请求是伙伴的EVRC-NW宽带解码能力和偏好的隐式指示。能够接收请求的EVRC-NW宽带节点可以在宽带模式下工作。来自通信伙伴的MMM=1、2、…、或7的模式请求是该伙伴行为的隐式指示
EVRC-NW narrowband decoding preference. The encoder of an EVRC-NW node receiving the request shall honor the request and operate in narrowband mode.
EVRC-NW窄带解码首选项。接收请求的EVRC-NW节点的编码器应接受该请求并在窄带模式下运行。
'sendmode' is used as a Session Description Protocol (SDP) mode attribute in EVRC [6], EVRC-B [2], and EVRC-WB [3]. However, it is deprecated in EVRC-NW.
“sendmode”用作EVRC[6]、EVRC-B[2]和EVRC-WB[3]中的会话描述协议（SDP）模式属性。但是，EVRC-NW中不推荐使用它。
The interleaved/bundled packet format for the EVRC family of vocoders supports a 3-bit field (MMM) that a communication node can use to indicate its preferred compression mode to an opposite node. The concept of the compression mode (also known as Capacity Operating Point) was introduced to allow a controlled trade-off between voice quality and channel capacity. The notion makes it possible to exercise vocoders at the highest possible (average) bit-rate (hence, highest voice quality) when the network is lightly loaded. Conversely, once the network load increases, the vocoders can be requested to operate at lower average bit-rates so as to absorb the additional network load without causing an undue increase in the frame-erasure rates; the underlying premise is that while a higher bit-rate improves vocoder performance, it also increases the network load, risking a sharp decline in voice quality should the frame-erasure rate be too high. By contrast, a lower bit-rate mode of operation can result in accommodation of the additional network load without causing unduly high frame-erasure rates, resulting in better overall quality despite the inherently lower voice quality of the lower bit-rate mode of the vocoder.
用于EVRC系列声码器的交织/捆绑分组格式支持3位字段（MMM），通信节点可使用该MMM向相反节点指示其优选压缩模式。引入了压缩模式（也称为容量工作点）的概念，以便在语音质量和信道容量之间进行有控制的权衡。这一概念使得在网络负载较轻的情况下，以尽可能高的（平均）比特率（因此，最高的语音质量）使用声码器成为可能。相反，一旦网络负载增加，可以请求声码器以较低的平均比特率操作，以便吸收额外的网络负载而不会导致帧擦除率的过度增加；其基本前提是，虽然较高的比特率可以提高声码器性能，但也会增加网络负载，如果帧擦除率过高，语音质量可能会急剧下降。相比之下，较低比特率的操作模式可导致在不引起过高的帧擦除率的情况下容纳额外的网络负载，从而导致更好的总体质量，尽管声码器的较低比特率模式的固有较低语音质量。
Accordingly, the MMM field should be used to request the far end to transmit compressed speech using a mode that provides the best balance between voice quality and capacity. However, in the case of mobile-mobile calls, for example, there are two wireless sides involved, each with a potentially different network load level and hence a different preferred mode. In such cases, achieving optimal end-to-end performance depends on coherent management of the operative mode by the two sides. This requires that even if the local node prefers a higher bit-rate vocoder mode, it should adjust to a lower bit-rate mode if requested by the far end, in order to avoid potentially high frame-erasure rates due to heavy load at the far-end network. For similar reasons, in cases where a mode requested by the far end should not be supported, it might still be beneficial to consider switching to a supported vocoder mode corresponding to a lower average bit-rate than requested. It is recommended that the next lower average bit-rate supported vocoder mode be used for encoding when a mode requested by the far end is not supported.
因此，MMM字段应用于请求远端使用在语音质量和容量之间提供最佳平衡的模式发送压缩语音。然而，例如，在移动呼叫的情况下，涉及两个无线侧，每个无线侧具有潜在不同的网络负载水平，因此具有不同的优选模式。在这种情况下，实现最佳端到端性能取决于双方对操作模式的一致管理。这要求即使本地节点偏好更高比特率声码器模式，如果远端请求，它也应调整到更低比特率模式，以避免由于远端网络的重负载而导致潜在的高帧擦除率。出于类似的原因，在不支持远端请求的模式的情况下，考虑切换到比所请求的较低的平均比特率对应的支持声码器模式仍然是有益的。当远端请求的模式不受支持时，建议使用下一个较低平均比特率支持的声码器模式进行编码。
A wideband-capable endpoint can use the information conveyed by the C-bit of the RTP payload header to determine the optimal mode to request of the far end. If the far end cannot provide mode 0 packets (C-bit=1), then the choice of MMM can be based strictly on the local network load. If the C-bit indicates the remote end's mode 0 encoding capability (C-bit=0), then even if the local network load is not light, mode 0 can be requested knowing definitively that it will be supported. This will permit operators to treat wideband-capable mobiles preferentially, should they wish to adopt such policy.
具有宽带能力的端点可以使用由RTP有效载荷报头的C比特传送的信息来确定远端请求的最佳模式。如果远端无法提供模式0数据包（C位=1），则MMM的选择可严格基于本地网络负载。如果C位表示远程端的模式0编码能力（C位=0），则即使本地网络负载不轻，也可以请求模式0，明确知道它将得到支持。这将允许运营商优先对待具有宽带能力的手机，如果他们希望采用这种政策的话。
Information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [10], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing EVRC-NW encoded speech, the mapping is as follows.
媒体类型规范中包含的信息与会话描述协议（SDP）[10]中的字段具有特定映射，该协议通常用于描述RTP会话。当SDP用于指定使用EVRC-NW编码语音的会话时，映射如下所示。
o The media type ("audio") goes in SDP "m=" as the media name.
o 媒体类型（“音频”）以SDP“m=”作为媒体名称。
o The media subtype ("EVRCNW", "EVRCNW0", or "EVRCNW1") goes in SDP "a=rtpmap" as the encoding name.
o 媒体子类型（“EVRCNW”、“EVRCNW0”或“EVRCNW1”）以SDP“a=rtpmap”作为编码名称。
o The optional parameters 'ptime and 'maxptime' (for subtypes EVRCNW and EVRCNW1) go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
o 可选参数“ptime”和“maxptime”（用于子类型EVRCNW和EVRCNW1）分别位于SDP“a=ptime”和“a=maxptime”属性中。
o Any remaining parameters (for subtypes EVRCNW, EVRCNW0, and EVRCNW1) go in the SDP "a=fmtp" attribute by copying them from the media type string as a semicolon-separated list of parameter=value pairs.
o 任何剩余的参数（对于子类型EVRCNW、EVRCNW0和EVRCNW1）都将作为参数=值对的分号分隔列表从媒体类型字符串复制到SDP“a=fmtp”属性中。
The following considerations apply when using the SDP offer-answer procedures of RFC 3264 [12] to negotiate the use of EVRC-NW payload in RTP:
当使用RFC 3264[12]的SDP报价-应答程序协商RTP中EVRC-NW有效载荷的使用时，以下注意事项适用：
o Since EVRC-NW is an extension of both EVRC-B and EVRC-WB, the offerer SHOULD also announce EVRC-B and EVRC-WB support in its "m=audio" lines, with EVRC-NW as the preferred codec. This will allow interoperability with an answerer that supports only EVRC-B and/or EVRC-WB.
o 由于EVRC-NW是EVRC-B和EVRC-WB的扩展，报价人还应在其“m=音频”行中宣布EVRC-B和EVRC-WB支持，EVRC-NW为首选编解码器。这将允许与仅支持EVRC-B和/或EVRC-WB的应答者进行互操作。
Below is an example of such an offer:
以下是此类报价的一个示例：
m=audio 55954 RTP/AVP 98 99 100
a=rtpmap:98 EVRCNW0/16000
a=rtpmap:99 EVRCWB0/16000
a=rtpmap:100 EVRCB0/8000
a=fmtp:98 mode-set-recv=0,1,2,3,4,5,6
a=fmtp:99 mode-set-recv=0,4
a=fmtp:100 recvmode=0
m=audio 55954 RTP/AVP 98 99 100
a=rtpmap:98 EVRCNW0/16000
a=rtpmap:99 EVRCWB0/16000
a=rtpmap:100 EVRCB0/8000
a=fmtp:98 mode-set-recv=0,1,2,3,4,5,6
a=fmtp:99 mode-set-recv=0,4
a=fmtp:100 recvmode=0
If the answerer supports EVRC-NW, then the answerer can keep the payload type 98 in its answer and the conversation can be done using EVRC-NW. Otherwise, if the answerer supports only EVRC-WB and/or EVRC-B, then the answerer will leave only the payload type 99 and/or 100, respectively, in its answer and the conversation will be done using EVRC-WB and/or EVRC-B, respectively.
如果应答者支持EVRC-NW，则应答者可以在其应答中保留有效负载类型98，并且可以使用EVRC-NW完成对话。否则，如果应答者仅支持EVRC-WB和/或EVRC-B，则应答者将在其回答中分别只保留有效负载类型99和/或100，并且将分别使用EVRC-WB和/或EVRC-B完成对话。
An example answer for the above offer:
上述报价的示例答案如下：
m=audio 55954 RTP/AVP 98
a=rtpmap:98 EVRCNW0/16000
a=fmtp:98 mode-set-recv=4
m=audio 55954 RTP/AVP 98
a=rtpmap:98 EVRCNW0/16000
a=fmtp:98 mode-set-recv=4
o 'mode-set-recv' is a unidirectional receive-only parameter.
o “模式设置recv”是一个单向仅接收参数。
o An offerer can use 'mode-set-recv' to request that the remote sender's encoder be limited to the list of modes signaled in 'mode-set-recv'. A remote sender MAY ignore 'mode-set-recv' requests. However, a remote sender shall not assume the other side can support mode 0, unless the offer includes mode 0 explicitly in 'mode-set-recv' or the remote sender receives mode requests with MMM=0 from the communication partner during an active call using the EVRC-NW interleaved/bundled format.
o 报价人可以使用“模式设置recv”请求将远程发送方的编码器限制在“模式设置recv”中发出信号的模式列表内。远程发送方可能会忽略“模式设置recv”请求。但是，远程发送方不应假设另一方可以支持模式0，除非要约在“模式设置recv”中明确包含模式0，或者远程发送方在使用EVRC-NW交织/捆绑格式的活动呼叫期间从通信伙伴接收MMM=0的模式请求。
o The parameters 'maxptime' and 'ptime' will in most cases not affect interoperability; however, the setting of the parameters can affect the performance of the application. The SDP offer-answer handling of the 'ptime' parameter is described in RFC 3264 [12]. The 'maxptime' parameter MUST be handled in the same way.
o 参数“maxptime”和“ptime”在大多数情况下不会影响互操作性；但是，参数的设置可能会影响应用程序的性能。RFC 3264[12]中描述了“ptime”参数的SDP提供-应答处理。必须以相同的方式处理“maxptime”参数。
o For a sendonly stream, the 'mode-set-recv' parameter is not useful and SHOULD NOT be used.
o 对于仅发送的流，“mode set recv”参数无效，不应使用。
o When using EVRCNW1, the entire session MUST use the same fixed rate and mode (0-Wideband or 1-Narrowband).
o 使用EVRCNW1时，整个会话必须使用相同的固定速率和模式（0-宽带或1-窄带）。
o For additional rules that MUST be followed while negotiating DTX parameters, see Section 6.8 in RFC 4788 [2].
o 有关协商DTX参数时必须遵守的其他规则，请参阅RFC 4788[2]中的第6.8节。
o Any unknown parameter in an SDP offer MUST be ignored by the receiver and MUST NOT be included in the SDP answer.
o 接收方必须忽略SDP报价中的任何未知参数，且不得将其包含在SDP应答中。
For declarative use of SDP in the Session Announcement Protocol (SAP) [15] and the Real Time Streaming Protocol (RTSP) [16], the following considerations apply:
对于会话公告协议（SAP）[15]和实时流协议（RTSP）[16]中SDP的声明性使用，以下注意事项适用：
o Any 'maxptime' and 'ptime' values should be selected with care to ensure that the session's participants can achieve reasonable performance.
o 应谨慎选择任何“maxptime”和“ptime”值，以确保课程参与者能够实现合理的绩效。
o The payload format configuration parameters are all declarative, and a participant MUST use the configuration(s) that is provided for the session. More than one configuration MAY be provided if necessary by declaring multiple RTP payload types; however, the number of types SHOULD be kept small. For declarative examples, see Section 15.
o 有效负载格式配置参数都是声明性的，参与者必须使用为会话提供的配置。如有必要，可通过声明多个RTP有效负载类型来提供多个配置；但是，类型的数量应保持在较小的范围内。有关声明性示例，请参见第15节。
o The usage of unidirectional receive-only parameters, such as 'mode-set-recv', should be excluded in any declarations, since these parameters are meaningless in one-way streaming applications.
o 在任何声明中都不应使用单向仅接收参数，例如“mode set recv”，因为这些参数在单向流应用程序中没有意义。
Some example SDP session descriptions utilizing EVRC-NW encodings follow. In these examples, long a=fmtp lines are folded to meet the column width constraints of this document. The backslash ("\") at the end of a line and the carriage return that follows it should be ignored. Note that media subtype names are case-insensitive. Parameter names are case-insensitive both in media types and in the mapping to the SDP a=fmtp attribute.
下面是使用EVRC-NW编码的一些示例SDP会话描述。在这些示例中，长a=fmtp行被折叠以满足本文档的列宽约束。应忽略行尾的反斜杠（\）和其后的回车符。请注意，媒体子类型名称不区分大小写。参数名称在媒体类型和到SDP a=fmtp属性的映射中都不区分大小写。
Example usage of EVRCNW if wideband mode is supported:
如果支持宽带模式，则使用EVRCNW的示例：
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW/16000
a=rtpmap:98 EVRCWB/16000
a=rtpmap:99 EVRCB/8000
a=fmtp:97 mode-set-recv=0,1,2,3,4,5,6
a=fmtp:98 mode-set-recv=0,4
a=fmtp:99 recvmode=0
a=maxptime:120
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW/16000
a=rtpmap:98 EVRCWB/16000
a=rtpmap:99 EVRCB/8000
a=fmtp:97 mode-set-recv=0,1,2,3,4,5,6
a=fmtp:98 mode-set-recv=0,4
a=fmtp:99 recvmode=0
a=maxptime:120
Example usage of EVRCNW if wideband mode is not supported:
如果不支持宽带模式，则使用EVRCNW的示例：
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW/16000
a=rtpmap:98 EVRCWB/16000
a=rtpmap:99 EVRCB/8000
a=fmtp:97 mode-set-recv=1,2,3,4,5,6
a=fmtp:98 mode-set-recv=4
a=fmtp:99 recvmode=0
a=maxptime:120
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW/16000
a=rtpmap:98 EVRCWB/16000
a=rtpmap:99 EVRCB/8000
a=fmtp:97 mode-set-recv=1,2,3,4,5,6
a=fmtp:98 mode-set-recv=4
a=fmtp:99 recvmode=0
a=maxptime:120
Example usage of EVRCNW0:
EVRCNW0的使用示例：
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW0/16000
a=rtpmap:98 EVRCWB0/16000
a=rtpmap:99 EVRCB0/8000
a=fmtp:97 mode-set-recv=0,1,2,3,4,5,6
a=fmtp:98 mode-set-recv=0,4
a=fmtp:99 recvmode=0
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW0/16000
a=rtpmap:98 EVRCWB0/16000
a=rtpmap:99 EVRCB0/8000
a=fmtp:97 mode-set-recv=0,1,2,3,4,5,6
a=fmtp:98 mode-set-recv=0,4
a=fmtp:99 recvmode=0
Example SDP answer from a media gateway requesting a terminal to limit its encoder operation to EVRC-NW mode 4.
来自媒体网关的示例SDP应答，请求终端将其编码器操作限制为EVRC-NW模式4。
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCNW0/16000
a=fmtp:97 mode-set-recv=4
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCNW0/16000
a=fmtp:97 mode-set-recv=4
Example usage of EVRCNW1:
EVRCNW1的示例用法：
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW1/16000
a=rtpmap:98 EVRCWB1/16000
a=rtpmap:99 EVRCB1/8000
a=fmtp:97 fixedrate=0.5
a=fmtp:98 fixedrate=0.5
a=fmtp:99 fixedrate=0.5
a=maxptime:100
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW1/16000
a=rtpmap:98 EVRCWB1/16000
a=rtpmap:99 EVRCB1/8000
a=fmtp:97 fixedrate=0.5
a=fmtp:98 fixedrate=0.5
a=fmtp:99 fixedrate=0.5
a=maxptime:100
Example usage of EVRCNW with DTX with silencesupp=1:
EVRCNW和DTX的示例用法，消声supp=1：
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW/16000
a=rtpmap:98 EVRCWB/16000
a=rtpmap:99 EVRCB/8000
a=fmtp:97 silencesupp=1;dtxmax=32;dtxmin=12;hangover=1; \
mode-set-recv=0,1,2,3,4,5,6
a=fmtp:98 silencesupp=1;dtxmax=32;dtxmin=12;hangover=1; \
mode-set-recv=0,4
a=fmtp:99 recvmode=0
a=maxptime:120
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW/16000
a=rtpmap:98 EVRCWB/16000
a=rtpmap:99 EVRCB/8000
a=fmtp:97 silencesupp=1;dtxmax=32;dtxmin=12;hangover=1; \
mode-set-recv=0,1,2,3,4,5,6
a=fmtp:98 silencesupp=1;dtxmax=32;dtxmin=12;hangover=1; \
mode-set-recv=0,4
a=fmtp:99 recvmode=0
a=maxptime:120
Example usage of EVRCNW with DTX with silencesupp=0:
带DTX的EVRCNW的示例用法，静音SUPP=0：
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW/16000
a=rtpmap:98 EVRCWB/16000
a=rtpmap:99 EVRCB/8000
a=fmtp:97 silencesupp=0;dtxmax=32;dtxmin=12;hangover=1; \
mode-set-recv=0,1,2,3,4,5,6
a=fmtp:98 silencesupp=0;dtxmax=32;dtxmin=12;hangover=1; \
mode-set-recv=0,4
a=fmtp:99 recvmode=0
a=maxptime:120
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW/16000
a=rtpmap:98 EVRCWB/16000
a=rtpmap:99 EVRCB/8000
a=fmtp:97 silencesupp=0;dtxmax=32;dtxmin=12;hangover=1; \
mode-set-recv=0,1,2,3,4,5,6
a=fmtp:98 silencesupp=0;dtxmax=32;dtxmin=12;hangover=1; \
mode-set-recv=0,4
a=fmtp:99 recvmode=0
a=maxptime:120
Example offer-answer exchange between EVRC-NW and legacy EVRC-B (RFC 4788):
EVRC-NW和传统EVRC-B（RFC 4788）之间的报价-应答交换示例：
Offer:
报价：
m=audio 55954 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW0/16000
a=rtpmap:98 EVRCWB0/16000
a=rtpmap:99 EVRCB0/8000
a=rtpmap:97 mode-set-recv=0,1,2,3,4,5,6
a=fmtp:98 mode-set-recv=0,4
a=fmtp:99 recvmode=0
m=audio 55954 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW0/16000
a=rtpmap:98 EVRCWB0/16000
a=rtpmap:99 EVRCB0/8000
a=rtpmap:97 mode-set-recv=0,1,2,3,4,5,6
a=fmtp:98 mode-set-recv=0,4
a=fmtp:99 recvmode=0
Answer:
答复:
m=audio 55954 RTP/AVP 99
a=rtpmap:99 EVRCB0/8000
m=audio 55954 RTP/AVP 99
a=rtpmap:99 EVRCB0/8000
Example offer-answer exchange between EVRC-NW and legacy EVRC-WB (RFC 5188):
EVRC-NW和旧版EVRC-WB（RFC 5188）之间的报价-应答交换示例：
Offer:
报价：
m=audio 55954 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW0/16000
a=rtpmap:98 EVRCWB0/16000
a=rtpmap:99 EVRCB0/8000
a=rtpmap:97 mode-set-recv=0,1,2,3,4,5,6
a=fmtp:98 mode-set-recv=0,4
a=fmtp:99 recvmode=0
m=audio 55954 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW0/16000
a=rtpmap:98 EVRCWB0/16000
a=rtpmap:99 EVRCB0/8000
a=rtpmap:97 mode-set-recv=0,1,2,3,4,5,6
a=fmtp:98 mode-set-recv=0,4
a=fmtp:99 recvmode=0
Answer:
答复:
m=audio 55954 RTP/AVP 98 99
a=rtpmap:98 EVRCWB0/16000
m=audio 55954 RTP/AVP 98 99
a=rtpmap:98 EVRCWB0/16000
Since compression is applied to the payload formats end-to-end, and the encodings do not exhibit significant non-uniformity, implementations of this specification are subject to all the security considerations specified in RFC 3558 [6]. Implementations using the payload defined in this specification are subject to the security considerations discussed in RFC 3558 [6], RFC 3550 [5], and any appropriate profile (for example, RFC 3551 [7]). Additional security considerations are described in RFC 6562 [13].
由于压缩是端到端地应用于有效负载格式的，并且编码没有表现出显著的不一致性，因此本规范的实现受到RFC 3558[6]中规定的所有安全考虑的约束。使用本规范中定义的有效负载的实现受RFC 3558[6]、RFC 3550[5]和任何适当配置文件（例如RFC 3551[7]）中讨论的安全注意事项的约束。RFC 6562[13]中描述了其他安全注意事项。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Xie, Q. and R. Kapoor, "Enhancements to RTP Payload Formats for EVRC Family Codecs", RFC 4788, January 2007.
[2] Xie，Q.和R.Kapoor，“EVRC系列编解码器RTP有效载荷格式的增强”，RFC 4788，2007年1月。
[3] Desineni, H. and Q. Xie, "RTP Payload Format for the Enhanced Variable Rate Wideband Codec (EVRC-WB) and the Media Subtype Updates for EVRC-B Codec", RFC 5188, February 2008.
[3] Desineni，H.和Q.Xie，“增强型可变速率宽带编解码器（EVRC-WB）的RTP有效载荷格式和EVRC-B编解码器的媒体子类型更新”，RFC 5188，2008年2月。
[4] "Enhanced Variable Rate Codec, Speech Service Options 3, 68, 70, and 73 for Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014-D v3.0, October 2010, <http://www.3gpp2.org/ public_html/specs/C.S0014-D_v3.0_EVRC.pdf>.
[4] “用于宽带扩频数字系统的增强型变速率编解码器、语音服务选项3、68、70和73”，3GPP2 C.S0014-D v3.0，2010年10月<http://www.3gpp2.org/ public_html/specs/C.S0014-D_v3.0_EVRC.pdf>。
[5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[5] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[6] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, July 2003.
[6] 李安，“增强型变速率编解码器（EVRC）和可选模式声码器（SMV）的RTP有效载荷格式”，RFC3558，2003年7月。
[7] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[7] Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[8] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[8] Casner，S.，“RTP有效载荷格式的媒体类型注册”，RFC 4855，2007年2月。
[9] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013.
[9] Freed，N.，Klensin，J.和T.Hansen，“媒体类型规范和注册程序”，BCP 13，RFC 6838，2013年1月。
[10] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[10] Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[11] Garudadri, H., "MIME Type Registrations for 3GPP2 Multimedia Files", RFC 4393, March 2006.
[11] Garudadri，H.，“3GPP2多媒体文件的MIME类型注册”，RFC 4393，2006年3月。
[12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[12] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[13] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, March 2012.
[13] 珀金斯，C.和吉咪。Valin，“带安全RTP的可变比特率音频使用指南”，RFC 6562，2012年3月。
[14] "3GPP2 File Formats for Multimedia Services", 3GPP2 C.S0050-B v1.0, May 2007, <http://www.3gpp2.org/public_html/specs/ C.S0050-B_v1.0_070521.pdf>.
[14] “3GPP2多媒体服务文件格式”，3GPP2 C.S0050-B v1.0，2007年5月<http://www.3gpp2.org/public_html/specs/ C.S0050-B_v1.0_070521.pdf>。
[15] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[15] Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 29742000年10月。
[16] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[16] Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
Author's Address
作者地址
Zheng Fang Qualcomm Incorporated 5775 Morehouse Drive San Diego, CA 92126 USA
美国加利福尼亚州圣地亚哥Morehouse大道5775号郑方高通公司，邮编92126
Phone: +1 858 651 9484
EMail: zfang@qualcomm.com
URI: http://www.qualcomm.com
Phone: +1 858 651 9484
EMail: zfang@qualcomm.com
URI: http://www.qualcomm.com