Network Working Group J. Sjoberg
Request for Comments: 4867 M. Westerlund
Obsoletes: 3267 Ericsson
Category: Standards Track A. Lakaniemi
Nokia
Q. Xie
Motorola
April 2007
Network Working Group J. Sjoberg
Request for Comments: 4867 M. Westerlund
Obsoletes: 3267 Ericsson
Category: Standards Track A. Lakaniemi
Nokia
Q. Xie
Motorola
April 2007
RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs
自适应多速率（AMR）和自适应多速率宽带（AMR-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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document specifies a Real-time Transport Protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate media type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. This document obsoletes RFC 3267.
本文件规定了用于自适应多速率（AMR）和自适应多速率宽带（AMR-WB）编码语音信号的实时传输协议（RTP）有效载荷格式。有效负载格式旨在与非IP网络上的现有AMR和AMR-WB传输格式进行互操作。此外，还指定了文件格式，用于在存储模式应用程序（如电子邮件）中传输AMR和AMR-WB语音数据。包括两个单独的媒体类型注册，一个用于AMR，另一个用于AMR-WB，指定RTP有效负载格式和存储格式的使用。本文件淘汰了RFC 3267。
Table of Contents
目录
1. Introduction ....................................................4
2. Conventions and Acronyms ........................................4
3. Background on AMR/AMR-WB and Design Principles ..................5
3.1. The Adaptive Multi-Rate (AMR) Speech Codec .................5
3.2. The Adaptive Multi-Rate Wideband (AMR-WB) Speech Codec .....6
3.3. Multi-Rate Encoding and Mode Adaptation ....................6
3.4. Voice Activity Detection and Discontinuous Transmission ....7
3.5. Support for Multi-Channel Session ..........................7
3.6. Unequal Bit-Error Detection and Protection .................8
3.6.1. Applying UEP and UED in an IP Network ...............8
3.7. Robustness against Packet Loss ............................10
3.7.1. Use of Forward Error Correction (FEC) ..............10
3.7.2. Use of Frame Interleaving ..........................12
3.8. Bandwidth-Efficient or Octet-Aligned Mode .................12
3.9. AMR or AMR-WB Speech over IP Scenarios ....................13
4. AMR and AMR-WB RTP Payload Formats .............................15
4.1. RTP Header Usage ..........................................15
4.2. Payload Structure .........................................17
4.3. Bandwidth-Efficient Mode ..................................17
4.3.1. The Payload Header .................................17
4.3.2. The Payload Table of Contents ......................18
4.3.3. Speech Data ........................................20
4.3.4. Algorithm for Forming the Payload ..................21
4.3.5. Payload Examples ...................................21
4.3.5.1. Single-Channel Payload Carrying a
Single Frame ..............................21
4.3.5.2. Single-Channel Payload Carrying
Multiple Frames ...........................22
4.3.5.3. Multi-Channel Payload Carrying
Multiple Frames ...........................23
4.4. Octet-Aligned Mode ........................................25
4.4.1. The Payload Header .................................25
4.4.2. The Payload Table of Contents and Frame CRCs .......26
4.4.2.1. Use of Frame CRC for UED over IP ..........28
4.4.3. Speech Data ........................................30
4.4.4. Methods for Forming the Payload ....................31
4.4.5. Payload Examples ...................................32
4.4.5.1. Basic Single-Channel Payload
Carrying Multiple Frames ..................32
4.4.5.2. Two-Channel Payload with CRC,
Interleaving, and Robust Sorting ..........32
4.5. Implementation Considerations .............................33
4.5.1. Decoding Validation ................................34
5. AMR and AMR-WB Storage Format ..................................35
5.1. Single-Channel Header .....................................35
5.2. Multi-Channel Header ......................................36
1. Introduction ....................................................4
2. Conventions and Acronyms ........................................4
3. Background on AMR/AMR-WB and Design Principles ..................5
3.1. The Adaptive Multi-Rate (AMR) Speech Codec .................5
3.2. The Adaptive Multi-Rate Wideband (AMR-WB) Speech Codec .....6
3.3. Multi-Rate Encoding and Mode Adaptation ....................6
3.4. Voice Activity Detection and Discontinuous Transmission ....7
3.5. Support for Multi-Channel Session ..........................7
3.6. Unequal Bit-Error Detection and Protection .................8
3.6.1. Applying UEP and UED in an IP Network ...............8
3.7. Robustness against Packet Loss ............................10
3.7.1. Use of Forward Error Correction (FEC) ..............10
3.7.2. Use of Frame Interleaving ..........................12
3.8. Bandwidth-Efficient or Octet-Aligned Mode .................12
3.9. AMR or AMR-WB Speech over IP Scenarios ....................13
4. AMR and AMR-WB RTP Payload Formats .............................15
4.1. RTP Header Usage ..........................................15
4.2. Payload Structure .........................................17
4.3. Bandwidth-Efficient Mode ..................................17
4.3.1. The Payload Header .................................17
4.3.2. The Payload Table of Contents ......................18
4.3.3. Speech Data ........................................20
4.3.4. Algorithm for Forming the Payload ..................21
4.3.5. Payload Examples ...................................21
4.3.5.1. Single-Channel Payload Carrying a
Single Frame ..............................21
4.3.5.2. Single-Channel Payload Carrying
Multiple Frames ...........................22
4.3.5.3. Multi-Channel Payload Carrying
Multiple Frames ...........................23
4.4. Octet-Aligned Mode ........................................25
4.4.1. The Payload Header .................................25
4.4.2. The Payload Table of Contents and Frame CRCs .......26
4.4.2.1. Use of Frame CRC for UED over IP ..........28
4.4.3. Speech Data ........................................30
4.4.4. Methods for Forming the Payload ....................31
4.4.5. Payload Examples ...................................32
4.4.5.1. Basic Single-Channel Payload
Carrying Multiple Frames ..................32
4.4.5.2. Two-Channel Payload with CRC,
Interleaving, and Robust Sorting ..........32
4.5. Implementation Considerations .............................33
4.5.1. Decoding Validation ................................34
5. AMR and AMR-WB Storage Format ..................................35
5.1. Single-Channel Header .....................................35
5.2. Multi-Channel Header ......................................36
5.3. Speech Frames .............................................37
6. Congestion Control .............................................38
7. Security Considerations ........................................38
7.1. Confidentiality ...........................................39
7.2. Authentication and Integrity ..............................39
8. Payload Format Parameters ......................................39
8.1. AMR Media Type Registration ...............................40
8.2. AMR-WB Media Type Registration ............................44
8.3. Mapping Media Type Parameters into SDP ....................47
8.3.1. Offer-Answer Model Considerations ..................48
8.3.2. Usage of Declarative SDP ...........................50
8.3.3. Examples ...........................................51
9. IANA Considerations ............................................53
10. Changes from RFC 3267 .........................................53
11. Acknowledgements ..............................................55
12. References ....................................................55
12.1. Normative References .....................................55
12.2. Informative References ...................................56
5.3. Speech Frames .............................................37
6. Congestion Control .............................................38
7. Security Considerations ........................................38
7.1. Confidentiality ...........................................39
7.2. Authentication and Integrity ..............................39
8. Payload Format Parameters ......................................39
8.1. AMR Media Type Registration ...............................40
8.2. AMR-WB Media Type Registration ............................44
8.3. Mapping Media Type Parameters into SDP ....................47
8.3.1. Offer-Answer Model Considerations ..................48
8.3.2. Usage of Declarative SDP ...........................50
8.3.3. Examples ...........................................51
9. IANA Considerations ............................................53
10. Changes from RFC 3267 .........................................53
11. Acknowledgements ..............................................55
12. References ....................................................55
12.1. Normative References .....................................55
12.2. Informative References ...................................56
This document obsoletes RFC 3267 and extends that specification with offer/answer rules. See Section 10 for the changes made to this format in relation to RFC 3267.
本文件废除了RFC 3267，并通过提供/应答规则扩展了该规范。有关RFC 3267对本格式所做的更改，请参见第10节。
This document specifies the payload format for packetization of AMR and AMR-WB encoded speech signals into the Real-time Transport Protocol (RTP) [8]. The payload format supports transmission of multiple channels, multiple frames per payload, the use of fast codec mode adaptation, robustness against packet loss and bit errors, and interoperation with existing AMR and AMR-WB transport formats on non-IP networks, as described in Section 3.
本文件规定了将AMR和AMR-WB编码语音信号打包成实时传输协议（RTP）[8]的有效载荷格式。如第3节所述，有效负载格式支持多信道传输、每个有效负载多帧、使用快速编解码器模式自适应、抗分组丢失和比特错误的鲁棒性，以及与非IP网络上现有AMR和AMR-WB传输格式的互操作。
The payload format itself is specified in Section 4. A related file format is specified in Section 5 for transport of AMR and AMR-WB speech data in storage mode applications such as email. In Section 8, two separate media type registrations are provided, one for AMR and one for AMR-WB.
第4节规定了有效载荷格式本身。第5节规定了相关文件格式，用于在存储模式应用程序（如电子邮件）中传输AMR和AMR-WB语音数据。在第8节中，提供了两个单独的媒体类型注册，一个用于AMR，另一个用于AMR-WB。
Even though this RTP payload format definition supports the transport of both AMR and AMR-WB speech, it is important to remember that AMR and AMR-WB are two different codecs and they are always handled as different payload types in RTP.
尽管此RTP有效负载格式定义支持AMR和AMR-WB语音的传输，但重要的是要记住，AMR和AMR-WB是两种不同的编解码器，它们在RTP中始终作为不同的有效负载类型处理。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[5]中所述进行解释。
The following acronyms are used in this document:
本文件中使用了以下首字母缩略词：
3GPP - the Third Generation Partnership Project AMR - Adaptive Multi-Rate (Codec) AMR-WB - Adaptive Multi-Rate Wideband (Codec) CMR - Codec Mode Request CN - Comfort Noise DTX - Discontinuous Transmission ETSI - European Telecommunications Standards Institute FEC - Forward Error Correction SCR - Source Controlled Rate Operation SID - Silence Indicator (the frames containing only CN parameters) VAD - Voice Activity Detection UED - Unequal Error Detection UEP - Unequal Error Protection
3GPP-第三代合作伙伴项目AMR-自适应多速率（编解码器）AMR-WB-自适应多速率宽带（编解码器）CMR-编解码器模式请求CN-舒适噪声DTX-不连续传输ETSI-欧洲电信标准协会FEC-前向纠错SCR-源控速率操作SID-静音指示器（仅包含CN参数的帧）VAD-语音活动检测UED-不等错误检测UEP-不等错误保护
The term "frame-block" is used in this document to describe the time-synchronized set of speech frames in a multi-channel AMR or AMR-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 represents exactly the same time period.
本文档中使用术语“帧块”来描述多通道AMR或AMR-WB会话中的时间同步语音帧集。特别地，在N信道会话中，帧块将包含N个语音帧，每个信道一个，并且所有N个语音帧表示完全相同的时间段。
The byte order used in this document is network byte order, i.e., the most significant byte first. The bit order is also the most significant bit first. This is presented in all figures as having the most significant bit leftmost on a line and with the lowest number. Some bit fields may wrap over multiple lines in which cases the bits on the first line are more significant than the bits on the next line.
本文件中使用的字节顺序为网络字节顺序，即最重要的字节排在第一位。位顺序也是最重要的第一位。这在所有图中表示为一行中最左边的最有效位和最低的数字。某些位字段可能会覆盖多行，在这种情况下，第一行上的位比下一行上的位更重要。
AMR and AMR-WB were originally designed for circuit-switched mobile radio systems. Due to their flexibility and robustness, they are also suitable for other real-time speech communication services over packet-switched networks such as the Internet.
AMR和AMR-WB最初是为电路交换移动无线电系统设计的。由于它们的灵活性和鲁棒性，它们也适用于通过分组交换网络（如因特网）的其他实时语音通信服务。
Because of the flexibility of these codecs, the behavior in a particular application is controlled by several parameters that select options or specify the acceptable values for a variable. These options and variables are described in general terms at appropriate points in the text of this specification as parameters to be established through out-of-band means. In Section 8, all of the parameters are specified in the form of media subtype registrations for the AMR and AMR-WB encodings. The method used to signal these parameters at session setup or to arrange prior agreement of the participants is beyond the scope of this document; however, Section 8.3 provides a mapping of the parameters into the Session Description Protocol (SDP) [11] for those applications that use SDP.
由于这些编解码器的灵活性，特定应用程序中的行为由多个参数控制，这些参数选择选项或指定变量的可接受值。这些选项和变量在本规范文本中的适当位置以一般术语描述，作为通过带外方式确定的参数。在第8节中，所有参数都以AMR和AMR-WB编码的媒体子类型注册的形式指定。用于在会话设置时发出这些参数信号或安排参与者事先同意的方法超出了本文件的范围；但是，第8.3节为使用SDP的应用程序提供了参数到会话描述协议（SDP）[11]的映射。
The AMR codec was originally developed and standardized by the European Telecommunications Standards Institute (ETSI) for GSM cellular systems. It is now chosen by the Third Generation Partnership Project (3GPP) as the mandatory codec for third generation (3G) cellular systems [1].
AMR编解码器最初由欧洲电信标准协会（ETSI）为GSM蜂窝系统开发和标准化。它现在被第三代合作伙伴计划（3GPP）选为第三代（3G）蜂窝系统的强制性编解码器[1]。
The AMR codec is a multi-mode codec that supports eight narrow band speech encoding modes with bit rates between 4.75 and 12.2 kbps. The sampling frequency used in AMR is 8000 Hz and the speech encoding is performed on 20 ms speech frames. Therefore, each encoded AMR speech frame represents 160 samples of the original speech.
AMR编解码器是一种多模式编解码器，支持8种窄带语音编码模式，比特率在4.75和12.2 kbps之间。AMR中使用的采样频率为8000 Hz，语音编码在20 ms语音帧上执行。因此，每个编码的AMR语音帧代表160个原始语音样本。
Among the eight AMR encoding modes, three are already separately adopted as standards of their own. Particularly, the 6.7 kbps mode is adopted as PDC-EFR [18], the 7.4 kbps mode as IS-641 codec in TDMA [17], and the 12.2 kbps mode as GSM-EFR [16].
在八种AMR编码模式中，有三种已经分别作为各自的标准采用。具体而言，PDC-EFR采用6.7 kbps模式[18]，TDMA采用is-641编解码器采用7.4 kbps模式[17]，GSM-EFR采用12.2 kbps模式[16]。
The Adaptive Multi-Rate Wideband (AMR-WB) speech codec [3] was originally developed by 3GPP to be used in GSM and 3G cellular systems.
自适应多速率宽带（AMR-WB）语音编解码器[3]最初由3GPP开发，用于GSM和3G蜂窝系统。
Similar to AMR, the AMR-WB codec is also a multi-mode speech codec. AMR-WB supports nine wide band speech coding modes with respective bit rates ranging from 6.6 to 23.85 kbps. The sampling frequency used in AMR-WB is 16000 Hz and the speech processing is performed on 20 ms frames. This means that each AMR-WB encoded frame represents 320 speech samples.
与AMR类似，AMR-WB编解码器也是一种多模式语音编解码器。AMR-WB支持九种宽带语音编码模式，其各自的比特率范围为6.6到23.85 kbps。AMR-WB中使用的采样频率为16000 Hz，语音处理在20 ms帧上执行。这意味着每个AMR-WB编码帧代表320个语音样本。
The multi-rate encoding (i.e., multi-mode) capability of AMR and AMR-WB is designed for preserving high speech quality under a wide range of transmission conditions.
AMR和AMR-WB的多速率编码（即多模式）功能旨在在各种传输条件下保持高语音质量。
With AMR or AMR-WB, mobile radio systems are able to use available bandwidth as effectively as possible. For example, in GSM it is possible to dynamically adjust the speech encoding rate during a session so as to continuously adapt to the varying transmission conditions by dividing the fixed overall bandwidth between speech data and error protective coding. This enables the best possible trade-off between speech compression rate and error tolerance. To perform mode adaptation, the decoder (speech receiver) needs to signal the encoder (speech sender) the new mode it prefers. This mode change signal is called Codec Mode Request or CMR.
通过AMR或AMR-WB，移动无线电系统能够尽可能有效地使用可用带宽。例如，在GSM中，可以在会话期间动态地调整语音编码速率，以便通过在语音数据和差错保护编码之间划分固定的总带宽来连续地适应变化的传输条件。这可以在语音压缩率和容错性之间实现最佳的折衷。要执行模式自适应，解码器（语音接收器）需要向编码器（语音发送器）发送它喜欢的新模式的信号。此模式更改信号称为编解码器模式请求或CMR。
Since in most sessions speech is sent in both directions between the two ends, the mode requests from the decoder at one end to the encoder at the other end are piggy-backed over the speech frames in the reverse direction. In other words, there is no out-of-band signaling needed for sending CMRs.
由于在大多数会话中，语音在两端之间双向发送，因此从一端的解码器到另一端的编码器的模式请求在相反方向上通过语音帧反向发送。换句话说，发送CMR不需要带外信令。
Every AMR or AMR-WB codec implementation is required to support all the respective speech coding modes defined by the codec and must be able to handle mode switching to any of the modes at any time. However, some transport systems may impose limitations in the number of modes supported and how often the mode can change due to bandwidth
每个AMR或AMR-WB编解码器实现都需要支持编解码器定义的所有相应语音编码模式，并且必须能够随时处理模式切换到任何模式。然而，一些传输系统可能会对支持的模式数量以及模式因带宽而改变的频率施加限制
limitations or other constraints. For this reason, the decoder is allowed to indicate its acceptance of a particular mode or a subset of the defined modes for the session using out-of-band means.
限制或其他限制。因此，允许解码器使用带外手段指示其接受会话的特定模式或定义模式的子集。
For example, the GSM radio link can only use a subset of at most four different modes in a given session. This subset can be any combination of the eight AMR modes for an AMR session or any combination of the nine AMR-WB modes for an AMR-WB session.
例如，GSM无线链路在给定会话中最多只能使用四种不同模式的子集。该子集可以是AMR会话的八种AMR模式的任意组合，也可以是AMR-WB会话的九种AMR-WB模式的任意组合。
Moreover, for better interoperability with GSM through a gateway, the decoder is allowed to use out-of-band means to set the minimum number of frames between two mode changes and to limit the mode change among neighboring modes only.
此外，为了通过网关与GSM更好地互操作性，允许解码器使用带外方式来设置两个模式改变之间的最小帧数，并且仅限制相邻模式之间的模式改变。
Section 8 specifies a set of media type parameters that may be used to signal these mode adaptation controls at session setup.
第8节规定了一组媒体类型参数，可用于在会话设置时向这些模式自适应控制发送信号。
Both codecs support voice activity detection (VAD) and generation of comfort noise (CN) parameters during silence periods. Hence, the codecs have the option to reduce the number of transmitted bits and packets during silence periods to a minimum. The operation of sending CN parameters at regular intervals during silence periods is usually called discontinuous transmission (DTX) or source controlled rate (SCR) operation. The AMR or AMR-WB frames containing CN parameters are called Silence Indicator (SID) frames. See more details about VAD and DTX functionality in [9] and [10].
这两种编解码器都支持语音活动检测（VAD）和静音期间舒适噪声（CN）参数的生成。因此，编解码器可以选择将静默期间传输的比特和分组的数量减少到最小。在静默期内定期发送CN参数的操作通常称为不连续传输（DTX）或源控速率（SCR）操作。包含CN参数的AMR或AMR-WB帧称为静默指示器（SID）帧。有关VAD和DTX功能的更多详细信息，请参见[9]和[10]。
Both the RTP payload format and the storage format defined in this document support multi-channel audio content (e.g., a stereophonic speech session).
本文档中定义的RTP有效负载格式和存储格式都支持多声道音频内容（例如，立体声语音会话）。
Although AMR and AMR-WB codecs themselves do not support encoding of multi-channel audio content into a single bit stream, they can be used to separately encode and decode each of the individual channels.
尽管AMR和AMR-WB编解码器本身不支持将多声道音频内容编码为单个比特流，但它们可用于单独编码和解码各个声道。
To transport (or store) 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, the number of channels is specified in the rtpmap attribute and the order of channels carried in each frame-block is
在会话设置中，必须使用带外信令来指示会话中的信道数量，以及每个帧块中来自不同信道的语音帧的顺序。当使用SDP发送信号时，在rtpmap属性中指定通道数，并指定每个帧块中携带的通道顺序
implied by the number of channels as specified in Section 4.1 in [12].
由[12]第4.1节中规定的通道数表示。
The speech bits encoded in each AMR or AMR-WB frame have different perceptual sensitivity to bit errors. This property has been exploited in cellular systems to achieve better voice quality by using unequal error protection and detection (UEP and UED) mechanisms.
在每个AMR或AMR-WB帧中编码的语音比特对比特错误具有不同的感知敏感性。该特性已在蜂窝系统中得到利用，通过使用不等错误保护和检测（UEP和UED）机制来实现更好的语音质量。
The UEP/UED mechanisms focus the protection and detection of corrupted bits to the perceptually most sensitive bits in an AMR or AMR-WB frame. In particular, speech bits in an AMR or AMR-WB frame are divided into class A, B, and C, where bits in class A are the most sensitive and bits in class C the least sensitive (see Table 1 below for AMR and [4] for AMR-WB). An AMR or AMR-WB frame is only declared damaged if there are bit errors found in the most sensitive bits, i.e., the class A bits. On the other hand, it is acceptable to have some bit errors in the other bits, i.e., class B and C bits.
UEP/UED机制将损坏位的保护和检测重点放在AMR或AMR-WB帧中感知最敏感的位上。特别是，AMR或AMR-WB帧中的语音位分为A类、B类和C类，其中A类中的位最敏感，C类中的位最不敏感（AMR见下表1，AMR-WB见[4]）。只有在最敏感位（即A类位）中发现位错误时，AMR或AMR-WB帧才会被声明为损坏。另一方面，在其他位（即B类和C类位）中存在一些位错误是可以接受的。
Class A Total speech
Index Mode bits bits
----------------------------------------
0 AMR 4.75 42 95
1 AMR 5.15 49 103
2 AMR 5.9 55 118
3 AMR 6.7 58 134
4 AMR 7.4 61 148
5 AMR 7.95 75 159
6 AMR 10.2 65 204
7 AMR 12.2 81 244
8 AMR SID 39 39
Class A Total speech
Index Mode bits bits
----------------------------------------
0 AMR 4.75 42 95
1 AMR 5.15 49 103
2 AMR 5.9 55 118
3 AMR 6.7 58 134
4 AMR 7.4 61 148
5 AMR 7.95 75 159
6 AMR 10.2 65 204
7 AMR 12.2 81 244
8 AMR SID 39 39
Table 1. The number of class A bits for the AMR codec
表1。AMR编解码器的A类比特数
Moreover, a damaged frame is still useful for error concealment at the decoder since some of the less sensitive bits can still be used. This approach can improve the speech quality compared to discarding the damaged frame.
此外，由于仍然可以使用一些不太敏感的比特，因此损坏的帧对于解码器处的错误隐藏仍然是有用的。与丢弃受损帧相比，该方法可以提高语音质量。
To take full advantage of the bit-error robustness of the AMR and AMR-WB codec, the RTP payload format is designed to facilitate UEP/UED in an IP network. It should be noted however that the utilization of UEP and UED discussed below is OPTIONAL.
为了充分利用AMR和AMR-WB编解码器的误码鲁棒性，RTP有效负载格式旨在促进IP网络中的UEP/UED。然而，应当注意，下面讨论的UEP和UED的使用是可选的。
UEP/UED in an IP network can be achieved by detecting bit errors in class A bits and tolerating bit errors in class B/C bits of the AMR or AMR-WB frame(s) in each RTP payload.
IP网络中的UEP/UED可以通过检测每个RTP有效载荷中AMR或AMR-WB帧的A类位中的位错误和容忍B/C类位中的位错误来实现。
Link-layer protocols exist that do not discard packets containing bit errors, e.g., SLIP and some wireless links. With the Internet traffic pattern shifting towards a more multimedia-centric one, more link layers of such nature may emerge in the future. With transport layer support for partial checksums (for example, those supported by UDP-Lite [19]), bit error tolerant AMR and AMR-WB traffic could achieve better performance over these types of links. The relationship between UDP-Lite's partial checksum at the transport layer and the checksum coverage provided by the link-layer frame is described in UDP-Lite specification [19].
链路层协议不丢弃包含位错误的数据包，例如SLIP和一些无线链路。随着互联网流量模式向更以多媒体为中心的模式转变，未来可能会出现更多这种性质的链路层。通过传输层对部分校验和的支持（例如，UDP Lite[19]支持的校验和），比特容错AMR和AMR-WB通信可以在这些类型的链路上实现更好的性能。UDP Lite在传输层的部分校验和与链路层帧提供的校验和覆盖率之间的关系在UDP Lite规范[19]中描述。
There are at least two basic approaches for carrying AMR and AMR-WB traffic over bit error tolerant IP networks:
在比特容错IP网络上承载AMR和AMR-WB流量至少有两种基本方法：
a) Utilizing a partial checksum to cover the IP, transport protocol (e.g., UDP-Lite), RTP and payload headers, and the most important speech bits of the payload. The IP, UDP and RTP headers need to be protected, and it is recommended that at least all class A bits are covered by the checksum.
a) 利用部分校验和覆盖IP、传输协议（例如UDP Lite）、RTP和有效负载头以及有效负载的最重要语音位。IP、UDP和RTP报头需要保护，建议校验和至少覆盖所有A类位。
b) Utilizing a partial checksum to only cover the IP, transport protocol, RTP and payload headers, but an AMR or AMR-WB frame CRC to cover the class A bits of each speech frame in the RTP payload.
b) 使用部分校验和仅覆盖IP、传输协议、RTP和有效负载报头，但使用AMR或AMR-WB帧CRC覆盖RTP有效负载中每个语音帧的a类位。
In either approach, at least part of the class B/C bits are left without error-check and thus bit error tolerance is achieved.
在这两种方法中，至少有一部分B/C类位未进行错误检查，从而实现了位错误容忍。
Note, it is still important that the network designer pays attention to the class B and C residual bit error rate. Though less sensitive to errors than class A bits, class B and C bits are not insignificant, and undetected errors in these bits cause degradation in speech quality. An example of residual error rates considered acceptable for AMR in the Universal Mobile Telecommunications System (UMTS) can be found in [24] and for AMR-WB in [25].
请注意，网络设计者仍需注意B类和C类残余误码率。虽然B类和C类比特对错误的敏感性不如A类比特，但B类和C类比特并非无关紧要，这些比特中未检测到的错误会导致语音质量下降。通用移动通信系统（UMTS）中的AMR可接受的残差率示例见[24]，AMR-WB可接受的残差率示例见[25]。
The application interface to the UEP/UED transport protocol (e.g., UDP-Lite) may not provide any control over the link error rate, especially in a gateway scenario. Therefore, it is incumbent upon the designer of a node with a link interface of this type to choose a residual bit error rate that is low enough to support applications such as AMR encoding when transmitting packets of a UEP/UED transport protocol.
UEP/UED传输协议（例如UDP Lite）的应用程序接口可能不提供对链路错误率的任何控制，尤其是在网关场景中。因此，当传输UEP/UED传输协议的分组时，具有这种类型的链路接口的节点的设计者有责任选择足够低的残余误码率以支持诸如AMR编码之类的应用。
Approach 1 is bit efficient, flexible and simple, but comes with two disadvantages, namely, a) bit errors in protected speech bits will cause the payload to be discarded, and b) when transporting multiple AMR or AMR-WB frames in a RTP payload, there is the possibility that a single bit error in protected bits will cause all the frames to be discarded.
方法1比特效率高、灵活且简单，但有两个缺点，即a）受保护语音比特中的比特错误将导致有效载荷被丢弃，以及b）在RTP有效载荷中传输多个AMR或AMR-WB帧时，受保护位中的单个位错误可能会导致丢弃所有帧。
These disadvantages can be avoided, if needed, with some overhead in the form of a frame-wise CRC (Approach 2). In problem a), the CRC makes it possible to detect bit errors in class A bits and use the frame for error concealment, which gives a small improvement in speech quality. For b), when transporting multiple frames in a payload, the CRCs remove the possibility that a single bit error in a class A bit will cause all the frames to be discarded. Avoiding that improves the speech quality when transporting multiple AMR or AMR-WB frames over links subject to bit errors.
如果需要，这些缺点可以通过以帧方式CRC形式存在的一些开销来避免（方法2）。在问题a）中，CRC可以检测a类位中的位错误，并使用帧进行错误隐藏，从而在语音质量方面有一点改进。对于b），当在有效载荷中传输多个帧时，CRC消除a类位中的单个位错误将导致丢弃所有帧的可能性。避免这一点可以提高通过易受位错误影响的链路传输多个AMR或AMR-WB帧时的语音质量。
The choice between the above two approaches must be made based on the available bandwidth, and the desired tolerance to bit errors. Neither solution is appropriate for all cases. Section 8 defines parameters that may be used at session setup to choose between these approaches.
以上两种方法之间的选择必须基于可用带宽和所需的位错误容忍度。这两种解决方案都不适用于所有情况。第8节定义了可在会话设置中用于选择这些方法的参数。
The payload format supports several means, including forward error correction (FEC) and frame interleaving, to increase robustness against packet loss.
有效载荷格式支持多种方法，包括前向纠错（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., RFC 2733 [23], which generates extra packets containing repair data. The whole payload can also be sorted in sensitivity order to support external FEC schemes using UEP. There is also a work in progress on a generic version of such a scheme [22] that can be applied to AMR or AMR-WB payload transport.
重复先前发送的数据的简单方案是实现FEC的一种方法。带宽效率更高的另一个可能方案是使用有效载荷外部FEC，例如RFC 2733[23]，其生成包含修复数据的额外分组。为了支持使用UEP的外部FEC方案，还可以对整个有效负载进行灵敏度排序。还有一项关于此类方案的通用版本[22]的工作正在进行中，该方案可应用于AMR或AMR-WB有效载荷传输。
With AMR or AMR-WB, it is possible to use the multi-rate capability of the codec to send redundant copies of a frame using either the same mode or another mode, e.g., one with lower bandwidth. We describe such a scheme next.
使用AMR或AMR-WB，可以使用编解码器的多速率功能，使用相同模式或另一模式（例如，带宽较低的模式）发送帧的冗余副本。下面我们将描述这样一个方案。
This 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 below shows us an example.
这涉及先前发送的帧块与当前帧块的简单重传。这是通过使用滑动窗口将要发送到每个有效负载中的语音帧块分组来完成的。下面的图1为我们展示了一个示例。
--+--------+--------+--------+--------+--------+--------+--------+--
| 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：冗余传输示例
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）表示有效载荷分组的序列。
The use of this approach does not require signaling at the session setup. However, a parameter for providing a maximum delay in transmitting any redundant frame is defined in Section 8. 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 (encoded with different modes) 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 mode with the highest rate be used by the speech decoder.
这种方法的使用不需要在会话设置时发送信令。然而，用于在传输任何冗余帧时提供最大延迟的参数在第8节中定义。换句话说，语音发送方可以选择使用该方案，而无需咨询接收方。这是因为包含冗余帧的数据包与仅包含新帧的数据包看起来没有什么不同。如果没有数据包丢失，则接收器可以接收特定时间戳的帧的多个副本或版本（以不同模式编码）。如果接收到同一语音帧的多个版本，建议语音解码器使用速率最高的模式。
This redundancy scheme provides the same functionality as the one described in RFC 2198, "RTP Payload for Redundant Audio Data" [27]. In most cases the mechanism in this payload format is more efficient and simpler than requiring both endpoints to support RFC 2198 in addition. There are two situations in which use of RFC 2198 is indicated: if the spread in time required between the primary and redundant encodings is larger than the duration of 5 frames, the bandwidth overhead of RFC 2198 will be lower; or, if a non-AMR codec is desired for the redundant encoding, the AMR payload format won't be able to carry it.
该冗余方案提供了与RFC 2198“冗余音频数据的RTP有效载荷”[27]中所述相同的功能。在大多数情况下，这种有效负载格式的机制比另外要求两个端点都支持RFC 2198更高效、更简单。指示使用RFC 2198的情况有两种：如果主编码和冗余编码之间所需的时间扩展大于5帧的持续时间，则RFC 2198的带宽开销将更低；或者，如果冗余编码需要非AMR编解码器，AMR有效负载格式将无法承载它。
The sender is responsible for selecting an appropriate amount of redundancy based on feedback about the channel, e.g., in RTCP
发送方负责根据有关信道的反馈选择适当的冗余量，例如在RTCP中
receiver reports. A sender should not base selection of FEC on the CMR, as this parameter most probably was set based on non-IP information, e.g., radio link performance measures. The sender is also responsible for avoiding congestion, which may be exacerbated by redundancy (see Section 6 for more details).
接收者报告。发送方不应基于CMR选择FEC，因为此参数很可能是基于非IP信息（例如，无线链路性能度量）设置的。发送方还负责避免因冗余而加剧的拥塞（有关更多详细信息，请参阅第6节）。
To decrease protocol overhead, the payload design allows several speech frame-blocks to be encapsulated into a single RTP packet. One of the drawbacks of such an approach is that packet loss can cause loss of several consecutive speech frame-blocks, which usually causes clearly audible distortion in the reconstructed speech. 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.
为了减少协议开销，有效负载设计允许将多个语音帧块封装到单个RTP数据包中。这种方法的缺点之一是，数据包丢失会导致多个连续语音帧块丢失，这通常会导致重建语音中明显的音频失真。在这种情况下，帧块的交错可以通过将连续的损失分配到一系列单帧块损失中来改善语音质量。然而，每个有效负载交错和捆绑几个帧块也会增加端到端延迟，因此不适合所有类型的应用。流应用程序最有可能利用交织来改善有损传输条件下的语音质量。
This payload design 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 8).
此有效负载设计支持使用帧交错作为选项。对于编码器（语音发送器）在给定会话的出站RTP分组中使用帧交织，解码器（语音接收器）需要通过带外方式指示其支持（参见第8节）。
For a given session, the payload format can be either bandwidth efficient or octet aligned, depending on the mode of operation that is established for the session via out-of-band means.
对于给定会话，有效负载格式可以是带宽有效的或八位字节对齐的，这取决于通过带外方式为会话建立的操作模式。
In the octet-aligned 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. In the bandwidth-efficient format, only the full payload is octet aligned, so fewer padding bits are added.
在八位字节对齐格式中，有效负载中的所有字段（包括有效负载标头、目录条目和语音帧本身）都单独与八位字节边界对齐，以提高实现效率。在带宽效率高的格式中，只有完整的有效负载是八位组对齐的，因此添加的填充位更少。
Note, 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 operation modes, only the octet-aligned mode has the capability to use the robust sorting, interleaving, and frame CRC to make the speech transport more robust to packet loss and bit errors.
在这两种操作模式之间，只有八位组对齐模式能够使用健壮的排序、交织和帧CRC，使语音传输对丢包和误码更健壮。
The primary scenario for this payload format is IP end-to-end between two terminals, as shown in Figure 2. This payload format is expected to be useful for both conversational and streaming services.
此有效负载格式的主要场景是两个终端之间的IP端到端，如图2所示。这种有效负载格式预计对会话和流式服务都很有用。
+----------+ +----------+
| | IP/UDP/RTP/AMR or | |
| TERMINAL |<----------------------->| TERMINAL |
| | IP/UDP/RTP/AMR-WB | |
+----------+ +----------+
+----------+ +----------+
| | IP/UDP/RTP/AMR or | |
| TERMINAL |<----------------------->| TERMINAL |
| | IP/UDP/RTP/AMR-WB | |
+----------+ +----------+
Figure 2: IP terminal to IP terminal scenario
图2:IP终端到IP终端场景
A conversational service puts requirements on the payload format. Low delay is one very important factor, i.e., few speech frame-blocks per payload packet. Low overhead is also required when the payload format traverses low bandwidth links, especially as the frequency of packets will be high. For low bandwidth links, it is also an advantage to support UED, which allows a link provider to reduce delay and packet loss, or to reduce the utilization of link resources.
会话服务将需求放在有效负载格式上。低延迟是一个非常重要的因素，即每个有效负载数据包的语音帧块很少。当有效负载格式穿越低带宽链路时，也需要低开销，特别是当数据包的频率很高时。对于低带宽链路，支持UED也是一个优势，它允许链路提供商减少延迟和数据包丢失，或降低链路资源的利用率。
A streaming service has less strict real-time requirements and therefore can use a larger number of frame-blocks per packet than a 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 that packet loss will have 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. The octet-aligned and interleaving modes require the least amount of resources, while CRC, robust sorting, and bandwidth-efficient modes have higher demands.
流式服务的实时性要求不那么严格，因此与会话服务相比，每个数据包可以使用更多的帧块。这减少了IP、UDP和RTP头的开销。然而，每个分组包括几个帧块使得传输更容易受到分组丢失的影响，因此可以使用交织来减少分组丢失对语音质量的影响。处理大量客户端的流式服务器还需要一种有效负载格式，在进行打包时需要尽可能少的资源。八位组对齐和交错模式需要最少的资源，而CRC、健壮排序和带宽效率模式有更高的要求。
Another scenario is when AMR or AMR-WB encoded speech is transmitted from a non-IP system (e.g., a GSM or 3GPP UMTS network) to an IP/UDP/RTP VoIP terminal, and/or vice versa, as depicted in Figure 3.
另一种情况是，AMR或AMR-WB编码语音从非IP系统（例如，GSM或3GPP UMTS网络）传输到IP/UDP/RTP VoIP终端，和/或反之亦然，如图3所示。
AMR or AMR-WB
over
I.366.{2,3} or +------+ +----------+
3G Iu or | | IP/UDP/RTP/AMR or | |
<------------->| GW |<---------------------->| TERMINAL |
GSM Abis | | IP/UDP/RTP/AMR-WB | |
etc. +------+ +----------+
|
GSM/ | IP network
3GPP UMTS network |
AMR or AMR-WB
over
I.366.{2,3} or +------+ +----------+
3G Iu or | | IP/UDP/RTP/AMR or | |
<------------->| GW |<---------------------->| TERMINAL |
GSM Abis | | IP/UDP/RTP/AMR-WB | |
etc. +------+ +----------+
|
GSM/ | IP network
3GPP UMTS network |
Figure 3: GW to VoIP terminal scenario
图3:GW到VoIP终端场景
In such a case, it is likely that the AMR or AMR-WB frame is packetized in a different way in the non-IP network and will need to be re-packetized into RTP at the gateway. Also, speech frames from the non-IP network may come with some UEP/UED information (e.g., a frame quality indicator) that will need to be preserved and forwarded on to the decoder along with the speech bits. This is specified in Section 4.3.2.
在这种情况下，很可能AMR或AMR-WB帧在非IP网络中以不同的方式打包，并且需要在网关处重新打包到RTP中。此外，来自非IP网络的语音帧可能带有一些UEP/UED信息（例如，帧质量指示符），这些信息将需要被保存并与语音比特一起转发到解码器。第4.3.2节对此进行了规定。
AMR's capability to do fast mode switching is exploited in some non-IP networks to optimize speech quality. To preserve this functionality in scenarios including a gateway to an IP network, a codec mode request (CMR) field is needed. 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 must accommodate the delay imposed by the IP network on the IP terminal's response to CMR.
AMR的快速模式切换能力在一些非IP网络中被用来优化语音质量。为了在包括IP网络网关的场景中保留此功能，需要一个编解码器模式请求（CMR）字段。网关将负责在非IP和IP部分之间双向转发CMR。IP终端应遵循网关转发的CMR，以优化到非IP解码器的语音质量。网关中的模式控制算法必须适应IP网络对IP终端对CMR的响应施加的延迟。
The IP terminal should not set the CMR (see Section 4.3.1), 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. The gateway can alternatively set a lower CMR value, if desired, as one means to control congestion on the IP network.
IP终端不应设置CMR（参见第4.3.1节），但网关可以在非IP部分中朝向编码器的帧上设置CMR值，以优化从编码器到网关的语音质量。如果需要，网关也可以设置较低的CMR值，作为控制IP网络上拥塞的一种手段。
A third likely scenario is that IP/UDP/RTP 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 below.
第三种可能的情况是，IP/UDP/RTP用作两个非IP系统之间的传输，即，IP在IP传输两侧的网关中发起和终止，如下图4所示。
AMR or AMR-WB AMR or AMR-WB
over over
I.366.{2,3} or +------+ +------+ I.366.{2,3} or
3G Iu or | | IP/UDP/RTP/AMR or | | 3G Iu or
<------------->| GW |<------------------->| GW |<------------->
GSM Abis | | IP/UDP/RTP/AMR-WB | | GSM Abis
etc. +------+ +------+ etc.
| |
GSM/ | IP network | GSM/
3GPP UMTS network | | 3GPP UMTS network
AMR or AMR-WB AMR or AMR-WB
over over
I.366.{2,3} or +------+ +------+ I.366.{2,3} or
3G Iu or | | IP/UDP/RTP/AMR or | | 3G Iu or
<------------->| GW |<------------------->| GW |<------------->
GSM Abis | | IP/UDP/RTP/AMR-WB | | GSM Abis
etc. +------+ +------+ etc.
| |
GSM/ | IP network | GSM/
3GPP UMTS network | | 3GPP UMTS network
Figure 4: GW to GW scenario
图4:GW到GW情景
This scenario requires the same mechanisms for preserving UED/UEP and CMR information as in the single gateway scenario. In addition, 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 minimum of three values:
此场景需要与单网关场景中相同的机制来保存UED/UEP和CMR信息。此外，可以在由IP网络侧的网关接收的分组中设置CMR值。网关应向非IP侧转发至少三个值的CMR值：
- the CMR value it receives on the IP side;
- 它在IP端接收的CMR值；
- the CMR value it calculates based on its reception quality on the non-IP side; and
- 它基于其在非IP侧的接收质量计算的CMR值；和
- a CMR value it may choose for congestion control of transmission on the IP side.
- 它可以选择用于IP侧传输拥塞控制的CMR值。
The details of the control algorithm are left to the implementation.
控制算法的细节留待实现。
The AMR and AMR-WB payload formats have identical structure, so they are specified together. The only differences are in the types of codec frames contained in the payload. The payload format consists of the RTP header, payload header, and payload data.
AMR和AMR-WB有效负载格式具有相同的结构，因此它们一起指定。唯一的区别在于有效负载中包含的编解码器帧的类型。有效负载格式由RTP报头、有效负载报头和有效负载数据组成。
The format of the RTP header is specified in [8]. This payload format uses the fields of the header in a manner consistent with that specification.
RTP标头的格式在[8]中指定。此有效负载格式以与该规范一致的方式使用报头的字段。
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 sampling frequency, so the timestamp unit is in samples.
RTP时间戳对应于为分组中的第一帧块编码的第一样本的采样瞬间。时间戳时钟频率与采样频率相同，因此时间戳单元在采样中。
The duration of one speech frame-block is 20 ms for both AMR and AMR-WB. For AMR, the sampling frequency is 8 kHz, corresponding to 160 encoded speech samples per frame from each channel. For AMR-WB, the sampling frequency is 16 kHz, corresponding to 320 samples per frame from each channel. Thus, the timestamp is increased by 160 for AMR and 320 for AMR-WB for each consecutive frame-block.
对于AMR和AMR-WB，一个语音帧块的持续时间均为20ms。对于AMR，采样频率为8 kHz，对应于来自每个信道的每帧160个编码语音样本。对于AMR-WB，采样频率为16 kHz，对应于每个通道每帧320个采样。因此，对于每个连续帧块，时间戳对于AMR增加160，对于AMR-WB增加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 as defined in Section 4.4.1. 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 rather than breaking a multi-frame-block packet into two, as explained in Section 4.3.2.
分组可以包含编码语音或舒适噪声参数的多个帧块。如果采用交织，则根据第4.4.1节中定义的交织规则拾取封装到有效载荷中的帧块。否则，每个分组覆盖一个或多个连续的20ms帧块间隔的周期。如果该时段内某个特定帧块的所有信道的数据丢失（例如，在某个其他传输格式的网关处），则可以指示该帧块不存在数据，而不是将多帧块分组一分为二，如第4.3.2节所述。
To allow for error resiliency through redundant transmission, the periods covered by multiple packets MAY overlap in time. A receiver MUST be prepared to receive any speech frame multiple times, in exact duplicates, in different AMR rate modes, or with data present in one packet and not present in another. If multiple versions of the same speech frame are received, it is RECOMMENDED that the mode with the highest rate be used by the speech decoder. A given frame MUST NOT be encoded as speech in one packet and comfort noise parameters in another.
为了允许通过冗余传输进行错误恢复，多个数据包覆盖的时间段可能在时间上重叠。接收器必须准备好多次接收任何语音帧，以精确的副本，以不同的AMR速率模式，或者数据存在于一个数据包中而不存在于另一个数据包中。如果接收到同一语音帧的多个版本，建议语音解码器使用速率最高的模式。给定的帧不能在一个数据包中编码为语音，在另一个数据包中编码为舒适噪声参数。
The payload length is always made an integral number of octets 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 in the header may be set and padding appended as specified in [8].
如有必要，通过填充零位，有效负载长度始终为八位字节的整数。如果需要额外的填充以使有效负载长度达到八位字节的更大倍数或出于某些其他目的，则可以按照[8]中的规定设置报头中RTP中的P位并附加填充。
The RTP header marker bit (M) 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).
如果包中携带的第一个帧块包含TalkSport中的第一个语音帧，则RTP报头标记位（M）应设置为1。对于所有其他数据包，标记位应设置为零（M=0）。
The assignment of an RTP payload type for this new packet format is outside the scope of this document, and will not be specified here. It is expected that the RTP profile 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.
此新数据包格式的RTP有效负载类型的分配超出了本文档的范围，此处将不进行指定。预计使用此有效负载格式的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 ...
+----------------+-------------------+----------------
Payloads containing more than one speech frame-block are called compound payloads.
包含多个语音帧块的有效载荷称为复合有效载荷。
The following sections describe the variations taken by the payload format depending on whether the AMR session is set up to use the bandwidth-efficient mode or octet-aligned mode and any of the OPTIONAL functions for robust sorting, interleaving, and frame CRCs. Implementations SHOULD support both bandwidth-efficient and octet-aligned operation to increase interoperability.
以下各节描述了有效负载格式的变化，具体取决于AMR会话是否设置为使用带宽效率模式或八位字节对齐模式，以及健壮排序、交织和帧CRC的任何可选功能。实现应同时支持带宽效率和八位字节对齐操作，以提高互操作性。
In bandwidth-efficient mode, the payload header simply consists of a 4-bit codec mode request:
在带宽有效模式下，有效负载报头仅由4位编解码器模式请求组成：
0 1 2 3
+-+-+-+-+
| CMR |
+-+-+-+-+
0 1 2 3
+-+-+-+-+
| CMR |
+-+-+-+-+
CMR (4 bits): Indicates a codec mode request sent to the speech encoder at the site of the receiver of this payload. The value of the CMR field is set to the frame type index of the corresponding speech mode being requested. The frame type index may be 0-7 for AMR, as defined in Table 1a in [2], or 0-8 for AMR-WB, as defined in Table 1a in [4]. CMR value 15 indicates that no mode request is present, and other values are for future use.
CMR（4位）：表示发送到此有效负载接收器站点的语音编码器的编解码器模式请求。CMR字段的值设置为所请求的相应语音模式的帧类型索引。AMR的帧类型索引可以是0-7（如[2]中表1a所定义），或者AMR-WB的帧类型索引可以是0-8（如[4]中表1a所定义）。CMR值15表示不存在模式请求，其他值供将来使用。
The codec mode request received in the CMR field is valid until the next codec mode request is received, i.e., a newly received CMR value corresponding to a speech mode, or NO_DATA overrides the previously received CMR value corresponding to a speech mode or NO_DATA. Therefore, if a terminal continuously wishes to receive frames in the
在接收到下一个编解码器模式请求之前，在CMR字段中接收到的编解码器模式请求是有效的，即，新接收到的对应于语音模式的CMR值，或无_数据覆盖先前接收到的对应于语音模式或无_数据的CMR值。因此，如果终端持续地希望在该帧中接收帧
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.
与模式X相同，它需要为其所有出站有效载荷设置CMR=X，如果终端没有首选接收模式，则应在其所有出站有效载荷中设置CMR=15。
If receiving a payload with a CMR value that is not a speech mode or NO_DATA, the CMR MUST be ignored by the receiver.
如果接收到CMR值不是语音模式或无_数据的有效载荷，则接收机必须忽略CMR。
In a multi-channel session, the codec mode request SHOULD be interpreted by the receiver of the payload as the desired encoding mode for all the channels in the session.
在多信道会话中，编解码器模式请求应由有效负载的接收器解释为会话中所有信道的所需编码模式。
An IP end-point SHOULD NOT set the codec mode request based on packet losses or other congestion indications, for several reasons:
IP端点不应基于数据包丢失或其他拥塞指示设置编解码器模式请求，原因如下：
- The other end of the IP path may be a gateway to a non-IP network (such as a radio link) that needs to set the CMR field to optimize performance on that network.
- IP路径的另一端可以是到需要设置CMR字段以优化该网络上的性能的非IP网络（例如无线电链路）的网关。
- Congestion on the IP network is managed by the IP sender, in this case, at the other end of the IP path. 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 adjusting the codec mode, but also includes adjusting the level of redundancy or number of frames per packet.
- IP网络上的拥塞由IP发送方管理，在这种情况下，是在IP路径的另一端。关于拥塞的反馈应该通过RTCP或其他方式提供给IP发送方，然后发送方可以选择使用最合适的机制避免拥塞。这可能包括调整编解码器模式，但也包括调整冗余级别或每个分组的帧数。
The encoder SHOULD follow a received codec mode request, but MAY change to a lower-numbered mode if it so chooses, 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 codec mode requests when sending speech to a multicast session but MAY use RTCP feedback information as a hint that a codec mode change is needed.
对于发送到多播组的数据包，必须将CMR字段设置为15。向多播会话发送语音时，语音发送器中的编码器应忽略编解码器模式请求，但可以使用RTCP反馈信息作为需要更改编解码器模式的提示。
The codec mode selection MAY be restricted by a session parameter to a subset of the available modes. If so, the requested mode MUST be among the signalled subset (see Section 8). If the received CMR value is outside the signalled subset of modes, it MUST be ignored.
编解码器模式选择可由会话参数限制为可用模式的子集。如果是这样，请求的模式必须在信号子集中（见第8节）。如果接收到的CMR值超出信号模式子集，则必须忽略该值。
The table of contents (ToC) consists of a list of ToC entries, each representing a speech frame.
目录（ToC）由ToC条目列表组成，每个条目代表一个语音帧。
In bandwidth-efficient mode, a ToC entry takes the following format:
在带宽效率模式下，ToC条目采用以下格式：
0 1 2 3 4 5
+-+-+-+-+-+-+
|F| FT |Q|
+-+-+-+-+-+-+
0 1 2 3 4 5
+-+-+-+-+-+-+
|F| FT |Q|
+-+-+-+-+-+-+
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, indicating either the AMR or AMR-WB speech coding mode or comfort noise (SID) mode of the corresponding frame carried in this payload.
FT（4位）：帧类型索引，指示此有效负载中承载的相应帧的AMR或AMR-WB语音编码模式或舒适噪声（SID）模式。
The value of FT is defined in Table 1a in [2] for AMR and in Table 1a in [4] for AMR-WB. FT=14 (SPEECH_LOST, only available for AMR-WB) and FT=15 (NO_DATA) are used to indicate frames that are either lost or not being transmitted in this payload, respectively.
[2]中的表1a和[4]中的表1a分别定义了AMR和AMR-WB的FT值。FT=14（语音_丢失，仅适用于AMR-WB）和FT=15（无_数据）分别用于指示在该有效载荷中丢失或未传输的帧。
NO_DATA (FT=15) frame could mean either that no data for that frame has been produced by the speech encoder or that no data for that frame is transmitted in the current payload (i.e., valid data for that frame could be sent in either an earlier or later packet).
NO_DATA（FT＝15）帧可能意味着语音编码器没有生成该帧的数据，或者在当前有效载荷中没有传输该帧的数据（即，该帧的有效数据可以在较早或较晚的分组中发送）。
If receiving a ToC entry with a FT value in the range 9-14 for AMR or 10-13 for AMR-WB, the whole packet SHOULD be discarded. This is to avoid the loss of data synchronization in the depacketization process, which can result in a huge degradation in speech quality.
如果接收到的ToC条目的FT值范围为9-14（适用于AMR）或10-13（适用于AMR-WB），则应丢弃整个数据包。这是为了避免在去分组过程中丢失数据同步，这可能导致语音质量的大幅下降。
Note that packets containing only NO_DATA frames SHOULD NOT be transmitted in any payload format configuration, except in the case of interleaving. Also, frame-blocks containing only NO_DATA frames at the end of a packet SHOULD NOT be transmitted in any payload format configuration, except in the case of interleaving. The AMR SCR/DTX is described in [6] and AMR-WB SCR/DTX in [7].
注意，不应以任何有效载荷格式配置传输仅包含NO_数据帧的数据包，除非在交织的情况下。此外，除了在交织的情况下，不应以任何有效载荷格式配置来传输在分组的末尾仅包含无_数据帧的帧块。[6]中描述了AMR SCR/DTX，而[7]中描述了AMR-WB SCR/DTX。
The extra comfort noise frame types specified in table 1a in [2] (i.e., GSM-EFR CN, IS-641 CN, and PDC-EFR CN) MUST NOT be used in this payload format because the standardized AMR codec is only required to implement the general AMR SID frame type and not those that are native to the incorporated encodings.
[2]中表1a中规定的额外舒适性噪声帧类型（即GSM-EFR CN、IS-641 CN和PDC-EFR CN）不得用于此有效载荷格式，因为标准化AMR编解码器仅需要实现一般AMR SID帧类型，而不是合并编码固有的帧类型。
Q (1 bit): Frame quality indicator. If set to 0, indicates the corresponding frame is severely damaged, and the receiver should set the RX_TYPE (see [6]) to either SPEECH_BAD or SID_BAD depending on the frame type (FT).
Q（1位）：帧质量指示器。如果设置为0，则表示相应的帧严重损坏，接收器应根据帧类型（FT）将RX_类型（参见[6]）设置为SPEECH_BAD或SID_BAD。
The frame quality indicator is included for interoperability with the ATM payload format described in ITU-T I.366.2, the UMTS Iu interface [20], as well as other transport formats. The frame quality indicator enables damaged frames to be forwarded to the speech decoder for error concealment. This can improve the speech quality more than dropping the damaged frames. See Section 4.4.2.1 for more details.
包括帧质量指示器是为了与ITU-T I.366.2中描述的ATM有效负载格式、UMTS Iu接口[20]以及其他传输格式进行互操作。帧质量指示器能够将损坏的帧转发到语音解码器以进行错误隐藏。这比丢弃损坏的帧更能提高语音质量。详见第4.4.2.1节。
For multi-channel sessions, the ToC entries of all frames from a frame-block are placed in the ToC in consecutive order as defined in Section 4.1 in [12]. When multiple frame-blocks are present in a packet in bandwidth-efficient mode, they will be placed in the packet in order of their creation time.
对于多信道会话，来自帧块的所有帧的ToC条目按照[12]第4.1节中定义的连续顺序放置在ToC中。当多个帧块以带宽有效模式存在于数据包中时，它们将按创建时间的顺序放置在数据包中。
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.
因此，对于分组中的N个信道和K个语音帧块，ToC中必须有N×K个条目，并且前N个条目将来自第一帧块，第二N个条目将来自第二帧块，依此类推。
The following figure shows an example of a ToC of three entries in a single-channel session using bandwidth-efficient mode.
下图显示了使用带宽有效模式的单通道会话中三个条目的ToC示例。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| FT |Q|1| FT |Q|0| FT |Q|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| FT |Q|1| FT |Q|0| FT |Q|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Below is an example of how the ToC entries will appear in the ToC of a packet carrying three consecutive frame-blocks in a session with two channels (L and R).
下面是在具有两个信道（L和R）的会话中携带三个连续帧块的分组的ToC中ToC条目将如何出现的示例。
+----+----+----+----+----+----+
| 1L | 1R | 2L | 2R | 3L | 3R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame- Frame- Frame-
Block 1 Block 2 Block 3
+----+----+----+----+----+----+
| 1L | 1R | 2L | 2R | 3L | 3R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame- Frame- Frame-
Block 1 Block 2 Block 3
Speech data of a payload contains zero or more speech frames or comfort noise frames, as described in the ToC of the payload.
有效载荷的语音数据包含零个或多个语音帧或舒适噪声帧，如有效载荷的ToC中所述。
Note, for ToC entries with FT=14 or 15, there will be no corresponding speech frame present in the speech data.
注意，对于FT=14或15的ToC条目，语音数据中将不存在相应的语音帧。
Each speech frame represents 20 ms of speech encoded with the mode indicated in the FT field of the corresponding ToC entry. The length of the speech frame is implicitly defined by the mode indicated in the FT field. The order and numbering notation of the bits are as specified for Interface Format 1 (IF1) in [2] for AMR and [4] for AMR-WB. As specified there, the bits of speech frames have been rearranged in order of decreasing sensitivity, while the bits of comfort noise frames are in the order produced by the encoder. The resulting bit sequence for a frame of length K bits is denoted d(0), d(1), ..., d(K-1).
每个语音帧表示20 ms的语音，该语音编码模式在相应ToC条目的FT字段中指示。语音帧的长度由FT字段中指示的模式隐式定义。位的顺序和编号符号与[2]中AMR和[4]中AMR-WB接口格式1（IF1）的规定一致。如这里所规定的，语音帧的比特已按降低灵敏度的顺序重新排列，而舒适噪声帧的比特则按编码器产生的顺序排列。长度为K比特的帧的结果比特序列表示为d（0），d（1），…，d（K-1）。
The complete RTP payload in bandwidth-efficient mode is formed by packing bits from the payload header, table of contents, and speech frames in order (as defined by their corresponding ToC entries in the ToC list), and to bring the payload to octet alignment, 0 to 7 padding bits. Padding bits MUST be set to zero and MUST be ignored on reception. They are packed contiguously into octets beginning with the most significant bits of the fields and the octets.
带宽有效模式下的完整RTP有效负载是通过按顺序（由ToC列表中相应的ToC条目定义）打包来自有效负载报头、目录和语音帧的位，并将有效负载调整为八位字节对齐（0到7个填充位）形成的。填充位必须设置为零，并且在接收时必须忽略。它们被连续地压缩成八位字节，从字段的最高有效位和八位字节开始。
To be precise, the four-bit payload header is packed into the first octet of the payload with bit 0 of the payload header in the most significant bit of the octet. The four most significant bits (numbered 0-3) of the first ToC entry are packed into the least significant bits of the octet, ending with bit 3 in the least significant bit. Packing continues in the second octet with bit 4 of the first ToC entry in the most significant bit of the octet. If more than one frame is contained in the payload, then packing continues with the second and successive ToC entries. Bit 0 of the first data frame follows immediately after the last ToC bit, proceeding through all the bits of the frame in numerical order. Bits from any successive frames follow contiguously in numerical order for each frame and in consecutive order of the frames.
准确地说，四位有效负载报头被压缩到有效负载的第一个八位字节中，有效负载报头的位0位于八位字节的最高有效位。第一个ToC条目的四个最高有效位（编号为0-3）被压缩到八位字节的最低有效位中，以最低有效位中的第3位结束。在第二个八位字节中继续打包，第一个ToC条目的第4位位于八位字节的最高有效位。如果有效载荷中包含一个以上的帧，则继续打包第二个和连续的ToC条目。第一个数据帧的位0紧跟在最后一个ToC位之后，以数字顺序通过该帧的所有位。来自任何连续帧的比特以数字顺序和帧的连续顺序连续跟随每个帧。
If speech data is missing for one or more speech frame within the sequence, because of, for example, DTX, a ToC entry with FT set to NO_DATA SHALL be included in the ToC for each of the missing frames, but no data bits are included in the payload for the missing frame (see Section 4.3.5.2 for an example).
如果序列中一个或多个语音帧的语音数据丢失，例如，由于DTX，对于每个丢失的帧，应在ToC中包括FT设置为NO_data的ToC条目，但对于丢失的帧，有效载荷中不包括任何数据位（示例见第4.3.5.2节）。
The following diagram shows a bandwidth-efficient AMR payload from a single-channel session carrying a single speech frame-block.
下图显示了来自承载单个语音帧块的单通道会话的带宽有效AMR有效负载。
In the payload, no specific mode is requested (CMR=15), the speech frame is not damaged at the IP origin (Q=1), and the coding mode is AMR 7.4 kbps (FT=4). The encoded speech bits, d(0) to d(147), are arranged in descending sensitivity order according to [2]. Finally, two padding bits (P) are added to the end as padding to make the payload octet aligned.
在有效载荷中，未请求特定模式（CMR=15），语音帧在IP原点未损坏（Q=1），编码模式为AMR 7.4 kbps（FT=4）。编码的语音比特d（0）到d（147）按照[2]按灵敏度降序排列。最后，将两个填充位（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=15|0| FT=4 |1|d(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d(147)|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=15|0| FT=4 |1|d(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d(147)|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following diagram shows a single-channel, bandwidth-efficient compound AMR-WB payload that contains four frames, of which one has no speech data. The first frame is a speech frame at 6.6 kbps mode (FT=0) that is composed of speech bits d(0) to d(131). The second frame is an AMR-WB SID frame (FT=9), consisting of bits g(0) to g(39). The third frame is a NO_DATA frame and does not carry any speech information, it is represented in the payload by its ToC entry. The fourth frame in the payload is a speech frame at 8.85 kbps mode (FT=1), it consists of speech bits h(0) to h(176).
下图显示了一个单通道、带宽有效的复合AMR-WB有效负载，其中包含四个帧，其中一个帧没有语音数据。第一帧是以6.6kbps模式（FT＝0）的语音帧，其由语音比特d（0）到d（131）组成。第二帧是AMR-WB SID帧（FT=9），由位g（0）到g（39）组成。第三帧是NO_数据帧，不携带任何语音信息，通过其ToC条目在有效载荷中表示。有效载荷中的第四帧是8.85 kbps模式（FT=1）下的语音帧，它由语音比特h（0）到h（176）组成。
As shown below, the payload carries a mode request for the encoder on the receiver's side to change its future coding mode to AMR-WB 8.85 kbps (CMR=1). None of the frames are damaged at IP origin (Q=1). The encoded speech and SID bits, d(0) to d(131), g(0) to g(39), and h(0) to h(176), are arranged in the payload in descending sensitivity order according to [4]. (Note, no speech bits are present for the third frame.) Finally, seven zero bits are padded to the end to make the payload octet aligned.
如下图所示，有效载荷携带一个模式请求，用于接收器侧的编码器将其未来编码模式更改为AMR-WB 8.85 kbps（CMR=1）。在IP原点（Q=1）没有任何机架损坏。已编码语音和SID位d（0）到d（131）、g（0）到g（39）和h（0）到h（176）按照[4]的灵敏度降序排列在有效载荷中。（注意，第三帧不存在语音位。）最后，七个零位被填充到末尾，以使有效负载八位组对齐。
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=1 |1| FT=0 |1|1| FT=9 |1|1| FT=15 |1|0| FT=1 |1|d(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d(131)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|g(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| g(39)|h(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h(176)|P|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=1 |1| FT=0 |1|1| FT=9 |1|1| FT=15 |1|0| FT=1 |1|d(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d(131)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|g(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| g(39)|h(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h(176)|P|P|P|P|P|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following diagram shows a two-channel payload carrying 3 frame-blocks, i.e., the payload will contain 6 speech frames.
下图显示了承载3个帧块的双信道有效载荷，即有效载荷将包含6个语音帧。
In the payload, all speech frames contain the same mode 7.4 kbps (FT=4) and are not damaged at IP origin. The CMR is set to 15, i.e., no specific mode is requested. The two channels are defined as left (L) and right (R) in that order. The encoded speech bits is designated dXY(0).. dXY(K-1), where X = block number, Y = channel, and K is the number of speech bits for that mode. Exemplifying this, for frame-block 1 of the left channel, the encoded bits are designated as d1L(0) to d1L(147).
在有效载荷中，所有语音帧都包含相同的模式7.4 kbps（FT=4），并且在IP原点不会损坏。CMR设置为15，即不请求特定模式。这两个通道按该顺序定义为左（L）和右（R）。编码的语音位被指定为dXY（0）。。dXY（K-1），其中X=块号，Y=通道，K是该模式的语音位数。举例来说，对于左信道的帧块1，编码比特被指定为d1L（0）到d1L（147）。
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=15|1|1L FT=4|1|1|1R FT=4|1|1|2L FT=4|1|1|2R FT=4|1|1|3L FT|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|4|1|0|3R FT=4|1|d1L(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d1L(147)|d1R(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d1R(147)|d2L(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|d2L(147|d2R(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d2R(147)|d3L(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d3L(147)|d3R(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d3R(147)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=15|1|1L FT=4|1|1|1R FT=4|1|1|2L FT=4|1|1|2R FT=4|1|1|3L FT|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|4|1|0|3R FT=4|1|d1L(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d1L(147)|d1R(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d1R(147)|d2L(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|d2L(147|d2R(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d2R(147)|d3L(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d3L(147)|d3R(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d3R(147)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In octet-aligned mode, 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): same as defined in Section 4.3.1.
CMR（4位）：与第4.3.1节中的定义相同。
R: is a reserved bit that MUST be set to zero. All R bits MUST be ignored by the receiver.
R：是必须设置为零的保留位。接收器必须忽略所有R位。
ILL (4 bits, unsigned integer): This is an OPTIONAL field that is present only if interleaving is signalled 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 signalled. ILP MUST take a value between 0 and ILL, inclusive, indicating the interleaving index for frame-blocks in this payload in the interleaving 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 signalled for the session. Interleaving MUST be performed on a frame-block basis (i.e., NOT on a frame basis) in a multi-channel session.
如果为会话发出交织信号，则会话中的每个数据包中必须存在ILL和ILP字段。在多信道会话中，必须以帧块为基础（即，不以帧为基础）执行交织。
The following example illustrates the arrangement of speech frame-blocks in an interleaving group during an interleaving session. Here we assume ILL=L for the interleaving group that starts at speech frame-block n. We also assume that the first payload packet of the interleaving 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 interleaving group):
ILL=L, ILP=0,
Carry frame-blocks: n, n+(L+1), n+2*(L+1), ..., n+(N-1)*(L+1)
Payload s (the first packet of this interleaving group):
ILL=L, ILP=0,
Carry frame-blocks: n, n+(L+1), n+2*(L+1), ..., n+(N-1)*(L+1)
Payload s+1 (the second packet of this interleaving group): ILL=L, ILP=1, frame-blocks: n+1, n+1+(L+1), n+1+2*(L+1), ..., n+1+(N-1)*(L+1) ...
有效载荷s+1（该交织组的第二个分组）：ILL=L，ILP=1，帧块：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 interleaving group):
ILL=L, ILP=L,
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 interleaving group):
ILL=L, ILP=L,
frame-blocks: n+L, n+L+(L+1), n+L+2*(L+1), ..., n+L+(N-1)*(L+1)
The next interleaving group will start at frame-block n+N*(L+1).
下一个交织组将从帧块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 interleaving group. In other words, all payloads in an interleaving group MUST have the same ILL and MUST contain the same number of speech frame-blocks.
除非每个包（N）的帧块数至少为2，否则将不会有交织效果。此外，每个有效负载的帧块数（N）和ILL的值不得在交织组内改变。换句话说，交织组中的所有有效负载必须具有相同的ILL，并且必须包含相同数量的语音帧块。
The sender of the payload MUST only apply interleaving if the receiver has signalled its use through out-of-band means. Since interleaving will increase buffering requirements at the receiver, the receiver uses media type parameter "interleaving=I" to set the maximum number of frame-blocks allowed in an interleaving group to I.
如果接收器已通过带外方式发出使用信号，则有效载荷的发送方必须仅应用交织。由于交织将增加接收机处的缓冲要求，接收机使用媒体类型参数“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 interleaving group is less or equal to I, that is, N*(L+1)<=I.
当执行交织时，发送方必须为每个有效载荷（N）和ILL使用适当数量的帧块，以便交织组的结果大小小于或等于I，即N*（L+1）<=I。
The table of contents (ToC) in octet-aligned mode consists of a list of ToC entries where each entry corresponds to a speech frame carried in the payload and, optionally, a list of speech frame CRCs. That is, the ToC is as follows:
八位组对齐模式下的目录（ToC）包括ToC条目列表，其中每个条目对应于有效载荷中携带的语音帧，并且可选地，还包括语音帧CRC列表。即目标为：
+---------------------+
| list of ToC entries |
+---------------------+
| list of frame CRCs | (optional)
- - - - - - - - - - -
+---------------------+
| list of ToC entries |
+---------------------+
| list of frame CRCs | (optional)
- - - - - - - - - - -
Note, for ToC entries with FT=14 or 15, there will be no corresponding speech frame or frame CRC present in the payload.
注意，对于FT=14或15的ToC条目，有效载荷中将不存在相应的语音帧或帧CRC。
The list of ToC entries is organized in the same way as described for bandwidth-efficient mode in 4.3.2, with the following exception: when interleaving is used, the frame-blocks in the ToC will almost never be placed consecutively in time. Instead, the presence and order of the frame-blocks in a packet will follow the pattern described in 4.4.1.
ToC条目列表的组织方式与4.3.2中描述的带宽效率模式相同，但以下情况除外：当使用交织时，ToC中的帧块几乎永远不会在时间上连续放置。相反，数据包中帧块的存在和顺序将遵循4.4.1中描述的模式。
The following example shows the ToC of three consecutive packets, each carrying three frame-blocks, in an interleaved two-channel session. 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 results in the interleaving group size of 9 frame-blocks.
以下示例显示了在交织双信道会话中三个连续分组的ToC，每个分组携带三个帧块。这里，两个信道是左（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:
+----+----+----+----+----+----+
| 2L | 2R | 5L | 5R | 8L | 8R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame- Frame- Frame-
Block 2 Block 5 Block 8
ILL=2, ILP=1:
+----+----+----+----+----+----+
| 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
A ToC entry takes the following format in octet-aligned mode:
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|
+-+-+-+-+-+-+-+-+
F (1 bit): see definition in Section 4.3.2.
F（1位）：见第4.3.2节中的定义。
FT (4 bits, unsigned integer): see definition in Section 4.3.2.
FT（4位，无符号整数）：见第4.3.2节中的定义。
Q (1 bit): see definition in Section 4.3.2.
Q（1位）：见第4.3.2节中的定义。
P bits: padding bits, MUST be set to zero, and MUST be ignored on reception.
P位：填充位，必须设置为零，并且在接收时必须忽略。
The list of CRCs is OPTIONAL. It only exists if the use of CRC is signalled out-of-band for the session. When present, each CRC in the list is 8 bits long and corresponds to a speech frame (NOT a frame-block) carried in the payload. Calculation and use of the CRC is specified in the next section.
CRC列表是可选的。只有当会话的CRC使用在带外发出信号时，它才存在。当存在时，列表中的每个CRC为8比特长，并且对应于有效载荷中携带的语音帧（不是帧块）。CRC的计算和使用将在下一节中详细说明。
The general concept of UED/UEP over IP is discussed in Section 3.6. This section provides more details on how to use the frame CRC in the octet-aligned payload header together with a partial transport layer checksum to achieve UED.
第3.6节讨论了IP上的UED/UEP的一般概念。本节提供了有关如何在八位字节对齐的有效负载报头中使用帧CRC以及部分传输层校验和来实现UED的更多详细信息。
To achieve UED, one SHOULD use a transport layer checksum (for example, the one defined in UDP-Lite [19]) to protect the IP, transport protocol (e.g., UDP-Lite), and RTP headers, as well as the payload header and the table of contents in the payload. The frame CRC, when used, MUST be calculated only over all class A bits in the AMR or AMR-WB frame. Class B and C bits in the AMR or AMR-WB frame MUST NOT be included in the CRC calculation and SHOULD NOT be covered by the transport checksum.
要实现UED，应使用传输层校验和（例如，UDP Lite[19]中定义的校验和）来保护IP、传输协议（例如UDP Lite）和RTP报头，以及有效负载中的有效负载报头和目录。使用帧CRC时，必须仅对AMR或AMR-WB帧中的所有A类位进行计算。AMR或AMR-WB帧中的B类和C类位不得包含在CRC计算中，且不应包含在传输校验和中。
Note, the number of class A bits for various coding modes in AMR codec is specified as informative in [2] and is therefore copied into Table 1 in Section 3.6 to make it normative for this payload format. The number of class A bits for various coding modes in AMR-WB codec is specified as normative in Table 2 in [4], and the SID frame (FT=9) has 40 class A bits. These definitions of class A bits MUST be used for this payload format.
注意，AMR编解码器中各种编码模式的A类比特数在[2]中被指定为信息性的，因此被复制到第3.6节的表1中，以使其成为该有效载荷格式的标准。[4]中的表2中规定了AMR-WB编解码器中各种编码模式的A类比特数，SID帧（FT=9）有40个A类比特。此类A类位的定义必须用于此有效负载格式。
If the transport layer checksum or link layer checksum detects any errors within the protected (sensitive) part, it is assumed that the complete packet will be discarded as defined by UDP-Lite [19].
如果传输层校验和或链路层校验和检测到受保护（敏感）部分内的任何错误，则假定完整数据包将被丢弃，如UDP Lite[19]所定义。
The receiver of the payload SHOULD examine the data integrity of the received class A bits by re-calculating the CRC over the received class A bits and comparing the result to the value found in the received payload header. If the two values mismatch, the receiver SHALL consider the class A bits in the receiver frame damaged and MUST clear the Q flag of the frame (i.e., set it to 0). This will subsequently cause the frame to be marked as SPEECH_BAD, if the FT of the frame is 0..7 for AMR or 0..8 for AMR-WB, or SID_BAD if the FT of the frame is 8 for AMR or 9 for AMR-WB, before it is passed to the speech decoder. See [6] and [7] more details.
有效载荷的接收器应通过重新计算接收到的A类比特上的CRC并将结果与接收到的有效载荷报头中的值进行比较来检查接收到的A类比特的数据完整性。如果两个值不匹配，接收机应考虑接收机帧中的A类位损坏，并且必须清除帧的Q标志（即，将其设置为0）。如果AMR的帧FT为0..7或AMR-WB的帧FT为0..8，则随后会导致该帧被标记为SPEECH_BAD；如果AMR的帧FT为8或AMR-WB的帧FT为9，则会导致该帧被标记为SID_BAD，然后再传递到语音解码器。更多详细信息，请参见[6]和[7]。
The following example shows an octet-aligned ToC with a CRC list for a payload containing 3 speech frames from a single-channel session (assuming none of the FTs is equal to 14 or 15):
以下示例显示了八位组对齐的ToC与包含来自单信道会话的3个语音帧的有效负载的CRC列表（假设没有一个FTs等于14或15）：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| FT#1 |Q|P|P|1| FT#2 |Q|P|P|0| FT#3 |Q|P|P| CRC#1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC#2 | CRC#3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| FT#1 |Q|P|P|1| FT#2 |Q|P|P|0| FT#3 |Q|P|P| CRC#1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC#2 | CRC#3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each of the CRCs takes 8 bits
每个CRC占用8位
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| c0| c1| c2| c3| c4| c5| c6| c7|
+---+---+---+---+---+---+---+---+
(MSB) (LSB)
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| c0| c1| c2| c3| c4| c5| c6| c7|
+---+---+---+---+---+---+---+---+
(MSB) (LSB)
and is calculated by the cyclic generator polynomial,
由循环生成器多项式计算，
C(x) = 1 + x^2 + x^3 + x^4 + x^8
C(x) = 1 + x^2 + x^3 + x^4 + x^8
where ^ is the exponentiation operator.
其中^是求幂运算符。
In binary form, the polynomial appears as follows: 101110001 (MSB..LSB).
在二进制形式中，多项式如下所示：101110001（MSB..LSB）。
The actual calculation of the CRC is made as follows: First, an 8-bit CRC register is reset to zero: 00000000. For each bit over which the CRC shall be calculated, an XOR operation is made between the rightmost (LSB) bit of the CRC register and the bit. The CRC
CRC的实际计算如下：首先，将8位CRC寄存器重置为零：00000000。对于计算CRC的每一位，在CRC寄存器的最右边（LSB）位和该位之间进行异或运算。CRC
register is then right-shifted one step (each bit's significance is reduced by one), inputting a "0" as the leftmost bit (MSB). If the result of the XOR operation mentioned above is a "1", then "10111000" is bit-wise XOR-ed into the CRC register. This operation is repeated for each bit that the CRC should cover. In this case, the first bit would be d(0) for the speech frame for which the CRC should cover. When the last bit (e.g., d(54) for AMR 5.9 according to Table 1 in Section 3.6) has been used in this CRC calculation, the contents in CRC register should simply be copied to the corresponding field in the list of CRCs.
然后寄存器右移一步（每一位的重要性减少一），输入一个“0”作为最左边的位（MSB）。如果上述异或运算的结果为“1”，则“10111000”被按位异或写入CRC寄存器。对CRC应覆盖的每个位重复此操作。在这种情况下，CRC应该覆盖的语音帧的第一位将是d（0）。当在该CRC计算中使用了最后一位（例如，根据第3.6节表1，AMR 5.9的d（54））时，CRC寄存器中的内容应简单地复制到CRC列表中的相应字段。
Fast calculation of the CRC on a general-purpose CPU is possible using a table-driven algorithm.
使用表驱动算法可以在通用CPU上快速计算CRC。
In octet-aligned mode, speech data is carried in a similar way to that in the bandwidth-efficient mode as discussed in Section 4.3.3, with the following exceptions:
在八进制对齐模式下，语音数据的传输方式与第4.3.3节中讨论的带宽效率模式类似，但以下情况除外：
- The last octet of each speech frame MUST be padded with zero bits at the end if all bits in the octet are not used. The padding bits MUST be ignored on reception. In other words, each speech frame MUST be octet-aligned.
- 如果未使用八位字节中的所有位，则每个语音帧的最后一个八位字节必须在结尾处填充零位。接收时必须忽略填充位。换句话说，每个语音帧必须是八位组对齐的。
- When multiple speech frames are present in the speech data (i.e., compound payload), the speech frames are arranged either one whole frame after another as usual, or with the octets of all frames interleaved together at the octet level, depending on the media type parameters negotiated for the payload type. Since the bits within each frame are ordered with the most error-sensitive bits first, interleaving the octets collects those sensitive bits from all frames to be nearer the beginning of the packet. This is called "robust sorting order" which allows the application of UED (such as UDP-Lite [19]) or UEP (such as the ULP [22]) mechanisms to the payload data. The details of assembling the payload are given in the next section.
- 当语音数据（即，复合有效载荷）中存在多个语音帧时，语音帧按照惯例一整帧接一整帧地排列，或者根据为有效载荷类型协商的媒体类型参数，所有帧的八位字节在八位字节级别交织在一起。由于每个帧内的位首先以对错误最敏感的位排序，所以交叉排列八位字节会从所有帧收集这些敏感位，使其更接近数据包的开头。这称为“鲁棒排序顺序”，允许对有效负载数据应用UED（如UDP Lite[19]）或UEP（如ULP[22]）机制。下一节将给出组装有效负载的详细信息。
The use of robust sorting order for a payload type MUST be agreed via out-of-band means. Section 8 specifies a media type parameter for this purpose.
有效负载类型的稳健排序顺序的使用必须通过带外方式达成一致。第8节为此指定了媒体类型参数。
Note, robust sorting order MUST only be performed on the frame level and thus is independent of interleaving, which is at the frame-block level, as described in Section 4.4.1. In other words, robust sorting can be applied to either non-interleaved or interleaved payload types.
注意，鲁棒排序顺序必须仅在帧级执行，因此独立于帧块级的交织，如第4.4.1节所述。换句话说，健壮排序可以应用于非交织或交织负载类型。
Two different packetization methods, namely, normal order and robust sorting order, exist for forming a payload in octet-aligned mode. In both cases, the payload header and table of contents are packed into the payload the same way; the difference is in the packing of the speech frames.
存在两种不同的分组方法，即正常顺序和鲁棒排序顺序，用于在八位组对齐模式下形成有效负载。在这两种情况下，有效载荷标题和目录以相同的方式打包到有效载荷中；区别在于语音帧的包装。
The payload begins with the payload header of one octet, or two octets if frame interleaving is selected. The payload header is followed by the table of contents consisting of a list of one-octet ToC entries. If frame CRCs are to be included, they follow the table of contents with one 8-bit CRC filling each octet. Note that if a given frame has a ToC entry with FT=14 or 15, there will be no CRC present.
有效载荷从一个八位字节的有效载荷头开始，如果选择了帧交织，则从两个八位字节的有效载荷头开始。有效载荷标题后面是由一个八位字节ToC条目列表组成的目录。如果要包括帧CRC，则它们遵循目录，每个八位字节填充一个8位CRC。请注意，如果给定帧具有FT=14或15的ToC条目，则不存在CRC。
The speech data follows the table of contents, or the CRCs if present. For packetization in the normal order, all of 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.
语音数据遵循目录或CRC（如果存在）。对于正常顺序的分组，组成语音帧的所有八位字节作为一个单元附加到有效载荷。语音帧的打包顺序与其对应的ToC条目在ToC列表中的排列顺序相同，但如果给定帧具有FT=14或15的ToC条目，则该帧将不存在数据八位字节。
For packetization in robust sorting order, the octets of all speech frames are interleaved together at the octet level. That is, the data portion of the payload begins with the first octet of the first frame, followed by the first octet of the second frame, then the first octet of the third frame, and so on. After the first octet of the last frame has been appended, the cycle repeats with the second octet of each frame. The process continues for as many octets as are present in the longest frame. If the frames are not all the same octet length, a shorter frame is skipped once all octets in it have been appended. The order of the frames in the cycle will be sequential if frame interleaving is not in use, or according to the interleave pattern specified in the payload header if frame interleaving is in use. Note that if a given frame has a ToC entry with FT=14 or 15, there will be no data octets present for that frame, so it is skipped in the robust sorting cycle.
为了以稳健的排序顺序进行分组，所有语音帧的八位字节在八位字节级别交织在一起。也就是说，有效载荷的数据部分从第一帧的第一个八位组开始，接着是第二帧的第一个八位组，然后是第三帧的第一个八位组，依此类推。追加最后一帧的第一个八位字节后，循环将与每一帧的第二个八位字节一起重复。这个过程持续到最长帧中出现的八位字节数。如果帧不都是相同的八位字节长度，则在附加了其中的所有八位字节后，将跳过较短的帧。如果未使用帧交织，则循环中的帧顺序将是连续的，或者如果正在使用帧交织，则根据有效负载报头中指定的交织模式。请注意，如果给定帧具有FT=14或15的ToC条目，则该帧将不存在数据八位字节，因此在鲁棒排序循环中跳过该八位字节。
The UED and/or UEP is RECOMMENDED to cover at least the RTP header, payload header, table of contents, and class A bits of a sorted payload. Exactly how many octets need to be covered depends on the network and application. If CRCs are used together with robust sorting, only the RTP header, the payload header, and the ToC SHOULD be covered by UED/UEP. The means for communicating the number of octets to be covered to other layers performing UED/UEP is beyond the scope of this specification.
建议UED和/或UEP至少覆盖RTP报头、有效载荷报头、目录和排序有效载荷的A类比特。具体需要覆盖多少个八位组取决于网络和应用程序。如果CRC与稳健排序一起使用，则UED/UEP仅涵盖RTP报头、有效负载报头和ToC。用于向执行UED/UEP的其他层传送要覆盖的八位字节数的方法超出了本规范的范围。
The following diagram shows an octet aligned payload from a single channel payload type that carries two AMR frames of 7.95 kbps coding mode (FT=5). In the payload, a codec mode request is sent (CMR=6), requesting the encoder at the receiver's side to use AMR 10.2 kbps coding mode. No frame CRC, interleaving, or robust sorting is in use.
下图显示了来自单信道有效负载类型的八位字节对齐有效负载，该有效负载承载两个7.95 kbps编码模式（FT=5）的AMR帧。在有效载荷中，发送编解码器模式请求（CMR=6），请求接收器侧的编码器使用AMR 10.2 kbps编码模式。没有使用帧CRC、交错或鲁棒排序。
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=6 |R|R|R|R|1|FT#1=5 |Q|P|P|0|FT#2=5 |Q|P|P| f1(0..7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f1(8..15) | f1(16..23) | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |f1(152..158) |P| f2(0..7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f2(8..15) | f2(16..23) | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |f2(152..158) |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=6 |R|R|R|R|1|FT#1=5 |Q|P|P|0|FT#2=5 |Q|P|P| f1(0..7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f1(8..15) | f1(16..23) | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |f1(152..158) |P| f2(0..7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f2(8..15) | f2(16..23) | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |f2(152..158) |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note, in the above example, the last octet in both speech frames is padded with one zero bit to make it octet-aligned.
注意，在上面的示例中，两个语音帧中的最后一个八位字节都用一个零位填充，以使其八位字节对齐。
This example shows an octet aligned payload from a two-channel payload type. Two frame-blocks, each containing two speech frames of 7.95 kbps coding mode (FT=5), are carried in this payload.
此示例显示来自双通道有效负载类型的八位组对齐有效负载。在该有效载荷中携带两个帧块，每个帧块包含两个7.95 kbps编码模式（FT=5）的语音帧。
The two channels are left (L) and right (R) with L coming before R. In the payload, a codec mode request is also sent (CMR=6), requesting the encoder at the receiver's side to use AMR 10.2 kbps coding mode.
这两个信道分别为左（L）和右（R），L在R之前。在有效载荷中，还发送了一个编解码器模式请求（CMR=6），请求接收机侧的编码器使用AMR 10.2 kbps编码模式。
Moreover, frame CRC, robust sorting, and frame-block interleaving are all enabled for the payload type. The interleaving length is 2 (ILL=1), and this payload is the first one in an interleaving group (ILP=0).
此外，帧CRC、鲁棒排序和帧块交织都针对有效负载类型启用。交织长度为2（ILL=1），该有效载荷是交织组中的第一个有效载荷（ILP=0）。
The first two frames in the payload are the L and R channel speech frames of frame-block #1, consisting of bits f1L(0..158) and f1R(0..158), respectively. The next two frames are the L and R channel frames of frame-block #3, consisting of bits f3L(0..158) and f3R(0..158), respectively, due to interleaving. For each of the four speech frames, a CRC is calculated as CRC1L(0..7), CRC1R(0..7), CRC3L(0..7), and CRC3R(0..7), respectively. Finally, the payload is robust sorted.
有效载荷中的前两个帧是帧块#1的L和R信道语音帧，分别由比特f1L（0..158）和f1R（0..158）组成。接下来的两个帧是帧块#3的L和R信道帧，由于交织，它们分别由比特f3L（0..158）和f3R（0..158）组成。对于四个语音帧中的每一个，CRC分别计算为CRC1L（0..7）、CRC1R（0..7）、CRC3L（0..7）和CRC3R（0..7）。最后，有效负载是健壮的。
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=6 |R|R|R|R| ILL=1 | ILP=0 |1|FT#1L=5|Q|P|P|1|FT#1R=5|Q|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|FT#3L=5|Q|P|P|0|FT#3R=5|Q|P|P| CRC1L | CRC1R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC3L | CRC3R | f1L(0..7) | f1R(0..7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f3L(0..7) | f3R(0..7) | f1L(8..15) | f1R(8..15) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f3L(8..15) | f3R(8..15) | f1L(16..23) | f1R(16..23) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f3L(144..151) | f3R(144..151) |f1L(152..158)|P|f1R(152..158)|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|f3L(152..158)|P|f3R(152..158)|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=6 |R|R|R|R| ILL=1 | ILP=0 |1|FT#1L=5|Q|P|P|1|FT#1R=5|Q|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|FT#3L=5|Q|P|P|0|FT#3R=5|Q|P|P| CRC1L | CRC1R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC3L | CRC3R | f1L(0..7) | f1R(0..7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f3L(0..7) | f3R(0..7) | f1L(8..15) | f1R(8..15) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f3L(8..15) | f3R(8..15) | f1L(16..23) | f1R(16..23) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f3L(144..151) | f3R(144..151) |f1L(152..158)|P|f1R(152..158)|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|f3L(152..158)|P|f3R(152..158)|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note, in the above example, the last octet in all four speech frames is padded with one zero bit to make it octet-aligned.
注意，在上面的示例中，所有四个语音帧中的最后一个八位字节都用一个零位填充，以使其八位字节对齐。
An application implementing this payload format MUST understand all the payload parameters in the out-of-band signaling used. For example, if an application uses SDP, all the SDP and media type parameters in this document MUST be understood. This requirement ensures that an implementation always can decide if it is capable or not of communicating.
实现此有效负载格式的应用程序必须了解所使用的带外信令中的所有有效负载参数。例如，如果应用程序使用SDP，则必须了解本文档中的所有SDP和媒体类型参数。此要求确保实现始终可以决定是否能够进行通信。
No operating mode of the payload format is mandatory to implement. The requirements of the application using the payload format should be used to determine what to implement. To achieve basic interoperability, an implementation SHOULD at least implement both bandwidth-efficient and octet-aligned modes for a single audio
有效负载格式的操作模式不强制实施。应该使用使用有效负载格式的应用程序的需求来确定要实现什么。为了实现基本的互操作性，实现应至少为单个音频实现带宽效率和八位字节对齐模式
channel. The other operating modes: interleaving, robust sorting, and frame-wise CRC (in both single and multi-channel) are OPTIONAL to implement.
频道其他操作模式：交错、鲁棒排序和逐帧CRC（在单通道和多通道中）是可选的。
The mode-change-period, mode-change-capability, and mode-change-neighbor parameters are intended for signaling with GSM endpoints. When interoperability with GSM is desired, encoders SHOULD only perform codec mode changes to neighboring modes and in integer multiples of 40 ms (two frame-blocks), but decoders SHOULD accept codec mode changes at any time, i.e., for every frame-block. The encoder may arbitrarily select the initial phase (odd or even frame-block) where codec mode changes are performed, but then SHOULD stick to that phase as far as possible. However, in rare cases, handovers or other events (e.g., call forwarding) may change this phase and may also cause mode changes to non-neighboring modes. The decoder SHALL therefore be prepared to accept changes also in the other phase and to other modes. Section 8 specifies the usage of the parameters mode-change-period and mode-change-capability to indicate the desired behavior in applications.
模式改变周期、模式改变能力和模式改变邻居参数用于与GSM端点进行信令。当需要与GSM的互操作性时，编码器应仅以40 ms的整数倍（两个帧块）对相邻模式执行编解码器模式更改，但解码器应随时接受编解码器模式更改，即对每个帧块。编码器可任意选择执行编解码器模式改变的初始相位（奇数或偶数帧块），但随后应尽可能地坚持该相位。然而，在极少数情况下，切换或其他事件（例如，呼叫转移）可能会改变此阶段，并且还可能导致模式改变为非相邻模式。因此，解码器应准备接受其他阶段和其他模式的变化。第8节规定了参数模式更改周期和模式更改能力的使用，以指示应用程序中的预期行为。
See 3GPP TS 26.103 [28] for preferred AMR and AMR-WB configurations for operation in GSM and 3GPP UMTS networks. In gateway scenarios, encoders can be requested through the "mode-set" parameter to use a limited mode-set that is supported by the link beyond the gateway. Further, to avoid congestion on that link, the encoder SHOULD limit the initial codec mode for a session to a lower mode, until at least one frame-block is received with rate control information.
有关在GSM和3GPP UMTS网络中运行的首选AMR和AMR-WB配置，请参见3GPP TS 26.103[28]。在网关方案中，可以通过“mode set”参数请求编码器使用网关以外链路支持的有限模式集。此外，为了避免该链路上的拥塞，编码器应将会话的初始编解码器模式限制为较低模式，直到接收到具有速率控制信息的至少一个帧块。
When processing a received payload packet, if the receiver finds that the calculated payload length, based on the information for the payload type and the values found in the payload header fields, does not match the size of the received packet, the receiver SHOULD discard the packet. This is because decoding a packet that has errors in its length field could severely degrade the speech quality.
在处理接收到的有效载荷数据包时，如果接收机发现基于有效载荷类型信息和有效载荷报头字段中的值计算出的有效载荷长度与接收到的数据包的大小不匹配，则接收机应丢弃该数据包。这是因为对长度字段中有错误的数据包进行解码可能会严重降低语音质量。
The storage format is used for storing AMR or AMR-WB speech frames in a file or as an email attachment. Multiple channel content is supported.
存储格式用于将AMR或AMR-WB语音帧存储在文件中或作为电子邮件附件。支持多频道内容。
In general, an AMR or AMR-WB file has the following structure:
通常，AMR或AMR-WB文件具有以下结构：
+------------------+
| Header |
+------------------+
| Speech frame 1 |
+------------------+
: ... :
+------------------+
| Speech frame n |
+------------------+
+------------------+
| Header |
+------------------+
| Speech frame 1 |
+------------------+
: ... :
+------------------+
| Speech frame n |
+------------------+
Note, to preserve interoperability with already deployed implementations, single-channel content uses a file header format different from that of multi-channel content.
注意，为了保持与已部署的实现的互操作性，单通道内容使用不同于多通道内容的文件头格式。
There also exists another storage format for AMR and AMR-WB that is suitable for applications with more advanced demands on the storage format, like random access or synchronization with video. This format is the 3GPP-specified ISO-based multimedia file format 3GP [31]. Its media type is specified by RFC 3839 [32].
AMR和AMR-WB还存在另一种存储格式，适用于对存储格式有更高级要求的应用程序，如随机访问或与视频同步。此格式是3GPP指定的基于ISO的多媒体文件格式3GP[31]。其媒体类型由RFC 3839[32]指定。
A single-channel AMR or AMR-WB file header contains only a magic number. Different magic numbers are defined to distinguish AMR from AMR-WB.
单通道AMR或AMR-WB文件头仅包含一个幻数。定义了不同的幻数来区分AMR和AMR-WB。
The magic number for single-channel AMR files MUST consist of ASCII character string:
单通道AMR文件的幻数必须由ASCII字符串组成：
"#!AMR\n" (or 0x2321414d520a in hexadecimal).
“#！AMR\n”（或十六进制的0x2321414d520a）。
The magic number for single-channel AMR-WB files MUST consist of ASCII character string:
单通道AMR-WB文件的幻数必须由ASCII字符串组成：
"#!AMR-WB\n" (or 0x2321414d522d57420a in hexadecimal).
“#！AMR-WB\n”（或十六进制格式的0x2321414d522d57420a）。
Note, the "\n" is an important part of the magic numbers and MUST be included in the comparison, since, otherwise, the single-channel magic numbers above will become indistinguishable from those of the multi-channel files defined in the next section.
请注意，“\n”是幻数的重要组成部分，必须包含在比较中，否则，上面的单通道幻数将无法与下一节中定义的多通道文件的幻数区分开来。
The multi-channel header consists of a magic number followed by a 32-bit channel description field, giving the multi-channel header the following structure:
多通道标头由一个幻数和一个32位通道描述字段组成，使多通道标头具有以下结构：
+------------------+
| magic number |
+------------------+
| chan-desc field |
+------------------+
+------------------+
| magic number |
+------------------+
| chan-desc field |
+------------------+
The magic number for multi-channel AMR files MUST consist of the ASCII character string:
多通道AMR文件的幻数必须由ASCII字符串组成：
"#!AMR_MC1.0\n" (or 0x2321414d525F4D43312E300a in hexadecimal).
“#！AMR_MC1.0\n”（或十六进制格式的0x2321414D525F443312E300A）。
The magic number for multi-channel AMR-WB files MUST consist of the ASCII character string:
多通道AMR-WB文件的幻数必须由ASCII字符串组成：
"#!AMR-WB_MC1.0\n" (or 0x2321414d522d57425F4D43312E300a in hexadecimal).
“#！AMR-WB_MC1.0\n”（或十六进制格式的0x2321414D522D57425F4D4312E300A）。
The version number in the magic numbers refers to the version of the file format.
幻数中的版本号指的是文件格式的版本。
The 32 bit channel description field is defined as:
32位信道描述字段定义为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved bits | CHAN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved bits | CHAN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved bits: MUST be set to 0 when written, and a reader MUST ignore them.
保留位：写入时必须设置为0，读卡器必须忽略它们。
CHAN (4 bits, unsigned integer): Indicates the number of audio channels contained in this storage file. The valid values and the order of the channels within a frame-block are specified in Section 4.1 in [12].
CHAN（4位，无符号整数）：表示此存储文件中包含的音频通道数。[12]第4.1节规定了帧块内通道的有效值和顺序。
After the file header, speech frame-blocks consecutive in time are stored in the file. Each frame-block contains a number of octet-aligned speech frames equal to the number of channels, and stored in increasing order, starting with channel 1.
在文件头之后，在时间上连续的语音帧块存储在文件中。每个帧块包含与通道数量相等的八位组对齐语音帧的数量，并以递增顺序存储，从通道1开始。
Each stored speech frame starts with a one-octet frame header with the following format:
每个存储的语音帧以一个八位字节的帧头开始，格式如下：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|P| FT |Q|P|P|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|P| FT |Q|P|P|
+-+-+-+-+-+-+-+-+
The FT field and the Q bit are defined in the same way as in Section 4.3.2. The P bits are padding and MUST be set to 0, and MUST be ignored.
FT字段和Q位的定义方式与第4.3.2节相同。P位是填充位，必须设置为0，并且必须忽略。
Following this one octet header come the speech bits as defined in 4.4.3. The last octet of each frame is padded with zeroes, if needed, to achieve octet alignment.
在这一个八位字节头之后是4.4.3中定义的语音位。如果需要的话，每个帧的最后一个八位字节用零填充，以实现八位字节对齐。
The following example shows an AMR frame in 5.9 kbps coding mode (with 118 speech bits) in the storage format.
以下示例显示存储格式为5.9 kbps编码模式（118个语音位）的AMR帧。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| FT=2 |Q|P|P| |
+-+-+-+-+-+-+-+-+ +
| |
+ Speech bits for frame-block n, channel k +
| |
+ +-+-+
| |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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| FT=2 |Q|P|P| |
+-+-+-+-+-+-+-+-+ +
| |
+ Speech bits for frame-block n, channel k +
| |
+ +-+-+
| |P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Non-received speech frames or frame-blocks between SID updates during non-speech periods MUST be stored as NO_DATA frames (frame type 15, as defined in [2] and [4]). Frames or frame-blocks lost in transmission MUST be stored as NO_DATA frames or SPEECH_LOST (frame type 14, only available for AMR-WB) in complete frame-blocks to keep synchronization with the original media.
非语音期间SID更新之间的未接收语音帧或帧块必须存储为无_数据帧（帧类型15，如[2]和[4]中所定义）。传输过程中丢失的帧或帧块必须作为无数据帧或语音丢失（帧类型14，仅适用于AMR-WB）存储在完整的帧块中，以保持与原始媒体的同步。
Comfort noise frames of other types than AMR SID (FT=8) (i.e., frame type 9, 10, and 11 for AMR) SHALL NOT be used in the AMR file format.
AMR文件格式中不得使用AMR SID（FT=8）以外的其他类型的舒适噪声帧（即AMR的帧类型9、10和11）。
The general congestion control considerations for transporting RTP data apply to AMR or AMR-WB speech over RTP as well. However, the multi-rate capability of AMR and AMR-WB speech coding may provide an advantage over other payload formats for controlling congestion since the bandwidth demand can be adjusted by selecting a different coding mode.
传输RTP数据的一般拥塞控制注意事项也适用于通过RTP的AMR或AMR-WB语音。然而，AMR和AMR-WB语音编码的多速率能力可能比其他有效载荷格式在控制拥塞方面提供优势，因为可以通过选择不同的编码模式来调整带宽需求。
Another parameter that may impact the bandwidth demand for AMR and AMR-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 IP/UDP/RTP headers, at the expense of increased delay.
可能影响AMR和AMR-WB带宽需求的另一个参数是封装在每个RTP有效负载中的帧块数。在每个RTP有效负载中封装更多的帧块可以减少发送的数据包数量，从而减少IP/UDP/RTP报头的开销，但会增加延迟。
If forward error correction (FEC) is used to combat 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本身的使用不会导致拥塞问题。
It is RECOMMENDED that AMR or AMR-WB applications using this payload format employ congestion control. The actual mechanism for congestion control is not specified but should be suitable for real-time flows, possibly "TCP Friendly Rate Control" [21].
建议使用此有效负载格式的AMR或AMR-WB应用程序采用拥塞控制。未指定拥塞控制的实际机制，但应适用于实时流，可能是“TCP友好的速率控制”[21]。
RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in [8] and in any used profile, like AVP [12] or SAVP [26].
使用本规范中定义的有效负载格式的RTP数据包受[8]和任何使用的配置文件（如AVP[12]或SAVP[26]）中讨论的一般安全考虑的约束。
As this format transports encoded speech, the main security issues include confidentiality, authentication, and integrity of the speech itself. The payload format itself does not have any built-in security mechanisms. External mechanisms, such as SRTP [26], need to be used for this functionality. Note that the appropriate mechanism to provide security to RTP and the payloads following this memo may vary. It is dependent on the application, the transport, and the signaling protocol employed. Therefore, a single mechanism is not sufficient, although if suitable the usage of SRTP [26] is RECOMMENDED. Other known mechanisms that may be used are IPsec [33] and TLS [34] (RTP over TCP), but other alternatives may also exist.
由于这种格式传输编码语音，主要的安全问题包括语音本身的机密性、身份验证和完整性。有效负载格式本身没有任何内置的安全机制。此功能需要使用外部机制，如SRTP[26]。请注意，为RTP和本备忘录之后的有效载荷提供安全性的适当机制可能会有所不同。它取决于应用程序、传输和所采用的信令协议。因此，单一机制是不够的，尽管如果合适，建议使用SRTP[26]。可使用的其他已知机制为IPsec[33]和TLS[34]（TCP上的RTP），但也可能存在其他替代方案。
This payload format does not exhibit any significant non-uniformity in the receiver side computational complexity for packet processing, and thus is unlikely to pose a denial-of-service threat due to the receipt of pathological data.
这种有效载荷格式在数据包处理的接收方计算复杂度方面没有表现出任何显著的非均匀性，因此不太可能由于接收病理数据而造成拒绝服务威胁。
To achieve confidentiality of the encoded AMR or AMR-WB speech, all speech data bits will need to be encrypted. There is less of a need to encrypt the payload header or the table of contents due to a) that they only carry information about the requested speech mode, frame type, and frame quality, and b) that this information could be useful to some third party, e.g., quality monitoring.
为了实现编码的AMR或AMR-WB语音的保密性，所有语音数据位都需要加密。由于a）有效载荷报头或目录仅携带关于请求的语音模式、帧类型和帧质量的信息，以及b）该信息可能对某些第三方有用（例如，质量监控），因此不需要加密有效载荷报头或目录。
The packetization and unpacketization of the AMR and AMR-WB payload is done only at the endpoints. Therefore encryption should be performed after packet encapsulation, and decryption should be performed before packet decapsulation.
AMR和AMR-WB有效负载的打包和解包仅在端点完成。因此，加密应该在包封装之后执行，而解密应该在包解封之前执行。
Encryption may affect interleaving. Specifically, a change of keys should occur at the boundary between interleaving groups. If it is not done at that boundary on both endpoints, the speech quality will be degraded during the complete interleaving group for any receiver.
加密可能会影响交织。特别地，密钥的改变应该发生在交织组之间的边界处。如果没有在两个端点上的该边界处进行，则在任何接收器的完整交织组期间，语音质量将降低。
The encryption mechanism may impact the robustness of the error correcting mechanism. This is discussed in Section 9.5 of SRTP [26]. From this, UED/UEP based on robust sorting may be difficult to apply when the payload data is encrypted.
加密机制可能会影响纠错机制的健壮性。SRTP[26]第9.5节对此进行了讨论。由此可知，当有效载荷数据被加密时，基于鲁棒排序的UED/UEP可能难以应用。
To authenticate the sender and to protect the integrity of the RTP packets in transit, an external mechanism has to be used. As stated before, it is RECOMMENDED that SRTP [26] be used for common interoperability. Note that the use of UED/UEP may be difficult to combine with some integrity protection mechanisms because any bit errors will cause the integrity check to fail.
为了验证发送方并保护传输中RTP数据包的完整性，必须使用外部机制。如前所述，建议将SRTP[26]用于通用互操作性。请注意，UED/UEP的使用可能很难与某些完整性保护机制结合使用，因为任何位错误都会导致完整性检查失败。
Data tampering by a man-in-the-middle attacker could result in erroneous depacketization/decoding that could lower the speech quality or produce unintelligible communications. Tampering with the CMR field may result in a different speech quality than desired.
中间人攻击者篡改数据可能导致错误的解包/解码，从而降低语音质量或产生无法理解的通信。篡改CMR字段可能会导致不同于预期的语音质量。
This section defines the parameters that may be used to select optional features of the AMR and AMR-WB payload formats. The parameters are defined here as part of the media type registrations for the AMR and AMR-WB speech codecs. The registrations are done following RFC 4855 [15] and the media registration rules [14].
本节定义了可用于选择AMR和AMR-WB有效负载格式可选功能的参数。这些参数在此处定义为AMR和AMR-WB语音编解码器的媒体类型注册的一部分。按照RFC 4855[15]和媒体注册规则[14]进行注册。
A mapping of the parameters into the Session Description Protocol (SDP) [11] is also provided for those applications that use SDP. Equivalent parameters could be defined elsewhere for use with control protocols that do not use media types or SDP.
还为使用SDP的应用程序提供了参数到会话描述协议（SDP）[11]的映射。可以在其他地方定义等效参数，以便与不使用介质类型或SDP的控制协议一起使用。
Two separate media type registrations are made, one for AMR and one for AMR-WB, because they are distinct encodings that must be distinguished by their own media type.
进行了两个单独的媒体类型注册，一个用于AMR，另一个用于AMR-WB，因为它们是不同的编码，必须根据各自的媒体类型进行区分。
Data formats are specified for both real-time transport in RTP and for storage type applications such as email attachments.
为RTP中的实时传输和存储类型应用程序（如电子邮件附件）指定了数据格式。
The media type for the Adaptive Multi-Rate (AMR) codec is allocated from the IETF tree since AMR is a widely used speech codec in general VoIP and messaging applications. This media type registration covers both real-time transfer via RTP and non-real-time transfers via stored files.
自适应多速率（AMR）编解码器的媒体类型是从IETF树中分配的，因为AMR是一般VoIP和消息传递应用中广泛使用的语音编解码器。此介质类型注册包括通过RTP的实时传输和通过存储文件的非实时传输。
Note, any unspecified parameter MUST be ignored by the receiver.
注意，接收器必须忽略任何未指定的参数。
Media Type name: audio
媒体类型名称：音频
Media subtype name: AMR
媒体子类型名称：AMR
Required parameters: none
所需参数：无
Optional parameters:
可选参数：
These parameters apply to RTP transfer only.
这些参数仅适用于RTP传输。
octet-align: Permissible values are 0 and 1. If 1, octet-aligned operation SHALL be used. If 0 or if not present, bandwidth-efficient operation is employed.
八位组对齐：允许值为0和1。如果为1，则应使用八位组对齐操作。如果0或不存在，则采用带宽效率高的操作。
mode-set: Restricts the active codec mode set to a subset of all modes, for example, to be able to support transport channels such as GSM networks in gateway use cases. Possible values are a comma separated list of modes from the set: 0,...,7 (see Table 1a [2]). The SID frame type 8 and NO_DATA (frame type 15) are never included in the mode set, but can always be used. If mode-set is specified, it MUST be abided, and frames encoded with modes outside of the subset MUST NOT be sent in any RTP payload or used in codec mode requests. If not present, all codec modes are allowed for the payload type.
模式集：将活动编解码器模式集限制为所有模式的子集，例如，在网关使用情况下能够支持GSM网络等传输通道。可能的值是集合中以逗号分隔的模式列表：0、…、7（见表1a[2]）。SID帧类型8和无_数据（帧类型15）从不包括在模式集中，但始终可以使用。如果指定了模式集，则必须遵守该模式集，并且使用子集之外的模式编码的帧不得在任何RTP有效负载中发送，也不得在编解码器模式请求中使用。如果不存在，则有效负载类型允许使用所有编解码器模式。
mode-change-period: Specifies a number of frame-blocks, N (1 or 2), that is the frame-block period at which codec mode changes are allowed for the sender. The initial phase of the interval is arbitrary, but changes must be separated by a period of N frame-blocks, i.e., a value of 2 allows the sender to change mode every second frame-block. The value of N SHALL be either 1 or 2. If this parameter is not present, mode changes are allowed at any time during the session, i.e., N=1.
模式更改周期：指定帧块数N（1或2），这是允许发送方更改编解码器模式的帧块周期。间隔的初始阶段是任意的，但更改必须由N个帧块的周期分隔，即，值2允许发送方每秒钟更改一个帧块的模式。N的值应为1或2。如果此参数不存在，则允许在会话期间的任何时间更改模式，即N=1。
mode-change-capability: Specifies if the client is capable to transmit with a restricted mode change period. The parameter may take value of 1 or 2. A value of 1 indicates that the client is not capable of restricting the mode change period to 2, and that the codec mode may be changed at any point. A value of 2 indicates that the client has the capability to restrict the mode change period to 2, and thus that the client can correctly interoperate with a receiver requiring a mode-change-period=2. If this parameter is not present, the mode-change restriction capability is not supported, i.e. mode-change-capability=1. To be able to interoperate fully with gateways to circuit switched networks (for example, GSM networks), transmissions with restricted mode changes (mode-change-capability=2) are required. Thus, clients RECOMMENDED to have the capability to support transmission according to mode-change-capability=2.
模式更改能力：指定客户端是否能够在受限的模式更改周期内进行传输。该参数的值可以为1或2。值1表示客户端不能将模式更改周期限制为2，并且编解码器模式可以在任何点更改。值2表示客户端有能力将模式更改周期限制为2，因此客户端可以正确地与需要模式更改周期=2的接收器进行互操作。如果此参数不存在，则不支持模式更改限制功能，即模式更改功能=1。为了能够与电路交换网络（例如，GSM网络）的网关完全互操作，需要具有受限模式变化（模式变化能力=2）的传输。因此，建议客户能够根据模式改变能力=2支持传输。
mode-change-neighbor: Permissible values are 0 and 1. If 1, the sender SHOULD only perform mode changes to the neighboring modes in the active codec mode set.
模式更改邻居：允许值为0和1。如果为1，则发送方应仅对活动编解码器模式集中的相邻模式执行模式更改。
Neighboring modes are the ones closest in bit rate to the current mode, either the next higher or next lower rate. If 0 or if not present, change between any two modes in the active codec mode set is allowed.
相邻模式是比特率与当前模式最接近的模式，可以是下一个更高的模式，也可以是下一个更低的模式。如果0或不存在，则允许在活动编解码器模式集中的任意两种模式之间进行更改。
maxptime: The maximum amount of media which can be encapsulated in a payload packet, expressed as time in milliseconds. The time is calculated as the sum of the time that the media present in the packet represents. The time SHOULD be an integer multiple of the frame size. If this parameter is not present, the sender MAY encapsulate any number of speech frames into one RTP packet.
maxptime：可封装在有效负载数据包中的最大媒体量，以毫秒表示。时间计算为数据包中存在的媒体所代表的时间之和。时间应该是帧大小的整数倍。如果该参数不存在，发送方可以将任意数量的语音帧封装到一个RTP包中。
crc: Permissible values are 0 and 1. If 1, frame CRCs SHALL be included in the payload. If 0 or not present, CRCs SHALL NOT be used. If crc=1, this also implies automatically that octet-aligned operation SHALL be used for the session.
crc：允许值为0和1。如果为1，框架CRC应包括在有效载荷中。如果0或不存在，则不应使用CRC。如果crc=1，这也自动意味着会话应使用八位字节对齐操作。
robust-sorting: Permissible values are 0 and 1. If 1, the payload SHALL employ robust payload sorting. If 0 or if not present, simple payload sorting SHALL be used. If robust-sorting=1, this also implies automatically that octet-aligned operation SHALL be used for the session.
稳健排序：允许值为0和1。如果为1，有效载荷应采用稳健的有效载荷分类。如果为0或不存在，则应使用简单有效载荷排序。如果robust sorting=1，这也自动意味着会话应使用八位字节对齐操作。
interleaving: Indicates that frame-block level interleaving SHALL be used for the session, and its value defines the maximum number of frame-blocks allowed in an interleaving group (see Section 4.4.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.
交织：表示会话应使用帧块级交织，其值定义交织组中允许的最大帧块数（见第4.4.1节）。如果该参数不存在，则不得使用交织。此参数的存在也自动意味着应使用八位组对齐操作。
ptime: see RFC 4566 [11].
ptime：见RFC 4566[11]。
channels: The number of audio channels. The possible values (1-6) and their respective channel order is specified in Section 4.1 in [12]. If omitted, it has the default value of 1.
频道：音频频道的数量。[12]第4.1节规定了可能的值（1-6）及其各自的通道顺序。如果省略，则默认值为1。
max-red: The maximum duration in milliseconds that elapses between the primary (first) transmission of a frame and any redundant transmission that the sender will use. This parameter allows a receiver to have a bounded delay when redundancy is used. Allowed values are between 0 (no redundancy will be used) and 65535. If the parameter is omitted, no limitation on the use of redundancy is present.
最大红色：帧的主要（第一次）传输和发送方将使用的任何冗余传输之间经过的最大持续时间（毫秒）。当使用冗余时，此参数允许接收器具有有界延迟。允许的值介于0（不使用冗余）和65535之间。如果省略该参数，则对冗余的使用没有限制。
Encoding considerations: The Audio data is binary data, and must be encoded for non-binary transport; the Base64 encoding is suitable for email. When used in RTP context the data is framed as defined in [14].
编码注意事项：音频数据为二进制数据，必须进行非二进制传输编码；Base64编码适用于电子邮件。在RTP上下文中使用时，数据按照[14]中的定义进行帧化。
Security considerations: See Section 7 of RFC 4867.
安全注意事项：见RFC 4867第7节。
Public specification: RFC 4867 3GPP TS 26.090, 26.092, 26.093, 26.101
公共规范：RFC 4867 3GPP TS 26.090、26.092、26.093、26.101
Applications that use this media type: This media type is used in numerous applications needing transport or storage of encoded voice. Some examples include; Voice over IP, streaming media, voice messaging, and voice recording on digital cameras.
使用此媒体类型的应用程序：此媒体类型用于许多需要传输或存储编码语音的应用程序。一些例子包括：；IP语音、流媒体、语音信息和数码相机上的语音录制。
Additional information: The following applies to stored-file transfer methods:
其他信息：以下内容适用于存储的文件传输方法：
Magic numbers: single-channel: ASCII character string "#!AMR\n" (or 0x2321414d520a in hexadecimal) multi-channel: ASCII character string "#!AMR_MC1.0\n" (or 0x2321414d525F4D43312E300a in hexadecimal) File extensions: amr, AMR Macintosh file type code: "amr " (fourth character is space)
幻数：单通道：ASCII字符串“#！AMR\n”（或十六进制的0x2321414d520a）多通道：ASCII字符串“#！AMR\U MC1.0\n”（或十六进制的0x2321414D525F4D43132E3300A）文件扩展名：AMR，AMR Macintosh文件类型代码：“AMR”（第四个字符是空格）
AMR speech frames may also be stored in the file format "3GP" defined in 3GPP TS 26.244 [31], which is identified using the media types "audio/3GPP" or "video/3GPP" as registered by RFC 3839 [32].
AMR语音帧也可以以3GPP TS 26.244[31]中定义的文件格式“3GP”存储，该文件格式使用RFC 3839[32]注册的媒体类型“音频/3GPP”或“视频/3GPP”识别。
Person & email address to contact for further information:
Magnus Westerlund <magnus.westerlund@ericsson.com>
Ari Lakaniemi <ari.lakaniemi@nokia.com>
Person & email address to contact for further information:
Magnus Westerlund <magnus.westerlund@ericsson.com>
Ari Lakaniemi <ari.lakaniemi@nokia.com>
Intended usage: COMMON. This media type is widely used in streaming, VoIP, and messaging applications on many types of devices.
预期用途：普通。这种媒体类型广泛应用于许多类型设备上的流媒体、VoIP和消息传递应用程序中。
Restrictions on usage: When this media type is used in the context of transfer over RTP, the RTP payload format specified in Section 4 SHALL be used. In all other contexts, the file format defined in Section 5 SHALL be used.
使用限制：当在RTP传输上下文中使用此媒体类型时，应使用第4节中规定的RTP有效负载格式。在所有其他情况下，应使用第5节中定义的文件格式。
Author:
Magnus Westerlund <magnus.westerlund@ericsson.com>
Ari Lakaniemi <ari.lakaniemi@nokia.com>
Author:
Magnus Westerlund <magnus.westerlund@ericsson.com>
Ari Lakaniemi <ari.lakaniemi@nokia.com>
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
The media type for the Adaptive Multi-Rate Wideband (AMR-WB) codec is allocated from the IETF tree since AMR-WB is a widely used speech codec in general VoIP and messaging applications. This media type registration covers both real-time transfer via RTP and non-real-time transfers via stored files.
自适应多速率宽带（AMR-WB）编解码器的媒体类型是从IETF树中分配的，因为AMR-WB是一般VoIP和消息传递应用中广泛使用的语音编解码器。此介质类型注册包括通过RTP的实时传输和通过存储文件的非实时传输。
Note, any unspecified parameter MUST be ignored by the receiver.
注意，接收器必须忽略任何未指定的参数。
Media Type name: audio
媒体类型名称：音频
Media subtype name: AMR-WB
媒体子类型名称：AMR-WB
Required parameters: none
所需参数：无
Optional parameters:
可选参数：
These parameters apply to RTP transfer only.
这些参数仅适用于RTP传输。
octet-align: Permissible values are 0 and 1. If 1, octet-aligned operation SHALL be used. If 0 or if not present, bandwidth-efficient operation is employed.
八位组对齐：允许值为0和1。如果为1，则应使用八位组对齐操作。如果0或不存在，则采用带宽效率高的操作。
mode-set: Restricts the active codec mode set to a subset of all modes, for example, to be able to support transport channels such as GSM networks in gateway use cases. Possible values are a comma-separated list of modes from the set: 0,...,8 (see Table 1a [4]). The SID frame type 9, SPEECH_LOST (frame type 14), and NO_DATA (frame type 15) are never included in the mode set, but can always be used. If mode-set is specified, it MUST be abided, and frames encoded with modes outside of the subset MUST NOT be sent in any RTP payload or used in codec mode requests. If not present, all codec modes are allowed for the payload type.
模式集：将活动编解码器模式集限制为所有模式的子集，例如，在网关使用情况下能够支持GSM网络等传输通道。可能的值是集合中以逗号分隔的模式列表：0、…、8（见表1a[4]）。SID帧类型9、语音丢失（帧类型14）和无数据（帧类型15）从未包含在模式集中，但始终可以使用。如果指定了模式集，则必须遵守该模式集，并且使用子集之外的模式编码的帧不得在任何RTP有效负载中发送，也不得在编解码器模式请求中使用。如果不存在，则有效负载类型允许使用所有编解码器模式。
mode-change-period: Specifies a number of frame-blocks, N (1 or 2), that is the frame-block period at which codec mode changes are allowed for the sender. The initial phase of the interval is arbitrary, but changes must be separated by multiples of N frame-blocks, i.e., a value of 2 allows the sender to change mode every second frame-block. The value of N SHALL be either 1 or 2. If this parameter is not present, mode changes are allowed at Any time during the session, i.e., N=1.
模式更改周期：指定帧块数N（1或2），这是允许发送方更改编解码器模式的帧块周期。间隔的初始阶段是任意的，但更改必须由N个帧块的倍数分隔，即，值2允许发送方每秒钟更改一个帧块的模式。N的值应为1或2。如果此参数不存在，则允许在会话期间的任何时间更改模式，即N=1。
mode-change-capability: Specifies if the client is capable to transmit with a restricted mode change period. The parameter may take value of 1 or 2. A value of 1 indicates that the client is not capable of restricting the mode change period to 2, and that the codec mode may be changed at any point. A value of 2 indicates that the client has the capability to restrict the mode change period to 2, and thus that the client can correctly interoperate with a receiver requiring a mode-change-period=2. If this parameter is not present, the mode-change restriction capability is not supported, i.e. mode-change-capability=1. To be able to interoperate fully with gateways to circuit switched networks (for example, GSM networks), transmissions with restricted mode changes (mode-change-capability=2) are required. Thus, clients are RECOMMENDED to have the capability to support transmission according to mode-change-capability=2.
模式更改能力：指定客户端是否能够在受限的模式更改周期内进行传输。该参数的值可以为1或2。值1表示客户端不能将模式更改周期限制为2，并且编解码器模式可以在任何点更改。值2表示客户端有能力将模式更改周期限制为2，因此客户端可以正确地与需要模式更改周期=2的接收器进行互操作。如果此参数不存在，则不支持模式更改限制功能，即模式更改功能=1。为了能够与电路交换网络（例如，GSM网络）的网关完全互操作，需要具有受限模式变化（模式变化能力=2）的传输。因此，建议客户机具有根据模式改变能力=2支持传输的能力。
mode-change-neighbor: Permissible values are 0 and 1. If 1, the sender SHOULD only perform mode changes to the neighboring modes in the active codec mode set. Neighboring modes are the ones closest in bit rate to the current mode, either the next higher or next lower rate. If 0 or if not present, change between any two modes in the active codec mode set is allowed.
模式更改邻居：允许值为0和1。如果为1，则发送方应仅对活动编解码器模式集中的相邻模式执行模式更改。相邻模式是比特率与当前模式最接近的模式，可以是下一个更高的模式，也可以是下一个更低的模式。如果0或不存在，则允许在活动编解码器模式集中的任意两种模式之间进行更改。
maxptime: The maximum amount of media which can be encapsulated in a payload packet, expressed as time in milliseconds. The time is calculated as the sum of the time that the media present in the packet represents. The time SHOULD be an integer multiple of the frame size. If this parameter is not present, the sender MAY encapsulate any number of speech frames into one RTP packet.
maxptime：可封装在有效负载数据包中的最大媒体量，以毫秒表示。时间计算为数据包中存在的媒体所代表的时间之和。时间应该是帧大小的整数倍。如果该参数不存在，发送方可以将任意数量的语音帧封装到一个RTP包中。
crc: Permissible values are 0 and 1. If 1, frame CRCs SHALL be included in the payload. If 0 or not present, CRCs SHALL NOT be used. If crc=1, this also implies automatically that octet-aligned operation SHALL be used for the session.
crc：允许值为0和1。如果为1，框架CRC应包括在有效载荷中。如果0或不存在，则不应使用CRC。如果crc=1，这也自动意味着会话应使用八位字节对齐操作。
robust-sorting: Permissible values are 0 and 1. If 1, the payload SHALL employ robust payload sorting. If 0 or if not present, simple payload sorting SHALL be used. If robust-sorting=1, this also implies automatically that octet-aligned operation SHALL be used for the session.
稳健排序：允许值为0和1。如果为1，有效载荷应采用稳健的有效载荷分类。如果为0或不存在，则应使用简单有效载荷排序。如果robust sorting=1，这也自动意味着会话应使用八位字节对齐操作。
interleaving: Indicates that frame-block level interleaving SHALL be used for the session, and its value defines the maximum number of frame-blocks allowed in an interleaving group (see Section 4.4.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.
交织：表示会话应使用帧块级交织，其值定义交织组中允许的最大帧块数（见第4.4.1节）。如果该参数不存在，则不得使用交织。此参数的存在也自动意味着应使用八位组对齐操作。
ptime: see RFC 2327 [11].
ptime：见RFC 2327[11]。
channels: The number of audio channels. The possible values (1-6) and their respective channel order is specified in Section 4.1 in [12]. If omitted, it has the default value of 1.
频道：音频频道的数量。[12]第4.1节规定了可能的值（1-6）及其各自的通道顺序。如果省略，则默认值为1。
max-red: The maximum duration in milliseconds that elapses between the primary (first) transmission of a frame and any redundant transmission that the sender will use. This parameter allows a receiver to have a bounded delay when redundancy is used. Allowed values are between 0 (no redundancy will be used) and 65535. If the parameter is omitted, no limitation on the use of redundancy is present.
最大红色：帧的主要（第一次）传输和发送方将使用的任何冗余传输之间经过的最大持续时间（毫秒）。当使用冗余时，此参数允许接收器具有有界延迟。允许的值介于0（不使用冗余）和65535之间。如果省略该参数，则对冗余的使用没有限制。
Encoding considerations: The Audio data is binary data, and must be encoded for non-binary transport; the Base64 encoding is suitable for email. When used in RTP context the data is framed as defined in [14].
编码注意事项：音频数据为二进制数据，必须进行非二进制传输编码；Base64编码适用于电子邮件。在RTP上下文中使用时，数据按照[14]中的定义进行帧化。
Security considerations: See Section 7 of RFC 4867.
安全注意事项：见RFC 4867第7节。
Public specification: RFC 4867 3GPP TS 26.190, 26.192, 26.193, 26.201
公共规范：RFC 4867 3GPP TS 26.190、26.192、26.193、26.201
Applications that use this media type: This media type is used in numerous applications needing transport or storage of encoded voice. Some examples include; Voice over IP, streaming media, voice messaging, and voice recording on digital cameras.
使用此媒体类型的应用程序：此媒体类型用于许多需要传输或存储编码语音的应用程序。一些例子包括：；IP语音、流媒体、语音信息和数码相机上的语音录制。
Additional information: The following applies to stored-file transfer methods:
其他信息：以下内容适用于存储的文件传输方法：
Magic numbers: single-channel: ASCII character string "#!AMR-WB\n" (or 0x2321414d522d57420a in hexadecimal) multi-channel: ASCII character string "#!AMR-WB_MC1.0\n" (or 0x2321414d522d57425F4D43312E300a in hexadecimal) File extensions: awb, AWB Macintosh file type code: amrw Object identifier or OID: none
幻数：单通道：ASCII字符串“#！AMR-WB\n”（或十六进制格式的0x2321414d522d57420a）多通道：ASCII字符串“#！AMR-WB_MC1.0\n”（或十六进制格式的0x2321414D522D57425F4D4313212E3300A）文件扩展名：awb、awb Macintosh文件类型代码：amrw对象标识符或OID：无
AMR-WB speech frames may also be stored in the file format "3GP" defined in 3GPP TS 26.244 [31] and identified using the media type "audio/3GPP" or "video/3GPP" as registered by RFC 3839 [32].
AMR-WB语音帧也可以3GPP TS 26.244[31]中定义的文件格式“3GP”存储，并使用RFC 3839[32]注册的媒体类型“音频/3GPP”或“视频/3GPP”进行识别。
Person & email address to contact for further information:
Magnus Westerlund <magnus.westerlund@ericsson.com>
Ari Lakaniemi <ari.lakaniemi@nokia.com>
Person & email address to contact for further information:
Magnus Westerlund <magnus.westerlund@ericsson.com>
Ari Lakaniemi <ari.lakaniemi@nokia.com>
Intended usage: COMMON. This media type is widely used in streaming, VoIP, and messaging applications on many types of devices.
预期用途：普通。这种媒体类型广泛应用于许多类型设备上的流媒体、VoIP和消息传递应用程序中。
Restrictions on usage: When this media type is used in the context of transfer over RTP, the RTP payload format specified in Section 4 SHALL be used. In all other contexts, the file format defined in Section 5 SHALL be used.
使用限制：当在RTP传输上下文中使用此媒体类型时，应使用第4节中规定的RTP有效负载格式。在所有其他情况下，应使用第5节中定义的文件格式。
Author:
Magnus Westerlund <magnus.westerlund@ericsson.com>
Ari Lakaniemi <ari.lakaniemi@nokia.com>
Author:
Magnus Westerlund <magnus.westerlund@ericsson.com>
Ari Lakaniemi <ari.lakaniemi@nokia.com>
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
The information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [11], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the AMR or AMR-WB codec, the mapping is as follows:
媒体类型规范中包含的信息与会话描述协议（SDP）[11]中的字段具有特定映射，该协议通常用于描述RTP会话。当使用SDP指定使用AMR或AMR-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 8000 for AMR and 16000 for AMR-WB, and the encoding parameters (number of channels) MUST either be explicitly set to N or omitted, implying a default value of 1. The values of N that are allowed are specified in Section 4.1 in [12].
- 媒体子类型（有效负载格式名称）以SDP“a=rtpmap”作为编码名称。“a=rtpmap”中的RTP时钟频率对于AMR必须为8000，对于AMR-WB必须为16000，编码参数（通道数）必须显式设置为N或省略，这意味着默认值为1。[12]第4.1节规定了允许的N值。
- 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 media type parameter string as a semicolon-separated list of parameter=value pairs.
- 通过直接从媒体类型参数字符串中以分号分隔的参数=值对列表形式复制其余参数，将其放入SDP“a=fmtp”属性中。
The following considerations apply when using SDP Offer-Answer procedures to negotiate the use of AMR or AMR-WB payload in RTP:
当使用SDP报价-应答程序协商RTP中AMR或AMR-WB有效载荷的使用时，以下注意事项适用：
- Each combination of the RTP payload transport format configuration parameters (octet-align, crc, robust-sorting, interleaving, and channels) is unique in its bit-pattern and not compatible with any other combination. When creating an offer in an application desiring to use the more advanced features (crc, robust-sorting, interleaving, or more than one channel), the offerer is RECOMMENDED to also offer a payload type containing only the octet-aligned or bandwidth-efficient configuration with a single channel. If multiple configurations are of interest to the application, they may all be offered; however, care should be taken not to offer too many payload types. An SDP answerer MUST include, in the SDP answer for a payload type, the following parameters unmodified from the SDP offer (unless it removes the payload type): "octet-align"; "crc"; "robust-sorting"; "interleaving"; and "channels". The SDP offerer and answerer MUST generate AMR or AMR-WB packets as described by these parameters.
- RTP有效负载传输格式配置参数的每个组合（八位对齐、crc、鲁棒排序、交织和通道）在其位模式中是唯一的，并且不与任何其他组合兼容。当在希望使用更高级功能（crc、鲁棒排序、交织或多个信道）的应用程序中创建报价时，建议报价人也提供仅包含八位组对齐或带宽有效配置的有效负载类型，并使用单个信道。如果应用程序对多个配置感兴趣，则可以提供所有配置；但是，应注意不要提供太多的有效负载类型。SDP应答器必须在有效负载类型的SDP应答中包含未经SDP报价修改的以下参数（除非删除有效负载类型）：“八位字节对齐”；“crc”；“稳健排序”；“交错”；及"渠道。SDP报价人和应答人必须按照这些参数的描述生成AMR或AMR-WB数据包。
- The "mode-set" parameter can be used to restrict the set of active AMR/AMR-WB modes used in a session. This functionality is primarily intended for gateways to access networks such as GSM or 3GPP UMTS, where the access network may be capable of supporting only a subset of AMR/AMR-WB modes. The 3GPP preferred codec configurations are defined in 3GPP TS 26.103 [25], and it is RECOMMENDED that other networks also needing to restrict the mode set follow the preferred codec configurations defined in 3GPP for greatest interoperability.
- “模式集”参数可用于限制会话中使用的活动AMR/AMR-WB模式集。该功能主要用于接入诸如GSM或3GPP UMTS等网络的网关，其中接入网络可能仅能够支持AMR/AMR-WB模式的子集。3GPP首选编解码器配置在3GPP TS 26.103[25]中定义，建议也需要限制模式集的其他网络遵循3GPP中定义的首选编解码器配置，以实现最大的互操作性。
The parameter is bi-directional, i.e., the restricted set applies to media both to be received and sent by the declaring entity. If a mode set was supplied in the offer, the answerer SHALL return the mode-set unmodified or reject the payload type. However, the answerer is free to choose a mode-set in the answer only if no mode-set was supplied in the offer for a unicast two-peer session. The mode-set in the answer is binding both for offerer and answerer. Thus, an offerer supporting all modes and subsets SHOULD NOT include the mode-set parameter. For any other offerer it is RECOMMENDED to include each mode-set it can support as a separate payload type within the offer. For multicast sessions, the answerer SHALL only participate in the session if it supports the offered mode-set. Thus, it is RECOMMENDED that any offer for a multicast session include only the mode-set it will require the answerers to support, and that the mode-set be likely to be supported by all participants.
该参数是双向的，即受限集适用于声明实体接收和发送的媒体。如果报价中提供了模式集，应答者应返回未修改的模式集或拒绝有效负载类型。但是，只有在单播双对等会话的报价中未提供模式集时，应答者才可以在应答中自由选择模式集。答案中设置的模式对报价人和应答人都具有约束力。因此，支持所有模式和子集的报价人不应包括模式集参数。对于任何其他报价人，建议将其能够支持的每个模式集作为单独的有效负载类型包含在报价中。对于多播会话，应答者仅应在支持所提供模式集的情况下参与会话。因此，建议对多播会话的任何提议只包括它将要求应答者支持的模式集，并且该模式集可能会得到所有参与者的支持。
- The parameters "mode-change-period" and "mode-change-capability" are intended to be used in sessions with gateways, for example, when interoperating with GSM networks. Both parameters are declarative and are combined to allow a session participant to determine if the payload type can be supported. The mode-change-period will indicate what the offerer or answerer requires of data it receives, while the mode-change-capability indicates its transmission capabilities.
- 参数“模式更改周期”和“模式更改能力”旨在用于网关会话中，例如，当与GSM网络互操作时。这两个参数都是声明性的，它们的组合允许会话参与者确定是否可以支持负载类型。模式转换周期将指示报价人或应答人对其接收的数据的要求，而模式转换能力则指示其传输能力。
A mode-change-period=2 in the offer indicates a requirement on the answerer to send with a mode-change period of 2, i.e., support mode-change-capability=2. If the answerer requires mode-change-period=2, it SHALL only include it in the answer if the offerer either has indicated support with mode-change-capability=2 or has indicated mode-change-period=2; otherwise, the payload type SHALL be rejected. An offerer that supports mode-change-capability=2 SHALL include the parameter in all offers to ensure the greatest possible interoperability, unless it includes mode-change-period=2 in the offer. The mode-change-capability SHOULD be included in answers. It is then indicating the answerer's capability to transmit with that mode-change-period for the provided payload format configuration. The information is useful in future re-negotiation of the payload formats.
报价中的模式更改周期=2表示要求应答者发送模式更改周期为2的邮件，即支持模式更改能力=2。如果应答方要求模式转换周期=2，则只有在报价方表示支持模式转换能力=2或表示模式转换周期=2时，应答方才应将其包含在应答中；否则，应拒绝有效载荷类型。支持模式转换能力=2的报价人应在所有报价中包含该参数，以确保最大可能的互操作性，除非报价中包含模式转换周期=2。答案中应包括模式改变能力。然后，它指示应答者在所提供的有效载荷格式配置的模式改变周期内进行传输的能力。这些信息在未来有效载荷格式的重新协商中很有用。
- The parameter "mode-change-neighbor" is a recommendation to restrict the switching of codec modes to its neighbor and SHOULD be followed. It is intended to be used in gateway scenarios (for example, to GSM networks) where the support of
- 参数“mode change neighbor”（模式更改邻居）是一项建议，用于限制将编解码器模式切换到其邻居，应遵循该参数。它旨在用于网关场景（例如，到GSM网络），其中支持
this parameter and the operations it implies improves interoperability.
此参数及其包含的操作提高了互操作性。
"mode-change-neighbor" is a declarative parameter. By including the parameter, the offerer or answerer indicates that it desires to receive streams with "mode-change-neighbor" restrictions.
“模式更改邻居”是一个声明性参数。通过包含该参数，提供方或应答方表示其希望接收具有“模式改变邻居”限制的流。
- In most cases, the parameters "maxptime" and "ptime" will not affect interoperability; however, the setting of the parameters can affect the performance of the application. The SDP offer-answer handling of the "ptime" parameter is described in RFC 3264 [13]. The "maxptime" parameter MUST be handled in the same way.
- 在大多数情况下，参数“maxptime”和“ptime”不会影响互操作性；但是，参数的设置可能会影响应用程序的性能。RFC 3264[13]中描述了“ptime”参数的SDP提供-应答处理。必须以相同的方式处理“maxptime”参数。
- The parameter "max-red" is a stream property parameter. For send-only or send-recv unicast media streams, the parameter declares the limitation on redundancy that the stream sender will use. For recvonly streams, it indicates the desired value for the stream sent to the receiver. The answerer MAY change the value, but is RECOMMENDED to use the same limitation as the offer declares. In the case of multicast, the offerer MAY declare a limitation; this SHALL be answered using the same value. A media sender using this payload format is RECOMMENDED to always include the "max-red" parameter. This information is likely to simplify the media stream handling in the receiver. This is especially true if no redundancy will be used, in which case "max-red" is set to 0. As this parameter was not defined originally, some senders will not declare this parameter even if it will limit or not send redundancy at all.
- 参数“最大红色”是一个流属性参数。对于仅发送或发送recv单播媒体流，参数声明流发送方将使用的冗余限制。对于recvonly streams，它指示发送到接收器的流的所需值。回答者可以更改值，但建议使用与报价声明相同的限制。在多播的情况下，报价人可以声明限制；应使用相同的值对此进行回答。建议使用此有效负载格式的媒体发送器始终包含“max red”参数。该信息可能简化接收器中的媒体流处理。如果不使用冗余，尤其如此，在这种情况下，“最大红色”设置为0。由于最初未定义此参数，因此某些发件人不会声明此参数，即使它将限制或根本不发送冗余。
- Any unknown parameter in an offer SHALL be removed in the answer.
- 报价中的任何未知参数应在答复中删除。
In declarative usage, like SDP in RTSP [29] or SAP [30], the parameters SHALL be interpreted as follows:
在声明性用法中，如RTSP[29]或SAP[30]中的SDP，参数应解释如下：
- The payload format configuration parameters (octet-align, crc, robust-sorting, interleaving, and channels) are all declarative, and a participant MUST use the configuration(s) that is provided for the session. More than one configuration may be provided if necessary by declaring multiple RTP payload types; however, the number of types should be kept small.
- 有效负载格式配置参数（八位字节对齐、crc、鲁棒排序、交织和通道）都是声明性的，参与者必须使用为会话提供的配置。如有必要，可通过声明多个RTP有效负载类型来提供多个配置；但是，类型的数量应保持在较小的范围内。
- Any restriction of the AMR or AMR-WB encoder mode-switching and mode usage through the "mode-set", and "mode-change-period" MUST be followed by all participants of the session. The restriction indicated by "mode-change-neighbor" SHOULD be followed. Please note that such restrictions may be necessary if gateways to other transport systems like GSM participate in the session. Failure to consider such restrictions may result in failure for a peer behind such a gateway to correctly receive all or parts of the session. Also, if different restrictions are needed by different peers in the same session (unless a common subset of the restrictions exists), some peer will not be able to participate. Note that the usage of mode-change-capability is meaningless when no negotiation exists, and can thus be excluded in any declarations.
- 通过“模式设置”和“模式更改周期”对AMR或AMR-WB编码器模式切换和模式使用的任何限制必须由会话的所有参与者遵守。应遵守“模式更改邻居”指示的限制。请注意，如果其他传输系统（如GSM）的网关参与会话，则可能需要此类限制。如果不考虑这样的限制，可能会导致这样的网关后面的对等体无法正确接收会话的全部或部分。此外，如果同一会话中的不同对等方需要不同的限制（除非存在共同的限制子集），则某些对等方将无法参与。注意，当不存在协商时，模式更改功能的使用是没有意义的，因此可以在任何声明中排除。
- Any "maxptime" and "ptime" values should be selected with care to ensure that the session's participants can achieve reasonable performance.
- 应谨慎选择任何“maxptime”和“ptime”值，以确保课程参与者能够实现合理的绩效。
- The usage of "max-red" puts a global upper limit on the usage of redundancy that needs to be followed by all that understand the parameter. However, due to the late addition of this parameter, it may be ignored by some implementations.
- “最大红色”的使用为冗余的使用设定了一个全局上限，所有理解该参数的人都需要遵守该上限。但是，由于该参数添加较晚，某些实现可能会忽略它。
Some example SDP session descriptions utilizing AMR and AMR-WB encodings follow. In these examples, long a=fmtp lines are folded to meet the column width constraints of this document; the backslash ("\") at the end of a line and the carriage return that follows it should be ignored.
下面是使用AMR和AMR-WB编码的一些示例SDP会话描述。在这些示例中，长a=fmtp行被折叠以满足本文档的列宽约束；应忽略行尾的反斜杠（\）和其后的回车符。
In an example of the usage of AMR in a possible GSM gateway-to-gateway scenario, the offerer is capable of supporting three different mode-sets and needs the mode-change-period to be 2 in combination with mode-change-neighbor restrictions. The other gateway can only support two of these mode-sets and removes the payload type 97 in the answer. If the offering GSM gateway only supports a single mode-set active at the same time, it should consider doing the 1 out of N selection procedures described in Section 10.2 of [13]:
在可能的GSM网关到网关场景中使用AMR的示例中，报价人能够支持三种不同的模式集，并且需要结合模式改变邻居限制将模式改变周期设置为2。另一个网关只能支持其中两个模式集，并删除应答中的有效负载类型97。如果提供的GSM网关仅支持同时激活的单模式集，则应该考虑执行[13 ]第10.2节中描述的N个选择过程中的1个：
Offer:
报价：
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; \
mode-change-capability=2; mode-change-neighbor=1
a=rtpmap:98 AMR/8000/1
a=fmtp:98 mode-set=0,2,3,6; mode-change-period=2; \
mode-change-capability=2; mode-change-neighbor=1
a=rtpmap:99 AMR/8000/1
a=fmtp:99 mode-set=0,2,3,4; mode-change-period=2; \
mode-change-capability=2; mode-change-neighbor=1
a=maxptime:20
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; \
mode-change-capability=2; mode-change-neighbor=1
a=rtpmap:98 AMR/8000/1
a=fmtp:98 mode-set=0,2,3,6; mode-change-period=2; \
mode-change-capability=2; mode-change-neighbor=1
a=rtpmap:99 AMR/8000/1
a=fmtp:99 mode-set=0,2,3,4; mode-change-period=2; \
mode-change-capability=2; mode-change-neighbor=1
a=maxptime:20
Answer:
答复:
m=audio 49120 RTP/AVP 98 99
a=rtpmap:98 AMR/8000/1
a=fmtp:98 mode-set=0,2,3,6; mode-change-period=2; \<
mode-change-capability=2; mode-change-neighbor=1
a=rtpmap:99 AMR/8000/1
a=fmtp:99 mode-set=0,2,3,4; mode-change-period=2; \
mode-change-capability=2; mode-change-neighbor=1
a=maxptime:20
m=audio 49120 RTP/AVP 98 99
a=rtpmap:98 AMR/8000/1
a=fmtp:98 mode-set=0,2,3,6; mode-change-period=2; \<
mode-change-capability=2; mode-change-neighbor=1
a=rtpmap:99 AMR/8000/1
a=fmtp:99 mode-set=0,2,3,4; mode-change-period=2; \
mode-change-capability=2; mode-change-neighbor=1
a=maxptime:20
The following example shows the usage of AMR between a non-GSM endpoint and a GSM gateway. The non-GSM offerer requires no restrictions of the mode-change-period or mode-change-neighbor, but must signal its mode-change-capability in the offer and abide by those restrictions in the answer.
以下示例显示了在非GSM端点和GSM网关之间使用AMR。非GSM报价人不要求对模式更改周期或模式更改邻居有任何限制，但必须在报价中表明其模式更改能力，并遵守答复中的这些限制。
Offer:
报价：
m=audio 49120 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-change-capability=2
a=maxptime:20
m=audio 49120 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-change-capability=2
a=maxptime:20
Answer:
答复:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-set=0,2,4,7; mode-change-period=2; \
mode-change-capability=2; mode-change-neighbor=1
a=maxptime:20
m=audio 49120 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-set=0,2,4,7; mode-change-period=2; \
mode-change-capability=2; mode-change-neighbor=1
a=maxptime:20
Example of usage of AMR-WB in a possible VoIP scenario where UEP may be used (99) and a fallback declaration (98):
在可能使用UEP（99）和回退声明（98）的VoIP场景中使用AMR-WB的示例：
m=audio 49120 RTP/AVP 99 98
a=rtpmap:98 AMR-WB/16000
a=fmtp:98 octet-align=1; mode-change-capability=2
a=rtpmap:99 AMR-WB/16000
a=fmtp:99 octet-align=1; crc=1; mode-change-capability=2
m=audio 49120 RTP/AVP 99 98
a=rtpmap:98 AMR-WB/16000
a=fmtp:98 octet-align=1; mode-change-capability=2
a=rtpmap:99 AMR-WB/16000
a=fmtp:99 octet-align=1; crc=1; mode-change-capability=2
Example of usage of AMR-WB in a possible streaming scenario (two channel stereo):
在可能的流媒体场景（双通道立体声）中使用AMR-WB的示例：
m=audio 49120 RTP/AVP 99
a=rtpmap:99 AMR-WB/16000/2
a=fmtp:99 interleaving=30
a=maxptime:100
m=audio 49120 RTP/AVP 99
a=rtpmap:99 AMR-WB/16000/2
a=fmtp:99 interleaving=30
a=maxptime:100
Note that the payload format (encoding) names are commonly shown in upper case. MIME subtypes are commonly shown in lower case. These names are case-insensitive in both places. Similarly, parameter names are case-insensitive both in MIME types and in the default mapping to the SDP a=fmtp attribute.
请注意，有效负载格式（编码）名称通常以大写形式显示。MIME子类型通常以小写形式显示。这些名称在两个位置都不区分大小写。类似地，参数名在MIME类型和到SDP a=fmtp属性的默认映射中都不区分大小写。
Two media types (audio/AMR and audio/AMR-WB) have been updated; see Section 8.
更新了两种媒体类型（音频/AMR和音频/AMR-WB）；见第8节。
The differences between RFC 3267 and this document are as follows:
RFC 3267与本文件之间的差异如下：
- Added clarification of behavior in regards to mode change period and mode-change neighbor that is expected from an IP client; see Section 4.5.
- 添加了关于模式更改周期和模式更改邻居的行为说明，这是IP客户端所期望的；见第4.5节。
- Updated the maxptime for better clarification. The sentence that previously read: "The time SHOULD be a multiple of the frame size." now says "The time SHOULD be an integer multiple of the frame size." This should have no impact on interoperability.
- 更新了maxptime以更好地进行澄清。前面的句子是：“时间应该是帧大小的倍数。”现在说“时间应该是帧大小的整数倍。”这应该不会影响互操作性。
- Updated the definition of the mode-set parameter for clarification.
- 更新了模式集参数的定义以进行澄清。
- Restricted the values for mode-change-period to 1 or 2, which are the values used in circuit-switched AMR systems.
- 将模式切换周期的值限制为1或2，这是电路切换AMR系统中使用的值。
- Added a new media type parameter Mode-Change-Capability that defaults to 1, which is the assumed behavior of any non-updated implementation. This enables the offer-answer procedures to work.
- 添加了新的媒体类型参数模式更改功能，默认值为1，这是任何未更新实现的假定行为。这使报价-应答过程能够正常工作。
- Changed mode-change-neighbor to indicate a recommended behavior rather than a required one.
- 更改模式更改邻居以指示建议的行为，而不是要求的行为。
- Added an Offer-Answer Section, see Section 8.3.1. This will have implications on the interoperability to implementations that have guessed how to perform offer/answer negotiation of the payload parameters.
- 增加了报价回复部分，见第8.3.1节。这将对那些猜测如何执行有效负载参数的提供/应答协商的实现的互操作性产生影响。
- Clarified and aligned the unequal detection usage with the published UDP-Lite specification in Sections 3.6.1 and 4.4.2.1. This included replacing a normative statement about packet handling with an informative paragraph with a reference to UDP-Lite.
- 在第3.6.1节和第4.4.2.1节中阐明了不平等检测的使用，并与已发布的UDP Lite规范保持一致。这包括将关于数据包处理的规范性声明替换为参考UDP Lite的信息性段落。
- Clarified the bit order in the CRC calculation in Section 4.4.2.1.
- 澄清了第4.4.2.1节中CRC计算中的位顺序。
- Corrected the reference in Section 5.3 for the Q and FT fields.
- 修正了第5.3节中Q和FT字段的参考。
- Changed the padding bit definition in Sections 4.4.2 and 5.3 so that it is clear that they shall be ignored.
- 更改了第4.4.2节和第5.3节中的填充位定义，以便明确应忽略它们。
- Added a clarification that comfort noise frames with frame type 9, 10, and 11 SHALL NOT be used in the AMR file format.
- 增加了一项澄清，即框架类型为9、10和11的舒适噪音框架不得在AMR文件格式中使用。
- Clarified in Section 4.3.2 that the rules about not sending NO_DATA frames do apply for all payload format configurations with the exception of the interleaved mode.
- 在第4.3.2节中阐明，关于不发送NO_数据帧的规则适用于除交织模式外的所有有效负载格式配置。
- The reference list has been updated to now published RFCs: RFC 3448, RFC 3550, RFC 3551, RFC 3711, RFC 3828, and RFC 4566. A reference to 3GPP TS 26.101 has also been added.
- 参考列表已更新为现在发布的RFC:RFC 3448、RFC 3550、RFC 3551、RFC 3711、RFC 3828和RFC 4566。还添加了对3GPP TS 26.101的参考。
- Added notes in storage format section and media type registration that AMR and AMR-WB frames can also be stored in the 3GP file format.
- 在“存储格式”部分和“介质类型注册”中添加了说明，说明AMR和AMR-WB帧也可以3GP文件格式存储。
- Added a media type parameter "max-red" that allows the sender to declare a bounded usage of redundancy. This parameter allows a receiver to optimize its function as it will know if redundancy will be used or not. If it is used, the maximum extra delay introduced by the sender (that is needed to be considered by the receiver to fully utilize the redundancy) will be known. The addition of this parameter should have no negative effects on older implementations as they are mandated to ignore unknown
- 添加了一个媒体类型参数“max red”，该参数允许发送方声明冗余的有界使用。此参数允许接收器优化其功能，因为它将知道是否将使用冗余。如果使用它，发送方引入的最大额外延迟（接收方需要考虑以充分利用冗余）将是已知的。添加此参数应该不会对较旧的实现产生负面影响，因为它们被强制忽略未知的
parameters per RFC 3267. In addition, older implementations are required to operate as if the value of max-red is unknown and possibly infinite.
符合RFC 3267的参数。此外，旧的实现需要像max red的值未知且可能是无限的那样运行。
- Updated the media type registration to comply with the new registration rules.
- 已更新媒体类型注册，以符合新的注册规则。
- Moved section on decoding validation from Security Considerations to Implementation Considerations, where it makes more sense.
- 将关于解码验证的一节从安全考虑事项移至实现考虑事项，在这一节中，它更有意义。
- Clarified the application of encryption, integrity protection, and authentication mechanism to the payload.
- 阐明了加密、完整性保护和身份验证机制在有效负载中的应用。
The authors would like to thank Petri Koskelainen, Bernhard Wimmer, Tim Fingscheidt, Sanjay Gupta, Stephen Casner, and Colin Perkins for their significant contributions made throughout the writing and reviewing of RFC 3267 and this replacement. The authors would also like to thank Richard Ejzak, Thomas Belling, and Gorry Fairhurst for their input on this replacement of RFC 3267.
作者要感谢Petri Koskelainen、Bernhard Wimmer、Tim Fingscheidt、Sanjay Gupta、Stephen Casner和Colin Perkins在RFC 3267和本次替换的整个编写和评审过程中做出的重大贡献。作者还想感谢Richard Ejzak、Thomas Belling和Gorry Fairhurst在更换RFC 3267方面的投入。
[1] 3GPP TS 26.090, "Adaptive Multi-Rate (AMR) speech transcoding", version 4.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
[1] 3GPP TS 26.090，“自适应多速率（AMR）语音转码”，版本4.0.0（2001-03），第三代合作伙伴计划（3GPP）。
[2] 3GPP TS 26.101, "AMR Speech Codec Frame Structure", version 4.1.0 (2001-06), 3rd Generation Partnership Project (3GPP).
[2] 3GPP TS 26.101，“AMR语音编解码器帧结构”，版本4.1.0（2001-06），第三代合作伙伴项目（3GPP）。
[3] 3GPP TS 26.190 "AMR Wideband speech codec; Transcoding functions", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
[3] 3GPP TS 26.190“AMR宽带语音编解码器；转码功能”，版本5.0.0（2001-03），第三代合作伙伴项目（3GPP）。
[4] 3GPP TS 26.201 "AMR Wideband speech codec; Frame Structure", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
[4] 3GPP TS 26.201“AMR宽带语音编解码器；帧结构”，版本5.0.0（2001-03），第三代合作伙伴项目（3GPP）。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[6] 3GPP TS 26.093, "AMR Speech Codec; Source Controlled Rate operation", version 4.0.0 (2000-12), 3rd Generation Partnership Project (3GPP).
[6] 3GPP TS 26.093，“AMR语音编解码器；源代码控制速率操作”，版本4.0.0（2000-12），第三代合作伙伴项目（3GPP）。
[7] 3GPP TS 26.193 "AMR Wideband Speech Codec; Source Controlled Rate operation", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
[7] 3GPP TS 26.193“AMR宽带语音编解码器；源代码控制速率操作”，版本5.0.0（2001-03），第三代合作伙伴计划（3GPP）。
[8] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[8] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[9] 3GPP TS 26.092, "AMR Speech Codec; Comfort noise aspects", version 4.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
[9] 3GPP TS 26.092，“AMR语音编解码器；舒适噪音方面”，版本4.0.0（2001-03），第三代合作伙伴项目（3GPP）。
[10] 3GPP TS 26.192 "AMR Wideband speech codec; Comfort Noise aspects", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
[10] 3GPP TS 26.192“AMR宽带语音编解码器；舒适噪声方面”，版本5.0.0（2001-03），第三代合作伙伴项目（3GPP）。
[11] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[11] Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[12] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[12] Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[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] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[14] Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[15] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[15] Casner，S.，“RTP有效载荷格式的媒体类型注册”，RFC 4855，2007年2月。
[16] GSM 06.60, "Enhanced Full Rate (EFR) speech transcoding", version 8.0.1 (2000-11), European Telecommunications Standards Institute (ETSI).
[16] GSM 06.60，“增强全速率（EFR）语音转码”，版本8.0.1（2000-11），欧洲电信标准协会（ETSI）。
[17] ANSI/TIA/EIA-136-Rev.C, part 410 - "TDMA Cellular/PCS Radio Interface, Enhanced Full Rate Voice Codec (ACELP)". Formerly IS-641. TIA published standard, June 1 2001.
[17] ANSI/TIA/EIA-136-Rev.C，第410部分-“TDMA蜂窝/PCS无线电接口，增强全速率语音编解码器（ACELP）”。原名IS-641。TIA发布的标准，2001年6月1日。
[18] ARIB, RCR STD-27H, "Personal Digital Cellular Telecommunication System RCR Standard", Association of Radio Industries and Businesses (ARIB).
[18] ARIB，RCR STD-27H，“个人数字蜂窝通信系统RCR标准”，无线电工业和商业协会（ARIB）。
[19] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
[19] Larzon，L-A.，Degermark，M.，Pink，S.，Jonsson，L-E.，和G.Fairhurst，“轻量级用户数据报协议（UDP-Lite）”，RFC 38282004年7月。
[20] 3GPP TS 25.415 "UTRAN Iu Interface User Plane Protocols", version 4.2.0 (2001-09), 3rd Generation Partnership Project (3GPP).
[20] 3GPP TS 25.415“UTRAN Iu接口用户平面协议”，版本4.2.0（2001-09），第三代合作伙伴项目（3GPP）。
[21] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[21] Handley，M.，Floyd，S.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 3448，2003年1月。
[22] Li, A., et al., "An RTP Payload Format for Generic FEC with Uneven Level Protection", Work in Progress.
[22] Li，A.等人，“具有不均匀级别保护的通用FEC的RTP有效负载格式”，正在进行中。
[23] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
[23] Rosenberg，J.和H.Schulzrinne，“通用前向纠错的RTP有效载荷格式”，RFC 2733，1999年12月。
[24] 3GPP TS 26.102, "AMR speech codec interface to Iu and Uu", version 4.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
[24] 3GPP TS 26.102，“到Iu和Uu的AMR语音编解码器接口”，版本4.0.0（2001-03），第三代合作伙伴项目（3GPP）。
[25] 3GPP TS 26.202, "AMR Wideband speech codec; Interface to Iu and Uu", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
[25] 3GPP TS 26.202，“AMR宽带语音编解码器；与Iu和Uu的接口”，版本5.0.0（2001-03），第三代合作伙伴项目（3GPP）。
[26] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[26] Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[27] 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.
[27] 帕金斯，C.，库维拉斯，I.，霍德森，O.，哈德曼，V.，汉德利，M.，博洛特，J.，维加·加西亚，A.，和S.福斯·帕里斯，“冗余音频数据的RTP有效载荷”，RFC 21981997年9月。
[28] 3GPP TS 26.103, "Speech codec list for GSM and UMTS", version 5.5.0 (2004-09), 3rd Generation Partnership Project (3GPP).
[28] 3GPP TS 26.103，“GSM和UMTS语音编解码器列表”，版本5.5.0（2004-09），第三代合作伙伴项目（3GPP）。
[29] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[29] Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[30] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[30] Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 29742000年10月。
[31] 3GPP TS 26.244, "3GPP file format (3GP)", version 6.1.0 (2004- 09), 3rd Generation Partnership Project (3GPP).
[31] 3GPP TS 26.244，“3GPP文件格式（3GP）”，版本6.1.0（2004-09），第三代合作伙伴项目（3GPP）。
[32] Castagno, R. and D. Singer, "MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files", RFC 3839, July 2004.
[32] Castagno，R.和D.Singer，“第三代合作伙伴项目（3GPP）多媒体文件的MIME类型注册”，RFC 3839，2004年7月。
[33] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[33] Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[34] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[34] Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
ETSI documents are available from <http://www.etsi.org/>. 3GPP documents are available from <http://www.3gpp.org/>. TIA documents are available from <http://www.tiaonline.org/>.
ETSI文件可从以下网址获得：<http://www.etsi.org/>. 3GPP文档可从以下位置获得：<http://www.3gpp.org/>. TIA文件可从以下网址获得：<http://www.tiaonline.org/>.
Authors' Addresses
作者地址
Johan Sjoberg Ericsson AB SE-164 80 Stockholm, SWEDEN
约翰斯约伯格爱立信AB SE-16480瑞典斯德哥尔摩
Phone: +46 8 7190000
EMail: Johan.Sjoberg@ericsson.com
Phone: +46 8 7190000
EMail: Johan.Sjoberg@ericsson.com
Magnus Westerlund Ericsson Research Ericsson AB SE-164 80 Stockholm, SWEDEN
Magnus Westerlund Ericsson Research Ericsson AB SE-164 80瑞典斯德哥尔摩
Phone: +46 8 7190000
EMail: Magnus.Westerlund@ericsson.com
Phone: +46 8 7190000
EMail: Magnus.Westerlund@ericsson.com
Ari Lakaniemi Nokia Research Center P.O.Box 407 FIN-00045 Nokia Group, FINLAND
芬兰诺基亚集团Ari Lakaniemi诺基亚研究中心邮政信箱407 FIN-00045
Phone: +358-71-8008000
EMail: ari.lakaniemi@nokia.com
Phone: +358-71-8008000
EMail: ari.lakaniemi@nokia.com
Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, 2-B8 Arlington Heights, IL 60004, USA
谢乔平摩托罗拉公司，地址：美国伊利诺伊州阿灵顿高地2-B8号舒尔大道西1501号，邮编60004
Phone: +1-847-632-3028
EMail: Qiaobing.Xie@motorola.com
Phone: +1-847-632-3028
EMail: Qiaobing.Xie@motorola.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编辑功能的资金目前由互联网协会提供。