Network Working Group S. Casner
Request for Comments: 4856 Packet Design
Obsoletes: 3555 March 2007
Category: Standards Track
Network Working Group S. Casner
Request for Comments: 4856 Packet Design
Obsoletes: 3555 March 2007
Category: Standards Track
Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences
音频和视频会议RTP配置文件中有效负载格式的媒体类型注册
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document specifies media type registrations for the RTP payload formats defined in the RTP Profile for Audio and Video Conferences. Some of these may also be used for transfer modes other than RTP.
本文档规定了音频和视频会议RTP配置文件中定义的RTP有效负载格式的媒体类型注册。其中一些也可用于RTP以外的传输模式。
Table of Contents
1. Introduction ....................................................2
1.1. IANA Considerations ........................................2
1.2. Terminology ................................................3
2. Registrations for "Audio/Video Profile" .........................3
2.1. Audio Type Registrations ...................................3
2.2. Video Type Registrations ..................................24
3. Changes from RFC 3555 ..........................................25
4. Security Considerations ........................................26
5. References .....................................................27
5.1. Normative References ......................................27
5.2. Informative References ....................................27
Table of Contents
1. Introduction ....................................................2
1.1. IANA Considerations ........................................2
1.2. Terminology ................................................3
2. Registrations for "Audio/Video Profile" .........................3
2.1. Audio Type Registrations ...................................3
2.2. Video Type Registrations ..................................24
3. Changes from RFC 3555 ..........................................25
4. Security Considerations ........................................26
5. References .....................................................27
5.1. Normative References ......................................27
5.2. Informative References ....................................27
This document updates the media type registrations initially specified in RFC 3555 for the Real-time Transport Protocol (RTP) payload formats defined in the RTP Profile for Audio and Video Conferences, RFC 3551 [1], as subtypes under the "audio" and "video" media types. This document does not include media type registrations for the RTP payload formats that are referenced in RFC 3551 but defined in other RFCs. The media type registrations for those payload formats are intended to be updated by including them in revisions of the individual RFCs defining the payload formats.
本文件将RFC 3555中最初指定的媒体类型注册更新为音频和视频会议RTP配置文件RFC 3551[1]中定义的实时传输协议（RTP）有效负载格式，作为“音频”和“视频”媒体类型下的子类型。本文档不包括RFC 3551中引用但在其他RFC中定义的RTP有效负载格式的媒体类型注册。这些有效载荷格式的媒体类型注册旨在通过将其包括在定义有效载荷格式的各个RFC的修订版中来更新。
The media type registrations specified here conform to the updated template format and procedures in RFC 4288 [2] and RFC 4855 [3]. This update makes no technical changes in the registrations. Together with RFC 4855, this document obsoletes RFC 3555.
此处指定的媒体类型注册符合RFC 4288[2]和RFC 4855[3]中更新的模板格式和程序。此更新不会对注册进行任何技术更改。与RFC 4855一起，本文件淘汰了RFC 3555。
As a consequence of the generalized applicability of the media types registry as specified in RFC 4288, some changes in nomenclature are needed in the RTP Payload Format section of the registry. In the registry title "RTP Payload Format MIME types" and the introductory text, "MIME" should be changed to "media". "MIME" should be deleted from the table headings, leaving just "media type" and "subtype".
由于RFC 4288中规定的介质类型注册表的普遍适用性，注册表的RTP有效负载格式部分需要对术语进行一些更改。在注册表标题“RTP有效负载格式MIME类型”和介绍性文本中，“MIME”应更改为“媒体”。应从表标题中删除“MIME”，只留下“媒体类型”和“子类型”。
This document updates the media type registrations listed below to conform to the revised registration format specified in RFC 4288 and RFC 4855, so the reference for these media types should be changed from RFC 3555 to this document. Some media type registrations contained in RFC 3555 are omitted from this document; the existing registrations for those types continue to be valid until updated by other RFCs. There are no new registrations contained here.
本文件更新了下面列出的介质类型注册，以符合RFC 4288和RFC 4855中规定的修订注册格式，因此这些介质类型的参考应从RFC 3555更改为本文件。本文件省略了RFC 3555中包含的一些媒体类型注册；在其他RFC更新之前，这些类型的现有注册继续有效。这里没有新的注册。
audio/DVI4 audio/G722 audio/G723 audio/G726-16 audio/G726-24 audio/G726-32 audio/G726-40 audio/G728 audio/G729 audio/G729D audio/G729E audio/GSM audio/GSM-EFR audio/L8 audio/L16 audio/LPC audio/PCMA audio/PCMU audio/VDVI video/nv
音频/DVI4音频/G722音频/G723音频/G726-16音频/G726-24音频/G726-32音频/G726-40音频/G728音频/G729音频/G729D音频/G729E音频/GSM音频/GSM-EFR音频/L8音频/L16音频/LPC音频/PCMA音频/PCMU音频/VDVI视频/nv
Media type audio/L16 was initially registered via RFC 2586 for transports other than RTP. That registration is incorporated here and augmented with additional information for RTP transport.
媒体类型audio/L16最初通过RFC 2586注册用于RTP以外的传输。该注册包含在此处，并添加了RTP传输的附加信息。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4] and indicate requirement levels for implementations compliant with this specification.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[4]中的描述进行解释，并表示符合本规范的实施的要求级别。
In the following sections, the RTP payload formats defined in the RTP Profile for Audio and Video Conferences, RFC 3551 [1], are registered as media types.
在以下章节中，音频和视频会议的RTP配置文件RFC 3551[1]中定义的RTP有效负载格式注册为媒体类型。
For most audio payload formats, the RTP timestamp clock rate is equal to the sampling rate. Some payload formats operate only at one fixed sampling rate, while others are adjustable.
对于大多数音频有效负载格式，RTP时间戳时钟速率等于采样速率。一些有效负载格式仅在一个固定采样率下工作，而其他有效负载格式可调。
These audio formats also include the optional parameters "ptime" to specify the recommended length of time in milliseconds represented by
这些音频格式还包括可选参数“ptime”，用于指定建议的时间长度（以毫秒为单位），由
the media in a packet, and "maxptime" to specify the maximum amount of media that can be encapsulated in each packet, expressed as time in milliseconds. The "ptime" and "maxptime" parameters are defined in the Session Description Protocol (SDP), RFC 4566 [5].
数据包中的媒体，以及“maxptime”，用于指定每个数据包中可封装的最大媒体量，以毫秒表示。“ptime”和“maxptime”参数在会话描述协议（SDP）RFC 4566[5]中定义。
Type name: audio
类型名称：音频
Subtype name: DVI4
子类型名称：DVI4
Required parameters: rate: The RTP timestamp clock rate, which is equal to the sampling rate. The typical rate is 8000, but other rates may be specified.
所需参数：速率：RTP时间戳时钟速率，等于采样速率。典型费率为8000，但可能会指定其他费率。
Optional parameters: ptime, maxptime (see RFC 4566)
可选参数：ptime、maxptime（参见RFC 4566）
Encoding considerations: This media type is framed binary data (see Section 4.8 in RFC 4288).
编码注意事项：此媒体类型为帧二进制数据（请参阅RFC 4288中的第4.8节）。
Security considerations: This media type does not carry active content. It does transfer compressed data. See Section 4 of RFC 4856.
安全注意事项：此媒体类型不包含活动内容。它确实传输压缩数据。见RFC 4856第4节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 3551
已发布规范：RFC 3551
Applications that use this media type: Audio and video streaming and conferencing tools.
使用此媒体类型的应用程序：音频和视频流媒体以及会议工具。
Additional information: none
其他信息：无
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550 [6]). Transfer within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输（RFC 3550[6]）。此时未定义其他帧协议内的传输。
Author: Stephen Casner
作者：斯蒂芬·卡斯纳
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
Type name: audio
类型名称：音频
Subtype name: G722
子类型名称：G722
Required parameters: none
所需参数：无
Optional parameters: ptime, maxptime (see RFC 4566)
可选参数：ptime、maxptime（参见RFC 4566）
Encoding considerations: This media type is framed binary data (see Section 4.8 in RFC 4288).
编码注意事项：此媒体类型为帧二进制数据（请参阅RFC 4288中的第4.8节）。
Security considerations: This media type does not carry active content. It does transfer compressed data. See Section 4 of RFC 4856.
安全注意事项：此媒体类型不包含活动内容。它确实传输压缩数据。见RFC 4856第4节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 3551
已发布规范：RFC 3551
Applications that use this media type: Audio and video streaming and conferencing tools.
使用此媒体类型的应用程序：音频和视频流媒体以及会议工具。
Additional information: none
其他信息：无
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550). Transfer within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输（RFC 3550）。此时未定义其他帧协议内的传输。
Author: Stephen Casner
作者：斯蒂芬·卡斯纳
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
Type name: audio
类型名称：音频
Subtype name: G723
子类型名称：G723
Required parameters: none
所需参数：无
Optional parameters: ptime, maxptime: see RFC 4566
可选参数：ptime、maxptime：请参阅RFC 4566
bitrate: the data rate in kb/s used or preferred for the audio bit stream, with permissible values 5.3 or 6.3. If unspecified, the bitrate may change from frame to frame as indicated inband.
比特率：音频比特流使用或首选的数据速率（kb/s），允许值为5.3或6.3。如果未指定，比特率可能会随着帧的变化而变化，如带内所示。
annexa: indicates that Annex A, voice activity detection, is used or preferred. Permissible values are "yes" and "no" (without the quotes); "yes" is implied if this parameter is omitted.
附录A：表示使用或首选附录A“语音活动检测”。允许值为“是”和“否”（不带引号）；如果省略此参数，则表示“是”。
Encoding considerations: This media type is framed binary data (see Section 4.8 in RFC 4288).
编码注意事项：此媒体类型为帧二进制数据（请参阅RFC 4288中的第4.8节）。
Security considerations: This media type does not carry active content. It does transfer compressed data. See Section 4 of RFC 4856.
安全注意事项：此媒体类型不包含活动内容。它确实传输压缩数据。见RFC 4856第4节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 3551
已发布规范：RFC 3551
Applications that use this media type: Audio and video streaming and conferencing tools.
使用此媒体类型的应用程序：音频和视频流媒体以及会议工具。
Additional information: none
其他信息：无
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550). Transfer within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输（RFC 3550）。此时未定义其他帧协议内的传输。
Author: Stephen Casner
作者：斯蒂芬·卡斯纳
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
Type name: audio
类型名称：音频
Subtype name: G726-16
子类型名称：G726-16
Required parameters: none
所需参数：无
Optional parameters: ptime, maxptime (see RFC 4566)
可选参数：ptime、maxptime（参见RFC 4566）
Encoding considerations: This media type is framed binary data (see Section 4.8 in RFC 4288).
编码注意事项：此媒体类型为帧二进制数据（请参阅RFC 4288中的第4.8节）。
Security considerations: This media type does not carry active content. It does transfer compressed data. See Section 4 of RFC 4856.
安全注意事项：此媒体类型不包含活动内容。它确实传输压缩数据。见RFC 4856第4节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 3551
已发布规范：RFC 3551
Applications that use this media type: Audio and video streaming and conferencing tools.
使用此媒体类型的应用程序：音频和视频流媒体以及会议工具。
Additional information: none
其他信息：无
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550). Transfer within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输（RFC 3550）。此时未定义其他帧协议内的传输。
Author: Stephen Casner
作者：斯蒂芬·卡斯纳
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
Type name: audio
类型名称：音频
Subtype name: G726-24
子类型名称：G726-24
Required parameters: none
所需参数：无
Optional parameters: ptime, maxptime (see RFC 4566)
可选参数：ptime、maxptime（参见RFC 4566）
Encoding considerations: This media type is framed binary data (see Section 4.8 in RFC 4288).
编码注意事项：此媒体类型为帧二进制数据（请参阅RFC 4288中的第4.8节）。
Security considerations: This media type does not carry active content. It does transfer compressed data. See Section 4 of RFC 4856.
安全注意事项：此媒体类型不包含活动内容。它确实传输压缩数据。见RFC 4856第4节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 3551
已发布规范：RFC 3551
Applications that use this media type: Audio and video streaming and conferencing tools.
使用此媒体类型的应用程序：音频和视频流媒体以及会议工具。
Additional information: none
其他信息：无
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550). Transfer within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输（RFC 3550）。此时未定义其他帧协议内的传输。
Author: Stephen Casner
作者：斯蒂芬·卡斯纳
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
Type name: audio
类型名称：音频
Subtype name: G726-32
子类型名称：G726-32
Required parameters: none
所需参数：无
Optional parameters: ptime, maxptime (see RFC 4566)
可选参数：ptime、maxptime（参见RFC 4566）
Encoding considerations: This media type is framed binary data (see Section 4.8 in RFC 4288).
编码注意事项：此媒体类型为帧二进制数据（请参阅RFC 4288中的第4.8节）。
Security considerations: This media type does not carry active content. It does transfer compressed data. See Section 4 of RFC 4856.
安全注意事项：此媒体类型不包含活动内容。它确实传输压缩数据。见RFC 4856第4节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 3551
已发布规范：RFC 3551
Applications that use this media type: Audio and video streaming and conferencing tools.
使用此媒体类型的应用程序：音频和视频流媒体以及会议工具。
Additional information: none
其他信息：无
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550). Transfer within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输（RFC 3550）。此时未定义其他帧协议内的传输。
Author: Stephen Casner
作者：斯蒂芬·卡斯纳
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
Type name: audio
类型名称：音频
Subtype name: G726-40
子类型名称：G726-40
Required parameters: none
所需参数：无
Optional parameters: ptime, maxptime (see RFC 4566)
可选参数：ptime、maxptime（参见RFC 4566）
Encoding considerations: This media type is framed binary data (see Section 4.8 in RFC 4288).
编码注意事项：此媒体类型为帧二进制数据（请参阅RFC 4288中的第4.8节）。
Security considerations: This media type does not carry active content. It does transfer compressed data. See Section 4 of RFC 4856.
安全注意事项：此媒体类型不包含活动内容。它确实传输压缩数据。见RFC 4856第4节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 3551
已发布规范：RFC 3551
Applications that use this media type: Audio and video streaming and conferencing tools.
使用此媒体类型的应用程序：音频和视频流媒体以及会议工具。
Additional information: none
其他信息：无
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550). Transfer within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输（RFC 3550）。此时未定义其他帧协议内的传输。
Author: Stephen Casner
作者：斯蒂芬·卡斯纳
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
Type name: audio
类型名称：音频
Subtype name: G728
子类型名称：G728
Required parameters: none
所需参数：无
Optional parameters: ptime, maxptime (see RFC 4566)
可选参数：ptime、maxptime（参见RFC 4566）
Encoding considerations: This media type is framed binary data (see Section 4.8 in RFC 4288).
编码注意事项：此媒体类型为帧二进制数据（请参阅RFC 4288中的第4.8节）。
Security considerations: This media type does not carry active content. It does transfer compressed data. See Section 4 of RFC 4856.
安全注意事项：此媒体类型不包含活动内容。它确实传输压缩数据。见RFC 4856第4节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 3551
已发布规范：RFC 3551
Applications that use this media type: Audio and video streaming and conferencing tools.
使用此媒体类型的应用程序：音频和视频流媒体以及会议工具。
Additional information: none
其他信息：无
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550). Transfer within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输（RFC 3550）。此时未定义其他帧协议内的传输。
Author: Stephen Casner
作者：斯蒂芬·卡斯纳
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
Type name: audio
类型名称：音频
Subtype name: G729
子类型名称：G729
Required parameters: none
所需参数：无
Optional parameters: ptime, maxptime: see RFC 4566
可选参数：ptime、maxptime：请参阅RFC 4566
annexb: indicates that Annex B, voice activity detection, is used or preferred. Permissible values are "yes" and "no" (without the quotes); "yes" is implied if this parameter is omitted.
附录B：表示使用或首选附录B“语音活动检测”。允许值为“是”和“否”（不带引号）；如果省略此参数，则表示“是”。
Encoding considerations: This media type is framed binary data (see Section 4.8 in RFC 4288).
编码注意事项：此媒体类型为帧二进制数据（请参阅RFC 4288中的第4.8节）。
Security considerations: This media type does not carry active content. It does transfer compressed data. See Section 4 of RFC 4856.
安全注意事项：此媒体类型不包含活动内容。它确实传输压缩数据。见RFC 4856第4节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 3551
已发布规范：RFC 3551
Applications that use this media type: Audio and video streaming and conferencing tools.
使用此媒体类型的应用程序：音频和视频流媒体以及会议工具。
Additional information: none
其他信息：无
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550). Transfer within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输（RFC 3550）。此时未定义其他帧协议内的传输。
Author: Stephen Casner
作者：斯蒂芬·卡斯纳
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
Type name: audio
类型名称：音频
Subtype name: G729D
子类型名称：G729D
Required parameters: none
所需参数：无
Optional parameters: ptime, maxptime: see RFC 4566
可选参数：ptime、maxptime：请参阅RFC 4566
annexb: indicates that Annex B, voice activity detection, is used or preferred. Permissible values are "yes" and "no" (without the quotes); "yes" is implied if this parameter is omitted.
附录B：表示使用或首选附录B“语音活动检测”。允许值为“是”和“否”（不带引号）；如果省略此参数，则表示“是”。
Encoding considerations: This media type is framed binary data (see Section 4.8 in RFC 4288).
编码注意事项：此媒体类型为帧二进制数据（请参阅RFC 4288中的第4.8节）。
Security considerations: This media type does not carry active content. It does transfer compressed data. See Section 4 of RFC 4856.
安全注意事项：此媒体类型不包含活动内容。它确实传输压缩数据。见RFC 4856第4节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 3551
已发布规范：RFC 3551
Applications that use this media type: Audio and video streaming and conferencing tools.
使用此媒体类型的应用程序：音频和视频流媒体以及会议工具。
Additional information: none
其他信息：无
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550). Transfer within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输（RFC 3550）。此时未定义其他帧协议内的传输。
Author: Stephen Casner
作者：斯蒂芬·卡斯纳
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
Type name: audio
类型名称：音频
Subtype name: G729E
子类型名称：G729E
Required parameters: none
所需参数：无
Optional parameters: ptime, maxptime: see RFC 4566
可选参数：ptime、maxptime：请参阅RFC 4566
annexb: indicates that Annex B, voice activity detection, is used or preferred. Permissible values are "yes" and "no" (without the quotes); "yes" is implied if this parameter is omitted.
附录B：表示使用或首选附录B“语音活动检测”。允许值为“是”和“否”（不带引号）；如果省略此参数，则表示“是”。
Encoding considerations: This media type is framed binary data (see Section 4.8 in RFC 4288).
编码注意事项：此媒体类型为帧二进制数据（请参阅RFC 4288中的第4.8节）。
Security considerations: This media type does not carry active content. It does transfer compressed data. See Section 4 of RFC 4856.
安全注意事项：此媒体类型不包含活动内容。它确实传输压缩数据。见RFC 4856第4节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 3551
已发布规范：RFC 3551
Applications that use this media type: Audio and video streaming and conferencing tools.
使用此媒体类型的应用程序：音频和视频流媒体以及会议工具。
Additional information: none
其他信息：无
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550). Transfer within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输（RFC 3550）。此时未定义其他帧协议内的传输。
Author: Stephen Casner
作者：斯蒂芬·卡斯纳
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
Type name: audio
类型名称：音频
Subtype name: GSM
子类型名称：GSM
Required parameters: none
所需参数：无
Optional parameters: ptime, maxptime (see RFC 4566)
可选参数：ptime、maxptime（参见RFC 4566）
Encoding considerations: This media type is framed binary data (see Section 4.8 in RFC 4288).
编码注意事项：此媒体类型为帧二进制数据（请参阅RFC 4288中的第4.8节）。
Security considerations: This media type does not carry active content. It does transfer compressed data. See Section 4 of RFC 4856.
安全注意事项：此媒体类型不包含活动内容。它确实传输压缩数据。见RFC 4856第4节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 3551
已发布规范：RFC 3551
Applications that use this media type: Audio and video streaming and conferencing tools.
使用此媒体类型的应用程序：音频和视频流媒体以及会议工具。
Additional information: none
其他信息：无
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550). Transfer within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输（RFC 3550）。此时未定义其他帧协议内的传输。
Author: Stephen Casner
作者：斯蒂芬·卡斯纳
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
Type name: audio
类型名称：音频
Subtype name: GSM-EFR
子类型名称：GSM-EFR
Required parameters: none
所需参数：无
Optional parameters: ptime, maxptime (see RFC 4566)
可选参数：ptime、maxptime（参见RFC 4566）
Encoding considerations: This media type is framed binary data (see Section 4.8 in RFC 4288).
编码注意事项：此媒体类型为帧二进制数据（请参阅RFC 4288中的第4.8节）。
Security considerations: This media type does not carry active content. It does transfer compressed data. See Section 4 of RFC 4856.
安全注意事项：此媒体类型不包含活动内容。它确实传输压缩数据。见RFC 4856第4节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 3551
已发布规范：RFC 3551
Applications that use this media type: Audio and video streaming and conferencing tools.
使用此媒体类型的应用程序：音频和视频流媒体以及会议工具。
Additional information: none
其他信息：无
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550). Transfer within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输（RFC 3550）。此时未定义其他帧协议内的传输。
Author: Stephen Casner
作者：斯蒂芬·卡斯纳
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
Type name: audio
类型名称：音频
Subtype name: L8
子类型名称：L8
Required parameters: rate: the RTP timestamp clock rate
所需参数：速率：RTP时间戳时钟速率
Optional parameters: channels: how many audio streams are interleaved -- defaults to 1; stereo would be 2, etc. Interleaving takes place between individual one-byte samples. The channel order is as specified in RFC 3551.
可选参数：通道：交错的音频流数量——默认为1；立体声将是2，等等。交错发生在单个单字节样本之间。信道顺序如RFC 3551中规定。
ptime, maxptime: see RFC 4566
ptime，maxptime：见RFC 4566
Encoding considerations: This media type is framed binary data (see Section 4.8 in RFC 4288).
编码注意事项：此媒体类型为帧二进制数据（请参阅RFC 4288中的第4.8节）。
Security considerations: This media type does not carry active content. It does transfer compressed data. See Section 4 of RFC 4856.
安全注意事项：此媒体类型不包含活动内容。它确实传输压缩数据。见RFC 4856第4节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 3551
已发布规范：RFC 3551
Applications that use this media type: Audio and video streaming and conferencing tools.
使用此媒体类型的应用程序：音频和视频流媒体以及会议工具。
Additional information: none
其他信息：无
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550). Transfer within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输（RFC 3550）。此时未定义其他帧协议内的传输。
Author: Stephen Casner
作者：斯蒂芬·卡斯纳
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
Media type audio/L16 was initially registered via RFC 2586 [10] for transports other than RTP. That registration is incorporated here and augmented with additional information for RTP transport.
媒体类型audio/L16最初是通过RFC 2586[10]注册的，用于RTP以外的传输。该注册包含在此处，并添加了RTP传输的附加信息。
Type name: audio
类型名称：音频
Subtype name: L16
子类型名称：L16
Required parameters: rate: number of samples per second -- For non-RTP transport, the permissible values for rate are 8000, 11025, 16000, 22050, 24000, 32000, 44100, and 48000 samples per second. For RTP transport, other values are permissible but the aforementioned values are RECOMMENDED. For RTP, the rate parameter indicates the RTP timestamp clock rate, which is equal to the sample rate.
所需参数：速率：每秒采样数——对于非RTP传输，速率的允许值为每秒8000、11025、16000、22050、24000、32000、44100和48000个样本。对于RTP运输，允许使用其他值，但建议使用上述值。对于RTP，rate参数表示RTP时间戳时钟速率，它等于采样速率。
Optional parameters: channels: how many audio streams are interleaved -- defaults to 1; stereo would be 2, etc. Interleaving takes place between individual two-byte samples. The channel order is as specified in RFC 3551 unless a channel-order parameter is also present.
可选参数：通道：交错的音频流数量——默认为1；立体声将是2，等等。交错发生在单个两字节样本之间。信道顺序如RFC 3551中规定，除非信道顺序参数也存在。
emphasis: analog preemphasis applied to the signal before quantization. The only emphasis value defined here is emphasis=50-15 to indicate the 50/15 microsecond preemphasis used with Compact Discs. This parameter MUST be omitted if no analog preemphasis was applied. Note that this is a stream property parameter, not a receiver configuration parameter. Thus, if parameters are negotiated, it may not be possible for the sender to comply with a receiver request for a particular setting.
重点：模拟预相位在量化前应用于信号。此处定义的唯一emphasis值为emphasis=50-15，表示光盘使用了50/15微秒的预相位。如果未应用模拟预相位，则必须忽略此参数。请注意，这是一个流属性参数，而不是接收器配置参数。因此，如果协商参数，发送方可能不可能遵守接收方对特定设置的请求。
channel-order: specifies the sample interleaving order for multiple-channel audio streams (see RFC 3190 [7], Section 7). Permissible values are DV.LRLsRs, DV.LRCS, DV.LRCWo, DV.LRLsRsC, DV.LRLsRsCS, DV.LmixRmixTWoQ1Q2, DV.LRCWoLsRsLmixRmix, DV.LRCWoLs1Rs1Ls2Rs2, DV.LRCWoLsRsLcRc.
通道顺序：指定多通道音频流的样本交错顺序（参见RFC 3190[7]，第7节）。允许值为DV.LRLsRs、DV.LRCS、DV.LRCWo、DV.LRLsRsC、DV.LRLsRsCS、DV.LMixrimxtWOQ1Q2、DV.LRCWoLsRsLmixRmix、DV.LRCWoLs1Rs1Ls2Rs2、DV.LRCWoLsRsLcRc。
For interoperation with DV video systems, only a subset of these channel combinations is specified for use with 20-bit linear encoding in the DV video specification [9]; those are DV.LRLsRs, DV.LRCS, DV.LmixRmixTWoQ1Q2. This parameter MUST be omitted when the AIFF-C channel order convention (see RFC 3551) is in use.
对于与DV视频系统的互操作，在DV视频规范[9]中，仅指定这些信道组合的子集用于20位线性编码；这些是DV.LRLsRs、DV.LRCS、DV.lmixrimxtwoq1q2。当使用AIFF-C信道顺序约定（参见RFC 3551）时，必须忽略此参数。
For RTP, ptime: RECOMMENDED duration of each packet in milliseconds.
对于RTP，ptime：每个数据包的建议持续时间（毫秒）。
For RTP, maxptime: maximum duration of each packet in milliseconds.
对于RTP，maxptime：每个数据包的最大持续时间（毫秒）。
Encoding considerations: Audio data is binary data, and must be encoded for non-binary transport; the Base64 encoding is suitable for Email. Note that audio data does not compress easily using lossless compression.
编码注意事项：音频数据是二进制数据，必须编码为非二进制传输；Base64编码适用于电子邮件。请注意，使用无损压缩时，音频数据不容易压缩。
Security considerations: Audio/L16 data is believed to offer no security risks. This media type does not carry active content. The encoding is not compressed. See Section 4 of RFC 4856.
安全注意事项：音频/L16数据被认为没有安全风险。此媒体类型不包含活动内容。编码没有被压缩。见RFC 4856第4节。
Interoperability considerations: This type is compatible with the encoding used in the WAV (Microsoft Windows RIFF) and Apple AIFF union types, and with the public domain "sox" and "rateconv" programs.
互操作性注意事项：此类型与WAV（Microsoft Windows RIFF）和Apple AIFF联合类型中使用的编码兼容，并与公共域“sox”和“rateconv”程序兼容。
Published specification: RFC 2586 for non-RTP transports, RFC 3551 for RTP
已发布规范：RFC 2586用于非RTP传输，RFC 3551用于RTP传输
Applications that use this media type: The public domain "sox" and "rateconv" programs accept this type.
使用此媒体类型的应用程序：公共域“sox”和“rateconv”程序接受此类型。
Additional information:
Magic number(s): none
File extension(s): WAV L16
Macintosh file type code: AIFF
Additional information:
Magic number(s): none
File extension(s): WAV L16
Macintosh file type code: AIFF
Person to contact for further information:
James Salsman <jps-L16@bovik.org>
Person to contact for further information:
James Salsman <jps-L16@bovik.org>
Intended usage: Common
预期用途：普通
It is expected that many audio and speech applications will use this type. Already the most popular platforms provide this type with the rate=11025 parameter, referred to as "radio quality speech".
预计许多音频和语音应用程序将使用这种类型。最流行的平台已经为这种类型提供了rate=11025参数，称为“无线电质量语音”。
Restrictions on usage: In addition to file-based transfer methods, this type is also defined for transfer via RTP (RFC 3550).
使用限制：除了基于文件的传输方法外，还为通过RTP（RFC 3550）传输定义了此类型。
Author: James Salsman for non-RTP transports. Stephen Casner for RTP transport.
作者：詹姆斯·萨尔斯曼，负责非RTP运输。Stephen Casner负责RTP运输。
Change controller: James Salsman for non-RTP transports. For RTP transport, IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：詹姆斯·萨尔斯曼负责非RTP运输。对于RTP传输，IESG授权的IETF音频/视频传输工作组。
Type name: audio
类型名称：音频
Subtype name: LPC
子类型名称：LPC
Required parameters: none
所需参数：无
Optional parameters: ptime, maxptime (see RFC 4566)
可选参数：ptime、maxptime（参见RFC 4566）
Encoding considerations: This media type is framed binary data (see Section 4.8 in RFC 4288).
编码注意事项：此媒体类型为帧二进制数据（请参阅RFC 4288中的第4.8节）。
Security considerations: This media type does not carry active content. It does transfer compressed data. See Section 4 of RFC 4856.
安全注意事项：此媒体类型不包含活动内容。它确实传输压缩数据。见RFC 4856第4节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 3551
已发布规范：RFC 3551
Applications that use this media type: Audio and video streaming and conferencing tools.
使用此媒体类型的应用程序：音频和视频流媒体以及会议工具。
Additional information: none
其他信息：无
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550). Transfer within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输（RFC 3550）。此时未定义其他帧协议内的传输。
Author: Stephen Casner
作者：斯蒂芬·卡斯纳
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
Type name: audio
类型名称：音频
Subtype name: PCMA
子类型名称：PCMA
Required parameters: rate: The RTP timestamp clock rate, which is equal to the sampling rate. The typical rate is 8000, but other rates may be specified.
所需参数：速率：RTP时间戳时钟速率，等于采样速率。典型费率为8000，但可能会指定其他费率。
Optional parameters: channels: how many audio streams are interleaved -- defaults to 1; stereo would be 2, etc. Interleaving takes place between individual one-byte samples. The channel order is as specified in RFC 3551.
可选参数：通道：交错的音频流数量——默认为1；立体声将是2，等等。交错发生在单个单字节样本之间。信道顺序如RFC 3551中规定。
ptime, maxptime: see RFC 4566
ptime，maxptime：见RFC 4566
Encoding considerations: This media type is framed binary data (see Section 4.8 in RFC 4288).
编码注意事项：此媒体类型为帧二进制数据（请参阅RFC 4288中的第4.8节）。
Security considerations: This media type does not carry active content. It does transfer compressed data. See Section 4 of RFC 4856.
安全注意事项：此媒体类型不包含活动内容。它确实传输压缩数据。见RFC 4856第4节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 3551
已发布规范：RFC 3551
Applications that use this media type: Audio and video streaming and conferencing tools.
使用此媒体类型的应用程序：音频和视频流媒体以及会议工具。
Additional information: none
其他信息：无
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550). Transfer within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输（RFC 3550）。此时未定义其他帧协议内的传输。
Author: Stephen Casner
作者：斯蒂芬·卡斯纳
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
Type name: audio
类型名称：音频
Subtype name: PCMU
子类型名称：PCMU
Required parameters: rate: The RTP timestamp clock rate, which is equal to the sampling rate. The typical rate is 8000, but other rates may be specified.
所需参数：速率：RTP时间戳时钟速率，等于采样速率。典型费率为8000，但可能会指定其他费率。
Optional parameters: channels: how many audio streams are interleaved -- defaults to 1; stereo would be 2, etc. Interleaving takes place between individual one-byte samples. The channel order is as specified in RFC 3551.
可选参数：通道：交错的音频流数量——默认为1；立体声将是2，等等。交错发生在单个单字节样本之间。信道顺序如RFC 3551中规定。
ptime, maxptime: see RFC 4566
ptime，maxptime：见RFC 4566
Encoding considerations: This media type is framed binary data (see Section 4.8 in RFC 4288).
编码注意事项：此媒体类型为帧二进制数据（请参阅RFC 4288中的第4.8节）。
Security considerations: This media type does not carry active content. It does transfer compressed data. See Section 4 of RFC 4856.
安全注意事项：此媒体类型不包含活动内容。它确实传输压缩数据。见RFC 4856第4节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 3551
已发布规范：RFC 3551
Applications that use this media type: Audio and video streaming and conferencing tools.
使用此媒体类型的应用程序：音频和视频流媒体以及会议工具。
Additional information: none
其他信息：无
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550). Transfer within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输（RFC 3550）。此时未定义其他帧协议内的传输。
Author: Stephen Casner
作者：斯蒂芬·卡斯纳
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
Type name: audio
类型名称：音频
Subtype name: VDVI
子类型名称：VDVI
Required parameters: none
所需参数：无
Optional parameters: ptime, maxptime (see RFC 4566)
可选参数：ptime、maxptime（参见RFC 4566）
Encoding considerations: This media type is framed binary data (see Section 4.8 in RFC 4288).
编码注意事项：此媒体类型为帧二进制数据（请参阅RFC 4288中的第4.8节）。
Security considerations: This media type does not carry active content. It does transfer compressed data. See Section 4 of RFC 4856.
安全注意事项：此媒体类型不包含活动内容。它确实传输压缩数据。见RFC 4856第4节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 3551
已发布规范：RFC 3551
Applications that use this media type: Audio and video streaming and conferencing tools.
使用此媒体类型的应用程序：音频和视频流媒体以及会议工具。
Additional information: none
其他信息：无
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550). Transfer within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输（RFC 3550）。此时未定义其他帧协议内的传输。
Author: Stephen Casner
作者：斯蒂芬·卡斯纳
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
For most video payload formats, including the one registered here, the RTP timestamp clock rate is always 90000 Hz, so the "rate" parameter is not applicable. Likewise, the "channel" parameter is not used with video, while "ptime" and "maxptime" could be but typically are not.
对于大多数视频有效负载格式，包括此处注册的格式，RTP时间戳时钟速率始终为90000 Hz，因此“速率”参数不适用。同样，“通道”参数不用于视频，而“ptime”和“maxptime”可以但通常不用于视频。
Type name: video
类型名称：视频
Subtype name: nv
子类型名称：nv
Required parameters: none
所需参数：无
Optional parameters: none
可选参数：无
Encoding considerations: This media type is framed binary data (see Section 4.8 in RFC 4288).
编码注意事项：此媒体类型为帧二进制数据（请参阅RFC 4288中的第4.8节）。
Security considerations: This media type does not carry active content. It does transfer compressed data. See Section 4 of RFC 4856.
安全注意事项：此媒体类型不包含活动内容。它确实传输压缩数据。见RFC 4856第4节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 3551
已发布规范：RFC 3551
Applications that use this media type: Audio and video streaming and conferencing tools.
使用此媒体类型的应用程序：音频和视频流媒体以及会议工具。
Additional information: none
其他信息：无
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Person & email address to contact for further information:
Stephen Casner <casner@acm.org>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550). Transfer within other framing protocols is not defined at this time.
使用限制：此媒体类型取决于RTP帧，因此仅定义为通过RTP传输（RFC 3550）。此时未定义其他帧协议内的传输。
Author: Stephen Casner
作者：斯蒂芬·卡斯纳
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
RFC 3555 is obsoleted by the combination of RFC 4855 [3] and this document. RFC 4855 retains the specification of procedures and requirements from RFC 3555, while the media type registrations from RFC 3555 were extracted into this document. The media type registrations for the RTP payload formats that are referenced in RFC 3551 [1], but defined in other RFCs, have been elided from this document because those registrations are intended to be updated by including them in revisions of the individual RFCs defining the payload formats.
RFC 3555被RFC 4855[3]和本文件的组合淘汰。RFC 4855保留了RFC 3555中的程序和要求规范，而RFC 3555中的介质类型注册被提取到本文件中。RFC 3551[1]中引用但在其他RFC中定义的RTP有效负载格式的媒体类型注册已从本文件中删除，因为这些注册旨在通过将其包含在定义有效负载格式的各个RFC的修订版中进行更新。
The media type registrations in this document have been updated to conform to the revised media type registration procedures in RFC 4288 [2] and RFC 4855. Whereas RFC 3555 required the encoding considerations to specify transfer via RTP, that is now specified under restrictions on usage. The encoding considerations now warn that these types are framed binary data. The change controller is also now identified according to current conventions. The optional parameter "channels" was clarified for audio subtypes L8, PCMA, and PCMU. Finally, reference [9], which was missing from RFC 3555, has been corrected.
本文件中的介质类型注册已更新，以符合RFC 4288[2]和RFC 4855中修订的介质类型注册程序。然而，现在需要通过RFC指定使用限制，而通过RFC指定使用限制。编码注意事项现在警告这些类型是框架二进制数据。变更控制器现在也根据当前约定进行标识。对音频子类型L8、PCMA和PCMU的可选参数“通道”进行了说明。最后，已更正RFC 3555中缺失的参考文献[9]。
This memo specifies media type registrations for the transfer of several compressed audio and video data encodings via RTP, so implementations using these media types are subject to the security considerations discussed in the RTP specification [8].
本备忘录规定了通过RTP传输多个压缩音频和视频数据编码的媒体类型注册，因此使用这些媒体类型的实现应遵守RTP规范[8]中讨论的安全注意事项。
None of these media types carry "active content" that could impose malicious side-effects upon the receiver. The content consists solely of compressed audio or video data to be decoded and presented as sound or images. However, several audio and video encodings are perfect for hiding data using steganography.
这些媒体类型中没有一种携带可能对接收者造成恶意副作用的“活动内容”。内容仅由压缩音频或视频数据组成，这些数据将被解码并以声音或图像的形式呈现。然而，有几种音频和视频编码非常适合使用隐写术隐藏数据。
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. However, none of the encodings registered here has an expansion factor greater than about 20, and all are considered relatively simple by modern standards (some are implemented on handheld devices and most were implemented on general-purpose computers ten years ago).
使用压缩技术的数据编码存在潜在的拒绝服务威胁，这种压缩技术具有非均匀的接收端计算负载。攻击者可以向流中注入病理数据报，这些数据报解码复杂，并导致接收器过载。然而，这里登记的编码没有一种扩展系数大于20左右，按照现代标准，所有编码都被认为是相对简单的（一些编码是在手持设备上实现的，大多数编码是在十年前在通用计算机上实现的）。
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.
与任何基于IP的协议一样，在某些情况下，接收机可能仅仅因为接收了太多的数据包而过载，不管是想要的还是不想要的。网络层认证可用于丢弃来自不希望的源的数据包，但认证本身的处理成本可能过高。
RTP may be sent via IP multicast, which provides no direct means for a sender to know all the receivers of the data sent and therefore no measure of privacy. Rightly or not, users may be more sensitive to privacy concerns with audio and video communication than they have been with more traditional forms of network communication. Therefore, the use of security mechanisms with RTP to provide confidentiality and integrity of the data is important. Because the data compression used with these media types is applied end-to-end, encryption may be performed after compression so there is no conflict between the two operations.
RTP可以通过IP多播发送，IP多播不提供发送者了解所发送数据的所有接收者的直接方式，因此没有隐私措施。不管正确与否，与传统的网络通信形式相比，用户可能对音频和视频通信的隐私问题更加敏感。因此，使用RTP的安全机制来提供数据的机密性和完整性非常重要。由于与这些媒体类型一起使用的数据压缩是端到端应用的，因此可以在压缩后执行加密，因此两个操作之间没有冲突。
[1] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003.
[1] Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，RFC 3551，2003年7月。
[2] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[2] Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[3] Casner, S., "Media Type Registration of RTP Payload Types", RFC 4855, January 2007.
[3] Casner，S.，“RTP有效负载类型的媒体类型注册”，RFC 4855，2007年1月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[5] Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[6] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
[6] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 35502003年7月。
[7] Kobayashi, K., Ogawa, A., Casner, S. and C. Bormann, "RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio", RFC 3190, January 2002.
[7] Kobayashi，K.，Ogawa，A.，Casner，S.和C.Bormann，“12位DAT音频和20位和24位线性采样音频的RTP有效载荷格式”，RFC 3190，2002年1月。
[8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
[8] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 35502003年7月。
[9] IEC 61834, Helical-scan digital video cassette recording system using 6,35 mm magnetic tape for consumer use (525-60, 625-50, 1125-60, and 1250-50 systems), August 1998.
[9] IEC 61834，使用6.35mm磁带的消费者用螺旋扫描数字盒式录像系统（525-60、625-50、1125-60和1250-50系统），1998年8月。
[10] Salsman, J. and H. Alvestrand, "The Audio/L16 MIME content type", RFC 2586, May 1999.
[10] Salsman，J.和H.Alvestrand，“音频/L16 MIME内容类型”，RFC 25861999年5月。
Author's Address
作者地址
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
Phone: +1 650 739-1843
EMail: casner@acm.org
Phone: +1 650 739-1843
EMail: casner@acm.org
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。