Network Working Group H. Desineni
Request for Comments: 5188 Qualcomm
Updates: 4788 Q. Xie
Category: Standards Track Motorola
February 2008
Network Working Group H. Desineni
Request for Comments: 5188 Qualcomm
Updates: 4788 Q. Xie
Category: Standards Track Motorola
February 2008
RTP Payload Format for the Enhanced Variable Rate Wideband Codec (EVRC-WB) and the Media Subtype Updates for EVRC-B Codec
增强型可变速率宽带编解码器（EVRC-WB）的RTP有效负载格式和EVRC-B编解码器的媒体子类型更新
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document specifies Real-time Transport Protocol (RTP) payload formats to be used for the Enhanced Variable Rate Wideband Codec (EVRC-WB) and updates the media type registrations for EVRC-B codec. Several media type registrations are included for EVRC-WB RTP payload formats. In addition, a file format is specified for transport of EVRC-WB speech data in storage mode applications such as email.
本文件规定了用于增强型可变速率宽带编解码器（EVRC-WB）的实时传输协议（RTP）有效载荷格式，并更新了EVRC-B编解码器的媒体类型注册。EVRC-WB RTP有效负载格式包含多个媒体类型注册。此外，还为存储模式应用程序（如电子邮件）中的EVRC-WB语音数据传输指定了文件格式。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. EVRC-WB Codec . . . . . . . . . . . . . . . . . . . . . . . . 3
5. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . . . 4
6. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 4
7. Congestion Control Considerations . . . . . . . . . . . . . . 5
8. Storage Format for the EVRC-WB Codec . . . . . . . . . . . . . 5
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
9.1. Media Type Registrations . . . . . . . . . . . . . . . . . 5
9.1.1. Registration of Media Type audio/EVRCWB . . . . . . . 6
9.1.2. Registration of Media Type audio/EVRCWB0 . . . . . . . 8
9.1.3. Registration of Media Type audio/EVRCWB1 . . . . . . . 9
9.1.4. Updated Registration of Media Type audio/EVRCB . . . . 11
9.1.5. Updated Registration of Media Type audio/EVRCB0 . . . 13
10. SDP Mode Attributes for EVRC-WB and EVRC-B . . . . . . . . . . 15
11. EVRC-B Interoperability with Legacy Implementations (RFC 4788) 15
12. Mapping EVRC-WB Media Type Parameters into SDP . . . . . . . . 16
13. Mapping EVRC-B Media Type Parameters into SDP . . . . . . . . 16
14. Offer-Answer Model Considerations for EVRC-WB . . . . . . . . 16
15. Offer-Answer Model Considerations for EVRC-B . . . . . . . . . 18
16. Declarative SDP Considerations . . . . . . . . . . . . . . . . 18
17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
18. Security Considerations . . . . . . . . . . . . . . . . . . . 22
19. Changes to RFC 4788 . . . . . . . . . . . . . . . . . . . . . 22
20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
20.1. Normative References . . . . . . . . . . . . . . . . . . . 22
20.2. Informative References . . . . . . . . . . . . . . . . . . 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. EVRC-WB Codec . . . . . . . . . . . . . . . . . . . . . . . . 3
5. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . . . 4
6. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 4
7. Congestion Control Considerations . . . . . . . . . . . . . . 5
8. Storage Format for the EVRC-WB Codec . . . . . . . . . . . . . 5
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
9.1. Media Type Registrations . . . . . . . . . . . . . . . . . 5
9.1.1. Registration of Media Type audio/EVRCWB . . . . . . . 6
9.1.2. Registration of Media Type audio/EVRCWB0 . . . . . . . 8
9.1.3. Registration of Media Type audio/EVRCWB1 . . . . . . . 9
9.1.4. Updated Registration of Media Type audio/EVRCB . . . . 11
9.1.5. Updated Registration of Media Type audio/EVRCB0 . . . 13
10. SDP Mode Attributes for EVRC-WB and EVRC-B . . . . . . . . . . 15
11. EVRC-B Interoperability with Legacy Implementations (RFC 4788) 15
12. Mapping EVRC-WB Media Type Parameters into SDP . . . . . . . . 16
13. Mapping EVRC-B Media Type Parameters into SDP . . . . . . . . 16
14. Offer-Answer Model Considerations for EVRC-WB . . . . . . . . 16
15. Offer-Answer Model Considerations for EVRC-B . . . . . . . . . 18
16. Declarative SDP Considerations . . . . . . . . . . . . . . . . 18
17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
18. Security Considerations . . . . . . . . . . . . . . . . . . . 22
19. Changes to RFC 4788 . . . . . . . . . . . . . . . . . . . . . 22
20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
20.1. Normative References . . . . . . . . . . . . . . . . . . . 22
20.2. Informative References . . . . . . . . . . . . . . . . . . 23
This document specifies the payload formats for packetization of EVRC-WB 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-WB codec as well as discontinuous transmission (DTX) support for EVRC-WB encoded speech transported via RTP. The EVRC-WB codec offers better speech quality than the EVRC and EVRC-B codecs. EVRC-WB belongs to the EVRC family of codecs. This document also updates the media type registrations for the EVRC-B codec.
本文件规定了将EVRC-WB编码语音信号打包成实时传输协议（RTP）的有效载荷格式。它定义了对EVRC-WB编解码器的无报头、交织/捆绑和紧凑捆绑包格式的支持，以及对通过RTP传输的EVRC-WB编码语音的不连续传输（DTX）支持。EVRC-WB编解码器比EVRC和EVRC-B编解码器提供更好的语音质量。EVRC-WB属于EVRC编解码器系列。本文档还更新了EVRC-B编解码器的媒体类型注册。
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-WB is a wideband extension of the EVRC-B [4] speech codec developed in the Third Generation Partnership Project 2 (3GPP2) with support for discontinuous transmission (DTX). It provides enhanced (wideband) voice quality.
EVRC-WB是第三代合作伙伴项目2（3GPP2）中开发的EVRC-B[4]语音编解码器的宽带扩展，支持不连续传输（DTX）。它提供增强的（宽带）语音质量。
The EVRC-WB codec operates on 20-ms frames, and the default sampling rate is 16 kHz. Input and output at an 8-kHz sampling rate are also supported. The EVRC-WB codec can operate in three modes (0, 4, and 7) defined in [5]. EVRC-WB modes 4 and 7 are interoperable with EVRC-B. EVRC-WB mode 4 uses full-rate, 1/2-rate, and 1/8-rate frames. EVRC-WB mode 7 uses only 1/2 rate and 1/8 rate frames. Mode change results in codec output bit-rate change but do not cause any decoding problems at the receiver. For successful decoding, the decoder does not need to know the encoder's current mode of operation. EVRC-WB provides a standardized solution for packetized voice applications that allow transitions between narrowband and wideband telephony. The most important service addressed is IP telephony. Target devices can be IP phones or Voice over IP (VoIP) handsets, media gateways, voice messaging servers, etc.
EVRC-WB编解码器在20毫秒帧上运行，默认采样率为16 kHz。还支持8-kHz采样率的输入和输出。EVRC-WB编解码器可以在[5]中定义的三种模式（0、4和7）下运行。EVRC-WB模式4和7可与EVRC-B互操作。EVRC-WB模式4使用全速率、1/2速率和1/8速率帧。EVRC-WB模式7仅使用1/2速率和1/8速率帧。模式改变会导致编解码器输出比特率改变，但不会在接收器处造成任何解码问题。为了成功解码，解码器不需要知道编码器的当前操作模式。EVRC-WB为分组语音应用提供了标准化解决方案，允许在窄带和宽带电话之间进行转换。最重要的服务是IP电话。目标设备可以是IP电话或IP语音（VoIP）手机、媒体网关、语音消息服务器等。
The EVRC-WB codec operates on 20-ms frames. It produces output frames of one of the three different sizes: 171 bits, 80 bits, or 16 bits. 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 an 8-kHz sampling rate are also supported.
EVRC-WB编解码器在20毫秒帧上运行。它产生三种不同大小的输出帧之一：171位、80位或16位。此外，还有两种零位编解码器帧类型：空白（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 0 (0 bit)
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 0 (0 bit)
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 [6]. The EVRC-WB payload formats (Section 6) use the fields of the RTP header in a manner consistent with RFC 3550 [6].
RTP报头的格式在RFC 3550[6]中规定。EVRC-WB有效载荷格式（第6节）以与RFC 3550[6]一致的方式使用RTP报头的字段。
EVRC-WB 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 electro acoustic 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-WB还具有使用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-WB 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, such as Table of Contents (ToC), interleaving, DTX, and bundling, of EVRC-WB are exactly the same as those of EVRC-B, as defined in [3], except that the mode change request field in the ToC MUST be interpreted according to the definition of the RATE_REDUC parameter as defined in EVRC-WB [5]. The media type audio/EVRCWB maps to the interleaved/bundled packet format, audio/EVRCWB0 maps to the header-free packet format, and audio/EVRCWB1 maps to the compact bundled packet format.
EVRC-WB编解码器支持三种RTP数据包格式——交织/捆绑数据包格式、无报头数据包格式和紧凑捆绑数据包格式。对于所有这些格式，EVRC-WB的操作细节和功能，如目录（ToC）、交织、DTX和捆绑，与[3]中定义的EVRC-B完全相同，但ToC中的模式更改请求字段必须根据EVRC-WB[5]中定义的RATE_Reduce参数的定义进行解释。媒体类型audio/EVRCWB映射到交织/捆绑包格式，audio/EVRCWB0映射到无报头包格式，audio/EVRCWB1映射到紧凑捆绑包格式。
Congestion control for RTP SHALL be used in accordance with RFC 3550 [6], and with any applicable RTP profile, e.g., RFC 3551 [11].
RTP的拥塞控制应根据RFC 3550[6]和任何适用的RTP配置文件（如RFC 3551[11]）使用。
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-WB encoded speech frames, e.g., as a file or email attachment.
存储格式用于存储EVRC-WB编码的语音帧，例如，作为文件或电子邮件附件。
The file begins with a magic number to identify the vocoder that is used. The magic number for EVRC-WB corresponds to the ASCII character string "#!EVCWB\n", i.e., "0x23 0x21 0x45 0x56 0x43 0x57 0x42 0x0A".
该文件以一个幻数开始，以标识所使用的声码器。EVRC-WB的幻数对应于ASCII字符串“#！EVCWB\n”，即“0x23 0x21 0x45 0x56 0x43 0x57 0x42 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. See Section 4 for the mapping from frame type to ToC value.
编解码器数据帧以连续顺序存储，具有单个ToC输入字段，扩展为一个八位字节，在每个编解码器数据帧前加前缀。通过将八位字节的四个最高有效位设置为零，ToC字段扩展为一个八位字节。例如，ToC值4（全速率帧）存储为0x04。有关从帧类型到ToC值的映射，请参见第4节。
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 updates the audio/EVRCB and audio/EVRCB0 media types defined in RFC 4788 [3] and adds new EVRC-WB 'audio' media subtypes.
本文档更新了RFC 4788[3]中定义的音频/EVRCB和音频/EVRCB0媒体类型，并添加了新的EVRC-WB“音频”媒体子类型。
Following the guidelines in RFC 4855 [9] and RFC 4288 [10], this section registers new 'audio' media subtypes for EVRC-WB and updates the audio/EVRCB and audio/EVRCB0 media type registrations contained in RFC 4788 [3].
按照RFC 4855[9]和RFC 4288[10]中的指南，本节为EVRC-WB注册新的“音频”媒体子类型，并更新RFC 4788[3]中包含的音频/EVRCB和音频/EVRCB0媒体类型注册。
Type name: audio
类型名称：音频
Subtype name: EVRCWB
子类型名称：EVRCWB
Required parameters: None
所需参数：无
Optional parameters:
可选参数：
These parameters apply to RTP transfer only.
这些参数仅适用于RTP传输。
mode-set-recv: A subset of EVRC-WB modes. Possible values are a comma-separated list of modes from the set {0,4,7} (see Table 2.5.1.2-1 in 3GPP2 C.S0014-C). 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 {0,4,7}.
模式集recv：EVRC-WB模式的子集。可能的值是集合{0,4,7}中以逗号分隔的模式列表（参见3GPP2 C.S0014-C中的表2.5.1.2-1）。解码器可以使用此属性通知编码器其在指定模式子集中操作的偏好。缺少此参数表示模式集{0,4,7}。
sendmode: A mode of the EVRC-WB codec. An encoder can use this to signal its current mode of operation. Possible values are 0,4,7 (see Table 2.5.1.2-1 in 3GPP2 C.S0014-C). Absence of this parameter signals mode 0.
sendmode：EVRC-WB编解码器的一种模式。编码器可以使用该信号来表示其当前操作模式。可能的值为0,4,7（参见3GPP2 C.S0014-C中的表2.5.1.2-1）。缺少此参数表示模式0。
ptime: See RFC 4566.
ptime：见RFC 4566。
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 4288, Section 4.8) and is defined for transfer of EVRC-WB encoded data via RTP using the interleaved/bundled packet format specified in RFC 3558.
该媒体类型为帧二进制数据（见RFC 4288，第4.8节），定义用于使用RFC 3558中规定的交织/捆绑包格式，通过RTP传输EVRC-WB编码数据。
Security considerations: See Section 18 of RFC 5188.
安全注意事项：见RFC 5188第18节。
Interoperability considerations: None
互操作性注意事项：无
Published specification:
已发布的规范：
The EVRC-WB vocoder is specified in 3GPP2 C.S0014-C. The transfer method with the interleaved/bundled packet format via RTP is specified in RFC 3558 and RFC 5188.
3GPP2 C.S0014-C中规定了EVRC-WB声码器。RFC 3558和RFC 5188中规定了通过RTP的交织/捆绑包格式的传输方法。
3GPP2 C.S0050-B, 3GPP2 File Formats for Multimedia Services.
3GPP2 C.S0050-B，用于多媒体服务的3GPP2文件格式。
3GPP2 specifications are publicly accessible at http://www.3gpp2.org
3GPP2 specifications are publicly accessible at http://www.3gpp2.org
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: #!EVCWB\n (see Section 8 of RFC 5188)
Magic number: #!EVCWB\n (see Section 8 of RFC 5188)
File extensions: evw, EVW
文件扩展名：evw，evw
Macintosh file type code: None
Macintosh文件类型代码：无
Object identifier or OID: None
对象标识符或OID:无
EVRC-WB speech frames may also be stored in the file format "3g2" defined in 3GPP2 C.S0050-B, which is identified using the media types "audio/3gpp2" or "video/3gpp2" registered by RFC 4393.
EVRC-WB语音帧也可以3GPP2 C.S0050-B中定义的文件格式“3g2”存储，该文件格式使用RFC 4393注册的媒体类型“音频/3GPP2”或“视频/3GPP2”识别。
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Harikishan Desineni <hd@qualcomm.com>
Harikishan Desineni <hd@qualcomm.com>
Intended usage: COMMON
预期用途：普通
Restrictions on usage:
使用限制：
When this media type is used in the context of transfer over RTP, the RTP payload format specified in Section 4.1 of RFC 3558 SHALL be used. In all other contexts, the file format defined in Section 8 of RFC 5188 SHALL be used.
当在RTP传输环境中使用该媒体类型时，应使用RFC 3558第4.1节中规定的RTP有效载荷格式。在所有其他情况下，应使用RFC 5188第8节中定义的文件格式。
Author:
作者：
Harikishan Desineni
哈里基尚·德西尼尼
Change controller:
更改控制器：
IETF Audio/Video Transport working group delegated from the IESG.
IESG授权的IETF音频/视频传输工作组。
Type name: audio
类型名称：音频
Subtype name: EVRCWB0
子类型名称：EVRCWB0
Required parameters: None
所需参数：无
Optional parameters:
可选参数：
These parameters apply to RTP transfer only.
这些参数仅适用于RTP传输。
mode-set-recv: A subset of EVRC-WB modes. Possible values are a comma-separated list of modes from the set {0,4,7} (see Table 2.5.1.2-1 in 3GPP2 C.S0014-C). 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 {0,4,7}.
模式集recv：EVRC-WB模式的子集。可能的值是集合{0,4,7}中以逗号分隔的模式列表（参见3GPP2 C.S0014-C中的表2.5.1.2-1）。解码器可以使用此属性通知编码器其在指定模式子集中操作的偏好。缺少此参数表示模式集{0,4,7}。
sendmode: A mode of the EVRC-WB codec. An encoder can use this to signal its current mode of operation. Possible values are 0,4,7 (see Table 2.5.1.2-1 in 3GPP2 C.S0014-C). Absence of this parameter signals mode 0.
sendmode：EVRC-WB编解码器的一种模式。编码器可以使用该信号来表示其当前操作模式。可能的值为0,4,7（参见3GPP2 C.S0014-C中的表2.5.1.2-1）。缺少此参数表示模式0。
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 4288, Section 4.8) and is defined for transfer of EVRC-WB encoded data via RTP using the header-free packet format specified in RFC 3558.
该媒体类型为帧二进制数据（见RFC 4288，第4.8节），定义用于使用RFC 3558中规定的无报头数据包格式，通过RTP传输EVRC-WB编码数据。
Security considerations: See Section 18 of RFC 5188.
安全注意事项：见RFC 5188第18节。
Interoperability considerations: None
互操作性注意事项：无
Published specification:
已发布的规范：
The EVRC-WB vocoder is specified in 3GPP2 C.S0014-C. The transfer method with the header-free packet format via RTP is specified in RFC 3558 and RFC 5188.
3GPP2 C.S0014-C中规定了EVRC-WB声码器。RFC 3558和RFC 5188中规定了通过RTP的无报头数据包格式的传输方法。
3GPP2 C.S0050-B, 3GPP2 File Formats for Multimedia Services.
3GPP2 C.S0050-B，用于多媒体服务的3GPP2文件格式。
3GPP2 specifications are publicly accessible at http://www.3gpp2.org
3GPP2 specifications are publicly accessible at http://www.3gpp2.org
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:
联系人和电子邮件地址，以获取更多信息：
Harikishan Desineni <hd@qualcomm.com>
Harikishan Desineni <hd@qualcomm.com>
Intended usage: COMMON
预期用途：普通
Restrictions on usage:
使用限制：
This media type depends on RTP framing and hence is only defined for transfer via RTP [6]; the RTP payload format specified in Section 4.2 of RFC 3558 SHALL be used. This media type SHALL NOT be used for storage or file transfer using the file format defined in Section 8 of RFC 5188; instead, audio/EVRCWB SHALL be used.
此媒体类型取决于RTP帧，因此仅定义为通过RTP传输[6]；应使用RFC 3558第4.2节中规定的RTP有效载荷格式。该媒体类型不得用于使用RFC 5188第8节中定义的文件格式进行存储或文件传输；相反，应使用音频/EVRCWB。
Author:
作者：
Harikishan Desineni
哈里基尚·德西尼尼
Change controller:
更改控制器：
IETF Audio/Video Transport working group delegated from the IESG.
IESG授权的IETF音频/视频传输工作组。
Type name: audio
类型名称：音频
Subtype name: EVRCWB1
子类型名称：EVRCWB1
Required parameters: None
所需参数：无
Optional parameters:
可选参数：
These parameters apply to RTP transfer only.
这些参数仅适用于RTP传输。
mode-set-recv: A subset of EVRC-WB modes. Possible values are a comma-separated list of modes from the set {0,4,7} (see Table 2.5.1.2-1 in 3GPP2 C.S0014-C). 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 the support for wideband fixed rate (full or half rate, depending on the value of the 'fixedrate' parameter). A value of 4 signals narrowband fixed full rate. A value of 7 signals narrowband fixed half rate. Absence of this parameter signals mode 0.
模式集recv：EVRC-WB模式的子集。可能的值是集合{0,4,7}中以逗号分隔的模式列表（参见3GPP2 C.S0014-C中的表2.5.1.2-1）。解码器可以使用此属性通知编码器其在指定模式子集中操作的偏好。值为0表示支持宽带固定速率（全速率或半速率，取决于“fixedrate”参数的值）。值为4的信号窄带固定全速率。值为7的信号窄带固定半速率。缺少此参数表示模式0。
sendmode: A mode of the EVRC-WB codec. An encoder can use this to signal its current mode of operation. Possible values are 0,4,7 (see Table 2.5.1.2-1 in 3GPP2 C.S0014-C). 'sendmode' with value 0 signals wideband fixed-rate operation (full or half rate, depending on the value of the 'fixedrate' parameter). 'sendmode' with value 4 signals narrowband fixed full-rate operation. 'sendmode' with value 7 signals narrowband fixed half-rate operation. The 'fixedrate' parameter MUST NOT be present when the 'sendmode' value is 4 or 7. Absence of this parameter signals mode 0.
sendmode：EVRC-WB编解码器的一种模式。编码器可以使用该信号来表示其当前操作模式。可能的值为0,4,7（参见3GPP2 C.S0014-C中的表2.5.1.2-1）。'值为0的sendmode'表示宽带固定速率操作（全速率或半速率，取决于'fixedrate'参数的值）。'sendmode‘值为4的信号为窄带固定全速运行。’值为7的sendmode'信号为窄带固定半速率操作。当“sendmode”值为4或7时，“fixedrate”参数不得存在。缺少此参数表示模式0。
ptime: See RFC 4566.
ptime：见RFC 4566。
maxptime: See RFC 4566.
最大时间：见RFC 4566。
fixedrate: Indicates the EVRC-WB 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-WB速率。有效值包括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 4288, Section 4.8) and is defined for transfer of EVRC-WB encoded data via RTP using the compact bundle packet format specified in RFC 4788.
该媒体类型为帧二进制数据（见RFC 4288，第4.8节），定义用于使用RFC 4788中规定的紧凑捆绑包格式，通过RTP传输EVRC-WB编码数据。
Security considerations: See Section 18 of RFC 5188.
安全注意事项：见RFC 5188第18节。
Interoperability considerations: None
互操作性注意事项：无
Published specification:
已发布的规范：
The EVRC-WB vocoder is specified in 3GPP2 C.S0014-C. The transfer method with the compact bundled packet format via RTP is specified in RFC 4788 and RFC 5188.
3GPP2 C.S0014-C中规定了EVRC-WB声码器。RFC 4788和RFC 5188中规定了通过RTP的紧凑捆绑包格式的传输方法。
3GPP2 C.S0050-B, 3GPP2 File Formats for Multimedia Services.
3GPP2 C.S0050-B，用于多媒体服务的3GPP2文件格式。
3GPP2 specifications are publicly accessible at http://www.3gpp2.org
3GPP2 specifications are publicly accessible at http://www.3gpp2.org
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:
联系人和电子邮件地址，以获取更多信息：
Harikishan Desineni <hd@qualcomm.com>
Harikishan Desineni <hd@qualcomm.com>
Intended usage: COMMON
预期用途：普通
Restrictions on usage:
使用限制：
This media type depends on RTP framing and hence is only defined for transfer via RTP [6]; 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 using the file format defined in Section 8 of RFC 5188; instead, audio/EVRCWB SHALL be used.
此媒体类型取决于RTP帧，因此仅定义为通过RTP传输[6]；应使用RFC 4788第4节中规定的RTP有效载荷格式。该媒体类型不得用于使用RFC 5188第8节中定义的文件格式进行存储或文件传输；相反，应使用音频/EVRCWB。
Author:
作者：
Harikishan Desineni
哈里基尚·德西尼尼
Change controller:
更改控制器：
IETF Audio/Video Transport working group delegated from the IESG.
IESG授权的IETF音频/视频传输工作组。
Type name: audio
类型名称：音频
Subtype name: EVRCB
子类型名称：EVRCB
Required parameters: None
所需参数：无
Optional parameters:
可选参数：
These parameters apply to RTP transfer only.
这些参数仅适用于RTP传输。
recvmode: A mode of the EVRC-B codec. A decoder can use this attribute to inform an encoder of its preference to operate in a specified mode. Possible values are 0..7 (see the encoder operating point column in Table 2-6 of 3GPP2 C.S0014-B).
recvmode：EVRC-B编解码器的一种模式。解码器可以使用此属性通知编码器其在指定模式下操作的偏好。可能的值为0..7（参见3GPP2 C.S0014-B表2-6中的编码器工作点列）。
sendmode: A mode of the EVRC-B codec. An encoder can use this to signal its current mode of operation. Possible values are 0..7 (see encoder operating point column in Table 2-6 of 3GPP2 C.S0014-B).
sendmode：EVRC-B编解码器的一种模式。编码器可以使用该信号来表示其当前操作模式。可能的值为0..7（参见3GPP2 C.S0014-B表2-6中的编码器工作点列）。
ptime: See RFC 4566.
ptime：见RFC 4566。
maxptime: See RFC 4566.
最大时间：见RFC 4566。
maxinterleave: Maximum number for interleaving length (field LLL in the Interleaving Octet). 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）。整个会话中使用的交织长度不得超过此最大值。如果未发出信号，则maxinterleave长度必须为5。
silencesupp: See Section 6.1 of RFC 4788 for a definition. If this parameter is not present, the default value 1 MUST be assumed.
消声抑制：有关定义，请参见RFC 4788第6.1节。如果此参数不存在，则必须假定默认值1。
dtxmax: See Section 6.1 of RFC 4788.
dtxmax：见RFC 4788第6.1节。
dtxmin: See Section 6.1 of RFC 4788.
dtxmin：见RFC 4788第6.1节。
hangover: See Section 6.1 of RFC 4788.
宿醉：见RFC 4788第6.1节。
Encoding considerations:
编码注意事项：
This media type is framed binary data (see RFC 4288, Section 4.8) and is defined for transfer of EVRC-B encoded data via RTP using the interleaved/bundled packet format specified in RFC 3558.
该媒体类型为帧二进制数据（见RFC 4288，第4.8节），定义用于使用RFC 3558中规定的交织/捆绑包格式通过RTP传输EVRC-B编码数据。
Security considerations: See Section 9 of RFC 4788.
安全注意事项：见RFC 4788第9节。
Interoperability considerations: None
互操作性注意事项：无
Published specification:
已发布的规范：
The EVRC-B vocoder is specified in 3GPP2 C.S0014-B. The transfer method with the interleaved/bundled packet format via RTP is specified in RFC 3558, RFC 4788, and RFC 5188.
3GPP2 C.S0014-B中规定了EVRC-B声码器。RFC 3558、RFC 4788和RFC 5188中规定了通过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: The following information applies for the storage format only.
附加信息：以下信息仅适用于存储格式。
Magic number: #!EVRC-B\n (see Section 5 of RFC 4788)
Magic number: #!EVRC-B\n (see Section 5 of RFC 4788)
File extensions: evb, EVB
文件扩展名：evb，evb
Macintosh file type code: None
Macintosh文件类型代码：无
Object identifier or OID: None
对象标识符或OID:无
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Harikishan Desineni <hd@qualcomm.com>
Harikishan Desineni <hd@qualcomm.com>
Intended usage: COMMON
预期用途：普通
Restrictions on usage:
使用限制：
When this media type is used in the context of transfer over RTP, the RTP payload format specified in Section 4.1 of RFC 3558 SHALL be used. In all other contexts, the file format defined in Section 5 of RFC 4788 SHALL be used.
当在RTP传输环境中使用该媒体类型时，应使用RFC 3558第4.1节中规定的RTP有效载荷格式。在所有其他情况下，应使用RFC 4788第5节中定义的文件格式。
Author:
作者：
Qiaobing Xie / Harikishan Desineni
谢乔冰/哈里基尚·德斯内尼
Change controller:
更改控制器：
IETF Audio/Video Transport working group delegated from the IESG.
IESG授权的IETF音频/视频传输工作组。
Type name: audio
类型名称：音频
Subtype name: EVRCB0
子类型名称：EVRCB0
Required parameters: None
所需参数：无
Optional parameters:
可选参数：
These parameters apply to RTP transfer only.
这些参数仅适用于RTP传输。
recvmode: A mode of the EVRC-B codec. A decoder can use this attribute to inform an encoder of its preference to operate in a specified mode. Possible values are 0..7 (see the encoder operating point column in Table 2-6 of 3GPP2 C.S0014-B).
recvmode：EVRC-B编解码器的一种模式。解码器可以使用此属性通知编码器其在指定模式下操作的偏好。可能的值为0..7（参见3GPP2 C.S0014-B表2-6中的编码器工作点列）。
sendmode: A mode of the EVRC-B codec. An encoder can use this to signal its current mode of operation. Possible values are 0..7 (see the encoder operating point column in Table 2-6 of 3GPP2 C.S0014-B).
sendmode：EVRC-B编解码器的一种模式。编码器可以使用该信号来表示其当前操作模式。可能的值为0..7（参见3GPP2 C.S0014-B表2-6中的编码器工作点列）。
silencesupp: See Section 6.1 of RFC 4788 for a definition. If this parameter is not present, the default value 1 MUST be assumed.
消声抑制：有关定义，请参见RFC 4788第6.1节。如果此参数不存在，则必须假定默认值1。
dtxmax: see Section 6.1 of RFC 4788.
dtxmax：见RFC 4788第6.1节。
dtxmin: see Section 6.1 of RFC 4788.
dtxmin：见RFC 4788第6.1节。
hangover: see Section 6.1 of RFC 4788.
宿醉：见RFC 4788第6.1节。
Encoding considerations:
编码注意事项：
This media type is framed binary data (see RFC 4288, Section 4.8) and is defined for transfer of EVRC-B encoded data via RTP using the header-free packet format specified in RFC 3558.
该媒体类型为帧二进制数据（见RFC 4288，第4.8节），定义用于使用RFC 3558中规定的无报头数据包格式，通过RTP传输EVRC-B编码数据。
Security considerations: See Section 9 of RFC 4788.
安全注意事项：见RFC 4788第9节。
Interoperability considerations: None
互操作性注意事项：无
Published specification:
已发布的规范：
The EVRC-B vocoder is specified in 3GPP2 C.S0014-B. The transfer method with the header-free packet format via RTP is specified in RFC 3558, RFC 4788, and RFC 5188.
3GPP2 C.S0014-B中规定了EVRC-B声码器。RFC 3558、RFC 4788和RFC 5188中规定了通过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:
联系人和电子邮件地址，以获取更多信息：
Harikishan Desineni <hd@qualcomm.com>
Harikishan Desineni <hd@qualcomm.com>
Intended usage: COMMON
预期用途：普通
Restrictions on usage:
使用限制：
When this media type is used in the context of transfer over RTP, the RTP payload format specified in Section 4.2 of RFC 3558 SHALL be used.
当该媒体类型用于RTP传输时，应使用RFC 3558第4.2节中规定的RTP有效载荷格式。
This media type depends on RTP framing and hence is only defined for transfer via RTP [6]; the RTP payload format specified in Section 4.2 of RFC 3558 SHALL be used. This media type SHALL NOT be used for storage or file transfer using the file format defined in Section 5 of RFC 4788; instead, audio/EVRCB SHALL be used.
此媒体类型取决于RTP帧，因此仅定义为通过RTP传输[6]；应使用RFC 3558第4.2节中规定的RTP有效载荷格式。该媒体类型不得用于使用RFC 4788第5节中定义的文件格式进行存储或文件传输；相反，应使用音频/EVRCB。
Author:
作者：
Qiaobing Xie / Harikishan Desineni
谢乔冰/哈里基尚·德斯内尼
Change controller:
更改控制器：
IETF Audio/Video Transport working group delegated from the IESG.
IESG授权的IETF音频/视频传输工作组。
'sendmode' can be used by a sender (EVRC-WB or EVRC-B) to announce its encoder's current mode of operation. A sender can change its mode anytime, and this does not cause any decoding problems at the receiver.
发送方（EVRC-WB或EVRC-B）可以使用“sendmode”来宣布其编码器的当前操作模式。发送方可以随时更改其模式，这不会在接收方造成任何解码问题。
'recvmode' is defined for use with EVRC-B. A decoder can use this attribute to inform an encoder of its preference to operate in a specified mode. The receiver will continue to decode properly even if the sender does not operate in the preferred mode.
“recvmode”定义用于EVRC-B。解码器可以使用此属性通知编码器其在指定模式下的操作偏好。即使发送方未在首选模式下工作，接收方仍将继续正确解码。
'mode-set-recv' is defined for use with EVRC-WB. A decoder can use this attribute to inform an encoder of its preference to operate in a specified subset of modes. The receiver will continue to decode properly even if the sender does not operate in one of the preferred modes. A set has been defined so that several modes can be expressed as a preference in one attempt. For instance, the set {4,7} signals that the receiver prefers the sender to operate in narrowband modes of EVRC-WB.
“模式集recv”定义用于EVRC-WB。解码器可以使用此属性通知编码器其在指定模式子集中操作的偏好。即使发送方未在其中一种首选模式下工作，接收方也将继续正确解码。定义了一个集合，以便在一次尝试中可以将多个模式表示为首选项。例如，集合{4,7}表示接收器希望发送器在EVRC-WB的窄带模式下工作。
This document adds new optional parameters "recvmode" and "sendmode" to the original EVRC-B media types "audio/EVRCB" and "audio/EVRCB0" defined in RFC 4788 [3]. Existing RFC 4788 [3] implementations will not send these parameters in the Session Description Protocol (SDP) and will ignore them if they are received. This will allow
本文件将新的可选参数“recvmode”和“sendmode”添加到RFC 4788[3]中定义的原始EVRC-B媒体类型“audio/EVRCB”和“audio/EVRCB0”中。现有RFC 4788[3]实现不会在会话描述协议（SDP）中发送这些参数，如果收到这些参数，将忽略它们。这将允许
interoperability between RFC 4788 [3] and RFC 5188 implementations of EVRC-B. For an example offer-and-answer exchange, see Section 17.
EVRC-B的RFC 4788[3]和RFC 5188实现之间的互操作性。有关提供和应答交换的示例，请参见第17节。
Information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [8], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing EVRC-WB encoded speech, the mapping is as follows.
媒体类型规范中包含的信息与会话描述协议（SDP）[8]中的字段具有特定映射，该协议通常用于描述RTP会话。当SDP用于指定使用EVRC-WB编码语音的会话时，映射如下所示。
o The media type ("audio") goes in SDP "m=" as the media name.
o 媒体类型（“音频”）以SDP“m=”作为媒体名称。
o The media subtype ("EVRCWB", "EVRCWB0", or "EVRCWB1") goes in SDP "a=rtpmap" as the encoding name.
o 媒体子类型（“EVRCWB”、“EVRCWB0”或“EVRCWB1”）以SDP“a=rtpmap”作为编码名称。
o The optional parameters 'ptime' and 'maxptime' (for subtypes EVRCWB, EVRCWB1) go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
o 可选参数“ptime”和“maxptime”（对于子类型EVRCWB，EVRCWB1）分别位于SDP“a=ptime”和“a=maxptime”属性中。
o Any remaining parameters (for subtypes EVRCWB, EVRCWB0, and EVRCWB1) 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 任何剩余的参数（对于子类型EVRCWB、EVRCWB0和EVRCWB1）都将从媒体类型字符串中复制为参数=值对的分号分隔列表，从而进入SDP“a=fmtp”属性。
The new optional parameters 'recvmode' and 'sendmode' (for 'audio' subtypes EVRCB and EVRCB0) go in the SDP "a=fmtp" attribute by copying them directly from the media type string.
新的可选参数“recvmode”和“sendmode”（用于“audio”子类型EVRCB和EVRCB0）通过直接从媒体类型字符串复制而进入SDP“a=fmtp”属性。
For all other media type parameters, the specification in Section 6.7 of RFC 4788 [3] still applies.
对于所有其他介质类型参数，RFC 4788[3]第6.7节中的规范仍然适用。
The following considerations apply when using the SDP offer-answer procedures of RFC 3264 [7] to negotiate the use of EVRC-WB payload in RTP:
当使用RFC 3264[7]的SDP报价-应答程序来协商RTP中EVRC-WB有效载荷的使用时，以下注意事项适用：
o Since EVRC-WB is an extension of EVRC-B, the offerer SHOULD announce EVRC-B support in its "m=audio" line, with EVRC-WB as the preferred codec. This will allow interoperability with an answerer that supports only EVRC-B.
o 由于EVRC-WB是EVRC-B的扩展，报价人应在其“m=音频”行中宣布对EVRC-B的支持，EVRC-WB是首选编解码器。这将允许与仅支持EVRC-B的应答者进行互操作。
Below is an example of such an offer:
以下是此类报价的一个示例：
m=audio 55954 RTP/AVP 98 99
a=rtpmap:98 EVRCWB0/16000
a=rtpmap:99 EVRCB0/8000
a=fmtp:98 mode-set-recv=0,4;sendmode=0
a=fmtp:99 recvmode=0 sendmode=4
m=audio 55954 RTP/AVP 98 99
a=rtpmap:98 EVRCWB0/16000
a=rtpmap:99 EVRCB0/8000
a=fmtp:98 mode-set-recv=0,4;sendmode=0
a=fmtp:99 recvmode=0 sendmode=4
If the answerer supports EVRC-WB, then the answerer can keep the payload type 98 in its answer and the conversation can be done using EVRC-WB. Else, if the answerer supports only EVRC-B, then the answerer will leave only the payload type 99 in its answer and the conversation will be done using EVRC-B.
如果回答者支持EVRC-WB，那么回答者可以在其回答中保留有效负载类型98，并且可以使用EVRC-WB完成对话。否则，如果应答者仅支持EVRC-B，则应答者将在其应答中仅保留有效负载类型99，并且将使用EVRC-B完成对话。
An example answer for the above offer is the following:
上述报价的示例答案如下：
m=audio 55954 RTP/AVP 98
a=rtpmap:98 EVRCWB0/16000
a=fmtp:98 mode-set-recv=4;sendmode=4
m=audio 55954 RTP/AVP 98
a=rtpmap:98 EVRCWB0/16000
a=fmtp:98 mode-set-recv=4;sendmode=4
o 'mode-set-recv' is a unidirectional receive-only parameter.
o “模式设置recv”是一个单向仅接收参数。
o 'sendmode' is a unidirectional send-only parameter.
o “sendmode”是一个单向仅发送参数。
o Using 'sendmode', a sender can signal its current mode of operation. Note that a receiver may receive RTP media well before the arrival of SDP with a (first-time, or updated) 'sendmode' parameter.
o 使用“sendmode”，发送器可以发出当前操作模式的信号。请注意，接收器可能在SDP到达之前接收RTP介质，并带有（首次或更新的）“sendmode”参数。
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.
o 报价人可以使用“模式设置recv”请求将远程发送方的编码器限制在“模式设置recv”中发出信号的模式列表内。远程发送方可能会忽略“模式设置recv”请求。
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 [7]. The 'maxptime' parameter MUST be handled in the same way.
o 参数“maxptime”和“ptime”在大多数情况下不会影响互操作性；但是，参数的设置可能会影响应用程序的性能。RFC 3264[7]中描述了“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 For a recvonly stream, the 'sendmode' parameter is not useful and SHOULD NOT be used.
o 对于recvonly流，“sendmode”参数无效，不应使用。
o When using EVRCWB1, the entire session MUST use the same fixed rate and mode (0-Wideband or 4,7-Narrowband).
o 使用EVRCWB1时，整个会话必须使用相同的固定速率和模式（0-宽带或4,7-窄带）。
o For additional rules that MUST be followed while negotiating DTX parameters, see Section 6.8 in [3].
o 有关协商DTX参数时必须遵守的其他规则，请参见[3]中的第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应答中。
See Section 6.8 of [3] for offer-answer usage of EVRC-B. The following are several additional considerations for EVRC-B.
有关EVRC-B的报价-应答用法，请参见[3]第6.8节。以下是EVRC-B的几个额外注意事项。
o 'recvmode' is a unidirectional receive-only parameter.
o “recvmode”是一个单向仅接收参数。
o 'sendmode' is a unidirectional send-only parameter.
o “sendmode”是一个单向仅发送参数。
o Using 'recvmode', a receiver can signal the remote sender to operate its encoder in the specified mode. A remote sender MAY ignore 'recvmode' requests.
o 使用“recvmode”，接收器可以向远程发送器发送信号，使其在指定模式下运行编码器。远程发件人可能会忽略“recvmode”请求。
o Using 'sendmode', a sender can signal its current mode of operation. Note that a receiver may receive RTP media well before the arrival of SDP with a (first-time, or updated) 'sendmode' parameter.
o 使用“sendmode”，发送器可以发出当前操作模式的信号。请注意，接收器可能在SDP到达之前接收RTP介质，并带有（首次或更新的）“sendmode”参数。
o For a sendonly stream, the 'recvmode' parameter is not useful and SHOULD NOT be used.
o 对于仅发送的流，“recvmode”参数无效，不应使用。
o For a recvonly stream, the 'sendmode' parameter is not useful and SHOULD NOT be used.
o 对于recvonly流，“sendmode”参数无效，不应使用。
For declarative use of SDP in the Session Announcement Protocol (SAP) [12] and the Real Time Streaming Protocol (RTSP) [13], the following considerations apply:
对于会话公告协议（SAP）[12]和实时流协议（RTSP）[13]中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 17.
o 有效负载格式配置参数都是声明性的，参与者必须使用为会话提供的配置。如有必要，可通过声明多个RTP有效负载类型来提供多个配置；但是，类型的数量应保持在较小的范围内。有关声明性示例，请参见第17节。
Some example SDP session descriptions utilizing EVRC-WB and EVRC-B 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-WB和EVRC-B编码的一些示例SDP会话描述。在这些示例中，长a=fmtp行被折叠以满足本文档的列宽约束。应忽略行尾的反斜杠（\）和其后的回车符。请注意，媒体子类型名称不区分大小写。参数名称在媒体类型和到SDP a=fmtp属性的映射中都不区分大小写。
Example usage of EVRCWB:
EVRCWB的使用示例：
m=audio 49120 RTP/AVP 97 98
a=rtpmap:97 EVRCWB/16000
a=rtpmap:98 EVRCB0/8000
a=fmtp:97 mode-set-recv=0,4;sendmode=0
a=fmtp:98 recvmode=0 sendmode=0
a=maxptime:120
m=audio 49120 RTP/AVP 97 98
a=rtpmap:97 EVRCWB/16000
a=rtpmap:98 EVRCB0/8000
a=fmtp:97 mode-set-recv=0,4;sendmode=0
a=fmtp:98 recvmode=0 sendmode=0
a=maxptime:120
Example usage of EVRCWB0:
EVRCWB0的示例用法：
m=audio 49120 RTP/AVP 97 98
a=rtpmap:97 EVRCWB0/16000
a=rtpmap:98 EVRCB0/8000
a=fmtp:97 mode-set-recv=0,4;sendmode=0
a=fmtp:98 recvmode=0 sendmode=0
m=audio 49120 RTP/AVP 97 98
a=rtpmap:97 EVRCWB0/16000
a=rtpmap:98 EVRCB0/8000
a=fmtp:97 mode-set-recv=0,4;sendmode=0
a=fmtp:98 recvmode=0 sendmode=0
Example SDP answer from a media gateway requesting a terminal to limit its encoder operation to EVRC-WB mode 4:
来自媒体网关的SDP应答示例，请求终端将其编码器操作限制为EVRC-WB模式4：
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCWB0/16000
a=fmtp:97 mode-set-recv=4;sendmode=4
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCWB0/16000
a=fmtp:97 mode-set-recv=4;sendmode=4
Example usage of EVRCWB1:
EVRCWB1的示例用法：
m=audio 49120 RTP/AVP 97 98
a=rtpmap:97 EVRCWB1/16000
a=fmtp:97 mode-set-recv=4;sendmode=4
a=maxptime:100
m=audio 49120 RTP/AVP 97 98
a=rtpmap:97 EVRCWB1/16000
a=fmtp:97 mode-set-recv=4;sendmode=4
a=maxptime:100
Example usage of EVRCWB with DTX with silencesupp=1:
带DTX的EVRCWB的示例用法，静音SUPP=1：
m=audio 49120 RTP/AVP 97 98
a=rtpmap:97 EVRCWB/16000
a=rtpmap:98 EVRCB0/8000
a=fmtp:97 silencesupp=1;dtxmax=32;dtxmin=12;hangover=1 \
mode-set-recv=0,4; sendmode=0
a=fmtp:98 recvmode=0 sendmode=0
a=maxptime:120
m=audio 49120 RTP/AVP 97 98
a=rtpmap:97 EVRCWB/16000
a=rtpmap:98 EVRCB0/8000
a=fmtp:97 silencesupp=1;dtxmax=32;dtxmin=12;hangover=1 \
mode-set-recv=0,4; sendmode=0
a=fmtp:98 recvmode=0 sendmode=0
a=maxptime:120
Example usage of EVRCWB with DTX with silencesupp=0:
带DTX的EVRCWB的示例用法，静音SUPP=0：
m=audio 49120 RTP/AVP 97 98
a=rtpmap:97 EVRCWB/16000
a=rtpmap:98 EVRCB0/8000
a=fmtp:97 silencesupp=0;dtxmax=32;dtxmin=12;hangover=1 \
mode-set-recv=0,4;sendmode=0
a=fmtp:98 recvmode=0 sendmode=0
a=maxptime:120
m=audio 49120 RTP/AVP 97 98
a=rtpmap:97 EVRCWB/16000
a=rtpmap:98 EVRCB0/8000
a=fmtp:97 silencesupp=0;dtxmax=32;dtxmin=12;hangover=1 \
mode-set-recv=0,4;sendmode=0
a=fmtp:98 recvmode=0 sendmode=0
a=maxptime:120
Example usage of EVRCB:
EVRCB的使用示例：
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCB/8000
a=fmtp:97 recvmode=0 sendmode=4
a=maxptime:120
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCB/8000
a=fmtp:97 recvmode=0 sendmode=4
a=maxptime:120
Example usage of EVRCB0:
EVRCB0的示例用法：
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCB0/8000
a=fmtp:97 recvmode=0 sendmode=4
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCB0/8000
a=fmtp:97 recvmode=0 sendmode=4
Example offer-answer exchange between EVRC-WB and legacy EVRC-B (RFC 4788):
EVRC-WB和旧版EVRC-B（RFC 4788）之间的报价-应答交换示例：
Offer:
报价：
m=audio 55954 RTP/AVP 98 99
a=rtpmap:98 EVRCWB0/16000
a=rtpmap:99 EVRCB0/8000
a=fmtp:98 mode-set-recv=0,4;sendmode=0
a=fmtp:99 recvmode=0 sendmode=0
m=audio 55954 RTP/AVP 98 99
a=rtpmap:98 EVRCWB0/16000
a=rtpmap:99 EVRCB0/8000
a=fmtp:98 mode-set-recv=0,4;sendmode=0
a=fmtp:99 recvmode=0 sendmode=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-WB and updated EVRC-B (RFC 5188):
EVRC-WB和更新后的EVRC-B（RFC 5188）之间的报价-应答交换示例：
Offer:
报价：
m=audio 55954 RTP/AVP 98 99
a=rtpmap:98 EVRCWB0/16000
a=rtpmap:99 EVRCB0/8000
a=fmtp:98 mode-set-recv=0,4; sendmode=0
a=fmtp:99 recvmode=0 sendmode=0
m=audio 55954 RTP/AVP 98 99
a=rtpmap:98 EVRCWB0/16000
a=rtpmap:99 EVRCB0/8000
a=fmtp:98 mode-set-recv=0,4; sendmode=0
a=fmtp:99 recvmode=0 sendmode=0
Answer:
答复:
m=audio 55954 RTP/AVP 99
a=rtpmap:99 EVRCB0/8000
a=fmtp:99 recvmode=0 sendmode=4
m=audio 55954 RTP/AVP 99
a=rtpmap:99 EVRCB0/8000
a=fmtp:99 recvmode=0 sendmode=4
In the above example, note that the answerer has chosen to send in mode 4 even though the offerer was willing to receive in mode 0. 'recvmode' is a receiver's preference, but the sender can send in a different mode.
在上述示例中，请注意，即使报价人愿意在模式0下接收，应答人仍选择在模式4下发送。”recvmode'是接收者的首选项，但发送者可以以不同的模式发送。
Example offer-answer exchanges for interoperability between legacy (RFC 4788) and updated EVRC-B (RFC 5188) implementations:
示例提供了旧版（RFC 4788）和更新版EVRC-B（RFC 5188）实现之间互操作性的答案交换：
Offer from an offerer that supports updated EVRC-B (RFC 5188) implementation:
支持更新版EVRC-B（RFC 5188）实施的报价人的报价：
m=audio 55954 RTP/AVP 99
a=rtpmap:99 EVRCB0/8000
a=fmtp:99 recvmode=0 sendmode=4
m=audio 55954 RTP/AVP 99
a=rtpmap:99 EVRCB0/8000
a=fmtp:99 recvmode=0 sendmode=4
Answer from an answerer that supports only legacy EVRC-B (RFC 4788) implementation:
仅支持传统EVRC-B（RFC 4788）实现的应答者的回答：
m=audio 55954 RTP/AVP 99
a=rtpmap:99 EVRCB0/8000
m=audio 55954 RTP/AVP 99
a=rtpmap:99 EVRCB0/8000
Offer from an offerer that supports only legacy EVRC-B (RFC 4788) implementation:
仅支持传统EVRC-B（RFC 4788）实施的报价人提供的报价：
m=audio 55954 RTP/AVP 99
a=rtpmap:99 EVRCB0/8000
m=audio 55954 RTP/AVP 99
a=rtpmap:99 EVRCB0/8000
Answer from an answerer that supports updated EVRC-B (RFC 5188) implementation:
来自支持更新版EVRC-B（RFC 5188）实施的应答者的回答：
m=audio 55954 RTP/AVP 99
a=rtpmap:99 EVRCB0/8000
a=fmtp:99 recvmode=0 sendmode=4
m=audio 55954 RTP/AVP 99
a=rtpmap:99 EVRCB0/8000
a=fmtp:99 recvmode=0 sendmode=4
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 [2]. Implementations using the payload defined in this specification are subject to the security considerations discussed in RFC 3558 [2], RFC 3550 [6], and any appropriate profile (for example, RFC 3551 [11]).
由于压缩是端到端地应用于有效负载格式的，并且编码没有表现出显著的不一致性，因此本规范的实现受到RFC 3558[2]中规定的所有安全考虑的约束。使用本规范中定义的有效负载的实现受RFC 3558[2]、RFC 3550[6]和任何适当配置文件（例如RFC 3551[11]）中讨论的安全注意事项的约束。
This document updates RFC 4788 [3], and the updates are summarized below:
本文件更新了RFC 4788[3]，更新内容总结如下：
o Added new media type attribute "sendmode" to media subtypes EVRCB and EVRCB0. This attribute can be used to signal the EVRC-B encoder's current mode of operation.
o 向媒体子类型EVRCB和EVRCB0添加了新的媒体类型属性“sendmode”。该属性可用于向EVRC-B编码器的当前操作模式发送信号。
o Added new media type attribute "recvmode" to media subtypes EVRCB and EVRCB0. This attribute can be used to signal the EVRC-B decoder's preferred operating mode to a remote sender.
o 向媒体子类型EVRCB和EVRCB0添加了新的媒体类型属性“recvmode”。该属性可用于向远程发送方发送EVRC-B解码器首选操作模式的信号。
[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] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, July 2003.
[2] 李安，“增强型变速率编解码器（EVRC）和可选模式声码器（SMV）的RTP有效载荷格式”，RFC3558，2003年7月。
[3] Xie, Q. and R. Kapoor, "Enhancements to RTP Payload Formats for EVRC Family Codecs", RFC 4788, January 2007.
[3] Xie，Q.和R.Kapoor，“EVRC系列编解码器RTP有效载荷格式的增强”，RFC 4788，2007年1月。
[4] "Enhanced Variable Rate Codec, Speech Service Option 3 and 68 for Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014-B v1.0 , May 2006.
[4] “用于宽带扩频数字系统的增强型变速率编解码器，语音服务选项3和68”，3GPP2 C.S0014-B v1.0，2006年5月。
[5] "Enhanced Variable Rate Codec, Speech Service Option 3,68 and 70 for Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014-C v1.0 , October 2006.
[5] “用于宽带扩频数字系统的增强型变速率编解码器、语音服务选项3、68和70”，3GPP2 C.S0014-C v1.0，2006年10月。
[6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, March 1997.
[6] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35501997年3月。
[7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[7] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[8] Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[9] Casner, S., "Media Type Specifications and Registration Procedures", RFC 4855, February 2007.
[9] Casner，S.，“媒体类型规范和注册程序”，RFC 4855，2007年2月。
[10] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[10] Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[11] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[11] Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[12] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[12] Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 29742000年10月。
[13] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[13] Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
Authors' Addresses
作者地址
Harikishan Desineni Qualcomm 5775 Morehouse Drive San Diego, CA 92126 USA
美国加利福尼亚州圣地亚哥莫尔豪斯大道5775号高通公司
Phone: +1 858 845 8996
EMail: hd@qualcomm.com
URI: http://www.qualcomm.com
Phone: +1 858 845 8996
EMail: hd@qualcomm.com
URI: http://www.qualcomm.com
Qiaobing Xie Motorola 1501 W. Shure Drive, 2-F9 Arlington Heights, IL 60004 USA
美国伊利诺伊州阿灵顿高地2-F9舒尔大道西1501号乔平谢摩托罗拉60004
Phone: +1-847-372-8481
EMail: Qiaobing.Xie@Gmail.com
URI: http://www.motorola.com
Phone: +1-847-372-8481
EMail: Qiaobing.Xie@Gmail.com
URI: http://www.motorola.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.