Network Working Group P. Luthi
Request for Comments: 5577 Tandberg
Obsoletes: 3047 R. Even
Category: Standards Track Gesher Erove Ltd
July 2009
Network Working Group P. Luthi
Request for Comments: 5577 Tandberg
Obsoletes: 3047 R. Even
Category: Standards Track Gesher Erove Ltd
July 2009
RTP Payload Format for ITU-T Recommendation G.722.1
ITU-T建议G.722.1的RTP有效载荷格式
Abstract
摘要
International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec. This document describes the payload format for including G.722.1-generated bit streams within an RTP packet. The document also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support G.722.1 audio codec.
国际电信联盟（ITU-T）建议G.722.1是一种宽带音频编解码器。本文档描述了在RTP数据包中包含G.722.1生成的比特流的有效负载格式。本文档还描述了支持G.722.1音频编解码器所需的会话描述协议（SDP）参数的语法和语义。
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
3. RTP Usage for G.722.1 ...........................................3
3.1. RTP G.722.1 Header Fields ..................................3
3.2. RTP Payload Format for G.722.1 .............................3
3.3. Multiple G.722.1 Frames in an RTP Packet ...................5
3.4. Computing the Number of G.722.1 Frames .....................6
4. IANA Considerations .............................................6
4.1. Media Type Registration ....................................6
4.1.1. Registration of Media Type audio/G7221 ..............6
5. SDP Parameters ..................................................8
5.1. Usage with the SDP Offer/Answer Model ......................8
6. Security Considerations .........................................8
7. Changes from RFC 3047 ...........................................9
8. Acknowledgments .................................................9
9. References ......................................................9
9.1. Normative References .......................................9
9.2. Informative References ....................................10
1. Introduction ....................................................2
2. Terminology .....................................................3
3. RTP Usage for G.722.1 ...........................................3
3.1. RTP G.722.1 Header Fields ..................................3
3.2. RTP Payload Format for G.722.1 .............................3
3.3. Multiple G.722.1 Frames in an RTP Packet ...................5
3.4. Computing the Number of G.722.1 Frames .....................6
4. IANA Considerations .............................................6
4.1. Media Type Registration ....................................6
4.1.1. Registration of Media Type audio/G7221 ..............6
5. SDP Parameters ..................................................8
5.1. Usage with the SDP Offer/Answer Model ......................8
6. Security Considerations .........................................8
7. Changes from RFC 3047 ...........................................9
8. Acknowledgments .................................................9
9. References ......................................................9
9.1. Normative References .......................................9
9.2. Informative References ....................................10
ITU-T G.722.1 [ITU.G7221] is a low-complexity coder; it compresses 50 Hz - 14 kHz audio signals into one of the following bit rates: 24 kbit/s, 32 kbit/s, or 48 kbit/s.
ITU-T G.722.1[ITU.G7221]是一种低复杂度编码器；它将50 Hz-14 kHz音频信号压缩为以下比特率之一：24 kbit/s、32 kbit/s或48 kbit/s。
The coder may be used for speech, music, and other types of audio.
编码器可用于语音、音乐和其他类型的音频。
Some of the applications for which this coder is suitable are:
本编码器适用的一些应用包括：
o Real-time communications such as videoconferencing and telephony
o 实时通信，如视频会议和电话
o Streaming audio
o 流式音频
o Archival and messaging
o 存档和消息传递
ITU-T G.722.1 [ITU.G7221] uses 20-ms frames and a sampling rate clock of 16 kHz or 32kHz. The encoding and decoding algorithm can change the bit rate at any 20-ms frame boundary, but no bit rate change notification is provided in-band with the bit stream.
ITU-T G.722.1[ITU.G7221]使用20ms帧和16kHz或32kHz的采样率时钟。编码和解码算法可以在任何20ms帧边界处改变比特率，但是在比特流所在的频带内不提供比特率改变通知。
For any given bit rate, the number of bits in a frame is a constant. Within this fixed frame, G.722.1 uses variable-length coding (e.g., Huffman coding) to represent most of the encoded parameters. All variable-length codes are transmitted in order from the leftmost bit (most significant bit -- MSB) to the rightmost bit (least significant bit -- LSB), see [ITU.G7221] for more details.
对于任何给定的比特率，帧中的比特数都是常数。在该固定帧内，G.722.1使用可变长度编码（例如，哈夫曼编码）来表示大多数编码参数。所有可变长度代码都是按从最左边的位（最高有效位--MSB）到最右边的位（最低有效位--LSB）的顺序传输的，有关详细信息，请参见[ITU.G7221]。
The ITU-T standardized bit rates for G.722.1 are 24 kbit/s or 32kbit/s at 16 Khz sample rate, and 24 kbit/s, 32 kbit/s, or 48 kbit/s at 32 Khz sample rate. However, the coding algorithm itself has the capability to run at any user-specified bit rate (not just 24, 32, and 48 kbit/s) while maintaining an audio bandwidth of 50 Hz to 14 kHz. This rate change is accomplished by a linear scaling of the codec operation, resulting in frames with size in bits equal to 1/50 of the corresponding bit rate.
G.722.1的ITU-T标准化比特率在16 Khz采样率下为24 kbit/s或32 kbit/s，在32 Khz采样率下为24 kbit/s、32 kbit/s或48 kbit/s。然而，编码算法本身能够以任何用户指定的比特率（不仅仅是24、32和48 kbit/s）运行，同时保持50 Hz到14 kHz的音频带宽。这种速率变化是通过编解码器操作的线性缩放来实现的，从而产生以比特为单位的帧大小等于相应比特率的1/50。
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 [RFC2119] and indicate requirement levels for compliant RTP implementations.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的描述进行解释，并指出符合RTP实施的要求级别。
The RTP header is defined in the RTP specification [RFC3550]. This section defines how fields in the RTP header are used.
RTP头在RTP规范[RFC3550]中定义。本节定义如何使用RTP标头中的字段。
Payload Type (PT): The assignment of an RTP payload type for this packet format is outside the scope of this document; it is specified by the RTP profile under which this payload format is used, or it is signaled dynamically out-of-band (e.g., using SDP).
有效负载类型（PT）：此数据包格式的RTP有效负载类型的分配不在本文档的范围内；它由RTP配置文件指定，在RTP配置文件下使用此有效负载格式，或者在带外动态发送信号（例如，使用SDP）。
Marker (M) bit: The M bit is set to zero.
标记（M）位：M位设置为零。
Extension (X) bit: Defined by the RTP profile used.
扩展（X）位：由使用的RTP配置文件定义。
Timestamp: A 32-bit word that corresponds to the sampling instant for the first frame in the RTP packet. The sampling frequency can be 16 Khz or 32 Khz. The RTP timestamp clock frequency of 32 Khz SHOULD be used unless only an RTP stream sampled at 16 Khz is going to be sent.
时间戳：与RTP数据包中第一帧的采样瞬间相对应的32位字。采样频率可以是16 Khz或32 Khz。除非仅发送以16 Khz采样的RTP流，否则应使用32 Khz的RTP时间戳时钟频率。
The RTP payload for G.722.1 has the format shown in Figure 1. No additional header fields specific to this payload format are required.
G.722.1的RTP有效负载的格式如图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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+ one or more frames of G.722.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+ one or more frames of G.722.1 |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RTP payload for G.722.1.
图1:G.722.1的RTP有效载荷。
Because bit rate is not signaled in-band, a separate out-of-band method is REQUIRED to indicate the bit rate (see Section 5 for an example of signaling bit rate information using SDP). For the payload format specified here, the bit rate MUST remain constant for a particular payload type value. An application MAY switch bit rates and clock rates from packet to packet by defining different payload type values and switching between them.
由于比特率不在带内发送信号，因此需要单独的带外方法来指示比特率（关于使用SDP发送比特率信息的示例，请参见第5节）。对于此处指定的有效负载格式，特定有效负载类型值的比特率必须保持恒定。应用程序可以通过定义不同的有效负载类型值并在它们之间切换来在分组之间切换比特率和时钟率。
The use of Huffman coding means that it is not possible to identify the various encoded parameters/fields contained within the bit stream without first completely decoding the entire frame. For the purposes of packetizing the bit stream in RTP, it is only necessary to consider the sequence of bits as output by the G.722.1 encoder and to present the same sequence to the decoder. The payload format described here maintains this sequence.
哈夫曼编码的使用意味着在没有首先对整个帧进行完全解码的情况下，不可能识别包含在比特流中的各种编码参数/字段。为了打包RTP中的比特流，仅需要考虑由G.722.1编码器输出的比特序列，并将相同的序列呈现给解码器。此处描述的有效负载格式维护此序列。
When operating at 24 kbit/s, 480 bits (60 octets) are produced per frame. When operating at 32 kbit/s, 640 bits (80 octets) are produced per frame. When operating at 48 kbit/s, 960 bits (120 octets) are produced per frame. Thus, all three bit rates allow for octet alignment without the need for padding bits.
当以24 kbit/s的速度运行时，每帧产生480位（60个八位字节）。当以32 kbit/s运行时，每帧产生640位（80个八位字节）。当以48 kbit/s运行时，每帧产生960位（120个八位字节）。因此，所有三个比特率都允许八位组对齐，而不需要填充比特。
Figure 2 illustrates how the G.722.1 bit stream MUST be mapped into an octet-aligned RTP payload.
图2说明了G.722.1比特流必须如何映射到八位组对齐的RTP有效负载。
first bit last bit
transmitted transmitted
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ sequence of bits (480, 640, or 960) generated by the |
| G.722.1 encoder for transmission |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
first bit last bit
transmitted transmitted
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ sequence of bits (480, 640, or 960) generated by the |
| G.722.1 encoder for transmission |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| | | ... | |
| | | | |
| | | | |
| | | ... | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+
|MSB... LSB|MSB... LSB| |MSB... LSB|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+
RTP RTP RTP
octet 1 octet 2 octet
60, 80, 120
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+
|MSB... LSB|MSB... LSB| |MSB... LSB|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+
RTP RTP RTP
octet 1 octet 2 octet
60, 80, 120
Figure 2: The G.722.1 encoder bit stream is split into a sequence of octets (60, 80, or 120 depending on the bit rate), and each octet is in turn mapped into an RTP octet.
图2:G.722.1编码器比特流被分割成一个八位组序列（60、80或120，取决于比特率），每个八位组依次映射成一个RTP八位组。
When operating at non-standard rates, the payload format MUST follow the guidelines illustrated in Figure 2. It is RECOMMENDED that values in the range 16000 to 48000 be used. Non-standard rates MUST have a value that is a multiple of 400 (this maintains octet alignment and does not then require (undefined) padding bits for each frame if not octet aligned). For example, a bit rate of 16.4 kbit/s will result in a frame of size 328 bits or 41 octets, which is mapped into RTP per Figure 2.
当以非标准速率运行时，有效负载格式必须遵循图2所示的准则。建议使用16000至48000范围内的值。非标准速率的值必须是400的倍数（这将保持八位字节对齐，如果没有八位字节对齐，则不需要（未定义的）每个帧的填充位）。例如，16.4 kbit/s的比特率将产生大小为328位或41个八位字节的帧，如图2所示映射到RTP。
A sender may include more than one consecutive G.722.1 frame in a single RTP packet.
发送方可以在单个RTP分组中包括多个连续的G.722.1帧。
Senders have the following additional restrictions:
发件人具有以下附加限制：
o Sender SHOULD NOT include more G.722.1 frames in a single RTP packet than will fit in the MTU of the RTP transport protocol.
o 发送方在单个RTP数据包中包含的G.722.1帧不应超过RTP传输协议MTU中所能容纳的数量。
o All frames contained in a single RTP packet MUST be of the same length and sampled at the same clock rate. They MUST have the same bit rate (octets per frame).
o 单个RTP数据包中包含的所有帧必须具有相同的长度并以相同的时钟速率采样。它们必须具有相同的比特率（每帧八位字节）。
o Frames MUST NOT be split between RTP packets.
o 帧不能在RTP数据包之间分割。
It is RECOMMENDED that the number of frames contained within an RTP packet be consistent with the application. For example, in a telephony application where delay is important, the fewer frames per packet, the lower the delay; whereas for a delay-insensitive streaming or messaging application, many frames per packet would be acceptable.
建议RTP数据包中包含的帧数与应用程序一致。例如，在延迟很重要的电话应用中，每个分组的帧越少，延迟越低；然而，对于延迟不敏感的流式传输或消息传递应用程序，每个数据包有许多帧是可以接受的。
Information describing the number of frames contained in an RTP packet is not transmitted as part of the RTP payload. The only way to determine the number of G.722.1 frames is to count the total number of octets within the RTP packet and divide the octet count by the number of expected octets per frame. This expected octet-per-frame count is derived from the bit rate and is therefore a function of the payload type.
描述RTP分组中包含的帧数的信息不作为RTP有效载荷的一部分传输。确定G.722.1帧数的唯一方法是计算RTP数据包内的八位字节总数，并将八位字节数除以每帧的预期八位字节数。此预期的每帧八位字节计数源自比特率，因此是有效负载类型的函数。
This document updates the G7221 media type described in RFC 3047.
本文档更新RFC 3047中描述的G7221介质类型。
This section describes the media types and names associated with this payload format. The section registers the media types, as per RFC 4288 [RFC4288]
本节介绍与此有效负载格式关联的媒体类型和名称。该部分根据RFC 4288[RFC4288]注册媒体类型
Media type name: audio
媒体类型名称：音频
Media subtype name: G7221
媒体子类型名称：G7221
Required parameters:
所需参数：
bitrate: the data rate for the audio bit stream. This parameter is mandatory because the bit rate is not signaled within the G.722.1 bit stream. At the standard G.722.1 bit rates, the value MUST be either 24000 or 32000 at 16 Khz sample rate, and 24000, 32000, or 48000 at 32 Khz sample rate. If using the non-standard bit rates, then it is RECOMMENDED that values in the range 16000 to 48000 be used. Non-standard rates MUST have a value that is a multiple of 400 (this maintains octet alignment and does not then require (undefined) padding bits for each frame if not octet aligned).
比特率：音频比特流的数据速率。此参数是必需的，因为G.722.1比特流中没有发送比特率信号。在标准G.722.1比特率下，16 Khz采样率下的值必须为24000或32000，32 Khz采样率下的值必须为24000、32000或48000。如果使用非标准比特率，则建议使用16000至48000范围内的值。非标准速率的值必须是400的倍数（这将保持八位字节对齐，如果没有八位字节对齐，则不需要（未定义的）每个帧的填充位）。
Optional parameters:
可选参数：
rate: RTP timestamp clock rate, which is equal to the sampling rate. If the parameter is not specified, a clock rate of 16 Khz is assumed.
速率：RTP时间戳时钟速率，等于采样速率。如果未指定参数，则假定时钟频率为16 Khz。
ptime: see RFC 4566. SHOULD be a multiple of 20 ms.
ptime：见RFC 4566。应该是20毫秒的倍数。
maxptime: see RFC 4566. SHOULD be a multiple of 20 ms.
最大时间：见RFC 4566。应该是20毫秒的倍数。
Encoding considerations:
编码注意事项：
This media type is framed and binary, see Section 4.8 in [RFC4288].
此媒体类型为帧和二进制，请参阅[RFC4288]中的第4.8节。
Security considerations: See Section 6
安全注意事项：见第6节
Interoperability considerations:
互操作性注意事项：
Terminals SHOULD offer a media type at 16 Khz sample rate in order to interoperate with terminals that do not support the new 32 Khz sample rate.
终端应提供16 Khz采样率的媒体类型，以便与不支持新32 Khz采样率的终端进行互操作。
Published specification: RFC 5577.
已发布规范：RFC5577。
Applications that use this media type:
使用此媒体类型的应用程序：
Audio and Video streaming and conferencing applications.
音频和视频流以及会议应用程序。
Additional information: none
其他信息：无
Person and email address to contact for further information :
联系人和电子邮件地址，以获取更多信息：
Roni Even: ron.even.tlv@gmail.com
罗恩：罗恩，甚至。tlv@gmail.com
Intended usage: COMMON
预期用途：普通
Restrictions on usage:
使用限制：
This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.
此媒体类型取决于RTP帧，因此仅定义为通过RTP传输[RFC3550]。此时未定义其他帧协议内的传输。
Author: Roni Even
作者：Roni Even
Change controller:
更改控制器：
IETF Audio/Video Transport working group delegated from the IESG.
IESG授权的IETF音频/视频传输工作组。
The media types audio/G7221 are mapped to fields in the Session Description Protocol (SDP) [RFC4566] as follows:
媒体类型audio/G7221映射到会话描述协议（SDP）[RFC4566]中的字段，如下所示：
o The media name in the "m=" line of SDP MUST be audio.
o SDP的“m=”行中的媒体名称必须是音频。
o The encoding name in the "a=rtpmap" line of SDP MUST be G7221 (the media subtype).
o SDP的“a=rtpmap”行中的编码名称必须是G7221（媒体子类型）。
o The parameter "rate" goes in "a=rtpmap" as clock rate parameter.
o 参数“速率”作为时钟速率参数进入“a=rtpmap”。
o Only one bitrate SHALL be defined (using the "bitrate=" parameter in the a=fmtp line) for each payload type.
o 对于每种有效负载类型，只能定义一个比特率（使用a=fmtp行中的“bitrate=”参数）。
When offering G.722.1 over RTP using SDP in an Offer/Answer model [RFC3264], the following considerations are necessary.
在报价/应答模型[RFC3264]中使用SDP通过RTP提供G.722.1时，需要考虑以下因素。
The combination of the clock rate in the rtpmap and the bitrate parameter defines the configuration of each payload type. Each configuration intended to be used MUST be declared.
rtpmap中的时钟速率和比特率参数的组合定义了每种有效负载类型的配置。必须声明拟使用的每个配置。
There are two sampling clock rates defined for G.722.1 in this document. RFC 3047 [RFC3047] supports only the 16 Khz clock rate. Therefore, a system that wants to use G.722.1 SHOULD offer a payload type with clock rate of 16000 for backward interoperability.
本文件中为G.722.1定义了两种采样时钟频率。RFC 3047[RFC3047]仅支持16 Khz时钟频率。因此，希望使用G.722.1的系统应提供时钟频率为16000的有效负载类型，以实现向后互操作性。
An example of an offer that includes a 16000 and 32000 clock rate is:
包含16000和32000时钟速率的报价示例如下：
m=audio 49000 RTP/AVP 121 122
a=rtpmap:121 G7221/16000
a=fmtp:121 bitrate=24000
a=rtpmap:122 G7221/32000
a=fmtp:122 bitrate=48000
m=audio 49000 RTP/AVP 121 122
a=rtpmap:121 G7221/16000
a=fmtp:121 bitrate=24000
a=rtpmap:122 G7221/32000
a=fmtp:122 bitrate=48000
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and any appropriate RTP profile. The main security considerations for the RTP packet carrying the RTP payload format defined within this memo are confidentiality, integrity, and source authenticity. Confidentiality is achieved by encryption of the RTP payload. Integrity of the RTP packets is achieved through a suitable cryptographic integrity-protection mechanism. Such a cryptographic system may also allow the authentication of the source
使用本规范中定义的有效负载格式的RTP数据包应遵守RTP规范[RFC3550]和任何适当RTP配置文件中讨论的安全注意事项。携带本备忘录中定义的RTP有效载荷格式的RTP数据包的主要安全注意事项是机密性、完整性和源真实性。保密性是通过对RTP有效负载进行加密来实现的。RTP数据包的完整性是通过合适的密码完整性保护机制实现的。这样的密码系统还可以允许对源进行认证
of the payload. A suitable security mechanism for this RTP payload format should provide confidentiality, integrity protection, and at least source authentication capable of determining if an RTP packet is from a member of the RTP session.
有效载荷的一部分。此RTP有效负载格式的合适安全机制应提供机密性、完整性保护，并且至少能够确定RTP分组是否来自RTP会话的成员的源认证。
Note that the appropriate mechanism to provide security to RTP and payloads following this memo may vary. It is dependent on the application, the transport, and the signaling protocol employed. Therefore, a single mechanism is not sufficient; although, if suitable, usage of the Secure Real-time Transport Protocol (SRTP) is [RFC3711] recommended. Another mechanism that may be used is IPsec [RFC4301] Transport Layer Security (TLS) [RFC5246] (RTP over TCP); other alternatives may exist.
请注意，根据本备忘录为RTP和有效负载提供安全性的适当机制可能会有所不同。它取决于应用程序、传输和所采用的信令协议。因此，单一的机制是不够的；不过，如果合适，建议使用安全实时传输协议（SRTP）[RFC3711]。可以使用的另一种机制是IPsec[RFC4301]传输层安全（TLS）[RFC5246]（TCP上的RTP）；可能存在其他替代方案。
This RTP payload format and its media decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing, and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological data. Nor does the RTP payload format contain any active content.
此RTP有效载荷格式及其媒体解码器在用于分组处理的接收器端计算复杂度方面不表现出任何显著的非均匀性，因此不太可能由于接收病理数据而造成拒绝服务威胁。RTP有效负载格式也不包含任何活动内容。
This specification obsoletes RFC 3047, adding the support for the Superwideband (14 Khz) audio support defined in annex C of the new revision of ITU-T G.722.1.
本规范废除了RFC 3047，增加了对ITU-T G.722.1新版本附录C中定义的超宽带（14 Khz）音频支持的支持。
Other changes:
其他变化：
Updated the text to be in line with the current rules for RFCs and with media type registration conforming to RFC 4288.
更新文本，使其符合RFC的现行规则，并符合RFC 4288的媒体类型注册要求。
The authors would like to thank Tom Taylor for his contribution to this work.
作者要感谢汤姆·泰勒对这项工作的贡献。
[ITU.G7221] International Telecommunications Union, "Low-complexity coding at 24 and 32 kbit/s for hands-free operation in systems with low frame loss", ITU-T Recommendation G.722.1, 2005.
[ITU.G7221]国际电信联盟，“在低帧丢失系统中以24和32 kbit/s的速度进行免提操作的低复杂度编码”，ITU-T建议G.722.12005年。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC3047] Luthi, P., "RTP Payload Format for ITU-T Recommendation G.722.1", RFC 3047, January 2001.
[RFC3047]Luthi，P.，“ITU-T建议G.722.1的RTP有效载荷格式”，RFC 3047，2001年1月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288]Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
Authors' Addresses
作者地址
Patrick Luthi Tandberg Philip Pedersens vei 22 1366 Lysaker Norway
Patrick Luthi Tandberg Philip Pedersens vei 22 1366 Lysaker挪威
EMail: patrick.luthi@tandberg.no
EMail: patrick.luthi@tandberg.no
Roni Even Gesher Erove Ltd 14 David Hamelech Tel Aviv 64953 Israel
Roni Even Gesher Erove有限公司14 David Hamelech特拉维夫64953以色列
EMail: ron.even.tlv@gmail.com
EMail: ron.even.tlv@gmail.com