Internet Engineering Task Force (IETF) C. Perkins
Request for Comments: 6051 University of Glasgow
Updates: 3550 T. Schierl
Category: Standards Track Fraunhofer HHI
ISSN: 2070-1721 November 2010
Internet Engineering Task Force (IETF) C. Perkins
Request for Comments: 6051 University of Glasgow
Updates: 3550 T. Schierl
Category: Standards Track Fraunhofer HHI
ISSN: 2070-1721 November 2010
Rapid Synchronisation of RTP Flows
RTP流的快速同步
Abstract
摘要
This memo outlines how RTP sessions are synchronised, and discusses how rapidly such synchronisation can occur. We show that most RTP sessions can be synchronised immediately, but that the use of video switching multipoint conference units (MCUs) or large source-specific multicast (SSM) groups can greatly increase the synchronisation delay. This increase in delay can be unacceptable to some applications that use layered and/or multi-description codecs.
本备忘录概述了RTP会话是如何同步的，并讨论了同步的速度。我们表明，大多数RTP会话可以立即同步，但使用视频交换多点会议单元（MCU）或大型源特定多播（SSM）组会大大增加同步延迟。延迟的增加对于使用分层和/或多描述编解码器的某些应用程序来说是不可接受的。
This memo introduces three mechanisms to reduce the synchronisation delay for such sessions. First, it updates the RTP Control Protocol (RTCP) timing rules to reduce the initial synchronisation delay for SSM sessions. Second, a new feedback packet is defined for use with the extended RTP profile for RTCP-based feedback (RTP/AVPF), allowing video switching MCUs to rapidly request resynchronisation. Finally, new RTP header extensions are defined to allow rapid synchronisation of late joiners, and guarantee correct timestamp-based decoding order recovery for layered codecs in the presence of clock skew.
本备忘录介绍了三种机制，以减少此类会话的同步延迟。首先，它更新RTP控制协议（RTCP）定时规则，以减少SSM会话的初始同步延迟。其次，定义了一个新的反馈包，用于基于RTCP的反馈（RTP/AVPF）的扩展RTP配置文件，允许视频交换MCU快速请求重新同步。最后，定义了新的RTP报头扩展，以允许后期加入者的快速同步，并保证在存在时钟偏移的情况下，分层编解码器基于时间戳的正确解码顺序恢复。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第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/rfc6051.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6051.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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. Synchronisation of RTP Flows ....................................4
2.1. Initial Synchronisation Delay ..............................5
2.1.1. Unicast Sessions ....................................5
2.1.2. Source-Specific Multicast (SSM) Sessions ............6
2.1.3. Any-Source Multicast (ASM) Sessions .................7
2.1.4. Discussion ..........................................8
2.2. Synchronisation for Late Joiners ...........................9
3. Reducing RTP Synchronisation Delays ............................10
3.1. Reduced Initial RTCP Interval for SSM Senders .............10
3.2. Rapid Resynchronisation Request ...........................10
3.3. In-Band Delivery of Synchronisation Metadata ..............11
4. Application to Decoding Order Recovery in Layered Codecs .......14
4.1. In-Band Synchronisation for Decoding Order Recovery .......14
4.2. Timestamp-Based Decoding Order Recovery ...................15
4.3. Example ...................................................16
5. Security Considerations ........................................18
6. IANA Considerations ............................................19
7. Acknowledgements ...............................................19
8. References .....................................................20
8.1. Normative References ......................................20
8.2. Informative References ....................................20
1. Introduction ....................................................3
2. Synchronisation of RTP Flows ....................................4
2.1. Initial Synchronisation Delay ..............................5
2.1.1. Unicast Sessions ....................................5
2.1.2. Source-Specific Multicast (SSM) Sessions ............6
2.1.3. Any-Source Multicast (ASM) Sessions .................7
2.1.4. Discussion ..........................................8
2.2. Synchronisation for Late Joiners ...........................9
3. Reducing RTP Synchronisation Delays ............................10
3.1. Reduced Initial RTCP Interval for SSM Senders .............10
3.2. Rapid Resynchronisation Request ...........................10
3.3. In-Band Delivery of Synchronisation Metadata ..............11
4. Application to Decoding Order Recovery in Layered Codecs .......14
4.1. In-Band Synchronisation for Decoding Order Recovery .......14
4.2. Timestamp-Based Decoding Order Recovery ...................15
4.3. Example ...................................................16
5. Security Considerations ........................................18
6. IANA Considerations ............................................19
7. Acknowledgements ...............................................19
8. References .....................................................20
8.1. Normative References ......................................20
8.2. Informative References ....................................20
When using RTP to deliver multimedia content it's often necessary to synchronise playout of audio and video components of a presentation. This is achieved using information contained in RTP Control Protocol (RTCP) sender report (SR) packets [RFC3550]. These are sent periodically, and the components of a multimedia session cannot be synchronised until sufficient RTCP SR packets have been received for each RTP flow to allow the receiver to establish mappings between the media clock used for each RTP flow, and the common (NTP-format) reference clock used to establish synchronisation.
使用RTP传送多媒体内容时，通常需要同步演示文稿音频和视频组件的播放。这是通过使用RTP控制协议（RTCP）发送方报告（SR）数据包[RFC3550]中包含的信息实现的。这些是周期性发送的，并且在为每个RTP流接收到足够的RTCP SR包以允许接收器在用于每个RTP流的媒体时钟和用于建立同步的公共（NTP格式）参考时钟之间建立映射之前，不能同步多媒体会话的组件。
Recently, concern has been expressed that this synchronisation delay is problematic for some applications, for example those using layered or multi-description video coding. This memo reviews the operations of RTP synchronisation, and describes the synchronisation delay that can be expected. Three backwards compatible extensions to the basic RTP synchronisation mechanism are proposed:
最近，有人表示担心这种同步延迟对于一些应用是有问题的，例如那些使用分层或多描述视频编码的应用。本备忘录回顾了RTP同步的操作，并描述了预期的同步延迟。建议对基本RTP同步机制进行三种向后兼容的扩展：
o The RTCP transmission timing rules are relaxed for source-specific multicast (SSM) senders, to reduce the initial synchronisation latency for large SSM groups. See Section 3.1.
o 对于源特定多播（SSM）发送方，RTCP传输定时规则被放宽，以减少大型SSM组的初始同步延迟。见第3.1节。
o An enhancement to the extended RTP profile for RTCP-based feedback (RTP/AVPF) [RFC4585] is defined to allow receivers to request additional RTCP SR packets, providing the metadata needed to synchronise RTP flows. This can reduce the synchronisation delay when joining sessions with large RTCP reporting intervals, in the presence of packet loss, or when video switching MCUs are employed. See Section 3.2.
o 定义了对基于RTCP的反馈（RTP/AVPF）[RFC4585]的扩展RTP配置文件的增强，以允许接收机请求额外的RTCP SR数据包，从而提供同步RTP流所需的元数据。这可以在加入具有较大RTCP报告间隔的会话、存在分组丢失或使用视频交换MCU时减少同步延迟。见第3.2节。
o Two RTP header extensions are defined, to deliver synchronisation metadata in-band with RTP data packets. These extensions provide synchronisation metadata that is aligned with RTP data packets, and so eliminate the need to estimate clock skew between flows before synchronisation. They can also reduce the need to receive RTCP SR packets before flows can be synchronised, although it does not eliminate the need for RTCP. See Section 3.3.
o 定义了两个RTP报头扩展，用于在带内与RTP数据包交付同步元数据。这些扩展提供与RTP数据包一致的同步元数据，因此无需在同步之前估计流之间的时钟偏差。它们还可以减少在同步流之前接收RTCP SR数据包的需要，尽管这并不能消除对RTCP的需要。见第3.3节。
The immediate use-case for these extensions is to reduce the delay due to synchronisation when joining a layered video session (e.g., an H.264/SVC (Scalable Video Coding) session in Non-Interleaved Timestamp-based (NI-T) mode [AVT-RTP-SVC]). The extensions are not specific to layered coding, however, and can be used in any environment when synchronisation latency is an issue.
这些扩展的直接用例是在加入分层视频会话（例如，基于非交织时间戳（NI-T）模式[AVT-RTP-SVC]的H.264/SVC（可伸缩视频编码）会话）时减少由于同步而产生的延迟。然而，这些扩展并不特定于分层编码，并且可以在同步延迟是一个问题的任何环境中使用。
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]中所述进行解释。
RTP flows are synchronised by receivers based on information that is contained in RTCP SR packets generated by senders (specifically, the NTP-format timestamp and the RTP timestamp). Synchronisation requires that a common reference clock MUST be used to generate the NTP-format timestamps in a set of flows that are to be synchronised (i.e., when synchronising several RTP flows, the RTP timestamps for each flow are derived from separate, and media specific, clocks, but the NTP-format timestamps in the RTCP SR packets of all flows to be synchronised MUST be sampled from the same clock). To achieve faster and more accurate synchronisation, it is further RECOMMENDED that senders and receivers use a synchronised common NTP-format reference clock with common properties, especially timebase, where possible (recognising that this is often not possible when RTP is used outside of controlled environments); the means by which that common reference clock and its properties are signalled and distributed is outside the scope of this memo.
接收方根据发送方生成的RTCP SR数据包中包含的信息（具体而言，NTP格式时间戳和RTP时间戳）同步RTP流。同步要求必须使用公共参考时钟在要同步的一组流中生成NTP格式的时间戳（即，当同步多个RTP流时，每个流的RTP时间戳来自单独的、特定于媒体的时钟，但所有要同步的流的RTCP SR数据包中的NTP格式时间戳必须从同一时钟采样）.为了实现更快、更准确的同步，进一步建议发送方和接收方使用具有共同属性的同步通用NTP格式参考时钟，特别是在可能的情况下使用时基（认识到在受控环境之外使用RTP时，这通常是不可能的）公共参考时钟及其属性的信号发送和分配方式不在本备忘录的范围内。
For multimedia sessions, each type of media (e.g., audio or video) is sent in a separate RTP session, and the receiver associates RTP flows to be synchronised by means of the canonical end-point identifier (CNAME) item included in the RTCP Source Description (SDES) packets generated by the sender or signalled out of band [RFC5576]. For layered media, different layers can be sent in different RTP sessions, or using different synchronisation source (SSRC) values within a single RTP session; in both cases, the CNAME is used to identify flows to be synchronised. To ensure synchronisation, an RTP sender MUST therefore send periodic compound RTCP packets following Section 6 of RFC 3550 [RFC3550].
对于多媒体会话，每种类型的媒体（例如，音频或视频）在单独的RTP会话中发送，并且接收器将RTP流关联起来，以便通过发送方生成的RTCP源描述（SDES）包中包含的规范端点标识符（CNAME）项或带外发信号的方式进行同步[RFC5576]。对于分层介质，可以在不同的RTP会话中发送不同的层，或者在单个RTP会话中使用不同的同步源（SSRC）值；在这两种情况下，CNAME用于识别要同步的流。为确保同步，RTP发送方因此必须按照RFC 3550[RFC3550]第6节定期发送复合RTCP数据包。
The timing of these periodic compound RTCP packets will depend on the number of members in each RTP session, the fraction of those that are sending data, the session bandwidth, the configured RTCP bandwidth fraction, and whether the session is multicast or unicast (see RFC 3550, Section 6.2 for details). In summary, RTCP control traffic is allocated a small fraction, generally 5%, of the session bandwidth, and of that fraction, one quarter is allocated to active RTP senders, while receivers use the remaining three quarters (these fractions can be configured via the Session Description Protocol (SDP) [RFC3556]). Each member of an RTP session derives an RTCP reporting interval based on these fractions, whether the session is multicast or unicast, the number of members it has observed, and whether it is actively sending data or not. It then sends a compound
这些周期性复合RTCP数据包的定时将取决于每个RTP会话中的成员数量、发送数据的部分、会话带宽、配置的RTCP带宽部分，以及会话是多播还是单播（详见RFC 3550第6.2节）。总之，RTCP控制流量分配给会话带宽的一小部分，通常为5%，其中四分之一分配给活动RTP发送方，而接收方使用其余四分之三（这些部分可通过会话描述协议（SDP）[RFC3556]进行配置）。RTP会话的每个成员都根据这些分数、会话是多播还是单播、它观察到的成员数以及它是否正在主动发送数据来导出RTCP报告间隔。然后它发送一个复合物
RTCP packet on average once per reporting interval (the actual packet transmission time is randomised in the range [0.5 ... 1.5] times the reporting interval to avoid synchronisation of reports).
每个报告间隔平均一次RTCP数据包（实际数据包传输时间在报告间隔的[0.5…1.5]倍范围内随机，以避免报告同步）。
A minimum reporting interval of 5 seconds is RECOMMENDED, except that the delay before sending the initial report "MAY be set to half the minimum interval to allow quicker notification that the new participant is present" [RFC3550]. Also, for unicast sessions, "the delay before sending the initial compound RTCP packet MAY be zero" [RFC3550]. In addition, for unicast sessions, and for active senders in a multicast session, the fixed minimum reporting interval MAY be scaled to "360 divided by the session bandwidth in kilobits/second. This minimum is smaller than 5 seconds for bandwidths greater than 72 kb/s" [RFC3550].
建议最小报告间隔为5秒，但发送初始报告之前的延迟“可设置为最小间隔的一半，以便更快地通知新参与者在场”[RFC3550]。此外，对于单播会话，“发送初始复合RTCP数据包之前的延迟可能为零”[RFC3550]。此外，对于单播会话和多播会话中的活动发送方，固定的最小报告间隔可以缩放为“360除以会话带宽（千比特/秒）。对于带宽大于72 kb/s的会话，该最小值小于5秒”[RFC3550]。
A multimedia session comprises a set of concurrent RTP sessions among a common group of participants, using one RTP session for each media type. For example, a videoconference (which is a multimedia session) might contain an audio RTP session and a video RTP session. To allow a receiver to synchronise the components of a multimedia session, a compound RTCP packet containing an RTCP SR packet and an RTCP SDES packet with a CNAME item MUST be sent to each of the RTP sessions in the multimedia session by each sender. A receiver cannot synchronise playout across the multimedia session until such RTCP packets have been received on all of the component RTP sessions. If there is no packet loss, this gives an expected initial synchronisation delay equal to the average time taken to receive the first RTCP packet in the RTP session with the longest RTCP reporting interval. This will vary between unicast and multicast RTP sessions.
多媒体会话包括一组公共参与者之间的并发RTP会话，每个媒体类型使用一个RTP会话。例如，视频会议（是多媒体会话）可能包含音频RTP会话和视频RTP会话。为了允许接收方同步多媒体会话的组件，每个发送方必须将包含RTCP SR数据包和带有CNAME项目的RTCP SDES数据包的复合RTCP数据包发送到多媒体会话中的每个RTP会话。在所有组件RTP会话上接收到此类RTCP数据包之前，接收器无法跨多媒体会话同步播放。如果没有数据包丢失，则预期的初始同步延迟等于RTP会话中接收第一个RTCP数据包所用的平均时间，RTP报告间隔最长。这在单播和多播RTP会话之间会有所不同。
The initial synchronisation delay for layered sessions is similar to that for multimedia sessions. The layers cannot be synchronised until the RTCP SR and CNAME information has been received for each layer in the session.
分层会话的初始同步延迟与多媒体会话的初始同步延迟类似。在会话中每个层接收到RTCP SR和CNAME信息之前，无法同步这些层。
For unicast multimedia or layered sessions, senders SHOULD transmit an initial compound RTCP packet (containing an RTCP SR packet and an RTCP SDES packet with a CNAME item) immediately on joining each RTP session in the multimedia session. The individual RTP sessions are considered to be joined once any in-band signalling for NAT traversal
对于单播多媒体或分层会话，发送方应在加入多媒体会话中的每个RTP会话时立即发送初始复合RTCP数据包（包含RTCP SR数据包和带有CNAME项的RTCP SDES数据包）。在NAT穿越的任何带内信令中，单个RTP会话被视为一次加入
(e.g., [RFC5245]) and/or security keying (e.g., [RFC5764], [ZRTP]) has concluded, and the media path is open. This implies that the initial RTCP packet is sent in parallel with the first data packet following the guidance in RFC 3550 that "the delay before sending the initial compound RTCP packet MAY be zero" and, in the absence of any packet loss, flows can be synchronised immediately.
（例如，[RFC5245]）和/或安全密钥（例如，[RFC5764]，[ZRTP]）已结束，并且媒体路径已打开。这意味着初始RTCP数据包按照RFC 3550中的指导“发送初始复合RTCP数据包之前的延迟可能为零”与第一个数据包并行发送，并且在没有任何数据包丢失的情况下，可以立即同步流。
It is expected that NAT pinholes, firewall holes, quality-of-service, and media security keys will have been negotiated as part of the signalling, whether in-band or out-of-band, before the first RTCP packet is sent. This should ensure that any middleboxes are ready to accept traffic, and reduce the likelihood that the initial RTCP packet will be lost.
预计在发送第一个RTCP数据包之前，NAT针孔、防火墙孔、服务质量和媒体安全密钥将作为信令的一部分进行协商，无论是带内还是带外。这应确保任何中间盒都准备好接受流量，并降低初始RTCP数据包丢失的可能性。
For multicast sessions, the delay before sending the initial RTCP packet, and hence the synchronisation delay, varies with the session bandwidth and the number of members in the session. For a multicast multimedia or layered session, the average synchronisation delay will depend on the slowest of the component RTP sessions; this will generally be the session with the lowest bandwidth (assuming all the RTP sessions have the same number of members).
对于多播会话，发送初始RTCP数据包之前的延迟以及同步延迟随会话带宽和会话中成员的数量而变化。对于多播多媒体或分层会话，平均同步延迟将取决于最慢的组件RTP会话；这通常是带宽最低的会话（假设所有RTP会话具有相同数量的成员）。
When sending to a multicast group, the reduced minimum RTCP reporting interval of 360 seconds divided by the session bandwidth in kilobits per second [RFC3550] should be used when synchronisation latency is likely to be an issue. Also, as usual, the reporting interval is halved for the first RTCP packet. Depending on the session bandwidth and the number of members, this gives the average synchronisation delays shown in Figure 1.
当发送到多播组时，如果可能存在同步延迟问题，则应使用减少的最小RTCP报告间隔（360秒）除以会话带宽（千比特/秒）[RFC3550]。此外，与往常一样，第一个RTCP数据包的报告间隔减半。根据会话带宽和成员数量，这将给出图1所示的平均同步延迟。
Session| Number of receivers:
Bandwidth| 2 3 4 5 10 100 1000 10000
--+------------------------------------------------
8 kbps| 2.73 4.10 5.47 5.47 5.47 5.47 5.47 5.47
16 kbps| 2.50 2.50 2.73 2.73 2.73 2.73 2.73 2.73
32 kbps| 2.50 2.50 2.50 2.50 2.50 2.50 2.50 2.50
64 kbps| 2.50 2.50 2.50 2.50 2.50 2.50 2.50 2.50
128 kbps| 1.41 1.41 1.41 1.41 1.41 1.41 1.41 1.41
256 kbps| 0.70 0.70 0.70 0.70 0.70 0.70 0.70 0.70
512 kbps| 0.35 0.35 0.35 0.35 0.35 0.35 0.35 0.35
1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.18 0.18 0.18
2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.09 0.09 0.09
4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04
Session| Number of receivers:
Bandwidth| 2 3 4 5 10 100 1000 10000
--+------------------------------------------------
8 kbps| 2.73 4.10 5.47 5.47 5.47 5.47 5.47 5.47
16 kbps| 2.50 2.50 2.73 2.73 2.73 2.73 2.73 2.73
32 kbps| 2.50 2.50 2.50 2.50 2.50 2.50 2.50 2.50
64 kbps| 2.50 2.50 2.50 2.50 2.50 2.50 2.50 2.50
128 kbps| 1.41 1.41 1.41 1.41 1.41 1.41 1.41 1.41
256 kbps| 0.70 0.70 0.70 0.70 0.70 0.70 0.70 0.70
512 kbps| 0.35 0.35 0.35 0.35 0.35 0.35 0.35 0.35
1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.18 0.18 0.18
2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.09 0.09 0.09
4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04
Figure 1: Average Initial Synchronisation Delay in Seconds for an RTP Session with 1 Sender
图1：具有1个发送方的RTP会话的平均初始同步延迟（以秒为单位）
These numbers assume a source-specific multicast channel with a single active sender, assuming an average RTCP packet size of 70 octets. These intervals are sufficient for lip-synchronisation without excessive delay, but might be viewed as having too much latency for synchronising parts of a layered video stream.
这些数字假定源特定的多播信道具有单个活动发送方，假定平均RTCP数据包大小为70个八位字节。这些间隔足以在没有过度延迟的情况下进行唇部同步，但是对于同步分层视频流的部分，可能被视为具有过多的延迟。
The RTCP interval is randomised in the usual manner, so the minimum synchronisation delay will be half these intervals, and the maximum delay will be 1.5 times these intervals. Note also that these RTCP intervals are calculated assuming perfect knowledge of the number of members in the session.
RTCP间隔以通常的方式随机化，因此最小同步延迟为这些间隔的一半，最大延迟为这些间隔的1.5倍。还请注意，这些RTCP间隔是在完全了解会话中成员数量的情况下计算的。
For ASM sessions, the fraction of members that are senders plays an important role, and causes more variation in average RTCP reporting interval. This is illustrated in Figure 2 and Figure 3, which show the RTCP reporting interval for the same session bandwidths and receiver populations as the SSM session described in Figure 1, but for sessions with 2 and 10 senders, respectively. It can be seen that the initial synchronisation delay scales with the number of senders (this is to ensure that the total RTCP traffic from all group members does not grow without bound) and can be significantly larger than for source-specific groups. Despite this, the initial synchronisation time remains acceptable for lip-synchronisation in typical small-to-medium sized group video conferencing scenarios.
对于ASM会话，作为发送方的成员比例起着重要作用，并导致平均RTCP报告间隔的变化更大。图2和图3对此进行了说明，其中显示了与图1中所述SSM会话相同的会话带宽和接收器总体的RTCP报告间隔，但分别针对具有2个和10个发送方的会话。可以看出，初始同步延迟随着发送方数量的增加而增加（这是为了确保来自所有组成员的总RTCP流量不会无限制地增长），并且可以显著大于特定于源的组。尽管如此，在典型的中小型群组视频会议场景中，初始同步时间对于lip同步仍然是可以接受的。
Note that multi-sender groups implemented using multi-unicast with a central RTP translator (Topo-Translator in the terminology of [RFC5117]) or mixer (Topo-Mixer), or some forms of video switching MCU (Topo-Video-switch-MCU) distribute RTCP packets to all members of the group, and so scale in the same way as an ASM group with regards to initial synchronisation latency.
请注意，使用带有中央RTP转换器（术语[RFC5117]中的Topo translator）或混合器（Topo mixer）或某种形式的视频交换MCU（Topo video switch MCU）的多单播实现的多发送方组将RTCP数据包分发给组的所有成员，因此，在初始同步延迟方面，其扩展方式与ASM组相同。
Session| Number of receivers:
Bandwidth| 2 3 4 5 10 100 1000 10000
--+------------------------------------------------
8 kbps| 2.73 4.10 5.47 6.84 10.94 10.94 10.94 10.94
16 kbps| 2.50 2.50 2.73 3.42 5.47 5.47 5.47 5.47
32 kbps| 2.50 2.50 2.50 2.50 2.73 2.73 2.73 2.73
64 kbps| 2.50 2.50 2.50 2.50 2.50 2.50 2.50 2.50
128 kbps| 1.41 1.41 1.41 1.41 1.41 1.41 1.41 1.41
256 kbps| 0.70 0.70 0.70 0.70 0.70 0.70 0.70 0.70
512 kbps| 0.35 0.35 0.35 0.35 0.35 0.35 0.35 0.35
1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.18 0.18 0.18
2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.09 0.09 0.09
4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04
Session| Number of receivers:
Bandwidth| 2 3 4 5 10 100 1000 10000
--+------------------------------------------------
8 kbps| 2.73 4.10 5.47 6.84 10.94 10.94 10.94 10.94
16 kbps| 2.50 2.50 2.73 3.42 5.47 5.47 5.47 5.47
32 kbps| 2.50 2.50 2.50 2.50 2.73 2.73 2.73 2.73
64 kbps| 2.50 2.50 2.50 2.50 2.50 2.50 2.50 2.50
128 kbps| 1.41 1.41 1.41 1.41 1.41 1.41 1.41 1.41
256 kbps| 0.70 0.70 0.70 0.70 0.70 0.70 0.70 0.70
512 kbps| 0.35 0.35 0.35 0.35 0.35 0.35 0.35 0.35
1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.18 0.18 0.18
2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.09 0.09 0.09
4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04
Figure 2: Average Initial Synchronisation Delay in Seconds for an RTP Session with 2 Senders
图2：具有2个发送方的RTP会话的平均初始同步延迟（秒）
Session| Number of receivers:
Bandwidth| 2 3 4 5 10 100 1000 10000
--+------------------------------------------------
8 kbps| 2.73 4.10 5.47 6.84 13.67 54.69 54.69 54.69
16 kbps| 2.50 2.50 2.73 3.42 6.84 27.34 27.34 27.34
32 kbps| 2.50 2.50 2.50 2.50 3.42 13.67 13.67 13.67
64 kbps| 2.50 2.50 2.50 2.50 2.50 6.84 6.84 6.84
128 kbps| 1.41 1.41 1.41 1.41 1.41 3.42 3.42 3.42
256 kbps| 0.70 0.70 0.70 0.70 0.70 1.71 1.71 1.71
512 kbps| 0.35 0.35 0.35 0.35 0.35 0.85 0.85 0.85
1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.43 0.43 0.43
2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.21 0.21 0.21
4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.11 0.11 0.11
Session| Number of receivers:
Bandwidth| 2 3 4 5 10 100 1000 10000
--+------------------------------------------------
8 kbps| 2.73 4.10 5.47 6.84 13.67 54.69 54.69 54.69
16 kbps| 2.50 2.50 2.73 3.42 6.84 27.34 27.34 27.34
32 kbps| 2.50 2.50 2.50 2.50 3.42 13.67 13.67 13.67
64 kbps| 2.50 2.50 2.50 2.50 2.50 6.84 6.84 6.84
128 kbps| 1.41 1.41 1.41 1.41 1.41 3.42 3.42 3.42
256 kbps| 0.70 0.70 0.70 0.70 0.70 1.71 1.71 1.71
512 kbps| 0.35 0.35 0.35 0.35 0.35 0.85 0.85 0.85
1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.43 0.43 0.43
2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.21 0.21 0.21
4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.11 0.11 0.11
Figure 3: Average Initial Synchronisation Delay in Seconds for an RTP Session with 10 Senders
图3：具有10个发送方的RTP会话的平均初始同步延迟（秒）
For unicast sessions, the existing RTCP SR-based mechanism allows for immediate synchronisation, provided the initial RTCP packet is not lost.
对于单播会话，现有的基于RTCP SR的机制允许立即同步，前提是初始RTCP数据包不会丢失。
For SSM sessions, the initial synchronisation delay is sufficient for lip-synchronisation, but may be larger than desired for some layered codecs. The rationale for not sending immediate RTCP packets for multicast groups is to avoid implosion of requests when large numbers of members simultaneously join the group ("flash crowd"). This is not an issue for SSM senders, since there can be at most one sender, so it is desirable to allow SSM senders to send an immediate RTCP SR
对于SSM会话，初始同步延迟对于lip同步是足够的，但是可能比某些分层编解码器所期望的要大。不向多播组发送即时RTCP数据包的基本原理是，当大量成员同时加入组（“闪存群组”）时，避免请求内爆。这对于SSM发送方来说不是问题，因为最多只能有一个发送方，所以最好允许SSM发送方立即发送RTCP SR
on joining a session (as is currently allowed for unicast sessions, which also don't suffer from the implosion problem). SSM receivers using unicast feedback would not be allowed to send immediate RTCP. For ASM sessions, implosion of responses is a concern, so no change is proposed to the RTCP timing rules.
加入会话时（当前允许单播会话，单播会话也不会出现内爆问题）。不允许使用单播反馈的SSM接收器立即发送RTCP。对于ASM会话，响应的内爆是一个问题，因此不建议对RTCP计时规则进行更改。
In all cases, it is possible that the initial RTCP SR packet is lost. In this case, the receiver will not be able to synchronise the media until the reporting interval has passed, and the next RTCP SR packet is sent. This is undesirable. Section 3.2 defines a new RTP/AVPF transport layer feedback message to request that an RTCP SR be generated, allowing rapid resynchronisation in the case of packet loss.
在所有情况下，初始RTCP SR数据包都可能丢失。在这种情况下，在超过报告间隔并发送下一个RTCP SR数据包之前，接收器将无法同步媒体。这是不可取的。第3.2节定义了新的RTP/AVPF传输层反馈消息，以请求生成RTCP SR，从而在数据包丢失的情况下允许快速重新同步。
Synchronisation between RTP sessions is potentially slower for late joiners than for participants present at the start of the session. The reasons for this are three-fold:
对于迟到的参与者，RTP会话之间的同步可能比会话开始时在场的参与者慢。原因有三：
1. Many of the optimisations that allow rapid transmission of RTCP SR packets apply only at the start of a session. This implies that a new participant may have to wait a complete RTCP reporting interval for each session before receiving the necessary data to synchronise media streams. This might potentially take several seconds, depending on the configured session bandwidth and the number of participants.
1. 许多允许快速传输RTCP SR数据包的优化仅在会话开始时适用。这意味着新参与者可能必须等待每个会话的完整RTCP报告间隔，然后才能接收同步媒体流所需的数据。这可能需要几秒钟，具体取决于配置的会话带宽和参与者数量。
2. Additional synchronisation delay comes from the nature of the RTCP timing rules. Packets are generated on average once per reporting interval, but with the exact transmission times being randomised +/- 50% to avoid synchronisation of reports. This is important to avoid network congestion in multicast sessions, but does mean that the timing of RTCP sender reports for different RTP sessions isn't synchronised. Accordingly, a receiver must estimate the skew on the NTP-format clock in order to align RTP timestamps across sessions. This estimation is an essential part of an RTP synchronisation implementation, and can be done with high accuracy given sufficient reports. Collecting sufficient RTCP SR data to perform this estimation, however, may require reception of several RTCP reports, further increasing the synchronisation delay.
2. 额外的同步延迟来自RTCP定时规则的性质。每个报告间隔平均生成一次数据包，但准确的传输时间是随机的+/-50%，以避免报告同步。这对于避免多播会话中的网络拥塞很重要，但确实意味着不同RTP会话的RTCP发送方报告的时间不同步。因此，接收机必须估计NTP格式时钟上的偏差，以便跨会话对齐RTP时间戳。该估计是RTP同步实施的一个重要部分，并且可以在提供足够报告的情况下以高精度完成。然而，收集足够的RTCP SR数据以执行此估计可能需要接收多个RTCP报告，从而进一步增加同步延迟。
3. Many media codecs have the notion of periodic access points, such that a newly joined receiver often cannot start decoding a media stream until the packets corresponding to the access point have been received. These access points may be sent less often than RTCP SR packets, and so may be the limiting factor in starting synchronised media playout for late joiners. The RTP extension
3. 许多媒体编解码器具有周期性接入点的概念，使得新加入的接收器通常在接收到与接入点对应的分组之前无法开始解码媒体流。这些接入点的发送频率可能低于RTCP SR数据包，因此可能是延迟加入者启动同步媒体播放的限制因素。RTP扩展
for unicast-based rapid acquisition of multicast RTP sessions [AVT-ACQUISITION-RTP] may be used to reduce the time taken to receive the access points in some scenarios.
对于基于单播的多播RTP会话的快速捕获，在某些场景中可以使用AVT-acquisition-RTP来减少接收接入点所花费的时间。
These delays are likely an issue for tuning in to an ongoing multicast RTP session, or for video switching MCUs.
这些延迟可能是调谐到正在进行的多播RTP会话或视频交换MCU的问题。
Three backwards compatible RTP extensions are defined to reduce the possible synchronisation delay: a reduced initial RTCP interval for SSM senders, a rapid resynchronisation request message, and RTP header extensions that can convey synchronisation metadata in-band.
定义了三个向后兼容的RTP扩展以减少可能的同步延迟：SSM发送方的缩短初始RTCP间隔、快速重新同步请求消息和可在频带内传输同步元数据的RTP头扩展。
In SSM sessions where the initial synchronisation delay is important, the RTP sender MAY set the delay before sending the initial compound RTCP packet to zero, and send its first RTCP packet immediately upon joining the SSM session. This is purely a local change to the sender that can be implemented as a configurable option. RTP receivers in an SSM session, sending unicast RTCP feedback, MUST NOT send RTCP packets with zero initial delay; the timing rules defined in [RFC5760] apply unchanged to receivers.
在初始同步延迟很重要的SSM会话中，RTP发送方可以在发送初始复合RTCP包之前将延迟设置为零，并在加入SSM会话后立即发送其第一个RTCP包。这纯粹是对发送方的本地更改，可以作为可配置选项实现。SSM会话中发送单播RTCP反馈的RTP接收器不得发送初始延迟为零的RTCP数据包；[RFC5760]中定义的定时规则不适用于接收机。
The general format of an RTP/AVPF transport layer feedback message is shown in Figure 4 (see [RFC4585] for details).
RTP/AVPF传输层反馈消息的一般格式如图4所示（有关详细信息，请参见[RFC4585]）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT=RTPFB=205 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT=RTPFB=205 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :
Figure 4: RTP/AVPF Transport Layer Feedback Message
图4:RTP/AVPF传输层反馈消息
One new feedback message type, RTCP-SR-REQ, is defined with FMT = 5. The Feedback Control Information (FCI) part of the feedback message MUST be empty. The SSRC of the packet sender indicates the member that is unable to synchronise media streams, while the SSRC of the media source indicates the sender of the media it is unable to synchronise. The length MUST equal 2.
一种新的反馈消息类型RTCP-SR-REQ定义为FMT=5。反馈消息的反馈控制信息（FCI）部分必须为空。数据包发送方的SSRC表示无法同步媒体流的成员，而媒体源的SSRC表示无法同步的媒体的发送方。长度必须等于2。
If the RTP/AVPF profile [RFC4585] is in use, this feedback message MAY be sent by a receiver to indicate that it's unable to synchronise some media streams, and desires that the media source transmit an RTCP SR packet as soon as possible (within the constraints of the RTCP timing rules for early feedback). When it receives such an indication, a media source that understands the RTCP-SR-REQ packet SHOULD generate an RTCP SR packet as soon as possible while complying with the RTCP early feedback rules. If the use of non-compound RTCP [RFC5506] was previously negotiated, both the feedback request and the RTCP SR response may be sent as non-compound RTCP packets. The RTCP-SR-REQ packet MAY be repeated once per RTCP reporting interval if no RTCP SR packet is forthcoming. The media source may ignore RTCP-SR-REQ packets if its regular schedule for transmission of synchronisation metadata can be expected to allow the receiver to synchronise the media streams within a reasonable time frame.
如果RTP/AVPF配置文件[RFC4585]正在使用中，则该反馈消息可由接收器发送以指示其无法同步某些媒体流，并期望媒体源尽快发送RTCP SR包（在用于早期反馈的RTCP定时规则的约束范围内）。当接收到此类指示时，理解RTCP-SR-REQ数据包的媒体源应尽快生成RTCP SR数据包，同时遵守RTCP早期反馈规则。如果先前协商使用非复合RTCP[RFC5506]，则反馈请求和RTCP SR响应均可作为非复合RTCP数据包发送。如果没有RTCP SR数据包，则RTCP-SR-REQ数据包可在每个RTCP报告间隔内重复一次。如果媒体源的同步元数据传输的常规调度可预期允许接收器在合理的时间帧内同步媒体流，则媒体源可忽略RTCP-SR-REQ分组。
When using SSM sessions with unicast feedback, it is possible that the feedback target and media source are not co-located. If a feedback target receives an RTCP-SR-REQ feedback message in such a case, the request should be forwarded to the media source. The mechanism to be used for forwarding such requests is not defined here.
使用具有单播反馈的SSM会话时，反馈目标和媒体源可能不在同一位置。在这种情况下，如果反馈目标收到RTCP-SR-REQ反馈消息，则应将请求转发至媒体源。此处未定义用于转发此类请求的机制。
If the feedback target provides a network management interface, it might be useful to provide a log of which receivers send RTCP-SR-REQ feedback packets and which do not, since those that do not will see slower stream synchronisation.
如果反馈目标提供网络管理接口，则提供哪些接收器发送RTCP-SR-REQ反馈数据包以及哪些不发送RTCP-SR-REQ反馈数据包的日志可能很有用，因为不发送RTCP-SR-REQ反馈数据包的接收器将看到较慢的流同步。
The RTP header extension mechanism defined in [RFC5285] can be adapted to carry an OPTIONAL NTP-format timestamp in RTP data packets. If such a timestamp is included, it MUST correspond to the same time instant as the RTP timestamp in the packet's header, and MUST be derived from the same clock used to generate the NTP-format timestamps included in RTCP SR packets. Provided it has knowledge of the SSRC to CNAME mapping, either from prior receipt of an RTCP CNAME packet or via out-of-band signalling [RFC5576], the receiver can use the information provided as input to the synchronisation algorithm, in exactly the same way as if an additional RTCP SR packet had been received for the flow.
[RFC5285]中定义的RTP报头扩展机制可适用于在RTP数据包中携带可选的NTP格式时间戳。如果包括这样的时间戳，则它必须与包的报头中的RTP时间戳对应相同的时间瞬间，并且必须从用于生成RTCP SR包中包括的NTP格式时间戳的相同时钟派生。如果从先前接收到RTCP CNAME数据包或通过带外信令[RFC5576]了解SSRC到CNAME的映射，则接收机可以使用提供的信息作为同步算法的输入，方式与接收到额外RTCP SR数据包时的方式完全相同。
Two variants are defined for this header extension. The first variant extends the RTP header with a 64-bit NTP-format timestamp as defined in [RFC5905]. The second variant carries the lower 24-bit part of the Seconds of a NTP-format timestamp and the 32 bits of the Fraction of a NTP-format timestamp. The formats of the two variants are shown in Figure 5 and Figure 6.
为此标头扩展定义了两个变体。第一种变体使用[RFC5905]中定义的64位NTP格式时间戳扩展RTP报头。第二种变体携带NTP格式时间戳秒数的较低24位部分和NTP格式时间戳分数的32位。这两种变体的格式如图5和图6所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|1| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R
| timestamp |T
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P
| synchronisation source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| 0xBE | 0xDE | length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
| ID-A | L=7 | NTP timestamp format - Seconds (bit 0-23) |x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
|NTP Sec.(24-31)| NTP timestamp format - Fraction (bit 0-23) |n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NTP Frc.(24-31)| 0 (pad) | 0 (pad) | 0 (pad) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| payload 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|1| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R
| timestamp |T
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P
| synchronisation source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| 0xBE | 0xDE | length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
| ID-A | L=7 | NTP timestamp format - Seconds (bit 0-23) |x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
|NTP Sec.(24-31)| NTP timestamp format - Fraction (bit 0-23) |n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NTP Frc.(24-31)| 0 (pad) | 0 (pad) | 0 (pad) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| payload data |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Variant A/64-Bit NTP RTP Header Extension
图5：变体A/64位NTP RTP头扩展
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|1| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R
| timestamp |T
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P
| synchronisation source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| 0xBE | 0xDE | length=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
| ID-B | L=6 | NTP timestamp format - Seconds (bit 8-31) |x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
| NTP timestamp format - Fraction (bit 0-31) |n
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| payload 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|1| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R
| timestamp |T
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P
| synchronisation source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| 0xBE | 0xDE | length=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
| ID-B | L=6 | NTP timestamp format - Seconds (bit 8-31) |x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
| NTP timestamp format - Fraction (bit 0-31) |n
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| payload data |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Variant B/56-Bit NTP RTP Header Extension
图6：变体B/56位NTP RTP报头扩展
An NTP-format timestamp MAY be included in any RTP packets the sender chooses, but it is RECOMMENDED when performing timestamp-based decoding order recovery for layered codecs transported in multiple RTP flows, as further specified in Section 4.1. This header extension SHOULD be also sent in the RTP packets corresponding to a video random access point, and in the associated audio packets, to allow rapid synchronisation for late joiners in multimedia sessions, and in video switching scenarios.
NTP格式时间戳可以包含在发送方选择的任何RTP数据包中，但建议在对在多个RTP流中传输的分层编解码器执行基于时间戳的解码顺序恢复时使用，如第4.1节中进一步规定。该报头扩展还应在与视频随机接入点相对应的RTP分组中以及在相关联的音频分组中发送，以允许在多媒体会话和视频交换场景中对延迟加入者进行快速同步。
Note: The inclusion of an RTP header extension will reduce the efficiency of RTP header compression, if it is used. Furthermore, middleboxes that do not understand the header extensions may remove them or may not update the content according to this memo.
注意：如果使用RTP报头扩展，则包含RTP报头扩展将降低RTP报头压缩的效率。此外，不理解标题扩展的中间盒可能会删除它们，或者可能不会根据此备忘录更新内容。
In all cases, irrespective of whether in-band NTP-format timestamps are included or not, regular RTCP SR packets MUST be sent to provide backwards compatibility with receivers that synchronise RTP flows according to [RFC3550], and robustness in the face of middleboxes (RTP translators) that might strip RTP header extensions. If the Variant B/56-bit NTP RTP header extension is used, RTCP sender reports MUST be used to derive the upper 8 bits of the Seconds for the NTP-format timestamp.
在所有情况下，无论是否包括带内NTP格式时间戳，必须发送常规RTCP SR数据包，以提供与根据[RFC3550]同步RTP流的接收器的向后兼容性，以及在可能剥离RTP报头扩展的中间盒（RTP转换器）面前的健壮性。如果使用变量B/56位NTP RTP报头扩展，则必须使用RTCP发送方报告来推导NTP格式时间戳的秒高8位。
When SDP is used, the use of the RTP header extensions defined above MUST be indicated as specified in [RFC5285]. Therefore, the following URIs MUST be used:
使用SDP时，必须按照[RFC5285]中的规定指示使用上述定义的RTP标头扩展。因此，必须使用以下URI：
o The URI used for signalling the use of Variant A/64-bit NTP RTP header extension in SDP is "urn:ietf:params:rtp-hdrext:ntp-64".
o 在SDP中，用于表示使用变体A/64位NTP RTP头扩展的URI是“urn:ietf:params:RTP hdrext:NTP-64”。
o The URI used for signalling the use of Variant B/56-bit NTP RTP header extension in SDP is "urn:ietf:params:rtp-hdrext:ntp-56".
o 在SDP中，用于向变体B/56位NTP RTP头扩展的使用发送信号的URI是“urn:ietf:params:RTP hdrext:NTP-56”。
The use of these RTP header extensions can greatly improve the user experience in IPTV channel surfing and in some interactive video conferencing scenarios. Network management tools that attempt to monitor the user experience may wish to log which sessions signal and use these extensions.
使用这些RTP报头扩展可以极大地改善IPTV频道浏览和某些交互式视频会议场景中的用户体验。尝试监视用户体验的网络管理工具可能希望记录哪些会话发出信号并使用这些扩展。
Packets in RTP flows are often predictively coded, with a receiver having to arrange the packets into a particular order before it can decode the media data. Depending on the payload format, the decoding order might be explicitly specified as a field in the RTP payload header, or the receiver might decode the packets in order of their RTP timestamps. If a layered encoding is used, where the media data is split across several RTP flows, then it is often necessary to exactly synchronise the RTP flows comprising the different layers before layers other than the base layer can be decoded. Examples of such layered encodings are H.264 SVC in NI-T mode [AVT-RTP-SVC] and MPEG surround multi-channel audio [RFC5691]. As described in Section 2, such synchronisation is possible in RTP, but can be difficult to perform rapidly. Below, we describe how the extensions defined in Section 3.3 can be used to synchronise layered flows, and provide a common timestamp-based decoding order.
RTP流中的数据包通常是经过预测编码的，在对媒体数据进行解码之前，接收器必须将数据包排列成特定的顺序。根据有效载荷格式，解码顺序可以明确指定为RTP有效载荷报头中的字段，或者接收机可以按照分组的RTP时间戳的顺序对分组进行解码。如果使用分层编码，其中媒体数据被分割到多个RTP流中，则通常需要在解码除基本层之外的层之前准确地同步包括不同层的RTP流。这种分层编码的示例是NI-T模式下的H.264 SVC[AVT-RTP-SVC]和MPEG环绕多声道音频[RFC5691]。如第2节所述，这种同步在RTP中是可能的，但很难快速执行。下面，我们将描述如何使用第3.3节中定义的扩展来同步分层流，并提供基于时间戳的通用解码顺序。
When a layered, multi-description, or multi-view codec is used, with the different components of the media being transferred on separate RTP flows, the RTP sender SHOULD use periodic synchronous in-band delivery of synchronisation metadata to allow receivers to rapidly and accurately synchronise the separate components of the layered media flow. There are three parts to this:
当使用分层、多描述或多视图编解码器时，媒体的不同组件在单独的RTP流上传输，RTP发送方应使用同步元数据的周期性同步带内传送，以允许接收器快速准确地同步分层媒体流的单独组件。这包括三个部分：
o The sender must negotiate the use of the RTP header extensions described in Section 3.3, and must periodically and synchronously insert such header extensions into all the RTP flows forming the separate components of the layered, multi-description, or multi-view flow.
o 发送方必须协商使用第3.3节中描述的RTP报头扩展，并且必须定期同步地将此类报头扩展插入构成分层、多描述或多视图流的单独组件的所有RTP流中。
o Synchronous insertion requires that the sender insert these RTP header extensions into packets corresponding to exactly the same sampling instant in all the flows. Since the header extensions
o 同步插入要求发送方将这些RTP头扩展插入到与所有流中完全相同的采样瞬间对应的数据包中。自标题扩展以来
for each flow are inserted at exactly the same sampling instant, they will have identical NTP-format timestamps, hence allowing receivers to exactly align the RTP timestamps for the component flows. This may require the insertion of extra data packets into some of the component RTP flows, if some component flows contain packets for sampling instants that do not exist in other flows (for example, a layered video codec, where the layers have differing frame rates).
对于在完全相同的采样时刻插入的每个流，它们将具有相同的NTP格式时间戳，因此允许接收器精确对齐组件流的RTP时间戳。这可能需要将额外的数据分组插入到一些组件RTP流中，如果一些组件流包含用于采样瞬间的分组，而这些分组不存在于其他流中（例如，分层视频编解码器，其中各层具有不同的帧速率）。
o The frequency with which the sender inserts the header extensions will directly correspond to the synchronisation latency, with more frequent insertion leading to higher per-flow overheads, but lower synchronisation latency. It is RECOMMENDED that the sender insert the header extensions synchronously into all component RTP flows at least once per random access point of the media, but they MAY be inserted more often.
o 发送方插入报头扩展的频率将直接对应于同步延迟，更频繁的插入会导致更高的每流开销，但同步延迟更低。建议发送方在媒体的每个随机接入点至少同步地将报头扩展插入所有组件RTP流一次，但可以更频繁地插入。
The sender MUST continue to send periodic RTCP reports including SR packets, and MUST ensure the RTP timestamp to NTP-format timestamp mapping in the RTCP SR packets is consistent with that used in the RTP header extensions. Receivers should use both the information contained in RTCP SR packets and the in-band mapping of RTP and NTP-format timestamps as input to the synchronisation process, but it is RECOMMENDED that receivers sanity check the mappings received and discard outliers, to provide robustness against invalid data (one might think it more likely that the RTCP SR mappings are invalid, since they are sent at irregular times and subject to skew, but the presence of broken RTP translators could also corrupt the timestamps in the RTP header extension; receivers need to cope with both types of failure).
发送方必须继续发送定期RTCP报告，包括SR数据包，并且必须确保RTCP SR数据包中的RTP时间戳到NTP格式时间戳映射与RTP报头扩展中使用的一致。接收机应使用RTCP SR数据包中包含的信息以及RTP和NTP格式时间戳的带内映射作为同步过程的输入，但建议接收机检查接收到的映射并丢弃异常值，以提供对无效数据的鲁棒性（有人可能会认为RTCP SR映射更可能无效，因为它们在不规则的时间发送并且会出现偏差，但损坏的RTP转换器也可能损坏RTP标头扩展中的时间戳；接收器需要处理这两种类型的故障）。
Once a receiver has synchronised the components of a layered, multi-description, or multi-view flow using the RTP header extensions as described in Section 4.1, it may then derive a decoding order based on the synchronised timestamps as follows (or it may use information in the RTP payload header to derive the decoding order, if present and desired).
一旦接收器使用第4.1节中所述的RTP报头扩展同步了分层、多描述或多视图流的组件，它就可以基于同步的时间戳导出解码顺序，如下所示（或者，如果存在并且需要，它可以使用RTP有效载荷报头中的信息来导出解码顺序）。
There may be explicit dependencies between the component flows of a layered, multi-description, or multi-view flow. For example, it is common for layered flows to be arranged in a hierarchy, where flows from "higher" layers cannot be decoded until the corresponding data in "lower" layer flows has been received and decoded. If such a decoding hierarchy exists, it MUST be signalled out of band, for example using [RFC5583] when SDP signalling is used.
分层、多描述或多视图流的组件流之间可能存在明确的依赖关系。例如，分层流被安排在层次中是常见的，其中来自“更高”层的流在“更低”层流中的相应数据被接收和解码之前不能被解码。如果存在这样的解码层次结构，则必须在带外发送信号，例如在使用SDP信号时使用[RFC5583]。
Each component RTP flow MUST contain packets corresponding to all the sampling instants of the RTP flows on which it depends. If such packets are not naturally present in the RTP flow, the sender MUST generate additional packets as necessary in order to satisfy this rule. The format of these packets depends on the payload format used. For H.264 SVC, the Empty Network Abstraction Layer (NAL) unit packet [AVT-RTP-SVC] should be used. Flows may also include packets corresponding to additional sampling instants that are not present in the flows on which they depend.
每个组件RTP流必须包含与其所依赖的RTP流的所有采样瞬间对应的数据包。如果RTP流中不自然存在此类数据包，则发送方必须根据需要生成附加数据包，以满足此规则。这些数据包的格式取决于所使用的有效负载格式。对于H.264 SVC，应使用空的网络抽象层（NAL）单元数据包[AVT-RTP-SVC]。流还可以包括对应于附加采样瞬间的分组，这些额外采样瞬间不存在于它们所依赖的流中。
The receiver should decode the packets in all the component RTP flows as follows:
接收器应按照以下方式解码所有组件RTP流中的数据包：
o For each RTP packet in each flow, use the mapping contained in the RTP header extensions and RTCP SR packets to derive the NTP-format timestamp corresponding to its RTP timestamp.
o 对于每个流中的每个RTP数据包，使用RTP报头扩展和RTCP SR数据包中包含的映射来导出与其RTP时间戳对应的NTP格式时间戳。
o Group together RTP data packets from all component flows that have identical calculated NTP-format timestamps.
o 将来自具有相同计算NTP格式时间戳的所有组件流的RTP数据包组合在一起。
o Processing groups in order of ascending NTP-format timestamps, decode the RTP packets in each group according to the signalled RTP flow decoding hierarchy. That is, pass the RTP packet data from the flow on which all other flows depend to the decoder first, then that from the next dependent flow, and so on. The decoding order of the RTP flow hierarchy may be indicated by mechanisms defined in [RFC5583] or by some other means.
o 处理组按照递增NTP格式时间戳的顺序，根据信令RTP流解码层次对每个组中的RTP分组进行解码。即，首先将来自所有其他流所依赖的流的RTP分组数据传递给解码器，然后将来自下一个依赖流的RTP分组数据传递给解码器，依此类推。RTP流层次结构的解码顺序可以通过[RFC5583]中定义的机制或一些其他方式来指示。
Note that the decoding order will not necessarily match the packet transmission order. The receiver will need to buffer packets for a codec-dependent amount of time in order for all necessary packets to arrive to allow decoding.
注意，解码顺序不一定与分组传输顺序匹配。接收器将需要缓冲数据包一段取决于编解码器的时间，以便所有必要的数据包到达以允许解码。
The example shown in Figure 7 refers to three RTP flows A, B, and C, containing a layered, a multi-view, or a multi-description media stream. In the example, the dependency signalling as defined in [RFC5583] indicates that flow A is the lowest RTP flow. Flow B is the next higher RTP flow and depends on A. Flow C is the highest of the three RTP flows and depends on both A and B. A media coding structure is used that results in video access units (i.e., coded video frames) present in higher flows but not present in all lower flows. Flow A has the lowest frame rate. Flows B and C have the same frame rate, which is higher than that of Flow A. The figure shows the full video access units with their corresponding RTP timestamps "(x)". The video access units are already re-ordered according to their RTP sequence number order. The figure indicates
图7中所示的示例涉及三个RTP流A、B和C，其中包含分层、多视图或多描述媒体流。在该示例中，[RFC5583]中定义的依赖信令指示流A是最低的RTP流。流B是下一个较高的RTP流，取决于A。流C是三个RTP流中最高的，取决于A和B。使用媒体编码结构，使得视频访问单元（即编码视频帧）出现在较高的流中，但不出现在所有较低的流中。流A具有最低的帧速率。流B和流C具有相同的帧速率，这高于流A。该图显示了完整的视频访问单元及其相应的RTP时间戳“（x）”。视频访问单元已根据其RTP序列号顺序重新订购。图中显示
the received video access unit part in decoding order within each RTP flow, as well as the associated NTP media timestamps ("TS[..]"). As shown in the figure, these timestamps may be derived using the NTP-format timestamp provided in the RTCP sender reports as indicated by the timestamp in "{x}", or derived directly from the NTP timestamp contained in the RTP header extensions as indicated by the timestamp in "<x>". Note that the timestamps are not in increasing order since, in this example, the decoding order is different from the output/presentation order.
接收到的视频访问单元在每个RTP流中以解码顺序排列，以及相关联的NTP媒体时间戳（“TS[…]”）。如图所示，这些时间戳可以使用RTCP发送方报告中提供的NTP格式时间戳（如“{x}”中的时间戳所示）来派生，或者直接从RTP头扩展中包含的NTP时间戳（如“<x>中的时间戳所示）派生。注意，时间戳不是递增顺序，因为在此示例中，解码顺序不同于输出/呈现顺序。
The decoding order recovery process first advances to the video access unit parts associated with the first available synchronous insertion of the NTP timestamp into RTP header extensions at NTP media timestamp TS=[8]. The receiver starts in the highest RTP flow C and removes/ignores all preceding video access unit parts (in decoding order) to video access unit parts with TS=[8] in each of the de-jittering buffers of RTP flows A, B, and C. Then, starting from flow C, the first media timestamp available in decoding order (TS=[8]) is selected, and video access unit parts starting from RTP flow A, and flows B and C are placed in order of the RTP flow dependency as indicated by mechanisms defined in [RFC5583] (in the example for TS[8]: first flow B and then flow C into the video access unit AU(TS[8]) associated with NTP media timestamp TS=[8]). Then the next media timestamp TS=[6] (RTP timestamp=(4)) in order of appearance in the highest RTP flow C is processed, and the process described above is repeated. Note that there may be video access units with no video access unit parts present, e.g., in the lowest RTP flow A (see, e.g., TS=[5]). The decoding order recovery process could also be started after an RTP sender report containing the mapping between the RTP timestamp and the NTP-format timestamp (indicated as timestamps "(x){y}") has been received, assuming that there is no clock skew in the source used for the NTP-format timestamp generation.
解码顺序恢复过程首先前进到与NTP媒体时间戳TS=[8]处的NTP时间戳的第一次可用同步插入到RTP报头扩展相关联的视频访问单元部分。接收器在最高的RTP流C中启动，并移除/忽略所有前面的视频访问单元部分（以解码顺序）到RTP流A、B和C的每个解抖动缓冲器中TS=[8]的视频访问单元部分。然后，从流C开始，选择以解码顺序（TS=[8]）可用的第一个媒体时间戳，以及从RTP流A开始的视频访问单元部分，以及流B和C按照RTP流依赖性的顺序放置，如[RFC5583]（在TS[8]的示例中）中定义的机制所示：首先流B，然后流C进入与NTP媒体时间戳TS=[8]相关联的视频访问单元AU（TS[8]）。然后，按照最高RTP流C中的出现顺序处理下一媒体时间戳TS=[6]（RTP时间戳=（4）），并且重复上述处理。注意，可能存在不存在视频访问单元部件的视频访问单元，例如，在最低RTP流A中（参见，例如，TS=[5]）。解码顺序恢复过程也可以在接收到包含RTP时间戳和NTP格式时间戳（指示为时间戳“（x）{y}”）之间的映射的RTP发送方报告之后启动，假设用于NTP格式时间戳生成的源中没有时钟偏移。
C:-(0)----(2)----(7)<8>--(5)----(4)----(6)-----(11)----(9){10}-
| | | | | | | |
B:-(3)----(5)---(10)<8>--(8)----(7)----(9){7}--(14)----(12)----
| | | |
A:---------------(3)<8>--(1)-------------------(7){12}-(5)-----
C:-(0)----(2)----(7)<8>--(5)----(4)----(6)-----(11)----(9){10}-
| | | | | | | |
B:-(3)----(5)---(10)<8>--(8)----(7)----(9){7}--(14)----(12)----
| | | |
A:---------------(3)<8>--(1)-------------------(7){12}-(5)-----
---------------------------------------decoding/transmission order->
TS:[1] [3] [8]=<8> [6] [5] [7] [12] [10]
---------------------------------------decoding/transmission order->
TS:[1] [3] [8]=<8> [6] [5] [7] [12] [10]
Key:
关键：
A, B, C - RTP flows
A、 B，C-RTP流
Integer values in "()" - video access unit with its RTP timestamp as indicated in its RTP packet.
“（）”中的整数值-视频访问单元，其RTP时间戳在其RTP数据包中指示。
"|" - indicates the corresponding parts of the same video access unit AU(TS[..]) in the RTP flows.
“|”-表示RTP流中相同视频访问单元AU（TS[…]）的对应部分。
Integer values in "[]" - NTP media timestamp TS, sampling time as derived from the NTP timestamp associated with the video access unit AU(TS[..]), consisting of video access unit parts in the flows above.
“[]”中的整数值-NTP媒体时间戳TS，从与视频访问单元AU（TS[…]）相关联的NTP时间戳导出的采样时间，包括上述流中的视频访问单元部分。
Integer values in "<>" - NTP media timestamp TS as directly taken from the NTP RTP header extensions.
“<>”-NTP媒体时间戳TS中的整数值，直接取自NTP RTP标头扩展。
Integer values in "{}" - NTP media timestamp TS as provided in the RTCP sender reports.
RTCP发送方报告中提供的“{}”-NTP媒体时间戳TS中的整数值。
Figure 7: Example of a Layered RTP Stream
图7：分层RTP流的示例
The security considerations of the RTP specification [RFC3550], the extended RTP profile for RTCP-based feedback [RFC4585], and the general mechanism for RTP header extensions [RFC5285] apply.
RTP规范[RFC3550]、基于RTCP的反馈的扩展RTP配置文件[RFC4585]和RTP报头扩展的一般机制[RFC5285]的安全注意事项适用。
The RTP header extensions defined in Section 3.3 include an NTP-format timestamp. When an RTP session using this header extension is protected by the Secure RTP (SRTP) framework [RFC3711], that header extension is not part of the encrypted portion of the RTP data packets or RTCP control packets; however, these NTP-format timestamps are encrypted when using SRTP without this header extension. This is a minor information leak, but one that is not believed to be
第3.3节中定义的RTP报头扩展包括NTP格式的时间戳。当使用该报头扩展的RTP会话受到安全RTP（SRTP）框架[RFC3711]的保护时，该报头扩展不是RTP数据包或RTCP控制包的加密部分的一部分；但是，当使用SRTP而不使用此标头扩展时，这些NTP格式的时间戳是加密的。这是一次轻微的信息泄漏，但据信并非如此
significant. The inclusion of this header extension will also reduce the efficiency of RTP header compression, if it is used. Furthermore, middleboxes that do not understand the header extensions may remove them or may not update the content according to this memo.
重要的如果使用RTP报头压缩，则包含此报头扩展还将降低RTP报头压缩的效率。此外，不理解标题扩展的中间盒可能会删除它们，或者可能不会根据此备忘录更新内容。
The IANA has registered one new value in the table of FMT Values for RTPFB Payload Types [RFC4585] as follows:
IANA在RTPFB有效载荷类型[RFC4585]的FMT值表中注册了一个新值，如下所示：
Name: RTCP-SR-REQ Long name: RTCP Rapid Resynchronisation Request Value: 5 Reference: RFC 6051
名称：RTCP-SR-REQ长名称：RTCP快速再同步请求值：5参考：RFC 6051
The IANA has also registered two new RTP Compact Header Extensions [RFC5285], according to the following:
IANA还注册了两个新的RTP Compact标头扩展[RFC5285]，如下所示：
Extension URI: urn:ietf:params:rtp-hdrext:ntp-64
Description: Synchronisation metadata: 64-bit timestamp format
Contact: Thomas Schierl <ts@thomas-schierl.de>
IETF Audio/Video Transport Working Group
Reference: RFC 6051
Extension URI: urn:ietf:params:rtp-hdrext:ntp-64
Description: Synchronisation metadata: 64-bit timestamp format
Contact: Thomas Schierl <ts@thomas-schierl.de>
IETF Audio/Video Transport Working Group
Reference: RFC 6051
Extension URI: urn:ietf:params:rtp-hdrext:ntp-56
Description: Synchronisation metadata: 56-bit timestamp format
Contact: Thomas Schierl <ts@thomas-schierl.de>
IETF Audio/Video Transport Working Group
Reference: RFC 6051
Extension URI: urn:ietf:params:rtp-hdrext:ntp-56
Description: Synchronisation metadata: 56-bit timestamp format
Contact: Thomas Schierl <ts@thomas-schierl.de>
IETF Audio/Video Transport Working Group
Reference: RFC 6051
This memo has benefited from discussions with numerous members of the IETF AVT working group, including Jonathan Lennox, Magnus Westerlund, Randell Jesup, Gerard Babonneau, Ingemar Johansson, Ali C. Begen, Ye-Kui Wang, Roni Even, Michael Dolan, Art Allison, and Stefan Doehla. The RTP header extension format of Variant A in Section 3.3 was suggested by Dave Singer, matching a similar mechanism specified by the Internet Streaming Media Alliance (ISMA).
本备忘录得益于与IETF AVT工作组众多成员的讨论，包括乔纳森·伦诺克斯、马格努斯·韦斯特隆德、兰德尔·杰苏普、杰拉德·巴邦诺、英格玛·约翰逊、阿里·C·贝根、叶奎王、罗尼·埃文、迈克尔·多兰、阿特·艾利森和斯特凡·多拉。第3.3节中变体A的RTP报头扩展格式由Dave Singer提出，与互联网流媒体联盟（ISMA）指定的类似机制相匹配。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[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, July 2006.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 45852006年7月。
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, July 2008.
[RFC5285]Singer，D.和H.Desneni，“RTP标头扩展的一般机制”，RFC 5285，2008年7月。
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, April 2009.
[RFC5506]Johansson，I.和M.Westerlund，“支持缩小尺寸实时传输控制协议（RTCP）：机会和后果”，RFC 5506，2009年4月。
[RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding Dependency in the Session Description Protocol (SDP)", RFC 5583, July 2009.
[RFC5583]Schierl，T.和S.Wenger，“会话描述协议（SDP）中的信令媒体解码依赖性”，RFC 5583，2009年7月。
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC5760]Ott，J.，Chesterfield，J.，和E.Schooler，“具有单播反馈的单源多播会话的RTP控制协议（RTCP）扩展”，RFC 57602010年2月。
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905]Mills，D.，Martin，J.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 59052010年6月。
[AVT-ACQUISITION-RTP] VerSteeg, B., Begen, A., VanCaenegem, T., and Z. Vax, "Unicast-Based Rapid Acquisition of Multicast RTP Sessions", Work in Progress, October 2010.
[AVT-ACQUISITION-RTP]VerSteeg，B.，Begen，A.，VanCaenegem，T.，和Z.Vax，“基于单播的多播RTP会话快速捕获”，正在进行的工作，2010年10月。
[AVT-RTP-SVC] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, "RTP Payload Format for SVC Video Coding", Work in Progress, October 2010.
[AVT-RTP-SVC]Wenger，S.，Wang，Y.，Schierl，T.，和A.Eleftheriadis，“SVC视频编码的RTP有效载荷格式”，正在进行的工作，2010年10月。
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[RFC3556]Casner，S.，“RTP控制协议（RTCP）带宽的会话描述协议（SDP）带宽修饰符”，RFC 3556，2003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.
[RFC5117]Westerlund，M.和S.Wenger，“RTP拓扑”，RFC 51172008年1月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月。
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009.
[RFC5576]Lennox，J.，Ott，J.，和T.Schierl，“会话描述协议（SDP）中的源特定媒体属性”，RFC 55762009年6月。
[RFC5691] de Bont, F., Doehla, S., Schmidt, M., and R. Sperschneider, "RTP Payload Format for Elementary Streams with MPEG Surround Multi-Channel Audio", RFC 5691, October 2009.
[RFC5691]de Bont，F.，Doehla，S.，Schmidt，M.，和R.Sperschneider，“具有MPEG环绕多声道音频的基本流的RTP有效负载格式”，RFC 5691，2009年10月。
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5764]McGrew，D.和E.Rescorla，“为安全实时传输协议（SRTP）建立密钥的数据报传输层安全（DTLS）扩展”，RFC 5764，2010年5月。
[ZRTP] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: Media Path Key Agreement for Unicast Secure RTP", Work in Progress, June 2010.
[ZRTP]Zimmermann，P.，Johnston，A.，Ed.，和J.Callas，“ZRTP：单播安全RTP的媒体路径密钥协议”，正在进行的工作，2010年6月。
Authors' Addresses
作者地址
Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ UK
柯林帕金斯格拉斯哥大学计算科学学院格拉斯哥G128QQ英国
EMail: csp@csperkins.org
EMail: csp@csperkins.org
Thomas Schierl Fraunhofer HHI Einsteinufer 37 D-10587 Berlin Germany
Thomas Schierl Fraunhofer HHI Einsteinufer 37 D-10587德国柏林
Phone: +49-30-31002-227
EMail: ts@thomas-schierl.de
Phone: +49-30-31002-227
EMail: ts@thomas-schierl.de