Internet Engineering Task Force (IETF) D. Singer
Request for Comments: 8285 Apple, Inc.
Obsoletes: 5285 H. Desineni
Category: Standards Track Qualcomm
ISSN: 2070-1721 R. Even, Ed.
Huawei Technologies
October 2017
Internet Engineering Task Force (IETF) D. Singer
Request for Comments: 8285 Apple, Inc.
Obsoletes: 5285 H. Desineni
Category: Standards Track Qualcomm
ISSN: 2070-1721 R. Even, Ed.
Huawei Technologies
October 2017
A General Mechanism for RTP Header Extensions
RTP报头扩展的通用机制
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 decentralized. The actual extensions in use in a session are signaled in the setup information for that session. This document obsoletes RFC 5285.
本文档提供了使用RTP（实时传输协议）的头扩展特性的一般机制。它提供了在每个RTP数据包中使用少量小扩展的选项，其中可能的扩展范围很大，注册是分散的。会话中使用的实际扩展将在该会话的设置信息中发出信号。本文件废除了RFC 5285。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8285.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8285.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Requirements Notation ...........................................3
3. Design Goals ....................................................3
4. Packet Design ...................................................4
4.1. General ....................................................4
4.1.1. Transmission Considerations .........................5
4.1.2. Header Extension Type Considerations ................6
4.2. One-Byte Header ............................................8
4.3. Two-Byte Header ............................................9
5. SDP Signaling Design ...........................................10
6. SDP Signaling for Support of Mixed One-Byte and Two-Byte
Header Extensions ..........................................12
7. SDP Offer/Answer ...............................................13
8. BNF Syntax .....................................................17
9. Security Considerations ........................................17
10. IANA Considerations ...........................................18
10.1. Identifier Space for IANA to Manage ......................18
10.2. Registration of the SDP "extmap" Attribute ...............20
10.3. Registration of the SDP "extmap-allow-mixed" Attribute ...20
11. Changes from RFC 5285 .........................................21
12. References ....................................................21
12.1. Normative References .....................................21
12.2. Informative References ...................................23
Acknowledgments ...................................................24
Authors' Addresses ................................................25
1. Introduction ....................................................3
2. Requirements Notation ...........................................3
3. Design Goals ....................................................3
4. Packet Design ...................................................4
4.1. General ....................................................4
4.1.1. Transmission Considerations .........................5
4.1.2. Header Extension Type Considerations ................6
4.2. One-Byte Header ............................................8
4.3. Two-Byte Header ............................................9
5. SDP Signaling Design ...........................................10
6. SDP Signaling for Support of Mixed One-Byte and Two-Byte
Header Extensions ..........................................12
7. SDP Offer/Answer ...............................................13
8. BNF Syntax .....................................................17
9. Security Considerations ........................................17
10. IANA Considerations ...........................................18
10.1. Identifier Space for IANA to Manage ......................18
10.2. Registration of the SDP "extmap" Attribute ...............20
10.3. Registration of the SDP "extmap-allow-mixed" Attribute ...20
11. Changes from RFC 5285 .........................................21
12. References ....................................................21
12.1. Normative References .....................................21
12.2. Informative References ...................................23
Acknowledgments ...................................................24
Authors' Addresses ................................................25
The RTP specification [RFC3550] provides a capability to extend the RTP header. Section 5.3.1 of [RFC3550] defines the header extension format and rules for its use. 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报头的功能。[RFC3550]第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 providing 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注册表，并提供会话描述协议（SDP）方法来映射命名URI和RTP数据包中携带的标识符值，从而消除了第二个缺点。
This header extension applies to RTP/AVP (the Audio/Visual Profile) and its extensions.
此标头扩展适用于RTP/AVP（音频/视频配置文件）及其扩展。
This document obsoletes [RFC5285] and removes a limitation from RFC 5285 that did not allow sending both one-byte and two-byte header extensions in the same RTP stream.
本文件废除了[RFC5285]，并从RFC 5285中删除了一个限制，即不允许在同一RTP流中同时发送单字节和双字节头扩展名。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
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 collisions.
此设计的目标是提供一种简单的机制，使多个已识别的扩展可以在RTP数据包中使用，而无需对这些扩展进行正式注册，但仍然可以避免冲突。
This mechanism provides an alternative to the practice of burying associated metadata into the media format bitstream. This has often been done in media data sent over fixed-bandwidth channels. Once
该机制提供了一种替代将相关元数据嵌入媒体格式比特流的方法。这通常在通过固定带宽通道发送的媒体数据中完成。一旦
this is done, a decoder for the specific media format needs to extract the metadata. Also, depending on the media format, the metadata can be added at the time of encoding the media so that the bit-rate used for the metadata is taken into account. But the metadata can be unknown at that time. Inserting metadata at a later time can cause a decode and re-encode to meet bit-rate requirements.
完成此操作后，特定媒体格式的解码器需要提取元数据。此外，根据媒体格式，可以在编码媒体时添加元数据，以便考虑用于元数据的比特率。但是元数据在当时可能是未知的。稍后插入元数据可能导致解码和重新编码以满足比特率要求。
In some cases, a more appropriate and higher-level mechanism may be available, and if so, it can be used. For cases where a higher-level mechanism is not available, it is better to provide a mechanism at the RTP level than to 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 16-bit identifier for the two forms of the RTP extension defined here 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扩展的16位标识符仅为架构常数（例如，供网络分析仪使用）；协商/定义（例如，在SDP中）是该报头扩展存在的最终指示。
The RTP specification [RFC3550] states that RTP "is designed so that the header extension may be ignored by other interoperating implementations that have not been extended." The intent of this restriction is that RTP header extensions MUST NOT be used to extend RTP itself in a manner that is backward incompatible with non-extended implementations. For example, a header extension is not allowed to change the meaning or interpretation of the standard RTP header fields or of the RTP Control Protocol (RTCP). Header extensions MAY carry metadata in addition to the usual RTP header information, provided the RTP layer can function if that metadata is missing. For example, RTP header extensions can be used to carry data that's also sent in RTCP, as an optimization to lower latency, since they'll fall back to the original non-optimized behavior if the header extension is not present. The use of header extensions to convey information that will, if missing, disrupt the behavior of a higher-layer application that builds on top of RTP is only acceptable if this doesn't affect interoperability at the RTP layer. For example, applications that use the SDP BUNDLE extension with the Media Identification (MID) RTP header extension [SDP-BUNDLE] to correlate RTP streams with SDP "m=" lines likely won't work with full
RTP规范[RFC3550]指出，RTP“被设计为可以被其他未扩展的互操作实现忽略头扩展。”此限制的目的是RTP头扩展不能用于以与非扩展实现向后不兼容的方式扩展RTP本身。例如，不允许标头扩展更改标准RTP标头字段或RTP控制协议（RTCP）的含义或解释。除了通常的RTP头信息之外，头扩展还可以携带元数据，前提是如果缺少元数据，RTP层可以正常工作。例如，RTP报头扩展可用于承载也在RTCP中发送的数据，作为降低延迟的优化，因为如果报头扩展不存在，它们将返回到原始的非优化行为。只有在不影响RTP层的互操作性的情况下，才可以使用头扩展来传递信息，如果信息丢失，将破坏构建在RTP之上的更高层应用程序的行为。例如，使用SDP包扩展和媒体标识（MID）RTP头扩展[SDP-BUNDLE]将RTP流与SDP“m=”行关联的应用程序可能无法使用完整的
functionality if the MID is missing, but the operation of the RTP layer of those applications will be unaffected. Support for RTP header extensions based on this memo is negotiated using, for example, SDP Offer/Answer [RFC3264]; intermediaries aware of the RTP header extensions are advised to be cautious when removing or generating RTP header extensions. See Section 4.7 of [RFC7667].
如果MID缺失，但这些应用程序的RTP层的操作将不受影响，则功能正常。基于此备忘录的RTP报头扩展支持通过使用SDP Offer/Answer[RFC3264]等协商获得；建议知道RTP头扩展的中介机构在删除或生成RTP头扩展时要小心。见[RFC7667]第4.7节。
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 can be present in some packets, not that they are in fact present in all (or indeed, any) packets.
按照良好的网络实践，数据只应在需要时传输。RTP报头扩展只应该出现在一个包中，如果该包还包含一个或多个扩展元素，如这里定义的。扩展元素只应在需要时出现在数据包中；扩展元素的信令设置仅指示那些元素可以存在于一些分组中，而不是它们实际上存在于所有（或实际上任何）分组中。
Some general considerations for getting the header extensions delivered to the receiver are as follows:
将报头扩展交付给接收方的一些一般注意事项如下：
1. The probability for packet loss and burst loss determines how many repetitions of the header extensions will be required to reach a targeted delivery probability, and if burst loss is likely, what distribution would be needed to avoid losing all repetitions of the header extensions in a single burst.
1. 分组丢失和突发丢失的概率确定需要多少次重复的报头扩展才能达到目标传递概率，如果可能发生突发丢失，则需要什么分布来避免在单个突发中丢失所有重复的报头扩展。
2. If a set of packets are all needed to enable decoding, there is commonly no reason for including the header extension in all of these packets, as they share fate. Instead, at most one instance of the header extension per independently decodable set of media data would be a more efficient use of the bandwidth.
2. 如果一组数据包都需要启用解码，则通常没有理由在所有这些数据包中包括报头扩展，因为它们共享命运。相反，每个独立可解码的媒体数据集至多有一个报头扩展实例将更有效地利用带宽。
3. How early the header extension item information is needed, from the first received RTP data or only after some set of packets are received, can guide whether the header extension(s) should be (1) in all of the first N packets or (2) included only once per set of packets -- for example, once per video frame.
3. 从第一个接收到的RTP数据或仅在接收到某组分组之后，需要多早的报头扩展项信息，可以指导报头扩展是（1）在所有前N个分组中还是（2）在每组分组中仅包括一次——例如，每视频帧一次。
4. The use of RTP-level robustness mechanisms, such as RTP retransmission [RFC4588] or Forward Error Correction (e.g., [RFC5109]) may treat packets differently from a robustness perspective, and header extensions should be added to packets that get a treatment corresponding to the relative importance of receiving the information.
4. RTP级健壮性机制的使用，例如RTP重传[RFC4588]或前向纠错（例如，[RFC5109]）可以从健壮性的角度不同地处理分组，并且应当向获得与接收信息的相对重要性相对应的处理的分组添加报头扩展。
As a summary, the number of header extension transmissions should be tailored to a desired probability of delivery, taking the receiver population size into account. For the very basic case, N repetitions of the header extensions should be sufficient but may not be optimal. N is selected so that the header extension target delivery probability reaches 1-P^N, where P is the probability of packet loss. For point-to-point or small receiver populations, it might also be possible to use feedback, such as RTCP, to determine when the information in the header extensions has reached all receivers and stop further repetitions. Feedback that can be used includes the RTCP Extended Report (XR) Loss RLE Report Block [RFC3611], which will indicate successful delivery of particular packets. If the RTP/AVPF transport-layer feedback messages for generic NACK [RFC4585] are used, they can indicate failure to deliver an RTP packet with the header extension, thus indicating the need for further repetitions. The normal RTCP report blocks can also provide an indicator of successful delivery, if no losses are indicated for a reporting interval covering the RTP packets with the header extension. Note that loss of an RTCP packet reporting on an interval where RTP header extension packets were sent does not necessarily mean that the RTP header extension packets themselves were lost.
总之，报头扩展传输的数量应根据期望的交付概率进行调整，同时考虑接收机总体大小。对于非常基本的情况，重复N次报头扩展应该足够了，但可能不是最优的。选择N使得报头扩展目标传送概率达到1-P^N，其中P是分组丢失的概率。对于点对点或小型接收器群体，也可以使用反馈（如RTCP）来确定报头扩展中的信息何时到达所有接收器并停止进一步重复。可使用的反馈包括RTCP扩展报告（XR）丢失RLE报告块[RFC3611]，它将指示特定数据包的成功传递。如果使用通用NACK[RFC4585]的RTP/AVPF传输层反馈消息，则它们可以指示未能交付具有报头扩展的RTP分组，从而指示需要进一步重复。正常RTCP报告块还可以提供成功传递的指示器，前提是在覆盖具有报头扩展名的RTP数据包的报告间隔内未指示任何丢失。请注意，在发送RTP报头扩展数据包的间隔上报告RTCP数据包丢失并不一定意味着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 of local identifiers. Each distinct extension MUST have a unique ID. The ID value 0 is reserved for padding and MUST NOT be used as a local identifier.
数据包中的每个扩展元素都有一个本地标识符（ID）和一个长度。流中存在的本地标识符必须在带外协商或定义。本地标识符没有静态分配。每个不同的扩展必须具有唯一的ID。ID值0保留用于填充，不能用作本地标识符。
An extension element with an ID value equal to 0 MUST NOT have an associated length field greater than 0. If such an extension element is encountered, its length field MUST be ignored, processing of the entire extension MUST terminate at that point, and only the extension elements present prior to the element with ID 0 and a length field greater than 0 SHOULD be considered.
ID值等于0的扩展元素的关联长度字段不得大于0。如果遇到这样的扩展元素，则必须忽略其长度字段，整个扩展的处理必须在该点终止，并且只应考虑ID为0且长度字段大于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
扩展有两种变体：一个字节和两个字节头。因为预期（a）任何给定RTP会话中的扩展数量都很小，（b）扩展本身很小
small, the one-byte header form is preferred and MUST be supported by all receivers. A stream MUST contain only one-byte headers or only two-byte headers unless it is known that all recipients support mixing, by either SDP Offer/Answer [RFC3264] negotiation (see Section 6) or out-of-band knowledge. Each RTP packet with an RTP header extension following this specification will indicate whether it contains one-byte or two-byte header extensions through the use of the "defined by profile" field. Extension element types that do not match the header extension format, i.e., one-byte or two-byte, MUST NOT be used in that RTP packet. Transmitters SHOULD NOT use the two-byte header form when all extensions are small enough for the one-byte header form. Transmitters that intend to send the two-byte form SHOULD negotiate the use of IDs above 14 if they want to let the receivers know that they intend to use the two-byte form -- for example, if the RTP header extension is longer than 16 bytes. A transmitter may be aware that an intermediary may add RTP header extensions; in this case, the transmitter SHOULD use the two-byte form.
较小，首选单字节报头形式，并且必须得到所有接收器的支持。流必须仅包含一个字节头或两个字节头，除非已知所有收件人都支持通过SDP提供/应答[RFC3264]协商（见第6节）或带外知识进行混合。每个带有RTP头扩展的RTP数据包都遵循本规范，通过使用“由概要文件定义”字段来指示它是包含一个字节头扩展还是两个字节头扩展。不能在该RTP数据包中使用与标头扩展格式不匹配的扩展元素类型，即一个字节或两个字节。当所有扩展都足够小，可以使用单字节报头格式时，变送器不应使用双字节报头格式。如果打算发送双字节格式的发射机想让接收机知道他们打算使用双字节格式，则应协商使用14以上的ID——例如，如果RTP报头扩展长度超过16字节。发送器可以意识到中介可以添加RTP报头扩展；在这种情况下，变送器应采用双字节形式。
A sequence of extension elements, possibly with padding, forms the header extension defined in the RTP specification. There are as many extension elements as will fit in the RTP header extension, as indicated by 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 needed), and parsing stops (1) at the end of the entire header extension or (2) in the "one-byte headers only" case, on encountering an identifier with the reserved value of 15 -- whichever happens earlier.
一系列扩展元素（可能带有填充）构成RTP规范中定义的头扩展。RTP报头扩展中包含尽可能多的扩展元素，如RTP报头扩展长度所示。由于此长度以完整的32位字表示，因此填充字节用于填充到32位边界。对整个扩展进行逐字节分析，以查找每个扩展元素（不需要对齐），并在遇到保留值为15的标识符时（1）在整个头扩展的末尾或（2）在“仅一字节头”的情况下停止分析（以较早发生的为准）。
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 does it supply 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 that one 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表示后面有一个字节的数据）。这允许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
使用RTP报头扩展将降低RTP报头压缩的效率，因为除非更新RTP报头压缩模块以识别扩展报头，否则报头扩展将以未压缩的方式发送。如果某些数据包中存在报头扩展
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 are explored further in [RFC2508] and [RFC3095].
但在其他情况下，这也会降低压缩效率，因为在发送报头扩展开始或停止时，需要传输对固定报头的更新。[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", MUST have the fixed bit pattern 0xBEDE (the pattern was picked for the trivial reason that the first version of this specification was written on May 25th -- the feast day of the Venerable Bede).
在扩展的单字节头形式中，RTP规范要求的头扩展的16位值（在RTP规范中标记为“由概要文件定义”）必须具有固定位模式0xBEDE（之所以选择这种模式，原因很简单，因为本规范的第一个版本是在5月25日——可敬的比德的节日——编写的）。
Each extension element MUST start 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 a future extension and MUST NOT be used as an identifier. If the ID value 15 is encountered, its length field MUST be ignored, processing of the entire extension MUST terminate at that point, and only the extension elements present prior to the element with ID 15 SHOULD be 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 (0) 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位长度是1字节头之后的该头扩展元素的数据字节数减去1。因此，该字段中的值0（0）表示后面跟着一个字节的数据，值15（最大值）表示16字节的元素数据。（这允许携带16字节值，这是标签和标识符的公共长度，同时失去了零长度值的可能性，这通常会被填充。）
An example header extension, with three extension elements and some padding, follows:
具有三个扩展元素和一些填充的标题扩展示例如下：
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 defined 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; this topic is 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 (zeros) 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
8位ID是该元素的本地标识符，范围为1-255（含1-255）。在信令部分中，范围1-256称为有效范围，值1-255表示有效范围
extension elements and the value 256 referring to the 4-bit appbits field (above). Note that there is one ID space for both the one-byte form and the two-byte form. This means that the lower values (1-14) can be used in the 4-bit ID field in the one-byte header format with the same meanings.
扩展元素和值256表示4位appbits字段（如上）。请注意，单字节形式和双字节形式都有一个ID空间。这意味着较低的值（1-14）可以在具有相同含义的单字节头格式的4位ID字段中使用。
The 8-bit length field is the length of extension data in bytes, not including the ID and length fields. The value zero (0) indicates that there is no subsequent data.
8位长度字段是以字节为单位的扩展数据长度，不包括ID和长度字段。值零（0）表示没有后续数据。
An example header extension, with three extension elements and some padding, follows:
具有三个扩展元素和一些填充的标题扩展示例如下：
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 an SDP Offer/Answer [RFC3264]. This section defines such signaling in SDP.
必须在带外执行此扩展存在的指示，以及头扩展中使用的本地标识符到更大名称空间的映射，例如，作为SDP提供/应答[RFC3264]的一部分。本节定义了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 section (or only once if the mappings are session level). Mappings that do not conform to these rules MAY be presented, for instance, during SDP Offer/Answer [RFC3264] negotiation as described in the next section, but remapping to conformant values is necessary before they can be applied.
可用映射必须使用有效范围内的ID，并且此范围内的每个ID对于每个媒体节只能使用一次（如果映射是会话级别的，则只能使用一次）。例如，如下一节所述，在SDP提供/应答[RFC3264]协商期间，可能会出现不符合这些规则的映射，但在应用这些映射之前，必须重新映射到符合性的值。
Each extension is named by a URI. That URI MUST be absolute; it 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 close to that date. (This avoids problems when domain names change ownership.) If the resource or document defines several extensions,
每个扩展都由一个URI命名。URI必须是绝对的；它精确地确定了扩展的格式和含义。包含域名的URI还应包含格式为mmyyyy的月份日期。元素的定义和URI的分配必须在该日期或非常接近该日期时由域名所有者授权。（这样可以避免域名更改所有权时出现问题。）如果资源或文档定义了多个扩展，
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 and gives documentation on the extension. The URIs do not have to be dereferencable, in order to permit confidential or experimental use, or to cover the case when extensions continue to be used after the organization that defined them ceases to exist.
理由：URI的使用提供了一个大的、未分配的空间，并提供了关于扩展的文档。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 can, of course, be used for several streams and can appear with different <extensionattributes> for the same stream.)
具有相同属性的扩展URI不得多次出现在应用于同一流的扩展URI中，即在会话级别或在媒体级别的单个流声明中。（当然，同一扩展可以用于多个流，并且可以在同一流中以不同的<extensionattributes>显示。）
For extensions defined in RFCs, the URI used SHOULD be a URN starting with "urn:ietf:params:rtp-hdrext:" followed by a registered, descriptive name.
对于RFCs中定义的扩展，使用的URI应该是一个URN，以“URN:ietf:params:rtp hdrext:”开头，后跟一个注册的描述性名称。
The registration requirements are detailed in Section 10 ("IANA Considerations").
注册要求详见第10节（“IANA注意事项”）。
An example where "avt-example-metadata" is the hypothetical name of a header extension might be:
“avt示例元数据”是头扩展的假设名称的示例可能是：
urn:ietf:params:rtp-hdrext:avt-example-metadata
urn:ietf:params:rtp-hdrext:avt-example-metadata
An example name not from the IETF 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 in each media section of the SDP or unique in the session for session-level SDP declarations.
可以针对每个媒体流（在SDP的媒体级部分中，即在“m=”行之后）或针对所有流（即在会话级的第一个“m=”行之前）提供映射。定义必须是所有会话级别或所有媒体级别；不允许混合使用这两种样式。此外，如上所述，所使用的ID在SDP的每个媒体部分中必须是唯一的，或者在会话级SDP声明的会话中必须是唯一的。
Each local identifier potentially used in the stream is mapped to an extension identified by a URI using an attribute of the form:
流中可能使用的每个本地标识符都映射到URI使用以下形式的属性标识的扩展：
a=extmap:<value>["/"<direction>] <URI> <extensionattributes>
a=extmap:<value>["/"<direction>] <URI> <extensionattributes>
where
哪里
o <value> is the local identifier (ID) of this extension and is an integer in the valid range (0 is reserved for padding in both forms, and 15 is reserved in the one-byte header form, as noted above).
o <value>是此扩展的本地标识符（ID），是有效范围内的整数（0保留用于两种形式的填充，15保留在单字节头形式中，如上所述）。
o <direction> is one of "sendonly", "recvonly", "sendrecv", or "inactive" (without the quotes) with relation to the device being configured.
o <direction>是与正在配置的设备相关的“sendonly”、“RecVoOnly”、“sendrecv”或“inactive”（不带引号）之一。
o <URI> is a URI, as above.
o <URI>是一个URI，如上所述。
The formal BNF syntax is presented in Section 8 of this specification.
本规范第8节介绍了正式的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 ("BEDE" or "100") indicated above.
当SDP信令用于RTP会话时，使用这种类型的报头扩展的诊断是“extmap”属性的存在，而不是上述的幻数（“BEDE”或“100”）。
6. SDP Signaling for Support of Mixed One-Byte and Two-Byte Header Extensions
6. 支持混合单字节和双字节头扩展的SDP信令
In order to allow for backward interoperability with systems that do not support the mixing of one-byte and two-byte header extensions, this document defines the "a=extmap-allow-mixed" Session Description Protocol (SDP) [RFC4566] attribute to indicate if the participant is capable of supporting this new mode. The attribute takes no value. This attribute can be used at the session level or the media level. A participant that proposes the use of this mode SHALL itself support the reception of mixed one-byte and two-byte header extensions.
为了允许与不支持单字节和双字节头扩展混合的系统进行向后互操作，本文档定义了“a=extmap allow mixed”会话描述协议（SDP）[RFC4566]属性，以指示参与者是否能够支持此新模式。该属性没有任何值。此属性可在会话级别或媒体级别使用。提议使用此模式的参与者本身应支持接收混合的单字节和双字节头扩展。
If SDP Offer/Answer [RFC3264] is supported and used, the negotiation for mixed one-byte and two-byte extensions MUST be negotiated using SDP Offer/Answer per [RFC3264]. In the absence of negotiations using
如果支持并使用SDP提供/应答[RFC3264]，则必须根据[RFC3264]使用SDP提供/应答协商混合单字节和双字节扩展的协商。在没有谈判的情况下，使用
SDP Offer/Answer -- for example, when declarative SDP is used -- mixed headers MUST NOT occur unless the transmitter has some (out-of-band) knowledge that all potential recipients support this mode.
SDP提供/应答——例如，当使用声明性SDP时——除非发送者知道（带外）所有潜在接收者都支持此模式，否则不得出现混合头。
The formal definition of this attribute is:
该属性的正式定义为：
Name: extmap-allow-mixed
名称：extmap允许混合
Value: None
价值：无
Usage Level: session, media
使用级别：会话、媒体
Charset Dependent: No
依赖字符集：否
Example:
例子：
a=extmap-allow-mixed
a=extmap允许混合
When doing SDP Offer/Answer [RFC3264], an offering client that wishes to use both one-byte and two-byte extensions MUST include the attribute "a=extmap-allow-mixed" in the SDP offer. If "a=extmap-allow-mixed" is present in the SDP offer, the answerer that supports this mode and wishes to use it SHALL include the "a=extmap-allow-mixed" attribute in the answer. In the cases where the attribute has been excluded, both clients SHALL NOT use mixed one-byte and two-byte extensions in the same RTP stream but MAY use the one-byte or two-byte form exclusively (see Section 4.1.2).
执行SDP提供/应答[RFC3264]时，希望同时使用单字节和双字节扩展名的提供客户端必须在SDP提供中包含属性“a=extmap allow mixed”。如果SDP报价中存在“a=extmap allow mixed”，则支持该模式并希望使用该模式的应答者应在应答中包含“a=extmap allow mixed”属性。在属性已被排除的情况下，两个客户端不得在同一RTP流中使用混合的单字节和双字节扩展名，但可以专门使用单字节或双字节形式（见第4.1.2节）。
When used per [SDP-BUNDLE], this attribute is specified as the IDENTICAL category [SDP-MUX].
按照[SDP-BUNDLE]使用时，此属性指定为相同类别[SDP-MUX]。
The simple signaling described above for the "extmap" attribute MAY be enhanced in an SDP Offer/Answer [RFC3264] context, to permit:
上述针对“extmap”属性的简单信令可以在SDP提供/应答[rfc326]上下文中增强，以允许：
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" as specified in [RFC3264].
“extmap”中可以包括方向属性；如果没有它，方向当然会隐式地从流方向继承，或者对于会话级属性或“非活动”流的扩展，方向是“sendrecv”。方向必须是[RFC3264]中规定的“仅发送”、“仅接收”、“发送接收”或“非活动”方向之一。
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 answer MAY be changed to modify or add direction qualifiers for that extension.
如果扩展映射以“sendrecv”的形式显式或隐式提供，并且需要不对称行为，则可以更改SDP答案以修改或添加该扩展的方向限定符。
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. An answerer MAY want to respond that he supports the extension and does not want to receive it at the moment, but he may indicate a desire to receive it in a future offer and will mark the extension as "inactive".
如果分机标记为“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. An answerer MAY want to respond that he supports this extension but has no intention of sending it now; he may indicate a desire to send it in a future offer by marking the extension as "inactive".
如果分机标记为“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). The local identifiers MUST be unique in an RTP session, and the same identifier MUST be used for the same offered extension in the answer. A session update MAY change the direction qualifiers of extensions being used. A session update MAY add or remove extension(s). Identifier values in the valid range MUST NOT be altered (remapped).
每个媒体部分（包括会话级别部分）不得多次使用报价或应答中包含的有效范围内的本地标识符。本地标识符在RTP会话中必须是唯一的，并且同一标识符必须用于应答中提供的相同扩展。会话更新可能会更改正在使用的扩展的方向限定符。会话更新可以添加或删除扩展。有效范围内的标识符值不得更改（重新映射）。
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 renumbering is not permitted either).
请注意，根据此规则，同一本地标识符不能用于同一媒体的两个扩展，即使其中一个是“sendonly”而另一个是“RecVoOnly”，因为这样就不可能使其中任何一个成为“sendrecv”（因为也不允许重新编号）。
If a party wishes to offer mutually exclusive alternatives, then multiple extensions with the same identifier in the extended 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范围内的标识符；回答者应选择所需的，并将其重新映射到有效范围内的自由标识符。
An answerer may copy an "extmap" for an identifier in the extended range into the answer to indicate to the offerer that it supports that extension. Of course, such an extension cannot be used, since there is no way to specify it in an extension header. If needed, the offerer or answerer can update the session to assign a valid identifier to that extension URI.
应答者可以将扩展范围内的标识符的“extmap”复制到应答中，以向报价人表明其支持该扩展。当然，不能使用这样的扩展，因为无法在扩展头中指定它。如果需要，报价人或应答人可以更新会话，为该扩展URI分配有效标识符。
Rationale: The range 4096-4351 for these negotiation identifiers is deliberately restricted to allow expansion of the range of valid identifiers in the 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, 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
When using [SDP-BUNDLE] to bundle multiple "m=" lines, the "extmap" attribute falls under the SPECIAL category of [SDP-MUX]. All the "m=" lines in a BUNDLE group are considered to be part of the same local identifier (ID) space. If an RTP header extension, i.e., a particular extension URI and configuration using <extensionattributes>, is offered in multiple "m=" lines that are part of the same BUNDLE group, it MUST use the same ID in all of these "m=" lines. Each "m=" line in a BUNDLE group can include different RTP header extensions allowing, for example, audio and video sources to use different sets of RTP header extensions. A difference in configuration using any of the <extensionattributes> is important. Unless an RTP header extension explicitly states otherwise, any such difference SHALL be communicated to all receivers and SHALL cause assignment of different IDs. An RTP header extension that does not follow this rule MUST explicitly define what would constitute compatible configurations that can be sent with the same ID. The directionality of the RTP header extensions in each "m=" line of the BUNDLE group is handled in the same way as handling for non-bundled "m=" lines. This allows for specifying different directionality for each of the repeated extension URIs in a BUNDLE group.
使用[SDP-BUNDLE]捆绑多个“m=”行时，“extmap”属性属于[SDP-MUX]的特殊类别。捆绑组中的所有“m=”行都被视为同一本地标识符（ID）空间的一部分。如果RTP头扩展（即使用<extensionattributes>的特定扩展URI和配置）在属于同一捆绑组的多个“m=”行中提供，则它必须在所有这些“m=”行中使用相同的ID。捆绑组中的每个“m=”行可以包括不同的RTP头扩展，例如，允许音频和视频源使用不同的RTP头扩展集。使用任何<extensionattributes>的配置差异都很重要。除非RTP报头扩展另有明确规定，否则任何此类差异应传达给所有接收器，并应导致分配不同的ID。不遵循此规则的RTP标头扩展必须明确定义构成可使用相同ID发送的兼容配置的内容。捆绑组的每个“m=”行中RTP标头扩展的方向性处理方式与非捆绑“m=”行的处理方式相同。这允许为捆绑组中的每个重复扩展URI指定不同的方向性。
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 can be several.
下面的语法定义根据[RFC5234]使用ABNF。语法元素“URI”在[RFC3986]中定义（此处仅允许绝对URI）。语法元素“extmap”是[RFC4566]中定义的属性，即“a=”位于“extmap”定义之前。特定的<extensionattributes>由定义特定扩展名的规范定义；可以有几个。
Name: extmap
名称：extmap
Value: extmap-value
值：extmap值
Syntax:
语法：
extmap-value = mapentry SP extensionname [SP extensionattributes]
extmap value=mapentry SP extensionname[SP extensionattributes]
mapentry = "extmap:" 1*5DIGIT ["/" direction]
mapentry = "extmap:" 1*5DIGIT ["/" direction]
extensionname = URI
extensionname = URI
extensionattributes = byte-string
extensionattributes = byte-string
direction = "sendonly" / "recvonly" / "sendrecv" / "inactive"
direction = "sendonly" / "recvonly" / "sendrecv" / "inactive"
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 document defines only a place to transmit information; the security implications of each of the extensions must be discussed with those extensions.
本文件仅定义了传输信息的场所；必须与这些扩展讨论每个扩展的安全含义。
Extension usage is negotiated using [RFC3264], so integrity protection and end-to-end authentication MUST be implemented. The security considerations of [RFC3264] MUST be followed to prevent, for example, extension-usage blocking.
扩展使用通过[RFC3264]协商，因此必须实现完整性保护和端到端身份验证。必须遵循[RFC3264]的安全注意事项，以防止（例如）扩展使用阻塞。
Header extensions have the same security coverage as the RTP header itself. When the Secure Real-time Transport Protocol (SRTP) [RFC3711] is used to protect RTP sessions, the RTP payload can be
标头扩展与RTP标头本身具有相同的安全覆盖率。当使用安全实时传输协议（SRTP）[RFC3711]来保护RTP会话时，RTP有效负载可以
both encrypted and integrity protected, while the RTP header is either unprotected or integrity protected. In order to prevent DoS attacks (for example, by changing the header extension) integrity protection SHOULD be used. Lower-layer security protection such as Datagram Transport Layer Security (DTLS) [RFC6347] MAY be used. RTP header extensions can carry sensitive information for which participants in multimedia sessions want confidentiality. RFC 6904 [RFC6904] provides a mechanism that extends the mechanisms of SRTP to selectively encrypt RTP header extensions in SRTP.
加密和完整性都受到保护，而RTP头要么不受保护，要么受完整性保护。为了防止DoS攻击（例如，通过更改标头扩展名），应使用完整性保护。可以使用诸如数据报传输层安全性（DTLS）[RFC6347]之类的低层安全保护。RTP报头扩展可以携带多媒体会话参与者希望保密的敏感信息。RFC 6904[RFC6904]提供了一种扩展SRTP机制的机制，以选择性地加密SRTP中的RTP头扩展。
The RTP application designer needs to consider their security needs, that includes cipher strength for SRTP packets in general and what that means for the integrity and confidentiality of the RTP header extensions. As defined by RFC 6904 [RFC6904], the encryption stream cipher for the header extension is dependent on the chosen SRTP cipher.
RTP应用程序设计器需要考虑它们的安全需求，包括SRTP分组的加密强度一般以及对RTP头扩展的完整性和机密性意味着什么。根据RFC 6904[RFC6904]的定义，报头扩展的加密流密码取决于所选的SRTP密码。
Other options for securing RTP are discussed in [RFC7201].
[RFC7201]中讨论了保护RTP的其他选项。
This document updates the references in three IANA registries to point to this document instead of RFC 5285, and updates and adds new SDP attributes in Sections 10.2 and 10.3, respectively.
本文件更新了三个IANA注册中心中的参考文献，以指向本文件而不是RFC 5285，并分别更新和添加了第10.2节和第10.3节中的新SDP属性。
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 [RFC8126].
从命名URI表单到规范引用的映射由IANA管理。根据[RFC8126]中定义的“专家评审”要求，将其插入本登记册。
IANA will also maintain a server that contains all of the registered elements in a publicly accessible space.
IANA还将维护一个服务器，该服务器包含一个公共可访问空间中的所有已注册元素。
Here is the formal declaration to comply with 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 SHOULD 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 reviewer 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 header extensions (specifically, that the header extension can be ignored or discarded without breaking the RTP layer);
2. 扩展符合RTP和本规范对报头扩展的要求（具体而言，在不破坏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;
6. 扩展通常是适用的——例如，点对多点安全的——并且规范正确地描述了存在的限制；
7. that the suggested naming URI form is appropriately chosen and unique; and
7. 建议的命名URI形式选择适当且唯一；和
8. that for multiplexed "m=" lines [SDP-BUNDLE], any RTP header extension with differences in configurations of <extensionattributes> that do not require assignment of different IDs MUST explicitly indicate this and provide rules for what would constitute compatible configurations that can be sent with the same ID.
8. 对于多路复用的“m=”行[SDP-BUNDLE]，任何在<extensionattributes>的配置中存在差异且不需要分配不同ID的RTP头扩展都必须明确指出这一点，并提供构成可使用相同ID发送的兼容配置的规则。
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 初始作业：无
IANA has updated the registration of the "extmap" SDP attribute [RFC4566] in the "att-field (both session and media level)" subregistry of the "Session Description Protocol (SDP) Parameters" registry.
IANA已在“会话描述协议（SDP）参数”注册表的“att字段（会话和媒体级别）”子区中更新了“extmap”SDP属性[RFC4566]的注册。
o Contact Name and email address: IETF, contacted via <mmusic@ietf.org> (or a successor address designated by the IESG)
o 联系人姓名和电子邮件地址：IETF，通过<mmusic@ietf.org>（或IESG指定的继任者地址）
o Attribute Name: extmap
o 属性名称：extmap
o Attribute Syntax: See Section 8 of RFC 8285.
o 属性语法：参见RFC 8285第8节。
o Attribute Semantics: The details of appropriate values are given in RFC 8285.
o 属性语义：RFC 8285中给出了适当值的详细信息。
o Usage Level: Media or session level
o 使用级别：媒体或会话级别
o Charset Dependent: No
o 依赖字符集：否
o Purpose: Defines the mapping from the extension numbers used in packet headers into extension names.
o 目的：定义从数据包头中使用的分机号码到分机名称的映射。
o Offer/Answer (O/A) Procedures: See Section 7 of RFC 8285.
o 报价/应答（O/A）程序：见RFC 8285第7节。
o MUX Category: SPECIAL
o 多路复用器类别：特殊
o Reference: RFC 8285
o 参考：RFC 8285
IANA has registered one new SDP attribute in the "att-field (both session and media level)" subregistry of the "Session Description Protocol (SDP) Parameters" registry:
IANA已在“会话描述协议（SDP）参数”注册表的“att字段（会话和媒体级别）”子区中注册了一个新的SDP属性：
o Contact Name and email address: IETF, contacted via <mmusic@ietf.org> (or a successor address designated by the IESG)
o 联系人姓名和电子邮件地址：IETF，通过<mmusic@ietf.org>（或IESG指定的继任者地址）
o Attribute Name: extmap-allow-mixed
o 属性名称：extmap允许混合
o Attribute Syntax: See Section 6 of RFC 8285.
o 属性语法：参见RFC 8285第6节。
o Attribute Semantics: See Section 6 of RFC 8285.
o 属性语义：参见RFC 8285第6节。
o Attribute Value: None
o 属性值：无
o Usage Level: Media or session level
o 使用级别：媒体或会话级别
o Charset Dependent: No
o 依赖字符集：否
o Purpose: Negotiate the use of one byte and two bytes in the same RTP stream.
o 目的：协商在同一RTP流中使用一个字节和两个字节。
o O/A Procedures: See Section 6 of RFC 8285.
o O/A程序：见RFC 8285第6节。
o MUX Category: IDENTICAL
o 多路复用器类别：相同
o Reference: RFC 8285
o 参考：RFC 8285
The major motivation for updating [RFC5285] was to allow having one-byte and two-byte RTP header extensions in the same RTP stream (but not in the same RTP packet). The support for this case is negotiated using a new SDP attribute, "extmap-allow-mixed", specified in this document.
更新[RFC5285]的主要动机是允许在同一RTP流中（但不在同一RTP数据包中）有一个字节和两个字节的RTP头扩展。使用本文档中指定的新SDP属性“extmap allow mixed”协商对这种情况的支持。
The other major change is to update the requirement from the RTP specifications [RFC3550] and [RFC5285] that the header extension "is designed so that the header extension may be ignored." This is described in Section 4.1.
另一个主要变化是更新RTP规范[RFC3550]和[RFC5285]的要求，即标题扩展“设计为可以忽略标题扩展”。这在第4.1节中进行了描述。
More text was added to Section 4.1.1 ("Transmission Considerations") to clarify when and how many times to send the RTP header extension to provide a higher probability of delivery.
在第4.1.1节（“传输注意事项”）中添加了更多文本，以澄清何时和多少次发送RTP报头扩展以提供更高的交付概率。
The Security Considerations section was expanded.
扩大了安全考虑部分。
The rest of the changes are editorial.
其余的变化是编辑性的。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, DOI 10.17487/RFC2508, February 1999, <https://www.rfc-editor.org/info/rfc2508>.
[RFC2508]Casner，S.和V.Jacobson，“压缩低速串行链路的IP/UDP/RTP报头”，RFC 2508，DOI 10.17487/RFC2508，1999年2月<https://www.rfc-editor.org/info/rfc2508>.
[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, DOI 10.17487/RFC3095, July 2001, <https://www.rfc-editor.org/info/rfc3095>.
[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，内政部10.17487/RFC30952001年7月<https://www.rfc-editor.org/info/rfc3095>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，DOI 10.17487/RFC3264，2002年6月<https://www.rfc-editor.org/info/rfc3264>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <https://www.rfc-editor.org/info/rfc3711>.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 3711，DOI 10.17487/RFC3711，2004年3月<https://www.rfc-editor.org/info/rfc3711>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<https://www.rfc-editor.org/info/rfc3986>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC 4566，DOI 10.17487/RFC4566，2006年7月<https://www.rfc-editor.org/info/rfc4566>.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<https://www.rfc-editor.org/info/rfc5234>.
[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, DOI 10.17487/RFC6904, April 2013, <https://www.rfc-editor.org/info/rfc6904>.
[RFC6904]Lennox，J.，“安全实时传输协议（SRTP）中的报头扩展加密”，RFC 6904，DOI 10.17487/RFC6904，2013年4月<https://www.rfc-editor.org/info/rfc6904>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 3550，DOI 10.17487/RFC3550，2003年7月<https://www.rfc-editor.org/info/rfc3550>.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, <https://www.rfc-editor.org/info/rfc3553>.
[RFC3553]Mealling，M.，Masinter，L.，Hardie，T.，和G.Klyne，“注册协议参数的IETF URN子命名空间”，BCP 73，RFC 3553，DOI 10.17487/RFC3553，2003年6月<https://www.rfc-editor.org/info/rfc3553>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, <https://www.rfc-editor.org/info/rfc3611>.
[RFC3611]Friedman，T.，Ed.，Caceres，R.，Ed.，和A.Clark，Ed.，“RTP控制协议扩展报告（RTCP XR）”，RFC 3611，DOI 10.17487/RFC36112003年11月<https://www.rfc-editor.org/info/rfc3611>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <https://www.rfc-editor.org/info/rfc4585>.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 4585，DOI 10.17487/RFC4585，2006年7月<https://www.rfc-editor.org/info/rfc4585>.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, <https://www.rfc-editor.org/info/rfc4588>.
[RFC4588]Rey，J.，Leon，D.，Miyazaki，A.，Varsa，V.，和R.Hakenberg，“RTP重传有效载荷格式”，RFC 4588，DOI 10.17487/RFC4588，2006年7月<https://www.rfc-editor.org/info/rfc4588>.
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, <https://www.rfc-editor.org/info/rfc5109>.
[RFC5109]Li，A.，Ed.“通用前向纠错的RTP有效载荷格式”，RFC 5109，DOI 10.17487/RFC5109，2007年12月<https://www.rfc-editor.org/info/rfc5109>.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 2008, <https://www.rfc-editor.org/info/rfc5285>.
[RFC5285]Singer，D.和H.Desneni，“RTP报头扩展的一般机制”，RFC 5285，DOI 10.17487/RFC5285，2008年7月<https://www.rfc-editor.org/info/rfc5285>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，DOI 10.17487/RFC6347，2012年1月<https://www.rfc-editor.org/info/rfc6347>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <https://www.rfc-editor.org/info/rfc7201>.
[RFC7201]Westerlund，M.和C.Perkins，“保护RTP会话的选项”，RFC 7201，DOI 10.17487/RFC7201，2014年4月<https://www.rfc-editor.org/info/rfc7201>.
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, <https://www.rfc-editor.org/info/rfc7667>.
[RFC7667]Westerlund，M.和S.Westerlund，M.和S.Wenger，“RTP拓扑”，RFC 7667，DOI 10.17487/RFC7667，2015年11月<https://www.rfc-editor.org/info/rfc7667>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[SDP-BUNDLE] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", Work in Progress, draft-ietf-mmusic-sdp-bundle-negotiation-39, August 2017.
[SDP-BUNDLE]Holmberg，C.，Alvestrand，H.，和C.Jennings，“使用会话描述协议（SDP）协商媒体多路传输”，正在进行的工作，草稿-ietf-mmusic-SDP-BUNDLE-negotiation-392017年8月。
[SDP-MUX] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", Work in Progress, draft-ietf-mmusic-sdp-mux-attributes-16, December 2016.
[SDP-MUX]Nandakumar，S.，“复用时SDP属性的框架”，正在进行的工作，草稿-ietf-mmusic-SDP-MUX-Attributes-162016年12月。
Acknowledgments
致谢
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在管理注册文本方面发挥了重要作用。
Authors' Addresses
作者地址
David Singer Apple, Inc. 1 Infinite Loop Cupertino, CA 95014 United States of America
David Singer苹果公司，加利福尼亚州库比蒂诺市无限环路1号，美国95014
Phone: +1 408 996 1010
Email: singer@apple.com
URI: https://support.apple.com/quicktime
Phone: +1 408 996 1010
Email: singer@apple.com
URI: https://support.apple.com/quicktime
Harikishan Desineni Qualcomm 10001 Pacific Heights Blvd. San Diego, CA 92121 United States of America
哈里基尚·德西尼尼高通公司太平洋高地大道10001号。加利福尼亚州圣地亚哥92121美利坚合众国
Phone: +1 858 845 8996
Email: h3dnvb@gmail.com
Phone: +1 858 845 8996
Email: h3dnvb@gmail.com
Roni Even (editor) Huawei Technologies Tel Aviv Israel
Roni Even（编辑）华为技术以色列特拉维夫
Email: Roni.even@huawei.com
Email: Roni.even@huawei.com