Network Working Group Q. Xie
Request for Comments: 4788 Motorola
Updates: 3558 R. Kapoor
Category: Standards Track Qualcomm
January 2007
Network Working Group Q. Xie
Request for Comments: 4788 Motorola
Updates: 3558 R. Kapoor
Category: Standards Track Qualcomm
January 2007
Enhancements to RTP Payload Formats for EVRC Family Codecs
EVRC系列编解码器RTP有效负载格式的增强
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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document updates the Enhanced Variable Rate Codec (EVRC) RTP payload formats defined in RFC 3558 with several enhancements and extensions. In particular, it defines support for the header-free and interleaved/bundled packet formats for the EVRC-B codec, a new compact bundled format for the EVRC and EVRC-B codecs, as well as discontinuous transmission (DTX) support for EVRC and EVRC-B-encoded speech transported via RTP. Voice over IP (VoIP) applications operating over low bandwidth dial-up and wireless networks require such enhancements for efficient use of the bandwidth.
本文档更新了RFC 3558中定义的增强型可变速率编解码器（EVRC）RTP有效负载格式，并提供了一些增强和扩展。特别是，它定义了对EVRC-B编解码器的无报头和交织/捆绑包格式的支持，对EVRC和EVRC-B编解码器的新的紧凑捆绑格式，以及对通过RTP传输的EVRC和EVRC-B编码语音的不连续传输（DTX）支持。在低带宽拨号和无线网络上运行的IP语音（VoIP）应用程序需要此类增强功能，以有效利用带宽。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Support of EVRC-B Codec . . . . . . . . . . . . . . . . . 3
1.2. Compact (Header-free) Bundled Format . . . . . . . . . . . 3
1.3. Discontinuous Transmission (DTX) . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. EVRC-B Codec . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Compact Bundled Format . . . . . . . . . . . . . . . . . . . . 5
4.1. Single-Rate Operation . . . . . . . . . . . . . . . . . . 5
5. Storage Format for EVRC-B Codec . . . . . . . . . . . . . . . 6
6. Media Type Definitions . . . . . . . . . . . . . . . . . . . . 6
6.1. Registration of Media Type EVRC1 . . . . . . . . . . . . . 6
6.2. Registration of Media Type EVRCB . . . . . . . . . . . . . 9
6.3. Registration of Media Type EVRCB0 . . . . . . . . . . . . 11
6.4. Registration of Media Type EVRCB1 . . . . . . . . . . . . 12
6.5. Updated Registration of Media Type EVRC . . . . . . . . . 13
6.6. Updated Registration of Media Type EVRC0 . . . . . . . . . 15
6.7. Mapping MIME Parameters into SDP . . . . . . . . . . . . . 17
6.8. Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 18
7. Backward Compatibility with RFC 3558 . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Support of EVRC-B Codec . . . . . . . . . . . . . . . . . 3
1.2. Compact (Header-free) Bundled Format . . . . . . . . . . . 3
1.3. Discontinuous Transmission (DTX) . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. EVRC-B Codec . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Compact Bundled Format . . . . . . . . . . . . . . . . . . . . 5
4.1. Single-Rate Operation . . . . . . . . . . . . . . . . . . 5
5. Storage Format for EVRC-B Codec . . . . . . . . . . . . . . . 6
6. Media Type Definitions . . . . . . . . . . . . . . . . . . . . 6
6.1. Registration of Media Type EVRC1 . . . . . . . . . . . . . 6
6.2. Registration of Media Type EVRCB . . . . . . . . . . . . . 9
6.3. Registration of Media Type EVRCB0 . . . . . . . . . . . . 11
6.4. Registration of Media Type EVRCB1 . . . . . . . . . . . . 12
6.5. Updated Registration of Media Type EVRC . . . . . . . . . 13
6.6. Updated Registration of Media Type EVRC0 . . . . . . . . . 15
6.7. Mapping MIME Parameters into SDP . . . . . . . . . . . . . 17
6.8. Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 18
7. Backward Compatibility with RFC 3558 . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . . 20
This document defines support for the header-free and interleaved/ bundled packet formats for the EVRC-B codec, a new compact bundled format for the EVRC and EVRC-B codecs, as well as discontinuous transmission (DTX) support for EVRC and EVRC-B-encoded speech transported via RTP. Voice over IP (VoIP) applications operating over low bandwidth dial-up and wireless networks require such EVRC RTP payload capabilities for efficient use of the bandwidth.
本文档定义了对EVRC-B编解码器的无报头和交织/捆绑包格式的支持，对EVRC和EVRC-B编解码器的一种新的紧凑捆绑格式，以及对通过RTP传输的EVRC和EVRC-B编码语音的不连续传输（DTX）支持。在低带宽拨号和无线网络上运行的IP语音（VoIP）应用程序需要这样的EVRC RTP有效负载能力，以便有效利用带宽。
EVRC-B [3] is an extension to EVRC [2] developed in the Third Generation Partnership Project 2 (3GPP2). EVRC-B [3] compresses each 20 milliseconds of 8000Hz, 16-bit sampled speech input into output frames of one of the four different sizes: Rate 1 (171 bits), Rate 1/2 (80 bits), Rate 1/4 (40 bits), or Rate 1/8 (16 bits). In addition, there are two zero-bit codec frame types: null frames and erasure frames, similar to EVRC [2]. One significant enhancement in EVRC-B is the use of 1/4-rate frames that were not used in EVRC. This provides lower average data rates (ADRs) compared to EVRC, for a given voice quality.
EVRC-B[3]是第三代合作伙伴项目2（3GPP2）中开发的EVRC[2]的扩展。EVRC-B[3]将8000Hz、16位采样语音输入的每20毫秒压缩为四种不同大小的输出帧之一：速率1（171位）、速率1/2（80位）、速率1/4（40位）或速率1/8（16位）。此外，还有两种零位编解码器帧类型：空帧和擦除帧，类似于EVRC[2]。EVRC-B中的一个显著增强是使用了EVRC中未使用的1/4速率帧。对于给定的语音质量，与EVRC相比，这提供了更低的平均数据速率（ADR）。
Since speech frames encoded by EVRC-B are different from those encoded by EVRC, EVRC-B and EVRC codecs do not interoperate with each other. At the initiation of an RTP session, the RTP sender and receiver need to indicate (e.g., using MIME subtypes that are separate from those of EVRC) that EVRC-B is to be used for the ensuing session.
由于由EVRC-B编码的语音帧与由EVRC编码的语音帧不同，因此EVRC-B和EVRC编解码器之间不互操作。在RTP会话启动时，RTP发送方和接收方需要指示（例如，使用与EVRC不同的MIME子类型）EVRC-B将用于后续会话。
The current interleaved/bundled packet format defined in RFC 3558 allows bundling of multiple speech frames of different rates in a single RTP packet, sending mode change requests, and interleaving. To support these functions, a Table of Contents (ToC) is used in each RTP packet, in addition to the standard RTP header. The size of the ToC varies depending on the number of EVRC frames carried in the packet [4].
RFC 3558中定义的当前交织/捆绑包格式允许在单个RTP包中捆绑不同速率的多个语音帧、发送模式更改请求和交织。为了支持这些功能，除了标准RTP报头之外，每个RTP数据包中还使用了一个目录（ToC）。ToC的大小取决于包中携带的EVRC帧的数量[4]。
The current header-free packet format defined in RFC 3558 is more compact and optimized for use over wireless links. It eliminates the need for a ToC by requiring that each RTP packet contain only one speech frame (of any allowable rate), i.e., bundling is not allowed. Moreover, interleaving and mode change requests are not supported in the header-free format [4].
RFC3558中定义的当前无报头数据包格式更加紧凑，并针对无线链路的使用进行了优化。它通过要求每个RTP包只包含一个语音帧（任何允许的速率），即不允许捆绑，从而消除了对ToC的需要。此外，无报头格式中不支持交错和模式更改请求[4]。
The compact bundled format described in this document presents the user an alternative to the header-free format defined in RFC 3558. This format allows bundling of multiple EVRC or EVRC-B frames without the addition of extra headers, as would be in the case of the interleaved/bundled format. However, in order to use this compact bundled format, only one EVRC/EVRC-B rate (full rate or 1/2 rate) can be used in the session. Similar to the header-free format defined in RFC 3558, interleaving and mode change requests are not supported in the compact bundled format.
本文档中描述的紧凑捆绑格式为用户提供了RFC 3558中定义的无标题格式的替代方案。这种格式允许捆绑多个EVRC或EVRC-B帧，而无需添加额外的报头，就像交错/捆绑格式一样。但是，为了使用这种紧凑的捆绑格式，会话中只能使用一个EVRC/EVRC-B速率（全速率或1/2速率）。与RFC 3558中定义的无报头格式类似，紧凑捆绑格式中不支持交错和模式更改请求。
Information carried in frames of EVRC and EVRC-B codecs varies little during periods of silence. The transmission of these frames across the radio interface in a wireless system is expensive, in terms of capacity; therefore, suppression of these frames is desirable. Such an operation is called DTX, also known as silence suppression.
在静默期间，EVRC和EVRC-B编解码器的帧中承载的信息变化很小。就容量而言，在无线系统中通过无线电接口传输这些帧是昂贵的；因此，希望抑制这些帧。这种操作称为DTX，也称为静音抑制。
In general, when DTX/silence suppression is applied, the first few frames of silence may be transmitted at the beginning of the period of silence to establish background noise. Then, a portion of the stream of subsequent silence frames is not transmitted, and is discarded at the sender. At the receiver, background or comfort noise may be generated by using the previously received silence frames.
通常，当应用DTX/静默抑制时，可以在静默周期的开始处发送前几个静默帧以建立背景噪声。然后，后续静默帧流的一部分不被发送，并且在发送方处被丢弃。在接收器处，可通过使用先前接收的静音帧来产生背景或舒适噪声。
The full detail of DTX/silence suppression operation can be found in DTX [8] as well as in RFC 3551 [9], and in RFC 3558 [4]. This document only defines the additional optional MIME parameters (silencesupp, dtxmax, dtxmin, and hangover) for setting up a DTX/ silence suppression session, where "silencesupp" is for indicating the capability and willingness of using DTX/silence suppression; "dtxmax" and "dtxmin", for indicating the desired range of DTX update interval; and "hangover", for indicating the desired number of silence frames at the beginning of each silence period to establish background noise at the receiver (see Section 6.1 for detailed definition).
DTX/静音抑制操作的完整细节可在DTX[8]以及RFC 3551[9]和RFC 3558[4]中找到。本文档仅定义用于设置DTX/静默抑制会话的附加可选MIME参数（静默抑制、dtxmax、dtxmin和hangover），其中“静默抑制”用于指示使用DTX/静默抑制的能力和意愿；“dtxmax”和“dtxmin”，用于指示所需的DTX更新间隔范围；以及“残留”，用于指示每个静默周期开始时所需的静默帧数，以在接收器处建立背景噪声（详细定义见第6.1节）。
The EVRC and EVRC-B codecs, in variable-rate operation mode, send 1/8-rate frames during periods of silence, while in single-rate operation mode (see Section 4), silence is encoded and sent in frames of the same rate as that of speech frames. The DTX parameters defined in this document apply to 1/8-rate frames in the variable-rate mode and to silence frames in the single-rate operation mode.
EVRC和EVRC-B编解码器在可变速率操作模式下，在静音期间发送1/8速率的帧，而在单速率操作模式下（参见第4节），静音以与语音帧相同的速率进行编码和发送。本文件中定义的DTX参数适用于可变速率模式下的1/8速率帧和单速率操作模式下的静音帧。
For simplicity, in the rest of this document the term "silence frame" refers either to an 1/8-rate frame in variable-rate operation or a frame that contains only silence in the signal-rate operation.
为简单起见，在本文件的其余部分中，术语“静默帧”指的是可变速率操作中的1/8速率帧或信号速率操作中仅包含静默的帧。
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]中所述进行解释。
Three RTP packet formats are supported for the EVRC-B codec: the interleaved/bundled packet format, the header-free packet format, and the compact bundled packet format. For the interleaved/bundled and header-free packet formats, the operational details and capabilities, such as ToC, interleaving, and bundling, of EVRC-B, are exactly the same as those of EVRC, as defined in RFC 3558 [4], except that the mode change request field in the ToC MUST be interpreted according to the definition of the RATE_REDUC parameter in EVRC-B [3]. The compact bundled packet format for EVRC-B is defined in Section 4 of this document.
EVRC-B编解码器支持三种RTP数据包格式：交织/捆绑数据包格式、无报头数据包格式和紧凑捆绑数据包格式。对于交织/捆绑和无报头数据包格式，EVRC-B的操作细节和功能（如ToC、交织和捆绑）与RFC 3558[4]中定义的EVRC完全相同，但ToC中的模式更改请求字段必须根据EVRC-B[3]中的RATE_Reduce参数定义进行解释。本文件第4节定义了EVRC-B的紧凑捆绑包格式。
A packet in the compact bundled format consists of an RTP header, followed by a sequence of one or more consecutive EVRC/EVRC-B codec data frames of the same rate, as shown below:
紧凑捆绑格式的数据包包括一个RTP报头，后面是一个或多个相同速率的连续EVRC/EVRC-B编解码器数据帧序列，如下所示：
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 [4] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
| One or more EVRC/EVRC-B data frames of same rate |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [4] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
| One or more EVRC/EVRC-B data frames of same rate |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The codec data frames MUST be generated from the output of the codec following the procedure described in Section 5.2 in RFC 3558 [4], and all MUST be of the same rate and size.
编解码器数据帧必须按照RFC 3558[4]第5.2节中描述的程序从编解码器的输出生成，并且所有数据帧的速率和大小必须相同。
As mentioned earlier, in order to use the compact bundled format, all the EVRC/EVRC-B data frames in the session MUST be of the same rate. This packet format may carry only full or half-rate frames.
如前所述，为了使用紧凑的捆绑格式，会话中的所有EVRC/EVRC-B数据帧必须具有相同的速率。此数据包格式只能承载全速率或半速率帧。
For a session that uses the compact bundled format, the rate for the session can be determined during the session setup signaling, for example, via Session Description Protocol (SDP) exchanges. See Section 6 below for more details.
对于使用紧凑捆绑格式的会话，会话的速率可以在会话设置信令期间确定，例如，通过会话描述协议（SDP）交换。更多详情见下文第6节。
The storage format is used for storing EVRC-B-encoded speech frames, e.g., as a file or e-mail attachment.
存储格式用于存储EVRC-B编码的语音帧，例如，作为文件或电子邮件附件。
The file begins with a magic number to identify the vocoder that is used. The magic number for EVRC-B corresponds to the ASCII character string:
该文件以一个幻数开始，以标识所使用的声码器。EVRC-B的幻数对应于ASCII字符串：
"#!EVRC-B\n" (or 0x2321 0x4556 0x5243 0x2d42 0x0a in hexadecimal).
“#！EVRC-B\n”（或十六进制格式的0x2321 0x4556 0x5243 0x2d42 0x0a）。
Note that the "\n" is an important part of both this magic number and the "#!EVRC\n" magic number defined in Section 11 of RFC 3558, and the "\n" MUST be included in any comparison of either magic number, since, otherwise, a prefix of the EVRC-B magic number could be mistaken for the EVRC magic number.
请注意，“\n”是该幻数和RFC 3558第11节中定义的“#！EVRC\n”幻数的重要组成部分，并且“\n”必须包含在任一幻数的任何比较中，否则，EVRC-B幻数的前缀可能会被误认为是EVRC幻数。
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, as defined in Section 5.1 of [4], 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.
编解码器数据帧以连续顺序存储，具有单个ToC输入字段，扩展为一个八位字节，在每个编解码器数据帧前加前缀。[4]第5.1节中定义的ToC字段通过将八位字节的四个最高有效位设置为零扩展到一个八位字节。例如，ToC值4（全速率帧）存储为0x04。
Speech frames lost in transmission and non-received frames MUST be stored as erasure frames to maintain synchronization with the original media.
传输中丢失的语音帧和未接收的帧必须作为擦除帧存储，以保持与原始媒体的同步。
Type name: audio
类型名称：音频
Subtype names: EVRC1
子类型名称：EVRC1
Required parameters: none
所需参数：无
Optional parameters:
可选参数：
ptime: See RFC 4566 [7].
ptime：见RFC 4566[7]。
maxptime: The maximum amount of media that can be encapsulated in each packet, expressed as time in milliseconds. The time MUST be calculated as the sum of the time the media present in the packet represents. The time SHOULD be a multiple of the duration of a single codec data frame (20 msec). If not signaled, the default maxptime value MUST be 200 milliseconds.
maxptime：每个数据包中可以封装的最大媒体量，以毫秒表示。时间必须计算为数据包中存在的媒体所代表的时间之和。时间应该是单个编解码器数据帧持续时间的倍数（20毫秒）。如果未发出信号，则默认maxptime值必须为200毫秒。
fixedrate: Indicates the EVRC 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速率。有效值包括：0.5和1，其中0.5表示1/2速率，而1表示全速率。如果此参数不存在，则假定为1/2速率。
silencesupp: Permissible values are 0 and 1. A value of 1 indicates that the sender of this parameter: a) is capable of receiving silence-suppressed speech using DTX, AND b) is capable of and will send out silence-suppressed speech using DTX, unless the other end indicates that it does not want to receive silence-suppressed speech using DTX.
消声抑制：允许值为0和1。值1表示此参数的发送方：A）能够使用DTX接收静音抑制语音，b）能够并将使用DTX发送静音抑制语音，除非另一端表示不希望使用DTX接收静音抑制语音。
A value of 0 indicates that the sender of this parameter: a) does NOT want to receive silence-suppressed speech using DTX, AND b) will NOT send out silence-suppressed speech using DTX.
值为0表示此参数的发送方：A）不希望使用DTX接收静音抑制语音，b）不使用DTX发送静音抑制语音。
If this parameter is not present, the default value 1 MUST be assumed. If the RTP receiver indicates through the use of SIP signaling or other means that it is incapable of or unwilling to use silence suppression using DTX, silence suppression using DTX as specified in this document MUST NOT be used for the session.
如果此参数不存在，则必须假定默认值1。如果RTP接收器通过使用SIP信令或其他方式表明其不能或不愿意使用DTX进行静音抑制，则不得将本文件中规定的使用DTX的静音抑制用于会话。
dtxmax: Permissible values are from 0 to 255. Indicates the maximum DTX update interval in number of frames. During DTX, the RTP sender occasionally updates the RTP receiver about the change in background noise characteristics, etc., by sending a new silence frame to the RTP receiver. The RTP receiver may use 'dtxmax' to indicate to the RTP sender the maximum interval (in number of frames) between any two DTX updates it expects to receive from the RTP sender.
dtxmax：允许值为0到255。以帧数表示最大DTX更新间隔。在DTX期间，RTP发送方通过向RTP接收机发送新的静默帧，偶尔向RTP接收机更新背景噪声特性等的变化。RTP接收器可使用“dtxmax”向RTP发送器指示其预期从RTP发送器接收的任何两个DTX更新之间的最大间隔（以帧数计）。
If this parameter is not present in a session that uses DTX, the default value 32, as specified in [8], MUST be assumed. This parameter MUST be ignored if silence suppression using DTX is not used for the session.
如果使用DTX的会话中不存在此参数，则必须假定[8]中指定的默认值32。如果会话未使用DTX静音抑制，则必须忽略此参数。
Note also that if the RTP receiver elects to detect DTX using dtxmax, the dtxmax parameter will affect the amount of delay the RTP receiver sees before detecting DTX in the stream.
还请注意，如果RTP接收器选择使用dtxmax检测DTX，则dtxmax参数将影响RTP接收器在检测流中的DTX之前看到的延迟量。
dtxmin: Permissible values are from 0 to 255. Indicates the minimum DTX update interval in number of frames. The RTP receiver may use 'dtxmin' to indicate to the RTP sender the minimal interval (in number of frames) between any two DTX updates it expects to receive from the RTP sender.
dtxmin：允许值为0到255。以帧数表示最小DTX更新间隔。RTP接收器可使用“dtxmin”向RTP发送器指示其预期从RTP发送器接收的任何两个DTX更新之间的最小间隔（以帧数计）。
If this parameter is not present, the default value 12, as specified in [8] MUST be assumed. This parameter MUST be ignored if silence suppression using DTX is not used for the session.
如果此参数不存在，则必须假定[8]中指定的默认值12。如果会话未使用DTX静音抑制，则必须忽略此参数。
hangover: Permissible values are from 0 to 255. Indicates the number of consecutive silence frames transmitted at the end of an active speech interval but before the DTX interval begins. When setting up an RTP session that uses DTX, an RTP receiver can use this parameter to signal the number of silence frames it expects to receive before the beginning of DTX. While hangover=0 is allowed, it is RECOMMENDED that hangover be set to 1 or greater since the presence of silence frames at the end of an active speech can help the RTP receiver to identify the beginning of the DTX period.
遗留问题：允许值为0到255。指示在活动语音间隔结束但在DTX间隔开始之前传输的连续静默帧数。当设置使用DTX的RTP会话时，RTP接收器可以使用此参数来发出信号，表示它希望在DTX开始之前接收的静默帧数。虽然允许hangover=0，但建议将hangover设置为1或更大，因为在活动语音结束时存在静默帧可以帮助RTP接收器识别DTX周期的开始。
If this parameter is not present for a session that uses DTX, the default value 1, as specified in [8] MUST be assumed. This parameter MUST be ignored if silence suppression using DTX is not used for the session.
如果使用DTX的会话不存在此参数，则必须假定[8]中指定的默认值1。如果会话未使用DTX静音抑制，则必须忽略此参数。
Encoding considerations: This media type is framed binary data (see RFC 4288, Section 4.8) and is defined for transfer of EVRC-encoded data via RTP, using the compact bundled format as described in RFC 4788.
编码注意事项：该媒体类型为帧二进制数据（见RFC 4288，第4.8节），定义用于通过RTP传输EVRC编码数据，使用RFC 4788中所述的紧凑捆绑格式。
Security considerations: See Section 9 of RFC 4788.
安全注意事项：见RFC 4788第9节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: The EVRC vocoder is specified in 3GPP2 C.S0014 [2]. Transfer method with compact bundled RTP format is specified in RFC 4788.
已发布规范：EVRC声码器在3GPP2 C.S0014[2]中有规定。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:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
Person & email address to contact for further information:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing; hence, it is only defined for transfer via RTP (RFC 3550 [5]). Transfer within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧；因此，它仅定义为通过RTP传输（RFC 3550[5]）。此时未定义其他帧协议内的传输。
Author: Qiaobing Xie
作者：谢乔冰
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
Type name: audio
类型名称：音频
Subtype names: EVRCB
子类型名称：EVRCB
Required parameters: none
所需参数：无
Optional parameters:
可选参数：
ptime: see RFC 4566 [7].
ptime：见RFC 4566[7]。
maxptime: The maximum amount of media that can be encapsulated in each packet, expressed as time in milliseconds. The time MUST be calculated as the sum of the time the media present in the packet represents. The time SHOULD be a multiple of the duration of a single codec data frame (20 msec). If not signaled, the default maxptime value MUST be 200 milliseconds.
maxptime：每个数据包中可以封装的最大媒体量，以毫秒表示。时间必须计算为数据包中存在的媒体所代表的时间之和。时间应该是单个编解码器数据帧持续时间的倍数（20毫秒）。如果未发出信号，则默认maxptime值必须为200毫秒。
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 for definition. If this parameter is not present, the default value 1 MUST be assumed.
消声抑制：定义见第6.1节。如果此参数不存在，则必须假定默认值1。
dtxmax: see Section 6.1
dtxmax：见第6.1节
dtxmin: see Section 6.1
dtxmin：见第6.1节
hangover: see Section 6.1
宿醉：见第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 [4].
编码注意事项：该媒体类型为帧二进制数据（见RFC 4288，第4.8节），定义用于使用RFC 3558[4]中规定的交织/捆绑包格式，通过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 [3]. Transfer method with Interleaved/Bundled packet format via RTP is specified in RFC 3558.
已发布规范：EVRC-B声码器在3GPP2 C.S0014-B[3]中有规定。RFC 3558中规定了通过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 storage format only.
附加信息：以下信息仅适用于存储格式。
Magic number: #!EVRC-B\n (see Section 5 of RFC 4788)
File extensions: evb, EVB
Macintosh file type code: None
Object identifier or OID: None
Magic number: #!EVRC-B\n (see Section 5 of RFC 4788)
File extensions: evb, EVB
Macintosh file type code: None
Object identifier or OID: None
Person & email address to contact for further information:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
Person & email address to contact for further information:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type may be used with RTP framing (RFC 3550 [5]) and as a storage format. When used with RTP, the procedures in Section 3 MUST be followed. In all other contexts, the storage format defined in Section 5 MUST be used.
使用限制：此媒体类型可与RTP帧（RFC 3550[5]）一起使用，并作为存储格式。与RTP一起使用时，必须遵循第3节中的程序。在所有其他上下文中，必须使用第5节中定义的存储格式。
Author: Qiaobing Xie
作者：谢乔冰
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
Type name: audio
类型名称：音频
Subtype names: EVRCB0
子类型名称：EVRCB0
Required parameters: none
所需参数：无
Optional parameters:
可选参数：
silencesupp: see Section 6.1 for definition. If this parameter is not present, the default value 1 MUST be assumed.
消声抑制：定义见第6.1节。如果此参数不存在，则必须假定默认值1。
dtxmax: see Section 6.1
dtxmax：见第6.1节
dtxmin: see Section 6.1
dtxmin：见第6.1节
hangover: see Section 6.1
宿醉：见第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 [4].
编码注意事项：该媒体类型为帧二进制数据（见RFC 4288，第4.8节），定义为使用RFC 3558[4]中规定的无报头数据包格式，通过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 [3]. Transfer method with Header-Free packet format via RTP is specified in RFC 3558 and RFC 4788.
已发布规范：EVRC-B声码器在3GPP2 C.S0014-B[3]中有规定。RFC 3558和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:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
Person & email address to contact for further information:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing; hence, it is only defined for transfer via RTP (RFC 3550 [5]). Transfer within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧；因此，它仅定义为通过RTP传输（RFC 3550[5]）。此时未定义其他帧协议内的传输。
Author: Qiaobing Xie
作者：谢乔冰
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
Type name: audio
类型名称：音频
Subtype names: EVRCB1
子类型名称：EVRCB1
Required parameters: none
所需参数：无
Optional parameters:
可选参数：
ptime: see RFC 4566 [7].
ptime：见RFC 4566[7]。
maxptime: The maximum amount of media that can be encapsulated in each packet, expressed as time in milliseconds. The time MUST be calculated as the sum of the time the media present in the packet represents. The time SHOULD be a multiple of the duration of a single codec data frame (20 msec). If not signaled, the default maxptime value MUST be 200 milliseconds.
maxptime：每个数据包中可以封装的最大媒体量，以毫秒表示。时间必须计算为数据包中存在的媒体所代表的时间之和。时间应该是单个编解码器数据帧持续时间的倍数（20毫秒）。如果未发出信号，则默认maxptime值必须为200毫秒。
fixedrate: Indicates the EVRC-B 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-B速率。有效值包括：0.5和1，其中0.5表示1/2速率，1表示全速率。如果此参数不存在，则假定为1/2速率。
silencesupp: see Section 6.1 for definition. If this parameter is not present, the default value 1 MUST be assumed.
消声抑制：定义见第6.1节。如果此参数不存在，则必须假定默认值1。
dtxmax: see Section 6.1
dtxmax：见第6.1节
dtxmin: see Section 6.1
dtxmin：见第6.1节
hangover: see Section 6.1
宿醉：见第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 compact bundled format as described in RFC 4788.
编码注意事项：该媒体类型为帧二进制数据（见RFC 4288，第4.8节），定义为使用RFC 4788中所述的紧凑捆绑格式，通过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 [3]. Transfer method with compact bundled RTP format is specified in RFC 4788.
已发布规范：EVRC-B声码器在3GPP2 C.S0014-B[3]中有规定。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:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
Person & email address to contact for further information:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing; hence, it is only defined for transfer via RTP (RFC 3550 [5]). Transfer within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧；因此，它仅定义为通过RTP传输（RFC 3550[5]）。此时未定义其他帧协议内的传输。
Author: Qiaobing Xie
作者：谢乔冰
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
(The definition is from RFC 3558, added with the optional DTX parameters, and updated with the new template specified in [10].)
（该定义来自RFC 3558，添加了可选的DTX参数，并使用[10]中指定的新模板进行了更新。）
Type name: audio
类型名称：音频
Subtype names: EVRC
子类型名称：EVRC
Required parameters: none
所需参数：无
Optional parameters:
可选参数：
ptime: Defined as usual for RTP audio (see RFC 4566).
ptime：与RTP音频的通常定义相同（参见RFC 4566）。
maxptime: The maximum amount of media that can be encapsulated in each packet, expressed as time in milliseconds. The time SHALL be calculated as the sum of the time the media present in the packet represents. The time SHOULD be a multiple of the duration of a single codec data frame (20 msec). If not signaled, the default maxptime value SHALL be 200 milliseconds.
maxptime：每个数据包中可以封装的最大媒体量，以毫秒表示。时间应计算为数据包中存在的媒体代表的时间之和。时间应该是单个编解码器数据帧持续时间的倍数（20毫秒）。如果未发出信号，默认的maxptime值应为200毫秒。
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 SHALL be 5.
maxinterleave：交织长度的最大数目（交织八位字节中的字段LLL）。整个会话中使用的交织长度不得超过此最大值。如果未发出信号，最大交织长度应为5。
silencesupp: see Section 6.1 for definition. If this parameter is not present, the default value 1 MUST be assumed.
消声抑制：定义见第6.1节。如果此参数不存在，则必须假定默认值1。
dtxmax: see Section 6.1
dtxmax：见第6.1节
dtxmin: see Section 6.1
dtxmin：见第6.1节
hangover: see Section 6.1
宿醉：见第6.1节
Encoding considerations: This media type is framed binary data (see RFC 4288, Section 4.8), and is defined for transfer of EVRC-encoded data via RTP using the Interleaved/Bundled packet format specified in Sections 4.1, 6, and 7 of RFC 3558. It is also defined for other transfer methods using the storage format specified in Section 11 of RFC 3558.
编码注意事项：该媒体类型为帧二进制数据（见RFC 4288，第4.8节），定义用于使用RFC 3558第4.1、6和7节规定的交织/捆绑包格式，通过RTP传输EVRC编码数据。还定义了使用RFC 3558第11节规定的存储格式的其他传输方法。
Security considerations: See Section 14, "Security Considerations", of RFC 3558.
安全注意事项：见RFC 3558第14节“安全注意事项”。
Interoperability considerations: The DTX parameters are receiver options. Existing RFC 3558 implementations will not send any of the DTX parameters in their SDP and will ignore any DTX parameters they receive. The adaptive DTX behavior of DTX-capable EVRC codecs (as detailed in [8], Section 4.3.5) ensures interoperability with non-DTX EVRC codecs.
互操作性注意事项：DTX参数是接收机选项。现有RFC3558实现不会发送SDP中的任何DTX参数，并且会忽略接收到的任何DTX参数。支持DTX的EVRC编解码器的自适应DTX行为（详见[8]，第4.3.5节）确保了与非DTX EVRC编解码器的互操作性。
Published specification: The EVRC vocoder is specified in 3GPP2 C.S0014 [2]. Transfer methods are specified in RFC 3558.
已发布规范：EVRC声码器在3GPP2 C.S0014[2]中有规定。RFC 3558中规定了传输方法。
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 storage format only.
附加信息：以下信息仅适用于存储格式。
Magic number: #!EVRC\n (see Section 11 of RFC 3558)
File extensions: evc, EVC
Macintosh file type code: none
Object identifier or OID: none
Magic number: #!EVRC\n (see Section 11 of RFC 3558)
File extensions: evc, EVC
Macintosh file type code: none
Object identifier or OID: none
Person & email address to contact for further information:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
Person & email address to contact for further information:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type may be used with RTP framing (RFC 3550 [5]) and as a storage format. When used with RTP, the procedures in RFC 3558, Section 4.1, MUST be followed. In all other contexts, the storage format defined in RFC 3558, Section 11, MUST be used.
使用限制：此媒体类型可与RTP帧（RFC 3550[5]）一起使用，并作为存储格式。与RTP一起使用时，必须遵守RFC 3558第4.1节中的程序。在所有其他情况下，必须使用RFC 3558第11节中定义的存储格式。
Author: Adam Li/Qiaobing Xie
作者：李亚当/谢乔冰
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
(The definition is from RFC 3558, added with the optional DTX parameters, and updated with the new template specified in [10].)
（该定义来自RFC 3558，添加了可选的DTX参数，并使用[10]中指定的新模板进行了更新。）
Type name: audio
类型名称：音频
Subtype names: EVRC0
子类型名称：EVRC0
Required parameters: none
所需参数：无
Optional parameters:
可选参数：
silencesupp: see Section 6.1 for definition. If this parameter is not present, the default value 1 MUST be assumed.
消声抑制：定义见第6.1节。如果此参数不存在，则必须假定默认值1。
dtxmax: see Section 6.1
dtxmax：见第6.1节
dtxmin: see Section 6.1
dtxmin：见第6.1节
hangover: see Section 6.1
宿醉：见第6.1节
Encoding considerations: This media type is framed binary data (see RFC 4288, Section 4.8) and is only defined for transfer of EVRC-encoded data via RTP using the Header-Free packet format specified in Section 4.2 of RFC 3558.
编码注意事项：该媒体类型为帧二进制数据（见RFC 4288，第4.8节），仅用于使用RFC 3558第4.2节规定的无报头数据包格式，通过RTP传输EVRC编码数据。
Security considerations: See Section 14, "Security Considerations", of RFC 3558.
安全注意事项：见RFC 3558第14节“安全注意事项”。
Interoperability considerations: The DTX parameters are receiver options. Existing RFC 3558 implementations will not send any of the DTX parameters in their SDP and will ignore any DTX parameters they receive. The adaptive DTX behavior of DTX-capable EVRC codecs (as detailed in [8], Section 4.3.5) ensures interoperability with non-DTX EVRC codecs.
互操作性注意事项：DTX参数是接收机选项。现有RFC3558实现不会发送SDP中的任何DTX参数，并且会忽略接收到的任何DTX参数。支持DTX的EVRC编解码器的自适应DTX行为（详见[8]，第4.3.5节）确保了与非DTX EVRC编解码器的互操作性。
Published specification: The EVRC vocoder is specified in 3GPP2 C.S0014 [2]. Transfer methods are specified in RFC 3558.
已发布规范：EVRC声码器在3GPP2 C.S0014[2]中有规定。RFC 3558中规定了传输方法。
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:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
Person & email address to contact for further information:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing; hence, it is only defined for transfer via RTP (RFC 3550 [5]). Transfer within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧；因此，它仅定义为通过RTP传输（RFC 3550[5]）。此时未定义其他帧协议内的传输。
Author: Adam Li/Qiaobing Xie
作者：李亚当/谢乔冰
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
The information carried in the MIME media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [7], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the compact bundled format for EVRC/EVRC-B-encoded speech, the mapping is as follows:
MIME媒体类型规范中包含的信息具有到会话描述协议（SDP）[7]中字段的特定映射，该协议通常用于描述RTP会话。当使用SDP为EVRC/EVRC-B编码语音指定采用紧凑捆绑格式的会话时，映射如下：
o The MIME type ("audio") goes in SDP "m=" as the media name.
o MIME类型（“音频”）以SDP“m=”作为媒体名称。
o The MIME subtype ("EVRC", "EVRC0", "EVRC1", "EVRCB", EVRCB0", or "EVRCB1") goes in SDP "a=rtpmap" as the encoding name.
o MIME子类型（“EVRC”、“EVRC0”、“EVRC1”、“EVRCB”、“EVRCB0”或“EVRCB1”）以SDP“a=rtpmap”作为编码名称。
o The optional parameters "ptime" and "maxptime" (for subtypes EVRC, EVRC1, EVRCB, and EVRCB1) go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
o 可选参数“ptime”和“maxptime”（用于子类型EVRC、EVRC1、EVRCB和EVRCB1）分别位于SDP“a=ptime”和“a=maxptime”属性中。
o The optional parameter "maxinterleave" (for subtypes EVRC and EVRCB) goes in the SDP "a=fmtp" attribute by copying it directly from the MIME media type string as "maxinterleave=value".
o 可选参数“maxinterleave”（用于子类型EVRC和EVRCB）直接从MIME媒体类型字符串复制为“maxinterleave=value”，从而进入SDP“a=fmtp”属性。
o The optional parameter "fixedrate" (for subtypes EVRC1 and EVRCB1) goes in the "a=fmtp" attribute by copying it directly from the MIME media type string as "fixedrate=value".
o 可选参数“fixedrate”（用于子类型EVRC1和EVRCB1）直接从MIME媒体类型字符串复制为“fixedrate=value”，从而进入“a=fmtp”属性。
o The optional parameters "silencesupp", "dtxmax", "dtxmin", and "hangover" go in the "a=fmtp" attribute by copying it directly from the MIME media type string as "silencesupp=value", "dtxmax=value", "dtxmin=value", and "hangover=value", respectively.
o 可选参数“silenesupp”、“dtxmax”、“dtxmin”和“hangover”通过直接从MIME媒体类型字符串复制而进入“a=fmtp”属性，分别为“silenesupp=value”、“dtxmax=value”、“dtxmin=value”和“hangover=value”。
Example of usage of EVRC1:
EVRC1的使用示例：
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRC1/8000
a=fmtp:97 fixedrate=0.5
a=maxptime:120
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRC1/8000
a=fmtp:97 fixedrate=0.5
a=maxptime:120
Example of usage of EVRCB:
EVRCB的使用示例：
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCB/8000
a=maxptime:120
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCB/8000
a=maxptime:120
Example of usage of EVRCB0:
EVRCB0的使用示例：
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCB0/8000
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCB0/8000
Example of usage of EVRCB1:
EVRCB1的使用示例：
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCB1/8000
a=fmtp:97 fixedrate=0.5
a=maxptime:100
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCB1/8000
a=fmtp:97 fixedrate=0.5
a=maxptime:100
Example of usage of EVRC with DTX with silencesupp=1:
带DTX的EVRC的使用示例，消声supp=1：
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRC/8000
a=fmtp:97 silencesupp=1 dtxmax=32 dtxmin=12 hangover=1
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRC/8000
a=fmtp:97 silencesupp=1 dtxmax=32 dtxmin=12 hangover=1
Example of usage of EVRC with DTX with silencesupp=0:
带DTX的EVRC的使用示例，静音SUPP=0：
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRC/8000
a=fmtp:97 silencesupp=0
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRC/8000
a=fmtp:97 silencesupp=0
All SDP parameters in this payload format are declarative, and all reasonable values are expected to be supported. In particular, when DTX is supported, the RTP sender implementation SHOULD support hangover, dtxmin, and dtxmax values from 0 to 255. Thus, the standard usage of Offer/Answer, as described in RFC 3264 [6], SHOULD be followed.
此有效负载格式中的所有SDP参数都是声明性的，预期支持所有合理的值。特别是，当支持DTX时，RTP发送方实现应该支持从0到255的hangover、dtxmin和dtxmax值。因此，应遵循RFC 3264[6]中所述的提供/应答的标准用法。
In addition, the following rules MUST be followed while negotiating DTX parameters:
此外，协商DTX参数时必须遵守以下规则：
1. If any DTX parameter is not present in either offer and/or answer, the default value of the DTX parameter MUST be assumed.
1. 如果报价和/或应答中没有任何DTX参数，则必须假定DTX参数的默认值。
2. If silencesupp is present and set to 0 in either offer or answer, the values of all received DTX parameters other than silencesupp SHOULD be ignored.
2. 如果存在silencesupp并在提供或应答中将其设置为0，则应忽略除silencesupp之外的所有接收到的DTX参数值。
3. In an offer or answer, the value of dtxmax SHOULD always be larger than or equal to the value of dtxmin, regardless of whether the values are indicated explicitly or implicitly by default. Moreover, if the indicated value of dtxmin is larger
3. 在报价或应答中，dtxmax的值应始终大于或等于dtxmin的值，而不管默认情况下是显式指示还是隐式指示。此外，如果dtxmin的指示值更大
than that of dtxmax, an RTP sender MUST ignore the indicated values and MUST fall back on using the default dtxmin and dtxmax values.
与dtxmax相比，RTP发送器必须忽略指示的值，并且必须使用默认的dtxmin和dtxmax值。
This document adds new optional DTX parameters to the original EVRC payload subtypes "EVRC" and "EVRC0" defined in RFC 3558. Since the new DTX parameters are receiver options, we expect that the existing RFC 3558 implementations will not send any of the DTX parameters in their SDP and will ignore any DTX parameters they receive. The adaptive DTX behavior of DTX-capable EVRC codecs (as detailed in [8], Section 4.3.5) ensures the backward interoperability between the DTX-capable EVRC codec and non-DTX EVRC codecs.
本文档向RFC 3558中定义的原始EVRC有效负载子类型“EVRC”和“EVRC0”添加了新的可选DTX参数。由于新的DTX参数是接收器选项，我们希望现有RFC 3558实现不会在其SDP中发送任何DTX参数，并且会忽略其接收的任何DTX参数。支持DTX的EVRC编解码器的自适应DTX行为（详见[8]，第4.3.5节）确保了支持DTX的EVRC编解码器和非DTX EVRC编解码器之间的向后互操作性。
Four (4) new MIME subtype registrations - "EVRC1", "EVRCB", "EVRCB0", and "EVRCB1" - are defined in this document (see Section 6.1 - Section 6.4) for EVRC-B and compact bundled payload format support.
本文件中定义了四（4）个新的MIME子类型注册——“EVRC1”、“EVRCB”、“EVRCB0”和“EVRCB1”（参见第6.1节-第6.4节），以支持EVRC-B和紧凑捆绑负载格式。
For all the EVRC and EVRC-B RTP payload formats defined in RFC 3558 [4] and RFC 4788, four additional optional parameters - "silencesupp", "dtxmax", "dtxmin", and "hangover" - are defined and used in DTX.
对于RFC 3558[4]和RFC 4788中定义的所有EVRC和EVRC-B RTP有效载荷格式，DTX中定义并使用了四个额外的可选参数——“静音抑制”、“dtxmax”、“dtxmin”和“hangover”。
The MIME subtype registrations "EVRC" and "EVRC0", originally defined in RFC 3558 [4], are updated with the optional DTX parameters (see Sections 6.5 and 6.6).
最初在RFC 3558[4]中定义的MIME子类型注册“EVRC”和“EVRC0”使用可选的DTX参数进行更新（参见第6.5节和第6.6节）。
Implementations using the payload defined in this specification are subject to the security considerations discussed in RFC 3558 [4], RFC 3550 [5], and any appropriate profile (for example, RFC 3551 [9]). This payload does not specify any different security services.
使用本规范中定义的有效负载的实现受RFC 3558[4]、RFC 3550[5]和任何适当配置文件（例如RFC 3551[9]）中讨论的安全注意事项的约束。此有效负载未指定任何不同的安全服务。
The following people have made significant contributions to this document (in alphabetical order): Parag Agashe, Jim Ashley, Harikishan Desineni, Serafin Diaz, Harinath Garudadri, Gouri Johanssen, Ananth Kandhadai, Waqar Mohsin, Ashok Roy, Gino Scribano, and Gajinder Singh Vij.
以下人士（按字母顺序）对本文件做出了重要贡献：Parag Agasher、Jim Ashley、Harikishan Desinini、Serafin Diaz、Harinath Garudadri、Gouri Johanssen、Ananth Kandhadai、Waqar Mohsin、Ashok Roy、Gino Scribano和Gajinder Singh Vij。
Special thanks to Colin Perkins, Magnus Westerlund, and Adam Li for their careful review and comments that significantly improved the quality of this document.
特别感谢Colin Perkins、Magnus Westerlund和Adam Li的仔细审阅和评论，这些审阅和评论显著提高了本文档的质量。
[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] "Enhanced Variable Rate Codec, Speech Service Option 3 for Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014, January 1997.
[2] “用于宽带扩频数字系统的增强型变速率编解码器，语音服务选项3”，3GPP2 C.S0014，1997年1月。
[3] "Enhanced Variable Rate Codec, Speech Service Option 3 and 68 for Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014-B v1.0, May 2006.
[3] “用于宽带扩频数字系统的增强型变速率编解码器，语音服务选项3和68”，3GPP2 C.S0014-B v1.0，2006年5月。
[4] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, July 2003.
[4] 李安，“增强型变速率编解码器（EVRC）和可选模式声码器（SMV）的RTP有效载荷格式”，RFC3558，2003年7月。
[5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
[5] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，RFC 35502003年7月。
[6] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002.
[6] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[7] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[7] Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[8] "Discontinuous Transmission (DTX) of Speech in cdma2000 Systems", 3GPP2 C.S0076-0, Version 1.0, December 2005.
[8] “cdma2000系统中语音的不连续传输（DTX）”，3GPP2 C.S0076-0，版本1.0，2005年12月。
[9] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003.
[9] Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，RFC 3551，2003年7月。
[10] Casner, S., "Media Type Registration of RTP Payload Formats", Work in Progress, March 2006.
[10] Casner，S.，“RTP有效载荷格式的媒体类型注册”，正在进行的工作，2006年3月。
Authors' Addresses
作者地址
Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, 2-F9 Arlington Heights, IL 60004 US
谢乔平摩托罗拉公司，美国伊利诺伊州阿灵顿高地2-F9舒尔大道西1501号，邮编60004
Phone: +1-847-632-3028
EMail: Qiaobing.Xie@Motorola.com
Phone: +1-847-632-3028
EMail: Qiaobing.Xie@Motorola.com
Rohit Kapoor Qualcomm Inc. US
美国罗希特卡普尔高通公司
Phone: +1-858-845-1161
EMail: rkapoor@qualcomm.com
Phone: +1-858-845-1161
EMail: rkapoor@qualcomm.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。