Network Working Group S. Casner
Request for Comments: 4855 Packet Design
Obsoletes: 3555 February 2007
Category: Standards Track
Network Working Group S. Casner
Request for Comments: 4855 Packet Design
Obsoletes: 3555 February 2007
Category: Standards Track
Media Type Registration of RTP Payload Formats
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 the procedure to register RTP payload formats as audio, video, or other media subtype names. This is useful in a text-based format description or control protocol to identify the type of an RTP transmission.
本文档指定了将RTP有效负载格式注册为音频、视频或其他媒体子类型名称的过程。这在基于文本的格式描述或控制协议中非常有用，可以识别RTP传输的类型。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Terminology ................................................2
2. Procedure For Registering Media Types for RTP Payload Types .....2
2.1. Example Media Type Registration ............................4
2.2. Restrictions on Sharing a Subtype Name .....................5
3. Mapping to SDP Parameters .......................................6
4. Changes from RFC 3555 ...........................................7
5. Security Considerations .........................................8
6. IANA Considerations .............................................9
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................10
1. Introduction ....................................................2
1.1. Terminology ................................................2
2. Procedure For Registering Media Types for RTP Payload Types .....2
2.1. Example Media Type Registration ............................4
2.2. Restrictions on Sharing a Subtype Name .....................5
3. Mapping to SDP Parameters .......................................6
4. Changes from RFC 3555 ...........................................7
5. Security Considerations .........................................8
6. IANA Considerations .............................................9
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................10
RFC 4288 [1] defines media type specification and registration procedures that use the Internet Assigned Numbers Authority (IANA) as a central registry. That document covers general requirements independent of particular application environments and transport modes. This document defines the specific requirements for registration of media types for use with the Real-time Transport Protocol (RTP), RFC 3550 [2], to identify RTP payload formats.
RFC 4288[1]定义了使用互联网分配号码管理局（IANA）作为中央注册表的媒体类型规范和注册程序。该文件涵盖了独立于特定应用环境和传输模式的一般要求。本文件定义了与实时传输协议（RTP）RFC 3550[2]一起使用的介质类型注册的具体要求，以识别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 [3] and indicate requirement levels for implementations compliant with this specification.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[3]中的描述进行解释，并表示符合本规范的实施的要求级别。
Registering an RTP payload type as a media type follows the same procedures as described in RFC 4288 [1] and uses the registration template shown in Section 10 of that RFC. To specify how the particular payload format is transported over RTP, some additional information is required in the following sections of that template:
将RTP有效负载类型注册为媒体类型遵循RFC 4288[1]中描述的相同过程，并使用该RFC第10节中所示的注册模板。要指定特定有效负载格式如何通过RTP传输，需要在该模板的以下部分中提供一些附加信息：
Required parameters: If the payload format does not have a fixed RTP timestamp clock rate, then a "rate" parameter is required to specify the RTP timestamp clock rate. A particular payload format may have additional required parameters.
所需参数：如果有效负载格式没有固定的RTP时间戳时钟速率，则需要“速率”参数来指定RTP时间戳时钟速率。特定有效负载格式可能具有额外的必需参数。
Optional parameters: Most audio payload formats can have an optional "channels" parameter to specify the number of audio channels included in the transmission. The default channel order is as specified in RFC 3551 [4]. Any payload format, but most likely audio formats, may also include the optional parameters "ptime" to specify the recommended length of time in milliseconds represented by the media in a packet, and/or "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) [5].
可选参数：大多数音频有效负载格式可以有一个可选的“通道”参数，用于指定传输中包含的音频通道数。默认通道顺序如RFC 3551[4]中所规定。任何有效负载格式，但最有可能的音频格式，也可以包括可选参数“ptime”，以指定由分组中的媒体表示的推荐时间长度（以毫秒为单位），和/或“maxptime”以指定可封装在每个分组中的媒体的最大量（以毫秒为单位）。“ptime”和“maxptime”参数在会话描述协议（SDP）[5]中定义。
A particular payload format may have additional optional parameters. As allowed in Section 4.3 of [1], new parameters MAY be added to RTP media types that have been previously
特定有效负载格式可能具有附加可选参数。如[1]第4.3节所允许，可将新参数添加到先前已安装的RTP介质类型中
defined, but the new parameters MUST NOT change existing functionality and it MUST be possible for existing implementations to ignore the additional parameters without impairing operation.
已定义，但新参数不得更改现有功能，并且现有实现必须能够在不影响操作的情况下忽略附加参数。
Encoding considerations: Most RTP payload formats include binary or framed data as described in Section 4.8 of [1]. The appropriate encoding considerations MUST be noted.
编码注意事项：大多数RTP有效载荷格式包括[1]第4.8节所述的二进制或帧数据。必须注意适当的编码注意事项。
Published specification: A description of the media encoding and a specification of the payload format must be provided, usually by reference to an RTP payload format specification RFC. That RFC may be separate, or the media type registration may be incorporated into the payload format specification RFC. The payload format specification MUST include the RTP timestamp clock rate (or multiple rates for audio encodings with multiple sampling rates).
已发布规范：必须提供媒体编码说明和有效负载格式规范，通常参考RTP有效负载格式规范RFC。该RFC可以是单独的，或者媒体类型注册可以合并到有效负载格式规范RFC中。有效负载格式规范必须包括RTP时间戳时钟速率（或具有多个采样率的音频编码的多个速率）。
A reference to a further description of the data compression format itself should be provided, if available.
如果可用，应提供对数据压缩格式本身的进一步说明的参考。
Restrictions on usage: The fact that the media type is defined for transfer via RTP MUST be noted, in particular, if the transfer depends on RTP framing and hence the media type is only defined for transfer via RTP.
使用限制：必须注意，介质类型是为通过RTP传输而定义的，特别是当传输依赖于RTP帧，因此介质类型仅为通过RTP传输而定义时。
Depending on whether or not the type has already been registered for transfer with a non-RTP protocol (e.g., MIME mail or http), several different cases can occur:
根据类型是否已注册为使用非RTP协议（例如MIME邮件或http）传输，可能会出现以下几种不同情况：
a) Not yet registered as a media type
a) 尚未注册为媒体类型
A new registration should be constructed using the media type registration template. The registration may specify transfer via other means in addition to RTP if that is feasible and desired. The appropriate encoding considerations must be specified, and the restrictions on usage must specify whether the type is only defined for transfer via RTP or via other modes as well.
应使用媒体类型注册模板构建新注册。注册可以指定通过RTP之外的其他方式进行转让，如果这是可行和需要的话。必须指定适当的编码注意事项，并且使用限制必须指定该类型仅定义为通过RTP传输还是通过其他模式传输。
Optional parameters may be defined as needed, and it must be clearly stated to which mode(s) of transfer the parameters apply.
可根据需要定义可选参数，并且必须明确说明参数适用于哪种传输模式。
b) Media type exists for a non-RTP protocol
b) 存在非RTP协议的媒体类型
The restrictions on usage of the existing type should be changed, if present, or added, if not, to indicate that the type can also be transferred via RTP.
现有类型的使用限制应该更改（如果存在），或者添加（如果没有），以表明该类型也可以通过RTP传输。
RTP-specific parameters may be added, and it must be clearly stated that these are only to be used when the media type is transmitted via RTP transport.
可以添加RTP特定参数，并且必须明确说明，这些参数仅在通过RTP传输传输媒体类型时使用。
c) Update an existing media type for RTP to be used for a non-RTP protocol
c) 更新RTP的现有媒体类型以用于非RTP协议
The restrictions on usage of the existing type should be changed to indicate that the type can also be transferred via a non-RTP protocol (e.g., SMTP, HTTP).
应更改对现有类型使用的限制，以表明该类型也可以通过非RTP协议（例如SMTP、HTTP）传输。
Non-RTP-specific parameters can be added, and it must be clearly stated that these are only to be used when the media type is transmitted via a non-RTP transport.
可以添加非RTP特定参数，并且必须明确说明，这些参数仅在通过非RTP传输传输介质类型时使用。
The following sample registration of a fake media type audio/example provides examples for some of the required text. References to RFC nnnn would be replaced by references to the RFC that contains the payload format specification and the media type registration.
以下假媒体类型音频/示例的注册示例提供了一些所需文本的示例。对RFC nnnn的引用将替换为对RFC的引用，RFC包含有效负载格式规范和媒体类型注册。
Type name: audio
类型名称：音频
Subtype name: example
子类型名称：示例
Required parameters: rate: RTP timestamp clock rate, which is equal to the sampling rate. The typical rate is 8000; other rates may be specified.
所需参数：速率：RTP时间戳时钟速率，等于采样速率。典型比率为8000；可规定其他费率。
Optional parameters: channels: number of interleaved audio streams, either 1 for mono or 2 for stereo, and defaults to 1 if omitted. Interleaving takes place between on a frame-by-frame basis, with the left channel followed by the right channel.
可选参数：通道：交错音频流的数量，单声道为1，立体声为2，如果省略，默认为1。交织在帧与帧之间进行，左声道后接右声道。
ptime: recommended length of time in milliseconds represented by the media in a packet (see RFC 4566).
ptime：由数据包中的媒体表示的建议时间长度（以毫秒为单位）（参见RFC 4566）。
maxptime: maximum amount of media that can be encapsulated in each packet, expressed as time in milliseconds (see RFC 4566).
maxptime：每个数据包中可以封装的最大媒体量，以毫秒表示（请参阅RFC 4566）。
Encoding considerations: This media type is framed binary data (see RFC 4288, Section 4.8).
编码注意事项：此媒体类型为帧二进制数据（见RFC 4288，第4.8节）。
Security considerations: See Section n of RFC nnnn
安全注意事项：参见RFC nnnn第n节
Interoperability considerations: Some receivers may only be capable of receiving single-channel audio.
互操作性注意事项：某些接收器可能只能接收单声道音频。
Published specification: RFC nnnn
已发布规范：RFC nnnn
Applications that use this media type: Audio and video streaming and conferencing tools.
使用此媒体类型的应用程序：音频和视频流媒体以及会议工具。
Additional information: none
其他信息：无
Person & email address to contact for further information:
Fred Audio <fred@example.com>
Person & email address to contact for further information:
Fred Audio <fred@example.com>
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: Fred Audio
作者：Fred Audio
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
变更控制员：IESG授权的IETF音频/视频传输工作组。
The same media subtype name MUST NOT be shared for RTP and non-RTP (file-based) transfer methods unless the data format is the same for both methods. The data format is considered to be the same if the file format is equivalent to a concatenated sequence of payloads from RTP packets not including the RTP header or any RTP payload-format header.
RTP和非RTP（基于文件）传输方法不得共享相同的媒体子类型名称，除非两种方法的数据格式相同。如果文件格式等效于来自不包括RTP报头或任何RTP有效载荷格式报头的RTP数据包的有效载荷串联序列，则认为数据格式相同。
The file format MAY include a magic number or other header at the start of the file that is not included when the data is transferred via RTP.
文件格式可以在文件的开头包含一个幻数或其他头，当数据通过RTP传输时，不包括该头。
A second requirement for sharing a media subtype name is that the sets of required parameters must be the same for both methods.
共享媒体子类型名称的第二个要求是，两种方法所需的参数集必须相同。
For cases where the data format or required parameters cannot be the same for RTP and non-RTP transfer methods, the data formats MUST be registered as separate types. It is RECOMMENDED that the subtype names be related, such as by using a common root plus a suffix. For those cases where a suffix is applied in the subtype name for the RTP transfer method, the suffix "+rtp" is suggested.
对于RTP和非RTP传输方法的数据格式或所需参数不能相同的情况，必须将数据格式注册为单独的类型。建议将子类型名称关联起来，例如使用公共根加后缀。对于在RTP传输方法的子类型名称中应用后缀的情况，建议使用后缀“+RTP”。
The representation of a media type is specified in the syntax of the Content-Type header field in RFC 2045 [6] as follows:
媒体类型的表示在RFC 2045[6]中内容类型标题字段的语法中指定如下：
type "/" subtype *(";" parameter)
type "/" subtype *(";" parameter)
Parameters may be required for a particular type or subtype or they may be optional. For media types that represent RTP payload formats, the parameters "rate", "channels", "ptime", and "maxptime" have general definitions (given above) that may apply across types and subtypes. The format for a parameter is specified in RFC 2045 as
特定类型或子类型可能需要参数，也可能是可选的。对于表示RTP有效负载格式的媒体类型，参数“速率”、“通道”、“ptime”和“maxptime”具有可跨类型和子类型应用的通用定义（如上所述）。参数的格式在RFC 2045中指定为
attribute "=" value
属性“=”值
where attribute is the parameter name and the permissible values are specified for each parameter. RFC 2045 specifies that a value MUST be present and that the value MUST be a quoted string if it contains any of the special characters listed in that RFC.
其中，attribute是参数名称，并且为每个参数指定了允许的值。RFC 2045指定值必须存在，并且如果该值包含RFC中列出的任何特殊字符，则该值必须是带引号的字符串。
The information carried in the media type string has a specific mapping to fields in the Session Description Protocol (SDP) [5], which is commonly used to describe RTP sessions. The mapping is as follows:
媒体类型字符串中包含的信息与会话描述协议（SDP）[5]中的字段具有特定映射，该协议通常用于描述RTP会话。映射如下：
o The media type (e.g., audio) goes in SDP "m=" as the media name.
o 媒体类型（如音频）以SDP“m=”作为媒体名称。
o The media subtype (payload format) goes in SDP "a=rtpmap" as the encoding name.
o 媒体子类型（有效负载格式）以SDP“a=rtpmap”作为编码名称。
o The general (possibly optional) parameters "rate" and "channels" also go in "a=rtpmap" as clock rate and encoding parameters, respectively.
o 一般（可能可选）参数“速率”和“通道”也分别作为时钟速率和编码参数进入“a=rtpmap”。
o The general (and optional) parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
o 常规（和可选）参数“ptime”和“maxptime”分别位于SDP“a=ptime”和“a=maxptime”属性中。
o Any payload-format-specific parameters go in the SDP "a=fmtp" attribute. The set of allowed parameters is defined by the RFC that specifies the payload format and MUST NOT be extended by the media type registration without a corresponding revision of the payload format specification. The format and syntax of these parameters may also be defined by the payload format specification, but it is suggested that the parameters be copied directly from the media type string as a semicolon separated list of parameter=value pairs. For payload formats that specify some other syntax for the fmtp parameters, the registration of that payload format as a media type must specify what the parameters are in MIME format and how to map them to the "a=fmtp" attribute.
o 任何特定于有效负载格式的参数都会进入SDP“a=fmtp”属性。允许的参数集由RFC定义，RFC指定有效负载格式，未经有效负载格式规范的相应修订，不得通过媒体类型注册进行扩展。这些参数的格式和语法也可由有效负载格式规范定义，但建议直接从媒体类型字符串复制参数，作为以分号分隔的参数=值对列表。对于为fmtp参数指定其他语法的有效负载格式，将该有效负载格式注册为媒体类型必须指定MIME格式的参数以及如何将其映射到“a=fmtp”属性。
An example mapping is as follows:
映射示例如下所示：
audio/L16; rate=48000; channels=2; ptime=5; emphasis=50-15
audio/L16; rate=48000; channels=2; ptime=5; emphasis=50-15
m=audio 49170 RTP/AVP 97
a=rtpmap:97 L16/48000/2
a=fmtp:97 emphasis=50-15
a=ptime:5
m=audio 49170 RTP/AVP 97
a=rtpmap:97 L16/48000/2
a=fmtp:97 emphasis=50-15
a=ptime:5
Note that the payload format (encoding) names defined in the RTP Profile [4] are commonly shown in upper case. Media subtype names are commonly shown in lower case. These names are case-insensitive in both places. Similarly, parameter names are case-insensitive both in media type strings and in the default mapping to the SDP a=fmtp attribute.
请注意，RTP概要文件[4]中定义的有效负载格式（编码）名称通常以大写形式显示。媒体子类型名称通常以小写形式显示。这些名称在两个位置都不区分大小写。类似地，参数名称在媒体类型字符串和SDP a=fmtp属性的默认映射中都不区分大小写。
This document updates RFC 3555 to conform to the revised media type registration procedures in RFC 4288 [1]. Whereas RFC 3555 required the encoding considerations to specify transfer via RTP, that is now specified under restrictions on usage. This document also specifies the conditions under which new optional parameters may be added to a previously defined RTP media type and adds a new Section 2.2 to clarify the requirements for sharing a media type among RTP and non-RTP transfer methods.
本文件更新了RFC 3555，以符合RFC 4288[1]中修订的介质类型注册程序。然而，现在需要通过RFC指定使用限制，而通过RFC指定使用限制。本文件还规定了将新的可选参数添加到先前定义的RTP介质类型的条件，并添加了新的第2.2节，以澄清RTP和非RTP传输方法之间共享介质类型的要求。
RFC 3555 included media type registrations for the RTP payload formats defined in the RTP Profile for Audio and Video Conferences, RFC 3551 [4]. Those media type registrations have been removed from this document. Some of them have been assembled into a separate companion RFC 4856 [8], leaving out those that have been, or are intended to be, registered in revisions of their own payload format specification RFCs.
RFC 3555包括音频和视频会议RTP配置文件RFC 3551[4]中定义的RTP有效负载格式的媒体类型注册。这些媒体类型注册已从此文档中删除。其中一些已组装成单独的配套RFC 4856[8]，而不包括已经或打算在其自身有效载荷格式规范RFC修订版中注册的RFC。
Philipp Hoschka is a co-author of RFC 3555; his contributions to the foundation of this document are appreciated.
Philipp Hoschka是RFC 3555的合著者；他对这份文件的贡献是值得赞赏的。
The media type registration procedure specified in this memo does not impose any security considerations on its own. Also, registrations conforming to this procedure do not themselves impose security risks. However, use of the media type being registered could very well impose security risks:
本备忘录中规定的媒体类型注册程序本身不存在任何安全问题。此外，符合此程序的注册本身不会带来安全风险。但是，使用正在注册的媒体类型很可能会带来安全风险：
o Any media type that contains "active content" imposes the risk of malicious side-effects unless execution of that content is adequately constrained.
o 任何包含“活动内容”的媒体类型都会带来恶意副作用的风险，除非该内容的执行受到充分限制。
o Several audio and video encodings are perfect for hiding data using steganography.
o 有几种音频和视频编码非常适合使用隐写术隐藏数据。
o The RTP specification, RFC 3550, provides security considerations for the transport of audio and video data over RTP, including the use of encryption where confidentiality is required.
o RTP规范RFC 3550为通过RTP传输音频和视频数据提供了安全注意事项，包括在需要保密的情况下使用加密。
Therefore, each media type registration is required to state any security considerations that apply to the use of that type. The remainder of this section is copied from RFC 4288 [1], which specifies media type registration procedures in general.
因此，每个媒体类型注册都需要说明适用于该类型使用的任何安全注意事项。本节的其余部分是从RFC 4288[1]中复制的，RFC 4288[1]一般规定了介质类型注册程序。
An analysis of security issues MUST be done for all types registered in the standards tree. A similar analysis for media types registered in the vendor or personal trees is encouraged but not required. However, regardless of what security analysis has or has not been done, all descriptions of security issues MUST be as accurate as possible regardless of registration tree. In particular, a statement that there are "no security issues associated with this type" MUST NOT be confused with "the security issues associated with this type have not been assessed".
必须对标准树中注册的所有类型进行安全问题分析。鼓励但不要求对在供应商或个人目录树中注册的媒体类型进行类似的分析。但是，无论是否进行了安全性分析，无论注册树如何，所有安全性问题的描述都必须尽可能准确。特别是，不得将“不存在与此类型相关的安全问题”的声明与“未评估与此类型相关的安全问题”混淆。
There is absolutely no requirement that media types registered in any tree be secure or completely free from risks. Nevertheless, all known security risks MUST be identified in the registration of a media type, again regardless of registration tree.
绝对不要求在任何树中注册的媒体类型是安全的或完全没有风险的。尽管如此，所有已知的安全风险都必须在媒体类型的注册中识别出来，这与注册树无关。
The security considerations section of all registrations is subject to continuing evaluation and modification, and in particular MAY be extended by use of the "comments on media types" mechanism described in RFC 4288, Section 6.
所有注册的“安全注意事项”部分将继续进行评估和修改，特别是可以使用RFC 4288第6节中描述的“媒体类型评论”机制进行扩展。
Some of the issues that should be looked at in a security analysis of a media type are:
某些媒体的安全问题应被视为：
o Complex media types may include provisions for directives that institute actions on a recipient's files or other resources. In many cases, provision is made for originators to specify arbitrary actions in an unrestricted fashion that may then have devastating effects. See the registration of the application/postscript media type in RFC 2046 [7] for an example of such directives and how they should be described in a media type registration.
o 复杂的媒体类型可能包括对收件人的文件或其他资源执行操作的指令的规定。在许多情况下，规定发起者以不受限制的方式指定可能产生毁灭性影响的任意行为。请参阅RFC 2046[7]中的应用程序/postscript媒体类型注册，以了解此类指令的示例以及在媒体类型注册中应如何描述这些指令。
o All registrations MUST state whether or not they employ such "active content", and if they do, they MUST state what steps have been taken to protect users of the media type from harm.
o 所有注册必须说明他们是否使用此类“活动内容”，如果使用，则必须说明采取了哪些措施保护媒体类型的用户免受伤害。
o Complex media types may include provisions for directives that institute actions that, while not directly harmful to the recipient, may result in disclosure of information that either facilitates a subsequent attack or else violates a recipient's privacy in some way. Again, the registration of the application/postscript media type illustrates how such directives can be handled.
o 复杂的媒体类型可能包括指令规定，这些指令虽然不会直接伤害接收者，但可能导致信息泄露，从而促进后续攻击或以某种方式侵犯接收者的隐私。同样，应用程序/postscript媒体类型的注册说明了如何处理此类指令。
o A media type that employs compression may provide an opportunity for sending a small amount of data that, when received and evaluated, expands enormously to consume all of the recipient's resources. All media types SHOULD state whether or not they employ compression, and if they do they should discuss what steps need to be taken to avoid such attacks.
o 采用压缩的媒体类型可能会提供发送少量数据的机会，这些数据在接收和评估时会极大地扩展以消耗接收者的所有资源。所有媒体类型都应说明是否使用压缩，如果使用压缩，则应讨论需要采取哪些步骤来避免此类攻击。
o A media type might be targeted for applications that require some sort of security assurance but not provide the necessary security mechanisms themselves. For example, a media type could be defined for storage of confidential medical information that in turn requires an external confidentiality service or is designed for use only within a secure environment.
o 媒体类型可能针对需要某种安全保证但本身不提供必要安全机制的应用程序。例如，可以定义媒体类型来存储机密医疗信息，而机密医疗信息又需要外部保密服务，或者设计为仅在安全环境中使用。
The purpose of this document is to specify the requirements and procedures for registering RTP payload formats in the IANA media type registry. No registrations are defined here.
本文件旨在规定在IANA媒体类型注册表中注册RTP有效负载格式的要求和程序。此处未定义任何注册。
[1] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December, 2005.
[1] Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
[2] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 35502003年7月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003.
[4] Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，RFC 3551，2003年7月。
[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] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[6] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[7] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[8] Casner, S., "Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences", RFC 4856, February 2007.
[8] Casner，S.，“音频和视频会议RTP配置文件中有效载荷格式的媒体类型注册”，RFC 4856，2007年2月。
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编辑功能的资金目前由互联网协会提供。