Network Working Group S. Ahmadi
Request for Comments: 4348 January 2006
Category: Standards Track
Network Working Group S. Ahmadi
Request for Comments: 4348 January 2006
Category: Standards Track
Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec
用于可变速率多模宽带（VMR-WB）音频编解码器的实时传输协议（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 Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document specifies a real-time transport protocol (RTP) payload format to be used for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. The payload format is designed to be able to interoperate with existing VMR-WB transport formats on non-IP networks. A media type registration is included for VMR-WB RTP payload format.
本文件规定了用于可变速率多模式宽带（VMR-WB）语音编解码器的实时传输协议（RTP）有效载荷格式。有效负载格式旨在与非IP网络上的现有VMR-WB传输格式进行互操作。VMR-WB RTP有效负载格式包括介质类型注册。
VMR-WB is a variable-rate multimode wideband speech codec that has a number of operating modes, one of which is interoperable with AMR-WB (i.e., RFC 3267) audio codec at certain rates. Therefore, provisions have been made in this document to facilitate and simplify data packet exchange between VMR-WB and AMR-WB in the interoperable mode with no transcoding function involved.
VMR-WB是一种可变速率多模宽带语音编解码器，具有多种操作模式，其中一种模式可与AMR-WB（即RFC 3267）音频编解码器以一定速率互操作。因此，本文件中已作出规定，以促进和简化VMR-WB和AMR-WB之间在互操作模式下的数据包交换，且不涉及转码功能。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions and Acronyms ........................................3
3. The Variable-Rate Multimode Wideband (VMR-WB) Speech Codec ......4
3.1. Narrowband Speech Processing ...............................5
3.2. Continuous vs. Discontinuous Transmission ..................6
3.3. Support for Multi-Channel Session ..........................6
4. Robustness against Packet Loss ..................................7
4.1. Forward Error Correction (FEC) .............................7
4.2. Frame Interleaving and Multi-Frame Encapsulation ...........8
5. VMR-WB Voice over IP Scenarios ..................................9
5.1. IP Terminal to IP Terminal .................................9
5.2. GW to IP Terminal .........................................10
5.3. GW to GW (between VMR-WB- and AMR-WB-Enabled Terminals) ...10
5.4. GW to GW (between Two VMR-WB-Enabled Terminals) ...........11
6. VMR-WB RTP Payload Formats .....................................12
6.1. RTP Header Usage ..........................................13
6.2. Header-Free Payload Format ................................14
6.3. Octet-Aligned Payload Format ..............................15
6.3.1. Payload Structure ..................................15
6.3.2. The Payload Header .................................15
6.3.3. The Payload Table of Contents ......................18
6.3.4. Speech Data ........................................20
6.3.5. Payload Example: Basic Single Channel
Payload Carrying Multiple Frames ...................21
6.4. Implementation Considerations .............................22
6.4.1. Decoding Validation and Provision for Lost
or Late Packets ....................................22
7. Congestion Control .............................................23
8. Security Considerations ........................................23
8.1. Confidentiality ...........................................24
8.2. Authentication and Integrity ..............................24
9. Payload Format Parameters ......................................24
9.1. VMR-WB RTP Payload MIME Registration ......................25
9.2. Mapping MIME Parameters into SDP ..........................27
9.3. Offer-Answer Model Considerations .........................28
10. IANA Considerations ...........................................29
11. Acknowledgements ..............................................29
12. References ....................................................30
12.1. Normative References .....................................30
12.2. Informative References ...................................30
1. Introduction ....................................................3
2. Conventions and Acronyms ........................................3
3. The Variable-Rate Multimode Wideband (VMR-WB) Speech Codec ......4
3.1. Narrowband Speech Processing ...............................5
3.2. Continuous vs. Discontinuous Transmission ..................6
3.3. Support for Multi-Channel Session ..........................6
4. Robustness against Packet Loss ..................................7
4.1. Forward Error Correction (FEC) .............................7
4.2. Frame Interleaving and Multi-Frame Encapsulation ...........8
5. VMR-WB Voice over IP Scenarios ..................................9
5.1. IP Terminal to IP Terminal .................................9
5.2. GW to IP Terminal .........................................10
5.3. GW to GW (between VMR-WB- and AMR-WB-Enabled Terminals) ...10
5.4. GW to GW (between Two VMR-WB-Enabled Terminals) ...........11
6. VMR-WB RTP Payload Formats .....................................12
6.1. RTP Header Usage ..........................................13
6.2. Header-Free Payload Format ................................14
6.3. Octet-Aligned Payload Format ..............................15
6.3.1. Payload Structure ..................................15
6.3.2. The Payload Header .................................15
6.3.3. The Payload Table of Contents ......................18
6.3.4. Speech Data ........................................20
6.3.5. Payload Example: Basic Single Channel
Payload Carrying Multiple Frames ...................21
6.4. Implementation Considerations .............................22
6.4.1. Decoding Validation and Provision for Lost
or Late Packets ....................................22
7. Congestion Control .............................................23
8. Security Considerations ........................................23
8.1. Confidentiality ...........................................24
8.2. Authentication and Integrity ..............................24
9. Payload Format Parameters ......................................24
9.1. VMR-WB RTP Payload MIME Registration ......................25
9.2. Mapping MIME Parameters into SDP ..........................27
9.3. Offer-Answer Model Considerations .........................28
10. IANA Considerations ...........................................29
11. Acknowledgements ..............................................29
12. References ....................................................30
12.1. Normative References .....................................30
12.2. Informative References ...................................30
This document specifies the payload format for packetization of VMR-WB-encoded speech signals into the Real-time Transport Protocol (RTP) [3]. The VMR-WB payload formats support transmission of single and multiple channels, frame interleaving, multiple frames per payload, header-free payload, the use of mode switching, and interoperation with existing VMR-WB transport formats on non-IP networks, as described in Section 3.
本文件规定了将VMR WB编码语音信号打包成实时传输协议（RTP）[3]的有效载荷格式。VMR-WB有效载荷格式支持单通道和多通道传输、帧交错、每有效载荷多帧、无报头有效载荷、模式切换的使用以及与非IP网络上现有VMR-WB传输格式的互操作，如第3节所述。
The payload format is described in Section 6. The VMR-WB file format (i.e., for transport of VMR-WB speech data in storage mode applications such as email) is specified in [7]. In Section 9, a media type registration for VMR-WB RTP payload format is provided.
有效载荷格式在第6节中描述。VMR-WB文件格式（即，用于在存储模式应用程序（如电子邮件）中传输VMR-WB语音数据）在[7]中规定。在第9节中，提供了VMR-WB RTP有效负载格式的媒体类型注册。
Since VMR-WB is interoperable with AMR-WB at certain rates, an attempt has been made throughout this document to maximize the similarities with RFC 3267 while optimizing the payload format for the non-interoperable modes of the VMR-WB codec.
由于VMR-WB可与AMR-WB以一定速率进行互操作，因此在本文档中尝试最大限度地提高与RFC 3267的相似性，同时优化VMR-WB编解码器不可互操作模式的有效负载格式。
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 RFC2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC2119[2]中所述进行解释。
The following acronyms are used in this document:
本文件中使用了以下首字母缩略词：
3GPP - The Third Generation Partnership Project 3GPP2 - The Third Generation Partnership Project 2 CDMA - Code Division Multiple Access WCDMA - Wideband Code Division Multiple Access GSM - Global System for Mobile Communications AMR-WB - Adaptive Multi-Rate Wideband Codec VMR-WB - Variable-Rate Multimode Wideband Codec CMR - Codec Mode Request GW - Gateway DTX - Discontinuous Transmission FEC - Forward Error Correction SID - Silence Descriptor TrFO - Transcoder-Free Operation UDP - User Datagram Protocol RTP - Real-Time Transport Protocol RTCP - RTP Control Protocol MIME - Multipurpose Internet Mail Extension SDP - Session Description Protocol VoIP - Voice-over-IP
3GPP-第三代合作伙伴项目3GPP2-第三代合作伙伴项目2 CDMA-码分多址WCDMA-宽带码分多址GSM-全球移动通信系统AMR-WB-自适应多速率宽带编解码器VMR-WB-可变速率多模宽带编解码器CMR-编解码器模式请求GW-网关DTX-不连续传输FEC-前向纠错SID-静音描述符TrFO-无转码器操作UDP-用户数据报协议RTP-实时传输协议RTCP-RTP控制协议MIME-多用途Internet邮件扩展SDP-会话描述协议VoIP-IP语音
The term "interoperable mode" in this document refers to VMR-WB mode 3, which is interoperable with AMR-WB codec modes 0, 1, and 2.
本文档中的术语“可互操作模式”指VMR-WB模式3，可与AMR-WB编解码器模式0、1和2互操作。
The term "non-interoperable modes" in this document refers to VMR-WB modes 0, 1, and 2.
本文档中的术语“非互操作模式”指VMR-WB模式0、1和2。
The term "frame-block" is used in this document to describe the time-synchronized set of speech frames in a multi-channel VMR-WB session. In particular, in an N-channel session, a frame-block will contain N speech frames, one from each of the channels, and all N speech frames represent exactly the same time period.
术语“帧块”在本文档中用于描述多通道VMR-WB会话中的时间同步语音帧集。特别地，在N信道会话中，帧块将包含N个语音帧，每个信道一个，并且所有N个语音帧表示完全相同的时间段。
VMR-WB is the wideband speech-coding standard developed by Third Generation Partnership Project 2 (3GPP2) for encoding/decoding wideband/narrowband speech content in multimedia services in 3G CDMA cellular systems [1]. VMR-WB is a source-controlled variable-rate multimode wideband speech codec. It has a number of operating modes, where each mode is a tradeoff between voice quality and average data rate. The operating mode in VMR-WB (as shown in Table 2) is chosen based on the traffic condition of the network and the desired quality of service. The desired average data rate (ADR) in each mode is obtained by encoding speech frames at permissible rates (as shown in Tables 1 and 3) compliant with CDMA2000 system, depending on the instantaneous characteristics of input speech and the maximum and minimum rate constraints imposed by the network operator.
VMR-WB是由第三代合作伙伴项目2（3GPP2）开发的宽带语音编码标准，用于在3G CDMA蜂窝系统中对多媒体业务中的宽带/窄带语音内容进行编码/解码[1]。VMR-WB是一种源代码控制的可变速率多模宽带语音编解码器。它有许多操作模式，每种模式都是语音质量和平均数据速率之间的折衷。VMR-WB中的运行模式（如表2所示）是根据网络的流量状况和所需的服务质量选择的。根据输入语音的瞬时特性以及网络运营商施加的最大和最小速率限制，以符合CDMA2000系统的允许速率（如表1和表3所示）对语音帧进行编码，从而获得每种模式下的期望平均数据速率（ADR）。
While VMR-WB is a native CDMA codec complying with all CDMA system requirements, it is further interoperable with AMR-WB [4,12] at 12.65, 8.85, and 6.60 kbps. This is due to the fact that VMR-WB and AMR-WB share the same core technology. This feature enables Transcoder-Free (TrFO) interconnections between VMR-WB and AMR-WB across different wireless/wireline systems (e.g., GSM/WCDMA and CDMA2000) without use of unnecessary complex media format conversion.
尽管VMR-WB是一种符合所有CDMA系统要求的本机CDMA编解码器，但它还可以以12.65、8.85和6.60 kbps的速率与AMR-WB[4,12]进行互操作。这是因为VMR-WB和AMR-WB共享相同的核心技术。此功能可实现VMR-WB和AMR-WB之间跨不同无线/有线系统（例如GSM/WCDMA和CDMA2000）的无转码（TrFO）互连，而无需使用不必要的复杂媒体格式转换。
Note that the concept of mode in VMR-WB is different from that of AMR-WB where each fixed-rate AMR-WB codec mode is adapted to prevailing channel conditions by a tradeoff between the total number of source-coding and channel-coding bits.
请注意，VMR-WB中的模式概念与AMR-WB不同，AMR-WB中的每个固定速率AMR-WB编解码器模式通过信源编码和信道编码比特总数之间的折衷来适应当前信道条件。
VMR-WB is able to transition between various modes with no degradation in voice quality that is attributable to the mode switching itself. The operating mode of the VMR-WB encoder may be switched seamlessly without prior knowledge of the decoder. Any non-interoperable mode (i.e., VMR-WB modes 0, 1, or 2) can be chosen depending on the traffic conditions (e.g., network congestion) and the desired quality of service.
VMR-WB能够在各种模式之间转换，而不会因模式切换本身而降低语音质量。VMR-WB编码器的操作模式可以无缝切换，而无需事先了解解码器。任何不可互操作的模式（即VMR-WB模式0、1或2）都可以根据流量条件（例如网络拥塞）和所需的服务质量进行选择。
While in the interoperable mode (i.e., VMR-WB mode 3), mode switching between VMR-WB modes is not allowed because there is only one AMR-WB interoperable mode in VMR-WB. Since the AMR-WB codec may request a mode change, depending on channel conditions, in-band data included in VMR-WB frame structure (see Section 8 of [1] for more details) is used during an interoperable interconnection to switch between VMR-WB frame types 0, 1, and 2 in VMR-WB mode 3 (corresponding to AMR-WB codec modes 0, 1, or 2).
在可互操作模式（即VMR-WB模式3）下，不允许在VMR-WB模式之间切换模式，因为VMR-WB中只有一个AMR-WB可互操作模式。由于AMR-WB编解码器可能会根据信道条件请求模式更改，因此在可互操作互连期间使用VMR-WB帧结构中包含的带内数据（更多详细信息，请参见[1]的第8节），以在VMR-WB模式3（对应于AMR-WB编解码器模式0、1或2）中的VMR-WB帧类型0、1和2之间切换。
As mentioned earlier, VMR-WB is compliant with CDMA2000 system with the permissible encoding rates shown in Table 1.
如前所述，VMR-WB符合CDMA2000系统，允许的编码速率如表1所示。
+---------------------------+-----------------+---------------+
| Frame Type | Bits per Packet | Encoding Rate |
| | (Frame Size) | (kbps) |
+---------------------------+-----------------+---------------+
| Full-Rate | 266 | 13.3 |
| Half-Rate | 124 | 6.2 |
| Quarter-Rate | 54 | 2.7 |
| Eighth-Rate | 20 | 1.0 |
| Blank | 0 | 0 |
| Erasure | 0 | 0 |
+---------------------------+-----------------+---------------+
+---------------------------+-----------------+---------------+
| Frame Type | Bits per Packet | Encoding Rate |
| | (Frame Size) | (kbps) |
+---------------------------+-----------------+---------------+
| Full-Rate | 266 | 13.3 |
| Half-Rate | 124 | 6.2 |
| Quarter-Rate | 54 | 2.7 |
| Eighth-Rate | 20 | 1.0 |
| Blank | 0 | 0 |
| Erasure | 0 | 0 |
+---------------------------+-----------------+---------------+
Table 1: CDMA2000 system permissible frame types and their associated encoding rates
表1:CDMA2000系统允许的帧类型及其相关编码速率
VMR-WB is robust to high percentage of frame loss and frames with corrupted rate information. The reception of an Erasure (SPEECH_LOST) frame type at decoder invokes the built-in frame error concealment mechanism. The built-in frame error concealment mechanism in VMR-WB conceals the effect of lost frames by exploiting in-band data and the information available in the previous frames.
VMR-WB对高百分比的帧丢失和具有损坏速率信息的帧具有鲁棒性。解码器接收到的擦除（语音丢失）帧类型调用内置帧错误隐藏机制。VMR-WB中内置的帧错误隐藏机制通过利用带内数据和前一帧中可用的信息来隐藏丢失帧的影响。
VMR-WB has the capability to operate with either 16000-Hz or 8000-Hz sampled input/output speech signals in all modes of operation [1]. The VMR-WB decoder does not require a priori knowledge about the sampling rate of the original media (i.e., speech/audio signals sampled at 8 or 16 kHz) at the input of the encoder. The VMR-WB decoder, by default, generates 16000-Hz wideband output regardless of the encoder input sampling frequency. Depending on the application, the decoder can be configured to generate 8000-Hz output, as well.
VMR-WB能够在所有操作模式下使用16000 Hz或8000 Hz采样输入/输出语音信号[1]。在Vmi/Vmi.e.下，不需要对原始编码器输入的音频信号进行采样。默认情况下，VMR-WB解码器生成16000 Hz宽带输出，与编码器输入采样频率无关。根据应用，解码器也可配置为产生8000 Hz输出。
Therefore, while this specification defines a 16000-Hz RTP clock rate for VMR-WB codec, the injection and processing of 8000-Hz narrowband media during a session is also allowed; however, a 16000-Hz RTP clock rate MUST always be used.
因此，虽然本规范为VMR-WB编解码器定义了16000 Hz RTP时钟频率，但也允许在会话期间注入和处理8000 Hz窄带媒体；但是，必须始终使用16000 Hz RTP时钟频率。
The choice of VMR-WB output sampling frequency depends on the implementation and the audio acoustic capabilities of the receiving side.
VMR-WB输出采样频率的选择取决于接收端的实现和音频声学能力。
The circuit-switched operation of VMR-WB within a CDMA network requires continuous transmission of the speech data during a conversation. The intrinsic source-controlled variable-rate feature of the CDMA speech codecs is required for optimal operation of the CDMA system and interference control. However, VMR-WB has the capability to operate in a discontinuous transmission mode for some packet-switched applications over IP networks (e.g., VoIP), where the number of transmitted bits and packets during silence period are reduced to a minimum. The VMR-WB DTX operation is similar to that of AMR-WB [4,12].
在CDMA网络中，VMR-WB的电路交换操作要求在会话期间连续传输语音数据。CDMA语音编解码器固有的源控制变速率特性是CDMA系统最佳运行和干扰控制所必需的。然而，VMR-WB能够在IP网络（例如，VoIP）上的一些分组交换应用程序中以不连续传输模式运行，其中静默期间传输的比特和分组的数量减少到最小。VMR-WB DTX操作与AMR-WB类似[4,12]。
The octet-aligned RTP payload format defined in this document supports multi-channel audio content (e.g., a stereophonic speech session). Although VMR-WB codec itself does not support encoding of multi-channel audio content into a single bit stream, it can be used to encode and decode each of the individual channels separately.
本文档中定义的八位字节对齐RTP有效负载格式支持多声道音频内容（例如，立体声语音会话）。尽管VMR-WB编解码器本身不支持将多声道音频内容编码为单个比特流，但它可用于单独对每个声道进行编码和解码。
To transport the separately encoded multi-channel content, the speech frames for all channels that are framed and encoded for the same 20 ms periods are logically collected in a frame-block.
为了传输单独编码的多频道内容，在帧块中逻辑地收集针对相同20ms周期被帧化和编码的所有频道的语音帧。
At the session setup, out-of-band signaling must be used to indicate the number of channels in the session and the order of the speech frames from different channels in each frame-block. When using SDP for signaling (see Section 9.2 for more details), the number of channels is specified in the rtpmap attribute, and the order of channels carried in each frame-block is implied by the number of channels as specified in Section 4.1 in [6].
在会话设置中，必须使用带外信令来指示会话中的信道数量以及每个帧块中来自不同信道的语音帧的顺序。当使用SDP发送信号时（详见第9.2节），信道数量在rtpmap属性中指定，每个帧块中承载的信道顺序由[6]第4.1节中规定的信道数量表示。
The octet-aligned payload format described in this document (see Section 6 for more details) supports several features, including forward error correction (FEC) and frame interleaving, in order to increase robustness against lost packets.
本文档中描述的八位字节对齐有效负载格式（有关更多详细信息，请参见第6节）支持多种功能，包括前向纠错（FEC）和帧交错，以增强对丢失数据包的鲁棒性。
The simple scheme of repetition of previously sent data is one way of achieving FEC. Another possible scheme, which is more bandwidth efficient, is to use payload-external FEC; e.g., RFC2733 [8], which generates extra packets containing repair data.
重复先前发送的数据的简单方案是实现FEC的一种方法。另一种可能的方案，更具带宽效率，是使用有效载荷外部FEC；e、 例如，RFC2733[8]，它生成包含修复数据的额外数据包。
The repetition method involves the simple retransmission of previously transmitted frame-blocks together with the current frame-block(s). This is done by using a sliding window to group the speech frame-blocks to send in each payload. Figure 1 illustrates an example.
重复方法涉及先前发送的帧块与当前帧块的简单重传。这是通过使用滑动窗口将要发送到每个有效负载中的语音帧块分组来完成的。图1演示了一个示例。
In this example, each frame-block is retransmitted one time in the following RTP payload packet. Here, f(n-2)..f(n+4) denotes a sequence of speech frame-blocks, and p(n-1)..p(n+4) a sequence of payload packets.
在此示例中，每个帧块在以下RTP有效负载分组中重传一次。这里，f（n-2）…f（n+4）表示语音帧块的序列，p（n-1）…p（n+4）表示有效载荷分组的序列。
--+--------+--------+--------+--------+--------+--------+--------+--
| f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) |
--+--------+--------+--------+--------+--------+--------+--------+--
--+--------+--------+--------+--------+--------+--------+--------+--
| f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) |
--+--------+--------+--------+--------+--------+--------+--------+--
<---- p(n-1) ---->
<----- p(n) ----->
<---- p(n+1) ---->
<---- p(n+2) ---->
<---- p(n+3) ---->
<---- p(n+4) ---->
<---- p(n-1) ---->
<----- p(n) ----->
<---- p(n+1) ---->
<---- p(n+2) ---->
<---- p(n+3) ---->
<---- p(n+4) ---->
Figure 1: An example of redundant transmission
图1：冗余传输示例
The use of this approach does not require signaling at the session setup. In other words, the speech sender can choose to use this scheme without consulting the receiver. This is because a packet containing redundant frames will not look different from a packet with only new frames. The receiver may receive multiple copies or versions of a frame for a certain timestamp if no packet is lost. If multiple versions of the same speech frame are received, it is RECOMMENDED that the highest rate be used by the speech decoder.
这种方法的使用不需要在会话设置时发送信令。换句话说，语音发送方可以选择使用该方案，而无需咨询接收方。这是因为包含冗余帧的数据包与仅包含新帧的数据包看起来没有什么不同。如果没有数据包丢失，则接收器可以接收特定时间戳的帧的多个副本或版本。如果接收到同一语音帧的多个版本，建议语音解码器使用最高速率。
This redundancy scheme provides the same functionality as that described in RFC 2198, "RTP Payload for Redundant Audio Data" [10]. In most cases, the mechanism in this payload format is more efficient and simpler than requiring both endpoints to support RFC 2198. If the spread in time required between the primary and redundant encodings is larger than 5 frame times, the bandwidth overhead of RFC 2198 will be lower.
该冗余方案提供与RFC 2198“冗余音频数据的RTP有效负载”[10]中所述相同的功能。在大多数情况下，这种有效负载格式的机制比要求两个端点都支持RFC 2198更高效、更简单。如果主编码和冗余编码之间所需的时间扩展大于5帧时间，则RFC 2198的带宽开销将更低。
The sender is responsible for selecting an appropriate amount of redundancy based on feedback about the channel (e.g., in RTCP receiver reports) or network traffic. A sender SHOULD NOT base selection of FEC on the CMR, as this parameter most probably was set based on non-IP information. The sender is also responsible for avoiding congestion, which may be aggravated by redundant transmission (see Section 7).
发送方负责根据有关信道（例如，在RTCP接收方报告中）或网络流量的反馈选择适当的冗余量。发送方不应基于CMR选择FEC，因为此参数很可能是基于非IP信息设置的。发送方还负责避免因冗余传输而加剧的拥塞（见第7节）。
To decrease protocol overhead, the octet-aligned payload format, described in Section 6, allows several speech frame-blocks to be encapsulated into a single RTP packet. One of the drawbacks of this approach is that in case of packet loss several consecutive speech frame-blocks are lost, which usually causes clearly audible distortion in the reconstructed speech.
为了减少协议开销，第6节中描述的八位字节对齐有效负载格式允许将多个语音帧块封装到单个RTP数据包中。这种方法的缺点之一是，在分组丢失的情况下，几个连续的语音帧块丢失，这通常会导致重构语音中明显的音频失真。
Interleaving of frame-blocks can improve the speech quality in such cases by distributing the consecutive losses into a series of single frame-block losses. However, interleaving and bundling several frame-blocks per payload will also increase end-to-end delay and is therefore not appropriate for all types of applications. Streaming applications will most likely be able to exploit interleaving to improve speech quality in lossy transmission conditions.
在这种情况下，帧块的交错可以通过将连续的损失分配到一系列单帧块损失中来改善语音质量。然而，每个有效负载交错和捆绑几个帧块也会增加端到端延迟，因此不适合所有类型的应用。流应用程序最有可能利用交织来改善有损传输条件下的语音质量。
The octet-aligned payload format supports the use of frame interleaving as an option. For the encoder (speech sender) to use frame interleaving in its outbound RTP packets for a given session, the decoder (speech receiver) needs to indicate its support via out-of-band means (see Section 9).
八位字节对齐的有效负载格式支持使用帧交错作为选项。对于编码器（语音发送器）在给定会话的出站RTP分组中使用帧交织，解码器（语音接收器）需要通过带外方式指示其支持（参见第9节）。
The primary scenario for this payload format is IP end-to-end between two terminals incorporating VMR-WB codec, as shown in Figure 2. Nevertheless, this scenario can be generalized to an interoperable interconnection between VMR-WB-enabled and AMR-WB-enabled IP terminals using the offer-answer model described in Section 9.3. This payload format is expected to be useful for both conversational and streaming services.
此有效负载格式的主要场景是包含VMR-WB编解码器的两个终端之间的IP端到端，如图2所示。然而，这种情况可以推广到使用第9.3节中描述的提供-应答模型，在启用VMR WB和启用AMR WB的IP终端之间实现互操作互连。这种有效负载格式预计对会话和流式服务都很有用。
+----------+ +----------+
| | | |
| TERMINAL |<----------------------->| TERMINAL |
| | VMR-WB/RTP/UDP/IP | |
+----------+ +----------+
(or AMR-WB/RTP/UDP/IP)
+----------+ +----------+
| | | |
| TERMINAL |<----------------------->| TERMINAL |
| | VMR-WB/RTP/UDP/IP | |
+----------+ +----------+
(or AMR-WB/RTP/UDP/IP)
Figure 2: IP terminal to IP terminal
图2:IP终端到IP终端
A conversational service puts requirements on the payload format. Low delay is a very important factor, i.e., fewer speech frame-blocks per payload packet. Low overhead is also required when the payload format traverses across low bandwidth links, especially if the frequency of packets will be high.
会话服务将需求放在有效负载格式上。低延迟是一个非常重要的因素，即每个有效负载数据包的语音帧块更少。当有效负载格式穿越低带宽链路时，特别是当数据包的频率较高时，也需要低开销。
Streaming service has less strict real-time requirements and therefore can use a larger number of frame-blocks per packet than conversational service. This reduces the overhead from IP, UDP, and RTP headers. However, including several frame-blocks per packet makes the transmission more vulnerable to packet loss, so interleaving may be used to reduce the effect of packet loss on speech quality. A streaming server handling a large number of clients also needs a payload format that requires as few resources as possible when doing packetization.
流式服务的实时性要求不那么严格，因此与会话服务相比，每个数据包可以使用更多的帧块。这减少了IP、UDP和RTP头的开销。然而，每个分组包括几个帧块使得传输更容易受到分组丢失的影响，因此可以使用交织来减少分组丢失对语音质量的影响。处理大量客户端的流式服务器还需要一种有效负载格式，在进行打包时需要尽可能少的资源。
For VMR-WB-enabled IP terminals at both ends, depending on the implementation, all modes of the VMR-WB codec can be used in this scenario. Also, both header-free and octet-aligned payload formats (see Section 6 for details) can be utilized. For the interoperable interconnection between VMR-WB and AMR-WB, only VMR-WB mode 3 is used, and all restrictions described in Section 9.3 apply.
对于两端启用VMR WB的IP终端，根据实现情况，在此场景中可以使用VMR-WB编解码器的所有模式。此外，可以使用无报头和八位字节对齐的有效负载格式（详见第6节）。对于VMR-WB和AMR-WB之间的互操作互连，仅使用VMR-WB模式3，第9.3节中描述的所有限制均适用。
Another scenario occurs when VMR-WB-encoded speech will be transmitted from a non-IP system (e.g., 3GPP2/CDMA2000 network) to an IP terminal, and/or vice versa, as depicted in Figure 3.
如图3所示，当VMR WB编码语音将从非IP系统（例如，3GPP2/CDMA2000网络）传输到IP终端和/或反之亦然时，会出现另一种情况。
VMR-WB over
3GPP2/CDMA2000 network
+------+ +----------+
| | | |
<-------------->| GW |<---------------------->| TERMINAL |
| | VMR-WB/RTP/UDP/IP | |
+------+ +----------+
|
| IP network
|
VMR-WB over
3GPP2/CDMA2000 network
+------+ +----------+
| | | |
<-------------->| GW |<---------------------->| TERMINAL |
| | VMR-WB/RTP/UDP/IP | |
+------+ +----------+
|
| IP network
|
Figure 3: GW to VoIP terminal scenario
图3:GW到VoIP终端场景
VMR-WB's capability to switch seamlessly between operational modes is exploited in CDMA (non-IP) networks to optimize speech quality for a given traffic condition. To preserve this functionality in scenarios including a gateway to an IP network using the octet-aligned payload format, a codec mode request (CMR) field is considered. The gateway will be responsible for forwarding the CMR between the non-IP and IP parts in both directions. The IP terminal SHOULD follow the CMR forwarded by the gateway to optimize speech quality going to the non-IP decoder. The mode control algorithm in the gateway SHOULD accommodate the delay imposed by the IP network on the response to CMR by the IP terminal.
VMR-WB在CDMA（非IP）网络中利用其在操作模式之间无缝切换的能力来优化给定流量条件下的语音质量。为了在使用八位字节对齐有效负载格式的IP网络网关等场景中保留此功能，需要考虑编解码器模式请求（CMR）字段。网关将负责在非IP和IP部分之间双向转发CMR。IP终端应遵循网关转发的CMR，以优化到非IP解码器的语音质量。网关中的模式控制算法应适应IP网络对IP终端对CMR的响应施加的延迟。
The IP terminal SHOULD NOT set the CMR (see Section 6.3.2), but the gateway can set the CMR value on frames going toward the encoder in the non-IP part to optimize speech quality from that encoder to the gateway and to perform congestion control on the IP network.
IP终端不应设置CMR（参见第6.3.2节），但网关可以在非IP部分中朝向编码器的帧上设置CMR值，以优化从编码器到网关的语音质量，并在IP网络上执行拥塞控制。
A third likely scenario is that RTP/UDP/IP is used as transport between two non-IP systems, i.e., IP is originated and terminated in gateways on both sides of the IP transport, as illustrated in Figure 4. This is the most likely scenario for an interoperable interconnection between 3GPP/(GSM-WCDMA)/AMR-WB and 3GPP2/CDMA2000/VMR-WB-enabled mobile stations. In this scenario, the VMR-WB-enabled terminal also declares itself capable of AMR-WB with restricted mode set as described in Section 9.3. The CMR value may be set in packets received by the gateways on the IP network side. The gateway should forward to the non-IP side a CMR value that is the
第三种可能的情况是，RTP/UDP/IP用作两个非IP系统之间的传输，即，IP在IP传输两侧的网关中发起和终止，如图4所示。这是3GPP/（GSM-WCDMA）/AMR-WB和支持3GPP2/CDMA2000/VMR-WB的移动站之间最有可能实现互操作互连的场景。在这种情况下，启用VMR WB的终端还声明自己能够使用第9.3节所述的受限模式设置AMR-WB。可以在IP网络侧的网关接收的分组中设置CMR值。网关应向非IP侧转发一个CMR值，该值为
minimum of three values: (1) the CMR value it receives on the IP side; (2) a CMR value it may choose for congestion control of transmission on the IP side; and (3) the CMR value based on its estimate of reception quality on the non-IP side. The details of the traffic control algorithm are left to the implementation.
至少三个值：（1）它在IP端接收的CMR值；（2） 它可以选择用于IP侧传输的拥塞控制的CMR值；和（3）基于其对非IP侧的接收质量的估计的CMR值。流量控制算法的细节留待实现。
VMR-WB over AMR-WB over 3GPP2/CDMA2000 network 3GPP/(GSM-WCDMA) network
VMR-WB over AMR-WB over 3GPP2/CDMA2000网络3GPP/（GSM-WCDMA）网络
+------+ +------+
(AMR-WB Payload) | | AMR-WB/RTP/UDP/IP| |(AMR-WB Payload)
<---------------->| GW |<---------------->| GW |<--------------->
| | | |
+------+ +------+
| IP network |
| |
+------+ +------+
(AMR-WB Payload) | | AMR-WB/RTP/UDP/IP| |(AMR-WB Payload)
<---------------->| GW |<---------------->| GW |<--------------->
| | | |
+------+ +------+
| IP network |
| |
Figure 4: GW to GW scenario (AMR-WB <-> VMR-WB interoperable interconnection)
图4:GW到GW场景（AMR-WB<->VMR-WB互操作互连）
During and upon initiation of an interoperable interconnection between VMR-WB and AMR-WB, only VMR-WB mode 3 can be used. There are three Frame Types (i.e., FT=0, 1, or 2; see Table 3) within this mode that are compatible with AMR-WB codec modes 0, 1, and 2, respectively. If the AMR-WB codec is engaged in an interoperable interconnection with VMR-WB, the active AMR-WB codec mode set needs to be limited to 0, 1, and 2.
在启动VMR-WB和AMR-WB之间的互操作互连期间和之后，只能使用VMR-WB模式3。此模式中有三种帧类型（即FT=0、1或2；见表3），分别与AMR-WB编解码器模式0、1和2兼容。如果AMR-WB编解码器与VMR-WB进行互操作互连，则活动AMR-WB编解码器模式集需要限制为0、1和2。
The fourth example VoIP scenario is composed of a RTP/UDP/IP transport between two non-IP systems; i.e., IP is originated and terminated in gateways on both sides of the IP transport, as illustrated in Figure 5. This is the most likely scenario for Mobile-Station-to-Mobile-Station (MS-to-MS) Transcoder-Free (TrFO) interconnection between two 3GPP2/CDMA2000 terminals that both use VMR-WB codec.
第四个示例VoIP场景由两个非IP系统之间的RTP/UDP/IP传输组成；i、 例如，IP在IP传输的两侧的网关中发起和终止，如图5所示。这是两个均使用VMR-WB编解码器的3GPP2/CDMA2000终端之间的移动站到移动站（MS到MS）无转码（TrFO）互连的最可能场景。
VMR-WB over VMR-WB over 3GPP2/CDMA2000 network 3GPP2/CDMA2000 network
VMR-WB over VMR-WB over 3GPP2/CDMA2000网络3GPP2/CDMA2000网络
+------+ +------+
| | | |
<------------>| GW |<----------------->| GW |<------------>
| | VMR-WB/RTP/UDP/IP | |
+------+ +------+
| IP network |
| |
+------+ +------+
| | | |
<------------>| GW |<----------------->| GW |<------------>
| | VMR-WB/RTP/UDP/IP | |
+------+ +------+
| IP network |
| |
Figure 5: GW to GW scenario (a CDMA2000 MS-to-MS VoIP scenario)
图5:GW到GW场景（CDMA2000 MS到MS VoIP场景）
For a given session, the payload format can be either header free or octet aligned, depending on the mode of operation that is established for the session via out-of-band means and the application.
对于给定会话，有效负载格式可以是无报头的或八位字节对齐的，这取决于通过带外装置和应用程序为会话建立的操作模式。
The header-free payload format is designed for maximum bandwidth efficiency, simplicity, and low latency. Only one codec data frame can be sent in each header-free payload format packet. None of the payload header fields or table of contents (ToC) entries is present (the same consideration is also made in [11]).
无报头有效负载格式旨在实现最大的带宽效率、简单性和低延迟。在每个无报头有效负载格式数据包中只能发送一个编解码器数据帧。不存在任何有效载荷标题字段或目录（ToC）条目（在[11]中也进行了同样的考虑）。
In the octet-aligned payload format, all the fields in a payload, including payload header, table of contents entries, and speech frames themselves, are individually aligned to octet boundaries to make implementations efficient.
在八位字节对齐的有效负载格式中，有效负载中的所有字段（包括有效负载标头、目录条目和语音帧本身）都单独与八位字节边界对齐，以提高实现效率。
Note that octet alignment of a field or payload means that the last octet is padded with zeroes in the least significant bits to fill the octet. Also note that this padding is separate from padding indicated by the P bit in the RTP header.
请注意，字段或有效负载的八位字节对齐意味着最后一个八位字节用最低有效位中的零填充，以填充八位字节。还要注意，此填充与RTP头中的P位指示的填充是分开的。
Between the two payload formats, only the octet-aligned format has the capability to use the interleaving to make the speech transport robust to packet loss.
在这两种有效载荷格式之间，只有八位组对齐格式能够使用交织，使语音传输对分组丢失具有鲁棒性。
The VMR-WB octet-aligned payload format in the interoperable mode is identical to that of AMR-WB (i.e., RFC 3267).
互操作模式下的VMR-WB八位组对齐有效负载格式与AMR-WB（即RFC 3267）相同。
The format of the RTP header is specified in [3]. This payload format uses the fields of the header in a manner consistent with that specification.
RTP标头的格式在[3]中指定。此有效负载格式以与该规范一致的方式使用报头的字段。
The RTP timestamp corresponds to the sampling instant of the first sample encoded for the first frame-block in the packet. The timestamp clock frequency is the same as the default sampling frequency (i.e., 16 kHz), so the timestamp unit is in samples.
RTP时间戳对应于为分组中的第一帧块编码的第一样本的采样瞬间。时间戳时钟频率与默认采样频率（即16 kHz）相同，因此时间戳单元在采样中。
The duration of one speech frame-block is 20 ms for VMR-WB. For normal wideband operation of VMR-WB, the input/output media sampling frequency is 16 kHz, corresponding to 320 samples per frame from each channel. Thus, the timestamp is increased by 320 for VMR-WB for each consecutive frame-block.
VMR-WB的一个语音帧块的持续时间为20ms。对于VMR-WB的正常宽带操作，输入/输出媒体采样频率为16 kHz，对应于每个通道每帧320个采样。因此，对于每个连续帧块，VMR-WB的时间戳增加320。
The VMR-WB codec is capable of processing speech/audio signals sampled at 8 kHz. By default, the VMR-WB decoder output sampling frequency is 16 kHz. Depending on the application, the decoder can be configured to generate 8-kHz output sampling frequency, as well. Since the VMR-WB RTP payload formats for the 8- and 16-kHz sampled media are identical and the VMR-WB decoder does not need a priori knowledge about the encoder input sampling frequency, a fixed RTP clock rate of 16000 Hz is defined for VMR-WB codec. This would allow injection or processing of 8-kHz sampled speech/audio media without having to change the RTP clock rate during a session. Note that the timestamp is incremented by 320 per frame-block for 8-kHz sampled media, as well.
VMR-WB编解码器能够处理以8 kHz采样的语音/音频信号。默认情况下，VMR-WB解码器输出采样频率为16 kHz。根据应用，解码器也可配置为产生8-kHz输出采样频率。由于8 kHz和16 kHz采样介质的VMR-WB RTP有效载荷格式相同，并且VMR-WB解码器不需要关于编码器输入采样频率的先验知识，因此为VMR-WB编解码器定义16000 Hz的固定RTP时钟频率。这将允许注入或处理8-kHz采样语音/音频媒体，而无需在会话期间更改RTP时钟速率。请注意，对于8-kHz采样媒体，时间戳也会每帧块增加320。
A packet may contain multiple frame-blocks of encoded speech or comfort noise parameters. If interleaving is employed, the frame-blocks encapsulated into a payload are picked according to the interleaving rules defined in Section 6.3.2. Otherwise, each packet covers a period of one or more contiguous 20-ms frame-block intervals. In case the data from all the channels for a particular frame-block in the period is missing (for example, at a gateway from some other transport format), it is possible to indicate that no data is present for that frame-block instead of breaking a multi-frame-block packet into two, as explained in Section 6.3.2.
分组可以包含编码语音或舒适噪声参数的多个帧块。如果采用交织，则根据第6.3.2节中定义的交织规则拾取封装到有效载荷中的帧块。否则，每个分组覆盖一个或多个连续的20ms帧块间隔的周期。如果周期内某个特定帧块的所有通道的数据丢失（例如，在某个其他传输格式的网关处），则可以指示该帧块不存在任何数据，而不是将多帧块分组一分为二，如第6.3.2节所述。
No matter which payload format is used, the RTP payload is always made an integral number of octets long by padding with zero bits if necessary. If additional padding is required to bring the payload length to a larger multiple of octets or for some other purpose, then the P bit in the RTP header MAY be set, and padding appended, as specified in [3].
无论使用哪种有效负载格式，RTP有效负载总是由整数个八位字节组成，如果需要，可以用零位填充。如果需要额外的填充以使有效负载长度达到八位字节的更大倍数或出于某些其他目的，则可以按照[3]中的规定设置RTP报头中的P位，并附加填充。
The RTP header marker bit (M) SHALL be always set to 0 if the VMR-WB codec operates in continuous transmission. When operating in discontinuous transmission (DTX), the RTP header marker bit SHALL be set to 1 if the first frame-block carried in the packet contains a speech frame, which is the first in a talkspurt. For all other packets, the marker bit SHALL be set to zero (M=0).
如果VMR-WB编解码器在连续传输中运行，RTP头标记位（M）应始终设置为0。在不连续传输（DTX）中操作时，如果包中携带的第一个帧块包含语音帧，则RTP报头标记位应设置为1，语音帧是TalkSput中的第一个。对于所有其他数据包，标记位应设置为零（M=0）。
The assignment of an RTP payload type for this payload format is outside the scope of this document and will not be specified here. It is expected that the RTP profile under which this payload format is being used will assign a payload type for this encoding or specify that the payload type is to be bound dynamically (see Section 9).
此有效负载格式的RTP有效负载类型的分配超出了本文档的范围，此处将不进行指定。预计使用此有效负载格式的RTP配置文件将为此编码分配有效负载类型，或指定动态绑定有效负载类型（参见第9节）。
The header-free payload format is designed for maximum bandwidth efficiency, simplicity, and minimum delay. Only one speech data frame presents in each header-free payload format packet. None of the payload header fields or ToC entries is present. The encoding rate for the speech frame can be determined from the length of the speech data frame, since there is only one speech data frame in each header-free payload format.
无报头有效负载格式旨在实现最大带宽效率、简单性和最小延迟。每个无报头有效载荷格式数据包中仅显示一个语音数据帧。不存在任何有效负载标头字段或ToC条目。语音帧的编码速率可以根据语音数据帧的长度来确定，因为每个无报头有效载荷格式中只有一个语音数据帧。
The use of the RTP header fields for header-free payload format is the same as the corresponding one for the octet-aligned payload format. The detailed bit mapping of speech data packets permissible for this payload format is described in Section 8 of [1]. Since the header-free payload format is not compatible with AMR-WB RTP payload, only non-interoperable modes of VMR-WB SHALL be used with this payload format. That is, FT=0, 1, 2, and 9 SHALL NOT be used with header-free payload format.
无报头有效负载格式的RTP报头字段的使用与八位字节对齐有效负载格式的相应字段相同。[1]第8节描述了该有效载荷格式允许的语音数据包的详细位映射。由于无报头有效载荷格式与AMR-WB RTP有效载荷不兼容，因此只有VMR-WB的不可互操作模式可用于此有效载荷格式。也就是说，FT=0、1、2和9不得与无报头有效载荷格式一起使用。
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 [3] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+ ONLY one speech data frame +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [3] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+ ONLY one speech data frame +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that the mode of operation, using this payload format, is decided by the transmitting (encoder) site. The default mode of operation for VMR-WB encoder is mode 0 [1]. The mode change request MAY also be sent through non-RTP means, which is out of the scope of this specification.
请注意，使用此有效负载格式的操作模式由传输（编码器）站点决定。VMR-WB编码器的默认操作模式为模式0[1]。模式改变请求也可以通过非RTP方式发送，这超出了本规范的范围。
The complete payload consists of a payload header, a payload table of contents, and speech data representing one or more speech frame-blocks. The following diagram shows the general payload format layout:
完整的有效载荷包括有效载荷头部、有效载荷目录和表示一个或多个语音帧块的语音数据。下图显示了一般有效负载格式布局：
+----------------+-------------------+----------------
| Payload header | Table of contents | Speech data ...
+----------------+-------------------+----------------
+----------------+-------------------+----------------
| Payload header | Table of contents | Speech data ...
+----------------+-------------------+----------------
In octet-aligned payload format, the payload header consists of a 4-bit CMR, 4 reserved bits, and, optionally, an 8-bit interleaving header, as shown below.
在八位组对齐的有效负载格式中，有效负载报头由4位CMR、4个保留位和可选的8位交织报头组成，如下所示。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+- - - - - - - -
| CMR |R|R|R|R| ILL | ILP |
+-+-+-+-+-+-+-+-+- - - - - - - -
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+- - - - - - - -
| CMR |R|R|R|R| ILL | ILP |
+-+-+-+-+-+-+-+-+- - - - - - - -
CMR (4 bits): This indicates a codec mode request sent to the speech encoder at the site of the receiver of this payload. CMR value 15 indicates that no mode request is present, and other unused values are reserved for future use.
CMR（4位）：这表示发送到该有效负载接收器站点的语音编码器的编解码器模式请求。CMR值15表示不存在模式请求，其他未使用的值保留供将来使用。
The value of the CMR field is set according to the following table:
根据下表设置CMR字段的值：
+-------+----------------------------------------------------------+
| CMR | VMR-WB Operating Modes |
+-------+----------------------------------------------------------+
| 0 | VMR-WB mode 3 (AMR-WB interoperable mode at 6.60 kbps) |
| 1 | VMR-WB mode 3 (AMR-WB interoperable mode at 8.85 kbps) |
| 2 | VMR-WB mode 3 (AMR-WB interoperable mode at 12.65 kbps) |
| 3 | VMR-WB mode 2 |
| 4 | VMR-WB mode 1 |
| 5 | VMR-WB mode 0 |
| 6 | VMR-WB mode 2 with maximum half-rate encoding |
| 7-14 | (reserved) |
| 15 | No Preference (no mode request is present) |
+-------+----------------------------------------------------------+
+-------+----------------------------------------------------------+
| CMR | VMR-WB Operating Modes |
+-------+----------------------------------------------------------+
| 0 | VMR-WB mode 3 (AMR-WB interoperable mode at 6.60 kbps) |
| 1 | VMR-WB mode 3 (AMR-WB interoperable mode at 8.85 kbps) |
| 2 | VMR-WB mode 3 (AMR-WB interoperable mode at 12.65 kbps) |
| 3 | VMR-WB mode 2 |
| 4 | VMR-WB mode 1 |
| 5 | VMR-WB mode 0 |
| 6 | VMR-WB mode 2 with maximum half-rate encoding |
| 7-14 | (reserved) |
| 15 | No Preference (no mode request is present) |
+-------+----------------------------------------------------------+
Table 2: List of valid CMR values and their associated VMR-WB operating modes
表2：有效CMR值及其相关VMR-WB操作模式列表
R: This is a reserved bit that MUST be set to zero. The receiver MUST ignore all R bits.
R：这是一个必须设置为零的保留位。接收器必须忽略所有R位。
ILL (4 bits, unsigned integer): This is an OPTIONAL field that is present only if interleaving is signaled out-of-band for the session. ILL=L indicates to the receiver that the interleaving length is L+1, in number of frame-blocks.
ILL（4位，无符号整数）：这是一个可选字段，只有在会话的带外信号为交织时才会出现。ILL=L向接收机指示交织长度为L+1，以帧块为单位。
ILP (4 bits, unsigned integer): This is an OPTIONAL field that is present only if interleaving is signaled. ILP MUST take a value between 0 and ILL, inclusive, indicating the interleaving index for frame-blocks in this payload in the interleave group. If the value of ILP is found greater than ILL, the payload SHOULD be discarded.
ILP（4位，无符号整数）：这是一个可选字段，仅当发出交织信号时才显示。ILP必须取一个介于0和ILL（包括0和ILL）之间的值，指示交织组中此有效负载中的帧块的交织索引。如果发现ILP的值大于ILL，则应丢弃有效负载。
ILL and ILP fields MUST be present in each packet in a session if interleaving is signaled for the session.
如果为会话发出交织信号，则会话中的每个数据包中必须存在ILL和ILP字段。
The mode request received in the CMR field is valid until the next CMR is received, i.e., until a newly received CMR value overrides the previous one. Therefore, if a terminal continuously wishes to receive frames in the same mode, x, it needs to set CMR=x for all its outbound payloads, and if a terminal has no preference in which mode to receive, it SHOULD set CMR=15 in all its outbound payloads.
在收到下一个CMR之前，在CMR字段中收到的模式请求有效，即，直到新收到的CMR值覆盖上一个CMR值。因此，如果终端持续希望以相同的模式x接收帧，则需要为其所有出站有效载荷设置CMR＝x，并且如果终端没有在哪种模式下接收的偏好，则应在其所有出站有效载荷中设置CMR＝15。
If a payload is received with a CMR value that is not valid, the CMR MUST be ignored by the receiver.
如果使用无效的CMR值接收有效负载，则接收器必须忽略CMR。
In a multi-channel session, CMR SHOULD be interpreted by the receiver of the payload as the desired encoding mode for all the channels in the session, if the network allows.
在多信道会话中，如果网络允许，有效负载的接收器应将CMR解释为会话中所有信道的期望编码模式。
There are two factors that affect the VMR-WB mode selection: (i) the performance of any CDMA link connected via a gateway (e.g., in a GW to IP terminal scenario), and (ii) the congestion state of an IP network. The CDMA link performance is signaled via the CMR field, which is not used by IP-only end-points. The IP network state is monitored using, for example, RTCP. A sender needs to select the operating mode to satisfy both these constraints (see Section 7).
影响VMR-WB模式选择的因素有两个：（i）通过网关连接的任何CDMA链路的性能（例如，在GW到IP终端的情况下），以及（ii）IP网络的拥塞状态。CDMA链路性能通过CMR字段发出信号，该字段不被仅IP端点使用。IP网络状态使用例如RTCP进行监控。发送器需要选择运行模式以满足这两个约束（参见第7节）。
The encoder SHOULD follow a received mode request, but MAY change to a different mode if the network necessitates it, for example, to control congestion.
编码器应遵循接收到的模式请求，但如果网络需要（例如）控制拥塞，则编码器可改变为不同的模式。
The CMR field MUST be set to 15 for packets sent to a multicast group. The encoder in the speech sender SHOULD ignore mode requests when sending speech to a multicast session but MAY use RTCP feedback information as a hint that a mode change is needed.
对于发送到多播组的数据包，必须将CMR字段设置为15。向多播会话发送语音时，语音发送器中的编码器应忽略模式请求，但可使用RTCP反馈信息作为需要更改模式的提示。
If interleaving option is utilized, interleaving MUST be performed on a frame-block basis, as opposed to a frame basis, in a multi-channel session.
如果使用了交织选项，则必须在多信道会话中以帧块为基础而不是以帧为基础执行交织。
The following example illustrates the arrangement of speech frame-blocks in an interleave group during an interleave session. Here we assume ILL=L for the interleave group that starts at speech frame-block n. We also assume that the first payload packet of the interleave group is s and the number of speech frame-blocks carried in each payload is N. Then we will have
以下示例说明在交织会话期间交织组中语音帧块的排列。这里，我们假设从语音帧块n开始的交织组为ILL=L。我们还假设交织组的第一个有效载荷分组是s，并且每个有效载荷中携带的语音帧块的数量是N。然后我们将
Payload s (the first packet of this interleave group): ILL=L, ILP=0,
有效负载s（该交织组的第一个数据包）：ILL=L，ILP=0，
Carry frame-blocks: n, n+(L+1), n+2*(L+1),..., n+(N-1)*(L+1)
Carry frame-blocks: n, n+(L+1), n+2*(L+1),..., n+(N-1)*(L+1)
Payload s+1 (the second packet of this interleave group):
ILL=L, ILP=1,
Carry frame-blocks: n+1, n+1+(L+1), n+1+2*(L+1),..., n+1+
(N-1)*(L+1)
Payload s+1 (the second packet of this interleave group):
ILL=L, ILP=1,
Carry frame-blocks: n+1, n+1+(L+1), n+1+2*(L+1),..., n+1+
(N-1)*(L+1)
...
...
Payload s+L (the last packet of this interleave group):
ILL=L, ILP=L,
Carry frame-blocks: n+L, n+L+(L+1), n+L+2*(L+1), ..., n+L+
(N-1)*(L+1)
Payload s+L (the last packet of this interleave group):
ILL=L, ILP=L,
Carry frame-blocks: n+L, n+L+(L+1), n+L+2*(L+1), ..., n+L+
(N-1)*(L+1)
The next interleave group will start at frame-block n+N*(L+1). There will be no interleaving effect unless the number of frame-blocks per packet (N) is at least 2. Moreover, the number of frame-blocks per payload (N) and the value of ILL MUST NOT be changed inside an interleave group. In other words, all payloads in an interleave group MUST have the same ILL and MUST contain the same number of speech frame-blocks.
下一个交织组将从帧块n+n*（L+1）开始。除非每个包（N）的帧块数至少为2，否则将不会有交织效果。此外，每个有效负载的帧块数（N）和ILL的值不得在交织组内改变。换句话说，交织组中的所有有效负载必须具有相同的ILL，并且必须包含相同数量的语音帧块。
The sender of the payload MUST only apply interleaving if the receiver has signaled its use through out-of-band means. Since interleaving will increase buffering requirements at the receiver, the receiver uses MIME parameter "interleaving=I" to set the maximum number of frame-blocks allowed in an interleaving group to I.
如果接收器已通过带外方式发出使用信号，则有效载荷的发送方必须仅应用交织。由于交织将增加接收机处的缓冲要求，接收机使用MIME参数“interleaving=I”将交织组中允许的最大帧块数设置为I。
When performing interleaving, the sender MUST use a proper number of frame-blocks per payload (N) and ILL so that the resulting size of an interleave group is less than or equal to I, i.e., N*(L+1)<=I.
当执行交织时，发送方必须为每个有效载荷（N）和ILL使用适当数量的帧块，以便交织组的结果大小小于或等于I，即，N*（L+1）<=I。
The following example shows the ToC of three consecutive packets, each carrying 3 frame-blocks, in an interleaved two-channel session.
以下示例显示了在交织双信道会话中三个连续分组的ToC，每个分组携带3个帧块。
Here, the two channels are left (L) and right (R), with L coming before R, and the interleaving length is 3 (i.e., ILL=2). This makes the interleave group 9 frame-blocks large.
这里，两个信道是左（L）和右（R），其中L在R之前，并且交织长度是3（即，ILL＝2）。这使得交织组9帧块变大。
Packet #1
---------
Packet #1
---------
ILL=2, ILP=0:
+----+----+----+----+----+----+
| 1L | 1R | 4L | 4R | 7L | 7R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame Frame Frame
Block 1 Block 4 Block 7
ILL=2, ILP=0:
+----+----+----+----+----+----+
| 1L | 1R | 4L | 4R | 7L | 7R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame Frame Frame
Block 1 Block 4 Block 7
Packet #2
---------
Packet #2
---------
ILL=2, ILP=1:
ILL=2，ILP=1：
+----+----+----+----+----+----+
| 2L | 2R | 5L | 5R | 8L | 8R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame Frame Frame
Block 2 Block 5 Block 8
+----+----+----+----+----+----+
| 2L | 2R | 5L | 5R | 8L | 8R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame Frame Frame
Block 2 Block 5 Block 8
Packet #3
---------
Packet #3
---------
ILL=2, ILP=2:
+----+----+----+----+----+----+
| 3L | 3R | 6L | 6R | 9L | 9R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame Frame Frame
Block 3 Block 6 Block 9
ILL=2, ILP=2:
+----+----+----+----+----+----+
| 3L | 3R | 6L | 6R | 9L | 9R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame Frame Frame
Block 3 Block 6 Block 9
The table of contents (ToC) in octet-aligned payload format consists of a list of ToC entries where each entry corresponds to a speech frame carried in the payload, i.e., when interleaving is used, the frame-blocks in the ToC will almost never be placed consecutive in time. Instead, the presence and order of the frame-blocks in a packet will follow the pattern described in 6.3.2.
八位字节对齐的有效载荷格式的目录（ToC）由ToC条目列表组成，其中每个条目对应于有效载荷中携带的语音帧，即，当使用交织时，ToC中的帧块几乎永远不会在时间上连续放置。相反，数据包中帧块的存在和顺序将遵循6.3.2中描述的模式。
+---------------------+
| list of ToC entries |
+---------------------+
+---------------------+
| list of ToC entries |
+---------------------+
A ToC entry for the octet-aligned payload format is as follows:
八位字节对齐有效负载格式的ToC条目如下所示：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F| FT |Q|P|P|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F| FT |Q|P|P|
+-+-+-+-+-+-+-+-+
The table of contents (ToC) consists of a list of ToC entries, each representing a speech frame.
目录（ToC）由ToC条目列表组成，每个条目代表一个语音帧。
F (1 bit): If set to 1, indicates that this frame is followed by another speech frame in this payload; if set to 0, indicates that this frame is the last frame in this payload.
F（1位）：如果设置为1，则表示此帧后面跟着此有效负载中的另一个语音帧；如果设置为0，则表示此帧是此有效负载中的最后一帧。
FT (4 bits): Frame type index whose value is chosen according to Table 3.
FT（4位）：帧类型索引，其值根据表3选择。
During the interoperable mode, FT=14 (SPEECH_LOST) and FT=15 (NO_DATA) are used to indicate frames that are either lost or not being transmitted in this payload, respectively. FT=14 or 15 MAY be used in the non-interoperable modes to indicate frame erasure or blank frame, respectively (see Section 2.1 of [1]).
在可互操作模式期间，FT=14（语音丢失）和FT=15（无数据）分别用于指示在该有效载荷中丢失或未传输的帧。FT=14或15可用于非互操作模式，分别表示帧擦除或空白帧（见[1]第2.1节）。
If a payload with an invalid FT value is received, the payload MUST be discarded. Note that for ToC entries with FT=14 or 15, there will be no corresponding speech frame in the payload.
如果接收到具有无效FT值的有效负载，则必须丢弃该有效负载。请注意，对于FT=14或15的ToC条目，有效负载中将没有相应的语音帧。
Depending on the application and the mode of operation of VMR-WB, any combination of the permissible frame types (FT) shown in Table 3 MAY be used.
根据VMR-WB的应用和运行模式，可使用表3所示的任何允许框架类型（FT）组合。
Q (1 bit): Frame quality indicator. If set to 0, indicates that the corresponding frame is corrupted. During the interoperable mode, the receiver side (with AMR-WB codec) should set the RX_TYPE to either SPEECH_BAD or SID_BAD depending on the frame type (FT), if Q=0. The VMR-WB encoder always sets Q bit to 1. The VMR-WB decoder may ignore the Q bit.
Q（1位）：帧质量指示器。如果设置为0，则表示相应的帧已损坏。在可互操作模式下，如果Q=0，接收器端（使用AMR-WB编解码器）应根据帧类型（FT）将RX_类型设置为SPEECH_BAD或SID_BAD。VMR-WB编码器始终将Q位设置为1。VMR-WB解码器可能忽略Q位。
P bits: Padding bits MUST be set to zero and MUST be ignored by a receiver.
P位：填充位必须设置为零，并且必须被接收器忽略。
+----+--------------------------------------------+-----------------+
| FT | Encoding Rate |Frame Size (Bits)|
+----+--------------------------------------------+-----------------+
| 0 | Interoperable Full-Rate (AMR-WB 6.60 kbps) | 132 |
| 1 | Interoperable Full-Rate (AMR-WB 8.85 kbps) | 177 |
| 2 | Interoperable Full-Rate (AMR-WB 12.65 kbps)| 253 |
| 3 | Full-Rate 13.3 kbps | 266 |
| 4 | Half-Rate 6.2 kbps | 124 |
| 5 | Quarter-Rate 2.7 kbps | 54 |
| 6 | Eighth-Rate 1.0 kbps | 20 |
| 7 | (reserved) | - |
| 8 | (reserved) | - |
| 9 | CNG (AMR-WB SID) | 40 |
| 10 | (reserved) | - |
| 11 | (reserved) | - |
| 12 | (reserved) | - |
| 13 | (reserved) | - |
| 14 | Erasure (AMR-WB SPEECH_LOST) | 0 |
| 15 | Blank (AMR-WB NO_DATA) | 0 |
+----+--------------------------------------------+-----------------+
+----+--------------------------------------------+-----------------+
| FT | Encoding Rate |Frame Size (Bits)|
+----+--------------------------------------------+-----------------+
| 0 | Interoperable Full-Rate (AMR-WB 6.60 kbps) | 132 |
| 1 | Interoperable Full-Rate (AMR-WB 8.85 kbps) | 177 |
| 2 | Interoperable Full-Rate (AMR-WB 12.65 kbps)| 253 |
| 3 | Full-Rate 13.3 kbps | 266 |
| 4 | Half-Rate 6.2 kbps | 124 |
| 5 | Quarter-Rate 2.7 kbps | 54 |
| 6 | Eighth-Rate 1.0 kbps | 20 |
| 7 | (reserved) | - |
| 8 | (reserved) | - |
| 9 | CNG (AMR-WB SID) | 40 |
| 10 | (reserved) | - |
| 11 | (reserved) | - |
| 12 | (reserved) | - |
| 13 | (reserved) | - |
| 14 | Erasure (AMR-WB SPEECH_LOST) | 0 |
| 15 | Blank (AMR-WB NO_DATA) | 0 |
+----+--------------------------------------------+-----------------+
Table 3: VMR-WB payload frame types for real-time transport
表3：用于实时传输的VMR-WB有效负载帧类型
For multi-channel sessions, the ToC entries of all frames from a frame-block are placed in the ToC in consecutive order. Therefore, with N channels and K speech frame-blocks in a packet, there MUST be N*K entries in the ToC, and the first N entries will be from the first frame-block, the second N entries will be from the second frame-block, and so on.
对于多通道会话，来自帧块的所有帧的ToC条目以连续顺序放置在ToC中。因此，对于分组中的N个信道和K个语音帧块，ToC中必须有N×K个条目，并且前N个条目将来自第一帧块，第二N个条目将来自第二帧块，依此类推。
Speech data of a payload contains one or more speech frames as described in the ToC of the payload.
有效载荷的语音数据包含一个或多个语音帧，如有效载荷的ToC中所述。
Each speech frame represents 20 ms of speech encoded in one of the available encoding rates depending on the operation mode. The length of the speech frame is defined by the frame type in the FT field, with the following considerations:
根据操作模式，每个语音帧表示以可用编码速率之一编码的20ms语音。语音帧的长度由FT字段中的帧类型定义，并考虑以下因素：
- The last octet of each speech frame MUST be padded with zeroes at the end if not all bits in the octet are used. In other words, each speech frame MUST be octet-aligned.
- 如果没有使用八位字节中的所有位，则每个语音帧的最后一个八位字节必须在末尾用零填充。换句话说，每个语音帧必须是八位组对齐的。
- When multiple speech frames are present in the speech data, the speech frames MUST be arranged one whole frame after another.
- 当语音数据中存在多个语音帧时，语音帧必须一帧接一帧地排列。
The order and numbering notation of the speech data bits are as specified in the VMR-WB standard specification [1].
语音数据位的顺序和编号符号如VMR-WB标准规范[1]所规定。
The payload begins with the payload header of one octet, or two if frame interleaving is selected. The payload header is followed by the table of contents consisting of a list of one-octet ToC entries.
有效载荷以一个八位字节的有效载荷头开始，如果选择了帧交错，则以两个八位字节的有效载荷头开始。有效载荷标题后面是由一个八位字节ToC条目列表组成的目录。
The speech data follows the table of contents. For the purpose of packetization, all the octets comprising a speech frame are appended to the payload as a unit. The speech frames are packed in the same order as their corresponding ToC entries are arranged in the ToC list, with the exception that if a given frame has a ToC entry with FT=14 or 15, there will be no data octets present for that frame.
语音数据遵循目录。为了分组的目的，将构成语音帧的所有八位字节作为一个单元附加到有效载荷。语音帧的打包顺序与其对应的ToC条目在ToC列表中的排列顺序相同，但如果给定帧具有FT=14或15的ToC条目，则该帧将不存在数据八位字节。
6.3.5. Payload Example: Basic Single Channel Payload Carrying Multiple Frames
6.3.5. 有效载荷示例：承载多个帧的基本单信道有效载荷
The following diagram shows an octet-aligned payload format from a single channel session that carries two VMR-WB Full-Rate frames (FT=3). In the payload, a codec mode request is sent (e.g., CMR=4), requesting that the encoder at the receiver's side use VMR-WB mode 1. No interleaving is used. Note that in the example below the last octet in both speech frames is padded with zeros to make them octet aligned.
下图显示了单通道会话的八位字节对齐有效负载格式，该会话承载两个VMR-WB全速率帧（FT=3）。在有效载荷中，发送编解码器模式请求（例如，CMR＝4），请求接收器侧的编码器使用VMR-WB模式1。不使用交错。请注意，在下面的示例中，两个语音帧中的最后一个八位字节都用零填充，以使它们八位字节对齐。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CMR=4 |R|R|R|R|1|FT#1=3 |Q|P|P|0|FT#2=3 |Q|P|P| f1(0..7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f1(8..15) | f1(16..23) | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| r |P|P|P|P|P|P| f2(0..7) | f2(8..15) | f2(16..23) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | l |P|P|P|P|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CMR=4 |R|R|R|R|1|FT#1=3 |Q|P|P|0|FT#2=3 |Q|P|P| f1(0..7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f1(8..15) | f1(16..23) | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| r |P|P|P|P|P|P| f2(0..7) | f2(8..15) | f2(16..23) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | l |P|P|P|P|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r= f1(264,265)
l= f2(264,265)
r= f1(264,265)
l= f2(264,265)
An application implementing this payload format MUST understand all the payload parameters. Any mapping of the parameters to a signaling protocol MUST support all parameters. Therefore, an implementation of this payload format in an application using SDP is required to understand all the payload parameters in their SDP-mapped form. This requirement ensures that an implementation always can decide whether it is capable of communicating.
实现此有效负载格式的应用程序必须了解所有有效负载参数。参数到信令协议的任何映射都必须支持所有参数。因此，需要在使用SDP的应用程序中实现此有效负载格式，以了解SDP映射形式的所有有效负载参数。此要求确保实现始终可以决定是否能够通信。
To enable efficient interoperable interconnection with AMR-WB and to ensure that a VMR-WB terminal appropriately declares itself as a AMR-WB-capable terminal (see Section 9.3), it is also RECOMMENDED that a VMR-WB RTP payload implementation understand relevant AMR-WB signaling.
为了实现与AMR-WB的高效互操作互连，并确保VMR-WB终端适当地声明自己是具有AMR-WB能力的终端（参见第9.3节），还建议VMR-WB RTP有效负载实现了解相关的AMR-WB信令。
To further ensure interoperability between various implementations of VMR-WB, implementations SHALL support both header-free and octet-aligned payload formats. Support of interleaving is optional.
为了进一步确保VMR-WB各种实现之间的互操作性，实现应支持无报头和八位字节对齐的有效负载格式。支持交错是可选的。
When processing a received payload packet, if the receiver finds that the calculated payload length, based on the information of the session and the values found in the payload header fields, does not match the size of the received packet, the receiver SHOULD discard the packet to avoid potential degradation of speech quality and to invoke the VMR-WB built-in frame error concealment mechanism. Therefore, invalid packets SHALL be treated as lost packets.
当处理接收到的有效载荷分组时，如果接收机发现基于会话信息和在有效载荷报头字段中找到的值计算出的有效载荷长度与接收到的分组的大小不匹配，接收机应丢弃数据包，以避免语音质量的潜在下降，并调用VMR-WB内置帧错误隐藏机制。因此，无效数据包应视为丢失数据包。
Late packets (i.e., the unavailability of a packet when it is needed for decoding at the receiver) should be treated as lost packets. Furthermore, if the late packet is part of an interleave group, depending upon the availability of the other packets in that interleave group, decoding must be resumed from the next available frame (sequential order). In other words, the unavailability of a packet in an interleave group at a certain time should not invalidate the other packets within that interleave group that may arrive later.
延迟分组（即，当需要在接收器处解码时，分组不可用）应被视为丢失分组。此外，如果延迟分组是交织组的一部分，则取决于该交织组中其他分组的可用性，必须从下一可用帧（顺序）恢复解码。换言之，交织组中的分组在特定时间不可用不应使该交织组中可能稍后到达的其他分组无效。
The general congestion control considerations for transporting RTP data apply to VMR-WB speech over RTP as well. However, the multimode capability of VMR-WB speech codec may provide an advantage over other payload formats for controlling congestion since the bandwidth demand can be adjusted by selecting a different operating mode.
传输RTP数据的一般拥塞控制考虑也适用于RTP上的VMR-WB语音。然而，VMR-WB语音编解码器的多模能力可提供优于其他有效载荷格式的用于控制拥塞的优势，因为可以通过选择不同的操作模式来调整带宽需求。
Another parameter that may impact the bandwidth demand for VMR-WB is the number of frame-blocks that are encapsulated in each RTP payload. Packing more frame-blocks in each RTP payload can reduce the number of packets sent and hence the overhead from RTP/UDP/IP headers, at the expense of increased delay.
可能影响VMR-WB带宽需求的另一个参数是封装在每个RTP有效负载中的帧块数。在每个RTP有效负载中封装更多的帧块可以减少发送的数据包数量，从而减少RTP/UDP/IP报头的开销，但会增加延迟。
If forward error correction (FEC) is used to alleviate the packet loss, the amount of redundancy added by FEC will need to be regulated so that the use of FEC itself does not cause a congestion problem.
如果使用前向纠错（FEC）来减轻分组丢失，则需要调节FEC添加的冗余量，以便FEC本身的使用不会导致拥塞问题。
Congestion control for RTP SHALL be used in accordance with RFC 3550 [3] and any applicable RTP profile, for example, RFC 3551 [6]. This means that congestion control is required for any transmission over unmanaged best-effort networks.
RTP的拥塞控制应根据RFC 3550[3]和任何适用的RTP配置文件（例如RFC 3551[6]）使用。这意味着在非托管尽力而为网络上的任何传输都需要拥塞控制。
Congestion on the IP network is managed by the IP sender. Feedback about congestion SHOULD be provided to that IP sender through RTCP or other means, and then the sender can choose to avoid congestion using the most appropriate mechanism. That may include selecting an appropriate operating mode, but also includes adjusting the level of redundancy or number of frames per packet.
IP网络上的拥塞由IP发送方管理。关于拥塞的反馈应该通过RTCP或其他方式提供给IP发送方，然后发送方可以选择使用最合适的机制避免拥塞。这可能包括选择适当的操作模式，但也包括调整冗余级别或每个分组的帧数。
RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in RTP [3] and any applicable profile such as AVP [9] or SAVP [10].
使用本规范中定义的有效负载格式的RTP数据包受RTP[3]和任何适用配置文件（如AVP[9]或SAVP[10]）中讨论的一般安全注意事项的约束。
As this format transports encoded audio, the main security issues include confidentiality, integrity protection, and data origin authentication of the audio itself. The payload format itself does not have any built-in security mechanisms. Any suitable external mechanisms, such as SRTP [10], MAY be used.
由于这种格式传输编码音频，主要的安全问题包括机密性、完整性保护和音频本身的数据源身份验证。有效负载格式本身没有任何内置的安全机制。可以使用任何合适的外部机制，如SRTP[10]。
This payload format and the VMR-WB decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing; thus, they are unlikely to pose a denial-of-service threat due to the receipt of pathological data.
该有效载荷格式和VMR-WB解码器在用于分组处理的接收器侧计算复杂度方面不表现出任何显著的非均匀性；因此，由于收到病理数据，它们不太可能构成拒绝服务威胁。
In order to ensure confidentiality of the encoded audio, all audio data bits MUST be encrypted. There is less need to encrypt the payload header or the table of contents since they only carry information about the frame type. This information could also be useful to a third party, for example, for quality monitoring.
为了确保编码音频的机密性，必须对所有音频数据位进行加密。不需要加密有效负载头或目录，因为它们只携带有关帧类型的信息。这些信息也可能对第三方有用，例如用于质量监控。
The use of interleaving in conjunction with encryption can have a negative impact on the confidentiality for a short period of time. Consider the following packets (in brackets) containing frame numbers as indicated: {10, 14, 18}, {13, 17, 21}, {16, 20, 24} (a typical continuous diagonal interleaving pattern). The originator wishes to deny some participants the ability to hear material starting at time 16. Simply changing the key on the packet with the timestamp at or after 16, and denying the new key to those participants, does not achieve this; frames 17, 18, and 21 have been supplied in prior packets under the prior key, and error concealment may make the audio intelligible at least as far as frame 18 or 19, and possibly further.
交织与加密结合使用会在短时间内对保密性产生负面影响。考虑下面的数据包（括号内）包含帧编号，如{ 10, 14, 18 }，{ 13, 17, 21 }，{ 16, 20, 24 }（典型的连续对角交错模式）。发起者希望剥夺一些参与者从时间16开始聆听材料的能力。简单地更改时间戳为16或16之后的数据包上的密钥，并拒绝向这些参与者提供新密钥，并不能实现这一点；帧17、18和21已在先前密钥下的先前分组中提供，并且错误隐藏可使音频至少远至帧18或19，并且可能远至帧18或19。
To authenticate the sender of the speech, an external mechanism MUST be used. It is RECOMMENDED that such a mechanism protects both the complete RTP header and the payload (speech and data bits).
要对语音发送者进行身份验证，必须使用外部机制。建议这种机制同时保护完整的RTP报头和有效负载（语音和数据位）。
Data tampering by a man-in-the-middle attacker could replace audio content and also result in erroneous depacketization/decoding that could lower the audio quality. For example, tampering with the CMR field may result in speech of a different quality than desired.
中间人攻击者篡改数据可能会替换音频内容，还可能导致错误的解包/解码，从而降低音频质量。例如，篡改CMR字段可能导致不同于期望的语音质量。
This section defines the parameters that may be used to select optional features in the VMR-WB RTP payload formats.
本节定义了可用于选择VMR-WB RTP有效负载格式中可选功能的参数。
The parameters are defined here as part of the MIME subtype registration for the VMR-WB speech codec. A mapping of the parameters into the Session Description Protocol (SDP) [5] is also provided for those applications that use SDP. In control protocols that do not use MIME or SDP, the media type parameters must be mapped to the appropriate format used with that control protocol.
这些参数在这里定义为VMR-WB语音编解码器MIME子类型注册的一部分。还为使用SDP的应用程序提供了参数到会话描述协议（SDP）[5]的映射。在不使用MIME或SDP的控制协议中，媒体类型参数必须映射到与该控制协议一起使用的适当格式。
The MIME subtype for the Variable-Rate Multimode Wideband (VMR-WB) audio codec is allocated from the IETF tree since VMR-WB is expected to be a widely used speech codec in multimedia streaming and messaging as well as in VoIP applications. This MIME registration only covers real-time transfers via RTP.
可变速率多模宽带（VMR-WB）音频编解码器的MIME子类型是从IETF树中分配的，因为VMR-WB有望成为多媒体流和消息传递以及VoIP应用中广泛使用的语音编解码器。此MIME注册仅包括通过RTP的实时传输。
Note, the receiver MUST ignore any unspecified parameter and use the default values instead. Also note that if no input parameters are defined, the default values will be used.
注意，接收方必须忽略任何未指定的参数，并使用默认值。还请注意，如果未定义输入参数，将使用默认值。
Media Type name: audio
媒体类型名称：音频
Media subtype name: VMR-WB
媒体子类型名称：VMR-WB
Required parameters: none
所需参数：无
Furthermore, if the interleaving parameter is present, the parameter "octet-align=1" MUST also be present.
此外，如果存在交织参数，则参数“octet align=1”也必须存在。
OPTIONAL parameters:
可选参数：
mode-set: Requested VMR-WB operating mode set. Restricts the active operating modes to a subset of all modes. Possible values are a comma-separated list of integer values. Currently, this list includes modes 0, 1, 2, and 3 [1], but MAY be extended in the future. If such mode-set is specified during session initiation, the encoder MUST NOT use modes outside of the subset. If not present, all operating modes in the set 0 to 3 are allowed for the session.
模式设置：请求的VMR-WB操作模式设置。将激活操作模式限制为所有模式的子集。可能的值是以逗号分隔的整数值列表。目前，该列表包括模式0、1、2和3[1]，但将来可能会扩展。如果在会话启动期间指定了此类模式集，编码器不得使用子集之外的模式。如果不存在，则会话允许设置为0到3的所有操作模式。
channels: The number of audio channels. The possible values and their respective channel order is specified in Section 4.1 in [6]. If omitted, it has the default value of 1.
频道：音频频道的数量。[6]第4.1节规定了可能的值及其各自的通道顺序。如果省略，则默认值为1。
octet-align: RTP payload format; permissible values are 0 and 1. If 1, octet-aligned payload format SHALL be used. If 0 or if not present, header-free payload format is employed (default).
八位组对齐：RTP有效负载格式；允许值为0和1。如果为1，则应使用八位字节对齐的有效载荷格式。如果0或不存在，则使用无报头有效负载格式（默认）。
maxptime: See RFC 3267 [4]
maxptime:参见RFC 3267[4]
interleaving: Indicates that frame-block level interleaving SHALL be used for the session. Its value defines the maximum number of frame-blocks allowed in an interleaving group (see Section 6.3.1). If this parameter is not present, interleaving SHALL NOT be used. The presence of this parameter also implies automatically that octet-aligned operation SHALL be used.
交织：表示会话应使用帧块级交织。其值定义了交织组中允许的最大帧块数（见第6.3.1节）。如果该参数不存在，则不得使用交织。此参数的存在也自动意味着应使用八位组对齐操作。
ptime: See RFC2327 [5]. It SHALL be at least one frame size for VMR-WB.
ptime：见RFC2327[5]。VMR-WB的框架尺寸应至少为一个。
dtx: Permissible values are 0 and 1. The default is 0 (i.e., No DTX) where VMR-WB normally operates as a continuous variable-rate codec. If dtx=1, the VMR-WB codec will operate in discontinuous transmission mode where silence descriptor (SID) frames are sent by the VMR-WB encoder during silence intervals with an adjustable update frequency. The selection of the SID update-rate depends on the implementation and other network considerations that are beyond the scope of this specification.
dtx：允许值为0和1。默认值为0（即无DTX），其中VMR-WB通常作为连续可变速率编解码器运行。如果dtx=1，VMR-WB编解码器将在不连续传输模式下运行，其中VMR-WB编码器在静音间隔期间以可调整的更新频率发送静音描述符（SID）帧。SID更新率的选择取决于本规范范围以外的实现和其他网络注意事项。
Encoding considerations:
编码注意事项：
This type is only defined for transfer of VMR-WB-encoded data via RTP (RFC 3550) using the payload formats specified in Section 6 of RFC 4348.
此类型仅定义为使用RFC 4348第6节中规定的有效负载格式，通过RTP（RFC 3550）传输VMR WB编码数据。
Security considerations:
安全考虑：
See Section 8 of RFC 4348.
参见RFC 4348第8节。
Public specification:
公开规格：
The VMR-WB speech codec is specified in 3GPP2 specifications C.S0052-0 version 1.0. Transfer methods are specified in RFC 4348.
VMR-WB语音编解码器在3GPP2规范C.S0052-0版本1.0中指定。RFC 4348中规定了传输方法。
Additional information:
其他信息：
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Sassan Ahmadi, Ph.D. sassan.ahmadi@ieee.org
萨桑·艾哈迈迪博士。萨桑。ahmadi@ieee.org
Intended usage: COMMON.
预期用途：普通。
It is expected that many VoIP, multimedia messaging and streaming applications (as well as mobile applications) will use this type.
预计许多VoIP、彩信和流媒体应用程序（以及移动应用程序）将使用这种类型。
Author/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) [5], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the VMR-WB codec, the mapping is as follows:
MIME媒体类型规范中包含的信息与会话描述协议（SDP）[5]中的字段具有特定映射，该协议通常用于描述RTP会话。当使用SDP指定使用VMR-WB编解码器的会话时，映射如下：
- The media type ("audio") goes in SDP "m=" as the media name.
- 媒体类型（“音频”）以SDP“m=”作为媒体名称。
- The media subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 16000 for VMR-WB.
- 媒体子类型（有效负载格式名称）以SDP“a=rtpmap”作为编码名称。对于VMR-WB，“a=rtpmap”中的RTP时钟频率必须为16000。
- The parameter "channels" (number of channels) MUST be either explicitly set to N or omitted, implying a default value of 1. The values of N that are allowed is specified in Section 4.1 in [6]. The parameter "channels", if present, is specified subsequent to the MIME subtype and RTP clock rate as an encoding parameter in the "a=rtpmap" attribute.
- 参数“channels”（通道数）必须显式设置为N或省略，这意味着默认值为1。[6]第4.1节规定了允许的N值。参数“channels”（如果存在）在MIME子类型和RTP时钟速率之后指定为“a=rtpmap”属性中的编码参数。
- The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
- 参数“ptime”和“maxptime”分别位于SDP“a=ptime”和“a=maxptime”属性中。
- Any remaining parameters go in the SDP "a=fmtp" attribute by copying them directly from the MIME media type string as a semicolon-separated list of parameter=value pairs.
- 通过直接从MIME媒体类型字符串中以分号分隔的参数=值对列表形式复制其余参数，将其放入SDP“a=fmtp”属性中。
Some examples of SDP session descriptions utilizing VMR-WB encodings follow.
下面是一些使用VMR-WB编码的SDP会话描述示例。
Example of usage of VMR-WB in a possible VoIP scenario (wideband audio):
在可能的VoIP场景（宽带音频）中使用VMR-WB的示例：
m=audio 49120 RTP/AVP 98
a=rtpmap:98 VMR-WB/16000
a=fmtp:98 octet-align=1
m=audio 49120 RTP/AVP 98
a=rtpmap:98 VMR-WB/16000
a=fmtp:98 octet-align=1
Example of usage of VMR-WB in a possible streaming scenario (two channel stereo):
在可能的流媒体场景（双通道立体声）中使用VMR-WB的示例：
m=audio 49120 RTP/AVP 99
a=rtpmap:99 VMR-WB/16000/2
a=fmtp:99 octet-align=1; interleaving=30
a=maxptime:100
m=audio 49120 RTP/AVP 99
a=rtpmap:99 VMR-WB/16000/2
a=fmtp:99 octet-align=1; interleaving=30
a=maxptime:100
To achieve good interoperability for the VMR-WB RTP payload in an Offer-Answer negotiation usage in SDP [13], the following considerations are made:
为了在SDP[13]中的要约-应答协商使用中实现VMR-WB RTP有效负载的良好互操作性，需要考虑以下因素：
- The rate, channel, and payload configuration parameters (octet-align and interleaving) SHALL be used symmetrically, i.e., offer and answer must use the same values. The maximum size of the interleaving buffer is, however, declarative, and each agent specifies the value it supports to receive for recvonly and sendrecv streams. For sendonly streams, the value indicates what the agent desires to use.
- 速率、信道和有效负载配置参数（八位组对齐和交织）应对称使用，即提供和应答必须使用相同的值。但是，交错缓冲区的最大大小是声明性的，每个代理指定它支持接收的RecvoOnly和sendrecv流的值。对于sendonly流，该值指示代理希望使用的内容。
- To maintain interoperability among all implementations of VMR-WB that may or may not support all the codec's modes of operation, the operational modes that are supported by an implementation MAY be identified at session initiation. The mode-set parameter is declarative, and only operating modes that have been indicated to be supported by both ends SHALL be used. If the answerer is not supporting any of the operating modes provided in the offer, the complete payload type declaration SHOULD be rejected by removing it from the answer.
- 为了保持VMR-WB的所有实现之间的互操作性（可能支持也可能不支持所有编解码器的操作模式），可在会话启动时识别一个实现支持的操作模式。模式设置参数是声明性的，只能使用两端都支持的操作模式。如果应答者不支持报价中提供的任何操作模式，则应通过将其从应答中删除来拒绝完整的有效负载类型声明。
- The remaining parameters are all declarative; i.e., for sendonly streams they provide parameters that the agent desires to use, while for recvonly and sendrecv streams they declare the parameters that it accepts to receive. The dtx parameter is used to indicate DTX support and capability, while the media sender is only RECOMMENDED to send using the DTX in these cases. If DTX is not supported by the media sender, it will send media without DTX; this will not affect interoperability only the resource consumption.
- 其余的参数都是声明性的；i、 例如，对于sendonly流，它们提供代理希望使用的参数，而对于RecVoOnly和sendrecv流，它们声明代理接受接收的参数。dtx参数用于指示dtx支持和功能，而在这些情况下，仅建议媒体发送器使用dtx发送。如果媒体发送方不支持DTX，则将发送不支持DTX的媒体；这不会影响互操作性，只会影响资源消耗。
- Both header-free and octet-aligned payload format configurations MAY be offered by a VMR-WB enabled terminal. However, for an interoperable interconnection with AMR-WB, only octet-aligned
- 启用VMR-WB的终端可以提供无报头和八位字节对齐的有效负载格式配置。但是，对于与AMR-WB的互操作互连，只有八位组对齐
- The parameters "maxptime" and "ptime" should in most cases not affect the interoperability; however, the setting of the parameters can affect the performance of the application.
- 参数“maxptime”和“ptime”在大多数情况下不应影响互操作性；但是，参数的设置可能会影响应用程序的性能。
- To maintain interoperability with AMR-WB in cases where negotiation is possible using the VMR-WB interoperable mode, a VMR-WB-enabled terminal SHOULD also declare itself capable of AMR-WB with limited mode set (i.e., only AMR-WB codec modes 0, 1, and 2 are allowed) and of octet-align mode of operation.
- 为了在可能使用VMR-WB互操作模式进行协商的情况下保持与AMR-WB的互操作性，启用VMR-WB的终端还应声明自己能够使用有限模式集（即，仅允许使用AMR-WB编解码器模式0、1和2）和八位字节对齐操作模式的AMR-WB。
Example:
例子：
m=audio 49120 RTP/AVP 98 99
a=rtpmap:98 VMR-WB/16000
a=rtpmap:99 AMR-WB/16000
a=fmtp:99 octet-align=1; mode-set=0,1,2
m=audio 49120 RTP/AVP 98 99
a=rtpmap:98 VMR-WB/16000
a=rtpmap:99 AMR-WB/16000
a=fmtp:99 octet-align=1; mode-set=0,1,2
An example of offer-answer exchange for the VoIP scenario described in Section 5.3 is as follows:
第5.3节中描述的VoIP场景的提供-应答交换示例如下：
CDMA2000 terminal -> WCDMA terminal Offer:
m=audio 49120 RTP/AVP 98 97
a=rtpmap:98 VMR-WB/16000
a=fmtp:98 octet-align=1
a=rtpmap:97 AMR-WB/16000
a=fmtp:97 mode-set=0,1,2; octet-align=1
CDMA2000 terminal -> WCDMA terminal Offer:
m=audio 49120 RTP/AVP 98 97
a=rtpmap:98 VMR-WB/16000
a=fmtp:98 octet-align=1
a=rtpmap:97 AMR-WB/16000
a=fmtp:97 mode-set=0,1,2; octet-align=1
WCDMA terminal -> CDMA2000 terminal Answer:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 AMR-WB/16000
a=fmtp:97 mode-set=0,1,2; octet-align=1;
WCDMA terminal -> CDMA2000 terminal Answer:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 AMR-WB/16000
a=fmtp:97 mode-set=0,1,2; octet-align=1;
For declarative use of SDP such as in SAP [14] and RTSP [15], all parameters are declarative and provide the parameters that SHALL be used when receiving and/or sending the configured stream.
对于SDP的声明性使用，如在SAP[14]和RTSP[15]中，所有参数都是声明性的，并提供接收和/或发送配置流时应使用的参数。
The IANA has registered one new MIME subtype (audio/VMR-WB); see Section 9.
IANA注册了一个新的MIME子类型（audio/VMR-WB）；见第9节。
The author would like to thank Redwan Salami of VoiceAge Corporation, Ari Lakaniemi of Nokia Inc., and IETF/AVT chairs Colin Perkins and Magnus Westerlund for their technical comments to improve this document.
作者要感谢VoiceAge公司的Redwan Salami、诺基亚公司的Ari Lakaniemi以及IETF/AVT主席Colin Perkins和Magnus Westerlund为改进本文档提出的技术意见。
Also, the author would like to acknowledge that some parts of RFC 3267 [4] and RFC 3558 [11] have been used in this document.
此外，作者希望确认，本文件中使用了RFC 3267[4]和RFC 3558[11]的某些部分。
[1] 3GPP2 C.S0052-0 v1.0 "Source-Controlled Variable-Rate Multimode Wideband Speech Codec (VMR-WB) Service Option 62 for Spread Spectrum Systems", 3GPP2 Technical Specification, July 2004.
[1] 3GPP2 C.S0052-0 v1.0“用于扩频系统的源控可变速率多模宽带语音编解码器（VMR-WB）服务选项62”，《3GPP2技术规范》，2004年7月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[3] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[4] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002.
[4] Sjoberg，J.，Westerlund，M.，Lakaniemi，A.，和Q.Xie，“自适应多速率（AMR）和自适应多速率宽带（AMR-WB）音频编解码器的实时传输协议（RTP）有效载荷格式和文件存储格式”，RFC 3267，2002年6月。
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[5] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[6] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[6] Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[7] 3GPP2 C.S0050-A v1.0 "3GPP2 File Formats for Multimedia Services", 3GPP2 Technical Specification, September 2005.
[7] 3GPP2 C.S0050-A v1.0“多媒体服务的3GPP2文件格式”，3GPP2技术规范，2005年9月。
[8] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
[8] Rosenberg，J.和H.Schulzrinne，“通用前向纠错的RTP有效载荷格式”，RFC 2733，1999年12月。
[9] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[9] Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[10] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[10] 帕金斯，C.，库维拉斯，I.，霍德森，O.，哈德曼，V.，汉德利，M.，博洛特，J.，维加·加西亚，A.，和S.福斯·帕里斯，“冗余音频数据的RTP有效载荷”，RFC 21981997年9月。
[11] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, July 2003.
[11] 李安，“增强型变速率编解码器（EVRC）和可选模式声码器（SMV）的RTP有效载荷格式”，RFC3558，2003年7月。
[12] 3GPP TS 26.193 "AMR Wideband Speech Codec; Source Controlled Rate operation", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
[12] 3GPP TS 26.193“AMR宽带语音编解码器；源代码控制速率操作”，版本5.0.0（2001-03），第三代合作伙伴计划（3GPP）。
[13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[13] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[14] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[14] Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 29742000年10月。
[15] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[15] Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
Any 3GPP2 document can be downloaded from the 3GPP2 web server, "http://www.3gpp2.org/", see specifications.
可以从3GPP2 web服务器下载任何3GPP2文档，“http://www.3gpp2.org/“，请参阅规格。
Author's Address
作者地址
Dr. Sassan Ahmadi EMail: sassan.ahmadi@ieee.org
Sassan Ahmadi博士电子邮件：Sassan。ahmadi@ieee.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。