Network Working Group H. Schulzrinne
Request for Comments: 3551 Columbia University
Obsoletes: 1890 S. Casner
Category: Standards Track Packet Design
July 2003
Network Working Group H. Schulzrinne
Request for Comments: 3551 Columbia University
Obsoletes: 1890 S. Casner
Category: Standards Track Packet Design
July 2003
RTP Profile for Audio and Video Conferences with Minimal Control
用于音频和视频会议的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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings.
本文档描述了一个名为“RTP/AVP”的配置文件，用于在音频和视频多方会议中使用实时传输协议（RTP），版本2，以及相关的控制协议RTCP，具有最小的控制。它提供了RTP规范中适用于音频和视频会议的通用字段的解释。特别是，本文档定义了一组从有效负载类型号到编码的默认映射。
This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications.
本文档还描述了如何在RTP中传输音频和视频数据。它定义了一组标准编码及其在RTP中使用时的名称。这些描述提供了参考实现和详细标准的指针。本文档旨在为音频、视频和其他实时多媒体应用的实施者提供帮助。
This memorandum obsoletes RFC 1890. It is mostly backwards-compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published.
本备忘录废除了RFC 1890。除了由于找不到两个可互操作的实现而删除的函数外，它基本上是向后兼容的。RFC 1890的新增内容编纂了本概要下有效载荷格式使用的现有实践，并包括自RFC 1890发布以来定义的新有效载荷格式。
Table of Contents
目录
1. Introduction ................................................. 3
1.1 Terminology ............................................. 3
2. RTP and RTCP Packet Forms and Protocol Behavior .............. 4
3. Registering Additional Encodings ............................. 6
4. Audio ........................................................ 8
4.1 Encoding-Independent Rules .............................. 8
4.2 Operating Recommendations ............................... 9
4.3 Guidelines for Sample-Based Audio Encodings ............. 10
4.4 Guidelines for Frame-Based Audio Encodings .............. 11
4.5 Audio Encodings ......................................... 12
4.5.1 DVI4 ............................................ 13
4.5.2 G722 ............................................ 14
4.5.3 G723 ............................................ 14
4.5.4 G726-40, G726-32, G726-24, and G726-16 .......... 18
4.5.5 G728 ............................................ 19
4.5.6 G729 ............................................ 20
4.5.7 G729D and G729E ................................. 22
4.5.8 GSM ............................................. 24
4.5.9 GSM-EFR ......................................... 27
4.5.10 L8 .............................................. 27
4.5.11 L16 ............................................. 27
4.5.12 LPC ............................................. 27
4.5.13 MPA ............................................. 28
4.5.14 PCMA and PCMU ................................... 28
4.5.15 QCELP ........................................... 28
4.5.16 RED ............................................. 29
4.5.17 VDVI ............................................ 29
5. Video ........................................................ 30
5.1 CelB .................................................... 30
5.2 JPEG .................................................... 30
5.3 H261 .................................................... 30
5.4 H263 .................................................... 31
5.5 H263-1998 ............................................... 31
5.6 MPV ..................................................... 31
5.7 MP2T .................................................... 31
5.8 nv ...................................................... 32
6. Payload Type Definitions ..................................... 32
7. RTP over TCP and Similar Byte Stream Protocols ............... 34
8. Port Assignment .............................................. 34
9. Changes from RFC 1890 ........................................ 35
10. Security Considerations ...................................... 38
11. IANA Considerations .......................................... 39
12. References ................................................... 39
12.1 Normative References .................................... 39
12.2 Informative References .................................. 39
13. Current Locations of Related Resources ....................... 41
1. Introduction ................................................. 3
1.1 Terminology ............................................. 3
2. RTP and RTCP Packet Forms and Protocol Behavior .............. 4
3. Registering Additional Encodings ............................. 6
4. Audio ........................................................ 8
4.1 Encoding-Independent Rules .............................. 8
4.2 Operating Recommendations ............................... 9
4.3 Guidelines for Sample-Based Audio Encodings ............. 10
4.4 Guidelines for Frame-Based Audio Encodings .............. 11
4.5 Audio Encodings ......................................... 12
4.5.1 DVI4 ............................................ 13
4.5.2 G722 ............................................ 14
4.5.3 G723 ............................................ 14
4.5.4 G726-40, G726-32, G726-24, and G726-16 .......... 18
4.5.5 G728 ............................................ 19
4.5.6 G729 ............................................ 20
4.5.7 G729D and G729E ................................. 22
4.5.8 GSM ............................................. 24
4.5.9 GSM-EFR ......................................... 27
4.5.10 L8 .............................................. 27
4.5.11 L16 ............................................. 27
4.5.12 LPC ............................................. 27
4.5.13 MPA ............................................. 28
4.5.14 PCMA and PCMU ................................... 28
4.5.15 QCELP ........................................... 28
4.5.16 RED ............................................. 29
4.5.17 VDVI ............................................ 29
5. Video ........................................................ 30
5.1 CelB .................................................... 30
5.2 JPEG .................................................... 30
5.3 H261 .................................................... 30
5.4 H263 .................................................... 31
5.5 H263-1998 ............................................... 31
5.6 MPV ..................................................... 31
5.7 MP2T .................................................... 31
5.8 nv ...................................................... 32
6. Payload Type Definitions ..................................... 32
7. RTP over TCP and Similar Byte Stream Protocols ............... 34
8. Port Assignment .............................................. 34
9. Changes from RFC 1890 ........................................ 35
10. Security Considerations ...................................... 38
11. IANA Considerations .......................................... 39
12. References ................................................... 39
12.1 Normative References .................................... 39
12.2 Informative References .................................. 39
13. Current Locations of Related Resources ....................... 41
14. Acknowledgments .............................................. 42
15. Intellectual Property Rights Statement ....................... 43
16. Authors' Addresses ........................................... 43
17. Full Copyright Statement ..................................... 44
14. Acknowledgments .............................................. 42
15. Intellectual Property Rights Statement ....................... 43
16. Authors' Addresses ........................................... 43
17. Full Copyright Statement ..................................... 44
This profile defines aspects of RTP left unspecified in the RTP Version 2 protocol definition (RFC 3550) [1]. This profile is intended for the use within audio and video conferences with minimal session control. In particular, no support for the negotiation of parameters or membership control is provided. The profile is expected to be useful in sessions where no negotiation or membership control are used (e.g., using the static payload types and the membership indications provided by RTCP), but this profile may also be useful in conjunction with a higher-level control protocol.
该概要文件定义了RTP版本2协议定义（RFC 3550）[1]中未指定的RTP方面。此配置文件用于音频和视频会议中，会话控制最少。特别是，未提供对参数协商或成员资格控制的支持。在不使用协商或成员资格控制的会话中（例如，使用RTCP提供的静态有效负载类型和成员资格指示），该配置文件预计会有用，但该配置文件也可能与更高级别的控制协议结合使用。
Use of this profile may be implicit in the use of the appropriate applications; there may be no explicit indication by port number, protocol identifier or the like. Applications such as session directories may use the name for this profile specified in Section 11.
该配置文件的使用可能隐含在适当应用程序的使用中；可能没有端口号、协议标识符等的明确指示。会话目录等应用程序可以使用第11节中指定的此配置文件的名称。
Other profiles may make different choices for the items specified here.
其他配置文件可能会对此处指定的项目做出不同的选择。
This document also defines a set of encodings and payload formats for audio and video. These payload format descriptions are included here only as a matter of convenience since they are too small to warrant separate documents. Use of these payload formats is NOT REQUIRED to use this profile. Only the binding of some of the payload formats to static payload type numbers in Tables 4 and 5 is normative.
本文档还定义了音频和视频的一组编码和有效负载格式。这些有效负载格式描述仅为方便起见，因为它们太小，无法保证单独的文档。使用此配置文件不需要使用这些有效负载格式。只有表4和表5中的一些有效负载格式与静态有效负载类型编号的绑定是规范性的。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2] and indicate requirement levels for implementations compliant with this RTP profile.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中的描述进行解释，并表示符合本RTP配置文件的实施要求级别。
This document defines the term media type as dividing encodings of audio and video content into three classes: audio, video and audio/video (interleaved).
本文档将术语媒体类型定义为将音频和视频内容的编码分为三类：音频、视频和音频/视频（交错）。
The section "RTP Profiles and Payload Format Specifications" of RFC 3550 enumerates a number of items that can be specified or modified in a profile. This section addresses these items. Generally, this profile follows the default and/or recommended aspects of the RTP specification.
RFC 3550的“RTP配置文件和有效负载格式规范”一节列举了一些可以在配置文件中指定或修改的项目。本节讨论这些项目。通常，此配置文件遵循RTP规范的默认和/或建议方面。
RTP data header: The standard format of the fixed RTP data header is used (one marker bit).
RTP数据头：使用固定RTP数据头的标准格式（一个标记位）。
Payload types: Static payload types are defined in Section 6.
有效载荷类型：静态有效载荷类型在第6节中定义。
RTP data header additions: No additional fixed fields are appended to the RTP data header.
RTP数据头添加：RTP数据头没有附加固定字段。
RTP data header extensions: No RTP header extensions are defined, but applications operating under this profile MAY use such extensions. Thus, applications SHOULD NOT assume that the RTP header X bit is always zero and SHOULD be prepared to ignore the header extension. If a header extension is defined in the future, that definition MUST specify the contents of the first 16 bits in such a way that multiple different extensions can be identified.
RTP数据头扩展：未定义RTP头扩展，但在此配置文件下运行的应用程序可能会使用此类扩展。因此，应用程序不应假定RTP报头X位始终为零，而应准备忽略报头扩展。如果将来定义了头扩展，则该定义必须指定前16位的内容，以便可以识别多个不同的扩展。
RTCP packet types: No additional RTCP packet types are defined by this profile specification.
RTCP数据包类型：此配置文件规范未定义其他RTCP数据包类型。
RTCP report interval: The suggested constants are to be used for the RTCP report interval calculation. Sessions operating under this profile MAY specify a separate parameter for the RTCP traffic bandwidth rather than using the default fraction of the session bandwidth. The RTCP traffic bandwidth MAY be divided into two separate session parameters for those participants which are active data senders and those which are not. Following the recommendation in the RTP specification [1] that 1/4 of the RTCP bandwidth be dedicated to data senders, the RECOMMENDED default values for these two parameters would be 1.25% and 3.75%, respectively. For a particular session, the RTCP bandwidth for non-data-senders MAY be set to zero when operating on unidirectional links or for sessions that don't require feedback on the quality of reception. The RTCP bandwidth for data senders SHOULD be kept non-zero so that sender reports can still be sent for inter-media synchronization and to identify the source by CNAME. The means by which the one or two session parameters for RTCP bandwidth are specified is beyond the scope of this memo.
RTCP报告间隔：建议的常数用于RTCP报告间隔计算。在此配置文件下运行的会话可以为RTCP流量带宽指定单独的参数，而不是使用会话带宽的默认部分。RTCP流量带宽可分为两个单独的会话参数，分别用于活动数据发送者和非活动数据发送者。根据RTP规范[1]中的建议，1/4的RTCP带宽专用于数据发送方，这两个参数的建议默认值分别为1.25%和3.75%。对于特定会话，当在单向链路上操作或对于不需要接收质量反馈的会话，非数据发送方的RTCP带宽可以设置为零。数据发送方的RTCP带宽应保持为非零，以便发送方报告仍可发送以进行媒体间同步，并通过CNAME识别源。指定RTCP带宽的一个或两个会话参数的方法超出了本备忘录的范围。
SR/RR extension: No extension section is defined for the RTCP SR or RR packet.
SR/RR扩展：没有为RTCP SR或RR数据包定义扩展节。
SDES use: Applications MAY use any of the SDES items described in the RTP specification. While CNAME information MUST be sent every reporting interval, other items SHOULD only be sent every third reporting interval, with NAME sent seven out of eight times within that slot and the remaining SDES items cyclically taking up the eighth slot, as defined in Section 6.2.2 of the RTP specification. In other words, NAME is sent in RTCP packets 1, 4, 7, 10, 13, 16, 19, while, say, EMAIL is used in RTCP packet 22.
SDES使用：应用程序可以使用RTP规范中描述的任何SDES项。虽然CNAME信息必须每一个报告间隔发送一次，但其他项目只能每三个报告间隔发送一次，名称在该时隙内发送八次中的七次，其余SDES项目周期性地占用第八个时隙，如RTP规范第6.2.2节所定义。换句话说，名称在RTCP数据包1、4、7、10、13、16、19中发送，而电子邮件在RTCP数据包22中使用。
Security: The RTP default security services are also the default under this profile.
安全性：RTP默认安全服务也是此配置文件下的默认服务。
String-to-key mapping: No mapping is specified by this profile.
字符串到键的映射：此配置文件未指定任何映射。
Congestion: RTP and this profile may be used in the context of enhanced network service, for example, through Integrated Services (RFC 1633) [4] or Differentiated Services (RFC 2475) [5], or they may be used with best effort service.
拥塞：RTP和此配置文件可在增强型网络服务的上下文中使用，例如，通过集成服务（RFC 1633）[4]或差异化服务（RFC 2475）[5]，或与尽力而为服务一起使用。
If enhanced service is being used, RTP receivers SHOULD monitor packet loss to ensure that the service that was requested is actually being delivered. If it is not, then they SHOULD assume that they are receiving best-effort service and behave accordingly.
如果正在使用增强服务，RTP接收器应该监控数据包丢失，以确保请求的服务实际正在交付。如果不是，那么他们应该假设他们正在接受尽力而为的服务，并相应地采取行动。
If best-effort service is being used, RTP receivers SHOULD monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path and experiencing the same network conditions would achieve an average throughput, measured on a reasonable timescale, that is not less than the RTP flow is achieving. This condition can be satisfied by implementing congestion control mechanisms to adapt the transmission rate (or the number of layers subscribed for a layered multicast session), or by arranging for a receiver to leave the session if the loss rate is unacceptably high.
如果正在使用尽力而为服务，RTP接收器应监控数据包丢失，以确保数据包丢失率在可接受的参数范围内。如果通过相同网络路径并经历相同网络条件的TCP流能够达到在合理时间尺度上测量的平均吞吐量，即不小于RTP流所达到的平均吞吐量，则认为丢包是可接受的。可以通过实现拥塞控制机制来适应传输速率（或分层多播会话订阅的层数），或者如果丢失率高得令人无法接受，则通过安排接收机离开会话来满足该条件。
The comparison to TCP cannot be specified exactly, but is intended as an "order-of-magnitude" comparison in timescale and throughput. The timescale on which TCP throughput is measured is the round-trip time of the connection. In essence, this requirement states that it is not acceptable to deploy an application (using RTP or any other transport protocol) on the best-effort Internet which consumes bandwidth arbitrarily and does not compete fairly with TCP within an order of magnitude.
无法精确指定与TCP的比较，但其目的是在时间尺度和吞吐量方面进行“数量级”比较。测量TCP吞吐量的时间尺度是连接的往返时间。本质上，该要求表明，在尽力而为的互联网上部署应用程序（使用RTP或任何其他传输协议）是不可接受的，因为该互联网任意消耗带宽，并且在一个数量级内不能与TCP公平竞争。
Underlying protocol: The profile specifies the use of RTP over unicast and multicast UDP as well as TCP. (This does not preclude the use of these definitions when RTP is carried by other lower-layer protocols.)
底层协议：概要文件指定在单播和多播UDP以及TCP上使用RTP。（当RTP由其他较低层协议承载时，这并不排除使用这些定义。）
Transport mapping: The standard mapping of RTP and RTCP to transport-level addresses is used.
传输映射：使用RTP和RTCP到传输级地址的标准映射。
Encapsulation: This profile leaves to applications the specification of RTP encapsulation in protocols other than UDP.
封装：此配置文件将RTP封装的规范留给应用程序，而不是UDP协议。
This profile lists a set of encodings, each of which is comprised of a particular media data compression or representation plus a payload format for encapsulation within RTP. Some of those payload formats are specified here, while others are specified in separate RFCs. It is expected that additional encodings beyond the set listed here will be created in the future and specified in additional payload format RFCs.
此概要文件列出了一组编码，每个编码都由特定的媒体数据压缩或表示以及用于在RTP中封装的有效负载格式组成。其中一些有效负载格式在此处指定，而其他格式在单独的RFC中指定。预计将来将创建此处列出的集合之外的其他编码，并以其他有效负载格式RFCs指定。
This profile also assigns to each encoding a short name which MAY be used by higher-level control protocols, such as the Session Description Protocol (SDP), RFC 2327 [6], to identify encodings selected for a particular RTP session.
该配置文件还为每个编码分配一个短名称，该名称可由更高级别的控制协议（如会话描述协议（SDP））RFC 2327[6]使用，以识别为特定RTP会话选择的编码。
In some contexts it may be useful to refer to these encodings in the form of a MIME content-type. To facilitate this, RFC 3555 [7] provides registrations for all of the encodings names listed here as MIME subtype names under the "audio" and "video" MIME types through the MIME registration procedure as specified in RFC 2048 [8].
在某些上下文中，以MIME内容类型的形式引用这些编码可能很有用。为了便于实现这一点，RFC 3555[7]通过RFC 2048[8]中规定的MIME注册过程，为此处列出的所有编码名称提供注册，这些名称作为“音频”和“视频”MIME类型下的MIME子类型名称。
Any additional encodings specified for use under this profile (or others) may also be assigned names registered as MIME subtypes with the Internet Assigned Numbers Authority (IANA). This registry provides a means to insure that the names assigned to the additional encodings are kept unique. RFC 3555 specifies the information that is required for the registration of RTP encodings.
在此配置文件下指定使用的任何其他编码（或其他编码）也可以被指定为在Internet assigned Numbers Authority（IANA）注册为MIME子类型的名称。该注册表提供了一种确保分配给其他编码的名称保持唯一的方法。RFC 3555指定注册RTP编码所需的信息。
In addition to assigning names to encodings, this profile also assigns static RTP payload type numbers to some of them. However, the payload type number space is relatively small and cannot accommodate assignments for all existing and future encodings. During the early stages of RTP development, it was necessary to use statically assigned payload types because no other mechanism had been specified to bind encodings to payload types. It was anticipated that non-RTP means beyond the scope of this memo (such as directory services or invitation protocols) would be specified to establish a
除了为编码分配名称外，此概要文件还为其中一些编码分配静态RTP有效负载类型号。但是，有效负载类型编号空间相对较小，无法容纳所有现有和未来编码的分配。在RTP开发的早期阶段，有必要使用静态分配的有效负载类型，因为没有指定其他机制将编码绑定到有效负载类型。预计将指定超出本备忘录范围的非RTP方式（如目录服务或邀请协议）来建立
dynamic mapping between a payload type and an encoding. Now, mechanisms for defining dynamic payload type bindings have been specified in the Session Description Protocol (SDP) and in other protocols such as ITU-T Recommendation H.323/H.245. These mechanisms associate the registered name of the encoding/payload format, along with any additional required parameters, such as the RTP timestamp clock rate and number of channels, with a payload type number. This association is effective only for the duration of the RTP session in which the dynamic payload type binding is made. This association applies only to the RTP session for which it is made, thus the numbers can be re-used for different encodings in different sessions so the number space limitation is avoided.
有效负载类型和编码之间的动态映射。现在，在会话描述协议（SDP）和其他协议（如ITU-T建议H.323/H.245）中已经指定了定义动态有效负载类型绑定的机制。这些机制将编码/有效负载格式的注册名称以及任何额外的必需参数（如RTP时间戳时钟速率和通道数）与有效负载类型编号相关联。此关联仅在进行动态有效负载类型绑定的RTP会话期间有效。此关联仅适用于为其创建的RTP会话，因此数字可以在不同会话中重新用于不同编码，从而避免了数字空间限制。
This profile reserves payload type numbers in the range 96-127 exclusively for dynamic assignment. Applications SHOULD first use values in this range for dynamic payload types. Those applications which need to define more than 32 dynamic payload types MAY bind codes below 96, in which case it is RECOMMENDED that unassigned payload type numbers be used first. However, the statically assigned payload types are default bindings and MAY be dynamically bound to new encodings if needed. Redefining payload types below 96 may cause incorrect operation if an attempt is made to join a session without obtaining session description information that defines the dynamic payload types.
此配置文件专门为动态分配保留96-127范围内的有效负载类型编号。应用程序应首先将此范围内的值用于动态有效负载类型。那些需要定义32种以上动态有效负载类型的应用程序可能会绑定96以下的代码，在这种情况下，建议首先使用未分配的有效负载类型编号。但是，静态分配的有效负载类型是默认绑定，如果需要，可以动态绑定到新编码。如果试图加入会话而未获得定义动态负载类型的会话描述信息，则将负载类型重新定义到96以下可能会导致错误操作。
Dynamic payload types SHOULD NOT be used without a well-defined mechanism to indicate the mapping. Systems that expect to interoperate with others operating under this profile SHOULD NOT make their own assignments of proprietary encodings to particular, fixed payload types.
如果没有明确定义的机制来指示映射，则不应使用动态有效负载类型。期望与在此配置文件下运行的其他系统进行互操作的系统不应将其自己的专有编码分配给特定的固定负载类型。
This specification establishes the policy that no additional static payload types will be assigned beyond the ones defined in this document. Establishing this policy avoids the problem of trying to create a set of criteria for accepting static assignments and encourages the implementation and deployment of the dynamic payload type mechanisms.
本规范确立了一项政策，即除本文档中定义的静态有效负载类型外，不会分配其他静态有效负载类型。建立此策略避免了试图创建一组接受静态分配的标准的问题，并鼓励实现和部署动态有效负载类型机制。
The final set of static payload type assignments is provided in Tables 4 and 5.
表4和表5提供了静态有效负载类型分配的最后一组。
Since the ability to suppress silence is one of the primary motivations for using packets to transmit voice, the RTP header carries both a sequence number and a timestamp to allow a receiver to distinguish between lost packets and periods of time when no data was transmitted. Discontiguous transmission (silence suppression) MAY be used with any audio payload format. Receivers MUST assume that senders may suppress silence unless this is restricted by signaling specified elsewhere. (Even if the transmitter does not suppress silence, the receiver should be prepared to handle periods when no data is present since packets may be lost.)
由于抑制静默的能力是使用分组来传输语音的主要动机之一，因此RTP报头携带序列号和时间戳以允许接收机区分丢失的分组和没有传输数据的时间段。不连续传输（静音抑制）可用于任何音频有效负载格式。接收者必须假设发送者可以抑制静默，除非这受到别处指定的信令的限制。（即使发射机不抑制静音，接收机也应准备好处理不存在数据的时段，因为数据包可能会丢失。）
Some payload formats (see Sections 4.5.3 and 4.5.6) define a "silence insertion descriptor" or "comfort noise" frame to specify parameters for artificial noise that may be generated during a period of silence to approximate the background noise at the source. For other payload formats, a generic Comfort Noise (CN) payload format is specified in RFC 3389 [9]. When the CN payload format is used with another payload format, different values in the RTP payload type field distinguish comfort-noise packets from those of the selected payload format.
一些有效载荷格式（见第4.5.3节和第4.5.6节）定义了“静音插入描述符”或“舒适噪声”帧，以指定静音期间可能产生的人工噪声参数，以近似源处的背景噪声。对于其他有效载荷格式，RFC 3389[9]中规定了通用舒适性噪声（CN）有效载荷格式。当CN有效载荷格式与其他有效载荷格式一起使用时，RTP有效载荷类型字段中的不同值将舒适性噪声包与所选有效载荷格式的噪声包区分开来。
For applications which send either no packets or occasional comfort-noise packets during silence, the first packet of a talkspurt, that is, the first packet after a silence period during which packets have not been transmitted contiguously, SHOULD be distinguished by setting the marker bit in the RTP data header to one. The marker bit in all other packets is zero. The beginning of a talkspurt MAY be used to adjust the playout delay to reflect changing network delays. Applications without silence suppression MUST set the marker bit to zero.
对于在静默期间不发送分组或偶尔发送舒适噪声分组的应用程序，应通过将RTP数据报头中的标记位设置为1来区分TalkSput的第一个分组，即在没有连续发送分组的静默期之后的第一个分组。所有其他数据包中的标记位均为零。TalkSport的开始可用于调整播放延迟以反映不断变化的网络延迟。无静音抑制的应用程序必须将标记位设置为零。
The RTP clock rate used for generating the RTP timestamp is independent of the number of channels and the encoding; it usually equals the number of sampling periods per second. For N-channel encodings, each sampling period (say, 1/8,000 of a second) generates N samples. (This terminology is standard, but somewhat confusing, as the total number of samples generated per second is then the sampling rate times the channel count.)
用于生成RTP时间戳的RTP时钟速率与信道数量和编码无关；它通常等于每秒的采样周期数。对于N信道编码，每个采样周期（例如，1/8000秒）生成N个采样。（此术语是标准术语，但有些混乱，因为每秒生成的采样总数是采样率乘以通道计数。）
If multiple audio channels are used, channels are numbered left-to-right, starting at one. In RTP audio packets, information from lower-numbered channels precedes that from higher-numbered channels.
如果使用多个音频频道，则频道从左到右编号，从一个开始。在RTP音频数据包中，来自编号较低通道的信息优先于来自编号较高通道的信息。
For more than two channels, the convention followed by the AIFF-C audio interchange format SHOULD be followed [3], using the following notation, unless some other convention is specified for a particular encoding or payload format:
对于两个以上的频道，应遵循AIFF-C音频交换格式遵循的约定[3]，使用以下符号，除非为特定编码或有效负载格式指定了其他约定：
l left r right c center S surround F front R rear
左左右c中心S环绕F前右后
channels description channel
1 2 3 4 5 6
_________________________________________________
2 stereo l r
3 l r c
4 l c r S
5 Fl Fr Fc Sl Sr
6 l lc c r rc S
channels description channel
1 2 3 4 5 6
_________________________________________________
2 stereo l r
3 l r c
4 l c r S
5 Fl Fr Fc Sl Sr
6 l lc c r rc S
Note: RFC 1890 defined two conventions for the ordering of four audio channels. Since the ordering is indicated implicitly by the number of channels, this was ambiguous. In this revision, the order described as "quadrophonic" has been eliminated to remove the ambiguity. This choice was based on the observation that quadrophonic consumer audio format did not become popular whereas surround-sound subsequently has.
注：RFC1890为四个音频通道的顺序定义了两种约定。由于顺序是由通道数隐式表示的，因此这是不明确的。在本次修订中，为了消除歧义，取消了“四和弦”的顺序。这一选择是基于这样一个观察结果，即四和弦消费音频格式并未流行，而环绕声随后已经流行。
Samples for all channels belonging to a single sampling instant MUST be within the same packet. The interleaving of samples from different channels depends on the encoding. General guidelines are given in Section 4.3 and 4.4.
属于单个采样瞬间的所有通道的采样必须在同一数据包内。来自不同通道的样本交错取决于编码。一般指南见第4.3节和第4.4节。
The sampling frequency SHOULD be drawn from the set: 8,000, 11,025, 16,000, 22,050, 24,000, 32,000, 44,100 and 48,000 Hz. (Older Apple Macintosh computers had a native sample rate of 22,254.54 Hz, which can be converted to 22,050 with acceptable quality by dropping 4 samples in a 20 ms frame.) However, most audio encodings are defined for a more restricted set of sampling frequencies. Receivers SHOULD be prepared to accept multi-channel audio, but MAY choose to only play a single channel.
采样频率应从以下集合中抽取：8000、11025、16000、22050、24000、32000、44100和48000 Hz。（较旧的Apple Macintosh计算机的本机采样率为22254.54 Hz，可以通过在20毫秒的帧中删除4个采样，将其转换为质量可接受的22050。）然而，大多数音频编码是为一组更受限制的采样频率定义的。接收机应准备好接受多声道音频，但可以选择只播放一个声道。
The following recommendations are default operating parameters. Applications SHOULD be prepared to handle other values. The ranges given are meant to give guidance to application writers, allowing a
以下建议为默认操作参数。应用程序应准备好处理其他值。给出的范围旨在为应用程序编写者提供指导，允许
set of applications conforming to these guidelines to interoperate without additional negotiation. These guidelines are not intended to restrict operating parameters for applications that can negotiate a set of interoperable parameters, e.g., through a conference control protocol.
符合这些准则的一组应用程序，无需额外协商即可进行互操作。这些指南并非旨在限制可协商一组互操作参数（例如通过会议控制协议）的应用程序的操作参数。
For packetized audio, the default packetization interval SHOULD have a duration of 20 ms or one frame, whichever is longer, unless otherwise noted in Table 1 (column "ms/packet"). The packetization interval determines the minimum end-to-end delay; longer packets introduce less header overhead but higher delay and make packet loss more noticeable. For non-interactive applications such as lectures or for links with severe bandwidth constraints, a higher packetization delay MAY be used. A receiver SHOULD accept packets representing between 0 and 200 ms of audio data. (For framed audio encodings, a receiver SHOULD accept packets with a number of frames equal to 200 ms divided by the frame duration, rounded up.) This restriction allows reasonable buffer sizing for the receiver.
对于打包音频，默认打包间隔的持续时间应为20 ms或一帧，以较长者为准，除非表1中另有说明（“ms/packet”列）。分组间隔确定最小端到端延迟；较长的数据包引入较少的报头开销，但更高的延迟，使数据包丢失更加明显。对于非交互式应用，例如讲座或具有严重带宽限制的链接，可以使用更高的分组延迟。接收器应接受表示0到200ms音频数据的数据包。（对于帧音频编码，接收器应接受帧数等于200 ms除以帧持续时间的数据包，向上舍入。）此限制允许接收器合理调整缓冲区大小。
In sample-based encodings, each audio sample is represented by a fixed number of bits. Within the compressed audio data, codes for individual samples may span octet boundaries. An RTP audio packet may contain any number of audio samples, subject to the constraint that the number of bits per sample times the number of samples per packet yields an integral octet count. Fractional encodings produce less than one octet per sample.
在基于样本的编码中，每个音频样本由固定位数表示。在压缩音频数据中，单个样本的代码可能跨越八位字节边界。RTP音频分组可以包含任意数量的音频样本，但受制于每个样本的比特数乘以每个分组的样本数产生整数八位组计数的约束。分数编码每个样本产生少于一个八位组。
The duration of an audio packet is determined by the number of samples in the packet.
音频分组的持续时间由分组中的样本数确定。
For sample-based encodings producing one or more octets per sample,
samples from different channels sampled at the same sampling instant
SHOULD be packed in consecutive octets. For example, for a two-
channel encoding, the octet sequence is (left channel, first sample),
(right channel, first sample), (left channel, second sample), (right
channel, second sample), .... For multi-octet encodings, octets
SHOULD be transmitted in network byte order (i.e., most significant
octet first).
For sample-based encodings producing one or more octets per sample,
samples from different channels sampled at the same sampling instant
SHOULD be packed in consecutive octets. For example, for a two-
channel encoding, the octet sequence is (left channel, first sample),
(right channel, first sample), (left channel, second sample), (right
channel, second sample), .... For multi-octet encodings, octets
SHOULD be transmitted in network byte order (i.e., most significant
octet first).
The packing of sample-based encodings producing less than one octet per sample is encoding-specific.
每个样本产生少于一个八位组的基于样本的编码的打包是特定于编码的。
The RTP timestamp reflects the instant at which the first sample in the packet was sampled, that is, the oldest information in the packet.
RTP时间戳反映分组中第一个样本被采样的时刻，即分组中最早的信息。
Frame-based encodings encode a fixed-length block of audio into another block of compressed data, typically also of fixed length. For frame-based encodings, the sender MAY choose to combine several such frames into a single RTP packet. The receiver can tell the number of frames contained in an RTP packet, if all the frames have the same length, by dividing the RTP payload length by the audio frame size which is defined as part of the encoding. This does not work when carrying frames of different sizes unless the frame sizes are relatively prime. If not, the frames MUST indicate their size.
基于帧的编码将固定长度的音频块编码为另一个压缩数据块，通常也是固定长度的。对于基于帧的编码，发送方可以选择将多个这样的帧组合成单个RTP分组。如果所有帧具有相同的长度，则接收机可以通过将RTP有效负载长度除以定义为编码的一部分的音频帧大小来告诉RTP分组中包含的帧的数量。当承载不同尺寸的框架时，这不起作用，除非框架尺寸相对较大。如果没有，框架必须指明其大小。
For frame-based codecs, the channel order is defined for the whole block. That is, for two-channel audio, right and left samples SHOULD be coded independently, with the encoded frame for the left channel preceding that for the right channel.
对于基于帧的编解码器，为整个块定义通道顺序。也就是说，对于双声道音频，应分别对右声道和左声道采样进行编码，左声道的编码帧先于右声道的编码帧。
All frame-oriented audio codecs SHOULD be able to encode and decode several consecutive frames within a single packet. Since the frame size for the frame-oriented codecs is given, there is no need to use a separate designation for the same encoding, but with different number of frames per packet.
所有面向帧的音频编解码器应能够在单个数据包中编码和解码多个连续帧。由于面向帧的编解码器的帧大小是给定的，因此不需要对相同的编码使用单独的指定，但是每个分组的帧数不同。
RTP packets SHALL contain a whole number of frames, with frames inserted according to age within a packet, so that the oldest frame (to be played first) occurs immediately after the RTP packet header. The RTP timestamp reflects the instant at which the first sample in the first frame was sampled, that is, the oldest information in the packet.
RTP数据包应包含完整数量的帧，并根据数据包内的时间插入帧，以便最早的帧（首先播放）立即出现在RTP数据包报头之后。RTP时间戳反映第一帧中的第一个样本被采样的时刻，即，分组中最早的信息。
name of sampling default
encoding sample/frame bits/sample rate ms/frame ms/packet
__________________________________________________________________
DVI4 sample 4 var. 20
G722 sample 8 16,000 20
G723 frame N/A 8,000 30 30
G726-40 sample 5 8,000 20
G726-32 sample 4 8,000 20
G726-24 sample 3 8,000 20
G726-16 sample 2 8,000 20
G728 frame N/A 8,000 2.5 20
G729 frame N/A 8,000 10 20
G729D frame N/A 8,000 10 20
G729E frame N/A 8,000 10 20
GSM frame N/A 8,000 20 20
GSM-EFR frame N/A 8,000 20 20
L8 sample 8 var. 20
L16 sample 16 var. 20
LPC frame N/A 8,000 20 20
MPA frame N/A var. var.
PCMA sample 8 var. 20
PCMU sample 8 var. 20
QCELP frame N/A 8,000 20 20
VDVI sample var. var. 20
name of sampling default
encoding sample/frame bits/sample rate ms/frame ms/packet
__________________________________________________________________
DVI4 sample 4 var. 20
G722 sample 8 16,000 20
G723 frame N/A 8,000 30 30
G726-40 sample 5 8,000 20
G726-32 sample 4 8,000 20
G726-24 sample 3 8,000 20
G726-16 sample 2 8,000 20
G728 frame N/A 8,000 2.5 20
G729 frame N/A 8,000 10 20
G729D frame N/A 8,000 10 20
G729E frame N/A 8,000 10 20
GSM frame N/A 8,000 20 20
GSM-EFR frame N/A 8,000 20 20
L8 sample 8 var. 20
L16 sample 16 var. 20
LPC frame N/A 8,000 20 20
MPA frame N/A var. var.
PCMA sample 8 var. 20
PCMU sample 8 var. 20
QCELP frame N/A 8,000 20 20
VDVI sample var. var. 20
Table 1: Properties of Audio Encodings (N/A: not applicable; var.:
variable)
Table 1: Properties of Audio Encodings (N/A: not applicable; var.:
variable)
The characteristics of the audio encodings described in this document are shown in Table 1; they are listed in order of their payload type in Table 4. While most audio codecs are only specified for a fixed sampling rate, some sample-based algorithms (indicated by an entry of "var." in the sampling rate column of Table 1) may be used with different sampling rates, resulting in different coded bit rates. When used with a sampling rate other than that for which a static payload type is defined, non-RTP means beyond the scope of this memo MUST be used to define a dynamic payload type and MUST indicate the selected RTP timestamp clock rate, which is usually the same as the sampling rate for audio.
本文件中描述的音频编码特性如表1所示；表4按有效载荷类型的顺序列出了它们。虽然大多数音频编解码器仅针对固定的采样率进行指定，但一些基于采样的算法（由表1的采样率列中的“var”项表示）可与不同的采样率一起使用，从而产生不同的编码比特率。当与定义了静态有效负载类型的采样率以外的采样率一起使用时，必须使用超出本备忘录范围的非RTP方式来定义动态有效负载类型，并且必须指示所选RTP时间戳时钟率，该时钟率通常与音频采样率相同。
DVI4 uses an adaptive delta pulse code modulation (ADPCM) encoding scheme that was specified by the Interactive Multimedia Association (IMA) as the "IMA ADPCM wave type". However, the encoding defined here as DVI4 differs in three respects from the IMA specification:
DVI4使用交互式多媒体协会（IMA）指定为“IMA ADPCM波形类型”的自适应增量脉冲编码调制（ADPCM）编码方案。然而，此处定义为DVI4的编码在三个方面与IMA规范不同：
o The RTP DVI4 header contains the predicted value rather than the first sample value contained the IMA ADPCM block header.
o RTP DVI4标头包含预测值，而不是包含IMA ADPCM块标头的第一个样本值。
o IMA ADPCM blocks contain an odd number of samples, since the first sample of a block is contained just in the header (uncompressed), followed by an even number of compressed samples. DVI4 has an even number of compressed samples only, using the `predict' word from the header to decode the first sample.
o IMA ADPCM块包含奇数个样本，因为块的第一个样本仅包含在头中（未压缩），然后是偶数个压缩样本。DVI4只有偶数个压缩样本，使用来自报头的“predict”字对第一个样本进行解码。
o For DVI4, the 4-bit samples are packed with the first sample in the four most significant bits and the second sample in the four least significant bits. In the IMA ADPCM codec, the samples are packed in the opposite order.
o 对于DVI4，4位样本与四个最高有效位中的第一个样本和四个最低有效位中的第二个样本一起打包。在IMA ADPCM编解码器中，样本以相反的顺序打包。
Each packet contains a single DVI block. This profile only defines the 4-bit-per-sample version, while IMA also specified a 3-bit-per-sample encoding.
每个数据包包含一个DVI块。此配置文件仅定义了每样本4位的版本，而IMA还指定了每样本3位的编码。
The "header" word for each channel has the following structure:
每个通道的“标题”字具有以下结构：
int16 predict; /* predicted value of first sample
from the previous block (L16 format) */
u_int8 index; /* current index into stepsize table */
u_int8 reserved; /* set to zero by sender, ignored by receiver */
int16 predict; /* predicted value of first sample
from the previous block (L16 format) */
u_int8 index; /* current index into stepsize table */
u_int8 reserved; /* set to zero by sender, ignored by receiver */
Each octet following the header contains two 4-bit samples, thus the number of samples per packet MUST be even because there is no means to indicate a partially filled last octet.
报头后面的每个八位字节包含两个4位样本，因此每个数据包的样本数必须为偶数，因为无法指示部分填充的最后一个八位字节。
Packing of samples for multiple channels is for further study.
多通道样品的包装有待进一步研究。
The IMA ADPCM algorithm was described in the document IMA Recommended Practices for Enhancing Digital Audio Compatibility in Multimedia Systems (version 3.0). However, the Interactive Multimedia Association ceased operations in 1997. Resources for an archived copy of that document and a software implementation of the RTP DVI4 encoding are listed in Section 13.
IMA ADPCM算法在文件《IMA增强多媒体系统中数字音频兼容性的推荐做法》（3.0版）中进行了描述。然而，互动多媒体协会于1997年停止运作。第13节列出了该文件的存档副本和RTP DVI4编码的软件实现的资源。
G722 is specified in ITU-T Recommendation G.722, "7 kHz audio-coding within 64 kbit/s". The G.722 encoder produces a stream of octets, each of which SHALL be octet-aligned in an RTP packet. The first bit transmitted in the G.722 octet, which is the most significant bit of the higher sub-band sample, SHALL correspond to the most significant bit of the octet in the RTP packet.
G722在ITU-T建议G.722“64kbit/s内的7kHz音频编码”中有规定。G.722编码器产生八位字节流，每个八位字节在RTP数据包中对齐。G.722八位字节中传输的第一位，即较高子带样本的最高有效位，应对应于RTP数据包中八位字节的最高有效位。
Even though the actual sampling rate for G.722 audio is 16,000 Hz, the RTP clock rate for the G722 payload format is 8,000 Hz because that value was erroneously assigned in RFC 1890 and must remain unchanged for backward compatibility. The octet rate or sample-pair rate is 8,000 Hz.
尽管G.722音频的实际采样率为16000 Hz，但G722有效负载格式的RTP时钟率为8000 Hz，因为该值在RFC 1890中被错误分配，并且必须保持不变以实现向后兼容性。八位组速率或样本对速率为8000 Hz。
G723 is specified in ITU Recommendation G.723.1, "Dual-rate speech coder for multimedia communications transmitting at 5.3 and 6.3 kbit/s". The G.723.1 5.3/6.3 kbit/s codec was defined by the ITU-T as a mandatory codec for ITU-T H.324 GSTN videophone terminal applications. The algorithm has a floating point specification in Annex B to G.723.1, a silence compression algorithm in Annex A to G.723.1 and a scalable channel coding scheme for wireless applications in G.723.1 Annex C.
G723在ITU建议G.723.1“用于以5.3和6.3 kbit/s传输多媒体通信的双速率语音编码器”中规定。G.723.1 5.3/6.3 kbit/s编解码器由ITU-T定义为ITU-T H.324 GSTN可视电话终端应用的强制性编解码器。该算法在G.723.1附录B中有浮点规范，在G.723.1附录a中有静默压缩算法，在G.723.1附录C中有用于无线应用的可伸缩信道编码方案。
This Recommendation specifies a coded representation that can be used for compressing the speech signal component of multi-media services at a very low bit rate. Audio is encoded in 30 ms frames, with an additional delay of 7.5 ms due to look-ahead. A G.723.1 frame can be one of three sizes: 24 octets (6.3 kb/s frame), 20 octets (5.3 kb/s frame), or 4 octets. These 4-octet frames are called SID frames (Silence Insertion Descriptor) and are used to specify comfort noise parameters. There is no restriction on how 4, 20, and 24 octet frames are intermixed. The least significant two bits of the first octet in the frame determine the frame size and codec type:
本建议规定了可用于以极低比特率压缩多媒体服务的语音信号分量的编码表示。音频以30毫秒的帧进行编码，由于向前看，额外延迟7.5毫秒。G.723.1帧可以是三种大小之一：24个八位字节（6.3 kb/s帧）、20个八位字节（5.3 kb/s帧）或4个八位字节。这些4-octet帧称为SID帧（静音插入描述符），用于指定舒适噪声参数。对于如何混合4、20和24个八位组帧没有限制。帧中第一个八位字节的最低有效位决定帧大小和编解码器类型：
bits content octets/frame 00 high-rate speech (6.3 kb/s) 24 01 low-rate speech (5.3 kb/s) 20 10 SID frame 4 11 reserved
比特内容八位字节/帧00高速率语音（6.3 kb/s）24 01低速率语音（5.3 kb/s）20 10 SID帧4 11保留
It is possible to switch between the two rates at any 30 ms frame boundary. Both (5.3 kb/s and 6.3 kb/s) rates are a mandatory part of the encoder and decoder. Receivers MUST accept both data rates and MUST accept SID frames unless restriction of these capabilities has been signaled. The MIME registration for G723 in RFC 3555 [7] specifies parameters that MAY be used with MIME or SDP to restrict to a single data rate or to restrict the use of SID frames. This coder was optimized to represent speech with near-toll quality at the above rates using a limited amount of complexity.
可以在任何30ms帧边界上在两个速率之间切换。这两种速率（5.3kb/s和6.3kb/s）都是编码器和解码器的必备部分。接收机必须接受这两种数据速率，并且必须接受SID帧，除非这些能力受到限制。RFC 3555[7]中G723的MIME注册指定了可与MIME或SDP一起使用的参数，以限制单个数据速率或限制SID帧的使用。该编码器经过优化，以有限的复杂度以上述速率表示接近通行费质量的语音。
The packing of the encoded bit stream into octets and the transmission order of the octets is specified in Rec. G.723.1 and is the same as that produced by the G.723 C code reference implementation. For the 6.3 kb/s data rate, this packing is illustrated as follows, where the header (HDR) bits are always "0 0" as shown in Fig. 1 to indicate operation at 6.3 kb/s, and the Z bit is always set to zero. The diagrams show the bit packing in "network byte order", also known as big-endian order. The bits of each 32-bit word are numbered 0 to 31, with the most significant bit on the left and numbered 0. The octets (bytes) of each word are transmitted most significant octet first. The bits of each data field are numbered in the order of the bit stream representation of the encoding (least significant bit first). The vertical bars indicate the boundaries between field fragments.
记录G.723.1中规定了将编码比特流打包成八位字节以及八位字节的传输顺序，并且与G.723 C代码参考实现产生的顺序相同。对于6.3kb/s的数据速率，这种打包如下所示，其中头部（HDR）位始终为“0 0”，如图1所示，以指示以6.3kb/s的速度运行，并且Z位始终设置为零。图中显示了“网络字节顺序”中的位打包，也称为大端顺序。每个32位字的位编号为0到31，最高有效位在左边，编号为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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LPC |HDR| LPC | LPC | ACL0 |LPC|
| | | | | | |
|0 0 0 0 0 0|0 0|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2|
|5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACL2 |ACL|A| GAIN0 |ACL|ACL| GAIN0 | GAIN1 |
| | 1 |C| | 3 | 2 | | |
|0 0 0 0 0|0 0|0|0 0 0 0|0 0|0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
|4 3 2 1 0|1 0|6|3 2 1 0|1 0|6 5|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAIN2 | GAIN1 | GAIN2 | GAIN3 | GRID | GAIN3 |
| | | | | | |
|0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0|
|3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|3 2 1 0|1 0 9 8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSBPOS |Z|POS| MSBPOS | POS0 |POS| POS0 |
| | | 0 | | | 1 | |
|0 0 0 0 0 0 0|0|0 0|1 1 1 0 0 0|0 0 0 0 0 0 0 0|0 0|1 1 1 1 1 1|
|6 5 4 3 2 1 0| |1 0|2 1 0 9 8 7|9 8 7 6 5 4 3 2|1 0|5 4 3 2 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| POS1 | POS2 | POS1 | POS2 | POS3 | POS2 |
| | | | | | |
|0 0 0 0 0 0 0 0|0 0 0 0|1 1 1 1|1 1 0 0 0 0 0 0|0 0 0 0|1 1 1 1|
|9 8 7 6 5 4 3 2|3 2 1 0|3 2 1 0|1 0 9 8 7 6 5 4|3 2 1 0|5 4 3 2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| POS3 | PSIG0 |POS|PSIG2| PSIG1 | PSIG3 |PSIG2|
| | | 3 | | | | |
|1 1 0 0 0 0 0 0|0 0 0 0 0 0|1 1|0 0 0|0 0 0 0 0|0 0 0 0 0|0 0 0|
|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2|2 1 0|4 3 2 1 0|4 3 2 1 0|5 4 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LPC |HDR| LPC | LPC | ACL0 |LPC|
| | | | | | |
|0 0 0 0 0 0|0 0|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2|
|5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACL2 |ACL|A| GAIN0 |ACL|ACL| GAIN0 | GAIN1 |
| | 1 |C| | 3 | 2 | | |
|0 0 0 0 0|0 0|0|0 0 0 0|0 0|0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
|4 3 2 1 0|1 0|6|3 2 1 0|1 0|6 5|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAIN2 | GAIN1 | GAIN2 | GAIN3 | GRID | GAIN3 |
| | | | | | |
|0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0|
|3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|3 2 1 0|1 0 9 8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSBPOS |Z|POS| MSBPOS | POS0 |POS| POS0 |
| | | 0 | | | 1 | |
|0 0 0 0 0 0 0|0|0 0|1 1 1 0 0 0|0 0 0 0 0 0 0 0|0 0|1 1 1 1 1 1|
|6 5 4 3 2 1 0| |1 0|2 1 0 9 8 7|9 8 7 6 5 4 3 2|1 0|5 4 3 2 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| POS1 | POS2 | POS1 | POS2 | POS3 | POS2 |
| | | | | | |
|0 0 0 0 0 0 0 0|0 0 0 0|1 1 1 1|1 1 0 0 0 0 0 0|0 0 0 0|1 1 1 1|
|9 8 7 6 5 4 3 2|3 2 1 0|3 2 1 0|1 0 9 8 7 6 5 4|3 2 1 0|5 4 3 2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| POS3 | PSIG0 |POS|PSIG2| PSIG1 | PSIG3 |PSIG2|
| | | 3 | | | | |
|1 1 0 0 0 0 0 0|0 0 0 0 0 0|1 1|0 0 0|0 0 0 0 0|0 0 0 0 0|0 0 0|
|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2|2 1 0|4 3 2 1 0|4 3 2 1 0|5 4 3|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: G.723 (6.3 kb/s) bit packing
图1:G.723（6.3kb/s）位打包
For the 5.3 kb/s data rate, the header (HDR) bits are always "0 1", as shown in Fig. 2, to indicate operation at 5.3 kb/s.
对于5.3kb/s的数据速率，报头（HDR）位始终为“01”，如图2所示，以指示以5.3kb/s的速度运行。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LPC |HDR| LPC | LPC | ACL0 |LPC|
| | | | | | |
|0 0 0 0 0 0|0 1|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2|
|5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACL2 |ACL|A| GAIN0 |ACL|ACL| GAIN0 | GAIN1 |
| | 1 |C| | 3 | 2 | | |
|0 0 0 0 0|0 0|0|0 0 0 0|0 0|0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
|4 3 2 1 0|1 0|6|3 2 1 0|1 0|6 5|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAIN2 | GAIN1 | GAIN2 | GAIN3 | GRID | GAIN3 |
| | | | | | |
|0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0|
|3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|4 3 2 1|1 0 9 8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| POS0 | POS1 | POS0 | POS1 | POS2 |
| | | | | |
|0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
|7 6 5 4 3 2 1 0|3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| POS3 | POS2 | POS3 | PSIG1 | PSIG0 | PSIG3 | PSIG2 |
| | | | | | | |
|0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|
|3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|3 2 1 0|3 2 1 0|3 2 1 0|3 2 1 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LPC |HDR| LPC | LPC | ACL0 |LPC|
| | | | | | |
|0 0 0 0 0 0|0 1|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2|
|5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACL2 |ACL|A| GAIN0 |ACL|ACL| GAIN0 | GAIN1 |
| | 1 |C| | 3 | 2 | | |
|0 0 0 0 0|0 0|0|0 0 0 0|0 0|0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
|4 3 2 1 0|1 0|6|3 2 1 0|1 0|6 5|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAIN2 | GAIN1 | GAIN2 | GAIN3 | GRID | GAIN3 |
| | | | | | |
|0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0|
|3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|4 3 2 1|1 0 9 8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| POS0 | POS1 | POS0 | POS1 | POS2 |
| | | | | |
|0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
|7 6 5 4 3 2 1 0|3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| POS3 | POS2 | POS3 | PSIG1 | PSIG0 | PSIG3 | PSIG2 |
| | | | | | | |
|0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|
|3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|3 2 1 0|3 2 1 0|3 2 1 0|3 2 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: G.723 (5.3 kb/s) bit packing
图2:G.723（5.3kb/s）位打包
The packing of G.723.1 SID (silence) frames, which are indicated by the header (HDR) bits having the pattern "1 0", is depicted in Fig. 3.
图3中描绘了G.723.1 SID（静默）帧的打包，其由具有模式“1 0”的报头（HDR）位指示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LPC |HDR| LPC | LPC | GAIN |LPC|
| | | | | | |
|0 0 0 0 0 0|1 0|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2|
|5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LPC |HDR| LPC | LPC | GAIN |LPC|
| | | | | | |
|0 0 0 0 0 0|1 0|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2|
|5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: G.723 SID mode bit packing
图3:G.723 SID模式位打包
ITU-T Recommendation G.726 describes, among others, the algorithm recommended for conversion of a single 64 kbit/s A-law or mu-law PCM channel encoded at 8,000 samples/sec to and from a 40, 32, 24, or 16 kbit/s channel. The conversion is applied to the PCM stream using an Adaptive Differential Pulse Code Modulation (ADPCM) transcoding technique. The ADPCM representation consists of a series of codewords with a one-to-one correspondence to the samples in the PCM stream. The G726 data rates of 40, 32, 24, and 16 kbit/s have codewords of 5, 4, 3, and 2 bits, respectively.
除其他外，ITU-T建议G.726描述了建议用于将以8000采样/秒编码的单个64 kbit/s a律或mu律PCM信道转换为40、32、24或16 kbit/s信道的算法。该转换使用自适应差分脉冲编码调制（ADPCM）转码技术应用于PCM流。ADPCM表示法由一系列与PCM流中的样本一一对应的码字组成。G726数据速率为40、32、24和16 kbit/s，其码字分别为5、4、3和2位。
The 16 and 24 kbit/s encodings do not provide toll quality speech. They are designed for used in overloaded Digital Circuit Multiplication Equipment (DCME). ITU-T G.726 recommends that the 16 and 24 kbit/s encodings should be alternated with higher data rate encodings to provide an average sample size of between 3.5 and 3.7 bits per sample.
16和24 kbit/s编码不能提供收费质量的语音。它们设计用于过载数字电路乘法设备（DCME）。ITU-T G.726建议16和24 kbit/s编码应与更高的数据速率编码交替使用，以提供每个样本3.5到3.7位之间的平均样本大小。
The encodings of G.726 are here denoted as G726-40, G726-32, G726-24, and G726-16. Prior to 1990, G721 described the 32 kbit/s ADPCM encoding, and G723 described the 40, 32, and 16 kbit/s encodings. Thus, G726-32 designates the same algorithm as G721 in RFC 1890.
G.726的编码在这里表示为G726-40、G726-32、G726-24和G726-16。在1990年之前，G721描述了32 kbit/s ADPCM编码，G723描述了40、32和16 kbit/s编码。因此，G726-32指定的算法与RFC1890中的G721相同。
A stream of G726 codewords contains no information on the encoding being used, therefore transitions between G726 encoding types are not permitted within a sequence of packed codewords. Applications MUST determine the encoding type of packed codewords from the RTP payload identifier.
G726码字流不包含所使用编码的任何信息，因此在压缩码字序列中不允许G726编码类型之间的转换。应用程序必须根据RTP有效负载标识符确定压缩码字的编码类型。
No payload-specific header information SHALL be included as part of the audio data. A stream of G726 codewords MUST be packed into octets as follows: the first codeword is placed into the first octet such that the least significant bit of the codeword aligns with the least significant bit in the octet, the second codeword is then packed so that its least significant bit coincides with the least significant unoccupied bit in the octet. When a complete codeword cannot be placed into an octet, the bits overlapping the octet boundary are placed into the least significant bits of the next octet. Packing MUST end with a completely packed final octet. The number of codewords packed will therefore be a multiple of 8, 2, 8, and 4 for G726-40, G726-32, G726-24, and G726-16, respectively. An example of the packing scheme for G726-32 codewords is as shown, where bit 7 is the least significant bit of the first octet, and bit A3 is the least significant bit of the first codeword:
音频数据中不应包含特定于有效载荷的报头信息。G726码字流必须按如下方式打包成八位字节：将第一个码字放入第一个八位字节，以便码字的最低有效位与八位字节中的最低有效位对齐，然后对第二个码字进行压缩，使其最低有效位与八位字节中最低有效未占用位一致。当一个完整的码字不能放入一个八位组时，与八位组边界重叠的位被放入下一个八位组的最低有效位。包装必须以完全包装的最后八位字节结束。因此，对于G726-40、G726-32、G726-24和G726-16，压缩的码字数将分别为8、2、8和4的倍数。G726-32码字的打包方案示例如图所示，其中位7是第一个八位字节的最低有效位，位A3是第一个码字的最低有效位：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|B B B B|A A A A|D D D D|C C C C| ...
|0 1 2 3|0 1 2 3|0 1 2 3|0 1 2 3|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|B B B B|A A A A|D D D D|C C C C| ...
|0 1 2 3|0 1 2 3|0 1 2 3|0 1 2 3|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
An example of the packing scheme for G726-24 codewords follows, where again bit 7 is the least significant bit of the first octet, and bit A2 is the least significant bit of the first codeword:
G726-24码字的打包方案示例如下，其中位7是第一个八位组的最低有效位，位A2是第一个码字的最低有效位：
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|C C|B B B|A A A|F|E E E|D D D|C|H H H|G G G|F F| ...
|1 2|0 1 2|0 1 2|2|0 1 2|0 1 2|0|0 1 2|0 1 2|0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|C C|B B B|A A A|F|E E E|D D D|C|H H H|G G G|F F| ...
|1 2|0 1 2|0 1 2|2|0 1 2|0 1 2|0|0 1 2|0 1 2|0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Note that the "little-endian" direction in which samples are packed into octets in the G726-16, -24, -32 and -40 payload formats specified here is consistent with ITU-T Recommendation X.420, but is the opposite of what is specified in ITU-T Recommendation I.366.2 Annex E for ATM AAL2 transport. A second set of RTP payload formats matching the packetization of I.366.2 Annex E and identified by MIME subtypes AAL2-G726-16, -24, -32 and -40 will be specified in a separate document.
请注意，此处规定的样本以G726-16、-24、-32和-40有效载荷格式打包成八位字节的“小端”方向与ITU-T建议X.420一致，但与ITU-T建议I.366.2附录E中规定的ATM AAL2传输相反。第二组RTP有效载荷格式与I.366.2附录E的打包匹配，并由MIME子类型AAL2-G726-16、-24、-32和-40标识，将在单独的文件中指定。
G728 is specified in ITU-T Recommendation G.728, "Coding of speech at 16 kbit/s using low-delay code excited linear prediction".
G728在ITU-T建议G.728“使用低延迟码激励线性预测对16 kbit/s的语音进行编码”中规定。
A G.278 encoder translates 5 consecutive audio samples into a 10-bit codebook index, resulting in a bit rate of 16 kb/s for audio sampled at 8,000 samples per second. The group of five consecutive samples is called a vector. Four consecutive vectors, labeled V1 to V4 (where V1 is to be played first by the receiver), build one G.728 frame. The four vectors of 40 bits are packed into 5 octets, labeled B1 through B5. B1 SHALL be placed first in the RTP packet.
G.278编码器将5个连续音频样本转换为10位码本索引，以每秒8000个样本的速度采样的音频的比特率为16 kb/s。由五个连续样本组成的组称为向量。四个连续的向量，标记为V1到V4（其中V1首先由接收器播放），构建一个G.728帧。40位的四个向量被压缩成5个八位字节，标记为B1到B5。B1应首先放入RTP包中。
Referring to the figure below, the principle for bit order is "maintenance of bit significance". Bits from an older vector are more significant than bits from newer vectors. The MSB of the frame goes to the MSB of B1 and the LSB of the frame goes to LSB of B5.
参考下图，比特顺序的原则是“保持比特重要性”。来自旧向量的位比来自新向量的位更重要。帧的MSB指向B1的MSB，帧的LSB指向B5的LSB。
1 2 3 3
0 0 0 0 9
++++++++++++++++++++++++++++++++++++++++
<---V1---><---V2---><---V3---><---V4---> vectors
<--B1--><--B2--><--B3--><--B4--><--B5--> octets
<------------- frame 1 ---------------->
1 2 3 3
0 0 0 0 9
++++++++++++++++++++++++++++++++++++++++
<---V1---><---V2---><---V3---><---V4---> vectors
<--B1--><--B2--><--B3--><--B4--><--B5--> octets
<------------- frame 1 ---------------->
In particular, B1 contains the eight most significant bits of V1, with the MSB of V1 being the MSB of B1. B2 contains the two least significant bits of V1, the more significant of the two in its MSB, and the six most significant bits of V2. B1 SHALL be placed first in the RTP packet and B5 last.
特别是，B1包含V1的八个最高有效位，V1的MSB是B1的MSB。B2包含V1的两个最低有效位、MSB中两个最低有效位中的较高有效位以及V2的六个最高有效位。B1应首先放入RTP包中，B5应最后放入。
G729 is specified in ITU-T Recommendation G.729, "Coding of speech at 8 kbit/s using conjugate structure-algebraic code excited linear prediction (CS-ACELP)". A reduced-complexity version of the G.729 algorithm is specified in Annex A to Rec. G.729. The speech coding algorithms in the main body of G.729 and in G.729 Annex A are fully interoperable with each other, so there is no need to further distinguish between them. An implementation that signals or accepts use of G729 payload format may implement either G.729 or G.729A unless restricted by additional signaling specified elsewhere related specifically to the encoding rather than the payload format. The G.729 and G.729 Annex A codecs were optimized to represent speech with high quality, where G.729 Annex A trades some speech quality for an approximate 50% complexity reduction [10]. See the next Section (4.5.7) for other data rates added in later G.729 Annexes. For all data rates, the sampling frequency (and RTP timestamp clock rate) is 8,000 Hz.
G729在ITU-T建议G.729“使用共轭结构代数码激励线性预测（CS-ACELP）对8kbit/s语音进行编码”中作了规定。建议G.729的附录A中规定了G.729算法的简化版本。G.729主体和G.729附录A中的语音编码算法完全互操作，因此无需进一步区分它们。发出信号或接受使用G729有效载荷格式的实现可以实现G.729或G.729A，除非受到其他地方特别规定的与编码而非有效载荷格式相关的附加信号的限制。G.729和G.729附录A编解码器经过优化，以表示高质量的语音，其中G.729附录A用一些语音质量换取大约50%的复杂度降低[10]。见下一节（4.5.7），了解后续G.729附件中增加的其他数据速率。对于所有数据速率，采样频率（以及RTP时间戳时钟速率）为8000 Hz。
A voice activity detector (VAD) and comfort noise generator (CNG) algorithm in Annex B of G.729 is RECOMMENDED for digital simultaneous voice and data applications and can be used in conjunction with G.729 or G.729 Annex A. A G.729 or G.729 Annex A frame contains 10 octets, while the G.729 Annex B comfort noise frame occupies 2 octets. Receivers MUST accept comfort noise frames if restriction of their use has not been signaled. The MIME registration for G729 in RFC 3555 [7] specifies a parameter that MAY be used with MIME or SDP to restrict the use of comfort noise frames.
建议将G.729附录B中的语音活动检测器（VAD）和舒适性噪声发生器（CNG）算法用于数字同步语音和数据应用，并可与G.729或G.729附录A一起使用。A G.729或G.729附录A帧包含10个八位字节，而G.729附录B舒适性噪声帧占用2个八位字节。如果未发出使用限制信号，则接收器必须接受舒适噪音框架。RFC 3555[7]中G729的MIME注册指定了一个参数，该参数可与MIME或SDP一起使用，以限制舒适噪声帧的使用。
A G729 RTP packet may consist of zero or more G.729 or G.729 Annex A frames, followed by zero or one G.729 Annex B frames. The presence of a comfort noise frame can be deduced from the length of the RTP payload. The default packetization interval is 20 ms (two frames), but in some situations it may be desirable to send 10 ms packets. An
G729 RTP数据包可以由零个或多个G.729或G.729附录A帧组成，然后是零个或一个G.729附录B帧。舒适性噪声帧的存在可以从RTP有效载荷的长度推断出来。默认分组间隔为20毫秒（两帧），但在某些情况下，可能需要发送10毫秒的分组。一
example would be a transition from speech to comfort noise in the first 10 ms of the packet. For some applications, a longer packetization interval may be required to reduce the packet rate.
例如，在数据包的前10毫秒内，从语音过渡到舒适噪声。对于某些应用，可能需要更长的分组间隔来降低分组速率。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| L1 | L2 | L3 | P1 |P| C1 |
|0| | | | |0| |
| |0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4 5 6 7| |0 1 2 3 4|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C1 | S1 | GA1 | GB1 | P2 | C2 |
| 1 1 1| | | | | |
|5 6 7 8 9 0 1 2|0 1 2 3|0 1 2|0 1 2 3|0 1 2 3 4|0 1 2 3 4 5 6 7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C2 | S2 | GA2 | GB2 |
| 1 1 1| | | |
|8 9 0 1 2|0 1 2 3|0 1 2|0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| L1 | L2 | L3 | P1 |P| C1 |
|0| | | | |0| |
| |0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4 5 6 7| |0 1 2 3 4|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C1 | S1 | GA1 | GB1 | P2 | C2 |
| 1 1 1| | | | | |
|5 6 7 8 9 0 1 2|0 1 2 3|0 1 2|0 1 2 3|0 1 2 3 4|0 1 2 3 4 5 6 7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C2 | S2 | GA2 | GB2 |
| 1 1 1| | | |
|8 9 0 1 2|0 1 2 3|0 1 2|0 1 2 3|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: G.729 and G.729A bit packing
图4:G.729和G.729A钻头填料
The transmitted parameters of a G.729/G.729A 10-ms frame, consisting of 80 bits, are defined in Recommendation G.729, Table 8/G.729. The mapping of the these parameters is given below in Fig. 4. The diagrams show the bit packing in "network byte order", also known as big-endian order. The bits of each 32-bit word are numbered 0 to 31, with the most significant bit on the left and numbered 0. The octets (bytes) of each word are transmitted most significant octet first. The bits of each data field are numbered in the order as produced by the G.729 C code reference implementation.
建议G.729表8/G.729中定义了由80位组成的G.729/G.729A 10ms帧的传输参数。这些参数的映射如图4所示。图中显示了“网络字节顺序”中的位打包，也称为大端顺序。每个32位字的位编号为0到31，最高有效位在左边，编号为0。每个字的八位字节（字节）首先传输最重要的八位字节。每个数据字段的位按照G.729 C代码参考实现产生的顺序进行编号。
The packing of the G.729 Annex B comfort noise frame is shown in Fig. 5.
图5显示了G.729附录B舒适性噪声框架的包装。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| LSF1 | LSF2 | GAIN |R|
|S| | | |E|
|F| | | |S|
|0|0 1 2 3 4|0 1 2 3|0 1 2 3 4|V| RESV = Reserved (zero)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| LSF1 | LSF2 | GAIN |R|
|S| | | |E|
|F| | | |S|
|0|0 1 2 3 4|0 1 2 3|0 1 2 3 4|V| RESV = Reserved (zero)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: G.729 Annex B bit packing
图5:G.729附录B钻头填料
Annexes D and E to ITU-T Recommendation G.729 provide additional data rates. Because the data rate is not signaled in the bitstream, the different data rates are given distinct RTP encoding names which are mapped to distinct payload type numbers. G729D indicates a 6.4 kbit/s coding mode (G.729 Annex D, for momentary reduction in channel capacity), while G729E indicates an 11.8 kbit/s mode (G.729 Annex E, for improved performance with a wide range of narrow-band input signals, e.g., music and background noise). Annex E has two operating modes, backward adaptive and forward adaptive, which are signaled by the first two bits in each frame (the most significant two bits of the first octet).
ITU-T建议G.729的附件D和E提供了额外的数据速率。由于数据速率在比特流中不发信号，不同的数据速率被赋予不同的RTP编码名称，这些名称映射到不同的有效负载类型号。G729D表示6.4 kbit/s的编码模式（G.729附录D，用于瞬时降低信道容量），而G729E表示11.8 kbit/s模式（G.729附录E，用于改善宽带输入信号的性能，例如音乐和背景噪声）。附录E有两种工作模式，后向自适应和前向自适应，由每个帧中的前两位（第一个八位组的最高有效位）发出信号。
The voice activity detector (VAD) and comfort noise generator (CNG) algorithm specified in Annex B of G.729 may be used with Annex D and Annex E frames in addition to G.729 and G.729 Annex A frames. The algorithm details for the operation of Annexes D and E with the Annex B CNG are specified in G.729 Annexes F and G. Note that Annexes F and G do not introduce any new encodings. Receivers MUST accept comfort noise frames if restriction of their use has not been signaled. The MIME registrations for G729D and G729E in RFC 3555 [7] specify a parameter that MAY be used with MIME or SDP to restrict the use of comfort noise frames.
除G.729和G.729附录A框架外，G.729附录B中规定的语音活动检测器（VAD）和舒适噪声发生器（CNG）算法可与附录D和附录E框架一起使用。G.729附录F和G中规定了附录D和E与附录B CNG操作的算法细节。请注意，附录F和G未引入任何新编码。如果未发出使用限制信号，则接收器必须接受舒适噪音框架。RFC 3555[7]中G729D和G729E的MIME注册指定了一个参数，该参数可与MIME或SDP一起使用，以限制舒适噪声帧的使用。
For G729D, an RTP packet may consist of zero or more G.729 Annex D frames, followed by zero or one G.729 Annex B frame. Similarly, for G729E, an RTP packet may consist of zero or more G.729 Annex E frames, followed by zero or one G.729 Annex B frame. The presence of a comfort noise frame can be deduced from the length of the RTP payload.
对于G729D，RTP数据包可以由零个或多个G.729附录D帧组成，然后是零个或一个G.729附录B帧。类似地，对于G729E，RTP分组可以由零个或多个G.729附件E帧组成，然后是零个或一个G.729附件B帧。舒适性噪声帧的存在可以从RTP有效载荷的长度推断出来。
A single RTP packet must contain frames of only one data rate, optionally followed by one comfort noise frame. The data rate may be changed from packet to packet by changing the payload type number. G.729 Annexes D, E and H describe what the encoding and decoding algorithms must do to accommodate a change in data rate.
单个RTP数据包必须仅包含一个数据速率的帧，可选地后跟一个舒适噪声帧。通过改变有效载荷类型号，可以在分组之间改变数据速率。G.729附录D、E和H描述了编码和解码算法必须做什么以适应数据速率的变化。
For G729D, the bits of a G.729 Annex D frame are formatted as shown below in Fig. 6 (cf. Table D.1/G.729). The frame length is 64 bits.
对于G729D，G.729附录D帧的位的格式如图6所示（参见表D.1/G.729）。帧长度为64位。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| L1 | L2 | L3 | P1 | C1 |
|0| | | | | |
| |0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4 5 6 7|0 1 2 3 4 5|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C1 |S1 | GA1 | GB1 | P2 | C2 |S2 | GA2 | GB2 |
| | | | | | | | | |
|6 7 8|0 1|0 1 2|0 1 2|0 1 2 3|0 1 2 3 4 5 6 7 8|0 1|0 1 2|0 1 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| L1 | L2 | L3 | P1 | C1 |
|0| | | | | |
| |0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4 5 6 7|0 1 2 3 4 5|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C1 |S1 | GA1 | GB1 | P2 | C2 |S2 | GA2 | GB2 |
| | | | | | | | | |
|6 7 8|0 1|0 1 2|0 1 2|0 1 2 3|0 1 2 3 4 5 6 7 8|0 1|0 1 2|0 1 2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: G.729 Annex D bit packing
图6:G.729附录D钻头填料
The net bit rate for the G.729 Annex E algorithm is 11.8 kbit/s and a total of 118 bits are used. Two bits are appended as "don't care" bits to complete an integer number of octets for the frame. For G729E, the bits of a data frame are formatted as shown in the next two diagrams (cf. Table E.1/G.729). The fields for the G729E forward adaptive mode are packed as shown in Fig. 7.
G.729附录E算法的净比特率为11.8 kbit/s，总共使用118位。两个位被附加为“不关心”位，以完成该帧的整数个八位字节。对于G729E，数据帧的位的格式如下面两个图所示（参见表E.1/G.729）。G729E前向自适应模式的字段如图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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0|L| L1 | L2 | L3 | P1 |P| C0_1|
| |0| | | | |0| |
| | |0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4 5 6 7| |0 1 2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | C1_1 | C2_1 | C3_1 | C4_1 |
| | | | | |
|3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GA1 | GB1 | P2 | C0_2 | C1_2 | C2_2 |
| | | | | | |
|0 1 2|0 1 2 3|0 1 2 3 4|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | C3_2 | C4_2 | GA2 | GB2 |DC |
| | | | | | |
|6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2|0 1 2 3|0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0|L| L1 | L2 | L3 | P1 |P| C0_1|
| |0| | | | |0| |
| | |0 1 2 3 4 5 6|0 1 2 3 4|0 1 2 3 4|0 1 2 3 4 5 6 7| |0 1 2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | C1_1 | C2_1 | C3_1 | C4_1 |
| | | | | |
|3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GA1 | GB1 | P2 | C0_2 | C1_2 | C2_2 |
| | | | | | |
|0 1 2|0 1 2 3|0 1 2 3 4|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | C3_2 | C4_2 | GA2 | GB2 |DC |
| | | | | | |
|6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2|0 1 2 3|0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: G.729 Annex E (forward adaptive mode) bit packing
图7:G.729附录E（前向自适应模式）位封装
The fields for the G729E backward adaptive mode are packed as shown in Fig. 8.
G729E向后自适应模式的字段如图8所示进行压缩。
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 1| P1 |P| C0_1 | C1_1 |
| | |0| 1 1 1| |
| |0 1 2 3 4 5 6 7|0|0 1 2 3 4 5 6 7 8 9 0 1 2|0 1 2 3 4 5 6 7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | C2_1 | C3_1 | C4_1 |GA1 | GB1 |P2 |
| | | | | | | |
|8 9|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2|0 1 2 3|0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | C0_2 | C1_2 | C2_2 |
| | 1 1 1| | |
|2 3 4|0 1 2 3 4 5 6 7 8 9 0 1 2|0 1 2 3 4 5 6 7 8 9|0 1 2 3 4 5|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | C3_2 | C4_2 | GA2 | GB2 |DC |
| | | | | | |
|6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2|0 1 2 3|0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1| P1 |P| C0_1 | C1_1 |
| | |0| 1 1 1| |
| |0 1 2 3 4 5 6 7|0|0 1 2 3 4 5 6 7 8 9 0 1 2|0 1 2 3 4 5 6 7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | C2_1 | C3_1 | C4_1 |GA1 | GB1 |P2 |
| | | | | | | |
|8 9|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2|0 1 2 3|0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | C0_2 | C1_2 | C2_2 |
| | 1 1 1| | |
|2 3 4|0 1 2 3 4 5 6 7 8 9 0 1 2|0 1 2 3 4 5 6 7 8 9|0 1 2 3 4 5|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | C3_2 | C4_2 | GA2 | GB2 |DC |
| | | | | | |
|6|0 1 2 3 4 5 6|0 1 2 3 4 5 6|0 1 2|0 1 2 3|0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: G.729 Annex E (backward adaptive mode) bit packing
图8:G.729附录E（后向自适应模式）位打包
GSM (Group Speciale Mobile) denotes the European GSM 06.10 standard for full-rate speech transcoding, ETS 300 961, which is based on RPE/LTP (residual pulse excitation/long term prediction) coding at a rate of 13 kb/s [11,12,13]. The text of the standard can be obtained from:
GSM（Speciale Mobile集团）表示欧洲GSM 06.10全速率语音转码标准ETS 300 961，该标准基于13 kb/s速率的RPE/LTP（剩余脉冲激励/长期预测）编码[11,12,13]。本标准的文本可从以下网址获得：
ETSI (European Telecommunications Standards Institute) ETSI Secretariat: B.P.152 F-06561 Valbonne Cedex France Phone: +33 92 94 42 00 Fax: +33 93 65 47 16
ETSI（欧洲电信标准协会）ETSI秘书处：B.P.152 F-06561 Valbonne Cedex法国电话：+33 92 94 42 00传真：+33 93 65 47 16
Blocks of 160 audio samples are compressed into 33 octets, for an effective data rate of 13,200 b/s.
160个音频样本块压缩为33个八位字节，有效数据速率为13200 b/s。
The GSM standard (ETS 300 961) specifies the bit stream produced by the codec, but does not specify how these bits should be packed for transmission. The packetization specified here has subsequently been adopted in ETSI Technical Specification TS 101 318. Some software implementations of the GSM codec use a different packing than that specified here.
GSM标准（ETS 300 961）规定了编解码器产生的比特流，但未规定这些比特应如何打包以进行传输。ETSI技术规范TS 101 318随后采用了此处规定的包装。GSM编解码器的某些软件实现使用与此处指定的不同的包装。
field field name bits field field name bits
________________________________________________
1 LARc[0] 6 39 xmc[22] 3
2 LARc[1] 6 40 xmc[23] 3
3 LARc[2] 5 41 xmc[24] 3
4 LARc[3] 5 42 xmc[25] 3
5 LARc[4] 4 43 Nc[2] 7
6 LARc[5] 4 44 bc[2] 2
7 LARc[6] 3 45 Mc[2] 2
8 LARc[7] 3 46 xmaxc[2] 6
9 Nc[0] 7 47 xmc[26] 3
10 bc[0] 2 48 xmc[27] 3
11 Mc[0] 2 49 xmc[28] 3
12 xmaxc[0] 6 50 xmc[29] 3
13 xmc[0] 3 51 xmc[30] 3
14 xmc[1] 3 52 xmc[31] 3
15 xmc[2] 3 53 xmc[32] 3
16 xmc[3] 3 54 xmc[33] 3
17 xmc[4] 3 55 xmc[34] 3
18 xmc[5] 3 56 xmc[35] 3
19 xmc[6] 3 57 xmc[36] 3
20 xmc[7] 3 58 xmc[37] 3
21 xmc[8] 3 59 xmc[38] 3
22 xmc[9] 3 60 Nc[3] 7
23 xmc[10] 3 61 bc[3] 2
24 xmc[11] 3 62 Mc[3] 2
25 xmc[12] 3 63 xmaxc[3] 6
26 Nc[1] 7 64 xmc[39] 3
27 bc[1] 2 65 xmc[40] 3
28 Mc[1] 2 66 xmc[41] 3
29 xmaxc[1] 6 67 xmc[42] 3
30 xmc[13] 3 68 xmc[43] 3
31 xmc[14] 3 69 xmc[44] 3
32 xmc[15] 3 70 xmc[45] 3
33 xmc[16] 3 71 xmc[46] 3
34 xmc[17] 3 72 xmc[47] 3
35 xmc[18] 3 73 xmc[48] 3
36 xmc[19] 3 74 xmc[49] 3
37 xmc[20] 3 75 xmc[50] 3
38 xmc[21] 3 76 xmc[51] 3
field field name bits field field name bits
________________________________________________
1 LARc[0] 6 39 xmc[22] 3
2 LARc[1] 6 40 xmc[23] 3
3 LARc[2] 5 41 xmc[24] 3
4 LARc[3] 5 42 xmc[25] 3
5 LARc[4] 4 43 Nc[2] 7
6 LARc[5] 4 44 bc[2] 2
7 LARc[6] 3 45 Mc[2] 2
8 LARc[7] 3 46 xmaxc[2] 6
9 Nc[0] 7 47 xmc[26] 3
10 bc[0] 2 48 xmc[27] 3
11 Mc[0] 2 49 xmc[28] 3
12 xmaxc[0] 6 50 xmc[29] 3
13 xmc[0] 3 51 xmc[30] 3
14 xmc[1] 3 52 xmc[31] 3
15 xmc[2] 3 53 xmc[32] 3
16 xmc[3] 3 54 xmc[33] 3
17 xmc[4] 3 55 xmc[34] 3
18 xmc[5] 3 56 xmc[35] 3
19 xmc[6] 3 57 xmc[36] 3
20 xmc[7] 3 58 xmc[37] 3
21 xmc[8] 3 59 xmc[38] 3
22 xmc[9] 3 60 Nc[3] 7
23 xmc[10] 3 61 bc[3] 2
24 xmc[11] 3 62 Mc[3] 2
25 xmc[12] 3 63 xmaxc[3] 6
26 Nc[1] 7 64 xmc[39] 3
27 bc[1] 2 65 xmc[40] 3
28 Mc[1] 2 66 xmc[41] 3
29 xmaxc[1] 6 67 xmc[42] 3
30 xmc[13] 3 68 xmc[43] 3
31 xmc[14] 3 69 xmc[44] 3
32 xmc[15] 3 70 xmc[45] 3
33 xmc[16] 3 71 xmc[46] 3
34 xmc[17] 3 72 xmc[47] 3
35 xmc[18] 3 73 xmc[48] 3
36 xmc[19] 3 74 xmc[49] 3
37 xmc[20] 3 75 xmc[50] 3
38 xmc[21] 3 76 xmc[51] 3
Table 2: Ordering of GSM variables
表2:GSM变量的排序
Octet Bit 0 Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7
_____________________________________________________________________
0 1 1 0 1 LARc0.0 LARc0.1 LARc0.2 LARc0.3
1 LARc0.4 LARc0.5 LARc1.0 LARc1.1 LARc1.2 LARc1.3 LARc1.4 LARc1.5
2 LARc2.0 LARc2.1 LARc2.2 LARc2.3 LARc2.4 LARc3.0 LARc3.1 LARc3.2
3 LARc3.3 LARc3.4 LARc4.0 LARc4.1 LARc4.2 LARc4.3 LARc5.0 LARc5.1
4 LARc5.2 LARc5.3 LARc6.0 LARc6.1 LARc6.2 LARc7.0 LARc7.1 LARc7.2
5 Nc0.0 Nc0.1 Nc0.2 Nc0.3 Nc0.4 Nc0.5 Nc0.6 bc0.0
6 bc0.1 Mc0.0 Mc0.1 xmaxc00 xmaxc01 xmaxc02 xmaxc03 xmaxc04
7 xmaxc05 xmc0.0 xmc0.1 xmc0.2 xmc1.0 xmc1.1 xmc1.2 xmc2.0
8 xmc2.1 xmc2.2 xmc3.0 xmc3.1 xmc3.2 xmc4.0 xmc4.1 xmc4.2
9 xmc5.0 xmc5.1 xmc5.2 xmc6.0 xmc6.1 xmc6.2 xmc7.0 xmc7.1
10 xmc7.2 xmc8.0 xmc8.1 xmc8.2 xmc9.0 xmc9.1 xmc9.2 xmc10.0
11 xmc10.1 xmc10.2 xmc11.0 xmc11.1 xmc11.2 xmc12.0 xmc12.1 xcm12.2
12 Nc1.0 Nc1.1 Nc1.2 Nc1.3 Nc1.4 Nc1.5 Nc1.6 bc1.0
13 bc1.1 Mc1.0 Mc1.1 xmaxc10 xmaxc11 xmaxc12 xmaxc13 xmaxc14
14 xmax15 xmc13.0 xmc13.1 xmc13.2 xmc14.0 xmc14.1 xmc14.2 xmc15.0
15 xmc15.1 xmc15.2 xmc16.0 xmc16.1 xmc16.2 xmc17.0 xmc17.1 xmc17.2
16 xmc18.0 xmc18.1 xmc18.2 xmc19.0 xmc19.1 xmc19.2 xmc20.0 xmc20.1
17 xmc20.2 xmc21.0 xmc21.1 xmc21.2 xmc22.0 xmc22.1 xmc22.2 xmc23.0
18 xmc23.1 xmc23.2 xmc24.0 xmc24.1 xmc24.2 xmc25.0 xmc25.1 xmc25.2
19 Nc2.0 Nc2.1 Nc2.2 Nc2.3 Nc2.4 Nc2.5 Nc2.6 bc2.0
20 bc2.1 Mc2.0 Mc2.1 xmaxc20 xmaxc21 xmaxc22 xmaxc23 xmaxc24
21 xmaxc25 xmc26.0 xmc26.1 xmc26.2 xmc27.0 xmc27.1 xmc27.2 xmc28.0
22 xmc28.1 xmc28.2 xmc29.0 xmc29.1 xmc29.2 xmc30.0 xmc30.1 xmc30.2
23 xmc31.0 xmc31.1 xmc31.2 xmc32.0 xmc32.1 xmc32.2 xmc33.0 xmc33.1
24 xmc33.2 xmc34.0 xmc34.1 xmc34.2 xmc35.0 xmc35.1 xmc35.2 xmc36.0
25 Xmc36.1 xmc36.2 xmc37.0 xmc37.1 xmc37.2 xmc38.0 xmc38.1 xmc38.2
26 Nc3.0 Nc3.1 Nc3.2 Nc3.3 Nc3.4 Nc3.5 Nc3.6 bc3.0
27 bc3.1 Mc3.0 Mc3.1 xmaxc30 xmaxc31 xmaxc32 xmaxc33 xmaxc34
28 xmaxc35 xmc39.0 xmc39.1 xmc39.2 xmc40.0 xmc40.1 xmc40.2 xmc41.0
29 xmc41.1 xmc41.2 xmc42.0 xmc42.1 xmc42.2 xmc43.0 xmc43.1 xmc43.2
30 xmc44.0 xmc44.1 xmc44.2 xmc45.0 xmc45.1 xmc45.2 xmc46.0 xmc46.1
31 xmc46.2 xmc47.0 xmc47.1 xmc47.2 xmc48.0 xmc48.1 xmc48.2 xmc49.0
32 xmc49.1 xmc49.2 xmc50.0 xmc50.1 xmc50.2 xmc51.0 xmc51.1 xmc51.2
Octet Bit 0 Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7
_____________________________________________________________________
0 1 1 0 1 LARc0.0 LARc0.1 LARc0.2 LARc0.3
1 LARc0.4 LARc0.5 LARc1.0 LARc1.1 LARc1.2 LARc1.3 LARc1.4 LARc1.5
2 LARc2.0 LARc2.1 LARc2.2 LARc2.3 LARc2.4 LARc3.0 LARc3.1 LARc3.2
3 LARc3.3 LARc3.4 LARc4.0 LARc4.1 LARc4.2 LARc4.3 LARc5.0 LARc5.1
4 LARc5.2 LARc5.3 LARc6.0 LARc6.1 LARc6.2 LARc7.0 LARc7.1 LARc7.2
5 Nc0.0 Nc0.1 Nc0.2 Nc0.3 Nc0.4 Nc0.5 Nc0.6 bc0.0
6 bc0.1 Mc0.0 Mc0.1 xmaxc00 xmaxc01 xmaxc02 xmaxc03 xmaxc04
7 xmaxc05 xmc0.0 xmc0.1 xmc0.2 xmc1.0 xmc1.1 xmc1.2 xmc2.0
8 xmc2.1 xmc2.2 xmc3.0 xmc3.1 xmc3.2 xmc4.0 xmc4.1 xmc4.2
9 xmc5.0 xmc5.1 xmc5.2 xmc6.0 xmc6.1 xmc6.2 xmc7.0 xmc7.1
10 xmc7.2 xmc8.0 xmc8.1 xmc8.2 xmc9.0 xmc9.1 xmc9.2 xmc10.0
11 xmc10.1 xmc10.2 xmc11.0 xmc11.1 xmc11.2 xmc12.0 xmc12.1 xcm12.2
12 Nc1.0 Nc1.1 Nc1.2 Nc1.3 Nc1.4 Nc1.5 Nc1.6 bc1.0
13 bc1.1 Mc1.0 Mc1.1 xmaxc10 xmaxc11 xmaxc12 xmaxc13 xmaxc14
14 xmax15 xmc13.0 xmc13.1 xmc13.2 xmc14.0 xmc14.1 xmc14.2 xmc15.0
15 xmc15.1 xmc15.2 xmc16.0 xmc16.1 xmc16.2 xmc17.0 xmc17.1 xmc17.2
16 xmc18.0 xmc18.1 xmc18.2 xmc19.0 xmc19.1 xmc19.2 xmc20.0 xmc20.1
17 xmc20.2 xmc21.0 xmc21.1 xmc21.2 xmc22.0 xmc22.1 xmc22.2 xmc23.0
18 xmc23.1 xmc23.2 xmc24.0 xmc24.1 xmc24.2 xmc25.0 xmc25.1 xmc25.2
19 Nc2.0 Nc2.1 Nc2.2 Nc2.3 Nc2.4 Nc2.5 Nc2.6 bc2.0
20 bc2.1 Mc2.0 Mc2.1 xmaxc20 xmaxc21 xmaxc22 xmaxc23 xmaxc24
21 xmaxc25 xmc26.0 xmc26.1 xmc26.2 xmc27.0 xmc27.1 xmc27.2 xmc28.0
22 xmc28.1 xmc28.2 xmc29.0 xmc29.1 xmc29.2 xmc30.0 xmc30.1 xmc30.2
23 xmc31.0 xmc31.1 xmc31.2 xmc32.0 xmc32.1 xmc32.2 xmc33.0 xmc33.1
24 xmc33.2 xmc34.0 xmc34.1 xmc34.2 xmc35.0 xmc35.1 xmc35.2 xmc36.0
25 Xmc36.1 xmc36.2 xmc37.0 xmc37.1 xmc37.2 xmc38.0 xmc38.1 xmc38.2
26 Nc3.0 Nc3.1 Nc3.2 Nc3.3 Nc3.4 Nc3.5 Nc3.6 bc3.0
27 bc3.1 Mc3.0 Mc3.1 xmaxc30 xmaxc31 xmaxc32 xmaxc33 xmaxc34
28 xmaxc35 xmc39.0 xmc39.1 xmc39.2 xmc40.0 xmc40.1 xmc40.2 xmc41.0
29 xmc41.1 xmc41.2 xmc42.0 xmc42.1 xmc42.2 xmc43.0 xmc43.1 xmc43.2
30 xmc44.0 xmc44.1 xmc44.2 xmc45.0 xmc45.1 xmc45.2 xmc46.0 xmc46.1
31 xmc46.2 xmc47.0 xmc47.1 xmc47.2 xmc48.0 xmc48.1 xmc48.2 xmc49.0
32 xmc49.1 xmc49.2 xmc50.0 xmc50.1 xmc50.2 xmc51.0 xmc51.1 xmc51.2
Table 3: GSM payload format
表3:GSM有效载荷格式
In the GSM packing used by RTP, the bits SHALL be packed beginning from the most significant bit. Every 160 sample GSM frame is coded into one 33 octet (264 bit) buffer. Every such buffer begins with a 4 bit signature (0xD), followed by the MSB encoding of the fields of the frame. The first octet thus contains 1101 in the 4 most significant bits (0-3) and the 4 most significant bits of F1 (0-3) in the 4 least significant bits (4-7). The second octet contains the 2 least significant bits of F1 in bits 0-1, and F2 in bits 2-7, and so on. The order of the fields in the frame is described in Table 2.
在RTP使用的GSM包装中，应从最高有效位开始包装位。每160个采样GSM帧被编码到一个33八位组（264位）缓冲器中。每个这样的缓冲区都以4位签名（0xD）开始，然后是帧字段的MSB编码。因此，第一个八位组在4个最高有效位（0-3）中包含1101，在4个最低有效位（4-7）中包含F1（0-3）的4个最高有效位。第二个八位组包含位0-1中F1的2个最低有效位和位2-7中F2的2个最低有效位，依此类推。框架中字段的顺序如表2所示。
In the RTP encoding we have the bit pattern described in Table 3, where F.i signifies the ith bit of the field F, bit 0 is the most significant bit, and the bits of every octet are numbered from 0 to 7 from most to least significant.
在RTP编码中，我们有表3中描述的位模式，其中F.i表示字段F的第i位，位0是最高有效位，每个八位组的位从0到7从最高有效到最低有效进行编号。
GSM-EFR denotes GSM 06.60 enhanced full rate speech transcoding, specified in ETS 300 726 which is available from ETSI at the address given in Section 4.5.8. This codec has a frame length of 244 bits. For transmission in RTP, each codec frame is packed into a 31 octet (248 bit) buffer beginning with a 4-bit signature 0xC in a manner similar to that specified here for the original GSM 06.10 codec. The packing is specified in ETSI Technical Specification TS 101 318.
GSM-EFR表示ETS 300 726中规定的GSM 06.60增强全速率语音转码，可从ETSI获得，地址见第4.5.8节。此编解码器的帧长度为244位。对于RTP中的传输，每个编解码器帧以类似于此处为原始GSM 06.10编解码器指定的方式打包到以4位签名0xC开头的31八位组（248位）缓冲区中。ETSI技术规范TS 101 318中规定了包装。
L8 denotes linear audio data samples, using 8-bits of precision with an offset of 128, that is, the most negative signal is encoded as zero.
L8表示线性音频数据样本，使用偏移量为128的8位精度，也就是说，最负的信号编码为零。
L16 denotes uncompressed audio data samples, using 16-bit signed representation with 65,535 equally divided steps between minimum and maximum signal level, ranging from -32,768 to 32,767. The value is represented in two's complement notation and transmitted in network byte order (most significant byte first).
L16表示未压缩的音频数据样本，使用16位有符号表示，最小和最大信号电平之间有65535个等分步长，范围从-32768到32767。该值以2的补码表示，并以网络字节顺序传输（最高有效字节优先）。
The MIME registration for L16 in RFC 3555 [7] specifies parameters that MAY be used with MIME or SDP to indicate that analog pre-emphasis was applied to the signal before quantization or to indicate that a multiple-channel audio stream follows a different channel ordering convention than is specified in Section 4.1.
RFC 3555[7]中L16的MIME注册规定了可与MIME或SDP一起使用的参数，以指示量化前对信号应用了模拟预加重，或指示多声道音频流遵循与第4.1节规定不同的声道顺序约定。
LPC designates an experimental linear predictive encoding contributed by Ron Frederick, which is based on an implementation written by Ron Zuckerman posted to the Usenet group comp.dsp on June 26, 1992. The codec generates 14 octets for every frame. The framesize is set to 20 ms, resulting in a bit rate of 5,600 b/s.
LPC指定了一种由Ron Frederick贡献的实验性线性预测编码，该编码基于Ron Zuckerman于1992年6月26日发布到Usenet group comp.dsp的实现。编解码器为每帧生成14个八位字节。帧大小设置为20毫秒，导致比特率为5600 b/s。
MPA denotes MPEG-1 or MPEG-2 audio encapsulated as elementary streams. The encoding is defined in ISO standards ISO/IEC 11172-3 and 13818-3. The encapsulation is specified in RFC 2250 [14].
MPA表示封装为基本流的MPEG-1或MPEG-2音频。编码在ISO标准ISO/IEC 11172-3和13818-3中定义。RFC 2250[14]中规定了封装。
The encoding may be at any of three levels of complexity, called Layer I, II and III. The selected layer as well as the sampling rate and channel count are indicated in the payload. The RTP timestamp clock rate is always 90,000, independent of the sampling rate. MPEG-1 audio supports sampling rates of 32, 44.1, and 48 kHz (ISO/IEC 11172-3, section 1.1; "Scope"). MPEG-2 supports sampling rates of 16, 22.05 and 24 kHz. The number of samples per frame is fixed, but the frame size will vary with the sampling rate and bit rate.
编码可以是三个复杂级别中的任意一个，称为层I、II和III。所选层以及采样率和信道计数在有效载荷中指示。RTP时间戳时钟频率始终为90000，与采样率无关。MPEG-1音频支持32、44.1和48 kHz的采样率（ISO/IEC 11172-3，第1.1节，“范围”）。MPEG-2支持16、22.05和24 kHz的采样率。每帧的采样数是固定的，但帧大小将随采样率和比特率而变化。
The MIME registration for MPA in RFC 3555 [7] specifies parameters that MAY be used with MIME or SDP to restrict the selection of layer, channel count, sampling rate, and bit rate.
RFC 3555[7]中MPA的MIME注册指定了可与MIME或SDP一起使用的参数，以限制层、通道计数、采样率和比特率的选择。
PCMA and PCMU are specified in ITU-T Recommendation G.711. Audio data is encoded as eight bits per sample, after logarithmic scaling. PCMU denotes mu-law scaling, PCMA A-law scaling. A detailed description is given by Jayant and Noll [15]. Each G.711 octet SHALL be octet-aligned in an RTP packet. The sign bit of each G.711 octet SHALL correspond to the most significant bit of the octet in the RTP packet (i.e., assuming the G.711 samples are handled as octets on the host machine, the sign bit SHALL be the most significant bit of the octet as defined by the host machine format). The 56 kb/s and 48 kb/s modes of G.711 are not applicable to RTP, since PCMA and PCMU MUST always be transmitted as 8-bit samples.
PCMA和PCMU在ITU-T建议G.711中有规定。经过对数缩放后，音频数据被编码为每个样本8位。PCMU表示mu定律标度，PCMA表示A定律标度。Jayant和Noll[15]给出了详细说明。每个G.711八位字节应在RTP数据包中对齐。每个G.711八位字节的符号位应对应于RTP数据包中八位字节的最高有效位（即，假设G.711样本在主机上作为八位字节处理，符号位应为主机格式定义的八位字节的最高有效位）。G.711的56 kb/s和48 kb/s模式不适用于RTP，因为PCMA和PCMU必须始终作为8位样本传输。
See Section 4.1 regarding silence suppression.
关于静音抑制，见第4.1节。
The Electronic Industries Association (EIA) & Telecommunications Industry Association (TIA) standard IS-733, "TR45: High Rate Speech Service Option for Wideband Spread Spectrum Communications Systems", defines the QCELP audio compression algorithm for use in wireless CDMA applications. The QCELP CODEC compresses each 20 milliseconds of 8,000 Hz, 16-bit sampled input speech into one of four different size output frames: Rate 1 (266 bits), Rate 1/2 (124 bits), Rate 1/4 (54 bits) or Rate 1/8 (20 bits). For typical speech patterns, this results in an average output of 6.8 kb/s for normal mode and 4.7 kb/s for reduced rate mode. The packetization of the QCELP audio codec is described in [16].
电子工业协会（EIA）和电信工业协会（TIA）标准IS-733“TR45：宽带扩频通信系统的高速语音服务选项”，定义了无线CDMA应用中使用的QCELP音频压缩算法。QCELP编解码器将8000 Hz的每20毫秒16位采样输入语音压缩为四个不同大小的输出帧之一：速率1（266位）、速率1/2（124位）、速率1/4（54位）或速率1/8（20位）。对于典型的语音模式，正常模式的平均输出为6.8 kb/s，而低速模式的平均输出为4.7 kb/s。[16]中描述了QCELP音频编解码器的打包。
The redundant audio payload format "RED" is specified by RFC 2198 [17]. It defines a means by which multiple redundant copies of an audio packet may be transmitted in a single RTP stream. Each packet in such a stream contains, in addition to the audio data for that packetization interval, a (more heavily compressed) copy of the data from a previous packetization interval. This allows an approximation of the data from lost packets to be recovered upon decoding of a subsequent packet, giving much improved sound quality when compared with silence substitution for lost packets.
冗余音频有效负载格式“红色”由RFC 2198[17]规定。它定义了一种方法，通过该方法，可以在单个RTP流中传输音频分组的多个冗余副本。这样的流中的每个分组除了包含该分组化间隔的音频数据外，还包含来自先前分组化间隔的数据的（更严重压缩的）副本。这允许在解码后续分组时恢复来自丢失分组的数据的近似值，与丢失分组的静音替换相比，提供了更高的音质。
VDVI is a variable-rate version of DVI4, yielding speech bit rates of between 10 and 25 kb/s. It is specified for single-channel operation only. Samples are packed into octets starting at the most-significant bit. The last octet is padded with 1 bits if the last sample does not fill the last octet. This padding is distinct from the valid codewords. The receiver needs to detect the padding because there is no explicit count of samples in the packet.
VDVI是DVI4的可变速率版本，产生10到25 kb/s的语音比特率。它仅指定用于单通道操作。样本从最高有效位开始打包到八位字节中。如果最后一个样本未填充最后一个八位字节，则最后一个八位字节填充1位。此填充不同于有效的码字。接收器需要检测填充，因为数据包中没有明确的样本计数。
It uses the following encoding:
它使用以下编码：
DVI4 codeword VDVI bit pattern
_______________________________
0 00
1 010
2 1100
3 11100
4 111100
5 1111100
6 11111100
7 11111110
8 10
9 011
10 1101
11 11101
12 111101
13 1111101
14 11111101
15 11111111
DVI4 codeword VDVI bit pattern
_______________________________
0 00
1 010
2 1100
3 11100
4 111100
5 1111100
6 11111100
7 11111110
8 10
9 011
10 1101
11 11101
12 111101
13 1111101
14 11111101
15 11111111
The following sections describe the video encodings that are defined in this memo and give their abbreviated names used for identification. These video encodings and their payload types are listed in Table 5.
以下各节描述了本备忘录中定义的视频编码，并给出了用于识别的缩写名称。表5列出了这些视频编码及其有效负载类型。
All of these video encodings use an RTP timestamp frequency of 90,000 Hz, the same as the MPEG presentation time stamp frequency. This frequency yields exact integer timestamp increments for the typical 24 (HDTV), 25 (PAL), and 29.97 (NTSC) and 30 Hz (HDTV) frame rates and 50, 59.94 and 60 Hz field rates. While 90 kHz is the RECOMMENDED rate for future video encodings used within this profile, other rates MAY be used. However, it is not sufficient to use the video frame rate (typically between 15 and 30 Hz) because that does not provide adequate resolution for typical synchronization requirements when calculating the RTP timestamp corresponding to the NTP timestamp in an RTCP SR packet. The timestamp resolution MUST also be sufficient for the jitter estimate contained in the receiver reports.
所有这些视频编码都使用90000 Hz的RTP时间戳频率，与MPEG表示时间戳频率相同。该频率为典型的24（HDTV）、25（PAL）、29.97（NTSC）和30 Hz（HDTV）帧速率以及50、59.94和60 Hz场速率产生精确的整数时间戳增量。虽然90 kHz是此配置文件中使用的未来视频编码的建议速率，但也可以使用其他速率。然而，使用视频帧速率（通常在15和30hz之间）是不够的，因为在计算与RTCP SR分组中的NTP时间戳相对应的RTP时间戳时，这不能为典型的同步要求提供足够的分辨率。时间戳分辨率还必须足以满足接收器报告中包含的抖动估计。
For most of these video encodings, the RTP timestamp encodes the sampling instant of the video image contained in the RTP data packet. If a video image occupies more than one packet, the timestamp is the same on all of those packets. Packets from different video images are distinguished by their different timestamps.
对于大多数这些视频编码，RTP时间戳对包含在RTP数据分组中的视频图像的采样瞬间进行编码。如果视频图像占用多个数据包，则所有这些数据包上的时间戳都相同。来自不同视频图像的数据包通过其不同的时间戳进行区分。
Most of these video encodings also specify that the marker bit of the RTP header SHOULD be set to one in the last packet of a video frame and otherwise set to zero. Thus, it is not necessary to wait for a following packet with a different timestamp to detect that a new frame should be displayed.
这些视频编码中的大多数还指定RTP报头的标记位应在视频帧的最后一个分组中设置为1，否则设置为0。因此，不必等待具有不同时间戳的后续分组来检测应显示新帧。
The CELL-B encoding is a proprietary encoding proposed by Sun Microsystems. The byte stream format is described in RFC 2029 [18].
CELL-B编码是Sun Microsystems提出的专有编码。RFC 2029[18]中描述了字节流格式。
The encoding is specified in ISO Standards 10918-1 and 10918-2. The RTP payload format is as specified in RFC 2435 [19].
ISO标准10918-1和10918-2中规定了编码。RTP有效负载格式如RFC 2435[19]所述。
The encoding is specified in ITU-T Recommendation H.261, "Video codec for audiovisual services at p x 64 kbit/s". The packetization and RTP-specific properties are described in RFC 2032 [20].
ITU-T建议H.261“p x 64 kbit/s视听服务的视频编解码器”中规定了编码。RFC 2032[20]中描述了封装和RTP特定属性。
The encoding is specified in the 1996 version of ITU-T Recommendation H.263, "Video coding for low bit rate communication". The packetization and RTP-specific properties are described in RFC 2190 [21]. The H263-1998 payload format is RECOMMENDED over this one for use by new implementations.
1996年版本的ITU-T建议H.263“低比特率通信的视频编码”中规定了编码。RFC 2190[21]中描述了封装和RTP特定属性。建议新实施使用H263-1998有效负载格式，而不是此格式。
The encoding is specified in the 1998 version of ITU-T Recommendation H.263, "Video coding for low bit rate communication". The packetization and RTP-specific properties are described in RFC 2429 [22]. Because the 1998 version of H.263 is a superset of the 1996 syntax, this payload format can also be used with the 1996 version of H.263, and is RECOMMENDED for this use by new implementations. This payload format does not replace RFC 2190, which continues to be used by existing implementations, and may be required for backward compatibility in new implementations. Implementations using the new features of the 1998 version of H.263 MUST use the payload format described in RFC 2429.
1998年版本的ITU-T建议H.263“低比特率通信的视频编码”中规定了编码。RFC 2429[22]中描述了封装和RTP特定属性。由于H.263的1998版本是1996年语法的超集，因此此有效负载格式也可以与1996年版本的H.263一起使用，并建议新的实现使用此格式。此有效负载格式不会取代RFC 2190，现有实现仍在使用RFC 2190，新实现中的向后兼容性可能需要RFC 2190。使用1998版H.263新功能的实现必须使用RFC 2429中描述的有效负载格式。
MPV designates the use of MPEG-1 and MPEG-2 video encoding elementary streams as specified in ISO Standards ISO/IEC 11172 and 13818-2, respectively. The RTP payload format is as specified in RFC 2250 [14], Section 3.
MPV分别指定使用ISO标准ISO/IEC 11172和13818-2中规定的MPEG-1和MPEG-2视频编码基本流。RTP有效载荷格式如RFC 2250[14]第3节所述。
The MIME registration for MPV in RFC 3555 [7] specifies a parameter that MAY be used with MIME or SDP to restrict the selection of the type of MPEG video.
RFC 3555[7]中MPV的MIME注册指定了一个参数，该参数可与MIME或SDP一起使用，以限制MPEG视频类型的选择。
MP2T designates the use of MPEG-2 transport streams, for either audio or video. The RTP payload format is described in RFC 2250 [14], Section 2.
MP2T指定对音频或视频使用MPEG-2传输流。RTP有效载荷格式在RFC 2250[14]第2节中描述。
The encoding is implemented in the program `nv', version 4, developed at Xerox PARC by Ron Frederick. Further information is available from the author:
该编码在由Ron Frederick在施乐PARC开发的第4版“nv”程序中实现。可从作者处获得更多信息：
Ron Frederick Blue Coat Systems Inc. 650 Almanor Avenue Sunnyvale, CA 94085 United States EMail: ronf@bluecoat.com
Ron Frederick Blue Coat Systems Inc.加利福尼亚州桑尼维尔阿尔马诺大道650号，邮编94085美国电子邮件：ronf@bluecoat.com
Tables 4 and 5 define this profile's static payload type values for the PT field of the RTP data header. In addition, payload type values in the range 96-127 MAY be defined dynamically through a conference control protocol, which is beyond the scope of this document. For example, a session directory could specify that for a given session, payload type 96 indicates PCMU encoding, 8,000 Hz sampling rate, 2 channels. Entries in Tables 4 and 5 with payload type "dyn" have no static payload type assigned and are only used with a dynamic payload type. Payload type 2 was assigned to G721 in RFC 1890 and to its equivalent successor G726-32 in draft versions of this specification, but its use is now deprecated and that static payload type is marked reserved due to conflicting use for the payload formats G726-32 and AAL2-G726-32 (see Section 4.5.4). Payload type 13 indicates the Comfort Noise (CN) payload format specified in RFC 3389 [9]. Payload type 19 is marked "reserved" because some draft versions of this specification assigned that number to an earlier version of the comfort noise payload format. The payload type range 72-76 is marked "reserved" so that RTCP and RTP packets can be reliably distinguished (see Section "Summary of Protocol Constants" of the RTP protocol specification).
表4和表5为RTP数据头的PT字段定义了该配置文件的静态有效负载类型值。此外，范围96-127中的有效载荷类型值可以通过会议控制协议动态定义，这超出了本文档的范围。例如，会话目录可以指定对于给定会话，有效负载类型96表示PCMU编码，8000 Hz采样率，2个信道。表4和表5中有效负载类型为“dyn”的条目未分配静态有效负载类型，仅与动态有效负载类型一起使用。有效载荷类型2在RFC 1890中分配给G721，在本规范草案版本中分配给其等效的后续版本G726-32，但其使用现在已被弃用，并且由于有效载荷格式G726-32和AAL2-G726-32的使用冲突，该静态有效载荷类型被标记为保留（见第4.5.4节）。有效载荷类型13表示RFC 3389[9]中规定的舒适性噪声（CN）有效载荷格式。有效载荷类型19标记为“保留”，因为本规范的某些草案版本将该编号指定给舒适性噪声有效载荷格式的早期版本。有效负载类型范围72-76标记为“保留”，以便可以可靠地区分RTCP和RTP数据包（请参阅RTP协议规范的“协议常数摘要”一节）。
The payload types currently defined in this profile are assigned to exactly one of three categories or media types: audio only, video only and those combining audio and video. The media types are marked in Tables 4 and 5 as "A", "V" and "AV", respectively. Payload types of different media types SHALL NOT be interleaved or multiplexed within a single RTP session, but multiple RTP sessions MAY be used in parallel to send multiple media types. An RTP source MAY change payload types within the same media type during a session. See the section "Multiplexing RTP Sessions" of RFC 3550 for additional explanation.
此配置文件中当前定义的有效负载类型仅分配给三个类别或媒体类型中的一个：仅音频、仅视频和音频与视频相结合的类别或媒体类型。表4和表5分别将介质类型标记为“A”、“V”和“AV”。不同媒体类型的有效负载类型不得在单个RTP会话中交错或复用，但多个RTP会话可并行使用以发送多个媒体类型。RTP源可以在会话期间更改同一媒体类型内的有效负载类型。有关更多说明，请参阅RFC 3550的“多路传输RTP会话”一节。
PT encoding media type clock rate channels
name (Hz)
___________________________________________________
0 PCMU A 8,000 1
1 reserved A
2 reserved A
3 GSM A 8,000 1
4 G723 A 8,000 1
5 DVI4 A 8,000 1
6 DVI4 A 16,000 1
7 LPC A 8,000 1
8 PCMA A 8,000 1
9 G722 A 8,000 1
10 L16 A 44,100 2
11 L16 A 44,100 1
12 QCELP A 8,000 1
13 CN A 8,000 1
14 MPA A 90,000 (see text)
15 G728 A 8,000 1
16 DVI4 A 11,025 1
17 DVI4 A 22,050 1
18 G729 A 8,000 1
19 reserved A
20 unassigned A
21 unassigned A
22 unassigned A
23 unassigned A
dyn G726-40 A 8,000 1
dyn G726-32 A 8,000 1
dyn G726-24 A 8,000 1
dyn G726-16 A 8,000 1
dyn G729D A 8,000 1
dyn G729E A 8,000 1
dyn GSM-EFR A 8,000 1
dyn L8 A var. var.
dyn RED A (see text)
dyn VDVI A var. 1
PT encoding media type clock rate channels
name (Hz)
___________________________________________________
0 PCMU A 8,000 1
1 reserved A
2 reserved A
3 GSM A 8,000 1
4 G723 A 8,000 1
5 DVI4 A 8,000 1
6 DVI4 A 16,000 1
7 LPC A 8,000 1
8 PCMA A 8,000 1
9 G722 A 8,000 1
10 L16 A 44,100 2
11 L16 A 44,100 1
12 QCELP A 8,000 1
13 CN A 8,000 1
14 MPA A 90,000 (see text)
15 G728 A 8,000 1
16 DVI4 A 11,025 1
17 DVI4 A 22,050 1
18 G729 A 8,000 1
19 reserved A
20 unassigned A
21 unassigned A
22 unassigned A
23 unassigned A
dyn G726-40 A 8,000 1
dyn G726-32 A 8,000 1
dyn G726-24 A 8,000 1
dyn G726-16 A 8,000 1
dyn G729D A 8,000 1
dyn G729E A 8,000 1
dyn GSM-EFR A 8,000 1
dyn L8 A var. var.
dyn RED A (see text)
dyn VDVI A var. 1
Table 4: Payload types (PT) for audio encodings
表4：音频编码的有效负载类型（PT）
PT encoding media type clock rate
name (Hz)
_____________________________________________
24 unassigned V
25 CelB V 90,000
26 JPEG V 90,000
27 unassigned V
28 nv V 90,000
29 unassigned V
30 unassigned V
31 H261 V 90,000
32 MPV V 90,000
33 MP2T AV 90,000
34 H263 V 90,000
35-71 unassigned ?
72-76 reserved N/A N/A
77-95 unassigned ?
96-127 dynamic ?
dyn H263-1998 V 90,000
PT encoding media type clock rate
name (Hz)
_____________________________________________
24 unassigned V
25 CelB V 90,000
26 JPEG V 90,000
27 unassigned V
28 nv V 90,000
29 unassigned V
30 unassigned V
31 H261 V 90,000
32 MPV V 90,000
33 MP2T AV 90,000
34 H263 V 90,000
35-71 unassigned ?
72-76 reserved N/A N/A
77-95 unassigned ?
96-127 dynamic ?
dyn H263-1998 V 90,000
Table 5: Payload types (PT) for video and combined encodings
表5：视频和组合编码的有效负载类型（PT）
Session participants agree through mechanisms beyond the scope of this specification on the set of payload types allowed in a given session. This set MAY, for example, be defined by the capabilities of the applications used, negotiated by a conference control protocol or established by agreement between the human participants.
会话参与者通过超出本规范范围的机制就给定会话中允许的有效负载类型集达成一致。例如，该集合可以由所使用的应用程序的能力定义，由会议控制协议协商或由人类参与者之间的协议建立。
Audio applications operating under this profile SHOULD, at a minimum, be able to send and/or receive payload types 0 (PCMU) and 5 (DVI4). This allows interoperability without format negotiation and ensures successful negotiation with a conference control protocol.
在此配置文件下运行的音频应用程序应至少能够发送和/或接收有效负载类型0（PCMU）和5（DVI4）。这允许互操作性而无需格式协商，并确保与会议控制协议的协商成功。
Under special circumstances, it may be necessary to carry RTP in protocols offering a byte stream abstraction, such as TCP, possibly multiplexed with other data. The application MUST define its own method of delineating RTP and RTCP packets (RTSP [23] provides an example of such an encapsulation specification).
在特殊情况下，可能需要在提供字节流抽象的协议（如TCP）中承载RTP，该协议可能与其他数据多路复用。应用程序必须定义自己描述RTP和RTCP数据包的方法（RTSP[23]提供了此类封装规范的示例）。
As specified in the RTP protocol definition, RTP data SHOULD be carried on an even UDP port number and the corresponding RTCP packets SHOULD be carried on the next higher (odd) port number.
按照RTP协议定义中的规定，RTP数据应在偶数UDP端口号上传输，相应的RTCP数据包应在下一个更高（奇数）端口号上传输。
Applications operating under this profile MAY use any such UDP port pair. For example, the port pair MAY be allocated randomly by a session management program. A single fixed port number pair cannot be required because multiple applications using this profile are likely to run on the same host, and there are some operating systems that do not allow multiple processes to use the same UDP port with different multicast addresses.
在此配置文件下运行的应用程序可以使用任何此类UDP端口对。例如，端口对可以由会话管理程序随机分配。不需要单个固定端口号对，因为使用此配置文件的多个应用程序可能在同一主机上运行，并且有些操作系统不允许多个进程使用具有不同多播地址的同一UDP端口。
However, port numbers 5004 and 5005 have been registered for use with this profile for those applications that choose to use them as the default pair. Applications that operate under multiple profiles MAY use this port pair as an indication to select this profile if they are not subject to the constraint of the previous paragraph. Applications need not have a default and MAY require that the port pair be explicitly specified. The particular port numbers were chosen to lie in the range above 5000 to accommodate port number allocation practice within some versions of the Unix operating system, where port numbers below 1024 can only be used by privileged processes and port numbers between 1024 and 5000 are automatically assigned by the operating system.
但是，对于选择将端口号5004和5005用作默认对的应用程序，端口号5004和5005已注册为此配置文件使用。在多个配置文件下运行的应用程序可以使用此端口对作为选择此配置文件的指示，如果它们不受上一段的约束。应用程序不需要有默认值，可能需要显式指定端口对。选择的特定端口号在5000以上的范围内，以适应Unix操作系统某些版本中的端口号分配实践，其中1024以下的端口号只能由特权进程使用，1024到5000之间的端口号由操作系统自动分配。
This RFC revises RFC 1890. It is mostly backwards-compatible with RFC 1890 except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile. Since this profile may be used without using any of the payload formats listed here, the addition of new payload formats in this revision does not affect backwards compatibility. The changes are listed below, categorized into functional and non-functional changes.
本RFC修订了RFC 1890。除了由于找不到两个可互操作的实现而删除的函数外，它主要与RFC1890向后兼容。RFC 1890的新增内容编纂了本概要下有效载荷格式使用的现有实践。由于可以在不使用此处列出的任何有效负载格式的情况下使用此配置文件，因此在本版本中添加新的有效负载格式不会影响向后兼容性。变更如下所示，分为功能性变更和非功能性变更。
Functional changes:
功能变化：
o Section 11, "IANA Considerations" was added to specify the registration of the name for this profile. That appendix also references a new Section 3 "Registering Additional Encodings" which establishes a policy that no additional registration of static payload types for this profile will be made beyond those added in this revision and included in Tables 4 and 5. Instead, additional encoding names may be registered as MIME subtypes for binding to dynamic payload types. Non-normative references were added to RFC 3555 [7] where MIME subtypes for all the listed payload formats are registered, some with optional parameters for use of the payload formats.
o 增加了第11节“IANA注意事项”，以指定此配置文件的名称注册。该附录还引用了新的第3节“注册附加编码”，该节确立了一项政策，即除了本修订版中添加的以及表4和表5中包含的静态有效负载类型外，不会对该配置文件进行额外的静态有效负载类型注册。相反，可以将其他编码名称注册为MIME子类型，以便绑定到动态负载类型。RFC 3555[7]中添加了非规范性引用，其中注册了所有列出的有效负载格式的MIME子类型，其中一些具有用于有效负载格式的可选参数。
o Static payload types 4, 16, 17 and 34 were added to incorporate IANA registrations made since the publication of RFC 1890, along with the corresponding payload format descriptions for G723 and H263.
o 添加了静态有效负载类型4、16、17和34，以合并自RFC 1890发布以来进行的IANA注册，以及G723和H263的相应有效负载格式说明。
o Following working group discussion, static payload types 12 and 18 were added along with the corresponding payload format descriptions for QCELP and G729. Static payload type 13 was assigned to the Comfort Noise (CN) payload format defined in RFC 3389. Payload type 19 was marked reserved because it had been temporarily allocated to an earlier version of Comfort Noise present in some draft revisions of this document.
o 在工作组讨论之后，添加了静态有效负载类型12和18以及QCELP和G729的相应有效负载格式说明。静态有效载荷类型13被指定为RFC 3389中定义的舒适性噪声（CN）有效载荷格式。有效载荷类型19被标记为保留，因为它已临时分配给本文件某些修订草案中存在的早期版本的舒适性噪音。
o The payload format for G721 was renamed to G726-32 following the ITU-T renumbering, and the payload format description for G726 was expanded to include the -16, -24 and -40 data rates. Because of confusion regarding draft revisions of this document, some implementations of these G726 payload formats packed samples into octets starting with the most significant bit rather than the least significant bit as specified here. To partially resolve this incompatibility, new payload formats named AAL2-G726-16, -24, -32 and -40 will be specified in a separate document (see note in Section 4.5.4), and use of static payload type 2 is deprecated as explained in Section 6.
o 在ITU-T重新编号后，G721的有效载荷格式被重命名为G726-32，G726的有效载荷格式描述被扩展为包括-16、-24和-40数据速率。由于对本文件草案修订的混淆，这些G726有效负载格式的一些实现将样本打包成八位字节，从最高有效位开始，而不是此处指定的最低有效位。为了部分解决此不兼容问题，将在单独的文档中指定名为AAL2-G726-16、-24、-32和-40的新有效负载格式（参见第4.5.4节中的注释），并且如第6节所述，不推荐使用静态有效负载类型2。
o Payload formats G729D and G729E were added following the ITU-T addition of Annexes D and E to Recommendation G.729. Listings were added for payload formats GSM-EFR, RED, and H263-1998 published in other documents subsequent to RFC 1890. These additional payload formats are referenced only by dynamic payload type numbers.
o 有效载荷格式G729D和G729E是在ITU-T将附件D和E添加到建议G.729之后添加的。在RFC 1890之后的其他文件中，添加了有效载荷格式GSM-EFR、RED和H263-1998的列表。这些附加有效负载格式仅由动态有效负载类型编号引用。
o The descriptions of the payload formats for G722, G728, GSM, VDVI were expanded.
o 扩展了G722、G728、GSM和VDVI的有效载荷格式描述。
o The payload format for 1016 audio was removed and its static payload type assignment 1 was marked "reserved" because two interoperable implementations were not found.
o 1016音频的有效负载格式已删除，其静态有效负载类型分配1标记为“保留”，因为未找到两个可互操作的实现。
o Requirements for congestion control were added in Section 2.
o 第2节增加了拥塞控制要求。
o This profile follows the suggestion in the revised RTP spec that RTCP bandwidth may be specified separately from the session bandwidth and separately for active senders and passive receivers.
o 此配置文件遵循修订的RTP规范中的建议，即RTCP带宽可以与会话带宽分开指定，并且可以分别为主动发送方和被动接收方指定。
o The mapping of a user pass-phrase string into an encryption key was deleted from Section 2 because two interoperable implementations were not found.
o 用户密码短语字符串到加密密钥的映射已从第2节中删除，因为未找到两个可互操作的实现。
o The "quadrophonic" sample ordering convention for four-channel audio was removed to eliminate an ambiguity as noted in Section 4.1.
o 删除了四声道音频的“四声道”样本排序约定，以消除第4.1节所述的歧义。
Non-functional changes:
非功能性变化：
o In Section 4.1, it is now explicitly stated that silence suppression is allowed for all audio payload formats. (This has always been the case and derives from a fundamental aspect of RTP's design and the motivations for packet audio, but was not explicit stated before.) The use of comfort noise is also explained.
o 在第4.1节中，现在明确指出，所有音频有效负载格式都允许静音抑制。（这种情况一直存在，并且源于RTP设计的一个基本方面和分组音频的动机，但之前没有明确说明。）还解释了舒适性噪声的使用。
o In Section 4.1, the requirement level for setting of the marker bit on the first packet after silence for audio was changed from "is" to "SHOULD be", and clarified that the marker bit is set only when packets are intentionally not sent.
o 在第4.1节中，将音频静音后第一个数据包上标记位设置的要求级别从“是”更改为“应该”，并阐明仅当有意不发送数据包时才设置标记位。
o Similarly, text was added to specify that the marker bit SHOULD be set to one on the last packet of a video frame, and that video frames are distinguished by their timestamps.
o 类似地，添加文本以指定标记位应在视频帧的最后一个分组上设置为1，并且视频帧通过其时间戳来区分。
o RFC references are added for payload formats published after RFC 1890.
o RFC参考是为RFC 1890之后发布的有效负载格式添加的。
o The security considerations and full copyright sections were added.
o 增加了安全注意事项和完整的版权部分。
o According to Peter Hoddie of Apple, only pre-1994 Macintosh used the 22254.54 rate and none the 11127.27 rate, so the latter was dropped from the discussion of suggested sampling frequencies.
o 根据苹果公司的彼得·霍迪（Peter Hoddie）的说法，只有1994年以前的Macintosh使用22254.54的速率，而11127.27的速率则没有，因此后者被从建议采样频率的讨论中删除。
o Table 1 was corrected to move some values from the "ms/packet" column to the "default ms/packet" column where they belonged.
o 对表1进行了更正，将一些值从“ms/packet”列移到它们所属的“default ms/packet”列。
o Since the Interactive Multimedia Association ceased operations, an alternate resource was provided for a referenced IMA document.
o 由于交互式多媒体协会停止运作，为参考的IMA文件提供了替代资源。
o A note has been added for G722 to clarify a discrepancy between the actual sampling rate and the RTP timestamp clock rate.
o 已为G722添加注释，以澄清实际采样率与RTP时间戳时钟率之间的差异。
o Small clarifications of the text have been made in several places, some in response to questions from readers. In particular:
o 一些地方对文本作了一些小的澄清，有些地方是为了回答读者的问题。特别地：
- A definition for "media type" is given in Section 1.1 to allow the explanation of multiplexing RTP sessions in Section 6 to be more clear regarding the multiplexing of multiple media.
- 第1.1节给出了“媒体类型”的定义，以使第6节中关于多路复用RTP会话的解释更清楚地说明多路复用多个媒体。
- The explanation of how to determine the number of audio frames in a packet from the length was expanded.
- 关于如何根据长度确定数据包中的音频帧数的解释进行了扩展。
- More description of the allocation of bandwidth to SDES items is given.
- 给出了SDES项目带宽分配的更多描述。
- A note was added that the convention for the order of channels specified in Section 4.1 may be overridden by a particular encoding or payload format specification.
- 增加了一条注释，即第4.1节中规定的信道顺序约定可由特定编码或有效载荷格式规范覆盖。
- The terms MUST, SHOULD, MAY, etc. are used as defined in RFC 2119.
- 术语“必须”、“应该”、“可以”等按照RFC 2119中的定义使用。
o A second author for this document was added.
o 已添加此文档的第二位作者。
Implementations using the profile defined in this specification are subject to the security considerations discussed in the RTP specification [1]. This profile does not specify any different security services. The primary function of this profile is to list a set of data compression encodings for audio and video media.
使用本规范中定义的概要文件的实现受RTP规范[1]中讨论的安全注意事项的约束。此配置文件未指定任何不同的安全服务。此配置文件的主要功能是列出音频和视频媒体的一组数据压缩编码。
Confidentiality of the media streams is achieved by encryption. Because the data compression used with the payload formats described in this profile is applied end-to-end, encryption may be performed after compression so there is no conflict between the two operations.
媒体流的机密性是通过加密实现的。由于与此概要文件中描述的有效负载格式一起使用的数据压缩是端到端应用的，因此可以在压缩之后执行加密，因此两个操作之间没有冲突。
A potential denial-of-service threat exists for data encodings using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream which are complex to decode and cause the receiver to be overloaded.
使用压缩技术的数据编码存在潜在的拒绝服务威胁，这种压缩技术具有非均匀的接收端计算负载。攻击者可以向流中注入病理数据报，这些数据报解码复杂，并导致接收器过载。
As with any IP-based protocol, in some circumstances a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication MAY be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. In a multicast environment, source pruning is implemented in IGMPv3 (RFC 3376) [24] and in multicast routing protocols to allow a receiver to select which sources are allowed to reach it.
与任何基于IP的协议一样，在某些情况下，接收机可能仅仅因为接收了太多的数据包而过载，不管是想要的还是不想要的。网络层认证可用于丢弃来自不希望的源的数据包，但认证本身的处理成本可能过高。在多播环境中，源修剪在IGMPv3（RFC 3376）[24]和多播路由协议中实现，以允许接收器选择允许到达它的源。
The RTP specification establishes a registry of profile names for use by higher-level control protocols, such as the Session Description Protocol (SDP), RFC 2327 [6], to refer to transport methods. This profile registers the name "RTP/AVP".
RTP规范建立了一个配置文件名称注册表，供更高级别的控制协议使用，如会话描述协议（SDP），RFC 2327[6]，以引用传输方法。此配置文件注册名称“RTP/AVP”。
Section 3 establishes the policy that no additional registration of static RTP payload types for this profile will be made beyond those added in this document revision and included in Tables 4 and 5. IANA may reference that section in declining to accept any additional registration requests. In Tables 4 and 5, note that types 1 and 2 have been marked reserved and the set of "dyn" payload types included has been updated. These changes are explained in Sections 6 and 9.
第3节确立了一项政策，即除了本文件修订版中添加并包含在表4和表5中的静态RTP有效负载类型外，不会对该概要文件的静态RTP有效负载类型进行额外注册。IANA可在拒绝接受任何其他注册请求时参考该部分。在表4和表5中，请注意类型1和2已标记为保留，并且包含的“dyn”有效负载类型集已更新。第6节和第9节解释了这些变化。
[1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
[1] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 35502003年7月。
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Apple Computer, "Audio Interchange File Format AIFF-C", August 1991. (also ftp://ftp.sgi.com/sgi/aiff-c.9.26.91.ps.Z).
[3] 苹果计算机，“音频交换文件格式AIFF-C”，1991年8月。（也ftp://ftp.sgi.com/sgi/aiff-c.9.26.91.ps.Z).
[4] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[4] Braden，R.，Clark，D.和S.Shenker，“互联网体系结构中的综合服务：概述”，RFC16331994年6月。
[5] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[5] Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[6] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[6] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[7] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Types", RFC 3555, July 2003.
[7] Casner，S.和P.Hoschka，“RTP有效载荷类型的MIME类型注册”，RFC 3555，2003年7月。
[8] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
[8] Freed，N.，Klensin，J.和J.Postel，“多用途互联网邮件扩展（MIME）第四部分：注册程序”，BCP 13，RFC 2048，1996年11月。
[9] Zopf, R., "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)", RFC 3389, September 2002.
[9] Zopf，R.，“舒适噪声（CN）的实时传输协议（RTP）有效载荷”，RFC 3389，2002年9月。
[10] Deleam, D. and J.-P. Petit, "Real-time implementations of the recent ITU-T low bit rate speech coders on the TI TMS320C54X DSP: results, methodology, and applications", in Proc. of International Conference on Signal Processing, Technology, and Applications (ICSPAT) , (Boston, Massachusetts), pp. 1656--1660, October 1996.
[10] Deleam，D.和J.-P.Petit，“最新ITU-T低比特率语音编码器在TI TMS320C54X DSP上的实时实现：结果、方法和应用”，摘自Proc。国际信号处理、技术和应用会议（ICSPAT）（马萨诸塞州波士顿），第1656-1660页，1996年10月。
[11] Mouly, M. and M.-B. Pautet, The GSM system for mobile communications Lassay-les-Chateaux, France: Europe Media Duplication, 1993.
[11] Mouly，M.和M.-B.Pautet，《移动通信GSM系统拉赛城堡》，法国：欧洲媒体复制，1993年。
[12] Degener, J., "Digital Speech Compression", Dr. Dobb's Journal, December 1994.
[12] Degener，J.，“数字语音压缩”，Dobb博士期刊，1994年12月。
[13] Redl, S., Weber, M. and M. Oliphant, An Introduction to GSM Boston: Artech House, 1995.
[13] 雷德尔，S.，韦伯，M.和M.奥列芬特，《波士顿GSM导论：阿泰奇之家》，1995年。
[14] Hoffman, D., Fernando, G., Goyal, V. and M. Civanlar, "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998.
[14] Hoffman，D.，Fernando，G.，Goyal，V.和M.Civanlar，“MPEG1/MPEG2视频的RTP有效载荷格式”，RFC 2250，1998年1月。
[15] Jayant, N. and P. Noll, Digital Coding of Waveforms--Principles and Applications to Speech and Video Englewood Cliffs, New Jersey: Prentice-Hall, 1984.
[15] Jayant，N.和P.Noll，《波形的数字编码——语音和视频的原理和应用》，新泽西州恩格伍德悬崖：普伦蒂斯大厅，1984年。
[16] McKay, K., "RTP Payload Format for PureVoice(tm) Audio", RFC 2658, August 1999.
[16] McKay，K.，“PureVoice（tm）音频的RTP有效载荷格式”，RFC 2658，1999年8月。
[17] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J.-C., Vega-Garcia, A. and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[17] 帕金斯，C.，库维拉斯，I.，霍德森，O.，哈德曼，V.，汉德利，M.，博洛特，J.-C.，维加·加西亚，A.和S.福斯·帕里斯，“冗余音频数据的RTP有效载荷”，RFC 21981997年9月。
[18] Speer, M. and D. Hoffman, "RTP Payload Format of Sun's CellB Video Encoding", RFC 2029, October 1996.
[18] Speer，M.和D.Hoffman，“Sun CellB视频编码的RTP有效载荷格式”，RFC 2029，1996年10月。
[19] Berc, L., Fenner, W., Frederick, R., McCanne, S. and P. Stewart, "RTP Payload Format for JPEG-Compressed Video", RFC 2435, October 1998.
[19] Berc，L.，Fenner，W.，Frederick，R.，McCanne，S.和P.Stewart，“JPEG压缩视频的RTP有效载荷格式”，RFC 2435，1998年10月。
[20] Turletti, T. and C. Huitema, "RTP Payload Format for H.261 Video Streams", RFC 2032, October 1996.
[20] Turletti，T.和C.Huitema，“H.261视频流的RTP有效载荷格式”，RFC 2032，1996年10月。
[21] Zhu, C., "RTP Payload Format for H.263 Video Streams", RFC 2190, September 1997.
[21] 朱，C，“H.263视频流的RTP有效载荷格式”，RFC 2190，1997年9月。
[22] Bormann, C., Cline, L., Deisher, G., Gardos, T., Maciocco, C., Newell, D., Ott, J., Sullivan, G., Wenger, S. and C. Zhu, "RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)", RFC 2429, October 1998.
[22] Bormann，C.，Cline，L.，Deisher，G.，Gardos，T.，Maciocco，C.，Newell，D.，Ott，J.，Sullivan，G.，Wenger，S.和C.Zhu，“1998版ITU-T Rec.H.263视频（H.263+）的RTP有效载荷格式”，RFC 24291998年10月。
[23] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[23] Schulzrinne，H.，Rao，A.和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[24] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[24] Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
Note: Several sections below refer to the ITU-T Software Tool Library (STL). It is available from the ITU Sales Service, Place des Nations, CH-1211 Geneve 20, Switzerland (also check http://www.itu.int). The ITU-T STL is covered by a license defined in ITU-T Recommendation G.191, "Software tools for speech and audio coding standardization".
注：以下几节涉及ITU-T软件工具库（STL）。可从ITU销售服务处获得，地址：瑞士日内瓦20号CH-1211国家广场（另请参阅http://www.itu.int). ITU-T STL包含在ITU-T建议G.191“语音和音频编码标准化软件工具”中定义的许可证中。
DVI4
DVI4
An archived copy of the document IMA Recommended Practices for Enhancing Digital Audio Compatibility in Multimedia Systems (version 3.0), which describes the IMA ADPCM algorithm, is available at:
描述IMA ADPCM算法的文件《IMA增强多媒体系统中数字音频兼容性的推荐做法》（3.0版）的存档副本可从以下网址获得：
http://www.cs.columbia.edu/~hgs/audio/dvi/
http://www.cs.columbia.edu/~hgs/audio/dvi/
An implementation is available from Jack Jansen at
Jack Jansen提供了一个实现，网址为
ftp://ftp.cwi.nl/local/pub/audio/adpcm.shar
ftp://ftp.cwi.nl/local/pub/audio/adpcm.shar
G722
G722
An implementation of the G.722 algorithm is available as part of the ITU-T STL, described above.
G.722算法的实现作为上述ITU-T STL的一部分提供。
G723
G723
The reference C code implementation defining the G.723.1 algorithm and its Annexes A, B, and C are available as an integral part of Recommendation G.723.1 from the ITU Sales Service, address listed above. Both the algorithm and C code are covered by a specific license. The ITU-T Secretariat should be contacted to obtain such licensing information.
定义G.723.1算法的参考C代码实现及其附录A、B和C可作为建议G.723.1的组成部分从ITU销售服务处获得，地址如上所列。算法和C代码都包含在特定的许可证中。应联系ITU-T秘书处以获取此类许可信息。
G726
G726
G726 is specified in the ITU-T Recommendation G.726, "40, 32, 24, and 16 kb/s Adaptive Differential Pulse Code Modulation (ADPCM)". An implementation of the G.726 algorithm is available as part of the ITU-T STL, described above.
ITU-T建议G.726“40、32、24和16 kb/s自适应差分脉冲编码调制（ADPCM）”中规定了G726。G.726算法的实现作为上述ITU-T STL的一部分提供。
G729
G729
The reference C code implementation defining the G.729 algorithm and its Annexes A through I are available as an integral part of Recommendation G.729 from the ITU Sales Service, listed above. Annex I contains the integrated C source code for all G.729 operating modes. The G.729 algorithm and associated C code are covered by a specific license. The contact information for obtaining the license is available from the ITU-T Secretariat.
定义G.729算法的参考C代码实现及其附录A至I作为建议G.729的组成部分，可从ITU销售服务处获得，如上所列。附录I包含所有G.729操作模式的集成C源代码。G.729算法和相关的C代码包含在特定的许可证中。获得许可证的联系信息可从ITU-T秘书处获得。
GSM
GSM
A reference implementation was written by Carsten Bormann and Jutta Degener (then at TU Berlin, Germany). It is available at
Carsten Bormann和Jutta Degener（当时在德国柏林大学）编写了一个参考实现。可于
http://www.dmn.tzi.org/software/gsm/
http://www.dmn.tzi.org/software/gsm/
Although the RPE-LTP algorithm is not an ITU-T standard, there is a C code implementation of the RPE-LTP algorithm available as part of the ITU-T STL. The STL implementation is an adaptation of the TU Berlin version.
尽管RPE-LTP算法不是ITU-T标准，但作为ITU-T STL的一部分，RPE-LTP算法有一个C代码实现。STL实现是TU Berlin版本的改编。
LPC
LPC
An implementation is available at
可在以下网址获得实施：
ftp://parcftp.xerox.com/pub/net-research/lpc.tar.Z
ftp://parcftp.xerox.com/pub/net-research/lpc.tar.Z
PCMU, PCMA
PCMU，PCMA
An implementation of these algorithms is available as part of the ITU-T STL, described above.
这些算法的实现作为上述ITU-T STL的一部分提供。
The comments and careful review of Simao Campos, Richard Cox and AVT Working Group participants are gratefully acknowledged. The GSM description was adopted from the IMTC Voice over IP Forum Service Interoperability Implementation Agreement (January 1997). Fred Burg and Terry Lyons helped with the G.729 description.
感谢Simao Campos、Richard Cox和AVT工作组参与者的评论和仔细审查。GSM描述采用了IMTC IP语音论坛服务互操作性实施协议（1997年1月）。弗雷德·伯格和特里·莱昂斯帮助完成了G.729的描述。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
Henning Schulzrinne Department of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 United States
美国纽约州纽约市阿姆斯特丹大道1214号哥伦比亚大学计算机科学系
EMail: schulzrinne@cs.columbia.edu
EMail: schulzrinne@cs.columbia.edu
Stephen L. Casner Packet Design 3400 Hillview Avenue, Building 3 Palo Alto, CA 94304 United States
Stephen L.Casner Packet Design美国加利福尼亚州帕洛阿尔托市Hillview大道3400号3号楼，邮编94304
EMail: casner@acm.org
EMail: casner@acm.org
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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编辑功能的资金目前由互联网协会提供。