Network Working Group J. Sjoberg
Request for Comments: 3267 M. Westerlund
Category: Standards Track Ericsson
A. Lakaniemi
Nokia
Q. Xie
Motorola
June 2002
Network Working Group J. Sjoberg
Request for Comments: 3267 M. Westerlund
Category: Standards Track Ericsson
A. Lakaniemi
Nokia
Q. Xie
Motorola
June 2002
Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs
自适应多速率（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 Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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 MIME type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format.
本文件规定了用于自适应多速率（AMR）和自适应多速率宽带（AMR-WB）编码语音信号的实时传输协议（RTP）有效载荷格式。有效负载格式旨在与非IP网络上的现有AMR和AMR-WB传输格式进行互操作。此外，还指定了文件格式，用于在存储模式应用程序（如电子邮件）中传输AMR和AMR-WB语音数据。包括两个单独的MIME类型注册，一个用于AMR，另一个用于AMR-WB，指定RTP有效负载格式和存储格式的使用。
Table of Contents
目录
1. Introduction.................................................... 3
2. Conventions and Acronyms........................................ 3
3. Background on AMR/AMR-WB and Design Principles.................. 4
3.1. The Adaptive Multi-Rate (AMR) Speech Codec.................. 4
3.2. The Adaptive Multi-Rate Wideband (AMR-WB) Speech Codec...... 5
3.3. Multi-rate Encoding and Mode Adaptation..................... 5
3.4. Voice Activity Detection and Discontinuous Transmission..... 6
3.5. Support for Multi-Channel Session........................... 6
3.6. Unequal Bit-error Detection and Protection.................. 7
3.6.1. Applying UEP and UED in an IP Network................... 7
3.7. Robustness against Packet Loss.............................. 9
3.7.1. Use of Forward Error Correction (FEC)................... 9
3.7.2. Use of Frame Interleaving...............................11
3.8. Bandwidth Efficient or Octet-aligned Mode...................11
3.9. AMR or AMR-WB Speech over IP scenarios......................12
4. AMR and AMR-WB RTP Payload Formats..............................14
4.1. RTP Header Usage............................................14
4.2. Payload Structure...........................................16
4.3. Bandwidth-Efficient Mode....................................16
4.3.1. The Payload Header......................................16
4.3.2. The Payload Table of Contents...........................17
4.3.3. Speech Data.............................................19
4.3.4. Algorithm for Forming the Payload.......................20
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.........................30
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
5. AMR and AMR-WB Storage Format...................................34
5.1. Single Channel Header.......................................34
5.2. Multi-channel Header........................................35
5.3. Speech Frames...............................................36
6. Congestion Control..............................................37
7. Security Considerations.........................................37
7.1. Confidentiality.............................................37
1. Introduction.................................................... 3
2. Conventions and Acronyms........................................ 3
3. Background on AMR/AMR-WB and Design Principles.................. 4
3.1. The Adaptive Multi-Rate (AMR) Speech Codec.................. 4
3.2. The Adaptive Multi-Rate Wideband (AMR-WB) Speech Codec...... 5
3.3. Multi-rate Encoding and Mode Adaptation..................... 5
3.4. Voice Activity Detection and Discontinuous Transmission..... 6
3.5. Support for Multi-Channel Session........................... 6
3.6. Unequal Bit-error Detection and Protection.................. 7
3.6.1. Applying UEP and UED in an IP Network................... 7
3.7. Robustness against Packet Loss.............................. 9
3.7.1. Use of Forward Error Correction (FEC)................... 9
3.7.2. Use of Frame Interleaving...............................11
3.8. Bandwidth Efficient or Octet-aligned Mode...................11
3.9. AMR or AMR-WB Speech over IP scenarios......................12
4. AMR and AMR-WB RTP Payload Formats..............................14
4.1. RTP Header Usage............................................14
4.2. Payload Structure...........................................16
4.3. Bandwidth-Efficient Mode....................................16
4.3.1. The Payload Header......................................16
4.3.2. The Payload Table of Contents...........................17
4.3.3. Speech Data.............................................19
4.3.4. Algorithm for Forming the Payload.......................20
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.........................30
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
5. AMR and AMR-WB Storage Format...................................34
5.1. Single Channel Header.......................................34
5.2. Multi-channel Header........................................35
5.3. Speech Frames...............................................36
6. Congestion Control..............................................37
7. Security Considerations.........................................37
7.1. Confidentiality.............................................37
7.2. Authentication..............................................38
7.3. Decoding Validation.........................................38
8. Payload Format Parameters.......................................38
8.1. AMR MIME Registration.......................................39
8.2. AMR-WB MIME Registration....................................41
8.3. Mapping MIME Parameters into SDP............................44
9. IANA Considerations.............................................45
10. Acknowledgements...............................................45
11. References.....................................................45
11.1 Informative References......................................46
12. Authors' Addresses.............................................48
13. Full Copyright Statement.......................................49
7.2. Authentication..............................................38
7.3. Decoding Validation.........................................38
8. Payload Format Parameters.......................................38
8.1. AMR MIME Registration.......................................39
8.2. AMR-WB MIME Registration....................................41
8.3. Mapping MIME Parameters into SDP............................44
9. IANA Considerations.............................................45
10. Acknowledgements...............................................45
11. References.....................................................45
11.1 Informative References......................................46
12. Authors' Addresses.............................................48
13. Full Copyright Statement.......................................49
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 MIME type registrations are provided, one for AMR and one for AMR-WB.
第4节规定了有效载荷格式本身。第5节规定了相关文件格式，用于在存储模式应用程序（如电子邮件）中传输AMR和AMR-WB语音数据。在第8节中，提供了两个单独的MIME类型注册，一个用于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 RFC2119 [5].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC2119[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
3GPP-第三代合作伙伴项目AMR-自适应多速率编解码器AMR-WB-自适应多速率宽带编解码器CMR-编解码器模式请求CN-舒适噪声DTX-不连续传输
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
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个语音帧表示完全相同的时间段。
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 MIME 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编码的MIME子类型注册的形式指定。用于在会话设置时发出这些参数信号或安排参与者事先同意的方法超出了本文件的范围；但是，第8.3节为使用SDP的应用程序提供了参数到会话描述协议（SDP）[11]的映射。
The AMR codecs 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 8 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 8 AMR encoding modes, three are already separately adopted as standards of their own. Particularly, the 6.7 kbps mode is adopted as PDC-EFR [14], the 7.4 kbps mode as IS-641 codec in TDMA [13], and the 12.2 kbps mode as GSM-EFR [12].
在8种AMR编码模式中，有三种已分别作为各自的标准采用。具体而言，PDC-EFR采用6.7 kbps模式[14]，TDMA采用is-641编解码器采用7.4 kbps模式[13]，GSM-EFR采用12.2 kbps模式[12]。
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 9 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支持9种宽带语音编码模式，各自的比特率在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. E.g., 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 to enable 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 8 AMR modes for an AMR session or any combination of the 9 AMR-WB modes for an AMR-WB session.
例如，GSM无线链路在给定会话中最多只能使用四种不同模式的子集。该子集可以是AMR会话的8种AMR模式的任意组合，也可以是AMR-WB会话的9种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 MIME parameters that may be used to signal these mode adaptation controls at session setup.
第8节指定了一组MIME参数，可用于在会话设置时向这些模式自适应控制发送信号。
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
在会话设置中，必须使用带外信令来指示会话中的信道数量以及每个帧块中来自不同信道的语音帧的顺序。当使用SDP发送信号时，rtpmap中指定了通道数
attribute and the order of channels carried in each frame-block is implied by the number of channels as specified in Section 4.1 in [24].
属性和每个帧块中承载的通道顺序由[24]第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 most sensitive and bits in class C least sensitive (see Table 1 below for AMR and [4] for AMR-WB). A 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类位）中发现位错误时，才宣布帧已损坏。另一方面，在其他位（即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类位中的位错误来实现。
Today there exist some link layers that do not discard packets with 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 [15], bit error tolerant AMR and AMR-WB traffic could achieve better performance over these types of links.
今天，存在一些链路层，它们不会丢弃具有比特错误的数据包，例如SLIP和一些无线链路。随着互联网流量模式向更以多媒体为中心的模式转变，未来可能会出现更多这种性质的链路层。通过传输层对部分校验和的支持，例如UDP Lite[15]支持的校验和，比特容错AMR和AMR-WB通信可以在这些类型的链路上实现更好的性能。
There are at least two basic approaches for carrying AMR and AMR-WB traffic over bit error tolerant IP networks:
在比特容错IP网络上承载AMR和AMR-WB流量至少有两种基本方法：
1) Utilizing a partial checksum to cover headers and the most important speech bits of the payload. It is recommended that at least all class A bits are covered by the checksum.
1) 利用部分校验和覆盖有效负载的报头和最重要的语音位。建议校验和至少覆盖所有A类位。
2) Utilizing a partial checksum to only cover headers, but a frame CRC to cover the class A bits of each speech frame in the RTP payload.
2) 使用部分校验和仅覆盖报头，而使用帧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 pay 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 UMTS can be found in [20] and for AMR-WB in [21].
请注意，网络设计者仍需注意B类和C类残余误码率。虽然B类和C类比特对错误的敏感性不如A类比特，但B类和C类比特并非无关紧要，这些比特中未检测到的错误会导致语音质量下降。参考文献[20]和参考文献[21]中的AMR-WB可接受的剩余错误率示例。
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 a bit efficient, flexible and simple way, 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 frames in a payload there is the possibility that a single bit error in protected bits will cause all the frames to be discarded.
方法1是一种比特效率高、灵活且简单的方法，但有两个缺点，即a）受保护语音比特中的比特错误将导致丢弃有效负载，以及b）当在有效负载中传输多个帧时，受保护比特中的单个比特错误将导致丢弃所有帧。
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 gives an improvement in speech quality when transporting multiple frames over links subject to bit errors.
如果需要，这些缺点可以通过以帧方式CRC形式存在的一些开销来避免（方法2）。在问题a）中，CRC可以检测a类位中的位错误，并使用帧进行错误隐藏，从而在语音质量方面有一点改进。对于b），当在有效载荷中传输多个帧时，CRC消除a类位中的单个位错误将导致丢弃所有帧的可能性。避免这种情况可在通过易受比特错误影响的链路传输多个帧时提高语音质量。
The choice between the above two approaches must be made based on the available bandwidth, and desired tolerance to bit errors. Neither solution is appropriate to all cases. Section 8 defines parameters that may be used at session setup to select 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., RFC2733 [19], 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 [18] that can be applied to AMR or AMR-WB payload transport.
重复先前发送的数据的简单方案是实现FEC的一种方法。带宽效率更高的另一个可能方案是使用有效载荷外部FEC，例如RFC2733[19]，其生成包含修复数据的额外分组。为了支持使用UEP的外部FEC方案，还可以对整个有效负载进行灵敏度排序。还有一项关于此类方案的通用版本[18]的工作正在进行中，该方案可应用于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 the same mode or of 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. 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.
这种方法的使用不需要在会话设置时发送信令。换句话说，语音发送方可以选择使用该方案，而无需咨询接收方。这是因为包含冗余帧的数据包与仅包含新帧的数据包看起来没有什么不同。如果没有数据包丢失，则接收器可以接收特定时间戳的帧的多个副本或版本（以不同模式编码）。如果接收到同一语音帧的多个版本，建议语音解码器使用速率最高的模式。
This redundancy scheme provides the same functionality as the one described in RFC 2198 "RTP Payload for Redundant Audio Data" [24]. 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 5 frame times, 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有效负载”[24]中所述相同的功能。在大多数情况下，这种有效负载格式的机制比另外要求两个端点都支持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 receiver reports. A sender should not base selection of FEC on the CMR, as this parameter most probably was set based on none-IP
发送方负责根据有关信道的反馈选择适当的冗余量，例如在RTCP接收方报告中。发送方不应基于CMR选择FEC，因为此参数很可能是基于none 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).
信息，例如无线链路性能度量。发送方还负责避免因冗余而加剧的拥塞（有关更多详细信息，请参阅第6节）。
To decrease protocol overhead, the payload design allows several speech frame-blocks be encapsulated into a single RTP packet. One of the drawbacks of such an approach is that in case of packet loss this means 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 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 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也是一个优势，它允许链路提供商减少延迟和数据包丢失或降低链路资源的利用率。
Streaming service has less strict real-time requirements and therefore can use a larger number of frame-blocks per packet than conversational service. This reduces the overhead from IP, UDP, and RTP headers. However, including several frame-blocks per packet makes the transmission more vulnerable to packet loss, so interleaving may be used to reduce the effect 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 occurs when AMR or AMR-WB encoded speech will be transmitted from a non-IP system (e.g., a GSM or 3GPP network) to an IP/UDP/RTP VoIP terminal, and/or vice versa, as depicted in Figure 3.
如图3所示，当AMR或AMR-WB编码语音将从非IP系统（例如GSM或3GPP网络）传输到IP/UDP/RTP VoIP终端和/或反之亦然时，会出现另一种情况。
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/3GPP network | IP 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/3GPP network | IP 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 response to CMR by the IP terminal.
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/3GPP network | IP network | GSM/3GPP 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/3GPP network | IP network | GSM/3GPP 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, either in exact duplicates, or 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 is always made an integral number of octets long by padding with zero bits if necessary. If additional padding is required to bring the payload length to a larger multiple of octets or for some other purpose, then the P bit in the RTP 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 mode request received in the CMR field is valid until the next CMR is received, i.e., a newly received CMR value overrides the previous one. Therefore, if a terminal continuously wishes to receive frames in the same mode X, it needs to set CMR=X for all its outbound payloads, and if a terminal has no preference in which mode to receive, it SHOULD set CMR=15 in all its outbound payloads.
在收到下一个CMR之前，在CMR字段中收到的模式请求有效，即，新收到的CMR值覆盖上一个CMR值。因此，如果终端持续希望以相同的模式X接收帧，则需要为其所有出站有效载荷设置CMR＝X，并且如果终端没有在哪种模式下接收的偏好，则应在其所有出站有效载荷中设置CMR＝15。
If receiving a payload with a CMR value which is not a speech mode or NO_DATA, the CMR MUST be ignored by the receiver.
如果接收到CMR值不是语音模式或无_数据的有效载荷，则接收机必须忽略CMR。
In a multi-channel session, CMR SHOULD be interpreted by the receiver of the payload as the desired encoding mode for all the channels in the session.
在多信道会话中，有效负载的接收器应将CMR解释为会话中所有信道的期望编码模式。
An IP end-point SHOULD NOT set the CMR based on packet losses or other congestion indications, for several reasons:
IP端点不应基于数据包丢失或其他拥塞指示设置CMR，原因如下：
- 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 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 mode requests when sending speech to a multicast session but MAY use RTCP feedback information as a hint that a mode change is needed.
对于发送到多播组的数据包，必须将CMR字段设置为15。向多播会话发送语音时，语音发送器中的编码器应忽略模式请求，但可使用RTCP反馈信息作为需要更改模式的提示。
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).
编解码器模式选择可由会话参数限制为可用模式的子集。如果是这样，请求的模式必须在信号子集中（见第8节）。
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 there is no data produced by the speech encoder for that frame 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. Also, frame-blocks containing only NO_DATA frames at the end of a packet SHOULD NOT be transmitted, except in the case of interleaving. The AMR SCR/DTX is described in [6] and AMR-WB SCR/DTX in [7].
请注意，不应传输仅包含无_数据帧的数据包。此外，除了在交织的情况下，不应发送在分组末尾仅包含无_数据帧的帧块。[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 [16], 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 comparing to dropping the damaged frames. See Section 4.4.2.1 for more details.
包括帧质量指示器是为了与ITU-T I.366.2中描述的ATM有效负载格式、UMTS Iu接口[16]以及其他传输格式进行互操作。帧质量指示器能够将损坏的帧转发到语音解码器以进行错误隐藏。与丢弃受损帧相比，这可以提高语音质量。详见第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 [24]. 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条目按照[24]第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 3 consecutive frame-blocks in a session with two channels (L and R).
下面是在具有两个信道（L和R）的会话中携带3个连续帧块的分组的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 one 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, contiguously into octets beginning with the most significant bits of the fields and the octets.
带宽有效模式下的完整RTP有效负载是通过将来自有效负载报头、目录和语音帧的位按其在ToC列表中的对应ToC条目所定义的顺序连续打包成八位字节形成的，从字段的最高有效位和八位字节开始。
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 zero bits 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]按灵敏度降序排列。最后，在末尾添加两个零位作为填充，以使有效负载八位组对齐。
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 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 kpbs 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 kpbs模式（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 is 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 0s 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填充到末尾，以使有效负载八位组对齐。
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 kbit/s (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 kbit/s（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 interleave group. If the value of ILP is found greater than ILL, the payload SHOULD be discarded.
ILP（4位，无符号整数）：这是一个可选字段，仅当发出交织信号时才显示。ILP必须取一个介于0和ILL（包括0和ILL）之间的值，指示交织组中此有效负载中的帧块的交织索引。如果发现ILP的值大于ILL，则应丢弃有效负载。
ILL and ILP fields MUST be present in each packet in a session if interleaving is 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 interleave group during an interleave session. Here we assume ILL=L for the interleave group that starts at speech frame-block n. We also assume that the first payload packet of the interleave group is s and the number of speech frame-blocks carried in each payload is N. Then we will have:
以下示例说明在交织会话期间交织组中语音帧块的排列。这里，我们假设从语音帧块n开始的交织组为ILL=L。我们还假设交织组的第一个有效载荷分组是s，并且每个有效载荷中携带的语音帧块的数量是N。那么我们将有：
Payload s (the first packet of this interleave group):
ILL=L, ILP=0,
Carry frame-blocks: n, n+(L+1), n+2*(L+1), ..., n+(N-1)*(L+1)
Payload s (the first packet of this interleave 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 interleave group):
有效负载s+1（该交织组的第二个数据包）：
ILL=L, ILP=1, frame-blocks: n+1, n+1+(L+1), n+1+2*(L+1), ..., n+1+(N-1)*(L+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 interleave 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 interleave 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 interleave 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 interleave group. In other words, all payloads in an interleave group MUST have the same ILL and MUST contain the same number of speech frame-blocks.
除非每个包（N）的帧块数至少为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 MIME parameter "interleaving=I" to set the maximum number of frame-blocks allowed in an interleaving group to I.
如果接收器已通过带外方式发出使用信号，则有效载荷的发送方必须仅应用交织。由于交织将增加接收机处的缓冲要求，接收机使用MIME参数“interleaving=I”将交织组中允许的最大帧块数设置为I。
When performing interleaving the sender MUST use a proper number of frame-blocks per payload (N) and ILL so that the resulting size of an interleave group is less or equal to I, i.e., 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, i.e.,
八位字节对齐模式下的目录（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 consecutive 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 3 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 makes the interleave group 9 frame-blocks large.
以下示例显示了在交织双信道会话中三个连续分组的ToC，每个分组携带3个帧块。这里，两个信道是左（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.
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 bit 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 [15], to protect the RTP header, payload header, and table of contents bits in a payload. The frame CRC, when used, MUST be calculated only over all class A bits in the frame. Class B and C bits in the frame MUST NOT be included in the CRC calculation and SHOULD NOT be covered by the transport checksum.
为了实现UED，应该使用传输层校验和，例如UDP Lite[15]中定义的校验和，以保护有效负载中的RTP头、有效负载头和内容表位。使用帧CRC时，必须仅对帧中的所有A类位进行计算。帧中的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类位的定义必须用于此有效负载格式。
Packets SHOULD be discarded if the transport layer checksum detects errors.
如果传输层校验和检测到错误，则应丢弃数据包。
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 CRC's takes 8 bits
每个CRC都采用8位
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| c0| c1| c2| c3| c4| c5| c6| c7|
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| c0| c1| c2| c3| c4| c5| c6| c7|
+---+---+---+---+---+---+---+---+
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 has the following form: 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 bit of the CRC register and the bit. The CRC register is then right shifted one step (inputting a "0" as the leftmost bit). If the result of the XOR operation mentioned above is a "1" "10111000" is then 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) have been used in this CRC calculation, the contents in CRC register should simply be copied to the corresponding field in the list of CRC's.
CRC的实际计算如下：首先，将8位CRC寄存器重置为零：00000000。对于计算CRC的每一位，在CRC寄存器最右边的位和该位之间进行异或运算。然后将CRC寄存器右移一步（输入“0”作为最左边的位）。如果上述异或运算的结果是“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 zeroes at the end if not all bits in the octet are used. In other words, each speech frame MUST be octet-aligned.
- 如果没有使用八位字节中的所有位，则每个语音帧的最后一个八位字节必须在末尾用零填充。换句话说，每个语音帧必须是八位组对齐的。
- When multiple speech frames are present in the speech data (i.e., compound payload), the speech frames can be arranged either one whole frame after another as usual, or with the octets of all frames interleaved together at the octet level. 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 [15]) or UEP (such as the ULP [18]) mechanisms to the payload data. The details of assembling the payload are given in the next section.
- 当语音数据（即，复合有效载荷）中存在多个语音帧时，语音帧可以像往常一样一整帧接一整帧地排列，或者所有帧的八位字节在八位字节级别交织在一起。由于每个帧内的位首先以对错误最敏感的位排序，所以交叉排列八位字节会从所有帧收集这些敏感位，使其更接近数据包的开头。这称为“鲁棒排序顺序”，允许对有效负载数据应用UED（如UDP Lite[15]）或UEP（如ULP[18]）机制。下一节将给出组装有效负载的详细信息。
The use of robust sorting order for a session MUST be agreed via out-of-band means. Section 8 specifies a MIME parameter for this purpose.
必须通过带外方式同意对会话使用可靠的排序顺序。第8节为此指定了一个MIME参数。
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 sessions.
注意，如第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 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 that frame 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 to communicate to other layers performing UED/UEP the number of octets to be covered 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 session 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 above example the last octet in both speech frames is padded with one 0 to make it octet-aligned.
注意，在上面的示例中，两个语音帧中的最后一个八位字节都用一个0填充，以使其八位字节对齐。
This example shows an octet aligned payload from a two channel session. Two frame-blocks, each containing 2 speech frames of 7.95 kbps coding mode (FT=5), are carried in this payload,
此示例显示来自双通道会话的八位字节对齐有效负载。在该有效载荷中携带两个帧块，每个帧块包含2个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 and frame-block interleaving are both enabled for the session. The interleaving length is 2 (ILL=1) and this payload is the first one in an interleave 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
有效载荷中的前两个帧是帧块#1的L和R信道语音帧，包括比特f1L（0..158）和
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.
分别为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 above example the last octet in all the 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 MIME 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和MIME参数。此要求确保实现始终可以决定是否能够进行通信。
No operation 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 mode for single channel. The other operations mode: interleaving, robust sorting, frame-wise CRC in both single and multi-channel is OPTIONAL to implement.
有效负载格式的操作模式不强制实施。应该使用使用有效负载格式的应用程序的需求来确定要实现什么。为了实现基本的互操作性，一个实现至少应该为单通道实现带宽效率和八位字节对齐模式。其他操作模式：交替、鲁棒排序、单通道和多通道中的逐帧CRC是可选的。
The storage format is used for storing AMR or AMR-WB speech frames in a file or as an e-mail 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.
注意，为了保持与已部署的实现的互操作性，单通道内容使用不同于多通道内容的文件头格式。
A single channel AMR or AMR-WB file header contains only a magic number and 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 bit 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 [24].
CHAN（4位无符号整数）：表示此存储文件中包含的音频通道数。[24]第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.1.2. The P bits are padding and MUST be set to 0.
FT字段和Q位的定义方式与第4.1.2节相同。P位是填充位，必须设置为0。
Following this one octet header come the speech bits as defined in 4.3.3. The last octet of each frame is padded with zeroes, if needed, to achieve octet alignment.
在这一个八位字节头之后是4.3.3中定义的语音位。如果需要的话，每个帧的最后一个八位字节用零填充，以实现八位字节对齐。
The following example shows an AMR frame in 5.9 kbit coding mode (with 118 speech bits) in the storage format.
以下示例显示存储格式为5.9 kbit编码模式（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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame-blocks or speech frames lost in transmission and non-received 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]) 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）存储在完整的帧块中，以保持与原始媒体的同步。
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, e.g., "Equation-Based Congestion Control for Unicast Applications" [17].
建议使用此有效负载格式的AMR或AMR-WB应用程序采用拥塞控制。未规定拥塞控制的实际机制，但应适用于实时流，例如，“单播应用的基于等式的拥塞控制”[17]。
RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in [8].
使用本规范中定义的有效负载格式的RTP数据包应遵守[8]中讨论的一般安全注意事项。
As this format transports encoded speech, the main security issues include confidentiality and authentication of the speech itself. The payload format itself does not have any built-in security mechanisms. External mechanisms, such as SRTP [22], MAY be used.
由于这种格式传输编码语音，主要的安全问题包括语音本身的保密性和身份验证。有效负载格式本身没有任何内置的安全机制。可以使用外部机制，例如SRTP[22]。
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 a need to encrypt the payload header or the table of contents due to 1) that they only carry information about the requested speech mode, frame type, and frame quality, and 2) that this information could be useful to some third party, e.g., quality monitoring.
为了实现编码的AMR或AMR-WB语音的保密性，所有语音数据位都需要加密。由于1）有效载荷报头或目录仅携带关于请求的语音模式、帧类型和帧质量的信息，以及2）该信息可能对某些第三方有用，例如质量监控，因此不需要对有效载荷报头或目录进行加密。
As long as the AMR or AMR-WB payload is only packed and unpacked at either end, encryption may be performed after packet encapsulation so that there is no conflict between the two operations.
只要AMR或AMR-WB有效负载仅在任意一端打包和解包，就可以在包封装之后执行加密，以便两个操作之间没有冲突。
Interleaving may affect encryption. Depending on the encryption scheme used, there may be restrictions on, for example, the time when keys can be changed. Specifically, the key change may need to occur at the boundary between interleave groups.
交错可能会影响加密。根据所使用的加密方案，可能会有一些限制，例如，更改密钥的时间。具体地说，密钥改变可能需要发生在交织组之间的边界处。
The type of encryption method used may impact the error robustness of the payload data. The error robustness may be severely reduced when the data is encrypted unless an encryption method without error-propagation is used, e.g., a stream cipher. Therefore, UED/UEP based on robust sorting may be difficult to apply when the payload data is encrypted.
使用的加密方法类型可能会影响有效负载数据的错误鲁棒性。当对数据进行加密时，错误鲁棒性可能会严重降低，除非使用没有错误传播的加密方法，例如流密码。因此，当有效载荷数据被加密时，基于鲁棒排序的UED/UEP可能难以应用。
To authenticate the sender of the speech, an external mechanism has to be used. It is RECOMMENDED that such a mechanism protect all the speech data bits. Note that the use of UED/UEP may be difficult to combine with authentication because any bit errors will cause authentication to fail.
要对语音发送者进行身份验证，必须使用外部机制。建议这种机制保护所有语音数据位。请注意，UED/UEP的使用可能很难与身份验证结合使用，因为任何位错误都会导致身份验证失败。
Data tampering by a man-in-the-middle attacker could result in erroneous depacketization/decoding that could lower the speech quality. Tampering with the CMR field may result in speech in a different quality than desired.
中间人攻击者篡改数据可能导致错误的解包/解码，从而降低语音质量。篡改CMR字段可能会导致语音质量与预期不同。
To prevent a man-in-the-middle attacker from tampering with the payload packets, some additional information besides the speech bits SHOULD be protected. This may include the payload header, ToC, frame CRCs, RTP timestamp, RTP sequence number, and the RTP marker bit.
为了防止中间人攻击者篡改有效负载数据包，应保护语音位之外的一些附加信息。这可以包括有效载荷报头、ToC、帧crc、RTP时间戳、RTP序列号和RTP标记位。
When processing a received payload packet, if the receiver finds that the calculated payload length, based on the information of the session and the values found in the payload header fields, does not match the size of the received packet, the receiver SHOULD discard the packet. This is because decoding a packet that has errors in its length field could severely degrade the speech quality.
当处理接收到的有效载荷分组时，如果接收机发现基于会话信息和有效载荷报头字段中的值计算出的有效载荷长度与接收到的分组的大小不匹配，则接收机应丢弃该分组。这是因为对长度字段中有错误的数据包进行解码可能会严重降低语音质量。
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 MIME subtype registrations
本节定义了可用于选择AMR和AMR-WB有效负载格式可选功能的参数。此处将参数定义为MIME子类型注册的一部分
for the AMR and AMR-WB speech codecs. 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 MIME or SDP.
用于AMR和AMR-WB语音编解码器。还为使用SDP的应用程序提供了参数到会话描述协议（SDP）[11]的映射。可以在其他地方定义等效参数，以便与不使用MIME或SDP的控制协议一起使用。
Two separate MIME registrations are made, one for AMR and one for AMR-WB, because they are distinct encodings that must be distinguished by the MIME subtype.
进行了两个单独的MIME注册，一个用于AMR，另一个用于AMR-WB，因为它们是不同的编码，必须通过MIME子类型来区分。
The data format and parameters are specified for both real-time transport in RTP and for storage type applications such as e-mail attachments.
为RTP中的实时传输和存储类型应用程序（如电子邮件附件）指定数据格式和参数。
The MIME subtype for the Adaptive Multi-Rate (AMR) codec is allocated from the IETF tree since AMR is expected to be a widely used speech codec in general VoIP applications. This MIME registration covers both real-time transfer via RTP and non-real-time transfers via stored files.
自适应多速率（AMR）编解码器的MIME子类型是从IETF树中分配的，因为AMR有望成为一般VoIP应用中广泛使用的语音编解码器。MIME注册包括通过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: Requested AMR mode set. Restricts the active codec mode set to a subset of all modes. Possible values are a comma separated list of modes from the set: 0,...,7 (see Table 1a [2]). If such mode set is specified by the decoder, the encoder MUST abide by the request and MUST NOT use modes outside of the subset. If not present, all codec modes are allowed for the session.
模式集：请求的AMR模式集。将活动编解码器模式集限制为所有模式的子集。可能的值是集合中以逗号分隔的模式列表：0、…、7（见表1a[2]）。如果解码器指定了此类模式集，编码器必须遵守请求，并且不得使用子集之外的模式。如果不存在，则会话允许使用所有编解码器模式。
mode-change-period: Specifies a number of frame-blocks, N, that is the interval at which codec mode changes are allowed. The initial phase of the interval is arbitrary, but
模式更改周期：指定帧块数N，即允许更改编解码器模式的间隔。间隔的初始阶段是任意的，但是
changes must be separated by multiples of N frame-blocks. If this parameter is not present, mode changes are allowed at any time during the session.
更改必须以N个帧块的倍数分隔。如果此参数不存在，则允许在会话期间随时更改模式。
mode-change-neighbor: Permissible values are 0 and 1. If 1, mode changes SHALL only be made 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 the media present in the packet represents. The time SHOULD be a 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, otherwise not. If crc=1, this also implies automatically that octet-aligned operation SHALL be used for the session.
crc：允许值为0和1。如果为1，框架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 RFC2327 [11].
ptime：见RFC2327[11]。
channels: The number of audio channels. The possible values and their respective channel order is specified in section 4.1 in [24]. If omitted it has the default value of 1.
频道：音频频道的数量。[24]第4.1节规定了可能的值及其各自的通道顺序。如果省略，则默认值为1。
Encoding considerations: This type is defined for transfer via both RTP (RFC 1889) and stored-file methods as described in Sections 4 and 5,
编码注意事项：此类型定义为通过RTP（RFC 1889）和存储文件方法进行传输，如第4节和第5节所述，
respectively, of RFC 3267. Audio data is binary data, and must be encoded for non-binary transport; the Base64 encoding is suitable for Email.
分别为RFC3267。音频数据是二进制数据，必须进行编码以进行非二进制传输；Base64编码适用于电子邮件。
Security considerations: See Section 7 of RFC 3267.
安全注意事项：见RFC 3267第7节。
Public specification: Please refer to Section 11 of RFC 3267.
公共规范：请参考RFC 3267第11节。
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)
幻数：单通道：ASCII字符串“#！AMR\n”（或十六进制的0x2321414d520a）多通道：ASCII字符串“#！AMR\U MC1.0\n”（或十六进制的0x2321414D525F4D4312E3300A）
File extensions: amr, AMR Macintosh file type code: none Object identifier or OID: none
文件扩展名：amr、amr Macintosh文件类型代码：无对象标识符或OID:无
Person & email address to contact for further information: johan.sjoberg@ericsson.com ari.lakaniemi@nokia.com
联系人和电子邮件地址，以获取更多信息：johan。sjoberg@ericsson.com阿里。lakaniemi@nokia.com
Intended usage: COMMON. It is expected that many VoIP applications (as well as mobile applications) will use this type.
预期用途：普通。预计许多VoIP应用程序（以及移动应用程序）将使用这种类型。
Author/Change controller: johan.sjoberg@ericsson.com ari.lakaniemi@nokia.com IETF Audio/Video transport working group
作者/变更负责人：johan。sjoberg@ericsson.com阿里。lakaniemi@nokia.comIETF音频/视频传输工作组
The MIME subtype for the Adaptive Multi-Rate Wideband (AMR-WB) codec is allocated from the IETF tree since AMR-WB is expected to be a widely used speech codec in general VoIP applications. This MIME registration covers both real-time transfer via RTP and non-real-time transfers via stored files.
自适应多速率宽带（AMR-WB）编解码器的MIME子类型是从IETF树中分配的，因为AMR-WB有望成为一般VoIP应用中广泛使用的语音编解码器。MIME注册包括通过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: Requested AMR-WB mode set. Restricts the active codec mode set to a subset of all modes. Possible values are a comma separated list of modes from the set: 0,...,8 (see Table 1a [4]). If such mode set is specified by the decoder, the encoder MUST abide by the request and MUST NOT use modes outside of the subset. If not present, all codec modes are allowed for the session.
模式集：请求的AMR-WB模式集。将活动编解码器模式集限制为所有模式的子集。可能的值是集合中以逗号分隔的模式列表：0、…、8（见表1a[4]）。如果解码器指定了此类模式集，编码器必须遵守请求，并且不得使用子集之外的模式。如果不存在，则会话允许使用所有编解码器模式。
mode-change-period: Specifies a number of frame-blocks, N, that is the interval at which codec mode changes are allowed. The initial phase of the interval is arbitrary, but changes must be separated by multiples of N frame-blocks. If this parameter is not present, mode changes are allowed at any time during the session.
模式更改周期：指定帧块数N，即允许更改编解码器模式的间隔。间隔的初始阶段是任意的，但更改必须以N个帧块的倍数分隔。如果此参数不存在，则允许在会话期间随时更改模式。
mode-change-neighbor: Permissible values are 0 and 1. If 1, mode changes SHALL only be made 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 the media present in the packet represents. The time SHOULD be a 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, otherwise not. If crc=1, this also implies automatically that octet-aligned operation SHALL be used for the session.
crc：允许值为0和1。如果为1，框架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 RFC2327 [11].
ptime：见RFC2327[11]。
channels: The number of audio channels. The possible values and their respective channel order is specified in section 4.1 in [24]. If omitted it has the default value of 1.
频道：音频频道的数量。[24]第4.1节规定了可能的值及其各自的通道顺序。如果省略，则默认值为1。
Encoding considerations: This type is defined for transfer via both RTP (RFC 1889) and stored-file methods as described in Sections 4 and 5, respectively, of RFC 3267. Audio data is binary data, and must be encoded for non-binary transport; the Base64 encoding is suitable for Email.
编码注意事项：此类型定义为通过RTP（RFC 1889）和存储文件方法进行传输，分别如RFC 3267第4节和第5节所述。音频数据是二进制数据，必须进行编码以进行非二进制传输；Base64编码适用于电子邮件。
Security considerations: See Section 7 of RFC 3267.
安全注意事项：见RFC 3267第7节。
Public specification: Please refer to Section 11 of RFC 3267.
公共规范：请参考RFC 3267第11节。
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)
幻数：单通道：ASCII字符串“#！AMR-WB\n”（或十六进制格式的0x2321414d522d57420a）多通道：ASCII字符串“#！AMR-WB_MC1.0\n”（或十六进制格式的0x2321414D522D57425F443312E3300A）
File extensions: awb, AWB Macintosh file type code: none Object identifier or OID: none
文件扩展名：awb，awb Macintosh文件类型代码：无对象标识符或OID:无
Person & email address to contact for further information: johan.sjoberg@ericsson.com ari.lakaniemi@nokia.com
联系人和电子邮件地址，以获取更多信息：johan。sjoberg@ericsson.com阿里。lakaniemi@nokia.com
Intended usage: COMMON. It is expected that many VoIP applications (as well as mobile applications) will use this type.
预期用途：普通。预计许多VoIP应用程序（以及移动应用程序）将使用这种类型。
Author/Change controller: johan.sjoberg@ericsson.com ari.lakaniemi@nokia.com IETF Audio/Video transport working group
作者/变更负责人：johan。sjoberg@ericsson.com阿里。lakaniemi@nokia.comIETF音频/视频传输工作组
The information carried in the MIME 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:
MIME媒体类型规范中包含的信息具有到会话描述协议（SDP）[11]中字段的特定映射，该协议通常用于描述RTP会话。当使用SDP指定使用AMR或AMR-WB编解码器的会话时，映射如下所示：
- The MIME type ("audio") goes in SDP "m=" as the media name.
- MIME类型（“音频”）以SDP“m=”作为媒体名称。
- The MIME 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 is specified in Section 4.1 in [24].
- MIME子类型（有效负载格式名称）以SDP“a=rtpmap”作为编码名称。“a=rtpmap”中的RTP时钟频率对于AMR必须为8000，对于AMR-WB必须为16000，编码参数（通道数）必须显式设置为N或省略，这意味着默认值为1。[24]第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 MIME media type string as a semicolon separated list of parameter=value pairs.
- 通过直接从MIME媒体类型字符串中以分号分隔的参数=值对列表形式复制其余参数，将其放入SDP“a=fmtp”属性中。
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行被折叠以满足本文档的列宽约束；应忽略行尾的反斜杠（\）和其后的回车符。
Example of usage of AMR in a possible GSM gateway scenario:
在可能的GSM网关方案中使用AMR的示例：
m=audio 49120 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=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,5,7; mode-change-period=2; \
mode-change-neighbor=1
a=maxptime:20
Example of usage of AMR-WB in a possible VoIP scenario:
在可能的VoIP场景中使用AMR-WB的示例：
m=audio 49120 RTP/AVP 98
a=rtpmap:98 AMR-WB/16000
a=fmtp:98 octet-align=1
m=audio 49120 RTP/AVP 98
a=rtpmap:98 AMR-WB/16000
a=fmtp:98 octet-align=1
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 new MIME subtypes have been registered, see Section 8. A new SDP attribute "maxptime", defined in Section 8, has also been registered. The "maxptime" attribute is expected to be defined in the revision of RFC 2327 [11] and is added here with a consistent definition.
已注册了两个新的MIME子类型，请参见第8节。第8节中定义的新SDP属性“maxptime”也已注册。“maxptime”属性预计将在RFC 2327[11]的修订版中定义，并在此处添加一致的定义。
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 this document.
作者要感谢Petri Koskelainen、Bernhard Wimmer、Tim Fingscheidt、Sanjay Gupta、Stephen Casner和Colin Perkins在本文件编写和审查过程中做出的重大贡献。
[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", RFC 1889, January 1996.
[8] Schulzrinne，H，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[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. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[11] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[24] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control" RFC 1890, January 1996.
[24] Schulzrinne，H.，“具有最小控制的音频和视频会议的RTP配置文件”，RFC 1890，1996年1月。
[12] GSM 06.60, "Enhanced Full Rate (EFR) speech transcoding", version 8.0.1 (2000-11), European Telecommunications Standards Institute (ETSI).
[12] GSM 06.60，“增强全速率（EFR）语音转码”，版本8.0.1（2000-11），欧洲电信标准协会（ETSI）。
[13] 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.
[13] ANSI/TIA/EIA-136-Rev.C，第410部分-“TDMA蜂窝/PCS-无线电接口，增强全速率语音编解码器（ACELP）”，原名IS-641。TIA发布的标准，2001年6月1日。
[14] ARIB, RCR STD-27H, "Personal Digital Cellular Telecommunication System RCR Standard", Association of Radio Industries and Businesses (ARIB).
[14] ARIB，RCR STD-27H，“个人数字蜂窝通信系统RCR标准”，无线电工业和商业协会（ARIB）。
[15] Larzon, L., Degermark, M. and S. Pink, "The UDP Lite Protocol", Work in Progress.
[15] Larzon，L.，Degermark，M.和S.Pink，“UDP Lite协议”，工作正在进行中。
[16] 3GPP TS 25.415 "UTRAN Iu Interface User Plane Protocols", version 4.2.0 (2001-09), 3rd Generation Partnership Project (3GPP).
[16] 3GPP TS 25.415“UTRAN Iu接口用户平面协议”，版本4.2.0（2001-09），第三代合作伙伴项目（3GPP）。
[17] S. Floyd, M. Handley, J. Padhye, J. Widmer, "Equation-Based Congestion Control for Unicast Applications", ACM SIGCOMM 2000, Stockholm, Sweden .
[17] S.Floyd，M.Handley，J.Padhye，J.Widmer，“单播应用中基于方程的拥塞控制”，ACM SIGCOMM 2000，斯德哥尔摩，瑞典。
[18] Li, A., et. al., "An RTP Payload Format for Generic FEC with Uneven Level Protection", Work in Progress.
[18] Li，A.等人，“具有不均匀级别保护的通用FEC的RTP有效负载格式”，正在进行中。
[19] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
[19] Rosenberg，J.和H.Schulzrinne，“通用前向纠错的RTP有效载荷格式”，RFC 2733，1999年12月。
[20] 3GPP TS 26.102, "AMR speech codec interface to Iu and Uu", version 4.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
[20] 3GPP TS 26.102，“到Iu和Uu的AMR语音编解码器接口”，版本4.0.0（2001-03），第三代合作伙伴项目（3GPP）。
[21] 3GPP TS 26.202 "AMR Wideband speech codec; Interface to Iu and Uu", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
[21] 3GPP TS 26.202“AMR宽带语音编解码器；与Iu和Uu的接口”，版本5.0.0（2001-03），第三代合作伙伴项目（3GPP）。
[22] Baugher, et. al., "The Secure Real Time Transport Protocol", Work in Progress.
[22] Baugher等人，“安全实时传输协议”，正在进行中。
[23] 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.
[23] 帕金斯，C.，库维拉斯，I.，霍德森，O.，哈德曼，V.，汉德利，M.，博洛特，J.，维加·加西亚，A.和S.福斯·帕里斯，“冗余音频数据的RTP有效载荷”，RFC 21981997年9月。
ETSI documents can be downloaded from the ETSI web server, "http://www.etsi.org/". Any 3GPP document can be downloaded from the 3GPP webserver, "http://www.3gpp.org/", see specifications. TIA documents can be obtained from "www.tiaonline.org".
ETSI文件可从ETSI web服务器下载，”http://www.etsi.org/". 任何3GPP文档都可以从3GPP Web服务器下载，“http://www.3gpp.org/“，请参阅规格。TIA文件可从“www.tiaonline.org”获取。
Johan Sjoberg Ericsson Research Ericsson AB SE-164 80 Stockholm, SWEDEN
约翰·索伯格·爱立信研究公司爱立信AB SE-16480瑞典斯德哥尔摩
Phone: +46 8 50878230
EMail: Johan.Sjoberg@ericsson.com
Phone: +46 8 50878230
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 4048287
EMail: Magnus.Westerlund@ericsson.com
Phone: +46 8 4048287
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: qxie1@email.mot.com
Phone: +1-847-632-3028
EMail: qxie1@email.mot.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。