Internet Engineering Task Force (IETF) M. Westerlund
Request for Comments: 7941 B. Burman
Category: Standards Track Ericsson
ISSN: 2070-1721 R. Even
Huawei Technologies
M. Zanaty
Cisco Systems
August 2016
Internet Engineering Task Force (IETF) M. Westerlund
Request for Comments: 7941 B. Burman
Category: Standards Track Ericsson
ISSN: 2070-1721 R. Even
Huawei Technologies
M. Zanaty
Cisco Systems
August 2016
RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items
RTP控制协议（RTCP）源描述项的RTP标头扩展
Abstract
摘要
Source Description (SDES) items are normally transported in the RTP Control Protocol (RTCP). In some cases, it can be beneficial to speed up the delivery of these items. The main case is when a new synchronization source (SSRC) joins an RTP session and the receivers need this source's identity, relation to other sources, or its synchronization context, all of which may be fully or partially identified using SDES items. To enable this optimization, this document specifies a new RTP header extension that can carry SDES items.
源描述（SDES）项通常在RTP控制协议（RTCP）中传输。在某些情况下，加快这些项目的交付是有益的。主要情况是，当新同步源（SSRC）加入RTP会话时，接收方需要该源的标识、与其他源的关系或其同步上下文，所有这些都可以使用SDES项完全或部分标识。为了实现此优化，本文档指定了一个新的RTP标头扩展，该扩展可以携带SDES项。
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 http://www.rfc-editor.org/info/rfc7941.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7941.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. SDES Item Header Extension . . . . . . . . . . . . . . . 5
4.1.1. One-Byte Format . . . . . . . . . . . . . . . . . . . 6
4.1.2. Two-Byte Format . . . . . . . . . . . . . . . . . . . 6
4.2. Usage of the SDES Item Header Extension . . . . . . . . . 6
4.2.1. One-Byte or Two-Byte Headers . . . . . . . . . . . . 6
4.2.2. MTU and Packet Expansion . . . . . . . . . . . . . . 7
4.2.3. Transmission Considerations . . . . . . . . . . . . . 8
4.2.4. Different Usages . . . . . . . . . . . . . . . . . . 9
4.2.5. SDES Items in RTCP . . . . . . . . . . . . . . . . . 10
4.2.6. Update Flaps . . . . . . . . . . . . . . . . . . . . 10
4.2.7. RTP Header Compression . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5.1. Registration of an SDES Base URN . . . . . . . . . . . . 11
5.2. Creation of the "RTP SDES Compact Header Extensions"
Sub-Registry . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Registration of SDES Item . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. SDES Item Header Extension . . . . . . . . . . . . . . . 5
4.1.1. One-Byte Format . . . . . . . . . . . . . . . . . . . 6
4.1.2. Two-Byte Format . . . . . . . . . . . . . . . . . . . 6
4.2. Usage of the SDES Item Header Extension . . . . . . . . . 6
4.2.1. One-Byte or Two-Byte Headers . . . . . . . . . . . . 6
4.2.2. MTU and Packet Expansion . . . . . . . . . . . . . . 7
4.2.3. Transmission Considerations . . . . . . . . . . . . . 8
4.2.4. Different Usages . . . . . . . . . . . . . . . . . . 9
4.2.5. SDES Items in RTCP . . . . . . . . . . . . . . . . . 10
4.2.6. Update Flaps . . . . . . . . . . . . . . . . . . . . 10
4.2.7. RTP Header Compression . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5.1. Registration of an SDES Base URN . . . . . . . . . . . . 11
5.2. Creation of the "RTP SDES Compact Header Extensions"
Sub-Registry . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Registration of SDES Item . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
This specification defines an RTP header extension [RFC3550][RFC5285] that can carry RTCP Source Description (SDES) items. Normally, the SDES items are carried in their own RTCP packet type [RFC3550]. By including selected SDES items in a header extension, the determination of relationship and synchronization context for new RTP streams (SSRCs) in an RTP session can be optimized. Which relationship and what information depends on the SDES items carried. This becomes a complement to using only RTCP for SDES item delivery.
本规范定义了RTP标头扩展[RFC3550][RFC5285]，该扩展可携带RTCP源描述（SDES）项。通常，SDES项目以其自身的RTCP数据包类型[RFC3550]携带。通过在头扩展中包括选定的SDES项，可以优化RTP会话中新RTP流（SSRC）的关系和同步上下文的确定。哪些关系和哪些信息取决于所携带的SDES项目。这是对SDES项目交付仅使用RTCP的补充。
It is important to note that not all SDES items are appropriate to transmit using RTP header extensions. Some SDES items perform binding or identify synchronization contexts with strict timeliness requirements, while many other SDES items do not have such requirements. In addition, security and privacy concerns for the SDES item information need to be considered. For example, the Name and Location SDES items are highly sensitive from a privacy perspective and should not be transported over the network without strong security. No use case has identified that such information is required when the first RTP packets arrive. A delay of a few seconds before such information is available to the receiver appears acceptable. Therefore, only appropriate SDES items, such as CNAME, will be registered for use with this header extension.
需要注意的是，并非所有SDE项都适合使用RTP标头扩展进行传输。一些SDES项目执行绑定或识别具有严格时效性要求的同步上下文，而许多其他SDES项目没有此类要求。此外，还需要考虑SDES项目信息的安全和隐私问题。例如，从隐私角度来看，SDES项目的名称和位置是高度敏感的，在没有强大安全性的情况下，不应通过网络传输。当第一个RTP数据包到达时，没有用例确定需要这样的信息。在接收器获得此类信息之前几秒钟的延迟似乎是可以接受的。因此，只有适当的SDES项（如CNAME）将注册以用于此标头扩展。
Requirements language and terminology are defined in Section 2. Section 3 describes why this header extension is sometimes required or at least provides a significant improvement compared to waiting for regular RTCP packet transmissions of the information. Section 4 provides a specification of the header extension and usage recommendations. Section 5 defines a subspace of the header extension URN to be used for existing and future SDES items and registers the appropriate existing SDES items.
第2节定义了需求语言和术语。第3节描述了为什么有时需要此报头扩展，或者与等待信息的常规RTCP数据包传输相比，至少提供了显著的改进。第4节提供了标题扩展规范和使用建议。第5节定义了用于现有和未来SDES项目的标题扩展URN的子空间，并注册了适当的现有SDES项目。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This document uses terminology defined in "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources" [RFC7656]. In particular, the following terms are used:
本文档使用“实时传输协议（RTP）源的语义和机制分类法”[RFC7656]中定义的术语。具体而言，使用以下术语：
Media Source
媒体来源
RTP Stream
RTP流
Media Encoder
媒体编码器
Participant
参与者
SDES items are associated with a particular SSRC and thus with a particular RTP stream. The Source Description items provide various metadata associated with the SSRC. How important it is to have this data no later than when the first RTP packets is received depends on the item itself. The CNAME item is one item that is commonly needed either at reception of the first RTP packet for this SSRC or at least by the time the first media can be played out. If it is not available, the synchronization context cannot be determined; thus, any related streams cannot be correctly synchronized. Therefore, this is a valuable example for having this information early when a new RTP stream is received.
SDES项目与特定SSRC关联，因此与特定RTP流关联。源描述项提供与SSRC相关的各种元数据。不迟于接收到第一个RTP数据包时获取此数据的重要性取决于项目本身。CNAME项目是在接收该SSRC的第一RTP分组时或至少在第一媒体可以播放时通常需要的一个项目。如果不可用，则无法确定同步上下文；因此，任何相关流都无法正确同步。因此，这是在接收到新的RTP流时尽早获得该信息的有价值的示例。
The main reason for new SSRCs in an RTP session is when media sources are added. This can be because either an endpoint is adding a new actual media source or additional participants in a multi-party session are added to the session. Another reason for a new SSRC can be an SSRC collision that forces both colliding parties to select new SSRCs.
RTP会话中出现新SSRC的主要原因是添加了媒体源。这可能是因为端点正在添加新的实际媒体源，或者多方会话中的其他参与者已添加到会话中。新SSRC的另一个原因可能是SSRC碰撞，迫使碰撞双方选择新的SSRC。
For the case of rapid media synchronization, one may use the RTP header extension for rapid synchronization of RTP flows [RFC6051]. This header extension carries the clock information present in the RTCP sender report (SR) packets. However, it assumes that the CNAME binding is known, which can be provided via signaling [RFC5576] in some cases, but not all. Thus, an RTP header extension for carrying SDES items like CNAME is a powerful combination to enable rapid synchronization in all cases.
对于快速媒体同步的情况，可以使用RTP报头扩展来快速同步RTP流[RFC6051]。此报头扩展携带RTCP发送方报告（SR）数据包中的时钟信息。但是，它假设CNAME绑定是已知的，在某些情况下，但不是所有情况下，可以通过信令[RFC5576]提供。因此，用于承载SDES项（如CNAME）的RTP标头扩展是一个强大的组合，可以在所有情况下实现快速同步。
The "Rapid Synchronisation of RTP Flows" specification [RFC6051] does provide an analysis of the initial synchronization delay for different sessions depending on the number of receivers as well as on session bandwidth (Section 2.1 of [RFC6051]). These results are also
“RTP流的快速同步”规范[RFC6051]确实根据接收器数量和会话带宽（RFC6051第2.1节）对不同会话的初始同步延迟进行了分析。这些结果也很重要
applicable for other SDES items that have a similar time dependency until the information can be sent using RTCP. These figures can be used to determine the benefit of reducing the initial delay before information is available for some use cases.
适用于具有类似时间依赖性的其他SDES项目，直到可以使用RTCP发送信息。这些数字可用于确定在某些用例的信息可用之前减少初始延迟的好处。
[RFC6051] also discusses the case of late joiners and defines an RTCP Feedback format to request synchronization information, which is another potential use case for SDES items in the RTP header extension. It would, for example, be natural to include a CNAME SDES item with the header extension containing the NTP-formatted reference clock to ensure synchronization.
[RFC6051]还讨论了延迟加入者的情况，并定义了RTCP反馈格式以请求同步信息，这是RTP标头扩展中SDES项的另一个潜在用例。例如，包含一个CNAME SDES项，其标题扩展包含NTP格式的参考时钟，以确保同步是很自然的。
The ongoing work on bundling Session Description Protocol (SDP) media descriptions [SDP-BUNDLE] has identified a new SDES item that can benefit from timely delivery. A corresponding RTP SDES compact header extension is therefore also defined and registered in that document:
正在进行的捆绑会话描述协议（SDP）媒体描述[SDP-BUNDLE]的工作已经确定了一个新的SDES项，它可以从及时交付中受益。因此，相应的RTP SDES compact标头扩展也在该文档中定义和注册：
MID: This is a media description identifier that matches the value of the SDP [RFC4566] a=mid attribute [RFC5888], to associate RTP streams multiplexed on the same transport with their respective SDP media description.
MID：这是一个媒体描述标识符，与SDP[RFC4566]a=MID属性[RFC5888]的值相匹配，以将在同一传输上多路复用的RTP流与其各自的SDP媒体描述相关联。
This section first specifies the SDES item RTP header extension format, followed by some usage considerations.
本节首先指定SDES项目RTP标头扩展格式，然后是一些使用注意事项。
An RTP header extension scheme allowing for multiple extensions is defined in "A General Mechanism for RTP Header Extensions" [RFC5285]. That specification defines both short and long item headers. The short headers (one byte) are restricted to 1 to 16 bytes of data, while the long format (two bytes) supports a data length of 0 to 255 bytes. Thus, the RTP header extension formats are capable of supporting any SDES item from a data length perspective.
“RTP报头扩展的通用机制”[RFC5285]中定义了允许多个扩展的RTP报头扩展方案。该规范定义了短项和长项标题。短头（一个字节）限制为1到16字节的数据，而长格式（两个字节）支持0到255字节的数据长度。因此，RTP头扩展格式能够从数据长度的角度支持任何SDES项。
The ID field, independent of a short or long format, identifies both the type of RTP header extension and, in the case of the SDES item header extension, the type of SDES item. The mapping is done in signaling by identifying the header extension and SDES item type using a URN, which is defined in Section 5 ("IANA Considerations") for the known SDES items appropriate to use.
ID字段独立于短格式或长格式，标识RTP标题扩展的类型，如果是SDES项目标题扩展，则标识SDES项目的类型。通过使用URN（第5节（“IANA注意事项”）中针对适合使用的已知SDES项目定义的URN）识别报头扩展和SDES项目类型，在信令中完成映射。
The one-byte header format for an SDES item extension element consists of the one-byte header (defined in Section 4.2 of [RFC5285]), which consists of a 4-bit ID followed by a 4-bit length field (len) that identifies the number of data bytes (len value +1) following the header. The data part consists of len+1 bytes of UTF-8 [RFC3629] text. The type of text and its mapping to the SDES item type are determined by the ID field value.
SDES项目扩展元素的单字节标题格式由单字节标题（在[RFC5285]第4.2节中定义）组成，该标题由一个4位ID和一个4位长度字段（len）组成，该字段标识标题后的数据字节数（len值+1）。数据部分由len+1字节的UTF-8[RFC3629]文本组成。文本类型及其到SDES项目类型的映射由ID字段值确定。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | len | SDES item text value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | len | SDES item text value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
图1
The two-byte header format for an SDES item extension element consists of the two-byte header (defined in Section 4.3 of [RFC5285]), which consists of an 8-bit ID followed by an 8-bit length field (len) that identifies the number of data bytes following the header. The data part consists of len bytes of UTF-8 text. The type of text and its mapping to the SDES item type are determined by the ID field value.
SDES项目扩展元素的双字节标头格式由双字节标头（在[RFC5285]第4.3节中定义）组成，该标头由8位ID和8位长度字段（len）组成，该字段标识标头后面的数据字节数。数据部分由长字节的UTF-8文本组成。文本类型及其到SDES项目类型的映射由ID字段值确定。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | len | SDES item text value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | len | SDES item text value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
图2
This section discusses various usage considerations: which form of the header extension to use, the packet expansion, and when to send SDES items in the header extension.
本节讨论各种使用注意事项：使用哪种形式的报头扩展、数据包扩展以及何时在报头扩展中发送SDES项。
The RTP header extensions for SDES items MAY use either the one-byte or two-byte header formats, depending on the text value size for the used SDES items and the requirement from any other header extensions used. The one-byte header SHOULD be used when all non-SDES item
SDES项目的RTP标题扩展可以使用单字节或双字节标题格式，具体取决于所用SDES项目的文本值大小以及所用任何其他标题扩展的要求。当所有非SDES项目
header extensions support the one-byte format and all SDES item text values contain at most 16 bytes. Note that the RTP header extension specification [RFC5285] does not allow mixing one-byte and two-byte headers for the same RTP stream (SSRC), so if any SDES item requires the two-byte header, then all other header extensions MUST also use the two-byte header format.
标题扩展支持单字节格式，所有SDES项目文本值最多包含16个字节。请注意，RTP标头扩展规范[RFC5285]不允许为同一RTP流（SSRC）混合单字节标头和双字节标头，因此，如果任何SDES项目需要双字节标头，则所有其他标头扩展也必须使用双字节标头格式。
For example, if using CNAMEs that are generated according to "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)" [RFC7022], if using short-term persistent values, and if 96-bit random values prior to base64 encoding are sufficient, then they will fit into the one-byte header format.
例如，如果使用根据“选择RTP控制协议（RTCP）规范名称（CNAMEs）的指南”[RFC7022]生成的CNAMEs，如果使用短期持久值，并且如果base64编码之前的96位随机值足够，则它们将适合单字节头格式。
An RTP middlebox needs to take care choosing between one-byte headers and two-byte headers when creating the first packets for an outgoing stream (SSRC) with header extensions. First of all, it needs to consider all the header extensions that may potentially be used. Second, it needs to know the size of the SDES items that are going to be included and use two-byte headers if any are longer than 16 bytes. An RTP middlebox that forwards a stream, i.e., not mixing it or combining it with other streams, may be able to base its choice on the header size in incoming streams. This is assuming that the middlebox does not modify the stream or add additional header extensions to the stream it sends, in which case it needs to make its own decision.
RTP中间盒在为具有报头扩展的传出流（SSRC）创建第一个数据包时，需要注意在单字节报头和双字节报头之间进行选择。首先，它需要考虑可能使用的所有报头扩展。其次，它需要知道要包含的SDES项的大小，如果有超过16字节的头，则使用两字节头。转发流（即，不将流混合或与其他流组合）的RTP中间盒可以基于传入流中的报头大小进行选择。这是假设中间盒不修改流或向其发送的流添加额外的头扩展，在这种情况下，它需要自己做出决定。
The RTP packet size will clearly increase when a header extension is included. How much depends on the type of header extensions and their data content. The SDES items can vary in size. There are also some use cases that require transmitting multiple SDES items in the same packet to ensure that all relevant data reaches the receiver. An example of that is when CNAME, a MID, and the rapid time synchronization extension from RFC 6051 are all needed. Such a combination is quite likely to result in at least 16+3+8 bytes of data plus the headers, which will be another 7 bytes for one-byte headers, plus two bytes of header padding to make the complete header extension 32-bit word aligned, thus 36 bytes in total.
当包含报头扩展时，RTP数据包大小将明显增加。多少取决于标题扩展的类型及其数据内容。SDES项目的大小可能不同。还有一些用例需要在同一个数据包中传输多个SDE项，以确保所有相关数据到达接收器。例如，当CNAME、MID和RFC6051的快速时间同步扩展都需要时。这样的组合很可能导致至少16+3+8字节的数据加上报头，对于一个字节的报头，这将是另外7个字节，再加上两个字节的报头填充，以使完整的报头扩展32位字对齐，因此总共36个字节。
If the packet expansion cannot be taken into account when producing the RTP payload, it can cause an issue. An RTP payload that is created to meet a particular IP-level Maximum Transmission Unit (MTU), taking the addition of IP/UDP/RTP headers but not RTP header extensions into account, could exceed the MTU when the header extensions are present, thus resulting in IP fragmentation. IP fragmentation is known to negatively impact the loss rate due to middleboxes unwilling or not capable of dealing with IP fragments, as
如果在生成RTP有效负载时无法考虑数据包扩展，则可能会导致问题。为满足特定IP级别最大传输单元（MTU）而创建的RTP有效负载（考虑添加IP/UDP/RTP报头但不考虑RTP报头扩展）在存在报头扩展时可能超过MTU，从而导致IP碎片。众所周知，由于中间盒不愿意或不能处理IP碎片，IP碎片会对丢失率产生负面影响，如
well as increasing the target surface for other types of packet losses.
以及增加其他类型的数据包丢失的目标表面。
As this is a real issue, the media encoder and payload packetizer should be flexible and be capable of handling dynamically varying payload size restrictions to counter the packet expansion caused by header extensions. If that is not possible, some reasonable worst-case packet expansion should be calculated and used to reduce the RTP payload size of all RTP packets the sender transmits.
由于这是一个真正的问题，媒体编码器和有效负载打包器应该是灵活的，并且能够处理动态变化的有效负载大小限制，以对抗由报头扩展引起的数据包扩展。如果这是不可能的，则应计算一些合理的最坏情况下的数据包扩展，并用于减少发送方传输的所有RTP数据包的RTP有效负载大小。
The general recommendation is to only send header extensions when needed. This is especially true for SDES items that can be sent in periodic repetitions of RTCP throughout the whole session. Thus, the different usages (Section 4.2.4) have different recommendations. The following are some general considerations for getting the header extensions delivered to the receiver:
一般建议仅在需要时发送头扩展。对于SDES项目尤其如此，这些项目可以在整个会话期间定期重复发送RTCP。因此，不同的用途（第4.2.4节）有不同的建议。以下是将标头扩展交付给接收方的一些一般注意事项：
1. The probability for packet loss and burst loss determine 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 getting all repetitions of the header extensions lost 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 SDES item information is needed, from the first received RTP data or only after some set of packets are received, can guide if the header extension(s) should be in all of the first N packets or be included only once per set of packets, for example, once per video frame.
3. 从第一个接收到的RTP数据或仅在接收到某组分组之后，需要多早SDES项目信息可以指导报头扩展是否应该在所有前N个分组中，或者仅在每组分组中包括一次，例如，每个视频帧一次。
4. The use of RTP-level robustness mechanisms, such as RTP retransmission [RFC4588] or forward error correction [RFC5109], may treat packets differently from a robustness perspective, and SDES 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]，可以从健壮性的角度不同地处理分组，并且应将SDES报头扩展添加到获得与接收信息的相对重要性相对应的处理的分组。
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次报头扩展应该足够了，但可能不是最优的。
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 to stop further repetitions. Feedback that can be used includes the RTCP Extended Report (XR) Loss RLE Report Block [RFC3611], which indicates successful delivery of particular packets. If the RTP/AVPF transport-layer feedback message for generic NACK [RFC4585] is used, it can indicate the 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使得报头扩展目标传送概率达到1-P^N，其中P是分组丢失的概率。对于点对点或小型接收器群体，也可以使用反馈（如RTCP）来确定报头扩展中的信息何时到达所有接收器并停止进一步重复。可使用的反馈包括RTCP扩展报告（XR）丢失RLE报告块[RFC3611]，它指示特定数据包的成功传递。如果使用通用NACK[RFC4585]的RTP/AVPF传输层反馈消息，则它可以指示未能交付具有报头扩展的RTP分组，从而指示需要进一步重复。正常RTCP报告块还可以提供成功传递的指示器，前提是在覆盖具有报头扩展名的RTP数据包的报告间隔内未指示任何丢失。请注意，在发送RTP报头扩展数据包的间隔上报告RTCP数据包丢失并不一定意味着RTP报头扩展数据包本身丢失。
A new SSRC joins an RTP session. As this SSRC is completely new for everyone, the goal is to ensure, with high probability, that all RTP session participants receive the information in the header extension. Thus, header extension transmission strategies that allow some margins in the delivery probability should be considered.
新的SSRC加入RTP会话。由于这个SSRC对于每个人来说都是全新的，所以我们的目标是以高概率确保所有RTP会话参与者都能收到头扩展中的信息。因此，应考虑允许在交付概率中有一定裕度的报头扩展传输策略。
In a multi-party RTP session where one or a small number of receivers join a session where the majority of receivers already have all necessary information, the use of header extensions to deliver relevant information should be tailored to reach the new receivers. The trigger to send header extensions can, for example, be either RTCP from a new receiver(s) or an explicit request like the Rapid Resynchronization Request defined in [RFC6051]. In centralized topologies where an RTP middlebox is present, it can be responsible for transmitting the known information, possibly stored, to the new session participant only and not repeat it to all the session participants.
在多方RTP会话中，一个或少数接收器加入了大多数接收器已经拥有所有必要信息的会话，应定制使用报头扩展来传递相关信息，以到达新的接收器。例如，发送标头扩展的触发器可以是来自新接收器的RTCP，也可以是明确的请求，如[RFC6051]中定义的快速重新同步请求。在存在RTP中间盒的集中式拓扑中，它可以负责将已知信息（可能已存储）仅传输给新会话参与者，而不向所有会话参与者重复。
If the SDES information is tightly coupled with the RTP data, and the SDES information needs to be updated, then the use of the RTP header extension is superior to RTCP. Using the RTP header extension ensures that the information is updated on reception of the related
如果SDES信息与RTP数据紧密耦合，并且SDES信息需要更新，则使用RTP头扩展优于RTCP。使用RTP报头扩展可确保在接收到相关信息时更新信息
RTP media, ensuring synchronization between the two. Continued use of the old SDES information can lead to undesired effects in the application. Thus, header extension transmission strategies with high probability of delivery should be chosen.
RTP介质，确保两者之间的同步。继续使用旧的SDES信息可能会在应用程序中产生不期望的效果。因此，应选择具有高发送概率的报头扩展传输策略。
The RTP header extension information, i.e., SDES items, can and will be sent also in RTCP. Therefore, it is worth making some reflections on this interaction. As an alternative to the header extension, it is possible to schedule a non-regular RTCP packet transmission containing important SDES items, if one uses an RTP-/AVPF-based RTP profile. Depending on the mode in which one's RTCP feedback transmitter is working, extra RTCP packets may be sent as immediate or early packets, enabling more timely SDES information delivery.
RTP标头扩展信息，即SDES项目，也可以并且将在RTCP中发送。因此，值得对这种互动进行一些反思。作为报头扩展的替代方案，如果使用基于RTP-/AVPF的RTP配置文件，则可以调度包含重要SDES项的非常规RTCP数据包传输。根据RTCP反馈发送器的工作模式，额外的RTCP数据包可作为即时数据包或早期数据包发送，从而实现更及时的SDES信息传递。
There are, however, two aspects that differ between using RTP header extensions and any non-regular transmission of RTCP packets. First, as the RTCP packet is a separate packet, there is no direct relation and also no fate sharing between the relevant media data and the SDES information. The order of arrival for the packets will matter. With a header extension, the SDES items can be ensured to arrive if the media data to play out arrives. Second, it is difficult to determine if an RTCP packet is actually delivered, as the RTCP packets lack both a sequence number and a mechanism providing feedback on the RTCP packets themselves.
然而，使用RTP报头扩展和任何RTCP数据包的非常规传输有两个方面的不同。首先，由于RTCP分组是单独的分组，因此相关媒体数据和SDES信息之间没有直接关系，也没有命运共享。数据包的到达顺序很重要。通过标头扩展，如果要播放的媒体数据到达，可以确保SDES项到达。其次，很难确定是否实际交付了RTCP数据包，因为RTCP数据包既没有序列号，也没有提供RTCP数据包本身反馈的机制。
The SDES item may arrive both in RTCP and in RTP header extensions, potentially causing the value to flap back and forth at the time of updating. There are at least two reasons for these flaps. The first one is packet reordering, where a pre-update RTP or RTCP packet with an SDES item is delivered to the receiver after the first RTP/RTCP packet with the updated value. The second reason is the different code paths for RTP and RTCP in implementations. An update to the sender's SDES item parameter can take a different time to propagate to the receiver than the corresponding media data. For example, an RTCP packet with the SDES item included that may have been generated prior to the update can still reside in a buffer and be sent unmodified. The update of the item's value can, at the same time, cause RTP packets to be sent including the header extension, prior to the RTCP packet being sent.
SDES项可能在RTCP和RTP头扩展中到达，这可能导致值在更新时来回摆动。这些皮瓣至少有两个原因。第一种是数据包重新排序，其中在具有更新值的第一个RTP/RTCP数据包之后，将带有SDES项的预更新RTP或RTCP数据包传递给接收方。第二个原因是RTP和RTCP在实现中的代码路径不同。对发送方SDES项参数的更新可能需要与相应媒体数据不同的时间传播到接收方。例如，可能在更新之前生成的包含SDES项的RTCP数据包仍然可以驻留在缓冲区中，并且可以不经修改地发送。同时，项目值的更新可导致在发送RTCP数据包之前发送RTP数据包，包括报头扩展。
However, most of these issues can be avoided by the receiver performing some checks before updating the receiver's stored value. To handle flaps caused by reordering, SDES items received in RTP packets with the same or a lower extended sequence number than the
然而，在更新接收器的存储值之前，接收器执行一些检查可以避免大多数问题。为了处理由重新排序引起的抖动，SDES项目以RTP数据包的形式接收，其扩展序列号与原始序列号相同或更低
last change MUST NOT be applied, i.e., discard items that can be determined to be older than the current one. For compound RTCP packets, which will contain an SR packet (assuming an active RTP sender), the receiver can use the RTCP SR timestamp field to determine at what approximate time it was transmitted. If the timestamp is earlier than the last received RTP packet with a header extension carrying an SDES item, and especially if carrying a previously used value, the SDES item in the RTCP SDES packet can be ignored. Note that media processing and transmission pacing can easily cause the RTP header timestamp field as well as the RTCP SR timestamp field to not match with the actual transmission time.
不得应用上次更改，即丢弃可确定为比当前更改旧的项目。对于将包含SR数据包的复合RTCP数据包（假设为活动RTP发送方），接收方可使用RTCP SR时间戳字段确定其传输的大致时间。如果时间戳早于最后一个接收到的RTP数据包，且报头扩展携带SDES项，尤其是如果携带先前使用的值，则可以忽略RTCP SDES数据包中的SDES项。请注意，媒体处理和传输调整很容易导致RTP报头时间戳字段以及RTCP SR时间戳字段与实际传输时间不匹配。
When Robust Header Compression (ROHC) [RFC5225] is used with RTP, the RTP header extension [RFC5285] data itself is not part of what is being compressed and thus does not impact header compression performance. The extension indicator (X) bit in the RTP header is, however, compressed. It is classified as rarely changing, which may no longer be true for all RTP header extension usage, in turn leading to lower header compression efficiency.
当鲁棒头压缩（ROHC）[RFC5225]与RTP一起使用时，RTP头扩展[RFC5285]数据本身不是被压缩的数据的一部分，因此不会影响头压缩性能。然而，RTP报头中的扩展指示符（X）位被压缩。它被归类为很少更改，这可能不再适用于所有RTP头扩展使用，从而导致较低的头压缩效率。
This section details the following updates made by IANA:
本节详细介绍了IANA进行的以下更新：
o Creation of a new sub-registry reserved for RTCP SDES items with the URN subspace "urn:ietf:params:rtp-hdrext:sdes:" in the "RTP Compact Header Extensions" registry.
o 创建为RTCP SDES项目保留的新子注册表，该子注册表在“rtp Compact Header Extensions”注册表中具有URN子空间“URN:ietf:params:rtp hdrext:SDES:”。
o Registration of the SDES items appropriate for use with the RTP header extension defined in this document.
o 注册SDES项目，以便与本文档中定义的RTP标头扩展一起使用。
IANA has registered the following entry in the "RTP Compact Header Extensions" registry:
IANA已在“RTP Compact Header Extensions”注册表中注册了以下条目：
Extension URI: urn:ietf:params:rtp-hdrext:sdes
Description: Reserved as base URN for RTCP SDES items that are also
defined as RTP compact header extensions.
Contact: Authors of RFC 7941
Reference: RFC 7941
Extension URI: urn:ietf:params:rtp-hdrext:sdes
Description: Reserved as base URN for RTCP SDES items that are also
defined as RTP compact header extensions.
Contact: Authors of RFC 7941
Reference: RFC 7941
The reason to register a base URN for an SDES subspace is that the name represents an RTCP Source Description item, for which a specification is strongly recommended [RFC3550].
为SDES子空间注册基本URN的原因是该名称表示RTCP源描述项，强烈建议使用规范[RFC3550]。
IANA has created a sub-registry to the "RTP Compact Header Extensions" registry, with the same basic requirements, structure, and layout as the "RTP Compact Header Extensions" registry.
IANA为“RTP Compact Header Extensions”注册表创建了一个子注册表，其基本要求、结构和布局与“RTP Compact Header Extensions”注册表相同。
o Registry name: RTP SDES Compact Header Extensions
o 注册表名称：RTP SDES Compact标头扩展
o Specification: RFC 7941
o 规格：RFC7941
o Information required: Same as for the "RTP Compact Header Extensions" registry [RFC5285]
o 所需信息：与“RTP Compact Header Extensions”注册表相同[RFC5285]
o Review process: Same as for the "RTP Compact Header Extensions" registry [RFC5285], with the following requirements added to the Expert Review [RFC5226]:
o 评审过程：与“RTP Compact Header Extensions”注册表[RFC5285]相同，专家评审[RFC5226]中增加了以下要求：
1. Any registration using an extension URI that starts with "urn:ietf:params:rtp-hdrext:sdes:" (Section 5.1) MUST also have a registered Source Description item in the "RTP SDES item types" registry.
1. 使用以“urn:ietf:params:rtp hdrext:sdes:”（第5.1节）开头的扩展URI进行的任何注册还必须在“rtp sdes项类型”注册表中具有已注册的源描述项。
2. Security and privacy considerations for the SDES item MUST be provided with the registration.
2. SDES项目的安全和隐私注意事项必须随注册一起提供。
3. Information MUST be provided on why this SDES item requires timely delivery, motivating it to be transported in a header extension rather than as RTCP only.
3. 必须提供有关此SDES项目需要及时交付的原因的信息，以促使其在标题扩展中传输，而不是仅作为RTCP传输。
o Size and format of entries: Same as for the "RTP Compact Header Extensions" registry [RFC5285].
o 条目的大小和格式：与“RTP Compact Header Extensions”注册表相同[RFC5285]。
o Initial assignments: See Section 5.3 of this document.
o 初始作业：见本文件第5.3节。
IANA has registered the following SDES item in the newly formed "RTP SDES Compact Header Extensions" registry:
IANA已在新成立的“RTP SDES Compact Header Extensions”注册表中注册了以下SDES项：
Extension URI: urn:ietf:params:rtp-hdrext:sdes:cname
Description: Source Description: Canonical End-Point Identifier
(SDES CNAME)
Contact: Authors of RFC 7941
Reference: RFC 7941
Extension URI: urn:ietf:params:rtp-hdrext:sdes:cname
Description: Source Description: Canonical End-Point Identifier
(SDES CNAME)
Contact: Authors of RFC 7941
Reference: RFC 7941
Source Description items may contain data that are sensitive from a security perspective. There are SDES items that are or may be sensitive from a user privacy perspective, like CNAME, NAME, EMAIL, PHONE, LOC, and H323-CADDR. Some may contain sensitive information, like NOTE and PRIV, while others may be sensitive from profiling implementations for vulnerability or other reasons, like TOOL. The CNAME sensitivity can vary depending on how it is generated and what persistence it has. A short-term CNAME identifier generated using a random number generator [RFC7022] may have minimal security implications, while a CNAME of the form user@host has privacy concerns, and a CNAME generated from a Media Access Control (MAC) address has long-term tracking potentials.
源描述项可能包含从安全角度看敏感的数据。从用户隐私角度来看，SDES项目是或可能是敏感的，如CNAME、姓名、电子邮件、电话、LOC和H323-CADDR。一些可能包含敏感信息，如NOTE和PRIV，而另一些可能由于漏洞或其他原因（如工具）而对分析实现敏感。CNAME敏感度可能因其生成方式和持久性而异。使用随机数生成器[RFC7022]生成的短期CNAME标识符可能具有最小的安全影响，而user@host存在隐私问题，并且从媒体访问控制（MAC）地址生成的CNAME具有长期跟踪潜力。
In RTP sessions where any type of confidentiality protection is enabled for RTCP, the SDES item header extensions MUST also be protected. This implies that to provide confidentiality, users of the Secure Real-time Transport Protocol (SRTP) need to implement and use encrypted header extensions per [RFC6904]. SDES items carried as RTP header extensions MUST then use commensurate strength algorithms and SHOULD use the same cryptographic primitives (algorithms, modes) as applied to RTCP packets carrying corresponding SDES items. If the security level is chosen to be different for an SDES item in RTCP and an RTP header extension, it is important to justify the exception and to consider the security properties as the worst in each aspect for the different configurations. It is worth noting that the current SRTP [RFC3711] only provides protection for the next trusted RTP/RTCP hop, which is not necessarily end to end.
在RTP会话中，如果为RTCP启用了任何类型的机密性保护，则还必须保护SDES项头扩展。这意味着为了提供机密性，安全实时传输协议（SRTP）的用户需要根据[RFC6904]实现并使用加密的报头扩展。然后，作为RTP头扩展携带的SDE项必须使用相应的强度算法，并应使用与携带相应SDE项的RTCP数据包相同的加密原语（算法、模式）。如果对于RTCP中的SDE项目和RTP头扩展，选择安全级别是不同的，那么重要的是要为异常辩解，并将安全属性视为不同配置中各方面最差的属性。值得注意的是，当前SRTP[RFC3711]仅为下一个受信任的RTP/RTCP跃点提供保护，这不一定是端到端的。
The general RTP header extension mechanism [RFC5285] does not itself contain any functionality that is a significant risk for a denial-of-service attack, neither from processing nor from storage requirements. The extension for SDES items defined in this document can potentially be a risk. The risk depends on the received SDES item and its content. If the SDES item causes the receiver to perform a large amount of processing, create significant storage structures, or emit network traffic, such a risk does exist. The CNAME SDES item in the RTP header extension is only a minor risk, as reception of a CNAME item will create an association between the stream carrying the SDES item and other RTP streams with the same SDES item. This usually results in time synchronizing the media streams; thus, some additional processing is performed. However, the application's media quality is likely more affected by an erroneous or changing association and media synchronization than the application quality impact caused by the additional processing.
通用RTP报头扩展机制[RFC5285]本身不包含任何可能导致拒绝服务攻击的功能，无论是来自处理还是来自存储需求。本文件中定义的SDES项目扩展可能存在风险。风险取决于收到的SDES项目及其内容。如果SDES项导致接收方执行大量处理、创建重要的存储结构或发出网络流量，则确实存在此类风险。RTP标头扩展中的CNAME SDES项目只是一个小风险，因为接收CNAME项目将在承载SDES项目的流与具有相同SDES项目的其他RTP流之间创建关联。这通常导致媒体流的时间同步；因此，执行一些附加处理。但是，与附加处理引起的应用程序质量影响相比，错误或变化的关联和媒体同步可能更影响应用程序的媒体质量。
As the SDES items are used by the RTP-based application to establish relationships between RTP streams or between an RTP stream and information about the originating participant, there SHOULD be strong integrity protection and source authentication of the header extensions. If not, an attacker can modify the SDES item value to create erroneous relationship bindings in the receiving application. For information regarding options for securing RTP, see [RFC7201].
由于基于RTP的应用程序使用SDES项来建立RTP流之间或RTP流与原始参与者信息之间的关系，因此应该对报头扩展进行强大的完整性保护和源身份验证。否则，攻击者可以修改SDES项值，在接收应用程序中创建错误的关系绑定。有关保护RTP选项的信息，请参阅[RFC7201]。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[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, <http://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月<http://www.rfc-editor.org/info/rfc3550>.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 2008, <http://www.rfc-editor.org/info/rfc5285>.
[RFC5285]Singer，D.和H.Desneni，“RTP报头扩展的一般机制”，RFC 5285，DOI 10.17487/RFC5285，2008年7月<http://www.rfc-editor.org/info/rfc5285>.
[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, DOI 10.17487/RFC6904, April 2013, <http://www.rfc-editor.org/info/rfc6904>.
[RFC6904]Lennox，J.，“安全实时传输协议（SRTP）中的报头扩展加密”，RFC 6904，DOI 10.17487/RFC6904，2013年4月<http://www.rfc-editor.org/info/rfc6904>.
[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, <http://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月<http://www.rfc-editor.org/info/rfc3611>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<http://www.rfc-editor.org/info/rfc3629>.
[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, <http://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月<http://www.rfc-editor.org/info/rfc3711>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC 4566，DOI 10.17487/RFC4566，2006年7月<http://www.rfc-editor.org/info/rfc4566>.
[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, <http://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月<http://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, <http://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月<http://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, <http://www.rfc-editor.org/info/rfc5109>.
[RFC5109]Li，A.，Ed.“通用前向纠错的RTP有效载荷格式”，RFC 5109，DOI 10.17487/RFC5109，2007年12月<http://www.rfc-editor.org/info/rfc5109>.
[RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite", RFC 5225, DOI 10.17487/RFC5225, April 2008, <http://www.rfc-editor.org/info/rfc5225>.
[RFC5225]Pelletier，G.和K.Sandlund，“鲁棒头压缩版本2（ROHCv2）：RTP、UDP、IP、ESP和UDP Lite的配置文件”，RFC 5225，DOI 10.17487/RFC5225，2008年4月<http://www.rfc-editor.org/info/rfc5225>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, <http://www.rfc-editor.org/info/rfc5576>.
[RFC5576]Lennox，J.，Ott，J.，和T.Schierl，“会话描述协议（SDP）中的源特定媒体属性”，RFC 5576，DOI 10.17487/RFC5576，2009年6月<http://www.rfc-editor.org/info/rfc5576>.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, <http://www.rfc-editor.org/info/rfc5888>.
[RFC5888]Camarillo，G.和H.Schulzrinne，“会话描述协议（SDP）分组框架”，RFC 5888，DOI 10.17487/RFC5888，2010年6月<http://www.rfc-editor.org/info/rfc5888>.
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010, <http://www.rfc-editor.org/info/rfc6051>.
[RFC6051]Perkins，C.和T.Schierl，“RTP流的快速同步”，RFC 6051，DOI 10.17487/RFC6051，2010年11月<http://www.rfc-editor.org/info/rfc6051>.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, September 2013, <http://www.rfc-editor.org/info/rfc7022>.
[RFC7022]Begen，A.，Perkins，C.，Wing，D.，和E.Rescorla，“选择RTP控制协议（RTCP）规范名称（CNAMEs）的指南”，RFC 7022，DOI 10.17487/RFC7022，2013年9月<http://www.rfc-editor.org/info/rfc7022>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <http://www.rfc-editor.org/info/rfc7201>.
[RFC7201]Westerlund，M.和C.Perkins，“保护RTP会话的选项”，RFC 7201，DOI 10.17487/RFC7201，2014年4月<http://www.rfc-editor.org/info/rfc7201>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, <http://www.rfc-editor.org/info/rfc7656>.
[RFC7656]Lennox，J.，Gross，K.，Nandakumar，S.，Salgueiro，G.，和B.Burman，Ed.，“实时传输协议（RTP）源的语义和机制分类”，RFC 7656，DOI 10.17487/RFC7656，2015年11月<http://www.rfc-editor.org/info/rfc7656>.
[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-32, August 2016.
[SDP-BUNDLE]Holmberg，C.，Alvestrand，H.，和C.Jennings，“使用会话描述协议（SDP）协商媒体多路复用”，正在进行的工作，草稿-ietf-mmusic-SDP-BUNDLE-negotiation-32，2016年8月。
Acknowledgments
致谢
The authors would like to thank the following individuals for feedback and suggestions: Colin Perkins, Ben Campbell, and Samuel Weiler.
作者要感谢以下个人的反馈和建议：科林·珀金斯、本·坎贝尔和塞缪尔·韦勒。
Authors' Addresses
作者地址
Magnus Westerlund Ericsson Farogatan 6 SE-164 80 Stockholm Sweden
Magnus Westerlund Ericsson Farogatan 6 SE-164 80瑞典斯德哥尔摩
Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com
Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com
Bo Burman Ericsson Gronlandsgatan 31 Stockholm 16480 Sweden
Bo Burman Ericsson Gronlandsgatan 31斯德哥尔摩16480瑞典
Email: bo.burman@ericsson.com
Email: bo.burman@ericsson.com
Roni Even Huawei Technologies Tel Aviv Israel
Roni甚至华为技术公司以色列特拉维夫
Email: roni.even@mail01.huawei.com
Email: roni.even@mail01.huawei.com
Mo Zanaty Cisco Systems 7100 Kit Creek RTP, NC 27709 United States of America
Mo Zanaty Cisco Systems 7100 Kit Creek RTP，美国北卡罗来纳州27709
Email: mzanaty@cisco.com
Email: mzanaty@cisco.com