Network Working Group D. Singer
Request for Comments: 5285 Apple, Inc.
Category: Standards Track H. Desineni
Qualcomm
July 2008
Network Working Group D. Singer
Request for Comments: 5285 Apple, Inc.
Category: Standards Track H. Desineni
Qualcomm
July 2008
A General Mechanism for RTP Header Extensions
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）。本备忘录的分发不受限制。
Abstract
摘要
This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session.
本文档提供了使用RTP（实时传输协议）的头扩展特性的一般机制。它提供了在每个RTP数据包中使用少量小扩展的选项，其中可能的扩展范围很大，并且注册不集中。会话中使用的实际扩展将在该会话的设置信息中发出信号。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2
3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Packet Design . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.2. One-Byte Header . . . . . . . . . . . . . . . . . . . . . 5
4.3. Two-Byte Header . . . . . . . . . . . . . . . . . . . . . 6
5. SDP Signaling Design . . . . . . . . . . . . . . . . . . . . . 7
6. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. Identifier Space for IANA to Manage . . . . . . . . . . . 13
9.2. Registration of the SDP extmap Attribute . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. Normative References . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2
3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Packet Design . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.2. One-Byte Header . . . . . . . . . . . . . . . . . . . . . 5
4.3. Two-Byte Header . . . . . . . . . . . . . . . . . . . . . 6
5. SDP Signaling Design . . . . . . . . . . . . . . . . . . . . . 7
6. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. Identifier Space for IANA to Manage . . . . . . . . . . . 13
9.2. Registration of the SDP extmap Attribute . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. Normative References . . . . . . . . . . . . . . . . . . . . . 15
The RTP specification [RFC3550] provides a capability to extend the RTP header. It defines the header extension format and rules for its use in Section 5.3.1. The existing header extension method permits at most one extension per RTP packet, identified by a 16-bit identifier and a 16-bit length field specifying the length of the header extension in 32-bit words.
RTP规范[RFC3550]提供了扩展RTP报头的功能。第5.3.1节定义了标题扩展格式及其使用规则。现有的报头扩展方法允许每个RTP数据包最多有一个扩展，由一个16位标识符和一个16位长度字段标识，该字段以32位字指定报头扩展的长度。
This mechanism has two conspicuous drawbacks. First, it permits only one header extension in a single RTP packet. Second, the specification gives no guidance as to how the 16-bit header extension identifiers are allocated to avoid collisions.
这种机制有两个明显的缺点。首先，它只允许单个RTP数据包中有一个报头扩展。其次，该规范没有给出如何分配16位报头扩展标识符以避免冲突的指导。
This specification removes the first drawback by defining a backward-compatible and extensible means to carry multiple header extension elements in a single RTP packet. It removes the second drawback by defining that these extension elements are named by URIs, defining an IANA registry for extension elements defined in IETF specifications, and a Session Description Protocol (SDP) method for mapping between the naming URIs and the identifier values carried in the RTP packets.
本规范通过定义向后兼容和可扩展的方式来在单个RTP数据包中携带多个报头扩展元素，从而消除了第一个缺点。它通过定义这些扩展元素由URI命名，为IETF规范中定义的扩展元素定义IANA注册表，以及用于命名URI和RTP数据包中携带的标识符值之间映射的会话描述协议（SDP）方法，消除了第二个缺点。
This header extension applies to RTP/AVP (the Audio/Visual Profile) and its extensions.
此标头扩展适用于RTP/AVP（音频/视频配置文件）及其扩展。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The goal of this design is to provide a simple mechanism whereby multiple identified extensions can be used in RTP packets, without the need for formal registration of those extensions but nonetheless avoiding collision.
此设计的目标是提供一种简单的机制，使多个已识别的扩展可以在RTP数据包中使用，而无需对这些扩展进行正式注册，但仍然可以避免冲突。
This mechanism provides an alternative to the practice of burying associated metadata into the media format bit stream. This has often been done in media data sent over fixed-bandwidth channels. Once this is done, a decoder for the specific media format is required to extract the metadata. Also, depending on the media format, the metadata may need to be added at the time of encoding the media so that the bit-rate required for the metadata is taken into account. But the metadata may not be known at that time. Inserting metadata at a later time can require a decode and re-encode to meet bit-rate requirements.
该机制提供了一种替代将相关元数据嵌入媒体格式比特流的做法。这通常在通过固定带宽通道发送的媒体数据中完成。完成此操作后，需要特定媒体格式的解码器来提取元数据。此外，根据媒体格式，可能需要在编码媒体时添加元数据，以便考虑元数据所需的比特率。但当时可能还不知道元数据。稍后插入元数据可能需要解码和重新编码以满足比特率要求。
In some cases, a more appropriate, higher-level mechanism may be available, and if so, it should be used. For cases where a higher-level mechanism is not available, it is better to provide a mechanism at the RTP level than have the metadata be tied to a specific form of media data.
在某些情况下，可能会有更合适、更高级别的机制，如果是这样，就应该使用。对于高级机制不可用的情况，最好在RTP级别提供机制，而不是将元数据绑定到特定形式的媒体数据。
The following design is fit into the "header extension" of the RTP extension, as described above.
如上所述，以下设计适合RTP扩展的“头扩展”。
The presence and format of this header extension and its contents are negotiated or defined out-of-band, such as through signaling (see below for SDP signaling). The value defined for an RTP extension (defined below for the one-byte and two-byte header forms) is only an architectural constant (e.g., for use by network analyzers); it is the negotiation/definition (e.g., in SDP) that is the definitive indication that this header extension is present.
该报头扩展及其内容的存在和格式在带外协商或定义，例如通过信令（SDP信令见下文）。为RTP扩展定义的值（以下为单字节和双字节头形式定义）仅为体系结构常量（例如，供网络分析仪使用）；协商/定义（例如，在SDP中）是该报头扩展存在的最终指示。
This specification inherits the requirement from the RTP specification that the header extension "is designed so that the header extension may be ignored". To be specific, header extensions using this specification MUST only be used for data that can safely be ignored by the recipient without affecting interoperability, and MUST NOT be used when the presence of the extension has changed the form or nature of the rest of the packet in a way that is not compatible with the way the stream is signaled (e.g., as defined by the payload type). Valid examples might include metadata that is additional to the usual RTP information.
本规范继承了RTP规范的要求，即标题扩展“设计为可以忽略标题扩展”。具体而言，使用本规范的报头扩展必须仅用于接收方可以安全忽略而不影响互操作性的数据，并且不得在扩展的存在以与流信号发送方式不兼容的方式改变了数据包其余部分的形式或性质时使用（例如，由有效负载类型定义）。有效示例可能包括通常RTP信息之外的元数据。
The RTP header extension is formed as a sequence of extension elements, with possible padding. Each extension element has a local identifier and a length. The local identifiers may be mapped to a larger namespace in the negotiation (e.g., session signaling).
RTP报头扩展是由一系列扩展元素组成的，可能有填充。每个扩展元素都有一个本地标识符和一个长度。本地标识符可以映射到协商中的较大名称空间（例如，会话信令）。
As is good network practice, data should only be transmitted when needed. The RTP header extension should only be present in a packet if that packet also contains one or more extension elements, as defined here. An extension element should only be present in a packet when needed; the signaling setup of extension elements indicates only that those elements may be present in some packets, not that they are in fact present in all (or indeed, any) packets.
按照良好的网络实践，数据只应在需要时传输。RTP报头扩展只应该出现在一个包中，如果该包还包含一个或多个扩展元素，如这里定义的。扩展元素只应在需要时出现在数据包中；扩展元素的信令设置仅指示那些元素可能存在于一些分组中，而不是它们实际上存在于所有（或实际上任何）分组中。
Each extension element in a packet has a local identifier (ID) and a length. The local identifiers present in the stream MUST have been negotiated or defined out-of-band. There are no static allocations
数据包中的每个扩展元素都有一个本地标识符（ID）和一个长度。流中存在的本地标识符必须在带外协商或定义。没有静态分配
of local identifiers. Each distinct extension MUST have a unique ID. The value 0 is reserved for padding and MUST NOT be used as a local identifier.
本地标识符的定义。每个不同的扩展必须具有唯一的ID。值0保留用于填充，不能用作本地标识符。
There are two variants of the extension: one-byte and two-byte headers. Since it is expected that (a) the number of extensions in any given RTP session is small and (b) the extensions themselves are small, the one-byte header form is preferred and MUST be supported by all receivers. A stream MUST contain only one-byte or two-byte headers: they MUST NOT be mixed within a stream. Transmitters SHOULD NOT use the two-byte form when all extensions are small enough for the one-byte header form.
扩展有两种变体：一个字节和两个字节头。由于预期（a）任何给定RTP会话中的扩展数量较小，（b）扩展本身较小，因此首选单字节报头形式，并且必须由所有接收器支持。流必须只包含一个字节或两个字节的头：它们不能在流中混合。当所有扩展都足够小，可以使用单字节头格式时，变送器不应使用双字节格式。
A sequence of extension elements, possibly with padding, forms the header extension defined in the RTP specification. There are as many extension elements as fit into the length as indicated in the RTP header extension length. Since this length is signaled in full 32- bit words, padding bytes are used to pad to a 32-bit boundary. The entire extension is parsed byte-by-byte to find each extension element (no alignment is required), and parsing stops at the earlier of the end of the entire header extension, or, in one-byte headers, on encountering an identifier with the reserved value of 15.
一系列扩展元素（可能带有填充）构成RTP规范中定义的头扩展。有尽可能多的扩展元素适合RTP标头扩展长度中指示的长度。由于此长度以完整的32位字表示，因此填充字节用于填充到32位边界。对整个扩展进行逐字节分析，以查找每个扩展元素（不需要对齐），并在整个头扩展结束时的较早位置停止分析，或者在单字节头中，在遇到保留值为15的标识符时停止分析。
In both forms, padding bytes have the value of 0 (zero). They may be placed between extension elements, if desired for alignment, or after the last extension element, if needed for padding. A padding byte does not supply the ID of an element, nor the length field. When a padding byte is found, it is ignored and the parser moves on to interpreting the next byte.
在这两种形式中，填充字节的值均为0（零）。如果需要对齐，可以将它们放置在扩展元素之间，如果需要填充，可以将它们放置在最后一个扩展元素之后。填充字节不提供元素的ID，也不提供长度字段。当找到一个填充字节时，它将被忽略，解析器将继续解释下一个字节。
Note carefully that the one-byte header form allows for data lengths between 1 and 16 bytes, by adding 1 to the signaled length value (thus, 0 in the length field indicates 1 byte of data follows). This allows for the important case of 16-byte payloads. This addition is not performed for the two-byte headers, where the length field signals data lengths between 0 and 255 bytes.
请注意，单字节头形式允许数据长度在1到16字节之间，方法是将1添加到信号长度值（因此，长度字段中的0表示后面有1字节的数据）。这允许16字节有效负载的重要情况。对于双字节头不执行此添加，其中长度字段表示数据长度介于0和255字节之间。
Use of RTP header extensions will reduce the efficiency of RTP header compression, since the header extension will be sent uncompressed unless the RTP header compression module is updated to recognize the extension header. If header extensions are present in some packets, but not in others, this can also reduce compression efficiency by requiring an update to the fixed header to be conveyed when header extensions start or stop being sent. The interactions of the RTP header extension and header compression is explored further in [RFC2508] and [RFC3095].
使用RTP报头扩展将降低RTP报头压缩的效率，因为除非更新RTP报头压缩模块以识别扩展报头，否则报头扩展将以未压缩的方式发送。如果在某些数据包中存在报头扩展，但在其他数据包中不存在报头扩展，这也会降低压缩效率，因为在发送报头扩展开始或停止时，需要传输对固定报头的更新。[RFC2508]和[RFC3095]进一步探讨了RTP报头扩展和报头压缩的相互作用。
In the one-byte header form of extensions, the 16-bit value required by the RTP specification for a header extension, labeled in the RTP specification as "defined by profile", takes the fixed bit pattern 0xBEDE (the first version of this specification was written on the feast day of the Venerable Bede).
在扩展的单字节头形式中，RTP规范要求的头扩展的16位值（在RTP规范中标记为“由概要文件定义”）采用固定位模式0xBEDE（本规范的第一个版本是在古老的Bede节日编写的）。
Each extension element starts with a byte containing an ID and a length:
每个扩展元素都以包含ID和长度的字节开头：
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| ID | len |
+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| ID | len |
+-+-+-+-+-+-+-+-+
The 4-bit ID is the local identifier of this element in the range 1-14 inclusive. In the signaling section, this is referred to as the valid range.
4位ID是该元素的本地标识符，范围为1-14（含1-14）。在信令部分，这被称为有效范围。
The local identifier value 15 is reserved for future extension and MUST NOT be used as an identifier. If the ID value 15 is encountered, its length field should be ignored, processing of the entire extension should terminate at that point, and only the extension elements present prior to the element with ID 15 considered.
本地标识符值15保留用于将来的扩展，不得用作标识符。如果遇到ID值15，则应忽略其长度字段，整个扩展的处理应在该点终止，并且仅考虑ID为15的元素之前存在的扩展元素。
The 4-bit length is the number minus one of data bytes of this header extension element following the one-byte header. Therefore, the value zero in this field indicates that one byte of data follows, and a value of 15 (the maximum) indicates element data of 16 bytes. (This permits carriage of 16-byte values, which is a common length of labels and identifiers, while losing the possibility of zero-length values -- which would often be padded anyway.)
4位长度是一个字节头之后的该头扩展元素的数据字节数减去一个字节。因此，该字段中的值0表示后面跟着一个字节的数据，值15（最大值）表示16字节的元素数据。（这允许携带16字节的值，这是标签和标识符的公共长度，同时失去了零长度值的可能性——这通常会被填充。）
An example header extension, with three extension elements, some padding, and including the required RTP fields, follows:
示例标头扩展包含三个扩展元素、一些填充，并包括所需的RTP字段，如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xBE | 0xDE | length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | L=0 | data | ID | L=1 | data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...data | 0 (pad) | 0 (pad) | ID | L=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xBE | 0xDE | length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | L=0 | data | ID | L=1 | data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...data | 0 (pad) | 0 (pad) | ID | L=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the two-byte header form, the 16-bit value required by the RTP specification for a header extension, labeled in the RTP specification as "defined by profile", is defined as shown below.
在双字节报头格式中，RTP规范要求的报头扩展所需的16位值（在RTP规范中标记为“由概要文件定义”）定义如下所示。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x100 |appbits|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x100 |appbits|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The appbits field is 4 bits that are application-dependent and may be defined to be any value or meaning, and are outside the scope of this specification. For the purposes of signaling, this field is treated as a special extension value assigned to the local identifier 256. If no extension has been specified through configuration or signaling for this local identifier value 256, the appbits field SHOULD be set to all 0s by the sender and MUST be ignored by the receiver.
appbits字段为4位，取决于应用程序，可定义为任何值或含义，不在本规范范围内。为了信令的目的，该字段被视为分配给本地标识符256的特殊扩展值。如果未通过配置或信令为此本地标识符值256指定扩展名，则发送方应将appbits字段设置为所有0，接收方必须忽略该字段。
Each extension element starts with a byte containing an ID and a byte containing a length:
每个扩展元素以一个包含ID的字节和一个包含长度的字节开头：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 8-bit ID is the local identifier of this element in the range 1-255 inclusive. In the signaling section, the range 1-256 is referred to as the valid range, with the values 1-255 referring to extension elements, and the value 256 referring to the 4-bit field 'appbits' (above).
8位ID是该元素的本地标识符，范围为1-255（含1-255）。在信令部分中，范围1-256被称为有效范围，值1-255表示扩展元素，值256表示4位字段“appbits”（如上）。
The 8-bit length field is the length of extension data in bytes not including the ID and length fields. The value zero indicates there is no data following.
8位长度字段是扩展数据的长度（字节），不包括ID和长度字段。值为零表示后面没有数据。
An example header extension, with three extension elements, some padding, and including the required RTP fields, follows:
示例标头扩展包含三个扩展元素、一些填充，并包括所需的RTP字段，如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x10 | 0x00 | length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | L=0 | ID | L=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data | 0 (pad) | ID | L=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x10 | 0x00 | length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | L=0 | ID | L=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data | 0 (pad) | ID | L=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The indication of the presence of this extension, and the mapping of local identifiers used in the header extension to a larger namespace, MUST be performed out-of-band, for example, as part of a SIP offer/ answer exchange using SDP. This section defines such signaling in SDP.
必须在带外（例如，作为使用SDP的SIP提供/应答交换的一部分）执行该扩展存在的指示，以及在报头扩展中使用的本地标识符到更大名称空间的映射。本节定义了SDP中的此类信令。
A usable mapping MUST use IDs in the valid range, and each ID in this range MUST be used only once for each media (or only once if the mappings are session level). Mappings that do not conform to these rules MAY be presented, for instance, during offer/answer negotiation as described in the next section, but remapping to conformant values is necessary before they can be applied.
可用映射必须使用有效范围内的ID，并且此范围内的每个ID对于每个媒体只能使用一次（如果映射是会话级别的，则只能使用一次）。不符合这些规则的映射可能会在下一节所述的提供/应答协商期间出现，但在应用它们之前，必须重新映射到一致的值。
Each extension is named by a URI. That URI MUST be absolute, and precisely identifies the format and meaning of the extension. URIs that contain a domain name SHOULD also contain a month-date in the form mmyyyy. The definition of the element and assignment of the URI MUST have been authorized by the owner of the domain name on or very
每个扩展都由一个URI命名。该URI必须是绝对的，并且精确地标识扩展的格式和含义。包含域名的URI还应包含格式为mmyyyy的月份日期。元素的定义和URI的分配必须由域名所有者在或非常早之前授权
close to that date. (This avoids problems when domain names change ownership.) If the resource or document defines several extensions, then the URI MUST identify the actual extension in use, e.g., using a fragment or query identifier (characters after a '#' or '?' in the URI).
接近那个日期。（这避免了域名更改所有权时出现问题。）如果资源或文档定义了多个扩展，则URI必须标识正在使用的实际扩展，例如，使用片段或查询标识符（URI中“#”或“？”后面的字符）。
Rationale: the use of URIs provides for a large, unallocated space,
理由：URI的使用提供了大量未分配的空间，
and gives documentation on the extension. The URIs are not required to be de-referencable, in order to permit confidential or experimental use, and to cover the case when extensions continue to be used after the organization that defined them ceases to exist.
并给出了扩展的文档。URI不需要是可取消引用的，以允许机密或实验性使用，并涵盖在定义它们的组织不再存在后继续使用扩展的情况。
An extension URI with the same attributes MUST NOT appear more than once applying to the same stream, i.e., at session level or in the declarations for a single stream at media level. (The same extension may, of course, be used for several streams, and may appear differently parameterized for the same stream.)
具有相同属性的扩展URI不得多次出现在应用于同一流的扩展URI中，即在会话级别或在媒体级别的单个流声明中。（当然，同一扩展可以用于多个流，并且对于同一个流，可能会出现不同的参数化。）
For extensions defined in RFCs, the URI used SHOULD be a URN starting "urn:ietf:params:rtp-hdrext:" and followed by a registered, descriptive name.
对于RFCs中定义的扩展，使用的URI应该是以“URN:ietf:params:rtp hdrext:”开头的URN，后跟注册的描述性名称。
The registration requirements are detailed in the IANA Considerations section, below.
注册要求详见下文IANA注意事项部分。
An example (this is only an example), where 'avt-example-metadata' is the hypothetical name of a header extension, might be:
示例（这只是一个示例），“avt example metadata”是头扩展的假设名称，可能是：
urn:ietf:params:rtp-hdrext:avt-example-metadata
urn:ietf:params:rtp-hdrext:avt-example-metadata
An example name not from the IETF (this is only an example) might be:
不是来自IETF的示例名称（这只是一个示例）可能是：
http://example.com/082005/ext.htm#example-metadata
http://example.com/082005/ext.htm#example-metadata
The mapping may be provided per media stream (in the media-level section(s) of SDP, i.e., after an "m=" line) or globally for all streams (i.e., before the first "m=" line, at session level). The definitions MUST be either all session level or all media level; it is not permitted to mix the two styles. In addition, as noted above, the IDs used MUST be unique for each stream type for a given media, or for the session for session-level declarations.
可以针对每个媒体流（在SDP的媒体级部分中，即在“m=”行之后）或针对所有流（即在会话级的第一个“m=”行之前）提供映射。定义必须是所有会话级别或所有媒体级别；不允许混合使用这两种样式。此外，如上所述，对于给定媒体的每种流类型或会话级别声明的会话，所使用的ID必须是唯一的。
Each local identifier potentially used in the stream is mapped to a string using an attribute of the form:
流中可能使用的每个本地标识符使用以下形式的属性映射到字符串：
a=extmap:<value>["/"<direction>] <URI> <extensionattributes>
a=extmap:<value>["/"<direction>] <URI> <extensionattributes>
where <URI> is a URI, as above, <value> is the local identifier (ID) of this extension and is an integer in the valid range inclusive (0 is reserved for padding in both forms, and 15 is reserved in the one-byte header form, as noted above), and <direction> is one of "sendonly", "recvonly", "sendrecv", or "inactive" (without the quotes).
其中，<URI>是URI，如上所述，<value>是此扩展的本地标识符（ID），并且是有效范围内的整数（包括在内）（0保留为两种形式的填充，15保留为单字节头形式，如上所述），<direction>是“sendonly”、“recvoOnly”、“sendrecv”或“inactive”（不带引号）之一。
The formal BNF syntax is presented in a later section of this specification.
正式的BNF语法将在本规范的后面部分介绍。
Example:
例子：
a=extmap:1 http://example.com/082005/ext.htm#ttime
a=extmap:1 http://example.com/082005/ext.htm#ttime
a=extmap:2/sendrecv http://example.com/082005/ext.htm#xmeta short
a=extmap:2/sendrecv http://example.com/082005/ext.htm#xmeta short
When SDP signaling is used for the RTP session, it is the presence of the 'extmap' attribute(s) that is diagnostic that this style of header extensions is used, not the magic number indicated above.
当SDP信令用于RTP会话时，“extmap”属性的存在可以诊断是否使用了这种类型的报头扩展，而不是上面所示的幻数。
The simple signaling described above may be enhanced in an offer/ answer context, to permit:
可以在提供/应答上下文中增强上述简单信令，以允许：
o asymmetric behavior (extensions sent in only one direction),
o 不对称行为（仅向一个方向发送扩展），
o the offer of mutually exclusive alternatives, or
o 提供相互排斥的备选方案，或
o the offer of more extensions than can be sent in a single session.
o 提供的扩展超过了单个会话中可以发送的扩展。
A direction attribute MAY be included in an extmap; without it, the direction implicitly inherits, of course, from the stream direction, or is "sendrecv" for session-level attributes or extensions of "inactive" streams. The direction MUST be one of "sendonly", "recvonly", "sendrecv", or "inactive". A "sendonly" direction indicates an ability to send; a "recvonly" direction indicates a desire to receive; a "sendrecv" direction indicates both. An "inactive" direction indicates neither, but later re-negotiation may make an extension active.
方向属性可以包括在extmap中；没有它，方向当然会隐式地从流方向继承，或者对于会话级属性或“非活动”流的扩展是“sendrecv”。方向必须是“仅发送”、“仅接收”、“发送接收”或“不活动”之一。“sendonly”方向表示发送的能力；“recvonly”方向表示接收的愿望；“sendrecv”方向指示这两个方向。“非活动”方向表示两者都不存在，但稍后重新协商可能会激活扩展。
Extensions, with their directions, may be signaled for an "inactive" stream. It is an error to use an extension direction incompatible with the stream direction (e.g., a "sendonly" attribute for a "recvonly" stream).
可针对“非活动”流向扩展及其方向发送信号。使用与流方向不兼容的扩展方向（例如，“recvonly”流的“sendonly”属性）是错误的。
If an offer or answer contains session-level mappings (and hence no media-level mappings), and different behavior is desired for each stream, then the entire set of extension map declarations may be moved into the media-level section(s) of the SDP. (Note that this specification does not permit mixing global and local declarations, to make identifier management easier.)
如果提供或应答包含会话级映射（因此没有媒体级映射），并且每个流需要不同的行为，那么可以将整个扩展映射声明集移动到SDP的媒体级部分。（请注意，本规范不允许混合使用全局声明和本地声明，以便于标识符管理。）
If an extension map is offered as "sendrecv", explicitly or implicitly, and asymmetric behavior is desired, the SDP may be modified to modify or add direction qualifiers for that extension. If an extension is marked as "sendonly" and the answerer desires to receive it, the extension MUST be marked as "recvonly" in the SDP answer. An answerer that has no desire to receive the extension or does not understand the extension SHOULD remove it from the SDP answer.
如果扩展映射显式或隐式地作为“sendrecv”提供，并且需要不对称行为，则可以修改SDP以修改或添加该扩展的方向限定符。如果分机标记为“sendonly”，且应答者希望接收该分机，则必须在SDP应答中将该分机标记为“RecvoOnly”。如果回答者不希望收到分机或不理解分机，则应将其从SDP回答中删除。
If an extension is marked as "recvonly" and the answerer desires to send it, the extension MUST be marked as "sendonly" in the SDP answer. An answerer that has no desire to, or is unable to, send the extension SHOULD remove it from the SDP answer.
如果分机标记为“recvonly”，且应答者希望发送该分机，则必须在SDP应答中将该分机标记为“sendonly”。不希望或无法发送分机的应答者应将其从SDP应答中删除。
Local identifiers in the valid range inclusive in an offer or answer must not be used more than once per media section (including the session-level section). A session update MAY change the direction qualifiers of extensions under use. A session update MAY add or remove extension(s). Identifiers values in the valid range MUST NOT be altered (remapped).
每个媒体部分（包括会话级别部分）不得多次使用报价或应答中包含的有效范围内的本地标识符。会话更新可能会更改正在使用的扩展的方向限定符。会话更新可以添加或删除扩展。有效范围内的标识符值不得更改（重新映射）。
Note that, under this rule, the same local identifier cannot be used for two extensions for the same media, even when one is "sendonly" and the other "recvonly", as it would then be impossible to make either of them sendrecv (since re-numbering is not permitted either).
请注意，在此规则下，同一本地标识符不能用于同一媒体的两个扩展，即使其中一个是“sendonly”而另一个是“RecVoOnly”，因为这样就不可能使其中任何一个发送RECV（因为也不允许重新编号）。
If a party wishes to offer mutually exclusive alternatives, then multiple extensions with the same identifier in the (unusable) range 4096-4351 may be offered; the answerer should select at most one of the offered extensions with the same identifier, and remap it to a free identifier in the valid range, for that extension to be usable.
如果一方希望提供相互排斥的备选方案，则可提供（不可用）范围4096-4351中具有相同标识符的多个扩展；应答者应最多选择一个具有相同标识符的扩展，并将其重新映射到有效范围内的自由标识符，以使该扩展可用。
Similarly, if more extensions are offered than can be fit in the valid range, identifiers in the range 4096-4351 may be offered; the answerer should choose those that are desired, and remap them to a free identifier in the valid range.
类似地，如果提供的扩展超过了有效范围内的扩展，则可以提供4096-4351范围内的标识符；回答者应选择所需的，并将其重新映射到有效范围内的自由标识符。
It is always allowed to place the offered identifier value "as is" in the SDP answer (for example, due to lack of a free identifier value in the valid range). Extensions with an identifier outside the valid range cannot, of course, be used. If required, the offerer or answerer can update the session to make space for such an extension.
始终允许将提供的标识符值“按原样”放在SDP答案中（例如，由于有效范围内缺少自由标识符值）。标识符超出有效范围的扩展当然不能使用。如果需要，报价人或应答人可以更新会话，为此类扩展腾出空间。
Rationale: the range 4096-4351 for these negotiation identifiers is deliberately restricted to allow expansion of the range of valid identifiers in future.
理由：有意限制这些协商标识符的4096-4351范围，以允许将来扩展有效标识符的范围。
Either party MAY include extensions in the stream other than those negotiated, or those negotiated as "inactive", for example, for the benefit of intermediate nodes. Only extensions that appeared with an identifier in the valid range in SDP originated by the sender can be sent.
例如，为了中间节点的利益，任一方可以在流中包括除协商的扩展或协商为“非活动”的扩展之外的扩展。只能发送在发送方发起的SDP中标识符在有效范围内的扩展名。
Example (port numbers, RTP profiles, payload IDs and rtpmaps, etc. all omitted for brevity):
示例（端口号、RTP配置文件、有效负载ID和RTPMAP等，为简洁起见全部省略）：
The offer:
报价：
a=extmap:1 URI-toffset
a=extmap:14 URI-obscure
a=extmap:4096 URI-gps-string
a=extmap:4096 URI-gps-binary
a=extmap:4097 URI-frametype
m=video
a=sendrecv
m=audio
a=sendrecv
a=extmap:1 URI-toffset
a=extmap:14 URI-obscure
a=extmap:4096 URI-gps-string
a=extmap:4096 URI-gps-binary
a=extmap:4097 URI-frametype
m=video
a=sendrecv
m=audio
a=sendrecv
The answerer is interested in receiving GPS in string format only on video, but cannot send GPS at all. It is not interested in transmission offsets on audio, and does not understand the URI-obscure extension. It therefore moves the extensions from session level to media level, and adjusts the declarations:
回答者只想在视频上接收字符串格式的GPS，但根本无法发送GPS。它对音频上的传输偏移不感兴趣，也不理解URI扩展。因此，它将扩展从会话级别移动到媒体级别，并调整声明：
m=video
a=sendrecv
a=extmap:1 URI-toffset
a=extmap:2/recvonly URI-gps-string
a=extmap:3 URI-frametype
m=audio
a=sendrecv
a=extmap:1/sendonly URI-toffset
m=video
a=sendrecv
a=extmap:1 URI-toffset
a=extmap:2/recvonly URI-gps-string
a=extmap:3 URI-frametype
m=audio
a=sendrecv
a=extmap:1/sendonly URI-toffset
The syntax definition below uses ABNF according to [RFC5234]. The syntax element 'URI' is defined in [RFC3986] (only absolute URIs are permitted here). The syntax element 'extmap' is an attribute as defined in [RFC4566], i.e., "a=" precedes the extmap definition. Specific extensionattributes are defined by the specification that defines a specific extension name; there may be several.
下面的语法定义根据[RFC5234]使用ABNF。[RFC3986]中定义了语法元素“URI”（此处仅允许绝对URI）。语法元素“extmap”是[RFC4566]中定义的属性，即“a=”位于extmap定义之前。特定的ExtensionAttribute由定义特定扩展名的规范定义；可能有几个。
extmap = mapentry SP extensionname [SP extensionattributes]
extmap=mapentry SP extensionname[SP extensionattributes]
extensionname = URI
extensionname = URI
direction = "sendonly" / "recvonly" / "sendrecv" / "inactive"
direction = "sendonly" / "recvonly" / "sendrecv" / "inactive"
mapentry = "extmap:" 1*5DIGIT ["/" direction]
mapentry = "extmap:" 1*5DIGIT ["/" direction]
extensionattributes = byte-string
extensionattributes = byte-string
URI = <Defined in RFC 3986>
URI = <Defined in RFC 3986>
byte-string = <Defined in RFC 4566>
byte-string = <Defined in RFC 4566>
SP = <Defined in RFC 5234>
SP = <Defined in RFC 5234>
DIGIT = <Defined in RFC 5234>
DIGIT = <Defined in RFC 5234>
This defines only a place to transmit information; the security implications of the extensions must be discussed with those extensions.
这只定义了一个传输信息的地方；必须与这些扩展讨论扩展的安全含义。
Care should be taken when defining extensions. Clearly, they should be solely informative, but even when the information is extracted, should not cause security concerns.
定义扩展时应小心。显然，它们应该仅提供信息，但即使在提取信息时，也不应引起安全问题。
Header extensions have the same security coverage as the RTP header itself. When Secure Real-time Transport Protocol (SRTP) [RFC3711] is used to protect RTP sessions, the RTP payload may be both encrypted and integrity protected, while the RTP header is either unprotected or integrity protected. Therefore, it is inappropriate to place information in header extensions that cause security problems if disclosed, unless the entire RTP packet is protected by a lower-layer security protocol providing both confidentiality and integrity capability.
标头扩展与RTP标头本身具有相同的安全覆盖率。当使用安全实时传输协议（SRTP）[RFC3711]来保护RTP会话时，RTP有效负载可以是加密的，也可以是完整性保护的，而RTP报头要么是未保护的，要么是完整性保护的。因此，除非整个RTP数据包受到提供机密性和完整性能力的较低层安全协议的保护，否则不适合将信息放置在导致安全问题的报头扩展中。
The mapping from the naming URI form to a reference to a specification is managed by IANA. Insertion into this registry is under the requirements of "Expert Review" as defined in [RFC5226].
从命名URI表单到规范引用的映射由IANA管理。根据[RFC5226]中定义的“专家评审”要求，将其插入本登记册。
The IANA will also maintain a server that contains all of the registered elements in a publicly accessible space.
IANA还将维护一个服务器，该服务器包含一个公共可访问空间中的所有已注册元素。
Here is the formal declaration required by the IETF URN Sub-namespace specification [RFC3553].
以下是IETF URN子命名空间规范[RFC3553]要求的正式声明。
o Registry name: RTP Compact Header Extensions
o 注册表名称：RTP压缩头扩展
o Specification: RFC 5285 and RFCs updating RFC 5285.
o 规范：RFC 5285和RFC更新RFC 5285。
o Information required:
o 所需资料：
A. The desired extension naming URI
A.所需的扩展命名URI
B. A formal reference to the publicly available specification
B.对公开可用规范的正式引用
C. A short phrase describing the function of the extension
C.描述扩展功能的简短短语
D. Contact information for the organization or person making the registration
D.进行注册的组织或个人的联系信息
For extensions defined in RFCs, the URI is recommended to be of the form urn:ietf:params:rtp-hdrext:, and the formal reference is the RFC number of the RFC documenting the extension.
对于RFCs中定义的扩展，建议URI的格式为urn:ietf:params:rtp hdrext:，正式引用是记录扩展的RFC的RFC编号。
o Review process: Expert review is required. The expert review should check the following requirements:
o 审查过程：需要专家审查。专家评审应检查以下要求：
1. that the specification is publicly available;
1. 该规范是公开的；
2. that the extension complies with the requirements of RTP and this specification, for extensions (notably, that the stream is still decodable if the extension is ignored or not recognized);
2. 对于扩展，扩展符合RTP和本规范的要求（特别是，如果忽略或不识别扩展，则流仍然是可解码的）；
3. that the extension specification is technically consistent (in itself and with RTP), complete, and comprehensible;
3. 扩展规范在技术上是一致的（本身和RTP），完整和可理解的；
4. that the extension does not duplicate functionality in existing IETF specifications (including RTP itself), or other extensions already registered;
4. 扩展不复制现有IETF规范（包括RTP本身）或已注册的其他扩展中的功能；
5. that the specification contains a security analysis regarding the content of the header extension;
5. 该规范包含关于报头扩展的内容的安全性分析；
6. that the extension is generally applicable, for example point-to-multipoint safe, and the specification correctly describes limitations if they exist; and
6. 扩展通常适用，例如点对多点安全，规范正确描述了存在的限制；和
7. that the suggested naming URI form is appropriately chosen and unique.
7. 建议的命名URI形式选择适当且唯一。
o Size and format of entries: a mapping from a naming URI string to a formal reference to a publicly available specification, with a descriptive phrase and contact information.
o 条目的大小和格式：从命名URI字符串到正式引用到公开可用规范的映射，带有描述性短语和联系信息。
o Initial assignments: none.
o 初始作业：无。
This section contains the information required by [RFC4566] for an SDP attribute.
本节包含[RFC4566]要求的SDP属性信息。
o contact name, email address, and telephone number:
o 联系人姓名、电子邮件地址和电话号码：
D. Singer singer@apple.com +1 408-974-3162
D.辛格singer@apple.com +1 408-974-3162
o attribute name (as it will appear in SDP): extmap
o 属性名称（将在SDP中显示）：extmap
o long-form attribute name in English: generic header extension map definition
o 英文长格式属性名称：通用标题扩展映射定义
o type of attribute (session level, media level, or both): both
o 属性类型（会话级别、媒体级别或两者）：两者
o whether the attribute value is subject to the charset attribute: not subject to the charset attribute
o 属性值是否受charset属性约束：不受charset属性约束
o a one-paragraph explanation of the purpose of the attribute: This attribute defines the mapping from the extension numbers used in packet headers into extension names as documented in specifications and appropriately registered.
o 关于属性用途的一段解释：该属性定义了从数据包头中使用的分机号到规范中记录并适当注册的分机名的映射。
o a specification of appropriate attribute values for this attribute: see RFC 5285.
o 此属性的适当属性值规范：请参阅RFC 5285。
Both Brian Link and John Lazzaro provided helpful comments on an initial draft of this document. Colin Perkins was helpful in reviewing and dealing with the details. The use of URNs for IETF-defined extensions was suggested by Jonathan Lennox, and Pete Cordell was instrumental in improving the padding wording. Dave Oran provided feedback and text in the review. Mike Dolan contributed the two-byte header form. Magnus Westerlund and Tom Taylor were instrumental in managing the registration text.
Brian Link和John Lazzaro都对本文件的初稿提出了有益的意见。科林·帕金斯在审查和处理细节方面很有帮助。Jonathan Lennox建议在IETF定义的扩展中使用URN，Pete Cordell在改进填充措辞方面发挥了重要作用。Dave Oran在评论中提供了反馈和文本。Mike Dolan提供了双字节头表单。Magnus Westerlund和Tom Taylor在管理注册文本方面发挥了重要作用。
[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月。
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[RFC2508]Casner，S.和V.Jacobson，“压缩低速串行链路的IP/UDP/RTP报头”，RFC 2508，1999年2月。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3095]Bormann，C.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，L-E.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.，和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP，UDP，ESP，和未压缩”，RFC 3095，2001年7月。
[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月。
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, June 2003.
[RFC3553]Mealling，M.，Masinter，L.，Hardie，T.，和G.Klyne，“注册协议参数的IETF URN子命名空间”，BCP 73，RFC 3553，2003年6月。
[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月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[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月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
Authors' Addresses
作者地址
David Singer Apple, Inc. 1 Infinite Loop Cupertino, CA 95014 USA
David Singer苹果公司，美国加利福尼亚州库比蒂诺市无限环路1号，邮编95014
Phone: +1 408 996 1010
EMail: singer@apple.com
URI: http://www.apple.com/quicktime
Phone: +1 408 996 1010
EMail: singer@apple.com
URI: http://www.apple.com/quicktime
Harikishan Desineni Qualcomm 5775 Morehouse Drive San Diego, CA 92126 USA
美国加利福尼亚州圣地亚哥莫尔豪斯大道5775号高通公司
Phone: +1 858 845 8996
EMail: hd@qualcomm.com
URI: http://www.qualcomm.com
Phone: +1 858 845 8996
EMail: hd@qualcomm.com
URI: http://www.qualcomm.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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.